C'est le 27 mai que le Parlement débattra et votera sur l'application StopCovid. Cédric O, le secrétaire d'État au numérique, a fait miroiter une disponibilité de l'app de traçage des contacts pour le 2 juin, ce qui nous a apparu très optimiste au vu de l'avancement du projet (lire : Le code source de StopCovid en partie disponible, une sortie le 2 juin parait difficile). Quoi qu'il en soit, le gouvernement a sorti l'artillerie lourde avec un dossier de presse qui, hasard du calendrier, tombe le lendemain de la disponibilité de l'API Exposure Notification d'Apple et de Google.

Cédric O vante un « projet emblématique du savoir-faire technologique français ». StopCovid est développé sous l'égide de l'Inria, où le secrétaire d'État cultive de solides amitiés (lire : StopCovid, un projet porté à bout de bras par Cédric O). L'app a pour vocation de « casser les chaînes de transmission du virus » en prévenant si un utilisateur a été en contact rapproché avec une personne testée positive au COVID-19 : les critères d'un « contact StopCovid » sont de moins d'un mètre pendant au moins 15 minutes.

À la réception d'une notification de contact, l'utilisateur doit s'isoler et consulter son médecin (ou appeler le 0800 130 000) pour bénéficier d'un suivi médical et le cas échéant, un test. S'il s'avère positif, l'utilisateur peut prévenir tous ceux qui ont croisé son chemin ces 14 derniers jours ; en retour, ces derniers seront prévenus et ils pourront être pris en charge par leur médecin.

Le gouvernement rappelle les cinq grands principes de StopCovid :

• Volontariat : l'app n'est pas obligatoire.
• Respect de la vie privée : l'app utilise le Bluetooth et pas la localisation GPS.
• Anonymat : il est impossible de connaitre l'identité de l'utilisateur de l'application, et StopCovid ne contient aucun système d'authentification lors de l'installation de l'app. L’application génèrera seulement des pseudonymes (crypto-identifiants éphémères) qui ne seront pas associés à une personne. Seuls ces pseudonymes éphémères sont stockés sur un smartphone et, le cas échéant, partagés vers un serveur central. Personne, pas même l’État, n’aura accès à une liste de personnes diagnostiquées positives ou à une liste des interactions sociales entre les utilisateurs.
• Transparence : les codes sources et la documentation sont livrés en fonction d'un calendrier lié au développement technique.
• Temporaire : l'app n'a pas vocation à perdurer au-delà de la crise sanitaire. Les crypto-identifiants n’ayant plus de pertinence d’un point de vue épidémiologique seront régulièrement supprimés (au bout de 15 jours).

Cela part d'un bon sentiment, mais on manque d'informations pour juger de la réalité de ces principes. Le travail est en effet loin d'être terminé du côté du gouvernement, alors que la solution d'Apple et de Google est achevée, disponible et documentée.

L'approche d'Apple et de Google

L'API Exposure Notification fait en sorte de contenir au maximum les données dans le smartphone. Quand des informations doivent sortir, le flot doit être limité et contrôlé. Et là désolé, il va falloir être un peu technique 😅.

Protection des identifiants — Les clés et les informations qui permettent de « construire » les identifiants (pseudonymes) sont stockés sur l'appareil de l'utilisateur uniquement par défaut. Chaque jour, une clé temporaire est générée, qui est conservée au maximum 14 jours. À partir de cet identifiant, deux clés sont créées à partir desquelles découlent un identifiant chiffré qui tourne et des méta-données. Ce sont ces informations qui sont ensuite envoyées en Bluetooth aux autres smartphones.

Protection Bluetooth — Seuls les contacts entre 5 et 30 minutes sont captés : en dessous des 5 minutes, le signal est ignoré. Au-delà de 30 minutes, il est également ignoré puisqu'il y a suffisamment de clés. Quand un signal tombe dans ce laps de temps, l'application capte l'identifiant aléatoire chiffré pour une période de 10 minutes, les méta-données (version, puissance du signal), et, toutes les informations de l'outil qui va capter le signal… donc, potentiellement, la géolocalisation. D'où l'importance d'ignorer les signaux sur une période trop courte ou trop longue.

Stockage des données — Pour le stockage des données sur les appareils, Apple et Google recommandent de les conserver de manière aléatoire, d'attendre avant de les distribuer et de les supprimer après 14 jours.

Protection de l'app — Le sujet est souvent ignoré, mais les failles d'iOS (sans oublier celles d'Android) nous rappellent que l'application de traçage des contacts doit être sécurisée de l'intérieur. Si elle ne protège pas suffisamment les données, la moindre vulnérabilité dans la cuirasse du système d'exploitation peut les exposer.

La partie Bluetooth et génération d'identifiants est gérée par le système, dont une partie est en lecture seule et qui a accès à l'enclave sécurisée. En cas de brèche dans l'app, ces parties restent sous haute sécurité. Les applications standard, celles qui n'ont pas accès à l'API, n'ont pas ces possibilités. Par ailleurs, au cas où l’app serait atteinte par une attaque externe qui prendrait son contrôle, le système lui bloque l’accès au GPS.

Signalement d'un malade — Le signalement d'un malade, c'est le seul moment où les données personnelles de l'utilisateur transitent en dehors de l'application de traçage. Si cette personne le souhaite, et il n'y a aucune obligation, elle peut envoyer ses propres clés ainsi que les périodes horaires utilisées. Cela implique que la personne malade ait donné son accord, sachant qu'elle ne partage que les clés qui signent les pseudonymes, et pas les pseudonymes eux mêmes. Il est difficile d'associer les pseudonymes aux clés, car il faudrait les avoir captés en Bluetooth au préalable.

Sécurité de la connexion — Pour ce qui concerne la sécurité de la connexion, Apple et Google recommandent l'utilisation de DeviceCheck afin de s'assurer que c'est bien l'application qui communique avec le serveur, et pas un malandrin ! Par ailleurs, il est probable qu'Apple recommande l'utilisation du HTTPS « renforcée » pour éviter les attaques Man-in-the-Middle. Le format recommandé pour la transmission des informations est Protocol Buffer en lieu et place de l'habituel JSON : ce n'est pas une sécurité en soi, mais le niveau de compression étant meilleur, cela ne facilitera pas la tâche au brigand.

Réception des données — Les données envoyées sur le serveur de l'autorité de santé ou du gouvernement sont donc des clés de diagnostic. Pour chacune d'entre elles, on a la clé utilisée pour générer les identifiants, ainsi que le début et la validité de la clé (une validité qui a une durée de 10 minutes). Apple et Google recommandent avec insistance de sécuriser cette connexion. Les trois barrières mises en place sont extrêmement difficiles à contourner : la vérification du canal de communication HTTPS, la vérification de l'authenticité de l'application et la vérification des données qui arrivent.

Envoi des données aux appareils — L'envoi des données aux appareils comprend deux barrières de base : la vérification du canal de communication HTTPS et celle de l'authenticité de l'application. Les deux partenaires en ajoutent une supplémentaire : les données envoyées sont non pas chiffrées, mais signées via des clés fournies par les autorités à Apple et Google. Des clés qui peuvent tourner. Toutes les 24 heures, l'application reçoit ces identifiants.

Diagnostic — Quant au diagnostic, il est géré par le framework qui valide les données (si elles ne sont pas validées, bim, elles seront ignorées). Il est ensuite possible de déchiffrer les données avec les clés, ce qui permet de poser le diagnostic. Et ce résultat est ensuite envoyé à l'application.

L'approche de StopCovid

Le gouvernement s'appuie sur le protocole ROBERT — pour ROBust and privacy-presERving proximity Tracing — pour l'application StopCovid. Les informations fournies par les autorités sont encore parcellaires, et pour cause le développement n'est pas terminé. La promesse de publication du code source est d'ailleurs sujette à caution, sachant qu'une partie « restreinte » restera cachée aux yeux de tous car « correspondant à des tests ou à des parties critiques pour la sécurité de l’infrastructure »…

On sait cependant que les informations qui permettent de générer les pseudonymes passent par internet : il y a donc un risque. L'approche consiste à faire transiter par internet un maximum d'informations, alors que celle d'Apple et de Google est que les données restent sur l'appareil des utilisateurs le plus possible.

Protection des identifiants Difficile de faire mieux que chez Apple, mais ce qu'accomplit StopCovid est équivalent… à l'exception d'une petite sécurité reCaptcha fournie par Google. Rien à voir avec DeviceCheck qui n'a pas été envisagé, et pour cause : le nombre d'appels à l'API est limité. Ensuite, les identifiants de chacun des utilisateurs sont fournis via Internet.

Protection Bluetooth — Le principe est similaire à celui de la solution d'Apple et de Google : l'idée est de sortir un identifiant anonyme régulièrement.

Protection de l'app — Elle dépend des développeurs en grande partie, mais ce qui est sûr c'est que l'application n'a pas accès aux enclaves sécurisées.

Signalement d'un malade — Le protocole ROBERT a cette spécificité d'envoyer les identifiants des malades potentiels. Aucun choix n'est laissé ici, contrairement à l'API Exposure Notification. Lors du test de dépistage, on ne peut pas s'opposer à l'utilisation des données pour repérer un cas COVID-19, en revanche il est toujours possible de refuser leur utilisation pour la recherche.

Diagnostic — Chaque application de chaque utilisateur s'identifie sur le serveur pour savoir s'il est potentiellement malade. Si c'est le cas, il en est informé, sans savoir qui l'a potentiellement contaminé.

Souveraineté numérique ou solution universelle ?

Il n'y a pas d'approche meilleure que l'autre. Les deux solutions avancées par Apple et Google d'un côté, le gouvernement français et ROBERT de l'autre peuvent servir à contenir la pandémie, comme l'explique la publication Science. Les autorités françaises ne manquent pourtant pas de relever les risques de faille « importants » et que « des modèles d'attaques informatiques sont déjà disponibles sur le web ».

Aucun système informatique n'est parfaitement sécurisé, c'est entendu. Mais il se trouve que StopCovid aussi présente des faiblesses, comme les développeurs le soulignent sur le GitLab de l'application (ici, là, ou encore ici). L'application de l'Inria nécessite également d'activer le Bluetooth en permanence, ce qui ouvre un vecteur de risque pour les applications qui utilisent le Bluetooth. Les apps avec l'API réservent le Bluetooth à un seul usage, celui d'envoi et de réception des signaux.

Par ailleurs, les autorités considèrent que leur mission de protection de la santé des Français relève « exclusivement de l'État et non d'acteurs privés internationaux ». Quand on sait qui se cache derrière le développement de StopCovid, cet argument de la souveraineté numérique souvent ressassé est une gentille fable pour esprits naïfs.

L'application est le fruit du travail commun d'organismes publics (Inria, ANSSI, Santé Publique France, la Direction interministérielle du numérique, l'Inserm) et d'entreprises privées : Capgemini, Dassault Systèmes, Lunabee Studio, Orange et Withings. De grands industriels dont une partie des capitaux est détenue par… des investisseurs étrangers ! Rappelons aussi en passant que pour protéger les identifiants, StopCovid utilise une solution reCaptcha fournie par un certain… Google.

Cette raideur vis à vis de l'API Exposure Notification est d'autant plus malvenue qu'une partie du travail de développement de ces outils a été réalisée en France, par quelques uns des meilleurs ingénieurs en sécurité d'Apple. Par ailleurs, cette solution est désormais pleinement disponible, au contraire de StopCovid.

Plusieurs gouvernements ont choisi la solution d'Apple et de Google, dont l'Allemagne, l'Italie et la Suisse (22 pays en tout). Pour ce qui nous concerne, l'API « proposée après que la France ait [sic] débuté ses travaux » ne donnerait pas les « garanties suffisantes en matière de respect de la vie privée et de protection des données de santé ». Les autorités françaises estiment que les outils d'Apple et de Google « reposent sur la transmission à tous les smartphones des pseudonymes des personnes diagnostiquées positives » : cela revient à dire qu’un diagnostic médical, « même sous une forme encryptée », circule dans toutes les applications.

Mais ce n'est pas le diagnostic qui transite, c'est la clé qui permet de détecter un contact. Une clé et une date, ce n'est pas contact. Le diagnostic est établi quand la clé permet de déverrouiller un identifiant reçu : le diagnostic est donc posé depuis le smartphone, pas depuis un serveur.

Il se pose également la question de l'interopérabilité. Lorsque les frontières intra-européennes vont rouvrir, que se passera-t-il quand un utilisateur français de StopCovid va se retrouver dans un pays qui a choisi l'API commune d'Apple et de Google ? Le gouvernement travaille sur cette question au sein de l'institut européen de standardisation des télécommunications (ETSI). Peu d'informations complémentaires sont disponibles sur ce sujet. Évidemment, ce serait tellement plus simple que tout le monde utilise la même solution…

La promesse de publication du code source est aussi sujette à caution, sachant qu'une partie « restreinte » restera cachée aux yeux de tous car « correspondant à des tests ou à des parties critiques pour la sécurité de l’infrastructure »… La question de la confiance se pose clairement alors que du côté d'Apple et de Google, la documentation ne manque pas.

Les parlementaires se saisiront de StopCovid le 27 mai. Pour peu que l'application franchisse le barrage du vote, il ne restera plus qu'à la soumettre à l'App Store et au Play Store. Mais avant de la mettre à disposition de tous, il faudra bien réaliser au moins un test grandeur nature : on nous a indiqué que cette période allait être réduite à la portion congrue de 3 petits jours seulement. Il faut bien ça pour parvenir à une sortie le 2 juin.

Merci à Florent pour le coup de main