Hacker News new | past | comments | ask | show | jobs | submit login
Extracting Bitlocker Keys from a TPM (pulsesecurity.co.nz)
112 points by hongseleco 43 days ago | hide | past | web | favorite | 40 comments

I find the title is misleading, it did not "extract" Bitlocker keys from the inside of a TPM at all, but merely sniffed the key material on the bus. I was so excited to see the title, and so disappointed after reading it...

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".

The described attack allows you to recover Bitlocker keys and decrypt the harddrive from any random computer that you have physical access to, since when you boot it the key will be sent over the LPC bus in a way that can be extracted. I'm not sure what the distinction you're making is, given that the probability that someone ends up with access to a TPM but not the system it's associated with is basically zero.

> This post will look at extracting the clear-text key from a TPM chip by sniffing the LPC bus

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".

Honestly it feels like splitting hairs, unless I'm misunderstanding something.

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?

> What is there to gain "cracking" the TPM itself, if you can get the keys fine by sniffing?

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.

> What is there to gain "cracking" the TPM itself, if you can get the keys fine by sniffing?

The ability to forge remote attestations by extracting the endorsement key or various attestation identity keys that never leave the TPM in plaintext.

Ah I see, they can successfully protect asymmetric crypto but not symmetric.

> What is there to gain "cracking" the TPM itself

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]?

[0] https://xkcd.com/538/

I’m not convinced it would be a world first. Certainly not for nation states :) but you should definitely check out the amazing work by Chris Tarnovsky on YouTube. The level of detail he goes into when decamping the chip... and the way he explains it all leaves me in a state of awe.

Maybe nation states is a different case. When I say "world first" I mean "that we know of". But otherwise it's incredibly interesting to see work like this especially when it's about something so obscure and undocumented that the researchers have to dig up every single bit of information by themselves.

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) :).

I get what your saying, but if the end result means that they were able to get the encryption keys, what's the difference?

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.

> 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?

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.

I knew several of the acronyms in the article but some were new to me. Here are some references in case anyone is in the same boat.

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

> 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]

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.

Security modules are prone to abuses by various interest groups, but by themselves, they are never inherently evil or even desirable if it has an open standard, and is under the control of a user.

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.


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.


Today it's genuinely a security tool under user's control.

Anything that has hardcoded nearly-impossible-to-extract keys which you don't know, is not under your control.

FWIW in the earlier days of BitLocker (when it was called cornerstone) a preboot PIN was considered then default secure setting.

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

Perhaps it's time to move towards the Android/iOS model of having the OS unencrypted (since that isn't a secret anyway), and only do encryption of all the user data and apps.

That way, the OS can get to the login prompt entirely without secret data.

Obviously that's a big architecture change...

At a bare minimum you still need to sign the OS in order to prevent tampering.

How would one guarantee the integrity of the OS?

Secure boot.

Given Microsoft's response, it seems this isn't new. I'm in charge of my company's security so now I'm a bit concerned. I mandated the use of Bitlocker with TPM across the business but no pre-authentication measures.

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.

Common person? No. If you are a common EE grad student, no problem. However could someone take it to a nefarious local PC repair shop with better than average skills and pay someone? Yes.

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.

The Bitlocker + TPM without PIN model is primarily aimed at preventing the contents of a drive from being accessed from a different system - you can send your old drive to the recycler without worrying about someone hooking it up to a different computer to scan for financial information or passwords.

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.

I suppose in retrospect it shouldn't be surprising. I just thought it would be a lot harder than this. I imagined that the communication between the TPM chip and the CPU would be encrypted somehow; I should have verified that.

Does the TPM have a mechanism to lock out if the PIN is entered incorrectly? That sounds like a good move to me.

Yes. By default you get 3 or 5 chances and then you have to use the recovery key. In corporate environments the recovery key is often stored in AD or another location by default so it's retrievable by IT (whether because the user entered the wrong PIN or because they quite /were fired and you still need to be able to get data off the computer.

You're probably fine. Adapters do exist which make this a bit easier, but it's still going to be at least $100 in custom hardware. A curious thief is not going to bother with this and will just wipe the disk when they notice it's encrypted.

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-...

Ahhh, I was very concerned until I got to the part about pre-boot verification. That is definitely a critical part of full disk encryption, and should really be the default. (Although I’ll admit that it’s really annoying sometimes.)

I agree the pre-boot verification and PIN should be a default. Otherwise, just having the hardware makes it insecure. All hardware is insecure with physical access of course, but it should be more difficult to access even for someone with a logic analyzer.

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.

I guess "standard" bitlocker is just a defense against the "legacy" attack of someone stealing/mirroring your hd;not a defense against the more likely "current" attack of someone stealing your laptop :/

When I first setup Bitlocker on Windows 10, I was hunting for the option to enter a pre-boot password, but couldn't find it. I don't even think it have me the option of entering a PIN.

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.

Yeah, I had to jump through the same hoops. They're really odd, and they seem like low hanging fruit in terms of improving the customer experience for BitLocker.

Very nice article. I was pondering the same attack surface when using luks-tpm2 package on Arch that works just like Bitlocker in basic (non PIN) configuration.

This is excellent. I've been wondering/troubled about the ease of use of bitlocker. Nice to get confirmation that standard bitlocker is rubbish against real attackers.

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).

You actually can configure Bitlocker to accept a passphrase instead but the option isn't easy to find.


Now that you mention it, I was actually aware of this possibility. But it feels a little counter-intuitive to disable security hw in order to get secure 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.

SGX could mitigate this — it’s much more resistant to this type of attack than the TPM.

How? The lack of trusted I/O in SGX seems like it would make secure disk encryption rather hard. You still need to use something like a password for access control. While it can be mixed with a key in SGX, you have to get that password into SGX from untrusted space. At least in the TPM architecture there's some effort to establish a trusted pre-boot environment where you can enter a password/PIN.

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.

You make a little enclave that (proxied through the host) gets the TPM to attest online to the relevant PCRs. Then the enclave gives the host the VMK.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact