StopCovid : Inria dévoile son protocole ROBERT en réponse à celui d’Apple et Google

StopCovid : Inria dévoile son protocole ROBERT en réponse à celui d’Apple et Google

Mais que dira Raymonde si Robert plante ?

Avatar de l'auteur
Marc Rees

Publié dans

Logiciel

18/04/2020 8 minutes
62

StopCovid : Inria dévoile son protocole ROBERT en réponse à celui d’Apple et Google

En partenariat avec Fraunhofer, l’Inria publie aujourd’hui sur Github les premières briques du protocole « ROBERT » (pour ROBust and privacy-presERving proximity Tracing). Ces documents représentent « l’état de l’art de nos réflexions sur l’architecture technique d’une application de « contact tracing » respectueuse des valeurs européennes ».

« Le terme de tracking utilisé dans le débat public est impropre, car cet outil ne permettra pas la géolocalisation des personnes : il s’agit juste d’établir, grâce à la technologie Bluetooth, un historique de proximité entre différentes personnes équipées de l’application, auquel nul n’a accès, pas même le propriétaire du téléphone ». Voilà les lignes rouges qu’avait dessinées Cédric O lors de son audition à l’Assemblée nationale, devant la Commission des lois. 

Aujourd’hui, Inria publie sur la plateforme GitHub une présentation du protocole ROBust and privacy-presERving proximity Tracing. Un trait d’union entre le projet politique et le futur code. Fruit du travail du laboratoire Privatics de l'institut, il s’inscrit dans le cadre de l'initiative européenne PEPP-PT (Pan European PrivacyPreserving Proximity Tracing) « dont le but principal est de permettre le développement de solutions de suivi de contacts respectueuses des normes européennes en matière de protection des données, de vie privée et de sécurité, dans le cadre d’une réponse plus globale à la pandémie ».

On est donc encore loin de la mise à disposition des sources de StopCovid, la fameuse application du suivi de contacts. ROBERT, de son petit nom, n’est pas lui-même finalisé, témoignage que si les travaux avancent, une sortie de l'application avant le 11 mai n'est pas assurée comme le relevait le secrétaire d'État au numérique.

Toutefois, la mise en lumière de cet élément important permet d’en savoir plus sur l’architecture qui soutiendra le projet. Dans un texte explicatif, ce cadre est défini par contraste. « Il me semble utile de commencer par rappeler ce qu’une application qui reposerait sur ce protocole n’est pas, eu égard aux interrogations légitimes qui s’expriment et aux confusions qui peuvent avoir lieu » écrit Bruno Sportisse, PDG Inria.

Ni tracking, ni surveillance, ni délation. « Sa conception permet que PERSONNE, pas même l’État, n’ait accès à la liste des personnes diagnostiquées positives ou à la liste des interactions sociales ». Il est encore confirmé que l’application sera proposée non imposée. Une base donc volontaire, non obligatoire.

Une composante d'une politique de santé 

Inria repousse sans hésiter l'idée d’un sésame qui viendrait terrasser Covid-19 : « Aucune équipe travaillant sur ces sujets n’oublie que le « proximity tracing » n’est qu’une composante d’un ensemble plus vaste de mesures, dans le cadre d’une approche pilotée par une politique de santé. Je ne connais personne qui croie au solutionnisme technologique en la matière ». En clair, ROBERT et demain StopCovid ne sont que des briques d’un mur combinant une multitude de mesures de santé publique.

La difficulté de l’exercice est à conjuguer au pluriel. D’un, « la technologie Bluetooth n’a pas été conçue pour être précise dans l’estimation de distances entre deux smartphones ». Cela a été dit : ces transmissions dépendant de facteurs environnementaux ou internes au smartphone, comme l’état de la batterie, la position de l’appareil, la physiologie des personnes.

De deux, difficile de calquer ces variables avec celles relatives aux modèles de transmissions du virus : aérosols, gouttelettes, surfaces, charges virales… « Cette connaissance est encore très lacunaire et est susceptible de changer très rapidement, en fonction des retours d’expérience » reconnaît sans mal Bruno Sportisse.

Sur la structure même du protocole, « aucun projet n’a pour ambition de mettre en place un réseau de pair-à-pair, où tout reposerait sur une communauté supposée « indépendante » de terminaux/de smartphones qui échangent des informations entre eux ». Pourquoi ? « La raison principale est l’impact des failles de sécurité qui pourraient exister avec une telle approche ». Une forme « d'hommage » à la solution commune proposée par Apple et Google, sur laquelle des zones d’ombres planent toujours. 

Décentralisation, centralisation et crypto-identifiants

L’idée est de marier une solution centralisée et décentralisée, tout en étant sécurisée (l’ANSSI a d’ailleurs été impliquée à ces travaux). Une personne installe l’application. « Son smartphone reçoit alors un ensemble de crypto-identifiants (ou une méthode pour les générer toutes les 15 minutes) ».

Si le Bluethooth est activé, elle va « construire un historique des crypto-identifiants rencontrés, « à proximité », pendant une durée significative lors des déplacements (ces crypto identifiants étant sur les smartphones des personnes ayant elles aussi téléchargé l’application) ».

Que se passera-t-il si un des détenteurs est diagnostiqué positif ? Cette personne devra consentir à ce que « son historique de crypto-identifiants rencontrés soit envoyé sur un serveur d’une autorité de santé (par exemple), sans divulguer au serveur son (ses) propre(s) cryptoidentifiant(s) ».

Ainsi, prévient le document, « aucun lien n’est fait entre le téléphone de la personne et son historique. Chacun de ces crypto-identifiants est donc potentiellement « à risque » (il correspond, sans qu’aucun lien ne soit possible avec une personne, à un smartphone qui a été en proximité d’un smartphone porté par une personne qui a été ultérieurement diagnostiquée positive) ».

