On 5/11/23 11:30, Giacomo Tesio wrote:
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.
E' un esempio ed è l'unico. Almeno per ora. Il successo di questo tipo di attacchi dipende dalle proprietà di "Semantically security" dei criptosystem. Possiamo vederla come una difficoltà in più per i crittografi del mondo HE.
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.
Non la gestirei comunque così. Significherebbe rendere del tutto vani gli sforzi dell'HE. Se poi addirittura non dessi la chiave pubblica al gestore del server, allora non potrei eseguire funzioni che non siano definite a priori lato server. Anche in questo caso, troppo limitante.
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.
Certo che si può. E' sufficiente che il sistema di cifratura stesso non sia prono a questo tipo di attacchi, ossia che non sia possibile ottenere informazioni statisticamente certe o probabili da applicazioni di funzioni arbitrarie. Come del resto si sono dimostrati, almeno per ora, tutti i criptosystem in uso, tranne Microsoft SEAL. [...]
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.
Dipende cosa intendi con problema. Se intendi una cosa che si può affrontare, allora la ricerca può andare avanti, come in effetti sta andando avanti e pure in ottima salute. Se invece intendi che non si può affrontare, allora chiunque si stia occupando di HE sta semplicemente perdendo tempo. Solo che in quest'ultimo caso la comunità potrebbe richiederti di sostanziare le tue affermazioni scrivendo un paper e facendotelo revisionare dagli addetti ai lavori. Se decidi di farlo, sarei felice di collaborare con te.
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.
Come già detto, direi proprio che non è il caso.
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.
Certo. Siamo qui per questo.
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.
Abbstanza, direi... :-D Possiamo continuare anche off-line, io penso che sia fondamentale. D. (null)