NSA infiltrated RSA security more deeply than thought: Study

http://www.reuters.com/article/2014/03/31/uk-usa-security-nsa-rsa-idUKBREA2U0U620140331

by Libertatea • 12 years ago

425 97 12 years ago

dan_bk• 12 years ago

"We could have been more sceptical of NSA's intentions," RSA Chief Technologist Sam Curry told Reuters. "We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

PS: "We also would like to express that we believe the entire World to be a bunch of idiots."

higherpurpose3• 12 years ago

Does the word "NSA" still have a 60 percent upvote penalty here? It seems to be moving pretty slowly up. I understand using that sort of penalties if during a period of time the site gets flooded with those stories, but I don't think keeping the penalty forever is such a good idea, or at least not such a big one. Maybe make it "decay" over a period of time.

tokenadult• 12 years ago

What is your documentation for saying that a particular word in a headline has any penalty at all?

AFTER EDIT: I guess I'm glad I asked, downvotes and all, because I see the link is to a source off HN, not to a statement from any of the HN moderators (which is what I was checking).

revscat• 12 years ago

http://www.righto.com/2013/11/how-hacker-news-ranking-really...

Crito• 12 years ago

Scratch HN moderators, here it is straight from the horse's mouth:

"So already for the past week TSA stories have had an automatic penalty applied. Or more precisly, they've been autotagged as being political, which entails a penalty."
"When anything gets over a certain number of flags, it shows up on a list that admins see. They decide either to kill it, mark it as political or whatever, or do nothing."

https://news.ycombinator.com/item?id=1934950

So, at least as of 3 years ago, HN both "autotags" and has admin driving tagging. Penalties are given to posts that have received particular tags.

Strictly speaking, "words in titles" may or may not be involved in that "autotagging", but given PG's history with content classification... I suspect it is.

bradleysmith• 12 years ago

I'm glad you asked. I was not aware of any published documentation of HN's algorithmic workings, and had the same question.

I also appreciate an established name in HN pointing out that the linked article was not from a moderator. It points itself out quickly, but it's nice to know something is derived information before clicking.

noja• 12 years ago

Derail!

eli• 12 years ago

This story is on the front page which suggests to me that the current system, whatever it is, can't be that broken. Meanwhile these meta discussions (of which I'm now a part) get tired pretty quickly.

kens• 12 years ago

You can tell that the article has been penalized by comparing it with the articles above it. Currently this article is at #7 with 168 points and 2 hours. The #6 article is at 179 points and 6 hours. The #5 article is at 172 points and 4 hours. Because time is weighted heavily (an exponent of 1.8), the NSA article would easily rank above these ones if there are no penalties. Thus, due to penalties, the NSA article is ranking a few spots below where it should, but is still on the front page.

Source: I did the righto.com analysis of how HN ranking really works.

jacquesm• 12 years ago

It's been penalized, but you don't know how. It could simply be a bunch of flags.

Zigurd3• 12 years ago

Although these stories have a political dimension, they also have at least two other highly relevant dimensions:

1. Who can be trusted? Is it OK to have NSA employee participation in open source projects? Is it OK to mask contributor identity in open source projects that are widely used to provide security?

2. What are the technical measures US and other nations' Internet service companies can take to restore trust? Will any major provider provide auditable, buildable client software that implements end-to-end encryption?

Currently, the value of this set of issues is over $100B in lost business for US technology companies. What other $100B+ issues are on the table here where there are available technology solutions?

jusben1369• 12 years ago

I remember when this first broke getting heavily downvoted for suggesting that RSA wasn't paid $10 million to create a backdoor for their customer's as everyone was implying at the time. Rather, they (naively) were paid to joint develop a technology that would be a marketing dream "Hey this included help from the brightest minds at the NSA so why wouldn't you use it for your own organization?!"

So I found this quote to be very interesting: "We could have been more sceptical of NSA's intentions," RSA Chief Technologist Sam Curry told Reuters. "We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

higherpurpose3• 12 years ago

They took the money and then accepted NSA's "help".

hga• 12 years ago

"We trusted them because they are charged with security for the U.S. government and U.S. critical infrastructure."

Which is true, and as examples we have SE Linux and apparently strengthening the S-boxes of DES against differential cryptanalysis, which had not yet been independantly discovered by public researchers (https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA.2...).

However, that was then; now, we legitimately trust the NSA a lot less, but I'm not sure we should blame RSA too much for not noticing the transition.

I'd also note that I arrived at MIT a couple of years after RSA was first published, and I heard various rumors that there were rather intense sub rosa interactions between the team and the NSA et. al. in that period. With a good outcome, but threats were made etc.

akira2501• 12 years ago

I've brought up the S-Box strengthening several times before, but it's important to note that the NSA pushed IBM to reduce the key length in DES. IBM wanted 64 bits, NSA wanted 48, and we all got 56 as a compromise; not entirely egalitarian work.

ig13• 12 years ago

A far bigger issue is "The NSA played a significant role in the origins of Extended Random. The authors of the 2008 paper on the protocol were Margaret Salter, technical director of the NSA's defensive Information Assurance Directorate, and an outside expert named Eric Rescorla."

Given Rescorla involvement with the TLS standard and Mozilla it's concerning that he declined to comment on this.

doe88• 12 years ago

I'm maybe too naive/optimistic but I think the most likely is that he has been manipulated in co-authoring a document which by itself is innocuous but once coupled with a rigged prng might have disastrous effects.

ig13• 12 years ago

Sure, he might be innocent, but he really needs to put out a statement clarifying what his involvement was and what he knew.

Mozilla should probably hire an independent auditor to review all of his code changes. It might be unnecessary but this seems to be a scenario where it's better to play it safe (plus always good to audit security related code).

mcphilip3• 12 years ago

Well there's at least one other document coauthored by M Salter and E Rescorla [1], so the notion that Rescorla was manipulated into co-authoring the Extended Random paper has is a bit more problematic since it wasn't a one-off collaboration.

[1]http://tools.ietf.org/html/draft-ietf-tls-suiteb-00

higherpurpose3• 12 years ago

It's also very concerning that are least 2 NSA employees working within IETF groups as far as I know, and they don't want to get rid of them. One is the one Trevor Perrin called out from the CFRG, but I remember someone else calling out another on a security blog, either months before the Snowden leaks came out or soon after.

NSA is not to be trusted in terms of security anymore, when by far their main priority these days is to undermine the security of protocols. If certain organizations don't want to get rid of them, then I can't trust that organization either. And I don't care how much of a "good guy" he is within the organization. It's probably his job to play the good guy.

derefr• 12 years ago

Having NSA employees standardizing TLS extensions is about as surprising as having Google employees standardizing HTTP extensions. The NSA isn't just a bunch of spies; they're also the managers of the US government's crypto infrastructure.

If the USG wants to make some devices--secure phones, say--that use TLS in a weird way, but wants other devices--commercial off-the-shelf routers, say--to be able to interoperate with those devices, then the USG gets the NSA to draft a TLS extension allowing the routers to consider the behavior of the secure phone normative.

tptacek19• 12 years ago