Dans le même temps, « chaque smartphone ayant téléchargé l’application vérifie auprès du serveur central, « de temps en temps » (toutes les heures, tous les jours, cela fait partie des paramètres à fixer) si ses propres crypto-identifiants sont parmi ceux à risque ». Si la réponse est positive, « cela signifie que le smartphone a été à proximité lors des jours précédents d’un smartphone porté par une personne qui s’est avérée être positive ultérieurement ».

Il y aura notification selon une évaluation du risque définie avec les épidémiologistes, en utilisant l’information de proximité. « La flexibilité du système est clé pour le management d’une crise sanitaire, la prise en compte de connaissances médicales qui évoluent rapidement, voire un apprentissage par le système (toujours sur la base de données statistiques anonymisées) pour le rendre plus efficace, par exemple, pour diminuer l’occurrence de faux positifs » insiste le PDG Inria. « Pour autant que l’autorité sanitaire ait la main sur tout cela ».

Robert StopCovid
Crédits : Inria

L’information diffusée devrait alors « déclencher un renvoi vers divers actes ». L’article évoque « un respect scrupuleux des gestes barrières, un suivi journalier des symptômes, une consultation, un test, etc. », sachant que ces suites relèvent des politiques de santé, non d’Inria.

« Par exemple, sur le serveur central (pour assumer le terme), il n’y a AUCUNE donnée relative au statut des personnes positives. Il s’y trouve une liste de crypto-identifiants des smartphones s’étant trouvés à proximité des smartphones des personnes positives ». De même, « dans le smartphone de mon voisin, il n’y a AUCUNE donnée concernant mon diagnostic médical, aussi encrypté soit-il. Il y a une liste des cryptoidentifiants de tous les smartphones rencontrés » (consulter la FAQ).

« D’autres choix sont possibles et fondent d’autres approches, qui n’ont pas été celles des équipes d’Inria et du Fraunhofer, précise le document : des crypto-identifiants des personnes diagnostiquées positives peuvent transiter par des serveurs centraux et être envoyés dans tous les smartphones. Smartphones au sein desquels la mise en correspondance entre crypto-identifiants rencontrés et crypto-identifiants de personnes testées positives peuvent être effectués.

C’est un système que l’on peut présenter comme fortement décentralisé... tout comme on peut le présenter comme une centralisation décentralisée : il y aura ainsi, sur chaque smartphone, la liste de l’ensemble des crypto-identifiants des personnes diagnostiquées comme positives. Ce système a par ailleurs l’avantage d’être facilement permis par l’API à venir (mi-mai), dévoilée par Apple et Google il y a une semaine, une grande première dans l’histoire de l’informatique. En tout état de cause, c’est le choix d’un Etat de décider d’utiliser ou non le protocole qu’il désire en fonction de sa politique. Et c’est notre responsabilité de scientifique de lui procurer les moyens de ce choix. »

Mise en open source, sous Mozilla Public License

Ce protocole est mis sur la table. Ouvert à commentaires, critiques et autres enrichissements. L'acceptabilité de cette solution passe aussi par la pédagogie, finalement il reviendra au « choix d’un État de décider d’utiliser ou non le protocole qu’il désire en fonction de sa politique. Et c’est notre responsabilité de scientifique de lui procurer les moyens de ce choix ».

« Une première implémentation logicielle est en cours de développement sur la base du protocole ROBERT. Comme toutes les productions associées au projet StopCovid, elle sera mise en open source, sous licence MPL ».

Nous reviendrons sous peu sur ces éléments, dans le cadre d’un entretien réalisé ce jour avec Bruno Sportisse.

Écrit par Marc Rees

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une composante d'une politique de santé 

Décentralisation, centralisation et crypto-identifiants

Mise en open source, sous Mozilla Public License

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (62)


Je vois que j’arrive trop tard pour la référence aux Bidochons, Marc m’a grillé…


Si Robert plante, Raymonde dira au choix :




  • tout plein d’amour !

  • un escalier pour le paradis !


ROBERT&nbsp;<img data-src=" />



Ca risque d’inspirer un dessinateur pour la semaine prochaine <img data-src=" />


Y a-t-il des informations sur la manière dont le statut d’un identifiant sera passé en covid-positif tout en évitant de possible trolls ?



Certaines personnes dans le milieu médical auront une application spéciale qui pourra (par bluetooth là aussi?) demander de récupérer la liste des identifiants stockés dans l’app d’un patient positif pour les envoyer au serveur ?



J’ai cherché un peu mais je ne trouve rien de précis là-dessus :/


J’attends avec impatience l’implémentation de la génération des&nbsp;crypto-identifiants, cela semble fort intéressant&nbsp;<img data-src=" />Je suis surtout très curieux de voir comment les générer de manière parfaitement unique entre 2 smartphones et ce que cela donne sur le long terme.Aussi&nbsp;puisqu’il y aura algo fatalement, il devrait être possible de déterminer un facteur commun entre 2 ids du même smartphone. Je ne suis pas crypto-analyste, mais cela m’intrigue&nbsp;<img data-src=" />&nbsp;enfin à coté de ça, faire le lien entre 2 ids n’apporterait pas grand chose&nbsp;<img data-src=" />


Je pense que c’est du domaine de l’implémentation, pas du protocole.


Donc l’autorité centrale connaît tous les identifiants et peut donc retracer les déplacements de tout le monde (sans avoir leur identité directement certes), pas uniquement les personnes qui se déclarent positives.



Mais pire, qu’est-ce qui empêche d’avoir une caméra de surveillance par exemple, couplée à un appareil qui émet des identifiants qui changent toutes les 5 secondes ? Dès qu’un des identifiants qui a été émis est signalé, on a potentiellement une photo de la personne positive !








Nicky5 a écrit :



Je suis surtout très curieux de voir comment les générer de manière parfaitement unique entre 2 smartphones





&nbsp;Pour être totalement décentralisé, il n’y aura pas d’assurance à 100% qu’un identifiant soit parfaitement unique. A priori, ce seront des clés générées aléatoirement d’une longueur allant de 16 à 32 octets (d’après le protocole proposé par Google et Apple). La probabilité de doublon est faible, d’autant plus que les identifiants n’auront probablement pas une durée de vie de plus d’une quinzaine de jours, ce qui limite d’autant plus le problème.



