Key Management
The security of SEV relies heavily on the protection of memory encryption keys. Exposure of these keys to malicious entities, including a malicious or flawed hypervisor, poses a significant risk to SEV-protected guests. While the hypervisor is responsible for managing the guest and its resources, it must never gain access to the memory encryption keys themselves. To achieve this, the SEV firmware running within the AMD Secure Processor (AMD-SP) provides a secure key management interface.
The hypervisor utilizes this interface to enable SEV for secure guests and carry out common hypervisor tasks, such as guest launching, running, snapshotting, migrating, and debugging.
To safeguard SEV-enabled guests, the firmware assists in enforcing three crucial security properties:
Authenticity of the Platform: This property ensures that the platform is genuinely an authentic AMD platform with SEV capabilities. The platform's identity key, signed by both AMD and the owner of the platform, demonstrates its authenticity and ownership.
Attestation of a Launched Guest: The firmware provides a signature of various components of the SEV-related guest state, including initial memory contents, to the guest owner for verification. This attestation proves that the guest securely launched with SEV enabled and assures the guest owner that the hypervisor did not tamper with SEV initialization before transmitting confidential information to the guest.
Confidentiality of the Guest's Data: To achieve this, the SEV firmware encrypts guest memory using a memory encryption key known only to itself. This ensures that the hypervisor is prevented from accessing the keys and, subsequently, the guest's sensitive data.
The secure key management interface guarantees robust protection for SEV-enabled guests, mitigating potential security risks associated with memory encryption keys.
Authenticating the platform serves as a crucial defense against malicious software or rogue devices attempting to impersonate a legitimate platform. The platform's authenticity is verified using its identity key, which is signed by AMD to demonstrate that the platform is indeed an authentic AMD platform with SEV capabilities. Additionally, the owner of the platform signs the identity key to establish ownership and administration of the machine. This information is shared with the owners of guests or other instances of the firmware on remote platforms, ensuring a secure and trusted environment (see figure below).
Attestation of the guest launch provides reassurance to guest owners that their guests have launched securely with SEV enabled. The firmware generates a signature of various components of the SEV-related guest state, including the initial memory contents. This signature is then provided to the guest owner, enabling them to verify that the guest is in the expected state. This attestation ensures that the hypervisor has not tampered with SEV initialization before confidential information is transmitted to the guest.
An illustrative process is shown in Figure above. The guest owner initially provides the guest image to the cloud system, where the SEV firmware assists in launching the guest and sends a measurement back to the guest owner. If the guest owner validates this measurement as correct, they then provide additional secrets (such as a disk decryption key) to the running guest, enabling it to proceed with start-up.
To maintain guest confidentiality, memory is encrypted using a memory encryption key known exclusively to the SEV firmware. The SEV management interface strictly prevents the export of the memory encryption key or any other secret SEV state outside the firmware without proper authentication of the recipient. This ensures that the hypervisor cannot access the keys and, consequently, the guest's sensitive data.
The interface also facilitates secure guest data migration to another SEV-capable platform. During this process, the guest's memory contents remain encrypted during transmission. Once the remote platform is authenticated, the SEV firmware securely sends the guest's memory encryption keys to enable the remote platform to run the guest. This secure transport mechanism allows the hypervisor to implement migration and snapshot functions while maintaining SEV-enabled security.
Last updated