Is it true that all Windows 10 SKUs have full-disk encryption turned on by default?
And this automatic full-disk encryption is called "device encryption", which is really the same as BitLocker but without any way for the user to control it? And you can't get BitLocker on the Home edition?
If you immediately set up BitLocker, it allows you to save or print your key instead of sending it to Microsoft. But does it use the same key as the default "device encryption" that was already sent to Microsoft? BitLocker doesn't create a new key and re-encrypt the drive?
And the TPM automatically loads your key into RAM when the device is powered on, so it's still vulnerable when the device is not in your possession?
Are you safe if you (1) create a local account instead of a Microsoft account, (2) use BitLocker instead of device encryption, (3) save your key locally instead of sending it to Microsoft, and (4) require a separate PIN or key to boot the computer in addition to the local Windows account??
It would be helpful to describe exactly how to create a local account, because the Windows 10 setup procedure hides this pretty well. It looks like the only option is to use an existing Microsoft account or create a new one during setup.
And it would be great to explain how to create a secondary PIN or key since that doesn't show up in the BitLocker UI until you edit the local policy[1].
From only reading the article, it looks like they're shipping BitLocker already on, and that the recovery key Microsoft has is the BitLocker recovery key for the already enabled BitLocker configuration. Turning BitLocker off and back on resets this key. As long as you don't send it to Microsoft after re-enabling, Microsoft won't have it.
> As long as you don't send it to Microsoft after re-enabling, Microsoft won't have it.
Unless you have a Home edition of windows, in which case you have no control over it at all. In order to use device encryption you have to sign on with a Microsoft Account and Microsoft will have the key.
I'm pretty sure that key can be deleted/removed from the online account; of course it's already out of your control, so you're now in a position of trusting the completion of Microsoft's key deletion.
Just an aside: I'm running Windows 10 Pro and Bitlocker is off for all 4 of the drives in my machine. This machine was setup from a fresh install of windows 10 shortly after it went live in July. Only a single data point, but apparently there are cases when Microsoft does NOT encrypt the drives.
Disk encryption is enabled on some shipping machines, which is to say, it has been enabled on the three brand new Windows 10 machines I've used. The OEM is responsible for the installation, so I'd assume this is an OEM choice, but obviously I don't know.
I didn't notice at first, and really, there's no reason why I should have noticed. Also, I assumed Windows 10 Home didn't come with BitLocker anyway.
The Windows 10 security overview on Microsoft TechNet includes the following statements:
"Modern Windows devices are increasingly protected with device encryption out of the box and support SSO to seamlessly protect the BitLocker encryption keys from cold boot attacks."
"BitLocker supports encrypted hard drives with onboard encryption hardware built in, which allows administrators to use the familiar BitLocker administrative tools to manage them."
Unlikely that the KEK on the TPM is moved into RAM. The TPM would internally decrypt the KEK encrypted DEK, and then use the DEK in RAM (more likely it's just in the CPU using AES-NI, finding it in RAM would be non-trivial assuming the implementation is good).
This is compared to e.g. either Linux (LUKS) or OS X where the encrypted DEK is stored on the drive itself (outside of the encrypted volume of course), since neither of them leverage a TPM at the moment.
One can replace "Windows computer" with "Android device" and "Microsoft" with "Google" and the article is still factually correct. In other words, how is this any different from Google doing the exact same thing when you sign in to an Android device? On another note, the article gives clear instructions on how to generate a new key without giving it to Microsoft, something that (to the best of my knowledge) is impossible to do on Android or Chrome OS.
I get it, it's easy to pick on Microsoft and for good reason. But the hyper focus of this article screams bias.
How do we know they don't? But at least with Microsoft, there is a way to remove the encryption key from them.
Few years ago, I helped a person unlock their quicken backup file with help of Intuit by calling their support number. User forgot the password he created for the backup and when he tried to restore, he was unable to do it. Intuit was able to unlock that file for him using a master password...
Maybe someone can resolve this question by asking Google, examining Android source code, finding relevant online documentation, or even monitoring what a new Android device does on the network when setting up FDE. I don't feel like this should be a big insoluble mystery for the ages; it's a basic security property of a largely open-source OS that's one of the most popular in the world. We could even ask Micah Lee to do a follow-up article directly addressing other operating systems' FDE key management behavior.
You can't audit the firmware of the baseband processor, which is capable of sending the key to anyone, so there's not much point of auditing Android/asking Google. You cannot rely on any phone with a closed firmware baseband processor to be 100% secure.
It might also come as a surprise to many than most every post-2008 Intel processor is similarly insecure: http://libreboot.org/faq/#intel
> You cannot rely on any phone with a closed firmware baseband processor to be 100% secure.
That's not the question being asked. The question being asked is:
"How do you know that the key for full disk encryption on Android is sent to Google?"
Every technical person understands that any part of a system that has unrestricted read access to RAM can be used to thwart any FDE scheme. For the purposes of this conversation, it's not useful to talk about this.
Doing so is like saying "One can be instantly vaporized by a nuclear bomb, therefore the question is irrelevant." in a conversation about whether aspirin or ibuprofen is safer for occasional relief of minor pain.
My post does not answer that question and it wasn't trying to. The answer to that question is "We don't know". But suggesting that we do an audit of the code to find out doesn't seem productive, which is what I was responding to.
That's a terrible analogy. It would be more accurate to compare this to aspirin and ibuprofen both sharing an unknown compound known to be capable of easily killing someone when the manufacturer wants it to, then suggesting we audit both aspirin and ibuprofen of their known compounds to make sure they don't have anything capable of killing someone. It doesn't really matter if it does, because you don't want to use aspirin or ibuprofen if you want to guarantee you won't die through someone's arbitrary decision, in the same way you wouldn't use Android on a phone if you want to guarantee security of your data.
Microsoft isn't trying to hide the behavior of Windows in this respect, independent of whether Windows could contain a backdoor in some part of the code. That's why The Intercept was able to report on what Windows does, by testing it, seeing what the UI says, asking Microsoft for comment, or whatever. The same methods could be used to report about Android's behavior in this respect, in exactly the same way.
After all, the article isn't claiming that Windows has a backdoor or that the Pro version secretly also escrows user keys with Microsoft while claiming not to. Backdoors in devices and operating systems are an important risk and an appropriate and interesting topic for researchers and journalists to dig into, but this article is about, essentially, documented or disclosed OS behavior!
The very fact that we have to ask is what bothers me. Microsoft plainly states that they store the key for full disk encryption, and offer the ability to generate a new key not stored by them (as covered in the article). They also offer BitLocker in their Pro and Enterprise OSes, for even finer grained, user controlled, offline encryption management.
On the other hand, Google claims they don't store your Android disk encryption key, yet for all their other services, they do. (They also backtracked on encrypting MicroSD cards, leaving your actual valuable data exposed yet giving you a false sense of security, but that's a discussion for another day). Chrome syncing (and by extension Chrome OS), for example, is decrypted by your Google account login. You can set up a second, separate passphrase for those services, but again the key is definitely stored by them.
Given that they have done some really shady stuff in the recent past (Chromium builds that download closed-source binaries after compiling from source and executing for the first time, etc.), I don't trust them as much as I trust Microsoft. And that's not a lot of trust in the first place.
Do you have a reference for how Android or ChromeOS handles FDE encryption keys? I don't know what the current behavior is. My impression was that they weren't sent to Google (but I don't have a reference to support this).
I think the author of the article meant to compare the Windows behavior with other desktop operating systems, including Microsoft's other desktop operating systems. (I know him and have sometimes talked to him about this topic.)
Well, they do get to the reason it's done this way a couple of paragraphs in:
> Of course, keeping a backup of your recovery key in your Microsoft account is genuinely useful for probably the majority of Windows users, which is why Microsoft designed the encryption scheme, known as “device encryption,” this way. If something goes wrong and your encrypted Windows computer breaks, you’re going to need this recovery key to gain access to any of your files. Microsoft would rather give their customers crippled disk encryption than risk their data.
> “When a device goes into recovery mode, and the user doesn’t have access to the recovery key, the data on the drive will become permanently inaccessible. Based on the possibility of this outcome and a broad survey of customer feedback we chose to automatically backup the user recovery key,” a Microsoft spokesperson told me. “The recovery key requires physical access to the user device and is not useful without it.”
The crux of the matter is that the article is trying to confuse readers of the purpose of the encryption. The purpose of Windows "device encryption" is to keep anyone other than you from using your device or getting data off your drive. If you're worried about Microsoft stealing your files, they don't need your key: they just need to wait for you to log in. The only reason Microsoft has the key by default is because users inevitably forget their password and people would be very, very upset if that meant all their data disappeared, just as the above quoted paragraphs suggest.
And if you're a power user who really knows what you want, then you don't have to let Microsoft have the key to your device.
It sounds like a pretty sane system to me and a non-issue.
> Or a law enforcement or spy agency could send Microsoft a request for all data in your account, which would legally compel them to hand over your recovery key, which they could do even if the first thing you do after setting up your computer is delete it.
> As Green puts it, “Your computer is now only as secure as that database of keys held by Microsoft, which means it may be vulnerable to hackers, foreign governments, and people who can extort Microsoft employees.”
The status quo was that if law enforcement or criminals seized your computer, they by default could access all your files. By encrypting the device by default, they at least added an additional hurdle for law enforcement and made it all but impossible for the common thief.
I don't see much to complain about other than it would be nice if Home users had the full Bitlocker feature.
> It sounds like a pretty sane system to me and a non-issue.
That's my take on it as well.
It simply amazes me how most people will accept a vendor's total control of their cellphone or tablet, but when it comes to a PC (and PCs are getting smaller and smaller) everyone freaks out over the same thing. And in fact, Microsoft has far less control over a Windows PC than Google and Apple do over their respective phone OSes, especially if you don't use a Microsoft cloud account.
> The status quo was that if law enforcement or criminals seized your computer, they by default could access all your files. By encrypting the device by default, they at least added an additional hurdle for law enforcement and made it all but impossible for the common thief.
> I don't see much to complain about other than it would be nice if Home users had the full Bitlocker feature.
I'm going out on a limb and suggest that Micah Lee understands why Windows works this way: because Windows is the most popular operating system in the world, and the overwhelming majority of Windows users don't understand how encryption works, and are shocked and dismayed to discover that losing their key more or less forfeits all the data on their disk.
It's straightforward to set Bitlocker up so that Microsoft doesn't hold a backup key.
Microsoft is doing what their userbase wants them to do. I'm not sure what's interesting about this story.
There really is no ground for any excuses here. Companies like Microsoft and Google doing their part to further the government's agenda for the most complete surveillance and/or control over user data is simply not acceptable.
The only valid answer is to switch to Linux.
(And don't ask the average user to understand or do anything to prevent that. Default matter.)
The previous status quo was that law enforcement, criminals, or that guy at Best Buy could by default get all the data off your drive without any effort whatsoever.
Microsoft added drive encryption by default with easy recovery if you forget your password - which necessitates Microsoft keeping the recovery key by default.
Power users can change these settings.
There is no "excuse" here, Microsoft has improved the situation. (And unless things have changed recently, user action is required on virtually every popular Linux distribution except Android to get any drive encryption at all.)
Everybody's talking about encryption these days. People are finally waking up and getting a bit suspicious. Obviously it is convenient for Microsoft to produce an inferior solution which also happens to be what the government wants.
What people need is education about the situation and a real solution. Not a "solution" that makes them feel secure, which is what Microsoft sells here.
> So Microsoft is charging more to not keep the key, which means they view it as a benefit for them to keep the key.
Or it means that Bitlocker has been a Pro or Ultimate feature in Windows Vista, Windows 7, Windows 8, and Windows 8.1, and PHBs decreed that Microsoft wasn't going to put the full-fledged feature in Home to continue to differentiate between Home and Pro and that the intended market of Home users did not need to be provided a way to lose their keys and brick their computers because nobody wants those support calls and the negative publicity about your data being inaccessible?
>the intended market of Home users did not need to be provided a way to lose their keys and brick their computers because nobody wants those support calls and the negative publicity about your data being inaccessible
So make the option a registry tweak, which is free, not an upgrade to Pro, which isn't.
I don't think freedom from corporate decryption abilities should be something charged for.
Device Encryption is just Bitlocker under the hood, which has been a Pro/Ultimate feature since Vista.
A basic version of Bitlocker has been provided since Windows 8 in the Home edition, as you point out.
There's nothing more I can write I didn't address in the above post. Device encryption and Bitlocker aren't separate entities. Device encryption is the consumer version of Bitlocker. Device encryption doesn't expose all the features of Bitlocker because then there's less that differentiates Home and Pro/Enterprise.
I agree it would be nice to have in Home, but the average Home user doesn't know what this is, doesn't want it, and probably shouldn't have it. If you are the kind of knowledgeable user that does know it and should have it, Pro isn't hard to get. Hell, Home doesn't even have freakin' Remote Desktop.
Microsoft has to have something to differentiate editions (if they're going to insist on doing so in the first place - life would be simpler if they didn't), this seems reasonable enough and a step in the right direction - more encrypted harddrives.
There is no "corporate decryption ability" unless Microsoft is in actual physical possession of your TPM and harddrive.
> I'm going out on a limb and suggest that Micah Lee understands why Windows works this way
Which he states on his own, and with a quote from an unnamed Microsoft representative, starting on the 7th paragraph:
> Of course, keeping a backup of your recovery key in your Microsoft account is genuinely useful for probably the majority of Windows users, which is why Microsoft designed the encryption scheme...
But, I agree with you. This is pretty much a non-story. One might have to jump through one more hoop to setup BitLocker without sending the key to any third party, but it's essentially the same as the default of sending your FileVault key to Apple for the easiest backup option.
Ending up being tech support for a lot of my family, I tend to agree with you. Microsoft is likely holding the keys to be able de-escalte users who forget their key. I doubt many home users understand that encryption keys are not like online account passwords (you can't reset them).
Since Microsoft presumably doesn't have the data, they get little value from holding the key. However, I would never copy a key without telling anyone.
About a year ago I had to re-enter the world of MS desktop OS's for commercial use. Given a need to dual-boot (GNU/Linux & Windows 7) I looked at the handful of options that existed for on-disk encryption that was palatable to both, and settled on VeraCrypt (one of the TrueCrypt forks). Biggest surprise was the inflexibility with key management.
What you say here -- encryption keys are not like online account passwords (you can't reset them) -- is NOT the default for people coming from dmcrypt[1], for example, where I can have multiple pass phrases / files to the same vault, easily adding and removing them.
It feels odd to work with at rest encryptions systems, and I'm guessing Win10 has the same constraint out of the box?, that don't offer this feature.
I'm sure the small segment of Microsoft's userbase that would recognize the name Micah Lee would find this story interesting since it provides some very helpful instructions.
Your comment is basically a tldr of the article. Not sure what your point is besides that you don't think it's interesting to educate Windows users about their encryption options.
His problem doesn't seem to be with BitLocker, but with the "device encryption", which is what most Windows 10 users will get. BitLocker is only available on Pro and Enterprise (a very lame move on Microsoft's part, if you ask me).
Device encryption tends to be terrible, and as Micah says you can't ever change the storage option for the recovery key. It's automatically tied to the Microsoft account.
If Windows Home had BitLocker, this wouldn't be a problem. But as with most of Microsoft'/Nadella's moves lately, they seem to believe they know best not for 99% of their users, but for 100% of them. That's how we got encryption keys that can only get stored in Microsoft/NSA's datacenters, telemetry services that you can never truly stop, and even if you do, they come back as zombies, and updates that you can at best delay, but also never stop. And that's on top of all the other privacy invasive "features" that are set by default, and Microsoft makes it hard for 99% of the users to know they can turn them off.
I have a lot of sympathy for Microsoft here, given some professional history with Chrome's Sync feature. Originally Sync data was always encrypted locally with either your Google password or a custom passphrase, and recovery wasn't possible (well, practical) absent that passphrase. The result was a bit of a support nightmare, as people would lose their sync data because they changed their account password and forgot the old one, or upgraded their machine and had forgotten the password years before, because it was being autofilled.
To solve the problem we ended up changing the way we managed the encryption, so we could recover the data for the default case, and kept the custom passphrase as an opt-in for local-only encryption. That's not to say I think we did everything we could to promote and support the use of a custom passphrase, but I am thoroughly convinced that it's not something the majority of users are concerned about or want to hassle with. If the average user forgets their password they still want to be able to get their data back (and there's no good way to forewarn or explain away why it won't work).
That's my theory. I've seen the same effect keep organizations away from working, encrypted email.
User: "What do you mean I can't access my emails because I lost my password?"
Admin: "For privacy, it's designed so that your password is only thing that unlocks the keys. If that's gone, then the email is gone. That's how it's supposed to work."
User: "Well, that's bullshit. Now, we might loose all kinds of money over this crap. And for what!? It's not like there's people snooping our traffic on the internal network."
Scenario plays out in so many situations. In business, it's availability first, integrity second, and confidentiality maybe. Almost always.
I agree that this is better than no encryption. And they're likely escrowing (in most but not all cases) the key for valid UX reasons. The tricky part is doing it without asking the user. Apple used to do optional escrowing on OS X with File Vault 2, but they asked the user.
The privacy/surveillance concern comes to play now that China has a law (as of Sunday) saying that tech companies need to be able to hand over keys on demand/request (whatever). Since Microsoft escrows them, they'd be capable of complying. Google and Apple who don't escrow them at all anymore, can't actually comply. Uncertain is whether the law requires them to start a key escrow function.
EDIT: And then what if/when U.K. wants access on demand to that escrow service? And then what if/when the U.S. does? If the companies have the keys, it doesn't require a law to get access to them, just a subpoena. It'd require a law to compel the companies to create the escrow capability though.
I still wouldn't escrow my disk encryption keys, but I'd be happier if Apple and Microsoft could guarantee that they couldn't access the escrowed keys, kind of like how tarsnap's design means that cpersiva doesn't have access to my backups.
Tarsnap's design means the keys never leave your possession; they're never escrowed. You can do this with Microsoft and Apple products, but it's not default.
Hasn't this been discussed multiple times? Microsoft tends to backup your key because the majority base doesn't understand how encryption works. When an average person thinks of passwords, they think there is a way to reset it. Good luck explaining to your grandma why all her favorite photos disappeared when she forgot the password.
I think for an average Joe this seems like a good strategy. With the defaults being off if the computer is stolen, all of their data and identity are stolen with it. This atleast acts like a door for an otherwise open house. Advanced users can use another encryption or do what the article suggests to not sent the key to Microsoft.
> As Green puts it, “Your computer is now only as secure as that database of keys held by Microsoft, which means it may be vulnerable to hackers, foreign governments, and people who can extort Microsoft employees.”
One way to think about this: before Win10, my computer was only as secure as the car I sometimes left it in, not to mention that it was only as secure as a bag which I admit I sometimes left out of my sight in coffee shops for seconds at a time.
Overall this is a great win. The NSA is not the only actor that FDE secures us from: FDE is more critically protection from anyone who can smash the window of your car or grab your computer in a public place and run. Security is always full of compromises, and MS here is making a compromise to provide protection from the latter group without significantly damaging data availability.
Think about this from a C/I/A perspective - that is, Confidentiality/Integrity/Availability as the security industry often discusses. Will-implemented encryption, with as few parties as possible in control of the key (e.g. only the data owner), is excellent for confidentiality and integrity. However, it can have severe impacts on availability if the key is lost. Controlling availability often requires policy and procedure controls (e.g. manually keeping a backup of the key on media stored in a secure place) which cannot simply be automatically enabled like FDE can.
Users who are worried about protection from actors like the NSA must take significantly more stringent security measures, including less technical policy and procedural controls, and Windows gives them the capability to do so by re-encrypting without backup to Microsoft and making their own backup which they can manage as they see fit.
>before Win10, my computer was only as secure as the car I sometimes left it in
This was nobody's fault but your own. FDE has been available for Windows for over a decade. You didn't have to wait for Microsoft to (poorly) implement this.
I've actually had FDE for ages (back to when I was using TrueCrypt!), that point was for illustration from the perspective of a normal user, who would have had almost zero exposure to these options.
Totally guilty on leaving my computer in coffee shops, though.
The keys are stored in your individual OneDrive not a centralized database.
OneDrive key integration isn't on by default even if you link a windows live account to your windows ID.
Also it's important to note that Microsoft doesn't have your key it has a key recovery element they still need the TPM and your physical drive to recover the full key this is a very very important part as they 1) still need physical access to your machine and 2) cannot arbitrarily encrypt data on your behalf.
FDE isn't there to stop government surveillance it's to stop your life from being ruined because you forgot your laptop at a coffee shop or because the guy who you gave your laptop for repairs is a watcher.
FDE's biggest problem is that it can fail very easily and very miserably especially when anti-tampering is enabled with external hardware. This solution solves all the usability issues as long as you can get online your laptop will not turn into a paper weight, I can't count the number of times that BitLocker especially 1.0 failed on me when the anti tampering was triggered due to power failure, BIOS update, boot loader reconfiguration and just because it can.
With this you get to keep all the anti tampering while still keeping your key relatively secure, OneDrive is probably more secure than pretty much any location you would normal keep the key recovery element yourself (Mine was both my wallet and a scrambled version under the battery when i still have laptops with removable battery).
P.S.
This is like the 10000's time this has been posted every time some one else discovers this and goes for the clickbait.
This is important. It isn't the same as them possessing the key. They still require physical access and of course with physical access, all bets are off.
The recovery password doesn't require anything stored in the TPM; if you just had an image of the disk and the recovery password, you could decrypt it.
I know that this article is specific to Windows 10.
However, it sounds like the same caveats and risks also apply to Apple's iCloud keychain.
I'm not trying to excuse one by pointing at the other... I genuinely want to understand any differences in the implementations and the security implications of those differences.
TLDR;
Micah Lee writes an article that takes an in-depth look at how various encryption policies work by default on Windows platforms. No good deed in netsec goes unpunished, so of course Micah is attacked by Ars P.Bright and @SwitftOnSecurity (you know, really reliable people compared to The Intercept :-p).
58 comments
[ 5.0 ms ] story [ 147 ms ] threadIs it true that all Windows 10 SKUs have full-disk encryption turned on by default?
And this automatic full-disk encryption is called "device encryption", which is really the same as BitLocker but without any way for the user to control it? And you can't get BitLocker on the Home edition?
If you immediately set up BitLocker, it allows you to save or print your key instead of sending it to Microsoft. But does it use the same key as the default "device encryption" that was already sent to Microsoft? BitLocker doesn't create a new key and re-encrypt the drive?
And the TPM automatically loads your key into RAM when the device is powered on, so it's still vulnerable when the device is not in your possession?
Are you safe if you (1) create a local account instead of a Microsoft account, (2) use BitLocker instead of device encryption, (3) save your key locally instead of sending it to Microsoft, and (4) require a separate PIN or key to boot the computer in addition to the local Windows account??
It would be helpful to describe exactly how to create a local account, because the Windows 10 setup procedure hides this pretty well. It looks like the only option is to use an existing Microsoft account or create a new one during setup.
And it would be great to explain how to create a secondary PIN or key since that doesn't show up in the BitLocker UI until you edit the local policy[1].
[1] https://weikingteh.wordpress.com/2011/04/18/how-to-enable-bi...
Unless you have a Home edition of windows, in which case you have no control over it at all. In order to use device encryption you have to sign on with a Microsoft Account and Microsoft will have the key.
I didn't notice at first, and really, there's no reason why I should have noticed. Also, I assumed Windows 10 Home didn't come with BitLocker anyway.
The Windows 10 security overview on Microsoft TechNet includes the following statements:
"Modern Windows devices are increasingly protected with device encryption out of the box and support SSO to seamlessly protect the BitLocker encryption keys from cold boot attacks."
"BitLocker supports encrypted hard drives with onboard encryption hardware built in, which allows administrators to use the familiar BitLocker administrative tools to manage them."
https://technet.microsoft.com/en-us/library/mt601297%28v=vs....
Apparently it's "device encryption" but it's not BitLocker. And while it's optional at the moment, it becomes compulsory in summer 2016.
This is compared to e.g. either Linux (LUKS) or OS X where the encrypted DEK is stored on the drive itself (outside of the encrypted volume of course), since neither of them leverage a TPM at the moment.
I get it, it's easy to pick on Microsoft and for good reason. But the hyper focus of this article screams bias.
Few years ago, I helped a person unlock their quicken backup file with help of Intuit by calling their support number. User forgot the password he created for the backup and when he tried to restore, he was unable to do it. Intuit was able to unlock that file for him using a master password...
Maybe someone can resolve this question by asking Google, examining Android source code, finding relevant online documentation, or even monitoring what a new Android device does on the network when setting up FDE. I don't feel like this should be a big insoluble mystery for the ages; it's a basic security property of a largely open-source OS that's one of the most popular in the world. We could even ask Micah Lee to do a follow-up article directly addressing other operating systems' FDE key management behavior.
It might also come as a surprise to many than most every post-2008 Intel processor is similarly insecure: http://libreboot.org/faq/#intel
That's not the question being asked. The question being asked is:
"How do you know that the key for full disk encryption on Android is sent to Google?"
Every technical person understands that any part of a system that has unrestricted read access to RAM can be used to thwart any FDE scheme. For the purposes of this conversation, it's not useful to talk about this.
Doing so is like saying "One can be instantly vaporized by a nuclear bomb, therefore the question is irrelevant." in a conversation about whether aspirin or ibuprofen is safer for occasional relief of minor pain.
That's a terrible analogy. It would be more accurate to compare this to aspirin and ibuprofen both sharing an unknown compound known to be capable of easily killing someone when the manufacturer wants it to, then suggesting we audit both aspirin and ibuprofen of their known compounds to make sure they don't have anything capable of killing someone. It doesn't really matter if it does, because you don't want to use aspirin or ibuprofen if you want to guarantee you won't die through someone's arbitrary decision, in the same way you wouldn't use Android on a phone if you want to guarantee security of your data.
After all, the article isn't claiming that Windows has a backdoor or that the Pro version secretly also escrows user keys with Microsoft while claiming not to. Backdoors in devices and operating systems are an important risk and an appropriate and interesting topic for researchers and journalists to dig into, but this article is about, essentially, documented or disclosed OS behavior!
On the other hand, Google claims they don't store your Android disk encryption key, yet for all their other services, they do. (They also backtracked on encrypting MicroSD cards, leaving your actual valuable data exposed yet giving you a false sense of security, but that's a discussion for another day). Chrome syncing (and by extension Chrome OS), for example, is decrypted by your Google account login. You can set up a second, separate passphrase for those services, but again the key is definitely stored by them.
Given that they have done some really shady stuff in the recent past (Chromium builds that download closed-source binaries after compiling from source and executing for the first time, etc.), I don't trust them as much as I trust Microsoft. And that's not a lot of trust in the first place.
I think the author of the article meant to compare the Windows behavior with other desktop operating systems, including Microsoft's other desktop operating systems. (I know him and have sometimes talked to him about this topic.)
> Of course, keeping a backup of your recovery key in your Microsoft account is genuinely useful for probably the majority of Windows users, which is why Microsoft designed the encryption scheme, known as “device encryption,” this way. If something goes wrong and your encrypted Windows computer breaks, you’re going to need this recovery key to gain access to any of your files. Microsoft would rather give their customers crippled disk encryption than risk their data.
> “When a device goes into recovery mode, and the user doesn’t have access to the recovery key, the data on the drive will become permanently inaccessible. Based on the possibility of this outcome and a broad survey of customer feedback we chose to automatically backup the user recovery key,” a Microsoft spokesperson told me. “The recovery key requires physical access to the user device and is not useful without it.”
The crux of the matter is that the article is trying to confuse readers of the purpose of the encryption. The purpose of Windows "device encryption" is to keep anyone other than you from using your device or getting data off your drive. If you're worried about Microsoft stealing your files, they don't need your key: they just need to wait for you to log in. The only reason Microsoft has the key by default is because users inevitably forget their password and people would be very, very upset if that meant all their data disappeared, just as the above quoted paragraphs suggest.
And if you're a power user who really knows what you want, then you don't have to let Microsoft have the key to your device.
It sounds like a pretty sane system to me and a non-issue.
> Or a law enforcement or spy agency could send Microsoft a request for all data in your account, which would legally compel them to hand over your recovery key, which they could do even if the first thing you do after setting up your computer is delete it.
> As Green puts it, “Your computer is now only as secure as that database of keys held by Microsoft, which means it may be vulnerable to hackers, foreign governments, and people who can extort Microsoft employees.”
The status quo was that if law enforcement or criminals seized your computer, they by default could access all your files. By encrypting the device by default, they at least added an additional hurdle for law enforcement and made it all but impossible for the common thief.
I don't see much to complain about other than it would be nice if Home users had the full Bitlocker feature.
That's my take on it as well.
It simply amazes me how most people will accept a vendor's total control of their cellphone or tablet, but when it comes to a PC (and PCs are getting smaller and smaller) everyone freaks out over the same thing. And in fact, Microsoft has far less control over a Windows PC than Google and Apple do over their respective phone OSes, especially if you don't use a Microsoft cloud account.
> The status quo was that if law enforcement or criminals seized your computer, they by default could access all your files. By encrypting the device by default, they at least added an additional hurdle for law enforcement and made it all but impossible for the common thief.
> I don't see much to complain about other than it would be nice if Home users had the full Bitlocker feature.
Amen.
Most users just beam all their data up to Google. LEO and whoever really wants to can get them to hand it over.
That key then is really only useful for keeping opportunistic snatchers in Starbucks out. For which it will work just fine.
Windows is a different story. You can keep your data from being beamed up. Wanting to keep anyone else out then is a matter of changing the key.
A bit of an apples-oranges scenario.
It's microsoft, so it's big evil being evil for the sake of being evil and you should hate them for being evil.
When did Google start storing Android full disk encryption passphrases? I certainly haven't heard that it does.
It's straightforward to set Bitlocker up so that Microsoft doesn't hold a backup key.
Microsoft is doing what their userbase wants them to do. I'm not sure what's interesting about this story.
The only valid answer is to switch to Linux.
(And don't ask the average user to understand or do anything to prevent that. Default matter.)
Microsoft added drive encryption by default with easy recovery if you forget your password - which necessitates Microsoft keeping the recovery key by default.
Power users can change these settings.
There is no "excuse" here, Microsoft has improved the situation. (And unless things have changed recently, user action is required on virtually every popular Linux distribution except Android to get any drive encryption at all.)
What people need is education about the situation and a real solution. Not a "solution" that makes them feel secure, which is what Microsoft sells here.
You are correct:
http://www.cnet.com/news/best-buy-employee-accused-of-copyin...
http://consumerist.com/2007/07/05/video-consumerist-catches-...
http://consumerist.com/2007/05/02/the-10-page-geek-squad-con...
So Microsoft is charging more to not keep the key, which means they view it as a benefit for them to keep the key.
If it was just to help the user, why charge to not upload the key?
So get pro.
Or it means that Bitlocker has been a Pro or Ultimate feature in Windows Vista, Windows 7, Windows 8, and Windows 8.1, and PHBs decreed that Microsoft wasn't going to put the full-fledged feature in Home to continue to differentiate between Home and Pro and that the intended market of Home users did not need to be provided a way to lose their keys and brick their computers because nobody wants those support calls and the negative publicity about your data being inaccessible?
>the intended market of Home users did not need to be provided a way to lose their keys and brick their computers because nobody wants those support calls and the negative publicity about your data being inaccessible
So make the option a registry tweak, which is free, not an upgrade to Pro, which isn't.
I don't think freedom from corporate decryption abilities should be something charged for.
A basic version of Bitlocker has been provided since Windows 8 in the Home edition, as you point out.
There's nothing more I can write I didn't address in the above post. Device encryption and Bitlocker aren't separate entities. Device encryption is the consumer version of Bitlocker. Device encryption doesn't expose all the features of Bitlocker because then there's less that differentiates Home and Pro/Enterprise.
I agree it would be nice to have in Home, but the average Home user doesn't know what this is, doesn't want it, and probably shouldn't have it. If you are the kind of knowledgeable user that does know it and should have it, Pro isn't hard to get. Hell, Home doesn't even have freakin' Remote Desktop.
Microsoft has to have something to differentiate editions (if they're going to insist on doing so in the first place - life would be simpler if they didn't), this seems reasonable enough and a step in the right direction - more encrypted harddrives.
There is no "corporate decryption ability" unless Microsoft is in actual physical possession of your TPM and harddrive.
Which he states on his own, and with a quote from an unnamed Microsoft representative, starting on the 7th paragraph:
> Of course, keeping a backup of your recovery key in your Microsoft account is genuinely useful for probably the majority of Windows users, which is why Microsoft designed the encryption scheme...
But, I agree with you. This is pretty much a non-story. One might have to jump through one more hoop to setup BitLocker without sending the key to any third party, but it's essentially the same as the default of sending your FileVault key to Apple for the easiest backup option.
Since Microsoft presumably doesn't have the data, they get little value from holding the key. However, I would never copy a key without telling anyone.
What you say here -- encryption keys are not like online account passwords (you can't reset them) -- is NOT the default for people coming from dmcrypt[1], for example, where I can have multiple pass phrases / files to the same vault, easily adding and removing them.
It feels odd to work with at rest encryptions systems, and I'm guessing Win10 has the same constraint out of the box?, that don't offer this feature.
[1] https://wiki.archlinux.org/index.php/Dm-crypt/Device_encrypt...
This is also how they implement recovery passwords (as 'numerical passwords') by default.
Device encryption tends to be terrible, and as Micah says you can't ever change the storage option for the recovery key. It's automatically tied to the Microsoft account.
If Windows Home had BitLocker, this wouldn't be a problem. But as with most of Microsoft'/Nadella's moves lately, they seem to believe they know best not for 99% of their users, but for 100% of them. That's how we got encryption keys that can only get stored in Microsoft/NSA's datacenters, telemetry services that you can never truly stop, and even if you do, they come back as zombies, and updates that you can at best delay, but also never stop. And that's on top of all the other privacy invasive "features" that are set by default, and Microsoft makes it hard for 99% of the users to know they can turn them off.
I have a lot of sympathy for Microsoft here, given some professional history with Chrome's Sync feature. Originally Sync data was always encrypted locally with either your Google password or a custom passphrase, and recovery wasn't possible (well, practical) absent that passphrase. The result was a bit of a support nightmare, as people would lose their sync data because they changed their account password and forgot the old one, or upgraded their machine and had forgotten the password years before, because it was being autofilled.
To solve the problem we ended up changing the way we managed the encryption, so we could recover the data for the default case, and kept the custom passphrase as an opt-in for local-only encryption. That's not to say I think we did everything we could to promote and support the use of a custom passphrase, but I am thoroughly convinced that it's not something the majority of users are concerned about or want to hassle with. If the average user forgets their password they still want to be able to get their data back (and there's no good way to forewarn or explain away why it won't work).
User: "What do you mean I can't access my emails because I lost my password?"
Admin: "For privacy, it's designed so that your password is only thing that unlocks the keys. If that's gone, then the email is gone. That's how it's supposed to work."
User: "Well, that's bullshit. Now, we might loose all kinds of money over this crap. And for what!? It's not like there's people snooping our traffic on the internal network."
Scenario plays out in so many situations. In business, it's availability first, integrity second, and confidentiality maybe. Almost always.
The privacy/surveillance concern comes to play now that China has a law (as of Sunday) saying that tech companies need to be able to hand over keys on demand/request (whatever). Since Microsoft escrows them, they'd be capable of complying. Google and Apple who don't escrow them at all anymore, can't actually comply. Uncertain is whether the law requires them to start a key escrow function.
EDIT: And then what if/when U.K. wants access on demand to that escrow service? And then what if/when the U.S. does? If the companies have the keys, it doesn't require a law to get access to them, just a subpoena. It'd require a law to compel the companies to create the escrow capability though.
I think for an average Joe this seems like a good strategy. With the defaults being off if the computer is stolen, all of their data and identity are stolen with it. This atleast acts like a door for an otherwise open house. Advanced users can use another encryption or do what the article suggests to not sent the key to Microsoft.
One way to think about this: before Win10, my computer was only as secure as the car I sometimes left it in, not to mention that it was only as secure as a bag which I admit I sometimes left out of my sight in coffee shops for seconds at a time.
Overall this is a great win. The NSA is not the only actor that FDE secures us from: FDE is more critically protection from anyone who can smash the window of your car or grab your computer in a public place and run. Security is always full of compromises, and MS here is making a compromise to provide protection from the latter group without significantly damaging data availability.
Think about this from a C/I/A perspective - that is, Confidentiality/Integrity/Availability as the security industry often discusses. Will-implemented encryption, with as few parties as possible in control of the key (e.g. only the data owner), is excellent for confidentiality and integrity. However, it can have severe impacts on availability if the key is lost. Controlling availability often requires policy and procedure controls (e.g. manually keeping a backup of the key on media stored in a secure place) which cannot simply be automatically enabled like FDE can.
Users who are worried about protection from actors like the NSA must take significantly more stringent security measures, including less technical policy and procedural controls, and Windows gives them the capability to do so by re-encrypting without backup to Microsoft and making their own backup which they can manage as they see fit.
This was nobody's fault but your own. FDE has been available for Windows for over a decade. You didn't have to wait for Microsoft to (poorly) implement this.
Totally guilty on leaving my computer in coffee shops, though.
Also it's important to note that Microsoft doesn't have your key it has a key recovery element they still need the TPM and your physical drive to recover the full key this is a very very important part as they 1) still need physical access to your machine and 2) cannot arbitrarily encrypt data on your behalf.
FDE isn't there to stop government surveillance it's to stop your life from being ruined because you forgot your laptop at a coffee shop or because the guy who you gave your laptop for repairs is a watcher.
FDE's biggest problem is that it can fail very easily and very miserably especially when anti-tampering is enabled with external hardware. This solution solves all the usability issues as long as you can get online your laptop will not turn into a paper weight, I can't count the number of times that BitLocker especially 1.0 failed on me when the anti tampering was triggered due to power failure, BIOS update, boot loader reconfiguration and just because it can. With this you get to keep all the anti tampering while still keeping your key relatively secure, OneDrive is probably more secure than pretty much any location you would normal keep the key recovery element yourself (Mine was both my wallet and a scrambled version under the battery when i still have laptops with removable battery).
P.S. This is like the 10000's time this has been posted every time some one else discovers this and goes for the clickbait.
I agree with everything else you stated though.
However, it sounds like the same caveats and risks also apply to Apple's iCloud keychain.
I'm not trying to excuse one by pointing at the other... I genuinely want to understand any differences in the implementations and the security implications of those differences.
I suggest Calculate Linux or Slackware, if you want to have a good time. they both run Steam.