Contact tracing : tous fliqués ! Délires de l’artiste ou délires du paranoïaque ?

Entre le délire du complotiste et celui du scientifique, la marge est large. Récemment, ces derniers se sont lancés dans l’élaboration de solutions de contact tracing pour superviser la propagation de la pandémie. Alors, allons-nous vers des puces GPS dans les vaccins ou une utilisation épidémiologique de nos téléphones portables ?

De ce que je comprends des experts en santé, un vaccin contre le COVID-19 ne sera pas disponible avant quelques mois, et rien ne dit qu’il sera efficace contre toutes les mutations du virus. D’ici là, d’autres stratégies doivent être proposées.

Après la tentative de contact tracing manuel avec les clusters, le confinement total a été la réponse : pas de contact, pas de contagion. C’est une réponse d’urgence qui a été mise en place sur le court terme, permettant avant tout de gagner du temps pour élaborer une réponse plus efficace. Ce n’est cependant pas une solution durable viable : on ne peut pas tous rester tout le temps confinés sans craindre des retombées économiques négatives.

Une partie de cette nouvelle stratégie repose sur la capacité à détecter les nouveaux foyers d’épidémie pour mettre en place rapidement des confinements à une échelle locale et les traiter. Cependant, il est important dans cette démarche de devancer la maladie pour en ralentir la propagation par les porteurs sains.

C’est pour cela qu’il est aujourd’hui envisagé une campagne de tests qui inclut aussi les personnes en bonne santé : le but est de pouvoir identifier les porteurs encore sans symptômes du virus et les placer en confinement. Un outil s’offre à nous pour rendre cette tâche beaucoup plus efficace : le contact tracing.

Le principe est simple : si l’on découvre que vous êtes contaminés, il faut pouvoir prévenir toutes les personnes avec lesquelles vous avez été en contact les jours (ou semaines) précédents, que ce soit celles avec qui vous vivez, ou celles qui attendaient avec vous à la boulangerie. De la sorte, il sera possible pour ces personnes de se faire tester médicalement pour déterminer si elles sont contaminées. Elles pourront alors se confiner, et on recherchera de même tous leurs “contacts” récents pour les tester et les mettre en quatorzaine si besoin, et ainsi de suite…

Ce travail traditionnellement réalisé à la main sur la base d’interviews demande une main d’œuvre importante et beaucoup d’organisation, et c’est ainsi qu’il vient à l’esprit d’utiliser nos téléphones portables pour réaliser cette opération.

Le contact tracing pour les ignorants, paranoïaques, complotistes et autres décérébrés

Nos téléphones savent tout de nous, et dans le cas qui nous intéresse, où nous sommes grâce aux services de localisation qui y sont installés.

Une première version du contact tracing pourrait (notez le conditionnel) être que chaque téléphone envoie à intervalle très régulier sa position GPS à une base de données centrale pour qu’une autorité fasse les recherches des contacts quand une personne est détectée positive. C’est par exemple une des options retenues par les gouvernements chinois et norvégien.

Une alternative serait d’utiliser les relais téléphoniques, mais ils sont moins précis pour la localisation ce qui conduirait à de nombreux faux positifs (c’est-à-dire, des personnes catégorisées comme contaminées alors que saines) qui viendraient saturer la détection des personnes infectées. Pour une personne infectée, il peut y avoir des milliers d’autres connectées au même relais, sans pour autant qu’aucune n’ait croisé le patient zéro.

Bref, tous les paranoïaques et autres complotistes se réveillent en se disant que la police va tous nous fliquer. En revanche, que Facebook ou Google fassent exactement de même ne les dérangent pas une seconde. Époque étonnante : on veut bien dévoiler toute sa vie sur son mur ou sa timeline, mais on préfère la cacher à ses gouvernants.

Cependant, on peut être paranoïaque et ne pas avoir totalement tort non plus. L’histoire des lois anti-terroristes récentes par exemple montre qu’au nom de la sécurité, les peuples sont prêts à sacrifier un peu de liberté. Et quand un gouvernement dispose de tels moyens, au lieu de les restituer, songe plutôt à les étendre. Le risque est réel, surtout dans les pays un peu moins démocratiques que les autres. Un autre point de vue peut être de ne pas remettre en question la bienveillance de son État, mais d’admettre que dans la précipitation d’une épidémie, certaines approximations sont peut-être faites sur la sécurité… et quels moyens serait prêt à investir un acteur tiers pour mettre la main sur de telles données ?

