vTPM: Virtualizing the Trusted Platform Module

Stefan Berger Ramón Cáceres Kenneth A. Goldman

Ronald Perez Reiner Sailer Leendert van Doorn
{stefanb, caceres, kgoldman, ronpz, sailer, leendert}@us.ibm.com
IBM T. J. Watson Research Center
Hawthorne, NY 10532 USA

Abstract an investment bank to maintain a strict separation be-

tween its market analysis and security underwriting de-
We present the design and implementation of a sys-
partments, including their respective information pro-
tem that enables trusted computing for an unlimited num-
cessing facilities. Similarly, commercial interests may
ber of virtual machines on a single hardware platform.
dictate that the web sites of competing businesses not
To this end, we virtualized the Trusted Platform Module
have access to each other’s data. In addition, concerns
(TPM). As a result, the TPM’s secure storage and crypto-
about malicious software subverting normal operations
graphic functions are available to operating systems and
become specially acute in these shared hardware envi-
applications running in virtual machines. Our new facil-
ronments. For example, a remote client of a medical ser-
ity supports higher-level services for establishing trust in
vices site would like to determine that the server is not
virtualized environments, for example remote attestation
running corrupted software that will expose private infor-
of software integrity.
mation to a third party or return wrong medical informa-
We implemented the full TPM specification in soft-
tion. The increasing use of virtualization thus gives rise
ware and added functions to create and destroy virtual
to stringent security requirements in the areas of software
TPM instances. We integrated our software TPM into
integrity and workload isolation.
a hypervisor environment to make TPM functions avail-
The combination of a hardware-based root of trust
able to virtual machines. Our virtual TPM supports sus-
such as the Trusted Platform Module (TPM) [23],
pend and resume operations, as well as migration of a
and a virtual machine-based system such as Xen [4],
virtual TPM instance with its respective virtual machine
VMware [26], or PHYP [14], is exceedingly well suited
across platforms. We present four designs for certificate
to satisfying these security requirements. Virtual ma-
chains to link the virtual TPM to a hardware TPM, with
chine monitors, or hypervisors, are naturally good at iso-
security vs. efficiency trade-offs based on threat models.
lating workloads from each other because they mediate
Finally, we demonstrate a working system by layering an
all access to physical resources by virtual machines. A
existing integrity measurement application on top of our
hardware root of trust is resistant to software attacks and
virtual TPM facility.
provides a basis for reasoning about the integrity of all
software running on a platform, from the hypervisor it-
1 Introduction self to all operating systems and applications running in-
side virtual machines.
Hardware virtualization has enjoyed a rapid resurgence In particular, the TPM enables remote attestation by
in recent years as a way to reduce the total cost of owner- digitally signing cryptographic hashes of software com-
ship of computer systems [5]. This resurgence is spe- ponents. In this context, attestation means to affirm that
cially apparent in corporate data centers such as web some software or hardware is genuine or correct. TPM
hosting centers, where sharing each hardware platform chips are widely deployed on laptop and desktop PCs,
among multiple software workloads leads to improved and are becoming increasingly available on server-class
utilization and reduced operating expenses. machines such as the IBM eServer x366 [12].
However, along with these cost benefits come added Virtualizing the TPM is necessary to make its capabil-
security concerns. Workloads that share the same plat- ities available to all virtual machines running on a plat-
form must often be kept separate for a multitude of rea- form. Each virtual machine with need of TPM function-
sons. For example, government regulations may require ality should be made to feel that it has access to its own

USENIX Association Security ’06: 15th USENIX Security Symposium 305

 private TPM, even though there may be many more vir- co-processors. Virtualizing such devices presents similar
tual machines than physical TPMs on the system (typi- challenges to those outlined above for TPMs.
cally there is a single hardware TPM per platform). It is The rest of this paper is organized as follows. Sec-
thus necessary to create multiple virtual TPM instances, tion 2 introduces background concepts useful for under-
each of which faithfully emulates the functions of a hard- standing the ensuing material. Section 3 presents the re-
ware TPM. quirements on a virtual TPM facility. Sections 4, 5, and
However, virtualizing the TPM presents difficult chal- 6 respectively describe the design, the implementation,
lenges because of the need to preserve its security prop- and a sample application of our vTPM facility. Section 7
erties. The difficulty lies not in providing the low-level discusses open issues, Section 8 covers related work, and
TPM command set, but in properly supporting higher- Section 9 concludes the paper.
level security concepts such as trust establishment. In
particular, it is necessary to extend the chain of trust from
the physical TPM to each virtual TPM via careful man-
2 Background
agement of signing keys and certificates. As a result,
In this section we give some background on the two
some application and operating system software that re-
technologies that are basic to understanding this paper:
lies on TPM functionality needs to be made aware of se-
the Trusted Platform Module (TPM) and the Virtual Ma-
mantic differences between virtual and physical TPMs,
chine Monitor (VMM).
so that certificate chains can be correctly built and evalu-
ated, and trust chains correctly established and followed.
An additional challenge is the need to support migra- 2.1 The Trusted Platform Module
tion of a virtual TPM instance between hardware plat-
The TPM is a security specification defined by the
forms when its associated virtual machine migrates. The
Trusted Computing Group [23]. Its implementation is
ability to suspend, migrate, and resume virtual machines
available as a chip that is physically attached to a plat-
is an important benefit of hardware virtualization. For the
form’s motherboard and controlled by software running
virtual TPM, migration requires protecting the secrecy
on the system using well-defined commands [11]. It pro-
and integrity of data stored in a virtual TPM instance dur-
vides cryptographic operations such as asymmetric key
ing the transfer between platforms, and re-establishing
generation, decryption, encryption, signing and migra-
the chain of trust on the new platform.
tion of keys between TPMs, as well as random number
This paper presents the design and implementation of
generation and hashing. It also provides secure storage
a virtual TPM (vTPM) facility. This work makes the fol-
for small amounts of information such as cryptographic
lowing contributions:
keys. Because the TPM is implemented in hardware and
• It identifies the requirements for a vTPM, including presents a carefully designed interface, it is resistant to
those related to migration between hardware plat- software attacks [3].
forms. Of particular interest is the Platform Configuration
Register (PCR) extension operation. PCRs are initialized
• It introduces a vTPM architecture that meets these at power up and can only be modified by reset or ex-
requirements, including extensions to the standard tension. The PCR extension function cryptographically
TPM command set and a protocol for secure vTPM updates a PCR using the following function:
migration.
• It describes our implementation of this vTPM ar- Extend(P CRN , value) = SHA1(P CRN ||value)
chitecture on Xen, including support for remote
integrity attestation of the complete system: boot The cryptographic properties of the extension opera-
loader, hypervisor, vTPM subsystem, operating sys- tion state that it is infeasible to reach a certain PCR state
tems, and applications. through two different sequences of values. SHA1 refers
to the Secure Hash Algorithm standard [19]. The || oper-
• It discusses four alternative schemes for certifying ation represents a concatenation of two byte arrays.
a vTPM’s security credentials, including the trade- PCR extensions are used during the platform boot pro-
offs involved in choosing between them. cess and start within early-executed code in the Basic In-
put/Output System (BIOS) that is referred to as the Core
• It demonstrates that our vTPM facility works by
Root of Trust for Measurement (CRTM) [24]. Hash val-
running an existing TPM application inside Xen vir-
ues of byte arrays representing code or configuration data
tual machines.
are calculated, or measured, and PCRs are extended with
This work can also serve as a template for how to these values. A final PCR value represents this accu-
virtualize other security-related devices such as secure mulation of a unique sequence of measurements. Along

306 Security ’06: 15th USENIX Security Symposium USENIX Association

 with a sequential list of individual measurements and ap- Depending on the fidelity of the emulation of a physi-
plications’ names and information about measured con- cal machine, it may be necessary to make modifications
figuration data, PCR values are used to decide whether a to an operating system for it to run on a VMM. If modifi-
system can be trusted. A transitive trust model is imple- cations are required the environment is said to be par-
mented that hands off the measuring from the BIOS [24] avirtualized, otherwise the VMM is said to provide a
to the boot loader [18] and finally to the operating sys- fully virtualized environment.
tem. Procedures have also been developed for operating
systems to measure launched applications, scripts and
configuration files [21].
3 Requirements
Besides the aforementioned cryptographic operations A virtual TPM should provide TPM services to each vir-
it is possible to seal information against the state of the tual machine running on top of a hypervisor. The re-
TPM, where its state is represented through a subset of quirements discussed in this section can be summarized
PCRs. Sealed information is encrypted with a public key as follows:
and can only be decrypted if the selected PCRs are in the
exact state that they were at the time of sealing. 1. A virtual TPM must provide the same usage model
There are a number of signing keys associated with a and TPM command set to an operating system run-
TPM. Each TPM can be identified by a unique built-in ning inside a virtual machine as a hardware TPM
key, the Endorsement Key (EK), which stands for the va- provides to an operating system running directly on
lidity of the TPM [10]. The device manufacturer should a hardware platform.
provide a certificate for the EK. Related to the EK are At-
testation Identity Keys (AIKs). An AIK is created by the 2. A strong association between a virtual machine and
TPM and linked to the local platform through a certifi- its virtual TPM must be maintained across the life
cate for that AIK. This certificate is created and signed cycle of virtual machines. This includes migration
by a certificate authority (CA). In particular, a privacy of virtual machines together with their associated
CA allows a platform to present different AIKs to dif- virtual TPMs from one physical machine to another.
ferent remote parties, so that it is impossible for these
parties to determine that the AIKs are coming from the 3. A strong association between the virtual TPM and
same platform. AIKs are primarily used during quote its underlying trusted computing base (TCB) must
operations to provide a signature over a subset of PCRs be maintained.
as well as a 160-bit nonce. Quotes are delivered to re- 4. A virtual TPM must be clearly distinguishable from
mote parties to enable them to verify properties of the a hardware TPM because of the different security
platform. properties of the two types of TPM.

As much software as possible that was originally writ-

2.2 Virtual Machine Monitors
ten to interact with a hardware TPM should run unmodi-
VMMs [8], also known as hypervisors, allow multiple fied with a virtual TPM. It should remain unaware of the
operating systems to simultaneously run on one machine. fact that it is communicating with a software implemen-
A VMM is a software layer underneath the operating sys- tation of a TPM in a virtual environment. An example
tem that meets two basic requirements: of software that should remain unmodified is the TCG
Software Stack (TSS) [25] that issues low-level TPM re-
• It provides a Virtual Machine (VM) abstraction that quests and receives low-level TPM responses on behalf
models and emulates a physical machine. of higher-level applications.
The requirement that software be unaware that it is us-
• It provides isolation between virtual machines. ing emulated devices is basic to virtualization and has al-
ready been achieved for a wide range of devices found
The basic responsibility of a VMM is to provide CPU in modern computers. Open-source software such as
time, memory and interrupts to each VM. It needs to set QEmu [1], as well as proprietary products like VMWare
up the page tables and memory management unit of the Workstation [26], have been successful in emulating
CPU such that each VM runs in its own isolated sand- machine environments for personal computers. They
box. The hypervisor itself remains in full control over provide transparent emulation for timers, interrupt con-
the resources given to a VM. During the boot process of trollers, the PCI bus, and devices on that bus.
a VMM, often an initial virtual machine is started that However, as a security device the TPM presents new
serves as a management system for starting further vir- and challenging issues that preclude fully transparent vir-
tual machines. tualization. One challenge arises because modern virtual

USENIX Association Security ’06: 15th USENIX Security Symposium 307

 machine monitors provide suspend and resume capabil- Interestingly, as will become clear during our exposition,
ities. This enables a user to freeze the state of an oper- a software TPM can be as secure as a hardware TPM .
ating system and resume it at a later point, possibly on a In summary, virtualizing the TPM is not achieved by
different physical machine. A virtual TPM implementa- merely providing TPM functionality to a virtual machine
tion must support the suspension and resumption of TPM through device emulation. A virtual TPM must also pro-
state, including its migration to another system platform. vide the means for outside parties to establish trust in a
During normal operation of the virtual TPM, as well as larger software environment than is the case with hard-
during and after these more sophisticated lifecycle oper- ware TPMs. It must also enable reestablishment of trust
ations, the association between the virtual TPM and its after a virtual machine is migrated to another platform.
virtual machine must be securely maintained such that These requirements for providing virtual TPM function-
secrets held inside the virtual TPM cannot be accessed ality will be used as a guideline for the following sections
by unauthorized parties or other virtual machines. on architecture and implementation, as well as our final
Another challenge is to maintain the association of a discussion.
virtual TPM to its underlying trusted computing base.
PC manufacturers may issue a certificate for the TPM
endorsement key (EK) that states that the TPM hardware 4 Architecture
is tightly coupled to the motherboard and correctly em-
bedded into the BIOS for management. A challenger, We designed a virtual TPM facility in software that pro-
validating a digital signature from such a TPM, can thus vides TPM functionality to virtual machines. This sec-
determine the correct embedding and operation of the re- tion first describes the structure of the vTPM and the
mote TPM chip and establish the environmental security overall system design. It proceeds with describing our
properties of the hardware TPM. In a virtualized environ- extensions to the TPM 1.2 command set to support vir-
ment, each operating system communicates with a vir- tualization of the TPM. Then it introduces our protocol
tual TPM that may be running as a user-space process for virtual TPM migration and concludes with consider-
inside its own virtual machine. The association of such a ing security aspects of the vTPM platforms and run-time
TPM with its underlying software and hardware platform environments involved in the migration.
is not only loose but also subject to change, e.g., dur- Figure 1 illustrates the vTPM building blocks and their
ing migration. Tracking this changing trusted computing relationship. The overall vTPM facility is composed
base forms one major challenge in virtualizing a hard- of a vTPM manager and a number of vTPM instances.
ware TPM. Maintaining the ability of the virtual TPM Each vTPM instance implements the full TCG TPM 1.2
to attest to its mutable trusted computing base forms an- specification [11]. Each virtual machine that needs
other major challenge. It is necessary to enable remote TPM functionality is assigned its own vTPM instance.
parties that have established trust in the initial environ- The vTPM manager performs functions such as creating
ment to also establish trust in the vTPM environment at vTPM instances and multiplexing requests from virtual
a later point in time. machines to their associated vTPM instances.
For example, the strong binding of TPM credentials Virtual machines communicate with the vTPM using a
to those of the hardware platform is important to chal- split device-driver model where a client-side driver runs
lenging parties during remote attestation. The challenger inside each virtual machine that wants to access a virtual
must follow the trust chain from the target platform’s TPM instance. The server-side driver runs in the virtual
hardware TPM through a virtual TPM and into the run- machine hosting the vTPM.
time environment of the associated virtual machine.
Further, since software TPM implementations do not 4.1 Associating vTPM Instances with
usually offer the same security properties as hardware their Virtual Machines
TPM implementations, the different types of TPMs
should be distinguishable for remote parties relying on As shown in Figure 1, multiple virtual machines send
a TPM’s correct functioning. A virtualized TPM’s cer- TPM commands to the virtual TPM facility. A diffi-
tificates can be used to give an interested party enough culty arises because it cannot be determined from the
information to conclude relevant properties of the com- content of a TPM command from which virtual machine
plete software, firmware, and hardware environment on the command originated, and thereby to which virtual
which this TPM’s correct operation depends. In practice, TPM instance the command should be delivered. Our
this can be realized by the certificate issuer embedding solution is for the server-side driver to prepend a 4-byte
special attributes into the certificate, and the interested vTPM instance identifier to each packet carrying a TPM
party validating the certificate and translating these at- command. This number identifies the vTPM instance to
tributes during remote attestation of security properties. which a virtual machine can send commands. The in-

