Evaluation des attaques sur protocole Bluetooth : Différence entre versions

De Wiki d'activités IMA
(→‎Trame Bluetooth)
(→‎Bilan du stage)
 
(288 révisions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
 
==Description du stage==
 
==Description du stage==
  
−
Dans le cadre de ma quatrième année d'études en Informatique, Microélectronique et Automatique, je dois effecuer un stage ingénieur de six semaines minimum. J'ai choisi d'effectuer mon stage à L'IRCICA (Institut de Recherche sur les Composants logiciels et matériels pour l’Information et la Communication Avancée) à Villeneuve d'Ascq. L'objectif de mon stage est d'évaluer les attaques sur le protocole bluetooth. Pour cela, je dispose d'une enceinte bluetooth Nokia Play 360° et d'un module Ubertooth One.
+
Dans le cadre de ma quatrième année d'études en Informatique, Microélectronique et Automatique, je dois effecuer un stage ingénieur de six semaines minimum. J'ai choisi d'effectuer mon stage à L'IRCICA (Institut de Recherche sur les Composants logiciels et matériels pour l’Information et la Communication Avancée) à Villeneuve d'Ascq au sein de l'équipe CRIStAL 2XS. L'objectif de mon stage est d'évaluer les attaques sur le protocole bluetooth. Pour cela, je dispose d'un module Ubertooth One.
 +
 
 +
[[Fichier:bluetooth_logo.png|300px|center]]
  
 
==Avancement du Stage==
 
==Avancement du Stage==
Ligne 9 : Ligne 11 :
 
====Prise en main du module Ubertooth One====
 
====Prise en main du module Ubertooth One====
  
−
Le module Ubertooth one est une plateforme open source destinée aux expérimentations sur le protocle Bluetooth. Le module comprend :  
+
Le module Ubertooth one est une plateforme open source destinée aux expérimentations sur le protocole Bluetooth. Le module comprend :  
 
* un microcontrôleur LPC175x ARM Cortex-M3
 
* un microcontrôleur LPC175x ARM Cortex-M3
−
* un module RF front end CC2400
+
* un module RF front end CC2591
 
* un module de transmission sans fil CC2400
 
* un module de transmission sans fil CC2400
 
* un port USB-A 2.0 permettant de le connecter sur un ordinateur
 
* un port USB-A 2.0 permettant de le connecter sur un ordinateur
Ligne 19 : Ligne 21 :
  
 
[[Fichier:Ubertooth.jpg|300px|thumb|center|Figure 1 : Module Ubertooth One et son antenne]]
 
[[Fichier:Ubertooth.jpg|300px|thumb|center|Figure 1 : Module Ubertooth One et son antenne]]
−
 
  
 
[[Media:Schematic.pdf|Schematic de l'Ubertooth One]]
 
[[Media:Schematic.pdf|Schematic de l'Ubertooth One]]
Ligne 73 : Ligne 74 :
 
  make
 
  make
 
  sudo make install
 
  sudo make install
 +
 +
5) Installation de Kismet
 +
 +
sudo apt-get install libpcap0.8-dev libcap-dev pkg-config \
 +
build-essential libnl-dev libncurses-dev libpcre3-dev \
 +
libpcap-dev libcap-dev
 +
wget http://www.kismetwireless.net/code/kismet-2011-03-R2.tar.gz
 +
tar xf kismet-2011-03-R2.tar.gz
 +
sudo mv kismet-2011-03-R2 /usr/src/kismet
 +
ln -s ../ubertooth-2012-10-R1/host/kismet/plugin-ubertooth /usr/src/kismet
 +
cd /usr/src/kismet
 +
sudo ./configure
 +
sudo make && sudo make plugins
 +
sudo make suidinstall
 +
sudo make plugins-install
  
 
====Recherches sur le protocole Bluetooth====
 
====Recherches sur le protocole Bluetooth====
Ligne 86 : Ligne 102 :
 
* 2004 : sortie de la version 2.0 avec un meilleur débit (passage de 1 à 3 Mb/s).
 
* 2004 : sortie de la version 2.0 avec un meilleur débit (passage de 1 à 3 Mb/s).
 
* 2009 : sortie de la version 3.0.
 
* 2009 : sortie de la version 3.0.
−
* 2010 : sortie de la version 4.0 plus performante et moins gourmande en énergie. La bande passante permet des restitutions musicales stéréophoniques de qualité comparable au CD.
+
* 2010 : sortie de la version 4.0 plus performante et moins gourmande en énergie. Cette nouvelle génération apparaît comme une révolution et permet une large démocratisation d'appareils connectés en tout genre.
 
* 2016 : sortie de la version 5 avec un débit théorique jusqu'a 2 Mb/s et rayon d'action jusqu'a 240 mètres.
 
* 2016 : sortie de la version 5 avec un débit théorique jusqu'a 2 Mb/s et rayon d'action jusqu'a 240 mètres.
  
−
=====La couche radio=====
+
=====Couche radio=====
  
 
La couche radio (la couche la plus basse) est gérée au niveau matériel. C'est elle qui s'occupe de l'émission et de la réception des ondes radio. Elle définit les caractéristiques telles que la bande de fréquence et l'arrangement des canaux, les caractéristiques du transmetteur, de la modulation, du récepteur. Le système Bluetooth opère dans les bandes de fréquences ISM (Industrial, Scientific and Medical) 2,4 GHz dont l'exploitation ne nécessite pas de licence vu la faible puissance d'émission et le risque faible d'interférences. Cette bande de fréquences est comprise entre 2 400 et 2 483,5 MHz. Différents types de modulations peuvent être utilisées par l'émetteur : PSK à 2, 4 ou 8 symboles. Le Bluetooth utilise 79 canaux numérotés de 0 à 78 séparés de 1 MHz. Le codage de l'information se fait par sauts de fréquence. Il existe 3 classes de modules Bluetooth sur le marché caractérisant leur puissance et leur portée :
 
La couche radio (la couche la plus basse) est gérée au niveau matériel. C'est elle qui s'occupe de l'émission et de la réception des ondes radio. Elle définit les caractéristiques telles que la bande de fréquence et l'arrangement des canaux, les caractéristiques du transmetteur, de la modulation, du récepteur. Le système Bluetooth opère dans les bandes de fréquences ISM (Industrial, Scientific and Medical) 2,4 GHz dont l'exploitation ne nécessite pas de licence vu la faible puissance d'émission et le risque faible d'interférences. Cette bande de fréquences est comprise entre 2 400 et 2 483,5 MHz. Différents types de modulations peuvent être utilisées par l'émetteur : PSK à 2, 4 ou 8 symboles. Le Bluetooth utilise 79 canaux numérotés de 0 à 78 séparés de 1 MHz. Le codage de l'information se fait par sauts de fréquence. Il existe 3 classes de modules Bluetooth sur le marché caractérisant leur puissance et leur portée :
Ligne 96 : Ligne 112 :
 
* Classe 3 : 1 mW (0 dBm), quelques mètres
 
* Classe 3 : 1 mW (0 dBm), quelques mètres
  
−
=====Trame Bluetooth=====
+
=====Paquets Bluetooth=====
 +
 
 +
======Forme générale======
  
 
{| class="wikitable"
 
{| class="wikitable"
 
! style="background-color:#000080; color:#FFFFFF" | Code d'accès (Access code) !! style="background-color:#6495ED; color:#FFFFFF" | En-tête (Header) !! style="background-color:#87CEFA; color:#FFFFFF" | Données (Payload)
 
! style="background-color:#000080; color:#FFFFFF" | Code d'accès (Access code) !! style="background-color:#6495ED; color:#FFFFFF" | En-tête (Header) !! style="background-color:#87CEFA; color:#FFFFFF" | Données (Payload)
 
|- style="text-align: center;"
 
|- style="text-align: center;"
−
| 72 bits
+
| 68/72 bits
 
| 54 bits
 
| 54 bits
 
| 0 à 2745 bits
 
| 0 à 2745 bits
 
|}
 
|}
−
 
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! colspan="3" style="background-color:#000080; color:#FFFFFF" | Code d'accès (72 bits)
+
! colspan="3" style="background-color:#000080; color:#FFFFFF" | Code d'accès (68/72 bits)
 
|- style="text-align: center;"
 
|- style="text-align: center;"
 
| '''Préambule'''
 
| '''Préambule'''
Ligne 119 : Ligne 136 :
 
|-
 
|-
 
| 0101 ou 1010 <br> Permet de détecter le début de la trame
 
| 0101 ou 1010 <br> Permet de détecter le début de la trame
−
|  
+
|
−
| 0101 ou 1010 <br> Permet de détecter la fin de la trame si code sur 64 bits
+
* CAC (Channel Access Code)
 +
* DAC (Device Access Code)
 +
* IAC (Inquiry Access Code)
 +
** GIAC (Generic IAC)
 +
** DIAC (Dedicated IAC)
 +
| 0101 ou 1010 <br> Permet de détecter la fin de la trame
 
|}
 
|}
  
−
 
−
En-tête (18 bits répétés 3 fois pour garantir la réception = 54 bits)
 
 
{| class="wikitable"
 
{| class="wikitable"
−
! Adresse MAC !! Type !! Flow !! ARQN !! SEQN !! HEC
+
! colspan="6" style="background-color:#6495ED; color:#FFFFFF" | En-tête (18 bits répétés 3 fois pour garantir la réception = 54 bits)
−
|-
+
|- style="text-align: center;"
 +
| '''AMA'''
 +
| '''Type'''
 +
| '''Flow'''
 +
| '''ARQN'''
 +
| '''SEQN'''
 +
| '''HEC'''
 +
|- style="text-align: center;"
 
| 3 bits
 
| 3 bits
 
| 4 bits
 
| 4 bits
Ligne 135 : Ligne 162 :
 
| 8 bits
 
| 8 bits
 
|-
 
|-
−
| Medium Access Control <br> Adresse active de l'esclave
+
| Active Member Address : <br> Adresse active de l'esclave <br>
−
| SCO, ACL, NULL, POLL / type de FEC / durée du payload
+
* 0 pour le broadcast
 +
* 1 à 6 pour le périphérique
 +
|
 +
* ID (0000)
 +
* NULL (0001)
 +
* POLL (0010)
 +
* FHS (0011)
 +
* SCO
 +
* ACL
 
| Contrôle de flow pour signaler que la mémoire tampon est pleine
 
| Contrôle de flow pour signaler que la mémoire tampon est pleine
−
| Automatic Repeat reQuest sequence Number <br> Indication de l’acquittement (ACK)
+
| Automatic Repeat reQuest sequence Number :
−
| SEQuence Number <br> Numéro de séquence
+
* ARQN=1 si paquet précédent bien reçu et SEQN=SEQN+1
 +
* ARQN=0 si paquet précédent pas bien reçu
 +
| SEQuence Number : <br> Numéro de séquence
 
| Header Error Control
 
| Header Error Control
 +
|}
 +
 +
======Types de paquets======
 +
 +
* Paquets de contôle :
 +
** ID : utilsé pour le paging, la recherche, les réponses. Il est Composé d'un DAC ou IAC.
 +
** NULL : utilisé pour faire une réponse de retour notamment  lors  d’une réponse  à  une  requête  POLL.  Elle  informe  le  maître  sur  le  succès  de  la  transmission. Ne dois pas être acquité.
 +
** POLL : idem que NULL mais doit être acquité. Il est envoyé par le maître à l’esclave pour l’obliger a répondre même si il n’a rien à dire.
 +
** FHS (Frequency Hopping Synchronisation) : utilisé  pour  synchroniser les esclaves lors de la mise en place du piconet.
 +
 +
 +
* Paquets SCO (liaison à connexion synchrone) :
 +
** Transmission voix temps réel, point à point, bidirectionnelle.
 +
** Débit à 64 Kbit/s pour être compatible avec les normes d'encodage.
 +
** Deux types de paquets SCO :
 +
*** HVx (High quality Voice) sans correction d’erreur.
 +
*** DV (Data Voice) porte à la fois les données et la voix. Le ratio voix-données est d’environ 1/3  pour 2/3.
 +
 +
{| class="wikitable"
 +
! Type !! colspan ="5" style="background-color:#87CEFA; color:#FFFFFF" | Payload (30 octets)
 +
|- style="text-align:center;"
 +
| HV1
 +
| colspan="2" | Audio (10 octets)
 +
| colspan="3" | FEC (20 octets)
 +
|- style="text-align:center;"
 +
| HV2
 +
| colspan="3" | Audio (20 octets)
 +
| colspan="2" | FEC (10 octets)
 +
|- style="text-align:center;"
 +
| HV3
 +
| colspan="5" | Audio (30 octets)
 +
|- style="text-align:center;"
 +
| DV
 +
| Audio (10 octets)
 +
| Header (1 octet)
 +
| Données (0 à 9 octets)
 +
| FEC (2/3 données)
 +
| CRC (2 octets)
 +
|}
 +
 +
 +
* Paquets ACL (liaison à connexion asynchrone) :
 +
** Conçu pour l'échange de données.
 +
** Broadcast possible.
 +
** Deux types de paquets ACL :
 +
*** DMx (Data Medium) avec un encodage permettant la correction des erreurs en ligne.
 +
*** DHx (Data High) sans correction d'erreur pour un débit plus élevé.
 +
 +
{| class="wikitable"
 +
! Type !! colspan ="4" style="background-color:#87CEFA; color:#FFFFFF" | Payload (0 à 343 octets)
 +
|- style="text-align:center;"
 +
| DM1
 +
| Header (1 octet)
 +
| Données (0 à 17 octets)
 +
| rowspan="3" | FEC (2/3 données)
 +
| rowspan="6" | CRC (2 octets)
 +
|- style="text-align:center;"
 +
| DM3
 +
| rowspan="2" | Header (2 octet)
 +
| Données (0 à 121 octets)
 +
|- style="text-align:center;"
 +
| DM5
 +
| Données (0 à 224 octets)
 +
|- style="text-align:center;"
 +
| DH1
 +
| Header (1 octet)
 +
| colspan="2" | Données (0 à 27 octets)
 +
|- style="text-align:center;"
 +
| DH3
 +
| rowspan="2" | Header (2 octet)
 +
| colspan="2" | Données (0 à 183 octets)
 +
|- style="text-align:center;"
 +
| DH5
 +
| colspan="2" | Données (0 à 339 octets)
 
|}
 
|}
  
 
=====Le Bluetooth Low Energy (BLE)=====
 
=====Le Bluetooth Low Energy (BLE)=====
  
−
Le Bluetooth Low Energy ou Bluetooth 4.0 est une alternative au Bluetooth "classique", avec une réduction du coût et de la consommation en puissance, tout en conservant une portée de communication équivalente. Il cherche à adresser des appareils à faible puissance de calcul, à faible coût de production et dont l’espérance de vie est à maximiser.
+
Le Bluetooth Low Energy, Bluetooth 4.0 ou Bluetooth Smart est une alternative au Bluetooth "classique" (version 3.0 et inférieures), avec une réduction du coût et de la consommation en puissance, tout en conservant une portée de communication équivalente. Il cherche à adresser des appareils à faible puissance de calcul, à faible coût de production et dont l’espérance de vie est à maximiser. Le bluetooth "classique" est donc plutôt destiné aux appareils diffusant beaucoup de données comme de l'audio ou de la vidéo alors que le Bluetooth 4.0 est plutôt destiné aux appareils diffusant peu de données tels que les capteurs, objets connectés nécessitant un plus faible débit de données. le Bluetooth Smart Ready est compatible avec les deux types de Bluetooth, il est destiné aux smartphones, ordinateurs, il permet de faire le lien entre les deux standards car ils ne sont pas compatibles.
 +
 
 +
[[Fichier:ble.png|500px|thumb|center|Figure 2 : Bluetooth 4.0]]
 +
 
 +
La technologie Bluetooth Low Energy opère dans la même bande de fréquence (2,4000 - 2,4835 GHz) que le Bluetooth classique, il utilise une modulation par déplacement de fréquence GFSK. 40 canaux physiques sont alloués, espacés de 2 MHz (80 canaux espacés de 1 MHz pour le Bluetooth "classique"). Trois d'entre eux sont des canaux d'advertising et les autres sont des canaux de données.
 +
 
 +
[[Fichier:channels.png|500px|thumb|center|Figure 3 : Canaux physiques du BLE]]
 +
 
 +
Les trames BLE sont différentes de de celles du Bluetooth classique décrites ci-dessus. Les format de paquets est unique et il existe deux principaux types de paquets : "Advertising" et "Data", ce qui simplifie le protocole.
 +
 
 +
[[Fichier:trames_BLE.gif|500px|thumb|center|Figure 4 : Trames BLE]]
 +
 
 +
{| class="wikitable"
 +
! Canaux !! Etat !! Type de PDU !! Usage
 +
|-
 +
| rowspan="7" | Advertising (37, 38, 39)
 +
| rowspan="4" | Advertising
 +
| ADV_IND
 +
| Connectable undirected advertising event
 +
|-
 +
| ADV_DIRECT_IND
 +
| Connectable directed advertising event
 +
|-
 +
| ADV_NOCONN_IND
 +
| Broadcast
 +
|-
 +
| ADV_SCAN_IND
 +
| Connectable directed advertising event<br>Scannable
 +
|-
 +
| Scanning
 +
| ADV_SCAN_REQ
 +
| Requête
 +
|-
 +
| Advertising
 +
| ADV_SCAN_RSP
 +
| Réponse
 +
|-
 +
| Initiating
 +
| CONNECT_REQ
 +
| Envoyé par l'initiateur pour établir une connexion
 +
|-
 +
| rowspan="2" |Data (0 à 36)
 +
| Data
 +
| Data PDU. Empty PDU : l'esclave peut répondre avec n'importe quel type de PDU
 +
| General data
 +
|-
 +
| Control
 +
| Control PDU
 +
| Control data
 +
|}
 +
 
 +
====Capture de paquets Bluetooth====
 +
 
 +
=====Principe du "Bluetooth sniffing"=====
 +
 
 +
Le module Ubertooth One que j'utilise est un sniffer Bluetooth. Il permet d'intercepter les paquets échangés entre deux appareils Bluetooth appairés. L'un des appareils est le maître (par exemple un smartphone), et l'autre est l'esclave (par exemple une montre connectée). Un Sniffer est donc un dispositif passif qui n'envoie pas de paquets, il observe simplement le trafic.
 +
 
 +
 
 +
[[Fichier:sniffing.png|400px|thumb|center|Figure 5 : Bluetooth Sniffing]]
 +
 
 +
=====Commandes Ubertooth=====
 +
 
 +
Différents commandes Ubertooth permettent de récupérer des paquets Bluetooth :
 +
 
 +
* '''ubertooth-rx''' permet de voir le LAP (Lower Address Part) des différents appareils Bluetooth qui envoient des paquets à proximité de l'Ubertooth One. Le LAP est formé des trois derniers octets de l'adresse MAC bluetooth d'un appareil. On peut aussi voir le canal sur lequel le paquet a été envoyé.
 +
 
 +
* '''ubertooth-btle''' permet de récupérer les paquets BLE
 +
 
 +
=====Analyseur de spectre=====
 +
 
 +
Un outil d'analyse specrale est fourni avec Ubertooth. Il permet d'observer en temps réel le spectre fréquentiel entre 2,400 et 2,480 GHz, plage de fréquence utilisée par le WiFi et le Bluetooth. Cet outil ne m'est pas d'une grande utilité vu le grand nombre d'appareils connectés en Bluetooth ou en WiFi dans le labo, qui ne permettent pas d'analyser avec certitude les résulats. Pour ouvrir l'outil d'analyse spectrale :
 +
ubertooth-specan-ui
 +
 
 +
[[Fichier:spectre.png|500px|thumb|center|Figure 6 : Spectre observé avec l'outil d'analyse spectrale d'Ubertooth]]
 +
 
 +
=====Capture de paquets avec Kismet=====
 +
 
 +
======Méthode employée======
 +
 
 +
Pour capturer des paquets Bluetooth avec Kismet, il faut suivre la procédure suivante :
 +
 
 +
* Ouvrir Kismet en tant que root :
 +
sudo kismet
 +
* Appuyer sur "Yes" pour démarrer les services Kismet puis "Start"
 +
* Fermer la fenêtre console : "Close Console Window"
 +
* Quand la fenêtre "Add sources" apparaît, taper "ubertooth" dans les champs "Intf" et "Name" et appuyer sur "Add"
 +
* Dans le menu, ouvrir Kismet/Plugins/Select Pluggin...
 +
* Autoriser le pluggin "ubertooth_ui.so" en appuyant sur espace et fermer
 +
 
 +
======Trames observées======
 +
 
 +
Afin de tester la capture de paquets Bluetooth avec Kismet, je dispose d'une enceinte Bluetooth Nokia Play 360 et de mon smartphone pour envoyer de la musique.
 +
 
 +
[[Fichier:kismet.png|300px|thumb|center|Figure 7 : Captures de trames sur Kismet]]
 +
 
 +
Les trames capturées sont enregistrées dans un fichier pcap et peuvent être analysées avec Wireshark.
 +
 
 +
=====Capture de paquets BLE avec Wireshark=====
 +
 
 +
======Méthode employée======
 +
 
 +
Pour capturer des paquets Bluetooth LE sur Wireshark, il faut suivre les instructions suivantes :
 +
 
 +
* Ouvrir un pipe en tapant la commande :
 +
mkfifo /tmp/pipe
 +
* Ouvrir Wireshark en tant que root :
 +
sudo wireshark
 +
* Cliquer sur "Capture" -> "Options" puis "Manage Interfaces"
 +
* Cliquer sur "New" puis taper dans le champ "pipe" :
 +
/tmp/pipe
 +
* Sauvegarder et fermer puis appuyer sur "Start"
 +
* Sur un terminal, taper la commande :
 +
ubertooth-btle -f -c /tmp/pipe
 +
 
 +
======Trames observées======
 +
 
 +
Afin de visualiser des trames BLE, j'ai utilisé un bracelet connecté Razer Nabu X. J'ai pu observer différents types de trames sur wireshark.
 +
 
 +
[[Fichier:nabu.png|300px|thumb|center|Figure 8 : Bracelet connecté Razer Nabu X]]
 +
 
 +
 
 +
[[Fichier:wireshark.png|600px|thumb|center|Figure 9 : Capture de paquets BLE sous Wireshark]]
 +
 
 +
 
 +
Exemples de trames d'advertising observées :
 +
 
 +
* '''Trame SCAN_REQ''' :
 +
 
 +
00 00 18 00 93 00 00 00  36 75 0c 00 00 62 09 00<br>
 +
13 f0 af 09 1a 1a 00 00  <span style="color:red">d6 be 89 8e</span> <span style="color:green">c3 0c</span> <span style="color:blue">c1 06<br>
 +
c3 f6 5a 63</span> <span style="color:orange">fb b3 02 30  34 fb</span> <span style="color:gray">95 b0 3b</span>
 +
 
 +
On remarque que la trame BLE est encapsulée dans une trame PPI.
 +
On voit ensuite les différents éléments de la trame BLE :
 +
* <span style="color:red">Access Address: 0x8e89bed6</span>
 +
* PDU :
 +
** <span style="color:green">Header : 0x0cc3</span>
 +
** Payload :
 +
*** <span style="color:blue">Scanning Address : 63:5a:f6:c3:06:c1</span>
 +
*** <span style="color:orange">Advertising Address : fb:34:30:02:b3:fb</span>
 +
* <span style="color:gray">CRC : 0xa90ddc</span>
 +
 
 +
 
 +
* '''Trame SCAN_RSP''' :
 +
 
 +
00 00 18 00 93 00 00 00  36 75 0c 00 00 62 09 00<br>
 +
8c 00 b0 09 08 08 00 00  <span style="color:red">d6 be 89 8e</span> <span style="color:green">44 1a</span> <span style="color:blue">fb b3<br>
 +
02 30 34 fb</span> <span style="color:orange">06 09 4e 61  62 75 58</span> <span style="color:brown">0c ff 01 02 01<br>
 +
32 06 fb 34 30 02 b3 fb</span>  <span style="color:gray">8c 8b 06</span>
 +
 
 +
On remarque que la trame BLE est encapsulée dans une trame PPI.
 +
On voit ensuite les différents éléments de la trame BLE :
 +
* <span style="color:red">Access Address: 0x8e89bed6</span>
 +
* PDU :
 +
** <span style="color:green">Header : 0x441a</span>
 +
** Payload :
 +
*** <span style="color:blue">Advertising Address : fb:34:30:02:b3:fb</span>
 +
*** Scan Response Data :
 +
**** <span style="color:orange">Device Name :
 +
***** Length : 6 (0x06)
 +
***** Type : Device Name (0x09)
 +
***** Name : NabuX (0x4e61627558)</span>
 +
**** <span style="color:brown">Manufacturer Specific :
 +
***** Length : 12 (0x0c)
 +
***** Type : Manufacturer Specific (0xff)
 +
***** Company ID : Unknown (0x0201)
 +
***** Data : 01 32 06 fb 34 30 02 b3 fb</span>
 +
* <span style="color:gray">CRC : 0x31d160</span>
 +
 
 +
====Bilan de la première semaine====
 +
 
 +
Lors de cette première semaine, j'ai pu me familiariser avec le Bluetooth standard et Low Energy, installer et utiliser le module Ubertooth One pour capturer des paquets Bluetooth. Cependant, je n'arrive pas à capturer les paquets de données envoyés par le smartphone à l'enceinte Bluetooth, ni ceux envoyés par le bracelet connecté. Je ne capture que des packets de Type "Advertising". D'après mes recherches, il est difficile de capturer les paquets de données Bluetooth mais le module Ubertooth One est la solution la moins chère existant actuellement. Cela est du au fait que le Bluetooth utilise une modulation par saut de fréquence, deux paquets successifs ne sont pas envoyés sur le même canal. Mon travail des prochaines semaines va donc être de trouver comment intercepter les paquets de données.
  
 
===Semaine 2===
 
===Semaine 2===
 +
 +
====Pourquoi est-il difficile de "sniffer" les paquets Bluetooth ?====
 +
 +
D'après mes recherches sur les Sniffers Bluetooth, il est plus facile et moins cher de capturer les paquets Bluetooth Low Energy (LE) que les packets du Bluetooth classique (BR/EDR). Cela est dû à la complexité moindre du protocole BLE et à l'utilisation de la modulation GFSK. En effet, les Sniffers pour capturer les paquets du Bluetooth classique sont chers (environ $25 000 pour capturer tous les types de paquets : BR/EDR/LE) car leur capture et décodage nécessite une grande puissance de calcul en raison de la rapidité avec laquelle ils sont envoyés et des sauts de fréquence (1600 sauts/s, 625 us/paquet). L'Ubertooth One que j'utilise est une des solutions les moins chères du marché (environ 130 €) mais ne permet de capturer que les paquets de données BLE. Le fonctionnalités sont plus limitées pour le Bluetooth Classique :
 +
* Capture du LAP (Lower Address Part) des paquets transmis qui contient les 24 deniers bits de l’adresse MAC Bluetooth (BD_ADDR) d'un appareil. C'est la seule partie de l'adresse MAC transmise dans les paquets.
 +
* Capture avancée sous Kismet avec identification de l'UAP (Upper Address Part) qui est constitué des 8 bits qui précédent le LAP dans l'adresse MAC des appareils. Enregistrement des paquets décodés dans un fichier pcapbtbb. Le décodage complet des paquets n'est possible que si l'UAP a été déterminée.
 +
 +
[[Fichier:bd_addr.jpg|300px|thumb|center|Figure 10 : BD_ADDR]]
 +
 +
De plus, il est important de comprendre quelles sont les limitations des Sniffers Bluetooth. Lors de l'interception d'un paquets de données BLE envoyé de l'esclave au maître par exemple, il est possible que le paquet soit vu correctement par le Sniffer, mais le maître peut décoder ce paquet différemment.
 +
 +
====Capture de paquets de données BLE provenant de la communication entre le bracelet connecté et mon smartphone====
 +
 +
J'ai tenté plusieurs fois de capturer des paquets BLE sous Wireshark, mais généralement je n'arrivais à caputurer que des paquets d'Advertising qui ne me sont pas d'une grande utilité étant donné que je chreche à récupérer des paquets de données. A un moment j'ai pu constater la réception d'un paquet de type CONNECT_REQ suivi uniquement de packets de données de différents types. D'après mes recherches à ce sujet sur internet, il est bien nécessaire de capturer le paquet CONNECT_REQ pour que Ubertooth puisse suivre la connection et récupérer les paquets de données. Cependant, il a trois canaux d'Advertising sur lesquels ce paquet peut être envoyé, or Ubertooth ne peut écouter que sur un cannal à la fois, ce qui laisse une chance sur trois de capturer le paquet.
 +
 +
[[Fichier:paquets_data.png|1000px|thumb|center|Figure 11 : Réception de paquets de données sous Wireshark]]
 +
 +
[[Fichier:CONNECT_REQ.png|500px|thumb|center|Figure 12 : Capture du paquet CONNECT_REQ sous Wireshark]]
 +
 +
Le paquet CONNECT_REQ envoyé par le maître à l'esclave (ici le maître est mon smartphone, et l'esclave est le bracelet) lui permet de lui communiquer différents paramètres, notament ceux nécessaires à l'établisssemnt de la connection entre eux. La requête de connexion doit être approuvée par l'esclave pour que le processus de connexion puisse continuer. Les paramètres de connexion qu'on retouve dans ce paquet sont les suivants :
 +
* '''Intervalle de connexion''' (Connection interval) : temps entre deux événments de connexion (7,5ms à 4s)
 +
* '''Latence de l'escalve''' (Slave latency) : nombre d'événements de connexion qu'un esclave peuvent choisir de passer sans risquer une déconnexion
 +
* '''Connection supervision timeout''' : temps après lequel la connexion est considérée comme perdue entre la réception de deux paquets de données
 +
* '''Tâble''' des différents canaux de données utilisés et non utilisés (Channel map)
 +
* '''Hop''' : valeur pour le calcul du saut de fréquence entre les canaux : ''channel = (current_channel + hop) mod 37''
 +
 +
====Utilisation de Crackle pour décrypter les paquets BLE====
 +
 +
Le package crackle permet de trouver la clé de cryptage utilisée pour la communication Bluetooth Low Energy et donc de décoder les paquets de données cryptés. Il exploite une faille de sécurité dans le mécanisme d'appairage des périphériques BLE. Crakle trouve la clé à six chiffres dite TK (Temporary Key), qui lui permet permet ensuite de trouver les autres clés utilisées après appairage. La clé LTK (Long-Term Key) est généralement echangée après l'appairage, et est utilisée pour crypter les communications entre le maître et l'esclave. Pour utilser Crackle, il faut avoir préalablement captué des paquets cryptés sous Wireshark et enregistrer la capture en .pcap. La fichier doit contenir des requêtes du type LL_ENC_REQ et LL_ENC_RSP pour qu'il puisse décrypter les paquets. La commande est la suivante sous linux :
 +
 +
crackle -i input.pcap -o decrypted.pcap
 +
 +
input.pcap contient les paquets cryptés capturés et decrypted.pcap contient les paquets decryptés après l'opération.
 +
 +
On peut voir ci-dessous ce qu'affiche la console après avoir utilisé la commande crackle sur un fichier .pcap contenant des paquets de données que j'ai capturé avec wireshark en appairant le bracelet connecté à mon smartphone. On peut voir les clés TK (000000) et LTK permettant de décrypter les 14 paquets chiffrés détectés.
 +
 +
[[Fichier:crackle.png|500px|thumb|center|Figure 13 : Utilisation de Crackle]]
 +
 +
Une fois que les paquets ont été décryptés par Crackle, il suffit d'ouvrir le fichier .pcap généré avec Wireshark pour les voir. On remarque que les paquets chiffrés sont les paquets signalés par l'appelation "bytesL2CAP Fragment" avant décryptage et que les paquets sont cryptés dés que le paquet LL_START_ENC_REQ est reçu.
 +
 +
[[Fichier:paquets_crackle.png|1400px|thumb|center|Figure 14 : Paquets chiffrés à gauche et décryptés par Crackle à droite]]
 +
 +
 +
[[Media:Paquets_Nabu_X.zip|Fichiers pcap contenant les paquets capturés avant et après déchiffrement]]
 +
 +
====Bilan de la deuxième semaine====
 +
 +
Lors de cette deuxième semaine, j'ai pu capturer des paquets de données BLE provenant de la communication entre mon bracelet connecté et mon smartphone. Ainsi j'ai mieux compris comment fonctionne le module Ubertooth One : il sniffe tout d'abord les paquets d'avertising en alternant l'écoute entre les troix canaux d'advertising (37, 38 et 39). Dés qu'un paquet CONNECT_REQ est capturé, il a alors les informations nécessaires pour pouvoir capturer les paquets de données qui vont suivre. En effet le module Ubertooth One n'écoute que sur un canal à la fois, il lui faut donc connaître les sauts de fréquences sur les différents canaux pour ne manquer aucun paquet. J'ai aussi pu utiliser crackle pour décrypter les paquets BLE chiffrés. Cependant, j'ai pu remarquer que la réception des paquets de données s'arrête au bout d'un moment et que l'Ubertooth One se remet alors à sniffer les paquets d'advertising. Lors de la troisième semaine je vais devoir essayer de comprendre d'où vient ce problème et de comprendre l'utilité des paquets décryptés.
 +
 
===Semaine 3===
 
===Semaine 3===
 +
 +
====Sécurité des objets connectés BLE====
 +
 +
D'après des articles que j'ai pu lire sur internet, la sécurité des objets connectés BLE est aujourd'hui un réel problème. Dans la plupart des cas, les mécanismes de sécurité proposés par le protocole Bluetooth Low Energy ne sont pas bien implémentés par les fabricants d'appareils connectés, la sécurité n'est visiblement pas leur priorité. Une faille importante de sécurité a par exemple été découverte sur le bracelet connecté Nike Fuel Band. Le système d'autentification est vulnérable, n'importe qui peut se connecter à l'appareil, il possible de lire et d'écrire dans la mémoire interne de l'appareil.
 +
 +
[http://www.01net.com/actualites/espionner-les-objets-connectes-c-est-facile-grace-au-bluetooth-le-655726.html Espionner les objets connectés, c'est facile grâce au Bluetooth LE ]
 +
 +
[https://www.evilsocket.net/2015/01/29/nike-fuelband-se-ble-protocol-reversed/ Nike+ FuelBand SE BLE Protocol Reversed]
 +
 +
====Utilisation des deux modes de capture de l'Ubertooth One====
 +
 +
L'Ubertooth One a deux modes de fonctionnement :
 +
* Un mode "Connection Following" qui sniffe les connexions quand elles s'établissent :
 +
ubertooth-btle -f
 +
* Un mode "Promiscuous Mode" qui sniffe les connexions déjà établies :
 +
ubertooth-btle -p
 +
 +
Jusqu'a présent, je n'ai utilisé que le mode "Connection Following" qui écoute sur les canaux d'avertising et attend la réception d'un paquet de connexion CONNECT_REQ pour suivre la connexion, et donc l'envoi de paquets de données qui vont suivre. Il existe aussi un mode "Promiscous Mode" que je n'ai pas encore testé. Dans ce mode, on choisit d'abord un canal de données favori :
 +
ubertooth-util -c2404
 +
On peut aussi ajuster la valeur du "squelch" (sensibilité du récepteur) :
 +
ubertooth-util -z-50
 +
On lance ensuite la capture des paquets :
 +
ubertooth-btle -p
 +
Quand l'Ubertooth One a localisé l'access address, il se met à la suivre. Les packets de données sont alors reçus. Je ne peux cependant pas décrypter les paquets reçus à l'aide de crackle car je ne capture pas les paquets CONNECT_REQ, LL_ENC_REQ et LL_ENC_RSP. Ainsi il est difficile de comprendre à quoi correspondent les paquets reçus.
 +
 +
====Utilisation d'une plateforme de développement avec module BLE====
 +
 +
Afin d'aller plus loin dans la compréhension du protocole BLE, M. Vantroys m'a fourni une plateforme de développement NUCLEO-F401RE de chez STMicroelectronics. Cet plateforme intégre un microcontôleur ARM Cortex-M4 32 bits. On peut ajouter des modules sur cette plateforme de la même façon que pour l'Arduino Uno avec lequel il est d'ailleurs compatible. L'extension [http://www.st.com/en/ecosystems/x-nucleo-idb04a1.html X-NUCLEO-IDB04A1] ajoutée a la plateforme Nucleo permet de mener des expérimentation sur le protocle Bluetooth Low Energy.
 +
 +
[[Fichier:NUCLEO-F401RE.jpg|400px|thumb|center|Figure 15 : Plateforme de développement NUCLEO-F401RE et extension X-NUCLEO-IDB04A1 STMicroelectronics]]
 +
 +
====Prise en main de la plateforme Nucleo====
 +
 +
Afin de prendre en main la plateforme Nucleo et son extension BLE à ma disposition, j'ai téléchargé le package [http://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-expansion-software/x-cube-ble1.html X-CUBE-BLE1] sur le site internet de STMicroelectronics. Ce package contient les drivers nécessaires au pilotage de l'extension BLE ainsi que des exemples de programmes. Le fichier SensorDemo_F401RE.bin (.../STM32CubeExpansion_BLE1_V2.8.0/Projects/Multi/Applications/SensorDemo/Binary/STM32F401RE-Nucleo) contient un programme qui permet d'envoyer les informations des capteurs de la carte Nucleo à un smartphone via l'application Android [https://play.google.com/store/apps/details?id=com.st.blunrg&hl=fr BlueNRG]. Il est possible de faire tourner un cube 3D à l'écran du smartphone en appuyant sur le bouton B1 de la plateforme Nucleo ou encore d'afficher la température, le taux d'humidité, la pression atmosphérique et la puissance du signal en dBm.
 +
 +
====Précisions concernant le Bluetooth Attribute Protocol (ATT)====
 +
 +
Les paquets de données BLE que je reçois sous wireshark sont de type ATT. Je me suis renseigné sue ce protocole afin d'analyser les paquets de données.
 +
 +
Le protocole BLE contient différentes couches :
 +
* La couche GATT (Generic Attribute Profile) définit le protocole de transfert entre deux appareils BLE.
 +
* La couche ATT (Attribute Protocol) définit le protocole de transfert des données.
 +
* La couche L2CAP (Logical Link Control and Adaptation Protocol) est responsable de la qualité du service.
 +
* La couche LL (Link Layer) garantit le bon transfert et l'intégrité des données.
 +
 +
[[Fichier:couches_BLE.png|600px|thumb|center|Figure 17 : Couches du protocole BLE]]
 +
 +
Dans un paquet de données, la partie "Data" est constituée de l'en-tête L2CAP et des données ATT. Cette deuxième partie est composée de :
 +
* L'OP-code qui indique le type d'opération ATT : Write Command, Notification, Read Response, etc.
 +
* L'Attribute Handle
 +
* Les données
 +
 +
[[Fichier:trames.png|600px|thumb|center|Figure 18 : Détail des trames de données BLE]]
 +
 +
====Bilan de la troixième semaine====
 +
 +
Lors de cette troixième semaine, j'ai pu tester le "Promiscuous Mode" de l'Ubertooth One et constater que ce mode ne me permet malheureusement pas d'obtenir des paquets de données exploitables pour le bracelet connecté. J'ai aussi pu prendre en main la plateforeme de développement BLE Nucleo qui me permettra d'aller plus loin dans l'interprétation des paquets de données reçus.
 +
 
===Semaine 4===
 
===Semaine 4===
 +
 +
====Capture de paquets avec la plateforme Nucleo et son extension BLE====
 +
 +
=====Identification des services GATT=====
 +
 +
L'application SensorDemo installée sur la plateforme Nucleo crée quatre services GATT :
 +
* Accéléromètre (Accelerometer service)
 +
** Détection de chute libre (Free-fall detection)
 +
** Valeurs d'accélération (Directional acceleration value characteristic)
 +
* Environnement (Environmental Service)
 +
** Température (Temperature data characteristic)
 +
** Pression atmosphérique (Pressure data characteristic)
 +
** Humidité (Humidity data characteristic)
 +
* Date (Time service)
 +
* LED (LED Service)
 +
 +
Il n'y a cependant aucun capteur sur la plateforme Nucleo, les données sont simulées.
 +
 +
 +
=====Capture de paquets de type Read Request et Read Response=====
 +
 +
J'ai pu capturer des paquets de données de type Read Request qui sont envoyés par la smartphone à la plateforme afin de demander la lecture des valeurs environnementales (température, pression et humidité de l'air). La capture de ce paquet par l'Ubertooth One est généralement suivie de la réception de paquets du type Read Response contenant la valeur demandée. Cependant, la réception des paquets semble partielle, les données s'actualisent parfois sur l'application sans que des paquets ne soient capturés par l'Ubertooth One.
 +
 +
[[Fichier:read_req.png|500px|thumb|center|Figure 19 : Paquet Read Request]]
 +
[[Fichier:temp.png|500px|thumb|center|Figure 20 : Paquet Read Response avec valeur de température (13 = 27,5 °C)]]
 +
 +
[[Media:Paquets_Nucleo.zip|Fichier pcap contenant les paquets capturés]]
 +
 
===Semaine 5===
 
===Semaine 5===
 +
 +
Cette semaine :
 +
* Absence du mardi au jeudi cause à cause d'un problème de santé (certificat médical)
 +
* Travail à la maison :
 +
** Rédaction du rapport (première partie sur le contexte du stage)
 +
** Préparation des diapos pour la soutenance en vue de la présentation du sujet de stage devant l'équipe 2XS comme entraînement avant la soutenance
 +
* Vendredi : présentation du travail effectué devant l'équipe 2XS
 +
 
===Semaine 6===
 
===Semaine 6===
 +
 +
* Corrections apportés au niveau des slides de présentation
 +
* Rédaction du rapport de stage
 +
 +
==Bilan du stage==
 +
 +
Le Bluetooth Sniffing est un type d’attaque passive qui permet d’écouter les communications entre deux appareils Bluetooth. Le sniffing a été rendu plus simple avec l’apparition du Bluetooth Low Energy qui simplifie le protocole. De ce fait les objets connectés Bluetooth sont particulièrements vulnérables à ce type d’attaque. Les mécanismes de sécurité proposées par le protocole Bluetooth Low Energy tels que le chiffrement des données sont souvent mal ou non implémentés par les constructeurs de ce type d’objets. De plus, même bien implémenté, le chiffrement des données est vulnérable au sniffing à cause de la transmission en clair de données pour le chiffrement à l’appairage. Le codage de l’information par saut de fréquence et la nécessité de capturer les paquets envoyés à l’appairage constituent alors les derniers remparts au sniffing. La version 4.2 du Bluetooth vise à renforcer la sécurité du protocole avec un nouveau chiffrement à l’appairage et une fonctionnalité LE Privacy qui empêche, quant à elle, de suivre un utilisateur par l’intermédiaire de son objet connecté Bluetooth.
 +
Ce stage m’a permi de découvrir le monde de la recherche, secteur dans lequel je n’avais jamais évolué n’ayant fait que des stages en entreprise. J’ai pu observer le fonctionnement d’un institut de recherche au sein d’une équipe qui travaille sur le développement de systèmes embarqués, domaine particulièrement en adéquation avec ma formation d’IMA 4 SC. J’ai pu approfondir mes connaissances sur le Bluetooth, sujet sur lequel j’avais assez peu de connaissances. Même si je n’envisage pas de faire de la recherche, le développement de système embarqués m'intéresse tout particulièrement pour l’avenir.
  
 
==Bibliographie==
 
==Bibliographie==

Version actuelle datée du 23 juin 2017 à 09:36

Sommaire

Description du stage

Dans le cadre de ma quatrième année d'études en Informatique, Microélectronique et Automatique, je dois effecuer un stage ingénieur de six semaines minimum. J'ai choisi d'effectuer mon stage à L'IRCICA (Institut de Recherche sur les Composants logiciels et matériels pour l’Information et la Communication Avancée) à Villeneuve d'Ascq au sein de l'équipe CRIStAL 2XS. L'objectif de mon stage est d'évaluer les attaques sur le protocole bluetooth. Pour cela, je dispose d'un module Ubertooth One.

Bluetooth logo.png

Avancement du Stage

Semaine 1

Prise en main du module Ubertooth One

Le module Ubertooth one est une plateforme open source destinée aux expérimentations sur le protocole Bluetooth. Le module comprend :

  • un microcontrôleur LPC175x ARM Cortex-M3
  • un module RF front end CC2591
  • un module de transmission sans fil CC2400
  • un port USB-A 2.0 permettant de le connecter sur un ordinateur
  • Un connecteur RP-SMA RF destiné à connecter une antenne Bluetooth

Il permet d'envoyer et de recevoir des paquets à 2,4 GHz, qui est la fréquence du Bluetooth, mais aussi de voir le traffic Bluetooth en temps réel en mode moniteur. L'appareil est comparable à un module Bluetooth de classe 1, c'est à dire qu'il a une puissance maximale de 100 mW (20 dBm) et une portée de 100 mètres sans obstacles.

Figure 1 : Module Ubertooth One et son antenne

Schematic de l'Ubertooth One

Installation des packages Ubertooth One

Le projet Ubertooth étant open source, l'intégralité du code nécessaire à l'utilisation du module est disponible librement sur Git. J'ai commencé par installer les différents packages nécessaires.

1) Tout d'abord : 

sudo apt-get install cmake libusb-1.0-0-dev make gcc g++ libbluetooth-dev \
pkg-config libpcap-dev python-numpy python-pyside python-qt4

2) Installation de libbtbb : 

sudo ldconfig

wget https://github.com/greatscottgadgets/libbtbb/archive/2017-03-R2.tar.gz -O libbtbb-2017-03-R2.tar.gz
tar xf libbtbb-2017-03-R2.tar.gz
cd libbtbb-2017-03-R2
mkdir build
cd build
cmake ..
make
sudo make install

3) Installation des outils Ubertooth : 

wget https://github.com/greatscottgadgets/ubertooth/releases/download/2017-03-R2/ubertooth-2017-03-R2.tar.xz -O ubertooth-2017-03-R2.tar.xz
tar xf ubertooth-2017-03-R2.tar.xz
cd ubertooth-2017-03-R2/host
mkdir build
cd build
cmake ..
make
sudo make install

4) Installation de Wireshark 

sudo apt-get install wireshark wireshark-dev libwireshark-dev cmake
cd libbtbb-2017-03-R2/wireshark/plugins/btbb
mkdir build
cd build
cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/wireshark/libwireshark3/plugins ..
make
sudo make install

sudo apt-get install wireshark wireshark-dev libwireshark-dev cmake
cd libbtbb-2017-03-R2/wireshark/plugins/btbredr
mkdir build
cd build
cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu/wireshark/libwireshark3/plugins ..
make
sudo make install

5) Installation de Kismet 

