What Happened With Crypto This Year? 2015 in Review

[Jeffrey Walton <noloader () gmail com>]

http://www.eff.org/deeplinks/2015/12/technical-crypto-2015-review

Under the glare of the modern surveillance state, EFF's long-held goal
of encrypting the web has only grown more pressing. And crypto remains
on the march, with promising developments ranging from the public beta
launch of the Let's Encrypt project, to the expansion of CloudFlare's
Universal SSL program, or the Facebook announcement of PGP-encrypted
notifications. But there's also been misguided chatter from law
enforcement and elected officials, calling to weaken that crypto with
backdoors, “golden keys,” and other efforts to undermine security.

Looking at the technical developments of this past year can help us
understand why those calls are so fundamentally misguided. And while
2015 may not have been the banner year that 2014 was in terms of
attacks (with Heartbleed and POODLE), there were still a number of
interesting developments.

== When Our Computers Trust Somebody That We Don't ==

Two PC manufacturers were busted inserting a “trusted root
certificate” onto the computers they sell, undermining user security
in order to inject ads into web pages. Both faced major backlash, and
we hope they've learned from these disasters.

First, Lenovo was found out earlier this year to be shipping its
laptops installed with a piece of pre-installed junkware called
“Superfish” which installed a custom root certificate to enable the
software to man-in-the-middle HTTPS connections to inject
advertisements.

In addition to being creepy and inappropriate, this approach
introduced a devastating security vulnerability as it was easy for
anybody to extract the root certificate's private key and then (with
some mild trickery) man-in-the-middle HTTPS connections to most
external sites. EFF was able to confirm that several thousand
Superfish-signed certificates were seen in the wild using data from
our Decentralized SSL Observatory.

Despite the ensuing controversy, Dell was caught in November doing
essentially the same thing. On the plus side, while Lenovo initially
dragged its feet to recognize the severity of Superfish, Dell quickly
issued an apology and a tool to remove the offending certificates.

== Export-Grade “Security” Proves Insecure, Again ==

Calls for deliberately weakened encryption seem to overlook the fact
that we are less secure even today as we deal with the reverberations
of the 1990s-era “Crypto Wars,” and official decisions to limit the
security of crypto software around the world. The most significant
practical cryptanalytic attack of 2015 took advantage of that
insecurity.

On May 20, a group of 14 security researchers published a paper titled
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice
describing an attack targeting Diffie-Hellman (DH) key exchange as
used by HTTPS, SSH, VPN and other servers.

This was really two distinct vulnerabilities. The first, against
512-bit DH parameters, was demonstrated by the research team itself
using consumer-grade hardware and affects many servers still in
deployment in 2015 (many of which have seen been patched, but not
all). This is the attack that, like last year's FREAK, relies on the
continued use of "export grade" ciphersuites in many TLS deployments.
“Export grade” ciphersuites are, of course, a relic of law enforcement
limiting the export of strong encryption.

The second Logjam attack, against 1024-bit DH parameters, was
estimated by the researchers to be just within the resources of a
nation-state attacker (read: NSA) to perform. It relies on the fact
that breaking discrete-log in a 1024-bit DH group requires significant
pre-computation which is specific to the prime in use, but this can
amortized by attacking many servers using the same prime. By analyzing
the NSA 'black budget,' they went one step further, showing that it is
at least possible if not likely that the NSA has been performing this
attack for some time.

As in the past, the insecurity discovered here a pain to clean up.
Major browsers have removed the insecure 512-bit export-grade suites,
but the 1024-bit attack remains effective in practice.

== Certificate Transparency Catches Symantec's Screw-ups ==

Security certificates tell our computers who to trust, so a
“mis-issuance”—when somebody gets or makes a certificate they're not
supposed to—is a big problem. Fortunately, 2015 was a quiet year for
mis-issuance, and the big story comes from a long-awaited protection
measure doing its job.

In September, Google researchers discovered a certificate for
google.com mistakenly issued by Symantec, apparently for "testing"
purposes. Two things were interesting about this compared to past
rogue certificates. First, it was an extended validation (EV)
certificate, which are supposed to have a higher standard of checking
before issuance. Second, it was perhaps the first major rogue
certificate detected by Certificate Transparency logs.

This is exactly what CT was designed to achieve and this was a nice
validation of years of work to get CT deployed. Further testing
revealed that Symantec mis-issued at least 164 certificates for
"testing", indicating long-running operational problems. Symantec was
hit with an unusual penalty by Google: as of June 2016 all Symantec
certificates will have to be included in CT logs to be accepted by
Chrome. While the plan has always been for Chrome to eventually
require all certificates to be included in a CT log, imposing this on
Symantec early is effectively a probationary status. In December, one
of Symantec's root certificates was also removed from Chrome.

== Backdoor Backfires, in Exploit Built on NSA's Shaky Foundation ==

In late-breaking news, one of the backdoors discovered in Juniper's
code base this month might be the first non-NSA exploit of the
infamous Dual_EC random number generator.

One of the most pernicious NSA actions revealed by the Snowden leaks
was the backdoor inserted into the Dual_EC standard. Unpredictable,
random numbers are critical in cryptography for many purposes,
including generating secret keys. By picking two constant numbers (P
and Q) in the standard Dual_EC algorithm to have a special
relationship (a known discrete logarithm e), NSA gained the ability to
learn the value of secret keys and other random values generated using
the Dual_EC algorithm. Because the secret value e is needed to exploit
it, this appeared to be a "nobody but us" backdoor.

Interestingly, Juniper (as well as several other companies) recognized
the risk of using the NSA-recommended P and Q and used different
values in its devices. This would still be concerning, as it's not
clear if this gives Juniper (or somebody else) the same backdoor that
NSA wanted. However, the backdoor discovered by Juniper last week
appears to work by changing P and Q yet again through an "unauthorized
code change" to Juniper's source code.

Essentially, Juniper tried changing they key to NSA's backdoor
(possibly throwing their own key away) and then somebody apparently
sneakily changed the key yet again. It appears that, despite Juniper's
purported efforts to hedge against the use of Dual_EC with a second
random number generator, this is an exploitable backdoor due to bugs
in the software (intentional or unintentional). We don't know who did
this or how they inserted the unauthorized code. It could have been
NSA itself reclaiming its original backdoor, a foreign intelligence
agency, or possibly a criminal organization. Whoever did it had the
ability to decrypt all traffic from many Juniper middleboxes for a
period of several years.

Once again, the misguided belief that cryptography can be compromised
for "nobody but us" appears to have backfired spectacularly. Oh, and a
much simpler master SSH password vulnerability was also inserted into
Juniper's codebase for good measure.

== Out With the Old, In With the New: The Continual Process of
Upgrading HTTPS ==

It's always important in cryptography to upgrade best practices as new
attacks are discovered. Ideally of course, by the time algorithms are
broken they've already been phased out of use. The web has often been
very slow in removing support for outdated algorithms. 2015 was
encouraging in that several important changes were made to upgrade the
security of crypto on the web:

Although it happened several years after the other major browsers,
Microsoft Internet Explorer 11 finally added support for HSTS, an
important standard to allow Internet domains (such as eff.org) to ban
downgrades to insecure plain HTTP. All major current browsers now
support HSTS.
Chrome and Firefox both rolled out support for public-key pinning
(HPKP), enabling domains to specify an allowable whitelist of keys or
certificate authorities to block rogue certificates.
The long funeral procession for the RC4 cipher has finally reached the
cemetery. We've known RC4 was vulnerable for over a decade and there
have been an explosion of practical attacks over the past few years,
prompting IETF to officially declare RC4 banned for continued use. In
September, Microsoft, Mozilla and Google simultaneously announced RC4
will be completely disabled by early next year.
The long-running phaseout of the hash function SHA-1 continues. As of
January 1, 2016, new certificates issued using SHA-1 will no longer be
trusted. While a full collision in SHA-1 is yet to be found which
would represent a serious break of the algorithm in practice, about
the next-closest attack was announced in October of this year (a
free-start collision).

== The Shape of Crypto To Come & NSA's Troubled Leadership Role ==

We might look back on 2015 as the last year that non-quantum-safe
cryptography was considered acceptable. This comes from an official
NSA announcement this August—not the leaked documents we've grown used
to. The announcement states that NSA will update its list of recommend
cryptographic algorithms to include only algorithms which are
resistant to cryptanalysis by quantum computers.

In the long run, most cryptographers believe moving to quantum-safe
algorithms is necessary. Quantum computers may never exist, but
cryptography is about defending against the strongest conceivable
adversary. So on the surface, early government support for this
inevitable upgrade should be a positive development that
cryptographers can rally behind. Unfortunately, this NSA announcement
was also met with considerable skepticism and fear.

There has been a steady erosion of trust in the NSA's information
assurance mission due to incidents like its tampering with the Dual_EC
standard. As a result, many in the cryptography community aren't sure
what the real NSA motives are (and the announcement didn't offer any
explanation). Is NSA simply being cautious? Have they actually
developed a working quantum computer (which would be the world's
first)? Are they trying to replace secure algorithms with
"quantum-safe" algorithms that are actually back-doored? Or are there
other motives involved? Neal Koblitz and Alfred Menezes, two
experienced and well-respected cryptographers, outlined many possible
interpretations of this announcement.

In any case, this is major news because US government agencies will be
obligated to upgrade to whichever algorithms the NSA decides are
quantum-safe and hence the entire computer industry will have to
support them. Today, the Suite B list of recommend algorithms (AES,
SHA-256, ECDSA and so on) are still a de facto standard and are by and
large considered secure. But in the long run, the announcement should
have us asking the question: who should be in charge of setting
cryptography standards? Can the US government still lead this process
in an open and transparent way which the community believes is about
ensuring security rather than planting another round of dangerous
backdoors that the next generation of cryptographers will have to deal
with?

This article is part of our Year In Review series; read other articles
about the fight for digital rights in 2015. Like what you're reading?
EFF is a member-supported nonprofit, powered by donations from
individuals around the world. Join us today and defend free speech,
privacy, and innovation.

_______________________________________________

NOTE: As of July 10, the mailing list address HAS CHANGED from @linuxbox.org TO @lists.linuxbox.org. Please use the new 
address in all mail to the list.
_______________________________________________

Fun and Misc security discussion for OT posts.
http://lists.linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.