Sécurité des protocoles Bluetooth

Le but du Bluetooth est d'établir une connexion ad hoc ou peer-to-peer entre plusieurs appareils afin d'échanger des données dans un picoréseau, dans la bande de fréquence des 2,4 GHz[1].

Il existe plusieurs versions du Bluetooth :

• Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) : Établit une connexion sans fil continue sur des distances relativement courtes (10 m) ;
• Bluetooth à faible énergie (LE) Permet de courtes rafales de connexions radio, ce qui le rend idéal pour les applications Internet de type (IoT) qui ne nécessitent pas de connexion continue, mais demandent une longue durée de vie de la batterie ;

La mise en œuvre d’un système Bluetooth est spécifiée à partir des normes constituant l’architecture de base du protocole Bluetooth. Le cœur d’un système Bluetooth est divisé en deux parties : la couche contrôleur 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

La couche contrôleur est implémentée physiquement via un module RF radio qui permet d’envoyer et recevoir les signaux radio entre deux appareils. 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 picoréseau à travers plusieurs canaux :

• Basic channel : Canal pour la communication entre deux appareils ;
• Adapted channel : Canal pour la communication dans le picoréseau ;
• Inquiry scan : Canal pour l'acquisition des appareils bluetooth aux alentours ;
• Page scan Canal pour la connexion avec un nouvel appareil ;

Les paquets possèdent un champ header pour distinguer le picoréseau de l’appareil des autres picoréseaux. De plus, les paquets doivent avoir un champ LT_ADDR dans leur header qui spécifie quel transport logique ce paquet utilise. Plusieurs types de transports logiques sont définis via plusieurs protocoles[2]:

• 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) ;

La liste complète des protocoles Bluetooth est décrite dans cet article List_of_Bluetooth_protocols (en).

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

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éfinit l’aspect clients/serveur du picoréseau pour assurer l'échange des données une fois la connexion établie[3].

Treize profils sont définis dans la version 1.1 des spécifications Bluetooth. Ces profils correspondent au comportement général des appareils afin de communiquer entre eux. Ils décrivent une base pour les différents types d'usages et définissent les protocoles à utiliser pour les futurs usages.

Depuis la version 2.0 du Bluetooth de nombreux profils ont été ajoutés, la liste complète des profils est décrite dans l'article ci-contre : List_of_Bluetooth_profiles (en).

Tous les paquets possèdent un header de 8 bit, suivi par une adresse de 32 bits qui correspond a un identifiant unique pour une connexion donnée, enfin une suite variable de bits avec un PDU (Protocol Data Unit) de 2 a 39 octets[4] (en BLE 4.0 et 4.1) contenant la charge utile du message suivi d'un CRC (Cyclic redundancy check) de 24 bits[5].

Les appareils Bluetooth sont implémentés selon le GAP (Generic Access Profile) correspondant à un ensemble d’exigences obligatoires que doivent respecter les appareils Bluetooth pour qu'ils puissent communiquer entre eux. Plusieurs niveaux de sécurité sont définis dans le GAP[6] :

• Mode 1 :
  • Ce mode est non sécurisé pour toute opération
  • Aucune procédure d’initialisation sécurisée
  • Les appareils qui utilisent ce mode ne peuvent communiquer qu’avec les appareils de ce même mode.

• Mode 2
  • Fournit un niveau de sécurité au niveau application après établissement d'une liaison avec un autre appareil.
  • Il n’y a aucune procédure sécurisée 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 l’établissement du canal de communication.
  • Chiffrement sécurisé au niveau de la liaison avec un autre équipement Bluetooth : LMP protocol.

Si un service ou un service connexe effectue une demande avec un mode de sécurité différent, le mode de sécurité le plus élevé est forcé afin de traiter la demande[7].

Gestion des clés dans les protocoles bluetooth

La gestion et l'utilisation des clés permet aux protocoles Bluetooth d'établir et de maintenir une connexion entre plusieurs appareils d'un même picoréseau.

Les clés de communication peuvent être des combinaisons de plusieurs types de clés, les Unit keys, les clés de combinaisons, les clés maîtres et les clés d’initialisation.

Plusieurs entités permettent d’assurer une communication sécurisée entre plusieurs équipements Bluetooth : une adresse publique unique de 48 bit (BD-ADDR - Bluetooth Device address) utilisée pour identifier quel appareil est en train d'envoyer les données, aucun autre appareil ne doit avoir cette adresse[8] - [9]. Cette adresse est définie par l’IEEE (Institute of Electrical and Electronics Engineers).

