Sécurité des protocoles Bluetooth

La sécurité des protocoles Bluetooth dépend des normes décidées par le TRUC. Son implémentation au niveau matériel et logiciel a laissé des failles. De nombreuses attaques ont ainsi pu avoir lieu grâce à des outils spécifiques comme BT-crack ou Backtrack. Au fur et à mesure de l'évolution de Bluetooth, des contre-mesures ont été mises en place au niveau utilisateur comme au niveau matériel et logiciel.

Fondamentaux

Normes

Il existe plusieurs implémentations du bluetooth :

• Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) : établit une connexion sans fil continue relativement courte;
• Bluetooth à faible énergie (LE) : offre de courtes rafales de connexion radio longue distance, ce qui le rend idéal pour les applications Internet de type (IoT) qui ne nécessitent pas de connexion continue, mais dépendent d'une longue durée de vie de la batterie.

L’implémentation d’un système bluetooth est spécifié à partir de normes constituant l’architecture de base du protocole bluetooth. Le coeur d’un système bluetooth est divisé en deux parties, la couche controller implémentant la partie matérielle et une couche hôte implémentant la partie logicielle.

Description de l'architecture d'un système bluetooth

Implémentation matérielle

Implémenté physiquement via un module RF radio qui permet d’envoyer et recevoir les signaux radio entre deux appareil. La couche liaison est définie dans les systèmes Bluetooth comme la couche assurant le transport des paquets entre les appareils d’un même piconet à travers plusieurs canaux.

• Basic channel : Canal pour la communication entre deux appareils.
• Adapted channel : Canal pour la communication dans le piconet.
• Inquiry scan : Canal pour l'acquisition des appareils bluetooth aux alentour.
• page scan : Canal pour la connexion avec un nouvel appareil.

Canal de communication du protocole bluetooth

Les paquets possèdent un champ header pour distinguer le piconet de l’appareil des autres piconets. De plus les paquets doivent avoir un champ LT_ADDR dans leur header qui spécifie quel transport logique ce paquet utilisent. Plusieurs type de transports logiques sont définies via plusieurs protocols :

• ACL (Asynchronous Connection Less)
• SCO (Synchronous Connection Oriented)
• ASB (Active Slave Broadcast)
• PSB (Parked Slave Broadcast)
• LC (Link Control protocol)
• LMP (Link Manager Protocol)
• LELL (Low-energy Link Layer)

Une interface host-controller, (HCI), cette interface fait la liaison entre la couche host et la couche controller en assurant le transfert des événements et des paquets de données. Cette interface assure le transfert d’information pour que la couche host puisse découvrir, ajouter et gérer les appareils dans un piconet. Sur certains appareils bluetooth la couche host et contrôler sont implémenté sur le même microprocesseur, l’interface HCI existe mais devient obsolète.

Hardware implementation of Bluetoth security

Implémentation logicielle

Les paquets reçus par le HCI sont traités par le protocole L2CAP (Logical Link Control and Adaptation Protocol), dans le cas d’un appareil sans HCI les paquets sont directement envoyés par les liens ACL ,PSB et ASB.
Ce protocole assure le transports des paquets vers les couches supérieures, la segmentation et le ré-assemblage des paquets.
Attribute protocol (ATT) définies l’aspect clients/serveur du piconet pour assurer l'échange des données une fois la connexion établie.

Implémentation de la sécurité

Implémentation logicielle et physique

Modes de sécurité

Les appareils bluetooth, sont implémenté selon le GAP (generic access profile) correspondant à un ensemble d’exigences obligatoire que doivent respecter les appareil bluetooth afin de communiquer entre eux. Plusieurs niveaux de sécurités sont définies dans le GAP :

• Mode 1
  • Ce mode est non sécurisé pour toutes opération
  • Aucune procédure d’initialisation sécurisé
  • Les appareils qui utilisent ce mode peuvent communiquer qu’avec les appareils qui sont en mode 1.
• Mode 2
  • Fournit un niveau de sécurité au niveau application après que la liaison avec un autre appareil a été établie.
  • Il n’y a aucune procédure sécurisé avant l’établissement d’un canal de communication.
  • Niveau de sécurité implémenté au niveau du protocole minimal d’échange de donnée L2CAP.
• Mode 3
  • Fournit un niveau de sécurité avant la l’établissement du canal de communication.
  • Chiffrement sécurisé au niveau de la liaison avec un autre équipement bluetooth : LMP protocol.

Gestions des clés

