Pourquoi StopCOVID échoue dès sa conception sur la préservation de la vie privée (Nadim Kobeossi)

Alors que toute la presse française encense l’application StopCovid, et qu'elle nous apprend que près de 40% des Français sont près à l'installer, j’ai trouvé grâce à nos amis de la Quadrature du net, une analyse de Nadim Kobeossi beaucoup plus critique de cette application. Espérons que les principaux défauts aient été corrigés, mais il reste des failles au niveau même de la conception. De plus il semble atteint d’une « faille » critique Bluetooth CVE-2020-12856 (non corrigé) qui est pour l’instant sous « embargo ». Plus grave encore, on apprend que compter sur le Bluetooth pour détecter les autres appareils Bluetooth « proches » et calculer la distance ne fonctionne pas… Et cerise sur le gâteau Nadim Kobeossi explique que la base de données n'est absolument pas sécurisée au niveau de l'anonymisation et que l'utilisation de ce logiciel inclus qu'il faut «  faire confiance » au gouvernement pour ne pas qu’il « reconstruise » les données et en abuse…

Enfin, au moins, ils n’ont pas utilisé le Système d’Apple et de Google qui lui sera (a priori) installé de façon silencieuse au niveau OS sur tous les téléphones (sans votre accord).
 
Bref, ce n’est pas gagné tout ça, mais comme on vous le disait, si vous vous faites du mouron pour votre vie privée, ce n’est pas du côté de Stop Covid ou d'Apple ou de Google qu’il faut regarder, mais du côté de la NSA….
 
Amitiés,

f.

Cette analyse est rédigée en collaboration avec Anne Weine et Benjamin Lipp.

L'application française StopCOVID sera examinée aujourd'hui par le législateur français en vue d'un déploiement national, après avoir récemment obtenu un avis de la Commission nationale de l'informatique et des libertés (CNIL), qui ne contenait que des critiques et des suggestions légères concernant les mesures de transparence de l'application. Les développeurs de ROBERT/StopCOVID ont faussement indiqué que cela constituait une sorte d'approbation générale de la CNIL, comme je le montrerai plus loin dans ce post.

Ayant suivi de près le développement de ROBERT, le protocole sous-jacent de l'application, et ayant récemment examiné le code source de l'application StopCOVID elle-même, je rédige ce billet afin de justifier ma position, à savoir que StopCOVID n'est pas une technologie préservant la vie privée et qu'elle est strictement impropre à un déploiement au niveau national. En fait, j'irais même jusqu'à dire que les failles dans la conception de StopCOVID sont si graves que son déploiement à l'échelle nationale pourrait nécessiter un examen éthique scientifique indépendant. Je justifierai cette position par les arguments ci-dessous.

Compromettre un serveur unique, c'est désanomyser toute l'utilisation de StopCOVID en France

Dès le début, la conception de ROBERT a indiqué que l'ensemble du système de recherche des contacts "préservant la vie privée" fonctionnerait en ayant un seul serveur centralisé qui générerait et délivrerait des pseudonymes à tous les utilisateurs de StopCOVID. Le 18 avril, j'ai posé une question sur l'adéquation de ce type de conception à une application censée préserver la vie privée. A savoir, étant donné que la spécification ROBERT stipulait ce qui suit :

    Anonymat des utilisateurs d'une autorité centrale : L'autorité centrale ne devrait pas être en mesure d'obtenir des informations sur l'identité ou la localisation des utilisateurs participants, qu'ils soient ou non diagnostiqués comme COVID-positifs.

J'ai demandé, étant donné que tous les pseudonymes sont générés à partir du serveur après une demande d'API REST de l'appareil/adresse IP de l'utilisateur :

    En bref, tout ROBERT est construit sur la confiance des autorités centrales et sur l'hypothèse qu'elles se comporteront honnêtement et seront imperméables aux compromis de tiers. Je ne suis pas en mesure de déterminer en quoi il s'agit d'une approche solide, voire sérieuse et réaliste, de la véritable vie privée des utilisateurs. Pourriez-vous expliquer comment ce protocole permet de protéger la vie privée des autorités et comment le modèle actuel, qui suppose que toutes les autorités le font, est appliqué :

        1. Complètement honnêtes,
        2. Imperméable au compromis serveur/back-end,
        3. Imperméable à toute compromission ou usurpation d'identité de la part de la couche transport,

    ...est en quelque sorte réaliste ou quelque chose qui peut être pris au sérieux en tant que protocole de préservation de la vie privée ? Étant donné le niveau de confiance que vous attribuez aux autorités, et étant donné que les autorités sont responsables de la génération, du stockage et de la communication de tous les pseudonymes directement aux utilisateurs sur leurs appareils, quelle propriété de sécurité est réellement atteinte dans ROBERT en termes de pseudonymat entre les autorités et les utilisateurs ?