En conséquence, personne d’un peu sérieux (ou démocratique) n’a considéré l’utilisation du GPS, conscient que le contact tracing ne peut fonctionner que s’il est grandement utilisé. D’emblée, annoncer un traçage individuel ne promet pas de grand succès et les recherches se sont orientées vers une approche “locale”, plus respectueuse de la vie privée.

De quoi faut-il avoir vraiment peur … ou quelles sont les bonnes questions à se poser ?

Un court, mais très clair et instructif texte, à destination des non spécialistes, proposant une analyse de risques du traçage a été réalisé par des chercheurs interdisciplinaires (crypto, sécurité, droit) : le traçage anonyme, dangereux oxymore.

J’en recommande fortement la lecture et vais me contenter de résumer les questions à se poser. Je renvoie à l’article pour les explications et les modèles d’attaques.

• Qui certifie qu’une personne est malade ?
• Est-il possible d’identifier qui nous a contaminé ?
• Est-il possible de déterminer si / quand une personne précise est malade ?
• Comment déclencher de fausses alertes et faire croire à quelqu’un qu’il est à risque ?
• Qu’est-ce qui empêche des tiers (par exemple des applications foireuses) d’utiliser les données collectées par l’application de traçage sur le téléphone ?

Je me répète — on dit “radoter” à mon âge — mais l’article est très clair et pragmatique, avec des scénarios réalistes. J’aime particulièrement l’élève qui pour sécher un partiel “emprunte” le téléphone d’une personne probablement malade, mais pas encore déclarée officiellement. Il passe ensuite la journée avec ce téléphone en classe, le rend à son propriétaire qui va voir son médecin le lendemain et se fait déclarer enfin officiellement malade : tous les camarades de classe et professeurs sont maintenant (artificiellement) à risque.

Bref : lisez le document !

Contact Tracing : principes généraux pour les cérébrés

Heureusement, le problème du contact tracing se formalise sans avoir besoin de la géolocalisation. Ce que cherchent les épidémiologistes consiste à savoir qui a été en contact avec qui pendant un intervalle de 2 semaines. Que ce soit à un concert de M. Pokora, dans le métro, ou chez Tata Renée, on s’en fout. Donc, bonne nouvelle : nul besoin de Big Brother, le Bluetooth de nos téléphones suffit.

La plupart des propositions faites reposent sur le schéma suivant :

1. Chaque téléphone émet un identifiant en Bluetooth.
2. Chaque téléphone enregistre tous les identifiants qu’il reçoit. Ils sont émis par les téléphones des personnes proches.
3. Chaque téléphone change son propre identifiant de temps en temps, pour éviter qu’il soit trop facile d’identifier les individus.
4. Quand quelqu’un est contaminé, il prévient les personnes avec lesquelles il a été en contact. Là, les différences sont flagrantes selon que l’approche est centralisée (l’infecté téléverse la liste des contacts croisés) et décentralisée (l’infecté téléverse les identifiants qu’il a utilisé).
5. Une personne demande à intervalle régulier quel est son risque d’infection. Dans l’approche centralisée, la base de données contient la liste des gens croisés par une personne infectée. Le risque pour un individu est mis à jour à chaque rencontre par un calcul sur le serveur. L’application interroge alors la base de données pour connaître le risque. Dans l’approche décentralisée, l’utilisateur demande l’état (sain / infecté) des personnes de sa liste de contacts, et calcule sur son téléphone son risque.

Il existe de nombreuses variantes, soit sur les paramètres (ex. : la durée de renouvellement des identifiants), soit dans la structure de l’algorithme (avec ou sans base de données centralisée), mais le principe général reste globalement celui reposant sur ces 5 étapes.

Regardons cela un peu plus en détail les phases critiques de ces protocoles :

• L’installation, et les données utilisées par l’application
• La détection des contacts : à partir de quelles données, qui a accès à quoi, quand, qui émet quoi, etc. ?
• L’utilisateur infecté : que se passe-t-il quand un individu est infecté
• Contact tracing : comment les contacts sont notifiés ou comment un individu connaît-il son risque de contamination ?

Les protocoles qui sont présentés ensuite sont susceptibles d’évoluer et la liste n’est nullement exhaustive (oui, je sais déjà qu’il en manque ;-) ).

