Bluetooth Low Energy : quand le pairing legacy et les caractéristiques bavardes trahissent vos devices

Deux nouveaux trainings DVID pour explorer les angles morts de la sécurité Bluetooth Low Energy

Le Bluetooth Low Energy est partout. Bracelets connectés, capteurs médicaux, serrures intelligentes, équipements industriels portables, jouets connectés. Sa simplicité d’implémentation et sa faible consommation en font un protocole de référence sur les devices IoT. Mais cette même simplicité a un revers : la sécurité du BLE dépend presque entièrement des choix faits côté développeur, et ces choix sont rarement les bons.

Deux nouveaux trainings DVID explorent ces angles morts à partir de scénarios concrets. Le premier s’attaque au pairing BLE en mode legacy, hérité du Bluetooth 4.0, encore utilisé sur des produits commercialisés aujourd’hui. Le second adresse une faille plus discrète mais redoutable : la fuite d’informations sensibles via une caractéristique GATT mal conçue.

BLE legacy pairing / Bluetooth 4 : un mécanisme cassé qu’on continue d’utiliser

Le Bluetooth 4.0 a introduit le BLE en 2010, avec un modèle de pairing aujourd’hui considéré comme cryptographiquement faible. La version 4.2 a apporté le LE Secure Connections basé sur ECDH, qui résout l’essentiel des problèmes. Plus de quinze ans après, beaucoup de devices déployés — y compris en environnement médical ou industriel — continuent pourtant d’utiliser le legacy pairing.

Le scénario de ce training place le participant en position d’attaquant à portée radio du device. L’objectif : capturer le pairing, en dériver les clés de session, et déchiffrer l’intégralité du trafic BLE qui suit. Les participants découvrent comment :

sniffer le trafic BLE avec une sonde adaptée et identifier les paquets de pairing ;
reconnaître les modes de pairing utilisés (Just Works, Passkey Entry, Out of Band) ;
exploiter les faiblesses cryptographiques du legacy pairing pour reconstruire la TK puis la STK ;
déchiffrer les échanges qui suivent et reconstruire le contenu applicatif (données capteur, commandes, identifiants) ;
distinguer ce qui est exploitable en passif (écoute seule) et ce qui demande une attaque active (MitM).

Ce qui rend ce module particulièrement instructif, c’est qu’il met en évidence une réalité industrielle : la version du Bluetooth annoncée sur la fiche produit ne dit rien des modes de pairing réellement supportés. Un device peut afficher « Bluetooth 5.2 » et continuer à accepter des connexions en legacy par souci de compatibilité descendante. Le training apprend à détecter ces configurations en pratique.

Cette problématique relève de l’Annexe I du Cyber Resilience Act — exigences 2c (intégrité), 2g (protection contre les communications non autorisées) et 2h (confidentialité des données). Elle est également au cœur des recommandations de l’ETSI EN 303 645 sur la sécurité des objets connectés grand public.

Fuite d’informations sur une caractéristique BLE : le GATT trop bavard

Le second training change d’échelle. Plus besoin de casser de la cryptographie : ici, les informations sensibles sont accessibles parce qu’elles sont délibérément exposées par le device, dans une caractéristique GATT lisible sans authentification.

Le GATT (Generic Attribute Profile) est la couche logique qui structure les services et caractéristiques d’un device BLE. Chaque caractéristique a des permissions de lecture, d’écriture, de notification. Et c’est précisément sur ces permissions que se concentrent les erreurs de conception. Les participants explorent :

comment énumérer l’ensemble des services et caractéristiques d’un device BLE depuis un smartphone ou un PC ;
comment identifier les caractéristiques qui exposent plus que ce qu’elles devraient — numéros de série, identifiants utilisateur, configuration interne, données de capteur historiques ;
comment relier ces fuites à des informations exploitables : géolocalisation indirecte, profilage utilisateur, identifiants permettant des attaques ciblées ;
comment auditer un firmware BLE pour repérer ces caractéristiques mal classées avant la mise sur le marché ;
comment appliquer le principe du moindre privilège à un GATT (chiffrement requis, authentification, autorisation par caractéristique).

Ce module met en évidence une mécanique souvent sous-estimée : les développeurs BLE pensent en termes de fonctionnalités exposées, pas en termes de surface d’information. Une caractéristique qui retourne un identifiant interne « pour le debug » devient, une fois en production, un canal d’exfiltration accessible à toute personne dans un rayon de quelques mètres.

Cette faille recouvre les exigences 2h (confidentialité), 2k (minimisation de la surface d’attaque) et 2d (contrôle d’accès) de l’Annexe I du CRA.

Une approche 100 % pratique, fidèle à l’ADN DVID

Ces deux trainings prolongent notre méthode pédagogique : du vrai matériel, du vrai protocole, et des scénarios reproductibles en environnement professionnel. Apprendre en manipulant, pas en théorisant — c’est particulièrement vrai sur le BLE, où la documentation officielle est dense et les outils nombreux.

Les participants travaillent avec :

un device cible basé sur ESP32 ou nRF52, exécutant un firmware BLE volontairement vulnérable ;
une sonde de capture BLE (sniffer dédié type nRF52840 dongle) ;
des outils standards de l’écosystème BLE
Wireshark ;

Chaque scénario est progressif. Le module sur le legacy pairing introduit les concepts cryptographiques nécessaires au fil des étapes. Le module GATT permet de bâtir une checklist d’audit immédiatement applicable.

Ce que les participants retiennent

Au-delà de chaque scénario, ces deux modules transmettent les réflexes essentiels à toute équipe qui développe ou audite du BLE :

imposer LE Secure Connections (Bluetooth 4.2+) et désactiver explicitement le legacy pairing ;
choisir un mode de pairing adapté à l’interface du device — éviter Just Works dès qu’un canal de saisie est disponible ;
traiter chaque caractéristique GATT comme une décision de sécurité : qui peut la lire, qui peut l’écrire, et avec quel niveau d’authentification ;
ne jamais exposer d’identifiants stables (numéros de série, MAC, identifiants utilisateur) en lecture libre ;
intégrer un audit BLE systématique dans le cycle de développement, au même titre qu’une revue de code ;
considérer l’environnement radio comme toujours hostile — un sniffer coûte aujourd’hui moins de 50 euros.

Pour qui ?

Ces deux modules s’adressent aux équipes confrontées au BLE dans leurs produits ou leurs audits :

ingénieurs firmware travaillant sur des stacks BLE (Zephyr, ESP-IDF, Nordic SDK) ;
développeurs d’applications mobiles interfacées avec des devices BLE ;
pentesters spécialisés sur le sans-fil ;
architectes produit IoT, particulièrement sur les segments santé, industrie et grand public ;
responsables sécurité produit en préparation de la conformité CRA et ETSI EN 303 645.

Une connaissance préalable du BLE est utile mais pas indispensable : les concepts (advertising, GATT, pairing, bonding) sont introduits au fur et à mesure du parcours.

Disponibles dès maintenant

Ces deux trainings s’intègrent naturellement dans un parcours de montée en compétence IoT/OT, que ce soit pour renforcer une équipe interne, préparer la conformité CRA ou structurer une démarche de sécurité by design.

En savoir plus : https://dvid.eu/fr
Nous contacter : https://dvid.eu/fr#contact
Suivre notre actualité : https://www.linkedin.com/company/dvid/