Privacy de StopCovid : La dure réalité de l’implémentation face à la théorie de la spécification

Résumé des épisodes précédents :

• Une équipe de chercheurs de l’INRIA a formalisé le protocole Robert dans un document “papier”. Il s’agit d’une spécification de la partie protocolaire et du cœur algorithmique, laissant naturellement flous un certain nombre de détails qui seront à définir par l’implémentation.
• Un consortium (INRIA mais aussi de nombreux industriels et services de l’état) est ensuite en charge de développer StopCovid à partir de cette spécification.
• Une partie seulement de StopCovid est open-source. L’infrastructure et les éléments autour (systèmes, log, surveillance, …) ne sont pas documentés, et nous n’avons aucune preuve du code qui tourne réellement côté serveur (j’en parlais ici)

Dans cet article, je présente deux aspects où la théorie de la spécification Robert se heurte à la réalité de l’implémentation StopCovid, et où l’implémentation n’est donc pas conforme aux garanties votées (et n’arrivera pas à l’être) : l’usage de réseaux d’anonymisation (type mixnet) et la protection contre le multi-comptes (sybil attack)

Les réseaux d’anonymisation

Lors de chaque communication entre l’application et le serveur, le serveur reçoit naturellement des informations techniques de communication, telles que l’adresse IP et le port source. Ces données, historisées par l’opérateur, permettent de savoir qui a utilisé cette IP et ce port à un instant donné (c’est un des éléments d’Hadopi, c’est donc fonctionnel et automatisé). La CNIL, comme tous ses homologues d’autres pays, considère que ce sont bien des données à caractère personnel. Les développeurs de StopCovid le reconnaissent également en affirmant ne pas stocker ces IP (puis en se contredisant). La spécification Robert évite soigneusement de parler de ces éléments. Ces informations n’existant pas dans la spécification Robert, elles ne sont pas présentes dans les analyses de privacy, bien qu’étant disponibles dans la réalité et “à caractère personnel”. Les mixnets, solution technique qui permettrait de masquer ces informations, sont tout de même abordés lors du signalement de diagnostic positif.

Cependant, aucune trace de ces mixnets dans l’implémentation ! Un ticket sur le sujet est clos, après une réponse sans rapport avec la question. Ce problème, en fait, que ce soit souhaité ou non, n’est probablement pas soluble facilement.

La théorie de la spécification, ici, s’accommode bien d’un flou artistique. Mais en réalité, les mixnets, c’est extrêmement compliqué à faire fonctionner. Il existe TOR, qu’ils ont choisi de ne pas utiliser, et qui aurait peut-être des problèmes de charge si toutes les applications l’utilisaient ? Cela rendrait, également, la supervision du serveur un peu aveugle, alors qu’ils souhaitent manifestement collecter des données de supervision. On ne peut pas tout avoir…

La création de multiple comptes

L’un des avantages promus par Robert face aux solutions DP3T/Apple-Google est d’empêcher un utilisateur de savoir à quelle période il a croisé une personne qui a ensuite été diagnostiquée positive, pour des raisons de secret médical. En effet, dans l’approche DP3T, une application modifiée pourrait conserver l’heure à laquelle elle a reçu les tokens puis, si le token est publié comme positif, savoir à quelle heure il a été vu : en croisant cela avec ses souvenirs, l’utilisateur retrouverait potentiellement le lieu et la personne croisée.

Dans Robert, le serveur ne publie pas les tokens positifs, mais retourne juste à l’utilisateur s’il a croisé récemment un positif, sans lui dire précisément quand. Une attaque a donc été proposée avec une application qui créerait de multiples comptes et utiliserait chaque compte 15 minutes seulement (par exemple) : si un compte est signalé comme ayant croisé un positif, alors on sait quand c’était, et on peut deviner qui l’était. La spécification Robert évacue ce problème en se reposant sur des éléments de solution type proof-of-work ou autre solution technique à ajouter à l’implémentation.

Côté implémentation, au final, il n’y a rien. Le captcha ne protège pas de cela et l’équipe de développement reconnaît qu’il n’est pas là pour ça. En fait, se protéger du multi-comptes, c’est trouver une protection à la sybil attack, bien connue dans le monde académique des systèmes distribués. Et on sait que dans un système ouvert, c’est un problème extrêmement difficile voire insoluble (et je le sais, j’ai essayé pendant ma thèse :) ).

Encore une fois, l’implémentation n’apporte pas les garanties espérées par la spécification.

Quel problème cela pose ?

Qu’une implémentation diffère de sa spécification est assez classique. C’est cependant très dommageable car ici, l’implémentation remet en cause des hypothèses de la spécification, hypothèses utilisées pour analyser la privacy, analyse de privacy utilisée par la CNIL et par le parlement lors du vote par exemple. Par transitivité, l’accord de la CNIL et du parlement sur la spécification sont donc inadaptés à la réalité de l’implémentation. Et c’est ennuyeux…

Cela soulève un second problème, moins spécifique. On botte facilement en touche des problèmes difficiles quand on écrit un article académique. Et ces deux problèmes en sont typiques. Je ne suis pas très optimiste pour qu’on puisse résoudre ces deux limites d’implémentation, ce sont des problèmes dont la complexité dans la vraie vie est bien connue. On ne peut pas les cacher sous le tapis…

UPDATE #1 : Un très bon ticket sur le github de Robert qui avançait, hors de toute implémentation, que la seule solution réaliste et rapide contre la sybil attack serait d’utiliser FranceConnect, ce qui est loin de fournir l’anonymat espéré et susciterait évidemment une acceptation moindre de StopCovid… Prévention contre la sybil attack et anonymat ne font pas bon ménage dans le cas de StopCovid.