Douze jours plus tard, j'ai reçu la réponse suivante de l'équipe ROBERT :

    Dans le schéma ROBERT v1.0, le serveur est en effet responsable de la génération, du stockage et de la communication des pseudonymes. Ceci est fait pour deux raisons principales :

    Un utilisateur ne peut effectuer qu'une phase de demande de statut d'exposition correspondant à ses pseudonymes. En effet, les pseudonymes sont liés à une clé secrète K_A sur le serveur, et le serveur vérifie que la demande provient du propriétaire de la clé secrète K_A avant de répondre. Par conséquent, un attaquant ne peut pas demander au serveur le statut d'exposition d'un autre utilisateur.

    Les pseudonymes des utilisateurs infectés ne sont pas exposés aux autres utilisateurs. Comme le calcul du statut d'exposition est effectué sur le serveur, il n'est pas nécessaire de publier les pseudonymes des utilisateurs infectés comme cela peut être le cas avec d'autres solutions.

    A propos du pseudonymat des utilisateurs par rapport au serveur. Le serveur ne stocke pas d'autres identifiants que celui qui est inclus dans la base de données IDTable (voir section 3.2. Enregistrement de l'application (côté serveur)). Lors de l'enregistrement de l'application et de la demande de statut d'exposition, l'application peut exposer des identifiants de réseau qui pourraient compromettre sa véritable identité. Pour atténuer ce risque, des solutions telles que Mixnet ou des proxies pourraient être utilisées (comme suggéré dans la section 6, note de bas de page 11).

    Plus généralement, concernant l'hypothèse "honnête mais curieuse" : c'est une hypothèse clé pour la conception de ROBERT v1.0 comme vous l'avez remarqué. Il ne nous appartient pas, en tant que chercheurs dans le domaine de la protection de la vie privée, de juger si cette hypothèse est valable ou non.

    Il est clair que ce sujet pourrait être discuté pendant des heures. Cependant, en examinant l'"avis CNIL sur le projet d'application mobile StopCovid", nous avons le sentiment qu'il s'agit d'une hypothèse raisonnable.

La réponse ci-dessus contient deux affirmations scandaleuses :

1/    Elle affirme que les concepteurs d'un système de protection de la vie privée n'ont pas la responsabilité de juger si les hypothèses qu'ils font sur leur propre conception, qu'ils contrôlent sur leur propre cas d'utilisation, qu'ils peuvent librement limiter ou étendre, sont valables ou appropriées. Il s'agit là d'un abus d'un principe réservé aux situations où les chercheurs doivent évaluer des systèmes tiers, et qui est pourtant utilisé pour dire que les concepteurs de systèmes de protection de la vie privée ne sont responsables d'aucune de leurs hypothèses en matière de protection de la vie privée.

2/   La dernière phrase de la réponse renvoie à ce rapport de la CNIL qui, outre qu'il s'agit d'un avis préliminaire qui est loin d'être totalement favorable à la conception de ROBERT/StopCOVID, n'a aucune portée dans une discussion scientifique ou technique et constitue donc un appel à l'autorité.

Néanmoins, ce principe fondamental de la conception ROBERT a survécu et l'équipe ROBERT/StopCOVID a jugé bon de le mettre en œuvre mot pour mot dans la pile d'applications StopCOVID.

L'architecture de la base de données centralisée de StopCOVID/ROBERT

Au cours de l'examen du code source de StopCOVID/ROBERT effectué aujourd'hui, il est apparu que le serveur StopCOVID exploitait une base de données MongoDB unique qui stockait l'état utilisateur suivant pour chaque utilisateur de StopCOVID :

// robert-server-database/src/main/java/fr/gouv/stopc/robertserver/database/model/Registration.java
public class Registration {
	@Id
	@ToString.Exclude
	private byte[] permanentIdentifier;
	@ToString.Exclude
	private byte[] sharedKey;
	private boolean isNotified;
	private boolean atRisk;
	private int lastStatusRequestEpoch;
	private int lastNotificationEpoch;
	private List<EpochExposition> exposedEpochs;
}