Résumé grosses mailles pour les gens pressés

Si vous ne voulez pas rentrer dans les détails des applications et des protocoles présentés ci-après, le tableau suivant présente une synthèse des approches et des menaces associées à chaque étape.

Vous pouvez vous rendre directement à la conclusion sans passer par la case Bluetooth, ni la case protocoles et applications.

Préambule : le Bluetooth pour les nuls

Pour les pressés, le Bluetooth considère des équipements, appelés Peripherals, qui émettent des annonces sur ce qu’ils savent faire, et des Centrals, à qui les Peripherals se connectent pour rendre des services. En gros, le Peripheral dit “je sais cuisiner de la tête de veau”, et le Central lui répond “moi j’en veux”. Les 2 se mettent alors ensemble, l’un cuisinant pour l’autre et lui donnant la tête de veau tant attendue.

Si vous n’avez pas envie de rentrer dans les détails un peu plus techniques, vous pouvez finir votre tête de veau et passer à la partie suivante.

Le Bluetooth Low Energy est une technologie qui équipe maintenant tous les téléphones (et plus), afin de mettre en relation des équipements proches les uns des autres sans consommer trop de batterie. Sa construction même en fait un candidat idéal pour le traçage des contacts.

Comment cela fonctionne ?

La première couche, appelée GAP (Generic Access Profile), permet à des appareils de se découvrir entre eux. Cela repose sur 2 rôles :

• Le périphérique (Peripheral), souvent de faible capacité (moniteur cardiaque, casque, etc.), émet des annonces (advertising data) indiquant sa présence.
• Le central (Central), souvent un téléphone ou une tablette, sert à connecter le périphérique.

Une fois qu’un central a accroché un périphérique, ce dernier cesse d’émettre ses annonces, et il passe en mode exclusif. Arrive alors la seconde couche, appelée GATT (Generic ATTribute profile). Elle définit comment les devices échangent des données.

Pour que 2 équipements Bluetooth puissent communiquer, ils doivent partager un même profil. Un profil est un service standardisé comme BCS (Body Composition Service), HRP (Heart Rate Profile), IPSP (Internet Protocol Support Profile) … Un device peut contenir plusieurs profils, en fonction de son utilisation, un Profile peut contenir plusieurs Services (ex. HRP combine le Heart Rate Service et le Device Information Service), et chaque Service contient des Characteristics.

Un des profils du Bluetooth s’appelle PXP, pour ProXimity Profile. Son but est de déterminer la présence ou l’absence d’un objet dans un rayon donné. Ça tombe bien !

Point important évoqué par certains, mais pas tous : quand on communique en Bluetooth, le périphérique a une adresse MAC. Si cette adresse ne change pas autant que les identifiants manipulés par les applications de traçage, cela donne un moyen vraiment facile de reconstruire le graphe de voisinage d’une personne. Il existe un mécanisme dans Bluetooth Low Energy pour que les adresses MAC changent régulièrement (Resolvable Private Addresses — RPK) qui est utilisé par Google et Apple sur leurs appareils respectifs.

L’ancêtre : OpenTrace à Singapour

Site web: https://bluetrace.io

L’application open source OpenTrace repose sur le protocole BlueTrace.

Installation et gestion de l’identité

Lorsque l’application est installée et lancée pour la première fois, l’utilisateur doit renseigner son numéro de téléphone, qui est alors transmis au service en charge de l’application (le Singaporian Ministry of Health ici). En retour, l’application reçoit un userID unique. L’État dispose donc ici d’une base complète de ses utilisateurs, ce qui permet de prévenir immédiatement les personnes en contact avec une personne contaminée.

Pendant l’utilisation, un id temporaire (tempID) est généré à intervalle régulier (15 min d’après les spécifications). Cet id temporaire est chiffré en AES-256-GCM côté serveur, et contient l’userID précédemment renvoyé par le serveur du ministère, ainsi qu’un intervalle de temps.

Détection des contacts

Le message d’annonce des Peripherals contient essentiellement l’id de l’utilisateur, le modèle du téléphone, l’autorité auprès de qui l’instance de l’application OpenTrace est enregistrée (SG_MOH, Singapore Ministry of Health pour la version singapourienne de l’application). Le Central répond avec les mêmes champs et stipule en plus la force du signal pour évaluer la distance du Peripheral (RSSI — Received Signal Strength Indicator).

