Virtual Trusted Platform Module

Virtual TPM Research

As part of our research effort to add security to virtualizeable platforms, we are investigating how the Trusted Platform Module (TPM) can be used on systems where multiple Operating Systems are running concurrently. TPMs that are currently being built into newer systems provide singular instances of features such as: endorsement- and storage root key pairs, TPM owner, one set of Platform Configuration Registers and other singletons, with existing TPM-based security architectures having been built around these features. It is obvious that a TPM is not a device that was designed to be accessed by multiple systems at the same time. Therefore, we extended the current TPM V1.2 command set with virtual TPM management commands that allow us to create and delete instances of TPMs, depending on the current configuration requirements of the platform. In our model, each created instance of a TPM holds an association with a virtual machine (VM) throughout its lifetime on the platform.

As modern hypervisors also allow for the migration of Operating System VMs from one physical machine to another, a virtual TPM implementation must support migration of TPM state. Our proposed extensions to the TPM command set support this feature in such a way that the complete state of the TPM is secured throughout the transition, based on migrateable storage keys that are shared between the involved systems.

Our extended command set can be downloaded here. It's written in the style of the TPM specification and should currently be regarded as an IBM extension to the command set.

Virtual TPM for Xen

Our initial implementation of virtual TPMs was done in support of the security architecture of the Xen hypervisor. We implemented a TPM front- and backend driver through which all guest VMs can transpartently communicate with a virtual TPM-hosting VM where our own implementation of an extended V1.2 TPM resides. The virtual TPMs are managed through the new TPM commands which are sent from the privileged VM where all other VMs are started and stopped and VM migration is initiated. Software running in any Xen domain remains unaware of the fact that it is communicating with a software implementation of a TPM. Due to this transparent TPM usage model, software that has previously been written to work with a hardware TPM will simply continue to work.

High Assurance / Server Class Virtual TPMs

On high-end or mission critical systems where the highest degree of security is required due to the extreme sensitivity of the operations being performed, physically secure subsystems -- such as the tamper-sensing and responding IBM PCI-X Cryptographic Coprocessor (PCIXCC)-- are ideally suited for hosting virtual TPM functionality. The built-in tamper sensitivity of such subsystems makes it impossible for intruders to access sensitive data (e.g., private keys) from the device even if they have physical access. These subsystems also possess the necessary computational horsepower to efficiently run multiple virtual TPM instances at the same time. They typically inlcude hardware acceleration capabilities for cryptographic operations such as RSA key generation, encryption and decryption, which tremendously speeds up these time consuming operations. A virtual TPM architecture for the Xen hypervisor platform can be seen below, inlcuding an IBM PCIXCC subsystem running our virtual TPM implementation.

In Figure 1, the TPM that is typically available through the system's motherboard has effectively been replaced by as more powerful virtual TPM running on PCIXCC. We introduce a DOM-TPM in this architecture, a VM who's only purpose is to proxy for the PCIXCC virtual TPM and make TPM instances available to all other VMs running on the system. The DOM-TPM is assumed to be started first on this system, even before the privileged VM domain 0. All other VMs are depicted as user domains or dom U. The association between domains and TPM instances in this architecture is fixed only for the TPM domain and domain 0. These two domains have dedicated TPM instances with which to communicate, all others are created when dom U's are created.

Figure 1 does not depict the only possible solution. In Figure 2 we show an architecture with software TPMs running on the TPM VM. The TPM domain itself is associated with the TPM system's physical TPM. Again it is assumed that the TPM-DOM is started first on this system.