[Lake] Re: [Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems

[Mališa Vučinić <[e-mail]>]

Hi Usama,

Thanks for sharing, insightful. I added a 5-minute slot to the agenda as I understand that it would relate to EDHOC, not TLS.

Looking at the Relay Attack Scenario and the corresponding figure in [9], I would like to confirm with you that the Attacker maintains two separate sessions, one with the Relying Party and the other with the Attester (Legitimate Agent)?

I might be missing something from [9], but I don’t quite understand the link between the three Bindings Levels that you define and the actual mitigation of the attack. The attack that is explained in Relay Attack Scenario in [9] seems to be mitigated already with Binding Level 1 - shared DH secret. Is that correct? If so, the detail that I do not understand is which attack(s) are Level 2 and Level 3 bindings protecting against?

Best,
Mališa

> On Mar 3, 2026, at 19:01, Muhammad Usama Sardar <[e-mail]> wrote:
> 
> Hi lakers,
> 
> Following up with supporting public evidence: Cocos AI has publicly acknowledged [9] the relay attacks last Friday. 
> 
> # Context
> 
> As helpful context, Cocos AI [4] claimed their attested TLS to be the "best in the world" in the Confidential Computing Consortium and despite we having informed them repeatedly about the attacks after our formal analysis, they were continuing to misguide the community on social media. Anyway, we now respect their honesty and transparency, and we remain fully committed to helping them towards secure solutions.
> 
> # Cocos AI acknowledgment of attacks
> 
> Cocos AI (one of the implementers of the protocol) has publicly acknowledged [9] our email and the relay attacks we highlighted on their design and implementation in our email. Particularly, see the sections "Limitations and the Relay Attack" and "The Relay Attack Scenario" in [9]. Note that their description is almost a paraphrase of our email. There are some nits that we disagree with them but that doesn't matter much. They have essentially acknowledged the attacks and shared a short-term, medium-term and long-term roadmap for mitigations of the attacks. We believe this alone is sufficient supporting evidence.
> 
> We welcome any feedback. 
> 
> Chairs, if there is some time available and you feel it relevant, we would like to request 5 minutes to present our formal analysis for lake-ra draft.
> 
> Best regards,
> Usama, Slava (Viacheslav), and Jean-Marie
> 
> PS: You don't need to keep me in To/CC. I am back on list ;)
> 
> 
> On 11.01.26 02:58, Muhammad Usama Sardar wrote:
>> Hi lakers,
>> 
>> Sending this separately to keep the two discussions separate.
>> 
>> We discovered relay attacks in intra-handshake attestation implementations of attested TLS. Our intuition (no formal proof yet) is that the attacks should apply to attested EDHOC protocol in intra-handshake attestation [6] as well -- at least for the case of Responder as Attester.
>> 
>> Welcome any questions/thoughts/opinions.
>> 
>> -Usama
>> 
>> PS: For any follow-up, please keep me explicitly in To/CC.
>> 
>> 
>> 
>> -------- Forwarded Message --------
>> Subject: 	[Ufmrg] Relay Attacks in Intra-handshake Attestation for Confidential Agentic AI Systems
>> Date:	Sun, 11 Jan 2026 02:17:42 +0100
>> From:	Muhammad Usama Sardar <[e-mail]> <mailto:[e-mail]>
>> To:	[e-mail] <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>, UFMRG IRTF <[e-mail]> <mailto:[e-mail]>
>> 
>> 
>> 
>> Hi SEAT and UFMRG,
>> 
>> # Context
>> 
>> We (i.e., I, Dr. Viacheslav Dubeyko [IBM], and Prof. Jean-Marie Jacquet [University of Namur]) did an extensive exploration of binding mechanisms in intra-handshake attestation for confidential agentic AI systems, that was presented on mic at SEAT meeting 124 and later submitted as a draft [0] with focus on AI agent. In line with the scope of SEAT charter, we also did formal analysis in state-of-the-art tool ProVerif and we would like to share a summary of our findings from our formal analysis with the hope that the analysis provides important data points to WG for making informed decisions.
>> 
>> # Key Finding
>> 
>> All analyzed binding mechanisms and implementations are ad-hoc and all of them result in relay attacks.
>> 
>> Please note that this includes Meta's AI [1] for which a thorough security assessment [2] was carried out by Trail of Bits and they were unable to capture the relay attacks but as kindly clarified by Tjaden Hess, no formal methods were used in their review process. Our analysis shows the value of formal methods in the review process.
>> 
>> # Fundamental Issue
>> 
>> Basically, there is no binding of Evidence to the TLS connection in all of these implementations.
>> 
>> # TEE-agnostic System Model
>> Layered Attester (e.g., Intel TDX)
>> Composite Attester (e.g., Arm CCA)
>> # Scope of Attested TLS
>> Intra-handshake attestation
>> # Formalization Approach
>> 
>> Symbolic security analysis
>> # Formalization Tool
>> 
>> ProVerif
>> 
>> # Binding Mechanisms
>> 
>> A. We considered the following values for user-defined field "rdata" in TEEs
>> Client's TLS nonce
>> Client's Attestation nonce
>> Early exporter
>> (Hash of) Server's public key
>> Question for WG/RG: Is someone aware of any other value that folks use in "rdata"? If possible, please share a link to specification and/or implementation together.
>> 
>> B. Combinations:
>> We considered the following combinations of binding mechanisms from A:
>> Hash (Client's TLS nonce || Server's public key)
>> Hash (Client's Attestation nonce || Server's public key)
>> Question for WG/RG: Is someone aware of any other combination that folks use in "rdata"? If possible, please share a link to specification and/or implementation together.
>> 
>> 
>> 
>> # Prominent Industrial Implementations
>> 
>> Edgeless Systems Contrast [3]: uses binding mechanism B.2
>> Cocos AI [4]
>> CCC proof-of-concept [5]: Implementation of draft-fossati-tls-attestation
>> Meta’s AI [1]: uses binding mechanism A.1
>> Question for WG/RG: Is someone aware of any other intra-handshake attestation implementation? If possible, please share a link to specification and/or implementation together.
>> 
>> 
>> # Binding Levels
>> Shared DH secret (g^xy)
>> Client's handshake traffic key (htsc)
>> Client's application traffic key (atsc)
>> 
>> # Correlation Properties
>> G1: Correlation of Evidence to Shared DH Secret
>> G2: Correlation of Evidence to Client’s Handshake Traffic Key
>> G3: Correlation of Evidence to Client’s Application Traffic Key
>> 
>> # Results
>> 
>> We proved the proposition: G3 => G2 => G1
>> 
>> We discovered relay attacks in all above proposals for binding mechanisms as well as all implementations analyzed. We provide a formal proof of insecurity that all above binding mechanisms and implementations fail to even achieve G1 property (Level 1 binding).
>> 
>> Any binding that involves server's public key needs additional assumption that server's private key does not leak.
>> 
>> In general, all solutions fail when server's private key is leaked. In other words, extension of TLS with attestation in these implementations is not really bringing much benefit from a security perspective and rather giving a false sense of security.
>> 
>> We believe that it is not possible to achieve level 3 binding for intra-handshake attestation within the scope of SEAT charter.
>> 
>> 
>> # Implementation Issues
>> Meta's AI uses client's TLS nonce (instead of attestation nonce), and hence does not provide Evidence freshness.
>> Cocos AI abuses the SNI extension to convey attestation nonce.
>> Edgeless Systems Contrast was abusing the SNI extension to convey attestation nonce, and currently abusing the ALPN extension to convey attestation nonce.
>> 
>> # Proposed Mitigation
>> We propose a cryptographic binder and modify CertificateVerify message, which achieves level 2 binding.
>> 
>> # Paper and Artifacts
>> A paper draft has been prepared and artifacts are well-documented. If you are interested in reviewing one/both of them and can provide some feedback until 19th Jan, please reach out to me off-list. If someone can substantially improve the paper and/or artifacts, we are very welcoming to adding you as co-author. We will make the paper and artifacts public later on.
>> 
>> 
>> # Contributors
>> We thank Juho Forsén, Mariam Moustafa, Markus Rudy, Tjaden Hess, Yuning Jiang, and Pavel Nikonorov for sharing their insights and providing valuable feedback.
>> 
>> 
>> # Other known related implementations
>> Attested EDHOC: Our intuition (no formal proof yet) is that the attacks should apply to attested EDHOC protocol in intra-handshake attestation [6] as well -- at least for the case of Responder as Attester. We will reach out to LAKE WG to inform them about these attacks.
>> Attested Noise: Confer's private inference [7] uses binding mechanism A.4 [8] for Noise protocol. This implementation started just 3 weeks ago (with holidays in between) and is not mature yet. Anyway, we will reach out to the implementer (Moxie Marlinspike) to inform him about these attacks.
>> 
>> # Feedback/Ideas
>> We believe that we have explored all options in intra-handshake attestation within the scope of SEAT charter. We look forward to your thoughts and ideas on how we can mutually progress this work forward.
>> 
>> -Usama
>> 
>> [0] https://datatracker.ietf.org/doc/draft-jiang-seat-dynamic-attestation/
>> [1] https://ai.meta.com/static-resource/private-processing-technical-whitepaper
>> 
>> [2] https://github.com/trailofbits/publications/blob/master/reviews/2025-08-meta-whatsapp-privateprocessing-securityreview.pdf
>> 
>> [3] https://github.com/CCC-Attestation/meetings/blob/main/materials/MarkusRudy.contrast-atls-ccc-attestation.pdf
>> 
>> [4] https://docs.cocos.ultraviolet.rs/atls
>> [5] https://github.com/ccc-attestation/attested-tls-poc
>> 
>> [6] https://datatracker.ietf.org/doc/draft-ietf-lake-ra/
>> 
>> [7] https://confer.to/blog/2026/01/private-inference/
>> 
>> [8] https://github.com/ConferLabs/confer-proxy/blob/0f69f522f7597c6587741055e86ae802c10891ab/src/main/java/org/moxie/confer/proxy/attestation/AttestationService.java#L145
>> 
> [9] https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog/tee-tls-privacy/
> -- 
> Lake mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]