Passkey device-bound vs. sincronizzate (SCA e Passkey I)

Panoramica: Autenticazione forte del cliente con passkey#

• Analisi dei requisiti PSD2 e SCA
• Cosa significano i requisiti SCA per le passkey
• Implicazioni di PSD3 / PSR per le passkey

1. Introduzione: Passkey device-bound vs. sincronizzate#

Nel nostro precedente post del blog sulle passkey e la PSD2, abbiamo discusso di come le passkey siano già utilizzate da Fintech come Revolut e Finom e di come migliorino la sicurezza digitale nel settore bancario.

Le passkey si presentano in due forme principali: passkey sincronizzate e passkey device-bound. Mentre le passkey sincronizzate consentono agli utenti di autenticarsi senza problemi su più dispositivi, le passkey device-bound sono strettamente collegate a un dispositivo per passkey come una chiave di sicurezza hardware o un autenticatore locale.

Con questa serie di quattro post del blog, vogliamo analizzare in modo approfondito come i diversi tipi di passkey (device-bound vs. sincronizzate) soddisfino i requisiti SCA e PSD2.

Questa prima parte della serie è interamente dedicata alla comprensione della differenza tra passkey device-bound e sincronizzate.

La seconda parte spiega in modo comprensibile cosa significano la PSD2 e la Strong Customer Authentication (SCA), delineandone anche lo sviluppo storico.

La terza parte della serie mostra come i diversi tipi di passkey soddisfino la SCA e cosa questo significhi per banche, fintech e istituti finanziari che pensano di adottare le passkey.

La quarta e ultima parte della serie conclude cosa significheranno in futuro PSD3 / PSR per la SCA e le passkey.

2. Strong Customer Authentication, PSD2 e passkey#

In seguito alla pubblicazione del nostro ultimo post sul blog, abbiamo ricevuto molte domande di follow-up in merito alla nostra posizione sulle passkey, in particolare in relazione alla SCA nell'ambito del framework PSD2. C'è un chiaro interesse nel comprendere non solo l'applicazione delle passkey, ma anche come si allineino ai Regulatory Technical Standards (RTS). Inoltre, le parti interessate sono curiose di conoscere le potenziali interpretazioni e le linee guida dei regolatori, inclusa l'Autorità Bancaria Europea (EBA), sull'uso delle passkey.

Riconoscendo ciò, miriamo ad approfondire come le passkey possano essere integrate all'interno della direttiva PSD2, degli RTS sulla SCA e a fornire chiarezza sulla nostra posizione in merito all'uso di questa tecnologia. Esploreremo anche le domande e risposte esistenti dell'EBA per far luce su come i regolatori e l'EBA potrebbero percepire le passkey. Questo esame non solo affronterà le distinzioni tra passkey sincronizzate e device-bound, ma anche le loro applicazioni pratiche per migliorare sia la sicurezza che l'esperienza utente.

Comprendendone le sfumature, le parti interessate possono prendere decisioni informate che non solo rispettino i severi requisiti della PSD2, ma sfruttino anche la più recente tecnologia di autenticazione per proteggere le transazioni digitali. La nostra discussione mira a illuminare ulteriormente il percorso per integrare le passkey nei processi di autenticazione, garantendo che le misure di sicurezza stiano al passo con l'evoluzione del panorama digitale.

Naturalmente, ogni entità regolamentata che rientra nella PSD2 deve prendere le proprie decisioni su come soddisfare gli obiettivi normativi, poiché ogni implementazione ha le proprie complessità. Questo approccio individuale riconosce che, mentre il quadro normativo fornisce uno standard uniforme, l'applicazione pratica di questi standard varierà in modo significativo tra le diverse organizzazioni a causa dei loro ambienti operativi unici, delle capacità tecnologiche e delle basi di utenti.

Pertanto, mentre i nostri approfondimenti mirano a guidare e informare, non sono prescrittivi. Ogni entità deve considerare le proprie circostanze specifiche e le sfide nell'integrazione delle passkey nei propri protocolli di sicurezza e di autenticazione.

3. Dalle passkey device-bound alle passkey sincronizzate#

Per comprendere la differenziazione tra passkey device-bound e sincronizzate, esploreremo brevemente come si è sviluppato l'ecosistema.

3.1 Cosa sono le passkey device-bound (passkey per singolo dispositivo)?#

Iniziamo esaminando la storia e l'evoluzione delle passkey device-bound prima di approfondirne i dettagli tecnici.

3.1.1 Storia delle passkey device-bound#

Storicamente, i meccanismi di autenticazione all'interno di WebAuthn (lo standard alla base delle passkey) erano strettamente accoppiati a dispositivi fisici: chiavi di sicurezza (es. YubiKey). Prima dell'adozione diffusa delle passkey, le credenziali FIDO2 associate a un singolo autenticatore rappresentavano lo standard di riferimento in materia di sicurezza. Queste credenziali sono collegate al dispositivo in cui risiedono. L'implicazione di questo collegamento era significativa: la credenziale non poteva essere trasferita o utilizzata al di fuori del suo hardware originale.

Questo approccio, pur migliorando la sicurezza localizzando il processo di autenticazione su un singolo dispositivo, ha inevitabilmente incontrato limiti pratici che ne hanno influenzato l'adozione diffusa, soprattutto tra i consumatori generici non tecnici. Gli utenti erano costretti ad avere a disposizione il proprio dispositivo di autenticazione per ogni tentativo di accesso, il che non solo limitava la mobilità dell'utente, ma sollevava anche preoccupazioni in scenari in cui il dispositivo veniva perso, danneggiato o non era immediatamente accessibile.

Inoltre, c'era anche riluttanza da parte dei consumatori a investire in hardware aggiuntivo. Storicamente, il possesso e l'utilizzo di chiavi di sicurezza dedicate è stato molto basso tra i consumatori in generale. La prospettiva di acquistare hardware specializzato per scopi di autenticazione, nonostante i suoi vantaggi in termini di maggiore sicurezza, non è stata ben accolta dalla maggioranza degli utenti B2C, che allo stesso tempo sono solitamente il bersaglio di ampie campagne di phishing o attacchi di credential stuffing.

3.1.2 Dettagli tecnici delle passkey device-bound#

Le passkey device-bound sono caratterizzate dalla loro specifica categorizzazione in credenziali rilevabili e non rilevabili (discoverable e non-discoverable), una distinzione che definisce principalmente la loro rilevabilità. Ma il fattore chiave che distingue le chiavi device-bound è racchiuso nelle proprietà delle credenziali WebAuthn, in particolare attraverso i flag isBackupEligible e isBackupSynchronized. Per le passkey device-bound, entrambi questi campi sono impostati a zero, a indicare che le credenziali non sono idonee per il backup o la sincronizzazione tra dispositivi. Queste caratteristiche sottolineano il loro legame intrinseco con il dispositivo fisico su cui sono state create, assicurando che la credenziale rimanga legata a e utilizzabile esclusivamente su quello specifico componente hardware.

Un esempio notevole di credenziali device-bound in pratica si osserva all'interno dell'ecosistema Windows. Le credenziali Windows Hello su Windows 10 e Windows 11 rimangono device-bound: Windows Hello stesso non sincronizza ancora le passkey tra i dispositivi. Tuttavia, Microsoft ha compiuto un primo passo significativo introducendo il salvataggio e la sincronizzazione delle passkey in Microsoft Edge (a partire da Edge 142). Questa sincronizzazione a livello di browser tramite Gestore password di Microsoft consente alle passkey di sincronizzarsi sui dispositivi Windows quando si utilizza Edge, in modo simile a come il Gestore delle password di Google abilita la sincronizzazione delle passkey nel browser Chrome su Windows. Ciò rappresenta un importante progresso nelle funzionalità delle passkey di Windows, sebbene sia specifico per il browser Edge piuttosto che per l'autenticatore di piattaforma Windows Hello. Le passkey di Windows Hello rimangono device-bound, ma questa integrazione di Edge fornisce un percorso pratico verso le passkey sincronizzate su Windows, mentre l'autenticatore della piattaforma stesso potrebbe evolversi per supportare la sincronizzazione in futuro.

D'altra parte, Google ha espresso una posizione chiara riguardo alle passkey non rilevabili, indicando che le passkey non rilevabili esistenti potranno rimanere non sincronizzate nelle implementazioni future. Questa decisione si allinea con il principio più ampio secondo cui le credenziali non rilevabili svolgono un ruolo cruciale in determinati contesti di sicurezza rimanendo strettamente device-bound e, non essendo rilevabili, non possono quindi essere utilizzate come passkey.

Al contrario, l'approccio adottato da Apple con macOS e iOS differisce in modo significativo. A differenza della strategia fissa e device-bound osservata con Windows e le chiavi non rilevabili di Google, l'ecosistema di Apple è molto più orientato a consentire solo passkey sincronizzate, specialmente su iOS, rendendo quindi impossibile creare una passkey device-bound tramite WebAuthn.

Questa segmentazione delle strategie sulle principali piattaforme illustra i diversi approcci alla gestione delle credenziali WebAuthn, in particolare se si considera l'equilibrio tra sicurezza, convenienza e accessibilità per l'utente. Mentre le passkey device-bound offrono un elevato livello di sicurezza assicurando che le credenziali non possano essere spostate o utilizzate in modo improprio al di fuori del dispositivo previsto, l'industria continua a evolversi, cercando soluzioni che mantengano gli standard di sicurezza senza compromettere l'esperienza e la mobilità dell'utente.

3.2 Cosa sono le passkey sincronizzate (passkey multi-dispositivo)?#

Anche qui diamo un'occhiata allo sviluppo storico delle passkey sincronizzate prima di analizzarne i dettagli tecnici. A volte le passkey sincronizzate vengono anche chiamate passkey sincronizzabili.

3.2.1 Storia delle passkey sincronizzate#

In seguito alla pubblicazione delle specifiche WebAuthn Level 2 e CTAP 2.1 tra la metà e la fine del 2021, il gruppo di lavoro WebAuthn ha lanciato una significativa iniziativa del settore volta a superare i principali ostacoli che impedivano allo standard WebAuthn di sostituire le password e di aumentarne l'adozione. Questa iniziativa si è concentrata su due aree critiche: eliminare il requisito per dispositivi di sicurezza hardware aggiuntivi e mitigare il rischio associato alla perdita dell'autenticatore, mantenendo al contempo la piena retrocompatibilità con gli standard esistenti.

3.2.1.1 Utilizzo di autenticatori di piattaforma come moduli hardware sicuri#

La prima sfida – sradicare la necessità di nuovo hardware – è stata affrontata attraverso l'utilizzo di autenticatori di piattaforma integrati presenti nei moderni dispositivi di consumo (es. Touch ID, Face ID, Windows Hello).

I dispositivi moderni sono sempre più dotati di moduli di sicurezza specializzati, come il Trusted Execution Environment (TEE) su Android, il Secure Enclave su iOS e macOS e il Trusted Platform Module (TPM) sui dispositivi Windows. Questi keystore di sicurezza integrati fungono da solida base per le passkey, funzionando di fatto come "chiavi di sicurezza" integrate. Questo approccio consente l'adozione diffusa della crittografia a chiave pubblica, un livello di sicurezza precedentemente raggiungibile solo tramite chiavi di sicurezza hardware esterne (es. YubiKey), e in gran parte limitato a individui o organizzazioni tecnicamente preparati all'interno di settori altamente regolamentati.

Sfruttando le capacità del TEE, del Secure Enclave o del TPM, i protocolli WebAuthn sono in grado di fornire meccanismi di autenticazione degli utenti forti e crittografici. Ora, sofisticati metodi di autenticazione sono resi facili da usare e accessibili al pubblico in generale, senza la necessità di hardware aggiuntivo e specializzato.

Questa evoluzione rappresenta un forte miglioramento nell'approccio alla sicurezza digitale, sottolineando il ruolo critico che le soluzioni di sicurezza incentrate sull'utente svolgono nel guidare l'adozione diffusa. Le organizzazioni che combinano passkey sincronizzate con flussi di creazione di passkey e di accesso tramite passkey ottimizzati registrano i tassi di adozione più elevati. Utilizzando le funzionalità di sicurezza dei dispositivi contemporanei, lo sforzo del settore ha affrontato con successo l'ostacolo iniziale della rimozione della necessità di hardware esterno.

Questo sviluppo è stato un passo cruciale in una nuova era dell'ecosistema di autenticazione digitale, in cui l'ampia applicazione della crittografia a chiave pubblica diventa direttamente applicabile a una vasta gamma di casi d'uso e, allo stesso tempo, semplifica l'autenticazione per gli utenti.

