SECURITY / ATTESTATION

Who should receive the secret?

The chapters before kept the host and untrusted devices out of a confidential VM. But in this example the VM starts without the application's secret: someone outside must decide to give it that key. The VM asks the AMD Secure Processor for a signed report about itself, and a verifier decides. The report is evidence, not a decision; these experiments are about the decision.

What claims does this page make? 3 points

Spec rule: the report fields, keys and signing chain follow AMD's SNP firmware ABI 56860, which this page cites but does not reproduce.
Platform assumption: what a verifier accepts (policy, minimum TCB, which key signs) is each relying party's choice, not something the firmware decides.
Teaching model: the report is a set of named fields, its signature is an input and nothing is signed by an AMD key.

Experiments

Words used in the experiments

Report: A structure the AMD-SP firmware signs for a guest: what was launched (MEASUREMENT), its policy, the platform's security versions (TCB), and 64 bytes the guest chooses (REPORT_DATA).
Challenge: A fresh random value from the verifier, so an old report cannot be replayed.
Key pair: A private and public key the guest makes for this conversation. Binding the public key into the report means a secret encrypted to it reaches only the attested guest.
VMPL: The VMPL requested for this guest report. The firmware accepts a level numerically at least the caller's own, up to 3, so a VMPL0 caller can request a VMPL1 report: the field alone does not prove a VMPL1 caller. Which levels the verifier accepts is its own policy (see confidential VMs for VMPLs).
Associated data: A label AES-GCM authenticates but does not encrypt, such as a record's context.
VCEK, VLEK: The keys that sign reports: chip-specific and versioned (VCEK), or provisioned (VLEK). The report's SIGNING_KEY field says which.
ARK, ASK: AMD's root key and the intermediate key that certify a VCEK.
TCB, REPORTED_TCB: The trusted computing base's version numbers, one per component; REPORTED_TCB is the set the signing key was derived for.
AES-GCM, tag: Authenticated encryption: it hides a record and adds a tag that fails if a bit changes.

Choose an experiment (core: start here; deeper: more cases; reference: catalogue)

Experiment

The experiment, drawn from its own state

Worked example from the fixture, not run in this browser (S06, experiment att-05). The AES-GCM record is 12 + 16 + 16 = 44 bytes: nonce 101112131415161718191a1b, ciphertext c42f01ac0b4ab0e81fd457fecb2ae531, tag af2fc0197d7cd0975e51f216cd0edbe1. The associated data buffer-demo/v3 is authenticated, not encrypted, and outside the 44 bytes. The receiver opens it, the tag verifies and the plaintext 000102030405060708090a0b0c0d0e0f is released. Sent a second time, the same record verifies again: AES-GCM has no freshness. The transport is conceptual and the key is a public example key.Worked example from the fixture, not run in this browser (S08, experiment att-02). The verifier sent challenge N2; an attacker returns an old, correctly signed report bound to N1 and P1. The signature (assumed, not verified here), the VCEK path, launch measurement aa11, VMPL0, no debug and the TCB all pass. Then REPORT_DATA fails: the verifier expects 3bfa54ccfd02f9af… and the report holds 8c411edca7dd8160…. The result is no secret released. The exchange order is conceptual, not a trace of a real channel.

Intel and Arm:

What the verifier sees

The report

The verifier's policy

Its checks, in order

Outcome and records

The hashes, the AES-GCM record and the tamper checks are computed in your browser (WebCrypto). The report is a set of named fields, not AMD's binary layout, and its signature is an input: nothing here is signed by an AMD key. The AES key is a public example key.

What a report says, and what it does not

MEASUREMENT is taken at launch. A new report does not measure what the guest has run or received since.
REPORT_DATA is whatever the guest put there; the firmware signs it without interpreting it. Binding a challenge and a public key is the verifier's design, not the firmware's.
The guest's messages to the firmware have their own keys and sequence numbers; those do not make a report fresh for an outside verifier.
A valid report can still describe a guest you do not accept: debugging allowed, an old TCB, another image.

Keys are roles

Key	Its job	Not
VEK	Encrypts the guest's memory	Given to anyone, the guest included
VMPCK	Protects messages between the guest and the firmware	A memory or PCIe key
VCEK, VLEK	Sign the report	Anything that encrypts data
Derived (sealing) key	Chosen inputs, such as the measurement, give an application key	An exported VEK
SPDM and IDE session keys	Protect a device's messages and link (trusted I/O)	The guest's memory key

VMPCK is the VM Platform Communication Key (Linux's sev-guest documentation). VEK is "the VM encryption key used to encrypt the guest's memory" (56860 rev 1.58, Table 6).

Who signs it

For the usual path the verifier builds a chain from AMD's root key (ARK) through an intermediate (ASK) to the chip's VCEK, fetched from AMD's KDS, and checks the report's signature with the VCEK. A VLEK has its own provisioning path; a verifier must not treat every certificate as a VCEK. The TCB fields differ by processor generation.

Firmware interfaces change: pin the version you verified against.

Sources

AMD SEV Secure Nested Paging Firmware ABI Specification 56860, revisions 1.58 and 1.59 (publisher PDF): ATTESTATION_REPORT, guest policy, TCB_VERSION, key derivation.
AMD, Versioned Chip Endorsement Key certificate and KDS interface specification (VCEK, VLEK, KDS).
IETF RFC 5116, the interface for authenticated encryption (AEAD).
The author's own study notes on confidential computing, written from AMD's public documents (not published), examples E33 to E40 and W23, W24.