vault

Attestation for Confidential VMs

18 min read

Attestation for Confidential VMs

A confidential VM keeps its memory encrypted against the host (see Confidential Computing and the Trust Boundary), but encryption alone proves nothing to anyone outside it. A relying party — your key-management server, your secrets store, your CI pipeline — still needs a way to answer: “Is the thing asking me for secrets really a genuine confidential VM, running on genuine AMD/Intel silicon, booted with exactly the code I expect, and not a host-operator impostor?” Attestation is the cryptographic mechanism that answers it. A hardware root of trust (the AMD Secure Processor or the Intel TDX module) measures the guest’s initial state at launch — producing a launch measurement — and on demand signs an attestation report (AMD SEV-SNP) or quote (Intel TDX) embedding that measurement plus a caller-supplied nonce. The relying party verifies the signature against the hardware vendor’s certificate chain (AMD’s Key Distribution Service, KDS; Intel’s Provisioning Certification Service, PCS) and checks the measurement against a known-good value — and only then releases secrets (sev-guest doc, v6.12; AWS SEV-SNP attestation).

The end-to-end pattern is measure → report → verify → release secret. This note walks each stage for both AMD and Intel, distinguishes launch measurement from runtime measurement, and covers the orchestration frameworks (Confidential Containers’ Trustee/attestation agent, Keylime-style verifiers) that automate it.

Mental Model: A Notarized Photograph of the Guest at Birth

Think of attestation as a tamper-proof, vendor-notarized photograph of the guest taken the instant it was created, which the guest can later show to a stranger to prove its identity. The hardware takes the photo (the launch measurement) before the guest runs a single instruction of its own; the photo is signed by a key that chains back to AMD or Intel; and the guest can fold in a fresh nonce so the photo can’t be a stale replay. A verifier who trusts AMD/Intel and knows what the guest should look like can authenticate the photo and the subject in one step.

flowchart LR
  subgraph CVM["Confidential VM (the attester)"]
    G["Guest software"]
    RT["Hardware root of trust<br/>AMD-SP/PSP or TDX module"]
    G -->|"1. request, with 64-byte<br/>REPORT_DATA = hash(nonce, pubkey)"| RT
  end
  RT -->|"2. signed report/quote:<br/>MEASUREMENT + REPORT_DATA + signature"| RP
  subgraph RP["Relying party (the verifier)"]
    V["Verifier"]
    POL["Reference values<br/>(expected measurement) + policy"]
    V --- POL
  end
  V -->|"3. fetch cert chain"| KDS["Vendor PKI:<br/>AMD KDS / Intel PCS"]
  KDS -->|"VCEK/VLEK or PCK cert<br/>+ ASK/ARK or Intel root"| V
  V -->|"4. signature OK +<br/>measurement matches + nonce fresh"| REL["5. release secret<br/>(disk key, token)"]
  REL -.->|"wrapped to guest"| G

Caption — what it shows: the five-step attestation flow. (1) The guest asks its hardware root of trust for a report, supplying a 64-byte REPORT_DATA field that binds a verifier nonce and often a public key. (2) The root of trust returns a hardware-signed report containing the launch MEASUREMENT and the REPORT_DATA. (3-4) The verifier fetches the vendor certificate chain, checks the signature, confirms the measurement equals an expected reference value, and confirms the nonce is fresh. (5) Only then does it release a secret, cryptographically bound to that guest. The insight to take: attestation turns “trust me, I’m encrypted” into “here is hardware-signed, vendor-rooted, replay-proof evidence of exactly what I am” — that is the gate every secret passes through.

Stage 1 — Measurement: What the Hardware Records at Launch

Before a confidential guest executes its own code, the hardware root of trust computes a cryptographic digest of the guest’s initial memory image and initial CPU state. This launch measurement is the anchor of identity: change one byte of the firmware, kernel, initramfs, or command line, and the measurement changes, so a verifier can detect any substitution by the (untrusted) host.

