Attaques Radio IoT : BLE, Zigbee, LoRa et SDR 2026

La sécurité des communications radio IoT est fondamentalement différente de la sécurité réseau filaire. Un attaquant n'a pas besoin d'un accès physique au réseau : il lui suffit d'être à portée radio du dispositif cible, ce qui peut représenter plusieurs dizaines de mètres pour le BLE, une centaine de mètres pour le Zigbee et plusieurs kilomètres pour le LoRa. Les équipements nécessaires au pentest radio IoT sont devenus remarquablement accessibles depuis l'avènement du SDR grand public. Un HackRF One à 300 euros remplace des équipements de laboratoire qui coûtaient plusieurs dizaines de milliers d'euros il y a dix ans. Cette démocratisation des outils d'analyse radio signifie que les attaquants disposent désormais des mêmes capacités que les laboratoires de recherche spécialisés, ce qui impose aux fabricants de prendre la sécurité radio au sérieux plutôt que de compter sur l'obscurité des protocoles propriétaires. Les techniques présentées ici sont complémentaires de la méthodologie de pentest IoT OWASP et s'intègrent dans la phase d'audit des protocoles de communication. L'article sur les attaques wireless Wi-Fi et BLE couvre les aspects Wi-Fi non traités ici pour se concentrer sur les protocoles spécifiquement IoT.

Attaques sur le Bluetooth Low Energy

Le Bluetooth Low Energy (BLE) est le protocole radio le plus répandu dans l'IoT grand public : serrures connectées, bracelets de fitness, dispositifs médicaux et balises de localisation. Le mode d'appairage Just Works, utilisé par la majorité des dispositifs BLE pour sa simplicité, n'offre aucune protection contre les attaques Man-in-the-Middle. L'outil GATTacker implémente un proxy BLE transparent qui se positionne entre le dispositif et l'application mobile pour intercepter et modifier les commandes GATT en temps réel.

Le sniffing BLE avec un Ubertooth One capture les paquets advertising qui révèlent l'identité, les services exposés et parfois des données transmises en clair. L'outil GATTacker clone le profil GATT d'un dispositif légitime pour créer un jumeau malveillant auquel l'application mobile se connecte automatiquement lorsque le signal est plus fort. Cette technique, testée sur des serrures connectées commerciales, permet de capturer le code de déverrouillage et de le rejouer ultérieurement.

Interception et injection sur les réseaux Zigbee

Le protocole Zigbee utilise un chiffrement AES-128 au niveau réseau, mais la distribution de la clé réseau lors du join constitue sa vulnérabilité principale. Lorsqu'un nouveau dispositif rejoint le réseau, le coordinateur lui transmet la clé réseau chiffrée avec une clé de transport bien connue définie dans la spécification. Un attaquant qui capture cette phase avec un sniffer CC2531 peut déchiffrer la clé réseau et décrypter l'intégralité du trafic. La protection des données transmises via Zigbee rejoint la problématique de sécurité des protocoles IoT au niveau applicatif.

Le framework KillerBee fournit les outils offensifs : zbstumbler pour la découverte, zbdump pour la capture, zbreplay pour le rejeu et zbassocflood pour le déni de service. L'injection de trames avec un dongle ApiMote permet d'envoyer des commandes de contrôle aux actionneurs du réseau une fois la clé obtenue. La combinaison capture de clé et injection permet la prise de contrôle complète d'un réseau domotique ou industriel Zigbee déployé sans surveillance.

Vulnérabilités des réseaux LoRaWAN

Le protocole LoRaWAN couvre les déploiements longue portée avec des communications sur plusieurs kilomètres. LoRaWAN implémente un chiffrement AES-128 à deux niveaux : la clé NwkSKey protège l'intégrité des métadonnées, et l'AppSKey chiffre la charge utile. Le mode OTAA génère ces clés dynamiquement lors du join, offrant une meilleure sécurité que le mode ABP où les clés sont provisionnées statiquement.

Les vulnérabilités se concentrent sur le mode ABP encore largement déployé. Les compteurs de trames protègent théoriquement contre le rejeu, mais de nombreux dispositifs ABP réinitialisent ces compteurs après redémarrage, permettant le rejeu de trames capturées. L'interception avec un récepteur SDR et le décodeur gr-lora capture les trames même à plusieurs kilomètres. La migration vers OTAA avec rotation régulière des clés est la recommandation principale.

SDR et analyse de protocoles propriétaires

Le Software Defined Radio permet l'analyse de tout protocole radio dans sa bande de fréquences. Un HackRF One couvre 1 MHz à 6 GHz en réception et émission, englobant tous les protocoles IoT courants. L'analyse d'un protocole propriétaire commence par l'identification de la fréquence porteuse avec un scan spectral, suivie de la capture du signal brut, la démodulation avec GNU Radio et le décodage avec Universal Radio Hacker.

Les protocoles Sub-GHz propriétaires (télécommandes de garage, capteurs météo, systèmes d'alarme) utilisent fréquemment des codes fixes sans rolling code, rendant le rejeu trivial après capture. Le Yard Stick One et le Flipper Zero automatisent ce processus. Les contre-mesures incluent l'adoption de rolling codes et la détection spectrale continue. L'article sur le hardware hacking JTAG et UART complète l'approche radio avec les techniques d'accès physique aux interfaces de débogage pour extraire les clés de chiffrement et les paramètres radio.

Conclusion

Les protocoles radio IoT présentent des vulnérabilités structurelles exploitables avec du matériel SDR accessible. Le BLE en mode Just Works, le Zigbee avec sa distribution de clé en clair et le LoRaWAN en mode ABP offrent des vecteurs d'attaque documentés. L'intégration du pentest radio dans les audits de sécurité IoT est indispensable pour évaluer le risque réel posé par ces protocoles sans fil déployés massivement.