Portefeuille d’identité électronique eIDAS allemand : une architecture de vérification de la sécurité des appareils fondée sur les comptes Apple et Google

• Le National EUDI Wallet allemand maintient l’intégrité de l’authentification d’identité électronique via un dispositif de gestion des vulnérabilités des appareils mobiles (MDVM)
• Le MDVM détecte les vulnérabilités du système d’exploitation et du magasin matériel de clés (HKS) et, si le risque est élevé, bloque l’utilisation des clés d’authentification
• Sur Android, la vérification de l’intégrité des appareils s’appuie sur Google Play Integrity API et KeyAttestation ; sur iOS, sur Apple DeviceCheck·AppAttest
• En conséquence, lors de l’utilisation des fonctions d’identité électronique, une procédure de vérification fondée sur un compte Apple ou Google se déclenche nécessairement
• L’ensemble du système est conçu pour empêcher la copie et l’usage abusif des clés par des attaquants et pour maintenir un niveau élevé d’assurance de l’authentification eID

---

Concept de gestion des vulnérabilités des appareils mobiles (Mobile Device Vulnerability Management, MDVM)

• Le MDVM est, dans l’architecture du National EUDI Wallet allemand, le dispositif chargé de surveiller en continu les vulnérabilités de sécurité des appareils des utilisateurs et de préserver l’intégrité des moyens d’authentification
• Il détecte les vulnérabilités connues du HKS (magasin matériel de clés) et du système d’exploitation (OS) et, si le risque d’attaque est élevé, bloque l’utilisation des clés RWSCA/RWSCD
• Cela permet de maintenir un haut niveau d’assurance lors du processus de vérification d’identité électronique (eID) et d’empêcher la copie et l’usage abusif des clés par des attaquants
• Le MDVM se compose de quatre fonctions : vérification de l’état de sécurité de l’appareil et de l’application, identification de la classe d’appareil, vérification des vulnérabilités et décision d’usage

---

Motivation

• La Wallet Unit fournit des moyens d’authentification liés à plusieurs moyens d’identité (PID, etc.) au moyen d’une paire de clés publique/privée
• Lors de l’émission d’un PID, le WB (Wallet Backend) confirme auprès du PP (Provider Party), via OpenID4VCI Key Attestation, que cette clé est contrôlée par un moyen d’authentification offrant un certain niveau de résistance aux attaques
• Conformément à ISO/IEC 18045 et au règlement UE 2015/1502, la vérification d’identité électronique à haut niveau d’assurance exige des moyens d’authentification robustes
• Les moyens d’authentification apportent deux garanties
  1. Protection contre la copie et la falsification du magasin de clés
  2. Protection contre les attaques visant le mécanisme d’authentification utilisateur
• La première garantie peut être mise en œuvre avec un RWSCD fondé sur un HSM, indépendamment de l’appareil utilisateur
• La seconde dépend de la sécurité de l’appareil utilisateur et se compose d’un facteur de possession (fondé sur le HKS) et d’un facteur de connaissance (mot de passe, etc.)
• En pratique, il est impossible d’effectuer à l’avance une analyse de vulnérabilité et une certification du HKS ou de l’OS des appareils mobiles, et de nombreuses vulnérabilités ont déjà été signalées par le passé
• D’où l’usage d’un dispositif de surveillance des vulnérabilités en exploitation (MDVM) pour réduire la possibilité d’attaque et bloquer l’usage des clés RWSCA/RWSCD sur les appareils dont la sécurité est insuffisante

---

Fonctions principales du MDVM

Fonction	Description
Vérification de l’état de sécurité de l’appareil/de l’application	Vérifie l’intégrité et l’authenticité de l’appareil et de l’application Wallet en s’appuyant sur les fonctions de sécurité de la plateforme et sur RASP (Runtime Application Self-Protection)
Identification de la classe d’appareil	Identifie de manière vérifiée le modèle d’appareil, la version de l’OS, le niveau de patch et les informations HKS
Vérification des vulnérabilités par classe d’appareil	Contrôle les informations de vulnérabilités les plus récentes concernant l’OS et le HKS
Décision d’usage de l’appareil/de l’application	Sur la base de l’état de sécurité et des informations de vulnérabilité, bloque la validation de OpenID4VCI Key Attestation et l’usage des clés RWSCD sur les appareils dont la sécurité est insuffisante

---

Signaux collectés

• Les signaux collectés servent à la réponse aux menaces, à l’identification de la classe d’appareil et à la vérification de plausibilité (plausibility check)

• Principales sources de signaux : KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

• Vue d’ensemble

  Source de signal	Menaces traitées	Synergie	Remarques
  KeyAttestation	Root, déverrouillage du bootloader, ROM personnalisée, altération d’application, clonage, émulation, attaque par rejeu, etc.	LPADB, RASP	Utilisé comme entrée pour DCVDB
  PlayIntegrity	Altération d’application, rejeu, root, ROM personnalisée, décision MDVM fondée sur le backend Google, outils de vol d’identifiants, attaques par overlay, etc.	KeyAttestation, RASP	Vérification de l’état du bootloader nécessaire
  iOS DeviceCheck	Rejeu, falsification de certificats, attaques par proxy, altération d’application	RASP	Garanties limitées sur l’intégrité de l’appareil
  LPADB	Masquage du root au moyen de clés KeyAttestation publiquement divulguées	KeyAttestation	-
  DCVDB	Détection d’appareils non sûrs sur la base de vulnérabilités connues	KeyAttestation, RASP	La précision de l’identification de la classe d’appareil est essentielle
  RASP	Détection du hooking d’application, du débogage, du root et de l’émulation	-	Surveillance continue de l’intégrité à l’exécution

  ---

