Skip to content

SEV

The AMD Secure Encrypted Virtualization launch process is significantly simpler than SGX, although there are very many keys involved. The goal is to be able to launch a guest VM on a cloud host in a way that allows secrets to be provisioned into the guest without the cloud provider being able to see them, and to encrypt the memory of the guest in a way that the cloud provider can't see the running VM either. Protection from other guests and hardware attacks is also expected, although the firmware running on the AMD PSP is able to see everything in clear text.

Resources:

AMD SEV Attested launch

2019 Security

Manufacturing time

  • AMD generates Root Signing Key (ARK), which is used for all products
  • AMD generates SEV Signing Key (ASK) for each CPU model or family, signed it with ARK
  • PSP or AMD generates chip endorsement key (CEK) and burns it into OTP fuses in the CPU
  • AMD signs CEK with the ASK, allowing the PSP to prove that it is a valid AMD SEV CPU

Provisioning time

  • PSP generates Platform Endorsement Key (PEK), signs it with its own CEK
  • PSP generates ECDH Platform Diffie-Hellman key (PDH), signs it with PEK
  • Cloud provider installs Owner Certificate Authority Public Key (OCA) into the PSP
  • Cloud provider signs PEK with OCA, sends it into PSP

Enclave launch time

thumb

  • PSP sends PDH and PEK to hypervisor, which sends chain to guest owner
  • Guest owner validates PDH with chain of PEK, CEK, ASK and ARK, as well as OCA
  • Guest owner generates ephermeral ECDH key (GDH)
  • Guest owner derives shared Key Encryption Key (KEK) from private key of GDH and public key of PDH
  • Guest owner generate ephemeral Transport Integrity Key (TIK) and Transport Encryption Key (TEK), encrypts both with KEK
  • Guest owner sends public key of GDH, encrypted TIK/TEK, and launch policy to hypervisor
  • Hypervisor calls PSP LAUNCH_START with these parameters (but can't decrypt the TIK/TEK)
  • PSP derives KEK from its private key of PDH and the public key of GDH, uses KEK to decrypt TIK
  • Hypervisor allocates ASID and calls PSP ACTIVATE to enable guest
  • PSP generates memory encryption key (VEK) for this ASID (if the ASID is already in use, the PSP returns ASID_OWNED and won't activate the guest)
  • Guest owner sends clear text kernel and initrd to hypervisor
  • Hypervisor calls PSP LAUNCH_UPDATE_DATA to add the kernel and initrd to the guest
  • PSP hashes clear text of data and encrypts physical pages with VEK (*** IS THERE A TOCTOU? ***)
  • Hypervisor calls PSP LAUNCH_UPDATE_VMSA to configure virtualization structures
  • PSP hashes clear text VMSA structures and encrypts them with VEK
  • Hypervisor calls PSP LAUNCH_MEASURE
  • PSP generates liveliness nonce and computes HMAC of the nonce data, vmsa and policy using the TIK that only it and the guest owner know
  • Hypervisor sends this measurement HMAC to the guest owner (it can't fake it since it doesn't know TIK)
  • Guest owner validates HMAC, trusts that VM has been setup correctly
  • (Hypervisor can't add new pages at this point since the LAUNCH_MEASURE moves the guest into LSECRET mode and disables the LAUNCH_DATA command)
  • Guest owner sends up to 16 KB encrypted with TEK and HMAC'ed with TIK to the hypervisor. This can contain secrets like disk encryption keys so that the cloud provider can't see them (although the cloud provider was able to see the entire kernel and initrd, so they should not contain secrets).
  • Hypervisor calls PSP LAUNCH_SECRET to add this data to the guest
  • PSP validates HMAC with TIK, decrypts with TEK and re-encrypts with VEK into the guest's memory
  • Hypervisor calls PSP LAUNCH_FINISH, which causes the PSP to forget all of the guest keys except for VEK
  • Hypervisor invokes VMRUN to start the encrypted guest enclave

VM Exit

To be written. Guest has to protect access to VMSA.

Enclave migration

To be written (using SEND_START etc)

Last update: November 8, 2020