Recently Bought a Windows Computer? Microsoft Probably Has Your Encryption Key
theintercept.com
theintercept.com
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.
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.
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.
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.
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.
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.
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].
[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.
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.