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

[Yuxuan Song <[e-mail]>]

Hi Usama, 

Thanks for the information. We are currently working on it, we'll share our latest results in the next IETF meeting. 

BR, 
Yuxuan. 

> De: "Muhammad Usama Sardar" <[e-mail]>
> À: "lake" <[e-mail]>
> Envoyé: Dimanche 11 Janvier 2026 02:58:26
> Objet: [Lake] Fwd: [Ufmrg] Relay Attacks in Intra-handshake Attestation for
> Confidential Agentic AI Systems

> 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 [ mailto:[e-mail] |
> <[e-mail]> ]
> To: 	[ mailto:[e-mail] | [e-mail] ] [ mailto:[e-mail] |
> <[e-mail]> ] , UFMRG IRTF [ mailto:[e-mail] | <[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/ |
> https://datatracker.ietf.org/doc/draft-jiang-seat-dynamic-attestation/ ]

> [1] [
> https://ai.meta.com/static-resource/private-processing-technical-whitepaper |
> 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
> |
> 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
> |
> https://github.com/CCC-Attestation/meetings/blob/main/materials/MarkusRudy.contrast-atls-ccc-attestation.pdf
> ]

> [4] [ https://docs.cocos.ultraviolet.rs/atls |
> https://docs.cocos.ultraviolet.rs/atls ]

> [5] [ https://github.com/ccc-attestation/attested-tls-poc |
> https://github.com/ccc-attestation/attested-tls-poc ]

> [6] [ https://datatracker.ietf.org/doc/draft-ietf-lake-ra/ |
> https://datatracker.ietf.org/doc/draft-ietf-lake-ra/ ]

> [7] [ https://confer.to/blog/2026/01/private-inference/ |
> 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
> |
> https://github.com/ConferLabs/confer-proxy/blob/0f69f522f7597c6587741055e86ae802c10891ab/src/main/java/org/moxie/confer/proxy/attestation/AttestationService.java#L145
> ]

> --
> Lake mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]