L’utilisation d’un ordinateur portable sous Linux ou des smartphones iOS et Android rootés permet à BLEB de rester indétectable car il n’utilise que des scans passif sans perte de précision. En effet, le temps moyen requis pour compléter un scan actif est 2 à 4 fois supérieur au temps moyen requis pour détecter passivement un utilisateur. Pour le moment, il n’y a pas le besoin d’exploiter des informations supplémentaires qui peuvent être obtenues par les paquets de requêtes. Le point négatif est que le déploiement de tels nœuds BLEB requiert plus d’effort pour un adversaire vu qu’il y a beaucoup moins de smartphones rootés ou d’ordinateurs sous Linux que de smartphones non-modifiés.
Les smartphones Android non-modifiés avec une application ou une bibliothèque com-promises par un adversaire permet à BLEB d’effectuer un suivi des utilisateurs à grande échelle. La proportion des utilisateurs qui vont être suivis pourrait être uniquement li-mité par le taux de pénétration des périphériques BLE mal-configurés (ceux qui utilisent un identifiant (MAC ou UUID ) qui ne change pas au cours du temps). Le coté négatif
est que le comportement des ces nœuds BLEB peut éventuellement être détecté car les interfaces de programmation applicatives sous Android ne permettent de faire que des scans actifs. Un autre aspect négatif de ce type de scan est qu’il réduit la probabilité de détection lorsque les contacts sont limitées dans le temps.
5.8 Conclusion et recommandations
Nous avons étudié dans cette section la possibilité de suivre les déplacements des utilisa-teurs sur une plus grande échelle via l’utilisation d’un botnet BLE installé sur le smart-phones des utilisateurs. Avec un coût de déploiement peu élevé de la part d’un attaquant, cette méthode présente un potentiel risque pour les données privées des utilisateurs. Pour s’en protéger, les utilisateurs de smartphones et d’objets connectés BLE est d’une part la désactivation de l’interface Bluetooth lorsque qu’ils ne sont pas en utilisation et d’autre part, de conserver une connexion entre le smartphone et l’objet connecté pour éviter que ce dernier émette périodiquement des ADV_PKT qui pourraient divulguer sa présence aux autres membres du botnet. Il faut néanmoins noter que lors d’une connexion, l’Access Address (AA) reste inchangé jusqu’à la prochaine connexion. Un attaquant qui aurait capté l’AA d’une connexion peut donc suivre l’utilisateur. De manière similaire il faut s’assurer que les données échangées soient chiffrées car celles-ci pourraient contenir des identifiants et autres données sensibles.
Plus en amont, lors de l’installation d’applications, les utilisateurs doivent vérifier les permissions demandées par ladite application et s’assurer qu’aucune incohérence existe. Par exemple, une application qui propose de faire des achats en ligne et qui demande la permission d’interagir avec l’interface Bluetooth est potentiellement suspecte. De plus, il faudrait avoir le réflexe de surveiller la consommation énergétique générée par chaque application installée, une consommation anormalement élevée pourrait être synonyme de réveil périodique du téléphone pour des opérations de scans ou la réception d’intents de scans BLE auxquels l’application se serait abonnée.
En outre, il conviendrait aux utilisateurs de n’acheter que des périphériques qui sont cor-rectement configurés i.e. qui utilisent des adresses privées pour empêcher qu’un identifiant unique soit continuellement envoyé en clair sur le réseau. Pour le processus d’appariement avec cette technologie, il ne faudrait pas s’appairer avec n’importe quel périphérique qui pourrait stocker les clés secrètes (notamment l’IRK ) donnant ainsi la possibilité d’outre-passer la protection des adresses privées. Par suite, pour les constructeurs, la principale recommandation est l’utilisation de toutes les fonctionnalités de sécurité proposées par la norme Bluetooth. En effet, chaque objet BLE embarqué par un utilisateur doit utiliser des adresses privées résolvables pour éviter que ce dernier soit détectable dans la plupart
Contributions 92
des cas. Enfin, les OS mobiles ont déjà pris de bonnes initiatives en bannissant la pos-sibilité de réaliser des scans passifs par le biais des interfaces de programmation actives et certains ont bloqué les scans actifs en BLE lorsque l’application tourne en tâche de fond. La recommandation serait de limiter la possibilité pour les applications de cloner les ADV_PKT émis par un objet connecté et de les retransmettre sur les canaux afin de reproduire leur comportement.
Crowd Localization
6.1 Contexte
L’utilisation du Bluetooth Low Energy (BLE) est récemment devenu populaire dans les services de crowd-localization, c’est à dire la localisation d’objets collaborative par une foule équipée de smartphones d’une même communauté d’utilisateurs. Dans ce chapitre, nous mettons en évidence la menace que constituent de tels services et nous proposons une architecture de crowd-localization qui garantie le respect de la vie privée des utilisateurs.
Les applications de crowd-localization font appel à tous leurs utilisateurs pour effectuer des scans BLE périodiquement et de détecter les périphériques BLE à portée. L’utili-sateur exécute une application sur son smartphone, laquelle va périodiquement envoyer la liste des périphériques qu’il a détecté autour de lui vers un serveur central. Les uti-lisateurs peuvent ensuite se connecter au serveur pour obtenir la localisation de leurs périphériques. Sur la plupart des services, pour obtenir la position de son objet, il faut le déclarer comme perdu. Cela permet à un utilisateur de suivre la mobilité de ses péri-phériques sans payer de carte SIM dédiée ou se soucier d’un quelconque réseau auquel l’objet doit se connecter.
Nous montrons que ces périphériques utilisent une adresse publique ou une adresse aléa-toire statique pour identifier un utilisateur. Ces adresses sont envoyées au serveur de la compagnie sans modification, accompagnées de la position GPS et de l’identité du smartphone qui a collecté l’information.
Un tel comportement fait courir un risque inutile aux utilisateurs car la mobilité de ses objets (« a priori » la sienne) peut être suivie par la compagnie qui fournit le service. Étant donné que le service nécessite que les objets connectés utilisent une adresse publique ou
Contributions 94
une adresse aléatoire statique, l’objet connecté (et donc l’utilisateur) devient sensible aux attaques de type BLEB décrites au chapitre précédent.
Nous proposons PPCL (Privacy Preserving Crowd Localization) une nouvelle architec-ture qui effectue le crowd-localization tout en préservant la confidentialité des utilisateurs. PPCL rend impossible le suivi des utilisateurs par une compagnie ainsi que tout adver-saire qui possède un dispositif BLE. C’est uniquement lorsque l’utilisateur déclare son objet comme perdu que le serveur va pouvoir déterminer sa position. Il ne pourra pas récupérer l’historique des positions. Dès que l’objet est retrouvé, les clés sont changées et le serveur sera de nouveau incapable de suivre l’objet. Par rapport aux propositions actuelles, PPCL n’a aucun impact sur les objets connectés, la durée de vie de leurs batte-ries ou celles du smartphone. PPCL n’altère pas les performances du crowd-localization. Son seul inconvénient est une légère augmentation du coût de calcul pour les serveurs de la compagnie lorsqu’un utilisateur déclare la perte de son appareil.
Quatre variantes seront proposées, en fonction des risques dont on souhaite se protéger et du nombre de objets connectés suivis.
Pour résumer, les contributions de ce chapitre sont les suivantes :
1. Analyse des applications de crowd-localization existantes et mise en exergue des risques liés à leur utilisation ;
2. Analyse des propriétés souhaitées pour une solution idéale de crowd-localization respectueuse de la vie privée et proposition de PPCL avec quatre variantes en fonction des contraintes applicatives, matérielles et des attaques que l’on souhaite tolérer.