Attestation Azure, GCP and AWS really implement
We examine AMD's attestation report specification and assess how closely Azure, GCP, and AWS adhere to it.
The following article addresses AMD SEV-SNP remote attestation.
Source: SEV SNP Firmware ABI Specification (Revision: 1.57, January 2025)
AMD's attestation report
Following the AMD ABI spec, below table summarizes the remote attestation properties.
VERSION
The version number of the attestation report. It is used to identify major changes in the report structure.
GUEST_SVN
The guest Secure Version Number (SVN) which indicates the version of the guest being deployed.
POLICY
Policy which needs to be fulfilled by the platform.
FAMILY_ID
The family ID provided at launch.
IMAGE_ID
The image ID provided at launch.
VMPL
Indicates from which privilege level the guest called the attestation report or if the host requested the report.
SIGNATURE_ALGO
Signature algorithm used to sign the report.
CURRENT_TCB
Contains the data for the current running TCB.
PLATFORM_INFO
Information regarding the current configuration of the platform.
SIGNING_KEY
Indicates which kind of key was used to sign this report.
MASK_CHIP_KEY
Indicates that the VCEK is not used in attestation and guest key derivation.
AUTHOR_KEY_EN
Indicates that an Author Key was used to sign the ID key and that the digest of the Author Key is included,
REPORT_DATA
Can be filled with random data by the requesting guest in order to ensure freshness or communicate other properties.
MEASUREMENT
Measurement calculated over the initial guest state (firmware, bootloader, memory pages).
HOST_DATA
Data supplied by the hypervisor which is mixed into the report.
ID_KEY_DIGEST
SHA-384 digest of the public key which signed the ID block (policy, family/image id, ...).
AUTHOR_KEY_DIGEST
SHA-384 digest of the author key which certified the ID key.
REPORT_ID
An ID generated for each guest which is persistent through its lifetime and associated with every report generated during the lifetime.
REPORT_ID_MA
An ID for the migration agent of a guest. This ID persists through the entire lifetime of the guest.
REPORTED_TCB
The TCB version which was used to derive the VCEK which signed the report.
CPUID_FAM_ID
The general family of the underlying CPU.
CPUID_MOD_ID
The specific model of the CPU.
CPUID_STEP
The stepping ID of the CPU.
CHIP_ID
Unique chip identifier which can be hidden.
COMMITTED_TCB
Minimum TCB which can not be rollbacked to a previous due to hardware one time fuses.
CURRENT_BUILD
Build number of CurrentVersion of the firmware.
CURRENT_MINOR
Minor version of CurrentVersion of the firmware.
CURRENT_MAJOR
Major version of CurrentVersion of the firmware.
COMMITTED_BUILD
Build number of CommittedVersion of the firmware.
COMMITTED_MINOR
Minor version of CommittedVersion of the firmware.
COMMITTED_MAJOR
Major version of CommittedVersion of the firmware.
LAUNCH_TCB
TCB value at guest launch or import.
SIGNATURE
Signature of the report.
Explanation
The SEV-SNP attestation report starts with the Version field which indicates the specification the report is following. This is important as some following fields may interpret the same bytes differently depending on the report version. An example for this would be a report with version 2 and a report with version 3. Between these two report versions the structure of the PLATFORM_INFO section changed. One byte which was marked reserved for version 2 has been populated for report version 3 and indicates if the processor contains a mitigation for CVE-2024-21944.
As of 2025-05-20 GCP is the only provider to use the non public report version 4 and firmware version 1.55.31 on Milan CPUs.
The guest Security Version Number afterwards is indicating which version of the guest image is running. This field can be supplied by the user or hypervisor as part of the ID Block during the launch of the VM.
The Guest Policy field is also supplied through the user/hypervisor as part of the ID Block and contains information about features/versions that should be enabled/installed. The hardware is checking these values against the actual platform and will abort the boot process if a mismatch occurs.
Also as a part of the ID Block the hypervisor/user can provision a Family ID/Image ID in order to uniquely identify a VM or identify classes of VM's. This feature is currently only in use by Azure.
Overall the ID Block is following this structure:
LD
The expected launch digest/measurement of the guest. Will be checked by the firmware upon launch.
FAMILY_ID
Family ID provided by the guest owner.
IMAGE_ID
Image ID provided by the guest owner.
VERSION
Version of ID block format.
GUEST_SVN
Security Version Number of the guest.
POLICY
Guest launch policy.
The VMPL field always indicates from which Virtual Machine Privilege Level the attestation report was requested and if this was a guest or host request. Due to their vTPM Azure the report must be requested from VMPL 0. Other providers can use VMPL 1.
Through the signature field the algorithm, of which currently only one exists (ECDSA P-384 with SHA-384), for the signature of the report can be selected.
The CURRENT_TCB structure includes version information about the microcode, SNP firmware and other critical components and reports these at the time the of report creation. This may differ for each provider depending on their patch level and installed software. For example Azure and GCP reported the microcode version 219 while AWS reported 220 as they had a newer microcode version installed.
The Platform Info reports relevant enabled/disabled platform configurations. It is worth to note that AWS as the only cloud provider is using Transparent Secure Memory Encryption (TSME) which encrypts the complete memory irrespective from what an Operating System or hypervisor may indicate for a specific page with the C-bit. This requires no support in the hypervisor or Operating System for AMD SME.
The SIGNING_KEY field provides data about the key which is used to sign the attestation report. Most importantly it indicates if VLEK (AWS) or VCEK (Azure, GCP) signing was used. VCEK signing uses a unique secret embedded in the hardware chip while VLEK signing uses a seed for each certificate maintained by AMD.
MASK_CHIP_KEY indicates, when set, that the VCEK is not used in the attestation procedure and guest key derivation.
AUTHOR_KEY_ENABLED indicates that the digest of an author key is present this remains unused by all CSPs.
Report Data allows for providing random data to the SNP firmware during the creation of a report in order to guarantee its freshness. While AWS and GCP allow the user to pass its own random data on Azure the data is generated by the host through the vTPM which only uses half of the available space for randomness.
The measurement itself contains the hash calculated at launch of the VM and is the basis for trust as it needs to match the expected value by the user.
Host Data remains unused by the Cloud providers but would allow the hypervisor to supply additional data at the launch.
As Azure is using the Family ID and Image ID and in turn provides an ID Block it also used the ID Key Digest field which contains the hash of the public key that was used to sign the ID Block. As AWS and GCP do not utilize the ID Block this field remains empty for reports generated on their infrastructure.
As the ID Key can be certified the Author Key Digest can contain the hash of the public key of the certifier. However this remains unused by all providers.
Through the Report ID and Report ID MA fields the hardware can assign a unique ID for the lifetime of a guest. This unique ID will be linked to all reports generated by this guest or this guests Migration Agent. As the no CSP is using the Migration Agent it is currently filled with 0xFF completely by the firmware.
The Reported TCB holds the information which was used to derive the VCEK and should match with the Current TCB.
Through the three fields CPUID_FAM_ID, CPUID_MOD_ID and CPUID_STEP it is possible to identify the underlying CPU. The CPUID_FAM_ID is in the case of our three CSPs 25 which indicates that the CPU belongs to the Zen 3 or Zen 4 microarchitecture. Through CPUID_MOD_ID this can be further broken down to the CPU generation called Milan. The CPUID_STEP finally allows to differentiate between different iterations such as Engineering Samples within one generation of CPUs. In our case the CPUID_STEP is always 1 which indicates the production release of Milan CPUs.
An interesting field is the Chip ID as this field allows to uniquely identify a given AMD CPU. Azure and GCP both provide these values while AWS choose to enable a platform configuration setting which masks the ID by setting it to all zeroes.
The COMMITED_TCB field contains the information of the TCB which has been burned physically into the hardware using One Time Programmable fuses. This prevents the hypervisor or anyone else to rollback the TCB to values lower than those committed.
The CURRENT_BUILD, CURRENT_MINOR and CURRENT_MAJOR field indicate the version of the SEV firmware which is not to be confused with the SVN of the firmware. These values also exists in a committed variant which prevents the rollback to previous versions.
Finally the signature field contains the necessary information about the signature over the attestation report. Together with the VCEK or VLEK, that can be requested from AMD's Key Distribution Center together with a certificate chain, the authenticity of the attestation report can be verified for all three cloud providers.
Last updated
Was this helpful?