TEE

SEV Technical Overview

SEV (Secure Encrypted Virtualization) is a confidential computing model within AMD architecture. It aims to enhance isolation through cryptography by encrypting code and data, thereby protecting code from attacks by higher-privileged code.

Non-confidential computing systems operate on a ring-based model, where high-privileged code has full access to resources at its level and all lower privilege levels.Under the SEV model, a hypervisor can manage and execute multiple virtual machines (VMs) simultaneously. When enabled, SEV hardware tags all code and data with a VM ASID, indicating which VM the data originates from or is intended for. This tag, stored alongside the data within the SoC, prevents the data from being accessed by anyone other than its owner. Inside the SoC, tags protect VM data, while outside the SoC, AES with 128-bit encryption safeguards the data. When data exits or enters the SoC, it is encrypted or decrypted based on keys associated with the tags. An example communication setup is shown in the diagram. In this example, SEV-enabled guests and the hypervisor communicate through shared memory, with both entities marked as shared. All other guest memory is encrypted using guest keys (inaccessible to the hypervisor).

Each VM and the hypervisor is associated with a unique tag, generating a corresponding encryption key. Because of tagging and memory encryption, data access is restricted to the VM that owns the tag. If data is accessed by anyone else, including the hypervisor, they will only see its encrypted form. This establishes robust encryption-based isolation between VMs and the hypervisor.

Therefore, SEV technology is built on a threat model that assumes attackers may execute user-level privileged code on the target machine and potentially run malware at the higher-privileged hypervisor level. Attackers may also have physical access to the machine, including direct access to DRAM chips. In all these scenarios, SEV provides added assurance to help protect the VM's code and data from being compromised by attackers.

ZEROBASE SEV Sandbox

By utilizing hardware VM constructs, ZEROBASE prover nodes are built around the concept of a secure sandbox environment, where circuit programs can execute and remain isolated from other circuit programs on the system. These sandboxes enable encrypted isolation between Docker containers, housing different circuit programs, and the host system, thereby enhancing the security of the process from user input to proof generation and the release of user input.

ZEROBASE prover nodes implement private memory encryption at the container level, while shared memory on the host is encrypted using the hypervisor key. This feature allows VMs to designate selected pages for confidentiality-protected memory data, with other pages available for communication with the hypervisor. For security purposes, instruction pages and page table memory within ZEROBASE prover nodes are always private, ensuring protection for the virtual machine.

Key Management

The security of SEV relies heavily on the protection of memory encryption keys, which remain inaccessible to the hypervisor. The SEV firmware, running inside the AMD-SP, provides a secure key management interface to achieve this. The hypervisor uses this interface to enable SEV for prover nodes and to carry out typical hypervisor activities such as launching, running, snapshotting, migrating, and debugging clients. This interface also facilitates the migration of client data to another prover node. During this process, the memory content of the prover node remains encrypted during transmission. Once the remote platform is authenticated, the SEV firmware securely sends the memory encryption key for the prover node, allowing the remote platform to operate the client independently. This transmission mechanism enables ZEROBASE prover nodes to securely perform migration and replication with SEV enabled.

DOS Defense

SEV alone cannot defend against denial-of-service (DOS) attacks targeting circuit programs. The DOS defense mechanism involves issuing a single-use communication key to the user for each request initiated by the HUB.

Guide to Obtaining and Verifying SEV-SNP Attestation Reports

Prerequisites

Before you start, make sure the following dependencies are installed:

• git version control tool

• cargo Rust package manager

• A C compiler

• openssl cryptography library

Obtaining the Attestation Report

1. Install the snpguest Tool

snpguest is a tool for interacting with SEV-SNP trusted environments. Install it by following these steps:

shellCopyEditgit clone https://github.com/virtee/snpguest.git
cd snpguest
cargo build -r
cd target/release

1. Send a Request to Generate an Attestation Report

Run the following command to request the SEV-SNP attestation report from the host and save it locally:

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

Parameter descriptions:

• report: Requests the attestation report from the host.

• report.bin: Path where the attestation report is saved.

• request-file.txt: Request file parameter.

• --random: Generates 64 bytes of random data used in the request.

1. Request Certificates from Host Memory and Store as a PEM File

shellCopyEdit./snpguest certificates PEM ./

Verifying the Attestation Report

1. Download AMD's VLEK Root Trust Certificate

Download and save it as cert_chain.pem:

shellCopyEditsudo curl --proto '=https' --tlsv1.2 -sSf https://kdsintf.amd.com/vlek/v1/Milan/cert_chain -o ./cert_chain.pem

1. Verify that the VLEK Certificate was Signed by AMD's Root Trust Certificate

shellCopyEditsudo openssl verify --CAfile ./cert_chain.pem vlek.pem

1. Validate the Authenticity of the Attestation Report

shellCopyEdit./snpguest verify attestation ./ report.bin

By following the above steps, you can fully obtain, store, and verify the SEV-SNP attestation report to ensure its authenticity and integrity.