Les informations sur les contacts croisés sont conservées pendant 21 jours.

L’utilisateur infecté

Quand un patient est déclaré contaminé, les autorités lui demandent s’il a l’application et s’il veut charger ses données. Si c’est le cas, il reçoit un code autorisant l’upload de la liste de contacts croisés vers le serveur de l’autorité, ceci afin d’éviter les uploads frauduleux.

Contact tracing

Les données uploadées contiennent les tempID, mais l’autorité dispose de la clé pour les déchiffrer et accéder ainsi à tous les userID et donc les téléphones des personnes croisées par le patient.

Singapour a choisi de combiner les données issues de l’application avec une interview du patient. En croisant ces informations avec les données épidémiologiques, les autorités déterminent ensuite les personnes les plus à risque et les contactent.

Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT)

Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) est la réponse de l’Europe au contact tracing. Ou d’une certaine Europe. Ou d’on ne sait qui.

Pour comprendre les détails du micmac : Nadim Kobeissi: An Investigation Into PEPP-PT. Je recommande chaudement la lecture de la prose de Nadim.

Pour résumer l’imbroglio qui n’est pas l’objet ici, cet “organisme” est sorti de nulle part pour promouvoir une solution de contact tracing, des membres entrent et disparaissent (ex. : l’EPFL)… L’INRIA et le Fraunhofer Institue, qui n’ont pas oublié d’être bons, ont publié les spécifications d’un protocole appelé ROBERT sous la tutelle de PEPP-PT, et le même jour, 300 scientifiques ont publié une lettre ouverte demandant plus de transparence et une approche décentralisée (ce que n’est pas PEPP-PT). Bref, c’est le bordel, et les objectifs / personnes de PEPP-PT sont pour le moins flous.

Pour y voir plus clair, nous disposons de 2 sources :

• Pan-European Privacy-Preserving Proximity Tracing Need-To-Know System (PEPP-PT_NTK): une description haut niveau de ce qu’ils imaginent.
• ROBust and privacy-presERving proximity Tracing protocol (ROBERT) : une implémentation par l’INRIA et le Franhaufer Institute des principes poussés par PEPP-PT_NTK

Dans son document, PEPP-PT_NTK annonce d’emblée être conforme au RGPD, et aux principes de minimisation et anonymisation des données recommandés par les autorités européennes. Néanmoins, comme nous le verrons, des choix différents sont faits dans l’implémentation.

PEPP-PT version allemande

Les informations suivantes sont extraites de l’implémentation allemande de PEPP-PT

Installation et gestion de l’identité

Aucune donnée personnelle n’est requise pour connecter l’application au service. Des précautions sont prises pour éviter le souci de création massive de comptes bidon via des challenges crypto et des captchas.

Quand un utilisateur s’enregistre via son application, après avoir résolu les challenges pour s’assurer que c’est bien un humain, le serveur crée un identifiant unique appelé PUID, un nombre aléatoire de 128 bits, envoyé à l’humain et son application.

Pendant l’utilisation, ce PUID est utilisé pour générer des identifiants temporaires. En fait, le serveur dispose d’une clé secrète qui change à intervalle de temps fixe (par exemple 1 h dans les spécifications). Cette clé est utilisée pour chiffrer le PUID en AES (pas d’information sur le mode dans la documentation), ce qui génère un pseudonyme éphémère (EBID). En pratique, le serveur en génère une liste stockée par l’application, là où le serveur a juste besoin de sauvegarder seulement les clés utilisées, et l’intervalle de temps pour tous ses utilisateurs.

Détection des contacts

Quand 2 devices se croisent, ils enregistrent plusieurs informations :

• leur EBID respectif ;
• l’heure à laquelle ils se sont vus ;
• des metadata : en s’appuyant a priori sur PXP évoqué précédemment, le RSSI, la puissance pour le RX/TX. En plus, optionnellement après acception de l’utilisateur des informations plus précises comme l’appartenance à un WiFi et quelques autres données. Ces données additionnelles servent à un algorithme de scoring pour estimer le risque de contamination d’un contact si le détenteur de l’application se révèle contaminé.

Les informations sur les contacts croisés sont conservées pendant 21 jours.

L’utilisateur infecté