Il faut savoir que les clés privées bitcoin sont basés sur ce principe. Tu génères une clé aléatoire de 32 octets (256 bits), tu changes de temps en temps et tu pries pour que personne ne tombe sur la même clé que toi au moment où tu l’utilises.



&nbsp;





Nicky5 a écrit :



Aussi&nbsp;puisqu’il y aura algo fatalement, il devrait être possible de déterminer un facteur commun entre 2 ids du même smartphone.



Si c’est de la génération aléatoire, ça dépendra de la qualité de la génération du “pseudo-aléatoire” ou si le device possède une source réelle d’entropie. C’est pas forcément lié au protocole en question ici, je pense.









hwti a écrit :



Donc l’autorité centrale connaît tous les identifiants et peut donc retracer les déplacements de tout le monde (sans avoir leur identité directement certes), pas uniquement les personnes qui se déclarent positives.





Je serai curieux de savoir comment l’autorité centrale peut retracer les déplacements vu qu’il n’y a pas de géolocalisation dans le processus





hwti a écrit :



Mais pire, qu’est-ce qui empêche d’avoir une caméra de surveillance par exemple, couplée à un appareil qui émet des identifiants qui changent toutes les 5 secondes ? Dès qu’un des identifiants qui a été émis est signalé, on a potentiellement une photo de la personne positive !





Rien ne l’empeche, sauf que je ne vois pas

1- Comment une camera pourra identifier dans une foule la personne qui a envoyé l’identifiant

2- Comment la camera pourra récupérer l’identifiant de tout le monde vu que celui-ci ne devrait être envoyé qu’en fonction d’une certaine distance et après contact ininterrompu pendant x minutes.



Bref c’est fascinant cette faculté de toujours imaginer des trucs qui n’ont rien à avoir simplement par idéologie



Une appli avec des gros roberts pour attirer tous les geeks, bonne idée <img data-src=" />








carbier a écrit :



Je serai curieux de savoir comment l’autorité centrale peut retracer les déplacements vu qu’il n’y a pas de géolocalisation dans le processus





Si elle a des bornes qui écoutent les identifiants émis, l’autorité peut reconstituer les déplacements (le document évoque la question, mais semble juger que le risque est limité et similaire à la vidéo-surveillance ou le traçage GSM).

Au moins avec la solution Google/Apple et des bornes, ça ne concerne que les personnes qui se déclarent positives, là c’est tous les utilisateurs de l’application !







carbier a écrit :



1- Comment une camera pourra identifier dans une foule la personne qui a envoyé l’identifiant





Oui, ce n’est valable que si la densité de personnes est limitée, pas en plein milieu d’une gare.

La même technique est applicable pour les personnes avec lesquelles une personne malveillante a des contacts, s’il elle en a peu.







carbier a écrit :



2- Comment la camera pourra récupérer l’identifiant de tout le monde vu que celui-ci ne devrait être envoyé qu’en fonction d’une certaine distance et après contact ininterrompu pendant x minutes.





Déjà, les téléphones vont émettre régulièrement, c’est à la réception qu’on décide si la puissance et la durée indiquent un contact prolongé.



Donc si la caméra est liée à l’autorité, effectivement il lui suffit d’écouter les messages.



Si elle est indépendante, alors elle peut à l’inverse émettre des messages avec une identité qui change régulièrement, et vérifier plus tard leur statut auprès du serveur si elle a été “en contact” avec un cas diagnostiqué.

Les limites sont donc la capacité à s’enregistrer massivement (se faire passer pour un nouvel utilisateur à chaque contact), et le filtrage côté réception pour que le contact soit considéré comme valide (donc ça ne fonctionnerait pas dans un lieu de passage, où le téléphone ne recevrait le message que pendant un temps trop court).



Rob-er-T c’est déjà mieux que PEPP-PT. Depuis S.A.F.A.R.I. je crois que l’administration française n’avait pas fait aussi bien en terme d’acronymes.


Ce qui l’empêche, c’est “construire un historique des crypto-identifiants rencontrés, « à proximité », pendant une durée significative”



Si ton appareil change d’ID toutes les 5 secondes, la durée n’est pas significative, l’ID n’est donc pas ajouté à l’historique des ID rencontrés -&gt; l’appareil n’est pas notifié qu’il a été en contact








carbier a écrit :



2- Comment la camera pourra récupérer l’identifiant de tout le monde vu que celui-ci ne devrait être envoyé qu’en fonction d’une certaine distance et après contact ininterrompu pendant x minutes





Je n’ai pas relu les spécifications du protocole, mais ça dépendra si l’identifiant fait partie ou non des informations échangées pendant l’évaluation de la durée et de la proximité, auquel cas il pourrait être récupéré par l’autre terminal même s’il est trop éloigné ou s’il a été croisé pendant une trop courte durée.









PtiDidi a écrit :



Ce qui l’empêche, c’est “construire un historique des crypto-identifiants rencontrés, « à proximité », pendant une durée significative”



Si ton appareil change d’ID toutes les 5 secondes, la durée n’est pas significative, l’ID n’est donc pas ajouté à l’historique des ID rencontrés -&gt; l’appareil n’est pas notifié qu’il a été en contact





Certes, j’ai été un peu trop rapide, la durée minimale de contact apporte une certaine sécurité.



Mais si je suis le gérant d’un centre commercial, ou un employeur ? Je peux générer un nouvel identifiant régulièrement, et l’envoyer pendant un certain temps dans les locaux (donc plusieurs identifiants à la fois).



Plus la durée minimale pour qualifier un contact est courte et précise, plus c’est risqué. Si elle est aléatoire entre 10 et 15 min, là le cas du centre commercial semble effectivement difficile à mettre en pratique, mais le cas de l’entreprise l’est toujours (en corrélant l’horaire d’arrivée et de départ de chaque salarié avec les identifiants ayant eu un “contact”, et ce sur plusieurs jours).



