http://windows.microsoft.com/en-us/windows-8/bitlocker-recov...
>There are several locations in which your BitLocker recovery key might have been saved.
Keyword: might.
"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.
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.
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 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.
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.
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.
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.
And how does grandma retrieve it if she forgets her password?
Also, does Apple do this for OS X or just iOS?
We get it.
Key escrow can be key escrow for everyone.
Grandma gets her copy and so does Big Brother.
The stated reason was FIPS compliance.
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?
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.
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).
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.
* 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.
> 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.
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.
Maybe you could reply to the others.
Where you can no longer reasonably hold your position is where you got off the train.
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.
It would be really cool to hear what you think of using CBC mode for FDE, though.
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. :)
i may have to do some wikipedia editing later today ;-)
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.