Vous êtes perdu dans les différents initiatives et protocoles – centralisés et/ou décentralisés – autour des applications de contact tracing et plus particulièrement StopCovid en préparation ? On vous explique calmement de quoi il s’agit pour bien comprendre les avantages et inconvénients de chacune des solutions.

Avant d’entrer dans le vif du sujet, un rappel important. Nous parlons bien ici de protocoles pour des applications de suivi de contacts, pas de l’application StopCovid annoncée par le gouvernement, qui n'existe de toute façon pas pour le moment. Et même si des déclarations ont déjà été faites, en matière de logiciel (open source), seul le code fait foi.

« Il y a eu des promesses sous la forme de quelques mots (« anonyme », « sur la base du volontariat ») mais aucun détail technique n'a été publié. À l'heure actuelle, il n'est donc pas possible de dire quoi que ce soit de sérieux sur cette application spécifique », rappelle à très juste titre le spécialiste Stéphane Bortzmeyer. 

De plus, si des travaux sont en cours, rien n'a encore été décidé. Peut-être que StopCovid sera mise en œuvre, peut-être que non. Un débat aura lieu à l'Assemblée nationale la semaine prochaine, suivi d'un vote. Une décision finalement prise par le gouvernement après les critiques de parlementaires. Le Conseil National du Numérique a également été saisi.

D’un protocole à son implémentation, gare aux détails

Il faut dire que le projet ne fait pas vraiment l'unanimité. Bortzmeyer, s’appuyant notamment sur les arguments de la Quadrature du Net, de Framasoft, Paula Forteza et Baptiste Robert, affirme que « ce projet d'application de suivi des contacts semble davantage motivé par le désir d'agir, de faire quelque chose, même inutile, désir qui est commun en temps de crise, plutôt que par un vrai problème à résoudre ». Une problématique sur laquelle nous nous étions également penchés.

• Covid-19 : pourquoi le « contact tracking » ne fonctionnera (probablement) pas

La tentation est d'ailleurs forte sur ce sujet de ne réagir qu'en « techno-gaga », vantant le solutionnisme technologique et/ou les plateformes mises en place par des géants américains comme Apple et Google. Et de penser que toute initiative portée par l'État serait de fait très positive ou au contraire vouée à l'échec. Mais tout cela demande plus de nuance.

Car il est important de rappeler que le problème qu'il faut régler n'est pas que technologique. Au-delà des protocoles dont il est ici question, ce sont leurs implémentations qui peuvent parfois cacher quelques « surprises ». Les exemples sont nombreux par le passé (voir ici, là et encore ici… et ce n’est que la partie visible de l’iceberg).

Si le projet StopCovid venait à être acté et finalisé en France et, quel que soit le protocole qu'il utilisera, il faudra donc étudier de près le code, son implémentation et les moyens mis en place par le Gouvernement pour s'assurer que le plus grand nombre utilisera un tel dispositif, ce qui est une part importante du succès d'une telle opération. Ce, sans dépasser les bornes, la CNIL ayant déjà posé quelques barrières en rappelant les règles à suivre en la matière.

• « Contact tracing » : on vous explique les différents protocoles et initiatives
• « Contact tracing » : les limites du Bluetooth, les risques sur la vie privée et l’anonymat
• « Contact tracing » : la nécessité (oubliée) de milliers d'enquêteurs

PEPP-PT, DP-3T, PACT et ROBERT : un peu de vocabulaire et de contexte

Dans le petit monde du contact tracing, on voit passer de nombreux acronymes, aux descriptifs et ramifications souvent abscons pour le commun des mortels. Voici quelques définitions et présentations des principales initiatives, sur lesquelles nous reviendrons plus en détail : 

• PEPP-PT ou Pan European Privacy Preserving Proximity Tracing est, comme son nom l’indique, un projet européen regroupant plus de 130 scientifiques de huit pays (Inria en est un membre fondateur) : « L’objectif est de construire une ligne de front commun sur les composantes numériques essentielles de la lutte mondiale contre Covid-19 ». Ce projet souhaite donc « proposer des technologies et des standards pour une approche de suivi numérique des contacts de proximité (contact tracing) fondée sur le consentement, l’anonymat et le respect de la vie privée, en totale conformité avec la réglementation RGPD ». Il regroupe donc plusieurs idées et n’est pas l’esclave d’un seul protocole.