Careful with how you word this. Rescorla isn't an "outside expert"; he's been at the center of TLS standards for almost a decade now (he's also the author of SSLDump, which is/was a very useful tool). It's not hard to see why Rescorla would get roped into this: he's a standards sherpa. If you want to get some oddball extension you need for your internal systems specified, so that other systems might interoperate with yours, Rescorla is naturally the person you'd turn to.

Rescorla's name on an Internet draft is hardly an endorsement from Rescorla. I'm not sure that's how you're supposed to read any Internet standard; it happens to often be true, but it isn't always true. Sometimes those things get written with their authors holding their noses.

ig13• 12 years ago

It's a direct quote from the Reuters article; but my point is that saying "no comment" isn't a good approach in the circumstances.

sogen• 12 years ago

Mozilla?! wow this is going to hurt their image...

jgalt2122• 12 years ago

What's the best viable alternative to RSA SecurID?

cdjk• 12 years ago

Probably something like OATH (as used by google authenticator and similar software) or a yubikey. With yubikey you can even get your own HSM for the authentication server.

jgalt2122• 12 years ago

Thanks. I had heard about yubikey. will def check it out.

acd2• 12 years ago

Mcaffee Pledge, Yubikey

Yubikeys are more secure than RSA

nathancahill• 12 years ago

Duo Security[0] is awesome.

[0] https://www.duosecurity.com/

pbsd• 12 years ago

The actual analysis is available here: http://dualec.org/

I don't see much cryptographically new here; authors stretched what is a simple attack into 17 pages, and noticed that some non-standard TLS extensions that increase the amount of random data on wire make the attack easier.

mcphilip3• 12 years ago

One of the authors of that duealec paper had this to say [1]:

Our results <dualec.org> say nothing about whether NIST, the NSA, or anyone else inserted a backdoor into dual ec. Instead, they say that if you know the relationship between P and Q, then some TLS implementations can be broken at a given cost. The precise results are more nuanced than that. You can read the website for a summary or the paper for the details.

[1]http://www.ietf.org/mail-archive/web/tls/current/msg11730.ht...

acqq13• 12 years ago

Maybe not cryptographically, but it is definitely news and looks relevant for practical security engineering: they demonstate that the RSA BSAFE implementation in C was especially easy to be attacked compared to the other implementations: in seconds vs in hours, even without the newsworthy "extended_random_value."

Zigurd3• 12 years ago

"director of the NSA's defensive Information Assurance Directorate"

Now how many of you think dividing the NSA into defensive and offensive parts will do anything to restore trust?

samstave• 12 years ago

The best defense is a strong offense!

schoen• 12 years ago

One main argument for doing so has been that right now IAD has a conflict of interest.

mpyne2• 12 years ago

Except that it doesn't; NSA has a conflict of interest, but they're already split internally.

Even if you split them into separate agencies they're still going to both be part of the USG so while that might reduce the risk of a conflict of interest somewhat, it wouldn't eliminate it.

After all, think of the existing reaction we get when actually independent agencies of the USG throw out comments in support of NSA's signals intelligence. If the NSC, Congress's intelligence subcommittees, Executive Office of the President, Department of Justice, various Inspectors-General, Dept. of Defense, FBI, and, oh yeah, the courts can all be looped into what hacktivists claim is a vast conspiracy to violate the Constitution, then what defense would splitting IAD out really be?

cordite• 12 years ago

Is there an elliptic curve that is trustworthy?

KingMob• 12 years ago

Yes. There are many trustworthy curves. Elliptic curve cryptography in general has not been discredited.

zorlem• 12 years ago

To answer that you will have to define "trustworthy". I'm personally leaning toward trusting the curves proposed by Dan Bernstein [1], since he clearly explains the reasons for choosing the specific parameters and they're demonstrably valid.

[1] http://cr.yp.to/ecdh.html

tptacek19• 12 years ago

None of the issues being talked about in this story have anything to do with the trustworthiness of elliptic curves.

tptacek19• 12 years ago

The extended_random_value extension is by itself innocuous; in fact, in its historical context (2008), it's just on the edge of plausibly beneficial.

All extended_random_value does is add, to the random_bytes value in the TLS handshake, another variable-length blob of random data. The ostensible idea behind the extension is that there are protocols that want randomness proportional to key sizes, and the 28 random bytes already in the handshake are insufficient.

That is all the extension does. It doesn't influence your random number generator, it doesn't change the crypto algorithms in TLS.

Now, extended_random_value is not innocuous in 2014. There's a very good chance that the PKRNGs (Dual_EC and the like) are intended as cryptographic backdoors, and modern sensibilities about crypto protocols dictate that both sides of a protocol should be careful about "showing all their cards" (as it were) when it comes to random number generators. It's now thought to be risky to disclose too much state.

But that was definitely not the attitude in place in the early 2000s --- more randomness was better.

Finally, it's worth knowing that nobody uses extended_random_value. Even fewer people were exposed to it than were exposed to Dual_EC (which very few apps were --- so few that, from what I can tell, nobody has ever named such an app on HN [companies using BSafe do not equate to apps using Dual_EC, much less exploitably]). Even the Internet Draft seems quizzical about why the extension would exist, and it more or less says "you'd use this if your TLS needed to be compatible with the DoD".

PS: It's been a few months since I looked, but interesting to note: the mailing list discussions about extended_random_value were also skeptical about the intention behind the extension. Rescorla more or less said (IIRC) "the USG asked me to specify this so they could use TLS". Nobody on the TLS WG ever told an implementor that they should adopt this.†

PPS: Whatever 'pbsd says that conflicts with this comment, believe the 'pbsd comment, not mine. :)

