💻 computer science

WebAuthn PRF-Based Vault Key Wrapping and Zero-Knowledge PWA Storage Architecture

Questo articolo presenta un'architettura di sicurezza lato client per i vault di credenziali basati sul web che ottiene forti proprietà di zero-knowledge combinando l'estensione PRF di WebAuthn con la crittografia simmetrica e modelli di archiviazione del browser ottimizzati.

Autori originali: Ian Pinto

Pubblicato 2026-07-08✓ Author reviewed ⓘ

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Ian Pinto

Articolo originale sotto licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere una cassaforte digitale (una "vault") dove conservi i tuoi segreti più importanti, come password o note private. Di solito, per aprire questa cassaforte serve una chiave maestra (una password). Ma cosa succederebbe se potessi aprirla usando il tuo volto, la tua impronta digitale o una chiave di sicurezza fisica? E se, anche se un hacker rubasse una copia del contenuto della tua cassaforte, non riuscisse comunque a leggere una singola parola senza la tua specifica chiave biometrica?

Questo articolo di Ian Pinto descrive un nuovo modo per costruire una cassaforte digitale di questo tipo, ultra-sicura, per i browser web. Combina alcuni concetti tecnologicamente avanzati in un sistema che mantiene i tuoi dati "zero-knowledge" (a conoscenza zero) — il che significa che il server o il sistema di archiviazione non sanno nulla di ciò che c'è all'interno, nemmeno la chiave per aprerlo.

Ecco come funziona, suddiviso in parti semplici:

1. La Chiave Magica: WebAuthn PRF

Pensa alla tua passkey (quella che usi per accedere con il volto o l'impronta digitale) non solo come un guardiano "Sì/No", ma come un generatore di ricette segrete.

Il Vecchio Modo: Dimostri di essere tu, e il sistema dice "Accesso Concesso".
Il Nuovo Modo (PRF): Quando dimostri di essere tu, il tuo dispositivo esegue segretamente una complessa ricetta matematica (chiamata Funzione Pseudo-Casuale o PRF) utilizzando un "sale" speciale (un ingrediente casuale). Questa ricetta produce una "salsa segreta" unica e di alta qualità (un codice a 32 byte) che solo il tuo specifico dispositivo sa come preparare.
Il Problema: Questa salsa segreta viene creata all'interno del chip sicuro del tuo dispositivo. Non lascia mai il dispositivo e non viene mai salvata sull'hard disk. Esiste per un istante fugace, il tempo necessario per sbloccare la tua cassaforte, e poi viene immediatamente cancellata.

2. Il Lucchetto: Avvolgere la Chiave della Cassaforte

La tua cassaforte ha una chiave maestra (chiamiamola Chiave K) che effettivamente blocca i dati.

Il sistema prende quella salsa segreta fugace dalla tua passkey e la usa per avvolgere la Chiave K in una busta digitale (crittografia).
Una volta avvolta, la Chiave K viene chiusa dentro questa busta. Il sistema salva questa busta nella memoria del tuo browser (IndexedDB).
Punto Cruciale: Il sistema non salva mai la salsa segreta o la Chiave K non avvolta. Salva solo l'involucro chiuso. Se un hacker ruba l'archiviazione, avrà solo una scatola chiusa senza chiave.

3. La Casa Sicura: Archiviazione IndexedDB

L'articolo propone un modo specifico per organizzare questi dati nell'archiviazione del browser (IndexedDB), che è come un archivio digitale.

Il Sistema di Archiviazione: Il sistema crea tre cartelle specifiche:
1. Le Vault (Le Cassaforti): Dove vivono le buste chiuse (le chiavi avvolte).
2. Le Credenziali: Un elenco delle tue passkey e dei loro "numeri di serie" (per assicurarsi che nessuno stia usando una copia falsa della tua chiave).
3. I Meta: Note generali per l'app.
Garanzia Zero-Knowledge: L'articolo sostiene che poiché l'archiviazione contiene solo le buste chiuse e i metadati pubblici, un ladro che ruba l'intero archivio non può ricostruire la chiave. Rimarrà bloccato con la scatola chiusa e nessun modo per aprirla senza il tuo dispositivo fisico.

4. Il Piano di Riserva: Il "Fallback della Password"

E se il tuo browser non supportasse questa sofisticata funzione di "salsa segreta" (come su alcuni tablet Android)?

Il sistema ha un piano di riserva chiamato pw-v1. Inveve di usare la salsa segreta della passkey, utilizza un puzzle matematico molto lento e pesante (scrypt) basato su una password tradizionale che digiti.
È più lento e meno conveniente, ma garantisce che tu possa comunque aprire la tua cassaforte anche se la funzione hardware avanzata non è disponibile. È come avere una serratura fisica accanto allo scanner biometrico.

5. Controlli di Sicurezza: Fermare gli Attacchi di Replay

L'articolo enfatizza un "controllo di replay".

Immagina che un ladro registri il tuo segnale di "sblocco" e provi a riprodurlo in seguito per aprire la cassaforte.
Il sistema tiene un contatore (come il contatore dei chilometri su un'auto). Ogni volta che sblocchi la cassaforta, il contatore sale. Se il sistema vede un segnale con un numero di contatore vecchio, sa che si tratta di una registrazione e la rifiuta.
Nota: L'articolo ammette che questo non è perfetto per tutti i dispositivi (alcune passkey sincronizzate non aggiornano il contatore), ma aggiunge uno strato di difesa.

6. Cosa questo articolo NON fa

L'autore è molto attento a specificare contro cosa non protegge questo sistema:

Non protegge da un virus sul tuo computer. Se un hacker è già all'interno del tuo browser mentre stai digitando, può rubare la chiave mentre viene utilizzata. Questo sistema protegge solo i dati "a riposo" (quando sono fermi nell'archiviazione).
Non protegge dai leak "side-channel". Se l'app comprime i dati prima di bloccarli, o se la dimensione della scatola chiusa cambia in base alla lunghezza della tua password, un hacker esperto potrebbe indovinare cosa c'è dentro semplicemente misurando la dimensione della scatola. L'articolo avverte gli sviluppatori di aggiungere del "padding" ai propri dati (rendere tutte le scatole della stessa dimensione) per evitare questo.

Riassunto

Questo articolo presenta il progetto per una cassaforte per password basata sul web che è matematicamente provata come illeggibile per chiunque non possieda la tua specifica passkey fisica. Utilizza la tua passkey per generare un codice temporaneo e unico che blocca i tuoi dati, assicura che quel codice non venga mai salvato e organizza l'archiviazione in modo che anche un furto totale del database non fornisca altro che scatole chiuse. È un sistema "Zero-Knowledge" dove il fornitore dell'archiviazione (o un hacker) non sa nulla dei tuoi segreti.

Sintesi Tecnica: Architettura di Archiviazione per PWA con Chiave di Vault Avvolta tramite PRF di WebAuthn e Zero-Knowledge

Problematica
Il documento affronta la sfida di implementare una sicurezza zero-knowledge robusta per i vault di credenziali all'interno delle Progressive Web Applications (PWA). Sebbene WebAuthn e le passkey forniscano un'autenticazione a chiave pubblica forte, esse tradizionalmente non espongono un segreto simmetrico ad alta entropia all'applicazione web per la cifratura dei dati dell'utente. Le soluzioni esistenti spesso si affidano alla fiducia lato server o a password master, che possono essere vulnerabili ad attacchi offline o richiedere modelli di fiducia complessi. Il problema specifico è come derivare in modo sicuro una chiave di cifratura simmetrica da una credenziale passkey utilizzando l'estensione WebAuthn PRF (Pseudo-Random Function), avvolgere una chiave di vault e archiviare lo stato risultante nell'archiviazione del browser (IndexedDB), in modo tale che i dati persistiti non rivelino nulla dei segreti dell'utente senza una cerimonia di autenticazione live sull'autenticatore.

Metodologia
L'architettura proposta combina l'estensione WebAuthn PRF con la crittografia simmetrica e uno schema di archiviazione IndexedDB rigorosamente progettato.

Schema di Key Wrapping (Avvolgimento della Chiave):
- Enrollment (Registrazione): Durante la registrazione, l'applicazione richiede un output PRF di 32 byte dall'autenticatore utilizzando un salt unico e casuale di 32 byte. Questo output funge da Input Keying Material (IKM) per HKDF-SHA256.
- Derivazione: L'HKDF utilizza un'etichetta di separazione del dominio versione e congelata ("webauthn-prf-zktv vault key wrap v1") e un salt vuoto per derivare una chiave di wrapping $K_w$ AES-256-GCM non estraibile.
- Cifratura: La chiave del vault ( $K_v$ ) viene cifrata utilizzando $K_w$ e un nonce fresco di 96 bit.
- Archiviazione: Viene persistito solo il WrappedSecretRecord risultante. Questo record contiene l'identificatore dello schema (prf-v1), il ciphertext, il nonce e il salt PRF. Fondamentalmente, l'output PRF e la chiave di wrapping derivata non vengono mai memorizzati; vengono azzerati in memoria immediatamente dopo l'uso.
- Fallback: Per i client in cui la PRF non è disponibile (ad esempio, Android WebView), viene fornito uno schema pw-v1. Questo utilizza una derivazione scrypt con costo di memoria (con parametri a costo elevato fissi) da una password dell'utente invece della PRF, mantenendo la stessa struttura del record.
Unwrapping (Svolgimento) e Verifica:
- Protezione dal Replay: Il processo di svolgimento include un passaggio obbligatorio di verifica del replay. L'applicazione rivaluta la PRF con il salt memorizzato e verifica i dati del client (challenge, origin) e il contatore della firma. Il contatore deve essere strettamente crescente (a meno che non sia zero, un comportamento noto delle passkey sincronizzate) per prevenire attacchi di replay.
- Gestione degli Errori: Il sistema è progettato per essere generico nei modi di fallimento. Gli errori di decifrazione (dovuti a una chiave errata o manomissione) sollevano un generico DecryptError che non distingue tra una chiave errata e dati corrotti, prevenendo la fuga di informazioni tramite side-channel.
Architettura di Archiviazione (IndexedDB):
- La libreria (webauthn-prf-zktv) definisce uno schema con tre object store: vaults, credentials e meta.
- Lo store vaults utilizza una chiave primaria composta [vaultId, scheme], consentendo a un singolo vault di contenere simultaneamente un record prf-v1 e un record di fallback pw-v1.
- Lo store credentials contiene metadati non segreti, inclusi l'ultimo contatore di firma verificato e il salt PRF, ma mai le chiavi segrete stesse.
- Lo schema impone invarianti strutturali (ad esempio, lunghezza del nonce, dimensione del salt) ad ogni caricamento per garantire l'integrità dei dati.

Contributi Chiave
Il documento formalizza e fornisce un'implementazione open-source di:

Uno Schema di Vault Key Wrapping basato su PRF: Un metodo per utilizzare l'output PRF di WebAuthn come radice di fiducia per derivare una chiave di wrapping simmetrica, utilizzando HKDF con una rigorosa separazione del dominio.
Uno Schema IndexedDB Zero-Knowledge: Un pattern di archiviazione dove lo stato persistente non contiene input di chiave ricalcolabili. La sicurezza dei dati archiviati dipende interamente dal segreto della chiave interna dell'autenticatore.
La Libreria webauthn-prf-zktv: Una libreria TypeScript riutilizzabile e tipizzata che incapsula la logica crittografica, la gestione della memorizzazione e i percorsi di migrazione (inclusa un'adapter a passaggio singolo per i record legacy di TrustVault-PWA).
Verifica del Replay Lato Client: L'integrazione dei controlli del contatore della firma e della verifica di challenge/origin direttamente nell'algoritmo di sblocco del vault, una funzionalità spesso omessa nelle librerie helper PRF generiche.

Risultati e Valutazione
Il documento valuta l'architettura su tre assi:

Sicurezza: L'argomento zero-knowledge postula che senza l'autenticatore, il ciphertext memorizzato è computazionalmente inutile. Lo schema si basa sulla pseudo-casualità della PRF dell'autenticatore, sulla sicurezza di HKDF-SHA256 e sulla sicurezza IND-CPA/INT-CTXT di AES-256-GCM. Il documento nota che, sebbene lo strato simmetrico sia post-quantum adeguato (AES-256), lo strato di autenticazione asimmetrica rimane vulnerabile agli attacchi quantistici, sebbene ciò non comprometta la riservatezza della chiave del vault memorizzata.
Prestazioni: La latenza di sblocco è dominata dal gesto di verifica dell'utente richiesto dall'autenticatore. Le operazioni crittografiche (derivazione HKDF e decifrazione AES-GCM di un payload di 32 byte) sono trascurabili. Il fallback della password (scrypt) è intenzionalmente costoso per deterre gli attacchi offline, sebbene possa causare latenza su dispositivi mobili di fascia bassa.
Usabilità e Robustezza: Il sistema supporta una degradazione aggraziata tramite il fallback pw-v1 per i client non supportati. Utilizza un approccio "best-effort" per il rilevamento delle credenziali clonate (gestendo il caso limite del contatore zero delle passkey sincronizzate) e assicura che i fallimenti parziali (ad esempio, crash durante l'aggiornamento del contatore) non blocchino permanentemente l'utente, dando priorità alla disponibilità rispetto alla protezione rigorosa dal replay in casi limite.

Significatività e Rivendicazioni
Il documento sostiene di fornire un pattern pronto per la produzione per ottenere l'archiviazione zero-knowledge nelle applicazioni web utilizzando la moderna tecnologia delle passkey. La sua significatività risiede nel:

Rimuovere la Fiducia del Server: Sposta il confine della riservatezza interamente sul client, garantendo che anche se il server o un backup sincronizzato venissero compromessi, i segreti dell'utente rimangano sicuri a condizione che l'autenticatore non sia compromesso.
Standardizzazione dei Pattern: Definendo un formato v1 congelato e specifiche etichette di separazione del dominio, previene l'invalidazione silenziosa dei record dovuta a cambiamenti di algoritmo e fornisce un percorso di migrazione chiaro per versioni future (ad esempio, prf-v2).
Sicurezza Olistica: Affronta esplicitamente i vettori di fuga non crittografici (come la compressione pre-cifratura e la correlazione della dimensione del record) nella guida all'applicazione, riconoscendo che lo strato di archiviazione da solo non può garantire lo zero-knowledge se l'applicazione perde metadati.

L'autore sottolinea che la libreria è uno strumento per consentire agli sviluppatori di adottare questi pattern senza dover ridefinire la complessa igiene delle chiavi e la disciplina di archiviazione richieste per i vault sicuri lato client.