TPM Reset Attack

Welcome to the TPM Reset Attack page. Here you can find information about a novel new attack against TPMs and the TCG architecture, in addition to a video demo of the attack in action. This attack was first performed by Bernhard Kauer, but we at the Dartmouth College PKI/Trust Lab have been exploring the same kind of attack, and thought it would be interesting to demonstrate and document it here. Please read this entire document before jumping to conclusions about what this attack can and cannot do. For instance, this attack cannot get an endorsement (or any other) kind of key out of a TPM and thus does not enable a random remote party to masquerade as a trusted platform, only a remote party with physical access to the TPM with the endorsment key of the trusted system in question. Also, while the basis of this attack is very simple and interesting, building on this attack to do interesting things might require both basic and sophisticated specialized hardware. Consider yourself warned.


A Trusted Platform Module (TPM) is an embedded cryptographic device, whose spec was designed by the Trusted Computing Group (TCG). These devices are implemented by various vendors. They are meant to be cheap, commodity devices included on new PC motherboards and are designed to enable trusted computing.

One key facility that TPMs provide to enable trusted computing is the ability to securely store a series of measurements. To do this, the TPM employs a set of registers called Platform Configuration Registers (PCRs). A TPM equipped PC with a trusted BIOS can boot up, and take a series of measurements of the hardware and software of the running machine, and store them in the PCRs. The TPM can cryptographically sign these PCRs and send them to a remote party. This party can then verify that the platform equipped with that TPM has been booted up and measured in that specific manner. TPMs also use these PCRs for the purposes of binding wrapped keys to a platform in a particular state. That is, the TPM may not allow a platform in a different state than it was when the key was created to have access to the key.

PCRs work as secure measurement storage because they support only one operation: Extend(). At initialization, all PCRs are filled with 20 NULL bytes (0x00). Normally only the BIOS sees them in this state. The BIOS will then take some measurement, and Extend() it into a specified PCR. Extend is defined as follows.

Extend(PCR#, newval) {

val[PCR#] = SHA1(val[PCR#] . newval)

Where '.' is the concatenation operator.
Because of SHA1 pre-image resistance, it is very difficult to come up with a 'newval' which will get val[PCR#] into a desired state given an arbitrary old val[PCR#]. Thus, it is difficult to fake that an arbitrary series of measurements has taken place.

It is worth noting that some PCRs do support a reset operation (beginning with version 1.2 TPMs), but the PCRs most commonly used to store the trusted boot sequence (the ones we are interested in attacking) do not.

The Attack

So, given everything we've seen above, it should be very difficult to fake a trusted boot process, as long as the BIOS takes the first few measurements. The critical assumption here is that the PCRs cannot be easily reset without restarting the whole platform that the TPM resides on. If an attacker is capable of monitoring the measurements sent to the PCRs by the BIOS (with, for instance a logic analyzer, see this paper), and capable of zeroing out the PCRs without restarting the machine, then she could take a platform in any configuration and put it into a 'trusted' state. So, the difficult part is getting the TPM to reset without bringing down the whole machine. It is worth mentioning that we've also looked at interposing memory and other such things to change the running system after its been measured, but due to the speed of the busses that memory and hard drives sit on, this is a tricky endeavor. Attacking a slower bus is much easier.

TPMs typically reside on the Low Pin Count (LPC) bus. The LPC bus supports a ground driven reset line. This means that when this particular line on the bus is driven to ground every device on this bus is supposed to reset. Other devices attached to this bus include the BIOS, and legacy keyboard and mouse controllers. The video below demonstrates that driving this line is indeed possible, and fairly easy to do. Please note that in the video, we are accessing the computer in question via a remote ssh session. This is because the keyboard and mouse controller get reset when we drive the reset pin, but the network card does not. More details of this attack (and others!) can be seen in my senior honors thesis: A Security Assessment of Trusted Platform Modules, Dartmouth College Computer Science Technical Report TR2007-597.

The Video!

We attack a v1.1b TPM on an IBM NetVista PC. We chose this particular TPM as a target because it resides on a daughterboard and is thus easier to access physically.


This demonstration shows that we can drive this line without significantly disturbing the running system. If an attacker really wanted to keep from disturbing the rest of the platform, they could physically isolate the TPM from the platform and drive the reset line only on the TPM . Either way, we could ultimately take a platform in an untrusted configuration and put it into a trusted one.

An attacker with a v1.1b TPM and monitored measurements in hand could easily redrive these using the TPM_Extend() command using a standard TPM driver. Note that on a v1.2 TPM, if the BIOS locality is different from the host's (in terms of LPC locality), then some hardware attached to the bus which communicates using the BIOS's locality will be needed to redrive these measurements. However, since there is no authentication mechanism on the LPC bus itself, any rogue device could do this.

New work

Bernhard Kauer has created the OSLO Bootloader to defend against these types of attacks. It employs AMD's new sk_init instruction to use a dynamic root of trust, as opposed to a static root with the BIOS. This new type of protection relies on the LPC locality features incorporated into v1.2 TPMs.

However, an attacker with physical access to the LPC bus could circumvent these protections by communicating measurements to the TPM which claim to be from the CPU in sk_init mode.

Please direct questions, comments, and concerns to: or