Verifying an AMD SEV-SNP attestation report

What the report proves

A Sovereign Enclave runs on AMD SEV-SNP, where workload memory is encrypted by the processor using keys the hypervisor never holds. The attestation report is how that guarantee becomes checkable.

The report is signed by a key rooted in the processor's own certificate chain, which means a valid signature is evidence from the hardware rather than an assertion from us. If our control plane were compromised, it still could not forge a report.

Verification order

1. Validate the certificate chainCheck the report's signing key chains to the AMD root. A report that does not chain to the vendor root proves nothing, regardless of what the measurement says.
2. Compare the launch measurementCheck the measurement against the published expected value for your hardware profile and firmware version. A mismatch means the host booted something other than what you expected.
3. Check the policy fieldConfirm debug is disabled and migration is disabled. A correct measurement with a permissive policy is not the guarantee you want.
4. Check the report nonceConfirm the nonce matches the one you supplied. Without this you cannot distinguish a fresh report from a replayed one.

Doing it yourself

Our verification tool is a convenience, not a dependency. It is open source specifically so you can read what it checks, and you are free to verify with your own implementation instead.

NONCE=$(openssl rand -hex 32)

curl -sS \
  -H "Authorization: Bearer $SERVLOGI_TOKEN" \
  "https://api.servlogi.com/v1/hosts/$HOST_ID/attestation?nonce=$NONCE" \
  > report.json

servlogi-verify report.json \
  --profile enclave-gen4 \
  --nonce "$NONCE" \
  --require-policy no-debug,no-migrate

Verify on a machine you control, not on the host being attested. Verification performed by the thing under test is not verification.

When measurements change

Firmware updates change the expected launch measurement. This is normal and is not a compromise indicator on its own.

Planned changes are announced at least 14 days ahead through the Client Portal and the status feed, with the new expected value published before the change lands. Build that notification into your process so a scheduled update does not page someone at two in the morning.

An unannounced measurement change is a different matter. Treat it as a potential platform integrity event and open a P1 with the Security Operations Center.