Les ministères de la santé et de l’intérieur ont révélé ce lundi 11 mai les premiers détails sur l’application de traçage des contaminations au Covid-19, dans le cadre d’une conférence de presse en ligne. Cette application a été développé par plusieurs partenaires (En plus du trio Valyans, Aiox-Labs, et le groupe MedTech, d’autres intervenants entrent dans le processus Berkeley Systems, Dial Technologies, Omnishore, OCP à travers 1337, Abweb, Hidden Clouders, l’ADD et l’ANRT), et servira dans l’amélioration du protocole de tracage des contacts. S’inspirant et utilisant fortement le protocole BlueTrace développé par le gouvernement singaporien, cet article a pour but de détailler le protocole BlueTrace.
Fonctionnement Général
BlueTrace a été concu de telle façon à ce que les informations personnelles soient collectées une seule fois au moment de l’enregistrement et ne soient utilisées que pour contacter les patients potentiellement infectés. De plus, les utilisateurs peuvent se retirer à tout moment, effaçant toutes les informations personnelles et rendant toutes les données enregistrées introuvables. Le suivi des contacts se fait entièrement localement sur un appareil client à l’aide de Bluetooth Low Energy, stockant toutes les rencontres dans un journal d’historique des contacts retraçant les rencontres des 21 derniers jours.
Les utilisateurs dans le journal des contacts sont identifiés à l’aide d ‘«identifiants temporaires» temporaires décalés délivrés par l’autorité sanitaire. Cela signifie que l’identité d’un utilisateur ne peut être vérifiée par personne d’autre que l’autorité sanitaire auprès de laquelle il est enregistré.
De plus, comme les identifiants temporaires changent régulièrement, des tiers malveillants ne peuvent théoriquement pas suivre les utilisateurs en observant les entrées de journal au fil du temps.
Fonctionnement Technique
Le protocole a deux fonctions de communications principales :
- la journalisation locale des utilisateurs enregistrés à proximité d’un appareil
- la transmission du journal à l’autorité sanitaire opérationnelle, tout en préservant la confidentialité.
Pour ce faire, le protocole peut être divisé entre les domaines de communication de périphérique à périphérique DDC (Device to Device Communication) et de communication de périphérique à serveur de rapports DRSC (device to reporting server communication).
Il faut savoir que le protocole Bluetooth Low Energy, définit déjà un protocole d’échange d’informations permettant aux devices bluetooth d’être au courant de leur entourage. Le composant DDC fonctionne au dessus de cettte pile pour définir comment deux entitées de tracage reconnaissent la présence l’un de l’autre.
Le composant DRSC utilise HTTPS pour communiquer une chronologies de contacts à un serveur centralisé appartenant à une autorité sanitaire, et ceci, une fois qu’un utilisateur a été testé positif à une infection.
L’autorité sanitaire peut alors notifier tous les utilisateurs présents dans la chronologie sur les 21 jours précedant le test du contact avec un porteur positif.
Fonctionnement DRSC
Chaque application mettant en œuvre le protocole BlueTrace communique avec un serveur central exploité par une autorité sanitaire de confiance.
Le serveur de rapports est chargé de :
- Gérer l’enregistrement initial
- Fournir des identifiants d’utilisateurs uniques
- Collecter les journaux de contacts créés par la partie DDC du protocole.
Lorsque l’utilisateur lance l’application pour la première fois, il lui sera demandé son numéro de téléphone et un ID utilisateur statique lui sera attribué.
Ce numéro de téléphone est utilisé ultérieurement si l’application a enregistré une rencontre dans le journal des contacts d’un patient infecté.
Une fois enregistrés, les utilisateurs reçoivent des identifiants temporaires (TempID) qui les identifient de manière unique et temporaire sur d’autres appareils. Chaque TempID a une durée de vie de 15 minutes pour empêcher les parties malveillantes d’effectuer des attaques de type “Replay Attack” ou de suivre les utilisateurs dans le temps avec des identifiants uniques statiques.
Les TempID sont générés à partir de l’ID utilisateur d’un utilisateur, de l’heure de début TempID et de l’heure d’expiration TempID, qui sont chiffrés et transformés en une chaîne encodée en Base64 par le serveur à l’aide d’une clé de chiffrement symétrique secrète. Pour garantir que les appareils disposent d’un approvisionnement constant de TempID, en cas de déconnection internet, les TempID sont envoyé à l’appareil par lots.
Le TempID est composé de la façon suivante :
Une fois qu’un utilisateur a été testé positif à l’infection, l’autorité sanitaire génère un code PIN authentifiant l’utilisateur pour télécharger son journal de contacts sur le serveur de rapports. Dans le cadre du journal, des métadonnées sur chaque rencontre sont incluses; le plus important étant l’horodatage et l’identifiant de l’autorité sanitaire (HAI). Le HAI identifie à quelle autorité sanitaire le contact enregistré fait rapport. Si le HAI représente une autorité sanitaire étrangère, l’entrée de journal est transmise à l’autorité identifiée pour y être traitée. Une fois qu’une autorité sanitaire a filtré les entrées de journal pour n’inclure que les clients à domicile, elle déchiffre le TempID pour révéler l’ID utilisateur, l’heure de début et l’heure d’expiration. La date de début et d’expiration est comparée à l’horodatage de la rencontre pour garantir la validité, et l’ID utilisateur est associé à un numéro de téléphone. L’autorité sanitaire peut alors contacter le numéro de téléphone pour informer un utilisateur d’un contact potentiel avec un patient infecté.
Fonctionnement DDC
La partie DDC du protocole définit la façon dont deux appareils communiquent et enregistrent leurs contacts. Chaque appareil est dans l’un des deux états, Central ou Périphérique, l’état du périphérique étant défini de façon cyclique.
En mode périphérique, un appareil annonce sa présence et en mode central, il recherche les appareils qui sont en mode périphérique. De plus, certains appareils sont incapables de fonctionner en mode central et fonctionnent donc uniquement en mode périphérique, en fonction du matériel.
Une fois que deux appareils se sont découverts, ils communiquent un paquet caractéristique contenant des informations sur eux-mêmes. Le paquet est formé comme un fichier JSON, contenant le TempID, le modèle de périphérique, HAI et la version du protocole BlueTrace du périphérique.
Lorsqu’il fonctionne en mode Central, l’appareil envoie également la force du signal, ce qui permet de calculer la distance approximative entre les deux appareils ultérieurement. Voici un exemple de paquet de caractéristiques centrales:
{
“id”: “FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw + Iz8tqAdpbxR1 nSvr + ILXPG ==”, // TempID
“md”: “iPhone X”, // Modèle d’appareil
“rc”: -60, // Force du signal
“o”: “IJ_HAI”, // Identifiant de l’autorité sanitaire
“v”: 2 // Version du protocole
}
Ces caractéristiques sont ensuite ajoutées à une base de données locale sur l’appareil où elles sont stockées pendant 21 jours et peuvent être envoyées au serveur de rapports ultérieurement. L’appareil contacté est également ajouté à une liste noire locale pendant deux cycles de service afin d’empêcher deux appareils de se contacter de manière répétée, économisant ainsi de l’énergie et du stockage.
Callflow :
Le schéma suivant explique donc les principales étapes de communication des devices sur les différents domaines de communication :
Pour aller plus loin
En attendant la mise à disposition du code source de l’application marocaine, je vous invite à visiter le dépôt de code de l’implémentation opensource de BlueTrace : OpenTrace
https://github.com/opentrace-community
Les exemples d’applications sont en kotlin/swift/Xcode pour comprendre le code du client. Il existe aussi un exemple d’implémentation serveur pour voir la gestion de données.
Leave a Reply