WebAuthn pubKeyCredParams e credentialPublicKey: CBOR e COSE

1. Introduzione: pubKeyCredParams e credentialPublicKey

2. Cos'è la crittografia a chiave pubblica?

   2.1 Come funziona la crittografia a chiave pubblica?

   2.2 Tipi comuni di algoritmi di crittografia a chiave pubblica

   2.3 Crescente adozione della crittografia pubblica basata su ECC

3. WebAuthn: come viene utilizzata la crittografia a chiave pubblica nelle passkey?

4. Come scegliere le impostazioni corrette per pubKeyCredParams?

   4.1 Quali algoritmi COSE sono rilevanti per WebAuthn?

   4.2 Definire l'array pubKeyCredParams in pubKeyCredParams

5. Come estrarre la chiave pubblica dall'attestationObject?

   5.1 Panoramica: cos'è l'attestationObject?

   5.2 Cos'è il Concise Binary Object Representation (CBOR)?

   5.3 Cos'è il formato COSE Key?

   5.4 Decodifica e analisi dell'attestationObject

6. Raccomandazione

7. Conclusione

Nel mondo della sicurezza digitale, le passkey sono il nuovo standard per l'autenticazione senza password. Al centro delle passkey c'è la crittografia a chiave pubblica, utilizzata all'interno del protocollo WebAuthn su cui si basano. Capire come la crittografia a chiave pubblica viene utilizzata in WebAuthn, in particolare nella creazione, estrazione, gestione e archiviazione delle passkey, è fondamentale quando si progetta o si utilizza l'autenticazione con passkey. La chiave pubblica è memorizzata sul server della relying party (RP), ovvero il backend del sito web che vuole autenticare un utente tramite passkey, mentre la chiave privata è archiviata in modo sicuro in un Hardware Security Module a seconda del sistema operativo: Secure Enclave (iOS), TEE (Android) o un TPM (Windows).

In questo post, esamineremo rapidamente le basi della crittografia a chiave pubblica utilizzata nelle passkey. Alla fine del post, avremo risposto alle seguenti domande:

• Quali algoritmi di crittografia sono supportati in WebAuthn
• Come funzionano i pubKeyCredParams durante la creazione di una coppia di chiavi?
• Come funziona credentialPublicKey nell'estrazione delle chiavi pubbliche create?

Per capire come funziona la crittografia a chiave pubblica in WebAuthn, daremo una rapida occhiata al suo funzionamento generale e ai tipi di algoritmi più comuni.

La crittografia a chiave pubblica, nota anche come crittografia asimmetrica, si contrappone alla crittografia simmetrica, dove la stessa chiave viene utilizzata sia per la crittografia che per la decrittografia. La crittografia asimmetrica impiega due chiavi distinte: una chiave pubblica, che può essere condivisa apertamente, e una chiave privata, che il proprietario tiene segreta.

Immagine tratta da: https://en.wikipedia.org/wiki/Public-key_cryptography

Questo metodo non solo permette di crittografare i dati per garantirne la riservatezza, ma consente anche di firmare i messaggi. La firma verifica l'identità del mittente e assicura che il messaggio non sia stato alterato, confermandone così l'autenticità e l'integrità.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Ecco una panoramica di alcuni tipi comuni di algoritmi utilizzati nella crittografia a chiave pubblica:

Il fondamento matematico della crittografia a curva ellittica (ECC), che include ECDSA e EdDSA, si basa sulle proprietà delle curve ellittiche, che non tratteremo in questo articolo. Ma dalla tabella precedente è evidente che ci sono vantaggi che ne guidano l'adozione. Analizzeremo i più importanti nella prossima sezione.

Become part of our Passkeys Community for updates & support.

Join

La crittografia a curva ellittica è stata ampiamente adottata per i dispositivi mobili, che beneficiano di dimensioni delle chiavi più piccole, con i seguenti vantaggi:

