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

 (bmi.usercontent.opencode.de)
1 points par GN⁺ 29 일 전 | 1 commentaires | Partager sur WhatsApp
  • 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

À lire aussi

1 commentaires

 
GN⁺ 29 일 전
Avis Hacker News

  • La spécification eIDAS 2.0 n’exige aucun matériel spécifique
    C’est simplement une structure destinée à stocker des justificatifs vérifiables et des certificats signés cryptographiquement
    Cela ressemble à de la paresse de la part de l’équipe d’implémentation allemande, qui chercherait à contourner la clause disant qu’« un mécanisme permettant à l’utilisateur de vérifier l’authenticité de la Wallet Unit doit être implémenté »
    La documentation associée est disponible dans EUDI Architecture and Reference Framework

    • En regardant l’implémentation de référence, on voit que les mainteneurs ne veulent pas supprimer la dépendance à Google
      La raison n’est pas claire, mais quand quelque chose perdure sans raison apparente, c’est qu’il y en a généralement une
      Voir le dépôt GitHub
    • Les règles concernées sont précisées dans la section 5.4, sur les Attestation Rulebooks et les Attestation Schemes

  • En tant qu’implémenteur allemand, je dois utiliser un mécanisme d’attestation conformément au règlement d’exécution eIDAS
    Cela ne fonctionne pas sans prise en charge du système d’exploitation
    Je sais que le fait d’être actuellement limité à Google/Android n’est pas idéal, et le support d’autres OS comme GrapheneOS est aussi prévu
    Pour l’instant, c’est simplement une question de priorité, pas un manque de conscience du problème

    • Dépendre des produits de deux entreprises américaines n’est pas seulement « pas idéal », c’est un problème grave
      Les cas de verrouillage de compte sont nombreux, et il vaudrait mieux éviter complètement ce type de dépendance
    • Il y a aussi des éléments potentiellement illégaux au regard de l’accessibilité et de l’esprit d’eIDAS
      Au final, tous les citoyens se retrouvent soumis aux conditions de Google et d’Apple, et une suspension de compte peut bloquer l’accès au service eID
      Comme il existe des alternatives techniques, c’est votre responsabilité de chercher une solution de ce type
    • En tant que citoyen allemand, j’aimerais demander : pourquoi avancer alors que vous savez que cela ne fonctionnera pas pour tous les citoyens ?
      J’ai quitté Android basé sur AOSP sans Google Play pour Ubuntu Touch, et je prévois ensuite de passer à postmarketOS
    • Il est beaucoup trop facile de perdre l’accès à un compte Google. Et le récupérer est impossible
      Compte tenu de ce genre de situation et des risques géopolitiques, une dépendance envers une entreprise précise ne peut pas être justifiée
      Il y a aussi cette leçon de développeur : « rien n’est plus permanent qu’une solution temporaire »
    • Je me demande pourquoi on remplace par un modèle Wallet un problème déjà résolu avec le Mobile-ID d’eIDAS 1 (basé sur la SIM) ou Smart-ID (gestion des clés côté serveur)
      Il n’y a aucune raison de dépendre des backends de deux entreprises américaines

  • Il faudrait abolir l’attestation elle-même
    Une application ne devrait pas savoir sur quel appareil elle s’exécute
    L’utilisateur peut protéger lui-même son appareil, et il suffit aux développeurs de formuler des recommandations
    Cela devrait pouvoir fonctionner sur GrapheneOS, sur des appareils rootés, sur émulateur, avec une couche de compatibilité Linux, bref dans n’importe quel environnement

    • Exactement, c’est mon appareil, je devrais pouvoir l’utiliser comme je veux
      Il est inutile qu’une application vérifie automatiquement si elle est « certifiée » par une big tech américaine
    • La notion même de confiance dans l’appareil est une illusion
      L’histoire des consoles et des téléphones rootés montre qu’aucune sécurité n’est parfaite
      Le mieux serait d’en faire une option facultative, permettant à l’utilisateur de lier son identité à son appareil s’il le souhaite
    • Bien sûr, chacun est libre de rooter ou modifier son appareil, mais il faut alors en assumer les conséquences
      Si l’application ne peut pas vérifier sa propre intégrité, certaines fonctions deviennent impossibles du point de vue de la sécurité
      De la même façon qu’une pièce d’identité physique a des contraintes de forme ou de taille, certaines limites sont nécessaires
    • Le péché originel de l’informatique moderne, c’est que les « éléments de sécurité » ont été conçus pour les fabricants plutôt que pour les utilisateurs
      Le problème a commencé à l’époque de NGSCB, quand ces éléments n’ont pas été interdits par la loi

  • Que se passe-t-il si l’on perd son compte Google/Apple ?
    Si l’on devient visé par des sanctions, comme les juges de la Cour pénale internationale, l’accès à eIDAS devient impossible
    Le fait que la société européenne reste aussi dépendante d’entreprises américaines est une réalité contradictoire

    • Même sans être une personnalité connue, on peut se retrouver exclu socialement à cause d’une suspension automatisée de compte
      Il est dangereux que deux entreprises étrangères disposent d’un tel pouvoir de surveillance et de contrôle
    • Si « la capitale de l’Europe est à Washington », alors ce genre de chose est peut-être normal
    • Dans ce cas, impossible aussi de prendre un Waymo

  • Le peu d’opposition publique à ce genre de politique est choquant
    En tant que parent, je comprends la nécessité de contrôler l’usage d’Internet par les enfants,
    mais au final l’État se substitue à ce que devraient faire les parents, et on perd en liberté et en vie privée

    • La plupart des gens ne comprennent que de manière abstraite l’impact concret que cela a sur leur vie
      Tant que la menace n’est pas formulée aussi clairement que « le gouvernement lit mes messages WhatsApp », ils ne réagissent pas
    • En Allemagne, l’attention est détournée par des polémiques stériles comme le débat sur la limitation de vitesse
      La classe politique profite de cette confusion pour masquer les vrais problèmes
    • Beaucoup de parents sont au contraire favorables à la restriction de l’accès en ligne
      Ils veulent protéger leurs enfants de l’exploitation de leur attention par les grandes entreprises
      S’il existe des restrictions d’âge dans le monde réel, il n’y a pas de raison qu’Internet y échappe
    • Les gens sont enfermés dans leur propre bulle de filtres et n’entendent même pas parler de ces sujets
      C’est extrêmement inquiétant pour l’avenir de la démocratie
    • L’UE fonctionne en pratique comme une plateforme de lobbying
      Le lobbying citoyen est possible, mais il exige des coûts et de la coordination, ce qui laisse l’avantage aux grandes entreprises
      Il y a aussi eu récemment un incident où l’infrastructure numérique de l’UE a été compromise par un groupe de hackers
      Article lié

  • Exiger un matériel ou un logiciel spécifique est déraisonnable
    Tous les citoyens devraient pouvoir utiliser l’ordinateur de leur choix
    Une authentification par mot de passe ou paire de clés suffit, avec éventuellement du TOTP ou une clé de sécurité en plus
    On dirait qu’ils ont oublié qu’il existe aussi des ordinateurs autres que les smartphones

    • L’UE veut créer un système de paiement indépendant de VISA et MasterCard, mais au final il reste dépendant des app stores
      Sans compte Apple ou Google, impossible même de payer en euro numérique
      Ce qui surprend, c’est l’incapacité des politiques et des banques à regarder deux ou trois étapes plus loin
    • La politique de l’UE ne va pas dans le sens d’une « évaluation autonome du risque par l’utilisateur »,
      mais plutôt de l’idée que le fournisseur de service doit protéger l’utilisateur
      Au final, cela rend inévitable la limitation des plateformes prises en charge
    • Dire que « cela doit fonctionner sur tous les ordinateurs » est irréaliste
      Cela ne veut pas dire juridiquement qu’il faut aussi le faire tourner sur un Apple II

  • Les personnes sanctionnées ou certains groupes peuvent ne pas avoir accès au Play Store,
    ce qui peut rendre impossible l’installation même de l’application eIDAS

    • S’il faut un compte, alors oui.
      Quand on voit les récents cas de suppression de comptes d’opposants politiques, certaines autorités pourraient même s’en réjouir
    • Mais la protection de la clé privée est l’enjeu central
      Un dispositif de sécurité comme une carte à puce est nécessaire, donc un environnement totalement ouvert est risqué
      Je comprends le souhait d’utiliser un « Android alternatif », mais il faut alors admettre qu’il s’agit d’un environnement non sécurisé

  • Je me demande combien de budget l’UE va encore gaspiller dans ce genre de système
    Je ne vois vraiment pas qui en a besoin

  • Seule la Self Sovereign Identity (SSI) est une vraie solution
    L’identité d’une personne ne devrait dépendre d’aucune institution ni d’aucune entreprise
    L’identité devrait simplement être « moi-même »
    Ce qu’il faut, ce n’est ni un Google ID ni un Apple ID, mais une identité auto-souveraine

    • Mais dire « je suis simplement moi » ne constitue pas une vérification d’identité réaliste
      On ne peut pas répondre ça dans un bar à la place de montrer sa pièce d’identité
      Dans le cadre du contrat social, une vérification d’identité fonctionnelle reste nécessaire
    • L’UE a déjà créé en 2019 ESSIF (European Self-Sovereign Identity Framework)
      L’infrastructure existe donc depuis sept ans, on ne peut pas dire que les gouvernements sont simplement incompétents

  • On dirait qu’il est temps pour un « incendie numérique du Reichstag »
    J’aimerais vraiment savoir quand l’Allemagne cessera de répéter l’histoire