C’est cool, ça permettra de savoir qu’on a croisé des gens dont on ne sait pas s’ils sont porteurs du virus puisqu’il n’est toujours pas prévu de dépistage massif :)


Un des buts aussi ce de prévenir une future pandémie hein. C’est loin d’être la première.



Si on arrive à isoler rapidement les personnes ayant été en contact avec un patient admis à l’hôpital ayant été infecté par un nouveau virus de ce type. On pourrait limiter la casse, et si pas éviter la pandémie alors probablement pouvoir avoir des périodes de confinements beaucoup plus réduites avec moins d’impacts économiques et sociaux.


Entre les ID générés par l’authorité centrale, et l’interrogation régulière de sur ces même pseudo, il y a complètement une possibilité de traçage par l’état. Ces failles sont grossières pour un protocole dit “Privacy”.&nbsp; Et ne sont pas présente dans le protocole de Google/Apple.



&nbsp;Cela a été remonté dans leur Bug Tracker, mais cela botte en touche ensuite. Hors de question d’installer un truc pareil.








eureux a écrit :



Entre les ID générés par l’authorité centrale





Les id sont générées par le smartphone…









haelty a écrit :



Les id sont générées par le smartphone…





Tu es allé voir le fonctionnement du protocole sur le Github?&nbsp;



Avec le protocole Robert, les pseudo sont générés par le serveur et reçu lors de l’inscription du service. C’est une farce









haelty a écrit :



Les id sont générées par le smartphone…





Eh non, relisez le document de description de ROBERT.









eureux a écrit :



Tu es allé voir le fonctionnement du protocole sur le Github?&nbsp;



Avec le protocole Robert, les pseudo sont générés par le serveur et reçu lors de l’inscription du service. C’est une farce





Aux temps pour moi, j’avais lu qu’on recevait un algorithme de génération d’identifiants. En effet ici, c’est limite…



Est-ce que une application utilisant le protocole d’Apple/Google sera utilisable en Europe ?



Donc, autorité centrale, sécurisée par on-ne-sait-quoi, avec quelle compétence technique?



Pas d’open source dans l’implémentation?



Peu claire dans la génération des clés/smartphones, ni dans la sécurité de ces clés…



Fraunhoffer dans les partenaires…



Ça me semble pas incroyable comme projet.


Un employeur ou un employé, il n’y a aucune différence. Il y a moyen d’exploiter la chose c’est sûr.

Mais ca me semble difficile à mettre en place industriellement, c’est là le plus important.




(pour ROBust and privacy-presERving proximity Tracing)





Bizarre, moi avec ces lettres, j’arrive à PAVOT !



robust and PrivAcy-preserVing prOximity Tracing



&nbsp;Quelqu’un a le numéro de Bertrand Renard pour départager ?








jb a écrit :



Pas d’open source dans l’implémentation?





ROBERT est un protocole, pas un logiciel. Les auteurs de ROBERT travaillent à une mise en œuvre sous licence MPL (donc libre, sauf erreur). Mais rien ne dit que c’est ce qui sera utilisé dans l’application officielle.









Stéphane Bortzmeyer a écrit :



Eh non, relisez le document de description de ROBERT.





Ca s’appelle un profil Tinder ;)



<img data-src=" />









carbier a écrit :



Rien ne l’empeche, sauf que je ne vois pas

1- Comment une camera pourra identifier dans une foule la personne qui a envoyé l’identifiant







Les vendeurs de système de « suivi à la trace » des clients de supermarché se vantent d’être assez bons là-dedans. En couplant ça avec des caméras, la faisabilité technique d’associer un visage à l’identifiant échangé ne me semble pas insurmontable du tout.





2- Comment la camera pourra récupérer l’identifiant de tout le monde vu que celui-ci ne devrait être envoyé qu’en fonction d’une certaine distance et après contact ininterrompu pendant x minutes.



Bref c’est fascinant cette faculté de toujours imaginer des trucs qui n’ont rien à avoir simplement par idéologie





Je n’ai pas encore regardé le protocole dans le détail, mais de ce que j’en ai regardé, les attaques par « side-channel » n’ont pas été évaluées (par exemple, je rencontre X, et j’en profite pour lire le NFC de son pass navigo / carte bleue pour l’identifier). Ou je prends une photo discrètement. Le risque de réidentification à posteriori est très bien traité, mais pas celui d’identification « on-time », c’est à dire au moment de la rencontre. C’est pourtant plutôt par ce biais que la dépseudonymisation sera le plus efficace. Le téléphone peut bien envoyer un pseudonyme, si je suis à côté de la personne, il y a de bonnes chances que je sache de qui il s’agit.









white_tentacle a écrit :



Le téléphone peut bien envoyer un pseudonyme, si je suis à côté de la personne, il y a de bonnes chances que je sache de qui il s’agit.







Bah oui, mois je connais tout le monde dans les transports en commun, les marchés, les supermarchés, dans la rue, à la boulangerie…



J’ai peut-être mal compris ton propos hein, mais bon…









white_tentacle a écrit :



Je n’ai pas encore regardé le protocole dans le détail, mais de ce que j’en ai regardé, les attaques par « side-channel » n’ont pas été évaluées (par exemple, je rencontre X, et j’en profite pour lire le NFC de son pass navigo / carte bleue pour l’identifier).





Tout est question de compromis entre utilisabilité et sécurité.

&nbsp;

Des attaques par “side-channel”, il y en aura toujours. Pour le TLS, je peux aussi inventer un prétexte pour devoir chipoter à l’ordinateur d’une connaissance pour y configurer un proxy et installer mon certificat de CA dans son trust store et mettre en place un MITM bien comme il faut. En entreprise, si t’es un IT guy, le prétexte n’est vraiment pas difficile à trouver…



Je ne dis pas que ce genre d’attaque ne doit pas être envisagé, mais en l’occurence ici ces exemples vont servir à quoi exactement. A pouvoir dire que telle personne était à un endroit que tu connaissais déjà ?