• Requisiti di archiviazione ridotti: Le chiavi più piccole dell'ECC richiedono meno spazio di archiviazione rispetto ai metodi crittografici tradizionali come RSA. Ciò è particolarmente vantaggioso per i dispositivi con risorse di memoria limitate, consentendo un uso più efficiente dello spazio. La tabella seguente mostra un'approssimazione dei livelli di sicurezza comparabili e le dimensioni effettive delle chiavi utilizzate. Il livello di sicurezza è misurato in bit e di solito corrisponde a un cifrario a chiave simmetrica di quella dimensione:

Il termine livello di sicurezza in questo contesto si riferisce alla robustezza del sistema crittografico, in particolare al livello di difficoltà per un utente malintenzionato di superare le misure di sicurezza. Generalmente si misura in bit e rappresenta la quantità di lavoro (il numero di operazioni) necessaria per violare la crittografia o falsificare una firma. Con l'aumentare del livello di sicurezza, i vantaggi in termini di dimensioni diventano evidenti, fino a raggiungere rapporti di dimensione della chiave di 1:30.

• Prestazioni migliorate: Le chiavi più piccole consentono operazioni crittografiche più veloci, il che è cruciale per i dispositivi con minore potenza di elaborazione. Ciò si traduce in attività di crittografia e decrittografia più rapide, migliorando le prestazioni complessive e la reattività delle applicazioni mobili. A seconda del tipo di benchmark, l'accelerazione varia da 10 a 40 volte nell'esecuzione. Ecco un esempio di dati di benchmark che AWS ha condotto durante l'implementazione di ECDSA per Cloudfront nel 2018:

• Migliore efficienza della batteria: Con un'elaborazione più efficiente grazie a chiavi più piccole, le operazioni ECC possono consumare meno energia. Questo risparmio di energia è vitale per i dispositivi mobili, dove preservare la durata della batteria è una sfida costante.

Questi fattori rendono l'ECC particolarmente adatta agli ambienti mobili, dove l'ottimizzazione dello spazio di archiviazione, della velocità di elaborazione e del consumo energetico è essenziale. Di conseguenza, l'ECC è sempre più preferita nell'informatica mobile per la sua capacità di fornire una sicurezza robusta senza compromettere le prestazioni del dispositivo. Tuttavia, ad oggi esistono ancora molte versioni più vecchie di protocolli diffusi come TLS (utilizzato per HTTPS, FTPS o SMTPS), SSH o IPsec che supportano ancora RSA ma hanno iniziato a offrire varianti basate su ECC ai client che le supportano.

Lo standard WebAuthn non è uno standard di crittografia, ma piuttosto un protocollo di sicurezza che fornisce un'autenticazione forte basata su chiave pubblica per le applicazioni web, consentendo agli utenti di accedere utilizzando dati biometrici, dispositivi mobili o chiavi di sicurezza hardware (ad esempio, le YubiKey) al posto delle password. Pertanto, WebAuthn è intenzionalmente agnostico riguardo alla crittografia a chiave pubblica effettivamente utilizzata. Vediamo come questo viene realizzato.

Il protocollo di sicurezza WebAuthn facilita l'autenticazione crittograficamente sicura tra l'Utente e la Relying Party. In termini tecnici, ciò significa che la Relying Party (un sito web che desidera utilizzare le passkey con i suoi utenti) deve scambiare le chiavi con l'utente e il suo authenticator tramite il browser, il quale memorizza poi la chiave privata nello specifico modulo di sicurezza hardware (HSM).

Per la registrazione delle passkey, ci sono tre passaggi importanti:

