EVE-OS Virtual TPM

Updated

Introduction

EVE-OS provides a virtual Trusted Platform Module (vTPM) service that allows virtual machines (VMs) workloads to securely leverage TPM functionality, such as key generation, attestation, and sealed storage, even in environments without a physical TPM device.

At the core of EVE-OS's vTPM service is the integration of the software TPM emulator (SWTPM) with the QEMU virtualization infrastructure. This integration enables the creation of a fully functional TPM 2.0 device (TPM 1.2 is not supported) that is presented to each VM as a standard TPM device under the /dev/tpm* interface, mirroring how a physical TPM would be exposed in hardware-based systems. 

vTPM provides a fully compatible virtual TPM 2.0 per-VM. So the VMs can leverage it in any way they need (such as storing keys, deleting keys, do crypto operations, and more) without affecting EVE-OS. vTPM is required for some services (such as Azure IOT running on a VM) because they expect a full TPM to be available. Since EVE-OS relies on HW TPM, VMs and apps can’t be allowed to tamper with it, so a fully virtual TPM 2.0 is available, but the apps and VMs can't tell the difference. In the VM, it appears as a complete HW TPM, despite being software. 

If you are looking for communication between EVE-OS and VM that is limited to relaying curated services, such as with the Hardware TPM that is on the device, see VComLink: Asynchronous Communication Between EVE-OS and Virtual Machines instead. 

Prerequisites

  • This feature requires EVE-OS-OS version 14.5.0-LTS or greater.  
  • This feature requires TPM 2.0 or greater (note: TPM 1.2 is not supported).
  • This feature is currently available only in the KVM version of EVE-OS.
  • See Overview of the Trusted Platform Module (TPM) in EVE-OS-OS for more information about TPM in general. 

Architecture Overview

For each VM, EVE-OS automatically instantiates a dedicated SWTPM process, which emulates the TPM functionality. Communication between the QEMU virtual machine and the SWTPM emulator is established via a UDS. QEMU is configured to connect to this socket, and in doing so, it sets up a virtual TPM device inside the VM. From the VM’s perspective, this virtual TPM behaves identically to a physical TPM, allowing standard TPM-aware applications and operating systems to interact with it transparently.

To support operational flexibility, it is possible to disable the vTPM feature for specific VMs if it is not required, or if compatibility issues arise. By default, vTPM is enabled to maximize security out of the box.

Persistent TPM State Management

To maintain continuity across VM reboots and retain critical TPM assets such as keys, certificates, and NVRAM content, EVE-OS configures SWTPM to persist the TPM state. Each SWTPM instance saves and loads its state from a dedicated path on the host filesystem:

/persist/swtpm/tpm-state-[VM-UUID]

This path is uniquely tied to the VM’s UUID, ensuring isolation between tenants and consistency of TPM data for the lifetime of the VM. On subsequent reboots, the vTPM instance restores its previous state, enabling trusted workloads to function correctly without loss of TPM-backed secrets or configurations.

To ensure reliability and recoverability before every write, a backup of the TPM state is created. On VM startup, the vTPM service performs a health check on the primary TPM state directory. Based on the health check result, the vTPM service does one of the following: vTPM service operates normally, restores the backup (corrupted or unreadable primary state), or resets the TPM state (if both the primary and backup states are invalid or missing) ensuring that the VM can still boot. This mechanism ensures resilience against data corruption, unexpected crashes, or storage inconsistencies, enabling VMs to maintain secure operations across reboots while protecting critical TPM functionality.

vTPM Security Guarantees

EVE-OS’s vTPM service is designed not only to emulate TPM functionality but also to preserve the core security properties of hardware TPMs in a virtualized environment. The vTPM implementation in EVE-OS delivers strong security guarantees around data confidentiality and platform uniqueness, even in the presence of adversarial threats such as tampering, cloning, or replay attacks.

Specifically, EVE-OS’s vTPM service protects against the following critical threat scenarios:

Virtual TPM Data Confidentiality

To ensure that the sensitive contents of a virtual TPM, such as cryptographic keys, NVRAM content, and measurement logs remain confidential and protected against unauthorized access:

  • Each vTPM instance’s persistent state is encrypted using a 256-bit AES key.
  • This encryption key is securely stored inside the physical hardware TPM (HW TPM) on the device and is not accessible to any VM.
    Access to the AES key is gated by a PCR policy, which ties it to the measured boot integrity of the EVE-OS platform.
  • This policy is identical to the one used to secure the vault key, which protects other secrets on the system.

As a result, any tampering with the EVE-OS software stack, such as persistent malware injection, booting of unauthorized software, or unauthorized updates will alter the platform's measured PCR values. This change invalidates the PCR policy, preventing decryption of the vTPM state. When this occurs, EVE-OS withholds access to the vTPM, and the affected VM or container will fail to retrieve its trusted environment, serving as a reliable signal of compromise or system tampering.

Virtual TPM Uniqueness and Cloning Detection

To prevent cloning of virtual TPM identities across systems, and to ensure that each vTPM instance can be cryptographically linked to the unique physical device it was created on, EVE-OS implements endorsement identity binding using the hardware TPM:

  • Each vTPM generates a unique Endorsement Key (EK), which serves as its persistent identity.
  • This EK is then signed by a non-exportable Attestation Key (AK) stored securely inside the HW TPM.
  • The AIK is generated and certified as part of a zero-trust attestation process, ensuring that:
    • The AK itself is bound to the hardware TPM.
    • It cannot be extracted, copied, or forged outside the originating device.

EVE-OS leverages this chain of trust to allow remote parties (e.g., control planes, security auditors, or trusted verifiers) to verify the origin and integrity of a vTPM through cryptographic attestation. This process validates that:

  • The EK belongs to a specific vTPM instance.
  • The vTPM was instantiated on hardware that meets EVE-OS’s security policies.
  • The platform has not been cloned or tampered with.

Through this design, EVE-OS’s vTPM implementation enables device-bound identity and remote verification of platform authenticity, key features in zero-trust architectures and supply chain integrity frameworks. For more technical information refer to EVE-OS documents on vTPM.

Examples

VTPM and Windows 11 with BitLocker

To validate the functionality and compatibility of EVE-OS’s vTPM implementation, the following example is a real-world use case: running an unmodified version of Windows 11 as a virtual machine (VM) on EVE-OS and enabling BitLocker full disk encryption, both of which rely on Trusted Platform Module (TPM) 2.0 support.

Key Capabilities Demonstrated

  • Windows 11:
    Windows 11 enforces TPM 2.0 as a mandatory requirement for installation. By providing a standards-compliant virtual TPM device to the VM via SWTPM + QEMU integration, EVE-OS satisfies this requirement without any need to modify the Windows installation media or registry settings.

  • BitLocker Enablement:
    BitLocker Drive Encryption can be activated within the guest OS. BitLocker automatically detects the presence of a valid TPM 2.0 device and uses it to store disk encryption keys securely. 

vTPM and Azure IoT Service 

Using the vTPM, you can use the TPM based Device Provisioning service from Azure Portal. The following example walks you through an Individual Enrollment setup based on Ubuntu 22.04 and Azure IoT Edge 1.5.x .

Create TPM Keys

In your Ubuntu terminal, start by creating the necessary keys in the TPM. The two required keys are the Endorsement Key (EK) and the Storage Root Key (SRK). The default configuration expects to find them in TPM indexes 0x81010001 and 0x81000001, respectively. If a different index is used, it must be set by changing auth_key_index in the IoT Edge configuration file.

sudo apt-get update
sudo apt-get install -y tpm2-tools
# Create the EK and SRK
tpm2_createek -c 0x81010001 -G rsa -u ek.pub
tpm2_createprimary -Q -C o -c srk.ctx  /dev/null
tpm2_evictcontrol -c srk.ctx 0x81000001  /dev/null
tpm2_flushcontext -t  /dev/null

Configure Azure Portal

To provision a device using TPM, set up the necessary configuration in the Azure Portal. In your Ubuntu terminal, create an individual enrollment using the TPM EK and EK ID from the host:

# This outputs the EK
base64 -w0 ek.pub
# This outputs the ID
sha256sum -b ek.pub | cut -d' ' -f1 | sed -e 's/[^[:alnum:]]//g'
  1. Copy the EK and ID from the terminal. 
  2. Navigate to the Azure IoT Hub Device Provisioning Service (DPS) -> Manage enrollments -> Individual enrollments. 
  3. Click on Add individual enrollment. 
  4. Under the Registration + provisioning, set the Attestation mechanism to Trusted Platform Module (TPM). 
  5. Paste the EK value you copied to the Endorsement key field and ID to the Registration ID field.
  6. Make sure Enable this enrollment is checked and click on Review + create.

Install Azure IoT Edge Service

Back on the VM in the Ubuntu terminal, install Azure Iot Edge service:

# install microsoft repository
wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
# install pre-requisites
sudo apt-get update
sudo apt-get install -y moby-engine
sudo apt-get install -y aziot-edge

Configure Azure IoT Edge Service

After a successful installation, configure the Azure IoT Edge service. 

  1. You need a Registration ID, which is the same as the ID from when you configured the Azure Portal.
  2. You also need the ID Scope. This can be obtained from the Azure Portal: 
    1. Navigate to the Azure IoT Hub Device Provisioning Service (DPS).
    2. Under the Overview section, you will find the ID Scope, which is in the format 0ab1234C5D6. 
    3. After creating the config, apply it in your Ubuntu terminal and wait for it to take effect:
      config.toml cat <><-eof dps="DPS" provisioning="provisioning" with="with" tpm="TPM" source="dps" global_endpoint="https://global.azure-devices-provisioning.net" id_scope="!!!ID SCOPE GOES HERE!!!" method="tpm" registration_id="!!!ID GOES HERE!!!" eof="EOF" sudo="sudo" cp="cp" etc="etc" aziot="aziot" iotedge="iotedge" config="config" apply="apply"></-eof></>
    4. After a few seconds, execute the following command:
      sudo iotedge system status
      If successful, the output displays that all services are running.

Next Steps

After using vTPM in your application, you might be interested in the following article: 

Was this article helpful?
0 out of 0 found this helpful