How to Counter Threats Like the Heartbleed Bug

Due to the discovery of The Heartbleed Bug in OpenSSL by Google security researcher Neel Mehta, private keys now should be considered vulnerable. This a mission critical, worst case scenario.

How could such an event happen? OpenSSL and all other Open Source software have been considered to be secure because the source code is available to the public and such a critical bug would most likely be found and fixed immediately. But like any software, Open Source software can have bugs due to errors in implementation. This case also demonstrates that 100% security can never be guaranteed, even in open software

So, what can be done to better protect private keys? There are two major promising approaches: hardware tokens and the concept of diversity.

Hardware tokens, such as the CodeMeter Dongle, store private keys in a secure smart card chip. Each cryptographic operation sends data to the token. Data is signed or decrypted in the token, using the private key in the token. The private key itself never leaves the token. So it is not vulnerable to attacks against the memory.

In the Industry 4.0 era of connected machines, authentication is essential for secure communication. Most implementations rely upon OpenSSL. So without additional security, all controllers and embedded devices can be considered to be vulnerable. The effort for enrollment of new keys is more expensive than providing one hardware token for each device.

The other approach to protecting private keys is diversity. In this context, diversity refers to the application of two different technologies from two different development teams. It can be used to achieve safety as well as security. In a safety implementation, the two technologies are connected in parallel. In a security implementation, the technologies are connected sequentially. If one of the technologies fails, the other takes over to prevent the security breach.

In theory, if there was a bug in the server, a hacker could have access to the token. But, he would not be able to extract the keys from the token. If there was a bug in the firmware of the token, a hacker could not access this bug, because he cannot hack the server. In order for the hack to be successful, there would need to be two exploits occurring at the same time, directed at two separate technologies from two different development teams. If both technologies are maintained and up to date, the probability that exploits occur at the same time is much lower than in a single technology solution.

Wibu-Systems has used the diversity approach successfully for many years in our CodeMeter License Centralsecure licensing tool, which relies on Apache Tomcat and Apache Httpd Web servers. The servers are connected sequentially. So if there is an attack to one of them, the other one still protects data in the database.

The OpenSSL bug demonstrates two things: 1) Private keys do not belong on the hard drive and in the memory of the computer, and 2) security of Open Source software is a myth. You need to evaluate the threat scenarios and develop the appropriate security model that provides optimum protection, even in the case of implementation errors. Ask our experts.