Sachant que les identifiants changent régulièrement, tu ne pourras pas retrouver un trajet plus conséquent.

&nbsp;

Donc, pourquoi ne pas juste scanner les pass navigo et l’associer à la position gps actuelle ?

&nbsp;Ton attaque n’apporte rien de plus comme information.









white_tentacle a écrit :



Les vendeurs de système de « suivi à la trace » des clients de supermarché se vantent d’être assez bons là-dedans. En couplant ça avec des caméras, la faisabilité technique d’associer un visage à l’identifiant échangé ne me semble pas insurmontable du tout.



Pourtant même la Chine, largement en avance sur tout le monde, n’y arrive pas vraiment…









white_tentacle a écrit :



Les vendeurs de système de « suivi à la trace » des clients de supermarché se vantent d’être assez bons là-dedans. En couplant ça avec des caméras, la faisabilité technique d’associer un visage à l’identifiant échangé ne me semble pas insurmontable du tout.





Bah si les commerciaux le disent alors…





white_tentacle a écrit :



Je n’ai pas encore regardé le protocole dans le détail, mais de ce que j’en ai regardé, les attaques par « side-channel » n’ont pas été évaluées (par exemple, je rencontre X, et j’en profite pour lire le NFC de son pass navigo / carte bleue pour l’identifier). Ou je prends une photo discrètement. Le risque de réidentification à posteriori est très bien traité, mais pas celui d’identification « on-time », c’est à dire au moment de la rencontre. C’est pourtant plutôt par ce biais que la dépseudonymisation sera le plus efficace. Le téléphone peut bien envoyer un pseudonyme, si je suis à côté de la personne, il y a de bonnes chances que je sache de qui il s’agit.





Donc si j’ai bien compris tu vas te balader dans la rue avec un tracker en ayant piraté l’appli pour avoir accès aux ID en temps réel tout en prenant des photos de toutes personnes que tu croises… C’est un PoC ? <img data-src=" />

C’est après ou avant avoir piraté la BDD gérant les ID ?

J’ai du mal à voir le but: parceque si c’est pour faire du tracking, il te faut des dizaine de milliers de caméras mobiles + des dizaines de milliers de points fixes dans une seule grande ville <img data-src=" />

Je suis sur qu’il y a des moyens plus simples pour tracker les gens <img data-src=" />



Outre les problèmes de confidentialité, il y a le fait que le Bluetooth a une portée de plusieurs dizaines de mètres : ça ne voudra pas dire grand chose.


Si vous avez des remarques, github propose de créer des billets afin de faire remonter les problèmes que vous avez repéré au auteurs :

https://github.com/ROBERT-proximity-tracing/documents/issues

(oui, la règle est de l’écrire en anglais)

Ca sera surement plus constructif.


Je vais essayer de formuler plus clairement le propos. La donnée qu’on cherche à cacher, c’est « X a été malade ». C’est pour cela qu’est mis en place le système de pseudonymisation. Ensuite, on cherche à ce que le protocole ne permette pas la réidentification. Ça fait partie du cahier des charges, je dois savoir si j’ai été en contact avec un malade, mais pas pouvoir identifier qui est malade en particulier. Ce point est bien traité dans le cadre de la réidentification à posteriori, pas dans le cadre de l’identification sur le moment de la rencontre (de ce que j’ai vu).











haelty a écrit :



Tout est question de compromis entre utilisabilité et sécurité.







En effet.

 



Donc, pourquoi ne pas juste scanner les pass navigo et l’associer à la position gps actuelle ?

 Ton attaque n’apporte rien de plus comme information.





À la fin, je sais surtout qui est malade. Qui est précisément l’information que le système de pseudonymisation cherche à éviter que j’apprenne.







carbier a écrit :



Donc si j’ai bien compris tu vas te balader dans la rue avec un tracker en ayant piraté l’appli pour avoir accès aux ID en temps réel tout en prenant des photos de toutes personnes que tu croises… C’est un PoC ? <img data-src=" />







La sécurité du protocole ne doit pas dépendre d’une implémentation particulière. Autrement dit, une telle application « hostile » sera développée par quelqu’un qui y trouvera un intérêt.







carbier a écrit :



C’est après ou avant avoir piraté la BDD gérant les ID ?







HS total.







carbier a écrit :



J’ai du mal à voir le but: parceque si c’est pour faire du tracking, il te faut des dizaine de milliers de caméras mobiles + des dizaines de milliers de points fixes dans une seule grande ville <img data-src=" />

Je suis sur qu’il y a des moyens plus simples pour tracker les gens <img data-src=" />







Le but n’est pas de faire du tracking. Le but est d’identifier les personnes ayant été malades, nominativement (ce que le système de pseudonymisation est là pour empêcher). Exemple stupide (mais pas tant que ça) : supposons qu’on découvre qu’avoir été infecté par le covid-19 est un facteur de complications à long terme, susceptible d’entraîner une mortalité précoce par infarctus. Si je suis assureur de crédits, je suis très intéressé par la liste des gens malades, parce qu’ils présentent un risque supplémentaire.



On peut imaginer d’autres scénarios, plus ou moins crédible. La question n’est pas tant de « pourquoi » ou de « qui », mais plutôt de « est-ce que c’est possible » et « combien ça coûterait ». Et d’être honnête dans les affirmations ( « la réidentification est impossible », tel quel brut de fonderie, c’est juste une promesse intenable).









white_tentacle a écrit :



À la fin, je sais surtout qui est malade. Qui est précisément l’information que le système de pseudonymisation cherche à éviter que j’apprenne.





Absolument pas, tu sais qui est potentiellement malade, tu ne sais pas du tout qui a été testé positif. (Et ça se limite au fait qu’il ait été possiblement infecté dans un délai proche du moment où il te croise, ça limite la probabilité)

Toute personnes ayant été en contact avec une personne positive est mise en état “positif” dans la DB en ne stockant pas de quel individu ça provient.



A ce moment-là, comme il s’agit d’identifiants à durée de vie limitée, tu seras aussi mis en positif par le système puisque tu es entré en contact avec cet identifiant que tu connais. Tu serais donc malade aussi à tous les coups ?



