Comment by xnull2guest | Hacker News Reader

Comment by xnull2guest | Hacker News Reader

Parent Full thread

For personal use this is most certainly the case. Here are quotes and links from both Microsoft Technet and tech media coverage.

"Unlike a standard BitLocker implementation, device encryption is enabled automatically so that the device is always protected. The following list outlines the way this is accomplished:

* When a clean install of Windows 8.1 is completed the computer is prepared for first use. As part of this preparation, device encryption is initialized on the operating system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker suspended state).

* If the device is not domain-joined a Microsoft Account that has been granted administrative privileges on the device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a recovery key is uploaded to online Microsoft account and TPM protector is created. Should a device require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key access URL to retrieve the recovery key using their Microsoft Account credentials."

http://technet.microsoft.com/en-us/library/dn306081.aspx

"... because the recovery key is automatically stored in SkyDrive for you."

http://www.zdnet.com/surface-bitlocker-and-the-future-of-enc...

"BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices."

http://technet.microsoft.com/en-us/library/dn306081.aspx#BKM...

Device Encryption is supported by Bitlocker for all major skews including Windows Server 2012 R2.

That isn't Bit Locker, it's device encryption which is supported in 8.1 (Home) and Windows RT where naive users are more likely to forget to backup the key and hence lose data.

BitLocker is only available in the professional,enterprise and ultimate versions of Windows 8.1 and it does not automatically backup the key to an MS account.

"BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices."

http://technet.microsoft.com/en-us/library/dn306081.aspx

Device Encryption is supported by Bitlocker for all major skews including Windows Server 2012 R2.

They have also backported Device Encryption to 8.

Edit: Per your comment below you recognize that it is enabled automatically on PCs - and this is supported by the documentation provided. The grandma argument doesn't stack up with the fact that OneDrive/SkyDrive is enrolled in PRISM.

The big difference is that it's automatic on RT, Phone and 8.1 if the hardware supports it. Think Grandma's PC. Do you really want her to see the option window about where to store a recovery key? For the other SKUs, an option window pops up when you enable BitLocker asking about backup location.

>Edit: Per your comment below you recognize that it is enabled automatically on PCs - and this is supported by the documentation provided. The grandma argument doesn't stack up with the fact that OneDrive/SkyDrive is enrolled in PRISM.

The encryption is automatic, hence it makes sense that the backup is forced. Given that many Windows user get confused when their icons are moved, it would be hard to expect them to manage decryption keys. A significant percentage could lose their data. This is still better than earlier versions of personal use Windows where the data wasn't encrypted at all and all one had to do is to connect the hard drive on a different computer. On Professional and Enterprise versions, when you choose to encrypt, the dialog box with the choice does appear, I just tried.

