The State of Cryptography in 2014, Part 1: On Fragility and Heartbleed

It seems like cryptography has been taking a knock recently. This is both good and bad, but is not actually true: cryptography is always under attack, and for that reason constantly evolves. That’s bad, but it’s good to realize that cryptography needs constant attention. The threat to cryptography can be very disruptive, as we most recently saw with Heartbleed, and more distantly with ‘issues’ in various algorithms like RC4, MD5, SHA1 and Dual_EC_DRBG (all of which should not be used any more, by the way.)

Should we trust cryptography? No! Yes! Maybe!

Cryptography is both an art and a science. A lot of the math involved in creating a good cryptographic algorithm or protocol is solid, but also subtle. There are perhaps only a few dozen individuals in the world who are immersed enough in information theory, statistics, and algorithms to produce strong algorithms. Rare as they are, these people may not be the right choice for cryptanalysis – the flip-side of designing a cipher: breaking it. You need both these disciplines – cryptography and cryptanalysis – to produce a secure cryptographic algorithm.

There is no deterministic way (yet) of creating a good cipher or other cryptographic algorithm, so creativity is also required. Useful algorithms like one-way hashes (MD5, for example) were created on initial informed hunches and then rigorous analysis. Every time a candidate is produced, it is attacked until successful and the results cycled back to the design. In the end, an algorithm is produced that is believed to be strong enough, by current standards of creativity and ingenuity.

Despite that, these algorithms are eventually found to be broken. Consider MD5 and SHA1 back in 2004, where researchers found that they were demonstrably not collision resistant (a necessary prerequisite for using a hash algorithm for certification), after previous researchers had previously found flaws that, at the time, were not proved to be exploitable.

The 2004 study led to further attacks against the SSL/TLS protocol that secures our web browsing experience. Yet, even today, MD5 is still being used in SSL/TLS certificates – based on the data from the Crossbear SSL project. Even though it is believed that some of the vulnerabilities of MD5 are mitigated in this use case, attacks only get better, so using MD5 is still not recommended. More worryingly, it is not clear that practical, provably secure cryptographic hash functions can exist that fulfill the necessary criteria for such a function. Some still use MD5 for other purposes, and that is fine – so long as you know what you’re doing.

However, that is what I hope you’ll be able to take away from this post. Cryptography evolves, and users have to keep up with developments in the state of the art directly or indirectly. Microsoft, for example, has already announced that they will reject SHA1-based certificates from 2016 onwards. If Microsoft is your vendor of choice, this is good news: it means that at least in this, they have your back. Some vendors are good at security, some less so. What you choose to use may affect your security.

Fragility of cryptography

Because the math behind cryptography is rather subtle and specialized, getting to a secure implementation of any given algorithm is hard. If there ever was a case for a “programmer’s driver’s license”, cryptography is it. So many exploitable bugs have been found in implementations of cryptography, that my advise has always been to use a trusted open source implementation whenever possible, or contract the programming out to actual cryptographers who know the math. Victor Shoup, a leading cryptographer, maintains his own C++ library because he felt uncomfortable with using a library not built with security in mind.

And then Heartbleed happened. OpenSSL is an open source implementation of the SSL/TLS protocol and associated algorithms; it should (and was) a beacon of how cryptography needs to be implemented. However, bugs happen, and the real tragedy of Heartbleed was not that the bug (admittedly, a rather stupid one) was created, but that the bug was not found for more than two years. This was not supposed to happen in an open source project, where changes are public and can be immediately peer reviewed.

As a knee-jerk reaction, the OpenBSD community signaled no confidence in the stewardship of OpenSSL and forked it, creating LibreSSL. Given that their first act was to remove a lot of the legacy platform code (oh no, you can’t run LibreSSL on VMS anymore), it is rapidly becoming a OpenBSD-only library. All of us will lose if this approach is taken more often, as you get to the stage where the two code forks are so different that sharing security patches is very difficult. Postfix was created as a reaction to the bloat of Sendmail, but ended up nearly as bloated and only a little less buggy. Will this be the fate of LibreSSL?

It should be pointed out that Heartbleed had nothing to do with the actual cryptography in OpenSSL. It did have serious security consequences, though, and demonstrates that security problems can arise in nearly any piece of software.

In Part 2: Is hardware-based cryptography any safer? (Short answer: it isn’t.) Black swans, and takeaways.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

The State of Cryptography in 2014, Part 1: On Fragility and Heartbleed