Gli attuali sviluppi nel campo della crittografia permettono di proteggere i dati quando sono in movimento e quando sono a riposo. Ma è difficile mantenere crittografati i dati nel momento in cui sono in uso da parte di un’applicazione che deve, per esempio, controllare un documento per rilevare errori di ortografia.

Le soluzioni basate su software includono la tokenizzazione e la conservazione del formato, la crittografia omomorfica e la crittografia multi-party. Queste non funzionano per tutti i casi d’uso, e spesso sono più efficaci le protezioni basate su hardware. Gli smartphone le utilizzano già: creano aree sicure che consentono l’elaborazione di dati di identità e pagamento e non sono visibili al resto del dispositivo.

Sui server aziendali questo approccio viene chiamato “confidential computing” e attualmente vengono utilizzate due versioni principali di questa tecnologia. La più nota è SGX (Software Guard eXtensions) di Intel, un’area sicura detta “enclave” all’interno dei chip Intel che protegge applicazioni e dati durante l’uso. Queste aree sono relativamente piccole e le applicazioni in genere devono essere riprogettate o riscritte per trarne vantaggio. Le dimensioni ridotte, tuttavia, riducono al minimo anche i potenziali rischi dovuti a una logica applicativa errata.

L’altro approccio è utilizzato da IBM sui chip S390 nei suoi mainframe Z System e nei server LinuxOne, e da AMD nei chip Epyc. Qui l’enclave è più grande e può contenere non solo un’applicazione, ma l’intera macchina virtuale in cui si trova. Ciò significa che le applicazioni non devono essere rielaborate o riscritte per funzionare all’interno dell’area.

Anche i fornitori di servizi cloud si stanno muovendo verso il confidential computing. Amazon non ha ancora proposto una soluzione basata su hardware, mentre Microsoft ha scelto di utilizzare Intel SGX e Google Cloud ha optato per AMD Epyc. Ecco le differenze tra le diverse strategie.

IBM S390 soddisfa le massime esigenze di sicurezza

Il confidential computing è ancora relativamente agli albori e i primi a utilizzarlo sono società di servizi finanziari e altre aziende con elevati requisiti di sicurezza. Tra queste c’è Hex Trust, una società con sede a Hong Kong che offre custodia di livello bancario per risorse digitali come le criptovalute. “Abbiamo bisogno della stessa infrastruttura di sicurezza dei mercati finanziari”, afferma Rafal Czerniawski, che proviene dal settore dei servizi finanziari ed è CTO di Hex Trust.

Negli ultimi anni lo spazio delle criptovalute è stato travolto da un’imbarazzante ondata di violazioni e perdite di alto profilo. “Per questo non basta capire come archiviare in modo sicuro alcune chiavi crittografiche”, afferma Czerniawski. “In aziende e ambienti istituzionali di grandi dimensioni i clienti potrebbero avere centinaia o migliaia di asset e diverse blockchain. Anche se un’applicazione di gestione delle chiavi è stata riscritta in modo da adattarsi a Intel SGX, questo non significa che l’infrastruttura ha la capacità di gestire le chiavi”. Altre questioni aperte sono la scalabilità, la gestione di servizi che vengono eseguiti contemporaneamente e utilizzano le stesse chiavi, lo spostamento su un altro server nell’eventualità di arresto di una macchina.

A questi problemi IBM risponde con un approccio che permette di operare su larga scala e una tecnologia che è disponibile sia on premise che nel cloud. “Forse inizialmente i nostri clienti vogliono iniziare in piccolo, con un test nel cloud IBM”, aggiunge Czerniawski. “Man mano che la loro attività cresce e l’esposizione al rischio aumenta, possono passare a una soluzione on premise, che offre molta flessibilità”.

L’area sicura di IBM Z può raggiungere dimensioni fino a 16 terabyte. “Non è necessario scegliere quali parti del carico di lavoro proteggere”, spiega Rebecca Gott, responsabile dello sviluppo di blockchain e Z-as-a-service di IBM. “Si può proteggere tutto in una volta sola e non sono necessarie modifiche al codice”.

