7

I was quite shocked today to see that a Windows 10 Pro machine that I recently set up with BitLocker (startup PIN + TPM with full disk encryption) suddenly didn't have BitLocker enabled anymore:

Windows Update suspended BitLocker

And apparently Windows messed with my Bitlocker settings:

messed up settings

Here is a screenshot I took of my settings a week ago (which I haven't manually changed since then): enter image description here

So Windows must have changed them soemhow.

I have not messed with the registry or installed tools that would do so. I haven't even installed any third party AV software as I only visit websites that you would consider trustworthy (like google.com, youtube.com, amazon.com etc) and only install software that you'd consider trustworthy (like Firefox, Skype etc)... I suspect Windows Update to be the source of the problem. And as it turns out other people have reported similar issues with Windows Update suspending their BitLocker.

This is absolutely unacceptable in my opinion! As I use a startup PIN + TPM, there doesn't seem to be an obvious way to prevent this from happening again.

Is there a way I can prevent this? I really don't want to disable Windows Update as I won't get security updates anymore then. And I also don't like the idea of manually installing updates once a week and then afterwards checking if BitLocker is enabled again.

Improve this question

2 Answers 2

Reset to default
2

UPDATE: as per comments, this answer does not fully explain the behaviour.

I am not an expert, but I recently encountered something similar.

First, note that there is a difference between "Suspending" BitLocker, and "Turning Off" BitLocker:

BitLocker dialog showing the difference between "Suspending" BitLocker, and "Turning Off" BitLocker

From your screenshots, your BitLocker is suspended, not turned off.

According to Microsoft:

The Suspend-BitLocker cmdlet suspends Bitlocker encryption, allowing users to access encrypted data on a volume that uses BitLocker Drive Encryption. This cmdlet makes the encryption key available in the clear.

...

While suspended, BitLocker does not validate system integrity at start up. You might suspend BitLocker protection for firmware upgrades or system updates.

Windows Update has a mechanism where it installs some of the updates now, and the rest on the next reboot. I assume that this is accomplished by booting into some lightweight OS that exists only to install the new files, and then calls the Windows bootloader when it's done. It looks like Microsoft has decided that they don't want to bundle all the TPM drivers into this lightweight installer, so they disable BitLocker temporarily.

A suspended BitLocker should go back to full protection on the next reboot, so the answer seems to be when Windows Updates asks you to reboot, you should do it promptly. I know it's annoying, but unfortunately, that's how Windows works.

Improve this answer
5
  • Okay so according to your quote a suspended BitLocker means that my encryption key gets exposed. I don't want this to happen. Especially because as seem on my screenshots you can't rely on Windows un-suspending BitLocker again. This is way too risky. When the PC boots it has to be protected with the security PIN + TPM at all times, otherwise the TPM can't protect against brute force attacks. Besides that, " I assume that [...]" and "It looks like [...]" is not gonna cut it for me. Don't take it personally, but I can't just blindly trust things like that.
    – Forivin
    Dec 12, 2018 at 16:32
  • @Forivin I don't understand your screenshots. Your question doesn't mention whether you have rebooted and allowed Windows Updates to complete.
    – Mike Ounsworth
    Dec 12, 2018 at 16:42
  • My understanding is that many companies deal with this by forcing a Windows reboot within X hours of any updates that disable BitLocker, but again, I'm not a Windows expert nor am I a sysadmin. I'd love to know f you find a more satisfying answer (though I expect the only real answer is: "If you want more control, switch to Linux").
    – Mike Ounsworth
    Dec 12, 2018 at 16:45
  • The screenshot was taken after installing updates and rebooting. I can't imagine that Microsoft would be stupid enough to suspend BitLocker right after installing the updates, not knowing if the computer is going to restart any time soon. In the enterprise you would disable auto updates entirely and only pass updates to the workstations that have been tested. Well, I guess not everyone does it that way, but I have seen a few companies doing it like that. Unfortunately I don't have the time to do it like that.
    – Forivin
    Dec 12, 2018 at 17:05
  • 1
    Hmm, sounds like reasonable logic. I would at least expect Windows Update to suspect BitLocker during a clean shutdown, and re-enable it on the next startup after updates complete. I guess that's not what you're seeing. Please let me know if you find a more satisfying answer!
    – Mike Ounsworth
    Dec 12, 2018 at 17:23
0

For what it's worth, the "standard" way to prevent overwriting of group policy rules in Windows is to go to the associated registry key, edit it's permissions, and remove/deny Write access for the SYSTEM user (or all users). This is effective against the group policy engine used to push configuration changes to domain-joined machines. I've never heard of Windows Update changing a group policy rule before, so I'm not sure if it will work there, but blocking writes by SYSTEM (or by all users) would probably still do it if anything will (on the other hand, there's no guarantee that the Windows Update engine will respect ACLs; admin-level processes are free to ignore them if they so choose).

The relevant registry keys appear to be 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE (and subkeys)

and maybe also 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\Bitlocker (subkeys specifically)

The values in the second location reference the first, so the first may be the authoritative location, but as far as I can tell it's not really documented. Anyhow, denying write access for SYSTEM across both keys and their subkeys is the best shot I can think of for preventing this from happening again (but no guarantees). You could try denying write for all users, if you want to be extra sure (some update stuff runs as the special TrustedInstaller account, for example).

Improve this answer
2
  • 1
    Okay, this might keep Windows from changing the group policies, but it would still be able to suspend BitLocker, right?
    – Forivin
    Dec 13, 2018 at 9:14
  • 1
    @Forivin Yes, which is kind of important when installing updates if you use a TPM (updates that change the bootloader will otherwise result in the TPM not unlocking the key and you will need the recovery key to unlock the disk). However, it attempts to immediately resume protection when Windows successfully boots, and the incorrect configuration problem should (hopefully) not recur so resuming protection should occur automatically.
    – CBHacking
    Dec 14, 2018 at 5:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .