Previously, I described a recent attack on TPMs that only requires a short piece of wire. Dartmouth researchers used it to reset the TPM and then insert known-good hashes in the TPM’s PCRs. The TPM version 1.2 spec has changes to address such simple hardware attacks.
It takes a bit of work to piece together the 1.2 changes since they aren’t all in one spec. The TPM 1.2 changes spec introduces the concept of “locality”, the LPC 1.1 spec describes new firmware messages, and other information available from Google show how it all fits together.
In the TPM 1.1 spec, the PCRs were reset when the TPM was reset, and software could write to them on a “first come, first served” basis. However, in the 1.2 spec, setting certain PCRs requires a new locality message. Locality 4 is only active in a special hardware mode. This special hardware mode corresponds in the PC architecture to the SENTER instruction.
Intel SMX (now “TXT”, formerly “LT”) adds a new instruction called SENTER. AMD has a similiar instruction called SKINIT. This instruction performs the following steps:
- Load a module into RAM (usually stored in the BIOS)
- Lock it into cache
- Verify its signature
- Hash the module into a PCR at locality 4
- Enable certain new chipset registers
- Begin executing it
This authenticated code (AC) module then hashes the OS boot loader into a PCR at locality 3, disables the special chipset registers, and continues the boot sequence. Each time the locality level is lowered, it can’t be raised again. This means the AC module can’t overwrite the locality 4 hash and the boot loader can’t overwrite the locality 3 hash.
Locality is implemented in hardware by the chipset using the new LPC firmware commands to encapsulate messages to the TPM. Version 1.1 chipsets will not send those commands. However, a man-in-the-middle device can be built with a simple microcontroller attached to the LPC bus. While more complex than a single wire, it’s well within range of modchip manufacturers.
This microcontroller would be attached to the clock, frame, and 4-bit address/data bus, 6 lines in total. While the LPC bus is idle, this device could drive the frame and A/D lines to insert a locality 4 “reset PCR” message. Malicious software could then load whatever value it wanted into the PCRs. No one has implemented this attack as far as I know, but it has been discussed numerous times.
What is the TCG going to do about this? Probably nothing. Hardware attacks are outside their scope, at least according to their documents.
“The commands that the trusted process sends to the TPM are the normal TPM commands with a modifier that indicates that the trusted process initiated the command… The assumption is that spoofing the modifier to the TPM requires more than just a simple hardware attack, but would require expertise and possibly special hardware.”
— Proof of Locality (section 16)
This shows why drawing an arbitrary attack profile and excluding anything that is outside it often fails. Too often, the list of excluded attacks does not realistically match the value of the protected data or underestimates the cost to attackers.
In the designers’ defense, any effort to add tamper-resistance to a PC is likely to fall short. There are too many interfaces, chips, manufacturers, and use cases involved. In a closed environment like a set-top box, security can be designed to match the only intended use for the hardware. With a PC, legacy support is very important and no single party owns the platform, despite the desires of some companies.
It will be interesting to see how TCPA companies respond to the inevitable modchips, if at all.
rdist 
I occasionally hear rumors that TPM functionality may be built into future CPUs. As more and more cores go onto a single chip we will soon reach a point of diminishing returns in adding yet another regular processing core. Special purpose cores like graphics accelerators, crypto processors and TPMs will make sense as components of future CPUs. That will fix some but not all attacks on the TPM security model.
What you describe is nothing new. Just read https://www.cosic.esat.kuleuven.be/publications/article-591.pdf or chapter 13 of “The Intel Safer Computing Initiative” book.
TPM v1.2 has a feature called Transport Protection, which allows to create an encrypted and authenticated channel to the TPM. So manipulation of LPC bus will get detected.
The impact of these hardware attacks is rather limited. Remote attestation for instance is too complex for the internet (there are too many possible platform configuration) and most TPMs don’t even come with an endorsement certificate (only Infineon does the effort of creating them). The encryption key stored in the TPM by Vista Bitlocker is protected by a user password, so not only by TPM sealed storage (i.e., locking data to certain PCR value).
All this clearly shows that the TPM was never designed for DRM, where people will perform hardware attacks to break the system…
It will become increasing difficult to access to the LPC bus. The Winbond TPM is integrated in a Super I/O and the Broadcom TPM in an ethernet controller. In the future TPM will be integrated in south bridge and maybe even in the CPU (or maybe not, because adding EEPROM to a CPU is very expensive).
Hal, that’s unlikely without a full redesign of the TCG specs. Individual vendors may offer an onboard co-processor with EEPROM, probably on embedded CPUs like ARM first, but they won’t be TPMs. There were a lot of compromises for cost in the current design, missing functionality (i.e. no symmetric encryption), and other decisions that would have been different if it wasn’t an industry consortium trying to deal with a huge legacy compatibility problem.
Dries, I didn’t cite your paper but I did read it earlier. It’s pretty nice and was one of the first pointing out the obvious flaws in the bus design. However, few people seem to know about these attacks, hence my articles.
Your second point (TPMs useless anyway) has some merit. I don’t know of anyone who intends to use remote attestation, do you? Maybe a large corporate IT group some day, but even in those locked down systems, the number of hashes would still be hard to manage.
The TCG design had a lot of different companies involved, with widely varying agendas. That’s why it’s such a complicated system with no clear customer. In the eyes of Microsoft and movie studios, TPMs are probably still intended for DRM use. But other parties had at least cost concerns about a full tamper-resistant design and an intent to use it for IT security, hence the compromises.
I once heard a rumor that there’s no symmetric encryption (i.e. AES) in TPMs because the Chinese or other governments only wanted it to be used for signing, not encryption. (Ignore the RSA public keys, please).
Dries, on your tamper resistance points:
1. While transport encryption prevents the attack I describe above, it won’t help against modchips as they would then merely have keys provided by someone who makes the effort to crack open TPMs. A similar environment already exists in satellite TV piracy.
2. Integrating a TPM with a Super I/O chip means you just reset the whole LPC bus as before, but make sure you have some software to reinitialize the other devices in that chip afterwards.
But TPM vendors shouldn’t be making all this effort since hardware attacks are out of scope, right?
Nate, according to TCG there’s no symmetric encryption (i.e. AES) because of export restrictions. On the other hand, it does not make a lot of sense to have symmetric encryption because the TPM is too slow to do bulk encryption (e.g., for disk encryption).
There are claims that Chinese government wants TPMs with their only public key crypto algorithm instead of RSA. However, the public documents about the Sinosun TPM (http://www.sinosun.com.cn/eng/product/index.asp) do not mention this.
For me attestation only makes sense in corporate networks; I doubt it will ever be used to enforce DRM. Hypervisors in combination with Intel TXT (Trusted Execution Technology; formely know as LaGrande Technology) can solve some of the attestation issues (too many possible configurations). This is exactly what the EU OpenTC project tries to do: http://www.opentc.net
Dries, thanks for the followup. Public key encryption is subject to export control, just like symmetric encryption. So the Transport Protection feature shouldn’t be allowed if export control was the reason. I don’t buy this argument but will probably never have confirmation of the real reason.
I agree attestation will probably never be useful for DRM except in terms of getting a known OS image up and running. At that point, the OS will be expected to use TXT, code signing, and other features to try to create a protected path to the hardware. At that point, we’ll be back to “Hacking the Xbox1” as the likely scenario attackers will take.
Intel Q2’08 performance and mainstream desktop chipsets will support an integrated TPM following the spec version 1.2.
Implementation details are unknow.
Sebastien, if that’s the feature I think it is (Active Management Technology, AMT), I believe it’s a lights-out management co-processor, not a TPM.
Nate: Intel AMT is effectively a management technology. But what I said as nothing to do with it: Intel announced recently the next performance and mainstream desktop chipset refresh (codenamed EagleLake) will bring integrated TPM compatible with the 1.2 spec.
Thanks for the correction. I looked up that chipset since I hadn’t heard of it. Pretty amazing stuff — HDMI onboard, including keys; TXT + TPM to give you a hardware protected path to outputs. It will be very interesting to see if this results in more set-top boxes designed using Intel (really uncommon today) or if it’s used as a way to deprecate software-only playback of HD video on PCs.
The problem is that there’s no way the CPU, the chipset and the TPM authenticate with each other. This is probably because they are made by different manufacturers and how are you going to exchange certificates, what if a new manufacturer arrives etc. I think the solution is to move the TPM into the chipset. That would make it much harder to make these attacks. The problem is that you would then have to deprecate/reject all the stand-alone TPM’s that have already been sold. But of course that would happen automatically as time went by.
People here are very critical about remote attestation, saying it will be unmanageable. The problem is that most people are talking about TPM 1.1 remote attestation. I agree that would be unmanageable for most applications, particularly DRM on regular PC’s. How in the world are movie studios going to have a list of hashes of all trusted device drivers (even mouse drivers etc.) that run in ring 0. That would be required for RA to work. This was acknowledged sometimes during the development of 1.1 and TPM 1.2 can be seen as an “admission” of this. In TPM 1.2 you can start a secure session within an untrusted context. You only need to “trust” the images loaded in the secure context – not the o/s loading the context. A movie company could insist on you using a special signed secure context for watching your movies, and they could verify that you are using it etc. In practice I think we will have one core open-source root (maybe written by Intel/AMD) that can then load and authenticate agents for the particular application and provide separate storage for these agents. Hence, the movie company would only have to verify the root and their agent.
All decryption etc. for watching movies could be done in this secure context with memory curtaining etc. I think this would be feasible. Interestingly, TPM 1.2 spec could be much simpler than it is. In the context just described the chip is only used for authenticating the CPU image, establishing a session with the trusted root and for delivering the grant master key used to unlock the “trusted-context-only” secrets which may be stored in a file in the harddrive. There probably should be more than 1 grant master key so you can have multiple trusted roots etc. A few commands that could be described in 10 pages. It would definitely be feasible to integrate this system in the chipset or even the CPU itself. Oh well, now we’re stuck with the umpteen pages TPM spec.
This is related to the lack of symmetrical encryption mentioned: There’s no reason for having sym. enc. in the chip in the context of 1.2. The chip is only used for one authentication and basic key storage. Especially with SENTER/SKINIT all the chip has to do is to be the giant gatekeeper ensuring only trusted roots can get access to the keys (and the trusted root then has the responsibility of ensuring only trusted agents running in the trusted root context gets the keys they are allowed to etc.). Then these agents can do all the encryption they need on the regular CPU in a secure fashion (unless the system is broken via a hardware attack like memory snooping etc. I suspect that would be a quite difficult attack to carry out with ultra-fast memory etc.).
Martin, great comments. I agree the TPM is already destined for the chipset. It also appears dynamic launching of a compartment (SENTER/SKINIT) will be the preferred method versus doing it at boot time.
This system of separate components all loosely connected still seems fundamentally flawed. It’s similar to the “link encryption” approach of trying to do hop-by-hop encryption of audio/video between media components. By building it into the existing PC architecture, it also requires much more complicated software. For example, each compartment will be running a kernel instance, probably Linux. So that adds to the compartment setup/teardown time.
I think the purposes of DRM and intrusion resistance should and will be separated. Graphics chips will have their own decryption/decoding logic so that video will be completely processed there. Compartments could then be simplified and the TPM eliminated.
I’m certain DRM will evolve this way. The only question is whether the extraneous features of trusted computing are left in or are deprecated once the DRM use case is eliminated.