## 2 Related Work
### vTPM Anchoring  
The main work underpinning the idea of the TPM virtualization was proposed by [PERSON] et al. (2006) [5], establishing the foundations, key advantages, and challenges of working with this approach. This work was a pioneer in proposing the concept and presenting an architecture for creating virtual TPM instances that adapt to the dynamic lifecycle of virtual machines and can directly interface with the physical TPM of the platform hosting these VMs.  
[PERSON] et al. (2006) [5] presented four distinct approaches to establishing trust in vTPM instances. Two of these approaches involve anchoring the vTPM on the physical TPM by linking either the Attestation Key or the Endorsement Key (EK) of the vTPM to the Attestation Key of the physical TPM. The other two suggested alternatives consist of creating a hardware-independent certification authority for the Endorsement Key or using a secure co-processor as a substitute for the physical TPM. Most subsequent works have focused on proposing similar schemes using different approaches.  
The proposal by [PERSON] and [PERSON] (2022) [15] introduced a module called CoCoTPM, designed to provide a trusted platform for Confidential Computing by offering TPM functionalities to virtual machines. The authors advocated for a centralized management model for vTPM instances. Within this framework, a driver in the VMs, called CoCoTPMdriver, was considered, which communicates with the software-based TPM (CoCoTPM) using the hypervisor as an intermediary. Trust in CoCoTPM is established through the implementation of a self-signed certificate, which is used to sign the Endorsement Key and acts as a subordinate certification authority. Additionally, the persistent state of CoCoTPM is encrypted and stored on the host that houses the VMs.  
[PERSON] et al. (2024) [6] presented an approach for binding the physical TPM to the vTPM. The solution focuses on using the physical TPM to encrypt primary keys, the creation of child objects, and the primary seeds of the vTPM. The authors proposed a mechanism to safeguard the persistent state when the instance is interrupted based on creating a primary key in the vTPM for its encryption.  
[PERSON] and [PERSON] (2019) [22] proposed a hybrid TPM (hTPM) architecture that combines a hardware TPM and software TPM, leveraging Windows 10-based virtualization and Virtual Secure Mode (VSM) [23]. The hTPM isolates critical operations in VTL1, which is the trust level created by VSM for executing privileged code. Additionally, the proposed approach aims to protect the TPM state through encryption and secure storage. Together, the solution enables the establishment of a communication and trust transfer channel between the hardware and software modes, allowing users to choose between the hardware TPM and software TPM as needed.  
The eTPM, as presented by [PERSON] et al. (2018) [PERSON] et al. (2018), and its evolution, the svTPM, proposed by [PERSON] et al. (2023) [PERSON] et al. (2023), offer methods to protect the persistent state of the vTPM through sealing and encryption mechanisms provided by Intel Software Guard Extensions (SGXs). Both solutions employ SGXs to manage vTPM instances. In the context of trust establishment, the eTPM uses the physical TPM to enhance the reliability of the underlying platform and suggests leveraging SGXs to verify the initialization of the eTPM. In contrast, the svTPM introduces a mechanism based on an SGX remote attestation scheme, known as Intel DCAPs (Data Center Attestation Primitives) [24].