Qu'est-ce que l'attestation dans WebAuthn ?

L'attestation peut faire référence à trois choses (souvent utilisées de manière interchangeable dans le langage courant, bien qu'elles aient des significations différentes si on les prend au sens strict) :

1. Premièrement et de manière plus générale, l'attestation dans le domaine de la cryptographie est un terme par lequel une partie « atteste » cryptographiquement une déclaration à une autre partie.

2. Deuxièmement, pendant la phase d'enregistrement dans WebAuthn, un objet d'attestation est créé par l'authenticator et renvoyé à la Relying Party. C'est un objet conteneur qui contient les informations suivantes :

   • format de la déclaration d'attestation (fmt)
   • déclaration d'attestation (attStmt - voir ci-dessous)
   • données de l'authenticator (authData)

3. Troisièmement, dans WebAuthn, une déclaration d'attestation est un élément facultatif de l'objet d'attestation. Cette déclaration, lorsqu'elle est incluse, vérifie certaines caractéristiques de l'authenticator (appareil) impliqué dans le processus d'attestation. Cependant, certains fabricants d'appareils (par exemple, Apple) n'offrent pas de déclaration d'attestation car cet aspect de la spécification n'était pas destiné à la synchronisation des passkeys et ne parvient pas à vérifier efficacement les attributs de sécurité lorsque les informations d'identification peuvent être synchronisées sur différents appareils (par exemple, un passkey est créé sur un iPhone mais également utilisé sur un MacBook car il est synchronisé via le même Trousseau iCloud). Caractéristiques qui peuvent être fournies lorsque la déclaration d'attestation est présente :

   • Fournir la preuve qu'un appareil authentique et de confiance a été utilisé lors de l'authentification.
   • Fournir des détails sur l'origine de l'appareil, son modèle et d'autres informations pertinentes.
   • Renforcer les mesures de sécurité, en particulier dans les scénarios où la fiabilité de l'appareil est cruciale (par exemple, dans certains secteurs réglementés comme la santé).

Le flux de processus d'enregistrement suivant montre le rôle de l'attestation (objet) dans WebAuthn :

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

Dans la capture d'écran ci-dessus, aucun AAGUID et aucune déclaration d'attestation ne sont fournis.

Expérimentez les parcours passkey dans le Passkeys Debugger.

Essayer gratuitement

Poursuivez votre lecture pour une analyse technique des attributs les plus importants.

Dans WebAuthn, l'attestation garantit que l'authentification de l'utilisateur est sécurisée et transparente. Avec la déclaration d'attestation, vous pouvez vous assurer qu'un identifiant a été créé sur un authenticator / appareil spécifique.