On AMD SEV-SNP, the AMD Secure Processor (AMD-SP, a.k.a. PSP — Platform Security Processor) builds the measurement incrementally as the VMM populates guest memory. During the launch sequence (KVM_SEV_LAUNCH_START → KVM_SEV_SNP_LAUNCH_UPDATE → KVM_SEV_LAUNCH_FINISH), each page is hashed in: the digest is extended page-by-page as LD := Hash(LD || Page || Page Metadata), covering the initial firmware/kernel/initrd/cmdline (Contrast AMD details). The AMD memory-encryption doc describes the measurement as “a signature of the memory contents that can be sent to the guest owner as an attestation that the memory was encrypted correctly,” verifiable because “the measurement can be verified by comparing it to what the guest owner expects” (AMD doc, v6.12). The result is the 48-byte (SHA-384) MEASUREMENT field of the attestation report. SEV-SNP also distinguishes page types during launch — KVM_SEV_SNP_PAGE_TYPE_NORMAL, _ZERO, _UNMEASURED, _SECRETS, _CPUID — so that, for example, the CPUID page is measured (the guest can trust its CPU-feature view) while scratch pages are _UNMEASURED (AMD doc, v6.12).

On Intel TDX, the TDX module “records the state of the TDX guest in various stages of the guest boot process using the build time measurement register (MRTD) and runtime measurement registers (RTMR)” (TDX doc, v6.12). The MRTD (Measurement Register for the Trust Domain) captures the build-time image — the initial firmware/configuration sealed when the TD is finalized. The four RTMRs (Runtime Measurement Registers 0–3) are extend-only registers for everything measured after the build seal — kernel image, command line, initrd, ACPI tables — giving a TPM-style “measured boot.” A TD extends an RTMR with TDCALL[TDG.MR.RTMR.EXTEND], supplying the register index and a 48-byte extension value at a 64-byte-aligned address (kernel.org TDX search). Together MRTD + RTMR0–3 form the measured identity embedded in the TDREPORT.

The conceptual split — MRTD = build-time, RTMR = runtime on Intel; launch MEASUREMENT = initial, plus separate runtime mechanisms on AMD — maps directly onto launch vs runtime measurement, discussed below.

Stage 2 — The Report: Producing Signed Evidence

A measurement sitting in a register is useless to a remote party until the hardware signs it into a portable, verifiable artifact and binds it to a fresh challenge.

AMD SEV-SNP: the attestation report

The guest asks for a report through the /dev/sev-guest device. The sev-guest doc defines the SNP_GET_REPORT ioctl, which “uses the SNP_GUEST_REQUEST (MSG_REPORT_REQ) command provided by the SEV-SNP firmware to query the attestation report”; it takes a struct snp_report_req and returns a struct snp_report_resp whose data field holds the report (sev-guest doc, v6.12). The request carries a 64-byte REPORT_DATA — caller-controlled bytes the firmware copies verbatim into the report without interpreting. This is where the verifier’s nonce goes (defeating replay), and typically also a hash of the guest’s TLS public key (binding the report to a live secure channel) (Contrast AMD details).

The returned ATTESTATION_REPORT (defined in AMD’s SEV-SNP firmware ABI) carries, among other fields:

  • MEASUREMENT (48 bytes, SHA-384) — the launch measurement from Stage 1.
  • REPORT_DATA (64 bytes) — the guest-supplied nonce/pubkey hash, echoed back.
  • HOST_DATA (32 bytes) — data the hypervisor supplied at launch (e.g. in Confidential Containers, a digest of the Kata policy) (Contrast AMD details).
  • ID_KEY_DIGEST / AUTHOR_KEY_DIGEST — digests of the identity/author keys that signed the guest’s optional ID block.
  • REPORT_ID, CHIP_ID — a per-launch identifier and a per-chip identifier.
  • CURRENT_TCB / LAUNCH_TCB — the Trusted Computing Base version numbers (firmware/microcode security-patch levels); LAUNCH_TCB is “the lowest TCB the guest ever executed with.”
  • PLATFORM_INFO — platform configuration bits (SMT enabled, TSME, etc.).
  • VMPL — the VM Privilege Level the report was generated at.
  • SIGNATURE — an ECDSA signature over the report body.

Uncertain

Verify: the exact byte offsets, sizes, and complete field set of the SEV-SNP ATTESTATION_REPORT. Reason: the canonical layout lives in AMD’s SEV Secure Nested Paging Firmware ABI Specification (publication 56860), which timed out on fetch during this research; the field names and the 48-byte/64-byte sizes here are corroborated from AMD’s “Establishing Trust in Guests” deck and verifier docs but not read off the primary ABI table directly. To resolve: pin against publication 56860, Table 10. uncertain

The report is signed by the VCEK — the Versioned Chip Endorsement Key — which is “derived from chip-unique secrets” plus the four TCB version components (security-patch levels for the SP bootloader, SP OS, SNP firmware, and microcode) (sev-guest doc, v6.12; Contrast AMD details). Because the key is bound to both the specific chip and the current TCB level, a report’s signature simultaneously proves “genuine AMD silicon” and “running firmware no older than version X.”

