Holder binding spiegato: perché una credenziale copiata non vale nulla
Una credenziale firmata è un’ottima copia di sé stessa. Chi ne entra in possesso ha un documento con una firma valida dell’emittente, e verificando quella firma otterrà senza problemi la conferma che è autentico. L’holder binding chiude questa falla: lega la credenziale a una chiave che una sola persona può usare, così per presentarla non basta possederla.
Questa pagina ne è la versione in parole semplici. Spiega che cos’è davvero il legame, quando nasce, come lo realizza ciascuno dei due formati europei di credenziale e la parte che quasi tutte le spiegazioni tralasciano: ciò che l’holder binding continua a non dire al verificatore.
Il problema che risolve
I documenti digitali si copiano alla perfezione. La foto di un passaporto è una pessima contraffazione, perché la carta ha caratteristiche fisiche che una fotocopia perde. Una credenziale firmata non ha alcun segnale del genere. Copia il file e la copia si verifica esattamente come l’originale, perché la firma dell’emittente copre il contenuto e il contenuto non è cambiato.
Un verificatore che controlla solo la firma dell’emittente risponde quindi alla domanda sbagliata. Ha appreso che i dati sono autentici. Non ha appreso nulla sul fatto che la parte che ha davanti ne abbia diritto, che di solito è proprio ciò che aveva bisogno di sapere.
I dati
I fatti che la credenziale attesta: un nome, una data di nascita, una categoria di patente, un numero di registro delle imprese. È la parte a cui tutti pensano quando immaginano una credenziale.
La firma dell’emittente
La prova che quei fatti provengono dall’emittente e non sono stati modificati da allora. Non dice assolutamente nulla su chi li detiene ora.
La chiave pubblica del detentore
L’elemento che crea il legame. L’emittente scrive la chiave pubblica del detentore nella credenziale firmata, così la credenziale indica ora la chiave autorizzata a presentarla.
Quando nasce il legame e quando viene usato
Il legame si crea una sola volta, al rilascio, e viene messo in gioco ogni volta che la credenziale viene mostrata. Il detentore non ne vede nulla, a parte la richiesta di sblocco che già si aspetta.
1. Il wallet crea una chiave
Prima di chiedere qualsiasi cosa, il wallet crea una nuova coppia di chiavi nell’hardware sicuro del telefono. La metà privata non può essere riletta, nemmeno dall’app del wallet.
2. L’emittente la inserisce
Il wallet invia la metà pubblica con la sua richiesta e dimostra di possedere quella privata. L’emittente inserisce quella chiave pubblica nella credenziale prima di firmarla.
3. Un verificatore chiede
La richiesta contiene un nuovo valore casuale e indica chi la fa, così la risposta può essere usata una sola volta e solo dalla parte che l’ha richiesta.
4. Il wallet firma
Il wallet firma la risposta con la chiave privata, di solito dopo un’impronta digitale o un PIN. Il verificatore controlla quella firma con la chiave contenuta nella credenziale.
Dove si trova davvero la chiave privata
Il legame non vale mai più della difficoltà di usare la chiave senza il detentore. Per questo i wallet generano queste chiavi in hardware dedicato, il secure element o un equivalente che protegge anche i dati di pagamento del telefono, invece di salvarle come file che il sistema operativo può consegnare a qualsiasi app ne faccia richiesta.
Il verificatore non può vedere nulla di tutto questo nella presentazione stessa. Una firma dimostra che la chiave è stata usata, non che è stata custodita bene. Che la chiave si trovi davvero in hardware certificato è una garanzia distinta, fornita dalle attestazioni che un wallet presenta a un emittente prima di ricevere qualsiasi cosa. Secondo le regole europee, è proprio a questo che servono l’attestazione del wallet e l’attestazione della chiave.
L’holder binding risponde
Questa risposta è stata prodotta proprio ora, per questa richiesta, dalla chiave per cui questa credenziale è stata rilasciata?
L’attestazione della chiave risponde
Quella chiave è custodita in un luogo da cui un attaccante non può estrarla? Domanda diversa, prova diversa, decisa al rilascio.
Come lo fanno i due formati europei
L’idea è la stessa in entrambi i formati su cui si basa il wallet europeo. La meccanica è diversa, e questo conta per chi implementa un verificatore e per quasi nessun altro.
SD-JWT VC
L’emittente inserisce la chiave pubblica del detentore in un claim di conferma all’interno della credenziale firmata. Al momento della presentazione, il wallet aggiunge un piccolo token separato, firmato con la chiave privata, che copre l’identità del verificatore e il valore casuale della richiesta. Un verificatore che ignora quel token ha controllato l’emittente e nient’altro.
Leggi la definizionemdoc
La chiave del dispositivo è indicata nell’oggetto firmato che protegge gli elementi dati, e il telefono firma la trascrizione della sessione in corso. Poiché quella trascrizione copre lo scambio tra i due dispositivi, la registrazione di una presentazione non può essere riprodotta in un’altra. È questo che rende sicuro un controllo offline a bordo strada o a una porta.
Leggi la definizioneUn wallet dell’ecosistema europeo di solito porta la stessa attestazione in entrambi i formati e consegna quella che l’altra parte comprende. Un’organizzazione che accetta credenziali deve quindi saper verificare il legame in tutti e due.
Che cosa l’holder binding non dimostra
L’holder binding dimostra il controllo di una chiave. Non dimostra chi tiene in mano il telefono. Chi ha ricevuto il dispositivo e il PIN produce esattamente la stessa risposta valida del detentore legittimo, e nessuna crittografia nella credenziale può coglierne la differenza.
Né dice qualcosa su quanto accuratamente l’emittente abbia verificato l’identità prima del rilascio. Una credenziale legata a una chiave resta affidabile solo quanto il processo che l’ha creata, ed è questo che descrive un Level of Assurance. Legare con grande solidità a una chiave una credenziale rilasciata con poco rigore non rende più veri i dati che contiene.
Messi insieme, i ruoli sono abbastanza chiari. L’holder binding impedisce il riutilizzo e la copia, lo sblocco del wallet lega la chiave a una persona presente, il Level of Assurance descrive quanto bene quella persona è stata identificata e una trusted list stabilisce quali emittenti accetti in assoluto. Un verificatore che vuole una risposta vera ha bisogno di tutti e quattro, non solo di quello che arriva gratis con la credenziale.
Che cosa significa per te
Emittente
Le tue credenziali diventano inutili per chiunque ne rubi una copia, il che elimina un’intera categoria di frodi che altrimenti dovresti scoprire a posteriori. Il prezzo è che devi essere pronto a rilasciarle di nuovo ogni volta che un detentore cambia dispositivo.
Verificatore
Verifica il legame, non solo la firma dell’emittente. Invia un nuovo valore casuale a ogni richiesta e respingi ogni risposta che non lo firmi, altrimenti una presentazione registrata potrà esserti riproposta in seguito.
Titolare del wallet
Niente da gestire e una cosa da sapere: le tue credenziali sono legate a questo dispositivo, quindi con un nuovo telefono dovrai ottenerle di nuovo invece di ripristinarle da un backup.
Termini correlati
Domande frequenti
L’holder binding è la stessa cosa del key binding o del device binding?
In pratica sì. I termini diversi vengono da specifiche diverse, non da una differenza di significato. L’holder binding è la proprietà: questa credenziale appartiene a questo detentore. Key binding è il nome con cui il mondo SD-JWT VC chiama il meccanismo, mentre sul versante ISO si parla di device binding o device authentication, perché la chiave si trova in uno specifico telefono. Se un documento usa uno di questi termini, leggilo come la stessa idea vista da un’altra angolazione.
L’holder binding dimostra che chi presenta la credenziale è la persona a cui si riferisce?
No, ed è di gran lunga il fraintendimento più comune. Dimostra che chi ha prodotto la risposta controlla la chiave per cui la credenziale è stata rilasciata. Che la persona che tocca il telefono sia quella descritta dai dati dipende da come si sblocca il wallet, da quanto accuratamente l’emittente ha verificato l’identità all’inizio e dal fatto che il detentore abbia o meno ceduto il dispositivo e il PIN a qualcun altro. Per un controllo ad alto valore, si abbina il legame a un wallet che richiede la biometria e a una credenziale rilasciata con un Level of Assurance adeguato al rischio.
Che cosa succede a una credenziale legata quando il detentore cambia telefono?
Non si sposta. Il senso stesso di conservare la chiave privata in hardware sicuro è che non possa essere esportata, quindi una credenziale legata al vecchio telefono non può essere ripristinata sul nuovo aspettandosi che funzioni. Il nuovo dispositivo genera una propria chiave e la credenziale viene rilasciata di nuovo per quella. Pianifica il nuovo rilascio come un evento normale e frequente, non come un’eccezione, perché per i tuoi utenti è semplicemente il giorno in cui hanno cambiato telefono.
Esistono credenziali senza holder binding?
Sì, e hanno la loro utilità. Una credenziale senza holder binding è una credenziale al portatore: chi la presenta ne ottiene il beneficio, come con un biglietto di carta. È un compromesso ragionevole per qualcosa di poco valore e di breve durata, in cui il danno di una copia riutilizzata è modesto e si preferisce non chiedere al detentore di sbloccare nulla. È la scelta sbagliata per l’identità, i diritti e tutto ciò che un truffatore riterrebbe utile riutilizzare.
Fonti
- IETF SD-JWT-based Verifiable Digital Credentials (SD-JWT VC), ancora in bozza
- OpenID for Verifiable Credential Issuance, sulla prova di possesso della chiave al rilascio
- OpenID for Verifiable Presentations, sul legame tra una risposta e una singola richiesta
- ISO/IEC 18013-5, sull’autenticazione del dispositivo per i documenti mobili
Questa pagina è informativa e non costituisce consulenza legale. Per la formulazione ufficiale, consultare direttamente le specifiche.