Une clé secrète d'authentification de 128 bit, l’appareil qui génère aléatoirement cette clé.

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[10]. Un nombre aléatoire est généré à chaque transaction de données, l’appareil génère automatiquement ce nombre pour l'utiliser dans les différentes processus de chiffrement et d'authentification.

Clé de liaison

La clé de liaison est un nombre de 128 bit généré aléatoirement, elle est échangée entre plusieurs appareils Bluetooth pour effectuer toutes les transactions sécurisées. La clé est utilisée pour la routine d’authentification et c’est l’un des paramètres pour créer la clé de chiffrement[8].

C’est une clé semi-permanente, elle est stockée dans la mémoire vive de l’appareil et peut dont être réutilisée lorsque la session est terminée. La clé de liaison peut s'utiliser dans le processus d'authentification entre plusieurs appareils Bluetooth. La durée de vie de cette clé dépend uniquement de la durée de vie d’une session.

Clé d’initialisation

La clé d’initialisation est utilisée pendant l’initialisation d’une communication entre deux appareils Bluetooth quand aucune clé de liaison ou autre combinaison de clé n'existe[10]. Durant l’étape d’initialisation le code PIN des deux appareils doit être saisi. La clé est le résultat de l'algorithme 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[8].

Clé Initialisation

Clé Unit

La clé Unit est générée grâce à 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ée dans une mémoire non volatile, elle est rarement changée. Un appareil peut utiliser la Unit Key d’un autre appareil comme une clé de liaison entre les deux appareils. Durant la phase d’initialisation, l’application décide quel appareil fournit sa Unit Key en tant que clé de liaison[10]. Si la mémoire d’un des appareils est pleine, il ne pourra pas se souvenir d’une clé supplémentaire sa clé de liaison sera donc utilisée[8].

Clé de combinaison

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

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

Clé Maître

La clé maître est une clé temporaire remplaçant l’actuelle clé de liaison[10]. Elle est utilisée quand l'appareil maître 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 nombres aléatoires de 128 bit.

L’appairage (ou pairing en anglais) permet l’association entre deux terminaux Bluetooth. Les clefs de liaison, permettant de sécuriser les canaux de communication entre les deux terminaux, sont créés lors de cette phase.

Deux méthodes sont proposées : le « Legacy pairing » et le « Secure simple pairing ».

Le Legacy pairing est utilisé uniquement si un des terminaux n’est pas compatible avec une version supérieure à 2.0. Il se base sur un code PIN à 4 chiffres. La clef de liaison est générée à partir du code PIN. Ce mode n’offre pas de protection contre les attaques de l’intercepteur.

Le Secure simple pairing est utilisé par les terminaux supportant une norme supérieure à 2.0. Il se base sur un secret partagé par l’algorithme Diffie-Hellman. La clef de liaison est générée à partir de ce secret partagé. Ce mode offre une protection contre les attaques de l’intercepteur et contre les écoutes passives.

Les différentes phases du Secure simple pairing, définies par la norme 5.0, sont :

1. Échange des paramétrages d’entrée/sortie
2. Échange d’un secret via l’algorithme Diffie-Hellman
3. Première phase d’authentification via la vérification du code PIN généré par les terminaux. Quatre modèles d’association peuvent être utilisés
   • Comparaison numérique : peut être utilisée si les deux terminaux peuvent afficher un code PIN. Ce dernier est généré et est affiché par les deux terminaux. L’association continue après confirmation manuelle que les codes PIN sont identiques sur les deux terminaux
   • « Just work » : peut être utilisé si un des deux terminaux ne peut pas afficher de code PIN. Celui-ci est généré et l’association continue après confirmation manuelle sans vérifier que les codes PIN sont identiques. Cette méthode ne permet pas de protéger la communication d’attaque de l’intercepteur
   • Passphrase : peut être utilisé si un des deux terminaux peut afficher des chiffres et si l'autre permet d'entrer des chiffres mais n’offre pas d’affichage. L’association continue si le code PIN entré dans le deuxième terminal est identique à celui du premier terminal
   • Out-of-Band : la découverte de terminaux et l'échange des données cryptographiques pour la création des clefs sont faits hors ligne, par exemple via NFC
