CP-ABEMET nel Cloud: Dati Sicuri e Confronti Multipli a Prova di Futuro Quantistico!

Ciao a tutti, appassionati di tecnologia e sicurezza! Oggi voglio portarvi con me in un viaggio affascinante nel mondo della crittografia applicata al cloud computing. Immaginate un po’: le nostre città diventano “smart”, la sanità si digitalizza, i trasporti si ottimizzano, tutto grazie a una marea di dati raccolti da milioni di dispositivi. Fantastico, vero? Peccato che questi dispositivi, da soli, non abbiano la forza di processare questa enorme mole di informazioni. E qui entra in gioco il cloud, con la sua immensa capacità di archiviazione e calcolo. Ma, come dico sempre, ogni medaglia ha il suo rovescio: come proteggiamo la nostra privacy quando i dati sono lassù, sulla nuvola?

La Sfida: Crittografare Sì, Ma Poi?

La risposta più ovvia è: crittografiamo tutto prima di inviarlo al server cloud! Giusto. Però, una volta che i dati sono criptati, il server non può più leggerli. E se non può leggerli, come fa a eseguire ricerche o altre operazioni utili? È un bel dilemma. Per fortuna, la comunità scientifica non dorme sugli allori e ha sfornato soluzioni ingegnose come la crittografia ricercabile (searchable encryption) e il test di uguaglianza (equality test).

Quest’ultimo, in particolare, mi ha sempre incuriosito. L’idea di base, proposta da Yang e colleghi nel 2010, è quella di una crittografia a chiave pubblica (PKE) che permette di verificare se due messaggi criptati (ciphertext) nascondono lo stesso messaggio originale, senza doverli decifrare. Pensate alle applicazioni: social network dove trovare persone con interessi simili ai nostri senza svelare i propri dati, o sistemi sanitari intelligenti.

Però, anche le migliori idee hanno bisogno di evolvere. Prendiamo uno scenario con tanti utenti, ognuno con un proprio messaggio criptato. Se volessimo verificare se tutti i messaggi sono identici usando il PKEET tradizionale, il server dovrebbe fare un sacco di confronti a coppie. E se, per esempio, il primo messaggio fosse diverso dagli altri, che sono tutti uguali tra loro? Beh, il server potrebbe capire qualcosa di troppo, e questo non ci piace. Senza contare il costo computazionale che cresce con il numero di utenti.

PKEMET e CP-ABE: Due Alleati per la Sicurezza

Per risolvere questi problemi, Susilo e il suo team hanno introdotto il concetto di PKEMET (Public Key Encryption with Multi-ciphertext Equality Test). Con questo sistema, il server cloud può eseguire un singolo test per verificare se molti ciphertext nascondono messaggi identici, senza rivelare informazioni extra. Un bel passo avanti!

Ma non è finita qui. Quando condividiamo dati, vogliamo anche controllare chi può accedervi. Qui entra in gioco la CP-ABE (Ciphertext-Policy Attribute-Based Encryption), una tecnica che permette un controllo degli accessi granulare e flessibile. In pratica, i dati vengono criptati secondo una certa “policy” (politica di accesso) e solo chi possiede gli “attributi” giusti può decifrarli.

E se unissimo le due cose? Wang e colleghi ci hanno pensato, creando la CP-ABE con test di uguaglianza (CP-ABEET), che permette di verificare se ciphertext criptati con policy diverse contengono lo stesso messaggio. Molto utile, ma si poteva fare di più, soprattutto per il test su multipli ciphertext.

La Nostra Proposta: CP-ABEMET Basato su Reticoli

Ed è qui che entra in gioco il lavoro che voglio raccontarvi oggi: l’introduzione di un nuovo primitivo crittografico chiamato CP-ABEMET (CP-ABE with Multi-ciphertext Equality Test). L’idea è semplice ma potente: integrare i concetti di PKEMET e CP-ABE. Il risultato? Un sistema che permette al server cloud di eseguire un singolo test di uguaglianza su più ciphertext, anche se sono governati da policy di accesso distinte, mantenendo al contempo un controllo degli accessi granulare. E la ciliegina sulla torta? Lo abbiamo costruito usando la crittografia basata su reticoli (lattice-based), rendendolo resistente ai futuri attacchi dei computer quantistici!

Vi spiego a grandi linee come funziona. Immaginate dei mittenti che criptano i loro messaggi usando la chiave pubblica del destinatario e li caricano sul server cloud. Quando un destinatario vuole fare un test di uguaglianza, fornisce un “token” al server. Questo token permette al server di eseguire il test sui messaggi criptati, ma solo se gli attributi associati al token corrispondono alle policy di accesso dei ciphertext. E durante tutto questo processo, il server non impara nulla sui messaggi originali.

Il nostro schema non solo garantisce la sicurezza tradizionale come l’IND-CPA (indistinguibilità contro attacchi con testo in chiaro scelto) e l’OW-CPA (unidirezionalità contro attacchi con testo in chiaro scelto), ma è anche “number secure” (una proprietà specifica che abbiamo definito) e resistente agli attacchi di collusione.

Perché i Reticoli? La Minaccia Quantistica

