Architecture

Introduction

In order to establish a secure vTPM for confidential VMs a well thought out architecture between all involved components need to be established. This includes, but is not limited to, the SVSM, Host OS, Guest OS, and hardware and firmware.

Ephemeral vTPM

In 2023, IBM Research implemented a secure vTPM running inside the SVSM and established the first architecture for running a confidential vTPM inside the same VM as its user. The architecture uses the VMPL feature and the COCONUT SVSM project, which implements the SVSM specification.

The implementation uses the Trusted Computing Group's reference implementation of the TPM to realise a software-based TPM within the SVSM. Communication between the guest OS and the vTPM within the SVSM is realized by writes to memory and exits to the hypervisor, which initiates the context switch. Therefore, the hypervisor and guest operating system have been enhanced with support for switching between multiple VMPLs. Since requests and responses are only written to memory within the same VM, the content is always protected by SEV-SNP's memory encryption and integrity protection.

As the implementation recreates the vTPM every time during the boot of the VM it is not possible to persist data across reboots.

Persistent vTPM

In order to persist data across reboots the current architecture needs to be extended. The SVSM needs to be able to establish a communication with a remote service which is able to release the state of the vTPM after successful attestation and receive the state back once changes have been done. Persisting the state within the hypervisor is possible however as the state has to be encrypted the remote service is still required as it has to provision the necessary keys for encryption and decryption of the vTPM state. Therefore we will focus on a completely network based approach.

As the SVSM itself does not have support for a complete network stack the communication between the SVSM and the remote service happens through a proxy. This proxy can be reached from the SVSM via a serial connection and transforms the information received by the SVSM into HTTP and sends them to the remote service. The proxy itself runs in the host operating system and therefore is viewed as the SVSM as not trusted. Therefore all communication from the SVSM and the remote service needs to be encrypted in a way that only the SVSM and the remote service are able to access the data.

A secure connection between the SVSM and the remote service can be established using the attestation report generated by the SEV-SNP hardware. In a first step, the SVSM must contact the remote service to establish a communication. The remote service acknowledges the request from the SVSM by sending a nonce. After receiving the nonce, the SVSM generates its part of the Diffie-Hellman key exchange. To prove to the Remote Service that the generated key has not been regenerated, a hash is calculated over the nonce and the public key parameters. The hash is then provided to the SEV-SNP hardware as additional user data during report generation.

The Remote Service can verify that the attestation report generated by the SVSM is from a valid AMD SEV SNP platform. It can also verify that the expected startup measurements of the firmware match, and therefore that the SVSM is trustworthy and running the expected code base. By calculating the hash over the nonce initially sent by itself and the public key parameters provided by the SVSM along with the attestation report, the remote service is able to verify that the report was freshly generated and that the key parameters came directly from the SVSM.

After successful verification, the Remote Service can now send its own part of the Diffie-Hellman key exchange to the SVSM. The SVSM implicitly trusts the received key, as it has no means of verifying the remote service. Subsequent mechanisms, such as encrypted boot with a secret sealed within the TPM, must be implemented to safely accept the TPM state.

The SVSM itself can request a vTPM state from the Remote Service using its Family and Image ID. The Remote Service will release the corresponding vTPM state and encrypt it with the shared secret. Since the measurements of the attestation report match the expected launch measurements, it does not matter from a security perspective if the Family and Image IDs have been exchanged with another valid ID (signed ID block from the Remote Service), since the hypervisor cannot access the data and can only deny the correct vTPM state for a given VM.

In short the message exchange has the following steps:

SVSM establishes communication with Remote Service
Remote Service generates a nonce and supplies it to the SVSM
SVSM generation of Diffie-Hellman key part and transmission of attestation report
1. Generate a hash over the nonce and the key part
2. Provide the hash as user data to generate the Attestation Report
Remote service verifies the attestation report and its freshness, as well as the parameters of the received key part.
Remote Service generates its own Diffie-Hellman key part and sends it to the SVSM
SVSM requests vTPM state from Remote Service
1. Identifies the correct vTPM state through the family and image ID
The Remote Service releases the appropriate vTPM state and sends it back to the SVSM encrypted with the shared Diffie-Hellman secret.

Ephemeral vTPM

Persistent vTPM

Further Reading