Sécurité et respect de la vie privée des applications Covid-19

Le respect de la vie privée pour une personne concerne le choix de ne pas rendre certaines informations personnelles publiques. Ces informations peuvent concerner entre autres l'état de santé, la vie familiale et conjugale, ainsi que la correspondance avec d'autres personnes[1].

Des recherches sur les moyens de préserver la vie privée malgré l'utilisation d'applications de traçage sont en cours de réalisation, car ces chercheurs pensent que la confiance accordée aux applications Covid-19 facilitera l'adoption à grande échelle[2]^,[3]^,[4]. Une étude en sociologie menée en Allemagne, en Chine et aux États-Unis montre que les individus se sentent inquiets de leur vie privée vis-à-vis des technologies de traçage, bien que d'autres facteurs entrent aussi en jeu lorsque cela concerne son adoption comme l'habitude à ces technologies ou le régime du gouvernement en place. Les chercheurs de cette étude concluent que l'adoption volontaire des applications Covid-19 ne peut se faire que si les individus se sentent rassurés sur la protection de leurs données et de la non-instrumentalisation de la part de leurs institutions respectives[5].

On définit communément trois catégories d'attaquants qui pourraient atteindre à la vie privée des utilisateurs des applications Covid-19[6] :

Cela désigne une personne qui va écouter sur le réseau les informations échangées entre deux applications ou entre une application et l'entité centrale. Ces informations doivent être anonymisées afin qu'un renifleur qui récupère ces informations ne puisse pas les associer à une personne.

Cela désigne les autres utilisateurs de l'application. Si l'application échange des données entre utilisateurs qui se sont rencontrés et les enregistre sur le téléphone, un utilisateur ne doit pas pouvoir reconnaître l'identité des personnes avec qui il a été en contact.

Cela désigne l'entité qui a créé et qui gère l'application. Cela peut être un État comme dans le cas de l'application française TousAntiCovid[7] ou bien une entreprise privée. Si l'application centralise les données sur un serveur, il y a deux possibilités. Soit il faut que l'entité centrale conserve les données de manière anonyme, mais cela pose un problème pour pouvoir prévenir une personne si elle a été cas contact. Soit l'entité centrale a accès à toutes les informations de façon non anonyme et dans ce cas, il faut lui faire confiance.

Un autre aspect de la vie privée qui peut légitimement inquiéter les utilisateurs sont les demandes d'autorisations requises par les applications de traçage au Covid19. Certaines applications demandent des droits qui ne sont pas essentiels. Par exemple, l'application utilisée au Qatar demande l'accès aux informations sur l'historique d'appels ou l'application utilisée au Vietnam demande l'accès aux données stockées et à la caméra. D'autres applications demande l'autorisation de transférer des données vers des tierces parties inconnues sans données la nature de ses informations[8].

L'enjeu de Sécurité du téléphone pour les applications Covid-19 est de ne pas introduire de nouvelles failles sur le téléphone. Les nouvelles failles peuvent venir du protocole dont dépend l'application. En d'autres termes, l'enjeu de sécurité est de ne pas augmenter la surface d'attaques du téléphone.

Un attaquant malveillant ne doit pas pouvoir utiliser une faille de l'application ni pour gêner le fonctionnement normal de l'appareil (surcharger les ressources du téléphone, gêner la communication, vider la batterie...)[9], ni pour introduire des faux-positifs ou des faux-négatifs, ce qui peut avoir une charge psychologique inutile sur l'individu en plus d'un confinement non nécessaire et de polluer des données qui pourraient être utilisées par les épidémiologistes.[10]

Certaines applications de traçage au Covid-19 utilisent les coordonnées GPS pour monitorer la proximité entre les utilisateurs et détecter les cas contacts. Parmi eux, le Chinese health code system (Chine)[11], Rakning C-19 (Islande)[12], Aarogya Setu (Inde)[13], MorChana (Thaïlande)[14]... Cependant, environ la moitié des applications délaissent la solution GPS[15] soit par des soucis techniques puisque la précision des données GPS est supérieure à 10 mètres, ce qui ne convient pas à l'identification de cas contacts dans le cadre de l'épidémie du Covid-19 et ne fonctionne pas ou moins bien à l'intérieur de certains bâtiments, soit par souci de vie privée, sinon à cause de l'usage important de batterie qui ne convient donc pas à une utilisation prolongée[16]^,[17]. Cependant, les données GPS peuvent être utiles aux études épidémiologiques pour comprendre les mouvements de populations.[18]

