Verifying an AMD SEV-SNP attestation report

What the report proves

Secure Compute servers run on AMD SEV-SNP, where the processor encrypts workload memory using keys the virtualization software never holds. The attestation report allows you to verify this protection.

The report is signed with a key anchored in the processor's own certificate chain, so a valid signature is evidence from the hardware itself rather than a statement from ServLogi. Even if our management systems were compromised, they could not forge a report.

Verification order

1. Validate the certificate chainConfirm that the report's signing key chains to the AMD root certificate. A report that does not chain to the vendor root cannot be trusted, regardless of its measurement.
2. Compare the launch measurementCompare the measurement with the published expected value for your hardware profile and firmware version. A mismatch means the server started with something other than what you expected.
3. Check the policy fieldConfirm that debugging and migration are both disabled. A correct measurement combined with a permissive policy does not provide the intended assurance.
4. Check the report nonceConfirm that the nonce matches the one you supplied. This ensures the report is current rather than a copy of an earlier one.

Independent verification

Our verification tool is provided for convenience and is not required. It is open source so that you can review exactly what it checks, and you may use 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

Perform verification on a machine you control, not on the server being verified. A system cannot reliably verify itself.

When measurements change

Firmware updates change the expected launch measurement. This is normal and does not by itself indicate a compromise.

Planned changes are announced at least 14 days in advance through the Client Portal and the status feed, and the new expected value is published before the change takes effect. We recommend incorporating these notifications into your operational processes.

An unannounced measurement change should be treated as a potential platform integrity event. Open a P1 incident with the Security Operations Center immediately.