Journal A propos des protocoles de traçage pour le Covid-19 : Google/Apple vs. INRIA/Fraunhofer

Sommaire

• Intérêt d'une application de traçage de relations sociales
• Vie privée
• Des téléphones devenant des balises Bluetooth Low Energy
• Des identifiants éphémères pour limiter les recoupements
• Fiabilité du registre des infectés
• Conclusion de l'approche décentralisée Google/Apple
• Une seconde approche : le protocole de l'INRIA et de l'institut Fraunhofer
• Divulgation de l'identité d'une personne infectée
• Des fédérations d'autorités
• Conclusion de l'approche INRIA/Fraunhofer
• Opter pour l'approche de Google/Apple ou celle de l'INRIA/Fraunhofer ?
• Implantation des protocoles sur des bracelets

Cet article est consacré aux solutions techniques pour le traçage de contacts sociaux dans le cadre de l'épidémie de Covid-19.

Je voudrais consacrer ce journal à la comparaison des deux principales solutions qui émergent des réflexions concernant les protocoles de traçage :

• Tout d'abord la proposition de Google et d'Apple
• Et celle développée par l'INRIA et l'institut Fraunhofer nommée Robert

Intérêt d'une application de traçage de relations sociales

L'intérêt de la mise en place d'une application de traçage est de permettre d'informer les gens qui ont été en contact avec des personnes contagieuses (contact ayant lieu alors que ces personnes ne se savaient pas encore infectées). Ainsi la personne informée peut prendre des précautions : se confiner, se faire tester (en supposant que les tests soient en disponibilité suffisante pour cela) et/ou se faire prescrire un traitement préventif avant même l'apparition des symptômes (pas encore connu en l'état actuel des connaissances). Cela peut donc aider à ralentir le rythme de l'épidémie.

Vie privée

Cela pose des questions importantes quant au respect de la vie privée des personnes utilisant une telle application de traçage. En fait on distingue deux types d'intervenants au fonctionnement de l'application : les utilisateurs (citoyens) et l'autorité gérant le système. Les problématiques de vie privée concernent ces deux intervenants :

• On souhaiterait que l'autorité ne puisse pas pister les utilisateurs et donc par exemple savoir si tel utilisateur a rencontré tel autre utilisateur à certain moment au cours des derniers jours. L'autorité ne doit pas avoir la possibilité de reconstituer les cliques d'utilisateurs avec leurs interactions sociales.
• On souhaiterait que les utilisateurs ne puissent pas s'espionner entre-eux, c'est-à-dire qu'ils ne puissent pas d'une part arriver à déterminer leurs interactions sociales respectives ou reconstituer leur déplacements et d'autre part déterminer que tel utilisateur est infecté ou pas.

On suppose pour la suite que l'autorité et les utilisateurs sont tous potentiellement «pisteurs» dans le sens où s'ils ont la possibilité technique de pister, ils le feront.
On suppose également que le protocole de traçage est parfaitement connu et que les utilisateurs ont un total contrôle sur l'application qu'ils utilisent (on peut supposer qu'il existe plusieurs implantations d'applications, dont certaines open source et que les utilisateurs ont tout loisir de modifier les applications et donc d'accéder aux données qu'elles manipulent).

Des téléphones devenant des balises Bluetooth Low Energy

Aussi bien pour la solution de Google/Apple que celle de l'INRIA/Fraunhofer, le fonctionnement repose sur l'émission d'identifiants à intervalle de temps régulier en utilisant le Bluetooth Low Energy (BLE) ; un protocole de liaison radio qui diffère du Bluetooth classique dans le sens où il est beaucoup moins énergivore et possède une portée plus limitée. Le BLE est notamment utilisé pour mettre en oeuvre de solutions de localisation en intérieur (là où le signal GPS ne peut passer). On utilise pour cela des balises BLE (beacons) qui émettent leur identifiant avec leur positionnement dans le bâtiment au téléphone de l'utilisateur. Celui-ci peut en associant la force des signaux des balises BLE reçues déterminer par triangulation un positionnement précis dans le bâtiment. Une balise BLE qui annonce son identifiant toutes les secondes peut fonctionner plusieurs années avec une simple pile bouton lithium. Pour le protocole de traçage, le téléphone joue le rôle de balise BLE et émet régulièrement un identifiant.

Ainsi chaque téléphone va jouer le rôle de balise mais également d'écouteur de balises que sont les autres téléphones. L'application pourra mémoriser les identifiants de tous les téléphones qu'elle rencontre. Lorsqu'un utilisateur est testé positif pour le Covid-19, l'autorité récupère son identifiant de balise et le publie. Les autres utilisateurs consultent régulièrement le registre des identifiants des infectés et peuvent donc savoir si ils ont rencontré une personne contagieuse et prendre les mesures nécessaires le cas échéant.

Les avantages d'utiliser le BLE sont d'une part comme on l'a vu que la surconsommation énergétique du téléphone est faible et d'autre part que le risque de faux-positifs est réduit par rapport à un système de communication radio de plus forte portée. Mais dans l'approche qui vient d'être décrite, nous n'avons pas solutionné toutes les problématiques de vie privée posées.

L'autorité recueille et publie les identifiants des diagnostiqués positifs mais elle ne peut pas retracer leurs contacts et déplacements (sauf si elle déploie sur le terrain des récepteurs BLE à cette fin) ; ces informations restent dans la mémoire du téléphone de chacun (à laquelle on suppose que l'autorité n'a pas accès).

En revanche les utilisateurs peuvent se pister entre-eux sans difficulté et déduire l'identité de personnes infectées. Pour retrouver l'identité d'un infecté, il suffit d'associer à chaque identifiant collecté l'instant de collecte plus d'autres informations (position géographique GPS, note manuelle de l'utilisateur…). L'utilisateur pourra se rappeler qui il a croisé à cet instant et à cet endroit ce qui restreint beaucoup le nombre de personnes possibles. Il est possible aussi de placer des petits appareils BLE dans des lieux publics (rue, magasins…) et de faire des statistiques sur les personnes infectées ayant transité dans ces lieux et de désanonymiser ces informations si on les croise avec d'autres sources de données. Par exemple un magasin peut placer près de sa caisse un appareil récoltant les identifiants BLE des téléphones des clients. Si le client X utilise sa carte de fidélité et est déclaré ensuite malade dans le registre des identifiants des infectés, le magasin pourra savoir que X est infecté. On pourrait aussi croiser ces informations avec des vidéos de caméra (mais si X porte un masque, il est plus difficile de l'identifier ;)

Des identifiants éphémères pour limiter les recoupements

Pour limiter le risque de pistage entre utilisateurs, Google et Apple ont proposé dans leur approche que les utilisateurs émettent des identifiants éphémères plutôt que le même identifiant en permanence. Ces identifiants éphémères ont une durée de vie de 15 minutes et sont générés à partir d'une clé maître journalière connue uniquement du téléphone. Il n'est pas possible de retrouver la clé maître à partir des identifiants éphémères. Cette idée permet d'éviter qu'un boîtier BLE dans un lieu public puisse pister les mouvements d'une même personne au cours du temps (par exemple on ne pourra plus savoir qu'une certaine personne s'est rendue dans ce même lieu à tel moment et à tel autre moment). Par contre on peut toujours, si on dispose de donnés de croisement adéquates pour le moment précis, désanonymiser un identifiant même éphémère. Ainsi par exemple si X vient lundi dans le magasin payer avec sa carte de fidélité, on pourra associer son identifiant éphémère à son identité mais si il revient mercredi sans utiliser sa carte, son anonymat restera conservé, alors que si l'on avait utilisé un identifiant permanent on aurait pu le reconnaître également mercredi.

Il est maintenant nécessaire que la base des identifiants des malades contienne pour chaque malade non pas un seul identifiant mais tous ses identifiants éphémères des deux dernières semaines (si l'on suppose que la période d'incubation ne peut pas dépasser cette durée). Si l'on suppose que chaque identifiant tient sur 128 bits, qu'un nouvel identifiant éphémère est utilisé toutes les 15 minutes, cela représente jusqu'à ~21 Ko de données à conserver par malade. En pratique cela sera sûrement moins car on pourra ne pas envoyer les identifiants éphémères produits sur les périodes on l'on aura reçu aucun identifiant d'autres téléphones (par exemple la nuit ou chez soi). Mais ça reste un volume conséquent de données surtout si on le multiplie par le nombre de diagnostiqués positifs. Par exemple sur les 14 derniers jours, il y a eu plus de 400 000 nouveaux cas diagnostiqués aux Etats-Unis, la taille correspondante du registre des identifiants éphémères pourrait atteindre (si tout le monde utilisait une application de traçage) 8 Go pour 14 jours, soit une base journalière de l'ordre de 600 Mo. L'utilisateur qui voudrait savoir si il a croisé une personne qui a été testée positive devra télécharger chaque jour la base de la veille et vérifier si un identifiant éphémère qu'il a collecté y réside. On pourrait imaginer que la base soit fractionnée en bases régionales plus petites. On pourrait aussi avoir un service web à qui l'on fournirait les identifiants éphémères que l'on a collectés pour qu'il nous indique si l'un d'eux correspond à un infecté. Mais dans ce cas le service web en question pourrait obtenir des informations permettant de tracer les utilisateurs qui le sollicitent ; cela resterait uniquement une position de repli pour les utilisateurs ne disposant pas d'une connectivité Internet suffisante. On pourrait également imaginer que le service web soit interrogé en plusieurs fois, en utilisant des proxys web…

Fiabilité du registre des infectés

Mais qu'en est-il de la fiabilité de la base des identifiants éphémères des positifs au Covid-19 ? On pourrait imaginer que n'importe qui puisse prétendre être infecté et envoie ses identifiants éphémères pour qu'ils soient intégrés dans la base (et ainsi inquiéter inutilement les gens rencontrés). Pour éviter ce problème, l'autorité gérant la base peut distribuer des jetons uniques (nombre de 128 bits aléatoires par exemple) aux organismes habilités à diagnostiquer (labos, hôpitaux…). Il faudrait fournir à l'application un de ces jetons uniques qui serait communiqué par l'organisme de diagnostic. L'application enverrait ce jeton avec les identifiants éphémères personnels vers l'autorité (qui vérifierait qu'il s'agit bien d'un jeton qu'elle a émis et qu'il n'a pas été réutilisé). Il reste aussi le problème d'un utilisateur positif qui soumettrait non pas ses propres identifiants éphémères mais des identifiants éphémères d'autres personnes (pour faire croire que ce sont elles qui sont infectées et pas lui). Ce problème est facilement résolvable si l'autorité exige la fourniture des clés maîtres journalières ayant servi à générer les identifiants éphémères. Bien sûr l'autorité ne doit pas publier ces clés maîtres mais elle pourra les utiliser pour vérifier qu'elles génèrent bien les identifiants éphémères communiqués. Comme il n'est pas possible de déduire les clés maîtres des clés éphémères, la seule attaque possible serait une collusion entre plusieurs utilisateurs qui échangeraient les données de leurs téléphones.

Un autre souci serait le cas d'un utilisateur qui collecterait des identifiants éphémères qu'il réémettrait à son propre compte (rejeu d'identifiants). Si les identifiants réémis appartiennent à des personnes diagnostiquées positives plus tard, les personnes les ayant reçus pourraient surestimer leur risque d'infection. Pour éviter les rejeux d'identifiants, on pourrait faire en sorte que ceux-ci soient publiés avec leur date approximative d'émission dans le registre des infectés : si un utilisateur trouve dans le registre un identifiant qu'il a collecté il vérifiera que la date indiquée dans le registre correspond à celle où il a collecté l'identifiant (si ce n'est pas le cas, il l'ignorera).

Conclusion de l'approche décentralisée Google/Apple

On vient de décrire à peu près comment fonctionne l'approche de Google et Apple que l'on peut qualifier de décentralisée dans le sens où ce sont les utilisateurs eux-mêmes qui déterminent si ils sont à risque en consultant un registre central tenu par une autorité, ce registre contenant les identifiants éphémères des personnes diagnostiquées positives. Cette approche est intéressante dans le sens où l'utilisateur reste à tout moment maître de ces données. Il peut installer l'application à n'importe quel moment, commencer la collecte et l'annonce à n'importe quel moment et choisir de révéler ou non au registre s'il a été diagnostiqué positif. Il peut même se comporter de manière égoïste en collectant les identifiants émis dans son voisinage sans activer l'émission d'identifiants par son téléphone. Il reste ainsi invisible mais bénéficie d'alertes si il a croisé une personne à risque. Cette approche offre donc une liberté totale à l'utilisateur. Il faut toutefois qu'il ait conscience que l'action d'envoyer ses identifiants éphémères vers le registre peut potentiellement permettre de l'identifier comme malade auprès de ses contacts. Mais si cet envoi résulte d'un choix éclairé de sa part, on ne peut pas considérer qu'il y a rupture du secret médical. D'autre part l'utilisateur diagnostiqué positif peut choisir de révéler au registre sélectivement ses identifiants éphémères : il pourrait ne pas transmettre les identifiants correspondant à des périodes où il a côtoyé des personnes à qui il ne souhaite pas révéler sa maladie (et qui ne pourront donc pas prendre eux-mêmes des mesures préventives). En reprenant l'exemple évoqué précédemment, il pourrait ne pas transmettre les identifiants correspondant à ses visites au magasin.

Une seconde approche : le protocole de l'INRIA et de l'institut Fraunhofer

La seconde approche, celle développée par l'INRIA et l'institut Fraunhofer a pour objectif principal d'empêcher l'identification des malades par les utilisateurs. Pour arriver à cette fin, l'autorité joue un rôle plus important et plus actif. Lorsqu'un individu est diagnostiqué positif, plutôt que de demander la publication de ses identifiants éphémères dans un registre, il communique à l'autorité les identifiants éphémères de toutes les personnes qu'il a croisées. C'est l'autorité qui aura la charge de notifier ses contacts du risque qu'ils encourent sans jamais révéler la source de l'infection.

Le fonctionnement de l'approche INRIA/Fraunhofer peut ainsi être décrit :
1. L'utilisateur installe l'application sur son téléphone
2. L'application créé un compte sur le serveur de l'autorité. La création du compte est anonyme, le serveur n'étant pas censé récupérer l'identité réelle du participant. Le serveur génère un identifiant maître pour l'utilisateur qu'il conserve secrètement, une clé d'authentification qu'il communique à l'utilisateur (qui servira à authentifier ses communications futures avec le serveur) et un jeu d'identifiants éphémères qui devront être diffusés en BLE à des moments précis par l'utilisateur. Les identifiants éphémères d'un utilisateur sont générés à partir de son identifiant maître (connu uniquement du serveur) ainsi que d'une clé secrète du serveur en utilisant un algorithme de chiffrement symétrique. Cela signifie que le serveur peut aussi retrouver l'identifiant maître à partir des identifiants éphémères mais que les utilisateurs ne le peuvent pas car ils ne possèdent pas la clé secrète du serveur.
3. L'utilisateur diffuse ses identifiants éphémères par BLE et collecte les identifiants des gens avec qui il est physiquement proche.
4. Si l'utilisateur est diagnostiqué positif, il envoie au serveur les identifiants éphémères collectés de ses contacts. Le serveur peut retrouver les identifiants maîtres des contacts à partir des identifiants éphémères et les inscrire sur une liste d'utilisateurs à risque.
5. Chaque utilisateur interroge régulièrement le serveur pour savoir s'il est sur la liste des utilisateurs à risque : pour cela il communique son identifiant éphémère du moment, le serveur retrouve son identifiant maître et peut lui indiquer s'il est sur la liste des utilisateurs à risque. Le serveur ne révélera pas l'origine du risque.

Divulgation de l'identité d'une personne infectée

Les concepteurs de ce protocole ont cherché à minimiser les risques de divulgation de l'identité d'une personne infectée. Toutefois un attaquant motivé peut y parvenir. Il pourra pour cela créer de multiples comptes "jetables" sur le serveur de l'autorité : il les utilisera que pour ne diffuser qu'un seul identifiant éphémère qui sera collecté que par la personne ciblée. Si l'attaquant apprend qu'un de ses comptes jetables fait partie des utilisateurs à risque, il saura avec certitude que la personne ciblée avec ce compte est diagnostiquée positive. Pour rendre ce type d'attaque plus difficile, il est suggéré que le serveur utilise des captchas pour la création d'un compte ainsi que de répondre faussement qu'un utilisateur est à risque (génération de faux-positifs). Ainsi l'attaquant pourra savoir avec une probabilité haute que la personne ciblée est infectée mais pas certaine (mais cela pourrait être contourné par l'usage de multiples comptes ciblant une même personne).

Des fédérations d'autorités

Notons également que le protocole INRIA/Fraunhofer propose un fonctionnement avec une fédération de serveurs : chaque identifiant éphémère est associé avec un code pays chiffré qui ne peut être déchiffré que par une clé secrète partagée par les serveurs de la fédération. Ainsi lorsqu'un utilisateur est diagnostiqué positif, il envoie au serveur de son pays les identifiants éphémères associés au code pays chiffrés et le serveur local peut rediriger les identifiants éphémères étrangers vers les serveurs concernés qui pourront prévenir leurs utilisateurs qu'ils sont à risque.

Conclusion de l'approche INRIA/Fraunhofer

Le principal reproche que l'on peut faire à l'approche INRIA/Fraunhofer est que sous couvert de protéger l'identité des malades elle donne des pouvoirs importants à l'autorité. Si celle-ci est malhonnête, elle pourrait conserver les contacts des personnes infectées, reconstituer leur graphe d'interaction sociale qui pourrait même être désanonymisé si des informations adéquates sont collectées (adresse IP des requêtes et collusion avec les fournisseurs d'accès). Dans la description de la première version du protocole, il est suggéré que les utilisateurs diagnostiqués positifs contactent le serveur en envoyant un par un les identifiants éphémères de leurs contacts en utilisant un MixNet sur une longue période : ainsi le serveur ne peut pas savoir l'identité du malade et le rapprocher de ses contacts. C'est effectivement envisageable mais puisque le serveur n'aurait plus de contrôle sur l'identité de l'émetteur des messages, il ne pourrait pas savoir si ceux-ci correspondent effectivement à un utilisateur diagnostiqué positif. Il serait alors possible de spammer le serveur et de provoquer une grande quantité d'alertes infondées.

Opter pour l'approche de Google/Apple ou celle de l'INRIA/Fraunhofer ?

Pour résumer les deux approches, on pourrait dire que celle de Google/Apple considère les utilisateurs comme responsables et leur laisse le pouvoir de calculer leur exposition au risque. C'est intéressant car on peut savoir à quel moment on a pu être exposé au risque : on peut alors identifier la personne potentiellement contaminante mais on peut également se rappeler de détails qui permettent de mieux apprécier le risque en le contextualisant (portait-on un masque ? respectait-on les distances de sécurité ?). L'autorité ne joue qu'un rôle passif en se contentant de collecter et relayer les identifiants éphémères des personnes infectées.

Avec l'approche INRIA/Fraunhofer, l'autorité est présumée bienveillante, ce sont les utilisateurs dont il faut se méfier car on présume qu'ils chercheront à identifier les malades et à les stigmatiser. L'utilisateur doit donc avoir confiance en l'autorité qui le protégera de ses méchants congénères. L'autorité se contentera de lui indiquer s'il est à risque ou pas (et quelquefois en introduisant volontairement des faux-positifs comme on l'a vu) mais il ne pourra pas contextualiser le risque. Prenons l'exemple d'une caissière de magasin côtoyant quotidiennement des clients avec de bons moyens de protection : visière, masque, paroi de plexiglas et distance de sécurité. Cependant elle rencontre pour ses loisirs des personnes sans protection. Avec l'approche INRIA/Fraunhofer, si celle-ci reçoit une notification lui indiquant qu'elle a rencontré un individu infecté, elle ne pourra pas savoir si cela a eu lieu durant son temps de travail ou lors de ses loisirs. On peut supposer qu'elle serait moins inquiète d'apprendre que c'est l'un de ses clients qui est infecté plutôt qu'une des personnes rencontrées sans protection (information qu'il serait possible de savoir avec l'approche Google/Apple). Avec l'approche INRIA/Fraunhofer pour ne pas être avertie suite au contact avec un client infecté, elle devrait désactiver l'annonce de ses identifiants durant son temps de travail.

Implantation des protocoles sur des bracelets

Pour finir, on peut ouvrir les perspectives sur l'utilisation d'autres appareils que des téléphones Android/iOS pour le protocole de traçage. On pourrait imaginer par exemple des bracelets BLE pour ceux qui n'ont pas de smartphone supportant le BLE. Ceux-ci généreraient ou seraient pré-remplis avec des identifiants éphémères qu'ils diffuseraient périodiquement et ils collecteraient les identifiant reçus. En cas de diagnostic positif, l'hôpital récupérerait du bracelet soit les identifiants diffusés (approche Google/Apple), soit les identifiants collectés (approche INRIA/Fraunhofer) pour les transmettre à l'autorité. Mais comment faire pour que le bracelet puisse informer son utilisateur qu'il a rencontré une personne infectée ? Le bracelet pourrait se connecter à Internet périodiquement mais dans ce cas il faudrait un téléphone ou un ordinateur qui serve de relai. On pourrait imaginer à la place que les données permettant d'informer les utilisateurs à risque soient diffusées par un protocole de radiomessagerie unidirectionnel : le bracelet serait en permanence en écoute pour repérer si un des identifiants collectés est diffusé (approche Google/Apple). Pour l'approche INRIA/Fraunhofer, on peut supposer qu'un identifiant supplémentaire secret soit introduit pour chaque utilisateur qui ne soit connu que de l'autorité et de l'utilisateur lui-même : le bracelet réagirait lorsque cet identifiant serait diffusé. L'intérêt d'utiliser un bracelet est que l'on pourrait y introduire des fonctionnalités complémentaires : prise de pouls, de température, évaluation du sommeil… qui permettraient une meilleure évaluation du risque des malades potentiels et un meilleur suivi des malades confirmés.