Confidential Computing
Standardization and Open-source Implementation of Attested TLS for Confidential Computing
February 1, 2026
12:05 PM – 12:25 PM Add to calendar
12:05 PM – 12:25 PM Add to calendar
UD6.215
<h2>Summary</h2>
<p>Attested TLS is a fundamental building block of confidential computing. We have defended our position (cf. <a href="https://datatracker.ietf.org/doc/bofreq-fossati-tls-exported-attestation-expat/">expat BoF</a>) to standardize the attested TLS protocols for confidential computing in the <a href="https://www.ietf.org/">IETF</a>, and a new Working Group named <a href="https://datatracker.ietf.org/wg/seat/about/">Secure Evidence and Attestation Transport (SEAT)</a> has been formed to exclusively tackle this specific problem.
In this talk, we present the design choices for standardization of attested TLS, namely pre-handshake attestation, intra-handshake attestation, and post-handshake attestation. We present the journey of standardization effort showing replay, diversion and relay attacks on pre-handshake attestation and intra-handshake attestation (see <a href="https://www.researchgate.net/publication/398839141_Identity_Crisis_in_Confidential_Computing_Formal_Analysis_of_Attested_TLS">paper</a> and <a href="https://github.com/CCC-Attestation/formal-spec-id-crisis">formal proof</a>). We finally present the post-handshake attestation <a href="https://datatracker.ietf.org/doc/draft-fossati-seat-expat/">candidate draft</a> for standardization to gather feedback from the community, so that it can be accommodated in the standardization. </p>
<h2>Technical details</h2>
<p>We propose a specification that defines a method for two parties in a communication interaction to exchange Evidence and Attestation Results using exported authenticators, as defined in <a href="https://datatracker.ietf.org/doc/html/rfc9261">RFC9261</a>. Additionally, we introduce the cmw_attestation extension, which allows attestation credentials to be included directly in the Certificate message sent during the Exported Authenticator-based post-handshake authentication. The approach supports both the passport and background check models from the <a href="https://datatracker.ietf.org/doc/rfc9334/">RATS architecture</a> while ensuring that attestation remains bound to the underlying communication channel.</p>
<h2>WiP Implementation</h2>
<p><a href="https://github.com/tls-attestation/attestation-exported-authenticators">WiP Implementation</a> uses the <a href="https://github.com/veraison/rust-cmw">veraison/rust-cmw</a> implementation of <a href="https://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/">RATS conceptual messages wrapper</a>. It includes a test which demonstrates using it with QUIC (for transport) and Intel TDX (as confidential compute platform): <a href="https://github.com/tls-attestation/attestation-exported-authenticators/blob/main/tests/quic_tdx.rs">tests/quic_tdx.rs</a>.</p>
<h2>Useful links</h2>
<ul>
<li>IETF SEAT WG: https://datatracker.ietf.org/wg/seat/about/</li>
<li>Subscribe to SEAT WG mailing list: https://mailman3.ietf.org/mailman3/lists/seat.ietf.org/</li>
<li>Spec: https://datatracker.ietf.org/doc/draft-fossati-seat-expat/</li>
<li>Proposed for adoption at CCC Attestation SIG: https://github.com/CCC-Attestation/governance/issues/20</li>
</ul>
Additional information
| Live Stream | https://live.fosdem.org/watch/ud6215 |
|---|---|
| Type | devroom |
| Language | English |
More sessions
| 2/1/26 |
<p>Welcome to the 7th iteration of the Confidential Computing devroom! In this welcome session, we will give a very brief introduction to confidential computing and the devroom, and we will give an honorable mention to all the folks that contributed to this devroom, whether they are presenting or not.</p>
|
| 2/1/26 |
<p>Hardware extensions for confidential computing establish a strict trust boundary between a virtual machine and the host hypervisor. From the guest’s perspective, any interaction crossing this boundary must be treated as untrusted and potentially malicious. This places significant hardening demands on guest operating systems, especially around firmware interfaces, device drivers, and boot components.</p> <p>This talk explores how COCONUT-SVSM can act as a trusted proxy between the hypervisor ...
|
| 2/1/26 |
<p>Currently QEMU hypervisor based confidential guests on SEV-SNP, SEV-ES and TDX are not at-par with other non-confidential guests in terms of restartability. For these confidential guests, once their initial state is locked-in and its private memory pages, CPU register states are encrypted, its state is finalized and it cannot be changed. This means, in order to restart a confidential guest, a new confidential guest context must be created in KVM and CPU registers, private memory pages ...
|
| 2/1/26 |
<p>In this talk, I will first introduce Intellectual Property Encapsulation, the confidential computing feature of Texas Instruments MSP430 microcontrollers, and multiple vulnerabilities we have found in it. Then, I will propose two methods of mitigating these vulnerabilities: first, a software-only solution that can be deployed on existing devices; second, a standard-compliant reimplementation of the hardware on an open-source CPU with more advanced security features and an extensive testing ...
|
| 2/1/26 |
<p>Confidential computing is rapidly evolving with Intel TDX, AMD SEV-SNP, and Arm CCA. However, unlike TDX and SEV-SNP, Arm CCA lacks publicly available hardware, making performance evaluation difficult. While Arm's hardware simulation provides functional correctness, it lacks cycle accuracy, forcing researchers to build best-effort performance prototypes by transplanting their CCA-bound implementations onto non-CCA Arm boards and estimating CCA overheads in software. This leads to duplicated ...
|
| 2/1/26 |
<p>Confidential Computing poses a unique challenge of Attestation Verification. The reason is, Attester in Confidential Computing is infact a collection of Attesters, what we call as Composite Attester. One Attester is a Workload which runs in a CC Environment, while the other Attester is the actual platform on which the Workload is executed. The two Attesters have separate Supply Chains (one been the Workload Owner deploying the Workload) while the Platform is a different Supplier, say Intel ...
|
| 2/1/26 |
<p>We have released the sample codes for remote attestation on cloud confidential computing services. I report the lessons learned from them. https://github.com/iisec-suzaki/cloud-ra-sample The samples cover multiple types of Trusted Execution Environments (TEEs): (1) Confidential VMs, including AMD SEV-SNP on Azure, AWS, and GCP, and Intel TDX on Azure and GCP; (2) TEE enclaves using Intel SGX on Azure; and (3) hypervisor-based enclaves using AWS Nitro Enclaves. As verifiers, the samples make ...
|
