StopCovid et « contact tracing » : que contiennent les 44 pages de recommandations de l’Europe ?

Quelles lignes directrices que les États membres de l’Union européenne devraient-ils suivre pour mettre en œuvre des applications de traçage des contacts (« contact tracing »), à l’image de StopCovid en France ? C’est pour définir un plan de vol commun et organiser une réponse coordonnée à l’échelle du continent que la Commission européenne a dévoilé le 16 avril une « boîte à outils » dédiée.

Celle-ci vise à homogénéiser la réponse technique et doter les capitales d’un référentiel commun pour être sur la même longueur d’onde lorsque la levée progressive des mesures de confinement sera envisagée — et, avec elle, la possibilité de se déplacer de nouveau librement, à tout le moins dans l’espace Schengen dans un premier temps, si l’épidémie de coronavirus n’est pas maîtrisée dans le reste du monde.

Publié dans une première version, ce cadre sera probablement amené à évoluer au fil du temps. Mais d’ores et déjà, il est possible de relever plusieurs éléments notables dans ce document de 44 pages. Certaines des caractéristiques, obligations et problématiques que ce référentiel détaille sont d’ores et déjà prises en compte dans le cas de StopCovid, dont le développement a débuté en avril.

Pour aller plus loin

Pourquoi l’application StopCovid risque de ne servir à rien

Le cadre pour une appli de « contact tracing »

• Définition de ce qu’est un contact proche : utiliser des valeurs suffisantes pour définir ce qu’est un contact proche, en termes de distance, de durée et de contexte ;
• Durée de conservation des données de traçage des contacts : du fait de la durée d’incubation du virus SARS-CoV-2, l’historique des contacts doit être de 14 à 16 jours ;
• Information des utilisateurs à risque : elle peut se faire directement via l’application ou à travers les autorités sanitaires ;
• Délai pour avertir les utilisateurs à risque : en cas de test positif au Covid-19, les individus doivent être prévenus immédiatement ;
• Signalement d’un cas positif à travers l’application : Seules des autorités de santé devraient être habilitées à confirmer une infection et à déclencher une alerte via l’application ;
• Information à fournir aux contacts : ils doivent être informés de la possibilité d’une infection due à un contact étroit avec une personne infectée et de la marche à suivre (par exemple : confinement renforcé, symptômes à contrôler, mesures à prendre, etc.).

Sur le papier, l’application StopCovid doit pouvoir fonctionner via le Bluetooth pour communiquer avec un autre smartphone à proximité. // Source : FireChat

Ses spécificités techniques

• Détection de la proximité : celle-ci doit se faire dans un rayon de 1,5 mètre autour du smartphone, avec une précision de 50 centimètres, afin d’éviter les faux positifs, y compris quand le smartphone est verrouillé et rappeler en permanence qu’elle fonctionne ;
• Enregistrement des identifiants : celui-ci ne doit s’effectuer que si un autre smartphone se trouve dans une fenêtre épidémiologique pertinente (durée et distance) ;
• Identifiants éphémères : Pour éviter tout risque d’espionnage, de piratage ou de pistage, l’identifiant doit être modifié périodiquement et être généré de façon pseudo-aléatoire. Les données qu’il contient doivent être chiffrées et limitées au strict nécessaire, sans l’identifiant du terminal ;
• Inscription d’un cas positif dans l’application : elle doit être facile à réaliser pour les autorités de santé, en flashant par exemple un code QR à usage unique, afin d’éviter toute saisie erronée ;
• Déploiement : l’application doit pouvoir accueillir 100 millions d’utilisateurs en un mois. Les exigences technologiques doivent donc être réduites au minimum pour atteindre le plus grand nombre de personnes et ne pas réserver l’outil aux smartphones les plus récents ;
• Appareils : l’application doit pouvoir être installée sur tous les smartphones ayant une connectivité en Bluetooth, qu’importe le système d’exploitation ou la plateforme. Elle doit aussi éviter de trop peser sur la batterie ;
• Open source : les spécifications techniques et le code source de l’application doivent être accessibles publiquement, pour en assurer au maximum l’interopérabilité, l’emploi et la vérification.

L’emploi d’un code QR est une piste pour inscrire un cas positif dans l’application en limitant le risque d’erreur. // Source : Lauren Manning

Préservation de la vie privée des individus

• Application temporaire : elle devrait être désactivée automatiquement dès que la crise est terminée ;
• Suppression des données : toutes les données personnelles et de proximité restante devraient être effacées, à la fin de la crise ;
• Volontariat et consentement libre et éclairé : l’application doit être basée sur le consentement avec une information complète sur le traitement prévu des données
• Pas de géolocalisation : le pistage n’est ni nécessaire ni recommandé pour le suivi des contacts, car il ne s’agit pas de suivre les déplacements. Cela violerait le principe de minimisation des données et poserait des problèmes majeurs de sécurité et de respect de la vie privée ;
• Anonymat : l’application doit garantir qu’aucun utilisateur ne connaisse l’identité des personnes infectées ou celle de proches de personnes infectées ;
• Génération d’identifiants : Les identifiants éphémères transmis entre les appareils via le Bluetooth doivent être générés de manière pseudo-aléatoire et périodiquement modifiés . Ils ne doivent permettre à personne d’identifier l’utilisateur d’un smartphone spécifique ;
• Pseudonymes : les pseudonymes ne doivent avoir aucun lien avec des informations personnelles identifiables de longue durée ;
• Chiffrement : les données doivent être chiffrées autant que possible afin de renforcer la sécurité et la confidentialité.

Sécurité

Source : Illustration Lucie Benoit pour Numerama

Un développement dans les règles de l’art

• Minimisation des données et autorisations réduites : les données doivent être autant que possible être limitées au strict nécessaire, les rendre anonymes ou pseudonymes quand l’occasion se présente, sécurisées et détruites quand elles ne sont plus requises. Les autorisations de l’application doivent aussi être minimes.
• Développement dans les règles de l’art : Les développeurs doivent suivre les bonnes pratiques en matière de développement et de conception. Ils doivent multiplier les tests, utiliser des outils et des environnements de travail à jour, mais aussi faire attention aux attaques informatiques les ciblant spécifiquement au regard de leur mission ;
• Sécurité intégrée : les fonctions de sécurité intégrées aux systèmes d’exploitation des smartphones doivent être utilisées, que ce soit pour l’authentification, le stockage ou le fonctionnement dans un espace isolé et sécurisé ;
• Communications : les communications doivent être chiffrées en utilisant les outils et les protocoles cryptographiques publics adéquats, testés et reconnus. Des mesures contre des tentatives d’usurpation doivent être mises en place ;
• Application sécurisée par défaut et conviviale : elle doit pouvoir être utilisée par tout le monde, pas uniquement par les geeks. Il faut donc que ses réglages de sécurité soient déjà actifs et élevés, afin de n’avoir rien à configurer. L’application doit aussi être facile d’accès pour que l’utilisateur ne s’y perde pas ou l’utilise mal ;
• Authentification de l’utilisateur : elle doit être envisagée pour pouvoir sécuriser l’accès à des données sensibles de l’utilisateur ;
• Éviter du code source tiers : il est conseillé d’utiliser le moins possible des ressources extérieures. Si c’est le cas, il faut s’assurer qu’elles soient vérifiables et à jour ;
• Gérer les smartphones à risque : il faut pouvoir tenir compte de la fragmentation, car tout le monde n’utilise pas la version la plus à jour de son système d’exploitation. En outre, il faut aussi gérer les smartphones qui ont été rootés, jailbreakés ou modifiés d’une façon ou d’une autre par les utilisateurs ;
• Accessibilité et inclusivité : l’application doit pouvoir satisfaire les normes en vigueur sur les personnes handicapées. Il faut aussi envisager un plan pour des catégories très particulières de personnes : les personnes qui sont exclues du numérique, le personnel soignant, etc.

L’accessibilité de l’application ne doit pas non plus être oubliée, pour répondre aux besoins spécifiques des personnes handicapées. // Source : Home Office

Tenir compte des menaces informatiques

• Évaluation des risques : les États doivent estimer les risques cyber pouvant cibler une application comme StopCovid et les infrastructures sur lesquelles elle repose. Incidents récents, limites techniques connues (que ce soit les protocoles de communication, les langages de programmation utilisés, les systèmes d’exploitation, etc.) ;
• Partage d’informations : les États sont encouragés à faire collaborer les équipes en charge du projet, mais aussi leurs différents services nationaux et éventuellement à un niveau européen ;
• Réponse à un incident : les États doivent disposer d’un plan pour gérer tout incident, en mobilisant si besoin des agences spécialisées dans la cybersécurité et la protection des données ;
• Audit indépendant : le code devrait être testé et vérifié de façon indépendante par des experts à chaque fois que celui-ci est mis à jour, qu’il s’agisse de l’application ou de tout ce qui se trouve en coulisses, pour des enjeux de confiance et de transparence. Le code source doit être rendu public au maximum.
• Signalement des bugs et des failles : il doit être possible de remonter tout souci dans l’application, que l’on soit simple utilisateur ou expert international. Un plan pour la divulgation des vulnérabilités doit être envisagé, une fois celles-ci corrigées ;
• Chasse aux bugs : un programme de chasse aux bugs devrait être mis en place, pour inciter, grâce à un système de récompense, des spécialistes à challenger la sécurité de l’application, afin d’en rehausser la qualité.

Pour traquer les failles, un programme de chasse aux bugs est recommandé. // Source : EFF