Cos'è l'attestazione in WebAuthn?

L'attestazione può riferirsi a tre cose (spesso nel linguaggio parlato sono usate in modo intercambiabile, sebbene significhino qualcosa di diverso se prese alla lettera):

1. In primo luogo e più in generale, l'attestazione in ambito crittografico è un termine con cui una parte "attesta" crittograficamente una dichiarazione a un'altra parte.

2. In secondo luogo, durante la fase di registrazione in WebAuthn, un oggetto di attestazione viene creato dall'autenticatore e restituito alla Relying Party. È un oggetto contenitore che contiene le seguenti informazioni:

   • formato della dichiarazione di attestazione (fmt)
   • dichiarazione di attestazione (attStmt - vedi sotto)
   • dati dell'autenticatore (authData)

3. In terzo luogo, in WebAuthn, una dichiarazione di attestazione è un elemento opzionale dell'oggetto di attestazione. Questa dichiarazione, quando inclusa, verifica determinate caratteristiche dell'autenticatore (dispositivo) coinvolto nel processo di attestazione. Tuttavia, alcuni produttori di dispositivi (ad es. Apple) non offrono una dichiarazione di attestazione perché questo aspetto della specifica non era destinato alla sincronizzazione delle passkey e non riesce a verificare efficacemente gli attributi di sicurezza quando le credenziali possono essere sincronizzate su dispositivi diversi (ad es. una passkey viene creata su un iPhone ma utilizzata anche su un MacBook poiché è sincronizzata tramite lo stesso Portachiavi iCloud). Caratteristiche che possono essere fornite quando è presente la dichiarazione di attestazione:

   • Offrire la prova che durante l'autenticazione è stato utilizzato un dispositivo autentico e affidabile.
   • Fornire dettagli sull'origine, il modello e altre informazioni pertinenti del dispositivo.
   • Migliorare le misure di sicurezza, specialmente in scenari in cui l'affidabilità del dispositivo è cruciale (ad es. alcuni settori regolamentati come quello sanitario).

Il seguente diagramma di flusso del processo di Registrazione mostra il ruolo dell'attestazione (oggetto) 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"
    }
}

Nello screenshot qui sopra, non vengono forniti né l'AAGUID né la dichiarazione di attestazione.

Sperimenta i flussi passkey nel Passkeys Debugger.

Prova gratis

Continua a leggere per un'analisi tecnica degli attributi più importanti.

In WebAuthn, l'attestazione garantisce che l'autenticazione dell'utente sia sicura e trasparente. Con la dichiarazione di attestazione, puoi assicurarti che una credenziale sia stata creata su un autenticatore / dispositivo specifico.

Questi tipi di attestazione si riferiscono alla dichiarazione di attestazione (non all'oggetto di attestazione). Sono considerati una preferenza dalla relying party (quindi l'autenticatore può comportarsi diversamente poiché è solo una preferenza).

