How to perform AMD SEV-SNP attestation inside a guest virtual machine

Attestation is essentially the mechanism that a VPS server owner can use to verify any promises about a VPS server’s security, independent of the hosting provider, allowing you to ensure that AMD’s hardware-level memory protection and machine encapsulation are in fact set up correctly and working.

For this tutorial, we are going to use the ‘snpguest’ utility, a recognized tool for interacting with AMD SEV-SNP’s features from within the VPS. The process relies on validating cryptographic keys and certificates managed directly by AMD, ensuring a high degree of trust.

We will follow the official regular attestation workflow. This method involves fetching the necessary signing certificates directly from the official AMD Key Distribution Service (AMD KDS), providing a strong chain of trust originating from AMD itself. Crucially, the report we are going to generate is cryptographically signed by a unique key which is embedded in the processor, called the Versioned Chip Endorsement Key (VCEK). The VCEK's authenticity can be traced back to AMD's root keys via a certificate chain.

Performing AMD SEV-SNP attestation

In order to perform SEV-SNP attestation, we are going to have to follow these steps.

1. Install dependencies and build ‘snpguest’

Firstly, we are going to need to install of the dependencies as well as to build the actual snpguest utility. Here's how to get started for each server image.

Initial Setup

Before we get things started, we will need to run the correct setup commands for your operating system. Start by locating and running them for your server image.

Ubuntu:

sudo apt update

sudo apt install -y git gcc make linux-modules-extra-$(uname -r)

Debian:

sudo apt update

sudo apt install -y git gcc make

Fedora, AlmaLinux 9/10 and Rocky Linux 9/10:

sudo dnf upgrade

sudo dnf install gcc make g++ cmake perl perl-core perl-devel perl-IPC-Cmd openssl-devel pkg-config git

AlmaLinux 8 and Rocky Linux 8:

sudo dnf upgrade

sudo dnf install gcc make cmake perl perl-core perl-devel perl-IPC-Cmd openssl-devel pkg-config git

Installing Rust and Cargo

After you have done the initial setup for your server image, you will need to install Rust and Cargo:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Next, configure the current shell environment for Cargo using this command:

source "$HOME/.cargo/env"

After that, clone the snpguest repository:

git clone https://github.com/virtee/snpguest.git

It’s now time to navigate to the repository directory using the following command:

cd snpguest

Next, build the snpguest utility in release mode:

cargo build -r

Finally, navigate to the built executable using this command:

cd target/release

2. Generate the attestation report

Now that we’ve got everything set up, it’s time to ask the AMD Secure Processor, via the hypervisor, to generate an attestation report.

First, we need to ensure that the AMD SEV guest driver is loaded. This kernel module exposes the '/dev/sev-guest' device interface, which the 'snpguest' utility requires to communicate with the Secure Processor. You can proactively load it by running:

modprobe sev-guest

Next, generate the attestation report. We'll provide random data to be included in the report, ensuring its freshness:

./snpguest report report.bin request-file.txt --random

3. Fetch the AMD certificate chain (ARK & ASK) from KDS

In order to verify the report's signature, we need the public certificates that establish the chain of trust back to AMD. We are going to fetch the AMD Root Key (ARK) and AMD SEV Key (ASK) certificates directly from AMD's official Key Distribution Service (KDS). This will happen over the network.

./snpguest fetch ca -r report.bin pem ./

IMPORTANT: In the command above, '-r report.bin' is specifying the report file (that is generated in the previous step) to determine what processor model to use in order to fetch the appropriate certificates; 'pem' specifies the desired encoding for the certificates. The command './snpguest fetch ca pem ./ genoa|turin' could also be used, where you can explicitly specify the EPYC generation (either Genoa or Turin, which are used by powerful cloud VPS servers) without providing the report file.

4. Fetch the VCEK certificate from KDS

The attestation report that was previously generated during step 2 is signed by the VCEK, which is unique to the chip and its current TCB version. We will need to use information from the generated report (specifically the Chip ID and TCB version) to request the correct VCEK certificate from AMD KDS. This is once again done over the network.

./snpguest fetch vcek pem ./ ./report.bin

5. Verify the certificate chain

Before verifying the report itself, let's confirm that the certificates form a valid chain: the ARK should be self-signed (as it's the root), the ASK should also be signed by the ARK, and the VCEK should be signed by the ASK. We can verify this with the following command:

./snpguest verify certs ./

If everything is set up correctly, the expected output is:

The AMD ARK was self-signed!
The AMD ASK was signed by the AMD ARK!
The VCEK was signed by the AMD ASK!

6. Verify the attestation report

Finally, it’s time to verify the attestation report. To do this, we are going to be using the verified VCEK certificate to check the cryptographic signature on the report.bin file and compare the TCB version numbers embedded within the VCEK certificate to those recorded in the attestation report. They must match!

./snpguest verify attestation ./ ./report.bin

The expected output is:

Reported TCB Boot Loader from certificate matches the attestation report.
Reported TCB TEE from certificate matches the attestation report.
Reported TCB SNP from certificate matches the attestation report.
Reported TCB Microcode from certificate matches the attestation report.
VEK signed the Attestation Report!