Titolo

La guerra alla crittografia - alcune questioni tecniche

3 commenti (espandi tutti)

Karl, entrambi i punti che sollevi possono essere risolti, almeno dal punto di vista teorico:

A) Per la "one-time key", il problema è che sia il device da sbloccare sia l'agente di escrow (per esempio, un'entità governativa) devono conoscere un numero potenzialmente molto alto di chiavi, e soprattutto devono rimanere sincronizzati su quale chiavi utilizzare. Così su due piedi mi verrebbero in mente due soluzioni:

- Usare un sistema di cifratura simmetrico (tipo AES) in counter mode. In particolare, si utilizza AES per generare una one-time key partendo da un valore iniziale (VI) condiviso tra agente di escrow e device. Ad ogni utilizzo di una one-time key, entrambe le parti incrementano il contatore ed applicano AES alla vecchia chiave, in modo indipendente. La nuova chiave dipenderà dal valore della vecchia e dal nuovo valore del contatore. Ovviamente, questo sistema funziona solo se VI rimane segreto, e solo se i contatori di entrambe le parti rimangono sincronizzati, problema che avevi già intravisto tu nel tuo commento. Ragionevolmente, uno può aspettarsi che il punto debole in questo schema sia il device anziché l'agente di escrow.

- Visto che nella prima soluzione per un attaccante sarebbe molto più facile compromettere un device anziché un agente di escrow (che magari potrebbe essere, come argomentato da Francesco, una struttura tipo Fort Knox), risolviamo il problema alla base: togliamo la chiave dal device. Dopotutto, il problema essenziale è che l'agente di escrow deve *dimostrare* al device di essere davvero chi sostiene di essere. Quindi la questione può essere vista come un problema di autenticazione. Questo può essere risolto, per esempio, usando protocolli di dimostrazione a conoscenza zero. In particolare, solo l'agente di escrow mantiene la chiave. Applicando il protocollo di dimostrazione, l'agente è in grado di dimostrare al device di conoscere effettivamente il valore della chiave, senza però dovergliela trasmettere. Il protocollo è soggetto ad una probabilità di errore, ovvero un attaccante che si finge l'agente di escrow può ingannare il device con una probabilità di 1/2. Questa probabilità può essere però ridotta a piacere ripetendo il protocollo più volte in modo indipendente (per esempio dopo 20 volte la probabilità di errore è meno di una su un milione, ovvero 1/2^20).

B) Il problema del controllo del server contenente le "mezze chiavi" può essere risolto usando gli schemi di condivisione dei segreti. L'idea è di suddividere la chiave in più server anziché uno solo, ciascuno controllato da un'entità/organizzazione diversa. La distribuzione di questi pezzi di chiave viene fatta da una terza parte. Lo schema funziona in modo che la chiave possa essere recuperata solo se almeno un certo numero di server tra cui essa è stata suddivisa mette a disposizione il proprio pezzo. A questo punto uno potrebbe obiettare che il problema di fiducia è stato semplicemente spostato: magari non ci fidiamo di alcune delle organizzazioni tra cui la chiave è stata condivisa (ma questo problema è risolto dalla proprietà dello schema di condivisione, visto che non tutti i server sono necessari al recupero), ma alla fine bisogna sempre fidarsi della terza parte che distribuisce i pezzi all'inizio. In realtà, anche questo problema può essere risolto usando schemi verificabili. Questi schemi permettono ai server di verificare che i pezzi di chiave siano consistenti, e che il dealer non abbia fatto il furbo.

Ovviamente, tutte queste soluzioni teoriche possono essere interessanti, ma i problemi fondamentali rimangono sempre la scalabilità e i costi di un sistema del genere. Senza contare poi il bypass facile che hai già puntualizzato tu, ovvero il fatto che un criminale/terrorista potrebbe svilupparsi per conto proprio i sistemi di cifratura da usare (probabilmente sbagliando pure ad implementarli e quindi rendendoli violabili).

Grazie

Filippo Riccio 3/4/2016 - 21:09

E' chiaro che dal punto di vista tecnico ne sai molto più di me. Per quanto riguarda le possibilità di enforcement di simili soluzioni (e i relativi costi) credo che ci sarà molto da dire quando arriveremo a dibatterne nel thread sotto il contributo politico e giuridico.

Per esempio la prima cosa che mi viene in mente è: chi garantisce poi che sul device non giri altro software di crittografia che non implementa l'algoritmo del governo? L'agenzia delle dogane che sequestra tutti i telefoni in ingresso agli USA? Un accesso casuale a devices per vedere se davvero i dati che sono stati cifrati sono stati cifrati con quelle chiavi e non con altre introdotte dall'utente? Tutto questo quando si può far girare un sistema di messaggistica nel browser semplicemente collegandosi a un sito internet basato chissà dove? Mah...

Grazie Luca per la risposta,

le mie erano solo idee buttate li' in una domenica piovosa senza un granpremio davanti a cui fare un sonnellino. Grazie anche per gli spunti interessanti, che ho approfondito in questi giorni.

Rimango dell'idea che l'utilita' di avere una passpartout universale e' relativa, per i tanti motivi che sono gia' stati dettagliatamente esposti.

Volendo restare nell'esempio, probabilmente la soluzione piu' semplice sarebbe inserire tutto il meccanismo a livello di cifratura del filesystem (il che amplierebbe la cosa a qualsiasi supporto di memorizzazione oltre ai soli telefoni).

Resterei sull'idea che per usare il passpartout sia necessario un accesso fisico al device e pertanto escluderei la cifratura AES in counter mode a favore dimostrazione a conoscenza zero.

Quanto alla condivisione dei segreti mi piacerebbe che la terza parte che li distrubuisce fosse una entita' indipendente (e tendenzialmente un po' paranoica, tipo EEF), perche' questo sarebbe un fardello notevole da portare.

«Ash nazg durbatulûk, ash nazg gimbatul,
ash nazg thrakatulûk, agh burzum-ishi krimpatul.»