Raw Attestation with a vTPM
Last updated
Was this helpful?
Last updated
Was this helpful?
While the boot process can be secured through the usage of secure boot it is also in the interest of the attesting party to ensure that the applications of the guest have not been modified. Therefore the attestation process needs to be extended. This can be achieved through the usage of a virtualized TPM, which is used to store the measurements as the hardware is not able to measure the applications as this is outside of the design and to many different configurations need to be accounted for.
General considerations include if the vTPM needs to be able to have a state management and how the root Endorsement Key of the vTPM is created/provisioned as this key is usually used to identify genuine TPMs as it is signed by the manufacturer and injected at production time into the TPM.
AMD-SEV-SNP has a new concept of Virtual Machine Privilege Levels which allows to divide the address space of the VM into different privilege levels. This allows the Guest VM to assign specific pages read/write/execute permissions. Therefore VMPLs can be treated as a kind of nested virtualization with a management layer running at VMPL0.
To standardize the handling of the transition between different privilege levels and allow for the efficient usage of privileged modules a standardized Secure VM Service Module has been developed by AMD. Running at VMPL0 ensures that the guest can not temper with the SVSM and its services.
The SVSM can be used to realize a secure vTPM which is executed at VMPL0. The guest is able to interact through the exposed vTPM API from the SVSM with the vTPM. As the vTPM belongs to the same VM (vCPU and Address Space) that is issuing commands and receiving responses from the vTPM there is no need to establish a secure channel via SPDM or TLS. Instead the OS can write to the protected memory and afterwards notify the SVSM that a command needs to be executed with the information stored at that particular memory region. This reduces the Trusted Computing Base as the inbuild memory protection of AMD-SEV-SNP is leveraged. The execution between different VMPLs however forces a VMEXIT and VMENTRY therefore the guest and SVSM need to verify that the hypervisor placed the vCPU in the correct execution level before the VM can resume operation as otherwise the vTPM can not be executed.
In contrast to AMD-SEV-SNP, Intel TDX 1.0 is not equipped with different privilege levels. In Intel TDX 1.0 the complete VM is executed at the same privilege level. Therefore it is not possible to host a vTPM in the same address space of the VM without compromising its security guarantees. Therefore the current approach for Intel TDX is to launch a second VM which hosts the vTPM. This requires the VMs to establish a secure communication channel through SPDM, TLS or similar protocols which increases the TCB. If the vTPM is being hosted on the same platform the hypervisor can be leveraged afterwards to exchange the TPM command and the TPM response. This requires to compute additional keys after the session establishment which are used to encrypt and decrypt the messages that are written to shared memory pages which the hypervisor uses to notify the VM/vTPM about new incoming information.
Since Intel TDX 1.5 nested virtualization is supported and therefore launching a separate VM for the vTPM is no longer necessary. Instead the L1 VMM can launch a L2 VM and provide the VM with a vTPM created and hosted through the L1 VMM. This has the advantage that the VM can be directly provided with a vTPM through the already existing driver structure and therefore not needing to communicate over SPDM or TLS with another VM. As L1 VMM controls the L2 VM it can ensure that the vTPM is not tampered with. The data from the vTPM is protected through the security guarantees of the Intel TDX enabled hardware as the L1 VMM itself runs in a TDX enabled VM.