How broken is SHA-1 really?

Posted by   Martijn Grooten on   Mar 15, 2016

Earlier this month, I gave a talk entitled "How Broken Is Our Crypto Really?" at the RSA Conference in San Francisco. In the presentation, I looked at vulnerabilities found in cryptographic protocols and analysed the likeliness of these being exploited in practice.

I spent a few minutes talking about SHA-1 and stated that it is unlikely that we will see fake TLS certificates exploiting SHA-1 collisions in the next few years.

Afterwards, someone from the audience told me that, just the day before, Adi Shamir had told an audience at the same conference that he believes a SHA-1 collision will be found within the next few months. Bart Preneel, from the University of Leuven, made a similar statement at another conference. So who is right?

I wouldn't dare to disagree with either Adi Shamir or Bart Preneel, let alone with both of them, so if I were to find myself with an opposing opinion, I would humbly spend a few days reading research papers. But in this case, our statements don't contradict.

SHA-1 is a hash function: a function that turns any arbitrary sequence of bytes — whether it's a short string or a huge file — into a fixed-length block, called a "hash". While a simple cardinality argument shows that the output of a hash-function isn't unique, it should be impossible in practice to find two byte sequences with the same hash. Given a hash, it should also be impossible to find a byte sequence with that hash.

In TLS, including HTTPS, hash functions are used in certificates that demonstrate proof of ownership, in this case of a domain. To show the validity of the certificate, it is signed by a "higher authority". For practical reasons, this signature is actually the signature of the hash of the certificate, using one of a number of hash functions.

To create a fake but valid certificate, one needs to take an existing certificate and forge a second certificate with the same hash, so that their signatures will match. The existing certificate doesn't have to be that of the domain one is trying to impersonate: any so-called intermediate certificate (a certificate of a slightly higher authority) will do, as this can then be used to sign the actual certificate.

SHA-1-round.png

So how broken is SHA-1 really?

As a hash function, it is broken if someone can find a collision. We're not there yet, but Marc Stevens from CWI in the Netherlands is getting pretty close (he has found a collision for a slightly weaker form of SHA-1), and it may well be that he or someone else will find a proper collision. The time has come to move away from SHA-1.

But a collision doesn't mean one can forge certificates. For that to happen, someone needs to find a string of bytes that is both a valid certificate and whose SHA-1 is the same as that of a given certificate. This is orders of magnitude more difficult than finding a SHA-1 collision — in part because of a number of mitigations built into certificates to prevent these kinds of attacks — and although one can never be certain, it is likely that it will take years before someone is able to fake a certificate in this way.

However, we can't just wait for that moment and then quickly disable SHA-1 certificates all over the Internet. Certificates are often valid for several years and even if your own certificates don't use SHA-1, someone could fake an intermediate certificate and thus impersonate your domain. Hence the process of phasing out SHA-1 has started already.

I am confident that SHA-1 certificates will have long ceased to be accepted by the time they can be faked by the most powerful adversaries, but there are voices who argue that we should speed up the process. After all, we have been there before with another hash function, MD5, which was broken in 2004 and for which a hash collision was used to impersonate Microsoft by the Flame malware. We don't want to be caught out again!

Unfortunately, security vendors aren't all at the front of this phasing-out process. Mozilla recently had to revert part of the phasing-out process, due to the fact that some security devices generated certificates on-the-fly that used SHA-1 hashes.

And it's not just in certificates that SHA-1 is being used. A lot of security software uses SHA-1 or even MD5 internally. In many cases, even for MD5, this will be fine in practice, but there are implementations where it isn't and where it could, for instance, be used to bypass a security scanner.

It also remains common practice for security researchers to include MD5 hashes of malware samples in their research reports.

So let's calm down and realise that reports of the death of SHA-1 certificates are greatly exaggerated. But let's also practice what we preach and, especially as security researchers, get rid of MD5 and SHA-1.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest posts:

Necurs pump-and-dump spam campaign pushes obscure cryptocurrency

A Necurs pump-and-dump spam campaign pushing the lesser known Swisscoin botnet is mostly background noise for the Internet.

Alleged author of creepy FruitFly macOS malware arrested

A 28-year old man from Ohio has been arrested on suspicion of having created the mysterious FruitFly malware that targeted macOS and used it to spy on its victims.

The threat and security product landscape in 2017

At the start of the new year, Virus Bulletin looks back at the threats seen in the 2017 and at the security products that are available to help mitigate them.

Spamhaus report shows many botnet controllers look a lot like legitimate servers

Spamhaus's annual report on botnet activity shows that botherders tend to use popular, legitimate hosting providers, domain registrars and top-level domains when setting up command-and-control servers.

Tips on researching tech support scams

As tech support scammers continue to target the computer illiterate through cold calling, VB's Martijn Grooten uses his own experience to share some advice on how to investigate such scams.