Nel mondo della sicurezza informatica, cresce l’attenzione verso la protezione dei dati in uso. Questo significa proteggere i dati non solo quando sono archiviati o in transito, ma anche mentre vengono elaborati. Questo obiettivo è condiviso da due tecnologie che operano a livelli molto diversi: la Crittografia Omomorfica (HE) e gli Ambienti di Esecuzione Fidati (TEE).
Abbiamo già parlato di HE, che può essere utilizzata per addestrare modelli di ML su dati cifrati o per sviluppare Federated Learning a tutela della privacy. In questo articolo invece analizziamo i TEE, per poi confrontarli con HE.
Spoiler: nessuno dei due è magico. Entrambi hanno vantaggi significativi e compromessi importanti.
Cosa sono i TEE?
Un Trusted Execution Environment (TEE) è un’area protetta all’interno del processore di un dispositivo (o, in alcuni casi, un hardware separato) che garantisce la riservatezza e l’integrità del codice e dei dati caricati al suo interno, anche se il sistema operativo principale o l’hypervisor sono compromessi.
Un ambiente di esecuzione fidato (TEE) è un'area sicura di un processore principale. Aiuta a proteggere il codice e i dati caricati al suo interno garantendone riservatezza e integrità. La riservatezza dei dati impedisce a entità non autorizzate di leggere i dati dall’esterno del TEE, mentre l’integrità del codice impedisce che venga sostituito o modificato, anche da parte del proprietario del computer stesso, come avviene in certi schemi DRM descritti in Intel SGX. (Wikipedia)
All’interno di un TEE, codice sensibile—spesso chiamato trusted application o enclave—viene eseguito in completa isolamento dal resto del sistema. Né il sistema operativo, né l’hypervisor, né gli amministratori di sistema possono accedere o manipolare codice o dati al suo interno. Le protezioni hardware possono includere meccanismi di attestazione per verificare il codice in esecuzione e la cifratura della memoria per impedire intercettazioni a basso livello.
Caratteristiche principali:
Isolamento: la memoria e l’esecuzione del TEE sono separate dal mondo non fidato (OS/hypervisor).
Attestazione: opzionalmente, è possibile dimostrare da remoto che una certa enclave sta eseguendo codice atteso.
Radici hardware: la sicurezza deriva da protezioni hardware (non solo software).
Protezione dei dati in uso: i dati restano protetti anche durante l’elaborazione.
In pratica, i TEE estendono il “perimetro di fiducia” all’interno del processore, permettendo l’esecuzione sicura di funzioni critiche anche su host non fidati.
Tipi di TEE
Oggi i TEE sono presenti in una vasta gamma di dispositivi, dai comuni laptop ai grandi datacenter.
PC
Intel SGX: l’architettura di enclave di Intel che permette l’esecuzione di codice a livello utente in “enclave” isolate dal sistema operativo o dall’hypervisor.
ARM TrustZone: concetto di TEE per dispositivi ARM; separa il mondo in Secure e Normal World.
Altri elementi sicuri / chip separati (es. Secure Enclave di Apple, TPM) possono anch’essi essere considerati TEE o simili.
Server/Cloud
AMD SEV‑SNP: tecnologia di virtualizzazione sicura di AMD per il confidential computing.
Intel TDX: tecnologia di Intel per macchine virtuali confidenziali.
Apple Private Cloud Compute: per eseguire query Apple Intelligence nel cloud con forti garanzie di privacy.
Queste tecnologie abilitano il “confidential computing” nel cloud: carichi di lavoro possono essere eseguiti in ambienti dove nemmeno il software del provider cloud può accedere ai dati decifrati.
A cosa servono i TEE?
Come visto sopra, i TEE sono largamente diffusi su macchine comuni e nel cloud. Ecco alcuni scenari d’uso frequenti:
Protezione di chiavi e algoritmi crittografici: esecuzione di operazioni sensibili in enclave per impedire a software malevoli di intercettarli (es. decriptare un file con la tua password).
Confidential computing nel cloud: permettere a infrastrutture non fidate di ospitare carichi sensibili, con la certezza che l’host non possa accedere ai dati.
Protezione DRM/contenuti: garantire che la decodifica di video/audio avvenga in ambienti sicuri, rendendo difficile intercettarli dal sistema operativo.
Elaborazione sicura di credenziali/autenticazione: ad esempio, elaborare dati biometrici all’interno di un’enclave.
Workflow misti/fidati: combinare TEE lato utente con TEE nel cloud per catene di fiducia end-to-end.
È evidente che i TEE giocano un ruolo chiave nella sicurezza e nella privacy di molte attività che svolgiamo quotidianamente.
Pro e Contro
In generale, possiamo riassumere i pro e contro dei TEE così:
Pro:
Prestazioni elevate: l’esecuzione nativa e l’isolamento hardware comportano un overhead minimo rispetto alla crittografia pesante.
Modello di programmazione familiare: è spesso possibile riutilizzare codice esistente (con modifiche) senza doverlo riscrivere da zero.
Adatto a carichi sensibili alla latenza o in tempo reale.
Contro / criticità:
Assunzioni di fiducia: bisogna fidarsi del vendor hardware, firmware, catena di attestazione, SDK dell’enclave, ecc. Se l’hardware è compromesso, la sicurezza cade.
Limiti del modello di minaccia: molti TEE assumono l’assenza di accesso fisico da parte dell’attaccante. Ma attacchi concreti (vedi sotto) mettono in discussione questa ipotesi.
Side-channel / vulnerabilità: i TEE sono stati colpiti da attacchi microarchitetturali (cache-timing, page-faults, fault injection) e ora anche da attacchi fisici.
Confronto con HE
Pur perseguendo lo stesso (o almeno simile) obiettivo, TEE e HE differiscono profondamente.
Ricordiamo che HE permette di eseguire computazioni su dati cifrati senza mai decifrarli. Il risultato, una volta decifrato, corrisponde al risultato della computazione sul dato in chiaro. È il paradigma “lavora su dati sempre cifrati”.
Modello di fiducia:
TEE: richiede fiducia nell’hardware, nel vendor, nel firmware e nella catena di attestazione. Se uno cade, cade tutto.
HE: la fiducia si sposta nella matematica crittografica. Non serve fidarsi del server o dell’hardware: tutto resta cifrato.
Performance e praticità:
TEE: performance quasi-native, integrazione più facile in molti casi.
HE: overhead alto, cifrati pesanti, operazioni costose, profondità di calcolo limitata (specialmente in HE pienamente omomorfa).
Confini di sicurezza:
TEE: isolamento forte, ma ancora soggetto a side-channel e vulnerabilità hardware o fisiche.
HE: forti garanzie crittografiche sulla riservatezza, ma ancora problemi di integrità/correttezza e gap di performance/funzionalità.
Adattabilità agli scenari:
TEE: ideale per carichi a bassa latenza, ampio uso di memoria, tempo reale.
HE: utile per analytics esternalizzate dove la riservatezza è prioritaria.
Approcci ibridi: molte proposte recenti combinano i due—TEE per le parti critiche, HE per i dati ultra-sensibili.
I TEE sono una soluzione definitiva?
Non proprio. I TEE hanno ancora problemi seri. Ars Technica riporta che a fine 2025, dei ricercatori hanno scoperto attacchi fisici in grado di violare i TEE di fornitori importanti. In particolare, gli attacchi "Battering RAM" e "Wiretap" sfruttano interposer tra CPU e memoria per estrarre chiavi da SGX e SEV-SNP.
Purtroppo i vendor trattano gli attacchi fisici come “fuori ambito”, ma in realtà sono attacchi concreti e relativamente economici da realizzare.
Dunque: se il tuo modello di minaccia include l’accesso fisico all’hardware, le garanzie dei TEE possono crollare. Non vuol dire che i TEE siano inutili, ma bisogna comprendere bene i limiti e le assunzioni implicite.
Il Futuro
La crittografia omomorfica (HE) è ancora in evoluzione, ma ci si aspetta un miglioramento significativo nei prossimi anni, soprattutto in termini di performance e strumenti per sviluppatori. Quando questi miglioramenti diventeranno realtà, HE potrebbe diventare una delle opzioni principali per i carichi di lavoro più sensibili alla privacy. In questo contesto, sarà sempre più importante progettare sistemi dove tutto rimane cifrato, end-to-end, anche durante l’elaborazione, e non solo a riposo o in transito. HE ci guida verso quel futuro. E Dhiria sarà parte di quel futuro.