† I'm a little wrong here; the mailing list discussion I'm thinking of is about OpaquePRF. But OpaquePRF is basically the same concept, and by the same authors; extended_random_value is a refinement. Neither was standardized.

danielweber• 12 years ago

Maybe OT, but what's PKRNG?

tptacek19• 12 years ago

Public-key RNG; an RNG that has asymmetric structure.

The concept of PKRNG and how it ever could be innocuous got debated on Twitter last year, and (I think) Matt Blaze pointed out that you might want one in order to constrain the number of different math/crypto operations you relied on in your protocol. If your security already depends on number-theoretic crypto because (for instance) you use DSA, you might think "in for a penny, in for a pound" regarding discrete log, and use an RNG that has the exact same dependency; the thought might be that there's only one thing that could then go wrong to destroy your security, not several.

That said: PKRNGs are weird, uncommon, and (in 2013-2014) very shady. They're also very slow. Nobody uses them.

acqq13• 12 years ago

The draft (the last version I've found is March 2009):

http://tools.ietf.org/html/draft-rescorla-tls-extended-rando...

(The first seems to be "Opaque PRF Inputs for TLS" from December 2006. http://tools.ietf.org/html/draft-rescorla-tls-opaque-prf-inp... so the process lasted more than two years)

The relevant parts from the last:

   TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
   "Random" value consisting of a 32-bit time value time and 28 randomly
   generated bytes:

         struct {
            uint32 gmt_unix_time;
            opaque random_bytes[28];
         } Random;

   The United States Department of Defense has requested a TLS mode
   which allows the use of longer public randomness values for use with
   high security level cipher suites like those specified in Suite B
   [I-D.rescorla-tls-suiteb].

   This document defines a new TLS extension called "extended_random".

   The "extended_random" extension carried in a new TLS extension called
   "ExtendedRandom".

        struct {
            opaque extended_random_value<0..2^16-1>;
        } ExtendedRandom;

Note how they used the notation that casually looks smaller as in "there's 2 and 16 and 1" when they actually mean up to 65535 bytes (I've first thought it's fixed but it looks the length is a subject of negotiation).

Roughly 2300 times more than the default 28 bytes.

TPtacek says: "It's now thought to be risky to disclose too much state. But that was definitely not the attitude in place in the early 2000s --- more randomness was better."

I can't imagine that there was ever an attitude that it's not risky "to disclose too much state."

tptacek19• 12 years ago

I'm not sure what you're trying to say here that my comment doesn't already say.

It might be helpful to note that there are crypto people --- some of the authors on the recent Dual_EC exploit paper included --- that believe TLS already discloses too much random state, even without the TLS extension.

I think it's uncontroversial in 2014 to say that any more state disclosure --- 2 bytes, 200 bytes, 16k bytes --- is probably not a good thing.

It might be a little controversial to say this next thing, but I'll stand by it for the sake of an interesting argument: in 2005, when this discussion started, it was not known to be a bad thing to increase the amount of random state in the handshake.

TrainedMonkey• 12 years ago

Are there any details on how negotiation is handled? I think this may be innocuous by itself, however coupled with the software that requests large amount of randomness it is dangerous.

lallysingh• 12 years ago

Considering how rarely this was used, and the small amount of money ($10m) involved, I think this activity was designed for a specific system (or family). Perhaps something sold to an ally.

acd2• 12 years ago

Most likely also Vasco security tokens since NSA owned Digitalnotar which Vasco owns.

CA is a flawed security model with governments wanting to read all your data. Far to easy to forge a CA either by running one covertly or hacking into one.

One subset of users will get man in the middle certificates and interception.

The other set will get normal certificates.

How many really check the certificate fingerprints and who issued the certificate?

marshray2• 12 years ago

I thought the evidence was pretty clear that Diginotar was pwned by the Iranians.

Those certs did end up on the .ir national ISP's firewall doing man-in-the-middle attacks on Gmail users within Iran.

forgotAgain• 12 years ago

The NSA is now actually making US infrastructure less secure. Consider that many companies will forego association with the most advanced security agency in the country. The country has placed it's best security resources in one pot and then spoiled it.

They're a resource that could have continued to provide valuable assistance. Instead, due solely to their organizational egoism, the NSA will be shunned and their advice dismissed as suspect.

nullc• 12 years ago

Well it's a little more complicated than that: Other than the uniformity problems dual-drbg is a secure PRNG … against anyone who doesn't know the matching discrete log for the parameters.

If you don't consider a cryptographically locked single party back-door to be "less secure" then I don't think we can point out where they've done something to make things less secure.

einhverfr5• 12 years ago

It seems to me we are seeing a variant of the same problem that Ken Thompson articulated in his paper "Reflections on Trusting Trust."[1]

While not a compiler intercept of the sort Thompson is talking about, this is effectively a library intercept of critical crypto functions and it poses the same basic problem. I don't think the industry will ever be the same. I think more and more folks are going to demand source-level access to everything crypto-related, and cryptoanalysts are going to put a lot more effort into scrutinizing these things.

The NSA failed to heed the basic warning of the Greek drama: ὕβρις-ἄτη-Νέμεσις

Or in more familiar terms, "Pride goeth before a fall."

[1] http://cm.bell-labs.com/who/ken/trust.html

acqq13• 12 years ago

I just had too look up the Greek words:

hubris [ὕβρις] ‘outrage’; the opposite of dikē [δίκη]

dikē [δίκη], plural dikai [δίκαι] ‘judgment (short-range); justice (long-range)’; dikaios [δίκαιος] ‘just’

atē [ἄτη], plural atai [ἆται] ‘aberration, derangement, veering off-course; disaster; punishment for disaster’

nemesis [νέμεσις] indicates the process whereby everyone gets what he or she deserves

einhverfr5• 12 years ago

In other words, the basic formula of Greek tragedy is the hubris or outrageous pride overwhelming judgement, leading to deserved disaster. There's an additional subtext btw of exceeding prudent limits in "hubris."[1]

The thing here is that the NSA has acted out of hubris and exceeded prudent limits, and the result will be predictable. The deserved disaster will come from far more routine use of encryption, and this will deny legitimate law enforcement investigations many critical tools. While this is a cost that to some extent will be borne by everyone, it will particularly hit the NSA and law enforcement really hard.

[1] See "From Religion to Philosophy" by F. M. Cornford, 1914. Some parts are dated, but the general discussion of partition and nomos/nemesis is very well done.

linuxhansl• 12 years ago

The system, called Dual Elliptic Curve, was a random number generator, but it had a deliberate flaw - or "back door" - that allowed the NSA to crack the encryption

I would very clearly draw the line at the point where the NSA is deliberately weakening national security by undermining widely used cryptography. Companies or even other government agencies are now easier targets because of the doings of the NSA.

mpyne2• 12 years ago

I would very clearly draw the line at the point where the NSA is deliberately weakening national security by undermining widely used cryptography

There was no "threat to national security" here. Unlike what we think of as a normal backdoor, this one is and remains completely in NSA's control, as long as they're the only ones with the private key underlying the Dual EC constants. So even knowing there's a backdoor in there somewhere, there's no way for other security agencies or hackers to break Dual EC (assuming, of course, that it's properly implemented, which is not a given, and NSA's changes may have made it harder to implement).

NSA infiltrated RSA security more deeply than thought: Study

Related Stories