WebAuthn pubKeyCredParams & credentialPublicKey: CBOR & COSE erklärt

In der digitalen Sicherheit sind Passkeys der neue Standard für die passwortlose Authentifizierung. Das Herzstück von Passkeys ist die Public-Key-Kryptographie, die innerhalb des WebAuthn-Protokolls, auf dem Passkeys basieren, verwendet wird. Zu verstehen, wie die Public-Key-Kryptographie in WebAuthn eingesetzt wird, insbesondere bei der Erstellung, Extraktion, Verwaltung und Speicherung von Passkeys, ist entscheidend, wenn man Passkey-Authentifizierung entwirft oder verwendet. Der Public Key wird auf dem Server der Relying Party (RP) gespeichert, also dem Backend der Website, die einen User über Passkeys authentifizieren möchte. Der Private Key wird sicher in einem Hardware-Sicherheitsmodul gespeichert, je nach Betriebssystem im Secure Enclave (iOS), TEE (Android) oder einem TPM (Windows).

In diesem Blogbeitrag werden wir kurz die Grundlagen der Public-Key-Kryptographie, die in Passkeys verwendet wird, durchgehen. Die folgenden Fragen sollten am Ende des Blogbeitrags beantwortet sein:

• Welche Verschlüsselungsalgorithmen werden in WebAuthn unterstützt?
• Wie funktionieren pubKeyCredParams bei der Erstellung eines Schlüsselpaars?
• Wie funktioniert credentialPublicKey beim Extrahieren der erstellten Public Keys?

Um zu verstehen, wie die Public-Key-Kryptographie innerhalb von WebAuthn funktioniert, werfen wir einen kurzen Blick darauf, wie sie im Allgemeinen funktioniert und welche gängigen Arten von Algorithmen es gibt.

Die Public-Key-Kryptographie, auch als asymmetrische Kryptographie bekannt, steht im Gegensatz zur symmetrischen Kryptographie, bei der derselbe Schlüssel sowohl für die Ver- als auch für die Entschlüsselung verwendet wird. Die asymmetrische Kryptographie verwendet zwei unterschiedliche Schlüssel – einen Public Key, der offen geteilt werden kann, und einen Private Key, der vom Besitzer geheim gehalten wird.

Quelle: https://de.wikipedia.org/wiki/Public-Key-Verschlüsselungsverfahren

Diese Methode ermöglicht nicht nur die Verschlüsselung von Daten zur Sicherung ihrer Vertraulichkeit, sondern auch das Signieren von Nachrichten. Das Signieren bestätigt die Identität des Absenders und stellt sicher, dass die Nachricht nicht manipuliert wurde, wodurch ihre Authentizität und Integrität bestätigt werden.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Hier ist ein Überblick über einige gängige Arten von Algorithmen, die in der Public-Key-Kryptographie verwendet werden:

Die mathematische Grundlage der Elliptic Curve Cryptography (ECC), einschließlich ECDSA und EdDSA, beruht auf den Eigenschaften elliptischer Kurven, die wir in diesem Artikel nicht behandeln werden. Aus der obigen Tabelle wird jedoch deutlich, dass es Vorteile gibt, die ihre Verbreitung vorantreiben. Wir werden die wichtigsten im nächsten Abschnitt durchgehen.

Become part of our Passkeys Community for updates & support.

Join

Die Elliptic Curve Cryptography hat sich für mobile Geräte weitgehend durchgesetzt, da diese von den kleineren Schlüssellängen profitieren, was folgende Vorteile mit sich bringt:

• Reduzierter Speicherbedarf: Die kleineren Schlüssel von ECC benötigen im Vergleich zu traditionellen kryptographischen Methoden wie RSA weniger Speicherplatz. Dies ist besonders vorteilhaft für Geräte mit begrenzten Speicherressourcen und ermöglicht eine effizientere Nutzung des Platzes. Die folgende Tabelle zeigt eine Annäherung vergleichbarer Sicherheitsniveaus und die tatsächlichen Größen der verwendeten Schlüssel. Das Sicherheitsniveau wird in Bits gemessen und entspricht in der Regel einer symmetrischen Schlüsselschiffre dieser Größe:

