Extracting Bitlocker Keys from a TPM
pulsesecurity.co.nz
pulsesecurity.co.nz
Sniffing keys on the bus and extracting keys from a TPM are very different scenarios. If you can "extract keys from a TPM", it means you must have found a way to tamper the chip using a piece of semiconductor test equipment and to obtain it from the circuity via a microprobe (or somehow injecting a spurious signal externally), bypassing any verification and self-protections of the chip.
TPMv2-like security chips are usually implemented by a secure microcontroller core. The internal is mostly a secret, and there is little public information about its internal construction, public audits on their actual resistance against various forms of attacks is almost non-existent. Even obtaining these microcontrollers are difficult, usually even the basic datasheet is beind multiple NDAs, and their availability is usually highly restricted, they don't sell these microcontroller cores to ordinary people.
If you have broken it, it would be the breaking news in the infosec community. It means you would be possible to completely decrypt the entire harddrive (if no additional key is used) given a random computer without preconditions, and everyone would have an idea about how secure these chips actually are.
I suggest changing the title to "Sniffing Bitlocker Keys from a TPM".
It is a very interesting read but the title is a bit clickbaity. Luckily it's not with bad intentions, the first few lines (above) already tell you what it is.
> I'm not sure what the distinction you're making is
Imagine I tell you I can extract any information I want from the human brain. You'd be intrigued, how do I interface, how do I extract and process the data. Then I tell you I basically eavesdrop on your conversations.
I understand the end result is the same, the mechanism is compromised but the method makes all the difference to how interested I am in the article. I've read about sniffing already, I was now expecting to read how the TPM chip was "cracked".
What is there to gain "cracking" the TPM itself, if you can get the keys fine by sniffing?
Apple's Secure Enclaves aren't vulnerable to sniffing, as the AES keys used for encryption live only in silicon, with access to use them granted to the Enclave.
The keys never exist in a software-readable form, even to the coveted Enclave firmware. Do TPMs offer this functionality, and Bitlocker needs to take advantage of it? Or do TPMs just not protect their keys against physical access?
The technical achievement itself. :) It would be a world first, unlike sniffing. Hacking the TPM chip itself could open the door to even more interesting stuff. I think the analogy I gave before perfectly illustrates the difference between the 2 ideas. Getting to the same end result doesn't mean the paths are equivalent.
Would you find it equally interesting to read about getting Bitlocker keys using the legendary xkcd $5 wrench [0]?
Someone obviously doesn't agree with me since in the 10s it took me to read the comment above, all of mine received an equal number of downvotes. Guess I now have a fan (and their very own small army of puppet accounts) :).
The ability to forge remote attestations by extracting the endorsement key or various attestation identity keys that never leave the TPM in plaintext.
Sniffing requires the TPM be unlocked first. If you can't get it unlocked (poor wording, but it will do), no amount if sniffing is going to get you anywhere. They sort of acknowledge that here:
> Don’t want to be vulnerable to this? Enable additional pre-boot authentication.
If they really could just extract keys from a TPM without if being unlocked there would be little point in having a TPM at all. "Little point in having a TPM at all" would be big news, and the reason many of use read the article is because the headline implied it was describing a way to do just that.
In reality the TPM remains perfectly capable of keeping it's secrets secret until someone with the right credentials comes along, and proves they have them to the TPM itself. But in the scenario described the only "credentials" required to make Bitlocker unlock the TPM was was someone pressing the on switch.
So it doesn't sound like someone extracted the keys from the TPM to me. Once the software has unlocked it and asked it to send the keys, they will exist in multiple locations. The LPC bus is one, but they will also end up in RAM, or for that matter intercept the keying material when it is sent via the SATA bus to the drives.
Its kind of like if a bank had a big vault door and then a glass window to the vault. The bank robber will break the window and get all the cash. Who cares that the door wasn't breached? What the vault was supposed to protect still is gone.
A TPM without a PIN is kind of like if a bank had a big vault door and then an employee leaving the key on the office desk, the bank robber will get the key and open the door. Everyone would care whether the door itself is breached, or it was something else.
The bottomline is, if it doesn't even have a PIN code, no security is offered against an attacker with physical possession of both the motherboard and the harddrive (aka the computer), by design, and not even a considered 0day.
TPM: Trusted Platform Module (TPM, also known as ISO/IEC 11889) is an international standard for a secure cryptoprocessor, a dedicated microcontroller designed to secure hardware through integrated cryptographic keys. [0]
PCR: A Platform Configuration Register (PCR) is a memory location in the TPM that has some unique properties. The size of the value that can be stored in a PCR is determined by the size of a digest generated by an associated hashing algorithm. [1]
LPC: The Low Pin Count bus, or LPC bus, is a computer bus used on IBM-compatible personal computers to connect low-bandwidth devices to the CPU, such as the boot ROM, "legacy" I/O devices (integrated into a super I/O chip), and Trusted Platform Module (TPM). [2]
VMK: Volume Master Key. The FVEK and/or TWEAK keys are encrypted using another key, namely the Volume Master Key (VMK). Several copies of the VMK are also stored in the metadata. Each copy of the VMK is encrypted using another key, also know as key-protector key. [3]
[0] https://en.wikipedia.org/wiki/Trusted_Platform_Module
[1] https://docs.microsoft.com/en-us/windows/security/informatio...
[2] https://online.tugraz.at/tug_online/voe_main2.getvolltext?pC...
[3] https://www.forensicswiki.org/wiki/BitLocker_Disk_Encryption
Introduced around the time of Windows Vista by Hollywood to provide unbreakable HW drm throughout the OS.
I’ve never once enabled this malicious, user-hostile hardware.
TPM and trusted computering is an interesting case, it was originally planned to be the foundation of an unbreakable DRM system, however, this didn't go according to the plan. To this day, the most harmful result was Secure Boot and Boot Guard, but the TPMs are never used in any significant DRM systems. Today it's genuinely a security tool under user's control.
For example, see my explanation of how TPM-backed verified boot can help ensuring integrity of BIOS and bootloader.
https://news.ycombinator.com/item?id=18034227
Quote Richard Stallman,
As of 2015, treacherous computing has been implemented for PCs in the form of the “Trusted Platform Module”; however, for practical reasons, the TPM has proved a total failure for the goal of providing a platform for remote attestation to verify Digital Restrictions Management. Thus, companies implement DRM using other methods. At present, “Trusted Platform Modules” are not being used for DRM at all, and there are reasons to think that it will not be feasible to use them for DRM. Ironically, this means that the only current uses of the “Trusted Platform Modules” are the innocent secondary uses—for instance, to verify that no one has surreptitiously changed the system in a computer.
Therefore, we conclude that the “Trusted Platform Modules” available for PCs are not dangerous, and there is no reason not to include one in a computer or support it in system software.
Anything that has hardcoded nearly-impossible-to-extract keys which you don't know, is not under your control.
Working in the 16-bit boot loader places some serious restrictions on numeric text entry. If you have to consider the 100 or so keyboard layouts that windows supported at that time, so the pin was required to be entered using function keys F1 F2 etc. because they’re on all keyboard layouts
Source: I was on the Palladium/NGSCB/BitLocker team from 2002-5
That way, the OS can get to the login prompt entirely without secret data.
Obviously that's a big architecture change...
How accessible is this attack to the common person? Note that I am concerned about curious thieves as opposed to three letter agencies. I believe I would still be correct in saying that it's still really hard for your average person to extract data from a plain-TPM encrypted Bitlocker.
Are there commercially available TPM adapters that make the attachment easier for example? It looks like their attachment technique could be refined with custom hardware.
It is troubling to see that Bitlocker+TPM is essentially just obfuscation though.
About difficulty: Given this article, I'd expect that most serious electronics hobbyists can currently do this. It's certainly not easy, but not that hard either. It wouldn't be too hard to turn this into a tool which can be used by anyone with a screwdriver, like what happened with the iPhone [0]. But again, why would a common thief bother to do this?
[0]: http://www.iphonehacks.com/2015/03/this-tiny-box-uses-brute-...
For businesses that need to protect internal or customer data, the correct answer is requiring a PIN on boot, as this prevents the TPM from sending the key without receiving the PIN.
And it really shouldn't be surprising that if a computer doesn't require any user interaction before decrypting a drive that retrieving the encryption key is going to be relatively trivial if you're willing to put in some time and money.
Does the TPM have a mechanism to lock out if the PIN is entered incorrectly? That sounds like a good move to me.
So there is a vast middle ground between naive miscreants on one end and three letter agencies.
But if you are asking whether a casual thief who steals a company laptop out of a car cares about your data? Probably no. They will wipe the drive and sell it on Craigslist. However if someone might actually target you specifically, bitlocker+tpm is not a high hurdle. But then again nor are the weak passwords your users are using, or the phishing emails they will open, or the malware apps they will install...
All security is obfuscation really. Just moves the bar higher to deter those who don’t care or don’t value your data enough. The author hinted at some techniques you can use on boards to thwart (but not prevent) a determined hacker (still not three letter agency level). Chip cos have access to all sorts of equipment to probe and access chips themselves, so even inside the chip is not safe without specific countermeasures. Three letter agencies do chemistry at government lab facilities. That’s way beyond what most people care about.
Regarding annoyance, one of the most significant inconveniences I've experienced is the inability to boot when the hardware changes significantly, e.g. installing a new graphics card.
Fortunately the solution is easy: boot with the old hardware configuration, pause Bitlocker, install new hardware, resume Bitlocker. I feel this is safe as it requires you (with your PIN) to unlock the drive to perform the pause operation.
For some reason, if you have a TPM installed you need to jump through hoops to add a pre-boot PIN, and more so if you want to enable a pre-boot password. I had to flip various Windows security policy settings before it would work.
a TPM and pre-boot PIN/password work against different attack vectors - I really don't understand why Microsoft would want to hide these options.
Sad however, that the only additional defense appear to be "more blind trust in hardware" and no option for key derived from a passphrase.
We know from the Xbox hack that keys in cheap hw isn't secure (enough).
https://www.windowscentral.com/how-use-bitlocker-encryption-...
I consider it a pretty awful state, when what you probably want: no way to decrypt drive contents based only on what you get when you steal a laptop - the user has to go through extra work.
I suppose I can understand the preference for a "secure" key storage protected by a pin - over a complex pass-phrase. But I don't understand why it's easy (or even possible) to activate bitlocker with a largely unprotected key in "safe" storage.
Then, sure, you could keep the data encryption keys within SGX, but the decrypted data is going to come out of it. So, once you have the password, you can ask SGX to decrypt the drive for you.
I don't see how SGX is well-suited for drive encryption use cases. It's mostly for trusted execution.
Sure, one could then run this enclave under malicious control, but the attacker now has to do that live while the TPM thinks the system is okay. This requires active attack instead of passive attack. (Or it requires a DMA attack.) So the bar is a bit higher.