In this tutorial, we will focus on creating identities and policies. Identities consist of multiple parts:
Platform
The root of trust of the attestation, mainly the certificate chain used to verify the attestation. These are provided by the vendor of the attestation technology.
Firmware
The verification attributes of the OVMF/UEFI firmware that was used to boot the confidential VM. You need to measure this value based on the binary or extract it from the report.
Workload
CSP specific attestation attributes. We will leave them out for this tutorial and focus on the shared properties of all providers.
Metadata
Additional information that is attached to an attestation. Not used for verification and also left out for this tutorial.
Identities are then used in a policy and associated with a provider. Providers are constants that define how the attestation is generated and what attributes are included. Currently supported providers:
azure-sev-snp-vtpm
aws-sev-snp-raw
gcp-sev-snp-raw
Providers are specific to the used CSP, attestation technology and attestation flow.
To extract the values for a provider, this command can be used:
This will print the report, so additional fields for workloads can be extracted and for providers with vTPM based attestation the report can be processed further to extract the firmware measurement.
When using the vhsm nitride init command, basic identities for all supported CSPs will already be created, besides mounting the attestation plugin at ratls. This includes the platform identities for AMD SEV-SNP Milan/Genoa for VCEK/VLEK based attestations and firmware identities for Azure, AWS and GCP for the smallest available VM size at the time of writing.
Predefined Platform identities:
amd-sev-snp-milan-vcek
amd-sev-snp-milan-vlek
amd-sev-snp-genoa-vcek
amd-sev-snp-genoa-vlek
These are downloaded from https://kdsintf.amd.com/vcek/v1/{product}/cert_chain and the vlek counterpart. The certificate chains are valid for all chips or all cloud providers respectively. Currently, only AWS uses the VLEK based attestation. The attestation for AWS includes the VLEK in the request to verify the attestation. VCEKs for other providers are fetched automatically.
Platform firmware versions as of AMD-SB-3015:
Milan, >= 1.55.22
Genoa, >= 1.55.38
Predefined Firmware identities:
azure-dc2asv5
gcp-small
aws-c6a.large
These follow the format {provider}-{size}, as the measurement can be different for the same firmware if the vCPU count is changed, depending on the hypervisor.
Creating or updating identities
Identities are versioned by the creation timestamp. For verification, the newest available identity for a given name is used. So if an identity becomes outdated, you can easily update it without having to change the policy or the attestation itself.
Key Value
--- -----
created 1734560058
name test
type firmware
values map[measurement:eb5c02d3ba319e65218994fc47925cf8a5e9a433081c44d4d989434f15a7c6d715d302401b3147da04e49abc99e50aea]
Key Value
--- -----
created 1734560736
identities map[firmware:map[name:aws-c6a.large policy:<nil>] metadata:<nil> platform:map[name:amd-sev-snp-milan-vlek policy:<nil>] provider:aws-sev-snp-raw workload:<nil>]
name test
As seen in the example, this contains at least the name of the identity. Additionally, the field policy can configure which parts of the identity are actually used for the verification.
Verification of fields is enabled by default. Nested fields, like seen here with a specific PCR value, can be disabled using a path notation similar to jq.
Locally testing identities and policies
When attesting against the plugin in vHSM, the policy will be filled with the values from the named identities. To test these values locally, this command can be used:
The contents of policy.json match the values of each identity in identities of the policy stored in the plugin. This example only verifies the platform of a SEV-SNP Milan VCEK attestation: