Sicurezza della crittografia a livello di collegamento Bluetooth Low Energy (BLE)

14

La crittografia a livello di collegamento Bluetooth Low Energy (BLE) è protetta contro un utente malintenzionato che intercetta una connessione BLE casuale tra due dispositivi, ma non ha intercettato la prima connessione tra i due dispositivi?

Sfondo: quando i due dispositivi sono inizialmente accoppiati, derivano una chiave a lungo termine utilizzando un protocollo di scambio di chiavi. Chiunque riesca a origliare quell'associazione iniziale può apprendere la chiave a lungo termine, ma ai fini di questa domanda, supponi che l'avversario non abbia origliato quell'associazione iniziale (ad esempio perché l'avversario non era nelle vicinanze). I due dispositivi utilizzano quindi questa chiave a lungo termine per crittografare i dati inviati su tutte le connessioni future. BLE utilizza AES-CCM per la crittografia a livello di collegamento, che dovrebbe essere protetta se la chiave a lungo termine è imprevedibile.

Tuttavia, alla WOOT 2013, Mark Ryan ha pubblicato un articolo che speculava su un possibile attacco contro BLE. Nel suo attacco, l'attaccante inietta un messaggio LL_REJECT_IND falsificato su un dispositivo. Apparentemente questo farà sì che il destinatario dimentichi l'attuale chiave a lungo termine e costringa un nuovo scambio di chiavi a ricavare una nuova chiave a lungo termine. L'attaccante può origliare su questo nuovo scambio di chiavi, imparare la nuova chiave a lungo termine e decodificare tutto il traffico successivo. Almeno, questo è quello che ha ipotizzato Ryan.

Questo attacco funziona davvero? La crittografia a livello di collegamento di BLE è insicura, anche se l'utente malintenzionato non ha acquisito l'associazione iniziale tra i due dispositivi?

Riferimento: Mike Ryan, " Bluetooth: con bassa energia arriva bassa sicurezza ", WOOT 2013. link

    
posta D.W. 17.09.2015 - 04:18
fonte

1 risposta

13

L'attacco funziona davvero. Ho giocato con l'Ubertooth One che ho acquisito al DEF CON cinque anni fa e l'ho testato su una varietà di dispositivi IoT che implementano lo standard BLE. Il documento di Mike Ryan è corretto.

Dal libro "Abuse the Internet of Things", l'autore discute il lavoro di Mike Ryan e l'implementazione con Ubertooth One.

ubertooth-btle -f -c ble.pcap

L'autore discute anche sull'uso dell'app LightBlue iOS per una ulteriore risoluzione dei problemi, poiché può copiare i dispositivi Bluetooth ed emularli. Ci vuole un po 'di lavoro con BLE perché utilizza molti canali, quindi si consiglia vivamente di accendere e spegnere le interfacce durante la valutazione della cattura di rete.

I dati crittografati BLE standard utilizzano un protocollo di scambio di chiavi selezionando una chiave temporanea basata su AES (TK). Mike Ryan ha rilasciato lo strumento crackle per forzare questa chiave.

crackle -i ble.pcap -o decrypted-ble.pcap

Questa tecnica non è efficace contro la modalità OOB (chiave opzionale a 128 bit definita anche da BLE), tuttavia, come visto su mailing list di ubertooth , il team di sviluppo sta lavorando per raccogliere campioni e risolvere le possibilità di interrompere la modalità OOB.

Un noto blog sulle tecnologie di pagamento e l'infrastruttura associata è stato anche speculando sulla fine della sicurezza Bluetooth, compresi alcuni commenti sulla rottura della modalità BOB OOB. Aggiornamento 29/12/2015: C'è più discussione su BT 2.1. Si è anche imbattuto in btproxy, che sperabilmente sosterrà presto BTLE. Un altro tutorial che ho trovato è intitolato Sniffing and Cracking Bluetooth con UbertoothOne .

Tuttavia, (come visto nel libro "Hacking Exposed Wireless, 3rd Edition") l'idea di riparare Bluetooth è stata pubblicizzata per la prima volta nel documento "Cracking the Bluetooth PIN" di Yaniv Shaked e Avishai Wool ( link ). Un avversario può utilizzare un "attacco di riparazione" per manipolare lo stato di accoppiamento memorizzato tra due dispositivi impersonando il BD_ADDR di uno dei due dispositivi.

Lo strumento bdaddr è l'implementazione principale di questa tecnica.

gcc -obdaddr -lbluetooth bdaddr.c
hciconfig hci0
sudo bdaddr -i hci0 <new bdaddr>
(asks to reset device now)
sudo bccmd -d hci0 warmreset
(check that it changed)
hciconfig hci0
sudo hcitool cc <bdaddr of target to repair to>
sudo hcitool enc <bdaddr target again> enable

Per tornare a una lavagna pulita

sudo bccmd -d hci0 coldreset
hciconfig hci0
    
risposta data 17.09.2015 - 05:34
fonte

Leggi altre domande sui tag