308 Security ’06: 15th USENIX Security Symposium USENIX Association

 Application

Application

Application
Application
vTPM Instance … …

vTPM Instance
…
… … Proxy

Application

Application

Application
Application
…
vTPM Manager VM VM VM
Secure Co -
processor Driver
TPM Driver TPM Driver

…
VM VM VM Hypervisor
Server-side Client-side Client-side
TPM Driver TPM Driver TPM Driver

Hypervisor vTPM Manager

vTPM Instance

vTPM Instance
Hardware …
Request/Response Path Secure
TPM Coprocessor

Figure 1: vTPM Architecture

Figure 2: vTPM running inside a Secure Co-processor.

stance number is assigned by the virtual TPM when the 4.2 The Root vTPM Instance
vTPM instance is created.
Our design was driven by the goal of having a virtual
Every VM must associate with a unique vTPM in- TPM implementation that can be run on an external co-
stance. The vTPM instance number is prepended on the processor card as well as executed as a process running
server side so that virtual machines cannot forge packets within a virtual machine. We designed the virtual TPM
and try to get access to a vTPM instance that is not asso- such that the interaction of applications with either im-
ciated with them. A command’s originating virtual ma- plementation would be the same. New commands and
chine can be determined from the unique interrupt num- APIs that we introduce should work the same for both
ber raised by each client-side driver. implementations. Considerations regarding reducing the
trusted computing base of the environment hosting the
Since a TPM holds unique persistent state with se- virtual TPM did not directly influence the design, al-
cret information such as keys, it is necessary that a vir- though the intention is to have a virtual machine that is
tual machine be associated with its virtual TPM instance dedicated exclusively to providing virtual TPM function-
throughout the lifetime of the virtual machine. To keep ality.
this association over time, we maintain a list of virtual- Further, modern hypervisors support advanced fea-
machine-to-virtual-TPM-instance associations. tures such as virtual machine hibernation and migration
Figure 1 shows our architecture where TPM function- from one physical platform to another. The straightfor-
ality for all VMs is provided by a virtual TPM running in ward approach to supporting such features is to hibernate
the management VM. TPM functionality for this VM is and migrate a virtual TPM instance along with its as-
provided by the hardware TPM, and is used in the same sociated virtual machine, thus preserving existing mea-
way as in a system without a hypervisor where the oper- surements and avoiding the complexity of remeasuring
ating system owns the hardware TPM. running software in a new environment and accounting
for the loss of measurements representing software that
A variation of this architecture is shown in Figure 2 was loaded but is no longer running. However, the virtual
where virtual TPM functionality is provided by an ex- TPM migration process must offer more security guaran-
ternal secure coprocessor card that provides maximum tees for the virtual TPM instance state than is usually pro-
security for sensitive data, such as private keys, through vided for an operating system image that is being trans-
a tamper-responsive environment. Here the first VM is ferred. The virtual TPM migration process must guaran-
the owner of this hardware and uses one virtual TPM tee that any vTPM instance state in transit is not subject
instance for its own purposes. All other instances are to modification, duplication, or other compromise.
reserved for usage by other virtual machines. A proxy This set of requirements led us to design a virtual
process forwards TPM messages between the server-side TPM as a TPM capable of spawning new vTPM child
driver and the external card. instances. Having an always available vTPM root in-

USENIX Association Security ’06: 15th USENIX Security Symposium 309

 stance provides an entity that has cryptographic capabil- encryption we mitigate the cost of not directly coupling
ities for generating asymmetric keys, handling encryp- the key hierarchy of a virtual TPM instance to that of the
tion and decryption of data, and migration of asymmet- hardware TPM.
ric keys between virtual TPMs. The ability to handle
keys and encrypt data with them enables us to encrypt 4.4 Extended Command Set
the state of a vTPM instance when migrating it. The
virtual TPM’s ability to migrate keys to another virtual In order to realize our design of a virtual TPM, we ex-
TPM makes it possible to exchange encrypted data be- tended the existing TPM 1.2 command set with addi-
tween virtual TPMs. tional commands in the following categories.
Since the ability to spawn – and generally to manage
– new virtual TPM instances is a fairly powerful feature, • Virtual TPM Management commands
this capability should only be accessible to the owner of CreateInstance
the root instance. The administrator of the initial vir- DeleteInstance
tual machine, who has the ability to start new virtual ma-
chines, would own this capability. We designed all TPM SetupInstance
command extensions to require owner authorization in • Virtual TPM Migration commands
the same way as some of the existing TPM commands
do. In effect, the TPM verifies that such command blocks GetInstanceKey / SetInstanceKey
are authorized with the owner’s password. GetInstanceData / SetInstanceData
We introduced the concept of a privileged vTPM in-
stance. A privileged vTPM instance can spawn and man- • Virtual TPM Utility commands
age child vTPM instances. Since being a privileged in- TransportInstance
stance is an inheritable property, an instance may pass LockInstance / UnlockInstance
this privilege on to its own children. Using this inher-
itance scheme, we can support building a hierarchy of ReportEnvironment
vTPMs in parallel to a hierarchy of virtual machines The Virtual TPM Management commands manage the
where each virtual machine is given the privilege of start- life-cycle of vTPM instances and provide functions for
ing other virtual machines. their creation and deletion. The SetupInstance command
prepares a vTPM instance for immediate usage by the
4.3 Independent Key Hierarchies corresponding virtual machine and extends PCRs with
measurements of the operating system kernel image and
The TPM specification demands that a TPM establish a other files involved in the boot process. This command
storage root key (SRK) as the root key for its key hi- is used for virtual machines that boot without the support
erarchy. Every key that is generated has its private key of a TPM-enabled BIOS and boot loader, which would
encrypted by its parent key and thus creates a chain to the otherwise initialize the TPM and extend the TPM PCRs
SRK. In our virtual TPM we create an independent key with appropriate measurements.
hierarchy per vTPM instance and therefore unlink ev- The Virtual TPM Migration commands support vTPM
ery vTPM instance from the key hierarchy of a possible instance migration. We implemented a secure virtual
hardware TPM. This has the advantage that key genera- TPM instance migration protocol that can securely pack-
tion is much faster since we do not need to rely on the age the state of a virtual TPM instance and migrate it to
hardware TPM for this. It also simplifies vTPM instance a destination platform. Our extended commands enforce
migration. that the content of a vTPM instance is protected and that
Similarly, we generate an endorsement key (EK) per a vTPM instance can only be migrated to one target plat-
vTPM instance. This enables TPM commands that rely form destination, thus preventing duplication of a vTPM
on decrypting information with the private part of the EK instance and ensuring that a virtual TPM is resumed in
to also work after a virtual TPM has migrated. association with its VM.
If the SRK, EK or any other persistent data of vir- One of the Virtual TPM Utility commands offers a
tual TPMs are written into persistent memory, they are function for routing a limited subset of TPM commands
encrypted with a symmetric key rooted in the hardware from a vTPM parent instance to one of its child instances.
TPM by for example sealing it to the state of the hard- This command works similar to IP tunneling, where an
ware TPM’s PCRs during machine boot, or by encrypt- embedded packet is unwrapped and then routed to its
ing it using a password-protected key. We therefore earn destination. Embedding a command is useful since the
the flexibility of managing each virtual TPM’s key hier- association of a virtual machine to a privileged virtual
archy independently. In addition, by using file-level data TPM does not allow direct communication with a child

