Windows BitLocker – Screwed Without a Screwdriver
90 comments
·January 18, 2025wat10000
I can’t understand this design. You should derive the disk’s encryption key from the user’s login password. You have a small, secure program that presents a login screen on boot. It takes the password you input and uses it to unlock the disk. It passes the username and password along to the OS so that it can take you right into your account after it boots.
As long as your encryption is decent, this makes it fundamentally impossible to read the drive from a turned-off state without knowing or cracking the password.
stouset
Yours is not a good design.
First, passwords are terrible sources of entropy. Second, users want to change passwords without needing to re-encrypt every single block on their disk.
The correct approach, generally, is to generate a completely random encryption key (in a TPM) and encrypt it with the password.
The encryption key itself will have plenty of entropy, it can be changed trivially, you can set up multiple users to unlock the disk if desired, etc.
Further, what about systems with multiple users? Only one person should be unable to unlock the disk? No, you probably want the OS volume to be unlockable at boot without user intervention. When one of the users logs in, their password is used to unencrypt their volume’s encryption key.
IshKebab
Or in other words, you should derive the disk’s encryption key from the user’s login password?
whatevaa
No. If you derive, then you can't change it without full re-encryption of potentially terabytes of data.
112233
No, it should not be possible to compute encryption key from the password. Or, to phrase differently, you derive the key from the password and the data held by the secure element.
isjamesalive
The user’s password would protect the disk’s key, but would not necessarily derive it, I think.
oneplane
His design is perhaps not 'good' if you were to implement it with the explanation as-is, but his description is hardly an implementation guide.
The concept as described is used worldwide (by macOS and iOS) and works very well. In contrast to things like BitLocker, OPAL TCG and SED where it's such an "everything is optional"-free for all, there is no real way to be sure.
In the FOSS world, most of this can also be done (combination of self-enrolled secure boot and dm-verity for a heads loader and them LUKS for a OS-stage loader), but the issue is that you can subvert the root of trust and get infinite tries to attack the encrypted data, including when a TPM or SED is involved.
wat10000
Yes, I’m simplifying slightly. You want the lowest level key to be random as you say. In addition to the benefits you mention, it also supports a recovery key, and means you can securely “erase” the disk in an instant by just forgetting the encrypted key.
rollcat
Disclaimer: am not a cryptographer.
> First, passwords are terrible sources of entropy.
Use a KDF.
> users want to change passwords without needing to re-encrypt every single block
You've gone into a little more detail than OP, but I don't think it was necessary to disagree. The overall idea (even if simplified) is solid.
I've recently argued for the same solution for Linux: https://news.ycombinator.com/item?id=42739214
amelius
> The correct approach, generally, is to generate a completely random encryption key (in a TPM) and encrypt it with the password.
But they said:
> You should derive the disk’s encryption key from the user’s login password.
How is this not that?
brirec
It’s like using ssh-keygen to generate an SSH key, and entering your chosen password when prompted. This encrypts the private key, which is otherwise completely independent from the password. Not derived from it, just used to lock it.
null
LPisGood
>First, passwords are terrible sources of entropy
>generate a completely random encryption key (in a TPM) and encrypt it with the password.
I don’t see how this approach solves the problem. If the password has bad entropy then using it to encrypt anything seems wrong.
jrockway
The TPM is a computer running code that says "after 3 bad password guesses, forget the underlying key forever". That's the value it adds here. It's assumed that typing the password is the only way to get the actual encryption key out of the device, so the only attack is to guess the underlying encryption key, which is much harder than guessing a user's password (that they probably typed into totally-legit-blog.example.com to post a comment once).
In the real world, it's not clear that this is strictly better than using a slow password-based key derivation function. With a key derivation function, the attacker gets unlimited tries for all of time, so it is technically slightly less secure than "the key blows up in a ball of fire after 3 guesses". I don't have data on whether or not passwords are successfully guessable on average in 3 attempts, but they probably are for certain users. (You look at data breaches and if they use the same password on all of them, it's probably their TPM unlock password too.)
How secure TPMs are is also up for debate. I think I had an early one that was just a standard 8 bit microcontroller speaking the protocol the right way, without any actual security. That loophole is likely plugged for DRM reasons (software can ask the TPM to certify itself), but assuming that a computer running code you've never read has 0 bugs is unwise.
pinoy420
Because typical more learned than thou hn comment. That’s why.
oneplane
It is indeed a failed design. What you describe is how FV2 in Apple devices work. You have a native always-on DEK (Data Encryption Key) in the SEP (Secure Enclave Processor) that itself is encrypted with a KEK (Key Encryption Key) which in turn can have multiple encrypted versions for different end-users, which each has their password to decrypt the KEK, or better, authenticate to the SEP and it will decrypt the KEK. This is not exactly how it works, but a simplified story.
On top of that, there is indeed a small secure pre-boot stage where the user (any local user) logs in, which does both the OS login as well as the disk decryption (well, KEK decryption but that's a detail). It is of course also using a KDF so it's not just the end-user's password plainly applied to a cryptography function. This too is a simplified story (the pre-boot isn't actually a preboot, the OS is on a read-only signed volume since it's not secret/confidential, it's only important to prevent tampering).
This works, it works well, and has not had any real durable attacks that work against it so far.
wat10000
Yep. I’m a Mac user and the FDE is basically transparent. The only thing you notice in normal use is that you get a login prompt immediately when (re)booting, and the actual OS boot happens after that, as opposed to booting and then logging in.
Cumpiler69
>It is indeed a failed design. What you describe is how FV2 in Apple devices work. You have a native always-on DEK (Data Encryption Key) in the SEP (Secure Enclave Processor)
That's what TPM 2.0 is supposed to do on PC and why Microsoft is demanding it for Windows 11 yet people don't seem to see the need for it for some reason, then whine about the security implementation.
whatevaa
Cause literally millions of devices will end up in landfills. Not figuratevelly, literally.
dazilcher
And which user would you put in charge of decrypting the drive?
I vote for Bob from QA, he's always around.
wat10000
If you have multiple users then you make it so any of their passwords can decrypt the drive. It’s pretty simple to do this securely. Encrypt the drive with a random key. Derive keys from all the passwords. Use each of those keys to encrypt the drive key and store those encrypted keys. On boot, the user enters their password and then this is used to decrypt the disk key.
This also allows you to set up other keys, so that for example a company IT department can have a recovery key for the computer without needing to know your password.
This means your disk encryption security is now the limited by the worst password of any user, but that’s still a million times better than having the key be available to the system with no password at all.
serf
hardware key and physical attestation mechanism -> fde via key -> hosted encrypted userland or per-user virtualization.
it's not perfect and it's a lanky chain to keep maintaining, but it's not un-doable.
dunham
> I can’t understand this design. You should derive the disk’s encryption key from the user’s login password.
That's essentially what macos does. The key is not derived from the password, but it is stored wrapped with the users password (I assume the TPM is involved in the decryption of the key, but I haven't dug into the details). In the UI you can elect which users are capable of unlocking at boot, and wrapped keys are stored for them and hopefully updated when they change their passwords (or log in for the first time with the new password). On my work machine, with weird AD integration, I've had cases where this was missed, I've had to boot with the old password once to get things straightened out.
TBH, I don't reboot often, so I don't remember if it passes the password to the OS or if it makes you log in again after boot.
wat10000
It passes the login to the OS. The user experience is basically the same as logging in normally, except there’s a pause for the OS to actually start up after you enter your password.
rollcat
Deeper dive from The Eclectic Light Company: https://eclecticlight.co/2025/01/10/filevault-and-volume-enc...
k8sToGo
You can achieve the same with bitlocker by enabling PIN and autologin
wat10000
Having a separate PIN isn’t the same thing. Unlocking the disk with your login password means it’s just as convenient to have an encrypted drive as not (for the typical user who doesn’t need the thing to be able to boot by itself) and it can be the default configuration.
rhplus
Auto-unlock does exactly that, and its the default behavior for BitLocker encrypted OS disks.
k8sToGo
Yes I agree. It should be OOB like it is with MacOS. But you can set the PIN (they call it PIN, but you can enter any password) the same as your PW.
jeroenhd
Keeping your password in memory like that is pretty sketchy IMO. Then again, that's exactly what the fingerprint reader on my Lenovo tries to do if you set it up (though it uses a token and not the full password).
The reason TPMs are used is the unfortunate reality that most passwords are absolute shit. Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions. A TPM generates an actually secure key, and the brute force protections inside of it will make sure even quite insecure passwords don't get brute forced easily.
Another problem with this approach is that your password can be reset, remotely if it's attached to a domain. You can turn off a laptop, alter the domain password, boot it, and log in with the new one, even if you've forgotten the old password. With your proposed solution, you'd be disconnecting the password from the encryption password.
At that point, you might as well set the password to be the same as your login password and enable automatic login. You'll need to update both when they change anyway.
This TPM+PIN solution is actually the easiest, most common mitigation recommended for all of Bitlocker exploits I've seen.
jpc0
> Very few of them are longer than 12 characters and even fewer don't have numbers and special characters at easily guessable positions
Why yes because adding a $%^* at any point in your password easily increased the entropy and didn't make it significantly harder to remember...
Realistically randomly generate your password and if you are the forgetful type write the bloody thing down. In 2025 you should be inputting it at most once every now and then and for disc encryption effectively never...
A long password in a locked drawer or safe is much more secure than Summer2025!5
wat10000
It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.
This isn’t a replacement for a TPM, it’s a way to use a TPM in a sensible manner. You have the TPM do the password -> key derivation, which lets you prevent brute force attacks (at least without a TPM vulnerability or physical chip-level attack). I imagine the TPM could also be used to securely tell the OS who did the initial login so it doesn’t have to prompt a second time.
Having a separate PIN means something else to forget and people will tend to choose the easiest option. We’ve barely managed to convince people to put up with having a password at all. If it’s a choice between password or password+PIN, people are going to pick the former. That option should be secure, and it’s not that hard to design a system where it’s more secure than having a separate short PIN.
p_ing
> It doesn’t have to literally be your password. It could be some one-time proof that the user entered the correct password.
But that means the user is using a different password... so you may as well use a TPM PIN.
formerly_proven
> Keeping your password in memory like that is pretty sketchy IMO.
Every Windows version since "... for Workgroups" keeps the passwords of every logged-in user in memory as plaintext. This fact is widely exploited for privilege escalation and lateral movement in Windows environments.
shortsunblack
Local security authority protection changes this.
dist-epoch
Which is why recently Microsoft has been pushing very hard to replace the account login password with a TPM managed PIN. This way the (Microsoft) account password is rarely needed and never stored in memory.
mschuster91
> I can’t understand this design. You should derive the disk’s encryption key from the user’s login password.
In practice, this is not a good idea at all because no matter what you do, people will forget their passwords all the goddamn time. Back when I was doing freelance IT support, 90% of calls were "help, I forgot my password" - easy money lol, boot it up with MSDaRT or cmd+r on Macs, but nowadays... impossible to recover from if you don't have the recovery key.
rollcat
Macs have the option to store an emergency unlock key in your iCloud account: https://support.apple.com/en-gb/guide/mac-help/mh11785/mac
The trade-off for recovery key custody remains a user choice, but you cannot turn on encryption without setting up recovery.
I've never dealt with a Mac enrolled in MDM, but I figure this is also a solved problem for companies.
mschuster91
> The trade-off for recovery key custody remains a user choice, but you cannot turn on encryption without setting up recovery.
Yeah but just how many cases do you know where people just store the recovery key file on their desktop, lose the printout or whatever... or they only have one iDevice that they use for 2FA so they can't log in to their Apple account...
Any widespread way of encryption must take the most braindead user into account or whoever rolls it out will be inundated by utterly stupid and preventable complaints.
kylebenzle
The feature/bug only makes sense from the perspective that someone is telling Microsoft to leave it in.
laurensr
Video presentation at https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38...
null
lostmsu
Was BIOS fully updated as well?
Do new devices still suffer from the issue?
lostmsu
This is easily mitigated by requiring password to change boot order.
rollcat
It is not. The whole point of TPM/SEP is to protect the entire boot chain. Whatever BIOS/UEFI firmware does by asking for a "password" can be bypassed, unless it is also protected by the TPM.
I once forgot the BIOS password for my mid-2010s Thinkpad. You just desolder the flash chip and install a new one. I've even seen someone try dumping it straight from the mobo (sorry can't find TFA now).
The correct solution is to minimise the surface for such bugs to happen.
6SixTy
No it's not. Bitlocker, etc are full disk encryption methods. They are trying to prevent someone from accessing your data in the event someone has it physically. They can do other things to compromise the device in increasingly sophisticated methods, but generally speaking, that's what it's trying to do and protecting your device from those are generally up to other security measures.
varispeed
How these work on a headless server where you cannot enter password upon boot? If someone steals the server can they read data?
marcinzm
I'm not too familiar with this but as I understand it you you may have the disk encrypted with a key that is loaded from some other server at boot automatically. The key server may then require a manual un-seal to un-encrypt it's own key storage. If you steal the server and it loses power then the key is gone. Of course, there's ways around this like switching the server to a battery and possibly then literally freezing the RAM to dump it.
wildzzz
That's what physical security is for. We only have bitlocker on our laptops.
antithesis-nl
TL;DR, like all secure-boot disk-encryption outrage-bait articles of late: if you're really concerned about any of this, set a TPM PIN and/or explicit disk encryption password.
quotemstr
You know damn well most people aren't going to do that.
p_ing
It's not available on Windows 11 Home.
It's all about threat mitigation. Home machine with your financials and kid pics? Not as important as say... your work machine that you're going into and out of the DoD day after day.
antithesis-nl
Yeah, because... most people don't care about these attacks?
Because, well, and bear with me here, if they did, they would have set a darn PIN?
yapyap
thanks
antithesis-nl
Really? There might be an upvote button that might better suit your needs. Or not. You be you.
minedwiz
If there's one thing we should never criticise people for, it's politeness and generally being nice. Internet needs more of it.`
JimmyWilliams1
[dead]
kylebenzle
NSA and CIA do NOT want this info to be public. Surprised OP hasn't gotten a call yet to shut it down...
stavros
Maybe they did, but what are they going to do, convince Germany to extradite?
null
p_ing
Why not? The information was presented at a conference. What does the CIA/NSA care?
...I mean, aren't they too busy with the red and green blinking lights in the sky and demonstrating that Lake Minnewanka is indeed, flat?
This is all correct, but it’s been fairly well known since over 15 years ago that BitLocker only really protects a computer if you configure BitLocker to require a pre-boot password, and also only after you turned off the computer [0].
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...