Si tu répond non à cette dernière question, tu ne sais pas répondre oui pour l’autre personne.



On prend le problème à l’envers : ce n’est pas ce qui à cacher qui est important mais ce qui est à “prouver”.

Il faudrait se placer sur le plan des preuves nulle de divulgation de connaissances. Il ne faut donc ne révéler qu’une seule chose : suis-je a risque ou pas.








haelty a écrit :



Absolument pas, tu sais qui est potentiellement malade, tu ne sais pas du tout qui a été testé positif. (Et ça se limite au fait qu’il ait été possiblement infecté dans un délai proche du moment où il te croise, ça limite la probabilité)







Je suis retourné voir un peu plus en détail. Effectivement, pour savoir qui est malade, j’ai besoin de proposer une identité différente (donc autant de comptes applicatifs) à chaque personne rencontrée. Irréaliste dans un milieu urbain. Le système ne transfère pas le pseudo de la personne malade, mais avertit les pseudos des personnes avec qui la personne malade a été en contact. Mea culpa, j’avais mal identifié ce point.





Toute personnes ayant été en contact avec une personne positive est mise en état “positif” dans la DB en ne stockant pas de quel individu ça provient.





Non, ils sont mis « à risque ». Et il n’y a pas de lien entre les différentes personnes « à risque » (sinon, rapidement, tout serait saturé).









white_tentacle a écrit :



Non, ils sont mis « à risque ». Et il n’y a pas de lien entre les différentes personnes « à risque » (sinon, rapidement, tout serait saturé).





Oui, on est d’accord. Je parlais du seul flag en DB associé aux identifiants. Le terme “à risque” est plus approprié en effet.



Pour le tracking de population Bill & Melinda Gates foundation, Rockfeller Foundation et la Clinton Foundation, que des gens sympa en somme, bosse fort pour pousser leur ID2020.org.








white_tentacle a écrit :



Je vais essayer de formuler plus clairement le propos. La donnée qu’on cherche à cacher, c’est « X a été malade ».





Et pourquoi tu veux cacher cela ?



Perso le jour où cela m’arrive, je préviens un max de monde que j’ai pu côtoyer autour de moi.









carbier a écrit :



Et pourquoi tu veux cacher cela ?







C’est le cahier des charges :). Sinon tout le système de pseudonymisation perd beaucoup d’intérêt.





Perso le jour où cela m’arrive, je préviens un max de monde que j’ai pu côtoyer autour de moi.





Tes amis, oui, je n’en doute pas. Ton assureur, par exemple, j’en doute plus. Il y a toujours des gens dont on souhaite qu’ils ne soient pas au courant. Une liste publique des gens ayant eu une maladie, c’est pas une bonne idée que ça existe. Le système doit être prévu pour empêcher que cela n’arrive (les attaques doivent donc être limitées en portée et coûteuses à mettre en œuvre).









white_tentacle a écrit :



Tes amis, oui, je n’en doute pas. Ton assureur, par exemple, j’en doute plus.





Si tu prends une assurance tu remplis un questionnaire de santé.







white_tentacle a écrit :



C’est le cahier des charges :). Sinon tout le système de pseudonymisation perd beaucoup d’intérêt.





Sauf que ce n’est pas le cahier des charges: le principe était de ne pas tracer les déplacements ET de ne pas savoir qui on a rencontré.



https://github.com/ROBERT-proximity-tracing/documents/blob/master/ROBERT-specification-EN-v1_0.pdf



Relis le paragraphe 1.3 (ou même juste l’infographie, c’est dedans). Le principe est que personne dans le système n’apprenne que Alice a été malade (ni l’autorité, ni les gens qu’elle a croisé).


C’est pas un requirement dans leur doc, à ce que je vois.








jb a écrit :



C’est pas un requirement dans leur doc, à ce que je vois.





L’Inria est un institut de recherche, donc je ne suis même pas sûr que si implémentation il y a elle ne dépasse le proof of concept. De toute façon, les stagiaires ont déjà leur sujet.



Ils ne savent pas qui t’as rencontré.

Quand une personne est contrôlé positive on lui demande la liste de ses identifiants



Au soir le serveur envoie la totalité de la liste des identifiants positif a la totalité des smartphones.

&nbsp;

Ton smartphone compare avec la liste des personnes avec qui il a échangé des identifiants, si ça match t’as été proche d’une personne positive -&gt; on te demande de te faire tester.



Tu va dans le centre de test, tu montre que le smartphone clignote en mode “a tester”, ils te testent.

A aucun moment ils ne savent que t’as rencontré madame dupont, ou juliette lacroix.

Le gouvernement pourrait s’amuser a regarder “ah tiens Carbier a été testé, c’est qu’il a rencontré une personne positive” mais a aucun moment il n’est au courant de qui


Ils ne savent pas qui t’as rencontré.

Quand une personne est contrôlé positive on lui demande la liste de ses identifiants



Au soir le serveur envoie la totalité de la liste des identifiants positif a la totalité des smartphones.

&nbsp;



Ton smartphone compare avec la liste des personnes avec qui il a

échangé des identifiants, si ça match t’as été proche d’une personne

positive -&gt; on te demande de te faire tester.



Tu va dans le centre de test, tu montre que le smartphone clignote en mode “a tester”, ils te testent.

A aucun moment ils ne savent que t’as rencontré madame dupont, ou juliette lacroix.



Le gouvernement pourrait s’amuser a regarder “ah tiens Carbier a été

testé, c’est qu’il a rencontré une personne positive” mais a aucun

moment il n’est au courant de qui


Je ne crois pas que ce soit tes identifiants que tu envois mais les identifiants des gens que tu as croisé donc tu n’envoies jamais les tiens et les autres matches avec les leurs et uniquement les leurs.



Du coup les identifiants du nouveau malades ne quittent pas son smart.


Si ça fonctionnait comme tu le décris, ce serait vulnérable à l’attaque que je décrivais.



