A Password Is Not Enough 4: Using TPM to Combat Specific Attacks

Based on Daniel Selifonov’s perspective, learn the security measures prior to authenticating to a PC and the way TPM protects from hardware and reset attacks.

Ideas for assuring the PC hasn’t been tampered with before authentication

Ideas for assuring the PC hasn’t been tampered with before authentication

We want to then develop a protocol that a user can run against the computer so that they can verify that the computer has not been tampered with before they authenticate themselves to the computer and begin using it. What sort of things can we try sealing to platform configuration registers that would be useful for this sort of protocol? A couple of suggestions that I have are seeds to one-time password tokens, either the time or the even variety; maybe some sort of unique image or animation, like a photograph of you somewhere – something unique that cannot be easily found elsewhere (see right-hand image). You might also disable the ‘video out’ in your computer when you are in this challenge-response authentication mode.

You also want to seal a part of the disk key, and there are a couple of reasons you want to do that. It assures, within certain security assumptions, that the system is only going to be booting into some approved software configuration that you control as the owner of the computer. Ultimately, that means that anyone who wants to attack your system needs to do it either through breaking the TPM or they need to do it within the sandbox that you’ve created for them. This, of course, is not very cryptographically strong or anything like that; you’re not going to have a protocol which allows a user to securely authenticate a computer to the same level of security that you have, say, with AES. But unless you can do something like RSA encryption in your head, it’s never going to be perfect.

Setting conditions for self-destruct

Setting conditions for self-destruct

I mentioned that there’s a self-erase TPM command that you can issue as in the software. Since the TPM requires the system to be in a particular configuration before it will release secrets, you can actually do something interesting, like self-destruct (see left-hand image). You could develop the software and set up your protocol to limit, say, the number of times the computer has been started up unsuccessfully, have a time-out once the password has been waiting on the password screen for some period of time, or limit the number of passwords you can enter or the amount of time since the computer has been started up – say, if it’s been in ‘cold storage’ for a week or two. You could also restrict access to the computer for periods of time so that when you’re going to be traveling to a foreign country you want to lock down your computer for the duration of the trip; when you’re at the hotel or whatever on the other end, then you can unlock it, but not before.

You could also do fun things like leave little canaries on the disk which appear to contain the critical values for your policy but are really just tripwires, and you’re really just using the internal TPM values. You could also create self-destruct password or duress code to automatically issue this reset command. Since the two options that an attacker would have would be to break the TPM or run your software, you can kind of make them play by these rules and you can actually do an effective self-destruct. The TPM is intentionally designed to be very hard to copy; you can’t clone it very easily. So you could use things like monotonic counters to detect right blockers, any disk restore or replay attacks. And once the TPM ‘clear’ command is issued, it’s game over for an attacker who might want to get access to your data.

The TPM is intentionally designed to be very hard to copy.

There are some similarities to a system that Jacob Appelbaum discussed at the Chaos Communication Congress many years ago, 2005. He proposed using a remote network server for many of these options but admitted it was going to be brutal and kind of potentially difficult to use. Since the TPM is an integrated system component, you can get a lot of these advantages by using the TPM instead of remote server. A hybrid approach is potentially possible. You could have a system set up, say, as in IT department, where you temporarily lock down the system and it can only become available again once you plug it into the network, call your IT administrator and they unlock the system again. I’m kind of hesitant to expose a network stack this early in the boot process, just because it massively increases your attack surface. But it’s still a possibility.

Hardware attack countermeasures

Hardware attack countermeasures

I’ve sort of qualified all my statements that an attacker can only do this – that’s of course under the assumption that they cannot break the TPM very easily. This (see right-hand image) is actually an optical microscope scan of a TPM, or smart card done by Chris Tarnovsky. He has actually done some really great work in figuring out how hard these things are to break. He has enumerated the countermeasures and sort of figured out what it would take to actually break these things, and actually he has gone and done it and tested it. So, there are things like light detectors, there are active meshes, there are all sorts of really crazy circuit implementations to try to throw you off the track of what it’s actually doing.

But if you spend enough time and have enough resources and you’re careful enough, you can actually get around most of these, so you can de-encapsulate a chip, put it in an electro-microscope workstation and go wild, find where the unencrypted data bus is and just glitch it and get the thing to spill out all the secret data. But nonetheless, this sort of an attack, even if you’ve done all the R&D, is going to take hours with an expensive microscope, and you’re still going to spend lots of R&D to figure out what the countermeasures are on the chip so that you can actually break it without frying the one chip of your attack target.

Reset attacks

Reset attacks

There are also reset attacks (see left-hand image). I mentioned earlier that the TPM is a separate chip on the motherboard in almost all cases. It’s very-very low in the system hierarchy. It’s not up in the CPU like it is for DRM enforcement in video consoles. If you manage to reset it, you are not going to irreversibly affect the system that badly. It’s usually a chip that’s off the LPC bus on a computer, which itself is sort of a legacy bus that’s off the southbridge. On modern systems, really, the only sorts of things you are going to find are the TPM and things like the BIOS, legacy keyboards, we used to have floppy controllers, but I guess not really anymore. And if you find a way to reset, say, the Low Pin Count bus, you will reset the TPM into a ‘fresh system boot’ state. You’ll lose your PS to keyboard, but not really a big deal. And you’ll be able to play back the trusted boot sequence of the TPM that has data sealed to without actually executing that boot sequence, and you could use this to extract data.

There are a couple of attacks that have tried to exploit this. If you are using an older mode in the TPM called Static Root of Trust for Management, you can do this pretty easily. I have not seen any research on a successful attack against the newer Intel Trusted Execution Technology version of the TPM activation. It’s likely still possible – this is an area that probably needs more research – to intercept the LPC bus and what it’s communicating to the CPU; that might be another way that you can attack the TPM.

Read previous: A Password Is Not Enough 3: Trusted Platform Module as a Means for Measured Boot

Read next: A Password Is Not Enough 5: Secure Architecture Design

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: