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.
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.
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.
> 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.
> 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.
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.
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].
You could have inferred that the whole thing is a house of cards from vulnerabilities that were discovered prior to bitpixie, but I wouldn't say it was "known".
> Okay, so now we know how to edit a BCD file. But what do we put in there? This was the trickiest part of this exploit chain, as you get very little feedback when things go wrong. Recall the bug we are trying to reproduce: We want the bootloader to attempt to boot from our BitLocker partition, fail, and then trigger a PXE soft reboot into our controlled OS.
> 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?
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.
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.
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.
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.
[+] [-] wat10000|1 year ago|reply
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|1 year ago|reply
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.
[+] [-] oneplane|1 year ago|reply
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.
[+] [-] dazilcher|1 year ago|reply
I vote for Bob from QA, he's always around.
[+] [-] mschuster91|1 year ago|reply
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.
[+] [-] k8sToGo|1 year ago|reply
[+] [-] dunham|1 year ago|reply
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.
[+] [-] jeroenhd|1 year ago|reply
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.
[+] [-] kylebenzle|1 year ago|reply
[+] [-] TacticalCoder|1 year ago|reply
[deleted]
[+] [-] layer8|1 year ago|reply
[0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
[+] [-] ferbivore|1 year ago|reply
[+] [-] yread|1 year ago|reply
> 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?
[+] [-] pxeboot|1 year ago|reply
[+] [-] laurensr|1 year ago|reply
[+] [-] kopirgan|1 year ago|reply
[+] [-] lostmsu|1 year ago|reply
[+] [-] rollcat|1 year ago|reply
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|1 year ago|reply
[+] [-] lostmsu|1 year ago|reply
Do new devices still suffer from the issue?
[+] [-] betaby|1 year ago|reply
[+] [-] varispeed|1 year ago|reply
[+] [-] marcinzm|1 year ago|reply
[+] [-] wildzzz|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] antithesis-nl|1 year ago|reply
[+] [-] quotemstr|1 year ago|reply
[+] [-] yapyap|1 year ago|reply
[+] [-] JimmyWilliams1|1 year ago|reply
[deleted]
[+] [-] kylebenzle|1 year ago|reply
[+] [-] jazzyjackson|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] p_ing|1 year ago|reply
...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?
[+] [-] stavros|1 year ago|reply