4. Création des clefs de liaison à partir du secret partagé lors de l’étape 2.
5. Deuxième phase d’authentification via la vérification que les 2 terminaux partagent la même clef de liaison, décrite ci-dessous
6. Création de la clef de chiffrement si l’option est activée

L'authentification bluetooth utilise une technique de question/réponse, un appareil vérifie si l'autre appareil connait la clé de liaison. Le programme procède ensuite à l'authentification avec la clé de liaison actuelle, le processus nécessite que les deux parties partagent la même clé de liaison[11].

Authentification Bluetooth

Pour l'étape d'authentification, le maître envoie un numéro aléatoire au demandeur. Ensuite, les deux parties utilisent la fonction d'authentification avec le numéro généré aléatoirement et la clé de liaison pour produire une réponse signée, enfin le maître vérifie que les deux réponses sont valides[10] - [6] - [12].

Si l'authentification échoue, une nouvelle tentative est initialisée après une courte période, cette période est doublée pour chaque tentatives supplémentaires sur la même adresse.

Les données utilisateurs sont protégées par un chiffrement du paquet du payload. Le code d’accès et l'entête ne sont jamais chiffrés[13]. Le chiffrement du payload est effectué par un algorithme de chiffrement E0 qui se resynchronise à chaque nouveau payload[14].

L'algorithme de chiffrement E0 est réalisé en trois blocs :

• Initialisation de la clé du payload
• Génération des keys stream
• Réalisation du chiffrement et déchiffrement

Chiffrement des données depuis un système bluetooth

Le bloc d'initialisation combine les bits entrants dans un ordre approprié et les décale dans les 4 LFSRs du bloc de génération des key stream[13]. Plusieurs modes de chiffrements sont possibles si l'appareil utilise une clé semi-permanente ou la clé maître, dans le cas où l’appareil utilise une clé semi-permanente, la diffusion en broadcast n'est pas chiffrée car la clé est utilisée pour plus d'une session donc potentiellement moins sécurisée. Individuellement, le trafic peut être chiffré ou non. Dans le cas où la clé maître est utilisée, soit rien n'est chiffré, soit la diffusion en broadcast n'est pas chiffrée mais individuellement le trafic est chiffré avec la clé maître, soit tout le trafic est chiffré avec la clé maître.

Les failles suivantes ont été répertoriées depuis l'implémentation de la version 1.0 à 2.0 de Bluetooth

Ce tableau contient les vulnérabilités existantes dans les versions antérieures à 4.0 de Bluetooth

Ce tableau contient plusieurs vulnérabilités existantes depuis la création de Bluetooth et sa version 1.0 jusqu'à la version actuelle, qui restent non corrigées.

Bluejacking