La création et le stockage de cette entrée de base de données sont déclenchés par un appel API REST que l'application client StopCOVID fait au serveur lors de l'enregistrement du dispositif. Comme moi-même et d'autres l'avions fait remarquer quelques semaines auparavant à l'équipe StopCOVID/ROBERT, cela signifie qu'un serveur compromis, malveillant ou même simplement "honnête mais curieux" (le propre modèle de menace de StopCOVID) pourrait corréler les adresses IP et les agents utilisateurs (et donc les appareils) à leurs entrées d'état dans la base de données MongoDB unique.

Ce problème a été souligné par moi-même mais aussi indépendamment par Olivier Blazy. Bien que l'équipe ROBERT ait reconnu l'existence de ce problème, sa réponse s'est limitée à une comparaison (en fait fausse) avec une norme concurrente, DP-3T, et à proposer l'utilisation de réseaux mixtes comme solution potentielle, qui ne conviendrait probablement pas à un déploiement de masse et qui constituerait probablement un ajout à la conception plus complexe que la totalité de la conception actuelle de ROBERT elle-même. En dehors de cette discussion, l'équipe ROBERT n'a pas pris la question au sérieux, la considérant comme un défaut fondamental de la conception centralisée de traçage de proximité.

La section 8 du document de conception de ROBERT décrit comment le système peut se fédérer avec d'autres états :

    Pour que notre système soit un outil efficace, il doit fonctionner dans les États voisins. Nous proposons donc l'utilisation d'une architecture distribuée et fédérée dans laquelle les pays peuvent exploiter leurs propres applications et développer leurs propres logiciels.

Ce système pourrait être utilisé en France pour éviter d'avoir un seul serveur de base de données : Chaque service de santé de la région ou du département pourrait faire fonctionner un serveur, et les utilisateurs s'inscriraient sur le serveur de leur région/département d'origine (ou seraient assignés au hasard, ou choisiraient eux-mêmes). La fédération entre eux pourrait fonctionner comme décrit dans la section 8.

Fenêtre de compromis et données récupérées

En examinant le code source, il a été déterminé que les appareils clients StopCOVID s'enregistrent via l'API REST au moins une fois toutes les 24 heures, la minuterie commençant au moment de l'enregistrement. Étant donné que les utilisateurs sont plus susceptibles de s'enregistrer pendant les heures de veille en français, cela signifie qu'un attaquant ayant une fenêtre de compromis sur le serveur pendant un seul jour ouvrable pourrait désanonymiser complètement et irréversiblement pratiquement tous les utilisateurs de StopCOVID, en corrélant les adresses IP et les agents utilisateurs qui contactent le serveur via son API REST aux identifiants permanents de la base de données MongoDB. Nous répétons que cela est tout à fait conforme à ce que pourrait faire l'adversaire "honnête mais curieux" considéré par l'équipe StopCOVID/ROBERT.

Encore une fois, l'équipe StopCOVID/ROBERT était consciente de ce problème, a choisi de ne pas l'aborder et a plutôt cité un rapport de la CNIL qui n'a pas du tout abordé cette question. En fait, il n'est pas clair que la CNIL ait, à un moment donné, enquêté sérieusement sur ce défaut de conception fondamental.

Potentiel d'abus indétectable de la part des autorités

L'équipe StopCOVID/ROBERT cite la publication du code source du serveur comme une pierre angulaire de son initiative de transparence. Cependant, étant donné qu'il n'y a pas d'attestations concernant l'intégrité du code fonctionnant du côté du serveur, il est strictement impossible pour des tiers de déterminer si le code n'est pas modifié à un moment donné afin de faciliter la corrélation de l'adresse IP ou des informations sur l'agent utilisateur avec les identifiants permanents stockés dans la base de données MongoDB du serveur. Nous réaffirmons qu'une telle attaque serait conforme au modèle de menace adopté par ROBERT, à savoir un attaquant "honnête mais curieux". Cette faille pourrait s'appliquer à d'autres modèles de traçage de proximité, mais elle est considérablement amplifiée dans les modèles centralisés qui dépendent davantage du serveur.

Limitations de l'application StopCOVID