Les données GPS sont des données critiques car elles permettent de trouver l'identité d'un individu et sont donc un moyen de désanonymiser l'usager d'une application de traçage au Covid-19[19]. D'après Sonia Sotomayor, Juge assesseur de la Cour suprême des États-Unis, les données GPS et le traçage des mouvements sont le reflet de son statut social et familial, sa profession et donnent des détails sur ses orientations politiques, religieuses et sexuelles, en plus d'être un moyen de la réidentifier[20].

On définit communément trois catégories de protocoles :

Architecture de protocole hybride

Les tâches les plus complexes sont bien réalisées par le serveur central (analyse de risque et notification), mais l’ID temporaire est généré sur le téléphone de l’utilisateur. Les clés cryptographiques ne sont pas connues par le serveur central sauf si un utilisateur atteint du Covid-19 publie volontairement sa clé. Cela protège l’anonymat des individus sains face à l’entité générale, tout en gardant les usagers infectés anonymes des autres utilisateurs, car l’étude de risque se fait bien du côté du serveur, il n’est donc pas nécessaire de publier les graines des utilisateurs infectés aux utilisateurs sains[23].

Résumé des applications et protocoles

Les catégories de protocoles décentralisé et hybride prétendent protéger l'anonymat des utilisateurs vis-à-vis des autres utilisateurs et du serveur en utilisant des identifiants aléatoires[22]^,[23]. Certains protocoles centralisés comme ROBERT prétendent la même chose[24]. Cependant pour certains chercheurs, il n'est pas possible de concevoir des protocoles qui garantissent l'anonymat des utilisateurs, car le but de ces applications et de tracer les contacts des utilisateurs, donc faire une application de traçage anonyme est un oxymore[25]. Selon La Quadrature du Net, il est plus approprié d'utiliser le terme "pseudonymat" plutôt que "anonymat", car l'objectif de l'application (alerter des personnes ciblées) est par essence incompatible avec la notion juridique d’anonymat[26].

Le but de ces attaques est d'identifier une personne anonymisée par l'application.

Le but est de désanonymiser l'identité d'un utilisateur en exploitant les métadonnées et en formant des déductions. On peut par exemple utiliser la date de la rencontre, le modèle du téléphone et/ou la durée de contact. Cette attaque est particulièrement efficace dans le modèle décentralisé où plus d'informations sont traitées sur les téléphones des utilisateurs. Cette attaque peut aussi être utilisée en conjonction avec d'autres attaques pour ajouter des métadonnées qui ne seraient pas présentes sur le protocole d'origine[27].

Dans cette attaque, le centre de santé C et le serveur S s'entendent pour identifier la correspondance entre les identifiants éphémères et les identités des personnes infectées. C'est une exploitation du mécanisme d'autorisation par lequel les utilisateurs infectés communiquent leur statut à S. DP-3T propose trois mécanismes d'autorisation différents mais ils sont essentiellement basés sur un code d'autorisation publié par C. Il est clair que C connaît l'identité de l'utilisateur infecté et s’il est en collusion avec S, il peut alors fournir à S la correspondance entre l'identité réelle d'un utilisateur et son code d'autorisation. S peut associer cette identité aux identifiants éphémères envoyés par l'utilisateur[28].

Le but de ces attaques est d'alerter à tort des individus dans le but de nuire soit à l'application, soit aux institutions ou aux utilisateurs, alors forcés de se faire tester au Covid-19 ou de se confiner[29].

Le but de cette attaque est de créer des faux-positifs. En écoutant des messages honnêtes et en les répétant, à un temps et à un endroit différent, on peut étendre la portée du message d'un individu infecté et alerter inutilement les utilisateurs subissant l'attaque[30]^,[29].

