Was ist Attestation in WebAuthn?

Attestation kann sich auf drei Dinge beziehen (oft werden die Begriffe umgangssprachlich austauschbar verwendet, obwohl sie bei genauer Betrachtung unterschiedliche Bedeutungen haben):

1. Erstens und allgemeiner ist Attestation im kryptografischen Bereich ein Begriff, bei dem eine Partei einer anderen Partei eine Aussage kryptografisch „bescheinigt“.

2. Zweitens wird während der Registrierungsphase in WebAuthn ein Attestation-Objekt vom Authenticator erstellt und an die Relying Party zurückgegeben. Es ist ein Container-Objekt, das die folgenden Informationen enthält:

   • Attestation Statement Format (fmt)
   • Attestation Statement (attStmt - siehe unten)
   • Authenticator-Daten (authData)

Become part of our Passkeys Community for updates & support.

Join

3. Drittens ist in WebAuthn ein Attestation Statement ein optionales Element des Attestation-Objekts. Dieses Statement verifiziert, sofern es enthalten ist, bestimmte Eigenschaften des am Attestation-Prozess beteiligten Authenticators (Geräts). Einige Gerätehersteller (z. B. Apple) bieten jedoch kein Attestation Statement an, da dieser Aspekt der Spezifikation nicht für die Passkey-Synchronisierung vorgesehen war und die Sicherheitsattribute nicht effektiv überprüft werden können, wenn Anmeldeinformationen über verschiedene Geräte hinweg synchronisiert werden können (z. B. wird ein Passkey auf einem iPhone erstellt, aber auch auf einem MacBook verwendet, da er über denselben iCloud-Schlüsselbund synchronisiert wird). Eigenschaften, die angegeben werden können, wenn das Attestation Statement bereitgestellt wird:
   • Beweis dafür liefern, dass während der Authentifizierung ein echtes und vertrauenswürdiges Gerät verwendet wurde.
   • Details über Herkunft, Modell und andere relevante Informationen des Geräts bereitstellen.
   • Sicherheitsmaßnahmen verbessern, insbesondere in Szenarien, in denen die Vertrauenswürdigkeit des Geräts entscheidend ist (z. B. in bestimmten regulierten Branchen wie dem Gesundheitswesen).

Der folgende Prozessablauf der Registrierung zeigt die Rolle der Attestation (des Objekts) in 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"
    }
}

Im obigen Screenshot werden keine AAGUID und kein Attestation Statement bereitgestellt.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Lesen Sie weiter für eine technische Aufschlüsselung der wichtigsten Attribute.

In WebAuthn stellt die Attestation sicher, dass die Benutzerauthentifizierung sicher und transparent ist. Mit dem Attestation Statement können Sie sicherstellen, dass eine Anmeldeinformation auf einem bestimmten Authenticator / Gerät erstellt wurde.

Diese Arten der Attestation beziehen sich auf das Attestation Statement (nicht auf das Attestation-Objekt). Sie werden von der Relying Party als Präferenz betrachtet (der Authenticator kann sich also anders verhalten, da es sich nur um eine Präferenz handelt).

