Microsoft Gives Details About Its Controversial Disk Encryption
firstlook.org
firstlook.org
It's proven to work in terms of liability in majority of cases.
So, I believe that the FBI and NSA might have worked together to use legal threats related to Patriot Act to force companies to comply with SIGINT-enabling for collection purposes. The other ECI leaks mention U.S. companies that were cooperative and made their systems "exploitable" for "SIGINT-enabling." So, they offer money first and call the FBI if that doesn't work. Almost everyone caved so I'm guessing there's a significant, legal threat there.
They're not telling you in detail because it's classified: releasing the info is a felony. Who would after seeing what happened to other whistleblowers... It's why I recommend privacy-focused companies being located in Iceland or countries similarly non-cooperative with police state activities. At least one can legally resist subversion in those countries rather than experience... whatever FBI does... for not subverting one's products.
[1] https://www.techdirt.com/articles/20130614/10341723470/yahoo...
[2] https://firstlook.org/theintercept/document/2014/10/10/eci-w...
[3] https://www.nsa.gov/public_info/_files/speeches_testimonies/...
Uhh what?
So following that same logic, if I know people at Microsoft who wrote the code for BitLocker, and I trust them, I should trust BitLocker.
Not the typical action of either someone trying to hide their incompetence or an ego-maniac. This attitude of his is why a number of us contributed there for years. Plenty of what we posted also pre-empted the Snowden leaks (incl many TAO attacks). Plenty to learn archived over there.
"Be suspicious of commercial encryption software, especially from large vendors. My guess is that most encryption products from large US companies have NSA-friendly back doors, and many foreign ones probably do as well. It's prudent to assume that foreign products also have foreign-installed backdoors. Closed-source software is easier for the NSA to backdoor than open-source software. Systems relying on master secrets are vulnerable to the NSA, through either legal or more clandestine means."
The article would have been far better if they only included Microsoft's answers and ended the piece with the same line:
"Whatever you choose, if trusting a proprietary operating system not to be malicious doesn’t fit your threat model, maybe it’s time to switch to Linux."
Not entirely unreasonable [0] -- a significant benefit of open-source is that more people have access to the code of the same software you are evaluating, so its more likely that you will be able to find a trusted evaluator (or, if you have the skills to do the evaluation, to do it yourself) -- and that you will likely have more trustworthy evaluators, as well.
But, ultimately, yes, its a question of trust in people who are familiar with the code , and what Schneier describes is a not unreasonable basis for personal trust in closed-source code, its just harder to get than a comparable basis for trust in open-source code.
[0] The problem in both cases is that there are more people involved that you need to trust, although sufficient trust in and information from the people writing the software could suffice to trust the software.
If we are assuming some malevolent entity powerful enough to manipulate the world's largest companies like marionettes, I don't see why we think open source is safe.
Open source isn't fully trustable either, especially by the vast majority of users who are unable to review the source. But it is better, and we should not let perfect be the enemy of better in this case.
That this is usually lacking in vast majority of software is why we're seeing a ton of vulnerabilities in both commercial and FOSS software.
The second point about trust doesn't directly flow from the previous sentence (which would make it sound like he's saying something like "I trust this person sight-unseen"); instead, he's just meaning that cryptography (like any technology) ultimately requires you to trust someone at some point, because you can't audit every line of every piece of software and firmware you're sitting on top of.
And because of that, while there can be a point where you know "enough" about a particular codebase's architecture and management to have faith in its stewardship (or enough to not have faith in said stewardship—OpenSSL, for example), you can't really ever know everything there is to know about a codebase now-and-forevermore such that you no longer have to trust anyone about anything.
In the end, he's trusting MS the company as a whole.
Generally when I 'trust' open source, it's not a specific person I'm trusting. More so, I "trust" that given the millions of programmers in the world that will look at this code there will be one with similar interests to me that will catch any nefarious bits that slip in.
I think these two kinds of trust are categorically different. One providing much more permanence than the other.
So, he prefers we have or use open-source crypto where we can but recognizes many won't be able to. He gives them the best option he's seen in proprietary sphere for modern Windows boxes. Incidentally, that's the best that can be done outside of reverse engineering. That's how thin our trust baseline is in commercial crypto. It's why I pushed for a paid, open-source model with independent review below:
https://www.schneier.com/blog/archives/2014/05/friday_squid_...
Somehow, between the beginning of the Linux era and, say, 2005 or so, people forgot how to efficiently comprehend large assembly programs. But it's not 2005 anymore; it's fully ten years later. Virtually every software security team in the world has multiple people on staff who know what basic blocks and control flow graphs are. There are credible open-source competitors to IDA, and arguably the best disassembler currently available costs something like $80 and backs assembly out to C.
Closed source software imposes meaningful, significant costs. It's reasonable to prefer open-source code, or even to require it. But we cannot reasonably make the excuse that closed-source code is a "black box" anymore.
As for Microsoft, there's all kinds of people reverse engineering their code with most doing it to write exploits. So far, nobody has shared a link to a bug-for-bug compatible source equivalent for Bitlocker to analyze for cryptography issues. I'd just be taking someone else's word that (a) they R.E.'d it enough to see all potential subversions, (b) they had the skill to spot clever subversions with little context, and (c) they weren't lying to me. Please link to papers showing such a full deconstruction of the Bitlocker code with a hash that we can use to confirm it's the same on our machines. It will boost everyone's confidence in the product. Otherwise, you're talking like it's been rigorously R.E.'d and reviewed while providing zero citations to back that. Meanwhile, the Internet is full of citations on Microsoft's security failures and deceptions. Status quo stands until you deliver proof otherwise.
REFS is Microsoft's answer to the new generation of copy-on-write filesystems, akin to ZFS and BTRFS. It checksums all data on disk to verify integrity.
AES-XTS is a block cipher mode that avoids many of the problems of AES-CBC, although neither is as bad as EBC. But like all block cipher modes used for FDE, they're susceptible to malleability attacks. That's because there's just no room in a sector to store authentication information. Enter: a filesystem that performs checksumming and performs authentication at a higher level.
It's a little disappointing to me that Bitlocker was weakened and, from the outside, it appears no significant effort was undertaken to resolve this using tech Microsoft already has. The weak link may be some NTFS features that REFS doesn't implement, as currently Microsoft doesn't support using REFS for your system drive.
MS should have pushed to get the diffuser into whatever "standards" (I'm guessing OPAL/eDrive) they are worried about. And IIRC, the diffuser is quite fast, but nothing stops them from implementing an even faster one.
Kinda. When Elephant was designed AES-NI did not exist, and so AES was expected to work at somewhere between 10-20 cycles per byte. Elephant worked somewhere between 5-10 cpb, so it was not a lot of overhead. Post-AES-NI, however, the majority of CPU time is now spent on the diffuser.
Furthermore, SSDs were not popular at the time this was designed. So the relative low speed of software AES + diffuser was not that big a deal. Now, with 500 MB/s and higher drives, cipher speed matters. For reference, 10 cpb translates to ~200 MB/s in your average 2 GHz processor.
This is not to say that removing Elephant was a good idea, but the performance argument is not entirely unreasonable. It is of course possible to design a new diffuser that can take better advantage of modern chips; maybe they should do that.
Is Elephant even available, though? Even if someone has a low end chip but needs a high IO rate and thus must turn off Elephant, why kill off the feature? That's what's so odd. They admit it's critical, then go on to completely delete it, no mention of why (until this one line explanation now). For many users, the perf impact is irrelevant. I rarely do high rate IO (boot and copying movies); even large compiles I doubt are hitting the 100MB/sec level.
At 5cbp, even a low end Atom will get 100-200+MB/sec, right? What low end devices are pushing that on any frequent enough basis to hurt the user?
And, given their weight, they could have forced these requirements into eDrive, and offload it all to the SSD controller.
Regarding your tangent, hardware encryption will almost always beat software encryption in same process node technology. The next best thing are processors highly-optimized for cryptography (eg GD's AIM), vector processing with crypto-focused operators (SIMD/MIMD), or massively parallel processing with tiny cores (eg FPPA, GPU's) using the right ciphers/cryptosystems. We saw less-mainstream work focusing on these three in late 90's and early 2000's because they would accelerate arbitrary crypto while making upgrades easy. Flexibility & cost-reduction trumped raw performance in many use-cases. Certain defense contractors still sell products like those with more R&D work ongoing. Also support my polymorphic cipher designs unlike hard blocks.
Of course, we already have plenty on that subject. A good answer won't change anything. A bad one is extra nails in the coffin.
The Bitlocker "diffuser" code attempts to make it harder to make targeted changes to plaintext, without making it Hard to do so, because making it Hard is prohibitively expensive.
No mainstream full-disk encryption scheme makes it Hard to tamper with on-disk plaintext. The best anyone does is allowing attackers to randomize a wide-ish block at an attacker-chosen offset.
It is hard to use that primitive to pop calc.exe on boot, but it remains a powerful primitive: attackers can replace integers in trusted code or data files with very very large integers, and then exploit the resulting memory corruption.
The commenter below explains the performance implications, which are real.
I'd also note that the trend in Bitlocker seems to be to just delegate to the SSD, completely relying on the SSD vendor to get it right. That has zero performance overhead and is more suitable for low end devices.
> Microsoft, after considerable prodding, provided me with answers to some longstanding questions about BitLocker’s security. The company told me which random number generator BitLocker uses to generate encryption keys, alleviating concerns about a government backdoor in that subsystem
And then to answer it:
> Microsoft told me that while the backdoored algorithm is included with Windows, it is not used by BitLocker, nor is it used by other parts of the Windows operating system by default. According to Microsoft, the default PRNG for Windows is an algorithm known as CTR_DRBG, not Dual_EC_DRBG, and when BitLocker generates a new key it uses the Windows default.
Oh they "told you", great I guess we will just take them at face value and move on case clo... FUCK NO. Are you fucking kidding me???? MS may be getting better over all as a company by security/privacy is something I still don't trust them one bit on. That's not to say I think Apple is some bastion of privacy but MS has been in bed with the government for a LOT longer and hasn't been anywhere near as supportive of privacy/security as Apple has been as of late.
This ENTIRE article is supposed to be take on faith and I'm sorry but that's not good enough. It's one thing to say "Some encryption is better than none" or "It will protect your from run-of-the-mill thieves but not the government" but to eat up everything MS said as fact is insane...
And as one more gem:
> I asked Microsoft if the company would be able to comply with unlocking a BitLocker disk, given a legitimate legal request to do so. The spokesperson told me they could not answer that question.
MS knows what side their bread is buttered on and let me give you a hint, it's not the consumer side.
This actually sounds a lot like the government mandated a backdoored crypto algorithm in to a suite of crypto algorithms, and then Microsoft was forced to implement the backdoored algorithm in order to get certified for the suite, which is required for government contracts.
> I asked Microsoft if the company would be able to comply with unlocking a BitLocker disk, given a legitimate legal request to do so. The spokesperson told me they could not answer that question.
There's a ton of perfectly benign reasons that a spokesman would decline to answer that question, and since we don't have a direct quotation, we don't even know what the response actually was.
I don't particularly like Microsoft, but I feel like we should blame them for the things they actually do, not hold them to unreasonable standards.
Why ask when you can check?
All vendors are shits on this front. Look like a good boy on paper and do all your naught stuff via a side channel.
And when speaking of encryption, people should be concerned with crime syndicates or with industrial espionage, in other words entities that might have the resources to find and access those back-doors.
http://stackoverflow.com/questions/597188/encryption-with-mu...
Multi-encrypt the harddrive with YourPubKey & SpooksPubKey, and viola. The spooks have access, without giving criminals access (unless they steal SpooksPrivateKey, but is that any more risky than theft of YourPrivateKey?)
Therefore any company that is not American should shun such products like it is a herpes ridden whore.
So, a secure backdoor means you have to make a high assurance design/implementation of a remote access tool plus protect its keys. The last part is harder to do. NSA already does this, though, with their EKMS. So, most technical problems outside EMSEC and side channels are solved for such a simple use-case. It's the malicious insider risk that worries me and U.S. government is so thoroughly infiltrated that giving them keys = giving keys to top opponents. Maybe.
I wish those briefing Congress would bring up this side of things more often while citing DOD's own documents on their thorough compromise by Chinese, Russians, and so on. "Trust us and our double agents to protect your secrets against foreign governments" can't look convincing to most of Congress. ;)
A physical lock is more like an effective intrusion detection system - it's not going to prevent hacks, but it might make those that have something to lose think twice, and at least you're likely to know if you've been robbed. Just like intrusion detection, physical locks make it at least somewhat risky to even try to break in - after all, you might get caught.
Am I the only one who would rather not let any random theif have access to all my personal stuff? If the government wants to fuck me over they don't need my laptop for that.
You also have to consider that the punishment for refusing to comply with a court order may be less than the damage you may do to your case by disclosing your password and here I'm specifically thinking about people that do have something life-threatening to hide, like whistleblowers or whatever.
It's most likely beyond the average man to decrypt my data and that's good enough for me.
Applying the grey man principle, hiding in plain sight by blending into the crowd is a good approach. If you have something to hide, do it via a side channel, preferably off line and carry on using what everyone else does for everything else.
Asked about instances in which Microsoft built methods to bypass its security and about backdoors generally, a company spokesperson told me that Microsoft doesn’t consider complying with legitimate legal requests backdoors.
Which says to me, "There are no backdoors, provided we redefine the word 'backdoor' to be exclude all of the mechanisms we currently employ."
So, his research comes down to two major options: the above company's crypto product with assurances of their PR team; a proprietary product with no troubling history & endorsed by a well-known cryptographer. If Win8 and above, he should start talking about BestCrypt rather than dropping a whole extra paragraph on Bitlocker's advantages and how its fine for the average user. It's not fine because (a) the source screws all of its users, (b) alternatives only flourish if you support them (vote with wallet), and (c) a site accepting submissions on corrupt organizations by leakers should never recommend trusting security tech of a corrupt organization whose contributes to the evils they report on.
So, this post is just stupid except for the tiny parts where it mentions alternatives. Matter of fact, it reads like an advertisement written with the assistance of Microsoft's lawyers and publicists. I'm not saying it was but any objective investigation should never look like that.
Conclusion: Don't trust The Intercept for INFOSEC advice, don't trust Microsoft for security/crypto, use BestCrypt if on modern Windows, use VeraCrypt for Win7 or earlier, and switch to Linux if possible for extra transparency/options.
We actually don't know what it is past that. So, Microsoft says it was required for export approval & made backup key. NSA controls those export requirements. A declassified CIA document [1] from the period shows export changes were pro-escrow and most big companies were onboard. In short, the NSA, FBI, CIA, and other companies agreed on escrow keys for export of strong cryptography. Microsoft added an escrow (err backup) key called _NSAKEY for export approval. Logically, we should assume it was a COMSEC backdoor for NSA so Microsoft could make money on exports.
Assuming anything else is logically questionable given no hard data contradicting this and Microsoft's history of covert cooperation with NSA in much worse ways. Hard data as in statements by Microsoft such as above straight up saying who ordered the change and what it does vs the mere speculation we saw elsewhere.
[1] http://www.foia.cia.gov/sites/default/files/DOC_0006231614.p...
We do in fact know what it is, because no matter what the bits of the secret key are, the use of the key in Microsoft's software is published: the code we're talking about isn't obfuscated.
You say "[l]ogically, we should assume it was a COMSEC backdoor for NSA so Microsoft could make money on exports". You say that as if it was impossible to look at the code and see where the key is used. It obviously isn't. People have done that work. They did it years and years ago. They explained what the key does. But the conspiracy theory about NSAKEY being a secret backdoor keeps coming up.
Once again: the key we're talking about doesn't even make sense as a backdoor. It's a second authentication key, the first of which is a key Microsoft already has, and could already use to the exact same effect.