sudo apt-get install libpcap0.8-dev libcap-dev pkg-config \
build-essential libnl-dev libncurses-dev libpcre3-dev \
libpcap-dev libcap-dev
wget http://www.kismetwireless.net/code/kismet-2011-03-R2.tar.gz
tar xf kismet-2011-03-R2.tar.gz
sudo mv kismet-2011-03-R2 /usr/src/kismet
ln -s ../ubertooth-2012-10-R1/host/kismet/plugin-ubertooth /usr/src/kismet
cd /usr/src/kismet
sudo ./configure
sudo make && sudo make plugins
sudo make suidinstall
sudo make plugins-install

Recherches sur le protocole Bluetooth

Généralités

Le Bluetooth est un standard de communication permettant l'échange bidirectionnel de données à très courte distance en utilisant des ondes radio UHF sur une bande de fréquence de 2,4 GHz. Son objectif est de simplifier les connexions entre les appareils électroniques en supprimant des liaisons filaires.

Historique
  • 1994 : création par le fabricant suédois Ericsson.
  • 1999 : sortie de la version 1.0 et du premier téléphone Bluetooth.
  • 2004 : sortie de la version 2.0 avec un meilleur débit (passage de 1 à 3 Mb/s).
  • 2009 : sortie de la version 3.0.
  • 2010 : sortie de la version 4.0 plus performante et moins gourmande en énergie. Cette nouvelle génération apparaît comme une révolution et permet une large démocratisation d'appareils connectés en tout genre.
  • 2016 : sortie de la version 5 avec un débit théorique jusqu'a 2 Mb/s et rayon d'action jusqu'a 240 mètres.
