Les utilisateurs dans le journal des contacts sont identifi\u00e9s \u00e0 l’aide d ‘\u00abidentifiants temporaires\u00bb temporaires d\u00e9cal\u00e9s d\u00e9livr\u00e9s par l’autorit\u00e9 sanitaire. Cela signifie que l’identit\u00e9 d’un utilisateur ne peut \u00eatre v\u00e9rifi\u00e9e par personne d’autre que l’autorit\u00e9 sanitaire aupr\u00e8s de laquelle il est enregistr\u00e9.<\/span><\/p>\n De plus, comme les identifiants temporaires changent r\u00e9guli\u00e8rement, des tiers malveillants ne peuvent th\u00e9oriquement pas suivre les utilisateurs en observant les entr\u00e9es de journal au fil du temps. Le protocole a deux fonctions de communications principales : <\/span><\/span><\/p>\n Pour ce faire, le protocole peut \u00eatre divis\u00e9 entre les domaines de communication de p\u00e9riph\u00e9rique \u00e0 p\u00e9riph\u00e9rique DDC (Device to Device Communication) et de communication de p\u00e9riph\u00e9rique \u00e0 serveur de rapports DRSC (device to reporting server communication).<\/span><\/span><\/p>\n Il faut savoir que le protocole Bluetooth Low Energy, d\u00e9finit d\u00e9j\u00e0 un protocole d’\u00e9change d’informations permettant aux devices bluetooth d’\u00eatre au courant de leur entourage. Le composant DDC fonctionne au dessus de cettte pile pour d\u00e9finir comment deux entit\u00e9es de tracage reconnaissent la pr\u00e9sence l’un de l’autre.<\/p>\n Le composant DRSC utilise HTTPS pour communiquer une chronologies de contacts \u00e0 un serveur centralis\u00e9 appartenant \u00e0 une autorit\u00e9 sanitaire, et ceci, une fois qu’un utilisateur a \u00e9t\u00e9 test\u00e9 positif \u00e0 une infection.<\/p>\n L’autorit\u00e9 sanitaire peut alors notifier tous les utilisateurs pr\u00e9sents dans la chronologie sur les 21 jours pr\u00e9cedant le test du contact avec un porteur positif.<\/p>\n Chaque application mettant en \u0153uvre le protocole BlueTrace communique avec un serveur central exploit\u00e9 par une autorit\u00e9 sanitaire de confiance. <\/span><\/p>\n Le serveur de rapports est charg\u00e9 de :<\/span><\/p>\n Lorsque l’utilisateur lance l’application pour la premi\u00e8re fois, il lui sera demand\u00e9 son num\u00e9ro de t\u00e9l\u00e9phone et un ID utilisateur statique lui sera attribu\u00e9. Ce num\u00e9ro de t\u00e9l\u00e9phone est utilis\u00e9 ult\u00e9rieurement si l’application a enregistr\u00e9 une rencontre dans le journal des contacts d’un patient infect\u00e9. <\/span><\/p>\n Une fois enregistr\u00e9s, les utilisateurs re\u00e7oivent des identifiants temporaires (TempID) qui les identifient de mani\u00e8re unique et temporaire sur d’autres appareils. Chaque TempID a une dur\u00e9e de vie de 15 minutes pour emp\u00eacher les parties malveillantes d’effectuer des attaques de type “Replay Attack” ou de suivre les utilisateurs dans le temps avec des identifiants uniques statiques. <\/span><\/p>\n Les TempID sont g\u00e9n\u00e9r\u00e9s \u00e0 partir de l’ID utilisateur d’un utilisateur, de l’heure de d\u00e9but TempID et de l’heure d’expiration TempID, qui sont chiffr\u00e9s et transform\u00e9s en une cha\u00eene encod\u00e9e en Base64 par le serveur \u00e0 l’aide d’une cl\u00e9 de chiffrement sym\u00e9trique secr\u00e8te. Pour garantir que les appareils disposent d’un approvisionnement constant de TempID, en cas de d\u00e9connection internet, les TempID sont envoy\u00e9 \u00e0 l’appareil par lots. Le TempID est compos\u00e9 de la fa\u00e7on suivante : Une fois qu’un utilisateur a \u00e9t\u00e9 test\u00e9 positif \u00e0 l’infection, l’autorit\u00e9 sanitaire g\u00e9n\u00e8re un code PIN authentifiant l’utilisateur pour t\u00e9l\u00e9charger son journal de contacts sur le serveur de rapports.<\/span> Dans le cadre du journal, des m\u00e9tadonn\u00e9es sur chaque rencontre sont incluses;<\/span> le plus important \u00e9tant l’horodatage et l’identifiant de l’autorit\u00e9 sanitaire (HAI).<\/span> Le HAI identifie \u00e0 quelle autorit\u00e9 sanitaire le contact enregistr\u00e9 fait rapport.<\/span> Si le HAI repr\u00e9sente une autorit\u00e9 sanitaire \u00e9trang\u00e8re, l’entr\u00e9e de journal est transmise \u00e0 l’autorit\u00e9 identifi\u00e9e pour y \u00eatre trait\u00e9e.<\/span> Une fois qu’une autorit\u00e9 sanitaire a filtr\u00e9 les entr\u00e9es de journal pour n’inclure que les clients \u00e0 domicile, elle d\u00e9chiffre le TempID pour r\u00e9v\u00e9ler l’ID utilisateur, l’heure de d\u00e9but et l’heure d’expiration.<\/span> La date de d\u00e9but et d’expiration est compar\u00e9e \u00e0 l’horodatage de la rencontre pour garantir la validit\u00e9, et l’ID utilisateur est associ\u00e9 \u00e0 un num\u00e9ro de t\u00e9l\u00e9phone.<\/span> L’autorit\u00e9 sanitaire peut alors contacter le num\u00e9ro de t\u00e9l\u00e9phone pour informer un utilisateur d’un contact potentiel avec un patient infect\u00e9.<\/span><\/span><\/p>\n La partie DDC du protocole d\u00e9finit la fa\u00e7on dont deux appareils communiquent et enregistrent leurs contacts. Chaque appareil est dans l’un des deux \u00e9tats, Central ou P\u00e9riph\u00e9rique, l’\u00e9tat du p\u00e9riph\u00e9rique \u00e9tant d\u00e9fini de fa\u00e7on cyclique.<\/span><\/p>\n En mode p\u00e9riph\u00e9rique, un appareil annonce sa pr\u00e9sence et en mode central, il recherche les appareils qui sont en mode p\u00e9riph\u00e9rique. De plus, certains appareils sont incapables de fonctionner en mode central et fonctionnent donc uniquement en mode p\u00e9riph\u00e9rique, en fonction du mat\u00e9riel.<\/p>\n<\/div>\n Une fois que deux appareils se sont d\u00e9couverts, ils communiquent un paquet caract\u00e9ristique contenant des informations sur eux-m\u00eames. Le paquet est form\u00e9 comme un fichier JSON, contenant le TempID, le mod\u00e8le de p\u00e9riph\u00e9rique, HAI et la version du protocole BlueTrace du p\u00e9riph\u00e9rique.<\/span><\/p>\n Lorsqu’il fonctionne en mode Central, l’appareil envoie \u00e9galement la force du signal, ce qui permet de calculer la distance approximative entre les deux appareils ult\u00e9rieurement. Voici un exemple de paquet de caract\u00e9ristiques centrales:<\/p>\n { Ces caract\u00e9ristiques sont ensuite ajout\u00e9es \u00e0 une base de donn\u00e9es locale sur l’appareil o\u00f9 elles sont stock\u00e9es pendant 21 jours et peuvent \u00eatre envoy\u00e9es au serveur de rapports ult\u00e9rieurement. L’appareil contact\u00e9 est \u00e9galement ajout\u00e9 \u00e0 une liste noire locale pendant deux cycles de service afin d’emp\u00eacher deux appareils de se contacter de mani\u00e8re r\u00e9p\u00e9t\u00e9e, \u00e9conomisant ainsi de l’\u00e9nergie et du stockage.<\/p>\n<\/div>\n<\/div>\n Le sch\u00e9ma suivant explique donc les principales \u00e9tapes de communication des devices sur les diff\u00e9rents domaines de communication :<\/p>\n En attendant la mise \u00e0 disposition du code source de l’application marocaine, je vous invite \u00e0 visiter le d\u00e9p\u00f4t de code de l’impl\u00e9mentation opensource de BlueTrace : OpenTrace<\/p>\n
\n<\/span><\/p>\nFonctionnement Technique<\/h2>\n
\n
Fonctionnement DRSC<\/h2>\n
\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n
\n<\/span><\/p>\n![\"\"](\"https:\/\/www.erroussafi.com\/wp-content\/uploads\/2020\/05\/Capture_tempID.png\")
<\/p>\nFonctionnement DDC<\/h2>\n
\n“id”: “FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw + Iz8tqAdpbxR1 nSvr + ILXPG ==”, \/\/ TempID
\n“md”: “iPhone X”, \/\/ Mod\u00e8le d’appareil
\n“rc”: -60, \/\/ Force du signal
\n“o”: “IJ_HAI”, \/\/ Identifiant de l’autorit\u00e9 sanitaire
\n“v”: 2 \/\/ Version du protocole
\n}<\/p>\nCallflow :<\/span>
\n<\/span><\/span><\/h2>\n![\"\"](\"https:\/\/www.erroussafi.com\/wp-content\/uploads\/2020\/05\/CallFlow.png\")
<\/p>\nPour aller plus loin<\/h2>\n