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

Pour un article plus général, voir Application concernant la Covid-19.

La sécurité et le respect de la vie privée des applications Covid-19 sont nécessaires pour que les utilisateurs aient confiance et les adoptent largement. Les applications de traçage des contacts au Covid-19 permettent d'identifier des personnes susceptibles d'avoir contracté le Covid-19 et d'obtenir des informations supplémentaires utiles à la compréhension de la propagation du virus. Les applications récupèrent ainsi des informations confidentielles sur ses utilisateurs, et divers protocoles sont alors mis en place pour anonymiser les individus et protéger la vie privée de ses usagés. Parmi ces protocoles, la collecte des données collectées différera avec GPS ou Bluetooth, et le traitement des données se réalisera soit sur le serveur (protocole dit centralisé), soit sur le téléphone (protocole dit décentralisé). Des attaques existent et auront divers buts comme la dés-anonymisation des utilisateurs, le traçage des individus ou la création de faux-positifs. Chaque protocole possède ainsi une meilleure défense selon un corpus d'attaques particulières et répondra à des enjeux différents. Les gouvernements de plusieurs pays ont alors adopté divers choix au sujet du protocole et de la législation qui l'entoure, entre autres en rendant l'application obligatoire ou non.

Enjeux

[modifier | modifier le code]

Respect de la vie privée

[modifier | modifier le code]
Article détaillé : Vie privée.

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] :

Les renifleurs

[modifier | modifier le code]

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.

Entre utilisateurs

[modifier | modifier le code]

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.

Avec l'entité centrale

[modifier | modifier le code]

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].

Sécurité

[modifier | modifier le code]
Article détaillé : Sécurité logicielle des smartphones.

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].

Protocoles

[modifier | modifier le code]

Classification

[modifier | modifier le code]

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

Centralisé

[modifier | modifier le code]
Architecture de protocole centralisé
Les utilisateurs s’enregistrent auprès du serveur et le serveur donne à chaque utilisateur un ID temporaire qui change régulièrement. Quand deux usagers se croisent, ils partagent leurs informations respectives sous forme chiffrée que seule l’entité centrale sera capable de lire, ce qui préserve l’anonymat entre eux. Ces informations sont d’abord stockées sur le téléphone de l’usager avant d’être envoyées vers le serveur. Ces informations dépendent du protocole en question. Lorsqu’un cas infecté survient, le serveur parcourt ses données pour chercher les cas contacts et notifie ses utilisateurs[21].

Décentralisé

[modifier | modifier le code]
Architecture de protocole décentralisé
Le serveur central existe mais les fonctionnalités principales sont réalisées sur le téléphone de l’utilisateur. Il n’y a alors pas besoin de s’enregistrer auprès de l’entité centrale. Chaque téléphone crée une graine aléatoire qui génère fréquemment des ID temporaires qui serviront à anonymiser l’identité. Lorsque deux usagers se croisent, ils partagent leurs ID temporaires et les enregistrent sur leur téléphone. Lorsqu’un utilisateur est infecté, il peut volontairement envoyer sa graine auprès de l’entité centrale. L'application peut alors vérifier si son utilisateur est entré en contact avec l’une des graines révélées[22].

Hybride

[modifier | modifier le code]
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].

Attaques

[modifier | modifier le code]
Attaques possibles contre les applications et les protocoles

Attaques de désanonymisation

[modifier | modifier le code]

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

Attaque par linkage
[modifier | modifier le code]

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].

Brutus Attack
[modifier | modifier le code]

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].

Attaques permettant la création de faux-positifs

[modifier | modifier le code]

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].

Replay attaque ou Attaque Fregoli
[modifier | modifier le code]

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].

Matteotti Attack
[modifier | modifier le code]

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].

Missile Attack
[modifier | modifier le code]

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].

Attaques permettant le traçage des individus

[modifier | modifier le code]

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.

Paparazzi Attack
[modifier | modifier le code]

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].

Orwell Attack
[modifier | modifier le code]

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].

Traçage de réseau sans fil
[modifier | modifier le code]

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].

Confirmation de localisation
[modifier | modifier le code]

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].

Attaque Carryover
[modifier | modifier le code]

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].

Gossip Attack
[modifier | modifier le code]

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].

Création d'un graphe des rencontres sociales
[modifier | modifier le code]

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].

Autres

[modifier | modifier le code]
Énumération
[modifier | modifier le code]

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.

Déni de service
[modifier | modifier le code]

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].

Attaque par usage abusif
[modifier | modifier le code]
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].

Bluetooth
[modifier | modifier le code]
Article détaillé : Sécurité des protocoles Bluetooth.

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].

Des failles dans l'implémentation

[modifier | modifier le code]

Faille dans Aarogya Setu

[modifier | modifier le code]

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].

Faille dans EHTERAZ

[modifier | modifier le code]

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].

Attaque par corrélation possible dans TousAntiCovid

[modifier | modifier le code]

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].

Solutions

[modifier | modifier le code]

Desire

[modifier | modifier le code]

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].

DP-3T Unlikable

[modifier | modifier le code]

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].

ZE2-P3T

[modifier | modifier le code]

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].

Choix politiques

[modifier | modifier le code]

Concernant la confiance accordée à une entité centrale, il y a plusieurs exemples de pays ayant détourné l'application de son rôle premier.

  • En Israël, dans le cadre d'enquêtes judiciaires, la police peut maintenant accéder aux données de géolocalisation[48].
  • À Singapour, un projet de loi vise à rendre l'utilisation de l'application obligatoire d'ici fin décembre 2020. Les résidents devront utiliser l'application ou ils ne seront plus autorisés à accéder aux magasins, écoles ou autres lieux publics[49]. La police peut accéder aux données de l'application TraceTogether dans le cadre d'enquêtes judiciaires[50].
  • En Inde, alors que l'application possède le plus grand nombre d'utilisateurs, le gouvernement indien rend obligatoire l'utilisation de l'application à la population de certaines régions critiques et aux employés en temps de travail. Cependant, l'application est largement critiquée pour collecter des informations non nécessaires sur ses utilisateurs comme le sexe, la profession, le statut social ou encore l'appartenance religieuse[51]. Pour répondre aux inquiétudes, le gouvernement indien a publié le code de l'application mobile en open source, mais pas celui du serveur qui, lui, reste fermé pour des soucis de sécurité[52]. Les hautes autorités gouvernementales ont déjà rendu publiques des informations sur des personnes mises en quarantaine, ce qui a mené à un échange illégal de données privées et personnelles d'après la norme de la minimisation des données, mais aucune loi ne régit l'application sur la protection des données[51].
  • Au Qatar, l'application Ehteraz est rendue obligatoire par le gouvernement[53]. L'application utilise à la fois le Bluetooth et les coordonnées GPS avec un système centralisé, ce qui créa des inquiétudes pour Amnesty International, car les autorités du Qatar pourraient utiliser ces données pour surveiller sa population[42].
  • En Turquie, l'application Hayat Eve Sığar ("La vie tient à la maison") est obligatoire pour se rendre dans les lieux publics[54]. L'application fonctionne sur un modèle centralisé et est particulièrement intrusive, récoltant à la fois les coordonnées GPS, la caméra et les contacts[55].
  • Chaque gouvernement voulant créer une application Covid-19 doit choisir entre une solution à système centralisé ou à système décentralisé. D'après l'AFP, le succès des applications Covid-19 de certains pays européens comme l'Allemagne, l'Italie ou la Suisse provient du choix du système décentralisé qui garantirait la protection des données de l'utilisateur, contrairement au choix d'un système centralisé comme en France. La Grande-Bretagne a abandonné son projet d'application Covid-19 utilisant un système centralisé pour utiliser un système décentralisé[56].
  • L'application chinoise génère un Code QR de couleur qui indique l'état potentiel de contagion de l'utilisateur. Les citoyens doivent scanner leur Code QR pour accéder à tous les lieux publics. Un Code QR vert permet de circuler dans tous les lieux publics comme les restaurants, centres commerciaux et transports en commun. Un Code QR jaune contraint à une mise en quarantaine de sept jours et un rouge de quatorze jours[57]. D'après le New York Times, l'application transmet la localisation précise de la personne et un numéro de code d'identification à un serveur de la police. Les autorités chinoises sont informées chaque fois qu’un Code QR est numérisé dans un nouvel endroit, permettant de pister les citoyens et d'actualiser en temps réel la couleur du Code QR[58]. La ville de Hangzhou envisage de pérenniser l'application de traçage après le Covid-19. La ville souhaite attribuer une note de santé sur 100 à ses habitants en fonction de leurs habitudes de consommation, leurs modes de déplacements et la durée de leur sommeil. En fonction de cette note, les habitants pourraient ne pas avoir accès à certains bâtiments, commerces, services ou transports en commun[59].
  • En France la CNIL estime que l’application StopCovid respecte pour l’essentiel le RGPD et la loi Informatique et Libertés. Elle a cependant relevé plusieurs irrégularités et a mis le ministère des Solidarités et de la Santé en demeure d’y remédier le . Parmi ces irrégularités le filtrage pour conserver uniquement l'historique des utilisateurs ayant été en contact à moins d’un mètre pendant au moins 15 minutes est fait au niveau du serveur central au lieu d’être réalisé au niveau du téléphone de l’utilisateur. Une autre irrégularité est une analyse d’impact relative à la protection des données qui est incomplète en ce qui concerne des traitements de données réalisées à des fins de sécurité (solution anti-DDOS collectant l’adresse IP et recaptcha)[60]. Les modifications demandées par la CNIL ayant été ajouté dans l'application, la CNIL a clôt la mise en demeure à l’encontre du ministère des Solidarités et de la Santé le [61].
  • La Thaïlande a décidé de rendre obligatoire l'installation de son application contre le Covid-19 pour tous déplacements interprovinciaux dans les zones de contrôle maximum déclarées[62].

