6 ms·

Windows BitLocker – Screwed Without a Screwdriver

190 points by lima 2y ago

wat10000 2y ago
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.
- k8sToGo 2y ago
  You can achieve the same with bitlocker by enabling PIN and autologin
  - wat10000 2y ago
    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.
    - k8sToGo 2y ago
      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.
      - wat10000 2y ago
        Ah hah, terrible naming strikes again. 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.
      - p_ing 2y ago
        macOS has two things going on -- FDE (i.e., same as BL) which is auto-unlocked on boot up. What is protected by the user's password is FileVault encryption, but that's home directory protection only. https://support.apple.com/guide/mac-help/protect-data-on-your-mac-with-filevault-mh11785/mac https://support.apple.com/guide/mac-help/protect-data-on-you...
        wat10000 2y ago
        FileVault 1 was home directory encryption. That hasn’t been current in ages. The current FileVault 2 is FDE using the users’ passwords as the keys.
        dunham 2y ago
        Note in page that you linked: > 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-security-guide.pdf https://help.apple.com/pdf/security/en_US/apple-platform-sec...
        wat10000 2y ago
        Basic evil maid attacks are prevented by signing that login screen software (and everything leading up to it) so it can’t be altered. Of course there’s still the possibility of vulnerabilities in that software, hardware key loggers, etc.
    - rhplus 2y ago
      Auto-unlock does exactly that, and its the default behavior for BitLocker encrypted OS disks.
      - wat10000 2y ago
        Good. But why isn’t that the default? I get why the unattended-unlock mode would exist. Sometimes you have a computer that needs to be able to get started by itself. But it should be an advanced option, not be the default configuration! Especially on a laptop.
- dazilcher 2y ago
  And which user would you put in charge of decrypting the drive? I vote for Bob from QA, he's always around.
  - serf 2y ago
    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.
  - wat10000 2y ago
    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.
- TacticalCoder 2y ago
  [dead]
- jeroenhd 2y ago
  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.
  - wat10000 2y ago
    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 2y ago
      > 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.
- kylebenzle 2y ago
  The feature/bug only makes sense from the perspective that someone is telling Microsoft to leave it in.
- mschuster91 2y ago
  > 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 2y ago
    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 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 2y ago
      > 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.
      - rollcat 2y ago
        > 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... 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.
- stouset 2y ago
  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 2y ago
    Or in other words, you should derive the disk’s encryption key from the user’s login password?
    - isjamesalive 2y ago
      The user’s password would protect the disk’s key, but would not necessarily derive it, I think.
      - deleted 2y ago
        [deleted]
      - ArnoVW 2y ago
        Generally the way you solve that is by having the low entropy key give access to a hardware-based key store, like TPM. Those can be made tamper proof and throttled. I.e. the key is destroyed if you try to access the store by probing it, and it is locked (temporarily) after n failed attempts. 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.
    - 112233 2y ago
      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.
- oneplane 2y ago
  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 2y ago
    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 2y ago
    >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 2y ago
      Cause literally millions of devices will end up in landfills. Not figuratevelly, literally.
      - 2y ago
- dunham 2y ago
  > 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 2y ago
    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 2y ago
    Deeper dive from The Eclectic Light Company: https://eclecticlight.co/2025/01/10/filevault-and-volume-encryption-explained/ https://eclecticlight.co/2025/01/10/filevault-and-volume-enc...
JimmyWilliams1 2y ago
[dead]
lostmsu 2y ago
This is easily mitigated by requiring password to change boot order.
- rollcat 2y ago
  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 2y ago
  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.
lostmsu 2y ago
Was BIOS fully updated as well? Do new devices still suffer from the issue?
- betaby 2y ago
  Yes. That the architectural problem with auto-unseal.
  - lostmsu 2y ago
    The fact that it is an architectural problem doesn't imply that it works on latest firmware because newer firmware might be set to not trust signatures made before the patch was released. Hence the question.
kylebenzle 2y ago
NSA and CIA do NOT want this info to be public. Surprised OP hasn't gotten a call yet to shut it down...
- deleted 2y ago
  [deleted]
- p_ing 2y ago
  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?
- stavros 2y ago
  Maybe they did, but what are they going to do, convince Germany to extradite?
- jazzyjackson 2y ago
  NSA explicitly wants to increase the average joes security posture so they don't get fubar'd by foreign adversaries