Ogni area sicura ha il proprio set di chiavi di crittografia utilizzate per crittografare le comunicazioni in entrata o in uscita dall’area. Tramite un canale crittografato sicuro, l cliente aziendale invia all’area protetta l’applicazione, ospitata in una macchina virtuale, insieme ai suoi dati crittografati e alle chiavi utilizzate per sbloccarla.

L’applicazione svolge il suo lavoro al riparo da occhi indiscreti di chiunque altro, inclusi gli amministratori di sistema del provider di servizi cloud. “Questa è una parte fondamentale della nostra proposta di valore”, afferma Gott. “Nessuno può vedere i dati o il software dell’utente, nemmeno chi dispone di elevate credenziali di sistema, come gli amministratori dell’infrastruttura, dell’hypervisor o del cloud”.

L’invio in un’intera macchina virtuale crea un’esposizione aggiuntiva e IBM fa in modo che ogni area passi attraverso un processo di avvio sicuro per garantire che l’immagine iniziale non venga manomessa e che le chiavi di crittografia dell’area siano stabilite al momento della produzione per ogni macchina. “La chiave principale non lascia mai il modulo di protezione hardware”, afferma Gott. “L’architettura sottostante ha la più alta certificazione di sicurezza disponibile per un processore commerciale. Significa che se c’è una manomissione fisica del dispositivo, la manomissione viene rilevata e la chiave viene azzerata entro 100 nanosecondi”.

Per garantire che la macchina virtuale e l’applicazione non siano compromesse, i clienti aziendali possono caricare il proprio codice in un repository GitHub privato dove può essere verificato e firmato.“Quindi possono essere sicuri che non ci siano manomissioni in nessun passaggio”, sottolinea Gott. “Conoscono la provenienza del codice e beneficiano di un intero audit trail e protezioni lungo l’intero processo di elaborazione dei dati”.

Il confidential computing basato su hardware di IBM Z è stato il primo ad arrivare sul mercato. “Introdotto per la prima volta nel 2016, offre un livello di prestazioni superiore rispetto ai concorrenti”, aggiunge Charles King, analista di Pund-IT. “Come altre tecnologie mainframe Z, le aree sicure sono chiaramente progettate per soddisfare le esigenze di sicurezza più rigorose delle grandi aziende”.

AMD punta all’elaborazione sicura nel cloud

Come IBM, anche AMD consente agli utenti di inserire un’intera macchina virtuale all’interno dell’area sicura. “AMD punta al mercato del cloud pubblico con i suoi chip Epyc”, afferma King.

Questo approccio è interessante per le aziende native in cloud come la francese iExec, che fornisce alle aziende l’infrastruttura per eseguire applicazioni blockchain basate su cloud. “Affittiamo spazio da Google Cloud, lo prepariamo per blockchain e off-chain e lo proponiamo alle imprese”, afferma Lei Zhang, responsabile della sicurezza di iExec.

Google Cloud è stato il primo provider di cloud pubblico a offrire confidential computing basato su AMD Epyc come beta pubblica a metà luglio. Uno dei clienti di iExec è un ospedale che desidera condividere i propri dati medici con società di ricerca. “I dati medici sono altamente sensibili, quindi dobbiamo garantire la riservatezza e la proprietà dei dati”, afferma Zhang.

Un altro cliente sta utilizzando la piattaforma per il rendering 3D di film. “E’ importare garantire che non ci siano fughe di notizie e immagini prima che i film siano pronti”, spiega Zhang. L’area sicura AMD Epyc è abbastanza grande da consentire l’esecuzione dell’intero processo di rendering al suo interno.

“Le reti blockchain sono un modo affidabile per gestire i dati e alcuni altri casi d’uso”, prosegue Zhang. “I contratti intelligenti e alcune logiche di business vengono eseguite direttamente sulla blockchain, ma c’è un problema con la scalabilità”.

Ed è qui che entrano in gioco le aree sicure. “Non è possibile eseguire algoritmi sofisticati di intelligenza artificiale direttamente sulle reti blockchain. È costoso e non efficiente. Ecco perché vogliamo spostare tali applicazioni su reti off-chain, ma dobbiamo garantire un livello di sicurezza simile”.

Il confidential computing risponde a questa esigenza, e nemmeno gli amministratori del servizio Google Cloud possono penetrare in questa macchina virtuale sicura per ispezionare i dati.

Come con la piattaforma IBM Z, le applicazioni possono essere eseguite così come sono, senza modificare il codice sorgente. L’area sicura di Google Cloud arriva fino a 896 gigabyte e, come con IBM, ha le proprie chiavi di crittografia, generate da una combinazione di hardware e software che consente ai clienti aziendali di inviare i propri carichi di lavoro.

“I clienti possono mantenere il carico di lavoro crittografato utilizzando le proprie chiavi o scegliere la tecnologia cloud HSM (Hardware Security Module) per cifrare i dati quando li portano nel cloud”, afferma Nelly Porter, senior product manager di Google Cloud. “L’applicazione, e questo è molto importante per noi, non ha bisogno di modifiche”.

Google aveva provato a utilizzare le aree sicure Intel SGX e ha esaminato i modi per rendere il processo più semplice per i clienti, ma costringere le aziende a riprogettare le proprie applicazioni era troppo complicato. Il codice sorgente può non essere disponibile e, anche con codice open source, possono esserci dipendenze o altri motivi per cui l’applicazione non può essere modificata.

Con l’approccio di AMD deve essere modificato solo il codice dell’hypervisor. “Per Linux, per tutte le principali distribuzioni, è stato fatto e il codice è stato aggiornato e accettato dalla community”, spiega Greg Gibby, senior product marketing manager per AMD Epyc. “VMware si è impegnata ad abilitare questa tecnologia con la sua prossima versione e AMD sta lavorando con altre aziende che hanno i propri hypervisor”.

Consentire agli hypervisor e alle macchine virtuali di accedere all’area protetta amplia la potenziale superficie di attacco. “Se si dispone di un hypervisor dannoso, esistono potenziali modi per accedere alla macchina virtuale”, afferma Gibby. In un ambiente di produzione, altre soluzioni di sicurezza possono impedire che ciò accada, ma attualmente la piattaforma AMD non protegge da hypervisor dannosi. “Le protezioni sono nella roadmap di Epyc, ma non volevamo aspettare. Non volevamo che la perfezione fosse nemica del bene”.

Microsoft punta su Intel SGX

Non tutti sono d’accordo con l’approccio di AMD. Microsoft ha scelto di utilizzare Intel SGX e le sue enclave più piccole, che arrivano a 256 kilobyte.

Il vantaggio per i clienti è che hanno una protezione completa contro l’accesso sia logico che fisico. “Un cliente può installare software ed elaborare dati senza alcuna dipendenza da Microsoft”, afferma Mark Russinovich, CTO di Microsoft Azure. “Questo offre livelli estremi di protezione e garanzia”.

Le funzionalità Intel SGX in genere vengono eseguite su workstation più piccole, non su server multi-socket di classe data center, e Microsoft ha collaborato con Intel per portare SGX nei suoi centri cloud con server single-socket. “E’ certamente più facile se puoi avviare un’intera macchina virtuale, ma questo segnica anche un’enorme superficie che espone ad attacchi laterali”, afferma Russinovich.

Microsoft ha esaminato attentamente l’approccio AMD e ha rilevato alcune limitazioni. “I clienti devono scrivere codice che sappia di essere in esecuzione all’interno di Intel SGX”, afferma Russinovich, “ma stiamo lavorando su tecnologie, SDK e strumenti per rendere più facile l’inserimento del software in quelle enclave”.

Microsoft sta collaborando con il Confidential Computing Consortium (di cui fanno parte anche AMD, Google, Intel, Red Hat e Oracle) e ha contribuito con Open Enclave SDK, che astrae le differenze tra ambienti di elaborazione affidabili. “Il database SQL supporta Intel SGX”, aggiunge Russinovich. “Quindi, se un’applicazione utilizza SQL per il suo lavoro più delicato, il resto dell’applicazione non deve essere riscritto per sfruttare l’enclave“.