Titolo

La guerra alla crittografia - alcune questioni tecniche

11 commenti (espandi tutti)

Il concetto di chiave "di uso singolo" non mi è del tutto chiaro.

Questa chiave, conservata su un suporto cataceo custodito a Fort Knox è attivabile solo su ordine di una autorità giudiziaria di un paese OCSE e funziona solo una volta, nel senso che quando viene utilizzata risulta "bruciata" per cui non può venire impropriamente sfruttata per accedere ad altri dispositivi?

Quello che mi sfugge è come si fa ad avvisare i milioni di dispositivi sparsi per il pianeta che questo è avvenuto, dicendo loro di bruciare una delle chiavi che potrebbero sbloccarli.

Ammesso di farlo attraverso un aggiornamento del software, e ammesso che tutti lo facciano, comunicare urbi et orbi questa informazione equivarrebbe a dire che un dispositivo marca X e modello Y è stato sbloccato. Forse questo potrebbe danneggiare il segreto istruttorio. Sbaglio?

Beh, il concetto è chiaro: una volta che la chiave è stata usata, non funziona piu'una seconda volta. E' quello che succede in banca quando i tecnici devono accedere a dati riservati per sistemare errori informatici e quindi occorre conciliare provacy e integrità dei dati.
Ora poni una domanda concreta che anche io mi pongo, ma se hai compreso il citato concetto del "perché no, sì ma" dovresti iniziare a proporre soluzioni, non nostacoli.

Le soluzioni sono molteplici ed una a cui non avevo pensato, in quanto farraginosa, è proprio quella dell'aggiornamento del software. E quindi ti ringrazio.

Ma questo ci mette di fronte a due tipi di soluzione:

1) hard-coded (che necessita di un aggiornamento software)
2) data-coded (che necessita solo dell'accesso in rete ad una lista di chiavi "bruciate")

Il che non basta, ovviamente, ma che puo' essere stimolo per trovare soluzioni praticabili e trasparenti. Una puo' essere che ogni dispositivo ha una sua unica chiave di accesso "protetta" ma qui la soluzione "custodia cartacea" si fa complessa. Un miliardo di telefononi = un miliardo di buste in cassaforte. La vedo dura ma non impossibile. Direi impraticabie per costi e tempi di ricupero quindi se ci sono soluzioni miglori ben vengano.

Dai, su! Noi tecnici in queste cose siamo bravissimi.
Io che sono solo un vetusto programmatore di 62 anni, qualche idea me la sono già fatta venire. Non vorrete, voi giovani virgulti, farvi fregare da un anziano (sicuro) e spento (forse) concorrente! Basta fare un concorso per la migliore soluzione e mettere un premio di un milione di dollari (ma che gli economisti calcolino loro il giusto incentivo!) e poi vediamo chi gioca a "si ma" e chi a propporre soluzioni valide.

Ok, giocare mi piace.

, la questione della chiave fisica (carta e cassaforte) va bene per le banche: 1 cassaforte per 1 sistema informatico. Con una distribuzione di apparecchi su scala globale la soluzione mostra la corda. Meglio un server centrale con mezza-chiave, L'altra mezza arriva dalla autorizzazione del giudice di un paese OCSE (e potrebbe essere anche fisica). Ad ogni uso la mezza chiave relativa su server verrebbe bruciata.

Ora ci sono due problemi (magari di più, per ora ne vedo solo 2):
A) La chiave, così come viene messa insieme, deve essere usata una sola volta. Non ho idea come fare in modo che questo accada. O meglio, tutte le idee che mi vengono si scontrano con il fatto che si potrebbe manomettere l'orologio della periferica per fargli credere che la password non sia già scaduta.

B) Chi controlla il server delle mezze chiavi? (abbiamo aumentato solo di un ordine la complessità del problema).

Il gioco può essere divertente per passare la domenica pomeriggio.

Ma, se il malintenzionato di turno installa sul suo device un software di crittazione forte la nostra soluzione, oltre a passare una bella domenica, servirebbe a ben poco.

Diversamente se qualcuno avesse una soluzione che salva capra e cavoli andrebbe a sventolarla a Cupertino (o a Mountain View). Anche senza un concorso, una idea del genere toglierebbe un bel po' di castagne dal fuoco, quindi qualcuno riconoscente non si faticherebbe a trovarlo.

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.»

Come succede quasi sempre quando si ha un'idea, tipicamente qualcuno l'ha già pensata, e l'ha realizzata in modo migliore di quanto si potesse già pensare.

Molti altri oltre a me, Francesco, hanno già fatto notare nei commenti a questo post che sistemi di key recovery, escrow et similia sono già stati realizzati in passato. Ed è proprio l'esperienza passata che ha mostrato la loro inadeguatezza e il loro fallimento. Inoltre, si sono rivelati fallimentari in un periodo storico (anni '90) in cui le comunicazioni globali non erano sviluppate e complesse come ora. E già allora, alla fine di quell'esperienza, diversi tecnici del settore mettevano in guardia sull'estrema complessità di realizzazione di un sistema di key escrow universale, scalabile, e utilizzabile solo dalle autorità.

