Samstag, 14. November 2015

A+ Fail

... why an A+ at Qualys can fail nevertheless


So you're using encryption every day, right?

And you feel comfortable with it, because your browser shows a green icon next to the address bar and Qualys SSL Labs shows only A+ for your server?

You think the NSA can't sniff your connection, because you followed some of the best-practice guidelines and recommendations (123, 4) around there?

You're probably wrong. But let's start at the beginning...

Perfect Forward Secrecy

In 2013 Perfect Forward Secrecy (PFS) was a big topic. Everybody started using it, verifying that others are using it and demanding its usage from almost every website operator. Since then, not using PFS is frowned upon.

Today the situation has not changed much and most websites prefer using ciphers that provide PFS. Those are, for example, Diffie-Hellman Exchange (DHE) and Elliptic Curve Diffie-Hellman Exchange (ECDHE).

The efforts towards PFS may originate in the finding that the NSA stores internet traffic for later decryption.

Attacks on DHE Implementation

The documents released by Ed Snowden revealed indications for the NSA being able to decrypt most of the internet traffic nowadays. Security and cryptography specialists were curious about how the NSA actually manages to do that. Then some clever guys gave us an idea of how that can be done and they actually did it. The attack they used basically relies on specific DH keys that are commonly used all over the internet. When someone manages to break them, they can effectively break encryptions by forcing connections to use these weak keys (read the paper!).

What these people discovered is an attack on the implementation rather than on the mathematical problems behind the crypto system.

But the NSA can do more...

Mathematical Backdoors - The Case Dual_EC_DRBG (Confirmed)!

The NSA puts an enormous amount of effort into attempts to covertly introduce weaknesses into the encryption standards followed by hardware and software developers around the world.


On of the best studied examples may be the random number generator Dual_EC_DRBG. It is an algorithm for generating random numbers based on Elliptic Curve (EC) cryptography which got published by the National Institute of Standards and Technology (NIST) in 2007.

Soon after the draft was released in 2004 to the public there were indications of possible weaknesses in the algorithm. Despite these problems the algorithm was standardized by the NIST (not only by the NIST) as Dual_EC_DRBG in NIST SP 800-90A. In a nutshell:

1998 ANSI RNG standardization started as X9.82

2000 The NSA drives to include Dual_EC_DRBG in the emerging standard

2007 Standard released by NIST

2007 Dan Shumow and Niels Ferguson write about the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng

2007 Bruce Schneier asks Did NSA Put a Secret Backdoor in New Encryption Standard?

2013 Ed Snowden's leaks proof that the suspicions were justified and that the NSA indeed introduced a backdoor in this standard

Mathematical Backdoors - The Case secp256r1 (Suspicious)!

You may already know what I'm about to say. The secp256r1 curve is not trustworthy. Any indication to corroborate that statement? Well, kind of ...

The curve was defined in 1999 as Curve P-256 by the NIST. In the linked document the generation of suitable elliptic curve was defined as well as how to verify certain properties of the generation procedure. For generating pseudo-random curves (that's what the "r" in secp256r1 stands for) you have to take a random initial value, say c49d3608 86e70493 6a6678e1 139d26b7 819f7e90, put it through SHA-1 and use the resulting value to calculate the curve. The whole process is defined in the same document.

Curve P-256 alias secp256r1 - suspicious!


So where's the problem?

The way it should be

A trustworthy way of defining the curve would be to take an obviously unbiased number as the initial value. For example 1234567890 or the first numbers of Pi, or whatever you consider unbiased that more that 80 of 100 people would agree on. This would be a nothing up my sleeve number, which is a principle known at least since the mid nineties. You generate the SHA-1 hash of it and use it.

The way it is


  • Your good friend the NSA chose a random number (so they say) for you, namely c49d360886e704936a6678e1139d26b7819f7e90 and fixed it as the initial value.
  • We know what the NSA is capable of, and that they employ some of the best mathematicians in the world. 
  • This initial value is the foundation for (most?) encrypted connections in the whole world.
  • The NSA is interested in (and capable of) decrypting lots of stuff.

Just one way to rule them all

Assume, just for a moment, that the NSA is aware of a method to break one in a billion curves and they want one of those to be standardized. It's easy for them to just

  • try a billion random initial values and hash them with SHA-1
  • check if the result is breakable
  • give the breakable initial value to the NIST for standardization


Enough to be skeptical

Please get me right, I don't claim that this is what happened. I am just suspicious because if I can think of ways to undermine the security of that curve, than what might the NSA be able to realize? They employ some of the best mathematicians in the world and their influence on and weakening of standards is proven.

The bad news

If you are just a little susceptible to conspiracy theories or if you just want the most possible privacy for yourself, you might not want to use secp256r1 anymore. The bad news is

You use secp256r1 every day. Why?

For two reasons.

Webserver configuration

Most web servers today are configured according to the latest recommendations and best-practice guidelines. They usually recommend to activate PFS and they are not very picky when it comes to Elliptic Curves. Just an excerpt from some of the otherwise good recommendations:
[Qualys]:
"Put ECDHE and DHE suites to the top of your list."
[Mozilla]:
"ECDHE+AESGCM ciphers are selected first"
[IETF]:
"(...) following cipher suites is RECOMMENDED:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
[Acunetix]
"#1 Elliptic Curve Diffie–Hellman (ECDH)"

Browser configuration

So what does your browser say? Unfortunately all major browsers only support the NIST curves, namely secp256r1, secp384r1, secp521r1. And please, don't assume that the secp384r1 and secp521r1 are any more trustworthy. They're defined in exactly the same way as secp256r1.

I chose PayPal to dump some traffic. PayPal because they usually do things right and hence they serve as a good reference. So here are the results






And in case you wonder if the server really established a connection with the elliptic curves...






So yes, they did. Only in one case the PayPal server decided to chose another cipher suite. I wonder if that was on purpose... ^^

Conclusion

You may not have noticed that already, but you are probably using on of the most controversial crypto algorithms today, everyday.

I cannot prove that the NSA somehow backdoored these NIST curves, but they smell fishy!

And unfortunately these curves are the ones that are most widely used nowadays.

We are discussing the problem since 2013 without any advance.

Suspicions about the curves themselves reaches back to 1999.

So ... what next?

Please, dearest browser vendors, give us alternatives. There are many curves out there that are worth being supported by your products. Ed25519, Koblitz or Brainpool curves.


Google, Microsoft, Mozilla, Opera, What are you waiting for?

Keine Kommentare:

Kommentar veröffentlichen