[HN Gopher] Windows BitLocker - Screwed Without a Screwdriver
___________________________________________________________________
Windows BitLocker - Screwed Without a Screwdriver
Author : lima
Score : 127 points
Date : 2025-01-18 12:31 UTC (10 hours ago)
(HTM) web link (neodyme.io)
(TXT) w3m dump (neodyme.io)
| wat10000 wrote:
| 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.
| dazilcher wrote:
| And which user would you put in charge of decrypting the drive?
|
| I vote for Bob from QA, he's always around.
| serf wrote:
| 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 wrote:
| 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.
| k8sToGo wrote:
| You can achieve the same with bitlocker by enabling PIN and
| autologin
| wat10000 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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-
| you...
| wat10000 wrote:
| 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 wrote:
| 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-
| sec...
| wat10000 wrote:
| 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 wrote:
| Auto-unlock does exactly that, and its the default behavior
| for BitLocker encrypted OS disks.
| wat10000 wrote:
| 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.
| jeroenhd wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| wat10000 wrote:
| What do you mean? A different password from what?
| p_ing wrote:
| "Doesn't have to be _your_ password ... [just a] correct
| password "
|
| So not my password, then who's password? Why not TPM PIN?
| wat10000 wrote:
| Sorry to be unclear. Read that as "it doesn't have to be
| your _password_." As in, the fact that you've entered the
| correct password can be communicated to the OS without
| actually sending it your password. You can do it more
| securely than just setting a flag if that's a concern,
| although the fact that the disk is readable at all is
| solid proof that some user's password was entered
| correctly, so you don't have to defend against too much.
| p_ing wrote:
| > As in, the fact that you've entered the correct
| password can be communicated to the OS without actually
| sending it your password
|
| 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.
| wat10000 wrote:
| Of course you can communicate with the OS. The disk is
| unlocked at this point, not that you'd want to use
| persistent storage for this. You'd put the info in RAM.
|
| 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.
| p_ing wrote:
| Your methods continue to open more methods of attack than
| TPM + PIN.
| wat10000 wrote:
| How? With my proposal, if an attacker can obtain your
| password then they can get in, otherwise they can't. With
| TPM + PIN it's the same, just with your PIN instead.
| formerly_proven wrote:
| > 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 wrote:
| Local security authority protection changes this.
| formerly_proven wrote:
| Do I understand it correctly that LSA Protection
| leverages VBS/VSM such that the "actual" Windows instance
| is punted into a VM while LSASS and friends run in a
| separate VM, with communication between the two
| controlled by a specialized version of Hyper-V?
| p_ing wrote:
| See https://learn.microsoft.com/en-us/windows-
| server/security/cr...
| dist-epoch wrote:
| 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.
| jpc0 wrote:
| > 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
| kylebenzle wrote:
| The feature/bug only makes sense from the perspective that
| someone is telling Microsoft to leave it in.
| mschuster91 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| stouset wrote:
| 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 wrote:
| Or in other words, you should derive the disk's encryption
| key from the user's login password?
| isjamesalive wrote:
| The user's password would protect the disk's key, but would
| not necessarily derive it, I think.
| ArnoVW wrote:
| 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 wrote:
| 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.
| IshKebab wrote:
| Right, it's not _only_ derived from the password, but it
| derived from the password. You can 't decrypt the disk
| without the password.
| BoiledCabbage wrote:
| > but it derived from the password.
|
| 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.
| laptopdev wrote:
| What are the analogies here? If you can find the door in
| the book you just need the key.
| whatevaa wrote:
| No. If you derive, then you can't change it without full
| re-encryption of potentially terabytes of data.
| wat10000 wrote:
| 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.
| oneplane wrote:
| 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.
| rollcat wrote:
| 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
| LPisGood wrote:
| >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.
| pinoy420 wrote:
| Because typical more learned than thou hn comment. That's
| why.
| jrockway wrote:
| 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.
| wat10000 wrote:
| A theoretically perfect TPM is way better. The strength
| of your KDF is limited by the user experience. If you
| want to limit an attacker to trying one password per
| minute, then you have to make the user wait one minute to
| log in, if you assume the attacker only has the same
| amount of computing power you do. A TPM can just say "you
| have ten tries and that's it."
|
| 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.
| amelius wrote:
| > 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 wrote:
| 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.
| amelius wrote:
| I think that's just how you can implement it and not
| something that is incompatible with the commenter's post.
| They use a different meaning of "key" than you do, but
| that doesn't make it incorrect.
| oneplane wrote:
| 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 wrote:
| 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 wrote:
| _> 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 wrote:
| Cause literally millions of devices will end up in
| landfills. Not figuratevelly, literally.
| Cumpiler69 wrote:
| What happened to the MACs that had no secure enclave?
| dunham wrote:
| > 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 wrote:
| 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 wrote:
| Deeper dive from The Eclectic Light Company:
| https://eclecticlight.co/2025/01/10/filevault-and-volume-
| enc...
| lostmsu wrote:
| This is easily mitigated by requiring password to change boot
| order.
| rollcat wrote:
| 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 wrote:
| 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 wrote:
| Was BIOS fully updated as well?
|
| Do new devices still suffer from the issue?
| betaby wrote:
| Yes. That the architectural problem with auto-unseal.
| lostmsu wrote:
| 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 wrote:
| NSA and CIA do NOT want this info to be public. Surprised OP
| hasn't gotten a call yet to shut it down...
| p_ing wrote:
| 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 wrote:
| Maybe they did, but what are they going to do, convince Germany
| to extradite?
| antithesis-nl wrote:
| 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 wrote:
| thanks
| antithesis-nl wrote:
| Really? There might be an upvote button that might better
| suit your needs. Or not. You be you.
| minedwiz wrote:
| If there's one thing we should never criticise people for,
| it's politeness and generally being nice. Internet needs
| more of it.`
| ThrowawayR2 wrote:
| 1-2 word comments are considered low value contributions
| on HN, even if they are polite.
| antithesis-nl wrote:
| Sure.
| quotemstr wrote:
| You know damn well most people aren't going to do that.
| antithesis-nl wrote:
| 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?
| p_ing wrote:
| 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.
| varispeed wrote:
| How these work on a headless server where you cannot enter
| password upon boot? If someone steals the server can they read
| data?
| wildzzz wrote:
| That's what physical security is for. We only have bitlocker on
| our laptops.
| marcinzm wrote:
| 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 wrote:
| Video presentation at
| https://ftp.fau.de/cdn.media.ccc.de/congress/2024/h264-hd/38...
| layer8 wrote:
| 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...
___________________________________________________________________
(page generated 2025-01-18 23:00 UTC)