Confidential computing's core trust mechanism is broken. The fix may not exist

Jump to main content

Search

REG AD

SECURITY

Confidential computing's core trust mechanism is broken. The fix may not exist

Attested TLS: the handshake that can't prove who's on the other end

Kim Loohuis

Kim<br>Loohuis

Published<br>sat 4 Jul 2026 // 11:03 UTC

Vendors are trying to position "confidential computing" as the technical backbone of Europe's sovereign cloud ambitions. But new research shows that a security protocol used to prove cryptographic trust in the system may have a fundamental architectural flaw.<br>Confidential computing rests on a mechanism called remote attestation, in which a server cryptographically proves to a client that it is running inside a genuine, unmodified Trusted Execution Environment (TEE) before any sensitive data changes hands. Intel's product pages promise TDX will "add safeguards to data sovereignty and governance." Google Cloud describes its confidential computing infrastructure as offering "full, auditable control over access to customer data."<br>In May, The Register reported that the chip beneath the chip, the management engines running below the operating system on Intel and AMD silicon, falls outside what European sovereignty frameworks like SecNumCloud actually assess. That left an open question about the layer above the silicon: the protocol meant to prove the chip itself can be trusted.

REG AD

New, independently verified research answers it, and the answer is not reassuring.

REG AD

A protocol that promises more than it proves<br>Muhammad Usama Sardar, a researcher at TU Dresden, has spent the past two years formally verifying whether that protocol, known as attested TLS, actually does what it claims. Using ProVerif, a tool for the symbolic security analysis of protocols, he and his co-authors discovered that it largely does not.<br>Their recent paper, Identity Crisis in Confidential Computing, published with co-authors Mariam Moustafa and Tuomas Aura and presented at the AsiaCCS 2026 conference, found diversion attacks against two state-of-the-art attested TLS protocols. A connection intended for one server can be silently redirected to a different, compromised machine running identical software, anywhere in the world, without the client ever knowing. The intended server has done nothing wrong. The attacker simply exploits the fact that the protocol checks the software's integrity, not its location.<br>The most recent paper, Intra-handshake.fail, published with co-authors Viacheslav Dubeyko and Jean-Marie Jacquet and accepted for ESORICS 2026, goes further. It examines what the industry calls intra-handshake attestation, where evidence is generated during the TLS handshake itself, and tests seven different ways of cryptographically binding that evidence to the underlying connection. None of them prevent relay attacks, in which a client verifies the evidence of a genuine, trustworthy AI agent or server but ends up encrypting its traffic to an entirely different, malicious one. The starting assumption in all of this is that the hardware itself can be trusted.<br>"In confidential computing, you have to trust the hardware manufacturer anyway," Sardar told The Register. "There is absolutely no way around this." With that root of trust accepted, he argues, the protocol layer was supposed to provide everything else. His research shows it provides far less than assumed.<br>Three levels of trust<br>The researchers formalise the problem as three increasingly strict levels of cryptographic binding between the attestation evidence and the actual TLS connection it is meant to vouch for.<br>The weakest, level one, ties evidence only to the very first key exchange in the handshake, the Diffie-Hellman step, where client and server agree on a shared secret before either side has proven who they are. Level two ties it to the client's handshake traffic key, covering everything up to the server's identity confirmation. Level three, the strongest and the one that matters most in practice, ties evidence to the application traffic key itself, the key actually used to encrypt the sensitive data a client sends once the connection is live.

REG AD

Sardar's extensive analysis in ProVerif focused on intra-handshake attestation; post-handshake attestation fell outside its scope. Three of the seven binding mechanisms examined achieve level one. The rest fail even that baseline.<br>His team's own proposed mitigation, a cryptographic binder built from the TLS handshake secret combined with the server's public key, formally achieves level two. Level three, the paper concludes, "may not be possible" within intra-handshake attestation as currently architected, without breaking properties of TLS 1.3 that the protocol was never designed to give up.<br>In plain terms: the best fix available today proves a client is talking to the right machine at the start of a handshake. It cannot prove that the data sent minutes later is still going to that...