310 Security ’06: 15th USENIX Security Symposium USENIX Association

 vTPM instance. For example, we use this command to sible Denial of Service (DoS) attacks where untrusted
create an endorsement key for a virtual TPM after the software involved in migration alters or omits state, op-
child instance has been created and before it is used by its eration of the vTPM instance can only resume if the cal-
associated virtual machine. Other functions in the util- culated migration digest matches the transmitted one.
ity category include locking a vTPM instance to keep its
state from being altered while its state is serialized for Support for Live Migration Modern virtual machine
migration, and unlocking it to make it available for use monitors support live migration [2] of virtual machines
after migration has completed. from one platform to another. Live migration tries to
shorten downtimes by replicating the running system’s
4.5 Virtual TPM Migration image on a destination machine and switching execution
to that machine once all pages have been replicated. Live
Since vTPM instance migration is one of the most im- migration can be supported with our virtual TPM migra-
portant features that we enabled through the command tion protocol, but will in the worst case extend the down-
set extension, we explain how it works in more detail. time of the migrated system by the time it takes to com-
The virtual TPM migration procedure is depicted in Fig- plete an outstanding TPM operation, transfer the vTPM
ure 3. state, and recreate it on the destination platform.
We enabled vTPM instance migration using asym-
metric and symmetric keys to encrypt and package TPM
state on the source virtual TPM and decrypt the state
4.6 Linking a vTPM to its TCB
on the destination virtual TPM. We based vTPM migra- Both architectures we introduced in Section 4.1 – a
tion on migrateable TPM storage keys, a procedure that vTPM hosted in a virtual machine or in a secure copro-
is supported by the existing TPM standard. cessor – provide TPM functionality to virtual machines.
The first step in our vTPM instance migration proto- It is therefore possible to enable an integrity measure-
col is to create an empty destination vTPM instance for ment facility [13] in each virtual machine and record ap-
the purpose of migrating state. The destination virtual plication measurements in the virtual TPM. However, it
TPM generates and exports a unique identifier (Nonce). is necessary that a challenger can establish trust in an en-
The source vTPM is locked to the same Nonce. All TPM vironment which consists of more than the content of the
state is exported with the Nonce, and the Nonce is vali- virtual machine. The reason is that each operating sys-
dated before import. This enforces uniqueness of the vir- tem is running inside a virtual machine that is fully con-
tual TPM and prevents TPM state from being migrated trolled by the hypervisor. Furthermore, a virtual TPM
to multiple destinations. can be running as a process inside a VM whose own
The next step involves marshaling the encrypted state execution environment must be trusted. Therefore it is
of the source vTPM. This step is initiated by sending to necessary that attestation support within the virtualized
the source vTPM a command to create a symmetric key. environment not only allows a challenger to learn about
The key is encrypted with a parent TPM instance stor- measurements inside the virtual machine, but also about
age key. The blobs of state encrypted with a symmetric those of the environment that provides virtual TPM func-
key are then retrieved from the source vTPM. This in- tionality. In addition, these measurements must include
cludes NVRAM areas, keys, authorization and transport the hypervisor and the entire boot process.
sessions, delegation rows, counters, owner evict keys, Our architecture therefore merges the virtual TPM-
and permanent flags and data. While the state is col- hosting environment with that of the virtual machine by
lected, the TPM instance is locked so the state cannot be providing two different views of PCR registers. Figure 4
changed by normal usage. After each piece of state infor- shows these two views. The lower set of PCR registers
mation has been serialized, an internal migration digest of a vTPM show the values of the hardware TPM and the
is updated with the data’s hash and the piece of state in- upper ones reflect the values specific to that vTPM. This
formation becomes inaccessible. The migration digest way, a challenger can see all relevant measurements. The
is embedded into the last piece of state information and providers of the measurements extended into the differ-
serves for validation on the target side. ent PCRs –BIOS, boot loader, and operating system– are
To recreate the state of the virtual TPM on the desti- denoted beside the PCRs. BIOS measurements include
nation platform, the storage key of the vTPM parent in- measurements of the boot stages and various hardware
stance (used to encrypt the symmetric key used to protect platform configurations. The boot loader measures, for
the vTPM instance state) must be migrated to the desti- example, the hypervisor and its configuration, the vir-
nation vTPM parent instance. After the decryption of the tual machine monitor operating system kernel, initrd, and
symmetric key, the migrating vTPM’s state is recreated configuration. Then the VMM takes over and measures
and the migration digest recalculated. To detect pos- the dynamically activated VMM environment, such as

USENIX Association Security ’06: 15th USENIX Security Symposium 311

 Migration Control Migration Control
Source Destination
Process On Process On
virtual TPM Source Platform Destination Platform virtual TPM

CreateInstance for Destination

of Migration
Transfer encrypted
LockInstance(Instance , Nonce)
Unique Identifier Returns Migration Unique
Identifier (Nonce)

GetInstanceKey(Instance )

Recv : Key
Package virtual TPM
Instance state

Recv : State data,

Migration Digest
DeleteInstance(Instance )

Transfer TPM SetInstanceKey(Instance,Key )

state

Unpackage virtual TPM

instance state

UnlockInstance(Instance,
Migration Digest)

Figure 3: Virtual TPM Migration Protocol

the vTPM manager, and other components on which the 5.1 Implementation for Xen
correct functioning of the virtual environment and the
Xen is a VMM for paravirtualized operating systems that
vTPM depends.
can also support full virtualization by exploiting emerg-
As previously mentioned, the certificate for a virtual
ing hardware support for virtualization. In Xen-speak,
TPM instance does not necessarily stand for the same
each virtual machine is referred to as a domain. Domain-
security guarantees as that of a hardware TPM. If a chal-
0 is the first instance of an OS that is started during sys-
lenger decides that the security guarantees of the virtual
tem boot. In Xen version 3.0, domain-0 owns and con-
TPM are not sufficient he can directly challenge the vir-
trols all hardware attached to the system. All other do-
tual machine owning the hardware TPM to verify the ba-
mains are user domains that receive access to the hard-
sic measurements including the one of the virtual TPM.
ware using frontend device drivers that connect to back-
Section 7.2 describes how certificates can be issued to
end device drivers in domain-0. Domain-0 effectively
mitigate this problem.
proxies access to hardware such as network cards or hard
drive partitions.
5 Implementation We have implemented the following components for
virtual TPM support under the Xen hypervisor:
In this section we present our implementation of virtual • Split device-driver pair for connecting domains to a
TPM support for the Xen hypervisor [27]. We expect that virtual TPM
an implementation for other virtualization environments
would be similar in the area of virtual TPM management, • Scripts to help connect virtual machines to virtual
but will differ in the particular management tools and TPM instances
device-driver structure.
We have implemented the two previously discussed • Virtual TPM management tools
solutions of a virtual TPM. One is a pure software so- • Virtual TPM-specific extensions to Xen’s manage-
lution targeted to run as a process in user space inside a ment tools (e.g., xend, xm)
dedicated virtual machine (Figure 1) and the other runs
on IBM’s PCI-X Cryptographic Coprocessor (PCIXCC) • Full TPM 1.2 implementation extended with our
card [15] (Figure 2). virtual TPM command set

