CLOUD INFRASTRUCTURE
What the guest can prove
Confidential computing on this generation of hardware rests on a specific claim: a workload can demonstrate to a remote party that it is running inside a memory-encrypted guest, on genuine hardware, with a boot measurement the relying party can check. Memory is encrypted with a key the host has no access to, and integrity protection closes the class of remapping attacks that earlier generations left open.
The proof mechanism is the attestation report. The guest asks the firmware for a report, optionally supplying its own data to be included, and receives a signed structure containing the launch measurement, policy bits, platform version information, and that supplied data. The signature chains to a certificate rooted in the processor vendor.
Verification is the relying party's job
The most common implementation error we see is a guest that fetches its own report, verifies it locally, and reports success to a control plane. This proves nothing. A compromised guest reports whatever it likes.
Verification has to happen on the party that needs the assurance. In our deployments that is the key management service, and the sequence is deliberately boring:
- The guest requests a resource, typically the key material that lets it decrypt customer data.
- The key service issues a random challenge and declines to proceed without it.
- The guest requests an attestation report with the challenge bound into the report data field.
- The key service verifies the signature chain, checks certificate revocation, compares the launch measurement against the expected value, checks the policy bits, and confirms the challenge matches the one it issued.
- Only then is key material released, and only to that session.
The freshness problem
Report data binding is what makes the report an assertion about now rather than an assertion about some past moment. Without it, a report captured from a legitimate boot can be replayed indefinitely. This is straightforward to implement and easy to omit, because a system without nonce binding works perfectly in every test that does not include an adversary.
The corollary is that attestation is not a one-time event at boot. Long-running guests re-attest on a schedule and on any event that changes their security-relevant state.
Measurement management is the hard part
The cryptography is well specified and, at this point, well implemented. What makes attestation genuinely difficult to operate is that the expected launch measurement changes whenever anything in the measured boot chain changes: firmware, kernel, initramfs, and the boot parameters themselves.
At fleet scale this means the set of acceptable measurements is not a constant. It is a versioned, signed artefact produced by the build pipeline, distributed to every verifier, and retired on a schedule as old images are drained. Get this wrong and one of two failure modes follows. Either the acceptable set is too narrow and a routine patch takes production offline, or it is too broad and the control degrades into a check that the machine is roughly the right shape.
We treat the measurement set as a first-class release artefact for exactly this reason. It is built with the image, signed with the image, and shipped ahead of the rollout so verifiers accept the new measurement before any host presents it.
Operational notes
- Certificate caching. Vendor certificate endpoints are a dependency on a critical path. Cache aggressively, refresh on a schedule, and fail closed with a clear signal rather than falling back to unverified acceptance.
- Revocation. Check it. A revoked platform certificate is precisely the case attestation exists to catch, and skipping the check is a common shortcut in early implementations.
- Policy bits. Verify them explicitly rather than assuming launch configuration. Debug-enabled guests should never satisfy a production policy.
- Failure telemetry. Attestation failures belong in the same pipeline as every other security signal. A rise in failures across a facility is an infrastructure event worth seeing early.
Where this sits in the boundary
Attestation is not a replacement for the rest of the control set. It answers one question well: is this workload running where and how it claims to be, on hardware that vouches for itself. Access control, key custody, monitoring, and physical security all remain load bearing.
What it adds is a foundation the other controls can rest on. Without it, the platform's isolation claims are assertions. With it, they are checkable, by the party that needs them checked, at the moment it matters.