Windows BitLocker – Screwed Without a Screwdriver
neodyme.io
neodyme.io
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.
I vote for Bob from QA, he's always around.
it's not perfect and it's a lanky chain to keep maintaining, but it's not un-doable.
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.
I’m guessing that means you now have to change your password in two places if you ever change it? Not great, but then again people probably never change their passwords.
https://support.apple.com/guide/mac-help/protect-data-on-you...
> When you turn on FileVault, you choose how you want to _unlock your startup disk_ if you ever forget your password:
The password now locks the entire startup disk (as of FileVault2, which has been around a while) and needs to be entered into a pre-os screen. There is a place in the UI (once booted) to designate which users can do this.
This is useful for securing lost devices (since they don't have enough key material to decrypt the disk), but probably still susceptible to evil maid attacks (hacking the login screen).
You can read details on pages 119 and 120 of this document (in particular, page 120 has a diagram of how the volume encryption key is derived):
https://help.apple.com/pdf/security/en_US/apple-platform-sec...
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.
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.
But that means the user is using a different password... so you may as well use a TPM PIN.
So not my password, then who's password? Why not TPM PIN?
Can't communicate with the OS -- the disk is locked.
> You can do it more securely than just setting a flag if that’s a concern
Now we just wait for a vulnerability in this mini-app stored in unencrypted storage to be able to set some flag and wallah, we bypass the user's password at the OS level.
Doing this in a secure fashion doesn’t seem very hard. For example, hash the password in the same way the OS does. Hash that hash with some salt. Put it in memory at some agreed location. The OS can retrieve it, verify the hash and proceed if it matches. And of course erase the message.
If you’re worried about replay attacks from someone who can capture the message between login and the OS verifying it, you can add the current time to the hash. If you don’t trust the clock, I’m sure the TPM can produce an ephemeral nonce for both sides to use, or the OS could store a hash of each message after verifying it, and reject any reused message.
You’ll never be safe from software vulnerabilities, but this reliably prevents an attacker from reading your disk from a cold boot without knowing or cracking your password.
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.
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
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.
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.
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.
You are asked to make a choice of who gets the custody of the recovery key: you or Apple. If you 1. choose to keep it safe yourself, 2. can't remember the password, and 3. lose the key, well... you've cooked yourself.
> or they only have one iDevice that they use for 2FA so they can't log in to their Apple account...
I don't use iCloud for recovery, but my understanding is that you can just log in to iCloud from the Mac in question (I do get 2FA prompts on my Mac). I might be wrong.
In case you also lose access to iCloud, go to an Apple Store - they will reset it for you (bring your ID/passport/driver license/etc, it's an involved process).
> 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.
Yeah, Apple is pretty good at that. Not perfect, but miles ahead of the competition.
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.
This also allows people changing their password as you do not change the actual (strong) key used for the disk but the key used to access it.
No, it's not. I use a book to generate a string of numbers and I can write them on a sheet of paper. If I put that paper in a room and lock the room with a key, I need the key to access the paper, but the numbers on the paper are in no way derived from the door key.
You are incorrect in your understanding of the word derived.
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.
> 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
>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.
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.
Of course, a real TPM won’t be perfect. But there’s no reason you can’t do both. Have the TPM use a good KDF and then an attacker has to break both.
But they said:
> You should derive the disk’s encryption key from the user’s login password.
How is this not that?
Eg: LUKS. It doesn’t use the passphrase to derive the key, but rather encrypts the key using the passphrase. This allows users to change their password and allows having multiple users with different passwords.
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.
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.
For one, you can't implement blanket security features on an OS unless all devices have TPM 2.0, so all users who want the better security will have to have TPM 2.0 devices. Those who don't can stay on current hardware and use it till it falls apart.
Secondly, if Microsoft is bad for deprecating SW support for devices without HW security features why isn't the same uproar against Apple for doing the same?
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.
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
> The easiest way to get this working has three parts:
> Get the original BCD from the victim’s device. This ensures the configuration matches the specific partition GUIDs. You can do that by shift-rebooting Windows, going “Troubleshoot > Advanced options > Command Prompt”, mounting the boot partition, and copying its contents to a USB drive. Or, be more advanced and use an SMB mount, if you don’t have USB access.
Do I understand it correctly that to bypass the encryption you need access to the decrypted contents of the encrypted disk? Did the original exploit guess the layout of the partitions instead?
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.
Do new devices still suffer from the issue?
Because, well, and bear with me here, if they did, they would have set a darn PIN?
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.
...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?