3.2.1.2 Sincronizzazione delle passkey nel cloud#

Per affrontare il rischio associato alla perdita del telefono cellulare e, per estensione, delle passkey memorizzate in esso, l'iniziativa del settore si è concentrata sull'abilitazione della sincronizzazione delle credenziali rilevabili nel cloud. Questo approccio ha effettivamente trasformato le credenziali dall'essere strettamente device-bound all'essere multi-dispositivo e, più accuratamente, legate all'account dell'utente con il proprio provider cloud, come iCloud per i dispositivi Apple o Google per i dispositivi Android.

Questa soluzione pratica significava che anche se il telefono di un utente veniva perso o sostituito, le credenziali stabilite in precedenza non sarebbero andate irrimediabilmente perse. Invece, queste credenziali potevano essere recuperate dall'account cloud dell'utente e sincronizzate su un nuovo dispositivo. Questo passaggio ha ridotto significativamente i disagi e i rischi per la sicurezza precedentemente associati alla perdita di un autenticatore fisico.

Sfruttando la sincronizzazione cloud, le passkey possono ora passare senza problemi tra i dispositivi di un utente, mantenendo la loro integrità e sicurezza indipendentemente dal dispositivo specifico in uso. Ad esempio, quando un utente accede a un sito web da un nuovo dispositivo, le credenziali disponibili nel suo account cloud possono essere suggerite automaticamente per l'autenticazione. Se necessario, queste credenziali possono essere trasmesse al nuovo dispositivo, mantenendo un'esperienza di autenticazione coerente e sicura su piattaforme e dispositivi diversi.

Questa transizione a credenziali associate all'account e sincronizzate nel cloud rappresenta un approccio pragmatico alla sicurezza digitale. Riconosce le realtà del moderno utilizzo dei dispositivi e il frequente verificarsi di sostituzioni di dispositivi, sia per smarrimento, danni o aggiornamenti. Legando le credenziali all'account cloud dell'utente (che si tratti di iCloud di Apple o dei servizi cloud di Google) la soluzione non solo mitiga il rischio associato alla perdita di un dispositivo, ma migliora anche la capacità dell'utente di gestire e recuperare la propria identità digitale su più dispositivi.

Questo sviluppo amplia di fatto l'applicabilità dei meccanismi di autenticazione forti e crittografici di WebAuthn, rendendoli più adattabili a scenari di utilizzo reali. Inoltre, garantisce che l'autenticazione forte sia accessibile e gestibile, non solo per coloro che hanno un background tecnico o per quelli in settori altamente regolamentati, ma per l'utente medio che naviga nel mondo digitale con più dispositivi.

3.2.2 Dettagli tecnici delle passkey sincronizzate#

Le passkey sincronizzate sono note anche come credenziali rilevabili o chiavi residenti (resident keys). Queste si distinguono dalle chiavi device-bound per due proprietà critiche: isBackupEligible e isBackedUp hanno valori diversi. Per le passkey sincronizzate, il flag isBackupEligible è impostato a 1, a indicare che queste credenziali sono idonee per il backup. A seguito della riuscita sincronizzazione nel cloud, anche il flag isBackedUp è impostato a 1, a conferma che la credenziale è stata sincronizzata correttamente. È importante notare che lo stato di sincronizzazione può cambiare nel tempo, riflettendo la natura dinamica dell'utilizzo e della gestione dei dispositivi.

Quando le piattaforme richiedono chiavi residenti, impostando il parametro "requireResidentKey" su required o preferred, le piattaforme che supportano i servizi cloud creano automaticamente passkey sincronizzate. Questo processo garantisce che gli utenti possano contare sul fatto che le proprie credenziali siano accessibili sui vari dispositivi. Su Windows, le passkey sincronizzate sono ora disponibili tramite Microsoft Edge/Gestore password di Microsoft (sincronizzazione a livello di browser), mentre le credenziali dell'autenticatore di piattaforma Windows Hello rimangono device-bound. Anche i gestori di password di terze parti (es. Dashlane, KeePassXC, 1Password) con capacità di gestione delle passkey forniscono la sincronizzazione tra piattaforme. Negli scenari in cui vengono utilizzate passkey sincronizzate, i flag isBackupEligible e isBackedUp sono impostati a 1, a indicare l'idoneità al backup e l'avvenuta sincronizzazione.

