Am I missing something or is this the same TPM bus sniffing for the key exchange attack (from @marcan maybe?) that was detailed some years back but using a cheap Pi? Is this attack BitLocker specific somehow? It looks like it would affect LUKS or others just as well. Just trying to understand the novelty of this particular method or if it's tied to BitLocker in particular.
Anyway, not to detract from the nice work of the author or to tout my own horn but I can hack a lot of encryptions in seconds with a simple keylogger. For the sake of this exercise I'll consider the key exchange (user typing password) is an integral part of any encryption scheme :).
More seriously, I think fTPM or TPM+PIN+USB key would be good ways to avoid this scenario.
> It looks like it would affect LUKS or others just as well.
Except you can use good old password protected FDE on any major desktop operating system other than Windows Home Edition.
> I can hack a lot of encryptions in seconds with a simple keylogger.
A thief can't use your keylogger to decrypt a stolen laptop that's properly encrypted. A rogue recycling shop can't do that either. And kids won't be able to use, uh, Raspberry Pis to decrypt random Surface laptops.
So yes, it's kind of a big deal. People shouldn't have to worry about the TPM details of their devices to benefit from encryption in ways that protect against the most common threats.
But one could not do that and be just as vulnerable. Same as you can use a PIN on BitLocker and be safe in this case. Which answers my question that this is not something BitLocker specific, just a bit of name dropping to garner more attention. Which is fine from the original author, not so fine from the journalists that picked it up.
> So yes, it's kind of a big deal.
You're not wrong but also this is not new. On close read this is indeed the same attack detailed as far back as 2019, says the internet. Presumably a few dollars cheaper now.
Use an additional factor if you care about that data staying encrypted, it only takes a few seconds and could save you quite the headache.
> But one could not do that and be just as vulnerable. Same as you can use a PIN on BitLocker and be safe in this case.
Right, but BitLocker is vulnerable by default whereas LUKS is not, because BitLocker relies on a TPM without a PIN by default whereas LUKS relies on a password by default. Yeah, technically this attack ain't BitLocker-specific, but I don't know of any other FDE implementation that defaults to using a TPM without a PIN/password.
Previous discussions: "Breaking Bitlocker – Bypassing the Windows Disk Encryption [video]"[0](110 points, 3 days ago, 68 comments), "BitLocker encryption broken in 43 seconds with sub-$10 Raspberry Pi Pico"[1] (108 points, 11 hours ago, 62 comments)
I'm not familiar at all with this kind of low-level knowledge so probably a stupid question but: does that require the device to be connected when the user types their password to actually retrieve the key, or is it an actual "crack" as in it can unlock BitLocker without key nor password ever being inputted on the device?
It only works with Bitlocker which relies only on external/discrete (dTPM) key material and no configured PIN or password, so there is nothing to input. It’s just sniffing key material off of the external TPM bus after the bootloader asks for it. This is an ancient attack and not very technically interesting, but it comes up every few years because Microsoft still don’t switch to using TPM encrypted sessions.
This is for non-password Bitlocker with discrete TPMs that aren't configured to encrypt their exchange.
There's a mode of Bitlocker where it boots into a basic boot environment, asks the TPM for the key, the TPM validates the environment, and then gives the decryption key. For some discrete TPMs, this last step of the TPM giving the key to the boot environment is done in the clear and can be sniffed.
Impressive technical feat, even if not completely new.
However, as tech people we need to stop downplaying our accomplishments. “43 seconds” (plus the lifetime of learning that allowed them to figure out how to do all these things: decoding the wire signals, writing a custom firmware, knowing how to probe the motherboard for the correct signals, etc.)
Anyway, not to detract from the nice work of the author or to tout my own horn but I can hack a lot of encryptions in seconds with a simple keylogger. For the sake of this exercise I'll consider the key exchange (user typing password) is an integral part of any encryption scheme :).
More seriously, I think fTPM or TPM+PIN+USB key would be good ways to avoid this scenario.