Projets étudiants cryptographie et sécurité/Treboux jerome Securite Bluetooth 4X

La sécurité du bluetooth 4.X

Introduction

Le bluetooth est moyen de communication a faible portée ( 10-50m), sur la bande des 2,4GHz ( comme le wifi et les fours a micro-ondes) et offrant un débit de 720Kbps ( pour la version 1) a 3Mbps ( pour les version 2 et plus). On l'utilise surtout pour des services ou des périphérique locaux ( imprimante, claviers, souris, …) La faible portée rend la consommation énergétique peu importante, ce qui permet de l'utilsier sur la plupart des appareils portables ( téléphones, casque, micro, …)

Pour ce qui est de la sécurité, dans les version antérieur a 4.0, on avait juste 3 modes de protection : - Pour ce qui est du 1er mode : tout est ouvert et ne protège pas l'équipement, il est visible par tous et accepte la connexion de tous - Pour le 2nd mode : Une connexion est obligatoire, et les services sont protégés ou pas selon les choix, il existe plusieurs niveaux de protection pour les services, comme ce qui est expliqué ci dessous. - Pour le 3ème mode : Tous les services sont obligatoirement protégés

pour ce qui est de la sécurité des services , il y a 3 niveaux de protection :

- Le niveau 1 qui nécessitent une autorisation et une authentification ( l'autorisation est un niveau de confiance (trust) que seul un administrateur peut avoir ) et l'authentification est le code pin a 4 chiffre qu'on devait écrire quand on voulait s'échanger des fichiers de mobile a mobile. - Le niveau 2 demande seulement une authentification - Et avec le niveau 3 , le service n'a aucune protection.

Voici pour ce qui était fait dans les version antérieur a 4.0 en terme de sécurité

La version 4.0

La version 4.0 est le est le Bluetooth Low Energy ( écrit LE, dans la suite de la page), qui introduit : - Une baisse de consommation ainsi qu'un mode de sommeil qui met en pause l'appareil Bluetooth jusqu’à qu'un signal de réveil. - Une volonté d'amélioration de la sécurité car le Bluetooth était considéré comme facilement attaquable avec les attaques Man In The Middle et beaucoup d'autre ce qui était un problème.

Cette volonté se verra avec la version 4.2 ou la sécurité a été très renforcé

La sécurité de la version 4.2

Pour éviter les attaques les plus courante, il suffit de crypter le message de manière a que seul le destinataire qui a la clé de déchiffrement pourra comprendre.

Donc pour cela, il faut s'échanger les clés de manière a que si il y a une personne qui écoute les échanges elle ne puisse pas les avoir non plus. Pour cela, le Bluetooth LE utilise un algorithme appelé « Elliptic Curve Diffie-Hellman » écrit ECDH dans la suite.

En plus détaillé, le maître (initiator) , va recevoir une demande de connexion par l'esclave ( responder) , cela peut être aussi l'inverse, mais on va voir sur le premier cas.

Après avoir établie une connexion non cryptée et échanger la courbe écliptique $E(a,b,p)$, c'est à dire Échec de l’analyse (erreur de syntaxe): {\displaystyle y² = x³ + ax + b mod p} , l'esclave va faire une « sécurity_request » pour déterminer le niveau de sécurité de la futur connexion cryptée et les services qui lui sera ouvert dépendra de son niveau de sécurité.

Durant le reste de la phase 1, le maitre et l'esclave vont s'échanger des données, la capacité d'interaction entrée/sortie que veut l'esclave, si l'utilisateur veut une protection contre « Man-In-The-Middle », la taille maximum de clé, …

Durant la phase 2, il vont commencer pas se choisir une « Temporary Key (TK) » en fonction des des données échangés plus tot. Cette valeur est un point P sur la courbe ou : « $nP=P+p+...P$  (n fois) où le « + » correspond à la somme de 2 points définie par le symétrique du troisième point d'intersection de la droite définie par les 2 points originaux avec la courbe elliptique. Dans le cas où les deux points à ajouter sont identiques, on considère que la droite qui les joint est la tangente à la courbe elliptique passant par l'un d'entre eux. Un tel point est rationnel. »

Tableau des méthode d'apairage, la clé qui en sera créer, et pour qulle raison choisir la méthode

Méthode d'appairage	Temporary Key (TK)	Protection contre MITM	Notes
Just Works	0 (zero)	NON	Pas d'authentification
Passkey Entry	0 ... 999999 (six nombre decimal) Le reste de la clé est rempli de zéro.	OUI	Authentifier et permet certaines fonctionnalité basique
Out Of Band	Une clé de 128bits	OUI	Authentifier

  Pour un clé de 128bits, on utilise une courbe sur $F_{q}$ , où $q\simeq 2^{256}$.

Après que la TK ait été créé , cela va être au tour de la « Short Temporary Key (STK) » qui va être généré après un certain nombre d'échange décrit ci dessous.

- Tout d'abord chacun de leur coté ils vont généré un nombre aléatoire de 128 bit ( Maître :« Mrand », Esclave : « Srand »)

- Ensuite chacun de leur coté ils vont calculé « Mconfirm » et « Sconfirm » qui est le résultat d'une fonction qui a comme paramètre la TK, leur nombre aléatoire respectif , et des données échangé plus tôt (adresse, type d'adresse, …)

- Une fois calculé, le Maître va envoyé « Mconfirm », une fois reçu, l'esclave va lui envoyé « Sconfirm », qui va lui répondre en lui renvoyant « Mrand », L'esclave va donc vérifier si « Mconfirm » correspond avec la fonction et les même paramètres (dont « Mrand » qu'il vient de recevoir). Si cela correspond, c'est bien la même personne, il lui envoit a son tour « Srand », sinon la communication est coupé. Le maitres fait pareil une fois qu'il a reçus « Srand »

- Une fois qu'ils ont tout les deux vérifier si cela corespondait, ils génèrent tous les deux STK qui est une fonction entre TK, Srand et Mrand

Ils commence ensuite une conversation crypté en utilisant STK comme clé.

Pour ce qui est de la phase 3, de manière cryptés ils vont s'échanger un certain nombre de clé dont la « Long Temporary Key (LTK)» qui va servir a crypté les communication dés que cette échange de clé sera terminé.

Sources

[[1]] [[2]]