La gestion et l'utilisation des clés permet aux protocoles bluetooth d'établir et maintenir une connexion entre plusieurs appareils d'un même piconet.
Les clés de communication peuvent être des combinaison de plusieurs type de clés, les Unit keys , les clés de combinaisons, les clés maîtres et les clés d’initialisations.
Plusieurs entités permettent d’assurer une communication sécurisé entre plusieur équipement bluetooth : Une adresse publique unique 48 bit (BD-ADDR - Bluetooth Device address) utilisé pour identifier quel appareil est en train d'envoyer les données, aucun autre appareil doit avoir cette adresse. Cette adresse est définie par l’IEEE (Institute of electrical and electronics engineers).
Une clé secrète d'authentification de 128 bit, c’est l’appareil qui génère aléatoirement cette clé.

Gestion des clés dans les protocoles blutooth

Une seconde clé secrète pour le chiffrement des données, la longueur de cette clé dépend du niveau de sécurité de la transaction, cette longueur varie entre 8 et 128 bit. Un nombre aléatoire généré aléatoirement à chaque transaction de donnée, l’appareil génère automatiquement ce nombre pour l'utiliser dans les différentes processus de chiffrement et d'authentifications.

• Clé de liaison

Cette clé est un nombre de 128 bit généré aléatoirement, elle est échangé entre plusieurs appareil bluetooth pour effectuer toutes les transactions sécurisées. La clé est utilisé pour la routine d’authentification et c’est l’un des paramètres pour créer la clé de chiffrement.
C’est une clé semi-permanente c’est à dire qu’elle est stocké dans la mémoire vive de l’appareil et peut dont être réutilisé lorsque la session est terminé. La clé de liaison peut donc être utilisé dans le processus d'authentification entre plusieurs appareil bluetooth. Le temps de vie de cette clé dépend uniquement du temps de vie d’une session.

• Clé d'initialisation

La clé d’initialisation est utilisé pendant l’initialisation d’une communication entre 2 appareil bluetooth quand aucune key link ou autre combinaison de clé n’existe. Durant l’étape d’initialisation le code PIN des deux appareil doit être saisi. La clé est le résultat de l'algorithm E22 avec le code PIN de l'appareil, l’adresse de l’autre appareil Bluetooth et un nombre 128 bit généré aléatoirement en entrée.

Clé d'initialisation

• Unit Key

La clé Unit est généré grâce a l’algorithme E21 quand l’appareil opère pour la première fois avec un autre appareil. Après la création la clé est stocké en mémoire non volatile est est rarement changé. Un appareil peut utiliser la unit key d’un autre appareil comme un link key entre les deux appareils. Durant la phase d’initialisation l’application décide quel appareil fournit sa unit key en tant que link key. Si la mémoire d’un des appareil est pleine il ne pourra pas se souvenir d’une clé supplémentaire sa link key sera donc utilisé.

• Combinaison Key

La Combinaison key est construite à partir d’informations de deux appareils. Elle est créée durant la phase d’initialisation, les deux appareils génère leur clé en même temps. Les deux appareils utilise l’algorithme E21 avec un nombre généré aléatoirement et leur BD_ADDR en entré. Ensuite ils échangent leurs nombre aléatoire de manière sécurisé afin de calculer leur combinaison key.

• Master Key

La master key est une clé temporaire remplaçant l’actuelle clé de liaison. Elle est utilisé quand le master unit veut transmettre des informations à plus d’un destinataire. L’appareil maître génère une clé maître avec l’algorithme E22 et 2 nombre aléatoire 128 bit.

construction de la clé maître dans le protocole bluetooth

Catégories de menaces

Voir tableau

Surveillance

• Blueprinting : an attack to remotely find out about characteristics of a device ;
• Btaudit : provides applications to scan the L2CAP and RFCOMM, which are the main Bluetooth protocols ;
• Redfang : small proof-of-concept application to find non discoverable Bluetooth devices [1];
• War-nibbling;
• Bluefish;
• Sdpool;
• Bluescanner;
• BTScanner.

Range extension

• BlueSniping;
• Bluetooone;
• Vera-NG.

Obfuscation

• Bdaddr;
• Hciconfig;
• Spooftooph.

Fuzzer

• BluePass;
• Bluetooth Stack Smasher;
• BlueSmack;
• Tanya;
• BlueStab.

Sniffing

• FTS4BT;
• Merlin;
• BlueSniff;
• HCIDump;
• Wireshark;
• Kismet.

DoS

• Battery exhaustion;
• Signal jamming;
• BlueSYN;
• Blueper;
• BlueJacking;
• vCardBlaster.

Malware

• BlueBag;
• Caribe;
• CommWarrior.

Illustrations

Exemples et historique des attaques (Section IV) Recherche sur les menaces de sécurité Bluetooth

Man-in-the-Middle Attack

Man-In-The-Middle attacks on bluetooth: a comparative analysis, a novel attack, and countermeasures

Outils

tools

Contre-mesures

Section IV - Countermeasures and SSP Improvements Contre-mesure attaque par le milieu

Comparaison avec d'autres protocoles sans fil

Comparaison Wifi/Bluetooth