The communication path is itself hardened: “Communication between an SEV guest and the SEV firmware in the AMD Secure Processor (ASP, aka PSP) is protected by a VM Platform Communication Key (VMPCK)” tied to the guest’s VMPL, and the firmware enforces a monotonic message sequence counter — “the firmware checks that the message sequence counter is one greater than the guest’s message sequence counter,” returning -EIO on failure (sev-guest doc, v6.12). This stops a malicious host from replaying or reordering guest↔firmware messages.

Intel TDX: the TDREPORT → quote conversion

TDX is two-stage by design. First, the guest gets a local report via /dev/tdx_guest and the TDX_CMD_GET_REPORT0 ioctl, which “can be used by the attestation software to get the TDREPORT0 … from the TDX module” by invoking TDCALL[TDG.MR.REPORT]; on success “TDREPORT data is copied to tdx_report_req.tdreport” (tdx-guest doc, v6.12). The request includes a 64-byte REPORTDATA — again the verifier’s nonce (Intel DCAP overview).

But the TDREPORT is only locally verifiable — it carries a MAC (message authentication code) checkable only on the same platform, not a remotely-verifiable signature. So a second step converts it into a quote. The TDREPORT is handed to an Intel SGX Quoting Enclave (QE), which verifies the TDREPORT locally, then re-signs it with an attestation key to produce a TD quote — the artifact a remote party can verify (Intel DCAP overview). The attestation key is itself certified by the platform’s Provisioning Certification Key (PCK). The TDREPORT-to-quote hop typically travels over a host-side service (a GetQuote hypercall handled by the VMM/quote-generation service).

Uncertain

Verify: whether the 6.12 LTS /dev/tdx_guest driver exposes a kernel ioctl for the quote step (e.g. a TDX_CMD_GET_QUOTE) or whether quote generation is entirely a userspace/host-service concern at that version. Reason: the v6.12 tdx-guest.rst documents only TDX_CMD_GET_REPORT0; a GetQuote/TDX_CMD_GET_QUOTE path was added in kernel work whose exact landing version I did not pin to a git.kernel.org tag here. To resolve: check the 6.12/6.18 drivers/virt/coco/tdx-guest/ source and Documentation. uncertain

Stage 3 — Verification: Chaining to the Hardware Vendor

A signed report is only as good as the verifier’s ability to trace the signing key back to a root the verifier already trusts — the hardware vendor.

AMD SEV-SNP. The VCEK that signed the report is itself certified by AMD’s PKI: the AMD Root Key (ARK) is self-signed and is the trust anchor; the ARK signs the AMD SEV Key (ASK); the ASK signs the leaf VCEK (ARK → ASK → VCEK) (IETF AMD KDS wiki). Verifiers fetch these from the AMD Key Distribution Service (KDS) at https://kdsintf.amd.com, which exposes:

  • GET vcek/v1/{product}/cert_chain — returns the ASK and ARK (PEM, in that order) for a CPU product (e.g. Milan, Genoa).
  • GET vcek/v1/{product}/{hwID}?{tcb params} — returns the leaf VCEK for a specific chip hardware ID at specific TCB security-patch levels.
  • GET vcek/v1/{product}/crl — the certificate revocation list.

(IETF AMD KDS wiki). A worked verification (AMD’s snpguest tool, as documented by AWS) is concretely:

# Inside the SEV-SNP guest: build the verifier tool, request a report with a random nonce.
$ git clone https://github.com/virtee/snpguest.git && cd snpguest && cargo build -r
$ ./snpguest report report.bin request-file.txt --random     # report.bin = the signed ATTESTATION_REPORT
$ ./snpguest certificates PEM ./                             # pull endorsement certs from host memory
 
# Fetch AMD's root-of-trust chain (here for a VLEK-signed report on an AWS Milan host):
$ curl --proto '=https' --tlsv1.2 -sSf \
    https://kdsintf.amd.com/vlek/v1/Milan/cert_chain -o cert_chain.pem
$ openssl verify --CAfile cert_chain.pem vlek.pem            # prove the endorsement key is AMD-issued
  vlek.pem: OK
$ ./snpguest verify attestation ./ report.bin               # prove the report is signed by that key
  Reported TCB ... matches the attestation report.
  VEK signed the Attestation Report!

(AWS SEV-SNP attestation). Line-by-line: snpguest report produces the hardware-signed report binding the random nonce; certificates extracts the endorsement-key cert the host cached; the curl to KDS retrieves AMD’s ASK+ARK; openssl verify proves the endorsement key chains to AMD’s root; and snpguest verify attestation proves the report’s ECDSA signature was made by that key and the report’s TCB fields match the cert. After cryptographic verification, the relying party performs the policy check: does MEASUREMENT equal the expected reference value for this exact image? Are PLATFORM_INFO bits (e.g. SMT off) acceptable? Is the TCB version recent enough? Is REPORT_DATA the nonce I just issued? Only an all-yes releases secrets.

Note the VCEK vs VLEK distinction surfaced above. The sev-guest doc explains a guest “is able to specify whether it wants SNP firmware to sign the report using either a Versioned Chip Endorsement Key (VCEK), which is derived from chip-unique secrets, or a Versioned Loaded Endorsement Key (VLEK) which is obtained from an AMD Key Derivation Service (KDS)” (sev-guest doc, v6.12). VLEK exists so a cloud provider can have AMD issue an endorsement key to the provider (loaded via the host SNP_VLEK_LOAD ioctl) rather than exposing a per-chip VCEK — useful operationally and for privacy. AWS uses VLEK, which is why the example fetches from the /vlek/v1/... KDS path rather than /vcek/v1/... (AWS SEV-SNP attestation).

Intel TDX. The verifier needs the platform’s PCK certificate to validate the quote’s signature, obtained “from a Provisioning Certification Caching Service (PCCS) or directly from the Intel Provisioning Certification Service (PCS)” (Intel DCAP overview). Intel’s DCAP (Data Center Attestation Primitives) quote-verification library checks the quote signature against the PCK chain rooted in Intel’s CA, then the verifier compares the embedded MRTD/RTMR measurements against expected reference values. The structure mirrors AMD exactly — vendor-rooted PKI, signature check, measurement-vs-reference check, nonce-freshness check — only the names differ (PCS↔KDS, PCK↔VCEK, quote↔report).

Stage 4 — Secret Release: Why Attestation Exists

Verification is not the goal; conditional secret release is. The canonical use is unsealing a disk-encryption key: a confidential VM boots with an encrypted root disk and no key; it attests to a key-broker; the broker verifies the report and only then hands back the decryption key, wrapped to the attested guest. A host operator who spun up a different image, or ran it outside a genuine TEE, produces a wrong measurement (or no valid signature) and the broker refuses — so the operator can never decrypt the disk. The nonce in REPORT_DATA/REPORTDATA makes each exchange fresh; binding a TLS public key into REPORT_DATA ties the released secret to the specific live channel the attested guest controls, defeating relay attacks.

Frameworks: Automating the Flow

Hand-rolling attestation per workload does not scale, so frameworks standardize it.

Confidential Containers (CoCo) Trustee is the reference stack for Kubernetes-native confidential workloads. Its components split across two projects: the Trustee project provides the Key Broker Service (KBS), the Attestation Service (AS), and the Reference Value Provider Service (RVPS); the Guest Components project provides the in-guest Attestation Agent (AA) and Confidential Data Hub (CDH) (Red Hat Trustee blog; CoCo attestation docs). The flow: the guest’s Attestation Agent gathers the hardware evidence (the SEV-SNP report or TDX quote) and runs a request-challenge-attestation-response (RCAR) handshake against the KBS; the KBS forwards the evidence to the Attestation Service, which verifies the signature and matches measurements against reference values held by the RVPS; on success the KBS issues a token or releases the requested resource (a key, a config) to the guest, which the Confidential Data Hub consumes (trustee KBS README). The get_token and get_resource agent APIs “are pivotal in initiating the request-challenge-attestation-response (RCAR) handshake.”

Keylime is an older, TPM-and-now-TEE-oriented remote-attestation framework: a verifier continuously checks an agent’s quotes against a registrar’s known-good values and a policy, revoking trust if measurements drift. Its model — continuous verifier + policy + reference values — is the same shape as Trustee’s AS+RVPS, and Keylime has been extended toward confidential-VM evidence.

Uncertain

Verify: the current CoCo Trustee component names and the precise division between the Trustee and Guest-Components repositories as of mid-2026, and the current state of Keylime’s confidential-VM (SEV-SNP/TDX) verifier support. Reason: CoCo and Keylime are fast-moving CNCF-adjacent projects; component names (KBS/AS/RVPS/AA/CDH) and repo boundaries have shifted across releases and may have changed since the sources consulted. To resolve: check the current confidential-containers/trustee and keylime/keylime repositories. uncertain

Launch Measurement vs Runtime Measurement

The distinction matters and is easy to conflate.

  • Launch (initial) measurement captures the guest’s state at creation, before it runs its own code — SEV-SNP’s MEASUREMENT field, TDX’s MRTD. It is immutable for the guest’s lifetime and answers “was I born from the right image?” This is what most secret-release policies key on.
  • Runtime measurement captures things measured during/after boot — TDX’s RTMR0–3, extended via TDG.MR.RTMR.EXTEND as the bootloader/kernel/initrd load, enabling a measured boot chain (analogous to TPM PCRs). SEV-SNP’s analog is the guest extending its own measured state into a virtual TPM or via the SVSM (Secure VM Service Module). Runtime measurement answers “did the boot chain after launch load the expected components?”

A robust policy checks both: the launch measurement pins the trusted base, and runtime measurements pin everything layered on top, so neither a swapped firmware nor a swapped kernel slips through.

Failure Modes and Common Misunderstandings

  • Forgetting the nonce ⇒ replay. A report without a fresh, verifier-chosen nonce in REPORT_DATA/REPORTDATA can be captured and replayed by a malicious host to impersonate a confidential VM. The nonce (and freshness check) is not optional.
  • Verifying the signature but not the measurement. “VEK signed the report” only proves genuine hardware. You must also compare MEASUREMENT/MRTD to a known-good reference value, or a malicious operator runs an attacker image on real silicon and still passes. Both checks are mandatory.
  • Stale or missing certificates / KDS rate limits. The AMD KDS rate-limits requests; verifiers that fetch VCEK certs per-attestation without caching get throttled. Production verifiers cache the cert chain (or use a PCCS for Intel).
  • TDREPORT mistaken for a quote. The TDREPORT is only locally verifiable (MAC, not a remote signature). Sending a bare TDREPORT to a remote verifier fails; it must be converted to a quote by the Quoting Enclave first.
  • TCB rollback. A report endorsed by a VCEK at an old TCB level may be from downgraded, vulnerable firmware. Policies should require a minimum TCB version (CURRENT_TCB/LAUNCH_TCB), which is exactly why the endorsement key is versioned (the “V” in VCEK/VLEK).
  • Trusting HOST_DATA as guest-attested. HOST_DATA is supplied by the hypervisor at launch, not measured from guest memory; treat it as an untrusted hint unless your policy specifically accounts for who set it.

Alternatives and When to Choose Them

  • SEV-SNP attestation report vs TDX quote. Same job, different PKI and format. SEV-SNP gives a single hardware-signed report (VCEK/VLEK, KDS); TDX needs the two-step TDREPORT→quote via a Quoting Enclave (PCK, PCS/DCAP). Choose by hardware. See AMD SEV and SEV-SNP and Intel TDX (Trust Domain Extensions).
  • TPM-based attestation. A discrete or firmware TPM attests a physical host’s boot (PCRs, AIK), but the TPM is on the host you don’t trust — it cannot attest a guest against its host. Confidential-VM attestation is rooted in the CPU/firmware specifically to exclude the host. Use TPM attestation for host integrity, CVM attestation for guest-from-host trust; they compose (e.g. vTPMs measured into the launch).
  • Software-only “attestation” (signed images, admission webhooks). Cheaper but trust the host/orchestrator — useless against a malicious operator, which is the whole point of confidential computing. Only hardware attestation removes the operator from the trust base.
  • Roll-your-own vs Trustee/Keylime. For one workload, the snpguest/DCAP CLI flow suffices. For a fleet, use a framework (Trustee, Keylime) for reference-value management, revocation, policy, and key brokering — the parts that are tedious and security-critical to get right.

Production Notes

All three major clouds expose confidential-VM attestation: AWS documents the snpguest + KDS flow verbatim (AWS), and AWS, Azure, and Google issue VLEK-signed reports so per-chip VCEKs are not exposed to tenants. Azure and Google additionally layer a vTPM and a managed attestation service (e.g. Microsoft Azure Attestation, Google’s Confidential Space) that wraps the raw report/quote behind a token-issuance API — the same measure→report→verify→release pattern, productized. The most common production pitfalls, per the CoCo and cloud guidance, are (1) caching failures against the vendor PKI causing throttling, and (2) reference-value drift — when a routine guest-image update changes the launch measurement and every attestation suddenly fails until the RVPS is updated. The operational discipline is to treat reference values as a versioned, deployed artifact that moves in lockstep with guest images.

See Also

Graph View

Backlinks