antithesis-nl 2y ago
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.
- yapyap 2y ago
  thanks
  - antithesis-nl 2y ago
    [flagged]
    - minedwiz 2y ago
      If there's one thing we should never criticise people for, it's politeness and generally being nice. Internet needs more of it.`
      - ThrowawayR2 2y ago
        1-2 word comments are considered low value contributions on HN, even if they are polite.
        antithesis-nl 2y ago
        Sure.
- quotemstr 2y ago
  You know damn well most people aren't going to do that.
  - antithesis-nl 2y ago
    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?
deleted 2y ago
[deleted]
varispeed 2y ago
How these work on a headless server where you cannot enter password upon boot? If someone steals the server can they read data?
- wildzzz 2y ago
  That's what physical security is for. We only have bitlocker on our laptops.
  - varispeed 2y ago
    There is security, but once I caught building management employee getting into office to check aircon. It was unannounced and probably permitted under contract (as an emergency access). If that person took the NAS, maybe they would get caught, but data still would be compromised.
- marcinzm 2y ago
  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.
laurensr 2y ago
Video presentation at https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38c3-816-eng-Windows_BitLocker_Screwed_without_a_Screwdriver.mp4 https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38...
layer8 2y ago
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 https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
- ferbivore 2y ago
  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".
yread 2y ago
> 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?
- pxeboot 2y ago
  On a UEFI system, the boot partition is unencrypted and formatted as fat32.
kopirgan 2y ago
I had posted this question in another thread re TPM on Linux and the answer is here after a couple of days.

190 points by lima 2y ago

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.

k8sToGo 2y ago
You can achieve the same with bitlocker by enabling PIN and autologin
- wat10000 2y ago
  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.
  - k8sToGo 2y ago
    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.
    - wat10000 2y ago
      Ah hah, terrible naming strikes again. 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.
    - p_ing 2y ago
      macOS has two things going on -- FDE (i.e., same as BL) which is auto-unlocked on boot up. What is protected by the user's password is FileVault encryption, but that's home directory protection only. https://support.apple.com/guide/mac-help/protect-data-on-your-mac-with-filevault-mh11785/mac https://support.apple.com/guide/mac-help/protect-data-on-you...
      - wat10000 2y ago
        FileVault 1 was home directory encryption. That hasn’t been current in ages. The current FileVault 2 is FDE using the users’ passwords as the keys.
      - dunham 2y ago
        Note in page that you linked: > 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-security-guide.pdf https://help.apple.com/pdf/security/en_US/apple-platform-sec...
        wat10000 2y ago
        Basic evil maid attacks are prevented by signing that login screen software (and everything leading up to it) so it can’t be altered. Of course there’s still the possibility of vulnerabilities in that software, hardware key loggers, etc.
  - rhplus 2y ago
    Auto-unlock does exactly that, and its the default behavior for BitLocker encrypted OS disks.
    - wat10000 2y ago
      Good. But why isn’t that the default? I get why the unattended-unlock mode would exist. Sometimes you have a computer that needs to be able to get started by itself. But it should be an advanced option, not be the default configuration! Especially on a laptop.
dazilcher 2y ago
And which user would you put in charge of decrypting the drive? I vote for Bob from QA, he's always around.
- serf 2y ago
  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.
- wat10000 2y ago
  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.
TacticalCoder 2y ago
[dead]
jeroenhd 2y ago
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.
- wat10000 2y ago
  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 2y ago
    > 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.
kylebenzle 2y ago
The feature/bug only makes sense from the perspective that someone is telling Microsoft to leave it in.
mschuster91 2y ago
> 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 2y ago
  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 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 2y ago
    > 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.
    - rollcat 2y ago
      > 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... 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.
stouset 2y ago
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 2y ago
  Or in other words, you should derive the disk’s encryption key from the user’s login password?
  - isjamesalive 2y ago
    The user’s password would protect the disk’s key, but would not necessarily derive it, I think.
    - deleted 2y ago
      [deleted]
    - ArnoVW 2y ago
      Generally the way you solve that is by having the low entropy key give access to a hardware-based key store, like TPM. Those can be made tamper proof and throttled. I.e. the key is destroyed if you try to access the store by probing it, and it is locked (temporarily) after n failed attempts. 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.
  - 112233 2y ago
    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.
oneplane 2y ago
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 2y ago
  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 2y ago
  >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 2y ago
    Cause literally millions of devices will end up in landfills. Not figuratevelly, literally.
    - 2y ago
dunham 2y ago
> 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 2y ago
  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 2y ago
  Deeper dive from The Eclectic Light Company: https://eclecticlight.co/2025/01/10/filevault-and-volume-encryption-explained/ https://eclecticlight.co/2025/01/10/filevault-and-volume-enc...

JimmyWilliams1 2y ago

[dead]

lostmsu 2y ago

This is easily mitigated by requiring password to change boot order.

rollcat 2y ago
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 2y ago
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.

lostmsu 2y ago

Was BIOS fully updated as well? Do new devices still suffer from the issue?

betaby 2y ago
Yes. That the architectural problem with auto-unseal.
- lostmsu 2y ago
  The fact that it is an architectural problem doesn't imply that it works on latest firmware because newer firmware might be set to not trust signatures made before the patch was released. Hence the question.

kylebenzle 2y ago

NSA and CIA do NOT want this info to be public. Surprised OP hasn't gotten a call yet to shut it down...

deleted 2y ago
[deleted]
p_ing 2y ago
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?
stavros 2y ago
Maybe they did, but what are they going to do, convince Germany to extradite?
jazzyjackson 2y ago
NSA explicitly wants to increase the average joes security posture so they don't get fubar'd by foreign adversaries

antithesis-nl 2y ago

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.

yapyap 2y ago
thanks
- antithesis-nl 2y ago
  [flagged]
  - minedwiz 2y ago
    If there's one thing we should never criticise people for, it's politeness and generally being nice. Internet needs more of it.`
    - ThrowawayR2 2y ago
      1-2 word comments are considered low value contributions on HN, even if they are polite.
      - antithesis-nl 2y ago
        Sure.
quotemstr 2y ago
You know damn well most people aren't going to do that.
- antithesis-nl 2y ago
  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?

deleted 2y ago

[deleted]

varispeed 2y ago

How these work on a headless server where you cannot enter password upon boot? If someone steals the server can they read data?

wildzzz 2y ago
That's what physical security is for. We only have bitlocker on our laptops.
- varispeed 2y ago
  There is security, but once I caught building management employee getting into office to check aircon. It was unannounced and probably permitted under contract (as an emergency access). If that person took the NAS, maybe they would get caught, but data still would be compromised.
marcinzm 2y ago
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.

laurensr 2y ago

Video presentation at https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38c3-816-eng-Windows_BitLocker_Screwed_without_a_Screwdriver.mp4 https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38...

layer8 2y ago

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 https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

ferbivore 2y ago
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".

yread 2y ago

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

pxeboot 2y ago
On a UEFI system, the boot partition is unencrypted and formatted as fat32.

kopirgan 2y ago

I had posted this question in another thread re TPM on Linux and the answer is here after a couple of days.