Pouvoir suivre les malades du Covid-19 est l’une des conditions nécessaires au déconfinement, mais pas à n’importe quel prix. La protection des données personnelles est nécessaire si l’on veut une forte adhésion de la population. L’architecture technique choisie est, de ce point de vue, fondamentale. On fait le point sur la technologie qui fait notamment fonctionner l’application qui sera bientôt lancée par les autorités françaises, Stop Covid.
Quel est le but du « contact tracing » ?
Le « contact tracing » est une méthode sanitaire qui permet aux agences de santé de savoir avec qui une personne infectée a été en contact. Le but est de pouvoir alerter ces personnes à risque et d’assurer leur prise en charge, par exemple en les isolant. Ce qui aurait pour effet de juguler la propagation de l’épidémie. Ce type d’enquête peut se faire manuellement, par l’intermédiaire de personnels sanitaires. Mais cela prend beaucoup de temps et ne serait pas très efficace dans le cadre d’une maladie comme le Covid-19, qui se propage très vite. D’où l’idée d’utiliser une application mobile. Le smartphone, en effet, est bourré de capteurs et pourrait révéler ce type d’informations.
Sur quoi repose le « contact tracing » par appli mobile ?
Il y a beaucoup de solutions envisageables. La plus évidente serait d’utiliser le GPS, mais c’est très risqué, car les données de localisation sont très sensibles. En Europe et aux États-Unis, il existe désormais un consensus sur l’utilisation du Bluetooth, une technologie de communication à courte distance intégrée dans chaque terminal mobile. Le principe est le suivant : en permanence, l’application de chaque utilisateur diffuse par Bluetooth des codes anonymes et reçoit ceux des personnes autour de lui. Tous ces codes sont stockés pendant un certain temps sur les smartphones, par exemple 14 jours.
Le jour où l’un des utilisateurs se déclare infecté, l’application transmet au serveur de l’agence de santé les codes anonymes diffusés ou reçus depuis le moment où l’utilisateur était contagieux. Il suffit alors de voir sur quels smartphones ces codes ont été stockés et d’évaluer le risque de contagion à partir de la distance et de la durée d’exposition. Ce qui permettra ensuite d’envoyer les alertes. L’avantage d’un tel mécanisme, c’est qu’il ne repose sur aucune donnée de localisation. Les ondes Bluetooth servent uniquement à mesurer la distance entre les personnes. La durée d’exposition peut être évaluée à partir du nombre de codes reçus. Par ailleurs, l’identité des personnes infectées n’est jamais révélée vis-à-vis des personnes à risque, et inversement.
Existe-t-il déjà un standard de « contact tracing » ?
Beaucoup de projets ont été lancés, mais aucun n’est encore finalisé. La proposition d’Apple et de Google a néanmoins la chance de devenir un standard de fait, en raison du poids économique des acteurs. À eux deux, ils couvrent la quasi totalité du marché des terminaux mobiles, ce qui ouvre la porte à une interopérabilité mondiale.
La particularité de leur solution est qu’elle est décentralisée. Les codes anonymes sont générés sur les terminaux et la mise en correspondance avec les codes d’une personne infectée se fait également en local. Le serveur de l’agence de santé ne sert que de passe-plat, pour transmettre les codes de la personne infectée aux autres utilisateurs. L’agence de santé ne peut donc pas identifier les personnes à risque. Quant aux serveurs d’Apple et de Google, ils ne reçoivent aucune donnée.
Mais techniquement, comment ça marche ?
Apple et Google proposent de mettre à disposition des agences de santé des interfaces de programmation qui prennent en charge la génération des codes à diffuser, le stockage des codes reçus et la mise en correspondance des codes de personnes infectées. Lorsque le « contact tracing » est activé, une clé unique, aléatoire et spécifique au terminal appelée « Tracing Key » (TK) est générée.
Un algorithme de hachage est utilisé pour dériver chaque jour une autre clé, baptisée « Daily Tracing Key » (DTK). Celle-ci sert, par l’intermédiaire d’un second algorithme de hachage, à générer les codes anonymes appelés « Rolling Proximity Identifier » (RPI). Ces derniers seront diffusés toutes les 200 ms et changent environ toutes les 10 minutes, tout comme l’adresse MAC du module Bluetooth.
Le hachage est une fonction mathématique à sens unique qui rend impossible de retrouver l’origine à partir du résultat. Quelqu’un qui arrive à intercepter des codes anonymes et des clés quotidiennes ne pourra pas retrouver la clé unique. L’identité de l’utilisateur est donc protégée.
Si une personne a été testée positive, les clés DTK correspondant à sa période de contagiosité sont transmises au serveur de l’agence de santé où les autres utilisateurs pourront le télécharger. Chaque smartphone pourra ensuite régénérer à partir de ces clés DTK les codes RPI de la personne infectée et les comparer avec ceux qui ont été reçus et stockés. Le cas échéant, l’application génère une alerte.
Existe-t-il d’autres propositions similaires ?
Il en existe au moins deux : DP3T, un protocole créé par un groupe des chercheurs européens, et PACT, un protocole créé par un groupe de chercheurs américains. Le projet européen semble néanmoins le plus avancé. Celui-ci propose d’ailleurs plusieurs designs, en fonction du niveau de protection des données personnelles. La proposition d’Apple et de Google correspond, à peu de choses près, au premier niveau de DP3T, appelé « low cost ». « Les différences sont mineures et résident essentiellement dans la manière de générer les clés et les codes à diffuser. Mais sinon, c’est extrêmement aligné avec ce que nous proposons. Et d’ailleurs, nous allons nous caler sur les spécifications d’Apple et Google dès qu’elles seront disponibles », nous explique Édouard Bugnion, co-auteur de DP3T, professeur et vice-président à l’École polytechnique fédérale de Lausanne et responsable pour le numérique pour le comité scientifique Covid en Suisse.
L’application StopCovid s’appuiera-t-elle sur l’API d’Apple et Google ?
A priori non. L’INRIA, qui est responsable du développement de StopCovid, vient de publier à son tour les premières spécifications de son protocole de « contact tracing », baptisé ROBERT (ROBust and privacy-presERving proximity tracing). Développé en partenariat avec l’institut allemand Fraunhofer Heinrich Hertz, celui-ci s’appuie sur une architecture dite centralisée, incompatible avec la proposition d’Apple et Google. Les codes anonymes ne sont pas générés par le terminal, mais par le serveur de l’agence de santé qui les transmet régulièrement aux utilisateurs.
Contrairement à DP3T ou à la proposition Apple/Google, la création des codes ne se fait pas par un algorithme de hachage, mais par un algorithme de chiffrement symétrique. Parmi les informations encodées dans chaque code, on retrouve, notamment, un identifiant unique lié à l’utilisateur. Quand une personne est testée positive, son smartphone va renvoyer au serveur les codes anonymes reçus pendant la période de contagiosité. Le système central va ensuite déchiffrer ces codes pour récupérer les identifiants uniques qui seront ajoutés à la liste des personnes à risque. Ces derniers recevront ensuite une alerte.
À noter, enfin, qu’Orange développe également une application de « contact tracing » fondée sur le Bluetooth. Les détails techniques ne sont pas connus, mais le PDG Stéphane Richard a salué l’initiative d’Apple et de Google.
Une telle architecture centralisée, présente-t-elle un risque ?
Oui, estiment les chercheurs de DP3T. Dans une architecture centralisée, le serveur de l’agence de santé détient beaucoup plus d’informations sur les utilisateurs. En récupérant les codes reçus des personnes infectées, le serveur pourrait — au bout d’un moment — reconstruire le graphe social de ces personnes, c’est-à-dire le réseau de leurs fréquentations. Le serveur pourrait également identifier les personnes infectées et les personnes à risque, dans la mesure où il leur attribue des identifiants uniques.
Pour limiter ces risques, l’INRIA a ajouté quelques garde-fous. Ainsi, les codes reçus d’une personne infectée ne sont pas transmis en un seul bloc au serveur de l’agence de santé, mais passent d’abord par un serveur intermédiaire où ils sont mélangés avec les codes reçus d’autres personnes infectées. Une telle lessiveuse empêche la reconstruction du graphe social… à condition que l’on puisse faire confiance à ce serveur intermédiaire.
Quant à l’identité des utilisateurs, elle serait protégée par le fait que le système ne manipule que des identifiants certes uniques, mais anonymes. Aucune donnée personnelle n’est traitée dans ce protocole. Au final, dans une architecture centralisée, il semble que la protection des données personnelles repose quand même beaucoup sur la confiance accordée au serveur.
La technologie Bluetooth est-elle vraiment adaptée?
Tous les experts s’accordent à dire que ce ne sera pas parfait. La mesure de distance en Bluetooth a une précision de l’ordre de quelques mètres, ce qui est finalement assez énorme pour une maladie qui peut se transmettre à une distance de trois ou quatre mètres. Par ailleurs, le Bluetooth passe à travers les cloisons et les murs. Il y aura donc forcément de faux positifs.
Interrogé par Le Monde, Christian Bachmann, expert de la mesure des distances par Bluetooth, estime que le Bluetooth est « la meilleure réponse pragmatique au problème posé ». D’autres technologies plus performantes existent, comme les ondes large bande (UWB) -notamment proposées par Apple sur ses smartphones récents- mais elles ne sont pas aussi omniprésentes que le Bluetooth. En tous les cas, le « contact tracing » ne devrait pas pomper la batterie du terminal, car la technologie utilisée sera le Bluetooth Low Energy.
Pourra-t-on hacker le « contact tracing » ?
Le risque premier, c’est qu’un utilisateur se déclare positif dans l’application alors qu’il ne l’est pas, générant ainsi quantité de fausses alertes. Pour contrer ce type de malveillance, il suffit que la déclaration soit soumise à une autorisation de la part de l’agence de santé, par exemple par l’intermédiaire d’un code à usage unique.
Néanmoins, certains risques sont impossibles à éliminer. Dans la diffusion broadcast envisagée, les codes ne sont pas authentifiés, ce qui ouvre la porte à des attaques par relais ou par rejeu ainsi qu’à des tentatives de désanonymisation.
Exemple : un pirate pourrait capter des codes à la ronde et les renvoyer à un autre endroit, générant ainsi de faux contacts. Et ces faux contacts peuvent se transformer, le cas échéant, en fausses alertes. Pour contrer ce type de malveillance, on pourrait imaginer que l’échange des codes se fasse de manière connectée entre les terminaux, mais c’est très complexe. Dans le protocole de l’INRIA, les codes à diffuser ne sont valables que pendant une certaine durée, ce qui limite ce type d’attaque.
Autre exemple : un attaquant pourrait collecter en permanence les codes à la ronde et, en même temps, collecter d’autres données des personnes présentes (un identifiant réseau, des prises de photos, etc.). Le jour où certains de codes sont marqués comme positifs, il pourrait ainsi réussir à savoir de qui il s’agit. Mais ce genre d’attaque est finalement assez compliqué et peu probable.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
