Raw Attestation with vTPM
Understand about virtual Trusted Platform Module and how it works for various vendors.
Last updated
Was this helpful?
Understand about virtual Trusted Platform Module and how it works for various vendors.
Last updated
Was this helpful?
While Raw Attestation and Secure Boot combine to validate the integrity of the boot process up to the OS kernel, they do not cover the runtime environment. To ensure that running applications, libraries, and their configurations have not been tampered with, the attestation process must be extended. This is achieved using a Virtual Trusted Platform Module (vTPM).
A vTPM provides a standardized, in-guest mechanism for recording cryptographic measurements. The underlying hardware is not designed to measure every possible application configuration, so the vTPM acts as a secure log where the running OS can store this evidence.
Key Considerations for vTPMs
Implementing a vTPM introduces two critical design considerations that must be addressed to maintain a chain of trust.
1. Establishing a Root of Trust (Endorsement Key)
A physical TPM's trustworthiness is rooted in its Endorsement Key (EK), a unique identity key that is injected and signed by the manufacturer during production. For a virtual TPM, this physical root of trust does not exist.
The Challenge: How can a relying party trust that a vTPM is genuine and not a spoofed piece of software?
The Solution: The vTPM's identity must be cryptographically bound to the underlying hardware's attestation. The vTPM generates its own Endorsement Key, which is then included in a hardware attestation report such as an AMD SEV-SNP or Intel TDX report. The relying party first verifies the hardware report and, in doing so, receives the authentic public half of the vTPM's Endorsement Key, establishing a new root of trust for all subsequent interactions with the vTPM.
2. State Management
Unlike a physical TPM, a vTPM's state including its keys and measurement logs can be either persistent or ephemeral.
The Challenge: Should the vTPM retain its state across reboots?
The Solution: The choice depends on the use case.
Stateless vTPM: Resets on every boot. This is ideal for pure attestation use cases, as it provides a clean slate for measurements every time the system starts.
Stateful vTPM: Persists its state across reboots. This is necessary for use cases that require the vTPM to act as a long-term key store or secret vault.
The method for implementing a Virtual Trusted Platform Module (vTPM) differs significantly between AMD and Intel due to their distinct hardware architectures for memory isolation and virtualization.
AMD SEV-SNP introduces Virtual Machine Privilege Levels (VMPLs), a hardware feature that partitions a single VM's address space into four distinct privilege rings (VMPL0 to VMPL3). This enables a form of nested isolation within the same confidential VM.
The SVSM and vTPM
This architecture is ideal for hosting a vTPM securely. The standard approach involves using a dedicated, open-source firmware component called the Secure VM Service Module (SVSM).
Isolation: The SVSM runs at the most privileged level, VMPL0, while the guest operating system runs at a less privileged level such as VMPL1. Because the guest OS cannot access VMPL0 memory, it cannot tamper with the SVSM.
vTPM Implementation: The vTPM logic is implemented as a service within the SVSM.
Communication Mechanism
Communication between the guest OS and the vTPM is highly efficient and secure:
The guest OS writes TPM commands to a specific memory region shared with the SVSM.
The guest notifies the SVSM that a command is ready.
The SVSM at VMPL0 executes the command and writes the response back to the shared memory.
This approach leverages the hardware-enforced memory protection of SEV-SNP, eliminating the need for complex protocols like SPDM or TLS between the OS and the vTPM. This results in a significantly smaller and more secure Trusted Computing Base (TCB).
The approach for Intel TDX has evolved with different hardware versions.
The initial release of Intel TDX did not support VMPLs or nested virtualization. The entire guest VM (TD Guest) runs at a single privilege level.
Isolation: To host a vTPM securely, it must be run in a separate, dedicated TD Guest. This "vTPM VM" is isolated from the primary "Workload VM" by the hardware.
Communication Mechanism:
The two VMs must first establish a secure communication channel (e.g., using SPDM or TLS) over a shared bus like virtio-vsock.
Once a session is established, encrypted TPM commands and responses are exchanged over shared memory pages, managed by the hypervisor.
This approach has a larger TCB, as it relies on networking protocols and inter-VM communication components.
With version 1.5, Intel TDX introduced support for nested virtualization, which simplifies vTPM implementation significantly.
Isolation: A trusted, TDX-protected VMM running at Level 1 or L1 can launch a nested TD Guest at Level 2 or L2. The L1 VMM can create and manage a vTPM instance for the L2 guest. The L2 guest cannot access or tamper with the L1 VMM, ensuring the vTPM's integrity.
Communication Mechanism: The L1 VMM provides the vTPM to the L2 guest through standard, existing virtualization driver interfaces. This eliminates the need for a separate vTPM VM and complex networking protocols, bringing the architecture closer to a traditional hypervisor-guest model while maintaining TDX security guarantees for both the L1 VM and its nested L2 guest.
