RFC: SEV SNP Node Attestation Plugin #4469
Comments
|
Hi @aembrito, thank you so much for putting in this detailed proposal. We're still reviewing and discussing this and will get back to you once we've digested some of the details. |
|
Hi @jensfr! There is a implementation of the plugin on this repository |
|
Hi @aembrito , thank you for your patience on this. The RFC is very thorough but also long which contributed to delay as we need to allocate time to review etc. I spent some time reading through and thinking about it, one thing I noticed is that there isn't much written on how this will actually be used. For example, there is a long list of selectors that the plugin emits, but it's hard for me to understand how someone will use and operationalize many of them. It would be really helpful to have an end-to-end worked example that includes workload registration. In the end, the person/process registering the workload needs to have advanced knowledge of the selector data. Understanding this part will help a lot in making sure that the plugin configuration, selectors, etc are clear and useful. Building on the LUKS example would be great! |
|
Hi @aembrito , happy new year! Just checking back in here |
|
Hi again @aembrito , we're going to go ahead and close this out until we have some a better understanding of how folks will interact with this. In the meantime, you could publish the plugin independently as an out-of-tree plugin for testing etc .. happy to point you in the right direction there if that's of interest. |
RFC: SEV SNP Node Attestation Plugin
Abstract
This document defines the AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) Node Attestation Plugin for SPIRE. The plugin provides a mechanism for verifying the identity of SEV-SNP-enabled Virtual Machines (VMs) by leveraging the hardware-based attestation capabilities of the AMD SEV-SNP processor. The document provides detailed specifications for the plugin, including its workflow, threat model, and description of its chain of trust. It also describes the security considerations and deployment scenarios for the plugin.
Background
AMD SEV-SNP
AMD SEV-SNP (Secure Encrypted Virtualization-Scalable Nested Paging) is a set of hardware-based security features designed to enhance the security of virtualized environments [4]. It extends both the AMD Secure Encrypted Virtualization (SEV) technology, which provides hardware-based memory encryption for VMs to isolate them from the hypervisor [1], and SEV-Encrypted State (SEV-ES), which adds additional protection for CPU register state as an extension of SEV [3].
The main difference between AMD SEV/SEV-ES and AMD SEV-SNP is the strong memory integrity protection present on SEV-SNP that helps prevent malicious hypervisor-based attacks, such as data replay and memory re-mapping. The fundamental concept behind SEV-SNP integrity is that whenever a VM accesses an encrypted memory page, it must retrieve the value it previously wrote. If it reads a different value, an exception must be thrown [4].
Threat Model for AMD SEV-SNP Confidential VMs
The threat model for Confidential Computing assumes a highly powerful attacker with privileges to access and manipulate all software layers of the infrastructure, including the operating systems, hypervisors, and cloud computing platforms where confidential workloads are running. Regarding the host machine and its software stack, the attacker may be able to steal cryptographic keys and sensitive data, modify application code or binaries, and launch various types of attacks, such as side-channel attacks. [4]
Under SEV-SNP, as with SEV and SEV-ES, the AMD System-On-Chip (SoC) hardware, the AMD Secure Processor (AMD-SP), and the VM itself are all treated as fully trusted, while all other CPU software components, PCI devices, and operators of these are treated as entirely untrusted. This includes the BIOS on the host system, the hypervisor, device drivers, and other VMs. This means that these components are assumed to be malicious, potentially conspiring with other untrusted components to compromise the security guarantees of a SEV-SNP VM.
(Figure from [4])
To enable third parties to have confidence in the VM's state, the SEV-SNP provides a mechanism to attest integrity of the VM's and its environment (confirming it is indeed a AMD SEV-SNP VM). This is done by generating an Attestation Report that reflects the VM's context, including policy information and measurements taken by the AMD-SP during launch. Through measurement hashes in the Attestation Reports, third parties can verify, for example, if the VM has been launched with the expected state (e.g., a specific version of Linux Kernel, the expected Initramfs that includes disk integrity mechanisms). In addition, other information in the Attestation Report reflect other configuration options, for example, if this VM is allowed to run in debug mode. These Attestation Reports are described next.
Chain of Trust
To build a chain of trust between the AMD-SP and the guest VM that remote parties can validate, the AMD-SP provides a protected path through which the guest VM can request Attestation Reports on their behalf at any time. When the guest asks for a report, it supplies 512 bits of arbitrary data to be included in the report. The resulting report will contain this data alongside identity information about the guest and the host where it is running. The report can be signed by a Versioned Chip Endorsement Key (VCEK), an attestation signing key derived from chip-unique secrets, and a TCB (Trusted Computing Base) version, signed by the AMD Root Keys and kept inside the AMD-SP with no access by users. The report may also be signed by a Versioned Loaded Endorsement Key (VLEK), derived from a seed maintained by the AMD Key Derivation Service (KSD) [5]. The third-party should verify the authenticity of the report based on its signature. A successful signature verification proves that the 512 bits of guest data supplied in the report came from the guest whose identity is described.
Attestation Report
The purpose of the Attestation Report is to allow the VM to prove to third parties that it is confidential and has been configured in a trustable state with no tampering. The following table describes the Attestation Report structure [5]:
The Attestation Report is signed by the private part of the VCEK/VLEK, which is located inside the AMD-SP. The public part of the VCEK/VLEK can be used to verify the signature, and its authenticity can be verified against the AMD Certificate Chain to ensure that it is valid. Therefore, we can guarantee that the report was generated inside an AMD-SP, as it is the only entity with access to the VCEK/VLEK private part.
Moreover, the user can include 512 bits of data in the Attestation Report, which ensures its freshness. By doing this, we can trust that (1) the Attestation Reports given by a VM have been freshly generated in response to the current request, and (2) the report was generated by an authentic AMD-SP (due to its signature).
Platform Info
The platform info structure details configurations about the platform. It is structured as follows.
Policy
The policy parameters refer to the set of rules that govern the behavior of the VM, for example, if the VM allows or not debug mode or if it is allowed to run in a platform with Simultaneous Multithreading (SMT) enabled. In the Attestation Report, the policy field is represented as 64 bits of data and is structured as follows [5]:
SINGLE_SOCKETDEBUGMIGRATE_MASMTABI_MAJORABI_MINORTCB Version
The TCB_VERSION is a structure containing the security version numbers of the components in the SNP firmware's trusted computing base (TCB). A TCB_VERSION is associated with each image of firmware. The TCB_VERSION structure is described below:
MICROCODESNPSecurity Version Number (SVN) of SNP firmware
-TEEBOOT_LOADERLaunch Measurement
The Attestation Report also contains a Launch Measurement of the guest, which is calculated as [6]:
Where "||" represents concatenation. GCTX represents the guest context and the GCTX.LD is a hash digest of all plaintext data imported into the guest at boot, and how this value is calculated depends on the hypervisor. For QEMU, it can be calculated as:
Where:
firmware_blobis the content of the entire firmware flash file (for example, OVMF.fd). Note that you must build a stateless firmware file that does not use an NVRAM store because the NVRAM area is not measured, and therefore, using firmware that uses a state from an NVRAM store is not secure.If kernel is used, and kernel-hashes=on, then
kernel_hashes_blobis the content of PaddedSevHashTable (including the zero padding), which itself includes the hashes of kernel, initrd, and cmdline that are passed to the guest.If SEV-ES is enabled (policy & 0x4 != 0),
vmsas_blobis the concatenation of all VMSAs of the guest vcpus. Each VMSA is 4096 bytes long; its content is defined inside Linux kernel code as struct vmcb_save_area, or in AMD APM Volume 2 (APMVOL2) Table B-2: VMCB Layout, State Save Area.Ensuring Node Integrity and Security
Although SEV-SNP guarantees guest memory encryption, it only encrypts data in use. To ensure data protection at rest, such as keys and secrets stored in the VM disk, a Full Disk Encryption (FDE) solution, such as Linux Unified Key Setup (LUKS), must be used. To guarantee data integrity at rest, an integrity verification tool such as DM-Verity must also be used. It is recommended to include these verifications in the Initramfs or kernel because they are measured in the Launch Measurement included in the Attestation Report so the VM owner can verify if the value matches with the expected, ensuring that everything has been performed correctly and that there has been no tampering neither in the kernel nor in Initramfs.
The sequence diagram presented next describes how a chain of trust between AMD-SP and the VM disk integrity is built through the Launch Measurement included in the Attestation Report. Although other components impact the chain of trust, in this scheme, we focus on the ones that directly affect the integrity of the VM Disk.
sequenceDiagram participant sp as AMD-SP participant kern as VM Kernel participant init as VM Initramfs participant vm as VM participant owner as Guest Owner par load in memory sp->>kern: and sp->>init: end par measure sp->>init: and sp->>kern: end init->>kern: calls DM-Crypt Note right of kern: Open Luks Partition init->>kern: calls DM-Verity activate kern Note right of kern: Verifies disk <br />Integrity kern-->>init: disk integrity status deactivate kern alt disk is ok init->>vm: load root fs and boot owner->>vm: request Attestation Report activate vm vm->>sp: request Attestation Report activate sp sp-->>vm: Attestation Report deactivate sp vm-->>owner: Attestation Report deactivate vm owner->>owner: Verifies measurement in<br/>the Report to assure kernel<br/>and initramfs integrity Note right of owner: If the measurement matches<br/>the expected value,<br/>the owner trusts the integrity<br/>of VM Disk else disk not ok init->>init: abort VM init endFor step 3, we must retrieve the secret to open the encrypted partition. For this, we can use a Key Managment Service (KMS). For the proof of concept, we used a workload named Fetch Key Workload (FetchKeyWL) to retrieve the secret (the disk encryption key) based on the SPIFFE ID and the disk UUID.
sequenceDiagram participant init as Initramfs participant agent as Agent participant wl as FetchKeyWL participant kms as KMS init->>agent: initialize Agent Note right of agent: Attest to Server init->>wl: fetch decryption key activate wl wl->>agent: attest to Agent activate agent agent-->>wl: SVID deactivate agent wl->>kms: request decryption key activate kms Note right of kms: verify CA kms-->>wl: decryption key<br/>associated to SPIFFEID deactivate kms wl-->>init: decryption key deactivate wl init->>init: decrypt and<br/>load root fsProposal
We propose a new SPIRE Node Attestation Plugin that uses SEV-SNP features to attest SPIRE Agents running inside SEV-SNP-enabled VMs. The idea behind the plugin is to take advantage of the existing Attestation Report provided by the AMD-SP to guarantee the identity and integrity of the VM running the SPIRE Agent.
Attestation Workflow
sequenceDiagram participant AMDSP as AMD-SP participant Agent as Agent in CVM participant Server as Server Agent->>Server: Request SVID activate Server Server->>Agent: Request Attestation Report<br/> providing the nonce activate Agent Agent->>AMDSP: Request Attestation Report and VCEK<br/>providing the nonce activate AMDSP AMDSP-->>Agent: VCEK + Attestation Report (nonce included) deactivate AMDSP Agent-->>Server: VCEK + Attestation Report (nonce included) deactivate Agent Note right of Server: 1) Verify the VCEK<br/>against AMD cert chain<br/>2) Verify nonce <br/>3) Verify signature Server-->>Agent: SVID deactivate ServerConfiguration
To run the plugin, the VCEK public certificate must be configured on the SEV-SNP host through the SNP_SET_EXT_CONFIG command. So the Guest can obtain it along with the attestation report through a SNP_GET_EXT_REPORT [9]. In most cloud providers, this configuration is done by default on the hosts; in on-premise solutions, it can be done using the sev-guest tool.
A sample configuration for the SPIRE Agent would include the following configs for the node attestor:
The server must then be configured with (or retrieve) the AMD certificate chain to verify the authenticity of the VCEK. The steps to obtain this cert chain can be found here.
amd_cert_chainA sample configuration for the SPIRE Server to attest Agents running inside SEV-SNP VMs, with the AMD Cert Chain file located at
/home/ubuntu, would include the following configs for Node Attestor:Selectors
The plugin selectors we propose use most of the fields in the attestation report:
The VCEK and VLEK selectors are the SHA512 of the signing key's certificate used to sign the report.
SPIFFE ID Format
Finally, the proposed SPIFFEID structure for the plugin looks like:
Example:
Current limitations
The AMD SEV SNP Node Attestor runs in any cloud provider that exposes the /dev/sev-guest device to the VMs. VMs that can generate SNP attestation reports could thus prove to run confidentially. However, some providers employ alternative approaches to measure the GCTX.LD and, therefore, some components will not be measured (such as the Initramfs). Consequently, our strategy of measuring the partition integrity cannot be applied in such scenarios.
One alternative approach for public cloud providers is to measure the virtual TPM during the AMD SEV-SNP boot, and use the Integrity Measurement Architecture (IMA) to measure the rest of the boot (or simply the Initramfs). Unfortunately, current vTPMs in public clouds are closed source.
Request for Comments
This proposal seeks to elicit feedback on the proposed approach for an AMD SEV-SNP Node Attestation Plugin. The plugin aims to enhance the security of virtualized environments by verifying the identity of SEV-SNP-enabled VMs by leveraging the hardware-based attestation capabilities of the AMD SEV-SNP processor. We welcome any comments, suggestions, or concerns you may have about the proposal.
Authors:
References
[1] AMD Secure Encrypted Virtualization (SEV) https://developer.amd.com/sev/
[2] AMD Memory Encryption. https://amd.wpenginepowered.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v9-Public.pdf
[3] Protecting VM Register State With SEV-ES. https://www.amd.com/system/files/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf
[4] AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
[5] SEV Secure Nested Paging Firmware ABI Specification. https://www.amd.com/system/files/TechDocs/56860.pdf
[6] Secure Encrypted Virtualization API Version 0.24. https://www.amd.com/system/files/TechDocs/56860.pdf
[7] QEMU AMD Secure Encrypted Virtualization (SEV). https://www.qemu.org/docs/master/system/i386/amd-memory-encryption.html
[8] Attesting AMD SEV-SNP Virtual Machines with SPIRE. https://doi.org/10.1145/3615366.3615419
[9] AMD SEV-SNP Attestation: Establishing Trust in Guests. https://www.amd.com/content/dam/amd/en/documents/developer/lss-snp-attestation.pdf
The text was updated successfully, but these errors were encountered: