Trusted Computing has been a controversial addition to PCs since it was first announced as Palladium in 2002. Recently, a group at Dartmouth implemented an attack first described by Bernhard Kauer earlier this year. The attack is very simple, using only a 3-inch piece of wire. As with the Sharpie DRM hack, people are wondering how a system designed by a major industry group over such a long period could be so easily bypassed.
The PC implementation of version 1.1 of the Trusted Computing architecture works as follows. The boot ROM and then BIOS are the first software to run on the CPU. The BIOS stores a hash of the boot loader in the TPM’s PCR before executing it. A TPM-aware boot loader hashes the kernel, appends that value to the PCR, and executes the kernel. This continues on down the chain until the kernel is hashing individual applications.
How does software know it can trust this data? In addition to reading the SHA-1 hash from the PCR, it can ask the TPM to sign the response plus a challenge value using an RSA private key. This allows the software to be certain it’s talking to the actual TPM and no man-in-the-middle is lying about the PCR values. If it doesn’t verify this signature, it’s vulnerable to this MITM attack.
As an aside, the boot loader attack announced by Kumar et al isn’t really an attack on the TPM. They apparently patched the boot loader (a la eEye’s BootRoot) and then leveraged that vantage point to patch the Vista kernel. They got around Vista’s signature check routines by patching them to lie and always say “everything’s ok.” This is the realm of standard software protection and is not relevant to discussion about the TPM.
How does the software know that another component didn’t just overwrite the PCRs with spoofed but valid hashes? PCRs are “extend-only,” meaning they only add new values to the hash chain, they don’t allow overwriting old values. So why couldn’t an attacker just reset the TPM and start over? It’s possible a software attack could cause such a reset if a particular TPM was buggy, but it’s easier to attack the hardware.
The TPM is attached to a very simple bus known as LPC (Low Pin Count). This is the same bus used for Xbox1 modchips. This bus has a 4-bit address/data bus, 33 MHz clock, frame, and reset lines. It’s designed to host low-speed peripherals like serial/parallel ports and keyboard/mouse.
The Dartmouth researchers simply grounded the LPC reset line with a short wire while the system was running. From the video, you can see that the fan control and other components on the bus were also reset along with the TPM but the system keeps running. At this point, the PCRs are clear, just like at boot. Now any software component could store known-good hashes in the TPM, subverting any auditing.
This particular attack was known before the 1.1 spec was released and was addressed in version 1.2 of the specifications. Why did it go unpatched for so long? Because it required non-trivial changes in the chipset and CPU that still aren’t fully deployed.
Next time, we’ll discuss a simple hardware attack that works against version 1.2 TPMs.
rdist 
The TPM reset has been known from the start by TCG. That is why the TCG specification says something like “resetting a TPM should reset the complete platform”.
Dries, does it actually say “should”? Because everyone knows when it comes to security, “should” means no one implements it. However, with functionality/features, “should” means the same as “mandatory”. :-)
In any case, it would require a pretty big change in chipsets to cause a LPC reset to reset the whole platform. At the moment, LPC reset is an output pin on all chipsets I know of, since the southbridge is mainly the one that drives this pin. If this was changed, then the attack would simply become cutting the trace before grounding the LPC reset pin, not a huge increase in difficulty.
Actually, it just means the TPM has to go inside the South or North bridge. Or inside the SoC for embedded designs. These are not yet available, AFAIK, but there is no real reason why they couldn’t be made. SuperIO chips with the TPM embedded inside are already common (my ThinkPad has one, for example) — too bad that doesn’t disable the reset attack, since it is non-fatal to the platform to reset the SuperIO.
Once you get the TPM inside the core chipset, getting access to the TPM hardware to mess with it without blowing it up all to hell becomes a lot more difficult…
Henrique, right, that’s the direction they’re going per EagleLake (discussed in this thread).
I disagree with your assessment of how hard it is to modify an integrated design, though. There have been some big advances in hobbyist silicon-level hacking, mostly by these guys. Since there is no deployed system for revoking TPM keys, opening just one chip suffices to enable attacks against the class.