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

[Muhammad Usama Sardar <[e-mail]>]

Hi SEAT and UFMRG,

Since some WG participants have shown a lot of interest in our work and 
also recently brought it to RG as well and seem to be patiently waiting 
for it, we are happy to update that the peer-review for paper and 
artifacts is almost over.

The paper has been accepted with /shepherding/ (see below) at ESORICS'26 
[10], a CORE rank A security conference [11]. Yesterday we received 
three reviews, all of which are very encouraging. In our understanding, 
there are no technical objections to either the core methodology in the 
paper or the artifacts (both symbolic and paper-and-pen analysis). There 
appear to be some requests for a more clear presentation on a couple of 
items, and more clarity on the future work.

We would like to share our understanding of the next steps in the 
shepherding process at ESORICS'26:

  * Within the next two days, the ESORICS shepherd will provide
    additional review and list of revision points.
  * /Latest/ by June 26 (11:59 p.m. AoE), we will work on the revisions
    and coordinate with the ESORICS shepherd to finalize the paper.

We intend to stay highly respectful of the community's time and thus 
release the artifacts and paper only after the ESORICS shepherd's 
confirmation. Based on that, here are the next steps that the WG/RG can 
expect:

  * *Artifacts*: If the ESORICS shepherd's list of revision points does
    not include any concern on artifacts, WG/RG can expect the artifacts
    to be released under Apache-2.0 License, allowing the WG/RG to carry
    out further research on top of that. If there is any concern on
    artifacts, we will wait for the ESORICS shepherd's confirmation
    before releasing the artifacts. There are also other dependencies:
    we have already requested creation of a repo from the co-chairs of
    CCC Attestation SIG, where this is an adopted project [12].
  * *Preprint*: We will share the paper preprint /latest/ by June 26
    (11:59 p.m. AoE).
  * *Presentation*: Unfortunately, UFMRG is not meeting in Vienna [13].
    We would ask for a slot in SEAT and likely present as follows:
      o Insights from symbolic analysis: Usama
      o Insights from Agentic AI use case: Slava (to be confirmed)
      o Insights from paper-and-pen analysis: Jean-Marie (to be confirmed)

We hope the paper will provide a useful input for SEAT, and a great 
motivation for UFMRG on how formal methods can be used to find the 
high-severity vulnerabilities in apparently secure protocols.

We would like to thank Eric Rescorla, Juho Forsen, Markus Rudy, Mariam 
Moustafa, Tjaden Hess, Yuning Jiang, Pavel Nikonorov, and Casey Wilson 
for their insightful contributions. We also thank Paul Wouters, the 
responsible AD back then, who requested an /exhaustive/ analysis of 
existing implementations of intra-handshake attestation, and this work 
aims to fulfill that requirement.

We will happily incorporate any feedback from the WG/RG in the follow-up 
work.

Best regards,

Usama, Slava (Viacheslav), and Jean-Marie


On 03.03.26 18:47, Muhammad Usama Sardar wrote:
>
> Hi all,
>
> 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.
>
> Best regards,
> Usama, Slava (Viacheslav), and Jean-Marie
>
> On 11.01.26 02:17, Muhammad Usama Sardar wrote:
>>
>> 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
>>
>>  1. Client's TLS nonce
>>  2. Client's Attestation nonce
>>  3. Early exporter
>>  4. (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*:
>>
>>  1. Hash (Client's TLS nonce || Server's public key)
>>  2. 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*
>>
>>  1. Edgeless Systems Contrast [3]: uses binding mechanism *B*.2
>>  2. Cocos AI [4]
>>  3. CCC proof-of-concept [5]: Implementation of
>>     draft-fossati-tls-attestation
>>  4. 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*
>>
>>  1. Shared DH secret (g^xy)
>>  2. Client's handshake traffic key (htsc)
>>  3. 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/

[10] https://sites.google.com/di.uniroma1.it/esorics2026/home

[11] https://portal.core.edu.au/conf-ranks/515/

[12] https://lists.confidentialcomputing.io/g/attestation/message/321

[13] 
https://mailarchive.ietf.org/arch/msg/ufmrg/0-gvfvCALhXbOEESkLuLCwMSXCM/