• (1) La Relying Party segnala gli algoritmi di crittografia supportati: La relying party segnala gli algoritmi di crittografia supportati tramite PublicKeyCredentialCreationOptions.pubKeyCredParams insieme alle altre PublicKeyCredentialCreationOptions.
• (2) L'Authenticator dell'utente crea la coppia di chiavi: L'authenticator controlla l'elenco pubKeyCredParams per trovare gli algoritmi di crittografia che supporta e crea una coppia di chiavi insieme a un Credential ID univoco. Memorizza la chiave privata all'interno dell'HSM e quindi restituisce la chiave pubblica e l'algoritmo di crittografia utilizzato al browser. Successivamente, il browser invia una richiesta POST al backend della Relying Party con l'attestationObject nella sezione "authData". Nel caso in cui non ci sia corrispondenza tra gli algoritmi di crittografia supportati, la procedura di creazione fallirà.
• (3) La Relying Party estrae la chiave pubblica e la memorizza: La relying party riceve l'attestationObject dal browser. Analizza la sezione authData.credentialPublicKey ed estrae la chiave pubblica. Insieme alla chiave pubblica, vengono inviate alla relying party anche le informazioni sull'algoritmo di crittografia utilizzato e il Credential ID.

Per i successivi accessi/autenticazioni con passkey, sono necessari i seguenti passaggi (dettagli semplificati):

• (1) La Relying Party presenta una challenge: La relying party genera una challenge casuale e la fornisce all'authenticator per la firma.
• (2) L'Authenticator dell'utente firma la challenge: L'Authenticator firma la challenge con la chiave che corrisponde alla richiesta di autenticazione e la restituisce con il Credential ID alla Relying Party.
• (3) La Relying Party convalida la firma: La Relying Party riceve le informazioni e cerca la chiave pubblica associata al Credential ID utilizzato. Quindi convalida crittograficamente la firma utilizzando l'algoritmo di crittografia/firma concordato durante la registrazione delle passkey.

Analizzando entrambi i casi, possiamo vedere che solo per la registrazione delle passkey le informazioni sulla chiave pubblica e sull'algoritmo di crittografia vengono scambiate tra gli attori.

Per i successivi eventi di accesso/autenticazione con passkey, solo la challenge e la firma fanno parte dei dati trasmessi.

Lo standard WebAuthn utilizza gli ID degli algoritmi COSE IANA per identificare gli algoritmi di crittografia utilizzati. Gli ID degli algoritmi COSE vengono utilizzati sia per segnalare gli algoritmi supportati in pubKeyCredParams sia per trasmettere il tipo di coppia di chiavi effettivamente creato in credentialPublicKey. Ci concentreremo sulla loro implementazione nelle prossime due sezioni.

L'elenco degli algoritmi COSE della IANA include oltre 75 algoritmi che teoricamente potrebbero essere utilizzati con lo standard WebAuthn. La maggior parte degli algoritmi con ID negativo è a chiave pubblica asimmetrica e la maggior parte di quelli con ID positivo è simmetrica, ma si tratta più di una convenzione, poiché esistono delle eccezioni.

Come abbiamo sottolineato in precedenza, l'algoritmo di crittografia deve essere supportato sia dall'Authenticator che dal backend della Relying Party per poter essere utilizzato nella procedura WebAuthn. Poiché la maggior parte delle relying party utilizza librerie WebAuthn esistenti che hanno accesso a una vasta gamma di algoritmi di crittografia, è più importante esaminare quali algoritmi sono supportati da quali authenticator:

(*) = Piccola parte delle chiavi di sicurezza (es. Yubikey 5+, Solokey o Nitrokey)
Estratto dalla tabella IANA: consulta l'elenco completo qui

Come si può vedere da questa tabella, per supportare tutti gli authenticator importanti, RS256 e ES256 sono sufficienti. Alcuni membri della community raccomandano di integrare anche EdDSA per migliorare ulteriormente la sicurezza. D'altra parte, i Credential ID che devono essere memorizzati sembrano essere significativamente più lunghi per le chiavi EdDSA. Ad oggi, la bozza dell'editore W3C sul prossimo Standard WebAuthn di Livello 3 suggerisce tutti e tre gli algoritmi.