Quand une personne est confirmée comme étant contaminée, elle doit recevoir un élément, appelé TAN dans le jargon PEPP-PT, sorte de token d’authentification confirmant la contamination et autorisant l’upload des données de traçage vers le serveur de l’autorité, c’est-à-dire la liste des EBID, les heures et les metadata associées.

Contact tracing

Avec les heures, le backend retrouve les bonnes clés et peut alors déchiffrer les EBID croisés. Ces données sont alors passées dans une moulinette qui met à jour le score de risque d’un PUID. Ainsi, un PUID ayant croisé trop de monde infecté verra son score croître et sera considéré comme plus à risque. Au-delà d’un certain seuil, une notification (push) est envoyée au PUID en question. L’algorithme de calcul du risque n’entre pas dans le champ du document étudié mais n’est pas détaillé par ailleurs.

Le message est envoyé à la fois aux personnes jugées à risque, mais aussi à des personnes tirées au sort afin qu’une entité en mesure d’intercepter les messages ne puisse distinguer les personnes contaminées des autres (des autorités ou des services comme le Push de Google ou d’Apple). Quand l’application reçoit le message, elle envoie une requête au backend pour connaître son facteur de risques, et si le niveau le requiert, alerter sur une possible contamination.

ROBust and privacy-presERving proximity Tracing protocol (ROBERT)

L’INRIA et le Fraunhofer se sont associés pour élaborer le protocole ROBERT. Il suit la description générale de PEPP-PT, avec quelques variantes par rapport à l’implémentation allemande. Plus précisément, une attention particulière est portée sur la synchronisation du temps (utilisé pour suivre les identifiants).

Une autre particularité de ROBERT est la notion de fédération. L’application est à vocation européenne, où la libre circulation des citoyens est normalement fondamentale. Or, les instances de santé n’étant pas nécessairement les même au travers de l’Europe, le serveur a aussi la notion de Country code permettant de spécifier où les personnes se sont déplacées et d’échanger les données relatives aux déplacements entre les autorités de santé des pays concernés.

Par exemple, si un utilisateur se déplace dans un pays alors qu’il réside dans un autre, et qu’il est détecté positif après son retour, les personnes du pays visité doivent aussi pouvoir être prévenues.

Un serveur dispose de 2 clés :

• une clé secrète qui lui est propre ;
• la clé de fédération, partagée par tous les pays qui collaborent.

Installation et gestion de l’identité

Très similaire à la version allemande, une fois connectée au backend, l’application génère aléatoirement un identifiant unique (ID) pour l’application. Pour supporter les fédérations, l’application envoie aussi le Country Code de l’application au serveur.

Le backend génère une clé spécifique à cet ID, qu’il conserve et partage avec l’application.

En plus de la clé, l’application reçoit de quoi synchroniser son horloge avec le backend et des identifiants temporaires.

Les identifiants temporaires sont des paires :

• EBID (Ephemeral Bluetooth IDentifier), qui est le chiffré avec la clé propre au serveur de i | ID, où i est le temps (secondes depuis Epoch) ;
• ECC (Encrypted Country Code) est le Country Code de A chiffré en AES OFB, avec la clé de pays du serveur, et l’EBID en guise d’IV.

Détection des contacts

L’application envoie des messages, appelés HELLO, avec les informations suivantes : ECC || EBID || Temps || MAC . La partie “Temps” sert à éviter les attaques de rejeu.

Du côté de l’application qui reçoit un HELLO, les éléments sont séparés, mais la seule vérification qui est faite est que le message soit reçu dans un intervalle de temps court par rapport à l’heure actuelle, histoire d’éviter de surcharger l’application avec des messages frauduleux inutiles.

Finalement, les messages HELLO sont stockés dans une LocalProximityList. Le temps de conservation CT dans la liste est laissé au choix des autorités sanitaires.

L’utilisateur infecté

L’article mentionne qu’une autorisation est nécessaire, autorisation qui dépend d’une autorité, mais rien n’est indiqué quant à cette autorisation et à son utilisation.

Une autre particularité de ROBERT est la manière de gérer l’upload, et surtout l’alerte aux personnes ayant croisé une personne infectée. En fait, pour ROBERT, une personne n’a pas besoin de savoir qui sont les infectés croisés, mais juste que des infectés ont été croisés, et quand. Leur souci est d’éviter que le serveur puisse reconstruire le graphe de proximité des utilisateurs.