Granted, ciò non implica che realizzare un sistema del genere rimarrà sempre fuori dalla nostra portata. Ma prima di buttarsi nella speculazione selvaggia su come poterlo realizzare, magari forse prima conviene documentarsi sulla letteratura a riguardo, ed apprezzare meglio le difficoltà tecniche in esso insite. Quindi, ti invito nuovamente a leggere questo paper:

  The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption

Lo so, leggere richiede tempo. Ma continuare a dibattere ignorando la letteratura scientifica a riguardo mi pare poco fruttuoso. D'altro canto, finora tu non hai portato alcuna documentazione a supporto dei tuoi claim. Tutte le tue argomentazioni sono impressioni e idee basate sulla tua esperienza lavorativa personale. Ovviamente, non metto in dubbio che la tua esperienza sia molto estesa e utile. D'altronde, nella mia limitatissima esperienza (sono ancora studente di dottorato) ho già notato che parecchi colleghi che lavorano in ambito IT quasi mai riescono ad apprezzare la complessità dei problemi affrontati in crittografia, e finiscono per affrontarli in maniera naive esattamente come stai facendo tu.

Di più, sempre dalla mia limitata esperienza ho notato che gli attori del mondo industriale (dove per "industriale" intendo "non accademico") finiscono per volere soluzioni *molto* più insicure ma, dal loro punto di vista, più "efficienti" e "praticabili". E questo considerando che le soluzioni tecniche allo stato dell'arte che gli si propone, in realtà, sono completamente fattibili e "within reach".

Icaro

Francesco Forti 3/4/2016 - 19:07

Beh, quel "quasi sempre" non mi convince perché se tu avessi ragione saremmo probabilmente ancora all'età della pietra. Non lo siamo e so che questo non significa affatto che ogni idea avuta in passato fosse per forza brillante. Le idee si valutano solo per quello che sono e capita che idee vecchie, che non erano realizzabili in passato, diventino realizzabili in seguoto, quanto la tecnica trova le soluzioni. Facile dire, nel 1700, che il mito di Icaro (idea vecchie e già carici di mitici fallimenti) fosse un sogno per pazzi. Oggi si vola normalmente ed è pure il sistema di trasporto piu' sicuro. In effetti con sistemi piu' complessi delle ali piumate di Icaro, ma ci siamo capiti, spero.Idem per andare sulla Luna.

Quanto al tuo consiglio di lettura, hai ragione nel dire che leggere (e capire) richiede tempo, nota risorsa scarsa. Sono anche d'accordo sul concetto che simili soluzioni implicano rischi e costi. Ma quello che forse non si è capito che siamo in presenza di un trade-off con ben altri costi e rischi (vite umane, sicurezza nazionale) e quindi alla fina una decsione va presa.

Si è capito, e continuare a metterlo in dubbio mi sembra anche abbastanza improduttivo.

Quando decidete come fare le norme sulla sanità, vi rivolgete ai medici per sapere quali sarebbero costi e benefici dei vari trattamenti possibili?

Quando decidete come fare le norme sulla radioprotezione, vi rivolgete ai fisici sanitari e agli ingegneri nucleari per sapere quali sono i rischi e le contromisure che si possono prendere contro tali rischi?

Ecco, vi siete rivolti agli esperti di crittografia e avete ricevuto una risposta chiarissima: "limitare la crittografia è pericoloso per la sicurezza". Anche nazionale. Non solo di qualche anarchico in lotta perenne contro il potere.

Ora potete decidere se ascoltare questo parere, oppure ignorarlo e discutere come si fa di sanità sui forum di omeopatia, o di radioprotezione su ecoblog...

Innanzitutto mi scuso: la frase con cui ho iniziato il mio commento l'avevo intesa come una battuta, ma per come l'ho scritta in effetti è abbastanza perentoria.

Venendo al tuo paragone con il volo e con il mito di Icaro, mi hai fatto venire in mente un'osservazione che avevo letto tempo fa sul "Artificial Intelligence: A Modern Approach" di Russell e Norvig. La faccenda in quell'ambito riguardava la possibilità di costruire "macchine pensanti", ma l'osservazione è di carattere puramente generale e prende spunto proprio dal caso del volo umano:

Gli esseri umani hanno imparato a volare quando hanno smesso di imitare gli uccelli.

Ed è esattamente ciò che riconosci anche tu scrivendo "con sistemi piu' complessi delle ali piumate di Icaro".

Mutatis mutandis, non pensi che per risolvere il problema di cui stiamo discutendo, forse, c'è anche la possibilità che la soluzione la troveremo cercando in un'altra direzione che non sia il key escrow (notare che per key escrow non mi riferisco a nessuna soluzione tecnica in particolare, ma alla questione generale di permettere l'accesso alle autorità a dati cifrati)? 

Sì, lo penso. Ritengo che se soluzione verrà trovata, sarà sicuramente migliore di key escrow ma probabilmente verrà trovata proprio approfondendo pro e contro di soluzioni come quella. Il che mi fa pensare che è solo continuando ad approfondire una soluzione che poi se ne risolvono i problemi, anche con innovazioni concettuali notevoli.