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.

WhisperPair: Kritická zranitelnost v Google Fast Pair ohrožuje miliony Bluetooth zařízení

Úvod

V lednu 2026 byla zveřejněna informace o kritické bezpečnostní zranitelnosti s označením CVE-2025-36911, která ohrožuje stovky milionů Bluetooth audio zařízení podporujících technologii Google Fast Pair. Tato zranitelnost, pojmenovaná WhisperPair, umožňuje útočníkům neautorizovaně převzít kontrolu nad zařízením a v některých případech i sledovat jeho majitele pomocí lokalizační sítě Google Find Hub.

Zranitelnost objevili výzkumníci z výzkumné skupiny COSIC na KU Leuven v Belgii, kteří problém odpovědně nahlásili společnosti Google již v srpnu 2025. Google klasifikoval tento problém jako kritický a udělil výzkumníkům maximální možnou odměnu 15 000 dolarů.

Co je Google Fast Pair?

Google Fast Pair je technologie usnadňující párování Bluetooth příslušenství s Android zařízeními. Místo klasického postupu, kdy uživatel musí manuálně vyhledat zařízení v nastavení Bluetooth, umožňuje Fast Pair spárování jediným dotykem po otevření pouzdra sluchátek. Systém navíc synchronizuje zařízení napříč všemi Android zařízeními přihlášenými ke stejnému Google účtu.

Tato funkce byla přijata mnoha předními výrobci audio příslušenství, včetně společností Sony, Google, Anker, JBL a dalších. Fast Pair je integrován přímo do firmwaru příslušenství a nelze ho vypnout.

Jak WhisperPair funguje?

Primární útok: Neautorizované párování

Útok WhisperPair využívá chybu v implementaci Fast Pair protokolu, kterou obsahuje překvapivě velké množství vlajkových produktů. Podle specifikace Fast Pair by zařízení mělo ignorovat požadavky na párování, pokud není v párovacím režimu. Mnohá zařízení však tuto kontrolu neimplementují správně.

Průběh útoku je následující:

1. Iniciace spojení: Útočník odešle zprávu Seekeru (zařízení, které chce provést párování) k Provideru (audio příslušenství), i když příslušenství není v párovacím režimu.

2. Nedostatečná validace: Zranitelné zařízení odpovídá na požadavek, ačkoliv by ho mělo ignorovat. Chybí kritická kontrola stavu zařízení.

3. Dokončení párování: Po obdržení odpovědi může útočník dokončit Fast Pair proceduru a navázat standardní Bluetooth spojení.

Celý útok trvá v mediánu pouhých 10 sekund a funguje na vzdálenost až 14 metrů. Nevyžaduje fyzický přístup k zařízení ani interakci s uživatelem. Útočník může použít běžný hardware, jako je notebook, smartphone nebo Raspberry Pi.

Po úspěšném převzetí má útočník plnou kontrolu nad zařízením. Může:

• Přehrávat audio na maximální hlasitosti
• Nahrávat rozhovory přes mikrofon zařízení
• Odposlouchávat veškerý zvuk přehrávaný na zařízení

Sekundární útok: Sledování polohy

WhisperPair umožňuje i sofistikovanější útok zaměřený na sledování polohy obětí. Tento útok funguje následovně:

1. Exploitace vlastnictví: Google Find Hub Network umožňuje majitelům najít ztracená zařízení pomocí crowdsourcovaných lokalizačních zpráv z Android zařízení. Vlastnictví zařízení je určeno prvním Account Key zapsaným do příslušenství při párování s Android zařízením.

2. Podmínka útoku: Pokud oběť nikdy nespárovala své příslušenství s Android zařízením (například používá iPhone nebo počítač), útočník může pomocí WhisperPair zařízení spárovat a zapsat svůj vlastní Account Key.

3. Následek: Útočník se stane "vlastníkem" zařízení v systému Find Hub a může sledovat jeho polohu v reálném čase prostřednictvím Android zařízení v okolí.

4. Maskování: Oběť může po několika hodinách nebo dnech obdržet upozornění na nechtěné sledování, ale toto upozornění zobrazí její vlastní zařízení, což může vést k tomu, že varování odmítne jako chybu systému.

Rozsah dopadu

WhisperPair není izolovaný problém jednoho výrobce. Výzkum prokázal, že zranitelnost postihuje:

• Více výrobců: Sony, Google (Pixel Buds), Anker, JBL, Nothing a další
• Různé chipsety: Problém není specifický pro jeden chipset, což naznačuje systematickou chybu v pochopení specifikace
• Vlaková produkty: I nejnovější a nejdražší produkty jsou zranitelné

Selhání na všech úrovních

Zranitelná zařízení prošla:

1. Interním testováním výrobců
2. Certifikačním procesem Google Fast Pair
3. Standardními QA testy

To demonstruje systémové selhání, nikoliv individuální vývojářskou chybu. Celý řetězec validace selhal při detekci této kritické zranitelnosti.

Kdo je zranitelný?

Zranitelnost postihuje všechny uživatele Bluetooth audio příslušenství s podporou Fast Pair, bez ohledu na používaný smartphone:

• Android uživatelé: Plně zranitelní vůči oběma útokům
• iPhone uživatelé: Zranitelní vůči útoku neautorizovaného párování i sledování polohy
• Ostatní platformy: Stejně zranitelní, protože Fast Pair je implementován v příslušenství, nikoliv v telefonu

Vypnutí Fast Pair skenování v nastavení Android telefonu problém neřeší, protože funkce je integrována přímo do firmwaru příslušenství.

Jak se chránit

Jediné řešení: Aktualizace firmwaru

Zranitelnost nelze opravit žádným nastavením ani factory resetem zařízení. Jediným řešením je instalace bezpečnostní aktualizace firmwaru vydané výrobcem příslušenství.

Doporučené kroky:

1. Identifikujte svá zařízení podporující Fast Pair (sluchátka, reproduktory)
2. Navštivte webovou stránku výrobce nebo konzultujte manuál
3. Zkontrolujte dostupnost bezpečnostní aktualizace
4. Nainstalujte nejnovější verzi firmwaru

Seznam zranitelných zařízení

Webová stránka whisperpair.eu poskytuje nástroj pro kontrolu konkrétních modelů zařízení. Mezi potvrzené zranitelné produkty patří:

• Google Pixel Buds Pro 2
• Sony WH-1000XM5 a další modely
• Anker Soundcore Liberty
• Nothing Ear
• JBL různé modely

Technická perspektiva: Návrh opravy

Výzkumníci ve své práci nenabízejí pouze identifikaci problému, ale i návrh řešení. Namísto spoléhání se na kontrolu stavu na aplikační vrstvě navrhují:

Kryptografickou vazbu záměru párování: Podmínku párování začlenit přímo do derivace klíčů. Tento přístup zajišťuje, že problém je řešen na nejvyšší možné úrovni protokolu, kde je nejméně pravděpodobné jeho opominutí.

Detaily tohoto návrhu budou brzy publikovány v akademické práci výzkumníků.

Zodpovědné zveřejnění a reakce

Timeline

• Srpen 2025: Nahlášení zranitelnosti společnosti Google
• 150denní okno: Čas pro práci s partnery na vydání záplat
• Leden 2026: Veřejné zveřejnění informací

Spolupráce

Google a Android Security Team projevili vysokou míru spolupráce:

• Klasifikace jako kritická zranitelnost (CVE-2025-36911)
• Maximální odměna 15 000 USD
• Koordinace s výrobci na vydání záplat
• Aktivní komunikace během celého procesu

Výzkumníci vyjádřili poděkování Google za jejich odpovědný přístup a rychlou reakci.

Mediální ohlas

Zranitelnost WhisperPair získala značnou pozornost mezinárodních médií:

• WIRED: Rozsáhlý článek o stovkách milionů ohrožených zařízení
• The Verge: Detailní pokrytí technických aspektů
• Ars Technica: Analýza dopadu na ekosystém
• The New York Times: Praktické rady pro ochranu

Český mediální prostor na problém reagoval prostřednictvím De Morgen, Het Nieuwsblad, Datanews a dalších médií.

Výzkumný tým

Zranitelnost objevil tým výzkumníků ze skupiny COSIC na KU Leuven:

Primární autoři:

• Sayon Duttagupta (COSIC)
• Seppe Wyns (DistriNet - Group T, dříve COSIC)

Přispívající výzkumníci:

• Nikola Antonijević (COSIC)
• Bart Preneel (COSIC)
• Dave Singelée (DistriNet - Group T)

Práce byla podpořena vlámskou vládou prostřednictvím programu Cybersecurity Research.

Závěr

WhisperPair představuje vážné memento o rizicích spojených s tzv. "convenience features" - funkcemi zaměřenými na zlepšení uživatelského komfortu. Zatímco Google Fast Pair skutečně zjednodušuje párování Bluetooth zařízení, jeho implementace přinesla bezpečnostní rizika pro stovky milionů uživatelů.

Případová studie WhisperPair ukazuje několik důležitých lekcí:

1. Bezpečnost musí být prioritou: Convenience funkce nesmějí být implementovány na úkor bezpečnosti
2. Certifikace není zárukou: I přísné certifikační procesy mohou přehlédnout kritické chyby
3. Zodpovědné zveřejnění funguje: Spolupráce mezi výzkumníky a výrobci vede k rychlejší nápravě
4. Aktualizace jsou klíčové: Firmware příslušenství je stejně důležitý jako aktualizace operačního systému

Pro uživatele je klíčovým poučením nutnost pravidelně aktualizovat nejen smartphone, ale i všechna připojená zařízení. V moderním propojeném světě je bezpečnost celého ekosystému určena nejslabším článkem.

Zdroje:

• WhisperPair.eu - oficiální stránka výzkumu
• CVE-2025-36911 - oficiální záznam zranitelnosti
• Zprávy WIRED, The Verge, Ars Technica a dalších médií

Poznámka: V době publikace tohoto článku již mnoho výrobců vydalo bezpečnostní záplaty. Uživatelé by měli co nejdříve zkontrolovat dostupnost aktualizací pro svá zařízení.

The post WhisperPair: Kritická zranitelnost v Google Fast Pair first appeared on Hard Wired.