Quand on regarde la LocalProximityList, les messages HELLO stockés ne contiennent aucune information sur l’utilisateur de l’application, mais seulement sur les personnes croisées. Or, en chargeant toute cette liste d’un coup sur le serveur, celui-ci est alors capable de faire le lien entre la liste et l’application en question, et donc de reconstruire le graphe de proximité (dans les messages HELLO, il a les EBID croisés, qu’il peut déchiffrer grâce à sa clé de serveur, et donc obtenir tous les IDs).

Donc, les auteurs recommandent différentes approches (NDLA : peu réalistes / pratiques) pour éviter que le backend ne puisse reconstruire ce lien.

Contact tracing

Une fois en possession de la liste de messages HELLO, le serveur effectue tout un tas de vérifications (sur le CountryCode, sur l’heure, sur le MAC, …). Si ces vérifications sont correctes, les intervalles de temps contenus dans les messages HELLO sont ajoutés à chaque utilisateur dans une liste appelée LEE (List of Exposed Epoch), c’est-à-dire la liste des heures où l’utilisateur a été exposé à une personne potentiellement contaminée. Chaque utilisateur, dans la base de données, dispose ainsi de sa propre liste d’exposition.

À intervalle très régulier, l’application de l’utilisateur va demander au serveur s’il est “à risque”. Un algorithme de mesure de risques prend en compte la liste LEE pour retourner sa réponse : oui ou non. Cet algorithme est laissé aux autorités sanitaires.

Decentralized Privacy-Preserving Proximity Tracing (DP-3T)

Le 3 avril 2020, une équipe internationale de 26 chercheurs et dirigée par le professeur Troncoso a publié un whitepaper sur le protocole Decentralized Privacy-Preserving Proximity Tracing (DP-3T) afin de faciliter le suivi des contacts tout en préservant la vie privée. Il y a en réalité 2 variantes de ce protocole, le compromis étant entre la préservation de la vie privée vs le volume de données à télécharger et traiter.

Installation et gestion de l’identité

Le téléphone génère une clé privée personnelle quotidienne SK_t (où t est le jour) qui sert ensuite à dériver les identifiants temporaires (EphID) qui seront broadcastés (c’est-à-dire diffusés localement) par Bluetooth.

Une fois la première clé générée, la nouvelle clé est générée le jour suivant en fonction de la précédente : S_{t+1} = H(S_t)

Au renouvellement de SK_t, les EphIDs sont régénérés. Il en faut (24*60) / l, où l représente la durée de vie d’un identifiant éphémère (non fixé dans l’article). Les clés SK_t sont conservées pendant 14 jours.

Détection des contacts

Chaque téléphone émet son identifiant temporaire du moment. Quand un tel message est reçu par un autre téléphone, celui-ci enregistre l’identifiant temporaire et quelques autres informations (comme l’heure, le RSSI, …).

À noter que chaque téléphone n’émet pas directement son identifiant individuel courant, mais une part d’un secret dit “partagé” (dont il faut plusieurs parts pour récupérer le secret). Le téléphone en réception devra donc être à proximité de l’émetteur pendant un certain temps pour en récupérer l’identifiant.

Cela permet notamment d’éviter la collecte automatisée dans un lieu de grande circulation, où il est de toute façon moins praticable de réaliser un suivi d’épidémie.

L’utilisateur infecté

Quand une autorité sanitaire confirme que l’utilisateur est infecté, il peut alors téléverser, avec son accord explicite, sa clé SK_t correspondant à la clé du 1er jour probable d’infection, la fenêtre d’infection étant laissée aux autorités sanitaires. Cela peut être forcé, par exemple à 14 jours avant la détection, ou bien en discutant avec le patient où il se met d’accord avec l’autorité sur la date de démarrage de l’infection.

Rappelons qu’à partir de cette clé, n’importe qui peut calculer les clés des jours suivants.

Contact tracing

Chaque application se voit notifiée par le serveur de l’ensemble des nouvelles clés reportées, à partir desquelles chaque application peut calculer les EphIDs qui ont été émis par les téléphones infectés. Un algorithme définit par les autorités détermine alors un niveau de risque de l’utilisateur, et choisit (ou non) de le notifier.

Cette approche est appelée low-cost dans l’article, du fait que la majorité des données sont recalculées en local. Une alternative est proposée où le serveur calcule lui-même les EphIDs qu’il insère dans une base de données probabiliste compacte qu’il distribue ensuite. Cela permet d’obtenir d’autres propriétés et de contrer certaines attaques, cependant cela dépasse le cadre de cet article.

