Breaking Bitlocker – Bypassing the Windows Disk Encryption [video] | Hacker News Reader

Breaking Bitlocker – Bypassing the Windows Disk Encryption [video]

youtube.com

111 pointstkems69 comments

Very interesting video. For those who can't watch, he creates a PCB with a RPi Pico and some data pins which can sniff the BitLocker key as it's sent from the TPM chip back to the CPU. I was surprised to see that this was sent in plaintext, so although his board probably will only work for that particular motherboard, the method would be sound for other computers as well.

I'll leave the comments about MS requiring TPM chips for Win11 to others.

It's a bit of a chicken-egg problem when the TPM is the root of trust for the entire system. Sure you can encrypt the data on the bus, but where do you store that key?

You don't need to store that key anywhere, just like you don't need to store any keys to validate TLS connections.

TPM can always store the (root) private key inside the TPM, but where will the other side of the channel (CPU, HD etc.) store their private key?

It could be burned into the CPU die by blowing fuses, or stored in a tiny bit of on-die flash, or stored encrypted in SPI flash, encrypted with a factory secret key burned into the CPU at manufacture.

But more generally, you don’t need a long term key to prevent sniffing attacks like this; Diffie-Hellman is a thing. Doing an unauthenticated DH would make this attack harder and slower (active MitM probably requires removing the TPM chip from the board) but would not prevent it.

Maybe it would be more practical MITMing near the CPU. Some plastic "extender" routing the relevant pins through an external device but still allowing for cooling?

But could the communication be authenticated? Like in CPU having a public cert, self signed. TPM then can authenticate the CPU that generates the key and later sends it only over an authenticated TLS session to the same CPU.

You use a Diffie-Hellman key exchange, signed by a cert stored in the CPU on one side and verified by the TPM on the other. CPUs already have such secret certs inside of them, for example for Intels' SGX.

But as you can read in the article linked by /u/osy, the TPM ecosystem is a victim of design by committee where such things as a threat model are not a thing. They were focused on building a "generic security solution" or some other nonsense, instead of making a threat model, then a protocol, then a verification of the protocol under the threat model - like people did for example with TLS 1.3.

> instead of making a threat model

because they want the threat model to be "what any customer who is going to buy this shit might have as a threat".

Or you use fTPM, the one inside your CPU, which is how most computers that run Windows 11 (without bypassing the restrictions) do it.

Unless you happen to have an fTPM that is permanently vulnerable to such attacks: https://www.amd.com/en/resources/product-security/bulletin/a...

Exactly. An attacker that has full access to the device can get past encrypted TPM parameters, it would just slow them down. The best method is pre-boot auth where the TPM itself requires a PIN to release the keys. Windows doesn't use that by default, but it can be enabled.

TPM 2.0 provides encrypted sessions specifically to handle this problem.

Of course you need to first use them...

No big deal here. This attack looks like it's using a crusty old TPM 1.2 laptop, so encrypted parameters to the TPM aren't supported. Even with Win11 and TPM2.0 (required for Win11), encrypted parameters to the TPM would just slow down an attacker.

You need to use pre-boot auth, like a PIN. Obviously, the TPM needs to have some kind of authentication to release the key, not just the default mode where Windows just needs to request it. This is all outlined in MS documentation: https://learn.microsoft.com/en-us/windows/security/operating...

TPM without PIN is the default configuration, so I'd consider it to be a big deal.

The age old battle of security vs convenience. Most Linux distros don't force you into pre boot, PIN TPM encryption either.

It is controllable through group policy, so orgs that care can force users into it.

I agree. It seems Microsoft wants to get the accolades of solving a hard key exchange problem without actually solving that hard key exchange problem. We see this a LOT in companies that "make it easy" to do cryptography.

With an ISO install, only 1.2 is required for Win11. TPM2 ia inly required to get the update offer from 10.

You can also set a registry key to ignore TPM/CPU requirements with the regular upgrade tools.

Interesting...

A PIN auth step eliminates the convenience value proposition of a TPM.

Selling passwordless authentication as a solution requiring a PIN just isn't recognizing that the PIN is now the password.

I think that's a bit of an overstatement. You already enter a password to sign in (or not, if you use biometrics). This is just another password that you enter once at boot. Doesn't seem all that bad of a tradeoff for data security.

You're forgetting the other convenience value of the TPM in Windows, which is that it allows you to use a PIN/bio instead of your (hopefully) long and complex account password.

TPM is insecure against physical attacks by design: https://gist.github.com/osy/45e612345376a65c56d0678834535166

The only secure implementation is called D-RTM which requires a level of chip, OEM, and OS support that's not done in practice.

I hope this attempt at shoving hardware DRM down our throats tanks just like the last one did.

It's not actually used for DRM, that's part of Intel ME and why AMD PSP is closed source. Both of those are involved in setting up "protected media path" which is all about setting up encrypted channel between display and media player to prevent sniffing.