Couche radio

La couche radio (la couche la plus basse) est gérée au niveau matériel. C'est elle qui s'occupe de l'émission et de la réception des ondes radio. Elle définit les caractéristiques telles que la bande de fréquence et l'arrangement des canaux, les caractéristiques du transmetteur, de la modulation, du récepteur. Le système Bluetooth opère dans les bandes de fréquences ISM (Industrial, Scientific and Medical) 2,4 GHz dont l'exploitation ne nécessite pas de licence vu la faible puissance d'émission et le risque faible d'interférences. Cette bande de fréquences est comprise entre 2 400 et 2 483,5 MHz. Différents types de modulations peuvent être utilisées par l'émetteur : PSK à 2, 4 ou 8 symboles. Le Bluetooth utilise 79 canaux numérotés de 0 à 78 séparés de 1 MHz. Le codage de l'information se fait par sauts de fréquence. Il existe 3 classes de modules Bluetooth sur le marché caractérisant leur puissance et leur portée :

  • Classe 1 : 100 mW (20 dBm), 100 mètres
  • Classe 2 : 2,5 mW (4 dBm), 10 à 20 mètres
  • Classe 3 : 1 mW (0 dBm), quelques mètres
Paquets Bluetooth
Forme générale
Code d'accès (Access code) En-tête (Header) Données (Payload)
68/72 bits 54 bits 0 à 2745 bits
Code d'accès (68/72 bits)
Préambule Code (Terminaison)
4 bits 64 ou 68 bits (4 bits)
0101 ou 1010
Permet de détecter le début de la trame
  • CAC (Channel Access Code)
  • DAC (Device Access Code)
  • IAC (Inquiry Access Code)
    • GIAC (Generic IAC)
    • DIAC (Dedicated IAC)
 0101 ou 1010
Permet de détecter la fin de la trame
En-tête (18 bits répétés 3 fois pour garantir la réception = 54 bits)
AMA Type Flow ARQN SEQN HEC
3 bits 4 bits 1 bit 1 bit 1 bit 8 bits
Active Member Address :
Adresse active de l'esclave
  • 0 pour le broadcast
  • 1 à 6 pour le périphérique
  • ID (0000)
  • NULL (0001)
  • POLL (0010)
  • FHS (0011)
  • SCO
  • ACL
 Contrôle de flow pour signaler que la mémoire tampon est pleine Automatic Repeat reQuest sequence Number :
  • ARQN=1 si paquet précédent bien reçu et SEQN=SEQN+1
  • ARQN=0 si paquet précédent pas bien reçu
 SEQuence Number :
Numéro de séquence 		Header Error Control
Types de paquets
  • Paquets de contôle :
    • ID : utilsé pour le paging, la recherche, les réponses. Il est Composé d'un DAC ou IAC.
    • NULL : utilisé pour faire une réponse de retour notamment lors d’une réponse à une requête POLL. Elle informe le maître sur le succès de la transmission. Ne dois pas être acquité.
    • POLL : idem que NULL mais doit être acquité. Il est envoyé par le maître à l’esclave pour l’obliger a répondre même si il n’a rien à dire.
    • FHS (Frequency Hopping Synchronisation) : utilisé pour synchroniser les esclaves lors de la mise en place du piconet.


  • Paquets SCO (liaison à connexion synchrone) :
    • Transmission voix temps réel, point à point, bidirectionnelle.
    • Débit à 64 Kbit/s pour être compatible avec les normes d'encodage.
    • Deux types de paquets SCO :
      • HVx (High quality Voice) sans correction d’erreur.
      • DV (Data Voice) porte à la fois les données et la voix. Le ratio voix-données est d’environ 1/3 pour 2/3.
Type Payload (30 octets)
HV1 Audio (10 octets) FEC (20 octets)
HV2 Audio (20 octets) FEC (10 octets)
HV3 Audio (30 octets)
DV Audio (10 octets) Header (1 octet) Données (0 à 9 octets) FEC (2/3 données) CRC (2 octets)


  • Paquets ACL (liaison à connexion asynchrone) :
    • Conçu pour l'échange de données.
    • Broadcast possible.
    • Deux types de paquets ACL :
      • DMx (Data Medium) avec un encodage permettant la correction des erreurs en ligne.
      • DHx (Data High) sans correction d'erreur pour un débit plus élevé.
Type Payload (0 à 343 octets)
DM1 Header (1 octet) Données (0 à 17 octets) FEC (2/3 données) CRC (2 octets)
DM3 Header (2 octet) Données (0 à 121 octets)
DM5 Données (0 à 224 octets)
DH1 Header (1 octet) Données (0 à 27 octets)
DH3 Header (2 octet) Données (0 à 183 octets)
DH5 Données (0 à 339 octets)
Le Bluetooth Low Energy (BLE)

Le Bluetooth Low Energy, Bluetooth 4.0 ou Bluetooth Smart est une alternative au Bluetooth "classique" (version 3.0 et inférieures), avec une réduction du coût et de la consommation en puissance, tout en conservant une portée de communication équivalente. Il cherche à adresser des appareils à faible puissance de calcul, à faible coût de production et dont l’espérance de vie est à maximiser. Le bluetooth "classique" est donc plutôt destiné aux appareils diffusant beaucoup de données comme de l'audio ou de la vidéo alors que le Bluetooth 4.0 est plutôt destiné aux appareils diffusant peu de données tels que les capteurs, objets connectés nécessitant un plus faible débit de données. le Bluetooth Smart Ready est compatible avec les deux types de Bluetooth, il est destiné aux smartphones, ordinateurs, il permet de faire le lien entre les deux standards car ils ne sont pas compatibles.

Figure 2 : Bluetooth 4.0

La technologie Bluetooth Low Energy opère dans la même bande de fréquence (2,4000 - 2,4835 GHz) que le Bluetooth classique, il utilise une modulation par déplacement de fréquence GFSK. 40 canaux physiques sont alloués, espacés de 2 MHz (80 canaux espacés de 1 MHz pour le Bluetooth "classique"). Trois d'entre eux sont des canaux d'advertising et les autres sont des canaux de données.

Figure 3 : Canaux physiques du BLE

Les trames BLE sont différentes de de celles du Bluetooth classique décrites ci-dessus. Les format de paquets est unique et il existe deux principaux types de paquets : "Advertising" et "Data", ce qui simplifie le protocole.

Figure 4 : Trames BLE
Canaux Etat Type de PDU Usage
Advertising (37, 38, 39) Advertising ADV_IND Connectable undirected advertising event
ADV_DIRECT_IND Connectable directed advertising event
ADV_NOCONN_IND Broadcast
ADV_SCAN_IND Connectable directed advertising event
Scannable
Scanning ADV_SCAN_REQ Requête
Advertising ADV_SCAN_RSP Réponse
Initiating CONNECT_REQ Envoyé par l'initiateur pour établir une connexion
Data (0 à 36) Data Data PDU. Empty PDU : l'esclave peut répondre avec n'importe quel type de PDU General data
Control Control PDU Control data

Capture de paquets Bluetooth

Principe du "Bluetooth sniffing"

Le module Ubertooth One que j'utilise est un sniffer Bluetooth. Il permet d'intercepter les paquets échangés entre deux appareils Bluetooth appairés. L'un des appareils est le maître (par exemple un smartphone), et l'autre est l'esclave (par exemple une montre connectée). Un Sniffer est donc un dispositif passif qui n'envoie pas de paquets, il observe simplement le trafic.


Figure 5 : Bluetooth Sniffing
Commandes Ubertooth

Différents commandes Ubertooth permettent de récupérer des paquets Bluetooth :

  • ubertooth-rx permet de voir le LAP (Lower Address Part) des différents appareils Bluetooth qui envoient des paquets à proximité de l'Ubertooth One. Le LAP est formé des trois derniers octets de l'adresse MAC bluetooth d'un appareil. On peut aussi voir le canal sur lequel le paquet a été envoyé.
  • ubertooth-btle permet de récupérer les paquets BLE
Analyseur de spectre

Un outil d'analyse specrale est fourni avec Ubertooth. Il permet d'observer en temps réel le spectre fréquentiel entre 2,400 et 2,480 GHz, plage de fréquence utilisée par le WiFi et le Bluetooth. Cet outil ne m'est pas d'une grande utilité vu le grand nombre d'appareils connectés en Bluetooth ou en WiFi dans le labo, qui ne permettent pas d'analyser avec certitude les résulats. Pour ouvrir l'outil d'analyse spectrale : 

ubertooth-specan-ui
Figure 6 : Spectre observé avec l'outil d'analyse spectrale d'Ubertooth
Capture de paquets avec Kismet
Méthode employée

Pour capturer des paquets Bluetooth avec Kismet, il faut suivre la procédure suivante :

  • Ouvrir Kismet en tant que root :
sudo kismet
  • Appuyer sur "Yes" pour démarrer les services Kismet puis "Start"
  • Fermer la fenêtre console : "Close Console Window"
  • Quand la fenêtre "Add sources" apparaît, taper "ubertooth" dans les champs "Intf" et "Name" et appuyer sur "Add"
  • Dans le menu, ouvrir Kismet/Plugins/Select Pluggin...
  • Autoriser le pluggin "ubertooth_ui.so" en appuyant sur espace et fermer
Trames observées

Afin de tester la capture de paquets Bluetooth avec Kismet, je dispose d'une enceinte Bluetooth Nokia Play 360 et de mon smartphone pour envoyer de la musique.

Figure 7 : Captures de trames sur Kismet

Les trames capturées sont enregistrées dans un fichier pcap et peuvent être analysées avec Wireshark.

Capture de paquets BLE avec Wireshark
Méthode employée

Pour capturer des paquets Bluetooth LE sur Wireshark, il faut suivre les instructions suivantes :

  • Ouvrir un pipe en tapant la commande :
mkfifo /tmp/pipe
  • Ouvrir Wireshark en tant que root : 
sudo wireshark
  • Cliquer sur "Capture" -> "Options" puis "Manage Interfaces"
  • Cliquer sur "New" puis taper dans le champ "pipe" :
/tmp/pipe
  • Sauvegarder et fermer puis appuyer sur "Start"
  • Sur un terminal, taper la commande :
ubertooth-btle -f -c /tmp/pipe
Trames observées

Afin de visualiser des trames BLE, j'ai utilisé un bracelet connecté Razer Nabu X. J'ai pu observer différents types de trames sur wireshark.

Figure 8 : Bracelet connecté Razer Nabu X


Figure 9 : Capture de paquets BLE sous Wireshark


Exemples de trames d'advertising observées :

  • Trame SCAN_REQ :
00 00 18 00 93 00 00 00  36 75 0c 00 00 62 09 00

13 f0 af 09 1a 1a 00 00  d6 be 89 8e c3 0c c1 06

c3 f6 5a 63 fb b3 02 30  34 fb 95 b0 3b

On remarque que la trame BLE est encapsulée dans une trame PPI. On voit ensuite les différents éléments de la trame BLE :

  • Access Address: 0x8e89bed6
  • PDU :
    • Header : 0x0cc3
    • Payload :
      • Scanning Address : 63:5a:f6:c3:06:c1
      • Advertising Address : fb:34:30:02:b3:fb
  • CRC : 0xa90ddc


  • Trame SCAN_RSP :
00 00 18 00 93 00 00 00  36 75 0c 00 00 62 09 00

8c 00 b0 09 08 08 00 00  d6 be 89 8e 44 1a fb b3

02 30 34 fb 06 09 4e 61  62 75 58 0c ff 01 02 01

32 06 fb 34 30 02 b3 fb  8c 8b 06

On remarque que la trame BLE est encapsulée dans une trame PPI. On voit ensuite les différents éléments de la trame BLE :

  • Access Address: 0x8e89bed6
  • PDU :
    • Header : 0x441a
    • Payload :
      • Advertising Address : fb:34:30:02:b3:fb
      • Scan Response Data :
        • Device Name :
          • Length : 6 (0x06)
          • Type : Device Name (0x09)
          • Name : NabuX (0x4e61627558)
        • Manufacturer Specific :
          • Length : 12 (0x0c)
          • Type : Manufacturer Specific (0xff)
          • Company ID : Unknown (0x0201)
          • Data : 01 32 06 fb 34 30 02 b3 fb
  • CRC : 0x31d160

Bilan de la première semaine

Lors de cette première semaine, j'ai pu me familiariser avec le Bluetooth standard et Low Energy, installer et utiliser le module Ubertooth One pour capturer des paquets Bluetooth. Cependant, je n'arrive pas à capturer les paquets de données envoyés par le smartphone à l'enceinte Bluetooth, ni ceux envoyés par le bracelet connecté. Je ne capture que des packets de Type "Advertising". D'après mes recherches, il est difficile de capturer les paquets de données Bluetooth mais le module Ubertooth One est la solution la moins chère existant actuellement. Cela est du au fait que le Bluetooth utilise une modulation par saut de fréquence, deux paquets successifs ne sont pas envoyés sur le même canal. Mon travail des prochaines semaines va donc être de trouver comment intercepter les paquets de données.

Semaine 2

Pourquoi est-il difficile de "sniffer" les paquets Bluetooth ?

D'après mes recherches sur les Sniffers Bluetooth, il est plus facile et moins cher de capturer les paquets Bluetooth Low Energy (LE) que les packets du Bluetooth classique (BR/EDR). Cela est dû à la complexité moindre du protocole BLE et à l'utilisation de la modulation GFSK. En effet, les Sniffers pour capturer les paquets du Bluetooth classique sont chers (environ $25 000 pour capturer tous les types de paquets : BR/EDR/LE) car leur capture et décodage nécessite une grande puissance de calcul en raison de la rapidité avec laquelle ils sont envoyés et des sauts de fréquence (1600 sauts/s, 625 us/paquet). L'Ubertooth One que j'utilise est une des solutions les moins chères du marché (environ 130 €) mais ne permet de capturer que les paquets de données BLE. Le fonctionnalités sont plus limitées pour le Bluetooth Classique :

  • Capture du LAP (Lower Address Part) des paquets transmis qui contient les 24 deniers bits de l’adresse MAC Bluetooth (BD_ADDR) d'un appareil. C'est la seule partie de l'adresse MAC transmise dans les paquets.
  • Capture avancée sous Kismet avec identification de l'UAP (Upper Address Part) qui est constitué des 8 bits qui précédent le LAP dans l'adresse MAC des appareils. Enregistrement des paquets décodés dans un fichier pcapbtbb. Le décodage complet des paquets n'est possible que si l'UAP a été déterminée.
Figure 10 : BD_ADDR

De plus, il est important de comprendre quelles sont les limitations des Sniffers Bluetooth. Lors de l'interception d'un paquets de données BLE envoyé de l'esclave au maître par exemple, il est possible que le paquet soit vu correctement par le Sniffer, mais le maître peut décoder ce paquet différemment.

Capture de paquets de données BLE provenant de la communication entre le bracelet connecté et mon smartphone

J'ai tenté plusieurs fois de capturer des paquets BLE sous Wireshark, mais généralement je n'arrivais à caputurer que des paquets d'Advertising qui ne me sont pas d'une grande utilité étant donné que je chreche à récupérer des paquets de données. A un moment j'ai pu constater la réception d'un paquet de type CONNECT_REQ suivi uniquement de packets de données de différents types. D'après mes recherches à ce sujet sur internet, il est bien nécessaire de capturer le paquet CONNECT_REQ pour que Ubertooth puisse suivre la connection et récupérer les paquets de données. Cependant, il a trois canaux d'Advertising sur lesquels ce paquet peut être envoyé, or Ubertooth ne peut écouter que sur un cannal à la fois, ce qui laisse une chance sur trois de capturer le paquet.

Figure 11 : Réception de paquets de données sous Wireshark
Figure 12 : Capture du paquet CONNECT_REQ sous Wireshark

Le paquet CONNECT_REQ envoyé par le maître à l'esclave (ici le maître est mon smartphone, et l'esclave est le bracelet) lui permet de lui communiquer différents paramètres, notament ceux nécessaires à l'établisssemnt de la connection entre eux. La requête de connexion doit être approuvée par l'esclave pour que le processus de connexion puisse continuer. Les paramètres de connexion qu'on retouve dans ce paquet sont les suivants :

  • Intervalle de connexion (Connection interval) : temps entre deux événments de connexion (7,5ms à 4s)
  • Latence de l'escalve (Slave latency) : nombre d'événements de connexion qu'un esclave peuvent choisir de passer sans risquer une déconnexion
  • Connection supervision timeout : temps après lequel la connexion est considérée comme perdue entre la réception de deux paquets de données
  • Tâble des différents canaux de données utilisés et non utilisés (Channel map)
  • Hop : valeur pour le calcul du saut de fréquence entre les canaux : channel = (current_channel + hop) mod 37

Utilisation de Crackle pour décrypter les paquets BLE

Le package crackle permet de trouver la clé de cryptage utilisée pour la communication Bluetooth Low Energy et donc de décoder les paquets de données cryptés. Il exploite une faille de sécurité dans le mécanisme d'appairage des périphériques BLE. Crakle trouve la clé à six chiffres dite TK (Temporary Key), qui lui permet permet ensuite de trouver les autres clés utilisées après appairage. La clé LTK (Long-Term Key) est généralement echangée après l'appairage, et est utilisée pour crypter les communications entre le maître et l'esclave. Pour utilser Crackle, il faut avoir préalablement captué des paquets cryptés sous Wireshark et enregistrer la capture en .pcap. La fichier doit contenir des requêtes du type LL_ENC_REQ et LL_ENC_RSP pour qu'il puisse décrypter les paquets. La commande est la suivante sous linux : 

crackle -i input.pcap -o decrypted.pcap

input.pcap contient les paquets cryptés capturés et decrypted.pcap contient les paquets decryptés après l'opération.

On peut voir ci-dessous ce qu'affiche la console après avoir utilisé la commande crackle sur un fichier .pcap contenant des paquets de données que j'ai capturé avec wireshark en appairant le bracelet connecté à mon smartphone. On peut voir les clés TK (000000) et LTK permettant de décrypter les 14 paquets chiffrés détectés.

Figure 13 : Utilisation de Crackle

Une fois que les paquets ont été décryptés par Crackle, il suffit d'ouvrir le fichier .pcap généré avec Wireshark pour les voir. On remarque que les paquets chiffrés sont les paquets signalés par l'appelation "bytesL2CAP Fragment" avant décryptage et que les paquets sont cryptés dés que le paquet LL_START_ENC_REQ est reçu.

Figure 14 : Paquets chiffrés à gauche et décryptés par Crackle à droite


Fichiers pcap contenant les paquets capturés avant et après déchiffrement

Bilan de la deuxième semaine

Lors de cette deuxième semaine, j'ai pu capturer des paquets de données BLE provenant de la communication entre mon bracelet connecté et mon smartphone. Ainsi j'ai mieux compris comment fonctionne le module Ubertooth One : il sniffe tout d'abord les paquets d'avertising en alternant l'écoute entre les troix canaux d'advertising (37, 38 et 39). Dés qu'un paquet CONNECT_REQ est capturé, il a alors les informations nécessaires pour pouvoir capturer les paquets de données qui vont suivre. En effet le module Ubertooth One n'écoute que sur un canal à la fois, il lui faut donc connaître les sauts de fréquences sur les différents canaux pour ne manquer aucun paquet. J'ai aussi pu utiliser crackle pour décrypter les paquets BLE chiffrés. Cependant, j'ai pu remarquer que la réception des paquets de données s'arrête au bout d'un moment et que l'Ubertooth One se remet alors à sniffer les paquets d'advertising. Lors de la troisième semaine je vais devoir essayer de comprendre d'où vient ce problème et de comprendre l'utilité des paquets décryptés.

Semaine 3

Sécurité des objets connectés BLE

D'après des articles que j'ai pu lire sur internet, la sécurité des objets connectés BLE est aujourd'hui un réel problème. Dans la plupart des cas, les mécanismes de sécurité proposés par le protocole Bluetooth Low Energy ne sont pas bien implémentés par les fabricants d'appareils connectés, la sécurité n'est visiblement pas leur priorité. Une faille importante de sécurité a par exemple été découverte sur le bracelet connecté Nike Fuel Band. Le système d'autentification est vulnérable, n'importe qui peut se connecter à l'appareil, il possible de lire et d'écrire dans la mémoire interne de l'appareil.

Espionner les objets connectés, c'est facile grâce au Bluetooth LE

Nike+ FuelBand SE BLE Protocol Reversed

Utilisation des deux modes de capture de l'Ubertooth One

L'Ubertooth One a deux modes de fonctionnement :

  • Un mode "Connection Following" qui sniffe les connexions quand elles s'établissent :
ubertooth-btle -f
  • Un mode "Promiscuous Mode" qui sniffe les connexions déjà établies :
ubertooth-btle -p

Jusqu'a présent, je n'ai utilisé que le mode "Connection Following" qui écoute sur les canaux d'avertising et attend la réception d'un paquet de connexion CONNECT_REQ pour suivre la connexion, et donc l'envoi de paquets de données qui vont suivre. Il existe aussi un mode "Promiscous Mode" que je n'ai pas encore testé. Dans ce mode, on choisit d'abord un canal de données favori : 

ubertooth-util -c2404

On peut aussi ajuster la valeur du "squelch" (sensibilité du récepteur) : 

ubertooth-util -z-50

On lance ensuite la capture des paquets : 

ubertooth-btle -p

Quand l'Ubertooth One a localisé l'access address, il se met à la suivre. Les packets de données sont alors reçus. Je ne peux cependant pas décrypter les paquets reçus à l'aide de crackle car je ne capture pas les paquets CONNECT_REQ, LL_ENC_REQ et LL_ENC_RSP. Ainsi il est difficile de comprendre à quoi correspondent les paquets reçus.

Utilisation d'une plateforme de développement avec module BLE

Afin d'aller plus loin dans la compréhension du protocole BLE, M. Vantroys m'a fourni une plateforme de développement NUCLEO-F401RE de chez STMicroelectronics. Cet plateforme intégre un microcontôleur ARM Cortex-M4 32 bits. On peut ajouter des modules sur cette plateforme de la même façon que pour l'Arduino Uno avec lequel il est d'ailleurs compatible. L'extension X-NUCLEO-IDB04A1 ajoutée a la plateforme Nucleo permet de mener des expérimentation sur le protocle Bluetooth Low Energy.

Figure 15 : Plateforme de développement NUCLEO-F401RE et extension X-NUCLEO-IDB04A1 STMicroelectronics

Prise en main de la plateforme Nucleo

Afin de prendre en main la plateforme Nucleo et son extension BLE à ma disposition, j'ai téléchargé le package X-CUBE-BLE1 sur le site internet de STMicroelectronics. Ce package contient les drivers nécessaires au pilotage de l'extension BLE ainsi que des exemples de programmes. Le fichier SensorDemo_F401RE.bin (.../STM32CubeExpansion_BLE1_V2.8.0/Projects/Multi/Applications/SensorDemo/Binary/STM32F401RE-Nucleo) contient un programme qui permet d'envoyer les informations des capteurs de la carte Nucleo à un smartphone via l'application Android BlueNRG. Il est possible de faire tourner un cube 3D à l'écran du smartphone en appuyant sur le bouton B1 de la plateforme Nucleo ou encore d'afficher la température, le taux d'humidité, la pression atmosphérique et la puissance du signal en dBm.

Précisions concernant le Bluetooth Attribute Protocol (ATT)

Les paquets de données BLE que je reçois sous wireshark sont de type ATT. Je me suis renseigné sue ce protocole afin d'analyser les paquets de données.

Le protocole BLE contient différentes couches :

  • La couche GATT (Generic Attribute Profile) définit le protocole de transfert entre deux appareils BLE.
  • La couche ATT (Attribute Protocol) définit le protocole de transfert des données.
  • La couche L2CAP (Logical Link Control and Adaptation Protocol) est responsable de la qualité du service.
  • La couche LL (Link Layer) garantit le bon transfert et l'intégrité des données.
Figure 17 : Couches du protocole BLE

Dans un paquet de données, la partie "Data" est constituée de l'en-tête L2CAP et des données ATT. Cette deuxième partie est composée de :

  • L'OP-code qui indique le type d'opération ATT : Write Command, Notification, Read Response, etc.
  • L'Attribute Handle
  • Les données
Figure 18 : Détail des trames de données BLE

Bilan de la troixième semaine

Lors de cette troixième semaine, j'ai pu tester le "Promiscuous Mode" de l'Ubertooth One et constater que ce mode ne me permet malheureusement pas d'obtenir des paquets de données exploitables pour le bracelet connecté. J'ai aussi pu prendre en main la plateforeme de développement BLE Nucleo qui me permettra d'aller plus loin dans l'interprétation des paquets de données reçus.

Semaine 4

Capture de paquets avec la plateforme Nucleo et son extension BLE

Identification des services GATT

L'application SensorDemo installée sur la plateforme Nucleo crée quatre services GATT :

  • Accéléromètre (Accelerometer service)
    • Détection de chute libre (Free-fall detection)
    • Valeurs d'accélération (Directional acceleration value characteristic)
  • Environnement (Environmental Service)
    • Température (Temperature data characteristic)
    • Pression atmosphérique (Pressure data characteristic)
    • Humidité (Humidity data characteristic)
  • Date (Time service)
  • LED (LED Service)

Il n'y a cependant aucun capteur sur la plateforme Nucleo, les données sont simulées.


Capture de paquets de type Read Request et Read Response

J'ai pu capturer des paquets de données de type Read Request qui sont envoyés par la smartphone à la plateforme afin de demander la lecture des valeurs environnementales (température, pression et humidité de l'air). La capture de ce paquet par l'Ubertooth One est généralement suivie de la réception de paquets du type Read Response contenant la valeur demandée. Cependant, la réception des paquets semble partielle, les données s'actualisent parfois sur l'application sans que des paquets ne soient capturés par l'Ubertooth One.

Figure 19 : Paquet Read Request
Figure 20 : Paquet Read Response avec valeur de température (13 = 27,5 °C)

Fichier pcap contenant les paquets capturés

Semaine 5

Cette semaine :

  • Absence du mardi au jeudi cause à cause d'un problème de santé (certificat médical)
  • Travail à la maison :
    • Rédaction du rapport (première partie sur le contexte du stage)
    • Préparation des diapos pour la soutenance en vue de la présentation du sujet de stage devant l'équipe 2XS comme entraînement avant la soutenance
  • Vendredi : présentation du travail effectué devant l'équipe 2XS

Semaine 6

  • Corrections apportés au niveau des slides de présentation
  • Rédaction du rapport de stage

Bilan du stage

Le Bluetooth Sniffing est un type d’attaque passive qui permet d’écouter les communications entre deux appareils Bluetooth. Le sniffing a été rendu plus simple avec l’apparition du Bluetooth Low Energy qui simplifie le protocole. De ce fait les objets connectés Bluetooth sont particulièrements vulnérables à ce type d’attaque. Les mécanismes de sécurité proposées par le protocole Bluetooth Low Energy tels que le chiffrement des données sont souvent mal ou non implémentés par les constructeurs de ce type d’objets. De plus, même bien implémenté, le chiffrement des données est vulnérable au sniffing à cause de la transmission en clair de données pour le chiffrement à l’appairage. Le codage de l’information par saut de fréquence et la nécessité de capturer les paquets envoyés à l’appairage constituent alors les derniers remparts au sniffing. La version 4.2 du Bluetooth vise à renforcer la sécurité du protocole avec un nouveau chiffrement à l’appairage et une fonctionnalité LE Privacy qui empêche, quant à elle, de suivre un utilisateur par l’intermédiaire de son objet connecté Bluetooth. Ce stage m’a permi de découvrir le monde de la recherche, secteur dans lequel je n’avais jamais évolué n’ayant fait que des stages en entreprise. J’ai pu observer le fonctionnement d’un institut de recherche au sein d’une équipe qui travaille sur le développement de systèmes embarqués, domaine particulièrement en adéquation avec ma formation d’IMA 4 SC. J’ai pu approfondir mes connaissances sur le Bluetooth, sujet sur lequel j’avais assez peu de connaissances. Même si je n’envisage pas de faire de la recherche, le développement de système embarqués m'intéresse tout particulièrement pour l’avenir.

Bibliographie

  • Getting Started with Bluetooth Low Energy

Kevin Townsend, Carles Cufi, Akiba & Robert Davidson
O'Reilly Media, 2014

Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=Evaluation_des_attaques_sur_protocole_Bluetooth&oldid=44781 »