NSA Foils Much Internet Encryption 607
An anonymous reader writes "The New York Times is reporting that the NSA has 'has circumvented or cracked much of the encryption, or digital scrambling, that guards global commerce and banking systems, protects sensitive data like trade secrets and medical records, and automatically secures the e-mails, Web searches, Internet chats and phone calls of Americans and others around the world, the documents show. ... The agency, according to the documents and interviews with industry officials, deployed custom-built, superfast computers to break codes, and began collaborating with technology companies in the United States and abroad to build entry points into their products. The documents do not identify which companies have participated.'" You may prefer Pro Publica's non-paywalled version, instead, or The Guardian's.
More technical discussion (Score:5, Informative)
From Bruce Schneier Here [theguardian.com] and here [wired.com].
Also a nice call to arms here [theguardian.com].
"I have resisted saying this up to now, and I am saddened to say it, but the US has proved to be an unethical steward of the internet. The UK is no better."
Re:SSH? (Score:5, Informative)
Re:SSH? (Score:5, Informative)
I wonder if their list includes SSH
OpenSSL came from SSLeay, which was created outside of the US specifically for this reason.
Its not a technical attack in the first round;
The long, strong arm of the NSA
July 27, 1998
Web posted at: 4:15 PM EDT
http://edition.cnn.com/TECH/computing/9807/27/security.idg/ [cnn.com]
[..]
It's gotten to the point where no vendor hip to the NSA's power will
even start building products without checking in with Fort Meade first.
This includes even that supposed ruler of the software universe,
Microsoft Corp. "It's inevitable that you design products with specific
[encryption] algorithms and key lengths in mind," said Ira Rubenstein,
Microsoft attorney and a top lieutenant to Bill Gates. By his own
account, Rubenstein acts as a "filter" between the NSA and
Microsoft's design teams in Redmond, Wash. "Any time that you're
developing a new product, you will be working closely with the NSA,"
he noted.
[..]
Clearly wary of granting the government supervision over its products,
Microsoft has stubbornly refused to submit a data-recovery plan, even
though the Redmond giant already includes a data-recovery feature in
its Exchange Server.
"The Exchange Server can only be used when this feature is present,"
Rubenstein said. "Because we haven't filed a product plan, it's harder
for us to export this than for companies that have filed plans."
[..]
Re:Uh... okay (Score:5, Informative)
No need to compromise anything. They just need a single CA to be complicit with a court order to produce a certificate that signs an NSA-provided key for a specific site. Then, they can freely MITM that site. SSL is swiss cheese as security goes, because certs are automatically trusted if signed by a CA, are never stored, and their designated requirements are never checked when determining whether a new key should be trusted or not. In short, SSL is a train wreck.
Self-signed keys are not more secure. If a site goes from a self-signed cert to a signed cert with a different key, most browsers do not display any warning. Although you can install anti-MITM tools that produce a warning when the key changes, those tools would detect such a government MITM whether you're using a CA-signed cert or a self-signed cert. By contrast, a CA-signed cert makes it much harder to perform a MITM attack the first time a user goes to your site, effectively limiting such attacks to those who can convince a CA to give them a cert for your site. Guess which is more likely.
Re:SSH? (Score:5, Informative)
Unless you exchange private keys offline, manually, preferably not using any temporary electronic storage means, the NSA has your keys.
um you never exchange privet key's you only share public keys.
Re:SSH? (Score:2, Informative)
Re:SSH? (Score:5, Informative)
The claim is VPNs and SSL... so either a break in RSA or AES, either way SSH would be covered.
You do not need to break RSA or AES to break a lot of VPNs. I.e. if you use aggressive mode IKEv1 PSK (typically plus XAUTH, but that does not actually help), the shared private key can be recovered by offline attacks. NSA supercomputers should have no problem handling most keys. Alternatively, if certificates are used, many organizations buy premade certificates including secret keys instead of going through the trouble of generating their own secret keys. That means the NSA only has to compromise the few certificate vendors.
And this is just the passive attacks the NSA can do. If they actively interfere, they can use downgrade attacks or (for HTTPS) the various TLS vulnerabilities or use proper fake vendor certificates or all sorts of other mischief. That is harder to pull off unnoticed of course.
Very little equipment supports IKEv1 with "raw" RSA keys (no certificates), even though that takes the whole PKI problem away and avoids aggressive mode. I'm only aware of (free|open|libre|strong)SWAN and RouterOS. IKEv2 is almost non-existent, and what little equipment supports it tends to only support the equivalent of IKEv1 main mode with PSK or certificates -- precisely the areas where IKEv1 is already good enough.
For those of us who use proprietary encryption acceleration: how do we know that the session keys are chosen securely and not divulged with steganography somehow? I know that products have existed which did exactly that, revealing part of the encryption key in the encrypted data stream (and I know that because the vendor was fairly open about the practice).
Re:I call bullshit (Score:3, Informative)
You can make keys longer than that too.... google on how to patch gpg for large keys.
I personally use a 16384 key for weaker stuff, and a 32768 bit key for more serious things.
The 4096 bit ceiling was purely for computational speed. Any higher back in the day would take over a day to generate the key. Took my machine 4 hours to make the 16384 key with modern hardware but this is significantly more secure than 4096.
Protip, you can still work with unpatched clients as long as your key is 16384 or less. You can go higher but only then with everyone you communicate with having the patched client. That's why I stick to 16384 for compatibility but go larger when serious.
Re:SSH? (Score:5, Informative)
Certificate authorities never see private keys so you are dead wrong about that. What's more, even if a rogue CA was minting bad certs on the fly to attest that the NSA was really foobar.com, that would have been noticed. Remember that secrecy is something they value insanely highly. They wouldn't ever do something so easily noticed and the articles do not imply any kind of CA compromise.
In fact if you read all the stories (they overlap largely but not entirely) you can get a vague picture of what's going on. Firstly, they record all encrypted traffic in case they can decrypt it later. Secondly, they have a database of public to private keys, populated via any means they can. Thirdly, they obtain keys in lots of ways (hacking, subversion, bogus court orders, brute forcing old/weak keys etc) but they don't seem to have a magical solution to all strong crypto. The closest that the leaks come to this is discussion of some amazing cryptoanalytic breakthrough, which could possibly mean they're able to break some kinds of RSA? Perhaps they're ahead of Joux et al by some years?
Regardless, what it is, it can't be a solution to all crypto, because these governments apparently asked the newspapers not to publish on the grounds that people might switch to stronger systems that worked.
Re:Uh... okay (Score:4, Informative)
There's nothing in the articles that implies this. Backdooring a CA only helps if several things hold:
1) They can not only intercept but also rewrite traffic on the fly. Possible, but if so, not yet mentioned in any leaks.
2) They're willing to take the chance that someone might notice.
So an operation against a single site, definitely possible. But they are clearly desperate to grab everything, all the time! Their whole MO is not targeted investigations but to spy on everyone simultaneously. You can't use a rogue CA to do that. They'd be detected immediately, if only by geeks setting up SSL for their new personal VPS and suddenly noticing the CA their browser gets isn't the one they installed.
The problems with SSL are not that CAs exist. The model holds against the global adversary who wants to decrypt everything. The problems with SSL are almost certainly more prosaic - many websites can be automatically hacked and their keys stolen without the owners ever knowing. In the default config that allows you to then decrypt all past traffic as well. Some implementations will use old, weak keys that were strong once upon a time but have since become obsolete. Some implementations will have bad random number generators. Some implementations will run on VPS providers and are subject to side channel attacks by colocated VMs. Some keys can be subpoenad and others can be obtained by covert agents. And of course you still leak traffic metadata even when SSL works perfectly.
There are lots of ways to attack SSL that will work some of the time, and that's exactly what the leaks imply - they can beat encryption sometimes but they don't have a magic skeleton key to everything.
Raw document (Score:4, Informative)
The raw document [theguardian.com] provides some more details but remains not especially explicit.
"The fact that NSA/CSS has some capabilities against the encryption in TLS/SSL, HTTPS, SSH, VPNs, VoIP, WEBMAIL, and other network communication technologies".
Capabilities are defined here as NSA/CSS ability to exploit a specific technology. This may encompass acquiring and processing plaintext data and/or acquiring, decrypting and processing encrypted data.
Re:perspective (Score:2, Informative)
It needs to be kept in mind that the definition of "legal search" in this day and age doesn't exactly translate into what a normal thinking person would think it does. Plenty of things are "legal" in this country that are in fact rather blatantly unconstitutional.
Remember, we've had a "conservative" Supreme Court for a long time now and they're doing what every consertative court has done before them: making it harder for people to hold big business and law enforcement accountable for anything. The only rule of law they're interested in is ruling over you and other actual people. They're not interested in the rule of law as it applies to restrain those in power. That's how you create a dictatorship. We may not have a single dictator, but make no mistake, in every way that actually matters, that's what we have now.
Re:SSH? (Score:5, Informative)
Bruce Schneier should be technically competent enough for you, see his articles today at the Guardian.
http://www.theguardian.com/commentisfree/2013/sep/05/government-betrayed-internet-nsa-spying
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance
Re: SSH? (Score:5, Informative)
From the article it sounds like the NSA has compromised most commercial VPN software (and is working on the rest) with backdoors, etc.
Do you use commercial (non open source) VPN software? If so, it doesn't matter that your keys are secure.
Re:Works for me (Score:2, Informative)
The phrase is "you have another think coming".
Re:SSH? (Score:5, Informative)
To be 1000% clear... all a CA does is sign keys generated by others. They never see the private server key(s). Having the CA signing certificates doesn't give you the magic ability to decode a site's traffic; it only allows you to pretend to be that site. (assuming you can get the users traffic to come to, or through, you. and that other steps (fingerprint validation, serial number checking, etc.) aren't being used.)
Re:Uh... okay (Score:4, Informative)
I think you can assume that most "popular" commercial encryption software has been compromised.
Bruce Schenier has a good article in The Guardian on how to protect your computer:
http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance [theguardian.com]
From the article:
With all this in mind, I have five pieces of advice:
1) Hide in the network. Implement hidden services. Use Tor to anonymize yourself. Yes, the NSA targets Tor users, but it's work for them. The less obvious you are, the safer you are.
2) Encrypt your communications. Use TLS. Use IPsec. Again, while it's true that the NSA targets encrypted connections – and it may have explicit exploits against these protocols – you're much better protected than if you communicate in the clear.
3) Assume that while your computer can be compromised, it would take work and risk on the part of the NSA – so it probably isn't. If you have something really important, use an air gap. Since I started working with the Snowden documents, I bought a new computer that has never been connected to the internet. If I want to transfer a file, I encrypt the file on the secure computer and walk it over to my internet computer, using a USB stick. To decrypt something, I reverse the process. This might not be bulletproof, but it's pretty good.
4) 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.
5) Try to use public-domain encryption that has to be compatible with other implementations. For example, it's harder for the NSA to backdoor TLS than BitLocker, because any vendor's TLS has to be compatible with every other vendor's TLS, while BitLocker only has to be compatible with itself, giving the NSA a lot more freedom to make changes. And because BitLocker is proprietary, it's far less likely those changes will be discovered. Prefer symmetric cryptography over public-key cryptography. Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can.
Re:Works for me (Score:5, Informative)
I'd like us to continue treating encryption as weapons and regulate its export accordingly. Unfortunately, it is not really possibly — any enemy worth the designation would be able to get it anyway, because moving an algorithm is much easier than a gun. And, unlike guns, you only need to move an algorithm once.
I wish I had sufficient confidence in my own government to be able to sincerely pick charity... Unfortunately, I do not. If the President can already ask the IRS to hurt opposition's finances [dailycaller.com], what's to prevent him from asking the NSA to look into the opposition's e-mails? The sort of thing, that got Nixon to resign is barely an issue with today's Americans...
However, according to an earlier article about Snowden's interaction with journalist(s) [nytimes.com], PGP (with sufficiently large keys) is still unbreakable even to the NSA — at least, as far Snowden was aware:
So that's, what a particularly private person should be using for all of his communications...
Re: Works for me (Score:2, Informative)
Re:Works for me (Score:5, Informative)
Though I sympathize with the gist of your position, I must question this particular argument:
Why exactly is this so? Of course, it would be rather uncomfortable to have no privacy, but would it necessarily lead to tyranny? Why not the opposite, for example — if no one's dealings are private and all information (from banking transactions, to kissing, to bowel movements) about everyone is readily available to whoever cares, wouldn't it be harder to subdue the electoral process, for example?
You would make it much, much easier to "subdue the electoral process". If you're currently the party in power and facing re-election, you first kill everyone who donates money to the opposition--everybody stops giving them money, hampering their campaign. Then you kill anyone who's given any hint that they might vote for the opposition. You and your cohorts get re-elected. Rinse and repeat, and eventually nobody dares form an opposition party, much less support one. If anybody says or does anything that remotely sounds like rebellion, you kill them too. Your party stays in power indefinately, the only things that might end your reign are a split in your party, or killing off so many people that there not enough people left to work and your economy collapses.
Re:SSH? (Score:4, Informative)
It's here: http://www.nytimes.com/interactive/2013/09/05/us/unlocking-private-communications.html?ref=us [nytimes.com]
Re:NIST 2006 (Score:4, Informative)
No, the article wasn't referring to AES. AES was developed by a pair of Belgian cryptographers as part of an open competition. The NSA approves the use of AES to protect Top Secret information. They didn't put a back door in AES.
The article was referring to the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), published as part of SP800-90. The DRBG uses a set of constants, like many crypto algorithms. The NSA, as the designer of the DRBG, selected the constants. Microsoft researchers noted that if the constants were carefully chosen, the NSA could predict future outputs of the DRBG. Despite what the New York Time article says, the NSA probably didn't do that. No one was going to use this DRBG anyway, except for the NSA and their partners, so they would have very little reason to sneak in a backdoor. Still, it's a bad property to have in a crypto algorithm. You should really explain the provenance of any constants used in a crypto algorithm, and there was no explanation of how the Dual EC DRBG constants were selected.
Re:Uh... okay (Score:4, Informative)
I'm sure part of the NSA's task isn't just compromising root CA's, but shutting down those who refuse to cooperate.
You may recall that even though lavabit shut down voluntarily the feds are still after them trying to get them busted on contempt charges for pulling the plug on themselves.
Re:FREEEEEEEDOM! (Score:4, Informative)
Re:SSH? (Score:4, Informative)
Certificate authorities never see private keys
Theoretically, in practice average Joe buy their certificate and private keys from a third party.
Um, no, Joe average does not. Joe doesn't understand where his keys come from, but the CA doesn't provide them.
The public/private key pair is generated on Joe's computer. Most CA's issue certificates through a web-based form, and that form triggers the browser to generate the key pair locally. Then the public key is placed in a certificate request and uploaded to the CA. Some time later the CA signs the public key and produces the resulting public key certificate, which is downloaded.
The private key never leaves the user's computer until they move it somewhere else (e.g. to install it in their web server).
Re:Works for me (Score:2, Informative)
Spy on foreign governments and foreign citizens. They need to stay the fuck away from Citizens of the United States of America. Spying on Americans is what other governments are for.
The NSA isn't actually spying on US CItizens, they're just storing the data in easy-to-interpret databases so that other governments can do the spying for the NSA. Oh, and probably also providing those governments with the tools they need to better spy on US Citizens.
Skirting the law is easy with the right thinkers. New Zealand was doing a similar thing with the GCSB by sending their contractors off to work for other government agencies. The contractors, being employed by the other agencies and hidden from the GCSB by a really secure "please don't let us know if you use our computers while working for them" policy, weren't part of the GCSB, so didn't have to play by their rules (which basically said "no spying on NZ citizens", recently changed to "only spy on NZ citizens if the government-selected overseer decides there's good reason for it").
Re:HTTPS forward secrecy to the rescue (Score:4, Informative)
Forward secrecy is supported in Apache 2.2.x in the form of ephemeral Diffie Hellman key exchange ("DHE"). This works out-of-the-box on Debian and Ubuntu servers (I run a few Debian/Ubuntu servers, and have those options enabled) without needing to recompile anything.
Apache 2.4.x is require for use of elliptic curve ephemeral Diffie Hellman ("ECDHE"), which provides greater protection with shorter key lengths (e.g. a 256-bit EC key is equivalent to a 3072-bit discrete log key, but Apache 2.2.x uses a baked-in set of DH parameters that's only 1024-bits long). EC is also a lot faster than discrete log DH which is useful in certain environments.