Sh*tLocker...
What good is full disk encryption if anyone (and the kitchen sink) can just simply turn it off ?
If Microsoft can do this through a 'security update' you can bet your a$$ every three-letter agency can do the same...
Three months on, users continue to report that Microsoft's BitLocker disk encryption technology turns itself off during security updates. The problem, which has prompted much head-scratching in security circles, was raised by power user "kingcr" on Microsoft's technet forums back in June as part of an ongoing discussion. He …
If you're using LUKS on linux then any user with root access can set a new decryption key once the drive is unlocked, without needing to know the existing decryption password(s).
cryptsetup luksAddKey $device --master-key-file <(dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p)
That one-liner is deconstructed here:
Change password on a LUKS filesystem without knowing the password
I'm not sure that works if all 8 keyslots are already occupied; and luksKillSlot needs an existing passphrase to do its job; so you can't simply delete the contents of a keyslot to free it up. You might, in that case, need to get creative with over-writing the luks header directly with dd and a carefully formatted input.
If an adversary has root on a running system, you can argue it is 'game over' in any case. luks is there to protect data at rest - protecting the disk decryption key when it is in use is a different problem.
"What good is full disk encryption if anyone (and the kitchen sink) can just simply turn it off ?"
It's essential to be able to turn it off for updates that impact the TPM such as flashing the BIOS.
"If Microsoft can do this through a 'security update' you can bet your a$$ every three-letter agency can do the same..."
Bitlocker with default settings is not meant to protect against 3 letter agencies. For instance it backs up your encryption keys by default to OneDrive.
However with corporate recommended settings there are no known exploits. To disable Bitlocker as the above requires access to a logged in and booted system.
Unfortunately, situation normal for far too much of Microsoft's "Jenga-like" code - a look at the "General changes, improvements, and fixes" that get listed for each Windows 10 Insider release seems to indicate that random stuff gets trashed every time something supposedly innocuous gets "improved" elsewhere.
Basically, everything comes down to how the symmetric key used for encryption is protected. That's what TPM, PIN, biometric, whatever, protects. If the system puts that key in a state when it is easily accessible, the disk is still encrypted, but the system (or whatever) can access it without going through any security mechanism. I might understand that if the software mechanism that protect the key is being updated, and there's no working backup system to protect it, its protection could be disabled to avoid a state when nothing works, and all is lost. But of course using a system where the key is always protected is far better.
My understanding is that when a bit-locker drive boots it looks for the key in an un-encrypted area of the drive. If the key isn't there then it looks at the TPM. If it's not there either then the BitLocker screen asks for the recovery key.
By placing the key in an un-encrypted area of the drive BitLocker is considered "suspended". This allows the drive to be moved into another device for example, or for updates to automatically reboot the device without requiring the PIN. Pretty useful - when it works.
BIOS updates, for example, should suspend the drive otherwise you'll be asked for the recovery key.
Incidentally, what's the benefit of storing the key in the TPM, without requiring a password, USB dongle, or pin to unlock it? The key is nice and secure, but the system can just read it and go right ahead. So the only difference is that if you steal only the hard drive, you can't read it. But if you steal the computer itself, you can just boot it up and attack the login window, which can gain you access to all the decrypted contents of the drive. Since encryption is primarily a defense against physical access and theft, storing a key in the TPM doesn't strike me as at all useful, let alone a good idea.
So are Microsoft saying is specific circumstances they decrypt the entire drive for just one reboot to install a security update then re-encrypt it again after it has rebooted?
Never used bitlocker, but other disk encryption I have used took hours to encrypt and decrypt all the data on the disk, so I am suspicious that MS are doing that just to install one security update. It sound like perhaps bitlocker just encrypts one small part of the NTFS file system to stop you reading files when it's running rather than the entire disk. And therefore isn't really full disk encryption.
So are Microsoft saying is specific circumstances they decrypt the entire drive for just one reboot to install a security update then re-encrypt it again after it has rebooted?
No, that would take far too long and be susceptible to breaking in less than useful ways if the power fails in the middle.
I expect the way that it works is similar to LUKS. Almost all* of the data on the disk is encrypted using a strong key (call it the 'data-encryption key'). The data-encryption key is then encrypted by a user-chosen password and stored somewhere (either on the disk, or in the TPM, or an external USB drive, or all three). When you unlock the drive, your user password is used to decrypt the actual data encryption key used for encryption of the data, which can then be used to read the data on the disk.
What Microsoft appear to be doing is temporarily storing the data-encryption key in plain text on the hard drive so that a firmware/security update can be done that messes with the other key storage possibilities. One the update is complete, it should tidy up after itself, removing the plain-text copy of the data encryption key, and you go back to using your password to decrypt the data-encryption key.
In the case of LUKS, it is possible to have up to 8 different user passwords, BitLocker has a slightly different implementation. If you know the data encryption key, you can access LUKS data without using any of the 8 user passwords. I suspect the BitLocker 'recovery key' is just the data encryption key, but I could be wrong, as I don't use BitLocker.
If I'm wrong, hopefully a fully qualified BitLocker expert will be along to put me right.
*If you are using UEFI boot, then I think the EFI System Partition (ESP) has to be** an unencrypted FAT partition. So assuming the ESP is on the same disk as your data, at least part of the disk is likely to be non-encrypted. That's most likely the place where the 'security' update will temporarily stash the plain-text copy of the drive encryption key. There are other possibilities.
**The standard allows other file-system types, but to be standards compliant, even if not used, the system has to support the use of the FAT partition. There's nothing to stop an ESP using another file system type, so long as there is a UEFI driver for it, and the UEFI boot firmware is capable of using the driver. At least, that's my understanding.
@mark12: "It sound like perhaps bitlocker just encrypts one small part of the NTFS file system to stop you reading files"
No, all the disk is fully encrypted. What's happening is that they normally have a "main" key for the disk which itself is always encrypted by another key - Usually one somehow derived from your password. Which is the reason you can change your password so easily without reprocessing the whole of the disk volume.
All Microsoft have to do is temporarily encrypt the "main" key with a "known" (to their software that is) key instead, and flag they did that, and the disk will be accessible without any passwords. They call this a "Clear Key". They would also have a copy of the normally used encrypted copy of the key to put back or enable when their clear "period" has ended.
I've been writing quite similar stuff professionally for nearly 18 years, so I know how it works - I hope!
it's not open source and I can't imagine Microsoft permitting a formal security audit.
Given their close connection with the TLAs I'd place a reasonable bet that there's a backdoor in the code, but that's just my paranoia. More importantly, unlike open source alternatives like Veracrypt, there is no way to prove the absence of a back door.
I really don't get it. Anyone using bitlocker clearly has some desire for security and/or privacy, which implies a little bit more awareness of the issues than the common herd. How can they not be aware of that fundamental trust problem?
The only thing I can think of is that they're concerned about script kiddies or thieves or family members getting access to their data but don't mind if it's Microsoft or the Government. Weird!
Suggestions anyone?
I use bitlocker, and it is mainly for convenience and reliability reasons. I trust bitlocker will protect me against thieves accessing my data and against the police accessing it without a good cause (in that they might be able to access it, but only with considerable effort and costs), and that protection is enough for me. If the government is really after me, disk encryption is not going to make the difference.
I don't use other encryption products (well, I use the hardware SSD encryption of my Samsung SSD, but that has the same issues as bitlocker), as I find bitlocker to be convenient to use, and have faith in its reliability (which for me is really critical, I don't want to loose data because of issues with the encryption software).
Do you install Linux only compiling sources after thoroughly perusing them? Do you believe it's so difficult for a TLA to deliver you a "custom" rpm/deb/whatever if they are after you? Most of the companies working on Linux and/or hosting repositories are often government contractors - or even government institutions....
If you're protecting personal data against a thief Bitlocker would do. If you need to protect against police in jurisdictions where is legal to force you to cough up the password, you'll need something hidden. If you need to protect against TLAs, well, most commercial and even open source stuff may be not enough.
Hold the power button down and count to ten. That should force a shutdown with a cold-ish reboot. But you already knew that.
Users shouldn't need to jump through hoops. Users should be able to reboot a Windows PC if that is what they want to do.
A Windows PC in a domain should normally take 60 to 120 seconds to boot to a login prompt, and login should take less than 30 seconds until an uninterrupted (non-jittery) desktop. Those are dreadful response times, but common targets.
If there's a stack of updates queued up, boot time will be long, even longer if updates have mutual dependencies. No matter how admins patch Windows, users have to reboot periodically. It is essential that admins provide a relatively painless boot experience when Windows doesn't need patching. Users have to accept that a reboot is good for them -- or acknowledge that they shutdown when they go home.
Queuing up patches create problems. Stacked up patch procedures disable/enable BitLocker and interact with others. A bit of a pickle.
"A Windows PC in a domain should normally take 60 to 120 seconds to boot to a login prompt"
I don't know what ancient hardware you are running, but it takes about 10 seconds here.
"login should take less than 30 seconds "
It does. More like 10 seconds again in general, but depends on group policy settings and profile.
"If there's a stack of updates queued up, boot time will be long"
Updates don't happen on boot up, they happen on shutdown / restart. At a managed time for us.
"even longer if updates have mutual dependencies"
I think you are getting confused with OSS issues there.
"No matter how admins patch Windows, users have to reboot periodically. "
No they don't. Admins here manage that so users never see it. Including remotely powering up systems if needed.
My experience with Windows 10 is updates that are "installed" on shutdown are actually just staged, and the next startup has me watching it update itself for several minutes.
I sympathize with hiding the shutdown command, though. I've done that to a few users where I work. They're in the habit of shutting down their machine every night, even though I've told them to put them to sleep instead -- they feel that shutting down is more secure somehow. Unfortunately this blocks the nightly backup job from running, and when it runs during the day they complain their computer is too sluggish.
Using the GUI, any Windows user with Administrator privileges (or elevated rights through other mechanisms) can use a standard control panel to Disable BitLocker. It means the volume is encrypted but that at subsequent boots the encryption key can be read from the boot volume without TPM, PIN or USB key device intervention. The facility is provided so that admins can perform maintenance on a PC without being in attendance all of the time.
Any program running as Administrator can access BitLocker APIs to disable/enable BL in the same way as the Control Panel. Windows Update runs as Administrator.
Whatever is going on is a horrible bug. Probably in Windows Update failing to reset flags after a reboot. There's nothing to suggest that there is a backdoor key.
Jeff Jones, senior director at Microsoft, said: “On older devices without a Trusted Platform Module, Bitlocker may be temporarily suspended during some updates. Protection resumes after the machine is restarted."
We're seeing this repeatedly on Windows 2016 Servers in Azure. The above does not give me a huge amount confidence that:
1) They understand the issue.
2) They've considered the severity of the issue especially when in the cloud.
3) They care.
> I really don't get it. Anyone using bitlocker clearly has some desire for security and/or privacy, which implies a little bit more awareness of the issues than the common herd. How can they not be aware of that fundamental trust problem
My employer uses it. Primarily, it's an arse-covering device for the company. If it actually happens to prevent someone accessing data on a stolen laptop as well then great!
Are you sure that they are decrypting the drive as both mention needing the recovery key?
From the first website http://www.datarecoveryspecialists.co.uk/blog/slaving-bitlocker-encrypted-drives
"Enter your recovery key and ‘hey presto’ all the data on the encrypted data volume will be recovered."
From https://www.m3datarecovery.com/bitlocker-decryption/
"as long as we provide the password or 48-digit recovery key."
"Companies will decrypt bitlocker encrypted drives for $."
Not without the keys they wont. Read what it actually says
"This only applies in Windows 7, 8, 8.1 and 10 on SafeGuard BitLocker Client 7.0 and SafeGuard BitLocker Client"
"as long as we provide the password or 48-digit recovery key."