(Problèmes de) sécurité du protocole TAC-WARNING
D'après le décret n°2021-157 du 12 février 2021, TousAntiCovid va intégrer un système de QR-codes dans les lieux publics, pour alerter les personnes co-exposées, c'est-à-dire les personnes s'étant trouvée dans le même lieu qu'un malade. D'après l'avis de la CNIL sur le décret, le protocole utilisé s'appelle TAC-WARNING, mais je ne trouve pas la description du protocole ni son analyse de sécurité, malgré les promesses de transparence de l'Équipe-Projet StopCovid/TousAntiCovid, et les appels répétés de la CNIL à interagir avec la communauté scientifique.
Cependant, l'application intègre cette fonctionnalité (pour l'instant désactivée) depuis la version 2.2.0 du 16 décembre, et l'avis de la CNIL contient une description succincte du fonctionnement du système. À partir de ces éléments, j'ai essayé de reconstruire le protocole TAC-WARNING, et d'analyser son impact sur la protection des données personnelles. Sauf erreur, ce protocole révèle au serveur énormément d'information sur la vie privée des utilisateurs, même s'ils ne sont pas co-exposés. Cela ne correspond pas du tout à la promesse de départ: «sa conception permet que PERSONNE, pas même l’Etat, n’ait accès à la liste des personnes diagnostiquées positives ou à la liste des interactions sociales entre les personnes».
Description du protocole
Le protocole semble fonctionner ainsi:
- Le responsable d'un lieu public génère un QR-code avec un identifiant aléatoire (UUID);
- L'utilisateur qui entre dans un lieu public scanne le QR-code, et l'appli enregistre l'UUID avec un timestamp (horodatage). Il calcule aussi une version masquée de l'UUID (SHA256(sel+UUID) avec un sel aléatoire);
- Si un utilisateur est malade, il envoie au serveur central sa liste de UUID + timestamp;
- Régulièrement, les utilisateurs envoient les UUID masqués + timestamp de leur liste. Le serveur vérifie si un des UUID est à risque pendant la période correspondante (pour chaque UUID envoyé par un malade, il calcule SHA256(sel+UUID) avec tous les sels possibles).
Grace au masquage des UUID avec un sel, ce protocole permet de ne pas révéler les UUID visités par les personnes qui ne sont pas à risque.
Contexte général
Les données de traçage, même non-nominatives, sont des données personnelles au sens du RGPD. Il faut donc mettre en place des protocoles qui permettent de minimiser la collecte de ces données. Le status de malade de la COVID-19 n'est pas une information très sensible en général, mais plusieurs exemples montrent que cette information peux avoir un impact important:
- au début de l'épidémie, certains soignants ont reçus des menaces de la part de leurs voisins;
- en Corée du Sud, un cluster dans un club gay a déclenché une vague d'homophobie.
Comme avec le protocole ROBERT utilisé pour la partie Bluetooth de TousAntiCovid, il y a deux risques principaux: traçage des utilisateurs, et injection de fausses alertes. Ces systèmes ne collectent pas l'identité des utilisateurs, mais certains utilisateurs peuvent être identifiés en utilisant des données en dehors du protocole. En particulier, le serveur connait leurs adresses IP, et pourrait les réidentifier avec l'aide des fournisseurs d'accès Internet.
Même si on considère l'État comme un tiers de confiance, les données peuvent être détournées:
- Singapour a changé sa législation pour donner à la police accès aux données de traçage;
- il peut y avoir une fuite de la base de données, comme aux Pays-Bas.
Risque 1: le serveur connaît les horodatages des QR-codes
Même si les UUID sont masqués, le serveur central reçoit les timestamp (horodatages) en clair: il sait combien de QR-codes un utilisateur a scanné et quand. Il peut par exemple repérer tous les QR-codes scannés après le couvre-feu.
Risque 2: le serveur apprend les interactions sociales
Si le serveur central arrive à déterminer quels UUID masqués correspondent au même UUID en clair, il peut en déduire quel utilisateurs étaient au même endroit au même moment, même si aucun d'entre eux n'est malade. Il y a au moins deux façons de reconstruire ces interactions par le serveur.
A. Le masquage est trop faible
Dans la version actuelle, le sel utilisé pour masquer les UUID fait seulement 1 bit. Cela signifie que si deux utilisateurs scannent le même QR-code, dans 50% des cas l'UUID sera masqué de la même façon, et le serveur apprend que les deux personnes étaient dans le même lieux.
B. Fuite d'UUID
Le système suppose que les UUID restent inconnus du serveur tant qu'il n'y a pas de malade dans le lieu public correspondant. Quand il apprend un UUID, le serveur peux retrouver tous les utilisateurs qui l'ont visité, même si le masquage est suffisamment fort (c'est nécessaire pour alerter les personnes à risques). Le serveur peux connaître des UUID de plusieurs manières:
-
Les QR-codes encodent une URL de la forme https://tac.gouv.fr/UUID. Si un utilisateur scanne le QR-code et suit le lien avec un navigateur web au lieu de scanner le code dans l'application, l'UUID correspondant est envoyée au serveur tac.gouv.fr.
-
Un UUID est envoyé au serveur dès qu'une personne l'ayant scannée est malade. Avec le taux d'incidence actuel (200/100000/semaine), c'est le cas s'il est scanné par environ 500 utilisateurs TAC pendant sa durée de vie (parce qu'un utilisateur envoie environ 1 semaine d'historique quand il est testé positif). Donc si le système est assez utilisé pour être utile, une grande partie des UUID seront envoyés au serveur (à moins que les QR-codes ne soient renouvelés assez fréquemment).
-
Comme indiqué au risque 3 ci-dessous, des agents de l'État pourraient facilement scanner les QR-code dans les lieux publics et envoyer les UUID au serveur.
Risque 3: le serveur peux reconstruire les trajets des utilisateurs
L'État pourrait facilement construire une base de données de QR-codes dans les lieux publics (restaurants, cinémas, gares, ...), avec la localisation correspondante et l'UUID. Une fois cette base de donnée construite, le serveur central peux reconstruire les déplacements de tous les utilisateurs du système (même s'il n'y a pas de malades). Cela permettra aussi d'identifier certains utilisateurs (en identifiant leur lieu de travail, par exemple).
Risque 4: les utilisateurs peuvent identifier les lieux à risque
L'architecture centralisée de ce protocole permet d'éviter de publier une liste des lieux à risques (c'est son principal avantage par rapport au système décentralisé). Cependant, il est facile d'interroger le serveur pour demander si un lieu est à risque. Des utilisateurs peuvent ainsi créer une application alternative qui calcule le niveau de risque avant de rentrer dans un lieu public. Il suffit de scanner le QR-code à l'entrée, puis d'envoyer des requêtes de calcul d'exposition au risque avec cet UUID et différents timestamps. Si le QR-code n'est pas changé régulièrement, cela révèle les horaires auquel le lieu a été visité par des malades.
Utilisation du protocole
Ces risques sont plus ou moins grave suivant les contextes dans lesquels ce système est déployé, mais on ne sait pas encore quelle est l'utilisation envisagée. Les QR-codes serviront peut-être d'alternative aux cahiers de rappel dans les restaurants ou les cinémas, ou de complément au traçage Bluetooth dans des lieux de passage (centre commerciaux, transports en communs). On ne sait pas non plus quelle sera la durée de vie des QR-codes. Les risques (notamment 2B, 3 et 4) sont réduits si les QR-codes sont renouvelés fréquemment, mais cela demande d'installer des écrans (alors qu'un QR-code statique peut être imprimé sur une affiche).
En tout état de cause, les cahiers de rappel papier sont une solution plus respectueuse de la vie privée, car les informations restent locales et ne sont pas centralisées. Des données centralisées permettent au serveur de faire des recoupements pour apprendre le graphe social, et augmentent énormément le risque de fuite de données.
Avant de déployer ce système, il faut débattre des avantages espérés et des risques possibles. De façon générale, on demande une étude clinique avant de déployer tout ce qui touche à la santé, pour évaluer les effets positifs ou négatifs, et les utilisateurs sont informés des effets secondaires. Ce type d'étude n'a toujours pas été publié pour le traçage Bluetooth de TousAntiCovid, et n'a probablement pas encore été fait pour le traçage par QR-code. Il serait bon d'évaluer les outils déjà déployés avant d'en créer de nouveaux.