Thread by @gilbsgilbs

Depuis quelques jours, le #PassSanitaire émis par AMELI et SI-DEP a abandonné le format français (2D-DOC) au profit d'un format européen standard appelé Digital Covid Certificate (DCC). Comment fonctionne-t-il ? Que contient-il ? Qui peut le lire ? Qui peut l'émettre ? Thread ⬇

Rappel : ce passe sanitaire permettra en France de participer aux grands rassemblements, accéder aux discothèques et voyager dans les pays qui l'acceptent. En France, il est vérifié à l'aide d'une obscure application propriétaire, TousAntiCovid Verif dont j'ai déjà parlé en mal.

Toutes les spécifications techniques de ce format sont publiques et disponibles sur une page du site de la commission européenne : ec.europa.eu/health/ehealth… . Contrairement au 2D-DOC qui utilisait un Datamatrix (gauche), ce nouveau format est basé sur le standard QR Code (droite).

À la différence du 2D-DOC, si on essaye de décoder ce QR Code à l'aide d'un lecteur de code-barres (tel que Binary Eye sur Android), on trouve une suite de caractères en apparence cryptique. Mais contrairement aux apparences, les données médicales sont bien encodées en clair.

Pour comprendre comment décoder ce QR Code sans devoir se farcir 200 pages de documentation en PDF, l'UE a créé des implémentations de référence et des synthèses sur GitHub, notamment ici : github.com/ehn-dcc-develo… .

Pour schématiser un peu mieux, je présenterais ça plutôt comme un système de "poupées russes", dans laquelle chaque "poupée" possède un rôle bien précis :

base45 et ZLIB permettent d'optimiser la quantité de données qu'on met dans le QR code afin de :
- pouvoir mettre plus de données dedans
- permettre un scan plus fiable

base45 est une norme qui semble avoir été créée pour l'occasion : datatracker.ietf.org/doc/draft-falt… .

La signature (ECDSA est recommandé dans les guidelines de la commission européenne) est ce qui rend ce QR Code théoriquement infalsifiable et permet à tout le monde de vérifier qu'un certificat donné est bel est bien authentique. J'y reviendrai plus tard.

Ce qu'il faut retenir c'est que les données du passe sont signées et non chiffrées, donc tout le monde en possession d'un QR Code et d'un lecteur peut techniquement lire toutes les données qu'il contient. Ça se fait en 10 lignes de code (0bin.net/paste/O2AKoNkA…).

Logiquement, on peut donc se demander quelles données personnelles ce passe contient. Et bien ceci a aussi été spécifié par la commission européenne sous la forme d'un schéma JSON : github.com/ehn-dcc-develo… . On y retrouve des données similaires à celles du 2D-DOC, par exemple :

- Un identifiant unique
- Le pays émetteur
- Nom/prénom/date de naissance
- Nom du vaccin / Date d'injection / nombre d'injection si certificat de vaccination
- Date d'un test PCR positif/négatif dans le cas d'un certificat de rétablissement ou d'un certificat de test.

Certains ont récemment critiqué le fait que les données de ce passe sont en clair, mais il faut comprendre que s'il était chiffré il ne serait pas possible de faire une vérification hors-ligne et ce serait pire. La question est donc plutôt : à qui va-t-on montrer ce document.

Et le problème de fond est là : ce passe est quand même bavard. C'est ridicule de montrer un document contenant autant d'informations à un videur de discothèque. On aurait pas idée de montrer sa carte bancaire à n'importe qui en disant de « surtout ne pas lire les 16 chiffres ».

Pour cacher la misère, les gouvernements forcent donc les organisateurs d'événements à utiliser des applications propriétaires "officielles" comme TousAntiCovid Verif qui masquent artificellement les données du passe. C'est assez illusoire et ça ouvre la porte à plein de dérives.

On peut également questionner l'utilité pour un agent d'aéroport de connaître (légalement) le nombre d'injections reçues. Cette information permet de déduire si une personne a déjà eu le COVID (1 injection) ou est à risque de forme grave (3 injections). Ça ne les regarde pas.

Il eût été plus respecteux des données personnelles de créer deux pass :
- l'un contenant peu de données (prénom, première lettre du nom, jour/mois de naissance, date de fin, OK/KO)
- l'autre contenant + de données (sauf le nb d'injections) réservé aux opérateurs de transport