Der Begriff Sicherheitsniveau bezieht sich in diesem Kontext auf die Stärke des kryptographischen Systems, insbesondere auf den Schwierigkeitsgrad für einen Angreifer, die Sicherheitsmaßnahmen zu überwinden. Es wird im Allgemeinen in Bits gemessen und stellt den Arbeitsaufwand (die Anzahl der Operationen) dar, der erforderlich wäre, um die Verschlüsselung zu brechen oder eine Signatur zu fälschen. Mit zunehmendem Sicherheitsniveau werden die Größenvorteile bis zu einem Schlüsselverhältnis von 1:30 deutlich.

• Verbesserte Leistung: Die kleineren Schlüssel ermöglichen schnellere kryptographische Operationen, was für Geräte mit geringerer Rechenleistung entscheidend ist. Dies führt zu schnelleren Ver- und Entschlüsselungsaktivitäten und steigert die Gesamtleistung und Reaktionsfähigkeit mobiler Anwendungen. Je nach Art der Benchmarks reichen die Geschwindigkeitssteigerungen von 10- bis 40-fach bei der Ausführung. Hier ist ein Beispiel für Benchmark-Daten, die AWS bei der Implementierung von ECDSA für Cloudfront im Jahr 2018 durchgeführt hat:

• Verbesserte Akkueffizienz: Durch die effizientere Verarbeitung mit kleineren Schlüsseln können ECC-Operationen weniger Strom verbrauchen. Diese Einsparung von Energie ist für mobile Geräte von entscheidender Bedeutung, bei denen die Erhaltung der Akkulaufzeit eine ständige Herausforderung darstellt.

Diese Faktoren machen ECC besonders geeignet für mobile Umgebungen, in denen die Optimierung von Speicher, Verarbeitungsgeschwindigkeit und Stromverbrauch unerlässlich ist. Infolgedessen wird ECC im mobilen Computing zunehmend bevorzugt, da es robuste Sicherheit bietet, ohne die Geräteleistung zu beeinträchtigen. Dennoch existieren bis heute viele ältere Versionen weit verbreiteter Protokolle wie TLS (verwendet für HTTPS, FTPS oder SMTPS), SSH oder IPsec, die immer noch RSA unterstützen, aber begonnen haben, ECC-basierte Varianten für Clients anzubieten, die diese unterstützen.

Der WebAuthn-Standard ist kein Verschlüsselungsstandard, sondern ein Sicherheitsprotokoll, das eine starke, auf Public-Key-Kryptographie basierende Authentifizierung für Webanwendungen bietet. Es ermöglicht Usern, sich anstelle von Passwörtern mit Biometrie, mobilen Geräten oder Hardware-Sicherheitsschlüsseln (z. B. YubiKeys) anzumelden. Daher ist WebAuthn bewusst agnostisch, welche zugrunde liegende Public-Key-basierte Kryptographie tatsächlich verwendet wird. Schauen wir uns an, wie dies erreicht wird.

Das WebAuthn-Sicherheitsprotokoll ermöglicht die kryptographisch sichere Authentifizierung zwischen dem User und der Relying Party. Technisch bedeutet dies, dass die Relying Party (eine Website, die Passkeys mit ihren Usern verwenden möchte) über den Browser Schlüssel mit dem User und seinem Authenticator austauschen muss, der dann den Private Key im spezifischen Hardware-Sicherheitsmodul (HSM) speichert.

Für die Anmeldung / Registrierung von Passkeys gibt es drei wichtige Schritte:

• (1) Die Relying Party signalisiert unterstützte Verschlüsselungsalgorithmen: Die Relying Party signalisiert unterstützte Verschlüsselungsalgorithmen über PublicKeyCredentialCreationOptions.pubKeyCredParams zusammen mit den anderen PublicKeyCredentialCreationOptions.
• (2) Der Authenticator des Users erstellt das Schlüsselpaar: Der Authenticator prüft die pubKeyCredParams-Liste auf Verschlüsselungsalgorithmen, die er unterstützt, und erstellt ein Schlüsselpaar zusammen mit einer eindeutigen Credential ID. Er speichert den Private Key im HSM und gibt dann den Public Key und den verwendeten Verschlüsselungsalgorithmus an den Browser zurück. Anschließend sendet der Browser eine POST-Anfrage an das Backend der Relying Party mit dem attestationObject im „authData“-Abschnitt. Falls keine Übereinstimmung der unterstützten Verschlüsselungsalgorithmen gefunden wird, schlägt die Erstellungszeremonie fehl.
• (3) Die Relying Party extrahiert den Public Key und speichert ihn: Die Relying Party empfängt das attestationObject vom Browser. Sie parst den authData.credentialPublicKey-Abschnitt und extrahiert den Public Key. Zusammen mit dem Public Key werden auch Informationen über den verwendeten Verschlüsselungsalgorithmus und die Credential ID an die Relying Party zurückgesendet.

