
Recently Bought a Windows Computer? Microsoft Probably Has Your Encryption Key - kmfrk
https://theintercept.com/2015/12/28/recently-bought-a-windows-computer-microsoft-probably-has-your-encryption-key/
======
tptacek
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.

~~~
jmount
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.

~~~
Jedd
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.

[1] [https://wiki.archlinux.org/index.php/Dm-
crypt/Device_encrypt...](https://wiki.archlinux.org/index.php/Dm-
crypt/Device_encryption)

~~~
geographomics
You can add multiple protection methods with BitLocker:
[https://technet.microsoft.com/en-
gb/library/ff829848.aspx](https://technet.microsoft.com/en-
gb/library/ff829848.aspx)

This is also how they implement recovery passwords (as 'numerical passwords')
by default.

------
jcrawfordor
> 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.

~~~
dublinben
>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.

~~~
jcrawfordor
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.

------
morganvachon
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.

~~~
Flimm
How do you know that the key for full disk encryption on Android is sent to
Google?

~~~
rdudek
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...

~~~
schoen
> How do we know they don't?

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.

~~~
beeboop
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](http://libreboot.org/faq/#intel)

~~~
simoncion
> 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.

~~~
beeboop
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.

~~~
schoen
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!

------
dogma1138
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.

~~~
geographomics
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 agree with everything else you stated though.

------
nivla
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.

------
cmurf
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.

------
panarky
I'm more confused now than ever.

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...](https://weikingteh.wordpress.com/2011/04/18/how-to-enable-bitlocker-to-
prompt-for-pin-during-startup/)

~~~
ashmud
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.

~~~
orillian
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.

~~~
scholia
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."

[https://technet.microsoft.com/en-
us/library/mt601297%28v=vs....](https://technet.microsoft.com/en-
us/library/mt601297%28v=vs.85%29.aspx)

~~~
scholia
_> Also, I assumed Windows 10 Home didn't come with BitLocker anyway._

Apparently it's "device encryption" but it's not BitLocker. And while it's
optional at the moment, it becomes compulsory in summer 2016.

------
mtnygard
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.

------
xenophonf
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.

~~~
feld
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.

------
anonbanker
So yeah, Linux is stable, and secure.

I suggest Calculate Linux or Slackware, if you want to have a good time. they
both run Steam.

------
jgallias
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).