Inoltre, sebbene sia attualmente ancora possibile identificare l'autenticatore specifico in cui è stata memorizzata la passkey, l'assenza di un'attestazione per la maggior parte di queste credenziali significa che la loro origine non può essere verificata crittograficamente. Questo aspetto evidenzia un potenziale limite nel garantire il livello di sicurezza delle passkey sincronizzate esclusivamente tramite i meccanismi standard di WebAuthn.

Questo sviluppo delle passkey sincronizzate amplia essenzialmente l'ambito delle credenziali rilevabili integrandole in un framework di sincronizzazione basato su cloud. Rendendo queste chiavi idonee al backup e assicurandone la sincronizzazione tra i dispositivi di un utente, WebAuthn affronta due delle principali sfide dell'autenticazione digitale: il rischio di perdere l'accesso a causa di dispositivi persi e il disagio di gestire credenziali multiple device-bound.

3.3 Associazione al singolo dispositivo delle credenziali WebAuthn sacrificata per il bene superiore#

La transizione dalle passkey device-bound a quelle sincronizzate ha avviato un dialogo critico all'interno del gruppo di lavoro WebAuthn, incentrato sulla necessità di misure di sicurezza avanzate, sulle questioni legali coinvolte e su un compromesso che fosse sia a misura di consumatore sia sicuro.

L'adozione di passkey sincronizzate è stata celebrata per la sua promessa di migliorare la comodità e la sicurezza dell'utente attraverso funzionalità come la sincronizzazione cloud e la perfetta funzionalità multi-dispositivo. Tuttavia, ha introdotto un certo disagio tra alcune relying party (RP), specialmente per quanto riguarda le implicazioni per la sicurezza e la conformità in ambienti con requisiti elevati. L'essenza del dibattito riguardava il requisito di un meccanismo che garantisse che anche le passkey sincronizzate mantenessero un collegamento con dispositivi specifici, un concetto cruciale per le relying party che si occupano di transazioni sensibili o che operano secondo rigidi standard normativi.

Per le RP non in grado o non disposte ad adottare le passkey, l'assenza di un metodo affidabile per collegare queste credenziali a dispositivi specifici in applicazioni critiche ha posto una sfida significativa. Un tale meccanismo era considerato molto importante da alcune RP. La mancanza di questa capacità di collegamento al dispositivo, un'aspettativa che forse non era stata dichiarata esplicitamente ma che era certamente attesa, ha rappresentato una grave sorpresa e una violazione della fiducia dal loro punto di vista.

La discussione ha concluso che dovrebbe esserci un'armonizzazione degli interessi, ma che in un primo momento il bene superiore della diffusione delle passkey dovrebbe avere la precedenza. Nella discussione l'estensione devicePubKey è stata vista come un modo per affrontare tali preoccupazioni, ma in seguito è stata sostituita con supplementalPubKeys che adottano un approccio molto più ampio nell'attuale bozza di WebAuthn Level 3. Sfortunatamente anche questo approccio è stato interrotto nell'agosto del 2024.

3.4 Il meglio di due mondi: Passkey ed estensione supplementalPubKeys [deprecata da agosto 2024]#

Analizziamo come è stato formato il compromesso con l'estensione supplementalPubKeys e cosa significa questo da un punto di vista tecnico.

3.4.1 Da devicePubKey all'estensione supplementalPubKeys#

La discussione che circonda la transizione dall'estensione devicePubKey all'estensione supplementalPubKeys evidenzia la natura dinamica delle specifiche WebAuthn. Inizialmente, devicePubKey serviva per migliorare la sicurezza attraverso chiavi pubbliche device-bound, ma in seguito è stata sostituita dal suggerimento di supplementalPubKeys nella WebAuthn Level 3 Editor's Working Draft. Questa estensione più recente offre una soluzione più completa consentendo l'uso di chiavi multiple per migliorare i processi di autenticazione.

