Centralisé ou décentralisé : quelles différences entre les architectures des apps de contact tracing ?

Le dimanche 3 mai, le secrétaire d’État au numérique Cédric O, a renouvelé, dans un long billet de blog, sa volonté de tester StopCovid dès le début du déconfinement. Cette application de contact tracing doit permettre de limiter la propagation de l’épidémie Covid-19.

Fin mai, le débat et le vote spécifique qui auront lieu à l’Assemblée puis au Sénat porteront sur l’usage même d’une app pour faire du contact tracing. Mais en attendant, une partie du débat se porte sur un détail technique de l’application : l’approche centralisée choisie par le gouvernement français diverge de l’approche décentralisée choisie par d’autres pays. Cette divergence a des conséquences politiques qui aspirent le débat. « Le choix du protocole et la façon dont il va être implémenté n’auront pas un impact important, car les failles de sécurité sont dues à la fonctionnalité même du contact tracing », rappelle pourtant la chercheuse en cryptographie Anne Canteaut.

L’app StopCovid se base sur l’échange d’information entre tous les smartphones. // Source : Numerama

Pour rappel, le contact tracing est une méthode de collecte des contacts physiques entre les personnes. Sur une application mobile, elle garantit l’anonymat des citoyens qui l’utilisent. Elle ne géolocalise pas et utilise à la place le Bluetooth pour échanger des identifiants chiffrés (une série de lettres et de chiffres) entre deux smartphones. Ces identifiants serviront de trace de l’interaction entre les deux individus. Si une personne est déclarée malade du Covid-19,  toutes les personnes qui auront reçu ses identifiants chiffrés pendant une certaine durée recevront une alerte. L’app ne donnera pas l’identité de la personne malade, et pourrait éventuellement distribuer des conseils de santé à la personne notifiée.

Le débat sur le protocole intervient après le débat sur le traçage

Une fois ce choix fait, l’épineuse question du protocole se pose : centralisé (comme la France ou le Royaume-Uni) ou décentralisé (comme en Allemagne, en Italie ou en Suisse).

Les différences entre ces deux approches attisent les tensions dans les communautés scientifiques, mais aussi politiques. En France, ce débat technique a poussé le gouvernement à écarter du projet StopCovid la Dinum (direction interministérielle du numérique), pourtant considérée comme la plus haute instance de l’administration sur ce genre de sujet, comme l’a expliqué Acteurs Publics. Le développement de l’app, dont elle était en charge, est désormais confié à un consortium d’entreprises. La différence dans les approches a également un rôle central dans les tensions entre le gouvernement et Apple, puisque l’entreprise californienne prévoit aux côtés de Google de seulement faciliter l’approche décentralisée.

Cédric O l’écrit : aucune des deux solutions n’est infaillible, mais leurs failles sont différentes. Le secrétaire d’État en conclut que le modèle « décentralisé » est significativement plus risqué en termes de protection des données que le modèle « centralisé » (choisi par la France). L’affaire est pourtant loin d’être aussi simple. Numerama vous donne quelques clés techniques sur ce débat parfois obscurci par les enjeux politiques.

Pourquoi le choix du protocole est-il important ?

Pour bien comprendre les enjeux, rappelons que le protocole est une sorte de plan du fonctionnement de l’application. Il va définir la façon dont les machines discutent entre elles, le type d’informations qu’elles échangent et le format de celles-ci. Dans le cas des app de contact tracing, il va encadrer la façon dont votre smartphone va échanger des informations avec d’autres smartphones, ainsi qu’avec les serveurs de l’État.

Le protocole n’est donc qu’une base pour l’application. Il faut ensuite construire le « back end », l’arrière-salle de l’application, qui a pour rôle d’assurer le fonctionnement. Les utilisateurs auront quant à eux accès au « front end », la face visible de l’application, qui demande aussi un développement spécifique. Dans le cas de StopCovid, il sera vraisemblablement très simple et composé de peu de pages et fonctionnalités.

En résumé, si le choix du protocole émerge autant dans le débat sur l’app, c’est parce qu’il va définir le standard de sécurité et le niveau de protection de la vie privée de l’application.

Centralisé ou décentralisé, quelle différence dans le fonctionnement ?

Centralisée comme décentralisée, les deux approches prévoient la mise en place des principes de bases du contact tracing : les smartphones vont s’échanger des pseudonymes (un ensemble de chiffres et de lettres) par Bluetooth, et ils vont en communiquer une partie avec un serveur central. Mais la chaîne de l’information ne va pas être la même dans les deux cas.