Für nachfolgende Anmeldungen / Authentifizierungen mit Passkeys sind die folgenden Schritte erforderlich (Details vereinfacht):

• (1) Die Relying Party präsentiert eine Challenge: Die Relying Party generiert eine zufällige Challenge und stellt sie dem Authenticator zur Signatur zur Verfügung.
• (2) Der Authenticator des Users signiert die Challenge: Der Authenticator signiert die Challenge mit dem Schlüssel, der zur Authentifizierungsanfrage passt, und gibt sie mit der Credential ID an die Relying Party zurück.
• (3) Die Relying Party validiert die Signatur: Die Relying Party empfängt die Informationen und sucht den Public Key, der mit der verwendeten Credential ID verknüpft ist. Anschließend validiert sie die Signatur kryptographisch mit dem Verschlüsselungs-/Signaturalgorithmus, der bei der Registrierung der Passkeys vereinbart wurde.

Wenn wir beide Fälle betrachten, sehen wir, dass nur bei der Anmeldung / Registrierung von Passkeys Informationen zum Public Key und zum Verschlüsselungsalgorithmus zwischen den Akteuren ausgetauscht werden.

Bei nachfolgenden Anmelde- / Authentifizierungsereignissen mit Passkeys sind nur die Challenge und die Signatur Teil der übertragenen Daten.

Der WebAuthn-Standard verwendet die IANA COSE Algorithm IDs, um die verwendeten Verschlüsselungsalgorithmen zu identifizieren. Die COSE Algorithm IDs werden sowohl zur Signalisierung der unterstützten Algorithmen in pubKeyCredParams als auch zur Übermittlung des tatsächlich erstellten Schlüsselpaartyps in credentialPublicKey verwendet. Wir werden uns in den nächsten beiden Abschnitten auf ihre Implementierung konzentrieren.

Die COSE-Algorithmenliste der IANA umfasst über 75 Algorithmen, die theoretisch mit dem WebAuthn-Standard verwendet werden könnten. Die meisten Algorithmen mit negativer ID sind asymmetrisch (Public Key) und die meisten mit positiver ID symmetrisch, aber dies ist eher eine Konvention, da es Ausnahmen gibt.

Wie wir bereits erwähnt haben, muss der Verschlüsselungsalgorithmus vom Authenticator und dem Backend der Relying Party unterstützt werden, um in der WebAuthn-Zeremonie verwendet zu werden. Da die meisten Relying Parties bestehende WebAuthn-Bibliotheken verwenden, die Zugriff auf eine breite Palette von Verschlüsselungsalgorithmen haben, ist es wichtiger zu prüfen, welche Algorithmen von welchen Authenticators unterstützt werden:

(*) = Kleiner Teil der Sicherheitsschlüssel (z. B. YubiKeys 5+, Solokey oder Nitrokey) Auszug aus der IANA-Tabelle: Vollständige Liste hier

Wie Sie aus dieser Tabelle ersehen können, sind RS256 und ES256 ausreichend, um alle wichtigen Authenticators zu unterstützen. Es gibt Teile der Community, die empfehlen, auch EdDSA zu integrieren, um die Sicherheit weiter zu verbessern. Andererseits scheinen die Credential IDs, die ebenfalls gespeichert werden müssen, bei EdDSA-Schlüsseln deutlich länger zu sein. Derzeit schlägt der W3C Editor’s Draft zum kommenden Level 3 WebAuthn Standard alle drei Algorithmen vor.

Die Konfiguration der unterstützten Verschlüsselungsalgorithmen für die Passkey-Erstellung erfolgt über die PublicKeyCredentialCreationOptions:

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

Das Beispiel zeigt, wie die Algorithmen innerhalb von pubKeyCredParams durch alg für die ID und das Hinzufügen von public-key als Typ des Algorithmus spezifiziert werden. In Zeile 29/30 werden die PublicKeyCredentialCreationOptions über die WebAuthn-API des Browsers an den Authenticator übergeben. Das Entfernen der Unterstützung für ES256 oder RS256 führt zu Fehlern und wird ausdrücklich nicht empfohlen.

