La difficulté de l’intégration d’un permis de conduire numérique sur téléphone (mDL) ne réside pas dans l’appel à une interface de programmation pour vérifier l’identité, mais dans la compréhension de ce qui se passe derrière cette interface : où les justificatifs sont-ils stockés, qui protège les clés de l’appareil, comment les certificats de confiance sont-ils gérés, et qu’est-ce qui continue de fonctionner en cas de coupure du réseau ou de défaillance du fournisseur de services ? L’article publié sur InfoQ présente une vision architecturale des systèmes mDL construits conformément à la norme ISO/IEC 18013-5, destinée aux organisations qui choisissent un fournisseur, un SDK, une plateforme de portefeuille ou un service de vérification.
Séparer la preuve d’identité de l’émission du justificatif
Le cadre proposé commence par séparer deux étapes différentes du cycle de vie de l’identité. Lors de la phase de preuve d’identité, l’utilisateur prend des photos de son permis physique ainsi qu’une vidéo pour la vérification de la vivacité, puis les preuves et les données extraites sont envoyées au système de vérification. L’autorité compétente, telle que l’administration chargée des véhicules automobiles, examine ces preuves automatiquement ou manuellement avant de prendre une décision d’acceptation ou de refus.
Après l’approbation commence la phase de provisionnement. L’appareil génère des clés asymétriques au sein d’un Secure Enclave ou d’un élément sécurisé, puis envoie la clé publique, les certificats d’attestation et la référence de l’opération de preuve à l’autorité émettrice. Celle-ci associe les données du permis à la clé dans un Mobile Security Object signé, puis chiffre le paquet de justificatif et l’envoie au portefeuille, qui le stocke dans un espace protégé par le matériel.
L’organisation n’est pas tenue d’exécuter elle-même ces étapes, mais elle doit déterminer quelle partie est responsable de chacune d’elles et quelle partie détient la décision de confiance qui en découle.
Que faut-il examiner derrière l’interface du fournisseur ?
L’article estime que le succès d’une expérience pilote appelant des fonctions telles que verifyCredential() ou requestPresentation() ne suffit pas à évaluer le fournisseur. L’examen doit couvrir six axes interdépendants :
- Architecture cryptographique : génération et protection des clés, attestation de l’appareil, algorithmes et cycle de vie des clés.
- Confiance et infrastructure à clés publiques : ancres de confiance, certificats Document Signer, listes de confiance et listes de révocation.
- Vie privée et minimisation des données : divulgation sélective, télémétrie, conservation des données de présentation et risques de corrélation entre les transactions.
- Fonctionnement hors ligne : éléments stockés en cache, état obsolète de la révocation et comportement du système pendant une interruption du réseau.
- Interopérabilité : conformité à la norme ISO/IEC 18013-5 et possibilité d’interagir avec des portefeuilles et des vérificateurs indépendants.
- Résilience opérationnelle : impact d’une panne du fournisseur, continuité du justificatif, mécanismes de reprise et gestion des défaillances.
Le chiffrement et les certificats ne sont pas de simples détails d’implémentation
L’article propose d’utiliser le Hybrid Public Key Encryption conformément à la RFC 9180 pour protéger les transmissions en ligne et les échanges via les interfaces de programmation, avec des paramètres comprenant DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 et AES-128-GCM. Toutefois, selon le cadre présenté, le chiffrement ne doit pas être traité comme une fonctionnalité distincte du modèle de confiance ; il faut savoir où commence et où s’achève le chiffrement, qui génère et protège les clés, comment celles-ci sont renouvelées et quels composants se trouvent dans les limites de confiance du fournisseur.
Les communications entre les serveurs de portefeuilles, les plateformes d’émission et les systèmes de vérification nécessitent également une authentification mutuelle via TLS et une architecture de certificats claire. L’article présente différents rôles pour les certificats, depuis la racine de confiance stockée dans une unité de sécurité matérielle et hors ligne jusqu’aux certificats Document Signer à courte durée de vie, aux certificats mTLS et aux certificats d’attestation des clés des appareils. La question déterminante reste la répartition des responsabilités : quelle infrastructure est gérée par le fournisseur, laquelle est sous le contrôle de l’organisation et quelles relations de confiance restent entre les mains de l’autorité émettrice.
Qu’est-ce qui change concrètement en cas d’interruption du service ?
La conception distingue les opérations synchrones qui se produisent pendant la vérification, telles que l’échange de données via NFC ou la vérification directe via une API, et les opérations asynchrones pouvant être exécutées en arrière-plan, telles que l’examen de la preuve d’identité, le provisionnement du justificatif, le renouvellement des clés et la synchronisation des listes de confiance.
Cette séparation permet de continuer à présenter et à vérifier un justificatif existant hors ligne lorsque les politiques l’autorisent, tandis que la synchronisation des listes de confiance ou les mises à jour de révocation peuvent être différées. L’article propose de tester la présentation et la vérification sans réseau, les justificatifs expirés, les listes de révocation obsolètes, la dérive de l’horloge de l’appareil, le rétablissement de la connexion et le comportement du système pendant une panne du fournisseur. En effet, la dépendance à un fournisseur hautement disponible peut rester un point unique de défaillance si chaque vérification exige une connexion à ses services dorsaux.
Divulgation sélective et prévention de la dépendance au fournisseur
Les données requises varient selon le cas. Un point de contrôle dans un aéroport peut avoir besoin du nom, de la photo, de la date de naissance, du numéro du document et de l’autorité émettrice, tandis qu’un magasin peut se contenter d’une déclaration logique prouvant que l’utilisateur a plus de 21 ans, accompagnée d’une photo, sans le nom, l’adresse ni le numéro du document. Il ne suffit donc pas de tester le fournisseur au moyen d’un seul scénario ; il faut l’évaluer au regard des politiques de l’organisation et des catégories réelles de transactions.
Le contenu propose de maintenir la logique métier indépendante de l’architecture du fournisseur, afin que les applications expriment une politique telle que la demande d’une preuve attestant que l’utilisateur a plus de 21 ans, au lieu de diffuser dans l’ensemble du système des structures de données propres au fournisseur. Les détails tels que la séquence CBOR, la construction des messages APDU et les appels aux bibliothèques cryptographiques peuvent être masqués, mais les ancres de confiance, l’identité de l’autorité émettrice, les attributs divulgués, l’état du certificat et de la révocation, la dépendance au fournisseur et les capacités de fonctionnement hors ligne doivent rester visibles pour l’organisation.
La lecture de certi.news
Le véritable changement mis en avant par l’article consiste à faire passer l’évaluation d’un mDL du test d’une fonctionnalité de SDK à l’examen d’un système de confiance complet. Cette approche est utile aux équipes chargées de la sécurité, de l’identité et des achats, car elle précise ce qui peut être acheté et ce qui doit rester sous la gouvernance de l’organisation : il est possible d’acheter l’implémentation du portefeuille, les protocoles NFC et les bibliothèques cryptographiques, tandis que les politiques de divulgation, d’autorisation et d’audit, ainsi que la gouvernance de la gestion des clés et des certificats, de la vie privée, de la disponibilité et de l’interopérabilité, devraient être élaborées par l’organisation.
Le cadre ne tranche toutefois pas à lui seul des questions telles que les exigences locales de conformité ou les modèles de gouvernance entre les autorités émettrices et les vérificateurs. En outre, garantir la validité d’une signature ne garantit pas la vie privée si les systèmes conservent des journaux excessifs ou associent les opérations de présentation aux utilisateurs. Les questions de traçabilité, de révocation préservant la vie privée et de responsabilité en cas de défaillance du fournisseur restent donc des points nécessitant des décisions institutionnelles et réglementaires avant le passage en production.