• Nessuna attestazione (none): Per i casi in cui la privacy è della massima importanza o sono in gioco dispositivi sincronizzati, questo tipo non fornisce alcuna informazione sul dispositivo, garantendo che la privacy dell'utente rimanga intatta. Un altro motivo per utilizzare questo valore potrebbe essere quello di risparmiare un roundtrip verso un'autorità di certificazione (CA). none è anche il valore predefinito.
• Attestazione indiretta (indirect): La relying party preferisce ottenere un'attestazione ma consente al client di decidere come ottenere le dichiarazioni di attestazione. Il client può sostituire le dichiarazioni di attestazione generate dall'autenticatore con dichiarazioni di attestazione anonime per proteggere la privacy dell'utente.
• Attestazione diretta (direct): Questa è la forma più trasparente. Qui, la relying party comunica all'autenticatore che desidera una dichiarazione di attestazione, in modo che la relying party ottenga informazioni dettagliate sul dispositivo, inclusi marca, modello e altre specifiche. Sebbene offra la massima trasparenza, può sollevare preoccupazioni sulla privacy in determinati scenari o potrebbe non essere realmente utilizzabile per le credenziali sincronizzate.
• Attestazione aziendale (enterprise): La relying party desidera ricevere una dichiarazione di attestazione che può includere informazioni identificative uniche. Questo tipo di attestazione è tipicamente utilizzato in aziende o organizzazioni che vogliono tenere traccia di dispositivi / autenticatori specifici. I browser web (user agent) non dovrebbero fornire questa attestazione dettagliata a meno che le loro impostazioni non lo consentano specificamente per la parte richiedente. Se le impostazioni lo consentono, il browser dovrebbe comunicare al dispositivo quando è necessario (all'inizio del processo) che questo specifico tipo di attestazione è stato richiesto. Il browser dovrebbe quindi trasmettere l'ID univoco del dispositivo e la prova di attestazione esattamente come li riceve alla relying party.

Iscriviti al nostro Substack sulle passkey per le ultime novità.

Iscriviti

L'oggetto di attestazione contiene molti attributi, ecco una rapida spiegazione di alcuni attributi selezionati:

"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 è un oggetto codificato in CBOR, contenente informazioni sulle credenziali appena create, la chiave pubblica e altri dati rilevanti:

• fmt rappresenta il formato di attestazione, poiché gli autenticatori possono fornire dati di attestazione in modi diversi. Indica al server come dovrebbe convalidare i dati di attestazione. I valori consentiti sono "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" o "none". Vedi i dettagli qui
• attStmt è la dichiarazione di attestazione. Per le passkey, ad es. su dispositivi iOS o Android, viene lasciata vuota poiché le passkey su iOS o Android possono essere sincronizzate, e compilata per altri dispositivi come su Windows o chiavi di sicurezza hardware.
• authData è un buffer di valori contenente i seguenti dati:
  
  I dati della credenziale attestata giocano un ruolo importante qui. Contengono:
  • AAGUID,
  • lunghezza dell'ID della credenziale,
  • ID della credenziale e
  • Chiave pubblica della credenziale.

Contrariamente all'oggetto di attestazione sopra, dove attStmt è stato lasciato vuoto per motivi di leggibilità, ecco come apparirebbe una dichiarazione di attestazione compilata.

{
    "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 proprietà alg indica l'identificatore dell'algoritmo crittografico utilizzato dall'autenticatore per firmare la dichiarazione di attestazione.
• sig: La proprietà sig contiene la firma digitale generata dall'autenticatore. Questa firma viene utilizzata per verificare l'autenticità della dichiarazione di attestazione.
• ver: La proprietà ver specifica la versione del formato della dichiarazione di attestazione.
• x5c: L'array x5c contiene uno o più certificati X.509 che formano un percorso di certificazione, che aiuta a convalidare l'attestazione.
• pubArea: La proprietà pubArea contiene informazioni dettagliate sulla chiave pubblica e sulle caratteristiche dell'autenticatore.
• certInfo: La proprietà certInfo include tipicamente informazioni sulla certificazione dell'autenticatore da parte di una parte fidata.

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

Leggi di più su clientDataJSON nel rispettivo articolo del glossario.

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

La proprietà transports indica i meccanismi attraverso i quali un autenticatore può comunicare con un client. Alcune combinazioni di valori di esempio comuni sono:

• "transports": ["internal","hybrid"]: Le passkey possono essere utilizzate dall'autenticatore di piattaforma (ad es. Face ID, Touch ID, Windows Hello) o tramite l'autenticazione cross-device (utilizzando codice QR e Bluetooth).
• "transports": ["internal"]: Le passkey possono essere utilizzate dall'autenticatore di piattaforma (ad es. Face ID, Touch ID, Windows Hello)
• Nessuna proprietà transports impostata: comportamento predefinito che non fornisce indicazioni.

L'attestazione (la dichiarazione di attestazione) in WebAuthn è importante perché offre una prova dell'autenticità di un autenticatore. Garantisce che il processo di autenticazione sia eseguito da un dispositivo affidabile, proteggendo così da potenziali minacce alla sicurezza.

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

Sì, poiché le passkey possono essere sincronizzate tra dispositivi (ad es. da iPhone a MacBook tramite Portachiavi), le relying party non possono più determinare realmente quale dispositivo attestato sta effettuando l'accesso a un'app o a un sito web. Pertanto, Apple e Google hanno deciso che per le passkey sincronizzate non forniranno più dichiarazioni di attestazione. Tuttavia, per migliorare l'UX per le relying party e dare loro l'opportunità di riconoscere e visualizzare le passkey degli ecosistemi Apple e Google (Portachiavi iCloud e Google Password Manager), l'AAGUID sarà comunque fornito (a condizione che l'attestazione sia impostata su direct o indirect nelle impostazioni del server WebAuthn per PublicKeyCredentialCreationOptions. Vedi questo problema di GitHub per i dettagli.

Se vuoi integrare l'autenticazione con passkey nel tuo sito web e nella tua app, e vuoi offrire ai tuoi utenti un'ottima esperienza con le passkey, dovresti considerare quanto segue. Supponiamo che tu stia costruendo la tua soluzione principalmente per uno scenario in cui la maggior parte dei tuoi utenti utilizza un sistema operativo Windows, iOS, macOS o Android. Inoltre, supponiamo che la maggior parte delle passkey (a parte Windows) siano passkey sincronizzate. Poiché né iOS, né macOS, né Android inviano più una dichiarazione di attestazione, la vera convalida di un autenticatore non viene più utilizzata (per Windows questo funziona ancora, probabilmente perché Windows non offre ancora passkey sincronizzate tramite Windows Hello). Tuttavia, per ottenere l'AAGUID, ad esempio per una migliore gestione delle passkey nelle impostazioni dell'account, consigliamo di impostare la preferenza di attestazione su indirect, poiché ciò consentirebbe comunque di ottenere l'AAGUID mentre la dichiarazione di attestazione viene inviata (Windows) o non inviata (iOS, macOS, Android).

Il servizio di metadati FIDO fornisce un repository di metadati per vari autenticatori. Durante l'attestazione, questo servizio può essere interrogato per recuperare e convalidare i dettagli sull'autenticatore, garantendo l'accuratezza e migliorando l'affidabilità del processo. Il servizio di metadati FIDO controlla la dichiarazione di attestazione (non l'oggetto di attestazione).

Sì, l'attestazione diretta (nella dichiarazione di attestazione), pur offrendo la massima trasparenza fornendo informazioni dettagliate sul dispositivo, può sollevare preoccupazioni sulla privacy in determinati scenari. È fondamentale valutare la necessità di trasparenza rispetto alla privacy quando si sceglie il tipo di attestazione.

WebAuthn offre diversi tipi di preferenze di attestazione: none, indirect, direct ed enterprise. Per gli scenari in cui la privacy dell'utente è importante, si può impiegare attestation=none, che non fornisce dettagli sul dispositivo, garantendo che la privacy dell'utente rimanga protetta.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →