On Thu, May 11, 2023 at 09:45:37AM +0200, D. Davide Lamanna wrote: > > banalmente, la Homomorphic Encryption temo resterà sempre fortemente > > vulnerabile a timing attack. > > Attenzione! L'articolo parla di una specifica software library, molto > diffusa in HE, ma certamente non l'unica.
L'articolo è solo un esempio della classe di vulnerabilità che ho descritto, basato sul controllo dell'elaborazione effettuata sui dati cifrati anche in assenza della possibilità di decifrare il risultato di tale elaborazione. Ovviamente, se chi effettua l'elaborazione non ha accesso alla chiave pubblica (oltre che alla chiave privata) il problema non si pone. Tuttavia tale strategia pone un problema di protezione della chiave "pubblica" che va comunque condivisa con chi è autorizzato a trattare i dati cifrati (ovvero a stabilire quali elaborazione è possibile fare). Il che rende la crittografia omomorfica qualcosa di intermedio fra la crittografia simmetrica e quella asimmetrica. Ma fintanto che chi esegue l'elaborazione cifrata può anche cifrare un'elaborazione di propria scelta, dubito che si possa aggirare il tipo di timing attack che descrivevo. > Di HE si è parlato moltissimo dopo che Craig Gentry, uno > studente di dottorato della Duke University, è riuscito, nel 2009, ad ideare > per primo nella storia uno schema di Fully Homomorphic Encryption. L'idea di cifrare l'algoritmo di decifratura per ottenere una versione (sempre cifrata) del plain text con un rumore ridotto è stata GENIALE. Comunque, personalmente, sono interessato anzitutto alla FHE. > L'HE è solo più indietro degli altri tipi > di cifratura, perché è notovolmente più complessa. Ma la comunità è molto > più che vitale, ci sono migliaia di articoli che escono ogni anno. Vero, ma non tratterrei il respiro in attesa di una sua applicazione su vasta scala. > > Un ipotetico fornitore cloud che abbia accesso alla chiave PUBBLICA > > di cifratura (NB: non quella privata, basta quella pubblica) può > > cifrare una elaborazione arbitraria e applicarla ai dati cifrati > > ottenendo un risultato anch'esso cifrato. > > Questo però lo puoi fare anche con la cifratura di uso comune. Uhm... irrilevante. Con la cifratura non omomorfica, l'unico modo che hai per effettuare un'elaborazione sul dato cifrato è decifrarlo prima. A quel punto hai accesso al dato in chiaro e, oltre a ciò che devi, ci puòi fare quel che vuoi impunemente (perché la copia dei dati non lascia tracce). Insomma, con la crittografia di uso comune l'attacco che descrivevo è inutile (se hai accesso alle chiavi di cifratura) o impossibile (se non hai accesso a tali chiavi). > > Il bello della FHE è che tale avversario non può decifrare il risultato > > senza la chiave privata. > > Anche questo è vero per qualunque meccanismo di cifratura. Non sono stato chiaro: la FHE ti permette di cifrare un programma ed applicarlo ad un dato cifrato ottenendo un output cifrato senza che in alcun passaggio la CPU abbia accesso al dato in chiaro. Questo con la crittografia non-FHE è impossibile: 1. per usare un dato come input di un programma devi prima decriptarlo. 2. l'output che ottieni dal programma è in chiaro e se vuoi cifrarlo con un'algoritmo di cifratura asimmetrico, devi cifrarlo successivamente solo a quel punto, se non hai tenuto copie dei dati in chiaro non hai più accesso all'output se non hai la chiave privata. Poter effettuare l'elaborazione in modo completamente cifrato è ciò che caratterizza la FHE. Il problema è che i timing attack che ho descritto ne vanificano il selling point. > > Tuttavia, nulla gli impedisce di cifrare un elaborazione che è > > estremamente lenta se il primo bit del testo cifrato è 1 ed estremamente > > veloce se è 0. > > > > Applicando tale elaborazione cifrata e misurando i tempi di risposta può > > dedurre il valore del primo bit del testo in chiaro. > > E' questo il punto importante in cui si evidenzia la particolare > vulnerabilità. Non possiamo però estenderla alla HE tout court. La HE è > molto di più di Microsoft SEAL. Naturalmente. Ma l'articolo è (IMHO) solo un caso specifico di un problema strutturale. Un problema non invalicabile (trattando la chiave pubblica come chiave "riservata", ma distinta dalla chiave privata che deve rimanere _segreta_) ma comunque da non ignorare. Anche perché, se lo ignoriamo, non passerà troppo tempo prima che le BigTech usingo la FHE per buttare un po' di fumo negli occhi di utenti e policy maker, dichiarando di non poter accedere ai dati ricevuti mentre potranno farlo tranquillamente. > > Ho un vaghissimo ricordo di una tecnica simile presentata l'anno scorso > > ma non ritrovo l'articolo accademico che ne parlava. > > Grazie ancora per l'articolo e per lo scambio. Grazie a te! Spero solo che non siamo stati troppo "opachi" per chi non conosce il tema. Giacomo _______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
