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. 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." 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. New, independently verified research answers it, and the answer is not reassuring. A protocol that promises more than it proves 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. 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. 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. "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. Three levels of trust 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. 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. 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. 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. 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 same machine. Production systems, not laboratory proofs of concept The vulnerability is not confined to academic models. Sardar's team formally analysed four real-world implementations of intra-handshake attestation: Meta's Private Processing system for WhatsApp, Edgeless Systems' Contrast, the open-source Cocos AI platform, and a proof-of-concept maintained by the Confidential Computing Consortium's (CCC) Attestation Special Interest Group. The first three of the four are running in production today. The attacks apply to every version of Cocos AI between 0.4.0 and 0.8.2. The class of flaw itself is not new. Sardar's team notes the attacks are subtle enough to have gone undiscovered for years before formal analysis caught them. The responsible disclosure resulted in CVE-2026-33697, rated 7.5 on the Common Vulnerability Scoring System, high severity. For comparison, the researchers note in their paper that BadRAM, the 2024 memory aliasing attack against AMD's SEV-SNP that made headlines in its own right, scored 5.3. The CCC Attestation SIG's repository lists CVE-2026-33697 as the highest-scoring vulnerability among a cluster of recent confidential computing flaws, ahead of Fabricked (5.9), BreakFAST (5.9) and Staleus (4.0). The working group and the IETF's TLS working group have both formally acknowledged the relay attacks. "As implemented today, attested TLS is not mature yet," Sardar told The Register. "We are investigating further, and we are confident there are more issues yet to be discovered." What makes the finding more pointed is who missed it first. Meta commissioned an extensive security review of its WhatsApp implementation from Trail of Bits, a well-regarded security firm, before Sardar's team examined it. That review did not detect the relay attack. It is methodology, not incompetence, that explains the gap. The ESORICS paper records that Sardar's team contacted Trail of Bits directly, who confirmed no formal methods were used in their review process. Formal verification tools like ProVerif check a protocol exhaustively against every scenario a defined threat model allows. A manual audit, however thorough, samples. A subtle flaw in how evidence is bound to a connection can slip past a sampled review and still be provably broken under exhaustive formal analysis. The Attestation Special Interest Group of the CCC, which governs the adopted proof-of-concept project Sardar tested, found its own system vulnerable to the same relay attacks. A repository nobody would create The vulnerability itself had already been through a lengthy, orderly disclosure process. Sardar's team flagged it to Cocos AI in October 2025, the vendor acknowledged it two months later, and the CVE was published in March 2026. What happened next was different. On 14 June, Sardar wrote to the chairs of the CCC's Attestation Special Interest Group requesting a new public GitHub repository, named relay-attacks-in-intra-handshake, so his formal analysis artefacts for the relay attacks could be released under an Apache 2.0 licence, for use by researchers and the standardization community. He referenced an existing, adopted project under the same group's governance, the kind of administrative step that, on paper, should take minutes. Three days later, on 17 June, he sent a reminder. The following day, a second, noting the artefact link was needed for the paper's final version. On 24 June, ten days after the original request, he wrote again, this time without the diplomatic padding: "I do not see a good reason for such a delay, since the requested repo is part of an adopted project and creation of a new repo is not such a time-consuming task." The new repository still did not exist. The CCC's Attestation Special Interest Group is made up of representatives from the hardware and cloud vendors whose products the research concerns. That fact requires no embellishment. A working group populated by the companies whose attestation implementations were just shown to be vulnerable to relay attacks did not act, for over a week and across three written reminders, on a request to publish proof of that vulnerability. Since no repository had been created before the paper's final version went to the publisher, Sardar published the artefacts anyway, but inside an existing CCC-affiliated repository rather than the dedicated one he had asked for. He told The Register the repository had originally been built for an unrelated project: "Since the monopoly [of vendor-dominated working groups over this infrastructure] continues, we have released the artifacts to inform the community and for researchers to analyse it independently." The CVE stands regardless, credited and public. The delay changes nothing about the underlying mathematics. BSI reaches the same verdict None of this requires taking Sardar's interpretation on faith. A world away from the IETF mailing lists, Germany's Federal Office for Information Security (BSI) arrived at a closely related conclusion through its own, entirely separate channel. Carina Hilt, deputy press spokesperson at BSI, was asked directly about confidential computing's role in digital sovereignty. She told The Register the technology functions as "a defense-in-depth component," strengthening tenant isolation and protecting confidentiality and integrity, but not availability. Crucially, she added that "dependencies on other services, such as identity and key management etc., are also not mitigated by CC." That is, in other words, an institutional echo of exactly the gap Sardar's protocol analysis exposes: confidential computing's guarantees stop well short of guaranteeing who actually controls the keys and the identity infrastructure a deployment depends on. Pressed further on vendor marketing claims, BSI did not soften its position. "The vendors' positioning on CC might give too much weight to its technical capabilities," the spokesperson told The Register. "CC alone cannot satisfy the requirements for digital sovereignty." What the chipmakers say Mikael Moreau, Intel's France Communication Manager, was asked specifically about the attestation infrastructure underpinning its TDX confidential computing technology, and whether Intel's own role in that infrastructure constitutes a dependency. He said the company does "not consider its attestation infrastructure to be a limitation to sovereignty guarantees," arguing that any reliance on Intel's silicon and certificate root of trust is "bounded." Intel is not in the customer's workload data path, does not receive customer plaintext through attestation, and the operational trust decision can be delegated to an independent verifier or retained by the customer. That is a carefully constructed, technically defensible answer. It explains the architecture, not the law. Intel was asked whether its attestation infrastructure poses a sovereignty risk under RISAA, the 2024 US law that can compel hardware manufacturers to cooperate with secret intelligence orders. That question went unanswered. Google did not respond to a request for comment for this article. Acknowledged everywhere except the sales pitch Sardar's findings prompted four different institutional responses. The IETF's Secure Evidence and Attestation Transport (SEAT) working group, formed after a group including Sardar successfully argued for it at a Birds of a Feather session at IETF 123 in Madrid in July 2025, wrote his correlation properties directly into its charter as an explicit, mandatory requirement for any new specification work. That is a standards body doing exactly what it should, building formal verification into the process rather than bolting it on afterwards. The IETF's TLS working group formally acknowledged the same attacks, without adopting a binding requirement of its own. The CCC's inaction over ten days meant Sardar published the evidence himself, without the working group's help. None of that reached the sales conversation. Intel and Google continue to market confidential computing as proof of sovereign, verified protection. Asked directly about the infrastructure underpinning that claim, Intel's answer stopped short of the legal question at its centre. Google did not answer at all. For European CIOs and procurement officers, this raises a question beyond the one usually asked. It is no longer only which company owns the cloud or which government can compel which hardware manufacturer. It is whether the cryptographic handshake meant to prove a workload is running where it claims to be running can be trusted at all. The level that timing rules out Sardar's own mitigation reaches level two. Level three, the one that actually matters to a customer trying to verify their workload is still protected once data starts flowing, may not be achievable at all within the current architecture of intra-handshake attestation, where evidence is generated during the handshake itself. The timing is the problem. Level three requires binding the evidence to the key that encrypts the actual application data, but by the time that key exists, the evidence has already been sent, unless the TLS protocol itself is significantly changed. Post-handshake attestation waits until after that point, when the key is already there to bind against. "We believe post-handshake attestation alone can achieve level three binding," Sardar told The Register, warning that newer proposals combining both approaches add unnecessary complexity without adding security. His recommendation to the IETF's TLS working group is blunt: developers should abandon intra-handshake attestation altogether. ®
source
https://www.theregister.com/security/2026/07/04/confidential-computings-core-trust-mechanism-is-broken-the-fix-may-not-exist/5266056
Thursday, July 16, 2026
