Problems With Elliptic Curve Cryptography In TLS and SSH
Joe Testa Positron Security
October 19, 2017
Overview
● Elliptic Curve Cryptography (ECC) became pretty popular in the last decade. – Used in TLS and SSH
● Common parameters are… shady. – Some people think they're backdoored by the NSA.
● What can you do about it? – From a sysadmin's perspective.
What is Elliptic Curve Cryptography?
● ECC is done with elliptic curves over finite fields in the form of: y2 = x3 + ax + b (mod p)
● Its security is based on the discrete log problem. – Diffie-Hellman & DSA depend on this as well.
● There are EC equivalents of Diffie-Hellman and DSA: – ECDH – ECDSA
Why Does ECC Matter?
● The same security levels can be achieved with much smaller keys:
Source: NIST SP 800-57 Pt. 1 Rev. 4, page 53 Why Does ECC Matter?
● If keys are much smaller, then: – Key generation is much faster. – Embedded devices can encrypt & decrypt faster. – Embedded devices can use less power. – High-volume servers can perform more operations.
● A 256 bit security level becomes practical. – Otherwise, you'd need a 15,360-bit RSA key.
Curve Parameters
● ECC isn't immediately ready for use like RSA.
● Curve parameters must be set: y2 = x3 + ax + b (mod p)
● What do you use for a, b, p? – You also need the prime order r, the coefficient, and a base point, G.
NIST Curve Parameters
● National Institute of Standards and Technology (NIST) FIPS 186-2, January 2000. – “Hey everybody! Just use these curves!”
● “And don't ask any questions...”
● Defines three classes of curves: – 5 over prime fields, generated “randomly” – 5 over binary fields, also “random” – 5 special-case binary field Koblitz curves.
● Many people consider these “random” parameters
suspicious! NIST Curve Parameters
● The “random” parameters were generated using SHA-1(seed value).
● No mention of how the seed values were obtained! – For P-256: c49d3608 86e70493 6a6678e1 139d26b7 819f7e90
● The NSA could have iterated over many seeds to find parameters that introduce weaknesses. – This is exactly what the BADA55 project did with GPUs recently! https://bada55.cr.yp.to/ NIST Curve Parameters
● In FIPS 186-2: – “The pseudo-random curves are generated via the SHA-1 based method given in the ANSI X9.62 and IEEE P1363 standards.” – Why weren’t they included??
● Neither are available for free. – ANSI X9.62 costs $100. – IEEE P1363 costs $97 for the public; $77 for members. – The ANSI doc cost $500+ in 2006...
● I've never encountered proof that the seeds even yield the parameters(!) NIST Curve Parameters
● The five prime field curves started to become popular: – P-192 – P-224 – P-256 – P-384 – P-521 (not a typo)
● P-256 has a security level of 128 bits. – This curve became the most popular.
NSA Suite B
● In 2005, the National Security Agency released their “Suite B” protocols.
● Suite B is a set of publicly-known algorithms deemed suitable for Top Secret data. – Suite A are classified protocols.
● Recommended ECDSA, ECDH, and appropriate parameters. – Curve P-256 was included. – “If its back-doored, why was it included?” ECC Added To TLS
● In May 2006, ECC was formally added to TLS v1.0 and v1.1. – RFC 4492
● All curves included from: SEC 2: Recommended Elliptic Curve Domain Parameters (Certicom, 2000). – This includes all the NIST P-curves.
● In August 2008, TLS 1.2 was specified, and included the same ones.
Bitcoin
● In 2009, Satoshi Nakamoto avoided these popular NIST curves for Bitcoin.
● Chose the rarely-used secp256k1 from SEC 2. – Not even specified in NIST FIPS 186-2.
● secp256k1 is a Koblitz curve. – Parameters were chosen without NIST/NSA interference. – Has ~30% performance improvements over P- curves. Dual_EC_DRBG Backdoor
● Dual_EC_DRBG is effectively a random number generator.
● It first came to light in ANSI X9.82 (published Sept. 2007; early drafts in 2004?). – Members of ANSI committee were suspicious of it. – Tradeoff: suspicious parameters could be re- generated by the users. – However, later the suspicious parameters were mandatory to attain FIPS 140-2 certification.
● Source: http://marc.info/?l=openssl-announce&m=138747119822324&w=2
Dual_EC_DRBG Backdoor
● NIST Special Publication 800-90 published it in June 2006.
● Microsoft employees D. Shumow and N. Ferguson give an informal presentation in August 2007, detailing their suspicions. – http://rump2007.cr.yp.to/15-shumow.pdf
● Dual_EC_DRBG was also published in ISO 18031 on Nov. 2011 (?).
Dual_EC_DRBG Backdoor
● Snowden leaks confirmed that Dual_EC_DRBG had an intentional back door placed there by the NSA: “Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.”” – New York Times, Sept. 5, 2013, http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.h tml?pagewanted=all
Dual_EC_DRBG Backdoor
● On Dec. 20, 2013, Reuters reports that the National Security Agency paid RSA $10M include it as the default RNG in their BSAFE crypto toolkit. – http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C2201 31220
● So naturally, this made people even more afraid of the NIST P-curves.
SafeCurves Project
● D. Bernstein and T. Lange's SafeCurves Project (2014) evaluated 20 curves across 11 criteria. – https://safecurves.cr.yp.to/index.html
● Included were three of the NIST P-curves, along with secp256k1. – Wanna guess the results?
SafeCurves Project
Partial summary of results:
Source: https://safecurves.cr.yp.to/index.html
NSA Updates Long-Term Strategy
● In August 2015, NSA released a bombshell statement: “For those partners and vendors that have not yet made the transition to Suite B elliptic curve algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.” – https://web.archive.org/web/20151123081120/https://www.nsa.gov/ia/pr ograms/suiteb_cryptography
● The NSA had been pushing ECC hard for about two decades, then suddenly dumps it!
● Also, P-256 was removed from Suite B with no rationale provided. Koblitz and Menezes Weigh In
● Koblitz & Menezes publish an informal and in- depth 21-page paper a few months later (Oct. 2015). – http://eprint.iacr.org/2015/1018.pdf
● Examines the possibility of NIST curves backdoored. – Show estimations that if NSA could iterate over 248 seeds, then 2209 weak curves would exist in a pool of 2257
Koblitz and Menezes Weigh In
“This would mean that this huge class of weak curves was known to the NSA in 1997 but is still undiscovered by outside researchers in 2015. It is highly unlikely that such a large family of weak elliptic curves would have escaped detection by the cryptographic research community from 1997 to the present.”
Summary of NIST Curves
● Estimation & rationale by Koblitz & Menezes sound compelling…
● But why do seed values of P-curves appear random? – For P-256: c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 – For P-384: a335926a a319a27a 1d00896a 6773a482 7acdac73 – For P-521: d09e8800 291cb853 96cc6717 393284aa a0da64ba
● No rationale was ever given for these values! – It was recently shown that “random” seeds can be used to generate weak curve parameters with GPUs… – https://bada55.cr.yp.to/ Summary of NIST Curves
● NSA got caught red-handed with EC_DUAL_DRBG.
● The standardization path for EC_DUAL_DRBG is similar to how the NIST P-curves came about. – Pushed into ANSI, then NIST; parameters with little/no rationale.
● “Why would the government use back-doored algorithms?”
Summary of NIST Curves
● NObody But US (“NOBUS”) policy. Quote from former NSA Directory Hayden (Oct. 2013): “You look at a vulnerability through a different lens if even with the vulnerability it requires substantial computational power or substantial other attributes and you have to make the judgment who else can do this? If there's a vulnerability here that weakens encryption but you still need four acres of Cray computers in the basement in order to work it you kind of think "NOBUS" and that's a vulnerability we are not ethically or legally compelled to try to patch – it's one that ethically and legally we could try to exploit in order to keep Americans safe from others.” https://www.washingtonpost.com/news/the-switch/wp/2013/10/04/why-everyone-is-lef t-less-secure-when-the-nsa-doesnt-help-fix-security-flaws/
Summary of NIST Curves
● The NOBUS policy can be interpreted as the missing link.
● “Why would the US government push backdoored curves, then use them for classified intel itself?”
● Because NOBUS! – They reasonably think nobody else can break them.
Summary of NIST Curves
● My personal suspicion: the NSA intentionally chose parameters that looked weak at the time.
● They couldn't exploit the weaknesses immediately, but hoped to gain the ability in the future.
● Maybe they succeeded 10 years later? Maybe just two years ago? Maybe they never did? – Maybe they will three years from now?
Summary of NIST Curves
● Fact: the SafeCurves study showed that P-256 and P-384 have some bad properties.
● Fact: NSA no longer recommends P-256 for classified data.
● There are other curves created by the community with better properties.
● Verdict: don't use the NIST curves.
Improved Curves
● Curve25519, proposed by D. Bernstein in 2005. – Offers 128 bits of security. – Rationale provided for all parameters. – Offers excellent performance. – Became default for key exchange in OpenSSH 6.5 (Jan. 2014).
● Curve448 (aka Ed448-Goldilocks) – Same perks as Curve25519, but with ~224 bits of security.
● Both are formalized in RFC 7748.
– Referenced in upcoming TLSv1.3 draft! How To Avoid NIST Curves?
● Some people wonder how to avoid NIST curves.
● I started this project in order to answer this question… from a sysadmin's perspective.
● Well, its complicated...
How To Avoid NIST Curves?
● In Apache/mod_ssl, you can’t (?) change it. – It appears to always use P-256! – In theory, you could use secp256k1…
● Nginx doesn't let you change it either! – Nginx also appears to always use P-256.
● From rbsec's sslscan:
Preferred TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384 Curve P-256 DHE 256
How To Avoid NIST Curves?
● In Apache/mod_ssl, there's this: SSLOpenSSLConfCmd ECDHParameters secp256k1
● Seems very, very rarely used.
● sslscan reports that P-256 is still in use (!) – Bug in sslscan? Bug in mod_ssl?
● Even if it works for you, if only 0.00001% of servers use this, are you sure you want to trust it in production?
● How To Avoid NIST Curves?
● You could disable ECDH entirely.
● If SHA-1 and ECDH are both turned off, Firefox breaks:
How To Avoid NIST Curves?
● ECDSA can be used in X.509 certificates. – Many NIST curves are available. – Other curves are included, though they didn't pass all SafeCurves tests. – Many curves offering less than 128 bits of security are available!
● Its probably best to use traditional RSA in certificates for now. – Use 3072 or 4096-bit keys.
TLS v1.3 On The Horizon
● There's good and bad news about TLS v1.3 draft spec: – Curve25519 and Curve448 are both included! – But so are the NIST curves…
● “A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519.”
NIST Curves in SSH
● P-256, P-384, and P-521 have been a part of SSH for awhile.
● The default for ECDH changed to Curve25519 in OpenSSH 6.5 (Jan. 2014).
● You can (and should) disable the NIST curves. – KexAlgorithms [email protected],diffie-hellman-group- exchange-sha256 – #HostKey /etc/ssh/ssh_host_ecdsa_key
Useful Tools
● Command Line – sslscan: https://github.com/rbsec/sslscan – ssh-audit: https://github.com/arthepsy/ssh-audit
● Online Services – SSL Labs: https://www.ssllabs.com/ – SSH Audit: https://www.sshaudit.com/
https://www.sshaudit.com/
Questions?
Twitter: @therealjoetesta