Outre la question fondamentale évoquée ci-dessus, qui seule devrait discréditer entièrement la norme StopCOVID/ROBERT, la demande du client dans son état actuel souffre de divers problèmes qui limitent considérablement son efficacité et sa viabilité.

Publication de la version bêta sans politique de confidentialité

La version bêta de StopCOVID a été publiée avec un texte de remplissage de Lorem Ipsum au lieu d'une politique de confidentialité. Bien que ce problème soit facile à résoudre et qu'il ne reflète pas le bon sens technique ou scientifique de la pile StopCOVID/ROBERT, il reste un indicateur pessimiste en ce qui concerne le niveau d'attention accordé au système de manière plus générale.

Bluetooth ne peut pas mesurer de manière fiable la distance physique

L'une des principales prémisses de l'application StopCOVID est qu'elle est capable, via Bluetooth, de mesurer de manière fiable que des contacts ont eu lieu à une distance inférieure à un mètre. Cela est impossible pour un certain nombre de raisons :

1/ Il n'existe pas de fonctionnalité spécifiée de ce type dans la spécification Bluetooth, de sorte que toute tentative d'arriver à une telle mesure devrait être faite en utilisant des méthodes ad hoc.

2/ Il est peu probable que de telles méthodes ad hoc fonctionnent en raison d'un certain nombre de facteurs restrictifs : tout d'abord, les différents appareils de téléphonie intelligente sont livrés avec différents jeux de puces Bluetooth de qualité variable. Ces différents jeux de puces Bluetooth prennent en charge différentes versions du protocole Bluetooth, avec des portées maximales différentes. Enfin, ces puces sont reliées à des antennes de portées différentes. En résumé, cela signifie qu'un "signal fort" peut être obtenu uniquement entre les appareils A et B à une portée de cinq mètres ou moins, alors que l'appareil A et l'appareil C peuvent être capables de maintenir facilement un signal évalué au même niveau de puissance même à une portée de 10 mètres ou plus.

Paul-Olivier Dehaye a écrit une excellente étude technique approfondie qui explique plus en détail pourquoi il est peu probable que la déduction de la distance à partir de la puissance du signal Bluetooth fonctionne de manière fiable.

En tant que tel, StopCOVID fait une promesse impossible à ses utilisateurs et cette promesse devrait être retirée.

Les exigences fonctionnelles Bluetooth de StopCOVID ne peuvent pas être satisfaites de manière fiable sur iOS

Il est impossible d'obtenir une fonctionnalité d'arrière-plan fiable de l'API Bluetooth sur les appareils iOS d'une manière qui convienne au cas d'utilisation de StopCOVID. D'autres applications de recherche de contacts ont déjà été confrontées à ce problème et ont dû le résoudre par des mesures extrêmes impropres à une utilisation quotidienne, comme le fait de se fier à des pings constants provenant d'appareils Android qui peuvent ou non être à proximité, l'affichage d'une notification toutes les 30 minutes à l'utilisateur lui demandant de mettre l'application en avant, etc.

StopCOVID nécessite des autorisations de localisation et des autorisations administratives Bluetooth sur Android

L'application StopCOVID exige des utilisateurs qu'ils accordent des autorisations GPS et des autorisations Bluetooth au niveau administratif, ces dernières permettant à l'application StopCOVID de contrôler l'ensemble de la pile Bluetooth du téléphone, y compris l'activation ou la désactivation de Bluetooth, l'interférence avec les connexions Bluetooth établies par d'autres applications, etc. comme documenté ici.

Vulnérabilités critiques de la norme Bluetooth

La prochaine vulnérabilité CVE-2020-12856, actuellement sous embargo, risque d'avoir un impact sécuritaire critique sur toutes les communications Bluetooth effectuées par les applications de traçage de proximité, à l'exception de celles déployées par Google et les API internes d'Apple (puisque ces dernières disposent déjà d'atténuations pour cette attaque). Les découvreurs de la vulnérabilité ont déjà rédigé un rapport montrant comment elle affecte les applications de traçage de proximité. Il est donc irresponsable de déployer une quelconque application de recherche de contacts de tiers avant que l'embargo sur cette question ne soit levé dans 17 jours et qu'un correctif soit mis en place. Et pourtant, la date de lancement prévue pour StopCOVID est ce même week-end, au cas où il serait approuvé par le législateur français.

Utilisation de l'API Google reCaptcha

