Confidential computing: proteggere i dati anche durante l’elaborazione
Intel SGX, AMD SEV, ARM CCA: le architetture di Trusted Execution Environment ridefiniscono il perimetro della sicurezza, estendendo la protezione crittografica ai dati in uso. Ma il campo di battaglia è più insidioso del previsto.
Il problema che nessuno voleva affrontare
Per decenni, l’industria della sicurezza informatica ha operato con una convenzione implicita e scomoda: i dati si possono proteggere a riposo, su disco, con la crittografia dei volumi; si possono proteggere in transito, sulle reti, con TLS e i suoi successori. Ma nel momento in cui un processore li elabora, quella protezione deve cedere. La CPU deve vedere il testo in chiaro. L’hypervisor può accedere alla memoria del guest. L’amministratore del cloud provider ha, almeno in teoria, accesso a tutto.
Questa è stata a lungo una verità accettata come ineluttabile, quasi una legge fisica della computazione. Il Confidential Computing nasce dal rifiuto di questa rassegnazione.
L’idea di fondo è tanto radicale quanto semplice: estendere la crittografia all’intero ciclo di vita del dato, incluso il momento del suo utilizzo. Non più una protezione che si interrompe all’ingresso della CPU, ma una garanzia end-to-end che include l’elaborazione stessa. Il meccanismo attraverso cui questa promessa si realizza è il Trusted Execution Environment (TEE): un’enclave hardware isolata, protetta da chiavi crittografiche generate e custodite dal processore stesso, inaccessibile anche al sistema operativo, all’hypervisor e, in linea di principio, persino al fornitore del servizio cloud.
L’industria ha cominciato a prendere sul serio questa tecnologia. Nel suo rapporto sui Top Strategic Technology Trends for 2026, presentato il 20 ottobre 2025 al Gartner IT Symposium, Gartner ha inserito il Confidential Computing tra le tre tecnologie “Architect” fondamentali per l’infrastruttura enterprise nei prossimi cinque anni, stimando che entro il 2029 oltre il 75% delle operazioni elaborate in infrastrutture non fidate sarà protetta in uso dal Confidential Computing. Poco prima, a novembre 2025, la ricerca IDC commissionata dal CCC aveva mappato un’adozione in forte crescita trasversale a settori regolamentati come finanza, sanità e pubblica amministrazione.
Un ulteriore segnale di maturità viene dal report di Cyberus Technology, pubblicato ad aprile 2026 sulla base di interviste con oltre venti organizzazioni partner: le proiezioni di mercato convergono su un CAGR di almeno il 25%, con stime più aggressive che raggiungono il 56-63%.
Ma tra la promessa e la realtà, il percorso è lastricato di sfide architetturali, vulnerabilità emerse e compromessi che chiunque voglia implementare queste soluzioni deve comprendere con lucidità.
Il trilemma della sicurezza moderna: at rest, in transit, in use
La protezione delle informazioni si articola tradizionalmente intorno a tre stati del dato. At rest: quando risiede su un supporto di memorizzazione. In transit: quando attraversa una rete. In use: quando viene elaborato da una CPU.
I primi due stati hanno trovato soluzioni mature e ampiamente adottate. La crittografia dei dischi con standard come AES-256 e i protocolli di trasporto sicuro come TLS 1.3 sono oggi presupposti fondamentali di qualsiasi architettura degna di questo nome. Il terzo stato, il dato in use, è rimasto il tallone d’Achille.
Il problema non è banale. Un processore non può operare su dati cifrati (almeno non con le tecniche crittografiche classiche): deve decifrarli, caricarli in memoria, accedervi. In quel frangente, chiunque abbia accesso privilegiato al sistema, un hypervisor compromesso, un amministratore malevolo, un attaccante con accesso fisico ai moduli RAM, può in linea di principio leggere quei dati.
Nei contesti cloud multi-tenant, questo non è un rischio astratto. Un’azienda farmaceutica che esegue carichi di lavoro sensibili su un cloud provider condiviso deve fidarsi non solo del proprio codice, ma dell’intero stack software del provider, hypervisor, firmware, sistema operativo host e di tutti i suoi dipendenti con accesso privilegiato. La base di fiducia (Trusted Computing Base, TCB) è straordinariamente ampia.
Il Confidential Computing riduce questa TCB al minimo indispensabile: il processore stesso e il suo firmware di sicurezza. Tutto il resto, incluso il cloud provider, viene escluso dal perimetro di fiducia.
L’architettura delle enclave: Intel, AMD, ARM
Le tre famiglie di implementazione oggi disponibili, Intel SGX/TDX, AMD SEV-SNP e ARM CCA, condividono l’obiettivo ma differiscono profondamente nell’approccio architetturale. Comprendere queste differenze è essenziale per scegliere la soluzione giusta al problema giusto.
Intel SGX e TDX: dalla granularità del processo alla granularità della VM
Intel Software Guard Extensions (SGX) è la tecnologia più datata e, per certi versi, più radicale. Anziché proteggere intere macchine virtuali, SGX permette agli sviluppatori di isolare porzioni specifiche di un’applicazione, le enclave, a livello di processo utente. La memoria dell’enclave è cifrata con chiavi generate dal processore e inaccessibile a qualsiasi altro componente del sistema, incluso il kernel. L’enclave stessa, una volta avviata, viene misurata crittograficamente: la sua integrità è verificabile da remoto attraverso un meccanismo di attestazione che permette a un client di verificare che il codice giri effettivamente nell’enclave dichiarata e non in un ambiente compromesso.
SGX ha però dei limiti strutturali significativi. La memoria protetta (EPC, Enclave Page Cache) è limitata nelle dimensioni. La gestione dei processi è complessa: la chiamata fork(), per esempio, richiede workaround non banali. E soprattutto, SGX fu deprecato a partire dalla generazione 11 (Rocket Lake, 2021) per tutti i processori consumer, workstation e laptop, mantenendosi esclusivamente sulla linea Xeon server-grade. Questo non lo ha escluso dalla rilevanza: SGX è ancora fondamentale nell’infrastruttura di attestazione di Intel TDX (Trust Domain Extensions), la tecnologia successiva che sposta il perimetro di protezione dall’enclave di processo all’intera macchina virtuale.
TDX introduce un nuovo modo operativo del processore, lo Secure Arbitration Mode (SEAM), che isola le Trust Domain (TD, equivalenti a VM confidenziali) dall’hypervisor e dal sistema operativo host. A differenza di SGX, TDX non richiede la riprogettazione delle applicazioni: un’intera VM Linux può essere eseguita in una Trust Domain senza modifiche al codice applicativo. L’hypervisor conserva il controllo sulla gestione delle risorse (scheduling, allocazione memoria), ma perde l’accesso ai contenuti della memoria guest.
AMD SEV-SNP: protezione della VM con integrità della memoria
AMD Secure Encrypted Virtualization (SEV) ha attraversato tre generazioni di evoluzione. La versione originale (SEV) cifrava la memoria delle VM con chiavi per-VM gestite dall’AMD Secure Processor (un coprocessore dedicato sulla CPU), ma non proteggeva i registri CPU né garantiva l’integrità della memoria. SEV-ES (Encrypted State) ha aggiunto la protezione dello stato dei registri CPU durante i context switch. SEV-SNP (Secure Nested Paging) ha completato il quadro con la protezione dell’integrità della memoria attraverso una Reverse Map Table (RMP), che impedisce attacchi di replay, re-mapping della memoria e corruzione dei contenuti da parte dell’hypervisor.
Un aspetto distintivo di SEV-SNP è la flessibilità dell’attestazione: a differenza delle versioni precedenti, una VM guest può richiedere un report di attestazione al processore AMD in qualsiasi momento durante il suo ciclo di vita, non solo al momento dell’avvio. Questo apre scenari applicativi più sofisticati, dove la verifica dell’integrità è continua e non solo iniziale.
La scelta architetturale fondamentale di AMD, protezione a livello di VM anziché di processo, semplifica enormemente il deployment di applicazioni esistenti, che non richiedono alcuna modifica. Il prezzo è una TCB leggermente più ampia rispetto a SGX: il kernel del guest è incluso nel perimetro di fiducia.
ARM CCA: i Realm come spazi di esecuzione riservati
ARM Confidential Compute Architecture (CCA) è la risposta di ARM al mondo del mobile e dell’edge computing. Introdotta con l’architettura ARMv9, CCA introduce il concetto di Realm: spazi di esecuzione isolati che godono delle stesse garanzie delle VM confidenziali Intel e AMD, ma con un’integrazione più profonda nel modello di sicurezza dell’architettura ARM.
Come AMD SEV, CCA consente all’hypervisor di gestire le risorse della VM senza poter accedere al suo stato interno, codice, registri, dati. L’isolamento è garantito da un firmware verificato, il Realm Management Monitor (RMM), che implementa il monitor dei Realm. Un vantaggio architetturale rilevante è la scalabilità: CCA supporta l’allocazione dinamica della memoria per i metadati della VM e l’esecuzione multiprocessore concorrente, superando i limiti di scalabilità di tecnologie precedenti come ARM TrustZone.
L’adozione commerciale di CCA è ancora nelle fasi iniziali rispetto alle controparti x86. I principali cloud provider stanno costruendo il supporto, ma la maturità dell’ecosistema software è ancora in sviluppo. Con il crescente peso di ARM nell’infrastruttura cloud e la pervasività dei dispositivi ARM nell’edge e nel mobile, CCA è destinata ad acquisire rilevanza crescente nel prossimo triennio.
Applicazioni: dove il Confidential Computing cambia le regole del gioco
Multi-Party Computation sicura
Il caso d’uso più immediato e convincente del Confidential Computing è la computazione su dati di più parti senza che nessuna parte riveli i propri dati alle altre. Questo scenario, chiamato Secure Multi-Party Computation (MPC), era storicamente appannaggio della crittografia pura: protocolli come il calcolo sicuro a due parti o la condivisione segreta sono formalmente corretti ma computazionalmente proibitivi per dataset reali.
I TEE offrono un’alternativa pragmatica: le parti caricano i propri dati in un’enclave attestata, la computazione avviene in quel perimetro protetto e il risultato viene restituito alle parti interessate senza che i dati originali vengano mai esposti. La correttezza non è garantita dalla crittografia ma dall’hardware, una scelta che introduce fiducia nel produttore del chip ma riduce il costo computazionale di ordini di grandezza.
Nel settore finanziario, questo paradigma abilita collaborazioni che sarebbero altrimenti impossibili. Google Cloud ha documentato architetture in cui più istituti bancari addestrano modelli anti-frode in modo collaborativo senza condividere i dati transazionali, dati che non possono essere aggregati per ragioni regolamentari, competitive e di privacy. La stessa logica si applica alla verifica del rischio di credito incrociata tra concorrenti, alla condivisione di intelligence sulle minacce e alla rendicontazione fiscale aggregata.
Confidential AI: il problema dei modelli e dei dati
L’intelligenza artificiale ha portato il Confidential Computing in una nuova dimensione. Il problema non è più solo proteggere i dati in input a un sistema: è proteggere simultaneamente i dati dell’utente, il modello proprietario del fornitore e i risultati dell’inferenza.
In un’architettura di Confidential AI inference, un modello come un LLM viene caricato all’interno di un’enclave attestata. L’utente può verificare crittograficamente, attraverso l’attestazione remota, che il modello eseguito è esattamente quello dichiarato e che i suoi dati di input non sono accessibili al fornitore del servizio. Il fornitore, a sua volta, può distribuire il modello senza che il cliente possa estrarne i pesi. Entrambe le parti proteggono i propri asset sensibili senza doversi fidare ciecamente l’una dell’altra.
Red Hat, in collaborazione con la comunità open-source del progetto Tinfoil (ottobre 2025), sta sviluppando infrastrutture cloud-native per questa modalità, integrando Intel TDX e AMD SEV-SNP con orchestratori Kubernetes. L’obiettivo è rendere il deployment di inferenza confidenziale trasparente per lo sviluppatore, una richiesta di workload confidenziale gestita come una normale risorsa Kubernetes, senza richiedere competenze specifiche di hardware security.
Sul fronte delle performance, i dati disponibili sono incoraggianti ma devono essere letti con la necessaria cautela. Secondo benchmark condotti nell’ecosistema Phala, uno dei principali operatori di reti TEE per AI, l’overhead tipico per query su modelli linguistici di grandi dimensioni rimane inferiore al 7%. Si tratta di una misura autoprodotta dall’ecosistema e non ancora replicata da ricerca accademica indipendente; ricerche terze parti indicano un overhead generale del 10% circa per workload CPU-bound, che può diventare più significativo in scenari I/O-intensivi.
Privacy-preserving analytics nei settori regolamentati
Sanità e finanza sono i settori dove il Confidential Computing ha più da guadagnare e dove le barriere normative sono più alte. In sanità, la ricerca genomica cooperativa è storicamente vincolata dalla necessità di de-identificazione o di accordi di condivisione dati estremamente complessi. Con le enclave confidenziali, ospedali e istituti di ricerca possono partecipare ad analisi collaborative, modellazione delle malattie, scoperta di farmaci, trattamenti personalizzati, mantenendo i dati dei pazienti esclusivamente nei propri sistemi, accessibili all’enclave condivisa solo per il tempo necessario all’elaborazione.
In ambito finanziario, la pressione normativa è un acceleratore potente. La ricerca IDC del novembre 2025 ha rilevato che una maggioranza significativa delle organizzazioni nel settore finanziario europeo ha indicato DORA (Digital Operational Resilience Act, Reg. UE 2022/2554, in vigore dal 17 gennaio 2025) come fattore diretto nell’adozione del Confidential Computing. Come abbiamo approfondito nell’analisi sul recepimento di DORA in Italia, l’Art. 9 del regolamento impone esplicitamente che le entità finanziarie mantengano standard elevati di “availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit”. L’Art. 6 dello standard tecnico RTS sull’ICT risk management precisa ulteriormente l’obbligo di definire regole per “the encryption of data in use”.
Vale la pena segnalare che il settore finanziario europeo non accoglie questa disposizione in modo univocamente entusiasta: un position paper del luglio 2025 dell’associazione assicurativa tedesca GDV ha sottolineato che la encryption in use è ancora “agli inizi” per numerosi scenari pratici, in particolare per i processi AI generativi e le applicazioni di mobile banking. Questa tensione tra ambizione normativa e maturità tecnologica è uno dei fronti più vivaci del dibattito regolatorio europeo.
Il federated learning confidenziale combina due approcci complementari: i dati rimangono distribuiti presso le istituzioni partecipanti (come nel federated learning classico) e l’aggregazione dei modelli avviene in un’enclave attestata. Questo elimina la necessità di un aggregatore centrale fidato e riduce la superficie di attacco anche nelle fasi di aggiornamento del modello globale.
Il lato oscuro: vulnerabilità emerse e la fragilità delle garanzie
Sarebbe disonesto presentare il Confidential Computing come una soluzione definitiva. La storia della ricerca sulla sicurezza dei TEE è costellata di vulnerabilità che hanno ridimensionato, a volte drasticamente, le garanzie dei produttori.
TEE.fail: la minaccia da 1.000 dollari
L’ottobre 2025 ha portato una scoperta che ha scosso la comunità: ricercatori della Georgia Tech, della Purdue University e di Synkhronix hanno pubblicato TEE.fail, un attacco fisico basato su bus interposition su memoria DDR5 costruito con componenti acquistabili online per meno di 1.000 dollari.
L’attacco, che nella sua forma completa richiede accesso fisico al server e privilegi a livello kernel (root) sul sistema host, una combinazione che ne limita la rilevanza agli attori interni malevolenti e ai data center compromessi, consente di ispezionare fisicamente tutto il traffico in memoria all’interno di server DDR5 moderni. I ricercatori hanno estratto chiavi crittografiche da macchine virtuali confidenziali pienamente aggiornate, incluse in alcuni casi le chiavi di attestazione stesse, su processori Intel Xeon di quinta generazione e AMD EPYC Zen 5.
Le conseguenze sono severe: estraendo la Provisioning Certification Key (PCK) da un processore Intel, è possibile creare ambienti attestati fasulli che appaiono crittograficamente autentici a clienti e partner ma in realtà sono compromessi. I ricercatori hanno dimostrato questa possibilità su BUILDERNET, un’infrastruttura blockchain che usa TDX per garantire la riservatezza nella costruzione di blocchi Ethereum, riuscendo a estrarre chiavi Ethereum e dati transazionali pur superando tutti i controlli di attestazione.
Aspetto rilevante per il panorama AI: TEE.fail colpisce anche NVIDIA Confidential Computing, l’estensione GPU confidenziale presente negli H100 e nelle architetture successive, consentendo di compromettere l’attestazione nei deployment di inferenza confidenziale che combinano TDX e GPU CC.
I ricercatori hanno seguito un processo di responsible disclosure, notificando Intel, AMD e NVIDIA tra aprile e agosto 2025. La risposta dei vendor è stata rilevante non per quello che ha detto, ma per quello che ha ammesso: tutti e tre i vendor hanno riconosciuto i risultati classificando gli attacchi fisici come fuori dal proprio modello di minaccia. Il Confidential Computing, nella sua definizione corrente, non è progettato per resistere a un avversario con accesso fisico e privilegi di sistema al server host, una premessa che molti utenti non avevano esplicitato con chiarezza e che TEE.fail ha reso ineludibile.
Side-channel attack: il canale laterale non muore
La categoria più vasta e persistente di vulnerabilità è quella degli attacchi a canale laterale (side-channel attack). Anziché violare direttamente la crittografia, questi attacchi sfruttano informazioni indirette, timing, pattern di accesso alla memoria, consumo energetico, interferenze microarchitetturali, per inferire dati segreti.
SGX è stato storicamente il bersaglio più studiato. La tecnica del single-stepping, che utilizza il timer APIC per interrompere l’esecuzione dell’enclave dopo ogni istruzione, permette di ottenere tracce di esecuzione ad alta risoluzione temporale, da cui è possibile ricostruire chiavi crittografiche. Il framework SGX-Step, sviluppato da Van Bulck et al., ha automatizzato questo processo. La sua applicazione ad AMD SEV attraverso SEV-Step ha dimostrato che la vulnerabilità non è specifica di SGX ma condivisa con altri TEE. Intel TDX include una mitigazione contro il single-stepping basata sul timestamp counter, anche se una ricerca USENIX Security 2025 (TDXdown) ha mostrato come aggirare la versione iniziale di questa difesa.
Sul fronte della crittografia della memoria, ricercatori di USENIX Security 2025 hanno identificato difetti di progettazione strutturali nell’uso della cifratura AES-XTS in Intel SGX/TDX e AMD SEV: essendo deterministica (necessità tecnica per gestire gigabyte di memoria senza mantenere nonce per ogni pagina) produce lo stesso ciphertext per lo stesso plaintext allo stesso indirizzo. Se un’implementazione scrive ripetutamente dati dipendenti da bit segreti allo stesso indirizzo di memoria, un attaccante che può leggere i ciphertext può etichettarli e inferire quei bit segreti, anche senza decifrare la memoria. Le implementazioni constant-time, tipicamente considerate la difesa standard contro i side-channel, sono paradossalmente particolarmente vulnerabili a questo vettore.
La pubblicazione SCASE presentata a USENIX Security 2025 (Weber, Gerlach, Trampert, Lü, Van Bulck, Schwarz) ha mostrato come automatizzare la scoperta e lo sfruttamento di queste vulnerabilità: il framework Athena, proof-of-concept di SCASE, è riuscito a recuperare una chiave RSA a 2048 bit entro quattro minuti e una chiave RC4 a 256 bit entro cinque minuti da enclave SGX, senza richiedere una comprensione approfondita dell’applicazione vittima.
Attacchi all’orchestrazione e ai confini di fiducia
Una categoria emergente di vulnerabilità riguarda i confini tra ambienti TEE e l’ecosistema cloud-native che li circonda. Come approfondito nella nostra analisi sulle minacce ai sistemi cloud ibridi, ricercatori che hanno analizzato runtime per container TEE, tra cui Gramine, Occlum, Mystikos e CoCo, hanno identificato superfici di attacco nelle interfacce di orchestrazione: un’interfaccia OCI-shim non protetta può trasmettere immagini container compromesse durante l’istanziazione, aggirando le garanzie dell’enclave stessa. L’espansione della TCB per includere il kernel guest nei TEE basati su VM (TDX, SEV-SNP, CCA) introduce ulteriori vettori che non esistevano nell’approccio a enclave di processo di SGX originale.
La risposta dell’ecosistema: verso l’interoperabilità e la standardizzazione
La consapevolezza di queste sfide non ha frenato l’adozione, ma l’ha resa più matura. Il Confidential Computing Consortium (CCC), ospitato dalla Linux Foundation, coordina produttori di hardware, cloud provider e ricercatori per sviluppare standard di interoperabilità, framework di attestazione aperti e strumenti condivisi.
Il progetto Confidential Containers (CoCo) mira a portare il Confidential Computing nell’ecosistema Kubernetes in modo trasparente, supportando AMD SEV-SNP, Intel TDX e IBM Secure Execution attraverso una stessa interfaccia. dstack, donato alla Linux Foundation da Phala il 10 settembre 2025 e ora ospitato sotto il CCC, fornisce un workflow basato su container per il deployment di applicazioni confidenziali, con gestione integrata dei segreti e supporto al trust-no-code. Il progetto ha superato un audit di sicurezza indipendente condotto da zkSecurity tra maggio e giugno 2025, il primo di questo tipo per un stack di confidential compute basato su Intel TDX.
La questione dell’attestazione remota rimane centrale. Verificare che un carico di lavoro giri effettivamente in un’enclave autentica è il meccanismo fondante di tutto il paradigma. Ma la catena di fiducia dell’attestazione, che risale ai produttori di hardware come Intel e AMD, introduce una dipendenza strutturale da terze parti che alcune organizzazioni trovano difficilmente accettabile. Il dibattito su modelli di attestazione decentralizzati e verificabili apertamente è uno dei fronti più attivi della ricerca applicata.
Sul fronte delle performance, il progresso è continuo. I TEE basati su VM (TDX, SEV-SNP) mostrano overhead tipici dell’ordine del 10% per workload CPU-bound, accettabile nella maggior parte dei contesti applicativi. L’overhead diventa più significativo per workload I/O-intensivi, dove la cifratura e decifratura dei dati in ingresso e uscita dall’enclave si accumula.
Una riflessione conclusiva: fiducia come architettura
Il Confidential Computing porta con sé una domanda che va oltre la tecnica: di cosa possiamo fidarci, e perché?
La risposta tradizionale della sicurezza informatica era: fidarsi del perimetro. Il modello zero trust ha eroso questa risposta, spostando la fiducia verso l’identità e il contesto. Il Confidential Computing fa un passo ulteriore, proponendo di fondare la fiducia sull’hardware, sull’impossibilità logica di accedere alla memoria protetta senza le chiavi del processore.
È una risposta potente, ma non assoluta. TEE.fail ci ricorda che il confine fisico non è impenetrabile, almeno non per un avversario con accesso diretto al server e privilegi di sistema. Le vulnerabilità a canale laterale ci ricordano che il processore lascia tracce nell’architettura microarchitetturale che possono essere lette indirettamente. La crittografia deterministica della memoria ci ricorda che anche scelte ingegneristiche necessarie possono diventare superfici di attacco. L’attestazione remota ci ricorda che al fondo della catena di fiducia c’è sempre un’entità umana, il produttore del chip, in cui è necessario riporre una fiducia residua.
Eppure, la direzione è inequivocabile. Per la prima volta nella storia della computazione, è possibile progettare sistemi in cui i dati più sensibili, cartelle cliniche, segreti industriali, dati finanziari, possono essere elaborati su infrastrutture non fidate senza che il fornitore dell’infrastruttura possa accedervi in condizioni operative normali. Non è un miracolo, ma è un avanzamento reale.
Per i settori regolamentati italiani ed europei, dalle banche soggette a DORA agli ospedali sotto GDPR, dalle aziende farmaceutiche alle pubbliche amministrazioni, comprendere il Confidential Computing non è più un esercizio accademico. È una competenza strategica. Le architetture che oggi vengono disegnate determineranno chi potrà collaborare con chi, su quali dati, con quali garanzie, negli anni a venire.
La posta è alta. Le tecnologie ci sono. La maturità richiede ancora lavoro, ma il cantiere è aperto e questa volta non si può rimandare.
