9 min di lettura
Come le passkey proteggono il vault dell'identità in CardanoWall
Una passkey non diventa la tua identità CardanoWall: sblocca un vault cifrato che solo i tuoi autenticatori possono aprire. Ecco come WebAuthn PRF rende l'accesso quotidiano semplice senza fare di CardanoWall un custode del seed.

Una passkey in CardanoWall non è la tua identità. È la chiave che sblocca una copia cifrata di essa. La tua identità vera è un Identity Seed da 32 byte; la passkey si limita a permettere al tuo dispositivo di aprire il vault cifrato che custodisce quel seed, così non devi incollarlo ogni volta che firmi o decifri qualcosa.
Face ID, Touch ID, Windows Hello, una passkey di piattaforma sincronizzata o una chiave hardware compatibile possono fare da porta d'ingresso quotidiana. Dietro quella porta c'è testo cifrato che il server di CardanoWall non può leggere. Questa separazione — il seed è l'identità, la passkey è solo un fattore di sblocco — è tutto qui l'impianto del sistema.
Quale problema risolvono davvero le passkey?
Rendono usabile nel quotidiano una conservazione robusta dell'identità.
Senza un livello di comodità, ogni utente di ritorno dovrebbe incollare il proprio Identity Seed ogni volta che vuole firmare o decifrare qualcosa. È sicuro in senso stretto, ma è scomodo — e una sicurezza scomoda tende a degenerare in una sicurezza che non è più tale. Le persone copiano i segreti nel posto sbagliato, li lasciano in note in chiaro o semplicemente smettono di usare lo strumento.
Le passkey eliminano questo attrito. CardanoWall conserva un vault cifrato per il tuo account, e il tuo dispositivo lo sblocca dopo un passaggio di verifica dell'utente (un'impronta digitale, una scansione del volto, un PIN, un tocco su una chiave hardware). Ottieni l'accesso con un solo tocco senza consegnare a CardanoWall una copia in chiaro del tuo seed.
Cos'è una passkey in questo contesto?
Una passkey è una credenziale WebAuthn — la stessa tecnologia di accesso a chiave pubblica che sta dietro all'«accedi con Face ID» del web moderno.
Nel modello FIDO e WebAuthn, una credenziale viene creata per una specifica relying party (qui, il dominio di CardanoWall), e la metà privata è tenuta da un autenticatore. Quell'autenticatore può essere integrato nel tuo telefono o portatile, sincronizzato tramite un provider di passkey o custodito su una chiave di sicurezza hardware separata.
Per il vault dell'identità, il semplice accesso non basta. CardanoWall ha bisogno che l'autenticatore rilasci nel browser del materiale segreto ad alta entropia, così che il browser possa decifrare il vault. È esattamente ciò che fornisce l'estensione WebAuthn PRF.
Cos'è WebAuthn PRF, in parole semplici?
PRF sta per pseudorandom function. Un autenticatore con supporto PRF può produrre un output segreto unico per una data credenziale, una data relying party e un salt fornito dall'applicazione — e produce lo stesso output ogni volta a parità di input.
CardanoWall deriva quel salt in modo deterministico dall'identificativo del tuo account, così l'output PRF è circoscritto al tuo account: la stessa chiave fisica collegata a un account diverso produce materiale diverso e non può aprire il vault sbagliato. Il browser usa poi l'output PRF come chiave che sblocca il tuo vault.
Il riassunto a livello utente è breve:
- l'autenticatore mantiene il proprio segreto e non lo esporta mai;
- il browser vede il materiale di sblocco solo durante la cerimonia stessa;
- il server conserva sempre e solo il testo cifrato del vault;
- il server non può riprodurre l'output PRF da solo.
È questo che trasforma la tua passkey in un fattore di sblocco per il vault, anziché in una copia del segreto che esso custodisce.
Cosa viene cifrato esattamente?
Il bundle dell'identità del tuo account.
Un solo account può contenere più identità. Il bundle registra l'Identity Seed di ciascuna identità e la sua label privata, e l'intero bundle viene cifrato prima di essere mai conservato. Il vault è una sola riga di testo cifrato per account — stato opaco del servizio, non custodia.
CardanoWall lo cifra come testo cifrato age-v1 indirizzato solo a stanze di
destinatario WebAuthn-PRF (fido2prf) — una stanza per ogni passkey registrata.
Una qualsiasi delle tue passkey registrate può aprire il vault dopo una cerimonia
riuscita; l'implementazione si rifiuta di costruire un vault che contenga qualsiasi
altro tipo di destinatario, così la cifratura resta solo-simmetrica per costruzione.
Se non c'è alcuna passkey registrata, non esiste affatto un percorso di apertura lato server — e va bene così, perché il seed stesso è la vera identità portabile. Puoi sempre ripristinare a partire dal seed.
Perché un vault avvolto da una passkey è più sicuro di uno protetto da password?
Perché non c'è una stanza derivata da password da forzare offline.
Quando un attaccante ruba un file protetto da una password scelta dall'utente, può provare a indovinarla in locale, alla massima velocità che il suo hardware consente. È il classico problema della forza bruta offline, e le password deboli o riutilizzate lo perdono.
Il vault ospitato di CardanoWall non è costruito attorno a una password. È avvolto attorno a materiale PRF custodito dall'autenticatore — una chiave casuale da 256 bit che risiede dentro il tuo dispositivo. Una fuga di dati dal database consegna quindi all'attaccante soltanto testo cifrato: nessun hash di password da attaccare, nessun seed da leggere. È anche il motivo per cui le passkey sono interessanti per l'accesso quotidiano in generale — aggirano il phishing e il riuso delle password tenendo al contempo il server completamente lontano dal segreto dell'identità.
E gli attacchi quantistici al vault?
Qui conviene essere precisi anziché drammatici.
Il vault ospitato non contiene deliberatamente alcuna stanza di destinatario a chiave pubblica asimmetrica. Questo conta perché l'attacco quantistico su larga scala che preoccupa le persone — l'algoritmo di Shor — prende di mira i sistemi a chiave pubblica. La riservatezza del vault è solo-simmetrica: l'output PRF da 256 bit di una passkey lo avvolge, e nel progetto non esiste alcuna chiave pubblica contro cui un attacco alla Shor possa puntare.
Contro una chiave simmetrica, l'accelerazione quantistica generica rilevante è la ricerca alla Grover, di solito descritta come un dimezzamento approssimativo del margine di sicurezza effettivo. Per una chiave da 256 bit questo lascia un margine effettivo di circa 128 bit — un numero ancora enorme.
Quindi l'affermazione onesta non è «gli attacchi quantistici sono impossibili». È più ristretta e più solida: il vault ospitato non ha superficie di forza bruta derivata da password, non ha alcun bersaglio a chiave pubblica per Shor e ha un margine di chiave simmetrica che resta molto alto anche sotto ipotesi di ricerca quantistica generica. Meno appariscente, ma è l'affermazione di cui un lettore attento alla sicurezza può davvero fidarsi.
Perché non usare semplicemente un wallet Cardano per lo sblocco?
Perché firmare una sfida non è una chiave di vault stabile.
Una firma del wallet è davvero utile per alcune affermazioni pubbliche, ma è una primitiva scadente per riderivare un segreto che deve decifrare lo stesso vault attraverso dispositivi, browser, versioni di wallet e variazioni del supporto hardware. Lega il tuo vault a un wallet e avrai silenziosamente trasformato il comportamento del wallet nel recupero dell'account.
CardanoWall tiene questi ruoli separati:
- l'Identity Seed deriva le tue chiavi di firma e di ricezione Label 309;
- le passkey sbloccano il vault ospitato;
- una firma del wallet Cardano è riservata a record espliciti e vincolati al wallet, quando scegli deliberatamente quel percorso.
Passkey sincronizzata o chiave hardware: quale dovrei usare?
Funzionano entrambe; la scelta giusta dipende dal valore dell'identità.
Le passkey sincronizzate sono la scelta predefinita più comoda. Possono ricomparire su un nuovo dispositivo tramite il tuo provider — un portachiavi del sistema operativo o un password manager, a seconda della tua configurazione — il che rende il recupero ordinario molto più facile. Una passkey sincronizzata eredita il modello di sicurezza e di recupero del provider che la custodisce.
Le chiavi hardware sono più controllate. Poiché l'accesso richiede il dispositivo fisico, sono adatte a identità di valore elevato o condivise da un team, dove vuoi che il fattore sia vincolato a qualcosa che puoi chiudere a chiave in un cassetto.
Una regola ragionevole: adatta lo stile di passkey a quanto vale l'identità. Per la maggior parte delle persone, una passkey di piattaforma sincronizzata va benissimo per l'uso quotidiano. Per identità di team sensibili, una chiave hardware più un seed conservato con cura è spesso il compromesso migliore. L'articolo sulle passkey sincronizzate rispetto alle chiavi hardware illustra le differenze in dettaglio.
E se il mio browser o la mia chiave non supportano PRF?
Allora CardanoWall ripiega sul percorso del seed — per scelta progettuale.
Il supporto a WebAuthn PRF dipende dalla combinazione di browser, sistema operativo e autenticatore. CardanoWall rileva automaticamente se quella combinazione è in grado di fare PRF prima di registrare un fattore di vault, così non vieni mai condotto dentro un vault che poi non riusciresti a sbloccare.
L'accesso solo-seed non è una modalità degradata. È il percorso sovrano: il seed è l'identità, e tutto il resto è comodità aggiunta sopra quando la piattaforma può supportarla in modo sicuro.
Cosa può ancora andare storto?
Le passkey chiudono un'ampia categoria di rischi, ma restano alcune realtà, ed è meglio nominarle chiaramente.
- Un seed rubato è una compromissione totale dell'identità. Chiunque possieda il tuo Identity Seed è quell'identità. La risposta è creare una nuova identità e disattivare quella vecchia — non un reset della password, perché non c'è alcuna password.
- Una sessione sbloccata è un bersaglio vivo. Mentre il vault è sbloccato, i tuoi seed e le chiavi private derivate risiedono nella memoria del browser così che tu possa firmare e decifrare. CardanoWall tiene quel materiale fuori dallo stato di React e lo azzera al blocco e alla disconnessione, per quanto possibile, ma uno script o un'estensione malevola in una sessione sbloccata può comunque leggere i segreti in memoria. Una content-security policy rigorosa e script minimi riducono quel rischio; non possono eliminarlo. Su una macchina che non controlli del tutto, blocca il vault quando ti allontani anziché lasciare aperta una sessione.
- Rimuovere una passkey non ha effetto retroattivo. Quando rimuovi un fattore, il client ricifra il vault ai fattori rimanenti e la vecchia riga di testo cifrato viene cancellata definitivamente, così la chiave rimossa non può più aprire il vault attuale. Ma se un attaccante ha già usato quella passkey prima che tu la rimuovessi, la rimozione non può annullare ciò che ha fatto. Vedi cosa succede se rimuovi una passkey.
- Perdi tutto e la porta sparisce. Se perdi ogni copia del seed e ogni fattore di sblocco, l'uso futuro di quell'identità è perso. Le prove che hai già pubblicato continuano a verificarsi per sempre — risiedono su Cardano, non nel tuo vault — ma non puoi più agire come quell'identità.
Le passkey riducono il rischio. Non eliminano la tua responsabilità di proteggere il seed e il dispositivo.
In breve
Le passkey rendono CardanoWall utilizzabile senza fare di CardanoWall un custode.
Il server conserva il testo cifrato del vault e nulla che possa decifrare. La tua passkey permette al browser di derivare il materiale che lo sblocca. Il tuo Identity Seed resta la radice portabile dell'intera identità. Salva il seed, poi affidati alle passkey per l'accesso quotidiano. Comodità sopra, sovranità sotto. Se vuoi capire perché il seed conta ancora anche con le passkey registrate, leggi perché l'Identity Seed conta ancora.
Approfondimenti
- W3C Web Authentication (WebAuthn) Level 3: w3.org/TR/webauthn-3
- FIDO Alliance — panoramica sulle passkey: fidoalliance.org/passkeys
- MDN — estensioni WebAuthn (inclusa PRF): developer.mozilla.org
- Yubico — una guida per sviluppatori all'estensione WebAuthn PRF: developers.yubico.com
- Lo standard Label 309: label309.org — codice open-source su github.com/cardanowall