Ce qui est envoyé, c’est non pas la liste des identifiants d’Alice (qui est malade), mais la liste de tous les identifiants qu’Alice a rencontré dans les X derniers jours. À partir de cette liste, le serveur contacte toutes ces personnes pour leur dire « vous êtes à risque, allez vous faire dépister ». Il ne leur envoie que cette unique information.



L’autorité centrale (le serveur) connaît l’intégralité des identifiants de tous les utilisateurs, et donc c’est elle qui fait ce lien (et elle garde cette information secrète). Mais elle n’est pas censée connaître d’autres informations sur eux (sinon l’anonymat n’est plus garanti).








Jonathan Livingston a écrit :



Outre les problèmes de confidentialité, il y a le fait que le Bluetooth a une portée de plusieurs dizaines de mètres : ça ne voudra pas dire grand chose.







Le simple fait que les asymptomatiques peuvent représenter jusque 80% des porteurs du virus rend le principe même de l’appli totalement à coté de la plaque, en dehors de toute considération technique.



Ne pourrait-elle pas servir pour aider à prévenir d’une future&nbsp; épidémie&nbsp; qui ne serait pas forcément une autre du covid-19 ?



Même pour le cas du covid-19, ça permettrait d’établir un peu plus la liste des gens ayant été en contacts avec une personne infectée plus que “je crois que j’ai mangé avec untel tel jour, .. ho non attendez c’était pas lui”. La liste des contacts d’une personne infectée, on tente de l’identifier même sans app, c’est primordiale pour essayer d’endiguer la propagation. Il est là le souci. On ne parle pas de résoudre l’épidémie actuelle mais avoir plus d’outil pour éviter une possible reprise.



Personne n’a dit que c’était une solution absolue qui pousserait à ne pas faire toutes les autres procédures déjà possibles. C’est juste un outil en plus.



Si c’est le problème de confidentialité qui vous dérange, c’est bien normal, mais argumentez en parlant de confidentialité, pas d’efficacité…



Et pour parler d’efficacité, je pense qu’on est tous un peu mal placés pour savoir si telle ou telle méthode serait inutile. Les spécialistes en infection ne savent déjà pas se mettre d’accord sur l’efficacité des masques, et d’autres procédures, alors quelqu’un dont je ne sais rien qui poste un commentaire sur NXi… permet moi de douter de ton expertise sur le sujet.



Tu présupposes juste que cette application serait inefficace, mais absolument rien ne l’indique.



Y a une chose qu’on peut vérifier, c’est qu’elle soit respectueuse de la vie privée, et là on pourra le vérifier.



Tu aimerais peut-être que les ressources utilisées pour développer ça soit utilisées pour quelque chose de plus efficace ? Sans reparler du fait que tu ne sais pas quel sera le niveau d’efficacité de cette app, tu crois que&nbsp; les devs qui vont bosser dessus, ils bosseraient sur quoi d’autres à la place ? Tu veux quoi, un système de visio conférence développé par le gouvernement ? En quoi ces ressources seraient-elles d’une manière totalement objective mieux dépensées ?








Cumbalero a écrit :



Le simple fait que les asymptomatiques peuvent représenter jusque 80% des porteurs du virus rend le principe même de l’appli totalement à coté de la plaque, en dehors de toute considération technique.





Il faut le répéter combien de fois que l’appli ne fonctionnera pas toute seule mais en parallèle avec un dépistage intensif ?

L’appli n’est pas faite pour fonctionner maintenant mais quand l’épidémie aura fortement diminué et que notre capacité de dépistage aura fortement augmenté.




Justement, au contraire, c’est l’un des but de l’application : trouver les personnes porteuses avant l’apparition des symptômes. Si tu n’es tester qu’après l’apparition des symptômes, c’est trop tard, tu as déjà contaminé ton entourage.

On est face à un problème dans lequel on ne peut pas tester tout le monde tous les jours, on doit trouver un stratégie pour optimiser les tests, donc on doit tester en priorité les personnes les plus probablement contaminés (on est même dans un problème du dilemme d’exploration exploitation). Le but de l’application est donc d’aider à estimer dans l’estimation de cette probabilité sachant qu’il y a des nœuds dans le graph qui sont contaminé (énoncé ainsi on voit même que c’est un problème qui fait appelle à l’inférence bayésienne).



Ainsi ça permet aussi d’obtenir le “niveau global de contamination” plus proche de la réalité (avoir une évaluation le plus proche de la réalité instantanée et pas avec 2 semaines de retard) qui permet alors de prendre des mesures de confinement adaptées sans retomber dans le confinement total.








tazvld a écrit :



Justement, au contraire, c’est l’un des but de l’application : trouver les personnes porteuses avant l’apparition des symptômes.



Sachant qu’ils ne testent que les cas les plus graves, les politiciens et les célébrités, tu fais comment pour atteindre ce but? Par magie? <img data-src=" />



Ben justement,c’est exactement ce que j’ai écrit dans mon poste, c’est le but derrière l’outil, retrouver les personnes les plus susceptible d’être porteuse et donc de cibler les personnes à tester.



Dans le problème du dilemme d’exploration exploitation, tu es contraint par ta capacité à dévoiler un résultat (ici le nombre de test possible par jour). Mais tu dois trouver les zones les plus intéressantes (ici les clusters d’infection). Tu dois choisir entre explorer à l’aveugle (faire des tests au hasard) et l’exploitation (tu a un cas positif, tu essaies d’explorer à proximité si tu n’as pas d’autre cas).



Ce qui peut aider dans ce problème, c’est que l’on pourrait aussi faire appelle à des outils statistiques (comme l’inférence bayésienne) pour estimer à priori la probabilité qu’un id soit une personne porteuse. On peut donc prioriser les personnes les plus plausiblement porteuse dans le cas de l’exploitation. De même, dans le cas de l’exploration, on peut tester aléatoirement en priorité des identifiants dont on n’a trop peu informations pour estimer fiablement une probabilité.



On est donc dans des problèmes qui ont pas mal été développé et possède beaucoup de théories (mathématiques/informatique) derrières. C’est des problème classique qu’il faut adapter et mixer. C’est typiquement le genre de problèmes qui sont derrière les outils d’apprentissage automatique, que l’on appelle “intelligence artificielle” pour le grand public, rien de magique, juste des statistiques.



Et au passage, les modèles statistique ont une certaine tolérances à des fausses entrées, donc ici face aux trolls (se faisant passer pour positif alors qu’il ne le sont pas ou l’inverse) tant qu’ils reste en dessous d’un seuil.








tazvld a écrit :



Ben justement,c’est exactement ce que j’ai écrit dans mon poste, c’est le but derrière l’outil, retrouver les personnes les plus susceptible d’être porteuse et donc de cibler les personnes à tester.







C’est totalement incompatible avec la promesse de l’anonymat.



C’est les id des personnes qui sont retrouvé.

En gros, imagine toi que sur NextInpact, le serveur de NxI connait un pseudo unique qui est associé à ce compte. Ici NxI ne connait pas ton identité réel. De plus quand tu postes, au lieu de donner ce pseudo à tout le monde, il va générer un pseudo aléatoire qui sera temporairement associé à ton compte. Seul ce pseudo aléatoire est visible de tous. Donc même là difficile de suivre jour après jours ton activité sur NxI pour quelqu’un qui n’a pas accès à la BDD. Mais l’analogie s’arrête là, car ici NxI à la connaissance à la fois de tes pseudo temporaire et de totale des tes activités sur le site. Dans le cas de ce protocole, tes activité ne sont connu que des personnes que tu as croisés.

C’est totalement assumé par les gars qui développe ça et accordent une confiance au serveur central. Après, si l’autorité central est l’Etat, cette BDD est un peu inutile, il y a plus simple il lui suffit de piocher dans la BDD de la sécurité social, c’est tout sauf anonyme, elle est beaucoup plus complète et facile d’exploitation, il n’y a pas de pseudonymat.








tazvld a écrit :



C’est les id des personnes qui sont retrouvé.







Et cet id “anonyme” il sert à quoi pour retrouver qui que ce soit?







tazvld a écrit :



C’est totalement assumé par les gars qui développe ça et accordent une confiance au serveur central. Après, si l’autorité central est l’Etat, cette BDD est un peu inutile







Le risque majeur n’est pas que l’État puisse savoir que tu es ou a été touché par le virus. cf mon commentaire au dernier article sur le “contact tracing”. La simple information de savoir que tu n’as pas installé l’application c’est du pain béni pour ton assureur qui intégrera ta “négligence” au calcul de risque. A l’exemple que je donne dans cet autre commentaire, tu crois que Google et Apple vont se gêner pour vendre cette info ? C’est pas sur F-Droid que l’appli serait publiée que je sache. De fait, on va déléguer ça aux GAFAM. Au mieux, ça ne leur servira qu’à t’afficher des pubs pour des masques et du gel.



Donne moi un scénario réel, car j’ai déjà plein de contre exemple en tête (le mecs qui active l’application que pour l’entretient avec son assureur, le fait que beaucoup d’assurance ne sont font même plus en agence, qu’en dehors des périodes de risque épidémique, l’application n’a pas lieu de fonctionner….)



De ce que j’ai lu du protocole Google-Apple (DP-3T il me semble), tout l’intérêt est qu’il n’y a même pas besoin d’identifiant. Ton téléphone balance des messages aléatoire régulièrement, si tu es contaminé, tu mets sur une BDD publics tous les messages que ton téléphone a balancé (toujours sans avoir besoin d’identification). Il suffit de regarder régulièrement dans cette BDD si tu n’a pas reçu un certain nombre de message en commun. Tu n’as aucune ID a aucun moment. C’est encore plus difficile de faire un quelconque tracking même pour ceux qui gère la BDD centralisé.





SInon, si tu as des remarques pour le protocole ROBERT, la partie Issue du git du protocoleest à ta disposition.



Pour celui de Google-Apple, je n’ai pas regardé s’il y a une discussion possible.








tazvld a écrit :



Donne moi un scénario réel, car j’ai déjà plein de contre exemple en tête (le mecs qui active l’application que pour l’entretient avec son assureur, le fait que beaucoup d’assurance ne sont font même plus en agence, qu’en dehors des périodes de risque épidémique, l’application n’a pas lieu de fonctionner….)



De ce que j’ai lu du protocole Google-Apple (DP-3T il me semble), tout l’intérêt est qu’il n’y a même pas besoin d’identifiant. Ton téléphone balance des messages aléatoire régulièrement, si tu es contaminé, tu mets sur une BDD publics tous les messages que ton téléphone a balancé (toujours sans avoir besoin d’identification). Il suffit de regarder régulièrement dans cette BDD si tu n’a pas reçu un certain nombre de message en commun. Tu n’as aucune ID a aucun moment. C’est encore plus difficile de faire un quelconque tracking même pour ceux qui gère la BDD centralisé.





SInon, si tu as des remarques pour le protocole ROBERT, la partie Issue du git du protocoleest à ta disposition.



Pour celui de Google-Apple, je n’ai pas regardé s’il y a une discussion possible.





Et à côté, tous ceux qui bossent dans la sécurité d’authentification disent qu’un ID anonyme est un oxymore…

Etrangement, entre eux et toi, j’ai plus tendance à les écouter eux.



Peut-tu surligner le passage que tu réponds ?

Sinon, dans l’intégralité du dépot, il ne semble y avoir aucune référence à anonym” :

https://www.google.com/search?q=anonym+site%3Ahttps%3A%2F%2Fgithub.com%2FROBERT-…



Mais si tu cherches privacy, c’est une autre histoire :

https://www.google.com/search?q=privacy+site%3Ahttps%3A%2F%2Fgithub.com%2FROBERT…





Il y a peut être une différence sémantique, mais je ne suis pas expert non plus. Après, la question est donc “c’est quoi le but ?3