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)
_______________________________________________
nexa mailing list
[email protected]
https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
