DP3T, PACT et consorts : les protocoles de contact tracing se multiplient
Le contact tracing est une méthode visant à identifier toutes les personnes ayant été en contact avec une personne infectée par une maladie afin de pouvoir identifier et prévenir au plus vite les personnes potentiellement infectées. Si cette technique a déjà été mise en œuvre par le passé avec succès, l’utilisation des smartphones pour proposer des applications de contact tracing automatisé est aujourd’hui envisagée par de nombreux gouvernements. Le gouvernement français a ainsi annoncé travailler sur un projet d’application de ce type pour accompagner le deconfinement, prenant exemple sur de nombreux autres pays ayant mis en œuvre ce type de solution ou envisageant de le faire.
Mais depuis le début du mois d’avril, les discussions portent avant tout sur la façon de mettre en œuvre ces outils de contact tracing de la manière la plus appropriée. L’Inria a présenté en fin de semaine dernière son protocole ROBERT, qui propose une approche de mise en œuvre de ce type de protocole. Mais l’Inria n’est pas la seule à plancher sur le sujet et d’autres propositions, présentant des différences d’architectures, sont également à l’étude. Parmi les autres candidats, on peut ainsi citer DP3T, un protocole soutenu majoritairement par les écoles Polytechnique de Zurich et de Lausanne, mais aussi PACT ou encore TCN.
Si proches et pourtant si différents
Ces protocoles présentent des similarités évidentes au premier abord : toutes semblent s’accorder sur l’utilisation du bluetooth et de “crypto-identifiants” (ROBERT retient cette dénomination, DP3T opte plutôt pour “EphID” pour Ephemeral ID) changeant régulièrement et permettant de protéger l’identité d’un utilisateur. Tous promettent de respecter la vie privée des utilisateurs, d’être conforme aux régulations en vigueur en la matière et d’assurer la confidentialité des données. Mais personne ne semble vraiment s’accorder sur la façon de faire.
Le point de divergence principal repose avant tout sur le caractère centralisé ou non de l’architecture. Dans une approche centralisée, le serveur central génère les crypto-identifiants attribués aux utilisateurs, puis se charge de recueillir les crypto-identifiants des personnes ayant été en contact avec une personne infectée, de réaliser un calcul sur la probabilité d’infection et de prévenir les utilisateurs, le cas échéant, d’une probable infection.
Dans une approche décentralisée, ces opérations sont réalisées sur l’appareil de l’utilisateur et les informations transmises au serveur central sont limitées au maximum. Dans le cas d’un protocole décentralisé comme DP3T par exemple, les utilisateurs génèrent eux même les crypto-identifiants sur les téléphones et les échangent via bluetooth lors d’une interaction prolongée. Lorsqu’un utilisateur est infecté, il déclare auprès du serveur central la liste des identifiants rencontrés récemment. Les autres utilisateurs vont périodiquement télécharger depuis le serveur central cette liste d’identifiants ayant rencontré une personne infectée et comparer avec la liste stockée sur leur appareil afin d’indiquer à l’utilisateur si oui on non il a pu être exposé. D’autres protocoles reposant sur des choix d’architecture similaire ont également vu le jour, tel que TCN ou encore PACT.
Ambiance au beau fixe
L’opposition entre les défenseurs d’une approche centralisée et les partisans d’une approche décentralisée s’est cristallisée dans la publication d’une lettre ouverte, signée par de nombreux chercheurs en cryptographie, dénonçant l’utilisation d’approche centralisées et le manque de transparence du consortium PEPP-PT. A cela s’ajoutent de nombreuses critiques des différents modèles, exprimées au travers de tribunes et d’articles, défections et ralliements des uns et des autres.
Ce qui pourrait apparaître comme une simple divergence d’opinion obscure entre experts a pourtant une incidence concrète sur le développement des applications de contact tracing : Google et Apple ont ainsi récemment annoncé un partenariat visant à proposer des API afin d’aider la mise en place d’applications de contact tracing. Simplement, Google et Apple penchent plutôt du coté des défenseurs des approches décentralisées : les règles pré-existantes des deux constructeurs en matière de bluetooth n’autorisent pas le fonctionnement d’applications reposant sur le protocole ROBERT. Apple et Google ont conçu une API fonctionnant pour un protocole décentralisé, et la France et l’Allemagne se retrouvent aujourd’hui contraintes de négocier avec Apple afin de pouvoir permettre le fonctionnement d’une hypothétique application française de contact tracing utilisant le protocole de l’Inria, qu’on serait presque à deux doigt de qualifier de solution souveraine.
Comme si cela ne suffisait pas, plusieurs chercheurs (dont certains de l’Inria) ont publié sur un site web des exemples de la façon dont ces applications de contact tracing, centralisées ou non, pouvaient être utilisées à des fins malveillantes. Cette série d’exemples vient mettre en lumière les risques liés au déploiement de ces technologies et les dérives possibles qu’elles pourraient occasionner. On finira donc peut-être par voir arriver l’application StopCovid promise par le gouvernement français il y a maintenant trois semaines, mais le chemin risque encore d’être long.