Centralisé : le serveur central détermine qui a été exposé au covid 19

La France, sous la direction de l’Inria (Institut national de recherche en informatique et en automatique), a construit son propre protocole centralisé, le fameux protocole Robert. Mais elle n’est pas la seule à avoir fait ce choix : le Royaume-Uni par exemple s’est aussi engagé dans cette voie.

Dans cette architecture, un serveur central va récolter les pseudonymes des personnes atteintes de covid-19, ainsi que celles des personnes non atteintes. Cette collecte se fait à intervalle régulier et par paquet, de sorte qu’en théorie, la machine ne puisse isoler vos pseudonymes de ceux que vous avez rencontrés. Si vous avez croisé 15 personnes, votre smartphone va envoyer 15 clés, dont la vôtre, au serveur central.

L’approche centralisé requiert de faire confiance à l’État

Le serveur va ensuite comparer les différents flux qu’il reçoit et déterminer avec qui les personnes malades ont été en contact à une distance et pendant une durée suffisamment préoccupantes. Il n’a plus qu’à contacter les personnes concernées pour les avertir qu’elles ont été exposées. Avec ce système, même la personne malade pourrait recevoir une alerte.

Si l’approche inquiète certains, c’est parce que le serveur central apprend le graphe social d’un individu, c’est-à-dire la liste des pseudonymes (et indirectement, des personnes) qu’il a croisés. Il faut donc que l’utilisateur ait confiance dans le gestionnaire du serveur, ici l’État, à la fois pour ne pas utiliser ces informations à d’autres fins, mais aussi pour les protéger correctement.

Il existe toujours une possibilité de lever l’anonymat des personnes malades à partir des données contenues sur le serveur, sous condition d’avoir d’autres informations. Des garde-fous déployés en parallèle peuvent permettre de combler ce défaut.

Décentralisé : votre smartphone détermine si vous avez été exposé

L’approche décentralisée, choisie par l’Autriche et l’Allemagne, a l’avantage d’être compatible avec l’outil développé par Apple et Google, et pourra donc fonctionner sans accroc avec l’ensemble du parc de smartphones. Un des protocoles les plus mis en avant est DP-3T, qui a probablement inspiré Apple et Google dans la conception de leurs outils.

Dans cette approche, le serveur central ne va recevoir que les pseudonymes des personnes contaminées. L’historique des interactions reste quant à elles sur le smartphone de l’utilisateur.

L’État a moins de pouvoir

Ensuite, le serveur central va envoyer une liste des pseudonymes des personnes infectées à tous les smartphones. C’est donc notre smartphone qui va vérifier si ces pseudonymes apparaissent dans l’historique de nos interactions, qu’il a en mémoire. C’est lui qui va effectuer le calcul, et non le serveur central.

Dans cette approche, l’État a moins de contrôle sur les données, puisqu’il ne reçoit pas les graphes sociaux. Chaque individu peut gérer ses identifiants dans son coin. Les données de contact vont être conservées pendant une durée limitée, probablement équivalente à la période d’incubation du virus.

Si quelqu’un veut attaquer le système, comment doit-il s’y prendre ?

Savoir si telle ou telle personne est contaminée par le covid-19 peut servir à faire du chantage, mener à du harcèlement ou à des exclusions. Cette donnée pourrait être convoitée, et des personnes pourraient s’en prendre à l’application.

« Il y a énormément de vecteurs d’attaques différents, donc le niveau de protection suffisant dépendra de ceux qu’on considèrera comme réalistes », explique à Numerama Olivier Blazy, chercheur en cryptographie à l’Université de Limoges. Il a co-signé avec plus de 140 chercheurs et chercheuses français une mise en garde contre les risques liés à ce genre d’application, rapidement évoquée par Cédric O.

L’équation est complexe : quel niveau de menace représente des États hostiles ? Quel niveau de protection peut-on assurer avec la capacité de calcul de chaque smartphone ? Pour les chercheurs en cybersécurité, il s’agit de penser à toutes les éventualités, même les plus tordues, afin de poser clairement sur la table quels risques sont pris en compte et quels autres sont laissés de côté, car peu probables. Car les deux approches ont des défauts, et des failles impossibles à parfaitement combler, même avec des surcouches de sécurité.

Centralisé : le serveur central attirera les convoitises