Dans cette attaque, l'objectif est de tromper un utilisateur en lui fournissant un faux contact avec un utilisateur positif. Cette attaque nécessite la collusion de l'attaquant avec le serveur. Supposons que Uv est l'utilisateur victime de l'attaque. Dans la version "unlinkable" de , l'attaquant place les dispositifs passifs Bluetooth à proximité de Uv et lorsque celui-ci entre en contact avec un autre utilisateur Us, les dispositifs Bluetooth capturent les identifiants éphémères de Us et les envoient au serveur. Le serveur insère ces identifiants dans le filtre Cuckoo de sorte que, lorsque Uv vérifie le filtre, il est averti à tort. La version "low cost" de n'est pas vulnérable à cette attaque puisque le serveur n'est pas capable de générer les clés secrètes des utilisateurs à partir des identifiants éphémères collectés. De même que pour la version "unlinkable" de , dans ZE2-P3T, le serveur peut notifier de fausses informations sur les contacts à risque[29].

L'objectif de cette attaque est le même que celui de l'attaque Matteotti, et dans ce cas, l'attaquant est un utilisateur qui a été testé positif. Il peut utiliser un amplificateur Bluetooth pour envoyer ses identifiants éphémères à d'autres utilisateurs, même très éloignés de lui et donc sans risque. Lorsque le serveur communique les identifiants de l'attaquant, ces utilisateurs sont avertis à tort[29].

Le but de ces attaques est de découvrir les déplacements ou les rencontres des utilisateurs grâce aux failles présentes dans les protocoles des applications Covid-19.

L'attaquant doit installer plusieurs dispositifs Bluetooth afin de collecter les identifiants éphémères des autres utilisateurs situés à proximité de ces dispositifs. Il enregistre aussi l'heure et le lieu où ces identifiants sont reçus. Lorsqu'un utilisateur est infecté, il envoie sa clé secrète au serveur qui, à son tour, la diffuse à tous les utilisateurs. À partir de cette clé, l'attaquant est capable de générer tous les identifiants éphémères de l'utilisateur infecté et de le suivre à travers les informations d'heure et de lieu stockées lorsque l'utilisateur est passé à proximité des dispositifs Bluetooth. Cette attaque fonctionne seulement sur la version "low cost" de DP-3T. Dans la version "unlinkable", quand un utilisateur est infecté, il envoie sa clé secrète au serveur mais celui-ci ne la diffuse pas à tous les utilisateurs[31].

L'objectif est le même que l'attaque paparazzi, mais avec la différence que l'attaquant et le serveur s'entendent. Cette fois-ci, la version "unlinkable" de DP-3T est également vulnérable à l'attaque puisque le serveur connaît les caractéristiques des utilisateurs infectés et peut facilement relier leurs identifiants éphémères. Pour connaître les identifiants aléatoires des utilisateurs provenant d'une zone géographique spécifique, le serveur doit connaître le nombre aléatoire envoyé par l'opérateur télécoms dans cette zone géographique. Comme le serveur n'est pas de connivence avec l'opérateur télécoms, la seule façon d'obtenir ce nombre aléatoire est de collaborer avec un partenaire situé dans la zone géographique chaque fois que le nombre aléatoire est envoyé par l'opérateur télécoms[28].

Le but de cette attaque est de tracer les appareils en écoutant les messages de l'application Covid-19, sans nécessairement essayer de comprendre leur contenu. La simple présence de ces messages signifie la présence d'un individu, on peut donc construire les métadonnées nécessaires à son traçage. Écouter l'ID temporaire pour isoler chaque individu peut toutefois être utile et sa réussite dépendra du protocole utilisé, notamment de la durée de vie de l'ID temporaire. Cette attaque peut être utilisée par exemple par un magasin qui souhaite connaître le trajet et la durée des parcours de ses clients dans ses rayons[30].

Le but de cette attaque est de confirmer la localisation d'un individu dont on connaît le modèle du téléphone. Dans certains protocoles, le modèle du téléphone est connu via les messages d'avertissement Bluetooth. On peut donc écouter ces messages et si le modèle de téléphone ciblé est bien présent, on peut en déduire la confirmation de la présence de l'individu pris pour cible[30].