Le Bluejacking (de l'anglais « Blue » de Bluetooth et « to jack », prendre en otage), est une attaque consistant à envoyer un message visible non désiré à un appareil mobile via la fonctionnalité vCard. Ce type d'attaque est inoffensif pour l'appareil cible car l'attaquant n'obtient a aucun moment le contrôle de celui-ci, toutefois le possesseur du terminal peut penser être victime d'une intrusion dans sa vie privée. Cette pratique est utilisée, entre autres, pour diffuser des publicités sur les appareils à portée d'un magasin[19].

Bluesnarfing

Le Bluesnarfing (de l'anglais « to snarf », manger consommer gloutonnement), est une attaque consistant à extraire des informations personnelles d'un terminal. Dans ces informations on peut retrouver des données facilement accessibles sur mobile notamment, telles que le calendrier, les images, les contacts ainsi que les SMS. Contrairement au Blue Jacking cette attaque ne se contente pas d'envoyer des informations inoffensives aux terminaux mais elle a pour but le vol des informations privées[19].

Une version avancée du BlueSnarf appelée BlueSnarf++ permet également d’accéder au système de fichier de l'appareil cible.

Bluebugging

Le Bluebugging (de l'anglais « bugging », l'action de placer un mouchard), est une attaque similaire au Blue Snarfing, où l'attaquant ne se content pas de voler des informations disponible sur le terminal attaqué, mais laisse derrière lui un mouchard capable d'envoyer des informations même lorsque le lien Bluetooth est rompu, permettant à l'attaquant de récupérer et d'écouter des appels passés depuis l'appareil attaqué[20].

Bluetracking

Le Bluetracking (de l'anglais « track », suivre), est une technique qui consiste à placer un appareil qui écoute et enregistre le passage de tous les autres appareils à sa portée. L'attaquant peut donc se construire une base de données contenant les adresses MAC de terminaux, leur position et la durée durant laquelle ils sont à portée. Cette pratique ne laisse pas de traces et peut servir pour de futures attaques puisque l'on peut déterminer l'emplacement d'un certain terminal s'il se rend régulièrement au même endroit sur une même plage horaire[21] - [22].

Bluesnipping

Le Bluesnipping est une technique utilisée pour améliorer grandement la portée d'un signal Bluetooth afin de porter une attaque depuis une distance éloignée[23].

Man-in-the-Middle Attack

L'attaque Man-in-the-Middle est une attaque où un intrus se connecte à deux terminaux et fait croire à ces terminaux qu'ils sont connectés directement l'un à l'autre, il contrôle pourtant le trafic et peut écouter ou modifier les échanges entre les deux terminaux[24].

Épuisement de batterie

Diverses attaques permettent de vider rapidement la batterie d'un appareil connecté en Bluetooth en provoquant une utilisation intensive et inutile du protocole. Parmi ces attaques on peut retrouver: Ping of Death Flood, BlueSpam Flood, Blueper Flood ou encore BlueSmack Flood. Les attaques Blueper Flood ou BlueSmack Flood peuvent être qualifiées de DDoS, mais lorsque la quantité de requêtes est contrôlée, le service continue de marcher normalement et consomme de la batterie.

Cabir

Cabir est le nom d'un ver informatique infectant les mobiles, développé pour infecter des terminaux tournant sous Symbian OS, il utilise la fonction "Object Push Profile" pour se propager via Bluetooth sur les autres terminaux à portée. Ce virus est inoffensif car il ne fait que se répliquer et affiche le message "Caribe" au démarrage du téléphone, il est pourtant une preuve de concept sur le développement de virus sur mobile pouvant se répandre entre les terminaux et reste le premier ver pouvant infecter les mobiles découverts[25].

Pour mettre en place les différentes attaques citées ci-dessus, de nombreux outils ont vu le jour. En voici quelques exemples ainsi que l'utilisation qui peut en être faite.

BlueScanner

BlueScanner est un programme écrit en Bash qui permet de récupérer des informations sur les dispositifs Bluetooth alentours sans demander d'appariement[26].

Blooover

Trifinite a publié en décembre 2005 Blooover II, la seconde version de son logiciel d'attaques Bluetooth qui fonctionne sur téléphone[27]. Cet outil permet notamment à un attaquant de se connecter aux systèmes d'oreillettes sans fil des voitures vulnérables et d'enregistrer les conversations en cours dans cette voiture[28].

Bluetooth Stack Smasher

Publié par SecuObs en 2006, BSS (Bluetooth Stack Smasher) est un outil qui permet de stresser le protocole L2CAP d'un dispositif Bluetooth afin d'obtenir des informations sur ce dernier, ou le rendre non-fonctionnel[29]. Bien que le résultat le plus courant de ce genre d'attaques soit un simple arrêt de l'appareil, BSS représente néanmoins un pas en avant pour ceux qui souhaitent implémenter des logiciels plus robustes de détection de failles d'implémentation des protocoles Bluetooth[28].

BT-Crack

BT-Crack est un outil qui permet de reproduire d'implémenter l'attaque Cracking the Bluetooth PIN[30].

Kali Linux

La plateforme de tests d'intrusion Kali Linux 2.0

Kali Linux est la nouvelle version de Backtrack[31]. Kali Linux est une plateforme permettant des tentatives d'intrusion qui tourne sur Debian et est disponible en Live CD. C'est à ce jour un des outils les plus puissants pour faire des tentatives d'intrusions. Il possède notamment des extensions comme Redfang[32] qui permet de dévoiler les appareils Bluetooth non-visibles à proximité.

Avec l'arrivée de la version 4 et 5 de Bluetooth qui ont considérablement augmenté sa portée, le nombre d'outils a crû rapidement. L'intégration de Bluetooth aux appareils de l'internet des objets rend également les attaques plus intéressantes pour les pirates. C'est pourquoi cette liste n'est pas exhaustive et continuera de grandir à mesure que de nouveaux outils et méthodes de tests d'intrusions verront le jour.

L'analyse du trafic d'un appareil permet de déceler des anomalies dans l'utilisation de Bluetooth, et ainsi repérer des tentatives d'intrusions. Quelques règles simples d'analyse permettent de détecter des attaques de différents types[33] :

• Les tentatives de connexion répétées qui échouent peuvent indiquer une attaque en ligne visant à découvrir le PIN de la victime;
• Des connexions et déconnexions répétées peuvent indiquer une attaque par déni de service;
• Un nombre important de transmissions NAK peut indiquer une attaque Big NAK. Cela va causer une boucle de retransmission infinie sur le périphérique;
• Des délais anormalement longs peuvent indiquer une attaque par le milieu car l'attaquant perd un certain temps pour retransmettre les paquets à la destination;
• Des réceptions répétées de paquets POLL peuvent indiquer qu'un périphérique tente d'empêcher votre appareil de passer en mode veille. En effet, un paquet POLL est normalement envoyé par un maître pour vérifier si l'esclave est toujours en vie. Un périphérique esclave recevant un paquet POLL est obligé de répondre. Dans le cadre d'une attaque, cela peut forcer la victime à ne pas entrer en mode d'économie d'énergie ou en mode veille[34];
• Un taux anormal d'erreurs de bits peut indiquer que l'attaquant brouille la couche physique;
• Un trafic élevé entre deux périphériques. Cela peut indiquer que l'attaquant tente une attaque par épuisement de la batterie;
• Deux BD_ADDR identiques dans la portée de vulnérabilité peuvent indiquer que l'attaquant utilise une attaque de duplication du BD_ADDR pour empêcher les victimes d'échanger des données, ou même se faire passer pour elles;
• Une requête L2CAP pour le plus grand taux de données possible ou la plus faible latence possible est suspecte. Si une telle requête est acceptée, alors les périphériques légitimes ne pourront pas avoir accès au service dans un temps raisonnable car tout le débit sera réservé pour l'attaquant;
• Des tentatives de connexion surprenantes ou les requêtes de transfert de données depuis des hôtes inconnus peuvent indiquer qu'un virus ou un ver tente d'infecter le périphérique[35];
• Des périphériques qui demandent une clef de chiffrement inférieure à 128bits souhaitent probablement attaquer le système cryptographique de l'appareil;
• Une discordance dans les signatures des ondes radio indique une tentative d'usurpation d'identité. En effet, chaque appareil ayant une signature radio qui lui est propre, un changement de signature pendant une connexion est le signe que l'émetteur n'est plus celui qu'il prétend être[36];
• Les demandes de connexion en mode JW quand l'appareil peut utiliser un mode plus sécurisé sont à proscrire. Cela peut indiquer qu'une attaque par l'homme du milieu est en cours[37] - [38].

Un système de surveillance peut alors être implémenté. Ce système aurait besoin de connaître certaines informations concernant les autres périphériques du picoréseau auquel l'appareil est connecté, comme la signature de ses ondes radio par exemple. Ainsi, ce système pourrait détecter les tentatives d'attaques et ainsi déclencher un système de prévention des attaques manuel ou automatique. Un système automatique est fortement recommandé. Cependant, si aucun système de prévention d'attaques n'est implémenté, l'utilisateur serait néanmoins immédiatement prévenu.

Afin de traiter les attaques détectées par le système de détection, un système de prévention d'attaques doit être implémenté. Ce système a pour but d'empêcher l'attaque de continuer, tout en permettant au périphérique de fonctionner le plus normalement possible[39]. Cela fonctionne en deux étapes.

Tout d'abord, ce système recevrait un message d'alerte de la part du système de détection d'erreur. Il doit alors instantanément déconnecter le périphérique afin de stopper l'attaque au plus vite. Certains types d'attaques nécessitant également des demandes répétées de connexion, le système doit refuser toute demande d'appariement pendant un temps prédéterminé[40].

Dans un second temps, il sera possible de retenir un maximum d'informations possible concernant l'attaquant afin d'empêcher de nouvelles tentatives d'attaques de sa part. On peut notamment garder l'adresse de l'attaquant, son nom public, les aptitudes du périphérique attaquant ainsi que sa signature d'ondes radio[40].

Il faut cependant prendre garde, car l'implémentation de ces solutions n'est pas possible sur tous les périphériques. En effet, Bluetooth est implémenté dans des appareils qui possèdent parfois trop peu de mémoire ou de capacité de calcul pour permettre une utilisation de solutions de détection et de traitement des attaques. C'est sur ce point que se basent la majorité des attaques afin de ne pas être bloquées.

Pour se prémunir contre les attaques sur son périphérique Bluetooth, plusieurs solutions doivent être mises en place. Tout d'abord, d'un point de vue de l'utilisateur, il est important de ne pas utiliser son périphérique n'importe où et n'importe comment. Il faut éteindre son périphérique quand il n'est pas utilisé, et le rendre non-détectable par les périphériques alentours sauf quand c'est souhaité. Il ne faut pas accepter toutes les connexions, et taper son mot de passe à l'abri des regards indiscrets. Les mots de passe doivent être suffisamment longs et aléatoires pour ne pas être devinés. Lorsqu'un périphérique est perdu ou volé, il faut supprimer la connexion à ce périphérique sur tous les appareils qui s'y sont déjà connecté[41] - [42].

Ensuite, il faut configurer son périphérique. En effet, les paramètres par défaut ne sont souvent pas suffisamment sécurisés. L'installation d'un antivirus peut également permettre de se prémunir contre les vers. Le mode non-secure et le modèle Just Work ne doivent pas être utilisés pour transmettre des données confidentielles. L'authentification mutuelle doit être activée lors de l'appairage. Le chiffrement pour toutes les communications en broadcast doit être également activé. Enfin, il faut régler la puissance des appareils au minimum nécessaire, afin que la portée du périphérique n'excède pas celle escomptée[43].

Concernant les clefs d'appairage et de chiffrement, il ne faut pas utiliser de clef unique mais des combinaisons de clefs pour éviter la réutilisation de la clef d'appairage. Les clefs de chiffrement doivent avoir une longueur d'au moins 128bits pour empêcher les attaques par force brute. Une longueur supérieure augmentera encore le temps nécessaire à une telle attaque[44].

• (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) Margaret Tan et Kathrine Aguilar Masagca, « An Investigation of Bluetooth Security Threats », 2011 International Conference on Information Science and Applications,‎ avril 2011, p. 1-7 (ISBN 978-1-4244-9222-0, ISSN 2162-9048, DOI 10.1109/ICISA.2011.5772388)
  2011 International Conference on Information Science and Applications
• (en) Redjem Bouhenguel, Imad Mahgoub et Mohammad Ilyas, « Bluetooth Security in Wearable Computing Applications », 2008 International Symposium on High Capacity Optical Networks and Enabling Technologies,‎ novembre 2008, p. 182-186 (ISBN 978-1-4244-2960-8, 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
• (en) Alfred Loo, « Technical opinion: Security threats of smart phones and Bluetooth », Communications of the ACM - Being Human in the Digital Age, vol. 52, n^o 3,‎ mars 2009, p. 150-152 (ISSN 0001-0782, DOI 10.1145/1467247.1467282)

• (en) Mike Ryan, « Bluetooth: With Low Energy comes Low Security », Presented as part of the 7th USENIX Workshop on Offensive Technologies,‎ 2013
• (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 M.J. Haataja et Konstantin Hypponen, « Man-In-The-Middle attacks on bluetooth: a comparative analysis, a novel attack, and countermeasures », IEEE Transactions on Wireless Communications,‎ 12-18 mars 2008, p. 39-50 (ISBN 978-1-4244-1687-5, DOI 10.1109/ISCCSP.2008.4537388)
• (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)
• (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)
• (en) Dennis Kügler, « “Man in the Middle” Attacks on Bluetooth », Lecture Notes in Computer Science,‎ janvier 2003, p. 149-161 (ISBN 978-3-540-40663-1, DOI 10.1007/978-3-540-45126-6_11)
• (en) Jennifer Thom-Santelli, Alex Ainslie et Geri Gay, « Location, location, location: a study of bluejacking practices », CHI EA '07 CHI '07 Extended Abstracts on Human Factors in Computing Systems,‎ 28 avril 2007, p. 2693-2698 (ISBN 978-1-59593-642-4, DOI 10.1145/1240866.1241064)
• (en) Marc Haase et Matthias Handy, « BlueTrack – Imperceptible Tracking of Bluetooth Devices », Ubicomp Poster Proceedings,‎ septembre 2004, p. 2
  Bluetooth enabled devices are potentially vulnerable against passive tracking attacks because of their unique and invariant device address. The contribution of this paper is the exploration of tracking vulnerability of Bluetooth devices. We implemented BlueTrack, a tracking system based on off-the-shelf components. We tested our system at two sites, at a university building with several lecture rooms and at a CeBIT 2004 exhibition stand.

• (en) Paraskevas Kitsos, Nicolas Sklavos Sklavos, Kyriakos Papadomanolakis et Odysseas Koufopavlou, « Hardware implementation of Bluetooth security », IEEE Pervasive Computing, vol. 2, n^o 1,‎ janvier 2003, p. 1096-1102 (ISBN 978-1-4673-2843-2, 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 International Conference on Communications, 2005. ICC 2005. 2005, vol. 3,‎ mai 2005, p. 2070-2074 (ISBN 0-7803-8938-7, 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, « Contention for Man-in-the-Middle Attacks in Bluetooth Networks », 2012 Fourth International Conference on Computational Intelligence and Communication Networks,‎ novembre 2012, p. 700-703 (ISBN 978-1-4673-2981-1, DOI 10.1109/CICN.2012.72)
  2012 Fourth International Conference on Computational Intelligence and Communication Networks

• (en) Y. W. Su, 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

• (en) Kumar Panigraphy Saroj, Kumar Jena Sanjay et Kumar Turuk Ashok, « Security in Bluetooth, RFID and wireless sensor networks », Proceedings of the 2011 International Conference on Communication, Computing & Security,‎ février 2011, p. 628-633 (ISBN 978-1-4503-0464-1, DOI 10.1145/1947940.1948071)

• (en) Purvish Patel, Akash Marchant, Nisarg Tailor et Chintan Trivedi, « Bluetooth Security Issues », International Journal of Computer Science and Information Technologies,‎ 2015, p. 5295-5299 (ISSN 0975-9646)

• (en) Timothy K. Buennemeyer, Theresa M. Nelson, Michael A. Gora, Randy C. Marchany et Joseph G. Tront, « Battery Polling and Trace Determination for Bluetooth Attack Detection in Mobile Devices », 2007 IEEE SMC Information Assurance and Security Workshop,‎ 2007, p. 135-142 (DOI 10.1109/IAW.2007.381925)

• (en) Usman Sarwar, Sureswaran Ramadass et Rahmat Budiarto, « A framework for detecting bluetooth mobile worms », 2007 IEEE International Conference on Telecommunications and Malaysia International Conference on Communications,‎ 2007, p. 343-347 (DOI 10.1109/ICTMICC.2007.4448656)

• (en) Nateq Be-Nazir Ibn Minar et Mohammed Tarique, « Bluetooth Security Threats and Solutions: A survey », International Journal of Distributed and Parallel Systems,‎ 2012, p. 127-148 (DOI 10.5121/ijdps.2012.3110)

• (en) John Padgette, Karen Scarfone et Lily Chen, « Guide to Bluetooth Security », Guide to Bluetooth Security: Recommendations of the National Institute of Standards and Technology (Special Publication 800-121 Revision 1),‎ septembre 2008, p. 1-43 (ISBN 9781478168966)
  Recommendations of the National Institute of Standards and Technology

• (en) Keijo Haataja, Security Threats and Countermeasures in Bluetooth-Enabled Systems, University of Kuopio, Professor Markku Nihtilä, D.Sc. Department of Mathematics and Statistics, février 2009, 191 p. (ISBN 978-951-781-992-3, lire en ligne)

• (en) Sanna Pasanen, Keijo Haataja, Niina Paivinen et Pekka Toivanen, « New Efficient RF Fingerprint-Based Security Solution for Bluetooth Secure Simple Pairing », 2010 43rd Hawaii International Conference on System Sciences,‎ 2010, p. 1-8 (DOI 10.1109/HICSS.2010.286)

(en) EC-Council, Ethical Hacking and Countermeasures : Secure Network Operating Systems and Infrastructures, 2017, 50 p. (ISBN 978-1-305-88346-8)

• (en) Bruce Potter, « Bluetooth security moves », Network Security, vol. 2006, n^o 3,‎ mars 2006, p. 19-20 (DOI 10.1016/S1353-4858(06)70348-8)