PRETTINESS -- Privacy pResErving aTTrIbute maNagEment SyStem

1. Il Problema

Il contesto della ricerca è l'evoluzione dei quadri normativi europei, in particolare il regolamento eIDAS2 e il GDPR, che richiedono soluzioni di gestione dell'identità digitale (come il portafoglio digitale europeo EUDI) garantendo la privacy e la selettività nella divulgazione dei dati.

Sebbene esistano sistemi di credenziali basate su attributi (ABC) che permettono la divulgazione selettiva, la maggior parte delle implementazioni attuali richiede che gli utenti memorizzino e gestiscano le proprie credenziali crittografate direttamente sui propri dispositivi mobili. Questo approccio presenta diverse criticità:

• Rischio di perdita dei dati: Se il dispositivo viene perso o danneggiato, le credenziali potrebbero andare perse senza un backup sicuro.
• Limitazioni computazionali: I dispositivi mobili potrebbero avere risorse limitate per operazioni crittografiche complesse.
• Gestione delle revoca: Implementare meccanismi di revoca efficienti e privati è complesso quando i dati risiedono solo localmente.
• Mancanza di funzionalità nel framework ARF: Il documento critica l'attuale Architecture and Reference Framework (ARF) dell'EUDI Wallet, ritenendolo carente in termini di sicurezza e funzionalità pratiche, specialmente per quanto riguarda il backup e la gestione centralizzata delle credenziali senza compromettere la privacy.

2. Metodologia e Proposta (PRETTINESS)

Gli autori propongono PRETTINESS, un sistema di gestione degli attributi che bilancia l'approccio centralizzato (per facilità d'uso e backup) con quello decentralizzato (per la privacy).

Architettura del Sistema

Il sistema coinvolge quattro entità principali:

1. Utente (User): Possiede il dispositivo mobile e controlla le credenziali.
2. Servizio di Gestione degli Attributi (AMS): Un server centralizzato che memorizza le credenziali in forma crittografata e assiste nelle operazioni.
3. Emittente (Issuer): Emette le credenziali firmate.
4. Parte Affidabile (Relying Party - RP): Verifica le credenziali presentate dall'utente.

Meccanismi Crittografici Chiave

Per garantire la privacy anche contro un AMS "curioso" o parzialmente corrotto, PRETTINESS utilizza tre blocchi fondamentali:

• Crittografia Threshold (Soglia): Le chiavi private dell'utente sono divise tra il dispositivo mobile e il server AMS. Nessuna delle due parti possiede la chiave completa. Questo permette di:
  • Decrittazione assistita dal server: L'utente può decrittare le credenziali con l'aiuto del server senza rivelare al server quali attributi sta decrittando (grazie alla proprietà di blindness).
  • Firme Threshold: La generazione della firma per la presentazione avviene in modo collaborativo. Il server non vede il messaggio firmato, proteggendo la privacy della transazione.
• Rilevamento dei Cloni (Clone Detection): Se un attaccante clona la memoria del dispositivo mobile (es. dopo aver rubato il PIN), il sistema threshold rileva che la stessa chiave sta venendo utilizzata da due dispositivi diversi. Il server può quindi bloccare le operazioni future, limitando i danni a una singola sessione prima del blocco.
• Meccanismo di Revoca Privato: Il sistema supporta la revoca sia da parte dell'utente che dell'emittente. Utilizza token di revoca specifici che permettono di verificare lo stato di validità senza rivelare all'AMS quale credenziale specifica è stata revocata o presentata, a meno che non vi sia una collusione tra parti corrotte.

Modello di Sicurezza

Il sistema è modellato e provato nel modello di Componibilità Universale (Universal Composability - UC). Questo garantisce che il protocollo rimanga sicuro anche se eseguito in parallelo con altri protocolli o in ambienti complessi.
Il modello di minaccia considera:

• Un utente che può subire corruzione parziale (memoria clonata tra sessioni) o totale (PIN indovinato).
• Un AMS che è un avversario covert (nascosto): non agirà in modo malizioso se c'è una probabilità non trascurabile di essere scoperto e provato a un terzo (es. un giudice).

3. Contributi Chiave

1. Sistema Ibrido di Gestione: PRETTINESS offre un backup sicuro delle credenziali su un server centrale, risolvendo il problema della perdita dei dati, mantenendo al contempo la privacy degli attributi verso il server stesso.
2. Privacy contro l'AMS: A differenza di soluzioni cloud tradizionali che richiedono un server fidato, PRETTINESS garantisce che l'AMS non possa apprendere i valori degli attributi, né quale credenziale viene presentata o revocata, grazie all'uso di crittografia threshold cieca.
3. Gestione della Revoca Efficiente: Introduce un meccanismo di revoca che non richiede comunicazioni aggiuntive con l'emittente durante la verifica da parte della RP, mantenendo l'anonimato delle presentazioni rispetto all'emittente.
4. Prova di Sicurezza Formale: Viene fornita una dimostrazione rigorosa nel modello UC, definendo una funzionalità ideale ($F_{ideal}$) e mostrando che il protocollo reale la realizza in modo sicuro.
5. Analisi delle Prestazioni: Vengono forniti benchmark reali basati su implementazioni in Go e C, valutando tempi di calcolo e overhead di comunicazione.

4. Risultati ed Efficienza

Gli autori hanno valutato le prestazioni del sistema con scenari realistici (100 credenziali per utente, 10 attributi per credenziale, 1 milione di token di revoca).

• Tempi di Calcolo:
  • Le operazioni di firma e verifica RSA standard sono molto veloci (< 1 ms).
  • Le operazioni di decrittazione threshold richiedono circa 362 ms.
  • L'emissione completa di una credenziale (inclusa decrittazione e verifica) richiede circa 8,1 secondi (principalmente a causa della decrittazione degli attributi per verificarne il contenuto).
  • La presentazione di una credenziale richiede circa 5,7 secondi.
• Comunicazione:
  • Il download del backup completo (Get Creds) comporta un trasferimento di circa 3,9 MB per 100 credenziali.
  • L'aggiornamento del database di revoca (DB Update) è il collo di bottiglia principale, richiedendo il download di circa 32 MB per 1 milione di revoca. Gli autori suggeriscono di ottimizzare questo processo scaricando solo le revoca pertinenti all'utente specifico.
• Conclusioni sulle prestazioni: Sebbene i tempi di elaborazione siano accettabili per un'interazione utente-server, l'overhead di comunicazione per il database di revoca è significativo e richiede strategie di caching o aggiornamenti differenziali.

5. Significato e Impatto

Il lavoro di PRETTINESS è significativo per diversi motivi:

• Allineamento Normativo: Offre una soluzione tecnica concreta che soddisfa i requisiti di sicurezza e privacy dell'eIDAS2 e del GDPR, in particolare per quanto riguarda la gestione dei backup e la selettività dei dati.
• Superamento dei Limiti Attuali: Risolve il dilemma tra la necessità di un backup centralizzato (per la resilienza) e la privacy dell'utente, dimostrando che è possibile avere un server di gestione che non vede i dati sensibili.
• Sicurezza Pratica: L'introduzione del rilevamento dei cloni e del modello di avversario covert offre garanzie di sicurezza più realistiche rispetto ai modelli teorici puri, adattandosi a scenari reali dove i server potrebbero essere tentati di violare la privacy ma temono le conseguenze legali.
• Fondazione per Futuri Sviluppi: Il sistema è progettato per essere estendibile, con menzione di futuri lavori verso versioni post-quantum e ottimizzazioni delle prestazioni.

In sintesi, PRETTINESS rappresenta un passo avanti verso la realizzazione pratica di portafogli digitali europei sicuri, dove l'utente mantiene il controllo sulle proprie credenziali senza doverne sopportare l'intero onere di gestione e sicurezza locale.