Traduzione italiana di " Universal Anonymous Signatures: bridging past, present, and future of anonymous authentication"
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
Firme anonime universali: un ponte tra passato, presente e futuro dell’autenticazione anonima
Di recente, abbiamo ottenuto che l’articolo “Foundations of Anonymous Signatures: Formal Definitions, Simplified Requirements, and a Construction Based on General Assumptions”, fosse accettato nell’ambito di FC’24, l’edizione 2024 della conferenza sulla crittografia finanziaria. Questo documento presenta le Firme Anonime Universali (UAS).
Siamo davvero entusiasti perché, oltre a colmare diversi sottocampi nel dominio dell’autenticazione anonima, UAS traccia la strada verso quello che crediamo possa essere (parte) del futuro dell’identità auto-sovrana e che sicuramente spingeremo per integrare nell’offerta di Atala.
Ma basta con l’introduzione. Di cosa tratta UAS?
Un po’ di storia
Nel 1985, David Chaum pensò per la prima volta a una credenziale crittografica che le persone potessero utilizzare senza rivelare la propria identità, ma dando comunque ai fornitori di servizi la certezza di parlare con una persona legittima. Sono state proposte molte varianti, di solito sfruttando il concetto di attributi attestati, che i proprietari delle credenziali possono scegliere selettivamente se rivelare o meno. Si tratta dei cosiddetti schemi di credenziali anonime (AC).
Nel 1991, Chaum e van Heyst hanno proposto le firme di gruppo (GS), che consentono ai membri di un gruppo in possesso di una credenziale di appartenenza di fare qualcosa di simile alle AC. Queste credenziali di appartenenza di solito non hanno attributi, ma le firme prodotte dagli schemi GS possono essere elaborate da un’entità fidata, che può estrarre l’identificatore del firmatario altrimenti anonimo.
Sia gli schemi AC che GS si basano su autorità che rilasciano le credenziali necessarie per l’autenticazione o la firma. Tale entità è stata eliminata nel 2001, quando Rivest, Shamir e Tauman hanno ideato gli schemi Ring Signature (RS), che possono essere visti come una sorta di firma di gruppo che non può essere de-anonimizzata e non richiede emittenti.
Così, in appena 16 anni, la comunità crittografica si è ritrovata con tre modi diversi ma simili per consentire agli utenti di autenticarsi in modo anonimo. E dal 2001 sono state proposte molte altre varianti, a volte trovando punti intermedi. Queste includono schemi di RS che permettono di collegare le firme, o firme di gruppo in cui solo gli utenti possono collegare le proprie firme.
Cosa risolve la UAS?
In realtà, non è solo che gli schemi AC, GS e RS (e le loro numerose varianti) hanno alcuni elementi in comune. Le loro stesse ragioni d’essere sono strettamente correlate. Consentire agli utenti di autenticarsi in modo anonimo, pur lasciando ai fornitori di servizi una sorta di controllo sulle informazioni che possono estrarre. Da un punto di vista teorico, ciò si riflette nel fatto che i modelli di sicurezza si assomigliano molto. Ad esempio, è sempre necessario pensare alle proprietà di anonimato, che consentono di capire cosa si può apprendere da una firma. E alle proprietà di non falsificabilità, che hanno varianti di tracciabilità e di non falsificabilità, che stabiliscono esattamente il tipo di garanzia di non falsificabilità che i verificatori (fornitori di servizi) e gli utenti possono aspettarsi, rispettivamente. Inoltre, esistono modi per costruire questi schemi a partire da elementi costruttivi molto simili.
Tuttavia, per qualche motivo, finora AC, GS, RS e altri sono stati studiati in modo indipendente. Inoltre, anche se all’interno di alcuni rami concreti, come GS, esistono modelli di sicurezza di riferimento, come la linea di lavoro “Foundations of Group Signatures”, non è sempre così. Anche avendo dei modelli di riferimento, questi modelli di sicurezza sono solitamente legati a un concreto compromesso tra privacy e utilità.
Un esempio pratico
Supponiamo di avere uno schema di CA che consente di rivelare selettivamente attributi arbitrari al momento della presentazione della credenziale. Ma poi volete riutilizzarlo in uno scenario in cui dovete anche collegare le presentazioni dello stesso utente (forse volete premiare questo utente con alcuni punti fedeltà, o forse questo utente vi sta spammando e volete bloccarlo!) In breve, si vuole aggiungere un qualche tipo di verificabilità. Questo cambiamento semplice a priori richiede un nuovo modello di sicurezza! Certo, se sapete come farlo, potete estendere quello precedente e, se siete fortunati, anche la costruzione che avevate prima può essere aggiornata facilmente. Ma se avete mai implementato questo genere di cose, sapete già che di solito è troppo sperare.
Un modello dinamico per i compromessi privacy-vs-utilità nell’autenticazione anonima
Richiedere un modello di sicurezza per ogni compromesso concreto tra privacy e utilità non è ovviamente l’ideale. Ed è proprio quello che volevamo risolvere, dato che questo tipo di requisiti vicini ma diversi sono piuttosto comuni nella pratica. Quindi, abbiamo creato UAS, un modello di sicurezza generico che può essere modificato qua e là, in modo da poterlo adattare alle esigenze del vostro caso d’uso, in termini di compromesso privacy-vs-utilità. Più in dettaglio, guardando da vicino, ci sono tre punti in cui si potrebbe voler adattare questo tipo di schemi di autenticazione anonima:
- Al momento dell’emissione: quando un utente richiede una credenziale, gli può essere richiesto di fornire credenziali di approvazione ottenute in precedenza che soddisfino la proprietà A o B - o non gli può essere richiesto affatto di fornire una credenziale!
- Al momento della firma: quando un utente vuole produrre una firma anonima (o presentare la propria credenziale), il verificatore può richiedere di sapere che gli attributi della credenziale soddisfano determinati criteri.
- Al momento della verifica: i verificatori possono richiedere che alcune informazioni possano essere estratte dopo la creazione della firma. Potrebbe anche non esserci alcun verificatore!
Questi diversi compromessi vengono catturati tramite “segnaposto funzionali” (i programmatori possono considerarli come funzioni astratte) in questi tre punti, che sono inseriti in un quadro di sicurezza che segue fondamentalmente il modello di anonimato e falsificabilità menzionato in precedenza. L’aspetto più importante per gli ingegneri è che, data una costruzione che si dimostra sicura secondo il nostro modello, devono solo specificare le funzioni concrete necessarie in ogni fase - emissione, firma e verifica -, e il gioco è fatto! La sicurezza deriva dalla sicurezza della costruzione principale.
Cosa c’entra questo con GS, AC o RS?
Domanda corretta! Volevamo essere certi che il nostro modello generale dichiarato fosse effettivamente generale. Quindi, come lo abbiamo fatto? Abbiamo dimostrato che, fornendo funzioni concrete al momento dell’emissione, della firma e della verifica, la nostra costruzione generica può comportarsi come uno schema GS, AC o RS. Più precisamente, dimostriamo che una tale variante della nostra costruzione è uno schema GS, AC o RS sicuro, secondo i loro noti modelli di sicurezza).
Naturalmente, le carte sono finite, quindi dimostriamo solo che GS, AC e RS di base possono essere costruiti a partire da una costruzione generica di UAS. Abbozziamo anche prove per varianti più avanzate, come GS con apertura dipendente dal messaggio, Firme private multimodali e Credenziali anonime revocabili. È facile immaginare molte altre varianti. Credenziali anonime con funzionalità di auditing estese, per esempio, o anche schemi di firma anonima con un compromesso tra privacy e utilità che non è ancora stato considerato nello spazio accademico.
Cosa c’è (o può esserci) dopo?
La prima cosa che avrete notato è che si tratta di un lavoro piuttosto teorico. Mentre sulla carta tutto sembra a posto, i problemi potrebbero apparire durante la codifica. Una preoccupazione legittima è quale sia la penalizzazione in termini di efficienza di una costruzione che può essere adattata a molti casi d’uso diversi. Si tratta di una preoccupazione molto ragionevole. Dopo tutto, gli schemi progettati con un unico scopo tendono a essere più efficienti. Per valutare meglio questo aspetto, stiamo lavorando a un prototipo. Inizialmente, vogliamo avere una libreria in grado di astrarre i dettagli interni e lasciare che gli sviluppatori si concentrino sull’implementazione dei segnaposto funzionali concreti a cui sono interessati. In seguito, vogliamo testare l’efficienza del risultato, a partire dalla nostra costruzione (al momento solo generica). Questo probabilmente sarà sufficiente per alcune applicazioni, ma non per tutte.
Il documento fornisce una costruzione generica basata sulla BBS+, sulla crittografia e su prove ZK generiche (non interattive). Questo va sicuramente bene se vogliamo ottenere affermazioni di tipo selettivo, ma probabilmente non è adatto se vogliamo dimostrare predicati più espressivi, ad esempio. Il passo successivo è quindi quello di pensare a costruzioni generiche alternative che siano più adatte a requisiti più espressivi.
Inoltre, da un punto di vista teorico, abbiamo molte idee per il futuro. Permettere agli emittenti e ai revisori di cambiare le loro funzioni, ad esempio. Al momento, se molti emittenti o revisori possono coesistere, ciascuno di essi si impegna a svolgere una funzione. Oppure adattare il modello a un contesto completamente dinamico, e molte altre ancora.
Come pensiamo di integrare UAS in Atala?
Come detto, stiamo lavorando a un’implementazione basata sulla nostra costruzione generica di BBS+, sulla crittografia (ElGamal) e sulle prove ZK (protocolli Sigma di base). Questo sarà il nostro punto di partenza, che ci permetterà di testare questa nuova tecnologia nello stack SSI fornito da Atala. Integrando UAS all’interno dello stack Open Enterprise Agent di Atala, saremo in grado di sfruttare tutti gli strumenti che Atala include e di iniziare a testare il comportamento di UAS in ambienti pronti per la produzione (con agenti, nodi, protocolli di comunicazione specifici per SSI, ecc.), nonché di adattarlo alle esigenze del mercato e dei team di ingegneri.
Tenete d’occhio i prossimi aggiornamenti!