BitLocker encryption broken in 43 seconds with sub-$10 Raspberry Pi Pico

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)

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

Don't all TPUs use the same protocol? In any case, a basic sigrok-supported logic analyzer is only another $10.

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

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

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.

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.

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.

I’m also confused. If a laptop is stolen while off, can this attack still be applied?

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.

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

I don't think this applies to ones embedded in CPUs?

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

TPM integrated/embedded to the CPU is the most common way of having one and they are not vulnerable to this exploit.

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.

Worthless? Really? Laptops stolen every day are breached by all those thousands of thieves with logic analyzers bitbanging TPMs?

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.

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.

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.

Please no! When I last worked with physical servers we were replacing tpms all the time...

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.

This usually shows up in the UEFI settings, where you can also toggle it on or off.

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.

Pretty much any CPU made after 2018.

All mainstream AMD and Intel processors today do.

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

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.