BitLocker encryption broken in 43 seconds with sub-$10 Raspberry Pi Pico
tomshardware.comThe title makes it sound like Bitlocker's encryption is what was being broken, but what is broken is the key exchange on some laptops. The same vulnerability also affects LUKS2 and any other transparently encrypted system using a dedicated TPM chip for encryption.
Developing the exploit itself also took significantly more than $10, it's not like you can just hook up a Raspberry Pi to any circuit board and start bit banging blindly. Without a scope that supports digital signal processing, you'll struggle to adapt this attack to TPMs that speak a different protocol.
It's a shame that there's no E2EE between the CPU and the TPM, but luckily on many modern devices with fTPMs this attack doesn't apply. Unlocking your disk with systemd-boot will still be relatively safe.
On affected systems, the workaround (a TPM PIN) still leaves for a much more secure encryption system than a plain password would, assuming you have stored your backup key somewhere safe.
Your point about a TPM PIN being more secure than a password doesn't make sense. Both are passwords. If you're assuming the user stored their PIN safely, then you can also assume they would store their password safely.
Your broader point is fair though. Because this explout is nullified by a built-in TPM (already here) or the lanes being end to end encrypted (ship has sailed)
One is a password, the other is an unlock phrase for a securely generated key. Password based keys need to go through PKDFs and have limited entropy.
A "PIN" in the TPM sense is alphanumeric and will be entered the same way the user enters a passphrase, except the secret that actually protects the disk isn't derived from that passphrase.
It's much harder to brute force a TPM PIN than it is to brute force your average PKDF function. The brute force complexity grows to encompass the full key space rather than the key space of a key derived from memorable alphanumeric text. With a proper passphrase this probably won't matter much in terms of feasibility, but a lot of users pick terrible passwords that are easy to brute force with a whole bunch of servers, while with a TPM chip an attacker would need to choose another method (i.e. attacking the TPM itself).
Security in depth.
TPM+PIN prevents taking/imaging the drive and trying an offline attack.
And TPM is rate-limited, another security in depth feature.
I think they mean a Windows password. You enter it after the disk is already decrypted.
There is E2EE! The spec defines it! It works! But Bitlocker doesn't use it (systemd-cryptenroll does), and as a result is vulnerable to this attack.
As far as I understand parameter encryption, there are still ways to compromise the key if you don't use the TPM PIN, because of the difficulties of establishing trust between the TPM and the CPU and the risk of a MitM attack. This makes it much more difficult to attack the TPM, but the underlying challenge remains.
I'm happy that systemd-cryptenroll does what Windows failed to do, though. I can't fathom why Microsoft would make it do easy for an attacker to bypass Bitlocker's encryption like this.
You dont need expensive scopes (digital signal processing? you mean fancy decoders?). All you need is LPC development board. LPC is just serial ISA bus.
>Developing the exploit itself also took significantly more than $10
Less. You can perform same attack using $6.44 Free International Shipping "EZ-USB FX2LP CY7C68013A USB2.0 Core Boards Logic Analyzer" ebay board and https://sigrok.org/wiki/Protocol_decoder:Lpc
Don't all TPUs use the same protocol? In any case, a basic sigrok-supported logic analyzer is only another $10.
Yes, and yes - the LPC bus is standardized, and TPMs need to use the same protocol to enable them to be modules on the motherboard.
And yes, it's only $10 or thereabouts for a logic analyzer that can decode LPC bus communications.
2019 ref - https://pulsesecurity.co.nz/articles/TPM-sniffing
Some processors have a 'Firmware TPM' or 'Platform Trust Technology' where the TPM is integrated into the CPU itself, meaning no wires to probe/interpose.
RAM, PCIe and USB remain unencrypted though so you can just interpose one of those if you're performing an evil maid attack.
Recent Intel/AMD CPUs feature transparent full memory encryption.
Recent AMDs have another feature called SecureBio(metrics) which directly connect one USB socket to the CPU in such a way interception is not possible, which allows one to design a secure USB device (fingerprint reader, webcam for now) which can't be intercepted at the bus level.
PCIe is still vulnerable, but I bet it won't be long before transparent encryption comes to it.
Many of them use LPC, but LPC isn't the only protocol used, as I found out in my attempts to find a TPM for my desktop.
> Without a scope that supports digital signal processing, you'll struggle to adapt this attack to TPMs that speak a different protocol.
It's like with console modchips - once someone has developed an attack, every highschooler with a soldering iron and moderate skills can do it.
>The title makes it sound like Bitlocker's encryption is what was being broken, but what is broken is the key exchange on some laptops.
If the KEX is broken, the encryption is broken.
I think OP’s point is that singling out BitLocker when the attack is not specific to it is misleading. It leaves the wrong impression that other methods relying on the same key exchange mechanism are safe.
Name dropping BitLocker was one sure way to gather attention for something that had been proven years ago, and had already reached a “close enough for all intents and purposes” price point [0]. Not unlike name dropping Tesla or Apple even for mundane things.
A researcher found that the communication lanes between the CPU and external TPM are completely unencrypted on bootup — enabling an attacker to sniff critical data as it moves between the two units, thus stealing the encryption keys.
I say its more likely the researcher found article from 2019 https://pulsesecurity.co.nz/articles/TPM-sniffing describing this very attack vector using FPGA dev board. The only novel thing here is price point going down by a factor of x10 to $5-10.
I’m not completely sure about the attack scenario here.
It seems that a bitlocker key is stored unencrypted (no master password) on the TPM device. This seems to imply that I could boot the laptop without entering a password anyway, and get access to the disk. What would the point of such external device be?
Is bitlocker designed to only prevent stealing the hd separately from the laptop?
Or is anything in the protocol that makes it so that the boot code, after reading the master key, forces the user to enter a password nevertheless to access the hard drive contents? But it still looks like that if I can hijack this boot process (external usb boot?) I could get access to the drive contents.
Disclosure: unfamiliar with bitlocker but I have used and understand FDE on Linux and FileVault.
The TPM collects some measurements to verify that you actually booted to the correct operating system before releasing the key. From there, the system is protected by the operating system's login screen.
The core concept that makes TPMs work (in this usecase) is the Platform Control Registers (PCR). The idea behind the PCRs is to allow the TPM to know that the overall system is in a known state.
In particular, there are 2 operations that can be performed on a PCR: read and extend. Read does what it sounds like, and gives you the current value of the PCR. Extend concats the current value of the PCR with a provided value, and hashes the result back into the PCR: PCR[i] <- Hash ( PCR[i] || data ).
The TPM also has a small amount of general purpose non-volatile storage (NVRAM). It lets you "seal" entries in NVRAM such that it will only give you them if particular PCRs have particular values.
UEFI along with most modern bootloaders and operating systems incorporate this into the boot process such that a component will measure all critical configuration parameters and executables before operating on them. To take your USB boot example, before the UEFI boots into your USB it will measure (at least) the bootloader on your USB drive. As soon as that happens, there is no way to get the PCRs into the required state without breaking the hashing algorithm. Even if your USB drive uses the window's bootloader, the UEFI likely measured other things, such as the device it was booting off of, and possibly your entry into the one-time boot menu [1]. Even if you get through all of that, the Window's bootloader probably measures the code it runs. By the time you get to code you can actually change without invalidating the PCRs, you are running inside of Window's userspace subject to normal software security measures; and Window's might have already modified one of the appropriate PCRs (or simply locked the NVRAM for further reads until system reset).
There are several potential problems with this:
1) It assumes that all of the components in the chain are secure and do the right thing. If you can convince one to run your code without changing what it measures, then you can attack the system.
2) It assumes the entire system is an atomic unit. If you can talk to the TPM directly, you can simply measure in the same values that get measured during a normal boot, weather you are actually booting, or have the TPM on a breakout board. The measurement inputs to the TPM are not secret. They are just hashes of firmware, kernels, etc.
2.5) What this paper talks about, none of the communication to/from the TPM is encrypted.
TPM backed FDE exists on Linux as well and is vulnerable to the same class of attacks.
Some systems have the TPM integrated into the CPU itself, which makes such an attack practically impossible.
[0] Or, at least the initial bootloader, which is then responsible for measuring the kernel, which is then responsible for measuring the core OS components, etc).
[1] Although, these things are done in a seperate PCR, and BitLocker probably doesn't use all of the PCRs. You don't want to brick a system by simply changing a random setting in the bios.
Great answer! Thank you so much!
I’m also confused. If a laptop is stolen while off, can this attack still be applied?
Yes.
That’s not good.
Would be this something that can be avoided by setting up BitLocker with the encryption password to be provided at boot time by the user? Because that's the way I've always configured it when I've used Windows in the past, due to me being paranoid and suspicious about the default "key saved on TPM" approach.
Yes, if the key isn't in the TPM then it can't be sniffed. Secure boot would need to be enabled to protect against the threat model bitlocker is only good for here. Alternatively using a PIN would mean the key is only exposed once the PIN is typed (still vulnerable to a hardware attack, but requires physical modification).
See also this HN thread from 3 days ago:
Breaking Bitlocker – Bypassing the Windows Disk Encryption [video] https://news.ycombinator.com/item?id=39243305
Yet more evidence that TPMs, as commonly implemented in consumer devices, are worthless security theater.
TPM integrated/embedded to the CPU is the most common way of having one and they are not vulnerable to this exploit.
I disagree. Is locking your front door worthless security theater if a thief can just smash the window? Some actors are more opportunistic (or stupid) than others and not everyone can have (or wants) bars across their windows.
Similarly, BitLocker with a TPM may not be impenetrable, but it does stop a kid from booting Hiren's and running ntpasswd to change the local admin password and install Roblox on mom's work laptop. Or the employee dumping the SSD of company data before leaving for a competitor.
Not every security measure needs to address every threat entirely. This is why we have risk assessments and defense in depth. This exploit may change some people's calculations or it may still be worthwhile based on the balance of security to convenience. But that isn't worthless.
Even in the older hardware from which this example that allowed this to occur, the threat to the "consumer" is the driver whose Uber you left your laptop in, for whom this attack is still out of the realm of plausibility.
I don't think this applies to ones embedded in CPUs?
They call that out specifically at the end, CPUs with their own embedded TPM aren't vulnerable to this kind of attack as all the communication occurs within the CPU itself.
Let me rephrase.
I know this attack doesn't apply to commonplace embedded TPMs.
I think the label of "security theater" doesn't apply to commonplace embedded TPMs.
"embedded TPMs" are not commonplace. Intel has been pushing this hardest, and Intel still includes the TPM on the motherboard chipset and not the CPU itself in all consumer models, as of the 13th gen, at least.
Intel PTT is now quite common, isn't it?
PTT is in the southbridge - That is, not the chip but motherboard chipset.
Southbridge was eliminated years ago. Intel PTT is present on the Intel PCH located on the processor die package, not a chip on the motherboard.
Isn't that only for laptop packages?
I can find lots of current motherboards with a chipset on them, even specifically calling it a PCH.
Yep, you're correct. I misread. The Northbridge has been eliminated entirely. PCH is separate.
Don't Zen 2-4 all have fTPM?
...but but but they are ISO certified!!!
The only thing that TPM prevents from reading your hard drive is jealous coworkers. Everyone else just steals your laptop and gets access anyways.
Even the BIOS passwords are utterly useless because you can google the master passwords based on Laptop and model number these days. And if you can't, just flash a BIOS without a password on the memory chip via a 5$ ch341 adapter.
As long as all hardware has backdoors for everything and nothing relies on real cryptography, there is no point in assuming it is secure.
Embedded TPMs are the exception, for now, until one finds the next backdoor of broken undocumented CPU instructions. TPM was claimed to be secure so often in the past, at this point you must assume that every implementation is broken by default.
Everyone else steals your laptop, reinstalls Windows and sells it round the corner for 100€.
I never claimed that data theft and fencing hardware are mutually exclusive.
You wrote "Everyone else just steals your laptop and gets access anyways". Nobody (as opposed to "everyone") will get access because nobody will try to do so. They will reinstall to resell.
This is not a matter of exclusivity but of probability. If you split the world into "jealous coworkers" and "everyone else" then everyone else who wants your laptop does it to resell it and not access the data.
There’s a certain Apple feature people like to hate on that works very well too…
Ah yes, because everything that doesn't solve every problem imaginable is instantly worthless.
Sorry for the snark, but I'm getting tired of the pervasive cynicism. The situation got so much better since tpm and fde got commonplace. Laptop thieves no longer get your data, people no longer unwillingly expose their data when they sell their used disks, boot loader attacks got from easy to almost impossible.
Yes, the CIA will still be able to read your disk, and maybe even just a motivated hacker. But that doesn't mean everything is useless.
Worthless? Really? Laptops stolen every day are breached by all those thousands of thieves with logic analyzers bitbanging TPMs?
This is not a BitLocker vulnerability - this is a vulnerability of the hardware design where a TPM module communicates with the CPU over an insecure channel.
It's a Bitlocker vulnerability to the extent that Bitlocker doesn't encrypt its communication with the TPM, which is a feature provided by the spec.
It's always seemed crazy to me that the TPMs are separate chips rather than being integrated with the CPU; at least in the same package if not on the same die. That would make the bar for attacks like this much much higher.
Please no! When I last worked with physical servers we were replacing tpms all the time...
Is that because you mismanaged their security features and locked yourself out but they were working as designed, or because they failed?
If the latter, I think we can expect a higher quality bar from an integrated solution. If the former, well, I guess that’s just a security trade off.
Do you mean due to failure (why?). Or else I assume you mean upgrading the firmware?
I don't get it. If the laptop can already boot up with the tpm and the attacker has the entire laptop, what exactly is broken here? Isn't the TPM mainly there to protect against decrypting the SSD when it's separated from the Mainboard. If windows boots up automatically the encryption key probably could be extracted from the memory somehow too, right?
The OS might have protections in place - modern CPUs support encrypted memory - or even just something as annoying as a login prompt it won't let you past.
Any attack to find keys in memory - unless you find a simple exploit for the login prompt - will be more complex than just booting the machine with that sniffer plugged in.
Which CPUs have TPMs embedded? How do I check if mine does?
Edit: Note I'm asking about CPUs specifically. Not other TPMs on the system.
CPUs? AMDs support running a TPM implementation on the PSP which is on-die. Intel has a TPM implementation running on the PCH, and on low-power mobile parts that's on-package with the CPU. ARM SoCs frequently provide a TPM implementation running in Trustzone, which is also on CPU. Some of the latest Ryzen parts implement Pluton, Microsoft's security core, which is typically used to provide a TPM without also doing a bunch of other stuff.
This usually shows up in the UEFI settings, where you can also toggle it on or off.
Er, shouldn't I be able to look this up from the CPU model number without buying it?
Also, are you sure you're not confusing CPU-embedded TPMs with other TPMs in the system?
It's up to your firmware to enable any CPU or chipset provided TPM implementation. The CPU supporting it is unhelpful unless the firmware provides a mechanism to turn it on.
But my question wasn't "how do I check if the embedded TPM is being used?", it was "how do I check if an embedded TPM even exists?"
It exists in everything x86 made since around 2014. Whether it exists usefully is up to your firmware.
All mainstream AMD and Intel processors today do.
Pretty much any CPU made after 2018.
I never liked the design of Bitlocker
- I always set a PIN. Wish it was a proper passphrase instead. The whole magic thing of decrypting things automatically seems like a total design flaw.
- I often disable the hardware encryption support. Some of these are total jokes. AES-NI is decent but it’ll reduce performance on faster SSD drives.
An unbooted FileVault Apple device just does not know the decryption key. Until you’ve entered the passphrase there’s no flaw in the OS or hardware that can give it to you. Such a cleaner design. So much safer no magic TPM BS. Same goes for my Linux/LUKS servers. No passphrase not boot.
> - I often disable the hardware encryption support. Some of these are total jokes. AES-NI is decent but it’ll reduce performance on faster SSD drives.
By 2% at the outside. Well worth it.
How it should work is that the passphrase to the machine encrypts the keys that encrypt the drive.
Yeah but people don't like typing in their password twice, if they even have one and don't use a fingerprint/face scan or something. I use an entirely separate and very long password for unlocking my device and for nothing else, but most people don't want to.