Last updated: 16 May 2016
“A very little key will open a very heavy door.” – Charles Dickens, Hunted Down
The OpenSSL vulnerability, called Heartbleed, sent shockwaves through the security world. First discovered by Google and Codenomicon, Heartbleed grabs memory from applications running on a web server in a way that makes it possible to reveal private cryptographic keys used in OpenSSL.
These keys, commonly stored on the web server itself, could be used to decrypt web traffic, or even worse, to impersonate the server. In many instances, the hacker who gained access to the key would also be able to decrypt communications that had occurred well before they had the key in their possession. Although patches to the Heartbleed vulnerability are now available, thousands of private keys will have to be reissued.
The Heartbleed vulnerability once again reinforces the importance of strong cryptographic key storage and management. By ensuring the security of the private keys, an organization can significantly mitigate the risk to their sensitive data in the event of an attack – regardless of the point of vulnerability.
The problem extends beyond websites and web servers. Certificate Authorities, which form the root of trust for the Operating Systems we depend on every day, have been subject to complex attacks.
Breaches like Stuxnet and Duqu used private keys stolen from Certificate Authorities to sign malware in a way that made it appear to be legitimate code. Attacks of this nature could be used to sign fraudulent Operating System updates, or create drivers for devices capable of sneaking a malicious payload into even the best protected systems. When attackers successfully attack trusted systems, the systems built on that trust fall apart.
So What Is the Most Secure Way to Protect Cryptographic Keys?
When encryption is used, the risk is transferred from the data itself, to the cryptographic keys. Without strong security for private keys, our systems will always be vulnerable. This is an area where software vendors have struggled. When private keys are stored on the same server as the other components of a system, it is much easier to gain access to those keys, and compromise that system. With a copy of the private key an attacker can create fraudulent identities, and create certificates at will.
Hardware Security Modules (HSMs) are the best way to protect cryptographic keys. HSMs are designed to create a barrier between software on the server and cryptographic key material. HSMs achieve this by offloading cryptographic keys from an application server and isolating them in a dedicated appliance. Implementing an HSM – specifically an HSM that stores private keys inside of the physical device at all times – would greatly mitigate the attack vector for a hacker seeking to access sensitive private keys.
Would Using An HSM Prevent the Heartbleed Vulnerability?
No, but it would have significantly limited the scope of any attack. By preventing the loss of the private key, the need to re-issue certificates would be avoided. And more importantly, the risk to your Enterprise’s reputation by attackers setting up rogue web sites using your identity would also be avoided. Finally, the fact that the private key is safe also reduces the amount of data at risk during the time Heartbleed was exploitable.
For more information download our whitepaper, Making SSL Faster and More Secure