Bibliographie

1. Faiblesse
   • (en) « An analysis of Bluetooth security vulnerabilities », Wireless Communications and Networking, 2003. WCNC 2003. 2003 IEEE,‎ 16-20 march 2003, p. 1825-1831 vol.3 (ISBN 0-7803-7700-1, ISSN 1525-3511, DOI 10.1109/WCNC.2003.1200664)
     2003 IEEE Wireless Communications and Networking, 2003. WCNC 2003
   • (en) M. Tan et K. A. Masagca, « An Investigation of Bluetooth Security Threats », IEEE Xplore,‎ avril 2011, p. 1-7 (DOI 10.1109/ICISA.2011.5772388)
     2011 International Conference on Information Science and Applications
   • (en) R. Bouhenguel, I. Mahgoub et M. Ilyas, « Bluetooth Security in Wearable Computing Applications », IEEE Xplore,‎ novembre 2008, p. 182-186 (DOI 10.1109/HONET.2008.4810232)
     2008 International Symposium on High Capacity Optical Networks and Enabling Technologies
   • (en) Markus Jakobsson, Susanne Wetzel et David Naccache, « Security Weaknesses in Bluetooth », Lecture Notes in Computer Science, vol. 2020,‎ avril 2001, p. 176-191 (ISBN 978-3-540-41898-6, ISSN 0302-9743, DOI 10.1007/3-540-45353-9_14)
     Topics in Cryptology — CT-RSA 2001
   • (en) N. Baker, « ZigBee and Bluetooth strengths and weaknesses for industrial applications », Computing Control Engineering Journal, vol. 16, n^o 2,‎ avril 2005, p. 20-25 (ISSN 0956-3385, DOI 10.1049/cce:20050204)
     Topics in Cryptology — CT-RSA 2001
2. Attack
   • (en) Yaniv Shaked et Avishai Wool, « Cracking the Bluetooth PIN », MobiSys '05,‎ 6-8 juin 2005, p. 39-50 (ISBN 978-1-931971-31-7, DOI 10.1145/1067170.1067176)
   • (en) Keijo Haataja et Pekka Toivanen, « Two practical man-in-the-middle attacks on Bluetooth secure simple pairing and countermeasures », IEEE Transactions on Wireless Communications, vol. 9,‎ janvier 2010, p. 384-392 (ISSN 1536-1276, DOI 10.1109/TWC.2010.01.090935)
     We propose two new Man-In-The-Middle (MITM) attacks on Bluetooth Secure Simple Pairing (SSP
   • (en) Yi Lu, Willi Meier et Serge Vaudenay, « The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption », Lecture Notes in Computer Science,‎ aout 2005, p. 97-117 (ISBN 978-3-540-28114-6, DOI 10.1007/11535218_7)

1. • (en) Albert Levi, Erhan Çetintaş, Murat Aydos, Çetin Kaya Koç et M. Ufuk Çağlayan, « Relay Attacks on Bluetooth Authentication and Solutions », Lecture Notes in Computer Science,‎ septembre 2004, p. 278-288 (ISBN 978-3-540-23526-2, DOI 10.1007/978-3-540-30182-0_29)

1. Sécurité
   • (en) P. Kitsos, N. Sklavos, K. Papadomanolakis et O. Koufopavlou, « Hardware implementation of Bluetooth security », IEEE Pervasive Computing,‎ janvier 2003, p. 1096-1102 (ISSN 1536-1268, DOI 10.1109/MPRV.2003.1186722)
     Bluetooth can implement its security layer's key-generation mechanism and authentication in software or hardware.
   • (en) Gyongsu Lee et Sin-Chong Park, « Bluetooth security implementation based on software oriented hardware-software partition », IEEE Pervasive Computing, vol. 3,‎ mai 2005, p. 2070-2074 (DOI 10.1109/ICC.2005.1494702)
     IEEE International Conference on Communications, 2005. ICC 2005. 2005
   • (en) J. Alfaiate et J. Fonseca, « Bluetooth security analysis for mobile phones », IEEE Pervasive Computing,‎ juin 2012, p. 1-6
     7th Iberian Conference on Information Systems and Technologies (CISTI 2012)
   • (en) S. Sandhya et K. A. S. Devi, « Analysis of Bluetooth threats and v4.0 security features », IEEE Xplore,‎ février 2012, p. 1-4 (ISBN 978-1-4673-0273-9)
     2012 International Conference on Computing, Communication and Applications
   • (en) J. S. Lee et C. C. Shen, « A Comparative Study of Wireless Protocols: Bluetooth, UWB, ZigBee, and Wi-Fi », IEEE Xplore,‎ novembre 2007, p. 46-51 (DOI 10.1109/IECON.2007.4460126)
     33rd Annual Conference of the IEEE Industrial Electronics Society, 2007. IECON 2007