crowd-localization respectueux de la vie privée

Les services de crowd-localization déjà déployés semblent avoir des performances satisfai-santes. Cependant, elles ne protègent pas la vie privée des utilisateurs. Cette sous-section

Contributions 98

présente les propriétés qu’un service idéal de crowd-localization devrait satisfaire.

6.4.1 Propriétés souhaitées

1. crowd-localization : Possibilité de retrouver un objet connecté aussi vite que pos-sible, avec la meilleure précision spatiale et temporelle.

2. Sécurité sur les informations privées : Les objets connectés BLE ne doivent pouvoir être suivis par personne d’autre que son propriétaire. Cela inclut la compagnie qui fournit le service car celle-ci ne peut pas être considérée comme une entité de confiance.

3. Contraintes de coût : Le respect des deux premières contraintes ne doit pas se faire au détriment d’une augmentation excessive du coût dans le temps et dans l’espace. 4. Facilité de déploiement : La solution devrait autant que possible s’appuyer sur les

standards déjà déployés. Sinon, elle ne sera probablement pas utilisée.

6.4.2 Notre proposition : PPCL

Nous proposons une architecture qui préserve les informations privées des utilisateurs et qui satisfait les propriétés listées en 6.4.1. Les caractéristiques sont implémentées sur l’objet connecté, application installée sur les smartphones et sur le serveur. Cette section présente les interactions entre les entités de notre architecture.

L’application du smartphone est appairée à un objet connecté et établit une connexion sécurisée pour la communication. Lorsque cet objet n’est pas connecté au smartphone, il diffuse périodiquement des ADV_IND contenant un identifiant aléatoire résolvable. L’application du smartphone recherche périodiquement d’autres objets connectés à proxi-mité et envoie les résultats au serveur. Si l’objet connecté est perdu, l’utilisateur peut demander la dernière position connue au serveur.

6.4.2.1 Sensor

Le comportement des objets connectés peut être décrit comme suit :

1. Processus d’appariement (voir la section 3.1.4) : l’objet connecté et le smartphone échangent deux clés secrètes : la LTK et l’IRK. La LTK permettra de chiffrer la session actuelle et les futures sessions tandis que l’IRK sera utilisée pour la génération de d’adresse aléatoire résolvable.

2. Connecté : Tant que l’objet reste à portée du smartphone, il peut rester connecté. Cela permet au smartphone de faire sonner l’objet connecté et vice-versa.

3. Déconnecté ou perdu : Lorsqu’il n’est pas à portée du smartphone de l’uti-lisateur, l’objet connecté diffuse périodiquement des smartphone en utilisant des adresses privées fréquemment mises à jour. Pour permettre la reconnexion automa-tique, ces adresses doivent pouvoir être résolues. Comme le montre la figure 6.3, ces ADV_IND contiennent un identifiant privé résolvable notéRP IA

i . En sus du RP IA

i (on peut considérer que l’adresse MAC qui apparaît dans l’ADV_IND cor-respond à RP IA

i ), l’ADV_IND contient un champ UUID qui identifie le service de crowd-localization et permet de savoir que le message doit être traité par l’ap-plication. Nous reviendrons plus tard sur les différentes façons de composerRP IA

i . On peut simplement faire l’hypothèse qu’il est généré à partir de l’IRK.

4. Mise à jour périodique de l’IRK : L’objet connecté met à jour son IRK et l’envoie au smartphone. Cela se produit uniquement lorsque l’objet est connecté au smartphone.

6.4.2.2 Application

Comme le montre la figure 6.3, l’application analyse périodiquement les canaux Blue-tooth et collecte les ADV_IND des objets connectés à portée. Si le périphérique BLE détecté appartient au service de crowd-localization, l’application envoie au serveur un 3-tuple (RP IA

i , P os, T S) avec RP IA

i l’identifiant résolvable du périphérique détecté, Pos la position actuelle du smartphone et TS l’heure actuelle. Notez qu’un smartphone peut uniquement résoudre l’identifiant de son propre objet connecté. Périodiquement, le smartphone obtiendra l’IRK mis à jour par l’objet connecté. La mise à jour sera envoyée par ce dernier puisque les interfaces de programmation applicatives officielles proposées par iOS et Android ne permettent pas aux développeurs d’avoir accès à la valeur des clés secrètes (LTK, IRK ). La communication entre l’application et le serveur utilisera SSL. La mise à jour de l’IRK ne pourra se faire que lorsque l’objet connecté sera connecté au smartphone.

6.4.2.3 Serveur

Le serveur reçoit et sauvegarde tous les 3-uplets (contenant les identifiants privés résol-vables, notés RPI ) envoyés par les applications. Même si un attaquant a accès à la base de données, celui-ci ne pourra pas résoudre les RPI puisqu’il ne dispose pas de l’IRK.

Contributions 100

Sensor A Smartphone 1 Server

ADV_PKT (RP IA i ) SCAN_REQ (RP IA i ) SCAN_RSP (RP IA i ) SEND (RP IA i,POS,TS)

...

...

Figure 6.3: Interaction entre l’objet connecté, l’application et le serveur où l’applica-tion va envoyé au serveur les résultats de son scan actif.

Il en va de même pour le propriétaire du service de crowd-localization. Lorsque l’utilisa-teur déclare un objet connecté c comme perdu, l’application du smartphone envoie un 3-uplet (IRKc, P osc, T Sl) avec IRKc l’IRK actuel de l’ojet connecté, P osc la position actuelle de l’utilisateur et T S_l le temps de la dernière rencontre entre l’ objet connecté et le smartphone de l’utilisateur. Le serveur tente de résoudre chaque RPI de la base de données avecIRKc(nous verrons plus tard comment résoudre un RPI à l’aide d’une IRK ). Il essaie d’abord avec le RPI le plus récent qui est le plus proche de la dernière position connue P osc. Il s’arrête lorsque les RPI sont plus anciens que T S_l. S’il y a correspondance, le serveur renvoie à l’utilisateur la dernière position connue de l’objet connecté c.