Maintenant qu'on a parlé des données du pass, parlons un peu schéma de confiance : qui peut émettre ces certificats, comment vérifier qu'un pass donné est authentique. Ceci a aussi été spécifié par la commission européenne : github.com/ehn-dcc-develo…

Je vais expliquer avec l'exemple de la France parce que ce sera plus simple, mais c'est pareil pour tous les états membre. Chaque organisation autorisée à émettre des pass sanitaires génère une clé privée et une clé publique associée à cette clé privée.

La clé privée est tenue secrète. Elle permet de générer la fameuse signature infalsifiable que nous avons vue plus haut. À l'inverse, la clé publique est diffusée le plus largement possible. Elle permet d'assurer l'authenticité du QR code par vérification de sa signature.

Mais ces clés publiques ne sont pas partagées n'importe comment comme c'était le cas avec le 2D-DOC. Elles sont d'abord certifiées par l'Agence Nationale des Titres Sécurisés (ANTS).

(Pour les connaisseurs, c'est une un CSR classique. L'ANTS fait office d'autorité de certification et on peut trouver leur certificat racine ici : ants.gouv.fr/L-internationa… .)

Cette clé publique + la preuve que l'ANTS la reconnaît sont envoyées sur un serveur privé centralisé mis en place par l'UE : github.com/eu-digital-gre… . Ce serveur permet à chaque pays de :
- distribuer ses clés publiques
- connaître les clés publiques des autres états membres

(Pour les pros : l'utilité du CA dans le processus n'est pas clairement expliqué du point de vue sécurité, mais j'intuite que le serveur de l'UE connaît les CA de chaque état membre et vérifie que les certificats qu'il reçoit sont bien signés par un CA connu pour cet état.)

La suite est décrite ici : github.com/eu-digital-gre… . Chaque application de vérification (comme TousAntiCovid Verif) se connecte à un serveur intermédiaire (en l'occurrence celui d'IN Groupe) qui récupère périodiquement les clés publiques de tous les pays sur le serveur de l'UE.

Comme on l'a vu, les applications de vérification sont souvent des applications propriétaires, difficiles à auditer, telles que TousAntiCovid Verif mais aussi la version autrichienne : greencheck.gv.at.

Ceci complexifie la création de vérificateurs alternatifs et compromet la sécurité du système puisqu'il est difficile de savoir si une appli de vérification se comporte bien comme attendu. J'ai pu extraire les clés publiques utilisées par ces deux applis : 0bin.net/paste/E-9oC3N3…

Je déplore que l'UE fournisse pas :
- Une liste publique de toutes les autorités de certifications reconnues pour chaque pays membre ainsi que leur certificat (ANTS, …)
- Une liste publique de toutes les clés publiques d'émetteurs reconnus de certificats COVID.

On peut noter que :
- La révocation d'une clé publique est possible en supprimant la clé du serveur de l'UE et après un temps de propagation
- La révocation d'un pass sanitaire donné ne semble pas possible pour le moment. J'imagine que c'est un risque mineur.

- Il n'y a pas de CA européen ni de vraie chaîne de confiance. Donc pas de moyen simple de vérifier qu'une clé publique fournie par le serveur d'une application de vérification est bien légitime.

En conclusion (c'était long, désolé), on peut souligner les efforts de l'UE pour sa transparence concernant les spécifications de ce pass mais moins sur la mise en œuvre (même si ça aurait pu être bien pire). Ce pass est trop bavard et le modèle de confiance est trop fragile.

Aucune mesure coercitive n'a été prise concernant les applications de vérification et on ne peut que s'en inquiéter quand on sait que l'une d'entre elles a jugé bon de faire transiter des pass sanitaires en clair via un prestataire américain.

Si vous voulez visualiser toutes les données contenues dans votre passe sanitaire européen pour mieux vous rendre compte, vous pouvez le faire ici : sanipasse.fr/import/video . (Aucune donnée du passe n'est envoyé sur un serveur, tout est vérifié en local.)

(Et bravo aux 2,5 personnes qui auront lu ce thread jusqu'au bout 😄)