La verificabilità (verifiability) di una computazione, provata da un soggetto a un altro, dimostra che questa sia avvenuta come programmato (rispettando l’accordo, dunque fedelmente o faithfully) senza compromettere la segretezza del dato.
Mi spiego meglio.
La coputation veriafiability è un’importante nozione nell’applicazione di tecniche di tutela della privacy, e cioè delle Privacy Enhancing Technology.
Devi considerare una cosa.
Il motivo di fondo per cui un simile sistema è necessario è presto detto.
In fin dei conti, per quanto avanzato un sistema possa essere, dovrà comunque rendere conto a un umano, un essere senziente che pretende (a volte giustamente) una prova concreta di quanto eseguito.
Questo è particolarmente vero per le reti neurali profonde, il cui comportamento è spesso descritto dal modello black-box.
I dati entrano, subiscono trasformazioni, ed esce una previsione che andrebbe presa per vera, affidando piena fiducia alla rete.
Immedesimati nel direttore di un fondo d’investimenti multimiliardario a cui una deep neural network consiglia, con sorpresa, di vendere diverse posizioni per alcune centinaia di milioni. (i.e. Prevedendo una diminuzione significativa dei valori azionari di alcuni titoli)
Prima di eseguire una simile operazione, sarebbe preferibile avere una prova, una spiegazione del perché il modello abbia eseguito quella previsione.
Lo stesso vale in molteplici ambiti.
Capiamolo meglio.
Privacy Preserving Verifiability
Nel nostro percorso alla scoperta delle Privacy Enhancing Technologies, abbiamo in passato esaminato le potenzialità del Federated Learning.
In questo contesto, la verifiability può essere usata da entrambe le parti:
- Il server garantisce ai client che le operazioni (e.g. aggregazione dati, mescolamento dei messaggi o applicazione della differential privacy) siano state eseguite fedelmente.
- I client provano al server che i loro dati rispettino le specifiche del protocollo (e.g. gli input hanno uno specifico range, o che i dati siano stati correttamente cifrati)
Ora la domanda emerge spontanea.
Come facciamo, in pratica, a raggiungere la tanto necessaria verificabilità computazionale?
Esistono alcuni metodi e noi ne vedremo due:
- Zero-knowledge proofs (ZKPs)
- Trusted Execution Environments (TEEs)
Iniziamo dal primo.
Zero-Knowledge Proofs (ZKPs)
Zero knowledge proofs (ZKPs) è una primitiva crittografica (i.e. un elemento base della crittografia) che permette a un soggetto definito prover di provare affermazioni a un altro soggetto definito verifier, che dipendono da informazioni segrete conosciute al prover, e definite witness, senza tuttavia rivelarle al verifier.
Intrigante.
In termini semplici, Zero Knowledge Proof può essere descritto come un metodo matematico per provare qualcuno che sei in possesso di un’informazione, senza tuttavia rivelarla.
In effetti Zero knowledge proofs risolvono il problema della verificabilità su dati privati.
Immagina che un gruppo di ragazzi entri in un bar e ordini un alcolico al banco.
Il barista, responsabile e attento, deve verificare che abbiano l’età sufficiente.
Ecco il problema: se i ragazzi presentassero il documento d’identità, non avrebbero un facile modo per nascondere tutte le informazioni fuorché la data di nascita.
Attraverso metodi come il Zero Knowledge Proof siamo in grado di provare che un valore (e.g. l’età) sia superiore a una certa soglia (e.g. 18 anni) senza tuttavia rivelare il valore esatto.
Properties of Zero Knowledge Proofs
Le prestazioni sono oggi stupefacenti, con la possibilità di gestire proof sizes nell’ordine di centinaia di bytes in pochi millisecondi, indipendentemente dalla dimensione dell’affermazione fornita.
Qui ringraziamo lo sviluppo della tecnologia blockchain, che ha investito ampiamente in queste tecnologie.
Ciò detto, sappi una cosa.
Una Zero-knowledge Proof ha tre proprietà salienti, che muovono dall’assunzione che prover e verifier seguino il protocollo:
- Completeness, se l’affermazione fosse corretta allora il verifier accetterebbe la prova
- Soundness, se l’affermazione fosse falsa allora il verifier rifiuterebbe la prova.
- Zero-knowledge, se l’affermazione fosse vera il verifier apprenderebbe unicamente la veridicità dell’affermazione senza alcuna informazione confidenziale trasmessa nell’interazione.
Oltre queste proprietà base, esistono differenti tipologie di metodi zero-knowledge in termini di:
- lingua delle prove
- requisiti tecnici
- efficienza computazionale delle parti
- Interattività
- Assunzioni di fondo
Per il momento ci limiteremo a concentrarci sui casi generali.
Altrimenti sai la noia di questo blogpost?
Protocolli di Zero-Knowledge
In una zero-knowledge è fondamentale la presenza di una configurazione fidata (trusted setup).
Some ZKPs si affidano alle così dette common reference string (CRS), che vengono calcolate usando secrets che devono rimanere nascosti per garantire la proprietà soundness della prova.
Un’altra proprietà significativa riguarda l’interazione necessaria tra prover e verifier per la sintesi della prova. Distinguiamo dunque due tipologie di prove:
- non-interactive zero-knowledge proof (NIZKs), che permettono al prover di inviare un singolo messaggio al verifier senza alcuna ulteriore comunicazione;
- interactive zero-knowledge proofs
Passiamo ora al secondo elemento per raggiungere la verifiability: trusted execution environment e remote attestation.
Application of Zero Knowledge Proofs
Vediamo rapidamente alcune applicazioni pratiche:
- Verificare che le tasse siano state propriamente pagate da un’azienda o persona.
- Assicurarsi che un prestito non sia troppo rischioso
- Controllare che un dato sia stato registrato senza rivelare o trasmettere l’informazione
- Verificare che un aereo sia stato propriamente sottoposto a manutenzione e sia idoneo al volo.
In ciascuno degli scenari di cui sopra la Zero Knowledge Proof è in grado di garantire che l’output sia correttamente calcolato su alcuni dati sensibili senza tuttavia esporne alcuno.
Per approfondire, ti lascio alcune risorse:
- PyZKP, una libreria di OpenMined
- Podcast su ZKP
- Una lista curata delle migliori fonti in materia.
Trusted execution environment (TEE)
TEE (Trusted Execution Environment) fornisce una prova di verificabilità sui calcoli eseguiti, con una combinazione di hardware specifico e software scritto per gestire questi particolari componenti.
Il principio alla base è comunque piuttosto semplice.
Ammesso che il verifier conosca, o possa riprodurre, il codice binario eseguito nell’ambiente sicuro, il TEE è in grado di garantirne:
- l’integrità (integrity): l’esecuzione del codice non può essere modificata fuorché dall’input.
- l’attestazione (attestation): garanzia di esecuzione di uno specifico codice e comunicazione eventuale dello stato iniziale.
Più in generale definiamo attestazione remota (remote attestation) la possibilità di un verifier di misurare con sicurezza lo stato interno di una piattaforma hardware remota, per assicurare così una static or dynamic root of trust.
Questo si rivela particolarmente utile in applicazioni di federated learning, in cui i client possono verificare le funzioni eseguite sul server.
Operazioni come secure aggregation o shuffling possono quindi essere eseguite in TEEs con garanzie di privacy differenziale sugli output.
Sappi comunque che i vendor di queste tecnologie a livello business si contano sulle dita di una mano.
Intel ha una soluzione denominata Intel Software Guard Extensions (SGX)™. Esistono poi alternative come l’ARM Trustzone e l’AMD Platform Security Processor.
Se vuoi approfondire, ti rimando a questo link.
Per il momento è tutto.
Per aspera, ad astra.
Un caldo abbraccio, Andrea.