TPM could be used for DRM in the sense that DRM software could refuse to run on system that isn't approved, but it's not going to stop you from enjoying a DRM free system - in fact it can help by explicitly supporting clearing of TPM state by owner.

Having a non-zero attack surface doesn't mean your security system provides "zero practical security". This is at best equally as hyperbolic as the vendors' own marketing claims that you are arguing against.

Not really? Encrypted sessions block the trivial attack of just watching the secret go across the bus. Pushing people to MITM attacks is already an improvement, and while generating initial trust in the TPM for that purpose isn't straightforward, it's not impossible. The almost universal implementation of TPM-backed secret management isn't secure against physical attack, but that's very different to "insecure by design". All the primitives to make this work reasonably are there, OS and firmware vendors just aren't using them.

>All the primitives to make this work reasonably are there, OS and firmware vendors just aren't using them.

To be precise, both Windows (according to the article) and Linux+systemd (since systemd v251) support letting the user specify a TPM PIN and then use parameter encryption. But yes, both make it optional.

Yes really. The lack of any working implementation in production systems is an issue (D-RTM + encrypted sessions), something that Apple has done in an equivalent threat model since the iPhone 11. You can argue that "insecure by design" doesn't apply because there is a secure design in the abstract but the fact that nobody has adopted it in 20 years says something about the design itself.

It's _also_ insecure by design because in every deployed implementation (including with PIN), it is S-RTM meaning that _any_ UEFI driver vuln will compromise your TPM key. Yes, any UEFI vulnerability in its countless vendor drivers, USB stack, network stack, etc.

There is nothing that is safe against physical attacks practically. You can always find a point where you can do a MITM attack as the communication channels between the TPM and anything else is almost always insecure.

>There is nothing that is safe against physical attacks practically.

This! If security is your prime directive in your line of work(government, highly sensitive data, etc), then as long as your device has been outside your physical possession and in the hands of an untrusted third party, then it's automatically considered compromised and gets wiped or discarded by your IT department.

Because no amount of marketing security fluff from Microsoft, Apple, Google can stand against targeted attacks of state actors or knowledgeable motivated well funded actors with freshly acquired zero days.

The security they provide is only good enough against the average thief off the street, which I guess covers 98% of Average Joe's threats.

Even CC security certifications never judge a device whether it's hackable or not, but only on how long it takes for it to be hacked by an accredited lab, because nothing with outside physical access is ever unbackable. With enough time and six figure equipment off the publicly available commercial market, everything reveals its secrets eventually. And that's without zero days off the black market.

Also, physical security is sometimes the best thing because it maps well to all of our human intuitions and senses for enforcing it and detecting when it was violated.

Consider how different a wireless hacking attack is from one where somebody has to sneak up and stab your device with an RJ-45 plug.

> only good enough against the average thief off the street,

Even there, only Apple has effective protection against street-thieves. Nearly all other models of phones/laptops can have their anti-theft features reset by a guy in a dark alley with a flash programmer...

So far, most thieves aren't interested in your info, they just want to reset the hardware and give it a new serial number.

Most other makes of phones and laptops aren't as valuable as Apple's to be big targets of theft. And Samsung has KNOX and Pixels have Google's Titan security.

Only a sith deals in absolutes (jk). Even with physical access, you can define restrictions that introduce some level of difficulty for a threat actor with limited capability. For example, you can just kick in most house doors to get past locks, but people still lock their doors. Cars are a better example, most car theft happens when people leave their doors unlocked.

Sure, but there are many shades of gray. Directly leaking the entire key on an external bus is very different than needing to find and somehow bond to individual traces (likely below the top metal layer) on the die itself.

I use to work in Microsoft DRM. I used to say: the key is on the machine! This is like leaving your house key under a rock in the garden. It just puts up a barrier of a certain level which puts off most villains.

If you want secure Bitlocker, use a password.

DTRM is offered with some Secured-Core machines that support Firmware Protection, is it not?

Nothing new. This attack is demonstrated here many times and the Microsoft docs discuss a similar attack using self encrypting drives. The counter measure is to use a virtual TPM built into the CPU or to use TPM+PIN (which is standard practice for security).

Another piece is to use encrypted session where the traffic between OS and TPM is encrypted as well.

Does Microsoft Pluton [1] help here? I noticed at least some recent ThinkPad AMD models support it.

[1] https://learn.microsoft.com/en-us/windows/security/hardware-...

Yes, it does, as does using any other CPU or chipset based TPM (Intel PTT, the AMD PSP-based TPM, running in Trustzone on ARM). The non-Pluton approaches potentially have greater overall attack surface, so Pluton is probably the best choice if available.

This is particularly interesting considering that TrueCrypt recommended migration to BitLocker as the main option for Windows: https://truecrypt.sourceforge.net/

IIRC Apple's version of TPM (Secure Enclave) should be immune to such attacks (since it's on the SoC, but I'm not sure whether the communication is encrypted or not), and the main data encryption method for GNU/Linux (LUKS) does not utilize TPM by default (might depend on distro though).

EDIT: I believe that the method in the video only works for volumes that aren't password/PIN-protected.

If you worry about someone sniffing your hardware buses, you should also worry about them intercepting your keyboard connection when you type the TrueCrypt password.

Does seem laughably easy to intercept the keyboard connection.

The problem is that they can sniff the bus at their convenience after grabbing the hardware and running. No need to hide a keylogger.

TPM 2.0 supports encrypted sessions, which block this kind of attack (TPM 2.0 is wholly different beast than TPM 1.x series).

I do not recall if cryptsetup's TPM2 support sets up encrypted session, but for BitLocker just setting it to require PIN breaks this attack (the PIN is used as part of TPM policy preventing automatic decryption).

Additionally, some laptops at the very least attempt to erase TPM on case open.

I think the "on case open" bypass was shown quite well in this video (the picture of the Surface device with a hole drilled in the back).

Such measures should protect against backdooring attempts (by the visible physical damage to the case) but they won't prevent an attacker from reading the secret key.

Worth noting that modern AMD CPUs incorporate the TPM functionality in the CPU itself, not sure about Intel.

AMD calls it fTPM (Firmware TPM I believe) and Intel calls it PTT (Platform Trust Technology)

The most recent AMD CPUs, Zen4 also incorporate Pluton, the TPM designed by Microsoft based on Xbox security experience.

Also given AMD's repeated bungling of the fTPM, Pluton is probably the better option if you must enable one.

Didn't know! After TC vanished with recommendation to use BL I had kept few files in direct Windows storage protected by BL. The more sensitive ones I still kept in Vera. Here my natural scepticism protected me lol.

Guess turning on pre boot pw is next thing to do.

Note: there's also Bitlocker for non-boot drives, aka Bitlocker to Go. It functions more like TV/VC in that you can encrypt a drive/partition/removable storage with a password. You probably don't want it to auto-unlock in that case.

I predict that this will necessitate an upgrade to TPM 3.0 with a key exchange handshake mitigation along with it being a requirement to upgrade to Windows 12. That’s fine though because it will help with economic growth and all the relevant companies’ bottom lines.

TPM2 already has encrypted session support which does exactly that.

To decrypt a drive with a TPM-only key you just need to turn on the PC. So what's the big deal here?

It's disappointing that TPM-only is the default for Bitlocker, but you can just use something else (pin/password, key file, ...).

These kinds of attacks aside, the intent is that you need to turn on the PC and then actually boot to the intended operating system, which is then protected with a login screen

Except that if you can sniff the encryption keys, you can tamper with the OS and for example remove the password...

That's why I caveated my explanation with "these kinds of attacks aside": this video describes such a bus sniffing attack

I've read your message too quickly ;)

Yeah fair enough. The login screen should still provide good protection in a TPM-only scenario. (Although it had some vulnerabilities in the past: https://secret.club/2021/01/15/bitlocker-bypass.html)

I think TPM-only encryption is still good enough for cases where a thief may try to swipe the hard drive out to steal the information on it later.

Plus, in a business where laptops may get reused, it could be a method to make an old Windows install inaccessible by wiping the backup key from the cloud and clearing the TPM on the device without any formatting. You may want to do a quick format to be sure (you never know if someone kept their private files in the EFI partition) but it'll protect you against data recovery risks from reassigned sectors without having to force everyone to enter a password twice every time they boot their laptop.

The default is an unencrypted computer. Microsoft is trying to improve that default without requiring yet another password.

The "big deal" is just seeing it demonstrated this quickly. TPM-Sniffing is an old hat [1], but I always thought it would take at least hours of painstaking fiddling with a soldering iron. I find this video impressive and eye opening.

[1] https://www.orangecyberdefense.com/ch/insights/blog/tpm-snif... (2021)

This presumably applies to any FDE utilizing TPM, not just BitLocker.

Modern systems don't have a dedicated TPM, so it's a lot harder to read the settings off the chip, as it is part of the CPU.

Then I believe modern TPM communication is encrypted.

On too of that you want your laptop to support physical tampering resistance, which prevents both this (outdated) chip attack and freezing the RAM. When you then boot the laptop the master password is required. I would prefer it to throw off the PCR but hey, it works too.

I do wonder if you have 8GB of soldered RAM and 8GB on a stick, Windows keeps the key in the soldered part to increase difficulty stealing?

I'm lead to believe the TPM is a firmware TPM and not a hardware one. Is this correct?

Opposite - the TPM is hardware TPM and that's why it was easier to sniff the communication between it and the CPU over LPC. fTPM resides inside the CPU so sniffing is not as easy.

That's compelling. I understand fTPM is less resistant to system level attacks because of the virtualization nature of it. Seems like a conundrum of tradeoffs.

Reply on news.ycombinator.com