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:

VB2018 preview: hacking cars

In recent years, car hacking has evolved from a mostly theoretical research field involving giggling researchers and scared journalists, to one that actually concerns car owners and manufacturers. On today's blog we preview two VB2018 papers, by…

Where are all the ‘A’s in APT?

In a guest blog post by VB2018 gold partner Kaspersky Lab, Costin Raiu, Director of the company's Global Research and Analysis Team, looks critically at the 'A' in APT.

VB2018 preview: commercial spyware and its use by governments

Today, we preview three VB2018 presentations that look at threats against civil society in general and the use of commercial spyware by governments for this purpose in particular.

VB2018 preview: Wipers in the wild

Today we preview the VB2018 paper by Saher Naumaan (BAE Systems Applied Intelligence) on the use of wipers in APT attacks.

VB2018 preview: IoT botnets

The VB2018 programme is packed with a wide range of security topics featuring speakers from all around the world. Today we preview two of them: one by Qihoo 360 researchers on tracking variants of Mirai and one by researchers from Bitdefender on the…

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.