Quale crittografia per gli scenari digitali del futuro?
Nel mondo digitale di oggi è oramai diventata consuetudine parlare di protezione dei dati in modo da garantire la riservatezza in qualunque stadio essi si trovino (at-rest, in-fly in-use), anche in caso di una loro esfiltrazione e divulgazione. Ma tutto questo può essere sufficiente per il futuro che ci aspetta?
Osservando con attenzione le attuali architetture di sicurezza per la protezione dei dati, notiamo come siano sempre presi in considerazione i due stadi più comuni in cui può trovarsi il dato, “at-rest” e “in-fly”, molto più raramente quando il dato è “in-use”. In presenza di ambienti cloud, ibridi o comunque aperti, dove il dato deve essere inevitabilmente trattato, ecco che si crea una grande vulnerabilità in quanto occorre decifrare il dato per poterlo elaborare, esponendolo così ad ogni tipo di attacco.
Applicando la tecnologia Fully Homomorphic Encryption (FHE) l’esposizione del dato “in-use” non costituisce più preoccupazione. Infatti FHE consente di operare con calcoli ed operazioni (come addizione e moltiplicazione e funzioni booleane) direttamente su dati crittografati. Il titolare del dato, potrà esporre tranquillamente le proprie informazioni sensibili, dopo averle cifrate con FHE, rendendole disponibili per qualsiasi tipo di elaborazione che verrà eseguita solo in modalità cifrata, quindi senza pericolo di violazione dei dati originali. La stessa elaborazione produrrà un risultato anch’esso cifrato, come se fosse stato prodotto con i dati non cifrati (fatto salvo una certa tolleranza di errore). Tale risultato cifrato potrà infine essere letto solo ed esclusivamente dal titolare che detiene la chiave privata con cui è possibile decifrare il dato.
FHE utilizza diversi schemi crittografici
Entrando un po’ più nello specifico, FHE utilizza diversi schemi crittografici, come BGV, BFV, TFHE e CKKS. Questi schemi differiscono tra loro per il tipo di numeri con cui sono in grado di operare. Ad esempio, BGV, BFV e TFHE operano su numeri interi. Lo schema CKKS si utilizza invece con numeri reali o complessi (tipicamente nelle applicazioni di AI/ML utilizzate con le reti neurali). Questi schemi si basano essenzialmente su una tecnica chiamata Learning with Errors (LWE) che, come dice la parola stessa, introduce errori di tolleranza. In particolare LWE introduce un errore nel testo cifrato per fornire sicurezza. Questo errore continua a crescere man mano che si eseguono le operazioni sui dati crittografati finché a un certo punto non è più possibile continuare. Quindi, per continuare e preservare i risultati computazionali, diventa necessario usare il metodo di “bootstrap” utile per ridurre l’errore nel testo cifrato aggiunto intenzionalmente per proteggere lo schema. Ciò consente, in linea di principio, di continuare a eseguire tutti i calcoli, ma è anche vero che, tale operazione può diventare molto costosa e può degradare notevolmente le prestazioni. Poi abbiamo lo schema BGV dove l’errore nel testo cifrato è effettivamente nascosto all’utente, nel senso che quando l’utente esegue il decrypting del dato, non è in grado di rilevare l’errore. Mentre nello schema CKKS, l’errore viene crittografato nei dati stessi. In questo modo, quando l’utente decifra, non riceve il valore esatto, ma il valore sommato di qualche errore.
Una crittografia quantum-resistant
Oggi la FHE è considerata una crittografia quantum-resistant. Pertanto non vi è alcun vantaggio nell’usare un processore quantistico per violare l’algoritmo di crittografia FHE poichè questo si basa proprio su presupposti di difficoltà computazionale con primitive che utilizzano i metodi/schemi omomorfici descritti in precedenza e che risultano sicuri e resistenti ai quanti. Lo schema originale di Craig Gentry, l’ideatore della FHE, è basato sui reticoli, un tipo di schema che è generalmente difficile da risolvere dai computer quantistici in quanto non suscettibile all’algoritmo di Shor. E’ per questo motivo che la FHE si candida ad essere una delle possibili soluzioni per la protezione del dato dai futuri attacchi digitali perpetrati tramite Quantum Computer.
Requisiti hardware e software
Allo stato attuale FHE può essere facilmente sperimentata utilizzando il solo software in quanto non c’è alcuna dipendenza dall’hardware. Basta avere la disponibilità di un ambiente Docker per consentire agli sviluppatori di creare ed eseguire applicazioni distribuite. Nella maggior parte dei casi d’uso quasi tutti i moderni PC, laptop o dispositivi mobili dispongono di risorse sufficienti per eseguire attività FHE di test. Certo, se si tratta di applicazioni lato server con calcolo crittografato intenso, allora occorre esaminare bene il caso d’uso scoprendo che avere la disponibilità di sistemi ad alta capacità computazionale come i nuovi Mainframe faciliterebbe non poco. Possiamo dire però, che normalmente, per uno sviluppo un pò serio di prototipi significativi è bene avere a disposizione almeno 32 GB di RAM ed una CPU con almeno 4 core. Infatti le prestazioni di FHE scalano piuttosto bene, il che significa che con più core e con più RAM si ottengono prestazioni certamente migliori.
Quale background è necessario?
Il background necessario per sviluppare applicazioni è in funzione dell’obbiettivo prefissato. Ad esempio se si vogliono sviluppare schemi FHE, allora è bene avere solide conoscenze di crittografia. Se si vuole operare direttamente con le API di livello inferiore fornite gratuitamente da HElib, una libreria software multipiattaforma gratuita di tipo open source sviluppata da IBM, allora è bene avere una certa familiarità con gli schemi FHE, per sapere come e quali usare in funzione del dominio di lavoro (come ad esempio il dominio relativo alle reti neurali).
Gli strumenti di lavoro
In ogni caso possiamo utilizzare HElayers, il Software Development Kit (SDK) fornito proprio da IBM per consentire e facilitare l’utilizzo della crittografia Fully Homomorphic Encryption (FHE). Infatti con HEleyers si possono utilizzare processi e tecniche avanzate di tutela della privacy senza che vengano richieste allo sviluppatore conoscenze particolari di crittografia. HElayers SDK è scritto in C++ e include API Python che permettono agli sviluppatori di applicazioni e ai data scientist di utilizzare la potenza di FHE supportando una varietà di operazioni ed analisi come la regressione lineare, la regressione logistica e le reti neurali, quindi particolarmente indicato per gli utilizzi sui dati con carichi di lavoro che fanno uso di ML/AI. A tal proposito ricordo ancora che FHE può essere implementata interamente nel software poichè non vi è alcuna dipendenza dal hardware. L’unico software richiesto è Docker 19 o 20 ed il Software Development Kit (SDK).
Aspetti prestazionali
Oggi si osserva come le prestazioni e la velocità di FHE siano diventate davvero interessanti, ovviamente in funzione del caso d’uso e dal tipo di implementazione. Ad esempio possiamo dire che i carichi di lavoro transazionali esprimono una latenza maggiore rispetto ai carichi di lavoro batch. Ma per diverse applicazioni, FHE è ora abbastanza veloce da poter essere utilizzata, soprattutto laddove vi è la necessità di abilitare tipi di lavoro che prima non potevano essere trattati in modo automatico per problemi di privacy o di condivisione dei dati.
Considerazioni sui casi d’uso
I due classici esempi sono il caso relativo alle frodi finanziarie nelle transazioni online e quello relativo all’analisi delle immagini in campo medico-sanitario. Sono due casi piuttosto diversi tra loro sia per la tempistica richiesta che per i requisiti. Infatti nel primo sono richieste prestazioni elevate, con centinaia o migliaia di transazioni al secondo, mentre nel secondo caso invece può essere accettabile una risposta dilatata nel tempo come minuti/ore. Ma è anche vero che, oggi, FHE può eseguire operazioni di regressione logistica in meno di un secondo, mentre con reti neurali. a diversi livelli di complessità, possiamo passare da secondi a minuti. In ogni caso stiamo parlando di un risultato incredibile se si pensa che fino a ieri erano necessari giorni ad eseguire le stesse operazioni.
Non dobbiamo però dimenticare di tenere sempre in considerazione che, i calcoli crittografati richiedono più risorse rispetto ai calcoli non crittografati. E se questi calcoli elaborano i dati in batch, ecco che le prestazioni migliorano di molto, perché tali operazioni sono di tipo SIMD (Single Instruction, Multiple Data) quindi con tempi e throughput nettamente migliori rispetto al transazionale. Insomma, l’overhead potrà risultare basso o alto, a seconda dei casi, su cui è necessario lavorare con un ‘analisi in profondità in modo da ottimizzare al meglio la resa di FHE.
Conclusioni
Come abbiamo già avuto modo di osservare, FHE non necessita di CPU o hardware speciali, ma se il nostro scopo è quello di utilizzarla per operazioni computazionali intensive è bene valutare la disponibilità di processori più veloci con dimensioni della cache e capacità di memoria maggiori che comporterebbero sicuramente prestazioni migliori. Ad esempio, l’utilizzo dei nuovi calcolatori IBM z16 costituiscono una piattaforma particolarmente indicata per lo scopo in quanto forniscono tutte le necessarie caratteristiche per realizzare un ambiente ottimale in cui sperimentare l’uso di FHE con le proprie applicazioni di business.
Articolo a cura di Luigi Perrone
Architetto e specialista IBM di sicurezza informatica e protezione dei dati.
Attualmente ricopre il ruolo di Security Technical Leader a livello GEO nell’ambito dei sistemi mainframe e hybrid-cloud. Nel suo lungo percorso professionale ha ricoperto diversi ruoli in ambito tecnologico con contatto diretto e continuo con i clienti fornendo consulenza e progettualità nella stesura di architetture di sicurezza e della security intelligence negli ambienti IT