À signaler que le consortium a indiqué qu’il s’appuierai sur les API proposées par Apple+Google, habile transition.

L’union improbable : Apple+Google

Une fois n’est pas coutume, le chantre auto-proclamé de la privacy (Apple) a décidé de s’associer avec le chantre non-avoué de la collecte des données (Google) (bon, ok, c’est pour la tournure de style car ils sont loin d’être les seuls) afin d’élaborer un protocole de contact tracing.

En préambule, rappelons que Apple+Google NE proposent PAS d’applications, mais uniquement des APIs pour en faciliter la création. La documentation explique le protocole et ses principes, en crypto et au niveau Bluetooth. Leur approche s’inspire fortement de DP-3T.

Cela permet de se rendre compte de l’importance des API dans notre monde. En effet, une autorité (de santé, un gouvernement, etc.) qui souhaite développer une application de traçage devra se conformer aux choix faits par les 2 géants. Et l’un d’eux est particulièrement clivant : ils ont opté pour une approche décentralisée.

Installation et gestion de l’identité

Dans la mesure où il n’y a pas d’application, il n’y a pas d’enregistrement. Toutefois, la gestion de l’identité est fournie. Elle passe par la création d’une clé de traçage (Tracing Key) sur le téléphone.

Cette clé sert à dériver des clés de traçage quotidiennes (Daily Tracing Keys), toujours sur le téléphone. Chacune de ces clés a une durée de vie de 24h.

Il y a les clés de diagnostic (Diagnosis Key). Il s’agit d’un sous-ensemble des Daily Tracing Keys une fois qu’une personne a été détectée comme contaminée.

Enfin, il y a aussi des Rolling Proximity Identifier, identifiants temporaires qui changent toutes les 15 minutes, et qui sont dérivés des Daily Tracing Keys. Ce sont ces identifiants qui seront émis par le téléphone via Bluetooth.

Détection des contacts

Le traçage est très simple. Via le Bluetooth et le service associé, le Rolling Proximity Identifier du moment est émis par le téléphone.

Quand une application reçoit un tel message, elle se contente de sauvegarder l’identifiant. Apple et Google conseillent de conserver également une heure (timestamp) et le RSSI

L’utilisateur infecté

Quand une personne est détectée comme étant contaminée, elle upload quelque part (ce n’est pas précisé et c’est normal) ses Diagnosis Keys pour la période précédant le diagnostic.

Ces clés sont juste des nombres aléatoires (ou presque) chargés par un device. Quelqu’un qui opère la base de données ou la regarde n’y voit que des nombres sans savoir à quoi / qui ils se rattachent.

Contact tracing

Chaque application récupère la liste des identifiants infectés sur son téléphone (les Diagnosis Keys mis sur une base de données), la compare à la liste des Rolling Proximity Identifiers croisés et stockés sur le téléphone et détermine selon un algorithme, qui n’est pas non plus spécifié (rôle de l’éditeur de l’application, donc implicitement une autorité sanitaire), le facteur de risque du propriétaire du téléphone.

Si le risque est élevé, un message apparaît incitant à aller se faire détecter.

Conclusion : alors, tous fliqués ?

La grosse question technique est : faut-il une base centralisée ou non ? Aucune ne protège de toutes les attaques. Techniquement, la complexité est identique. Donc, le choix relève du politique, au sens de ce qui concerne le citoyen, et des risques que chaque solution incorpore.

On le voit avec le cas d’Apple+Google, ce choix peut être fortement guidé par la technologie. Or, le politique — l’homme ou la femme cette fois — ne s’en rend malheureusement peut-être pas compte. Sans parler de chaque pays qui développe sa solution, comme si le virus s’arrêtait aux frontières alors que tout le monde sait que ça ne marche qu’avec la radioactivité.

De plus, les multiples scénarios d’attaques sont rarement considérés correctement. Par exemple, l’État qui se sert de la base de données pour fliquer ses citoyens. Ce risque existe, évidemment, mais dans les pays où il est réel, les gouvernements n’ont pas attendu cette opportunité pour le faire. Dans les démocraties plus soucieuses du sujet, l’enjeu est que sous prétexte de sécurité (sanitaire cette fois, pas contre-terroriste), on rogne encore un peu plus sur les libertés fondamentales.