Le but de l'attaque est d'utiliser le décalage entre l'ID temporaire d'un utilisateur et de l'adresse mac Bluetooth. Il suffit de faire le lien entre chaque ID temporaire avec la prochaine adresse mac, et l'on peut suivre isolément l'utilisateur[32]. Un autre exemple d'attaque qui permettrait d'isoler plusieurs ID temporaires d'un même individu serait d'utiliser l'intervalle d'envoi de message de l'application si celle-ci est constante et précise[33].

L'objectif de cette attaque est de fournir une preuve sur une rencontre avec un utilisateur infecté avant la découverte de son infection. Elle peut être considérée comme une faille de sécurité, car il s'agit d'une utilisation abusive du système à des fins involontaires, potentiellement menaçante pour la vie privée et exploitable pour les litiges. Dans les modèles décentralisés utilisant un ID temporaire, l'attaquant capture ces ID d'autres utilisateurs, il peut, par exemple, les stocker sur une blockchain et, successivement, démontrer qu'il a rencontré tels utilisateurs[28].

Un graphe des rencontres sociales constitue un graphe où chaque individu est représenté par un nœud, et chaque arête d'un nœud à l'autre représente la rencontre entre deux individus. Ce type de graphe n'est pas souhaitable pour le respect de la vie privée de l'individu. Cette attaque est possible dans un modèle centralisé où le serveur est mal attentionné ou si les ID temporaires auraient fuité. Elle est aussi possible dans un modèle décentralisé si les téléphones sont par exemple volés et que les graines aléatoires sont récupérées[32].

Le but de l'attaque est de compter le nombre de cas infectés. Cette attaque fonctionne uniquement avec le modèle décentralisé où les graines aléatoires des utilisateurs atteints du Covid-19 sont mises à disposition sur le serveur. Il suffit alors de les compter.

Le but de l'attaque est de consommer les ressources de l'appareil ou du serveur (réseau, batterie, mémoire, cpu...) en inondant de messages[27].

Illustration d'une analyse de risques à destination des non-spécialistes

Ces attaques constituent l'utilisation incorrecte de l'application dans le but de fausser les données ou de récupérer des informations, mais sans exploiter de faille logicielle particulière. Par exemple, il n'est pas possible de savoir si l'application est utilisée par un appareil se trouvant bien sur son porteur, et non pas, par exemple, dans un moyen de transport ou sur un animal de compagnie[32].

Un autre exemple donné par un groupe de chercheurs d'Inria et en automatique en sécurité informatique prend comme situation un entretien d'embauche où le recruteur activerait l'application lors de l'arrivée du candidat, rappelant alors que l'absence de données nominatives ne préserve pas l'anonymat[34].

Une grande partie des applications Covid-19, tel que ROBERT DP-3T (Decentralized Privacy-Preserving Proximity Tracing) , ou BlueTrace reposent sur le Bluetooth[24]^,[35]^,[36]. L'utilisateur du téléphone doit alors activer le Bluetooth tout au long de l'utilisation de l'application. Le Bluetooth possède cependant des vulnérabilités. La sécurité principale du Bluetooth dépend notamment du chiffrement des données, mais les clés de chiffrement montrent des vulnérabilités liées à leur faible entropie[37].

Les possibilités d'attaques sur des appareils mobiles via Bluetooth sont multiples. L'étude de 2018 "Security threats in Bluetooth technology" répertorie plusieurs attaques connues à ce jour. Entre autres, les attaques Bluetooth permettent de voler des données du téléphone (Bluesnarfing), écouter les appels (Bluebugging), tracer les téléphones (Bluetracking) ou voler les codes PIN (Pin cracking attack)[38].

Dans un article publié en septembre 2020, Paul-Olivier Dehaye expert en protection des données personnelles et Joel Reardon, de l'université de Calgary, montrent comment il est possible d'utiliser un kit de développement (SDK) ou une application mobile tierce ayant accès au bluetooth du téléphone pour mener des attaques de dé-anonymisation, de faux positifs ou de biosurveillance[39].