312 Security ’06: 15th USENIX Security Symposium USENIX Association

 Hardware TPM Virtual TPM Instance

PCR[0] BIOS mapped PCR[0]

PCR[1] BIOS PCR[1]
PCR[2] BIOS PCR[2]
PCR[3] BIOS PCR[3]
Lower PCRs
PCR[4] BIOS PCR[4]
(read-only)
PCR[5] BIOS PCR[5]
PCR[6] BIOS PCR[6]
PCR[7] Bootloader PCR[7]
PCR[8] OS 1 IM PCR[8]
PCR[9] PCR[9] OS 2 IM
PCR[10] PCR[10]
PCR[11] measurement
PCR[11]
PCR[12] PCR[12] Upper PCRs
providers
(read/write)
PCR[13] PCR[13]
PCR[14] PCR[14]
PCR[15] PCR[15]

OS 1 IM: VMM Operating System Integrity Measurements

OS 2 IM: Guest Operating System Integrity Measurements

Figure 4: Mapping of Virtual TPM to Hardware TPM PCRs

We have extended the Xen hypervisor tools to sup- configuration errors, the final decision on which virtual
port virtual TPM devices. xm, the Xen Management TPM instance is given to a virtual machine is made in the
tool, parses the virtual machine configuration file and, hotplug scripts and depends on already existing entries in
if specified, recognizes that a virtual TPM instance must the associations table.
be associated with a virtual machine. xend, the Xen Dae-
mon, makes entries in the xenstore [22] directory that in-
kernel = “/boot/vmlinuz -2.6.12 -xen”
dicate in which domain the TPM backend is located. Us-
ing this information, the TPM frontend driver in the user ramdisk = “/boot/vmlinuz -2.6.12 -xen.img”
domain establishes a connection to the backend driver. memory = 256
During the connection phase, the backend driver triggers name = “ UserDomainWithTPM ”
the Linux hotplug daemon that then launches scripts for
vtpm = [‘backend=0, instance=1’]
connecting the virtual TPM instance to the domain.
Within our virtual TPM hotplug scripts, we need to
differentiate whether the virtual machine was just created Figure 5: Virtual Machine Configuration File with vTPM
or whether it resumed after suspension. In the former Option
case, we initialize the virtual TPM instance with a reset.
In the latter case, we restore the state of the TPM from We have implemented the Xen-specific frontend driver
the time when the virtual machine was suspended. Inside such that it plugs into the generic TPM device driver that
the scripts we also administer a table of virtual-machine- is already in the Linux kernel. Any application that wants
to-virtual-TPM-instance associations and create new vir- to use the TPM would communicate with it through the
tual TPM instances when no virtual TPM exists for a usual device, /dev/tpm0. The backend driver is a com-
started virtual machine. ponent that only exists in the virtualized environment.
Figure 5 shows an example of a virtual machine con- There we offer a new device, /dev/vtpm, through which
figuration file with the virtual TPM option enabled. The the virtual TPM implementation listens for requests.
attributes indicate in which domain the TPM backend Our driver pair implements devices that are connected
driver is located and which TPM instance is preferred to a Xen-specific bus for split device drivers, called xen-
to be associated with the virtual machine. To eliminate bus. The xenbus interacts with the drivers by invoking

USENIX Association Security ’06: 15th USENIX Security Symposium 313

 their callback functions and calls the backend driver for assurance are required, e.g., banking and finance.
initialization when a frontend has appeared. It also no- The code for the virtual TPM on the card differs only
tifies the frontend driver about the request to suspend or slightly from that which runs in a virtual machine. The
resume operation due to suspension or resumption of the main differences are that the vTPM on the card receives
user domain. its commands through a different transport interface, and
Suspension and resumption is an important issue for it uses built-in cryptographic hardware for acceleration
our TPM frontend driver implementation. The existing of vTPM operations. To use the card in the Xen envi-
TPM protocol assumes a reliable transport to the TPM ronment, a process in user space must forward requests
hardware, and that for every request that is sent a guar- between the TPM backend driver and the driver for the
anteed response will be returned. For the vTPM driver card. This is the task of the proxy in Figure 2.
implementation this means that we need to make sure Table 1 describes the properties that can be achieved
that the last outstanding response has been received by for TPM functionality based on the three implementation
the user domain before the operating system in that do- alternatives: hardware TPM, virtual TPM in a trusted vir-
main suspends. This avoids extension of the basic TPM tual machine, and virtual TPM in a secure coprocessor.
protocol through a more complicated sequence number-
based protocol to work around lost packets.
6 Sample Application
We use Xen’s existing shared memory mechanism
(grant tables [6]) to transfer data between front- and We ran an existing TPM application to show that our vir-
back-end driver. Initially a page is allocated and shared tual TPM implementation provides correct TPM func-
between the front and back ends. When data is to be tionality to virtual machines. As a sample application
transmitted they are copied into pages and an access we chose IBM’s open-source Integrity Measurement Ar-
grant to the pages is established for the peer domain. Us- chitecture (IMA) for the Linux operating system [13].
ing an event channel, an interrupt is raised in the peer IMA provides to a remote system verifiable evidence
domain which then starts reading the TPM request from of what software is running on a measured system. It
the page, prepends the 4-byte instance number to the re- maintains a list of hash values covering all executable
quest and sends it to the virtual TPM. content loaded into a system since startup, including ap-
The virtual TPM runs as a process in user space in plication binaries. It brings together measurements made
domain-0 and implements the command extensions we by the BIOS, boot loader and OS, and it offers an inter-
introduced in Section 4.4. For concurrent processing face to retrieve these hash values from a remote system.
of requests from multiple domains, it spawns multiple IMA returns its list of measurements as well as a quote
threads that wait for requests on /dev/vtpm and a local of current PCR values signed by the TPM. The signed
interface. Internal locking mechanisms prevent multiple quote from the TPM proves the integrity of the measure-
threads from accessing a single virtual TPM instance at ments. The remote system can then compare the mea-
the same time. Although a TPM driver implementation surements against known values to determine what soft-
in a user domain should not allow more than one unan- ware was loaded on the measured system.
swered TPM request to be processed by a single TPM, IMA was originally written to run in a non-virtualized
we cannot assume that every driver is written that way. environment, where the Linux kernel has direct access to
Therefore we implemented the locking mechanism as a a hardware TPM. As a test of our vTPM facility, we ran
defense against buggy TPM drivers. IMA in a Xen virtual machine with access to a vTPM
The virtual TPM management tools implement com- instance.
mand line tools for formatting and sending virtual TPM The complete attestation sequence in our virtualized
commands to the virtual TPM over its local interface. environment is as follows. The virtual TPM runs as a
Requests are built from parameters passed through the process in Xen’s management virtual machine, domain-
command line. We use these tools inside the hotplug 0. We boot the system using a trusted boot loader,
scripts for automatic management of virtual TPM in- Trusted GRUB [9, 18]. We measure the Xen hypervisor
stances. executable, the domain-0 kernel and initial RAM disk,
as well as the initial Xen access control policy [20], and
5.2 Implementation for the PCI-X Crypto- extend a PCR in the hardware TPM with these measure-
graphic Coprocessor ments. The resulting hardware PCR value thus attests
to the integrity of the vTPM’s trusted computing base
IBM’s PCIXCC secure coprocessor is a programmable (TCB), namely the hypervisor plus the management vir-
PCI-X card that offers tamper-responsive protection. It tual machine.
is ideally suited for providing TPM functionality in When a user virtual machine starts, we measure its
security-sensitive environments where higher levels of kernel image and initial RAM disk, and extend a PCR

314 Security ’06: 15th USENIX Security Symposium USENIX Association

 Implementation
Properties
Hardware TPM PCIXCC Trusted VM TPM
HW Tamper no protection responsive no protection
BIOS or software crypto protected
SW Tamper SW protected
protected (signed software)

tamper responsive
TPM TCB TPM chip, BIOS environment, signed vTPM VM, hypervisor
software
Platform-Binding physical (e.g., soldering) PCI-X bus logical (H/W TPM or BIOS)
BIOS or hypervisor
OS-Binding hypervisor hypervisor
(if VM-owned)
Support OS 1 n n
Cost in USD 1 > 1,000 0

Table 1: Comparison of TPM Implementations

in the virtual TPM with these measurements. This se- 7 Discussion and Future Work
quence of measurements is part of the setup process of
the vTPM instance (see Section 4.4). As the user vir- In section 3 we introduced the requirements that an ar-
tual machine continues to run, the IMA-enhanced kernel chitecture for enabling TPM support in a virtual environ-
in that virtual machine also extends a virtual PCR with ment must fulfill. So far we have presented solutions for
measurements of every application that is loaded. the first three items and described their implementations.
We will now revisit our initial requirements and compare
them against our implementation. We then discuss solu-
IMA attests to the integrity of both the vTPM TCB tions for the remaining items.
and the user virtual machine by returning PCR values
from both the hardware TPM and the virtual TPM. We
achieve this with our vTPM by projecting the lower 7.1 Requirements Revisited
PCRs of the hardware TPM (e.g., PCRs 0 through 8) to Unmodified TPM Usage Model We provide TPM
all virtual TPMs. This means that if a user VM reads support by emulating device functionality through a soft-
one of those PCRs, the vTPM facility actually fetches ware implementation. We designed and implemented an
the value from the hardware TPM. Extending hardware architecture for the Xen hypervisor that enables us to
PCRs from user VMs is therefore disabled since these connect each user domain to its own TPM instance. With
registers are logically owned by the management VM as our command set extensions we can create as many vir-
depicted in Figure 4. Upper PCRs are accessible by user tual TPM instances as needed. All existing TPM V 1.2
VMs as usual. commands are available to a user domain and the TPM
command format remains unchanged.
Therefore, we have the management VM extend the
lower PCRs with measurements of the vTPM TCB. We Strong Virtual Machine to Virtual TPM Association
have the user VM extend the upper PCRs with measure- We have shown a design that supports strong virtual ma-
ments of the user VM itself. IMA reports then com- chine to virtual TPM association. Components that en-
bine lower PCR values, higher PCR values, and the mea- force this need to be implemented in the backend driver
surement list from both the user VM and the manage- such that TPM packets can be routed to the appropriate
ment VM to provide a comprehensive view of the sys- domain. Also, a table of virtual machine to virtual TPM
tem. To relay the names of applications measured into instance must be maintained.
the hardware TPM, we implemented a small extension to We introduced new TPM commands for secure migra-
Integrity Measurement Architecture that retrieves this in- tion of TPM state between two virtual TPM implemen-
formation from the vTPM-hosting domain using the Re- tations. Our migration protocol guarantees TPM unique-
portEnvironment command. Other aspects of IMA were ness and prevents attacks on the TPM state information
left unmodified. such as alterations to or omission of pieces of state infor-

USENIX Association Security ’06: 15th USENIX Security Symposium 315

 mation. We based virtual TPM migration on TPM key privacyCA sign
migration. Signing Key
AIK’ Signing/Identity Key
In our design we assume the trustworthiness of the
show
destination TPM implementation and the uniqueness of create
migration identifiers (which can all be verified). HMAC
values and migration digests are verified such that our se-
vTPM-n SRK EK’ Encryption Keys

AIK
curity features can be enforced. It is important for virtual
TPM migration that the asymmetric storage key is only Virtualized environment
migrated into a trusted virtual TPM. A possible solution quote
for determining the trustworthiness of a destination TPM privacyCA sign
is to require a certificate of the destination TPM’s stor- Signing Key
AIK Signing/Identity Key
age key where the signature key is an externally certified
show
Attestation Identity Key (AIK). create

Strong Association of the Virtual TPM with the Un- TPM SRK EK Encryption Keys
derlying TCB Using an existing attestation architec-
ture for Linux, we showed how a strong association be- sign
tween a virtual TPM instance and the hardware root of EK Certificate for EK MSK Manufacturer’s Signing Key

trust (hardware TPM) of the platform can be established.

Our architecture and virtual TPM have been designed Figure 6: Certification of Endorsement Key using an
such that a challenger not only sees measurements taken AIK
inside the virtual machine OS, but can establish trust into
the virtualization environment, including the boot pro-
cess, hypervisor and the operating system that is hosting same security guarantees as those provided by a hard-
the virtual TPM. ware TPM. However, virtual TPMs can be dynamically
created whenever a new VM is created, and therefore re-
7.2 Trust Establishment quests for EK certificates can become more frequent and
their management becomes much more dynamic.
We have so far reported several solutions from our expe- We have found several solutions for the creation of EK
rience providing TPM support to virtual machines. How- certificates, each having advantages and disadvantages.
ever, there are a number of issues that still need to be We discuss those solutions below and, after looking at
investigated. Whereas other devices can be satisfacto- virtual TPM migration, provide a comparison between
rily virtualized through device emulation, more support them.
is needed in our case, particularly on the treatment of se-
curity credentials such as TPM keys and associated cer- 1. Our first solution creates a certificate chain by con-
tificates. necting the certificate issued for the EK of a virtual
From our experience we can claim that it is easy to TPM instance to that of an AIK of the hardware
create an endorsement key for a virtual TPM instance, TPM. Figure 6 depicts this relationship. It shows
but some questions arise around the certificate that needs that a privacy CA issues certificates for AIKs of a
to be issued: virtual TPM based on the certificate of its endorse-
ment key EK’. The advantage of this scheme is that
• Who would provide a certificate for an endorsement we have preserved the normal procedure of acquir-
key of a virtual TPM? ing an AIK’ certificate by submitting the certificate
of EK’ to a privacy CA for evaluation.
• What guarantees would this certificate stand for?
In this and the following solutions we are using an
A certificate authority, i.e., a privacy CA, bases its de- (attestation) identity key and the TPM’s Quote com-
cision to certify an AIK of a TPM on the certificate of the mand to issue a signature over the current state of
EK that a manufacturer provides along with the device. PCRs and a user-provided 160bit number. We pro-
This certificate vouches for the TPM being a hardware vide as 160bit number the SHA1 hash of the certifi-
device and that it is firmly attached to the motherboard cate contents of the EK’. The resulting signature ties
of the computer. Since the availability of an EK certifi- this EK’ certificate and the virtual TPM instance to
cate plays this important role in receiving a certificate the underlying platform. In addition to the PCRs,
for AIKs, the EK certificate should also be available to the certificate can also contain the measurement list
a virtual TPM instance even if it does not stand for the of the VM environment to enable the establishment