Ces types d'attestation font référence à la déclaration d'attestation (et non à l'objet d'attestation). Ils sont considérés comme une préférence par la relying party (l'authenticator peut donc se comporter différemment car il ne s'agit que d'une préférence).

• Aucune attestation (none) : Pour les cas où la confidentialité est une préoccupation majeure ou lorsque des appareils synchronisés sont utilisés, ce type ne fournit aucune information sur l'appareil, garantissant ainsi la protection de la vie privée de l'utilisateur. Une autre raison d'utiliser cette valeur pourrait être d'économiser un aller-retour vers une autorité de certification (AC). none est également la valeur par défaut.
• Attestation indirecte (indirect) : La relying party préfère obtenir une attestation mais permet au client de décider comment obtenir les déclarations d'attestation. Le client peut remplacer les déclarations d'attestation générées par l'authentificateur par des déclarations d'attestation anonymes pour protéger la vie privée de l'utilisateur.
• Attestation directe (direct) : C'est la forme la plus transparente. Ici, la relying party indique à l'authentificateur qu'elle souhaite une déclaration d'attestation, afin que la relying party obtienne des informations détaillées sur l'appareil, y compris sa marque, son modèle et d'autres spécificités. Bien qu'elle offre la plus grande transparence, elle peut soulever des problèmes de confidentialité dans certains scénarios ou ne pas être réellement utilisable pour les identifiants synchronisés.
• Attestation d'entreprise (enterprise) : La relying party souhaite recevoir une déclaration d'attestation pouvant inclure des informations d'identification uniques. Ce type d'attestation est généralement utilisé dans les entreprises ou les organisations qui souhaitent suivre des appareils / authenticators spécifiques. Les navigateurs web (agents utilisateurs) ne devraient pas fournir cette attestation détaillée à moins que leurs paramètres ne l'autorisent spécifiquement pour la partie requérante. Si les paramètres le permettent, le navigateur doit indiquer à l'appareil au début du processus que ce type spécifique d'attestation est demandé. Le navigateur doit ensuite transmettre l'ID unique de l'appareil et la preuve d'attestation exactement tels qu'il les reçoit à la relying party.

Abonnez-vous à notre Substack passkeys pour les dernières actualités.

S'abonner

L'objet d'attestation contient de nombreux attributs, voici une explication rapide de certains attributs sélectionnés :

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

L'attestationObject est un objet encodé en CBOR, contenant des informations sur les nouveaux identifiants créés, la clé publique et d'autres données pertinentes :

• fmt représente le format d'attestation, car les authenticators peuvent fournir des données d'attestation de différentes manières. Il indique au serveur comment il doit valider les données d'attestation. Les valeurs autorisées sont "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" ou "none". Voir les détails ici
• attStmt est la déclaration d'attestation. Pour les passkeys, par exemple sur les appareils iOS ou Android, elle est laissée vide car les passkeys sur iOS ou Android peuvent être synchronisés, et remplie pour d'autres appareils tels que sur Windows ou les clés de sécurité matérielles.
• authData est un tampon de valeurs contenant les données suivantes :
  
  Les données d'identifiant attestées jouent un rôle important ici. Elles contiennent :
  • AAGUID,
  • Longueur de l'ID de l'identifiant,
  • ID de l'identifiant et
  • Clé publique de l'identifiant.

Contrairement à l'objet d'attestation ci-dessus où attStmt a été laissé vide pour des raisons de lisibilité, voici à quoi ressemblerait une déclaration d'attestation remplie.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: La propriété alg indique l'identifiant de l'algorithme cryptographique utilisé par l'authentificateur pour signer la déclaration d'attestation.
• sig: La propriété sig contient la signature numérique générée par l'authentificateur. Cette signature est utilisée pour vérifier l'authenticité de la déclaration d'attestation.
• ver: La propriété ver spécifie la version du format de la déclaration d'attestation.
• x5c: Le tableau x5c contient un ou plusieurs certificats X.509 qui forment un chemin de certification, ce qui aide à valider l'attestation.
• pubArea: La propriété pubArea contient des informations détaillées sur la clé publique et les caractéristiques de l'authenticator.
• certInfo: La propriété certInfo inclut généralement des informations sur la certification de l'authentificateur par une partie de confiance.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

Pour en savoir plus sur clientDataJSON, consultez l'article de glossaire correspondant.

"transports": [
        "hybrid",
        "internal"
      ]

La propriété transports indique les mécanismes par lesquels un authentificateur peut communiquer avec un client. Voici quelques combinaisons de valeurs courantes :

• "transports": ["internal","hybrid"]: Les passkeys peuvent être utilisés depuis l'authentificateur de plateforme (par ex. Face ID, Touch ID, Windows Hello) ou via l'authentification inter-appareils (en utilisant un code QR & Bluetooth).
• "transports": ["internal"]: Les passkeys peuvent être utilisés depuis l'authentificateur de plateforme (par ex. Face ID, Touch ID, Windows Hello)
• Aucune propriété transports définie : comportement par défaut qui ne donne aucune indication.

L'attestation (la déclaration d'attestation) dans WebAuthn est importante car elle offre une preuve de l'authenticité d'un authenticator. Elle garantit que le processus d'authentification est effectué par un appareil de confiance, protégeant ainsi contre les menaces de sécurité potentielles.

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Oui, comme les passkeys peuvent être synchronisés entre les appareils (par exemple, d'un iPhone à un MacBook via le Trousseau), les relying parties ne peuvent plus vraiment déterminer quel appareil attesté se connecte réellement à une application ou un site web. Par conséquent, Apple et Google ont décidé que pour les passkeys synchronisés, ils ne fourniraient plus de déclarations d'attestation. Cependant, pour améliorer l'UX pour les relying parties et leur donner la possibilité de reconnaître et d'afficher les passkeys des écosystèmes Apple et Google (Trousseau iCloud et Gestionnaire de mots de passe Google), l'AAGUID sera toujours fourni (tant que l'attestation est définie sur direct ou indirect dans les paramètres du serveur WebAuthn pour les PublicKeyCredentialCreationOptions. Voir ce problème GitHub pour plus de détails.

Si vous souhaitez intégrer l'authentification par passkey dans votre site web et votre application, et offrir à vos utilisateurs une excellente expérience utilisateur avec les passkeys, vous devriez considérer ce qui suit. Nous supposons que vous construisez votre solution principalement pour un scénario où la plupart de vos utilisateurs utilisent un système d'exploitation Windows, iOS, macOS ou Android. De plus, nous supposons que la plupart des passkeys (à l'exception de Windows) sont des passkeys synchronisés. Comme ni iOS, ni macOS, ni Android n'envoient plus de déclaration d'attestation, la validation réelle d'un authentificateur n'est plus utilisée (pour Windows, cela fonctionne toujours, probablement parce que Windows n'offre pas encore de passkeys synchronisés via Windows Hello). Cependant, pour obtenir l'AAGUID, par exemple pour une meilleure gestion des passkeys dans les paramètres du compte, nous recommandons de définir la préférence d'attestation sur indirect, car cela permettrait toujours d'obtenir l'AAGUID tandis que la déclaration d'attestation est soit envoyée (Windows), soit non envoyée (iOS, macOS, Android).

Le service de métadonnées FIDO fournit un référentiel de métadonnées pour divers authenticators. Lors de l'attestation, ce service peut être interrogé pour récupérer et valider les détails de l'authenticator, garantissant ainsi l'exactitude et renforçant la fiabilité du processus. Le service de métadonnées FIDO vérifie la déclaration d'attestation (et non l'objet d'attestation).

Oui, l'attestation directe (dans la déclaration d'attestation), bien qu'offrant la plus grande transparence en fournissant des informations détaillées sur l'appareil, peut soulever des préoccupations de confidentialité dans certains scénarios. Il est crucial d'évaluer le besoin de transparence par rapport à la confidentialité lors du choix du type d'attestation.

WebAuthn offre différents types de préférences d'attestation – aucune, indirecte, directe et d'entreprise. Pour les scénarios où la confidentialité de l'utilisateur est importante, attestation=none peut être utilisé, ce qui ne fournit aucun détail sur l'appareil, garantissant que la vie privée de l'utilisateur reste protégée.

À propos de Corbado

Corbado est la Passkey Intelligence Platform pour les équipes CIAM qui gèrent l'authentification client à grande échelle. Nous vous montrons ce que les logs IDP et les outils d'analytics génériques ne voient pas : quels appareils, versions d'OS, navigateurs et gestionnaires de credentials prennent en charge les passkeys, pourquoi les enrôlements ne deviennent pas des connexions, où le flux WebAuthn échoue et quand une mise à jour OS ou navigateur casse silencieusement la connexion — le tout sans remplacer Okta, Auth0, Ping, Cognito ni votre IDP interne. Deux produits : Corbado Observe ajoute l'observabilité pour les passkeys et toute autre méthode de connexion. Corbado Connect apporte des passkeys managés avec analytics intégrés (aux côtés de votre IDP). VicRoads gère les passkeys pour plus de 5M d'utilisateurs avec Corbado (+80 % d'activation passkey). Parler à un expert Passkey →