Les applications Android et iOS de StopCOVID utilisent toutes deux le service Google reCaptcha afin de limiter le spam et les signatures automatisées, envoyant ainsi des informations d'identification à Google, sous la forme d'adresses IP et d'agents utilisateurs, lors de l'embarquement dans chaque appareil.

StopCOVID est impropre à l'adoption nationale

En raison des questions abordées ci-dessus, il est clair que non seulement StopCOVID est impropre à l'adoption nationale, mais qu'il ne peut même pas être considéré comme aillant une conception ou un modèle préservant la vie privée comme il le prétend. Il est donc surprenant de voir comment cette norme a été défendue par l'Inria, le laboratoire national français d'informatique, d'autant plus que les propres chercheurs de l'Inria ont publié une large critique de la conception de StopCOVID/ROBERT, ainsi que des conceptions concurrentes. Cette critique porte sur une multitude de défauts non corrigés dans tous les modèles de recherche par contact, dont la quasi-totalité n'a pas été corrigée par StopCOVID/ROBERT malgré les critiques émanant du même laboratoire de recherche :

L'analyse de StopCOVID par la CNIL

De même, les analyses de la CNIL sur StopCOVID (1, 2), qui ont été citées comme des agréments par l'équipe StopCOVID/ROBERT, se révèlent, après inspection, n'être rien de tel. Les déclarations faites par la CNIL jusqu'à présent ne tiennent pas compte de la grande majorité des défauts évoqués dans ce post, limitant leurs déclarations sur StopCOVID/ROBERT à ce qui suit :

•     Que l'adhésion à StopCOVID doit être strictement volontaire,
•     Qu'aucune conséquence négative ne doit être attachée à l'absence d'utilisation de StopCOVID (telle que l'interdiction d'utiliser les transports publics),
•     Il faut veiller à satisfaire aux exigences de la GDPR,
•     Que StopCOVID doit avoir de solides garanties en matière de respect de la vie privée et surtout de pseudonymat (qui ne sont pas fournis en fin de compte, comme nous l'avons déjà mentionné dans ce post),
•     Que StopCOVID ne doit pas demander d'autorisations de géolocalisation aux appareils des utilisateurs (ce qu'il finit par faire, comme indiqué plus haut dans ce post).

Il est regrettable que l'équipe StopCOVID/ROBERT lance une paire de déclarations de la CNIL réservées et très spécifiques afin de mettre un terme aux discussions scientifiques, comme si un appel à l'autorité était valable dans de tels contextes. C'est d'autant plus regrettable que les déclarations de la CNIL sont loin d'innocenter StopCOVID et de lui donner du crédit. En fait, il semble clair que la CNIL n'a pas eu l'occasion de mettre à jour son avis maintenant que le code source de StopCOVID est publié, et je me demande si cela va se produire étant donné les questions discutées dans ce post parmi, inévitablement, les préoccupations distinctes soulevées par d'autres chercheurs.

Les échecs de StopCOVID en tant que conception logicielle préservant la vie privée

Les différentes parties prenantes, telles que la CNIL ainsi que la communauté des chercheurs, sont unanimes pour dire que l'efficacité d'une telle application ne peut même pas être vérifiée avant sa diffusion. Étant donné que nous n'avons pas de baromètre de l'efficacité finale, il semble que ce soit une grave erreur de diffuser une conception aussi fondamentalement défectueuse en tant que mesure numérique recommandée par le gouvernement dans toute la France.

Compte tenu de la discussion ci-dessus, il est clair que l'adoption de StopCOVID/ROBERT à l'échelle nationale en France constituerait une dilution permanente de ce qui est qualifié de conception préservant la vie privée destiné à être adopté au niveau national en période de crise nationale.

Source(s) : nadim.computer via La Quadrature du Net

C’est l’information d’aujourd’hui, c’est le monde dans lequel nous vivons, et c'est un article exclusif de Crashdebug.fr...

Notre petit site web ne vous impose aucune publicité, nous ne revendons pas vos données, bref nous ne gagnons pas d’argent avec, par contre il propose des services et des infrastructures (que nous vous offrons gratuitement). Cela coûte de l’argent, aussi sachez que si vous le désirez, vous pouvez nous soutenir financièrement à partir de 1€ mensuellement via Tipeee ou occasionnellement via Paypal. Merci par avance ; )

Informations complémentaires :