Forse vi starete chiedendo: “Perché tutta questa enfasi sui reticoli e la resistenza quantistica?”. Beh, i computer quantistici, quando diventeranno abbastanza potenti, saranno in grado di rompere molti degli schemi crittografici attuali, quelli basati su problemi come la fattorizzazione di interi o il logaritmo discreto. La crittografia basata su reticoli, invece, si fonda su problemi matematici considerati “difficili” anche per i computer quantistici, come il problema LWE (Learning With Errors). Quindi, è fondamentale prepararsi per tempo!

Nel nostro schema CP-ABEMET, ogni ciphertext ha un “numero designato” (eta). Questo numero indica che il test di uguaglianza può essere eseguito solo su un gruppo di (eta) ciphertext, e tutti devono avere lo stesso numero designato. L’idea centrale si basa sulla condivisione di segreti di Shamir, dove (eta) è il numero designato e (beta) è il numero di ciphertext richiesti per effettuare il test.

Architettura del Sistema CP-ABEMET

Il sistema CP-ABEMET che abbiamo proposto coinvolge diverse entità:

• Key Generation Center (KGC): Un’autorità fidata che genera i parametri pubblici e le informazioni segrete per i proprietari dei dati, oltre alle chiavi segrete basate su attributi per i destinatari.
• Private Key Generation center (PKG): Un’altra autorità fidata che genera chiavi segrete basate sull’identità per i destinatari.
• Proprietari dei Dati (Data Owners): Definiscono chi può accedere ai dati, stabiliscono le policy di accesso, generano i ciphertext e li inviano al cloud.
• Destinatari dei Dati (Data Receivers): Ottengono le chiavi dal KGC e dal PKG, generano token per il test di uguaglianza e possono scaricare e decifrare i ciphertext.
• Server Cloud (CS): Archivia i dati criptati ed esegue i test di uguaglianza su richiesta, restituendo i risultati ai destinatari.

Il processo include algoritmi per la configurazione (Setup), la generazione di chiavi per proprietari (KeyGenDO) e destinatari (ExtractDR, KeyGenDR), la crittografia (Encrypt), la decifratura (Decrypt), l’autorizzazione tramite token (Aut) e il test di uguaglianza (Test).

Sicurezza Sotto la Lente

Abbiamo analizzato la sicurezza del nostro schema CP-ABEMET contro diversi tipi di avversari:

• Avversario di Tipo I: Non può eseguire test di uguaglianza sul ciphertext “sfida” e cerca di distinguere tra due possibili messaggi originali (IND-CPA).
• Avversario di Tipo II: Può eseguire test di uguaglianza e cerca di recuperare il messaggio originale (OW-CPA).
• Avversario di Tipo III: Può eseguire test di uguaglianza e cerca di fare un test su (beta) ciphertext il cui numero designato (eta) è maggiore di (beta) (Number Security).

Le prove formali dimostrano che il nostro schema è sicuro contro questi attacchi, basandosi sulla difficoltà del problema LWE e sulle proprietà delle funzioni hash utilizzate. Inoltre, abbiamo dimostrato la resistenza agli attacchi di collusione, dove più utenti malintenzionati cercano di combinare le loro informazioni per accedere a dati a cui non avrebbero diritto.

Un Confronto con l’Esistente

Quando mettiamo il nostro CP-ABEMET a confronto con altri schemi simili, emergono vantaggi significativi. Molti sistemi esistenti o espongono informazioni utente non necessarie, o hanno costi computazionali ridondanti, o richiedono la gestione di chiavi pubbliche enormi, o non sono resistenti agli attacchi quantistici. Il nostro schema, invece, affronta queste problematiche.
Certo, in termini di dimensioni dei dati (ciphertext, parametri pubblici, chiavi), il nostro schema basato su reticoli è un po’ più “costoso” rispetto ad alcuni schemi classici. Ma questo è un prezzo che, a mio avviso, vale la pena pagare per ottenere la resistenza quantistica.
In termini di efficienza computazionale per il test di uguaglianza, il nostro approccio è superiore perché esegue un singolo test su multipli ciphertext, eliminando la necessità di complesse operazioni di esponenziazione e pairing tipiche di altri schemi, specialmente quando si devono confrontare molti messaggi.

Conclusioni e Prospettive Future

Insomma, con questo schema CP-ABEMET basato su reticoli, abbiamo fatto un bel passo avanti. Offriamo un controllo degli accessi granulare e la possibilità di testare l’uguaglianza di più ciphertext in una singola operazione, il tutto con un occhio di riguardo alla sicurezza contro le future minacce quantistiche. Questo non solo migliora la sicurezza dei dati e l’efficienza dei test, ma previene anche la fuga di informazioni non necessarie.
Certo, la ricerca non si ferma qui. Stiamo già pensando a come migliorare ulteriormente lo schema, magari per raggiungere livelli di sicurezza ancora più alti (come la CCA2) o per ridurre le dimensioni dei dati. E poi, implementare questi schemi e definire parametri concreti per l’uso reale rimane una sfida aperta e stimolante.
Spero che questa panoramica vi abbia incuriosito tanto quanto questo campo di ricerca affascina me! Alla prossima!

Fonte: Springer