Verifying AMD SEV-SNP attestation in an air-gapped environment

To verify an AMD SEV-SNP attestation report, the APM must validate the report’s certificate chain up to the AMD root key and confirm that no certificate in the chain has been revoked. By default the APM obtains the material it needs for this from the AMD Key Distribution Service (KDS) at kdsintf.amd.com, which requires outbound network access at verification time. This page describes the steps to allow the APM to verify an attestation report in case access to the internet is not allowed.

There are three such dependencies on AMD KDS, supplied across two hosts:

  • the per-chip VCEK certificate and the ARK/ASK certificate chain it chains up to, provisioned on the bare-metal host (Provision host certificates); and

  • the Certificate Revocation List (CRL) for the host’s CPU product line, seeded into the APM (Seed the APM CRL cache).

The certificates are provisioned on the bare-metal host so that they travel with the attestation report as evidence: the Anjuna Confidential Container reads them at boot and passes them to the Anjuna Runtime, which sends them alongside the report, and the APM anchors the chain from that evidence instead of querying KDS. The CRL, by contrast, is held by the APM, because revocation is checked on the APM host at verification time.

Once both parts below are complete, the APM verifies reports with no outbound access to kdsintf.amd.com.

Provision host certificates

On the bare-metal host, provision the VCEK and ARK/ASK certificates ahead of time. The offline flow has three steps:

  1. Generate a certificate descriptor on the air-gapped host. The descriptor identifies the exact VCEK and ARK/ASK certificates the host needs.

  2. Fetch those certificates from AMD KDS on a connected host, using the descriptor.

  3. Copy the certificates back and install them on the air-gapped host.

For the exact commands, see Provisioning attestation certificates in the Anjuna Seaglass for AMD SEV-SNP on Bare Metal documentation.

Seed the APM CRL cache

The APM checks the report’s certificate chain against the AMD CRL for the host’s product line on every attestation, and fails attestation rather than proceeding without a current CRL. In local mode the APM serves only the CRLs you supply, instead of fetching them from KDS.

AMD publishes each product line’s CRL at this location:

https://kdsintf.amd.com/vcek/v1/<Product>/crl

Replace <Product> with the host CPU’s product line: Milan (3rd Gen EPYC), Genoa (4th Gen EPYC), or Turin (5th Gen EPYC).

On a connected host, download the CRL, Base64-encode it, and write it to the APM with the source set to local:

curl -sf https://kdsintf.amd.com/vcek/v1/Milan/crl -o milan.crl

vault write "auth/apm/config" \
  sevsnp-crl-source=local \
  sevsnp-crl="$(base64 -w0 milan.crl)"

To provide CRLs for several product lines in one call, repeat the sevsnp-crl field:

vault write "auth/apm/config" \
  sevsnp-crl-source=local \
  sevsnp-crl="$(base64 -w0 milan.crl)" \
  sevsnp-crl="$(base64 -w0 genoa.crl)"

The APM keeps a single CRL per product line, and writing a CRL replaces the one currently stored for that product line. Before storing a supplied CRL, the APM validates it and rejects it if any of the following are true:

  • It is not signed by the AMD Root Key for its product line.

  • It is older than the stored CRL (a lower CRL number).

  • It has already passed its nextUpdate time.

The APM does not refresh CRLs in local mode, so you must supply a newer CRL before the stored one expires. The default sevsnp-crl-max-age of 24h expires a stored CRL well before its nextUpdate time. For offline use, either set sevsnp-crl-max-age to 0 to rely solely on the nextUpdate time, or reload CRLs within the max-age you choose.

For the per-field reference and the emergency override that suspends revocation checking, see AMD SEV-SNP certificate revocation.

Verifying the result

With host certificates provisioned and a current CRL seeded, the APM has everything it needs to verify reports without contacting AMD KDS. If attestation fails on a revocation error after this setup, see SEV-SNP attestation fails on certificate revocation.