316 Security ’06: 15th USENIX Security Symposium USENIX Association

 manufacturer links the endorsement key certificate

AIK
AIK’ Signing/Identity Key to the secure coprocessor certificate and enables re-
mote parties to establish security properties for the
create virtual TPM runtime environment as described in
Section 5.2.
vTPM-n SRK EK’ Encryption Keys Starting with this manufacturer-provided EK certifi-
cate, all the previously described solutions for creat-
Virtualized environment ing certificate chains for virtual TPM instances can
quote be applied.
privacyCA sign
Signing Key
AIK Signing/Identity Key Depending on which solution for issuing certificates is
show chosen, the migration of a virtual TPM to another plat-
create
form can affect the validity of certified TPM keys. If, for
example, AIKs have been certified based on an EK that
TPM SRK EK Encryption Keys was previously tied to the hardware platform through a
chain, as we have shown in the first two solutions, the
sign
AIKs must be invalidated once the VM is resumed on
EK Certificate for EK MSK Manufacturer’s Signing Key
the target platform since the link to the old platform has
now been broken. Our third solution avoids this prob-
Figure 7: Certification of AIK’ using AIK lem, because it does not establish a firm link with the
VM-hosting platform.
What makes the realization of an architecture based
of trust into the certificate-signing process [21]. on certificate chains more difficult is that AIKs and cer-
tificates may be maintained by programs inside the op-
2. Our second solution, depicted in Figure 7, does not erating system. The TSS stack must be aware of migra-
use a certificate for a virtual EK’, but issues cer- tion and destroy AIKs once the OS resumes on the target
tificates for virtual TPM AIKs based on an AIK is- platform. After the AIKs have been recreated, they must
sued for the hardware TPM. The resulting certifi- be certified for usage on the new platform. Applications
cate chain ties the virtual TPM’s AIK’ to the AIK must also be made aware of the new certificates and re-
of the hardware TPM, and thus to the hosting sys- move old ones from memory.
tem. The advantage of this solution is that once an Another problem can be certificates that clients exam-
AIK has been issued for the hardware TPM, virtual ine while a VM is migrating to a new platform. Based on
TPM AIKs for guest VMs can also be quickly cer- the evaluation of the certificate, the client may treat the
tified. Through the chain, a link is established to peer system as trusted, although it is now running inside
the hardware-TPM platform. The disadvantage of a new environment. For practical purposes, a migrating
this solution is that it requires changes to the nor- partition should offer a subscription service for any party
mal procedure of acquiring an AIK certificate from interested in learning about migration. Notifications can
a certificate authority. be sent that inform subscribers that migration has hap-
pened and trigger a reestablishment of trust. We do not
3. A third solution relies on a local authority to issue
currently offer such a service.
the certificate for the virtual TPM instance’s EKs.
The benefit of this procedure compared to the pre- Another question that arises due to virtual machine mi-
vious ones is that the resulting virtual TPM’s EK gration is: When a virtual machine is migrated from one
certificate is not tied to the hardware platform, since system to another, should all virtual machine environ-
no certificate chain is established to credentials of ments’ measurements be recorded and a history be es-
the hardware TPM. A local EK certificate authority tablished? We feel the answer to this question is ”yes”,
can also be used for hardware TPMs if they are not but we have not yet explored efficient ways to support
equipped with a platform certificate, as is often the this capability.
case today. Beyond this, this third solution offers
the advantage over the second one of not changing
the procedure for acquiring certificates for AIKs.
Table 2 gives an overview of the properties of the first
4. A fourth solution is based on a secure coprocessor three of our proposed solutions. A decision about which
that replaces the hardware TPM used in the other method to implement for certifying EKs must weigh
solutions to provide a hardware root of trust. The the advantages and disadvantages of each solution. If a

USENIX Association Security ’06: 15th USENIX Security Symposium 317

 XX
XXXMethod Local authority
XXX AIK certifies EK’ AIK certifies AIK’
Support X certifies EK’

local and privacy

Needs a CA privacy CA No
CA
Establishes link to
Yes, EK’ is linked Yes, AIK’ is linked No
hosting platform

Needs AIKs and

certificates to be Yes; must also
Yes No
invalidated after invalidate EK
migration

How external party Need to know Need to know Need to know

verifies AIK’ public signing key public AIK used public signing key
certificate of privacy CA for quoting of privacy CA

Software in VM Yes. AIK of parent

No - contact No - contact
needs to be aware of environment is
privacy CA as privacy CA as
how to have AIK’ used to have AIK’
normal normal
certified certified.
AIK: EK certificate AIK: EK certificate
Credentials a CA AIK’: TPM-quote AIK’: EK’ certifi-
AIK: EK certificate cate and (local)
must interpret to for EK’ and asso-
AIK’: not involved CA’s public signing
issue AIK certificate ciated public AIK
key

Table 2: Comparison of Methods to Issue Certificates for AIKs

strong connection between the virtual TPM and the hard- 8 Related Work
ware TPM is desired, then one of solution 1,2 or 4 should
be implemented. However, it will be necessary in this The Xen open-source repository [27] contains a lim-
case to invalidate the chained certificates and keys after ited virtual TPM implementation comprised of combined
migration in order to reestablish a chain to the new hard- contributions by Intel Corporation and the authors of this
ware root of trust. In that respect our second solution of- paper. Our contributions to Xen so far include the vir-
fers better support for a dynamic environment, since here tual TPM driver pair (front- and back-end drivers), hot-
only the AIKs of the virtualized environment need to be plug scripts, and changes to Xen’s management tools.
recreated and certified. The first solution would eventu- We kept this infrastructure modular so that different real-
ally have to place the EK’ certificate on a revocation list izations of virtual TPMs can work with it. The virtual
and create a new EK. TPM design and implementation presented in this pa-
per adds the following to what is currently available in
Xen: support for migrating a vTPM instance alongside
its associated virtual machine, support for attestation of
If a local certification process has already been estab- the complete vTPM environment along with the contents
lished to certify EKs for hardware TPMs, this or a similar of a virtual machine, and an entirely separate software
process can be applied to EKs of virtual TPMs as well. implementation of the TPM specification. In addition,
It would simplify an implementation for virtual TPM mi- the virtual TPM now in Xen is a partial implementation
gration with its VM since in this case there is no link to based on version 1.1 of the TPM specification, while we
the parent environment. Therefore migration would not have updated our virtual TPM to be a complete imple-
break any certificate chains. It can be regarded as the mentation of version 1.2.
least complicated solution, since neither side of the attes- Previous research in the area of trusted computing ex-
tation procedure would have to forget about credentials amined how data that is protected (sealed) by a hardware
that applied to the pre-migration environment. TPM can be moved to another platform. Kuehn et al. [17]

318 Security ’06: 15th USENIX Security Symposium USENIX Association

 proposed a protocol for migrating the key-related hard- cates related to TPM-generated keys or do not deal with
