Heartbleed begets headaches in perfecting encryption
Connecting state and local government leaders
New guidelines on improving encryption tools in the wake of the Heartbleed bug offer a range of options for improving encryption, but bigger changes loom down the road.
In the wake of major data breaches during the last few months, and with the ongoing scare over the OpenSSL Heartbleed bug, government security managers will likely find themselves dealing with major changes in some of the encryption tools they use to safeguard their agencies’ data.
One change is already in the works. The National Institute of Standards and Technology recently released an update to its Special Publication 800-52, which offers guidelines on how to implement transport layer security (TLS) protocols. TLS is the standard used to protect sensitive data — anything from credit card numbers to patient health information, email and social networking details — that have to move across open networks, such as the Internet.
The Internet Engineering Task Force (IETF), which oversees Internet standards, found vulnerabilities in the 1.0 version of TLS and spent several years upgrading it through versions 1.1 and 1.2. Meanwhile, NIST withdrew the initial 800-52 guidelines, which it released in 2005, because it didn’t include any of the updates included in TLS 1.1 and 1.2.
The latest revision of the guidelines rectifies that, and offers network administrators a range of recommendations on how to configure TLS options, according to NIST, including which algorithms to use and the length of cryptographic keys.
And admins will have to deal with even bigger changes down the road. The IETF is currently considering yet another update in the TLS spec, to 1.3, which will likely remove the RSA key transport cipher suites. The RSA code has been the decades-old basis of the “handshakes” that are used to control network sessions, and are considered to be too vulnerable to attack.
Improving the TLS handshake is one of the prime design targets for the IETF TLS 1.3 working group. The current IETF thinking is apparently to instead use systems such as the Diffie-Hellman Exchange or Elliptic Curve Diffie-Hellman Exchange. Both of those support perfect forward secrecy, which many organizations are pushing because they see it as offering much better protection for the keys used to encrypt data and communications. Perfect forward secrecy is set up when a compromise of one message cannot lead to the compromise of others.
However, perfect forward secrecy is not entirely perfect, as it turns out. All of the network sessions signed using a leaked or stolen key would still be open to compromise, for example. So while it would work for all future sessions it wouldn’t retroactively solve problems caused by the Heartbleed bug.
But the need for something better, and for the features TLS 1.3 will offer, is now much clearer. Heartbleed itself is still being examined, though early attempts to estimate the costs from fixing the many systems that could be affected suggest there will be major repercussions.
A more tangible indicator is what happened with the data breach at Target stores last year. Analysis of the numbers involved with that breach — which was not even the year’s biggest — are staggering: $200 million for banks to reissue cards to customers whose card numbers were stolen, and $100 million for Target to upgrade its payment terminals. The company also saw a 46 percent hit to its bottom line in the fourth quarter of 2013, as it struggled to regain its customers’ confidence.
There’s a takeaway from that analysis that NIST, the IETF or anybody else could have fixed, however. There were precisely zero people at Target with the title of either chief information security officer or chief security officer.
NEXT STORY: New tools for combating income tax refund fraud