Vi ricordate i film di spionaggio in cui una lettera prende fuoco dopo essere stata letta oppure un messaggio che appare visibile solo in un determinato momento grazie al decadimento radioattivo di un elemento che in qualche modo ne compone un sistema di protezione?
La crittografia come dico spesso è magica ma forse non può spingersi a tanto. Tuttavia una domanda lecita è:
Posso cifrare un messaggio che potrà essere decifrato solo dopo un certo intervallo di tempo?
Mi sono imbattuto in questo problema a seguito della richiesta di un cliente che voleva realizzare una logica di escrow software, ovvero un sistema che rilascia al cliente il codice sorgente di una app se il maintainer fosse stato impossibilitato a proseguirne la manutenzione.
Il requisito del cliente era piuttosto stringente e richiedeva che tale escrow fosse puramente software e senza una terza parte coinvolta. Non ho accettato l’incarico, sono abituato a realizzare escrow “finanziari” basati su smart contract e quindi senza un’intermediario, tuttavia in questo caso l’oggetto da trasferire non sarebbe un quantitativo di token o un token infungibile, ma sarebbe la conoscenza in chiaro del codice sorgente di una app.
Pur avendo rifiutato l’incarico ho continuato a pensare al problema e le mie ricerche mi hanno portato a pensare ad un sistema di cifratura a tempo. Immaginiamo ad esempio di avere un algoritmo che permetta di cifrare oggi un messaggio e di consegnare alla controparte una chiave che potrà decifrare non prima di un determinato tempo, ad esempio un mese.
Una non soluzione avrebbe potuto funzionare come segue:
- Il fornitore cifra il codice sorgente e lo distribuisce cifrato e consegna al cliente la chiave
- se allo scadere dei 30 giorni il fornitore è ancora adempiente il cliente oblitera la chiave che dunque non sarà più in grado di decifrare il testo cifrato e il fornitore genera una nuova chiave per i prossimi 30 giorni.
- Se invece il fornitore è inadempiente allora il cliente allo scadere dei 30 giorni aziona la sua chiave e decifra il testo e acquisisce il codice sorgente.
Ammesso e non concesso di avere chiavi a tempo obliterabili la soluzione farebbe comunque acqua da tutte le parti e pertanto è una non-soluzione. Mi è rimasta però la curiosità di sapere se una cifratura a tempo fosse o meno possibile e mi sono imbattuto in varie discussioni online
Il principio di base della crittografia (principio di Kerchoff) è che l’unica cosa necessaria per decifrare i dati è la chiave. Quindi la domanda che ci si pone è: “Come posso rendere disponibile l’intera chiave solo durante un certo periodo di tempo?”. Le due risposte ovvie sono:
a) rivelare la chiave solo in quel momento, oppure
b) far dipendere la chiave da dati conoscibili solo in quel momento.
La soluzione (a) sembra ovvia, banale e richiede un grande livello di trust, infatti qualcuno deve garantire che la chiave verrà consegnata al momento debito. La soluzione (b) sembra più interessante ed effettivamente esiste della letteratura scientifica a riguardo
How to build time-lock encryption. Jia Liu, Tibor Jager, Saqib A. Kakvi, and Bogdan Warinschi
Time chain
Il primo elemento necessario per la realizzazione del modello di cifratura a tempo è quello di disporre di un sistema inattaccabile e trustless che garantisca la marcatura temporale. In questo senso la proof of work di Bitcoin appare la scelta più ovvia. Ogni giorno vengono creati circa 144 blocchi e l’altezza di blocco è una variabile che potrebbe essere verificata in fase di esecuzione della decifratura. Anche se ci sono dei dubbi che presenterò in seguito nel testo.
Witness encryption
Tuttavia, la sola esistenza di una marcatura temporale garantita da un algoritmo di consenso e senza elementi fiduciari non è sufficiente. Infatti come posso costruire oggi una cifratura che sarà decifrabile da elementi che ancora non conosco e che saranno noti solo nel futuro, ad esempio la chiave potrebbe essere l’hash del millesimo blocco Bitcoin a partire dal tempo presente.
In realtà questo problema si può risolvere attraverso la cosiddetta witness encryption. Ovvero, non ho bisogno di conoscere oggi la chiave di decifratura ma posso cifrare il messaggio imponendo che la chiave avrà determinate caratteristiche. In altre parole io cifratore posso conoscere l’input x ad un problema di calcolo R, cifrare un messaggio grazie a questo input ed imporre che per decifrare il messaggio serva una chiave w che è la soluzione del problema.
(x, w) ∈ R
Se il problema è abbastanza complesso da un punto di vista computazionale, ad esempio richiede 30 giorni, la crittazione è sicura per 30 giorni. Facciamo l’esempio del Sudoku. Io potrei cifrare un messaggio a partire dai pochi numeri sparsi di uno schema Sudoku non ancora risolto, l’algoritmo di cifratura prevede che la decrittazione potrà avvenire solo a patto di fornire uno schema Sudoku completo a partire da quello iniziale.
Quando impongo la regola di decrittazione non ho neppure bisogno di sapere se la soluzione esiste veramente, se non esiste il messaggio non sarà mai decrittabile.
Tutto questo cosa c’entra con Bitcoin e la cifratura a tempo? Secondo gli autori del paper l’uso combinato di witness encryption e Bitcoin dove la witness sarà ricavabile da un qualsiasi blocco successivo al blocco attuale della blockchain Bitcoin e con un altezza pari a quella attuale più N (ricordo che sono 144 blocchi ogni giorno), e grazie al fatto che il tempo medio fra blocchi in Bitcoin si aggiusta in modo automatico e decentralizzato, si potrà realizzare una chiave crittografica a tempo.
Conclusioni
Abbiamo visto che almeno da un punto di vista teorico si può ipotizzare una cifratura a tempo usando Bitcoin come sorgente di verità “temporale” non soggetta al controllo di nessuna parte fiduciaria.
Secondo gli autori la sicurezza del messaggio è garantita dal fatto che nessuno potrà oggettivamente trovare più conveniente rompere la cifratura piuttosto che usare le proprie risorse di calcolo per prendere il controllo della rete Bitcoin.
Ovvero se so rompere la cifratura sarebbe comunque più conveniente usare questa capacità per acquisire Bitcoin in modo malevolo.
Detto che ancora non esistono delle implementazioni valide di questa soluzione, personalmente nutro anche qualche dubbio sulla sicurezza complessiva del sistema e sul fatto che siano stati considerati accuratamente tutti i possibili modelli di attacco. Ad esempio cosa succederebbe se un attaccante decidesse di fare un fork della chain a partire da quello attuale e cercasse di creare una chain capace di produrre una witness verificabile e valida ma adottando degli stratagemmi per far abbassare la Bitcoin difficulty in modo da ridurre il tempo fra blocchi. Certo sarebbe ancora un attacco costoso e sarebbe efficace solo se il numero di blocchi da creare per ottenere la witness fosse superiore a quelli che rimangono prima del prossimo aggiustamento di difficoltà (cosa che avviene ogni 2016 blocchi), ma mi pare ci sia spazio per attaccare il sistema in modo efficace.
Rispondi