Als funktionierendes Beispiel führen wir die folgenden PublicKeyCredentialCreationOptions auf einem Mac im Passkeys Debugger aus.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

Die vom Authenticator erzeugte Antwort wird an die Relying Party gesendet (als Attestation) und sieht wie folgt aus:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Im nächsten Abschnitt werden wir sehen, wie die Public Keys und der verwendete Verschlüsselungsalgorithmus aus der Antwort extrahiert werden können.

Zuerst müssen wir untersuchen, wie das eigentliche attestationObject aufgebaut ist, denn wie wir oben sehen, wird es nicht im JSON-Format an die Relying Party übertragen.

Das attestationObject spielt eine wichtige Rolle im WebAuthn-Registrierungsprozess und dient als Container für die vom Authenticator bereitgestellte Attestation Statement. Dieses Objekt liefert viele Informationen, die für die Relying Party (RP) notwendig sind, um den Ursprung und die Integrität der neu erstellten Public-Key-Credential zu überprüfen.

Im Kern ist das attestationObject eine komplexe Struktur. Es ist größtenteils im CBOR (Concise Binary Object Representation) Format kodiert, das dann am Ende mit Base64URL kodiert wird. Es kapselt die Authenticator-Daten zusammen mit einer Attestation-Anweisung, die die Authentizität der Informationen bestätigt. Da Passkeys mit der Attestation „none“ erstellt werden und daher keine Attestation-Anweisung enthalten, werden wir dies in diesem Artikel nicht behandeln. Nebenbei bemerkt: Wir schrieben größtenteils CBOR, weil es aufgrund der variablen Längen, die für die optionalen Erweiterungen benötigt werden, auch nicht standardmäßige CBOR-Präfixe gibt. Darauf werden wir nicht näher eingehen, eine Diskussion über die Komplexität findet sich hier.

Aus der WebAuthn-Spezifikation

Innerhalb der Authenticator-Daten (authData) werden der neu generierte Public Key sowie die Credential ID des Users sicher gespeichert und können von der Relying Party abgerufen werden. Da Entwickler die Aufgabe haben, den Public Key aus dem attestationObject in jedem WebAuthn-basierten System zu extrahieren, ist das Verständnis seiner Architektur wichtig.

CBOR (Concise Binary Object Representation) ist ein Datenformat, das entwickelt wurde, um Daten kompakt, effizient und erweiterbar zu kodieren. Es ist binär, was es kleiner und schneller zu parsen macht als sein textbasiertes Vorbild JSON. Das folgende Beispiel veranschaulicht, wie sich JSON und CBOR unterscheiden (Text vs. Binär):