• DP-3T ou Decentralized Privacy-Preserving Proximity Tracing est un protocole décentralisé ouvert de contact tracing via Bluetooth Low Energy (BLE) : « Nous développons le protocole et l'implémentons dans une application et un serveur open source », peut-on lire sur son dépôt GitHub. DP-3T s’inscrit dans le cadre du projet PEPP-PT, mais les deux ne doivent pas être confondus : « DP-3T n'est pas le seul protocole sous l’ombrelle PEPP-PT », qui abrite également d’autres projets, avec une approche qui peut être totalement différente (centralisée par exemple).

• PACT ou Private Automated Contact Tracing est un autre protocole très proche de DP-3T sur son principe de fonctionnement. Stéphane Bortmeyzer explique que « PACT et DP3T ont assez peu de différences. Les principales portent sur le mécanisme de génération des identifiants, PACT déduit une série d'identifiants d'une graine renouvelée aléatoirement (on stocke les graines, pas réellement les identifiants), alors que DP3T déduit chaque graine de la précédente, des choses comme ça ». PACT est ouvert et propose une approche décentralisée. 

• ROBERT ou ROBust and privacy-presERving proximity Tracing est le protocole dévoilé par Inria ce week-end. Ce protocole mise lui aussi sur le respect de la vie privée, mais avec une approche différente de DP-3T (et donc de PACT) puisqu’il est question d’une « autorité centrale » à laquelle il faudra accorder sa confiance. Ce projet s’inscrit lui aussi dans le cadre de l'initiative européenne PEPP-PT. 

• L'initiative commune d'Apple et Google. Les deux géants, ennemis sur le mobile, se sont associés afin de proposer une approche commune face à la crise sanitaire : « Il ne s'agit à proprement parler pas d'un protocole de suivi de contacts mais d'un ensemble de services dans les systèmes d'exploitation (iOS pour Apple et Android pour Google), pour aider les applications de suivi », explique Stéphane Bortzmeyer. Le fonctionnement technique est tout de même assez détaillé, jusqu’à la manière dont les clés et les partages en cas de contact sont gérés (nous y reviendrons).

Notez que les relations entre PEPP-PT et DP-3T sont « compliquées » en ce moment. Coindesk relevait en effet que la mention de DP-3T avait discrètement et sans explication été retirée de la page de présentation de PEPP-PT.

De plus, des promoteurs de l'approche décentralisée affirmaient ne pas pouvoir consulter le code des applications du PEPP-PT, et qu'ils n'avaient pas non plus été invités à participer à une réunion de travail des différents partenaires du consortium. Dans la foulée, plusieurs chercheurs se désolidarisaient de PEPP-PT, certains allant jusqu'à le qualifier de « cheval de Troie » privilégiant les intérêts d'industriels et de gouvernements promoteurs de la seule approche centralisée, comme le raconte le chercheur en cryptographie Nadim Kobeissi. Un sujet sur lequel nous reviendrons.

DP-3T vs ROBERT : des différences importantes

Pour bien comprendre la différence entre les approches de DP-3T/PACT d’un côté et ROBERT de l’autre, détaillons sommairement leur principe de fonctionnement.

Dans le cas de DP-3T, les smartphones des utilisateurs génèrent régulièrement des clés privées. Lorsque des utilisateurs sont au « contact » au sens épidémiologique du terme (la distance et les conditions restent encore à définir), ils s’échangent mutuellement des clés via Bluetooth et les enregistrent (sous la forme d’un historique).

Si une personne est testée positive au SARS-CoV-2 elle doit donner son accord pour diffuser anonymement cette information depuis son téléphone. Elle est envoyée à un serveur distant, qui se charge ensuite de les redistribuer à tous les utilisateurs (broadcast). Dans le cas de ROBERT, l’approche est différente. 

Principe de fonctionnement de DP-3T (à gauche) et celui de ROBERT (à droite)

L’utilisateur envoie une demande d’inscription à une « autorité centrale », qui génère des pseudonymes – Inria les présente comme des « "faux noms" temporaires associés à l'application de l'utilisateur » – et les envoie au smartphone.

Lors d’un « contact », les utilisateurs se partagent leurs pseudonymes. Lorsqu’une personne est testée positive, elle peut décider d’autoriser l’envoi des pseudonymes des personnes avec qui elle était en « contact » à la fameuse autorité centrale (les pseudonymes de la personne infectée restent dans son téléphone). Ils sont alors marqués comme « à risque ».

La dernière phase est la suivante : « pour vérifier [qu’un utilisateur] a été en contact avec des personnes diagnostiquées positives pour le virus Covid-19 au cours des derniers jours (par exemple deux semaines), son application envoie son pseudonyme actuel […] à l’autorité centrale [la période reste encore à définir, ndlr]. Celle-ci retrouve l’application correspondant à ce pseudonyme et vérifie si elle est mentionnée comme étant "à risque". Il est important de noter que l'autorité ne peut pas identifier les utilisateurs correspondant à ce pseudonyme, car cette information n’existe pas ».

Notez que l’approche d’Apple et Google colle plus au fonctionnement de DP-3T que de ROBERT : les clés sont générées sur le smartphone et le serveur central diffuse la liste des clés des personnes infectées. Le PDG d'Inria le reconnait dans sa tribune : « Ce système a par ailleurs l’avantage d’être facilement permis par l’API à venir (mi-mai) » contrairement à ROBERT.

• Covid-19 : comment Google et Apple veulent généraliser le traçage des contacts par Bluetooth

Avec ROBERT, « le serveur central a bien plus de pouvoir et de connaissances »

Bref, dans le cas de DP-3T le serveur sert uniquement de passe-plat pour diffuser à tout le monde la liste des clés anonymes (générées sur les smartphones) de personne identifiée comme positive au SARS-Cov-2, à charge pour les applications sur les smartphones de faire le recoupement et d’afficher une alerte le cas échéant.

L’approche de ROBERT est différente : l’autorité centrale se charge de générer des pseudonymes pour l’ensemble des utilisateurs et récupère ceux des personnes qui ont été au « contact » d’une personne testée positive (sans que le pseudonyme de la personne infectée ne soit envoyé à l’autorité).

Avec ROBERT, le serveur central peut donc associer les pseudonymes à un smartphone et dispose de la liste des pseudonymes potentiellement en contact, mais pas du pseudonyme des personnes infectées. Plus que de l’anonymat, il s’agit donc d’un pseudonymat.

Pour Stéphane Bortzmeyer « globalement, le serveur central a bien plus de pouvoir et de connaissances dans ROBERT ». Il en profite pour tordre le cou à une croyance populaire : « La question est souvent discutée de manière binaire, avec centralisé contre décentralisé, mais le choix est en fait plus compliqué que cela ».

Si le spécialiste des réseaux approuve la transparence des discussions autour de ROBERT (qui se déroulent sur GitHub), il regrette que certains points ne soient pas plus abordés : « Son analyse de sécurité est très insuffisante, comme le balayage de tous les problèmes liés au serveur central en affirmant qu'il sera "honnête et sécurisé" ». 

ROBERT part du principe que le serveur central est « honnête mais curieux »

Dans la présentation technique du protocole ROBERT, les chercheurs expliquent en effet que « l'autorité qui gère le système […] est "honnête mais curieuse" », c’est-à-dire qu’elle suit le protocole « honnêtement » sans modification ni dispositifs d’espionnage. De son côté « curieuse » désigne le fait « d'utiliser les informations collectées à d'autres fins, par exemple pour ré-identifier les utilisateurs ou pour déduire leurs graphiques de contact ».

Les chercheurs d’Inria balaient cette inquiétude d’un revers de la main indiquant que « nous supposons que le système principal est sécurisé et régulièrement audité et contrôlé par des autorités externes de confiance et neutres (telles que les autorités de protection des données et les agences nationales de cybersécurité) ». Pour résumer, le niveau de sécurité de ce protocole correspond au niveau de confiance que vous accordez au responsable du serveur central. Selon les cas, cela peut être un État, un organisme gouvernemental, une société privée, etc.

Dans le cas de DP-3T tout n’est pas rose non plus, une publication scientifique explique que certaines mesures de protection de la vie privée « peuvent avoir l’effet inverse de ce qu’elles sont censées faire ». Par exemple, « les personnes malades et déclarées peuvent être deanonymisées et des rencontres privées peuvent être révélées ».

Inria (promoteur de ROBERT) y va aussi de sa petite pique envers le schéma de base utilisé par DP-3T, sans pour autant le citer directement : « C’est un système que l’on peut présenter comme fortement décentralisé… tout comme on peut le présenter comme une centralisation décentralisée : il y aura ainsi, sur chaque smartphone, la liste de l’ensemble des crypto-identifiants des personnes diagnostiquées comme positives ».

Bref, chaque camp joue de ses avantages et ses défauts. « En tout état de cause, c’est le choix d’un État de décider d’utiliser ou non le protocole qu’il désire en fonction de sa politique. Et c’est notre responsabilité de scientifique de lui procurer les moyens de ce choix », rappelle justement Bruno Sportisse (PDG d’Inria).

iOS/Android : la question de l’accès au Bluetooth (en arrière plan)

Au-delà de l’aspect purement technique des différentes approches, il y aura d’autres barrières à lever. Pour que les applications de contact tracing fonctionnent correctement il faut en effet des tests en masse, y compris sur des personnes asymptomatiques, et des enquêteurs (nous y reviendrons dans la suite de notre dossier).

Il faut également pouvoir laisser le Bluetooth LE activé et accessible en permanence dans l’application, ce qui n’est pas gagné à l’heure actuelle. En effet, cela n'est en général pas autorisé par les OS mobiles pour éviter tout détournement à des fins publicitaires ou d'espionnage par exemple.

À Singapour par exemple, plusieurs utilisateurs de TraceTogether, qui sert de matrice aux autres projets de ce type, ont en effet déploré qu'elle ne fonctionnait pas ou mal, sur les iPhone.

Apple refuse ainsi aux applications d’accéder au Bluetooth si elles sont en arrière-plan… sauf à passer par sa solution maison développée conjointement avec Google. C’est du moins ce que laisse penser une audition de Cédric O (secrétaire d'État chargé du Numérique) devant la commission des lois, comme le rapporte Public Sénat.

« Nous avons besoin qu’Apple modifie cet élément […] faute de quoi l’application européenne telle qu’elle a été conçue, ne pourra pas fonctionner correctement », explique-t-il. Une demande a été déposée, visiblement sans réponse pour le moment : « Ce que nous leur demandons, et j’ose espérer qu’ils y répondront favorablement, c’est de faire en sorte d’apporter les modifications techniques impératives pour que les États puissent mettre en place les applications sanitaires qui peuvent être utiles à la lutte contre le virus ».

La société est loin d'être la seule à restreindre voire interdire ce tracking via Bluetooth : Anne van Rossum, le créateur d'une start-up développant des produits basés sur le Bluetooth, déplore ainsi (et entre autres choses) que de nombreuses autres marques de smartphones bloquent elles aussi le Bluetooth en arrière-plan, de sorte d'économiser la batterie, d'Huawei à Xiaomi en passant par Samsung et OnePlus, notamment (voir cette liste de dontkillmyapp.com).

Face à Apple et Google, l’État n’a « pas vraiment le choix » 

Une source du secteur des télécoms explique à BFMTV que l’État n’a aujourd'hui « pas vraiment le choix » face à la proposition d'Apple et Google. Car s'il ne l'utilise pas, StopCovid ne fonctionnera pas, ou mal, sur leurs appareils. Ces entreprises (et les constructeurs) sont ainsi les seuls à pouvoir accorder des « dérogations » aux applications.

Apple et Google ont également précisé qu'elles ne fourniraient leurs API aux autorités sanitaires qu'à condition que leurs applications soient décentralisées, afin d'empêcher les gouvernements de pouvoir disposer de bases de données centralisées de personnes (potentiellement) contaminées.

Auditionné à huis clos par la commission de lois du Sénat lundi, Cédric O aurait selon Le Figaro expliqué que « si Apple n’accepte pas de modifier ses critères techniques, l’application que nous construisons avec nos partenaires européens, notamment allemands, suisses et bientôt italiens, anglais et monégasques, ne sera jamais prête pour le 11 mai ».

De plus,  l'application ne pourra être efficacement installée sans l’aide d’Apple et de Google. Problème, la piste privilégiée pour le moment pour StopCovid n’est pas compatible avec cette solution. Sans parler de tous les citoyens qui ne disposent pas d'un smartphone, ou d'un modèle équipé du Bluetooth LE.