La configurazione degli algoritmi di crittografia supportati per la creazione di passkey viene eseguita tramite 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,
});

L'esempio mostra come gli algoritmi vengono specificati all'interno di pubKeyCredParams tramite alg per l'ID e aggiungendo public-key come tipo di algoritmo. Nelle righe 29/30, le PublicKeyCredentialCreationOptions vengono passate all'authenticator tramite l'API WebAuthn del browser. Rimuovere il supporto per ES256 o RS256 produrrà errori ed è assolutamente sconsigliato.

Come esempio funzionante, eseguiremo le seguenti PublicKeyCredentialCreationOptions su un Mac nel Passkeys Debugger.

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

La risposta prodotta dall'authenticator viene inviata alla relying party (come attestation) e ha questo aspetto:

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

Nella prossima sezione, vedremo come estrarre le chiavi pubbliche e l'algoritmo di crittografia utilizzato dalla risposta.

Prima di tutto, dobbiamo esaminare come viene costruito l'effettivo attestationObject, perché, come vediamo sopra, non viene trasmesso in formato JSON alla Relying Party.

L'attestationObject svolge un ruolo importante nel processo di registrazione di WebAuthn, fungendo da contenitore per la dichiarazione di attestazione fornita dall'authenticator. Questo oggetto fornisce molte informazioni necessarie alla Relying Party (RP) per verificare l'origine e l'integrità della credenziale a chiave pubblica appena creata.

Fondamentalmente, l'attestationObject è una struttura complessa. È per lo più codificato in formato CBOR (Concise Binary Object Representation), che viene poi codificato con Base64URL. Incapsula i dati dell'authenticator insieme a una dichiarazione di attestazione che ne verifica l'autenticità. Poiché le passkey vengono create con attestazione "none" e quindi non contengono una dichiarazione di attestazione, non tratteremo questo aspetto in questo articolo. Nota a margine: abbiamo scritto "per lo più CBOR" perché sono coinvolti anche prefissi CBOR non standard a causa delle lunghezze variabili necessarie per le estensioni opzionali. Non approfondiremo questo aspetto; una discussione sulle complessità si può trovare qui.

Immagine tratta dalla specifica WebAuthn

All'interno dei dati dell'authenticator (authData), la chiave pubblica appena generata, insieme all'ID della credenziale dell'utente, sono archiviati in modo sicuro e possono essere recuperati dalla relying party. Poiché gli sviluppatori devono affrontare il compito di estrarre la chiave pubblica dall'attestationObject in qualsiasi sistema basato su WebAuthn, comprenderne l'architettura è importante.

CBOR (Concise Binary Object Representation) è un formato dati progettato per codificare i dati in modo compatto, efficiente ed estensibile. È binario, il che lo rende più piccolo e veloce da analizzare rispetto al suo modello di riferimento testuale, JSON. L'esempio seguente illustra la differenza tra JSON e CBOR (Testo vs. Binario):

