Why Your RA-TLS Private Key Is the Weakest Link - and How SVSM Fixes It

Forum|Forum|5 hours ago
June 15, 2026
0 replies
3 views

Rene
Staff

Authors:

Rene Kolga, Google Cloud Confidential Computing

Confidential computing promises something radical: you can run workloads on infrastructure you don't trust, and prove it. AMD SEV-SNP encrypts VM memory with keys the cloud operator can't access. Remote attestation lets a client verify that specific code is running inside genuine hardware isolation. And RA-TLS - Remote Attestation Transport Layer Security - ties that attestation to a TLS connection, so the client knows it's talking directly to the attested workload and not to something pretending to be it.

This @works. But most production RA-TLS deployments have a gap that undermines the guarantee: the TLS private key sits in guest memory where a runtime exploit can steal it.

This post explains the gap, why it matters more than people think, and how SVSM (Secure VM Service Module) key isolation closes it.

How RA-TLS Works

A proxy running inside a Confidential VM generates a TLS key pair at startup, computes a hash of the public key and embeds that hash into a hardware attestation token. The token is signed by the CPU's attestation key - fused into the silicon at manufacturing, impossible to extract or forge in software.

When a client connects, it completes a normal TLS handshake, then retrieves the attestation token over the established connection. The client verifies the hardware signature, confirms the hash inside the token matches the TLS public key it just received, and pins the session. If anything doesn't match - if someone tried to swap in a different TLS key, or relay a token from a different machine - the verification fails and the connection is rejected.

The binding is elegant: the attestation token says "this public key belongs to this Trusted Execution Environment (TEE)," and the TLS handshake proves the server holds the corresponding private key. Together, they guarantee the client is talking to the genuine machine.

But that guarantee rests on an assumption: the private key stays inside the TEE.

What Happens When It Doesn't

Here's a possible attack:

A workload runs in a Confidential VM. The proxy generates its TLS key pair, attests it, and starts serving clients.
An attacker finds a zero-day in a dependency, i.e. a memory corruption bug that allows arbitrary reads of process memory.
The attacker reads the TLS private key directly from the proxy's address space.
They also get the cached attestation token, which is served at a public endpoint.
The attacker stands up a rogue server using the stolen key and the captured token.
A new client connects to the rogue server, receives the token, verifies the hardware signature, confirms the hash matches the TLS public key and ultimately has no idea it's talking to the attacker.

SEV-SNP protected the key from the cloud operator. It did nothing to protect the key from the exploit running inside the VM. The attestation binding is technically intact - the token genuinely corresponds to the key - but the key is no longer exclusively held by the TEE.

This isn't hypothetical. TEE key extraction has been demonstrated through side-channel attacks, firmware vulnerabilities, and software exploits within the guest. The question isn't whether it can happen, it's what your security model looks like when it does.

Joshua Guttman, Paul Rowe and colleagues formalized this as a design principle: attestation should be independent of secrets that could be disclosed by transient corruptions. The TLS private key is exactly such a secret. If a runtime compromise can disclose it, and the attestation depends on it staying secret, then the attestation doesn't survive the exact kind of compromise it was supposed to protect against.

The Intra-Handshake Problem

Before explaining the fix, it's worth understanding a related issue that affects the entire RA-TLS ecosystem.

The original RA-TLS design - pioneered by Intel for SGX (Software Guard Extensions), adopted by Gramine, Occlum, and others - embeds attestation evidence directly in the TLS certificate as an X.509 extension. The attestation arrives during the handshake, before the connection is established. This seems cleaner: the client knows whether it's talking to a TEE before any application data flows.

But the Confidential Computing Consortium Attestation SIG's formal analysis proved this approach has a fundamental flaw. Using ProVerif, security researchers Sardar, Moustafa, and Aura demonstrated that all production intra-handshake implementations are vulnerable to relay attacks. A man-in-the-middle can relay the entire certificate - attestation evidence included - from the real TEE to a victim client, while maintaining a separate TLS session with the real TEE. The attestation evidence isn't cryptographically bound to the TLS session. It's just cargo inside the certificate.

The findings, published at ACM AsiaCCS 2026, have driven a shift in the IETF's standardization work toward post-handshake attestation. Our RA-TLS implementation delivers attestation after the TLS handshake at the application layer, which avoids the relay vector entirely. The client completes the handshake, retrieves and verifies the attestation separately, then pins the connection. There's a brief window between handshake and verification - the mitigation is simple: don't send sensitive data until verification completes.

But post-handshake attestation, on its own, still depends on the private key being non-extractable. Which brings us back to SVSM.

The SVSM Solution: Use Without Possession

The Coconut-SVSM (Secure VM Service Module) introduces a second layer of hardware isolation inside the Confidential VM.

