Distributors are attempting to place “confidential computing” because the technical spine of Europe’s sovereign cloud ambitions. However new analysis exhibits {that a} safety protocol used to show cryptographic belief within the system could have a elementary architectural flaw.
Confidential computing rests on a mechanism known as distant attestation, through which a server cryptographically proves to a consumer that it’s working inside a real, unmodified Trusted Execution Atmosphere (TEE) earlier than any delicate information modifications arms. Intel’s product pages promise TDX will “add safeguards to information sovereignty and governance.” Google Cloud describes its confidential computing infrastructure as providing “full, auditable management over entry to buyer information.”
In Could, The Register reported that the chip beneath the chip, the administration engines working beneath the working system on Intel and AMD silicon, falls outdoors what European sovereignty frameworks like SecNumCloud truly assess. That left an open query concerning the layer above the silicon: the protocol meant to show the chip itself might be trusted.
New, independently verified analysis solutions it, and the reply is just not reassuring.
A protocol that guarantees greater than it proves
Muhammad Usama Sardar, a researcher at TU Dresden, has spent the previous two years formally verifying whether or not that protocol, often called attested TLS, truly does what it claims. Utilizing ProVerif, a instrument for the symbolic safety evaluation of protocols, he and his co-authors found that it largely doesn’t.
Their latest paper, Identity Crisis in Confidential Computing, printed with co-authors Mariam Moustafa and Tuomas Aura and offered on the AsiaCCS 2026 convention, discovered diversion assaults in opposition to two state-of-the-art attested TLS protocols. A connection meant for one server might be silently redirected to a special, compromised machine working equivalent software program, wherever on this planet, with out the consumer ever figuring out. The meant server has executed nothing mistaken. The attacker merely exploits the truth that the protocol checks the software program’s integrity, not its location.
The latest paper, Intra-handshake.fail, printed with co-authors Viacheslav Dubeyko and Jean-Marie Jacquet and accepted for ESORICS 2026, goes additional. It examines what the trade calls intra-handshake attestation, the place proof is generated in the course of the TLS handshake itself, and assessments seven other ways of cryptographically binding that proof to the underlying connection. None of them stop relay assaults, through which a consumer verifies the proof of a real, reliable AI agent or server however finally ends up encrypting its site visitors to a wholly completely different, malicious one. The beginning assumption in all of that is that the {hardware} itself might be trusted.
“In confidential computing, you must belief the {hardware} producer anyway,” Sardar informed The Register. “There’s completely no method round this.” With that root of belief accepted, he argues, the protocol layer was supposed to offer every little thing else. His analysis exhibits it supplies far lower than assumed.
Three ranges of belief
The researchers formalise the issue as three more and more strict ranges of cryptographic binding between the attestation proof and the precise TLS connection it’s meant to vouch for.
The weakest, degree one, ties proof solely to the very first key change within the handshake, the Diffie-Hellman step, the place consumer and server agree on a shared secret earlier than both facet has confirmed who they’re. Degree two ties it to the consumer’s handshake site visitors key, overlaying every little thing as much as the server’s id affirmation. Degree three, the strongest and the one which issues most in observe, ties proof to the appliance site visitors key itself, the important thing truly used to encrypt the delicate information a consumer sends as soon as the connection is reside.
Sardar’s intensive evaluation in ProVerif targeted on intra-handshake attestation; post-handshake attestation fell outdoors its scope. Three of the seven binding mechanisms examined obtain degree one. The remaining fail even that baseline.
His crew’s personal proposed mitigation, a cryptographic binder constructed from the TLS handshake secret mixed with the server’s public key, formally achieves degree two. Degree three, the paper concludes, “will not be attainable” inside intra-handshake attestation as presently architected, with out breaking properties of TLS 1.3 that the protocol was by no means designed to surrender.
In plain phrases: the most effective repair out there as we speak proves a consumer is speaking to the correct machine firstly of a handshake. It can’t show that the information despatched minutes later continues to be going to that very same machine.
Manufacturing techniques, not laboratory proofs of idea
The vulnerability is just not confined to educational fashions. Sardar’s crew formally analysed 4 real-world implementations of intra-handshake attestation: Meta’s Personal Processing system for WhatsApp, Edgeless Programs’ Distinction, the open-source Cocos AI platform, and a proof-of-concept maintained by the Confidential Computing Consortium’s (CCC) Attestation Particular Curiosity Group. The primary three of the 4 are working in manufacturing as we speak. The assaults apply to each model of Cocos AI between 0.4.0 and 0.8.2. The category of flaw itself is just not new. Sardar’s crew notes the assaults are adequately subtle to have gone undiscovered for years earlier than formal evaluation caught them.
The accountable disclosure resulted in CVE-2026-33697, rated 7.5 on the Frequent Vulnerability Scoring System, excessive severity. For comparability, the researchers be aware of their paper that BadRAM, the 2024 reminiscence aliasing assault in opposition to AMD’s SEV-SNP that made headlines in its personal proper, scored 5.3. The CCC Attestation SIG’s repository lists CVE-2026-33697 because the highest-scoring vulnerability amongst a cluster of latest confidential computing flaws, forward of Fabricked (5.9), BreakFAST (5.9) and Staleus (4.0).
The working group and the IETF’s TLS working group have each formally acknowledged the relay assaults. “As carried out as we speak, attested TLS is just not mature but,” Sardar informed The Register. “We’re investigating additional, and we’re assured there are extra points but to be found.”
What makes the discovering extra pointed is who missed it first. Meta commissioned an in depth safety evaluation of its WhatsApp implementation from Trail of Bits, a well-regarded safety agency, earlier than Sardar’s crew examined it. That evaluation didn’t detect the relay assault.
It’s methodology, not incompetence, that explains the hole. The ESORICS paper data that Sardar’s crew contacted Path of Bits instantly, who confirmed no formal strategies have been used of their evaluation course of. Formal verification instruments like ProVerif test a protocol exhaustively in opposition to each situation an outlined risk mannequin permits. A guide audit, nevertheless thorough, samples. A refined flaw in how proof is certain to a connection can slip previous a sampled evaluation and nonetheless be provably damaged underneath exhaustive formal evaluation.
The Attestation Particular Curiosity Group of the CCC, which governs the adopted proof-of-concept undertaking Sardar examined, discovered its personal system weak to the identical relay assaults.
A repository no one would create
The vulnerability itself had already been by means of a prolonged, orderly disclosure course of. Sardar’s crew flagged it to Cocos AI in October 2025, the seller acknowledged it two months later, and the CVE was printed in March 2026.
What occurred subsequent was completely different.
On 14 June, Sardar wrote to the chairs of the CCC’s Attestation Particular Curiosity Group requesting a brand new public GitHub repository, named relay-attacks-in-intra-handshake, so his formal evaluation artefacts for the relay assaults might be launched underneath an Apache 2.0 licence, to be used by researchers and the standardization group. He referenced an present, adopted project underneath the identical group’s governance, the type of administrative step that, on paper, ought to take minutes.
Three days later, on 17 June, he despatched a reminder. The next day, a second, noting the artefact hyperlink was wanted for the paper’s remaining model. On 24 June, ten days after the unique request, he wrote once more, this time with out the diplomatic padding: “I don’t see cause for such a delay, because the requested repo is a part of an adopted undertaking and creation of a brand new repo is just not such a time-consuming job.” The brand new repository nonetheless didn’t exist.
The CCC’s Attestation Particular Curiosity Group is made up of representatives from the {hardware} and cloud distributors whose merchandise the analysis issues. That truth requires no embellishment. A working group populated by the businesses whose attestation implementations have been simply proven to be weak to relay assaults didn’t act, for over per week and throughout three written reminders, on a request to publish proof of that vulnerability.
Since no repository had been created earlier than the paper’s remaining model went to the writer, Sardar printed the artefacts anyway, however inside an present CCC-affiliated repository fairly than the devoted one he had requested for. He informed The Register the repository had initially been constructed for an unrelated undertaking: “For the reason that monopoly [of vendor-dominated working groups over this infrastructure] continues, we have now launched the artifacts to tell the group and for researchers to analyse it independently.”
The CVE stands regardless, credited and public. The delay modifications nothing concerning the underlying arithmetic.
BSI reaches the identical verdict
None of this requires taking Sardar’s interpretation on religion. A world away from the IETF mailing lists, Germany’s Federal Workplace for Info Safety (BSI) arrived at a carefully associated conclusion by means of its personal, completely separate channel.
Carina Hilt, deputy press spokesperson at BSI, was requested instantly about confidential computing’s position in digital sovereignty. She informed The Register the know-how capabilities as “a defense-in-depth element,” strengthening tenant isolation and defending confidentiality and integrity, however not availability. Crucially, she added that “dependencies on different providers, similar to id and key administration and so on., are additionally not mitigated by CC.”
That’s, in different phrases, an institutional echo of precisely the hole Sardar’s protocol evaluation exposes: confidential computing’s ensures cease effectively wanting guaranteeing who truly controls the keys and the id infrastructure a deployment depends upon.
Pressed additional on vendor advertising claims, BSI didn’t soften its place. “The distributors’ positioning on CC may give an excessive amount of weight to its technical capabilities,” the spokesperson informed The Register. “CC alone can’t fulfill the necessities for digital sovereignty.”
What the chipmakers say
Mikael Moreau, Intel’s France Communication Supervisor, was requested particularly concerning the attestation infrastructure underpinning its TDX confidential computing know-how, and whether or not Intel’s personal position in that infrastructure constitutes a dependency. He stated the corporate does “not take into account its attestation infrastructure to be a limitation to sovereignty ensures,” arguing that any reliance on Intel’s silicon and certificates root of belief is “bounded.” Intel is just not within the buyer’s workload information path, doesn’t obtain buyer plaintext by means of attestation, and the operational belief determination might be delegated to an unbiased verifier or retained by the client.
That may be a rigorously constructed, technically defensible reply. It explains the structure, not the regulation. Intel was requested whether or not its attestation infrastructure poses a sovereignty danger underneath RISAA, the 2024 US regulation that may compel {hardware} producers to cooperate with secret intelligence orders. That query went unanswered.
Google didn’t reply to a request for remark for this text.
Acknowledged in every single place besides the gross sales pitch
Sardar’s findings prompted 4 completely different institutional responses.
The IETF’s Safe Proof and Attestation Transport (SEAT) working group, shaped after a bunch together with Sardar efficiently argued for it at a Birds of a Feather session at IETF 123 in Madrid in July 2025, wrote his correlation properties instantly into its constitution as an specific, necessary requirement for any new specification work. That may be a requirements physique doing precisely what it ought to, constructing formal verification into the method fairly than bolting it on afterwards.
The IETF’s TLS working group formally acknowledged the identical assaults, with out adopting a binding requirement of its personal. The CCC’s inaction over ten days meant Sardar printed the proof himself, with out the working group’s assist.
None of that reached the gross sales dialog. Intel and Google proceed to market confidential computing as proof of sovereign, verified safety. Requested instantly concerning the infrastructure underpinning that declare, Intel’s reply stopped wanting the authorized query at its centre. Google didn’t reply in any respect.
For European CIOs and procurement officers, this raises a query past the one normally requested. It’s not solely which firm owns the cloud or which authorities can compel which {hardware} producer. It’s whether or not the cryptographic handshake meant to show a workload is working the place it claims to be working might be trusted in any respect.
The extent that timing guidelines out
Sardar’s personal mitigation reaches degree two. Degree three, the one that truly issues to a buyer attempting to confirm their workload continues to be protected as soon as information begins flowing, will not be achievable in any respect throughout the present structure of intra-handshake attestation, the place proof is generated in the course of the handshake itself. The timing is the issue. Degree three requires binding the proof to the important thing that encrypts the precise utility information, however by the point that key exists, the proof has already been despatched, except the TLS protocol itself is considerably modified. Put up-handshake attestation waits till after that time, when the secret’s already there to bind in opposition to.
“We imagine post-handshake attestation alone can obtain degree three binding,” Sardar informed The Register, warning that newer proposals combining each approaches add pointless complexity with out including safety. His advice to the IETF’s TLS working group is blunt: builders ought to abandon intra-handshake attestation altogether. ®
Source link
