Váš Bluetooth čip křičí šifrovací klíče. Slyšet ho jde z parkoviště.

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:

Komponenta Model Cena
Target čip Nordic nRF52832 PCA10040 DK ~1 000 Kč
SDR přijímač HackRF One máte
Anténa WiFi directional 2,4 GHz (TP-Link nebo podobná) ~500 Kč
Počítač Linux, GNURadio 3.7+ máte

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:

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):

Kód a datasety:

Prezentace:

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é.

Loading

Tags