Signal Android KeyAttestation

• Les informations de vérification matérielle fondées sur le HKS permettent d’identifier le modèle d’appareil, la version de l’OS, le niveau de patch, l’état du bootloader, etc.
• Principaux éléments du signal
  • SecurityLevel : identification du type de HKS (TrustedEnvironment, StrongBox)
  • attestationIdModel/Product/Device : identification du modèle d’appareil
  • osVersion / osPatchLevel : version de l’OS et niveau de patch de sécurité
  • RootOfTrust : état du bootloader et de Verified Boot
  • AttestationApplicationId : nom du package applicatif, version, hash du certificat de signature
• La liste de révocation des certificats de Key-Attestation de Google étant mise à jour lentement, des clés divulguées publiquement peuvent encore être utilisées
• Certains champs d’identification peuvent manquer sur certains appareils, ce qui impose d’évaluer les trois champs ensemble

---

Signal Android PlayIntegrity Verdict

• Vérification de l’intégrité de l’application et de l’appareil via Google Play Integrity API
• Principaux éléments du signal
  • appRecognitionVerdict : indique si l’application est authentique
  • deviceRecognitionVerdict : niveau de confiance de l’appareil (par ex. MEETS_STRONG_INTEGRITY)
  • appLicensingVerdict : indique si l’installation provient du PlayStore
  • playProtectVerdict : évaluation du risque par Play Protect
• MEETS_STRONG_INTEGRITY impose l’application d’un patch de sécurité au cours des 12 derniers mois
• Pour garantir la fiabilité du signal, une vérification de signature et un déchiffrement sont nécessaires
• Le mode d’évaluation interne du backend de Google n’est pas public

---

Android RASP

• La solution concrète n’est pas encore arrêtée ; le projet en est au stade de définition des fonctions requises
• Fonctions de détection
  • App Hooking/Debugging : détection des manipulations dynamiques (Frida, Xposed, etc.)
  • App Repackaging/Tampering : détection de l’altération et de la re-signature de l’application
  • UD Rooting/Emulation : détection du root, de la virtualisation et des environnements d’automatisation
• RASP assure une surveillance de l’intégrité à l’exécution et maintient une blocklist distincte de la liste de révocation de Google afin d’empêcher les attaques fondées sur des clés divulguées

---

iOS DCDeviceCheck.AppAttest Attestation

• Architecture d’authentification applicative reposant sur la Secure Enclave et les serveurs d’Apple
• Principaux signaux
  • attestationObject : prouve que la clé App Attest a été générée dans la Secure Enclave
  • credentialId : identifiant de la clé App Attest
  • RP ID : préfixe App ID de l’application + Bundle ID
• L’indicateur de risque d’Apple (receipt metric) peut servir à détecter des attaques par proxy, mais l’absence de critères explicites et le risque d’exposition de données personnelles lié aux communications avec les serveurs d’Apple demeurent
• iOS ne permet pas de fournir des informations matérielles sur le modèle d’appareil, la version de l’OS ou le niveau de patch ; ces éléments ne peuvent être vérifiés que via des requêtes à l’OS

---

iOS DCDeviceCheck.AppAttest Assertions

• Structure de vérification par signature générée avec une clé App Attest
• Principaux signaux
  • assertionObject : contient une signature du challenge
  • keyId : identifiant de la clé App Attest
  • counter : nombre de signatures, qui doit augmenter de façon monotone
• Une hausse brutale de la valeur du compteur peut indiquer une attaque par proxy, tandis qu’une baisse peut indiquer une attaque par rejeu

---

iOS RASP

• Exigences de détection similaires à Android
  • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
• Le bac à sable applicatif (App Sandbox), la signature de code (Code Signing) et la System Integrity Protection d’Apple n’offrent qu’une protection au moment de l’installation et ne proposent pas de détection du root, du hooking ni de la manipulation à l’exécution
• RASP complète ce dispositif par une surveillance de l’intégrité pendant l’exécution
• Selon la documentation d’Apple, App Attest précise qu’« une application altérée s’exécutant sur un appareil légitime ne peut pas générer une assertion valide »

---

Conclusion

• Le MDVM évalue en temps réel l’état de sécurité des appareils et bloque l’usage des clés d’authentification dans les environnements à fort risque d’attaque, afin de préserver la fiabilité du système d’authentification d’identité électronique
• Sur Android comme sur iOS, le système combine les fonctions de sécurité de la plateforme et une protection dynamique fondée sur RASP pour constituer un dispositif de vérification de l’intégrité des appareils
• Il existe une dépendance aux mécanismes de vérification backend de Google et d’Apple, et leurs méthodes d’évaluation internes non publiques restent une source potentielle d’incertitude