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

[Muhammad Usama Sardar <[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

 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 public key does not leak.

In general, all solutions fail when server's public 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