Leggo, con un po’ di ritardo, questo interessante articolo relativo alla sicurezza del cloud nazionale, che offre lo spunto per qualche riflessione. Dalla data di pubblicazione sono successe diverse cose: l’Agenzia per la cybersicurezza italiana comincia a prendere forma, e nella gara per il cloud nazionale della PA è stata selezionata la cordata composta da TIM, Leonardo, Sogei e CDP, che ci si aspetta che si appoggeranno comunque a un fornitore USA.
E la sicurezza nell’utilizzo di questi fornitori è proprio il tema su cui vale la pena di riflettere.
Indice degli argomenti
Il rapporto con gli Stati Uniti
Prima di tutto, qualche premessa. Mi sembra già un enorme passo avanti, se non altro almeno a parole, che ci si ponga il problema che la dipendenza dai grandi operatori USA e la loro possibilità di accedere ai dati delle PA (ma anche delle aziende strategiche italiane) rappresentino un problema.
Finora, soprattutto da parte della classe politica italiana ed europea, ho visto un surreale atteggiamento da primo dopoguerra, “da piano Marshall”, in cui gli Stati Uniti sono una sorta di padre benevolente che, anche quando mette il naso nelle nostre informazioni, in fondo non fa niente di grave, mentre gli altri paesi europei sono da guardare con sospetto. Invece, da decenni la situazione è esattamente opposta: gli Stati Uniti fanno abbondantemente i propri interessi anche a danno dell’Europa, e noi e gli altri paesi europei siamo sulla stessa barca.
In questo senso, vedere un piano “nazionale” rispetto ad uno europeo mi sembra comunque l’ennesima manifestazione di debolezza e mancanza di coraggio, non da parte dell’Europa ma da parte dei singoli stati membri (non solo dell’Italia).
Basti pensare a quanto sarebbe assurdo se i singoli stati degli USA facessero il proprio piano di sicurezza nazionale: ci dà l’idea di quanto l’Europa sia ancora enormemente più debole rispetto alle grandi potenze mondiali, che probabilmente quando sentono i discorsi di “sovranità nazionale” da parte dei singoli stati europei si ribaltano dalle risate.
Una soluzione di compromesso
Detto questo, almeno abbiamo iniziato a prendere atto del problema del controllo di infrastrutture, dati e informazioni rispetto all’ingerenza da parte, nello specifico, degli Stati Uniti. Problema ben descritto nella sezione 3 della Strategia Cloud Italia e problema che, va detto, è ben difficile da risolvere.
Il documento, con una sana dose di realismo, prende atto del fatto che al momento non siamo in grado di fare a meno dei grandi operatori USA, e cerca porvi rimedio per quanto possibile, ma su questo torno dopo. Il primo problema della strategia, però, è che proprio per questo non è una strategia, è una tattica: è una soluzione di compromesso per gestire le difficoltà attuali con quanto a disposizione, ma come sottolinea Innocenzo Genna, non ha la prospettiva di costruire una vera autonomia europea, anzi, rischia di rafforzare ulteriormente il ruolo dei player statunitensi.
La strada di un cloud europeo dovrebbe essere, idealmente, quella che segue Gaia-X, sulla quale però sento più perplessità e critiche, soprattutto sui temi di governance. Sembra un progetto già sulla strada del fallimento, anche senza le logiche di “Embrace, extend and extinguish” che l’ingresso dei grandi player extraeuropei probabilmente porterà.
Un’alternativa europea è possibile?
Al di là delle tattiche, una vera strategia europea per il cloud (che poi in realtà vuole dire per il controllo delle informazioni, che a sua volta vuole dire il controllo dell’essenza dell’economia futura, non solo per “l’economia delle informazioni”, ma perché già da tempo chi ha le informazioni controlla l’economia) non sembra esserci, sembrano esserci ancora iniziative sparse e disordinate.
L’impressione è che non si creda realmente di essere in grado di sviluppare un’alternativa europea. Che sarebbe invece, appunto, quello che ci si aspetterebbe da una strategia.
Ma torniamo alla nostra strategia/tattica per il cloud nazionale, ai suoi problemi di sicurezza, e ai pregi e ai limiti delle soluzioni discusse. L’articolo di intervista a Baldoni cita due strade principali, identificando chiaramente e, anche qui, con sano realismo, alcuni limiti di queste soluzioni.
Le strade sono la crittografia omomorfica e il controllo delle chiavi di cifratura. In più, si parla anche di un “algoritmo di crittografia nazionale”, che invece mi sembra una pessima idea e su cui tornerò alla fine.
Le soluzioni tecnologiche
Prima di tutto, la crittografia omomorfica. Si tratta, in qualche modo, del “sacro Graal” della sicurezza dei servizi in cloud. Il concetto, di base, è abbastanza semplice.
Supponiamo che io abbia dei dati riservati, e ci voglia fare delle operazioni, diciamo ad esempio x+y=z, ma per esigenze di capacità di calcolo le voglia fare su un sistema in cloud, dei cui gestori però io non mi fidi. Vorrei quindi che loro vedessero solo dati cifrati. Quello che mi serve sono un algoritmo di cifratura C e una funzione F che abbiano la bellissima proprietà che F{C(x),C(y)}=C(z). Ovvero, in soldoni, che se io utilizzo la funzione F sui dati x e y cifrati, ottengo la mia somma z cifrata.
In questo modo, io mando al fornitore di servizi in cloud i dati cifrati, gli faccio fare i calcoli con i quali ottiene un numero ancora cifrato, che lui non è quindi in grado di interpretare, ma che io invece posso riportarmi a casa e decifrare. Naturalmente, in generale non faccio solo somme, faccio altre operazioni, per le quali mi servirebbero altre funzioni, che lavorino con gli stessi dati cifrati e quindi con lo stesso algoritmo C.
Di principio, tante funzioni possono essere “costruite” a partire da mattoncini come la somma, ma qui viene fuori il primo problema: la complessità computazionale. La funzione F è probabilmente molto più complicata della somma, e richiede quindi più tempo e più risorse per essere calcolata. Più si va verso un sistema che permetta di fare operazioni diverse e complesse, e più il problema peggiora.
Possiamo parlare di molti, molti ordini di grandezza come tempi e risorse, rispetto alle stesse operazioni in chiaro. Parlando cloud, questo vuole dire ordini di grandezza in termini di costi. La crittografia omomorfica è un’area di ricerca molto attiva, perché è chiaro l’interesse a soluzioni di questo tipo, ma siamo ancora piuttosto lontani dall’avere qualcosa che sia usabile se non per costruire soluzioni ad hoc per alcuni problemi specifici.
E qui viene fuori il secondo problema.
Il problema delle interfacce
Anche avessimo algoritmi di crittografia omomorfica “generali”, le applicazioni che utilizziamo non ne fanno uso. Sarebbe necessario in qualche modo riscrivere ad esempio un Google Sheet o un Microsoft Excel per fare uso di crittografia omomorfica. Dubito che basterebbe “ricompilarli”, perché sono scritti ed ottimizzati per le operazioni in chiaro, e si appoggiano a processori altrettanto ottimizzati per certi usi.
Le interfacce grafiche sono poi un’ulteriore complessità. Probabilmente l’Europa, dovesse seguire questa strada, farebbe davvero prima a farsi il proprio cloud con le proprie applicazioni, partendo da quelle open source, che a provare a (chiedere per favore di) convertire quelle esistenti, mantenendo per di più una dipendenza almeno in termini di licenze, e l’incertezza delle eventuali backdoor nel codice. Probabilmente poi, se e quando soluzioni di questo tipo saranno realistiche, gli algoritmi dovranno anche essere “quantum-resistant”, aggiungendo ulteriore complessità.
Dato che, come dice l’articolo, “ancora non abbiamo inventato una crittografia omomorfica computazionale”, vediamo la seconda strada, che è molto più attuale e realistica, ovvero quella della cifratura “tradizionale” dei dati cercando di mantenere il controllo delle chiavi.
Tutelare i dati europei o no?
Per capire pregi e limiti bisogna partire dal modello delle minacce, ovvero “da cosa cerchiamo di proteggerci”. Il problema di fondo è che ci dobbiamo aspettare che il governo degli Stati Uniti, dove lo ritenga opportuno (ed eventualmente, dove le norme USA come il Cloud Act e il FISA 702 lo consentano o prevedano) richieda al cloud provider statunitense di fornire dei dati di cittadini, aziende o governi europei.
Su questo è meglio essere chiari: gli Stati Uniti hanno storia di spionaggio ai danni dei paesi europei abbondantemente documentata. Pensare che le cose possano andare diversamente non sarebbe realistico. Come non sarebbe realistico pensare che un cloud provider statunitense, di fronte ad una richiesta anche illegittima del suo governo, faccia la scelta “etica” di rifiutarsi per proteggere un governo straniero. Al più, potrà organizzarsi in modo che, se la cosa venisse scoperta, lui possa sembrare vittima innocente.
Tornando a noi, vuole dire che ci aspettiamo di mettere i nostri dati riservati su di un cloud gestito da un fornitore che sappiamo già a priori che li potrà fornire a richiesta ad un governo che certamente non li utilizzerà a vantaggio dell’Europa. Qual è la soluzione di cui si parla? Di nuovo, cifrare il più possibile. Scartata la soluzione della crittografia omomorfica, necessariamente i dati devono essere in chiaro per essere elaborati, quindi, come dice l’articolo, “c’è un processore nel mondo che vede quel dato”.
Cifrare a più non posso
Possiamo tenere però i dati cifrati su disco (più genericamente, nella memoria di massa) e nelle comunicazioni, gestendo le chiavi di cifratura in un modulo hardware (HSM) dove siano accessibili solo a quel processore e siano gestite esclusivamente, nello specifico, dalla PA italiana. In sostanza, da quanto capisco si tratta di un’architettura simile a quella del Trusted Computing, solo più debole: l’applicazione in cloud quando ha bisogno di accedere ai dati cifrati li passa all’HSM che li decifra, oppure scarica la chiave dall’HSM, e così può lavorare sui dati in chiaro.
Le due opzioni sono diverse, prenderei per buona la prima perché è quella più sicura, a prescindere dalle complessità, ed è l’unica che garantisce il “controllo esclusivo delle chiavi di cifratura”, che è fra l’altro l’ultima foglia di fico trovata per poter continuare a usare i servizi in cloud negli USA fingendo di essere conformi al GDPR, in attesa di un eventuale Schrems III. In entrambi i casi, di fatto, alla fine i dati sono elaborati in chiaro sul processore del sistema.
In questo modo, si dice nell’articolo, “è molto più difficile per l’avversario sia fare incetta di dati sia effettuare l’estrazione del valore”. Affermazione anche questa assolutamente vera, il problema è: “quanto”, più difficile? Supponiamo quindi di avere la nostra applicazione, scritta e compilata in Italia, che viene eseguita sul processore di un servizio in cloud negli Stati Uniti.
Utilizzare una “backdoor”
Quando l’applicazione vuole elaborare dei dati, che se ne stanno su un disco cifrati, lei li prende, li manda all’HSM (autenticandosi, in qualche modo?) in Italia dove vengono decifrati, poi li salva ad esempio in una cache cifrata, e li elabora.
Il punto debole, che è lo stesso del Trusted Computing, è che su quel processore viene eseguito necessariamente anche un sistema operativo, gestito dal fornitore del servizio in cloud (altrimenti non potremmo neanche dire che è un servizio in cloud). Quel sistema operativo è il tallone d’Achille di tutta l’architettura. Riprendiamo il caso in cui il governo degli Stati Uniti voglia accedere a dati di un cittadino europeo sulla base ad esempio del Cloud Act, e in cui il fornitore di servizi in cloud debba quindi collaborare. Come può fare, visto che i dati sono cifrati e le chiavi sono in Italia?
La cosa più semplice è inserire una backdoor nel sistema operativo, che lui controlla, per accedere direttamente alla memoria dell’applicativo in esecuzione, ad esempio per estrarre le chiavi di cifratura del canale e quindi inserirsi sulle comunicazioni fra l’HSM e l’applicazione, e quindi leggere i dati scambiati o, meglio, chiedere direttamente all’HSM di decifrare i dati di interesse.
Complessità di questa operazione: per i soggetti coinvolti tendente a zero. Non la chiamerei neanche una backdoor, la chiamerei un’interfaccia per il wiretapping, come già ce ne sono in altri contesti. E una volta che una tale interfaccia sia disponibile, potrebbe il fornitore in cloud rifiutarsi di “girarsi dall’altra parte” mentre l’agenzia di intelligence utilizza quella stessa interfaccia per attività meno formalmente autorizzate ma comunque nell’interesse del (loro) Paese? Certo che no, con buona pace della riservatezza dei nostri dati.
Al più, in Italia potremmo avere “visibilità” del fatto che venga richiesta la decifratura di determinati dati, ma nella massa di richieste e in una logica decontestualizzata dubito che servirebbe a qualcosa.
Sarebbe almeno una protezione rispetto ad attacchi al cloud da parte di altri soggetti? Difficilmente, proprio perché l’applicazione i dati li deve vedere in chiaro (alla fine, i dati sono tutti elaborati sul processore, che è l’unico punto in cui sono in chiaro, ma è anche l’unico in cui serve che lo siano), e quindi, per fare un esempio, una SQL injection finirebbe quasi certamente per avere accesso ai dati non cifrati.
Un cloud federato europeo
Sia chiaro: io non ho soluzioni migliori. Credo che l’idea di affidare a un fornitore dei dati e pensare di proteggersi dal suo accesso a quegli stessi dati sia sostanzialmente bacata.
La crittografia omomorfica risolverebbe il problema non affidandogli i dati, ma dandogli solo la versione cifrata, ma purtroppo non è al momento una soluzione. Del resto, al momento buona parte delle aziende italiane affida dati, email, documenti e bilanci a fornitori in cloud statunitensi senza neanche queste minime salvaguardie, quindi come soluzione tattica va bene così. Basta che sia tattica.
La vera soluzione sarebbe un vero cloud federato europeo, ad esempio partendo dalle soluzioni open source esistenti. Dico partendo, perché non credo che l’open source sia la soluzione in sé, ma sicuramente è un punto di partenza, che oltretutto aiuta ad evitare dei lock-up che altrimenti non possono che aumentare.
In Italia, l’open source dovrebbe essere la prima alternativa per le PA, ma le soluzioni non sono per la maggior parte ancora all’altezza, anche dove qualcuno le consideri. Servirebbe lavorarci seriamente.
Ma al di là delle chiacchiere, dove sono gli investimenti? Ad esempio, il rapporto del 2020 di “The Document Foundation”, fondazione che cura lo sviluppo di LibreOffice, che dovrebbe essere l’alternativa open source a Microsoft Office, dice che “per la prima volta nel 2020 hanno superato il milione di euro in donazioni”. A livello mondiale. Per un prodotto che, pur uscendone certamente perdente, è confrontabile con Office. Mentre per la digitalizzazione della PA, solo l’Italia stanzia miliardi di euro. Miliardi.
Sembra che non si riesca ad uscire dalla logica per cui l’open source debba essere lavoro di appassionati che lo sviluppano nel proprio tempo libero, invece di essere probabilmente la migliore risorsa, in una prospettiva strategica, per uscire sia dalla dipendenza dai fornitori extra-europei, sia dalle logiche di sfiducia reciproca ma nello stesso tempo necessità di collaborazione fra paesi europei.
Lo stesso vale per il software per le infrastrutture cloud, per quelle di virtualizzazione e per un gran numero di soluzioni e componenti.
La pessima idea della crittografia all’italiana
Rimane un ultimo punto citato nell’articolo, ed è quello dell’“algoritmo di crittografia nazionale”. Questa, invece, è irrimediabilmente una pessima idea.
L’unica motivazione potrebbe essere la preoccupazione che tutti i meccanismi crittografici di cui si è parlato risultino deboli rispetto a possibili vulnerabilità degli algoritmi generalmente utilizzati che, diciamo, l’NSA conosca e la comunità scientifica internazionale no. Ipotesi vera fino a qualche decennio fa, ma che è considerata acqua passata dopo l’intenso sviluppo della crittografia “commerciale” e della relativa crittoanalisi.
Supponiamo comunque che l’Italia decida di sviluppare un proprio algoritmo, di qualsiasi tipo, e che lo faccia nelle stesse logiche di peer review che si sono utilizzate negli ultimi anni per algoritmi come AES (non voglio neanche pensare che qualcuno stia considerando logiche di security through obscurity).
Ebbene, l’algoritmo “italiano” sarebbe verificato al più da quella stessa comunità scientifica internazionale, e quindi non sarebbe più robusto, rispetto a possibili attacchi “segreti” dell’NSA, di quelli già in uso, ma molto probabilmente lo sarebbe meno, perché sviluppare e analizzare un algoritmo “italiano” è sicuramente meno interessante per la comunità internazionale, rispetto ad un algoritmo destinato ad un uso statunitense o mondiale.
Per di più, non ci si potrebbe approvvigionare al mercato di implementazioni hardware e software esistenti (ad esempio, di chip crittografici), ci sarebbe probabilmente una sola implementazione o poco più, poco verificata e poco testata, come succede per le soluzioni destinate a un mercato nazionale (su questo, dovremmo aver imparato da tempo). Credo che l’NSA potrebbe esserne solo felice. Potrebbe forse avere senso un’implementazione europea, di nuovo con poche probabilità di essere più robusta, ma almeno con un mercato di un qualche interesse. Nel complesso, comunque, direi che a livello europeo dovremmo avere altre priorità, e a livello nazionale non ci dovremmo neanche pensare.
In conclusione, la soluzione per il cloud della PA di cui si discute sembra voler mettere tutte le uova in un unico cesto difficile da proteggere, ma a cui potrebbe essere più facile e comodo accedere da parte in particolare del governo USA, anziché più difficile.
La considero comunque una soluzione più sicura rispetto a soluzioni “troppo distribuite”, gestite da singole PA con poche competenze e risorse, ma penso che potenziare le capacità e le competenze di alcuni nodi regionali avrebbe portato a soluzioni comunque di grande miglioramento rispetto all’attuale, con minore esposizione e maggiore controllo.
La vera partita è comunque quella della strategia europea, che però al momento non promette molto bene neanche quella.
