Secure Hash Algorithm is everywhere. Better known as SHA-1, it is a cryptographic hash function published by NIST
that's used in several popular security protocols, including Secure Sockets Layer (SSL), Pretty Good Privacy, Secure Shell, Secure Multi-Purpose Internet Mail Extensions and IPSec. It has been around since 1995 and is used in more than 98% of all digital certificates issued worldwide.
Many experts believe that theoretical collision attacks on SHA-1 could become a reality in the not-too-distant future.
However, SHA-1 is beginning to show its age and NIST has said that it should not be trusted for digital signature generation past January 2014.
So what's wrong with SHA-1? Are current enterprise applications at risk? How should organizations plan for its demise? In this tip, I will answer these questions and more.
The problem with SHA-1
Cryptographic hash functions are widely used in many aspects of information security, such as digital signatures and data integrity checks. These functions take an electronic file, message or block of data and generate a short digital fingerprint of the content called a message digest or hash value. There are two critical properties of a secure cryptographic hash function: First, nobody is able to determine the input from the output, and second, two different inputs can't create the same output. This last property, called collision resistance, has become a major concern when it comes to SHA-1. The strength of SHA-1's collision resistance in today's world of powerful cloud-based computing is pushing major software vendors and security experts to move to a stronger hash function sooner rather than later.
In other words, a collision attack against a hash function tries to find two inputs producing the same hash value. Many experts believe that theoretical collision attacks on SHA-1 could become a reality in the not-too-distant future. With the advent of affordable ASICs capable of trillions of hashes per second, there could easily be a sudden advance in hash collision attacks, which could quickly render the Internet's fundamental security protocols insecure.
Transitioning to SHA-2
To avoid a situation where mission-critical systems are suddenly reliant on insecure protocols, federal agencies started migrating applications to SHA-2 in 2010. SHA-2, a set of next-generation cryptographic hash functions created in 2001, doesn't suffer from SHA-1's mathematical weaknesses and offers hash functions with digest lengths of 224-, 256-, 384- or 512-bits, with SHA-256 and SHA-512 the most commonly used.
In 2012, Microsoft began signing code with SHA-2 and, according to its recently released SHA-1 Deprecation Policy, certificate authorities in the Microsoft Root Certificate Program will be required to only use SHA-2 when issuing certificates for SSL or code signing starting Jan. 1, 2016. Microsoft has already set 2,048-bit keys as a requirement for its root-certificate program. At the end of 2016, Windows Vista and later versions, as well as Windows Server 2008 and beyond, will stop accepting SHA-1 certificates in SSL.
Exploring the enterprise effect
Windows users will not need to do anything during this transition -- even Windows XP Service Pack 3 supports SHA-2 SSL certificates, as does Windows Server 2003 Service Pack 2. SHA-2 certificates are also compatible with most updated modern browsers, OS platforms, mail clients and mobile devices.
However, for enterprises running their own websites or developing Windows applications, it's a different story. Web masters must request new SHA-2 certificates to replace any that use SHA-1 and expire after Jan. 1, 2017, otherwise they will not be trusted by any Windows-based device. SHA-1 code signing certificates without time stamps won't be accepted by Windows after Jan. 1, 2016, while those certificates that are time-stamped before Jan. 1, 2016, will be accepted until further notice.
Organizations should push ahead with the upgrade to SHA-2 now and not hope for a last-minute reprieve despite the fact that no SHA-1 collisions have yet been found. The areas that will require the most work are legacy systems that make SSL connections, and software and hardware such as game consoles, phones and embedded devices that rely on hard-coded certificates. These certificates will all need to be replaced and have the software updated if they are unable to currently support SHA-2 encryption. Wherever possible, I suggest using one of the two established crypto libraries: Windows Crypto library or OpenSSL. Both support SHA-2 and will make the inevitable transition to SHA-3 at some point in the future much more straightforward.
Many organizations are currently upgrading their systems running on Windows XP to newer versions, since XP falls out of support on April 8, 2014. To me, it makes sense to upgrade any digital certificates to SHA-2 at the same time. Microsoft's decision to deprecate SHA-1 means its use will decline rapidly in favor of the more secure SHA-2. Two years should be plenty of time to make the necessary changes.
But note, those who procrastinate or put off the inevitable will quickly find that their systems will be unable to communicate with the rest of the connected world, which will certainly hinder business processes and profits. It's clearly better to upgrade now and face a little bit of pain, rather than wait and risk not only major security ramifications, but also significant business disruption.
About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with over 20 years of experience in the IT industry. He has a passion for making IT security best practices easier to understand and achievable. His website http://www.hairyitdog.com offers free security posters to raise employee awareness of the importance of safeguarding company and client data and of following good practices. He co-authored the book IIS Security and has written many technical articles for leading IT publications. Mike has also been a Microsoft Certified Database Manager and registered consultant with the CESG Listed Advisor Scheme (CLAS).