Exploring Hardware Security Modules (HSMs)

I once consulted a bank about their painstakingly slow cryptography and security processing system. After a week of searching, I examined the cryptographic subsystem, which used Windows Crypto API and a certified CSP.

The server processed digitally-signed data and its cryptographic library calls were mixed with XML processing, database access and other code. This left the machine with absolutely no CPU time to make cryptographic computations. Their processing farm had 10 servers and they were preparing to add two more.

I asked, “Why don’t you use a hardware security module?” The team leader asked me what that was, while the project managers present kept silent, only nodding quietly. I was surprised by his response. This question could take place in 1985, but not in 2005. Taking a deep breath, I began my lecture about HSMs.

This story had a happy ending. The programming team rewrote the code, offloaded crypto to HSMs and the processing server processed as it should. I like happy endings; so, I’d like to share my successful experience of HSM usage.

What is a Hardware Security Module?

The hardware security module (HSM) is a special “trusted” network computer performing a variety of cryptographic operations: key management, key exchange, encryption etc.

It seems to be obvious that cryptographic operations must be performed in a trusted environment. When I say trusted, I mean “no viruses, no malware, no exploit, no unauthorized access.” An HSM is trusted because it:

1. Is built on top of specialized hardware. The hardware is well-tested and certified in special laboratories.
2. Has a security-focused OS.
3. Has limited access via a network interface that is strictly controlled by internal rules.
4. Actively hides and protects cryptographic material.

An ordinary, run-of-the-mill program writer mixes the database access code, business-logic and cryptographic calls in one big application. This is a dangerous approach as an attacker can use crafted data and vulnerabilities to access cryptographic material, steal keys, install an arbitrary X.509 certificate and so on. In one case that I know of, an XML vulnerability opened a door to a hacker who installed a root certificate to the trusted CA and stole $20 million.

To prevent scenarios like this, we need to separate the operations into two different areas. One for the business logic and one for cryptography.  You then need to entrust the cryptographic operation to a trusted computer aka an HSM.

Weak Key, Strong Key

A cryptographic key must be truly random. A computer by design, is unable to generate a really random value because it is a finite-state machine. Therefore, we need a special physical process to generate random numbers and keys. An HSM has special hardware that uses a physical process to create a good source of randomness (entropy) that in turn is used to generate good quality and “perfectly” random keys.

Designed for Performance

HSMs have outstanding and incomparable performance. The maximum you can get in any server is n * 1000 digital signatures per second, but an HSM can achieve millions. It performs a small number of tasks, but does so very efficiently because it’s designed and optimized for such tasks.

Key Management and Use Cases for HSMs

HSMs are built to protect cryptographic keys. Large-sized banks or corporate offices often operate a variety of HSMs concurrently. Key management systems control and update these keys according to internal security policies and external standards. A centralized design of key management brings the advantage of streamlining the management of keys and providing the best overview for the keys across many different systems.

References and further reading

• Selected articles on HSMs (2013-17), by Ashiq JA, Peter Landrock, Peter Smirnoff, Steve Marshall, Torben Pedersen and more
• Selected articles on Key Management (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Martin Eriksen, Peter Landrock, Peter Smirnoff, Stefan Hansen and more
• Selected articles on PCI DSS (2012-today) by Ashiq JA, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Martin Eriksen, Stefan Hansen and more

Image: "Security", courtesy of DaveBleasdale, Flickr (CC BY 2.0)