Notes et références

[modifier | modifier le code]
  1. ↑ Serge Braudo
  2. ↑ Azad 2020, p. 7
  3. ↑ Ahmed Nadeem 2020, p. 134577
  4. ↑ TraceSecure 2020, p. 2
  5. ↑ Genia Kostka 2020, p. 25
  6. ↑ Hyunghoon Cho 2020, p. 2-3
  7. ↑ TousAntiCovid 2020
  8. ↑ Azad2020 2020, p. 7-11
  9. ↑ Fraunhofer AISE 2020, p. 3
  10. ↑ Mayers Baker 2020, p. 3-4
  11. ↑ Lian Fang 2020, p. 2
  12. ↑ Rakning C-19 2020
  13. ↑ Aarogya Setu 2020
  14. ↑ Suchit LEESA-NGUANSUK 2020
  15. ↑ LiJinfeng 2020, p. 4
  16. ↑ Jason Bay 2020, p. 3
  17. ↑ Ahmed Nadeem 2020, p. 134586
  18. ↑ Rajan Gupta 2020, p. 4
  19. ↑ Alastair R. Beresford 2004, p. 1
  20. ↑ Hecht-Felella 2020
  21. ↑ a et b Ahmed Nadeem 2020, p. 134578
  22. ↑ a et b Ahmed Nadeem 2020, p. 134580.
  23. ↑ a et b Ahmed Nadeem 2020, p. 134581
  24. ↑ a et b Claude Castelluccia 2020, p. 3-4
  25. ↑ Xavier Bonnetain 2020, p. 6
  26. ↑ a et b La quadrature du net 2020.
  27. ↑ a b c et d Ahmed Nadeem 2020, p. 134588
  28. ↑ a b et c Francesco Buccafurri 2020, p. 11
  29. ↑ a b c d et e Francesco Buccafurri 2020, p. 12
  30. ↑ a b c d et e Ahmed Nadeem 2020, p. 134587
  31. ↑ Francesco Buccafurri 2020, p. 10
  32. ↑ a b c et d Ahmed Nadeem 2020, p. 134589
  33. ↑ Wasilij 2020, p. 46
  34. ↑ Xavier Bonnetain 2020, p. 1
  35. ↑ Carmela Troncoso 2020
  36. ↑ Jason Bay 2020
  37. ↑ Antonioli 1999, p. 1047-1061
  38. ↑ Shahriar Hassana 2017
  39. ↑ (en) Paul-Olivier Dehaye et Joel Reardon, « Proximity Tracing in an Ecosystem of Surveillance Capitalism », WPES'20: Proceedings of the 19th Workshop on Privacy in the Electronic Society, Association for Computing Machinery,‎ , p. 191–203 (ISBN 978-1-4503-8086-7, DOI 10.1145/3411497.3420219, lire en ligne).
  40. ↑ Robert Baptiste 2020
  41. ↑ Aarogya Setu 2020
  42. ↑ a et b Amnesty International 2020
  43. ↑ Claude Castelluccia 2020, p. 4
  44. ↑ Olivier Blazy 2020
  45. ↑ Desire 2020, p. 6
  46. ↑ Troncoso 2020, p. 18
  47. ↑ Francesco Buccafurri 2020, p. 1
  48. ↑ Josh Breiner 2020
  49. ↑ Bobbie Johnson 2020
  50. ↑ Matthew Mohan 2021
  51. ↑ a et b Raja Gupta 2020, p. 6
  52. ↑ Raja Gupta 2020, p. 3
  53. ↑ Qatar News Agency 2020
  54. ↑ 2020 Travel Advice Turkey
  55. ↑ 2020 Emre
  56. ↑ AFP 2020
  57. ↑ Fan Liang 2020, p. 1-2
  58. ↑ Paul Mozur 2020
  59. ↑ Samuel Kahn 2020
  60. ↑ CNIL juillet 2020
  61. ↑ CNIL septembre 2020
  62. ↑ Redaction Thaïlande 2021