It does not matter whether a dialog box appears. Have you confirmed that the keys are not pushed into OneDrive? (That's the thing to check.)

So what you are saying is that bitlocker keys are automatically uploaded to OneDrive and OneDrive is PRISM, but this isn't key escrow for government.

The backup can both be for Grandma and Federal Law Enforcement. They are not mutually exclusive.

My original point stands. Modern Windows Bitlocker keys are automatically placed into a location where TLAs can request them.

BitLocker is not the same as Device Encryption. Please stop confusing the two. Also you have been unable to say what you want Microsoft to do in grandma's case.

"BitLocker provides support for device encryption on x86 and x64-based computers with a TPM that supports connected stand-by. Previously this form of encryption was only available on Windows RT devices."

http://technet.microsoft.com/en-us/library/dn306081.aspx

They are not the same. Agreed. Sorry about the confusion.

Anyway, it's true that modern Windows Operating Systems, even on non-RT devices, upload bitlocker keys automatically and transparently to the cloud, where the data is indexed for the PRISM program. They do this with Device Encryption, which is supported by Bitlocker on x86 and x64-based computers with a TPM that supports connected stand-by.

Edit: Regarding Grandma. Keys can be stored on a non-boot internal drive. Keys can be shown on the screen as a QR code (and the screen can tell Grandma to take a picture). Grandma's keys can be printed out on a small detachable USB or SD/MicroSD device with a kilobyte of space. The machine can provide provisional encryption until Grandma's computer can connect to a printer (where it gets printed). Grandma's computer could send the key over USB/Bluetooth/Wifi to a trusted computer friend after pairing (such as a 'tech savvy' niece/nephew). There are plenty of options.

The 'grandma clause' is not mutually exclusive with key escrow. OneDrive is a nice place for grandma AND a nice place for the FBI.

No it doesn't. The key could be automatically saved in the TPM - locally. Yet Microsoft chooses to save it in its own cloud.

And you could make the same argument against Android 5 and iOS 8 encryption, too. That users won't be able to "recover" their data. Tough luck. Google and Apple did it anyway, and it seems to be a successful move.

Microsoft is now the only one of the three major platforms who doesn't provide secure automatic encryption with locally stored keys.

>No it doesn't. The key could be automatically saved in the TPM - locally.

And how does grandma retrieve it if she forgets her password?

Also, does Apple do this for OS X or just iOS?

Grandma recieves it from the same place law enforcement does.

We get it.

Key escrow can be key escrow for everyone.

Grandma gets her copy and so does Big Brother.

via matthew green recently: So per @justintroutman and now confirmed, Microsoft has substantially weakened its disk encryption in Windows 8. Now uses plain CBC mode.

Yup, the diffuser was removed years ago. The designer of the diffuser removed was Neils Ferguson, the cryptographer who called out DUAL_EC as a backdoor in 2004.

The stated reason was FIPS compliance.

Do you understand what the "diffuser" in Bitlocker was intended to do? Virtually every other mainstream FDE scheme uses XTS, which is also not authenticated; XTS is literally the ECB mode of tweakable block ciphers.

> Do you understand what the "diffuser" in Bitlocker was intended to do?

Yes.

> Virtually every other mainstream FDE scheme uses XTS, which is also not authenticated; XTS is literally the ECB mode of tweakable block ciphers.

Not really relevant?

If you think the point I made about XTS isn't really relevant, I'm going to timidly suggest that you don't actually understand Elephant. I apologize in advance for saying that, but I think it's more productive to be honest than tactful in this case.

AES CBC + Elephant != XTS

Elephant 'mixes' the blocks on a sector level to limit CBC block modification attacks. It does not limit the maximum size to align to sectors. It is not XTS.

Nor is my claim that Elephant is what you want or need. Merely that it was removed, that Ferguson designed it, and that FIPS compliance was the underlying justification.

I didn't say Elephant was XTS. I said that neither XTS --- the industry standard sector-level construction --- nor Elephant actually authenticated sectors.

All three of AES-CBC, Elephant, and XTS fail to authenticate data. This isn't my point; it's Rogaway's, and the opinion of several other people during the XTS standardization process, including Ferguson.

So it's a stretch to talk about how Microsoft "weakened" Bitlocker by removing the idiosyncratic Elephant construction. None of the design alternatives Microsoft had available provided real authentication, and all of them provide adequate confidentiality (to the extent that's possible with sector-level crypto, which is itself just a bad idea).

Couldn't it both be true that Microsoft weakened Bitlocker by removing Elephant AND that AES-CBC + Elephant isn't good enough (e.g. lack of integrity)?

We might discuss how to best design FDE, or whether FDE is what we want.

But that conversation is orthogonal to the fact that AES-CBC is weaker than AES-CBC + Elephant, which is what we are talking about here.

Your criticism comes down to: "CBC + Elephant may be stronger than CBC, but neither are strong enough for me". I agree with this.

Not quite. My high level response to this thread, which opened with a subtextual claim that Microsoft removed Elephant in yet another example of a big vendor being coerced by NSA into weakening end-user crypto, is twofold:

* First, that Elephant does not provide meaningful (and certainly not provable) security improvements, and, put in the context of FDE in general, does not give/remove a Bitlocker capability that other mainstream FDE systems actually have.

* Second, that the clunky feature Elephant tries to provide (Ferguson calls it "poor man's authentication") is in fact not at all relevant to the NSA threat model; to wit: if your adversary has an (a) continuous and (b) active vantage point to hit you from, no FDE solution can help you. FDE is exclusively valuable in the case where your disk is irrevocably and totally compromised, despite the folklore that says otherwise.

Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA.

Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.

The security improvements due to Elephant certainly are not proveable (what in crypto truly is?). I argue that there is meaningful security added by Elephant, clunky though it certainly is - because it does make block modification attacks (which could be used to thwart "Secure Boot") and in that 'poor man's authentication' is better than no man's authentication. Here the perfect very well may be the enemy of the good. Of course I would be happier with something even better.

> Popping up a level further on the stack: I'm rebutting the claim that NSA coerced MSFT into removing Elephant. It was a marginal implementation of a marginal countermeasure that wasn't relevant to NSA.

Not sure whether this is strong enough evidence to be considered a rebuttal. I do not know and will not claim that it was the NSA (or other) coercing MSFT.

> Popping up a level further on the stack: I do not believe that NSA has within the last decade coerced Microsoft into doing anything cryptographic.

Not the NSA key? Not the removal of end-to-end crypto from Skype and then onboarding of Skype to PRISM? Not the SEA hacking of FBI request documents? Not bitlocker keys automatically uploaded to OneDrive, and OneDrive onboarded to PRISM? Not TPM 2.0 support - not Germany's leak of TPM backdoors - not China's following ban of TPM 2.0 and Windows 8.1 - not Microsoft's then downport of TPM 2.0 support to Windows 8?Not the cloud key escrow patent?

"Once a request comes in from a third party (e.g. a user, a business, a legal entity or governmental entity, etc.) to access user's data, the data storage system may send..."

https://www.google.com/patents/US20120321086

"MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs

http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30)

You probably think Microsoft did these things without NSA/TLA coercion.

"What in crypto truly is provable" is where I get off this train.

Hey I love (and defend) crypto but ultimately it relies on (sometimes standard) assumptions like the one-way hardness of discrete logarithms. Symmetric systems hardly have underlying information theoretic garuntees - usually symmetric constructs are based on reductions under random oracle models (which have has its own methodological problems). Furthermore implementations are hardly the same as mathematical constructs, which gives rise to side channels.

These are not controversial views - they are common knowledge among cryptographers.

It is thus an injustice to knock Elephant on 'provability' grounds. The papers for Elephant (and Lion before it) follow standards for peer reviewed work in cryptography.

It is a shame you will not reply to any of the examples in the remainder of the comment.

But other HN readers will see them.

Tiniest violin playing for the loss of another pointless discussion about NSAKEY.

https://www.schneier.com/crypto-gram-9909.html

And the others? Do I get an ORCHESTRA?

Maybe you could reply to the others. Agreed NSAKEY is old news.

NSAKEY isn't "old news". It's a bullshit conspiracy theory. It doesn't even make sense as news.

I understand how you feel about NSAKEY.

Maybe you could reply to the others.

The crypto bit is perfectly reasonable in this context as Elephant meets the standards for crypto publication in this regard. You excuse leaks water.

Where you can no longer reasonably hold your position is where you got off the train.

You've downvoted the content rather than replying to it.

I'll repeat it again, for the benefit of the larger HN community (and you can get you jollies downvoting again).

"MS, working with the FBI, developed a surveillance capability to deal with the new SSL... went live Dec 2012" - Snowden docs

http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPl... (30)

Microsoft stripped security from newly deployed TLS, worked to undermine TPMs, store copies of your Bitlocker keys for law enforcement, hand cloud data to law enforcement and stripped crypto from Skype.

They either did this all on their own voluntarily, were encouraged or pressured, or where forced. Choose your demon.

https://www.dropbox.com/s/pqy5un1vzcho6a4/Screenshot%202014-...

https://www.dropbox.com/s/bswum0iz8ggfheo/Screenshot%202014-...

Not that you're implying this, but just to be clear: I haven't ever hinted or suggested the NSA had a hand in this. I don't think they did. I can't think of a reason it would make sense. Lastly, I do not think Niels would silently let this happen; he was adamant about this when allegations arose in 2006. Elephant was somewhat of an "edge", even if only a slight one.

What does CBC mode have to do with the security of Bitlocker? Do you think CBC mode is weak because of that god-awful Wikipedia article on full disk encryption? Because that article is god-awful.

I've never used or studied BitLocker and don't have much relevant expertise when it comes to FDE...just was reading comments and was reminded of a tweet that seemed relevant.

It would be really cool to hear what you think of using CBC mode for FDE, though.

I think neither CBC mode nor XTS mode is a great tool for encrypting disks, but rather than restating all my thoughts, I'll just link back to what I wrote about it a few months ago:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

But, apropos this thread: the specific claim Wikipedia makes about the insecurity of CBC mode for FDE was debunked by Phil Rogaway, who --- much as I like Justin Troutman --- trumps Justin Troutman. :)

this was an excellent read--thank you

i may have to do some wikipedia editing later today ;-)

I'm okay with being trumped by Phil; that's fair. :)

I'm largely in agreement with you, and I enjoyed your article on XTS. My general thought towards Elephant's contribution to CBC is that it forced coarse-grained manipulation, which is probably a lot more likely to crash a system as opposed to allowing meaningful attacks.

To risk a new design like Elephant implies that they found the attack model worth consideration; we know the rationale for including it, but we don't know the rationale for removing it. Perhaps knowing this would tell us something useful about current perceptions on disk encryption.

Lastly, I echo your disdain for sector-level encryption.

Reply on news.ycombinator.com