Fett ist Name. Kursiv ist Corbado. (weitere Informationen finden Sie auf https://cbor.io/)

Im Kontext von WebAuthn wird CBOR aus mehreren Gründen verwendet:

• Verbindung zu FIDO2 / CTAP: Da CBOR in den zugrunde liegenden Standards verwendet wird, wird das Parsen und Verarbeiten von Daten optimiert, da sowohl WebAuthn als auch CTAP dasselbe kompakte Kodierungsschema verwenden.
• Kompaktheit: Die effiziente Kodierung von CBOR macht es zu einer ausgezeichneten Wahl für den Web-Traffic, wo die Minimierung der Datengröße die Leistung erheblich beeinflussen kann, insbesondere über mobile Netzwerke oder in Umgebungen mit begrenzter Bandbreite.
• Flexibilität: CBOR unterstützt eine Vielzahl von Datentypen und Strukturen, einschließlich Arrays, Maps, Textstrings, Bytestrings und Tags zur Erweiterbarkeit. Dies macht es vielseitig genug, um die verschiedenen Datentypen und komplexen Strukturen zu handhaben, die für die Operationen von WebAuthn erforderlich sind.
• Erweiterbarkeit: Das Format ist so konzipiert, dass es erweiterbar ist, was bedeutet, dass neue Funktionen zu WebAuthn hinzugefügt werden können, ohne die Kompatibilität mit bestehenden Implementierungen zu beeinträchtigen.

Die Verwendung von CBOR ist besonders passend für die Kodierung der Public Keys und des attestationObject, da es die verschiedenen Formate und Längen, die wir oben besprochen haben, handhaben muss. Zum Beispiel hätte ein RSA-Schlüssel andere Attribute und Größen als ein ECDSA-Schlüssel. Innerhalb des attestationObject werden Public Keys im COSE-Key-Format gespeichert, das auf CBOR basiert.

Eine COSE-Key-Struktur basiert auf einem CBOR-Map-Objekt. Sie definiert eine strukturierte Art der Schlüsseldarstellung, die verschiedene Schlüsseltypen und ihre entsprechenden Parameter umfasst, wie z. B. den RSA-Modul und -Exponent oder die Koordinaten des Public Keys einer elliptischen Kurve. Dieses standardisierte Format ermöglicht es, Schlüssel konsistent zu serialisieren und zu deserialisieren, unabhängig von ihrem zugrunde liegenden kryptographischen Algorithmus, zusätzlich zur oben besprochenen Verschlüsselungsalgorithmus-ID.

Durch die Nutzung von CBOR und dem COSE-Key-Format kann WebAuthn eine breite Palette kryptographischer Operationen ermöglichen, während die Nutzlast so klein wie möglich bleibt und anpassungsfähig für zukünftige Updates in der kryptographischen Technologie ist. Diese Wahl steht im Einklang mit den Zielen von WebAuthn, ein sicheres, effizientes und zukunftssicheres Protokoll für die Web-Authentifizierung bereitzustellen.

Wenn es darum geht, das attestationObject innerhalb von WebAuthn zu dekodieren, stehen Entwickler vor einer wichtigen Entscheidung: eine eigene Lösung entwickeln oder eine etablierte Bibliothek nutzen. Die Komplexität und kritische Natur dieses Prozesses kann nicht genug betont werden. Die manuelle Implementierung der Base64URL- und CBOR-Dekodierung ist zwar technisch machbar, birgt jedoch das Risiko subtiler Fehler, die die Integrität des Authentifizierungsprozesses gefährden können.

Um die kryptographische Überprüfung der Signatur sowie die Genauigkeit aller anderen Validierungsschritte zu gewährleisten, wird dringend empfohlen, eine gut getestete und weit verbreitete WebAuthn-Bibliothek zu verwenden. Solche Bibliotheken werden mit Verschlüsselungsexpertise entwickelt, um die Details der Dekodierung und Validierung des attestationObject zu handhaben, einschließlich:

• Korrektes Parsen des CBOR-Formats, um die Attestation-Anweisung und die Authenticator-Daten zu extrahieren.
• Interpretieren des COSE-Key-Formats, um den Public Key abzurufen.
• Durchführung kryptographischer Prüfungen zur Validierung der Signatur gemäß dem WebAuthn-Standard.

Durch die Verwendung einer seriösen Bibliothek sparen Entwickler nicht nur Zeit und Ressourcen, sondern gewinnen auch an Sicherheit. Der Public Key kann, sobald er durch diese zuverlässigen Werkzeuge extrahiert und verifiziert wurde, sicher in der Datenbank gespeichert werden und ist bereit für sichere Authentifizierungssitzungen. Dieser Ansatz gewährleistet die Einhaltung der Protokollspezifikationen und erhält die Sicherheitslage, die in WebAuthn-Implementierungen erwartet wird. Der Einfachheit halber verwenden wir den SimpleWebauthn Debugger, der eine vollständig dekodierte Version zurückgibt, bei der CBOR-Felder in ein aufgelöstes JSON konvertiert werden:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Die SimpleWebAuthn-Bibliothek wird verwendet, um das gesamte attestationObject zu dekodieren. Wie wir sehen können, sind alle Informationen jetzt lesbar. Alle kryptographischen Informationen sind Teil von credentialPublicKey, das Teil des authData-Teils ist, den die Bibliothek in die parsedCredentialPublicKey-Anweisung aufgelöst hat. In der Spezifikation gibt es mehrere Beispiele, wie das COSE-Key-Format aussieht.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Diese Ausgabe zeigt alle kryptographischen Elemente des credentialPublicKey sauber in menschenlesbarer Form geparst. Dieses spezielle Beispiel zeigt einen EC2-Schlüssel für den ES256-Algorithmus, wie durch den Algorithmus-Parameter und das Vorhandensein von x- und y-Koordinaten angezeigt wird.

Im Gegensatz dazu sieht die Ausgabe eines Windows 10-Systems wie folgt aus:

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

Hier ist die Algorithmus-ID -257, was RS256 entspricht, und wir können erkennen, dass die Attribute, die diesen Public Key charakterisieren, sich erheblich von denen eines ECDSA-Schlüssels unterscheiden. Das COSE-Key-Format ermöglicht die Angabe eindeutiger Attribute pro Typ:

Außerdem ist der RSA-Modul wesentlich länger als die Koordinaten der elliptischen Kurve, die im ES256-Schlüssel verwendet werden, was unsere frühere Diskussion über die Unterschiede in den Schlüssellängen und die inhärenten Anforderungen verschiedener kryptographischer Algorithmen unterstreicht.

Nachdem wir die Grundlagen der Public-Key-Kryptographie durchgegangen sind und verstanden haben, wie sie in den WebAuthn / FIDO2-Standard integriert ist, haben wir zwei wichtige Empfehlungen für Relying Parties:

• Die richtigen Verschlüsselungsalgorithmen auswählen: Bei der Implementierung von WebAuthn ist es wichtig, die richtigen Algorithmen für maximale Kompatibilität zu verwenden. Basierend auf aktuellen Empfehlungen ist eine Kombination aus RS256, ES256 und EdDSA ratsam. RS256 und ES256 zeichnen sich durch ihre breite Unterstützung aus, und die Einbeziehung von EdDSA kann die Sicherheit, wo möglich, erhöhen.
• Bewährte WebAuthn-Bibliotheken zum Extrahieren des Public Keys verwenden: Sobald Sie sich für die Algorithmen entschieden haben, besteht der nächste Schritt darin, eine gut getestete WebAuthn-Bibliothek zu integrieren. Eine solche Bibliothek kann die Komplexität des Parsens des attestationObject kompetent handhaben. Nachdem die Bibliothek die Public Keys und die zugehörigen Daten extrahiert hat, können diese sicher in der Datenbank gespeichert werden. Das von der Bibliothek verwendete Format stellt in der Regel sicher, dass der Schlüssel so gespeichert wird, dass er für zukünftige Authentifizierungszwecke genau gelesen und verwendet werden kann.

Es ist entscheidend, das Rad nicht neu zu erfinden: Nutzen Sie das kollektive Wissen, das in etablierten Bibliotheken verankert ist. Eine benutzerdefinierte Implementierung birgt das Risiko, Fehler und Sicherheitslücken einzuführen, die die Wirksamkeit der Authentifizierung und die allgemeine Sicherheit des Systems untergraben könnten.

In diesem Blogbeitrag haben wir die Grundlagen der Public-Key-Kryptographie untersucht, um die drei anfänglichen Kernfragen zu beantworten:

1. Unterstützte Verschlüsselungsalgorithmen in WebAuthn: WebAuthn ist flexibel konzipiert und unterstützt eine breite Palette von Verschlüsselungsalgorithmen, vor allem RSA (RS256), ECDSA (ES256) und EdDSA. Diese Anpassungsfähigkeit ermöglicht eine nahtlose Integration mit verschiedenen Authenticators und Plattformen und gewährleistet eine breite Kompatibilität.
2. Funktionalität von pubKeyCredParams bei der Erstellung von Schlüsselpaaren: Die pubKeyCredParams spielen eine wichtige Rolle in der Registrierungsphase des WebAuthn-Prozesses, indem sie angeben, welche kryptographischen Algorithmen die Relying Party unterstützt. Dies stellt sicher, dass die erstellten Schlüsselpaare sowohl mit dem Authenticator des Users als auch mit den Anforderungen der Relying Party kompatibel sind.
3. Funktionalität von credentialPublicKey und das Extrahieren von Public Keys: Der credentialPublicKey wird verwendet, um Public Keys aus dem von den Authenticators bereitgestellten attestationObject zu extrahieren.

Außerdem haben wir die Unabhängigkeit des WebAuthn-Protokolls von spezifischen Verschlüsselungsalgorithmen hervorgehoben, was seine Flexibilität und Zukunftssicherheit gegenüber aufkommenden kryptographischen Methoden erheblich verbessert. Wir hoffen, dass dieser Artikel auch anderen Entwicklern beim Debuggen und Verstehen von Konzepten / Problemen im Zusammenhang mit der Public-Key-Kryptographie in WebAuthn hilft.