From my side I would also add few other actors popular nowadays:<\/p>\n
- \n
- Good Samaritan John<\/b> who states often that he has nothing to hide and\u00a0 doesn’t care much about Eve, Jerry and others alike who never stop spying on him.<\/li>\n
- Seasoned Security Consultant Jim<\/b> who comes to executive meetings often\u00a0 to tell business leaders that “we can’t really protect your systems against state-sponsored attacks, so let us not even try and save money for something else”.<\/li>\n
- Influential Crypto Forum Chair Lars<\/b> whose job is to stay the course, pretend that nothing has happened and save the face of the organization whose almost mandatory advice is used by IETF, its TLS working group, NIST and others.<\/li>\n
- Insignificant Choir<\/b> of crypto forum’s, TLS’, IETF’s memebers,\u00a0 cryptographers and entrenched security engineers who are desperately trying to understand how to deal with all that in the real life (hereafter Choir<\/b>).<\/li>\n<\/ul>\n
Drama Unfolds<\/h3>\n
Dual_EC_DRBG<\/b><\/b><\/span><\/h4>\n
Oddly enough, the drama would not have ever happened if one of Jerry’s notorious colleagues (we’ll call him Snow White) had not decided to disclose very interesting and intriguing details about once NIST standard and RSA Bsafe’s default called Dual_EC_DRBG<\/b><\/b><\/span>. The nature of the hack is explained in simple terms here<\/a>. There are two points – P1 and P2 on a curve. The first is used to calculate a random value, which is a coordinate x of the production n*P1, where n can be considered as an internal state of the algorithm. P2 is used to change an internal state of the algorithm by calculating the production n*P2 and using its x coordinate as a new state.<\/p>\n
As it was demonstrated by Dan Shumow and Niels Ferguson in 2007<\/a>\u00a0 and pointed out by Bruce Schneier<\/a> if there was a dependency between P1 and P2, e.g. if P2 = s*P1, then calculating internal state becomes trivial – it’s an x coordinate of s*P1*n, where both P1*n and ‘s’ are known to an attacker.<\/p>\n
Since a method of P2 selection has never been disclosed, it created suspicions that a backdoor key (see ‘s’ above) has existed and was known to the algorithm creator since day one. The same has been confirmed by Snow White. The loop has been closed and NIST had nothing better to do as removing Dual_EC_DRBG from the standard<\/a>.<\/p>\n
The other Snow White’s revelation was that RSA got $10M from Jerry’s employer <\/a>to make Dual_EC_DRBG a default in their crypto library called BSafe that was successfully licensed to many commercial companies for very expensive license fees, so RSA made money from the both compromising their library with a backdoor and telling their customer how secure their solution was. What a wonderful business model! I firmly believe now that not only RSA had the best cryptographers, but very inventive and industrious business leaders as well.<\/p>\n
The funny thing about BSafe is that thanks to Seasoned Security Consultant Jim (see above) changing defaults in existing implementations is practically impossible, because nobody wants to spend money to protect their systems against state-sponsored attacks. Remember, “it’s impossible” according to the Jim’s assessment.<\/p>\n
NIST P-256<\/b><\/b><\/span><\/h4>\n
I think, it’s good time to talk about NIST P-256 now. There is a reason why this particular curve is given more attention than any other NIST curve:<\/p>\n
- \n
- A good compromise between speed and security (256-bit prime looks about right).<\/li>\n
- It’s a default in the latest production version of OpenSSL.<\/li>\n
- EC arithmetic is optimized in OpenSSL implementation (see enable-ec_nistp_64_gcc_128 flag in OpenSSL config), which increases the speed of algorithms such as ECDHE almost twofold.<\/li>\n<\/ol>\n
Looks good, right? Wrong, if you consider the fact that the method how EC parameters have been selected is not quite clear. To be more exact, it was not clear how a seed has been chosen to generate a curve parameter<\/a>.<\/p>\n
It means that a statement about P-256 being “verifiable random” is simply not true and a D. J. Bernstein’s note in a TLS WG discussion confirms that and provides a hint about Jerry’s employer involvement in this case as well<\/a>.<\/p>\n
The common suspicion here is that Jerry has tried many of them until found a weak EC curve that can be exploited in the same way as in Dual_EC_DRBG <\/b><\/b>case.<\/span> Since there is an opinion that there might be a “spectral weakness” in ECC<\/a> (check also this<\/a>), that suspicion seems quite plausible. “Spectral weakness” means that there is a uniform (?) distribution of weak EC curves that can be eventually found through enumeration in a reasonable time interval.<\/p>\n
Drama Perpetrators<\/b><\/b><\/b><\/p>\n
Good Samaritan John, Seasoned Security Consultant Jim and Influential Crypto Forum Chair Lars make everything even worse by pushing everyone into the direction of not doing anything. Let me explain why their rhetoric is dangerous and doesn’t make too much sense to me.<\/p>\n
John’s statement, “I have nothing to hide from my government”, is probably OK for personal emails and social media, but it becomes less acceptable, if at all, when John is in a position of protecting a global company’s secrets. Any international company wants to keep competitors at bay and any government tries to help its major businesses as much as possible. Conflict of interests becomes obvious here and a wise CEO would definitely try to find a replacement for John as soon as possible.<\/p>\n
Jim just wants to simplify his own life by ignoring threats coming from a government. The problem with this approach is that if one government can break a system, other governments might find a way of doing the same, as well as well heeled and organized cyber criminals that could be connected to a government. Furthermore, either a government or cyber criminals can create tools and make them available for script kiddies at which point everyone could attack the system.<\/p>\n
Finally, my favorite actor Lars<\/b> who knows very well what’s going on in his organization, who periodically listens to the Choir’s<\/b>\u00a0 rants, but still pretends that nothing has happened and who doesn’t want to do anything to rebuild\u00a0 trust to his organization even in the eyes of his own co-chairs. I won’t write too much about it, I just want to refer to Alyssa Rowan’s message to a Jerry’s colleague Kevin<\/a> and Lars’ response to the rant<\/a>.<\/p>\n
I won’t make any conclusion from this story, because I could not formulate it better than co-chair David McGrew\u00a0 did:<\/p>\n
“The Research Group needs to have chairs that it trusts, and who are trusted by the broader IETF and Internet communities that they work with”.<\/p><\/blockquote>\n
Trust is a keyword here in my view.<\/p>\n
Drama’s La Finale<\/b><\/p>\n
If you’ve followed my line of thought to this point, you’ve probably come to the same conclusion as I already – there is no anyone who would protect your curves from Jerry:<\/p>\n
- \n
- NIST, CFRG – dysfunctional and not trusted.<\/li>\n
- TLS WG – doesn’t have enough expertise, relies on CFRG when it comes to cryptography.<\/li>\n
- Choir<\/b> – not an organization, can’t really create a standard.<\/li>\n
- John, Jim, Lars<\/b> – simply do not care or corrupt (remember $10M?), or both.<\/li>\n<\/ul>\n
As you see, nobody will protect your curves, except you! <\/b><\/p>\n
What you can do<\/h2>\n
Special and Random Curves<\/h3>\n
To simplify our considerations we could divide all curves in two groups – random and the ones with specially selected domain parameters, e.g. NIST P-256, D.J. Bernstein’s Curve25519<\/a> and Curve41417 <\/a>are “special”, while Brainpool<\/a> curves are “random”.<\/p>\n
An important requirement of Brainpool curves is that the method of parameter’s selection is clearly defined. It includes seeds that are used for deriving the parameters. They also try avoiding the following threat coming from the “special” curves:<\/p>\n
“The primes selected for the base fields have a very special form facilitating efficient implementation.\u00a0 This does not only contradict the approach of pseudo-random parameters, but also increases the risk of implementations violating one of the numerous patents for fast modular arithmetic with special primes”<\/p><\/blockquote>\n
This requirement creates a certain “nothing up my sleeves” assurance, which is very important considering lack of trust to manually crafted curves especially when Jerry and his colleagues are involved.<\/p>\n
Even though optimized EC arithmetic is not available for the random curves, “nothing up my sleeves” factor seems to be more important and it very much determines my personal choice.<\/p>\n
Implementation<\/h3>\n
Since in the most cases you’re not going to build an isolated crypto-system, it’s important to integrate your crypto libraries with existing system software such as Apache, Tomcat, JBoss, RoR, HAProxy and other web and application servers that you might use.<\/p>\n
All of them use OpenSSL to do cryptography and that’s why using Brainpool curves will require an OpenSSL version that supports them. You could find the curves implemented in the OpenSSL version 1.0.2, but it’s still a beta that you probably don’t want to use in production.<\/p>\n
My solution was to backport Brainpool curves to a stable version 1.0.1. It was not trivial, but doable. The patch against 1.0.1j is provided in the “Appendix A”.<\/p>\n
After the new version is created you can statically link it with a web server of your choice.<\/p>\n
You should also keep in mind that when it comes to SSL\/TLS implementation, there is a possibility to use different curves for digital signature (ECDSA) and ephemeral key exchange (ECDHE).<\/p>\n
The type of curve used for ECDSA is the one that is used as your server’s private key, while ECDHE curve should be provided as a parameter in a server configuration file, e.g. ‘ecdhe’ parameter in ‘bind’ command<\/a> of HAProxy config. Please notice that NIST P-256 is a default there, just like it is in OpenSSL. I’m just saying … \ud83d\ude42<\/p>\n
To configure Apache<\/a> you can use SSLCertificateFile option that points to a certificate file containing EC parameters generated by ‘openssl ecparam’ command. If you want to use brainpoolP256r1curve, you’ll need to run:<\/p>\n
\u00a0openssl ecparam -name brainpoolP256r1 -out bp_params.pem<\/p><\/blockquote>\n
and then copy\/paste the output to your certificate file.<\/p>\n
Certificates<\/h3>\n
To use a Brainpool curve for signatures (ECDSA) you would need to generate a private key and then either use it for creating a self-signed certificate or a CSR file if you want your certificate to be signed by a known certificate authority (CA).<\/p>\n
The problem with the latter case is that big CA’s such as Symantec\/Verisign might not support Brainpool curves (even NIST curves support is relatively new for them<\/a>). I didn’t check smaller CA’s yet, so there is a room for research.<\/p>\n
Generating a private key is simple for a curve, you just need to use the same ‘openssl ecparam’ command:<\/p>\n
openssl ecparam -name brainpoolP256r1 -genkey -out bp_key.pem\u00a0 \u00a0 <\/span><\/span><\/p><\/blockquote>\n
After this is done, you can generate a self-signed certificate or a CSR file just like you did it in RSA case, e.g. to create a certificate run:<\/p>\n
openssl req -new -x509 -key bp_key.pem -out cert.pem <\/span><\/span><\/p><\/blockquote>\n
Brainpool security considerations<\/h3>\n
I’ve noticed when was going\u00a0 through DJB’s SafeCurves pages<\/a> that there was one problem called “Twist Security”, which didn’t look good for my choice (brainpoolP256r1):<\/p>\n
- John, Jim, Lars<\/b> – simply do not care or corrupt (remember $10M?), or both.<\/li>\n<\/ul>\n
- Seasoned Security Consultant Jim<\/b> who comes to executive meetings often\u00a0 to tell business leaders that “we can’t really protect your systems against state-sponsored attacks, so let us not even try and save money for something else”.<\/li>\n
![\"jerome-1027\"](\"https:\/\/credelius.com\/credelius\/wp-content\/uploads\/2015\/10\/jerome-1027-300x207.png\")
<\/a><\/p>\n