Grassetto è Name. Corsivo è Corbado. (maggiori informazioni si possono trovare su https://cbor.io/)

Nel contesto di WebAuthn, CBOR viene utilizzato per diverse ragioni:

• Collegamento a FIDO2 / CTAP: Poiché CBOR è utilizzato negli standard sottostanti, si ottiene una semplificazione dell'analisi e dell'elaborazione dei dati, dato che sia WebAuthn che CTAP utilizzano lo stesso schema di codifica compatto.
• Compattezza: La codifica efficiente di CBOR lo rende una scelta eccellente per il traffico web, dove la minimizzazione delle dimensioni dei dati può avere un impatto significativo sulle prestazioni, in particolare su reti mobili o in ambienti con larghezza di banda limitata.
• Flessibilità: CBOR supporta una varietà di tipi di dati e strutture, inclusi array, mappe, stringhe di testo, stringhe di byte e tag per l'estensibilità. Questo lo rende abbastanza versatile da gestire i diversi tipi di dati e le strutture complesse necessarie per le operazioni di WebAuthn.
• Estensibilità: Il formato è progettato per essere estensibile, il che significa che nuove funzionalità possono essere aggiunte a WebAuthn senza compromettere la compatibilità con le implementazioni esistenti.

L'uso di CBOR è particolarmente adatto per codificare le chiavi pubbliche e l'attestationObject perché deve gestire i diversi formati e lunghezze di cui abbiamo discusso sopra. Ad esempio, una chiave RSA avrebbe attributi e dimensioni diverse rispetto a una chiave ECDSA. All'interno dell'attestationObject, le chiavi pubbliche sono memorizzate nel formato COSE Key, che si basa su CBOR.

Una struttura COSE Key è costruita su un oggetto mappa CBOR. Definisce un modo strutturato per la rappresentazione delle chiavi, includendo vari tipi di chiave e i loro parametri corrispondenti, come il modulo e l'esponente RSA, o le coordinate della chiave pubblica a curva ellittica. Questo formato standardizzato consente di serializzare e deserializzare le chiavi in modo coerente, indipendentemente dal loro algoritmo crittografico sottostante, oltre all'ID dell'algoritmo di crittografia di cui abbiamo discusso in precedenza.

Sfruttando CBOR e il formato COSE Key, WebAuthn può facilitare una vasta gamma di operazioni crittografiche garantendo al contempo che il payload rimanga il più piccolo possibile e si adatti ai futuri aggiornamenti della tecnologia crittografica. Questa scelta è in linea con gli obiettivi di WebAuthn di fornire un protocollo sicuro, efficiente e compatibile con il futuro per l'autenticazione web.

Quando si tratta di decodificare l'attestationObject in WebAuthn, gli sviluppatori si trovano di fronte a una decisione importante: sviluppare una soluzione personalizzata o sfruttare una libreria consolidata. La complessità e la natura critica di questo processo non possono essere sottovalutate. L'implementazione manuale della decodifica Base64URL e CBOR, sebbene tecnicamente fattibile, introduce il rischio di errori impercettibili che possono compromettere l'integrità del processo di autenticazione.

Per garantire la verifica crittografica della firma, così come l'accuratezza di tutti gli altri passaggi di convalida, è fortemente consigliato utilizzare una libreria WebAuthn ben testata e ampiamente adottata. Tali librerie sono costruite con competenze crittografiche per gestire i dettagli della decodifica e della convalida dell'attestationObject, tra cui:

• Analizzare correttamente il formato CBOR per estrarre la dichiarazione di attestazione e i dati dell'authenticator.
• Interpretare il formato COSE Key per recuperare la chiave pubblica.
• Eseguire controlli crittografici per convalidare la firma secondo lo standard WebAuthn.

Affidandosi a una libreria affidabile, gli sviluppatori non solo risparmiano tempo e risorse, ma ottengono anche tranquillità. La chiave pubblica, una volta estratta e verificata tramite questi strumenti affidabili, può essere archiviata in modo sicuro nel database, pronta per essere utilizzata per sessioni di autenticazione sicure. Questo approccio garantisce l'aderenza alle specifiche del protocollo e mantiene il livello di sicurezza previsto nelle implementazioni di WebAuthn. Per semplicità, useremo il SimpleWebauthn Debugger che restituisce una versione completamente decodificata con i campi CBOR convertiti in JSON espanso:

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

La libreria SimpleWebAuthn viene utilizzata per decodificare l'intero attestationObject. Come possiamo vedere, tutte le informazioni sono ora leggibili. Tutte le informazioni crittografiche fanno parte di credentialPublicKey, che è parte della sezione authData, che la libreria ha espanso nella dichiarazione parsedCredentialPublicKey. Nella specifica, ci sono diversi esempi di come appare il formato COSE Key.

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

Questo output mostra tutti gli elementi crittografici del credentialPublicKey elegantemente analizzati in un formato leggibile dall'uomo. Questa particolare istanza rivela una chiave EC2 per l'algoritmo ES256, come indicato dal parametro dell'algoritmo e dalla presenza delle coordinate x e y.

Al contrario, l'output di un sistema Windows 10 appare come segue:

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

Qui, l'ID dell'algoritmo è -257, corrispondente a RS256, e possiamo notare che gli attributi che caratterizzano questa chiave pubblica divergono significativamente da quelli di una chiave ECDSA. Il formato COSE Key consente di specificare attributi unici per tipo:

Inoltre, il modulo RSA è sostanzialmente più lungo delle coordinate della curva ellittica utilizzate nella chiave ES256, sottolineando la nostra precedente discussione sulle differenze nelle dimensioni delle chiavi e sui requisiti intrinseci dei diversi algoritmi crittografici.

Dopo aver esaminato le basi della crittografia a chiave pubblica e aver compreso come è incorporata nello standard WebAuthn / FIDO2, abbiamo due raccomandazioni principali per le relying party:

• Selezionare gli algoritmi di crittografia giusti: Nell'implementazione di WebAuthn, è importante utilizzare gli algoritmi corretti per la massima compatibilità. Sulla base delle raccomandazioni attuali, è consigliabile una combinazione di RS256, ES256 e EdDSA. RS256 e ES256 si distinguono per il loro ampio supporto, e l'inclusione di EdDSA può migliorare la sicurezza dove possibile.
• Utilizzare librerie WebAuthn ben testate per estrarre la chiave pubblica: Una volta decisi gli algoritmi, il passo successivo è integrare una libreria WebAuthn ben testata. Tale libreria può gestire con competenza le complessità dell'analisi di * attestationObject*. Dopo che la libreria ha estratto le chiavi pubbliche e i dati associati, questi possono essere archiviati in modo sicuro nel database. Il formato utilizzato dalla libreria garantisce tipicamente che la chiave sia memorizzata in modo da poter essere letta e utilizzata accuratamente per future finalità di autenticazione.

È fondamentale non reinventare la ruota: sfruttate la conoscenza collettiva incorporata nelle librerie consolidate. Un'implementazione personalizzata rischia di introdurre errori e falle di sicurezza che potrebbero compromettere l'efficacia dell'autenticazione e la sicurezza generale del sistema.

In questo post, abbiamo analizzato le basi della crittografia a chiave pubblica per rispondere alle tre domande centrali iniziali:

1. Algoritmi di crittografia supportati in WebAuthn: WebAuthn è progettato per essere flessibile e supporta una vasta gamma di algoritmi di crittografia, tra cui spiccano RSA (RS256), ECDSA (ES256) e EdDSA. Questa adattabilità gli consente di integrarsi senza problemi con vari authenticator e piattaforme, garantendo un'ampia compatibilità.
2. Funzionalità di pubKeyCredParams nella creazione di coppie di chiavi: I pubKeyCredParams svolgono un ruolo importante nella fase di registrazione del processo WebAuthn, specificando quali algoritmi crittografici la relying party supporta. Ciò garantisce che le coppie di chiavi create siano compatibili sia con l'authenticator dell'utente che con i requisiti della relying party.
3. Funzionalità di credentialPublicKey e estrazione delle chiavi pubbliche: Il credentialPublicKey viene utilizzato per estrarre le chiavi pubbliche dall'attestationObject fornito dagli authenticator.

Inoltre, abbiamo evidenziato l'indipendenza del protocollo WebAuthn da specifici algoritmi di crittografia, il che ne aumenta significativamente la flessibilità e la capacità di adattarsi ai futuri metodi crittografici emergenti. Speriamo che questo articolo aiuti anche altri sviluppatori nel debugging e nella comprensione di concetti/problemi legati alla crittografia a chiave pubblica in WebAuthn.