Alors, faut-il une application de traçage ? Si elle peut aider les épidémiologistes, si elle peut aider à détecter et contenir les pandémies, alors la réponse est évidemment oui pour ma part.

Mais pas n’importe comment, à n’importe quel prix.

Le traçage anonyme, dangereux oxymore présente de nombreuses attaques, réalistes. Quelle que soit la solution retenue, elle ne sera pas parfaite et exposera à des attaques. Et je préfère largement assumer (c’est à la mode) les risques d’attaques potentielles et souvent à petite échelle, que perdre des libertés ou la santé.

Au-delà de ces risques d’usage malveillants, il y a des risques inhérents à la mise en place d’un tel système : de telles bases de données qui se partagent au niveau Européen, mises en place sur des infrastructures montées à la hâte, quel sera le coût d’une fuite de donnée ? L’histoire récente nous présente des exemples d’acteurs qui seraient prêts à déployer beaucoup de moyens pour collecter des données précises sur le graphe social à l’échelle d’un pays entier. Pour ne pas tomber dans le Cambridge Analytica, il nous faut certes agir vite, mais agir avec prudence…

Et comme toujours quand la sécurité est concernée, il n’y a pas de solution parfaite. Il faut faire des compromis et trouver des équilibres, avec des moyens limités et un temps court pour la mise en place. Une chose est sûre, je n’aimerais pas être à la place des gouvernants.

Pour le moment, l’application de traçage occupe les débats, intéressants au demeurant, au moins pour moi sans quoi je n’aurais pas écrit cet article.

Mais est-ce une aide réellement utile ? À l’heure de la rédaction de cet article (NDLA : le 22 avril), la pandémie reprend à Singapour, certains pointant le fait que de nombreux travailleurs immigrés n’utilisent pas l’application, d’autres que le traçage est trop incomplet pour être utile.

Quoiqu’il en soit, n’oublions pas non plus que la technologie ne peut qu’aider, à faciliter ou accélérer les solutions (vaccins, détections, etc.) : le contact tracing sur nos téléphones n’est pas la solution unique à la pandémie. Juste une aide le temps d’apprendre à être moins bête avec le monde qui nous entoure. Et il y a peut-être d’autres approches, moins technologiques – par exemple, des campagnes de tests plus larges comme ce qu’on a vu en Allemagne et dans certains pays asiatiques, ou des mesures sociales et humaines qui aideront au moins autant.

Update du 25/04/2020

Le 22/04/2020, L’Académie Nationale de Médecine a rendu son avis favorable à l’utilisation du smartphone

[…] Alertés, les contacts asymptomatiques pourraient alors être prévenus par sms, se faire dépister par un test PCR, être pris en charge au plus tôt et se confiner.

Cela suppose que le patient testé positif accepte, sur une base de volontariat, de se déclarer positif et de diffuser cette information aux utilisateurs de l’application qu’ils auraient pu rencontrer. Dans le cas de l’application StopCovid, il est prévu qu’il n’y aurait pas de demande de données personnelles (état civil, numéro de téléphone, géolocalisation…). Cependant, les données anonymes de géolocalisation recueillies au cours de ce protocole pourraient être utilisées pour suivre l’évolution de l’épidémie sur l’ensemble du territoire national. Ce traitement statistique et anonyme des données a été accepté par la CNIL (10 avril 2020).

Le 24/04/2020, la Commission Supérieure du Numérique et des Postes a rendu son avis sur les conditions de mise en oeuvre de StopCovid. Si le développement d’une telle application pose quelques questions techniques qui font qu’une telle application est livrable en quelques semaines, les plus gros défis ne sont pas là, mais relèvent du politique (et de l’administratif chez nous), qui est sur une échelle de temps bien plus longue. Or, en état d’urgence sanitaire, est-ce le bon référenciel de temps ? En résumé les recommandations de la commission :

1. création d’une structure de supervision et de gouvernance comprenant des parlementaires ;
2. publication d’une étude d’impact afin de s’assurer de l’efficacité sur le plan sanitaire de l’application ;
3. communication efficace sur l’application ;
4. lancement d’une concertation avec les organisations syndicales et patronales et le secteur de la médecine du travail.

Remerciements

Un énorme merci à Alexis Challande (dm) et Matthieu Daumas (plcp), mes
collègues, pour les échanges et pour la relecture express.