Il nocciolo del dibattito si è concentrato sul bilanciamento tra misure di sicurezza migliorate e la più ampia adozione e utilità pratica delle passkey su diversi dispositivi e piattaforme. L'estensione supplementalPubKeys rappresenta una combinazione di queste priorità, consentendo un'autenticazione più rigorosa. Ad esempio, accoglie normative che richiedono determinati standard di autenticazione consentendo ulteriori "sottochiavi" con dichiarazioni di attestazione. Queste chiavi possono segnalare la conformità ai requisiti di autenticazione, riducendo potenzialmente la necessità di ulteriori sfide di accesso in determinate condizioni (anche con le passkey).

Un esempio direttamente dalla bozza di WebAuthn:

"Supponiamo che una richiesta di accesso venga visualizzata su un sito web insieme ad alcuni segnali di geolocalizzazione che non sono stati mai visti prima per questo account utente e non rientrino nei tipici orari di utilizzo osservati per l'account. Il rischio può essere ritenuto sufficientemente elevato da non consentire la richiesta, anche con un'asserzione da parte di una credenziale multi-dispositivo da sola. Ma se può essere presentata anche una firma da una chiave supplementare device-bound che è ben consolidata per questo utente, allora ciò potrebbe far pendere l'ago della bilancia."

Durante la discussione è stato evidenziato che queste erano destinate solo a RP con requisiti di sicurezza estremamente elevati (es. nel contesto governativo).

Incorporando i feedback e affrontando casi d'uso specifici (tra cui le transazioni finanziarie regolamentate e la necessità di segnali device-bound in un ambiente di credenziali multi-dispositivo), la comunità WebAuthn mirava ad affrontare sia i problemi di sicurezza che di interoperabilità. L'estensione supplementalPubKeys è quindi un approccio che cerca di fornire solide funzionalità di sicurezza supportando al tempo stesso un'esperienza utente fluida e l'ampia compatibilità essenziale per l'adozione diffusa delle passkey. Si tratta di un'estensione completamente facoltativa che non interferisce con l'implementazione delle passkey che si è già vista negli ultimi 2 anni.

Questa evoluzione verso un framework più inclusivo e flessibile sottolinea l'impegno della comunità WebAuthn nel migliorare i metodi di autenticazione web anche per casi d'uso più rigorosi.

3.4.2 Dettagli tecnici di supplementalPubKeys#

L'estensione supplementalPubKeys introdotta in WebAuthn consente l'uso di coppie di chiavi aggiuntive accanto alla credenziale primaria.

Tratto dall'issue originale su GitHub

L'immagine mostra il concetto di supplementalPubKey tratto dall'issue originale su GitHub (pk = passkey, pspk = provider supplemental key, dspk = device supplemental key).

Ecco una ripartizione di come funziona e del suo utilizzo previsto:

Scopo e funzionalità di supplementalPubKey

• Rimane un'unica passkey centrale: È importante tenere presente che solo una passkey centrale rimane il metodo principale per l'autenticazione utente e le chiavi aggiuntive forniscono ulteriori livelli di sicurezza e garanzia. Questa struttura mantiene la semplicità e l'efficienza dell'utilizzo di una singola passkey di base per l'autenticazione su più dispositivi, garantendo un'esperienza utente fluida. Le chiavi supplementari, nel frattempo, servono a migliorare il contesto di autenticazione, offrendo alla Relying Party (RP) segnali aggiuntivi sull'ambiente di sicurezza o sulla conformità a standard di autenticazione specifici. Queste chiavi supplementari non sono metodi di autenticazione a sé stanti, ma piuttosto integrano la passkey primaria, rafforzandone l'affidabilità con l'evidenza dell'integrità del dispositivo.
• Chiavi Device-Bound: Queste sono legate specificamente a un dispositivo. Possono fornire garanzie che una richiesta di autenticazione provenga da un dispositivo fidato che è stato precedentemente autenticato. Non verranno sincronizzate in nessuna circostanza.
• Chiavi Provider-Bound: Queste chiavi hanno uno scopo "provider", il che significa che possono offrire garanzie aggiuntive basate sulle politiche del fornitore di autenticazione o sull'attestazione specifica del provider. Ad esempio, un provider potrebbe emettere una tale chiave solo dopo che un utente ha completato un livello superiore di autenticazione (come l'MFA).
• Chiavi pubbliche multiple: A differenza della sua predecessora, l'estensione devicePubKey, che consentiva una sola chiave pubblica device-bound, supplementalPubKeys consente l'inclusione di uno o due tipi di chiavi supplementari. Queste chiavi possono servire a scopi e ambiti diversi, vale a dire gli ambiti device-bound e provider-bound.