• Keine Attestation (none): In Fällen, in denen der Datenschutz von größter Bedeutung ist oder synchronisierte Geräte im Spiel sind, liefert dieser Typ keine Informationen über das Gerät und stellt so die Privatsphäre des Benutzers sicher. Ein weiterer Grund für die Verwendung dieses Werts könnte sein, den Roundtrip zu einer Zertifizierungsstelle (CA) zu sparen. none ist auch der Standardwert.
• Indirekte Attestation (indirect): Die Relying Party bevorzugt eine Attestation, überlässt es aber dem Client, wie er die Attestation Statements erhält. Der Client kann die vom Authenticator generierten Attestation Statements durch anonyme Attestation Statements ersetzen, um die Privatsphäre des Benutzers zu schützen.
• Direkte Attestation (direct): Dies ist die transparenteste Form. Hier teilt die Relying Party dem Authenticator mit, dass sie ein Attestation Statement wünscht, sodass die Relying Party detaillierte Informationen über das Gerät erhält, einschließlich Marke, Modell und anderer Besonderheiten. Obwohl dies die höchste Transparenz bietet, kann es in bestimmten Szenarien Datenschutzbedenken aufwerfen oder für synchronisierte Anmeldeinformationen nicht wirklich nutzbar sein.
• Unternehmens-Attestation (enterprise): Die Relying Party möchte ein Attestation Statement erhalten, das eindeutige identifizierende Informationen enthalten kann. Diese Art der Attestation wird typischerweise in Unternehmen oder Organisationen verwendet, die bestimmte Geräte / Authenticators nachverfolgen möchten. Webbrowser (User Agents) sollten diese detaillierte Attestation nicht bereitstellen, es sei denn, ihre Einstellungen erlauben dies speziell für die anfragende Partei. Wenn die Einstellungen dies zulassen, sollte der Browser dem Gerät bei Bedarf (zu Beginn des Prozesses) mitteilen, dass diese spezielle Art der Attestation angefordert wird. Der Browser sollte dann die eindeutige ID des Geräts und den Attestation-Nachweis genau so, wie er sie erhält, an die Relying Party weitergeben.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Das Attestation-Objekt enthält viele Attribute, hier ist eine kurze Erklärung einiger ausgewählter Attribute:

"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"
          }
        }

Das attestationObject ist ein CBOR-kodiertes Objekt, das Informationen über die neu erstellten Anmeldeinformationen, den öffentlichen Schlüssel und andere relevante Daten enthält:

• fmt repräsentiert das Attestation-Format, da Authenticators Attestation-Daten auf unterschiedliche Weise bereitstellen können. Es teilt dem Server mit, wie er die Attestation-Daten validieren soll. Erlaubte Werte sind „packed“, „tpm“, „android-key“, „android-safetynet“, „fido-u2f“, „apple“ oder „none“. Details finden Sie hier
• attStmt ist das Attestation Statement. Bei Passkeys, z. B. auf iOS- oder Android-Geräten, wird es leer gelassen, da Passkeys auf iOS oder Android synchronisiert werden können, und für andere Geräte wie Windows oder Hardware-Sicherheitsschlüssel ausgefüllt.
• authData ist ein Puffer von Werten, der die folgenden Daten enthält:
  
  Die attested credential data spielen hier eine wichtige Rolle. Sie enthalten:
  • AAGUID,
  • Länge der Credential ID,
  • Credential ID und
  • Öffentlicher Schlüssel der Anmeldeinformation.

Im Gegensatz zum obigen Attestation-Objekt, bei dem attStmt aus Gründen der Lesbarkeit leer gelassen wurde, würde ein ausgefülltes Attestation Statement so aussehen.

{
    "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: Die Eigenschaft alg gibt den kryptografischen Algorithmus-Identifikator an, der vom Authenticator zum Signieren des Attestation Statements verwendet wird.
• sig: Die Eigenschaft sig enthält die vom Authenticator generierte digitale Signatur. Diese Signatur wird verwendet, um die Authentizität des Attestation Statements zu überprüfen.
• ver: Die Eigenschaft ver gibt die Version des Attestation Statement-Formats an.
• x5c: Das x5c-Array enthält ein oder mehrere X.509-Zertifikate, die einen Zertifizierungspfad bilden, der bei der Validierung der Attestation hilft.
• pubArea: Die Eigenschaft pubArea enthält detaillierte Informationen über den öffentlichen Schlüssel und die Eigenschaften des Authenticators.
• certInfo: Die Eigenschaft certInfo enthält typischerweise Informationen über die Zertifizierung des Authenticators durch eine vertrauenswürdige Partei.

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

Lesen Sie mehr über clientDataJSON im entsprechenden Glossarartikel.

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

Die transports-Eigenschaft gibt Mechanismen an, über die ein Authenticator mit einem Client kommunizieren kann. Einige gängige Beispiel-Wertkombinationen sind:

• "transports": ["internal","hybrid"]: Passkeys können vom Plattform-Authenticator (z. B. Face ID, Touch ID, Windows Hello) oder über die geräteübergreifende Authentifizierung (mittels QR-Code & Bluetooth) verwendet werden.
• "transports": ["internal"]: Passkeys können vom Plattform-Authenticator (z. B. Face ID, Touch ID, Windows Hello) verwendet werden.
• Keine transports-Eigenschaft gesetzt: Standardverhalten, das keine Hinweise gibt.

Die Attestation (das Attestation Statement) in WebAuthn ist wichtig, da sie einen Nachweis über die Echtheit eines Authenticators bietet. Sie stellt sicher, dass der Authentifizierungsprozess von einem vertrauenswürdigen Gerät durchgeführt wird, und schützt so vor potenziellen Sicherheitsbedrohungen.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

3,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

Ja, da Passkeys über Geräte hinweg synchronisiert werden können (z. B. vom iPhone zum MacBook über den Schlüsselbund), können Relying Parties nicht mehr wirklich feststellen, welches attestierte Gerät sich tatsächlich in eine App oder auf einer Website anmeldet. Daher haben Apple und Google entschieden, für synchronisierte Passkeys keine Attestation Statements mehr bereitzustellen. Um jedoch die UX für Relying Parties zu verbessern und ihnen die Möglichkeit zu geben, Passkeys aus dem Apple- und Google-Ökosystem (iCloud-Schlüsselbund und Google Passwortmanager) zu erkennen und anzuzeigen, wird die AAGUID weiterhin bereitgestellt (solange die Attestation in den WebAuthn-Servereinstellungen für die PublicKeyCredentialCreationOptions auf direct oder indirect gesetzt ist). Siehe dieses GitHub-Issue für Details.

Wenn Sie die Passkey-Authentifizierung in Ihre Website und App integrieren und Ihren Benutzern eine großartige Passkey-UX bieten möchten, sollten Sie Folgendes beachten. Wir gehen davon aus, dass Sie Ihre Lösung hauptsächlich für ein Szenario entwickeln, in dem die meisten Ihrer Benutzer ein Windows-, iOS-, macOS- oder Android-Betriebssystem verwenden. Außerdem gehen wir davon aus, dass die meisten Passkeys (außer bei Windows) synchronisierte Passkeys sind. Da weder iOS, macOS noch Android ein Attestation Statement mehr senden, wird die eigentliche Validierung eines Authenticators nicht mehr verwendet (für Windows funktioniert dies noch, wahrscheinlich weil Windows noch keine synchronisierten Passkeys über Windows Hello anbietet). Um jedoch die AAGUID zu erhalten, z. B. für eine bessere Passkey-Verwaltung in den Kontoeinstellungen, empfehlen wir, die Attestation-Präferenz auf indirect zu setzen, da dies immer noch ermöglicht, die AAGUID zu erhalten, während das Attestation Statement entweder gesendet (Windows) oder nicht gesendet wird (iOS, macOS, Android).

Der FIDO-Metadatendienst stellt ein Repository mit Metadaten für verschiedene Authenticators bereit. Während der Attestation kann dieser Dienst abgefragt werden, um Details über den Authenticator abzurufen und zu validieren, was die Genauigkeit sicherstellt und die Vertrauenswürdigkeit des Prozesses erhöht. Der FIDO-Metadatendienst überprüft das Attestation Statement (nicht das Attestation-Objekt).

Ja, die direkte Attestation (im Attestation Statement) bietet zwar die höchste Transparenz durch die Bereitstellung detaillierter Informationen über das Gerät, kann aber in bestimmten Szenarien Datenschutzbedenken aufwerfen. Es ist entscheidend, den Bedarf an Transparenz gegenüber dem Datenschutz bei der Wahl der Attestation-Art abzuwägen.

WebAuthn bietet verschiedene Arten von Attestation-Präferenzen – keine, indirekte, direkte und Unternehmens-Attestation. Für Szenarien, in denen der Schutz der Privatsphäre des Benutzers wichtig ist, kann attestation=none verwendet werden, was keine Details über das Gerät liefert und so sicherstellt, dass die Privatsphäre des Benutzers geschützt bleibt.