Face à l'API Apple et Google, le gouvernement tente de convaincre du bien-fondé de StopCovid

Mickaël Bazoge |

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, , 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

Pour aller plus loin :
avatar Sindanárië | 

C’est juste une initiation et un apprentissage au développement d’une application pour smartphone pour l’ensemble des acteurs !

Il faut rappeler que ces acteurs étaient restés spécialisés dans l’électromécanique de 1950 jugée plus sûre et surtout bien comprise!

Le but de cette application n’est pas qu’elle fonctionne ou puisse servir, mais juste pour voir comment on débute dans un domaine qui serait l’avenir pour la France et les prochaines 50 années à venir!

L’espoir pour les entreprises françaises étant d’arriver, dans les 100 ans à venir, au même niveau que cette drôle civilisation du passé (les Atlantes qui sait) qui avait inventé MacOS 7.

avatar corben | 

Je comprends pas qu’on fasse tant de battage médiatique pour cette app prévue trop tard, pas encore validée légalement et qui ne sera utilisée que par une minorité de personnes

Beaucoup de vent pour rien et surtout de ressources gaspillées aux frais du contribuable

avatar pacou | 

De toute façon je n’utiliserais ni l’une, ni l’autre.
Pas confiance dans les intentions ni des ricains, ni du gouvernement français (pour être plus précis : de l’administration française).

Si ils mettaient autant d’énergie pour toutes les épidémies, ce serait moins louche, mais là ça sent l’opportunisme à plein nez.

avatar pagaupa | 

Ah le bashing français est en route!
Et pourquoi la France ne pourrait-elle pas devenir bonne en développement ?

avatar Moonwalker | 

À cause de sa technostructure.

On a les écoles, les talents, mais il n'y a aucun avenir pour eux ici parce que les médiocres gouvernent.

avatar Sonic Tooth | 

C’est-à-dire, en clair, que l’appli sera prête une fois que le virus aura disparu/muté. Vu comment les chiffres de nouvelles contaminations chutent il n’y a aucun doute là-dessus.

avatar Adrienhb | 

Une remarque en passant: "activer le Bluetooth en permanence"... sauf erreur Apple incite fortement à ce qu'il en soit ainsi. Ne serait-ce par le fait qu'il faille aller dans les réglages pour le désactiver. Si on passe par les raccourcis, il revient à minuit. Et de mémoire des messages peuvent apparaître pour vous inciter à le laisser tout le temps activé.

avatar lop1 | 

De l'open source où 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 , c'est ce que l'on appelle un mensonge. On cache la partie la plus problématique donc on fait exactement l'inverse de l'open source .

avatar PierreBondurant | 

“une disponibilité de l'app de traçage des contacts pour le 2 juin”

Maintenant on sait que la fin de l’épidémie sera le 2 juin!

avatar alucardex | 

Se poser des questions sur la bonne technologie, le tracking, la sécurité .. je crois que ces questions n'ont pas vraiment d'intérêt.

Ps : Je vais forcer un peu le trait :)

Tout ça, c'est complètement c** !

Sans déconner :
-> Les personnes à risque et âgées restent chez elles le plus possible et respectent du mieux possible les gestes, car ils ont peur (à raison). Donc cette population ne va pas augmenter beaucoup en nouveaux cas.
-> Les personnes âgées ne savent pas utiliser un téléphone, donc pas d'application. Oups.
-> Les asymptomatiques n'ont aucune raison d'aller faire un test .. ils n'ont pas de symptôme : donc ils ne vont prévenir personne via une app ou autre puisqu'ils ne le savent pas OoOo.