Cet enjeu de sécurité plus important avec l'utilisation des applications Covid-19 soulève des inquiétudes[26].

L'application Aarogya Setu utilisée en Inde aurait peut-être été victime d'une faille trouvée par le hacker français Robert Baptiste (du pseudonyme Elliot Alderson) qui a publié sa démarche sur son blog Medium. Le principe est de mentir sur sa position et de changer la valeur du rayon de la zone d'effet. Par exemple, en changeant le rayon à une valeur très faible et en mentant sur sa localisation pour préciser à la place celle d'un individu dont on souhaite découvrir l'état de santé, on peut découvrir si celui-ci a été infecté ou non[40]. Les développeurs de l'application ont publié en réponse qu'aucune donnée de ses utilisateurs ne risque d'être victime de piratage[41].

L'application EHTERAZ utilisée au Qatar a fait l'objet d'une faille permettant à n'importe qui de se connecter sur le compte d'un utilisateur. L'application donne un Code QR comme moyen de connexion si l'utilisateur donne son ID national. Or, l'ID national respecte un format constant. La faille consiste à essayer toutes les combinaisons d'ID national pour un Code QR donné. Aucun système d'authentification supplémentaire étant donné, il était relativement facile de passer cette étape et d'être connecté sur le compte d'un utilisateur donné, obtenant ainsi son nom, son état de santé et la localisation de son confinement. Le problème fut rapidement résolu par les autorités qatariennes après qu'Amnesty International ait découvert la faille[42].

Le protocole ROBERT utilisé pour l'application française TousAntiCovid est un protocole centralisé. Dans la définition du protocole, le serveur ne doit pas pouvoir corréler des données dans le but d’identifier un utilisateur[43]. Cependant dans l’implémentation du protocole, l'adresse IP du téléphone est enregistrée par le serveur. Si on suppose une collusion entre le serveur et le fournisseur de téléphone mobile, alors il est possible d'identifier les utilisateurs[44].

Le modèle centralisé permet de protéger facilement de certaines attaques comme les attaques de linkage, car toutes les métadonnées restent sur le serveur central, et seuls les ID temporaires sont communiqués entre les utilisateurs[21]. Mais cela est vrai à la condition que le serveur central soit digne de confiance et sécurisé. Autrement, le modèle est susceptible aux attaques de Linkage et à la construction de graphe des rencontres sociales[32]^,[27]. Le modèle décentralisé répond à cela mais en laissant les données sur l'appareil des utilisateurs, les attaques par linkage sont plus facilement réalisables[27]. En réponse à cela, le modèle hybride Desire propose de laisser le serveur faire la notification de cas contact, ne laissant pas les applications mobiles obtenir les graines aléatoires. Les données stockées sur le serveur sont cependant chiffrées avec une clé de chiffrement disponible sur l'appareil de l'utilisateur[45].

Dans le modèle décentralisé, les graines aléatoires des utilisateurs atteints du Covid-19 sont publiées sur un serveur disponible à tous les utilisateurs. Certaines attaques, comme l'attaque par linkage ou paparazzi sont alors facilitées[30]. En réponse à ces attaques, une version dite "Unlikable" est conçue. À la place de publier les graines aléatoires sur le serveur, le serveur recalcule les ID temporaires et les hash dans un cuckoo filter. L'application mobile des utilisateurs peut vérifier que leurs ID temporaires rencontrés n'existent pas sur le serveur via le cuckoo filter, sans directement connaître ces ID temporaires[46].

L'existence d'un ID utilisateur permet à de nombreuses attaques d'exister, comme le replay attaque, l'attaque carryover[29]^,[30]. Le Zero Ephemeral Exchanging Privacy Preserving Proximity Tracing (ZE2-P3T) pourrait régler ce problème en proposant un protocole n'utilisant pas d'ID utilisateur. À la place, ZE2-P3T utilise une conjonction de localisation GPS pour trouver les cas contacts, puis Bluetooth pour augmenter la précision[47].