Security / Remote attestation
Attestation evidence
Every trust decision in Privatemode rests on hardware-signed attestation evidence. This page describes what evidence is generated, its format, and which fields the Privatemode proxy verifies. For how this evidence is verified against the reference values, see The manifest. For the underlying mechanism, see the Contrast attestation documentation.
Privatemode runs on AMD SEV-SNP and Intel TDX-capable CPUs, with confidential-computing-enabled NVIDIA GPUs. Each hardware type produces evidence in its own format.
CPU evidence
A confidential VM requests a signed attestation report from the CPU. The signing key derives from a chip-unique secret fused during manufacturing and chains to the CPU vendor's PKI.
Two fields are common to both formats:
- The launch measurement is a digest over the firmware, kernel, initramfs, and kernel command line (including the dm-verity root hash). It proves which software booted inside the CVM.
- The runtime-policy hash is written into the report by the hypervisor at launch and is immutable afterward. It proves which containers run in the VM. See Runtime policies.
These measured values are captured when the CVM boots and stay fixed for its lifetime. The report itself is generated on demand and signed fresh each time it's requested, carrying those fixed measurements. A third field, REPORT_DATA, is what makes each report current: it binds the report to a single attestation session.
AMD SEV-SNP report
The SEV-SNP report is a fixed binary structure signed by the chip's Versioned Chip Endorsement Key (VCEK). The most important fields Privatemode relies on:
| Field | Content | Verified against |
|---|---|---|
MEASUREMENT | Launch digest over firmware, kernel, initramfs, and kernel command line | The manifest's trusted measurement |
HOST_DATA | SHA-256 of the runtime-policy document, set at launch | A policy hash in the manifest |
REPORT_DATA | Caller-chosen 64 bytes. In a handshake, a hash of the attestation session's public key and a nonce | Binds the report to one attestation session |
CHIP_ID | Unique identifier of the physical CPU | The manifest's allow-list of vetted chip IDs (AllowedChipIDs) |
SIGNATURE | ECDSA signature by the chip's VCEK | Chains to AMD's SEV CA and Root CA, with revocation checks |
| TCB versions, microcode | Firmware and microcode security-version numbers | The manifest's minimum-version requirements (MinimumTCB) |
PLATFORM_INFO, guest POLICY | Platform configuration and VM policy bits | Required platform state |
| Mitigation vector | Active CPU-vulnerability mitigation | The manifest's MinimumMitigationVector |
The chip ID pins the report to one physical CPU. See Allowed machines.
Intel TDX quote
The TDX equivalent is a quote signed by Intel's Quoting Enclave. It carries the same information in TDX-specific fields:
| Field | Content | Verified against |
|---|---|---|
MRTD | Measurement of the initial TD firmware | Reference firmware measurement |
MRSEAM | Measurement of the Intel TDX module | Reference TDX-module measurement |
RTMR[0..3] | Runtime measurements of kernel, initramfs, and command line (including the dm-verity root hash) | Reference values |
MRCONFIGID | Runtime-policy hash (same role as HOST_DATA on SNP) | A policy hash in the manifest |
REPORTDATA | Caller-chosen 64 bytes. The same session binding as REPORT_DATA on SNP | Binds the report to one attestation session |
XFAM, TD_ATTRIBUTES | Feature and attribute flags | The manifest's Xfam and platform flags |
| Platform Instance ID (PIID) | physical-machine identity, read from the quote's PCK certificate | The manifest's allow-list of vetted machines (AllowedPIIDs), the TDX analogue of CHIP_ID on SNP |
| TCB | Platform TCB security version | The manifest's MinTCBEvaluationDataNumber |
| Quote signature | Signature over the quote | Chains through the PCK certificate to Intel's SGX Provisioning Certification Root CA, with revocation checks |
The PIID plays the same role for TDX machines as the chip ID does for SEV-SNP. See Allowed machines.
GPU evidence
Contrast verifies CPU attestation evidence. Privatemode extends the chain to the GPU with the attestation-agent, whose own image and arguments are pinned by the runtime policy, so the GPU-verification logic is itself covered by CPU attestation.
Format. The GPU evidence is an SPDM GET_MEASUREMENTS request/response pair (DMTF DSP0274), obtained through NVIDIA's confidential-computing attestation-report interface and produced against a fresh nonce generated per GPU. It's signed by the GPU's device identity key, whose certificate chain leads to NVIDIA's device PKI. The report's opaque data includes the driver version, VBIOS version, project/SKU/chip-SKU identifiers, and board and firmware IDs.
Verification happens locally inside the worker CVM. The agent checks the ECDSA signature over the SPDM exchange, matches the nonce to the one it issued, and checks the driver and VBIOS versions against the allow-lists passed to it as arguments (and therefore pinned by the runtime policy). It then compares the measurement records against golden values from NVIDIA's signed Reference Integrity Manifests (RIMs) for the driver and VBIOS.
Revocation. Three certificate chains are checked against NVIDIA's OCSP responder (the GPU device identity, the driver-RIM signer, and the VBIOS-RIM signer), and each result is recorded per worker. The proxy's per-request policy then decides which states (good, unknown, revoked) are acceptable. See Certificate revocation.
Activation gate. GPUs stay unusable to the inference engine until the attestation-agent sets the confidential-computing ready state (via NVML) after successful verification.
Binding evidence to an attestation session
Each report is bound to the request that asked for it through the report data field, which always carries a fresh nonce from the verifier. When a worker registers with the Coordinator over an attested-TLS handshake, the field hashes the worker's session public key together with that nonce. When the proxy verifies the Coordinator, it instead hashes the nonce with the manifest history and the Root CA and Mesh CA fingerprints. Either way, because the report is hardware-signed over a fresh nonce, an attacker who captures a valid report can neither replay it into a new attestation session nor relay it through a different connection. The binding would no longer match.
Steady-state connections, such as the proxy's key exchange with the secret service, don't carry a fresh report. They authenticate with mesh certificates that were themselves issued after such an attestation (see Attestation flow in Privatemode).
Cryptographic details
The algorithms behind the steps above:
| Step | Algorithm |
|---|---|
| SEV-SNP report signature | ECDSA on NIST P-384 with SHA-384, by the chip's VCEK. The VCEK certificate chains through AMD's ASK to the ARK (both RSA-4096) |
| TDX quote signature | ECDSA on NIST P-256 by the Quoting Enclave's attestation key, certified through the PCK certificate to Intel's SGX Provisioning Certification Root CA |
| GPU report signature | ECDSA by the GPU's device identity key, chaining to NVIDIA's device PKI |
| Attested-TLS binding | TLS 1.3. The report's REPORT_DATA is SHA-512(session_public_key ‖ nonce). Mesh (workload) certificates use ECDSA on NIST P-256 |
| Coordinator-verification binding | The report's REPORT_DATA is SHA-256(nonce ‖ SHA-256(manifest_transition) ‖ SHA-256(Root_CA) ‖ SHA-256(Mesh_CA)) |
| Nonce | 32 bytes from a cryptographic RNG, generated fresh for every attestation (CPU and GPU) |