Silk Road forums
Discussion => Security => Topic started by: Bazille on September 08, 2013, 11:10 pm
-
http://boingboing.net/2013/09/08/firsthand-account-of-nsa-sabot.html
http://thread.gmane.org/gmane.technology.liberationtech/1185
On the Cryptography mailing list, John Gilmore (co-founder of pioneering ISP The Little Garden and the Electronic Frontier Foundation; early Sun employee; cypherpunk; significant contributor to GNU/Linux and its crypto suite; and all-round Internet superhero) describes his interactions with the NSA and several obvious NSA stooges on the IPSEC standardization working groups at the Internet Engineering Task Force. It's an anatomy of how the NSA worked to undermine and sabotage important security standards. For example, "NSA employees explicitly lied to standards committees, such as that for cellphone encryption, telling them that if they merely debated an actually-secure protocol, they would be violating the export control laws unless they excluded all foreigners from the room (in an international standards committee!)."
* NSA employees participted throughout, and occupied leadership roles in the committee and among the editors of the documents
* Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied.
* The resulting standard was incredibly complicated -- so complex that every real cryptographer who tried to analyze it threw up their hands and said, "We can't even begin to evaluate its security unless you simplify it radically". See for example:
https://www.schneier.com/paper-ipsec.html
That simplification never happened.
The IPSEC standards also mandated support for the "null" encryption option (plaintext hiding in supposedly-encrypted packets), for 56-bit Single DES, and for the use of a 768-bit Diffie-Hellman group, all of which are insecure and each of which renders the protocol subject to downgrade attacks.
* The protocol had major deployment problems, largely resulting from changing the maximum segment size that could be passed through an IPSEC tunnel between end-nodes that did not know anything about IPSEC. This made it unusable as a "drop-in" privacy improvement.
* Our team (FreeS/WAN) built the Linux implementation of IPSEC, but at least while I was involved in it, the packet processing code never became a default part of the Linux kernel, because of bullheadedness in the maintainer who managed that part of the kernel. Instead he built a half-baked implementation that never worked. I have no idea whether that bullheadedness was natural, or was enhanced or inspired by NSA or its stooges.
-
Interesting read. Another nice tidbit:
To this day, no mobile telephone standards committee has considered
or adopted any end-to-end (phone-to-phone) privacy protocols. This is
because the big companies involved, huge telcos, are all in bed with
NSA to make damn sure that working end-to-end encryption never becomes
the default on mobile phones.
-
Some German hacker built an encrypted ISDN phone in the 90s.
Less than a year later he got "suicided", probably by the same criminal organization which declared global war against internet cryptography.
https://en.wikipedia.org/wiki/Tron_%28hacker%29#Cryptophon
-
Oh yeah, does anyone remember this?
http://www.theregister.co.uk/2010/12/15/openbsd_backdoor_claim/
I guess that's more believable now.
-
anybody remember when a Debian developer accidentally ruined their PRNG and made all SSL certificates generated by Debian totally breakable (and lots of other Debian crypto breakable as well).
http://research.swtch.com/openssl
Last week, Debian announced that in September 2006 they accidentally broke the OpenSSL pseudo-random number generator while trying to silence a Valgrind warning. One effect this had is that the ssh-keygen program installed on recent Debian systems (and Debian-derived systems like Ubuntu) could only generate 32,767 different possible SSH keys of a given type and size, so there are a lot of people walking around with the same keys.
Many people have had fingers pointed at them, but it is not really interesting who made the mistake: everyone makes mistakes. What's interesting is the situation that encouraged making the mistake and that made it possible not to notice it for almost two years.
To do that, you have to understand the code involved and the details of the bug; those require understanding a little bit about entropy and random number generators.
In the security community right now a lot of people thinking this may have been covert operation by the NSA.
-
anybody remember when a Debian developer accidentally ruined their PRNG and made all SSL certificates generated by Debian totally breakable (and lots of other Debian crypto breakable as well).
Yeah, even assuming it was just stupidity and not malice, the fact that it persisted for so long had to be frightfully encouraging to anyone watching from the sidelines and wanting to water down something Open Source.
The OpenBSD thing struck me as bizarre when it happened, but it never resulted in any hard conclusions that I saw, just allegations. Hard to judge, because Theo endears himself to so many. Much of my confidence in OpenBSD comes from the fact that Theo pisses off *so* many people. The fact that we don't see a root OpenBSD exploit a week is a testament to their small TCB and codebase, because he's definitely spent the past 10-15 years motivating people to prove him wrong.
While backdoors can definitely be inserted in open source projects, they've been few and far between. I can only think of a handful off the top of my head in the past 20 years (barring just plain stupid examples of folks hacking source repositories, etc). And I can think of a million examples of ways you'd get owned by not upgrading to the latest version of whatever.
Not upgrading vulnerable software because of fears of backdoors in the newest version is almost always the wrong decision.
-
The OpenBSD thing struck me as bizarre when it happened, but it never resulted in any hard conclusions that I saw, just allegations.
My understanding is that a thorough code review of that time period found no malicious code, but the more important point is that three letter agencies have been actively trying to subvert internet encryption for a long time, as far back as 1999. In the OpenBSD case, they wanted to break a VPN that other government agencies were using, I believe.
This all started with the fight against Zimmerman and PGP. They lost in the courts, so they turned to technical subversion, and have been trying to do it ever since, although they haven't always succeeded.
Of course, they still use the law when it is handy, such as making people sign 10 year NDAs and using secret courts cover up their illegal activities.
-
The OpenBSD thing, was a sabotage of the local CVS they were using to build a custom project for the FBI, which I believe was a VPN box. The feds wanted the ability to spy on their own employees so demanded a backdoor and the guy obliged, but he didn't get his changes into the main repository. Regardless they did a full Ipsec stack check to make sure and found nothing, but alas with the criminal behavior of the NSA lately anything is possible.
Lot's of talk between non tinfoil hat developers on various IRC/Hacker News/Mailing lists that basically every single open source project is likely using sabotaged compilers with built in doors and trojans. http://www.dwheeler.com/trusting-trust/
Deterministic building is now mandatory for the Tor project, I see all the operating systems starting to do this. Compiler jacking is pretty dangerous, you could possible have access to a billion+ machines.
-
The concept of compiler backdoors is obviously a worst case for everyone. No disagreement there.
We tend to think of backdoors in code in terms of simple bypasses of checks, or obviously screwing with seed values to PRNGs. The clever way to do it at an NSA level would be with very small changes to multiple interrelated components and libraries that added up to a weakness. Nowhere near a full flaw or vulnerability, but just a weakness that would give them leverage to bring the "nearly-impossible" down to a level like "somewhat-difficult". Especially if they happen to be very good at whatever specific kind of "somewhat-difficult" task that is.
But since we don't really know exactly what is easy/hard/hardest for NSA, it's difficult to identify all the ways that code could be changed to give them leverage. That's specifically why the Snowden disclosures piss them off so much. Sure, the public drama has to suck, but the bigger threat is that all of their adversaries can make inferences just like we're doing (but augmented with crib sheets of their own intelligence to help out) to identify where NSA/etc may have focused their efforts, and make better guesses as to what is easy/hard/fast/slow for them to accomplish.
The good news? Snowden's disclosures have caused much of the security community to feel like they've been complacent and naive. That's a fantastic motivator to build systems that withstand the sorts of threats that we're seeing. Less naive reliance on centralized directories and services (i.e. CA's). Decentralization is really the only defense against NSL's.