"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."
As a3n said, there was a NSL, FISA warrant, or other legal threat that says they can't reveal even the existence of it. Saying yes reveals the existence in an obvious way. Saying no might get them in trouble if revealed to be lying later in court or mainstream media. So, like with classified matters, the safest comment is to not have one. Neutral.
It's proven to work in terms of liability in majority of cases.
Please cite such a case --- meaning, a case in which a software vendor faced civil or criminal liability for revealing the existence of a backdoor shipped in its product. Since you used the word "proven", a single example seems like a very reasonable request.
That's a trap. I just said a situation where'd they might do time for revealing it. You essentially want me to show where they reveal it. A tall order but I'll try anyway. Yahoo fought the FISA court, lost, and others were shown same decision showing resistance would be treated criminally [1]. Lavabit was ordered to give up their key to FBI, not talk about it, and lie to users about their privacy. (Google court docs if you doubt last part.) Finally, the ECI-classified leaks have a slide that says the "FBI compels" [2] the cooperation of U.S. companies with NSA's secret program(s). Compel is undefined. Yet, FBI is a LEO and involuntary compliance with them usually follows threats, yes? The same term is also used in this [3] document citing the specific, federal laws. Both are consistent with Yahoo's claims and leverage same laws.
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.
What's the point of encryption if the government can still force the creators to decrypt it at the drop of a legal reason, which may or may not be substantial?
What you are missing is that if the government has access then ANYONE can have access. That's the problem with backdoors ANYONE can walk through them. If I encrypt data I want to be the ONLY person who can decrypt it. If not then it's no better than security through obscurity.
Not "anyone", but it's all a matter of price. Given enough resources, all back-doors are shallow :-)
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.
Seeing how cheaply the KGB compromised FBI and CIA agents, it's probably a price many can reach. You don't need to compromise the key, just fake evidence so as to put the target under suspicion and get it decrypted. They must often chase down false leads, so this might be rather unnoticeable.
Government access doesn't require a backdoor per-se, does it? Can't you encrypt something with two public keys, such that either associated private key alone can decrypt?
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?)
The problem here is that the NSA are also in the business of corporate espionage. They spy on US competitors and give the ideas and patentable concepts to US companies.
Therefore any company that is not American should shun such products like it is a herpes ridden whore.
Not at all. The BND in Germany have been shown to have been complicit in corporate espionage on behalf of the NSA on German companies. That's why dual key (government access) aren't to be trusted.
That's not true: it's a myth commonly reported by mainstream security types. They say that despite using so-called remote administration tools such as SSH that are specifically designed to do what they say a "backdoor" can't. They contradict themselves.
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. ;)
Same reason you lock your front door despite the landlord having a spare key, or the lock maker having a master key. You're screwed if the landlord or a rouge lock maker employee want to get into your place -- but it's good protection against everything else.
Physicals locks are poor analogies for encryption. A physical lock isn't designed to provide robust security - it's trivially easy to open almost any lock - it's to make opening it a noisy, slow, dangerous and expensive affair. And even if you have that magical perfect physical lock, few houses (or other containers) are impregnable.
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.
Exactly what you said whether people like the lock analogy or not. I used to encourage the use of high assurance security that comes from defense sector. People said "but they might be backdoored by NSA!" I said, "Maybe but they'll protect you from all the other threats which are doing the real damage here. You can always layer something foreign in there if you want to give NSA headaches." Same concept.
How about you being protected from basically everybody else?
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.
A court order is not easy to obtain and usually investigators have good reasons for asking for one. Warrantless searches is what I worry about, plus in some countries there are laws protecting people that don't want to disclose their password, like the fifth amendment in the US.
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.
Considering Schneier has been outspoken for decades about the importance of open source cryptography, I asked if he recommends that other people use BestCrypt, even though it’s proprietary. “I do recommend BestCrypt,” Schneier told me, “because I have met people at the company and I have a good feeling about them. Of course I don’t know for sure; this business is all about trust. But right now, given what I know, I trust them.“
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.
I've said it before: Schneier is an empty suit. He knows what buttons to hit in geek culture to get viral traffic, but a lot of what he preaches is questionable and seemingly personal and subjective. If anyone else would have said this they would have been instantly buried.
He's far from an empty suit given the diverse work he's done that's arguably good. He does occasionally make spot judgments that seem weak and go in what I believe is the wrong direction at times. Unlike many, I post counterpoints to him each time on his own blog and he makes no attempts to censor/grayout those via moderation. He rarely gets into those debates: we sort them out instead. Yet, he lets it all stand for his crowd to read.
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.
Bruce's comment is quite bizarre. Here is a slightly better quote from him in 2013:
"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."
> 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 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.
Why doesn't that apply to open source contributors? They can be bought or coerced too.
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.
Because if it's open source, I don't need to trust anyone. I'm totally going to review the source code and build the binaries myself. One day. After writing the next chapter of my book.
There is little assumption needed to know there is collusions between powerful corporations and government spy agencies.
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.
Exactly. The code and executable might not match. As in obfuscated C, the code might be subtly designed to fail. Further, the code might work but be integrated with libraries or deployed on an OS that the enemy knows they can hit. The security case of a given piece of software always depends on the reviewers and knowing you're using what they reviewed.
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.
I think the "good feeling" is supposed to be about their cryptographic experience and expertise.
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.
Somewhat. But that's a pretty thin link of trust. People change jobs and I doubt the people he knows personally know every line of code either.
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.
Mostly likely it's the kind of intuitive guess-work common for those those who've been reviewing black-boxes for years. You get what technical detail you can [which may be lies]. Past that, the competence, attitude, and priorities of the organization will tell you more about the estimated quality/security of their product than anything else. He apparently saw these were good at BestCrypt. So, if you can't use open-source, then he says use this company that seems more qualified and with better intentions than others (esp Microsoft!).
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:
What "guesswork"? What "black box"? Microsoft's code is the most comprehensively reverse-engineered in the world.
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.
That's all so irrelevant to our discussion I wonder why you bring it up. The point is that a black box takes the kind of effort you describe to review: "meaningful, significant costs" most can't or won't invest using specialist skills or tools most don't have. Are you telling me you fully reverse engineer all the state and code paths in every proprietary offering you consider along with a robust evaluation against known vulnerabilities? Or do you look at their stated claims, prior/current credibility, and perform some basic evaluation? Most of us do the latter for economic reasons and that leaves proprietary software as a black box.
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.
This is a bit tangential, but which are the credible open-source competitors to IDA and the arguably best currently-available assembler you're referring to?
I generally like and agree with FirstLook/Intercept articles but this....
> 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.
> 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.
> 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.
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.
I'm surprised Microsoft hasn't implemented AES-XTS with REFS in Windows 10. Okay, that was perhaps an acronym too far.
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.
I use bitlocker on my laptop and my portable backup usb stick. I have no illusion that it's probably back doored but I continue to use it simply as a casual insurance policy against doing something stupid like leaving the storage device on a train.
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.
Removal of the diffuser is very suspicious, given its importance. Machines were weaker when Vista shipped, so that's an odd claim, about security. And since AES-NI is more widespread I'd bet overall the system is even faster! They should back up such a claim with solid benchmarks (I never had a problem with it.) Plus they could make it optional, and/or disable it on low power machines.
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.
Curious, wasn't Vista shipping on computers that had to have more processing power and memory? Do you think that would negate the performance argument a bit or not be sufficient? It's hard for me to reconcile Microsoft's argument about security for lower-performance machines when they were forcing upgrades on customers at same time. Not to mention Vista's efficiency tradeoffs. (shudders)
My post was about software encryption. Maybe I should've clarified that better. The beefier machines Microsoft pushed for Vista might negate the performance hit that older hardware might experience with the Elephant option. I'm sure others have more expertise (eg performance comparisons of old machines) in that area so I asked them.
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.
I think you may have missed the gist of this subthread. The CBC diffuser in Bitlocker was removed in part because it doesn't benefit from the hardware crypto now shipped with Intel machines.
Vista did increase hardware requirements across the board. But the change we are discussing here was made in Windows 8 and later, which is exactly when Microsoft started caring about getting Windows into tablets and, in particular, ARM chips.
What makes you think the diffuser is all that important? Even the "state of the art" in full disk encryption doesn't reliably protect the integrity of disk sectors (this was part of Rogaway's critique of XTS during its standardization).
The comment is calling into question the intent of Microsoft in removing the diffuser. They thought it was important in benefiting security. So, did they remove it for performance or yet another concession to U.S. government? It's a valid question in assessing Microsoft's trustworthiness for security/crypto.
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.
I'm not interested in debating Microsoft's motives, because the engineering issues here are straightforward.
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.
Now that is a legitimate critique. It's why I prefer Inline Media Encryptors with trusted path. Those plus an encryption scheme addressing such known issues. The IME knocks the host TCB out of the equation, at least.
It's been a while since I read the Bitlocker paper, but I remember having the distinct impression the author found it critical to have. And Ferguson knows more about this stuff than I ever will, so I trust his assessment. If this has changed, wouldn't it elicit a bit of an explanation? "Windows 8 takes advantage of better crypto knowledge to remove improve Bitlocker speed."
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.
If it's "critical to have", you should be able to mount an argument as to why. It's a little annoying that discussions like these always seem to devolve to "such-and-such an expert said X or Y". We're not debating the Goldilocks Curve vs. the Microsoft NUMS curves. We should reasonably be able to expect people who want to argue about the "Elephant Diffuser" to understand the issues involved.
Here's the most worrying line of the article, in my opinion:
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."
The article is a horrendous failure by The Intercept, which I usually love to read. The most important part of evaluating trust is character. Microsoft's character on the topic is to use low-quality software processes until forced otherwise, notify NSA etc about bugs so they can hit them, help them do the same with third party software (eg Skype), backdoor their own stuff (eg NSAKEY), and so on. This is one of the least trustworthy companies in existence with a known track record in subverting security and crypto of their customers.
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.
"Microsoft said that the key's symbol was "_NSAKEY" because the NSA is the technical review authority for U.S. export controls, and the key ensures compliance with U.S. export laws" (Wikipedia on NSAKEY)
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.
I sometimes don't know where to start with comments like these.
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.
Given your rep, I'll assume you did thorough research and drop NSAKEY for now. I'll dig up that old work later for verification. If it checks out, I'll pass the correction along to others bringing it up along with modifying Wikipedia article to keep it from confusing others.
82 comments
[ 4.7 ms ] story [ 150 ms ] threadIt'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/...
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.
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.
> 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.
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.
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.
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.
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.
https://news.ycombinator.com/item?id=9297787