Home / Blog / It is time for replacing SHA1

It is time for replacing SHA1

Posted on 09/25/2014, by Jesús Díaz (INCIBE)
SHA1

Following the NIST recommendation advising not to use cryptographic hashing algorithms providing security less than or equal to 80 bits of information (like SHA1), Microsoft announced during November 2013, its plan (for CAs adhered to the Microsoft Root Certificate Program) for deprecating digital certificates where the issuing CA has employed SHA1 as hashing algorithm for signing. Google has supported this announcement in August 2014 in Chromium’s security-dev group, and recently in their blog. There, Google has also made public its calendar for the adoption of more secure certificates.

In summary, the actions by the companies from Redmond and Mountains View will be:

Date Microsoft Google
01/01/2016 End of issuance of code-signing certificates Warning to users
01/01/2017 Rejection of SSL certificates Warning to users, Content treated as mixed

In more detail, on one hand, Microsoft, starting January 1st, 2016, Microsoft will reject certificates used to sign code (with the code signing flag set) signed with SHA1 and with an issuance date older than January 1st 2016.

On the other hand, Google will focus its plan in the following Chrome versions. Starting with version 39, all certificates using SHA1 and expiring after January 1st will be treated as insecure, with minor errors. In version 40, certificates using SHA1 and expiring between June 1st and December 31st (both included) will be considered secure, with minor errors; certificates expiring after January 1st 2017 will be treated as neutral, but lacking security. At last, in version 41, certificates using SHA1 and expiring between January 1st and December 31st will be treated as secure with minor errors, while certificates expiring after January 1st 2017 will be treated as insecure, being the content "protected" by them classified as mixed.

The implications of both strategies are different. In the forum of Certification Authorities and Browsers (CAB forum), in 2012, new requirements for the issuance of certificates were set. Specifically, it was defined that, starting April 2015, certificates issued by CAs to end users will have a life time of 39 months at most, instead the current 60 months. This means that, according to Microsoft criteria, a code-signing certificate issued in March 2015 would be considered valid until March 2020. However, Microsoft did state in the original announcement that they would revise this criterion when they deem SHA1 vulnerable to pre-image attacks.

In any case, it is clear that both Microsoft and Google are betting for a more secure Internet. However, what is the real impact of this policy? How many web sites are currently affected?

To gain some insight about the answers to these questions, we use as reference three rankings offered by Alexa:

From the websites appearing in the previous rankings, and which support SSL, we have taken the returned digital certificate, noted down the cryptographic hashing algorithm (sigAlgo) and the expiry dates (notAfter). The scripts employed for this task are available in Bash and Python in Github.

The retrieved data, at 11th September, 2014, is summarized in the charts below (click on the image to enlarge). In the three categories, more than 80% of the websites use SHA1 and between 1% and 2% of them still use MD5, for which attacks are known since 2009 that allow creating fake certificates in less than 1 day.

As for the expiry dates, only between a 27% (Top Global) and a 39% (Top Computer Security) of the digital certificates expire before 2016. Thus, between 61% and 73% of the websites still need to update their certificates to avoid to being considered insecure.

 

Alexa websites certificates

 

 

Causes and consequences

Warnings and restrictions by Microsoft and Google aside, what are the causes and consequences of this event?

Concerning the causes, several attacks started to be published, approximately since 2005, that reduced the security of SHA1 to less than the theoretical 80 bits of security against collisions (that is, a brute-force attacker would have to calculate on average 280 hashes in order to find a collision). Up to now, the most effective attack is probably Stevens’ attack, which may reduce SHA1’s security to roughly 60 bits (260 operations).

With the costs of Steven’s attack in mind, and considering that the calculation of a SHA1 requires (214 CPU cycles), the number of CPUs per server and the expected evolution of computing capacity according to Moore’s law, Jesse Walker estimated how much time would an attacker need in order to find a collision. His calculations are summarized as follows:

  • In 2015, 211 = 2048 server years would be necessary to compute a collision (that is, an attacker would have to dedicate a server during 2048 years to find a collision).
  • In 2018, 29 = 512 server years.
  • En 2021, 27 = 128 server years.

This may seem too much to worry about it but, as Jesse Walker keeps going, if we take into account the costs of hiring computing capacity to Amazon ($0.04/hour or $350/year, at October 2012), the previous costs converted to dollars are:

  • $700.000 in 2015.
  • $173.000 in 2018.
  • $43.000 in 2021.

Considering the benefits that might be obtained with an illegitimate certificate of, say, a big bank, these quantities are less exorbitant (especially for criminal organizations). Moreover, if Amazon lowers the previous prices or new attacks appear improving the costs of Stevens’ attack, these estimations would need revision. In addition, these costs are for commodity hardware. Thus, using specialized equipment (like GPUs) would also incur in results that are more efficient.

As for the consequences, concerning compatibility issues with browsers, servers or other devices and software components, this change would not suppose in principle a major problem, since most of them (or at least their recent versions) already support SHA256 hashes. And, obviously, the certificates themselves are compatible with the more secure alternatives (see for instance RFC 5754 or RFC 5758 for a definition of the OIDs combining the SHA2 family with several signing and encryption algorithms).

Finally, going back to the current state of the migration from SHA1 to SHA2, still much work remains to be done. Luckily, Microsoft and Google have been foresighted in order to avoid a new April 8th, although CAs still need to take the “bold” step.