Attaque de la phase d’appariement

Ryan et al. ont développé un outil nommé Crackle[124] qui exploite une faille dans le processus d’appariement BLE pour récupérer les valeurs des clés secrètes échangées, à savoir l’IRK ou la LTK et par la suite de déchiffrer les paquets de données collectés (voir 3.1.4). Ubertooth peut être couplé à cet outil en sauvegardant tous les paquets collectés dans un fichier .pcap avec l’argument -c :

# ubertooth-btle -f -c sample.pcap

Il faudra utiliser ce fichier résultat pour retrouver la valeur de la LTK qui va permettre de déchiffrer tous les paquets de données collectés avec l’argument -o :

Dans un contexte de suivi de la mobilité des utilisateurs, les paquets de données BLE ne sont pas construits à partir de l’adresse MAC Bluetooth réelle d’un périphérique contrairement au Bluetooth Classic. De ce fait, il n’est pas possible d’extraire des parties de l’adresse MAC réelle à partir de ces paquets. Cependant, il est probable que d’autres informations contenues dans ces paquets aient une entropie assez forte pour identifier un ou plusieurs périphériques durant la communication. Pour ce faire, il faut absolument récupérer la clé LTK qui va permettre de déchiffrer le contenu de ces paquets.

Un second intérêt de Crackle est qu’il permet d’obtenir l’IRK. Celui-ci pourra être utilisé pour résoudre des adresses privées résolvables.

7.8 Interfaces de programmation applicatives

Bien que similaire par leur nom, la technologie du BLE présente de grandes différences dans sa conception par rapport à sa version classique comme nous l’avons décrit dans les sections précédentes. De ce fait, les concepteurs d’interfaces de programmation se sont adaptés et ont mis à disposition des développeurs une nouvelle interface dédiée au Bluetooth Low Energy. Nous allons exposer dans cette sous-section les méthodes et les contraintes liées aux interfaces de programmation du BLE que peut utiliser un développeur dans le but d’élaborer une application liée au PT.

7.8.1 Permissions

Dans le but d’utiliser toutes les fonctionnalités du BLE lors du développement d’une application, la déclaration des permissions est obligatoire. Le BLE n’échappe pas à cette règle d’autant plus qu’elle traite des informations privées (adresse MAC Bluetooth par exemple) sur l’interface Bluetooth du smartphone auquel l’application sera déployée.

Android Les interfaces de programmation du BLE ont été introduites depuis la version 4.3 d’android. Similairement aux permissions décrites pour sa version classique 7.6.1, la permission BLUETOOTH est nécessaire pour l’utilisation des différentes fonctions essen-tielles du BLE, à savoir l’activation de l’interface Bluetooth, une demande de connexion, l’acceptation d’une connexion entrante mais surtout l’échange de données. De plus, la per-mission BLUETOOTH_ADMIN est utilisée dans la cadre de manipulation des options Bluetooth du smartphone et pour le service de découverte de périphériques à portée.

Annexes : Outils pour le Bluetooth Low Energy 138

Par suite, certaines fonctionnalités de ces interfaces permettent au smartphone d’en-voyer périodiquement des trames de beacon qui utilisent la position géographique ac-tuelle du smartphone. De ce fait, la permission ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION doit être déclarée afin d’en avertir l’utilisateur.

Finalement, le contenu du fichier manifest.xml est quasi-similaire à celui de la version classique du Bluetooth excepté l’ajout d’une ligne spécifiant que l’application utilisera la technologie du BLE :

# <uses-permission android:name="android.permission.BLUETOOTH"/>

# <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>

# <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/> // Spécifie que l’application utilisera le BLE

#<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

iOS L’interface de programmation principale du BLE sous iOS se nomme Core Blue-tooth. Similairement à version classique, la technologie BLE est considérée comme sensible car elle possède des informations privées du smartphone de l’utilisateur. Elle possède donc une permission privée à déclarer dans le fichier info.plist.

De plus, pour renseigner que l’utilisateur que l’application va utiliser les fonctionnalités BLE, la ligne de code suivante doit être spécifier dans le fichier de configuration de l’application (info.plist ) comme suit :

#<key>UIRequiredDeviceCapabilities</key> #<array>

# <string>bluetooth-le</string> #</array>

Par suite, certaines fonctionnalités liées au BLE utilisent la position géographique du smartphone qui est considérée comme une information sensible. De ce fait, pour manipu-ler ce type de donnée, une permission doit être obtenue de la part de l’utilisateur. Celle ci doit être décrite suivant le format suivant :

<key>NSLocationWhenInUseUsageDescription</key> <string>...Detailed reason...</string>

<key>NSLocationAlwaysUsageDescription</key> <string>...Detailed reason...</string>

Depuis iOS8, la description détaillé dans le fichier .plist est obligatoire sinon l’application ne se lancera pas. La clé NSLocationWhenInUseUsageDescription spécifique que l’accès aux données géographiques sera fera uniquement lorsque l’application sera exécuté en activité principale. La seconde (NSLocationAlwaysUsageDescription) permet d’accéder a ce type de donné même lorsque l’application s’exécute en arrière-plan. Pour apporter un contrôle plus fun à l’utilisateur, ce dernier pourra refuser l’accès aux données géo-graphiques via le BLE à l’application à tout moment en se rendant dans les paramètres général du smartphone.