ware TPM security state from one hardware platform to the concept of trust can remain unchanged. Applica-
another involving a separate TPM Migration Authority tions challenging a virtual machine or those following
(TMA). Our protocol differs from the one presented there certificate chains, like for example a privacy CA, must
in many significant ways. Most notably, we migrate the be aware of the modifications that were necessary for the
complete virtual TPM state, we do not require a third virtualized environment. Those modifications include
party for migration, we maintain associations of virtual certificate chains that consist of different types of certifi-
TPMs to their VMs and the operating system, and we can cates issued through special signing mechanisms of the
seamlessly integrate our protocol into the automated VM virtual TPM, or certificates provided by the manufacturer
migration process. In addition, the extensions we intro- of the device or those issued through a certificate author-
duce to the TPM standard do not require changes to ex- ity such as a privacy CA. Applications that have been
isting commands and semantics. Similar to their concern adapted to work in the virtualized environment will be
about security of the destination TPM, we have pointed backwards compatible with platforms using a singleton
out that secure migration relies on a decision process that hardware TPM.
determines the safety of migrating a key pair to another Our proposed architecture for virtualizing the TPM is
TPM based on trust in that other TPM implementation. a major building block for establishing trust in virtual-
The Terra project [7] investigated trusted virtual ma- ized environments. For example, Trusted Virtual Data
chine monitors. They developed a prototype based on Centers [16] create distributed virtual domains offering
VMWare’s GSX server product that performs attestation strong enterprise-level security guarantees in hosted data
of virtual machines and applications launched therein. center environments. In such an environment, virtual
Their publications recognize the availability of TPM TPMs help to establish trust in strong domain security
1.1b, but do not describe the design of a virtual TPM guarantees through their remote attestation and sealing
to run their attestation scheme against. Terra could use capabilities.
something like our vTPM facility to make a virtual TPM
instance available to each of their virtual machines.
Acknowledgments

9 Conclusions We would like to thank our shepherd, Peter Chen, and the
anonymous reviewers for their valuable comments. We
We have designed and implemented a system that pro- also thank the Xen community for their feedback on the
vides trusted computing functionality to every virtual vTPM work.
machine on a virtualized hardware platform. We virtual-
ized the Trusted Platform Module by extending the stan- References
dard TPM command set to support vTPM lifecycle man-
[1] Fabrice Bellard. Qemu, a fast and portable dynamic translator. In
agement and enable trust establishment in the virtualized Proceedings of the USENIX 2005 Annual Technical Conference,
environment. We added support for secure vTPM mi- FREENIX Track, pages 41–46, 2005.
gration while maintaining a strong association between a [2] C. Clark, K. Fraser, S. Hand, J. G. Hansen, E. Jul, C. Limpach,
vTPM instance and its associated VM. I. Pratt, and A. Warfield. Live Migration of Virtual Machines. In
We uncovered the most important difficulties that arise Proceedings of the 2nd Symposium on Networked Systems Design
and Implementation (NSDI ’05), 2005.
when virtualizing the TPM. Whereas usually virtualiza-
[3] Common Criteria. Trusted Computing Group (TCG) Personal
tion of hardware devices can be achieved through soft- Computer (PC) Specific Trusted Building Block (TBB) Protec-
ware emulation, we have demonstrated that this is not tion Profile and TCG PC Specific TBB With Maintenance Pro-
sufficient in the case of the TPM. Certificates that may tection Profile, July 2004.
exist for hardware TPMs and vouch for strong security [4] B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt,
properties need to be issued for virtual TPM instances’ A. Warfield, P. Barham, and R. Neugebauer. Xen and the Art
of Virtualization. In Proceedings of the ACM Symposium on Op-
endorsement keys . These certificates can naturally not erating Systems Principles, October 2003.
represent the same properties for a virtual TPM process [5] R. Figueiredo, P. A. Dinda, and J. Fortes. Resource virtualization
running in user space. Trust chains that are usually renaissance. IEEE Computer, 38(5):28–31, 2005.
owned by a single OS now pass through a hierarchy of [6] K. Fraser, S. Hand, R. Neugebauer, I. Pratt, A. Warfield, and
virtual machines. Virtual TPM migration can create fur- M. Williamson. Safe Hardware Access with the Xen Virtual Ma-
ther problems if certificate chains that have been estab- chine Monitor. In Proceedings of the OASIS ASPLOS Workshop,
2004.
lished break or trust must be reestablished.
[7] Tal Garfinkel, Ben Pfaff, Jim Chow, Mendel Rosenblum, and
We virtualized the Trusted Platform Module by mak- Dan Boneh. Terra: a Virtual Machine-based Platform for Trusted
ing all low-level TPM 1.2 commands available to every Computing. In Proceedings of the Symposium on Operating Sys-
virtual machine. Applications that don’t handle certifi- tems Principles (SOSP), pages 193–206, 2003.

USENIX Association Security ’06: 15th USENIX Security Symposium 319

 [8] R. P. Goldberg. Survey of Virtual Machine Research. IEEE Com-
puter Magazine, 7(6):34–45, 1974.
[9] Applied Data Security Group. What is TrustedGRUB,
http://www.prosec.ruhr-uni-bochum.de/trusted grub.html.
[10] Trusted Computing Group. TCG TPM Specification Version 1.2
- Part 1 Design Principles, 2005.
[11] Trusted Computing Group. TCG TPM Specification Version 1.2
- Part 3 Commands, 2005.
[12] IBM. IBM eServer x366. http://www-
03.ibm.com/servers/eserver/xseries/x366.html.
[13] IBM. Integrity Measurement Architecture for Linux.
http://www.sourceforge.net/projects/linux-ima.
[14] IBM. PHYP: Converged POWER Hypervisor Firmware for
pSeries and iSeries. http://www-1.ibm.com/servers/enable/site/
peducation/abstracts/abs 2bb2.html.
[15] IBM. Secure Coprocessing. http://www.research.ibm.com/secure
systems department/projects/scop/index.html.
[16] IBM. Trusted Virtual Data Center.
http://domino.research.ibm.com/comm/research projects.nsf/
pages/ssd trustedvirtualdatacenter.index.html.
[17] U. Kühn, K. Kursawe, S. Lucks, A. Sadeghi, and C. Stüble. Se-
cure data management in trusted computing. In Proceedings of
Workshop on Cryptographic Hardware and Embedded Systems
(CHES 2005), 2005.
[18] H. Maruyama, F. Seliger, N. Nagaratnam, T. Ebringer, S. Mune-
toh, S. Yoshihama, and T. Nakamura. Trusted platform on de-
mand. Technical Report RT0564, IBM, February 2004.
[19] National Institute of Standards and Technology. Secure Hash
Standard (SHA-1). Federal Information Processing Standards
Publication 180-1, 1993.
[20] R. Sailer, T. Jaeger, E. Valdez, R. Cáceres, R. Perez, S. Berger,
J. Griffin, and L. van Doorn. Building a MAC-based security
architecture for the Xen opensource hypervisor. In Proceedings
of the Annual Computer Security Applications Conference (AC-
SAC), December 2005.
[21] R. Sailer, X. Zhang, T. Jaeger, and L. van Doorn. Design and
implementation of a TCG-based integrity measurement architec-
ture. In Proceedings of the USENIX Security Symposium, 2004.
[22] The Xen Team. Xen Interface Manual - Xen v3.0 for x86.
[23] Trusted Computing Group. http://www.trustedcomputinggroup.org.
[24] Trusted Computing Group. TCG PC Specific Implementation
Specification, 2003.
[25] Trusted Computing Group. TCG Software Stack (TSS) Specifi-
cation - Version 1.10 Golden, 2003.
[26] VMware, Inc. http://www.vmware.com.
[27] Xensource. Xen Open-Source Hypervisor.
http://www.xensource.com/products/downloads.

320 Security ’06: 15th USENIX Security Symposium USENIX Association