Casi d'uso ed esempi di supplementalPubKey

1. Sicurezza avanzata: Nelle situazioni in cui un sito web (relying party) deve aderire a determinati standard di sicurezza avanzati per l'autenticazione, è possibile utilizzare chiavi supplementari per soddisfare questi requisiti. Se questa chiave supplementare è stata vista e verificata dal sito in precedenza, potrebbe consentire all'utente di bypassare ulteriori sfide di accesso in quanto la continuità del dispositivo può essere confermata da segnali precedenti.
2. Gestione del rischio: Per le richieste di accesso che sembrano rischiose (es. provenienti da una nuova geolocalizzazione o ad orari insoliti), la presenza di una chiave supplementare device-bound che ha una storia di utilizzo con l'account dell'utente potrebbe ridurre il rischio percepito e consentire di procedere con la richiesta dove altrimenti sarebbe stata bloccata.

Aspetti tecnici di supplementalPubKey

• Nessun ID credenziale proprio: Le chiavi supplementari non sono credenziali utente e non hanno un proprio ID credenziale.
• Dichiarazioni di attestazione: Le chiavi supplementari possono avere facoltativamente un'attestazione. Queste sono fondamentali per comprendere la portata e il livello di sicurezza delle chiavi supplementari. Un'attestazione può indicare il livello di protezione di cui gode una chiave legata all'hardware, o le politiche per altri tipi di chiavi supplementari.
• Implementazione per Relying Party: Le relying party possono richiedere queste chiavi supplementari come parte del processo di autenticazione. Tuttavia, la complessità di dover gestire più chiavi e dichiarazioni di attestazione significa che questa estensione è la più adatta per le entità con specifiche esigenze di sicurezza, come banche o servizi operanti in base a rigidi requisiti normativi.

È fondamentale notare che, a partire da aprile 2024, l'estensione supplementalPubKeys non è stata adottata da alcun browser principale e le specifiche WebAuthn Level 3 sono ancora in fase di sviluppo e soggette a modifiche. Resta incerto se questa funzionalità sarà inclusa nella versione finale delle specifiche e la sua potenziale implementazione e adozione futura, poiché attualmente è solo nell'Editor's Draft.

3.4.3 Deprecazione di supplementalPubKeys nell'agosto 2024#

Ad agosto 2024, l'estensione supplementalPubKeys è stata ufficialmente interrotta. Il gruppo di lavoro WebAuthn ha deciso di rimuovere questa funzionalità a causa dell'insufficiente supporto. La deprecazione di questa estensione evidenzia anche una nuova direzione. Attualmente, la FIDO Alliance sta lavorando allo sviluppo di un approccio diverso per supportare le Relying Party con elevati requisiti di sicurezza. Si prevede che questa imminente soluzione colmerà le lacune lasciate dall'interruzione di supplementalPubKeys e offrirà nuovi metodi per rafforzare i processi di autenticazione in scenari in cui standard di sicurezza rigorosi sono critici.

Per maggiori dettagli sulla deprecazione, consulta la pull request ufficiale su GitHub per WebAuthn.

4. Come Corbado gestisce in pratica le differenze tra passkey device-bound e sincronizzate#

Comprendere le differenze tra passkey device-bound e sincronizzate è essenziale, ma le banche hanno anche bisogno di strumenti per operazionalizzare queste differenze su larga scala. La piattaforma di Corbado fornisce un'intelligence sull'affidabilità del dispositivo che classifica automaticamente i tipi di passkey e applica a ciascuno il giusto trattamento SCA.

Visibilità sull'affidabilità dei dispositivi per i tipi di passkey#

La dashboard Device Trust di Corbado mostra come le passkey device-bound e sincronizzate si comportino diversamente in produzione. Le passkey device-bound raggiungono percentuali di successo più elevate (99,1%) senza requisiti di step-up, mentre le passkey sincronizzate con segnali di affidabilità del dispositivo raggiungono il 98,4% con una piccola percentuale di step-up per i nuovi dispositivi.

