Problems With Elliptic Curve CryptographyIn TLS and SSH

Joe TestaPositron Security

October 19, 2017

Overview

● Elliptic Curve Cryptography (ECC) becamepretty 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 theform 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 withmuch 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” parameterssuspicious!

NIST Curve Parameters

● The “random” parameters were generatedusing SHA-1(seed value).

● No mention of how the seed values wereobtained!– For P-256: c49d3608 86e70493 6a6678e1 139d26b7 819f7e90

● The NSA could have iterated over many seedsto 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 theparameters(!)

NIST Curve Parameters

● The five prime field curves started to becomepopular:– 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 releasedtheir “Suite B” protocols.

● Suite B is a set of publicly-known algorithmsdeemed suitable for Top Secret data.– Suite A are classified protocols.

● Recommended ECDSA, ECDH, andappropriate 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.0and v1.1.– RFC 4492

● All curves included from: SEC 2: RecommendedElliptic Curve Domain Parameters (Certicom, 2000).– This includes all the NIST P-curves.

● In August 2008, TLS 1.2 was specified, and includedthe same ones.

Bitcoin

● In 2009, Satoshi Nakamoto avoided thesepopular 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 randomnumber generator.

● It first came to light in ANSI X9.82 (publishedSept. 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 weremandatory 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 inJune 2006.

● Microsoft employees D. Shumow and N.Ferguson give an informal presentation inAugust 2007, detailing their suspicions.– http://rump2007.cr.yp.to/15-shumow.pdf

● Dual_EC_DRBG was also published in ISO18031 on Nov. 2011 (?).

Dual_EC_DRBG Backdoor

● Snowden leaks confirmed that Dual_EC_DRBGhad an intentional back door placed there bythe NSA:

“Classified N.S.A. memos appear to confirm thatthe fatal weakness, discovered by two Microsoftcryptographers in 2007, was engineered by theagency. The N.S.A. wrote the standard andaggressively 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.html?pagewanted=all

Dual_EC_DRBG Backdoor

● On Dec. 20, 2013, Reuters reports that theNational Security Agency paid RSA $10Minclude it as the default RNG in their BSAFEcrypto toolkit.– http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C2201

31220

● So naturally, this made people even more afraidof 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 bombshellstatement:“For those partners and vendors that have not yet made thetransition to Suite B elliptic curve algorithms, we recommendnot making a significant expenditure to do so at this point butinstead to prepare for the upcoming quantum resistantalgorithm transition.”

– https://web.archive.org/web/20151123081120/https://www.nsa.gov/ia/programs/suiteb_cryptography

● The NSA had been pushing ECC hard for abouttwo decades, then suddenly dumps it!

● Also, P-256 was removed from Suite B with norationale 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 curvesbackdoored.– Show estimations that if NSA could iterate over 248

seeds, then 2209 weak curves would exist in a poolof 2257

Koblitz and Menezes Weigh In

“This would mean that this huge class of weakcurves was known to the NSA in 1997 but is stillundiscovered by outside researchers in 2015. It ishighly unlikely that such a large family of weakelliptic curves would have escaped detection bythe cryptographic research community from 1997to the present.”

Summary of NIST Curves

● Estimation & rationale by Koblitz & Menezes soundcompelling…

● 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 togenerate 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_DRBGis similar to how the NIST P-curves cameabout.

– Pushed into ANSI, then NIST; parameterswith little/no rationale.

● “Why would the government use back-dooredalgorithms?”

Summary of NIST Curves

● NObody But US (“NOBUS”) policy. Quote from former NSADirectory Hayden (Oct. 2013):

“You look at a vulnerability through a different lens if even withthe vulnerability it requires substantial computational power orsubstantial other attributes and you have to make the judgmentwho else can do this? If there's a vulnerability here that weakensencryption but you still need four acres of Cray computers in thebasement in order to work it you kind of think "NOBUS" andthat's a vulnerability we are not ethically or legally compelled totry to patch – it's one that ethically and legally we could try toexploit in order to keep Americans safe from others.”

https://www.washingtonpost.com/news/the-switch/wp/2013/10/04/why-everyone-is-left-less-secure-when-the-nsa-doesnt-help-fix-security-flaws/

Summary of NIST Curves

● The NOBUS policy can be interpreted as themissing link.

● “Why would the US government pushbackdoored curves, then use them for classifiedintel itself?”

● Because NOBUS!– They reasonably think nobody else can break them.

Summary of NIST Curves

● My personal suspicion: the NSA intentionallychose parameters that looked weak at the time.

● They couldn't exploit the weaknessesimmediately, but hoped to gain the ability in thefuture.

● Maybe they succeeded 10 years later? Maybejust 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-256and P-384 have some bad properties.

● Fact: NSA no longer recommends P-256 forclassified data.

● There are other curves created by thecommunity 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 NISTcurves.

● I started this project in order to answer thisquestion… 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 usethis, 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, Firefoxbreaks:

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 passall SafeCurves tests.

– Many curves offering less than 128 bits of securityare available!

● Its probably best to use traditional RSA incertificates for now.– Use 3072 or 4096-bit keys.

TLS v1.3 On The Horizon

● There's good and bad news about TLS v1.3draft spec:– Curve25519 and Curve448 are both included!

– But so are the NIST curves…

● “A TLS-compliant application MUST supportkey exchange with secp256r1 (NIST P-256)and SHOULD support key exchange withX25519.”

NIST Curves in SSH

● P-256, P-384, and P-521 have been a part ofSSH for awhile.

● The default for ECDH changed to Curve25519in OpenSSH 6.5 (Jan. 2014).

● You can (and should) disable the NIST curves.– KexAlgorithms curve25519-sha256@libssh.org,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