Donc l'application permet d'aider (si, si, j'en suis convaincu) pour un seul cas en gros :
-> un asymptomatique a installé l'application
-> il croise une personne qui elle-même a installé l'application et se colle à elle (moins d1 mètre) pendant 15 minutes.
-> il contamine cette personne
-> Cette personne est testée positive et on remonte pour voir qui était en contact.

Je sais pas si c'est nécessaire de faire une table de probabilité ..

C'est une application pour jouer à se faire peur... peut-être que cette application aidera les parisiens qui prennent le RER ..

La vraie question à mon sens est : qui est le c** qui a eu cette idée..

Portez un masque, lavez vous les mains, vous collez pas aux autres et leur crachez pas dans le dos.. je pense que se sera plus utile.

avatar themasck | 

que des iphones representés sur les planches 😂😂

avatar Luneart | 

On a donc « Sylvie, Justin et Johanna » mais sur l’illustration deux hommes et une femme !
Cherchez l’erreur 🤣

avatar fte | 

@Luneart

Aucune erreur, c’est la parité. Un homme, une femme, un.e non-binaire.

avatar wallou | 

De toute façon, tous ceux qui pouvaient être tués sont déjà morts.
La campagne de tests est empêchée au maximum depuis le début.

Concernant les app, depuis le 11 Février !!
En Corée : 4 différentes sur tous les Stores !!

avatar ahvanco | 

L'app du gouvernement est absolument magnifique: il oublient quand même de dire qu'elle ne sera valable que sur le minitel.

avatar GenieTech.fr | 

L'intérêt d'une app est bien évidemment lié à sa large adoption, qui comme tout business case, doit être orienté par le besoin et pour l'intérêt de l'utilisateur, et doit être piloté avec agilité (ce qui manque peut-être à l'app gouvernementale actuelle pour ne pas basculer sur le protocole standardisé d'apple/google)
Bien sûr cette app doit prévenir la pandémie, mais aussi avant tout doit permettre de se protéger soi-même.
Jouir d'un niveau de confiance temps réel de son entourage, 100% respectueux de la vie privée, serait peut-être un plus pour revivre comme avant et sauver l'économie.
Pourquoi alors ne pas apporter une notion de "pass" donnant l'accès à des zones "Covid-free" que cette app pourrait gérer?
L'EN API actuelle ne permet pas d'alerter en temps réel (demande faite et comprise par apple, en cours chez google). Et pourtant, à peu de frais protocolairement parlant, cela donnerait une autre dimension à cette app de santé publique qui risque d'être utile pendant un certain temps.
Vos réactions (?) au projet zones "Covid-free" : https://www.genietech.fr/covid-free-app
D'avance merci,
GenieTech.fr

avatar fte | 

@GenieTech.fr

"comme tout business case"
"l'intérêt de l'utilisateur"
"piloté avec agilité"
"de se protéger soi-même."
"revivre comme avant et sauver l'économie"
"une notion de "pass" donnant l'accès à des zones "Covid-free""

"Vos réactions (?)"

Discours capitaliste individualiste extrême-occidental, façon Bretton Wood, absolument révulsant. 🤮

avatar Pyby | 

Les alertes par SMS "Cell broadcast", pas exactement pour le même usage, mais remis au goût du jour.

Interview d'un hacker toulousain:
https://www.francetvinfo.fr/sante/maladie/coronavirus/nouveau-monde-au-l...

Si le sujet du "Bluetooth contact tracing" intéresse, il a coécrit un article sur Medium:
https://medium.com/@paula_forteza/stopcovid-une-efficacité-incertaine-pour-des-risques-réels-7e12b3747cfc

Tout est une question d'évaluation du risque, pour un bénéfice attendu en retour. Au départ, convaincu, la connaissance s'affine et le doute s'installe.
Tant que les démocraties ne l'imposent pas, c'est bien aux créateurs et promoteurs du service / du produit, de convaincre chacun de son utilité.

avatar byte_order | 

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

De une, tous les "issues" remontées sur les gitlab de StopCovid ne concernent pas des pbs de sécurité.

De deux, il aurait été de bon ton, et plus ethique journalistiquement parlant, de souligner que dans le second lien cité, qui porte sur la partie du code iOS de StopCovid, 9 sur les 10 (et que 4 concernant la sécurité) publiées sont ceux de @FloMo, Florent Morin, qui est collaborateur de iGeneration ! On est dans ce cas plus proche de "un développeur / journaliste qu'on connait" que "les" développeurs, genre une vaste communauté, hein...

De trois, merci d'indiquer comment juger que l'API proposée par Apple/Google n'a pas de problème de sécurité dans sa conception ou son implémentation ? Faute de moyen de pouvoir le faire, tout repose sur la confiance, rien d'autre. Cela aurait été bien de le reconnaitre, histoire de ne pas avoir un article que à charge. Je rappelle que les développeurs d'Apple ne sont pas surhumains, qu'ils ont laissé trainé un bug affichant le mot de passe de FileVault en clair comme indice pour le retrouver dans des versions de macOS. Ou leur goto fail dans l'implementation SSL dans iOS, montrant l'absence de sérieux dans les outils QA chez Apple. Et c'étaitpas y'a 20 ans ça.

Le mythe de la sécurité supérieure parce que propriétaire et grosse boite a encore des belles années devant lui, il semblerait.

> Par ailleurs, cette solution est désormais pleinement disponible, au contraire de StopCovid.

Ah, parce que l'API fait tout toute seule, ayé y'a donc une app universelle pour iOS et Android de traçage de contacts !?
Non. C'est l'API qui est disponible, cela ne suffit pas pour construire la solution complète, c'est juste une brique côté client mobile.

Pages

CONNEXION UTILISATEUR