Comment by dijit
1 day ago
The defenders of Microsoft are right?
How?
There is no point locking your laptop with a passphrase if that passphrase is thrown around.
Sure, maybe some thief can't get access, but they probably can if they can convince Microsoft to hand over the key.
Microsoft should not have the key, thats part of the whole point of FDE; nobody can access your drive except you.
The cost of this is that if you lose your key: you also lose the data.
We have trained users about this for a decade, there have been countless dialogues explaining this, even if we were dumber than we were (we're not, despite what we're being told: users just have fatigue from over stimulation due to shitty UX everywhere); then it's still a bad default.
Just to be clear: bitlocker is NOT encrypting with your login password! I could be a little fuzzy on the details but I believe how it works is that your TPM (Trusted Platform Module) is able to decrypt your laptop, but will only do so if there is a fully signed and trusted boot chain, so if somebody gains access to your laptop and attempts to boot into anything other than Windows, it will ask for the bitlocker key because the TPM won't play ball.
The important bit here is that ~*nobody* who is using Windows cares about encryption or even knows what it is! This is all on by default, which is a good thing, but also means that yes, of course Microsoft has to store the keys, because otherwise a regular user will happen to mess around with their bios one day and accidentally lock themselves permanently out of their computer.
If you want regular FDE without giving Microsoft the key you can go ahead and do it fairly easily! But realistically if the people in these cases were using Linux or something instead the police wouldn't have needed an encryption key because they would never have encrypted their laptop in the first place.
> nobody who is using Windows cares about encryption or even knows what it is!
Right, so the solution is to silently upload their encryption keys to Microsoft's servers without telling them? If users don't understand encryption, they certainly don't understand they've just handed their keys to a third party subject to government data requests.
> otherwise a regular user will happen to mess around with their bios one day and accidentally lock themselves permanently out of their computer.
This is such transparent fear-mongering. How often does this actually happen versus how often are cloud providers breached or served with legal requests? You're solving a hypothetical edge case by creating an actual security vulnerability.
Encryption by default and cloud key escrow are separate decisions. You can have one without the other. The fact that Microsoft chose both doesn't make the second one necessary, it makes it convenient for Microsoft.
> If you want regular FDE without giving Microsoft the key you can go ahead and do it fairly easily!
Then why isn't that the default with cloud backup as opt-in? Oh right, because then Microsoft wouldn't have everyone's keys.
BitLocker encrypts data on a disk using what it calls a Full Volume Encryption Key (FVEK).[1][2] This FVEK is encrypted with a separate key which it calls a Volume Management Key (VMK) and the VMK-encrypted FVEK is stored in one to three (for redundancy) metadata blocks on the disk.[1][2] The VMK is then encrypted with one or more times with a key which is derived/stored using one or more methods which are identified with VolumeKeyProtectorID.[2][3] These methods include what I think would now be the default for modern Windows installations of 3 "Numerical password" (128-bit recovery key formatted with checksums) and 4 "TPM And PIN". Previously instead of 4 "TPM And PIN" most Windows installations (without TPMs forced to be used) would probably be using just 8 "Passphrase". Unless things have changed recently, in mode 4 "TPM And PIN", the TPM stores a partial key, and the PIN supplied by the user is the other partial key, and both partial keys are combined together to produce the key used to decrypt the VMK.
Seemingly once you've installed Windows and given the Microsoft your BitLocker keys in escrow, you could then use Remove-BitLockerKeyProtector to delete the VMK which is protected with mode 3 "Numerical password" (recovery key).[4] It appears that the escrow process (possibly the same as used by BackupToAAD-BitLockerKeyProtector) might only send the numerical key, rather than the VMK itself.[5][6] I couldn't find from a quick Internet search someone who has reverse engineered fveskybackup.dll to confirm this is the case though. If Microsoft are sending the VMK _and_ the numerical key, then they have everything needed to decrypt a disk. If Microsoft are only sending the numerical key, and all numerical key protected VMKs are later securely erased from the disk, the numerical key they hold in escrow wouldn't be useful later on.
Someone did however ask the same question I first had. What if I had, for example, a billion BitLocker recovery keys I wanted to ensure were backed up for my protection, safety and peace of mind? This curious person did however already know the limit was 200 recovery keys per device, and found out re-encryption would fail if this limit had been reached, then realised Microsoft had fixed this bug by adding a mechanism to automatically delete stale recovery keys in escrow, then reverse engineered fveskybackup.dll and an undocumented Microsoft Graph API call used to delete (or "delete") escrowed BitLocker recovery keys in batches of 16.[7]
It also appears you might only be able to encrypt 10000 disks per day or change your mind on your disk's BitLocker recovery keys 10000 times per day.[8] That might sound like a lot for particularly an individual, but the API also perhaps applies a limit of 150 disks being encrypted every 15 minutes for an entire organisation/tenancy. It doesn't look like anyone has written up an investigation into the limits that might apply for personal Microsoft accounts, or if limits differ if the MS-Organization-Access certificate is presented, or what happens to a Windows installation if a limit is encountered (does it skip BitLocker and continue the installation with it disabled?).
[1] https://learn.microsoft.com/en-us/purview/office-365-bitlock...
[2] https://itm4n.github.io/tpm-based-bitlocker/
[3] https://learn.microsoft.com/en-us/windows/win32/secprov/getk...
[4] https://learn.microsoft.com/en-us/powershell/module/bitlocke...
[5] https://learn.microsoft.com/en-us/graph/api/bitlockerrecover...
[6] https://learn.microsoft.com/en-us/powershell/module/bitlocke...
[7] https://patchmypc.com/blog/bitlocker-recovery-key-cleanup/
[8] https://learn.microsoft.com/en-us/graph/throttling-limits#in...
The vast, vast majority of Windows users don't know their laptops are encrypted, don't understand encryption, and don't know what bitlocker is. If their keys weren't stored in the cloud, these users could easily lose access to their data without understanding how or why. So for these users, which again is probably >99% of all windows users, storing their keys in the cloud makes sense and is a reasonable default. Not doing it would cause far more problems than it solves.
And the passphrase they log in to windows with is not the key, Microsoft is not storing their plain text passphrase in the cloud, just to be clear.
The only thing I would really fault Microsoft for here is making it overly difficult to disable the cloud storage for users who do understand all the implications.
> The vast, vast majority of Windows users don't know their laptops are encrypted, don't understand encryption, and don't know what bitlocker is.
Mate, if 99% of users don't understand encryption, they also don't understand that Microsoft now has their keys. You can't simultaneously argue that users are too thick to manage keys but savvy enough to consent to uploading them.
> If their keys weren't stored in the cloud, these users could easily lose access to their data without understanding how or why.
As opposed to losing access when Microsoft gets breached, or when law enforcement requests their keys, or when Microsoft decides to lock them out? You've traded one risk for several others, except now users have zero control.
The solution to "users might lock themselves out" is better UX for local key backup, not "upload everyone's keys to our servers by default and bury the opt-out". One is a design problem, the other is a business decision masquerading as user protection.
> The only thing I would really fault Microsoft for here is making it overly difficult to disable the cloud storage for users who do understand all the implications.
That's not a bug, it's the entire point. If it were easy to disable, people who understand the implications would disable it. Can't have that, can we?