⚙️
Morphisms: Confidential Serverless Containers
  • Introduction
  • Preliminaries
    • What is Confidential Computing?
      • Threat Model
      • Intel SGX
        • Threat Model
        • Memory Layout
        • Memory encryption
        • Enclave Lifecycle
        • Entering and Exiting an Enclave
        • Measurement
        • Certificate
        • Key Derivation
        • Attestation
        • Gramine
        • SGX2
        • Secret Key Provisioning
      • AMD SEV-SNP
        • Encrypted CPU Registers
        • Memory encryption
        • Secure Nested Paging
        • Virtual Machine Privilege Levels (VMPL's)
        • Cryptographic Keys
        • Secret Key Provisioning
        • Guest Deployment
    • Serverless (FaaS)
      • Knative
  • Confidential Serverless Containers
    • Introduction
    • Intel SGX
      • Threat Model
      • Remote attestation verification
      • Secure Storage
        • HashiCorp's Vault
      • Architecture
        • Confidential Knative
        • Certificates
        • Session Management
      • Confidential Container Configuration
    • AMD SEV-SNP
      • Threat Model
      • Architecture
        • Network communication
        • KMS
        • Updates
        • Key rotation
      • Design Decision
  • Benchmarks
    • Hardware
    • Results
    • Architecture Comparison
  • Getting Started
    • FAQ
    • Intel SGX
    • AMD SEV-SNP
  • Glossary
    • SGX Glossary
    • AMD SEV-SNP Glossary
Powered by GitBook
On this page
  1. Preliminaries
  2. What is Confidential Computing?
  3. AMD SEV-SNP

Secret Key Provisioning

PreviousCryptographic KeysNextGuest Deployment

Last updated 1 year ago

Only the hypervisor has access to the SEV API, so any inbound or outbound traffic to or from the SEV firmware must go through the hypervisor. The hypervisor is not trusted in the AMD SEV trust model and a secure channel must be established to the SEV firmware where the hypervisor cannot perform a man-in-the-middle (MITM) attack. In particular, authenticity, integrity and confidentiality must be guaranteed by the secure channel. This channel is needed for initial provisioning of VMs (case D) and for migration (case M). In the later context, a client is either the guest owner deploying VMs or another SEV firmware in case of migration. The source SEV firmware is migrating a VM to the target SEV firmware. Note that in further context the public keys, except the root keys of both trust chains, are received and validated by certificates.

The first step in both cases of secret channel instantiation is for the hypervisor to obtain the PDH, PEK, and platform ID of the SEV firmware. In case A, the hypervisor simply passes the previously received values to the guest, and the guest makes the request to the AMD key server with the received platform ID. In Case B, the hypervisor communicates directly with the AMD Key Server. In both cases, the AMD Key Server responds with the ARK, ASK, CEKID. Additionally, in case B, the hypervisor must also forward the response to the source firmware.

The next steps are identical in both cases. The PHD is auhenticated by verifying the certificate chains (PDH → PEK → CEKID → ASK → ARK). After the validation of both trust chains, the next step is to perform the signed key exchange non-interactively with the received PDH to derive the shared secret, called the master secret. Next, a Key Derivation Function (KDF) is used to generate the Key Encryption Key (KEK) and the Key Integrity Key (KIK) from the Master Secret. Finally, the client generates the Transport Encryption Key (TEK) and Transport Integrity Key (TIK). The KEK and KIK are used to securely send the TEK and TIK to the SEV firmware along with the client's unencrypted public Diffie-Hellman key.

Sequence to establish the secure channel for migration between two SEV firmware (AMD-SP's) (case M) or between a SEV firmware and the guest owner (case D). Figure from
here