How long does it take to steal your Bitlocker keys? Try 43 seconds, using less than $10 in hardware. Encrypting your hard drive is good security. If you’re running Windows, the most popular system is BitLocker, which has come with Windows since Vista. We’ve known for some time that Bitlocker could be defeated with direct access to the hardware. Microsoft claims that the process requires an attacker with skill and lengthy access to the hardware. [Stacksmashing] wanted to define lengthy, so he gave it a try. The result is a shockingly fast attack.
Anyone who uses Windows has probably run into Bitlocker. Your hard drive is encrypted, and Bitlocker runs silently in the background, decrypting data on demand. The problem is key storage. In a simplified sense, encryption keys are stored in the Trusted Platform Module (TPM). When your computer boots, it reads the key from the TPM over the LPC (low pin count) bus, which is one of the last remnants of the original ISA bus.
The problem is that the key can be sniffed as it passes on the LPC bus. Some laptops even have connectors and test points directly on the LPC. [Stacksmashing] takes advantage of the simple layout used on an older Lenovo Thinkpad (X1 Carbon 1st or 2nd Generation). Once the back cover is removed, Lenovo was nice enough to leave an unpopulated connector footprint on the motherboard. This was the key to stealing the key.
[Stacksmashing] used a Raspberry Pi Pico on a carrier board of his design. Pogo pins mounted on the end of the carrier board make it easy to probe the LPC bus.
To be fair, stealing the keys doesn’t give one the data on the drive. An attacker would have to take the drive itself or spend extra time transferring the data over USB. The X1 Carbon is a 10-year-old laptop, but at least it does have USB 3.0.
All is not lost though – more modern computers include the TPM inside the CPU itself. Sniffing that will take a bit more hardware than a Pi Pico. However, if anyone pulls it off, tell us in the tip line!
Thanks for the tip [YesterGearPc]
Yikes!
Not really a security threat to be scared of, if you need good security you shouldn’t be using Windows in the first place. And you shouldn’t be relying on “trusted” hardware modules, trusted by who? This hack might be pretty helpful for debugging crashed or otherwise damaged Windows machines though, unlocking them long enough to safely copy your data off before you give up on MS and install Linux.
This is not the fault of Windows, and Linux is no better.
The issue is that the discrete TPM chip can be probed. A simple and effective work-around is to use the fTPM inside your CPU instead. That still leaves the NVMe bus which can be probed, but it’s much harder to do due to higher speeds and lower voltage signalling.
Alternatively, just enable the PIN/password feature in Windows, and no attacker will be able to probe anything because it won’t release it until the PIN/password is entered. You can choose Bitlocker or sedutil.
On Linux your only choice is sedutil, and sleep support is still beta quality. TPM is not supported at all. Bitlocker supports sleep, but only one drive. Take your pick.
The best solution for most people is Windows with the key in the fTPM. Otherwise they need to remember two passwords, and maybe give up on sleep mode.
TPM spec provides for encrypted communications with the chip, which mitigates this issue, but the encryption is optional and so is not used widely. The fTPM is in turn vulnerable to software attacks (power glitching, debug access, decapping, etc), whereas discrete secure element chips presumably have better ‘physical’ security. Just need to use them with the provided secure communication.
Those handy mandatory backdoors in modern bioses probably have no issues in providing the TPM key to an attacker
Proof please?
Proof please that any bios is 100% secure *cough* pixiefail UEFI
They should mount the next Voyager probe to the goalposts you just moved.
Nobody asserted that bios is 100% secure, CJay asked for proof there’s a backdoor to access keys and that it is mandatory.
You don’t seem to understand what is happening here, or how the TPM works. Hacking the BIOS won’t get you the key from the TPM. It will only release it once Secure Boot confirms that it is the OS that created it which is requesting it.
fTPM remains secure as there is no way to probe it.
second law of thermodynamics, meet information theory.
Security, meet userspace convenience.
Hotel, meet Trivago.
That pun? Priceless.
For everything else, there’s Mastercard.
Hmmm so if the laptop is stolen, someone can crack the drive wide open and steal sensitive data. Maybe I need to pack in a bit of thermite right on the drive, ignition, and intrusion switch. If someone opens the laptop, the drive melts and becomes next to impossible to steal data.
I must keep my secret data on Jimmy Hoffa’s whereable a secret for a few more decades! /s
Just encrypt it with something that doesn’t store the key in an accessible manner.
LUKS (Linux full disc encryption) asks your password each time you boot and uses it to decrypt the drive. Without the pw it is really hard (brute-forcing it kind of hard) to get into your data.
It’s hilarious how much of a head scratcher this problem actually is. Solutions like intrusion based media destruction are actually a thing purely because everything else is an endless chicken and egg solution. Having systems that boot and ask for a pwd are fine (macos, linux etc) but running headless machines on customer sites with no supervision in ‘geopolitical areas with questionable IP protection practices’ is actually super hard. We’ve been working on this for ages and still don’t have an answer I’d call workable.
Just have the BIOS retreive the key from the keyserver, of modify Wake-on-LAN to the specific computer is sent a wake-up request together with the required key. I can see a number of workable solutions that cover the risk of theft and other non-complaint removal of hardware, but since it’s not implemented, i guess the problem is not perceived as serious enough.
Any answer to a technical problem that starts with “Just” is almost by definition overlooking a mountain of difficulties. Or perhaps a better geographical analogy is a bad lands of difficulties: the answer is right there, but the route to get to it is a maze of pitfalls and blind valleys.
It has its limits and fiddly behaviors; but the Bitlocker “Network Unlock” key protector is supposed to support that scenario; with the intended/example implementation being systems that are configured for one of the hands-on-interaction unlock options(TPM + PIN or TPM + startup key) under normal use and when offsite; but need to be managed and updated remotely when onsite.
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/network-unlock
It also makes the assumption that the TPM isn’t spilling its guts; so it’s not really a solution to this problem(and startup key is trivially vulnerable to extraction of the startup key file from the USB media, that mode is basically an improvisation dictated by the need to work with no special hardware, not a good idea; while PIN is probably OK-ish if the TPM is enforcing anti-hammering rate limiting; but just a weak password if someone has the leisure of an offline attack); but it does allow you to impose hands-on requirements on users without having every machine in the office stop talking to you when it reboots to update.
All well and good until someone installs a physical keylogger.
Or breaking your fingers one by one hard… one needs plausible deniability for occasions like this (one password gives access to clean partition, another one gives access to dirty partition, free space is filled with random so its impossible to say whats free whats not)… one would hope a rare scenario.
You can store LUKS password on a usbram pendrive (http://iclog-kits.com/?page=usbram), in most cases USB is not power cycled durning reset/reboot so it’s quite handy with servers.
What’s the point in using LUKS if the key is going to be stored in a plugged-in USB device all the time?
Point is to enable safe automouting durning (re)boot without manually typing passwords/keys. When device is already mounted and attacker gets “inside” the system there is no point to use encryption at all, becouse all (mounted) data are exposed to an attacker. You can secure boot (bios) to prevent booting and manipulating with (another) system to expose USB stick data. Many forsenic’s individuals have no idea about such ram devices so they plug them out firstly durning examination and destroys keys.
I think many of us simply assume once one has physical access to a cell phone, computer or other device, all security bets are off.
Precisely this, if physical access is obtained, the device is to be considered compromised.
Actually with that opinion you won’t sell any SSD drives to the NSA, which we managed to do.
Hows the encryption built into drives?
It isn’t. Bitlocker encrypt/decrypt happens in software, between the drive and the operating system.
Not necessarily, Bitlocker can interface with SEDs and use the built-in encryption of drives. Takes an excurse into group policy editor though.
An easy solution is to not use the TPM, use an alphanumeric boot pin instead. It seems obvious to me that if the computer can unlock itself without the user, then it will be fairly easy for an attacker with hardware access to recover that key.
The entire point of harddrive encryption is to *prevent* someone with hardware access from reading the data. The encryption is transparent to network attacks against a booted computer. So what is the point of using encryption that doesn’t prevent against that???
Microsoft, security.
The point is, Joe Schmo can FEEL secure and sleep easy at night.
Ignoring the attack described in the article for the moment, Bitlocker prevents data access if you remove (or steal) the drive from the computer even if auto-unlock-on-boot is enabled. If the entire computer is stolen, all bets are off unless there’s a preboot password (see below.) Of course, if you can boot the system and break into the OS, it doesn’t matter what whole-disk encryption you’re using.
Enabling the Bitlocker preboot password prevents the attack described in the article–this requires the user to enter a password on power-up before Bitlocker can access the encryption keys. Without the correct preboot password (which is also securely stored in the TPM) the TPM won’t release the encryption keys and so the keys can’t be sniffed.
Why does the headline single out Windows / Bitlocker when this is clearly a hardware-based key disclosure attack that would work for any keys stored in the TPM, even with Linux as the OS?
Bias maybe? Everyone loves to hate Microsoft, me included, but let’s be clear about what the real vulnerability is here. The vulnerability is in hardware.
So the solution is to require a piece of key (password) that’s *not* in the TPM, as LUKS for Linus does, or the macOS solution (as mentioned by others above).
Microsoft could’ve had more stringent requirements on TPMs, like requiring encrypted communications (which is part of the spec). Bitlocker also encourages use of a TPM (required by default) which isn’t the case for luks.
Singles out Bitlocker b/c it’s the one that has weak security by default. Other full disk encryption systems ask you to remember a password, so that it’s not compromised with the hardware. As other commenters have pointed out, that’s pretty much a requirement for the goal of full-drive encryption.
That said, I don’t use full-drive encryption. My guess is that I’m more likely to have a drive fail and be grateful for whatever I can retrieve than I am to have it stolen by anyone.
Of course, I _do_ encrypt files that need to be encrypted. Not saying I don’t have secrets. Just that they’re under 1%, maybe under 0.001%, of the total data on disk. Encrypting the whole thing just for them seems silly, and an unwarranted data-recovery risk.
I know I could probably do backups better to solve that problem. But you do your threat model, I’ll do mine. :)
It’s for all those times that government laptops get swiped with their juicy secrets on us.
https://www.cbsnews.com/news/irs-loses-laptops-your-data-exposed/
Agreed, it does seem an attack against MS, especially given that MS explicitly write “For some systems, bypassing TPM-only might require opening the case and require soldering, but can be done for a reasonable cost.” Additionally MS recommend using “Preboot authentication set to TPM with a PIN protector” against an attacker with skill.
Exactly. Bitlocker can be configured to require PIN/pw at boot, too.
Again, still seems like MSFT is catching grief here despite doing a decent job of balancing security and recoverability defaults for the average PC user.
I am using full disk encryption on both a Windows and a Linux (LMDE) laptop (bitlocker and LUKS).
TPM 2.0 allows parameter encryption. With good libraries it’s pretty easy to use. MS just didn’t implement it.
Neither has LUKS or just about any production ready systems.
I think the default Bitlocker setup with a TPM and no TPM PIN/password is really only meant to protect against drive by attacks where the attacker can’t just tamper/yank the laptop. The combination of secure boot, intrusion detection switch, bios password and OS password should protect against this.
When does the TPM give the key?
If it does so anytime the OS asks, then any stolen laptop can be broken.
If it does only immediately after a password or fingerprint has been given, this attack is only theoretical.
Security, schmecurity. Check out that awesome probe/jig that he made! I can see making different versions of that same thing for soooo many applications.
Yup, I ordered a couple hundred pogo pins of various types because of that jig to use with various flashers, sniffers and debuggers, really useful and very satisfying to get working.
Hmm, from the way that it works, I suppose this attack will also work if I encrypt my disk using LUKS in Linux using TPM2?
“Anyone who uses Windows has probably run into Bitlocker.”
lol
Enabled by default on Win11 machines that meet hardware requirements. So, everyone who uses a recent Windows has.
I wonder if this is the reason for the STILL problematic (fails with error) KB5034441: Windows Recovery Environment update for Windows 10, version 21H2 and 22H2: January 9, 2024 which supposedly fixes a Bitlocker vulnerability. Why it tries to install on my Win10 Home system which doesn’t have Bitlocker is beyond me. The “might work” system fiddling fix to maybe allow successful installation requires actions which are light-years beyond the average user.
“The “might work” system fiddling fix to maybe allow successful installation requires actions which are light-years beyond the average user.”
It’s just a few command line commands to delete the recovery partition, resize the system partition so the recovery partition can be bigger, then recreate the recovery partition in the larger available space.
It’s not that hard considering we’re in a forum talking about LUKS disk encryption for Linux.
Nice, but TPM is ancient history now. And with TPM 2.0 the data is encrypted.
Wait, this is only relevant on TPM1.x? So 10 years old hardware not even supported by Win11 anymore?
I expected at least some secure method for key exchange. Intercepting such a key would require more than sniffing, but also sending data to spoof both sides.
I always figured that if I encrypted my hard drive then the person who is one day trying but unable to read my data from said drive will be me.
I bet that scenario plays out a lot more often in real life than the one where a bad actor is trying to copy one’s hard drive.
The potential for losing everything is too great and my home is almost never empty of people who actually belong there and would notice an intruder anyway.
Yes. I know my backup strategy has holes, gets worse over time. It’ll cause me more problems at the moment when things blow up.
But for corporate, with IT staff, no problem.
…so what you’re saying is that your home is almost always full of potential intruders. But yeah, unfortunately I share the concern over the one getting locked out most likely being yourself.
This very neat… but doesn’t really matter. If someone has “physical” access like this then you have “bigger” problems. Also, if the HD and matching TPM are local, then it will boot normally…no TPM key grabbing needed.
Many are ragging on MS. I think the most likely scenario BitLocker was meant to address includes the casual theft of a computer’s only disk where the thief has no idea of login credentials. BitLocker prevents somebody simply removing the disk drive, popping it into an external USB enclosure and voila having immediate access to someone else’s files.
I don’t really believe BitLocker was intended for three-letter organization security.
As others have stated, I would be more concerned about file recovery so my main-use computers are backed up to the cloud, local NAS, and offsite drives. I’m told the cloud is encrypted, but neither the NAS or offsite drives are.
Microsoft’s marketing would suggest otherwise, although I’m sure they would argue that it works in cooperation with their other security features (… and can be improved with an annual subscription!). Plus, a thief is probably not going to bother taking apart a laptop to get the drive. They’ll just take the laptop (with the TPM).
Disclaimer: I haven’t watched the video/read the article.
But from the pictures here, it certainly looks like the 43-second thing doesn’t include the time to open the case up. It also doesn’t include the couple of weeks it takes to get a carrier board made–nor the inconvenient question of what percentage of all laptops will have the same footprint for the LPC bus.
LPC has a standardized footprint, although YMMV in a laptop. Also, corporations tend to buy large numbers of identical (or very similar) laptops.
Then don’t comment! If you literally watched only 1 second of the video you would have known your assumption was false. The 43 second the get the key includes opening the case.
Fascinating how you didn’t mention my main point, which is that this board–which had to be custom fabricated, so has a lead time of probably at least a couple of weeks, is only going to work for some models of laptop.
Also, I didn’t mention it, but the 43 second thing doesn’t include any time spent stealing anything off the drive–all it does is get the encryption keys.
And this won’t work on any PC with an fTPM, as mentioned by a commenter, but not by the article here.
Ars Technica has a much better article about this mostly non-story. (Get this–“This is not a new exploit, and StackSmashing has repeatedly said as much. We reported on a similar TPM sniffing exploit in 2021, and there’s another from 2019 that similarly used low-cost commodity hardware to pick up a plaintext encryption key over the same low-pin count (LPC) communication bus StackSmashing used.”)
To clarify, no CPUs currently integrate TPM hardware. However, there are firmware TPM implementations. These range in quality from “bad” to “terrible” and tend to be a security nightmare as the implementers have to be *very* careful to keep secrets tucked away in their own little corner of the cache, inaccessible to the OS. They also suffer from a slew of other issues.
are you sure?
https://www.amd.com/en/technologies/pro-security
Nothing is untraceable or unhackable. One should not count on the fact that the only people that have access to master keys or being able to develop at the lowest authorized level be a large corporate entity whose employees have signed non-disclosure agreements. Non-corporate developers and hackers do crack things believed to be very secure with their own code. Once something has been defeated, systems are vulnerable, encrypted data gets decrypted, or new code not created or authorized by the trust authority can be executed, including code created by hobbyist programmers or non-corporate developers. It is only a matter of time before a system gets cracked.