« Dans le cas de l’approche centralisée, il n’y a qu’un seul point d’entrée pour l’ensemble des données. En conséquence, si une attaque fonctionne elle sera dévastatrice, car elle touchera toute la population », prévient Olivier Blazy. Une attaque réussie permettrait aux hackers d’accéder aux graphes sociaux des personnes contaminées. S’il a un volume de données suffisant à croiser, il pourrait identifier les personnes malades, ou au moins identifier un petit groupe susceptible de l’être.

La première faille contre laquelle le serveur central doit être protégé est la plus commune :  l’humain. Une personne qui dispose d’un accès au serveur pourrait se faire acheter, et divulguer la clé de chiffrement, certaines données ou des codes d’accès. Il faudra donc que l’État se prémunisse contre les attaques internes. « L’application est dans les mains de beaucoup de personnes, qui travaillent a priori bénévolement, ce n’est pas rassurant pour assurer cette garantie », regrette Olivier Blazy,

D’excellentes garanties, si elles sont correctement mises en place

Ensuite, les développeurs de Robert partent du principe qu’il est « honnête », c’est-à-dire qu’il fait bien tout ce qu’on attend de lui, et notamment qu’il sépare les identifiants des adresses IP. Cette adresse permet, dans certaines conditions, de remonter à l’utilisateur. « Il y a le risque que cette séparation soit mal faite à cause de problèmes dans la programmation », rappelle le chercheur.

Pour garantir que même en cas d’attaque, il sera impossible pour toute personne (même l’État) de réidentifier les personnes malades, le gouvernement a annoncé qu’il déploierait une surcouche de sécurité. Elle utiliserait notamment des boîtes noires transactionnelles (BNT ou HSM en anglais), des appareils qui permettent de générer, stocker et protéger des clés cryptographiques. Ils garantiraient que les données récupérées ne soient pas exploitables par un attaquant, car elles seraient protégées par encore une autre couche de chiffrement.

« C’est très coûteux à mettre en place, alors qu’on ne connaît pas le budget déployé », s’inquiète cependant Olivier Blazy, « il faut acheter des machines et de l’équipement pour plus de 40 millions d’utilisateurs, cela me paraît difficilement faisable à un coût raisonnable. » Mais si l’État parvient à déployer cette couche de sécurité, et que tout est correctement déployé, le serveur central sera un véritable coffre-fort dont le trésor sera impossible à exploiter. De quoi dissuader les éventuels assaillants.

Décentralisé : la porte entrouverte à de petites attaques

« L’approche décentralisée permet beaucoup d’attaques low tech, mais chacune d’entre elles ne toucherait qu’une petite part de la population », diagnostique Olivier Blazy. Par « low tech », le chercheur entend réalisable par simple raisonnement logique.

Puisque le serveur envoie à chaque smartphone l’intégralité des identifiants de la personne malade, il révèle beaucoup d’information. « C’est le plus gros problème de DP-3T : quand je dis au serveur que je suis malade, je lui communique tous les identifiants que j’ai utilisés », constate le chercheur. Il évoque des scénarios dans lesquels vous pourriez réidentifier une personne malade en fonction de l’heure à laquelle vous l’avez rencontrée et des identifiants envoyés par le serveur central.

L’avantage de l’approche décentralisée est que notre historique des contacts reste en notre possession. Mais selon où il est stocké dans la mémoire de l’appareil, des assaillants pourraient tenter d’y accéder, par exemple par le biais d’applications tierces frauduleuses.

De même, une personne qui parviendrait à subtiliser votre smartphone pourrait accéder aux clés que vous avez utilisées. Reste que l’impact serait limité : elle n’aurait que vos clefs et une liste peut-être obsolètes d’identifiants chiffrés de malades, eux-mêmes possiblement obsolètes s’ils sont renouvelés quotidiennement.

Ces risques restent exceptionnels

Parmi les scénarios évoqués dans les deux cas, il s’agit de manipulations relativement complexes. Si le risque zéro n’existe pas en sécurité et que c’est le rôle des chercheurs d’envisager tous les cas de figure, le niveau de protection des deux types de protocoles reste extrêmement élevé. Et puisqu’ils sont publiés en open source, ils vont être constamment améliorés au fur et à mesure que les vulnérabilités seront remontées.

S’il est donc faux de dire qu’un protocole centralisé est plus sécurisé, il est rassurant de voir que l’un comme l’autre sont bien sécurisés, quand bien même ils restent faillibles.

Votre VPN préféré n'est pas celui que vous croyez Quel est le meilleur VPN en 2024 ? Notre comparatif Retrouvez notre comparateur pour choisir le meilleur VPN