Apple et Google ont précisé les évolutions apportées à leur interface de programmation permettant de faire du contact tracing par application. Sécurisée et personnalisable, elle ne permettra pourtant pas aux États de greffer un protocole maison complet par dessus.

Si la science médicale avance en ce moment à toute allure pour trouver des remèdes au coronavirus, les entreprises de la tech tentent elles aussi de rattraper le temps perdu pour apporter des outils qui pourraient être capables d’accompagner les autorités de santé.

Deux semaines après l’annonce d’un partenariat historique autour de la construction d’un outil utile au traçage des contacts, Google et Apple en ont précisé le fonctionnement. Numerama a pu assister à la conférence donnée à la presse internationale par des porte-paroles des deux entreprises, qui reconnaissent très volontiers la limite de ces applications : « Ce n’est pas une solution miracle et cela ne résoudra pas l’épidémie : nous avons conçu notre solution comme une boîte à outils que les agences de santé nous ont demandée pour les aider ».

Un changement de nom

Le premier changement à noter est terminologique, mais il permet de dire beaucoup mieux ce que sont, au fond, tous les projets de protocoles permettant du traçage des contacts : le projet joint de Google et Apple se nomme désormais « Notification d’exposition ». Ce changement permet de distinguer le procédé technologique, qu’il s’agisse de celui de Google et Apple, de ROBERT de l’Inria ou de DP3T du concept même de traçage des contacts.

alerte-good

Un système de notification qui permet de faire du contact tracing

Dans une tribune, Bill Gates a très justement rappelé que le traçage des contacts était particulièrement efficace quand il était mené par un opérateur humain qui appelait un à un les contacts d’un patient diagnostiqué positif au coronavirus : l’application mobile est une manière de faire du contact tracing. Une méthode valable qui a été rappelée par l’un des porte-paroles des entreprises, affirmant que l’effort joint par Google et Apple était un moyen de plus d’arriver à cette fin.

Google et Apple ont annoncé que la conception de leur API avait évolué, grâce aux discussions avec différents laboratoires dans le monde entier et les contributions d’ingénieurs dans ces laboratoires. Deux points ont été mis en avant par les entreprises : le premier concerne des changements majeurs dans la manière de sécuriser et anonymiser les données échangées ; le second à avoir avec la manière dont les États et les agences de santé peuvent personnaliser leurs applications pour correspondre à des recommandations sanitaires nationales.

Aucun des deux points ne vient rendre compatible cette solution essentielle avec les protocoles locaux, comme le protocole ROBERT de l’Inria en France.

Une plus grande protection

Du côté de la sécurité, Google et Apple ont choisi de chiffrer les données échangées (les identifiants chiffrés des autres personnes, par exemple) avec la technologie AES plutôt que HMAC, qui ne demande pas trop de puissance pour effectuer un chiffrement sur le téléphone sans le ralentir — même pour les modèles plus anciens. En plus, le système chiffrera également les métadonnées Bluetooth, ce qui ne permettra pas à un attaquant potentiel de déduire le modèle d’un smartphone en reconnaissant son signal.

Une clef unique et chiffrée sera générée tous les jours sur chaque smartphone

Du côté des clefs créées pour identifier les smartphones, elles ne seront plus dérivées d’une clef initiale, mais renouvelées tous les jours. Il y aura donc une clef unique tous les jours, attachée à un smartphone, ce qui empêche un attaquant potentiel de remonter à « la clef initiale » en la devinant à partir d’une clef dérivée. Enfin, pour rendre l’information sur le temps passé en présence d’un autre smartphone plus difficile à exploiter, il sera fractionné par période de 5 minutes, jusqu’à un maximum de 30 minutes.

Plus de précision avec le Bluetooth

L’un des arguments des détracteurs experts du contact tracing par application est l’impossibilité pour le Bluetooth de créer une mesure satisfaisante entre deux personnes, qui ne fera pas émerger de faux positifs. Des éléments ne pourront jamais être contrôlés, comme l’épaisseur du tissu d’une poche ou une surface qui viendrait bloquer le signal. Mais Google et Apple ont ajouté une information à l’API : la puissance nominale de la puce Bluetooth embarquée dans un smartphone.

Cela permettra de pondérer l’information sur le signal reçu par un autre smartphone : si une puce Bluetooth envoie un signal faible, le smartphone qui la reçoit saura que ce n’est pas forcément parce qu’elle est loin, mais peut-être parce qu’elle n’a pas la capacité technique d’émettre plus. Reste qu’il faudra toujours une table de conversion intensité du signal / distance dont la précision reste à prouver.

De même, pour donner plus de contrôles aux pays dans la construction de leurs apps, Google et Apple vont les laisser définir ce qui constitue, pour eux, un « événement d’exposition ». On sait que les pays ont tous une doctrine, par exemple sur la distance à respecter entre deux personnes et ils en auront une pour déterminer également à partir de combien de temps passé en présence d’une personne on considère qu’il y a eu un « contact » pouvant entraîner contamination. La nouvelle API permettra aux développeurs des agences de santé de régler ces niveaux à leur convenance.

Apple bloque le Bluetooth en arrière-plan pour protéger ses utilisateurs des apps malveillantes // Source : Claire Braikeh pour Numerama

Apple bloque le Bluetooth en arrière-plan pour protéger ses utilisateurs des apps malveillantes

Source : Claire Braikeh pour Numerama

Incompatible avec les protocoles tiers

Ces avancées sur les API de Google et Apple, les seules qui pourront permettre un accès au Bluetooth en arrière-plan et qui sont donc essentielles au bon fonctionnement d’une application enterrent les projets qui ne se basent pas dessus. Les porte-parole des deux entreprises ont salué le travail des États sur des solutions maison, mais estiment que seule une solution globale, déployée à l’échelle mondiale et la même sur tous les smartphones pourra être efficace du côté du protocole de communication : « Vous ne voulez pas que le protocole varie à l’échelle nationale, sinon cela ne marchera pas côté interopérabilité. C’est le fait que ce soit très normé justement qui fera que l’API fonctionnera à grande échelle ». Libre aux États, par la suite, de construire leur solution maison par-dessus ce jeu d’instruction.

Le protocole ROBERT qui est par exemple mis en avant par la France, n’est toujours pas compatible avec cette API : il suppose que la correspondance entre un utilisateur déclaré positif et tous ses contacts soit faite sur le serveur central, qui supposera donc que tous les contacts sont « à risque » pour ne jamais individualiser le porteur confirmé du virus. Du côté d’Apple et Google, la centralisation n’est là que pour l’agrégation des données anonymisées et la correspondance se fait sur le smartphone en local, seul moyen pour eux de garantir que l’information n’échappe pas au contrôle de l’utilisateur.

Reste à voir comment les pouvoirs publics vont sortir de cette impasse : adopter l’API Google / Apple et adapter ROBERT à son fonctionnement ? Dans le cas contraire, l’application StopCovid, dont les limites sont déjà très nombreuses, aura du mal à fonctionner. Côté communication, l’excuse du gouvernement sera toute trouvée si StopCovid ne fonctionne pas comme attendu : cela sera la faute de Google ou d’Apple, qui ne lui ont pas donné de passe-droit pour amoindrir la protection de la vie privée de leurs utilisateurs. Ou celle des Françaises et des Français qui n’auraient pas installé l’application en nombre suffisant : il ne faut jamais oublier que ce concept ne fonctionne que dans le cas d’une adoption massive.


Si vous avez aimé cet article, vous aimerez les suivants : ne les manquez pas en vous abonnant à Numerama sur Google News.