La dashboard traccia anche la classificazione dei dispositivi, identificando quali dispositivi sono esclusivi per un singolo utente (92% nelle tipiche implementazioni per il settore bancario), quali sono condivisi tra due utenti (7%) e quali sono dispositivi condivisi/chioschi (0,8%). Questa classificazione confluisce direttamente nelle decisioni di conformità SCA.

Controllo basato su policy per diversi scenari passkey#

Piuttosto che trattare tutte le passkey allo stesso modo, le trust policy di Corbado consentono alle banche di applicare regole diverse in base al tipo di passkey, allo stato del dispositivo e al livello di fiducia. Le passkey device-bound sui dispositivi conosciuti ottengono un'autenticazione senza attrito, mentre le passkey sincronizzate sui nuovi dispositivi attivano una verifica di step-up: esattamente il tipo di approccio sfumato richiesto dal framework SCA della PSD2.

Ciò significa che le banche possono implementare con sicurezza le passkey sincronizzate per una migliore esperienza utente, mantenendo al contempo il rigido controllo dei dispositivi che le passkey device-bound forniscono per scenari ad alta sicurezza, il tutto gestito tramite la configurazione delle policy anziché flussi di autenticazione separati.

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 →

Domande frequenti#

In che modo le passkey device-bound migliorano la sicurezza?#

Le passkey device-bound sono credenziali WebAuthn strettamente legate al dispositivo su cui sono state create. A differenza delle passkey sincronizzate, rimangono su un singolo dispositivo, rendendole intrinsecamente più sicure per determinati casi d'uso:

• Nessun furto di credenziali: La chiave privata non lascia mai il dispositivo, quindi gli aggressori non possono intercettare le credenziali.
• Prevenzione dell'accesso non autorizzato: L'autenticazione avviene solo dallo specifico dispositivo in cui è stata creata la passkey.
• Nessuna dipendenza dal cloud: Elimina i rischi associati alle violazioni dei dati nel cloud o all'acquisizione di account.
• Elevata conformità in materia di sicurezza: Soddisfa rigorosi requisiti di autenticazione device-bound per settori regolamentati come i servizi finanziari (AAL3).

Il principale svantaggio è la limitata portabilità. Se il dispositivo viene smarrito, la passkey non può essere recuperata a meno che l'utente non ne registri una nuova su un altro dispositivo.

Perché sono state introdotte le passkey sincronizzate e quali sono i loro vantaggi?#

Le passkey sincronizzate (passkey multi-dispositivo) sono state introdotte per risolvere i problemi di usabilità delle passkey device-bound, in particolare la mancanza di portabilità e il potenziale blocco dell'account in caso di smarrimento di un dispositivo. I vantaggi principali includono:

• Autenticazione multi-dispositivo: Accedi agli account da più dispositivi senza registrare manualmente una nuova passkey per ognuno.
• Nessun rischio di perdere l'accesso: Viene eseguito il backup delle credenziali nel cloud (es. Portachiavi di iCloud, Gestore delle password di Google), garantendo il recupero in caso di smarrimento di un dispositivo.
• Migliore UX: Elimina gli attriti rimuovendo la necessità di trasferire o ricreare manualmente le credenziali.
• Nessun hardware aggiuntivo richiesto: A differenza delle chiavi di sicurezza hardware, le passkey sincronizzate utilizzano moduli di sicurezza integrati nel dispositivo.
• Forte sicurezza con la praticità del cloud: La crittografia end-to-end assicura che la chiave privata non lasci mai il dispositivo in formato non crittografato.

5. Conclusione#

Nella prima parte della nostra serie di 4 parti, abbiamo analizzato quali sono le differenze storiche e tecniche delle passkey device-bound e sincronizzate. Comprendere queste differenze ci aiuterà ad applicare di conseguenza i requisiti di PSD2 e SCA. Abbiamo anche dato un'occhiata a cosa potrebbe riservare il futuro analizzando gli ultimi cambiamenti nello standard WebAuthn Level 3 ancora in evoluzione.

Ecco i link alle altre parti della nostra serie:

• Parte 2 "Analisi dei requisiti PSD2 e SCA (SCA e Passkey II)"
• Parte 3 "Cosa significano i requisiti SCA per le passkey (SCA e Passkey III)"
• Parte 4 "Implicazioni di PSD3 / PSR per le passkey (SCA e Passkey IV)"