## 6 Results and Discussion
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & \multicolumn{3}{c}{**Confidence Interval (95\%)**} \\ \hline
**Number of Extends** & **Mean Difference (ms)** & **Lower** & **Upper** \\ \hline
10 & 9.91 & 8.87 & 10.98 \\ \hline
100 & 7.94 & 7.35 & 8.55 \\ \hline
1000 & 8.08 & 7.59 & 8.41 \\ \hline
10,000 & 8.01 & 7.5 & 8.34 \\ \hline
100,000 & 8.16 & 7.62 & 8.48 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Increase in remote anchoring time compared to local anchoring. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & \multicolumn{3}{c}{**Confidence Interval (95\%)**} \\ \hline
**Number of Extends** & **Mean Difference (ms)** & **Lower** & **Upper** \\ \hline
10 & 27.23 & 25.62 & 28.86 \\ \hline
100 & 25.42 & 24.91 & 25.93 \\ \hline
1000 & 24.79 & 24.42 & 25.23 \\ \hline
10,000 & 24.71 & 24.43 & 24.99 \\ \hline
100,000 & 24.64 & 24.22 & 25.00 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Increase in remote anchoring time with mTLS compared to local anchoring. Figure 9: Estimated mean anchoring time with 95% confidence interval. Thus, the results suggest that, although the adopted strategy leads to an increase in resource consumption, this overhead can be considered moderate and potentially acceptable for most application scenarios. Therefore, in environments with high memory and CPU demand, the proposed solution is unlikely to affect performance. However, the main consideration concerns the observed increase in anchoring time. The introduction of remote communication or the implementation of an additional security layer, such as the use of mTLS, inherently results in increased process latency. In this context, a careful evaluation of the scenarios in which local or remote anchoring will be used becomes essential. For example, in contexts involving critical services, it is possible to adopt a strategy that combines local anchoring with redundant remote anchoring. In such an arrangement, the redundant remote anchoring would function as a backup mechanism, activated only in the event of failures or specific needs, thereby ensuring greater system resilience. Another relevant point concerns the analysis of the need for an additional security scheme, such as mTLS, in the context of remote anchoring communication. In scenarios involving on-premises data centers, anchoring may be performed without implementing mTLS in order to optimize response time since these infrastructures are locally maintained and managed. In contrast, in situations involving communication with external elements--where the external entity may pose a risk of compromise--the adoption of mTLS becomes crucial to ensure the integrity of the parties involved in the communication. In this context, the costs associated with using mTLS are justified by the benefits it provides, especially in mitigating risks and ensuring the security of interactions. Figure 11: Estimated mean CPU utilization of host 2 with 95% confidence interval. Figure 10: Estimated mean CPU utilization of host 1 with 95% confidence interval. Theoretical Evaluation of the Solution in the Context of Real Vulnerabilities  
In this section, we conduct a theoretical assessment of the proposed solution, focusing on real-world vulnerabilities documented in CVEs and the scientific literature. The analysis emphasizes recent vulnerabilities that compromise the integrity of the vTPM. We begin by describing potential threats to the system that could be exploited by malicious actors. Then, we present three threat scenarios constructed based on actual identified vulnerabilities. Finally, we analyze how the proposed solution can be employed to detect integrity violations. In this assessment, we consider the possibility of an attacker gaining full control over all the resources in the environment. This implies that the adversary may acquire superuser privileges, granting unrestricted access to the entire stack of services and infrastructure associated with the compromised node.