AMD SEV-SNP defines multiple Virtual Machine Privilege Levels. VMPL0 is the most privileged, VMPL2 is where the guest kernel and proxy run. The boundaries between them are enforced by the CPU and not by software. Code at VMPL2 cannot read memory belonging to VMPL0 regardless of its privileges within the guest OS. A compromised kernel, a root shell, a malicious kernel module - none of them can cross this boundary.

The SVSM runs at VMPL0 and provides an emulated TPM that generates and stores cryptographic keys inside this isolated environment. When the proxy starts, it asks the SVSM's e-vTPM (emulated Virtual Trusted Platform Module) to generate the TLS key pair. The private key is created at VMPL0 and never leaves. What the proxy receives back is a handle - an opaque reference it can use to request signatures, but which contains no key material.

When a TLS handshake arrives, the proxy sends the data to be signed along with the handle. The signing happens at VMPL0. The signature comes back. The key never crosses the boundary.

This is the critical distinction: the proxy can use the key but cannot possess it.

Now replay the attack:

The same runtime exploit compromises the proxy.
The attacker reads all of the guest memory. They find a key handle - a useless integer - not key bytes.
They capture the attestation token.
They try to stand up a rogue server, but they can't complete TLS handshakes because they don't have the private key. The handle only works inside the original SVSM on the original hardware.
The attack fails.

The attestation binding survives the compromise. The hardware-signed token still points to a key that only the SVSM can use. The attacker can't forge signatures, can't impersonate the server, and can't reuse the captured token from a different machine.

The Trust Chain

With SVSM, trust flows in one direction - from AMD silicon at manufacturing, through the certificate chain, into the signed attestation report, into the TLS session:

AMD Root Key (ARK)           Self-signed. Published by AMD.
    │
    ▼
AMD SEV Key (ASK)            Signed by ARK.
    │
    ▼
VCEK                         Fused into the CPU during manufacturing.
    │                        Unique per chip. Cannot be simulated.
    ▼
SNP Report                   Signed by VCEK.
    │                        Contains measurements, privilege level, firmware version.
    ▼
eat_nonce in REPORT_DATA     Hash of the TLS public key.
    │                        Binds the hardware attestation to this server identity.
    ▼
TLS Private Key              Held at VMPL0 inside the SVSM e-vTPM.
    │                        Non-exportable. Usable only via handle.
    ▼
Pinned TLS Session           Client verified the full chain.
                              Bound to this hardware, this key, this session.

No third party at any step. No cloud provider attestation service. No certificate authority. Verification is certificate chain validation and a single signature check - pure mathematics, auditable offline.

A client can verify a TEE's identity on an air-gapped laptop with nothing but AMD's published root certificates.

Fail-Hard, Not Fail-Soft

One design decision worth calling out: when SVSM initialization fails and SVSM mode is enabled, the proxy does not silently fall back to in-memory keys. It exits.

A silent fallback would mean an operator who configured VMPL0 key isolation is actually running with keys in guest memory - the exact configuration they were trying to avoid - with no visible indication. Fail-hard means you discover the problem immediately, not when an auditor or an attacker finds the gap.

What This Doesn't Solve

SVSM key isolation is one layer in a defense-in-depth architecture. We want to be precise about the boundaries.

SVSM solves key exfiltration from runtime exploits, kernel compromises, dependency supply chain attacks, cold boot attacks, and memory forensics within the guest. It makes the TLS private key non-extractable by anything outside VMPL0.

SVSM doesn't prevent key misuse. A compromised proxy can still issue signing commands through the handle for as long as it controls the process. It can't steal the key, but it can abuse it. The defense against misuse comes from continuous attestation - behavioral monitoring detects anomalies, kernel integrity checks detect rootkits, and the system automatically revokes cryptographic access when any verification layer fails. A compromised proxy that behaves anomalously gets shut down within seconds, not days.

SVSM doesn't address token replay across time. The attestation token is generated once and cached. For clients that need per-session guarantees, session-bound attestation - which binds evidence to each individual TLS session's key exchange using TLS 1.3 Exporter values - provides a stronger tier. But for most deployments, identity-bound attestation with SVSM key isolation is the right tradeoff between security and performance.

Availability

SVSM e-vTPM key isolation is available in preview on Google Cloud Confidential VMs with AMD SEV-SNP. The RA-TLS implementation described here - including the proxy, client SDK, and kernel integrity monitor - is open source under Apache 2.0 as part of the Polaris confidential computing platform.

How RA-TLS Works

What Happens When It Doesn't

The Intra-Handshake Problem

The SVSM Solution: Use Without Possession

The Trust Chain

Fail-Hard, Not Fail-Soft

What This Doesn't Solve

Availability

Further Reading

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded