## 4 Hyperconverged TPM
### Anchoring Architecture  
Among the architectures that propose the anchoring of the vTPM to the physical TPM, the approach presented in this paper is an evolution of the architecture introduced in [PERSON] et al. (2024) [51]. This architecture considers the protection of the vTPM's integrity through the monitoring of both the persistent and volatile states. The relationship between the main components of the solution can be visualized in Figure 3, where we can identify the following elements:* **Hosts:** Machines that comprise the hyperconverged system. There are two types of hosts: hosts with TPMs and hosts without TPMs. * **User VMs**: Virtual machines used by system users to run their applications and store data. * **u-vTPM**: vTPM instances allocated to user VMs. * **Management VM (m-VM)**: Individually, the m-VM is the virtual machine responsible for coordinating the anchoring of the u-vTPMs to their own vTPM. Together, the m-VMs form a logically centralized but physically distributed management system (MS). Each m-VM that makes up the management system is responsible for consuming the TPM resources and managing access to its resources by other m-VMs. To do so, the m-VMs exchange information among themselves to make the most appropriate decision about where to perform the anchoring of the vTPM, whether when the local node does not have a hardware TPM or when anchoring replicas are required. * **m-vTPM**: vTPM instance allocated to m-VM. * **Software TPM Emulator**: Software component responsible for providing the instances of u-vTPM and m-vTPM. Furthermore, it is the element that reports legitimate modifications made to the states of the vTPMs. * **vTPM Anchoring Module (vTPM-AM)**: Kernel module running on the m-VM, responsible for anchoring the u-vTPMs to the m-vTPM. It also anchors remote m-vTPMs, located on machines that either lack a local TPM chip or require information replication. * **m-vTPM Anchoring Module (m-vTPM-AM)**: Kernel module running on hosts with TPM, responsible for anchoring the m-vTPM to the TPM chip. * **Agent-Host**: Component responsible for receiving the measurements from the software emulator, identifying whether they belong to the m-vTPM or u-vTPM, and forwarding them to the appropriate element for anchoring. On a Host with TPM, the Agent-Host sends the anchoring data to the vTPM-AM when the measurement refers to the u-vTPM and to the m-vTPM-AM when it refers to the m-vTPM. On a host without a TPM, the Agent-Host forwards the anchoring data for both the u-vTPM and m-vTPM to the vTPM-AM. * **TPM**: A chip present in some hosts, responsible for providing hardware-based root of trust by anchoring the m-vTPM. In the proposed hyperconverged anchoring system, there are two types of hosts: hosts with TPMs and hosts without TPMs. Each of these hosts can host multiple user VMs, each with its own u-vTPM. The hosts must also have a management VM (m-VM), enabling  
Figure 3: Hosts with and without TPM. the integration of the solution with one of the main architectures used in hyperconverged infrastructures [32]. When using this architecture to build hyperconverged environments, the m-VM takes on the responsibility of allocating resources and managing access to these resources by other VMs. The main benefit of this model is flexibility as it tends to support multiple hypervisors and operate on different platforms. Furthermore, this architecture enables the implementation of mechanisms to manage the load on the TPM, resulting from the anchoring of vTPMs and the intrinsic limitations of the chip's hardware [52]. In this context, we consider that the anchoring of vTPMs can occur either locally or remotely. Local anchoring occurs when the trust chain is established with the local TPM chip on the same machine hosting the vTPM as the root of trust. This means that local anchoring of a vTPM applies to hosts that have a TPM chip. Remote anchoring occurs when the trust chain is based on the hyperconverged TPM as the root of trust.