Sécurité du chiffrement de couche liaison Bluetooth Low Energy (BLE)
Le cryptage de la couche liaison de Bluetooth Low Energy (BLE) est-il sécurisé contre un attaquant qui espionne une connexion BLE aléatoire entre deux appareils, mais qui n'a pas écouté la première connexion entre les deux appareils?
Contexte: lorsque les deux appareils sont initialement couplés, ils dérivent une clé à long terme à l'aide d'un protocole d'échange de clés. Quiconque peut espionner cet appariement initial peut apprendre la clé à long terme, mais aux fins de cette question, supposez que l'adversaire n'écoute pas cet appariement initial (par exemple, parce que l'adversaire n'était pas à proximité). Les deux appareils utilisent ensuite cette clé à long terme pour crypter les données envoyées sur toutes les futures connexions. BLE utilise AES-CCM pour le chiffrement de la couche liaison, qui doit être sécurisé si la clé à long terme est imprévisible.
Cependant, à WOOT 2013, Mark Ryan a publié un article spéculant sur une éventuelle attaque contre le BLE. Dans son attaque, l'attaquant injecte un faux message LL_REJECT_IND à un appareil. Apparemment, cela obligera le destinataire à oublier la clé à long terme actuelle et à forcer un nouvel échange de clé à dériver une nouvelle clé à long terme. L'attaquant peut espionner ce nouvel échange de clés, connaître la nouvelle clé à long terme et décrypter tout le trafic ultérieur. Du moins, c'est ce que Ryan a spéculé.
Cette attaque fonctionne-t-elle réellement? Le cryptage de couche liaison de BLE n'est-il pas sécurisé, même si l'attaquant n'a pas capturé le couplage initial entre les deux appareils?
Référence: Mike Ryan, " Bluetooth: avec Low Energy vient Low Security ", WOOT 2013. https://www.usenix.org/conference/woot13/workshop-program/presentation/ Ryan
L'attaque fonctionne réellement. J'ai joué avec l'Ubertooth One que j'ai acquis au DEF CON il y a cinq ans et je l'ai testé contre une variété d'appareils IoT qui implémentent la norme BLE. Le papier de Mike Ryan est correct.
À partir du livre "Abusing the Internet of Things", l'auteur discute du travail de Mike Ryan et de sa mise en œuvre avec Ubertooth One.
ubertooth-btle -f -c ble.pcap
L'auteur discute également de l'utilisation de l'application iOS LightBlue pour un dépannage plus approfondi, car elle peut copier des appareils Bluetooth et les émuler. Cela nécessite un certain travail avec BLE car il utilise de nombreux canaux, il est donc fortement recommandé d'activer et de désactiver les interfaces lors de l'évaluation de la capture du réseau.
Les données chiffrées BLE standard utilisent un protocole d'échange de clés en sélectionnant une clé temporaire (TK) basée sur AES. Mike Ryan a publié l'outil crackle pour forcer brutalement cette clé.
crackle -i ble.pcap -o decrypted-ble.pcap
Cette technique n'est pas efficace contre le mode OOB (clé facultative de 128 bits également définie par BLE), cependant, comme on le voit sur la liste de diffusion ubertooth , l'équipe de développement travaille à rassembler des échantillons et à dépanner les possibilités de rupture du mode OOB.
Un bien connu blog sur les technologies de paiement et l'infrastructure associée ont également spéculé sur la disparition de la sécurité Bluetooth, y compris quelques commentaires sur la rupture du mode BLE OOB. Mise à jour du 29/12/15: il y a plus de discussion sur BT 2.1. Nous sommes également tombés sur btproxy, qui, espérons-le, prendra bientôt en charge BTLE. Un autre tutoriel que j'ai rencontré est intitulé Renifler et craquer Bluetooth avec UbertoothOne .
Cependant, (comme on le voit dans le livre "Hacking Exposed Wireless, 3rd Edition"), l'idée de réparer Bluetooth a été publiée pour la première fois dans le document "Cracking the Bluetooth PIN" de Yaniv Shaked et Avishai Wool ( http: // www.eng.tau.ac.il/~yash/shaked-wool-mobisys05 ). Un adversaire peut utiliser une "attaque réparatrice" pour manipuler l'état d'appariement stocké entre deux appareils en usurpant l'identité du BD_ADDR de l'un des deux appareils.
L'outil bdaddr est la principale implémentation de cette technique.
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
Pour revenir à une table rase
Sudo bccmd -d hci0 coldreset
hciconfig hci0