Il confidential computing, presentato dai vendor come una base tecnica per cloud sovrani e gestione più controllata dei dati, si trova davanti a un problema strutturale nel suo meccanismo di fiducia. Nuove ricerche formalmente verificate indicano che attested TLS, il protocollo usato per dimostrare a un client che un server opera dentro un ambiente protetto e non modificato, può non garantire davvero che i dati finiscano alla macchina prevista.
Il punto critico è la remote attestation: prima che dati sensibili vengano scambiati, un server deve provare crittograficamente di essere in un Trusted Execution Environment genuino. È il presupposto su cui si innestano promesse come quelle di Intel TDX sulla sovranità dei dati e quelle di Google Cloud sul controllo verificabile dell’accesso alle informazioni dei clienti. La ricerca mette però in discussione il livello di protocollo che dovrebbe trasformare quella promessa in garanzia operativa.
Muhammad Usama Sardar, ricercatore della TU Dresden, ha lavorato per due anni alla verifica formale del protocollo con ProVerif, strumento usato per l’analisi simbolica della sicurezza. Con i coautori Mariam Moustafa e Tuomas Aura, nel paper Identity Crisis in Confidential Computing presentato ad AsiaCCS 2026, ha individuato attacchi di diversione contro due protocolli attested TLS considerati avanzati.
Lo scenario è particolarmente delicato per le imprese: una connessione destinata a un server può essere reindirizzata in silenzio verso una macchina compromessa che esegue lo stesso software, anche in un’altra area geografica, senza che il client se ne accorga. Il server legittimo non deve essere violato. L’attacco sfrutta una distinzione essenziale: il protocollo verifica l’integrità del software, non la sua posizione né l’identità effettiva del destinatario finale del traffico.
Un secondo lavoro, Intra-handshake.fail, firmato con Viacheslav Dubeyko e Jean-Marie Jacquet e accettato a ESORICS 2026, spinge l’analisi oltre. Il gruppo ha esaminato l’intra-handshake attestation, in cui la prova viene generata durante l’handshake TLS, testando sette modi diversi di legare crittograficamente quella prova alla connessione. Nessuno impedisce gli attacchi relay: un client può verificare la prova di un agente AI o server autentico e affidabile, ma cifrare poi il traffico verso un sistema diverso e malevolo.
Sardar ha riassunto il presupposto di fondo con una formula netta: nel confidential computing bisogna comunque fidarsi del produttore hardware, e “non c’è assolutamente modo di aggirarlo”. Accettata questa radice di fiducia, il protocollo avrebbe dovuto coprire il resto. La ricerca mostra invece tre livelli di legame crittografico tra prova e connessione: il primo aggancia la prova allo scambio Diffie-Hellman, il secondo alla chiave di traffico dell’handshake client, il terzo alla chiave applicativa usata per cifrare i dati sensibili.
Dei sette meccanismi studiati, tre raggiungono solo il primo livello, mentre gli altri non arrivano nemmeno a quella soglia. La mitigazione proposta dal team, basata su un binder costruito dal segreto dell’handshake TLS e dalla chiave pubblica del server, raggiunge formalmente il secondo livello. Il terzo, quello più vicino alla protezione dei dati realmente scambiati dopo l’apertura della connessione, secondo il paper potrebbe non essere possibile nell’architettura attuale senza alterare proprietà di TLS 1.3.
Il problema non resta confinato ai modelli accademici. Sono state analizzate quattro implementazioni reali: Meta Private Processing per WhatsApp, Edgeless Systems Contrast, la piattaforma open source Cocos AI e un proof-of-concept del Confidential Computing Consortium. Le prime tre sono in produzione; per Cocos AI gli attacchi riguardano le versioni dalla 0.4.0 alla 0.8.2. La disclosure ha portato alla vulnerabilità CVE-2026-33697, con punteggio 7.5 e severità alta. I gruppi di lavoro CCC Attestation SIG e IETF TLS hanno riconosciuto gli attacchi relay: per il confidential computing, la fiducia non è più solo una questione di hardware, ma di architettura del protocollo che collega quella prova ai dati in movimento.