Bibliographie

[modifier | modifier le code]
  • (en) Muhammad Ajmal Azad, Junaid Arshad, Syed Muhammad Ali Akmal et Al, « A First Look at Privacy Analysis of COVID-19 Contact Tracing Mobile Applications », IEEE Internet of Things Journal ( Early Access ),‎ , p. 1-11 (ISSN 2327-4662, DOI 10.1109/JIOT.2020.3024180). Ouvrage utilisé pour la rédaction de l'article
  • (en) Daniele Antonioli, Nils Ole Tippenhauer et Kasper B. Rasmussen, « The KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of Bluetooth BR/EDR », 28th USENIX Security Symposium (USENIX Security 19),‎ , p. 1047-1061 (ISBN 978-1-939133-06-9, lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Hassan, Shaikh and Bibon, Soumik and Hossain, Md Shohrab and Atiquzzaman, Mohammed, « Security threats in Bluetooth technology », Computers & Security, vol. 74,‎ (DOI 10.1016/j.cose.2017.03.008). Ouvrage utilisé pour la rédaction de l'article
  • (en) Fan Liang et & al., « COVID-19 and Health Code: How Digital Platforms Tackle the Pandemic in China », Social Media + Society, vol. 6, no 3,‎ , p. 2056305120947657 (DOI 10.1177/2056305120947657). Ouvrage utilisé pour la rédaction de l'article
  • (en) Gupta, Rajan and Bedi, Manan and Goyal, Prashi and Wadhera, Srishti and Verma, Vaishnavi, « Analysis of COVID-19 Tracking Tool in India: Case Study of Aarogya Setu Mobile Application », Association for Computing Machinery, vol. 1, no 4,‎ , p. 1-8 (ISSN 2691-199X, DOI 10.1145/3416088). Ouvrage utilisé pour la rédaction de l'article
  • Emre Kursat Kaya, « SAFETY AND PRIVACY IN THE TIME OF COVID-19: CONTACT TRACING APPLICATIONS », Cyber Governance and Digital Democracy, Centre for Economics and Foreign Policy Studies,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • Wasilij Beskorovajnov and Felix Dörre and Gunnar Hartung and Alexander Koch and Jörn Müller-Quade and Thorsten Strufe, « ConTra Corona: Contact Tracing against the Coronavirus by Bridging the Centralized–Decentralized Divide for Stronger Privacy », Cryptology ePrint Archive, vol. Report 2020/505,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Ahmed, Nadeem and Michelin, Regio and Xue, Wanli and Ruj, Sushmita and Malaney, Robert and Kanhere, Salil and Seneviratne, Aruna and Hu, Wen and Janicke, Helge and Jha, Sanjay, « A Survey of COVID-19 Contact Tracing Apps, », IEEE Access,, vol. PP,,‎ , p. 1-1, (DOI 10.1109/ACCESS.2020.3010226). Ouvrage utilisé pour la rédaction de l'article
  • (en) Fraunhofer AISEC, « Pandemic Contact Tracing Apps: DP-3T, PEPP-PT NTK, and ROBERT from a Privacy Perspective », Cryptology ePrint Archive, Report 2020/489,‎ 2020, (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Li Jinfeng and Guo Xinyi, « COVID-19 Contact-tracing Apps: a Survey on the Global Deployment and Challenges », arXiv e-prints,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) C. Castelluccia, N. Bielova, A. Boutet, M. Cunche, C. Lauradoux, D. Le Métayer et V. Roca, « ROBERT : ROBust and privacy-presERving proximityTracing », HAL archives-ouvertes.fr,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) J. Bell, D. Butler, A. Boutet, C. Hicks et J. Crowcrof, « TraceSecure : Towards Privacy PreservingContact Tracing », arxiv,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) J. Bay, J. Kek, A. Tan, C. Sheng Hau, L. Yongquan, J. Tan et T. Anh Quy, « BlueTrace : A privacy-preserving protocol forcommunity-driven contact tracing across borders », HAL archives-ouvertes.fr,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Serge Vaudenay, « Analysis of DP3T », none,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Luca Ferretti et & al., « Quantifying SARS-CoV-2 transmission suggests epidemic control with digital contact tracing », JMIR mHealth and uHealth,‎ (DOI 10.1126/science.abb6936, lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Jay Stanley et Jennifer Stisa Granick, « ACLU White Paper: The Limits of Location Tracking in an Epidemic », aclu,‎ (lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) A. R. Beresford et F. Stajano, « Mix zones: user privacy in location-aware services », IEEE Annual Conference on Pervasive Computing and Communications Workshops, 2004. Proceedings of the Second,‎ , {127-131}, (DOI 10.1109/PERCOMW.2004.1276918, lire en ligne). Ouvrage utilisé pour la rédaction de l'article.
  • (en) M. Azad, S.M.A Akmal et J. Arshad, « A First Look at Privacy Analysis of COVID-19 Contact Tracing Mobile Applications », IEEE Internet of Things Journal,‎ , p. 1-1 (DOI 10.1109/JIOT.2020.3024180). Ouvrage utilisé pour la rédaction de l'article
  • (en) Genia Kostka et Sabrina Habich-Sobiegalla, « In Times of Crisis: Public Perceptions Towards COVID-19 Contact Tracing Apps in China, Germany and the US », SSRN,‎ (DOI 10.2139/ssrn.3693783, lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Francesco Buccafurri, Vincenzo De Angelis et Cecilia Labrini, « A Privacy-Preserving Solution for Proximity Tracing Avoiding Identifier Exchanging », 2020 International Conference on Cyberworlds (CW),‎ , p. 235-242 (DOI 10.1109/CW49994.2020.00045, lire en ligne). Ouvrage utilisé pour la rédaction de l'article
  • (en) Thao L. P. Nguyen, Tran Khanh Dang, Tran Tri Dang et Ai Thao Nguyen Thi, « A Three-Way Energy Efficient Authentication Protocol Using Bluetooth Low Energy », Lecture Notes in Computer Science, vol 12466,‎ (DOI 10.1016/j.cose.2017.03.008, lire en ligne)
  • (en) S. Sharma and G. Singh and R. Sharma and P. Jones and S. Kraus and Y. K. Dwivedi, « Digital Health Innovation: Exploring Adoption of COVID-19 Digital Contact Tracing Apps », IEEE Transactions on Engineering Management,‎ , p. 1-17 (DOI 10.1109/TEM.2020.3019033)
  • (en) Hyunghoon Cho, Daphne Ippolito et Yun William Yu, « Contact Tracing Mobile Apps for COVID-19: Privacy Considerations and Related Trade-offs », arxiv.org,‎ (lire en ligne)
  • (en) Ramesh Raskar et & al., « AppsGoneRogue : Maintaining Personal Privacy in an Epidemic », arxiv.org,‎ (lire en ligne)
  • (en) I. Nakamoto et & al., « A COVID-19 Contact Tracing Self-Confirmation System for the General Population in Japan: Design and Implementation Evaluation (Preprint) », JMIR mHealth and uHealth,‎ (DOI 10.2196/22098, lire en ligne)
  • (en) Tania Martin, Georgios Karopoulos, José L. Hernández-Ramos, Georgios Kambourakis, Igor Nai Fovino, « "Demystifying COVID-19 Digital Contact Tracing: A Survey on Frameworks and Mobile Apps" », Wireless Communications and Mobile Computing, vol. vol. 2020,‎ , p. 29 pages (DOI 10.1155/2020/8851429)
  • Bradford, Laura and Aboy, Mateo and Liddell, Kathleen, « COVID-19 contact tracing apps: a stress test for privacy, the GDPR, and data protection regimes », Journal of Law and the Biosciences, vol. 7, no 1,‎ (ISSN 2053-9711, DOI 10.1093/jlb/lsaa034, lire en ligne)
  • Pietro Tedeschi and S. Bakiras and R. D. Pietro, « SpreadMeNot: A Provably Secure and Privacy-Preserving Contact Tracing Protocol », ArXiv, vol. abs/2011.07306,‎ (lire en ligne)
  • Nguyen, Thien Duc and Miettinen, Markus and Sadeghi, Ahmad-Reza, « Long Live Randomization: On Privacy-Preserving Contact Tracing in Pandemic », Proceedings of the 7th ACM Workshop on Moving Target Defense, Virtual Event, USA, Association for Computing Machinery,‎ , p. 1–9 (ISBN 9781450380850, DOI 10.1145/3411496.3421229, lire en ligne)
  • Seldağ Güneş Peschke and Ömer Fatih Sayan, « CHAPTER 9. A Comparative Study of Privacy Policies and Data Protection During the COVID-19 Pandemic Within Different Countries », CORONALOGY: Multidisciplinary Academic Analysis in Perspective of Covid-19, Berlin, Sciendo,‎ , p. 186 - 196 (ISBN 9788366675162, DOI 10.2478/9788366675162-009, lire en ligne)

Liens externes

[modifier | modifier le code]