The thing about Hardware Security Modules

Hardware Security Modules (HSMs) are not easy to maintain, and they don’t always end up providing the security you hope them to. If you are all about checking your FIPS 140–2 checkbox, then yes, go ahead and get that Level X HSM. But if you genuinely care about securing your infrastructure, you may want to consider several additional points.

What HSMs Are, and what they’re Not

HSMs securely generate and store cryptographic keys, and perform cryptographic operations such as signing, signature validation, encryption, decryption, and hashing. The HSM is a cryptographic oracle which one can ask to perform certain operations. That’s about it, more or less. But often, the more important question is who (or what) can query this oracle. For example, imagine you store your private key to your Bitcoin wallet in an HSM. An attacker might not be able to steal the key, but if she can ask the HSM to sign data with it, she can approve unintended transactions and steal that Bitcoin. The point is, you need to properly specify and enforce access controls and limit who can operate the HSM. You also need to think about protecting the credentials to access the HSM.

We have noticed, working with customers, that while users would kick the security can elsewhere, and obtain FIPS compliance by using an HSM, they might not properly secure the PIN code that enables authentication to the HSM. One example of it is encrypting data on a machine using a key that is stored in an HSM but putting the PIN code to the HSM alongside the encrypted data. To use an analogy, you wouldn’t lock your door and put the key right in front of it, right? Perhaps you’d ask your neighbor to keep your key. But then you wouldn’t put the key to your neighbor’s house right in front of your door, would you? For a real-world example of this issue see this blog post.

Network vs. USB/PCI-connected HSMs

Illustration of a PCI connected Hardware Security Module

Network HSMs are appliances with a network (Ethernet) port that can serve requests via encrypted communication channels. Establishing an encrypted and authenticated connection from the client software to the HSM is crucial to thwart man-in-the-middle attacks and prevent unauthorized clients from requesting service from the HSM.

USB and PCI connected HSM are installed onto a host machine (for instance a Linux server). While the keys generated and stored by the HSM might be protected, end-to-end security becomes dependent on the security of the host. Your real security perimeter is not the HSM itself, but rather the host it is attached to. Good job, you’ve just exposed your keys to network exploits, zero-day vulnerabilities in the operating system, or bugs in privileged software running on the host. And if you feel good about the security of that host, then why attach an HSM in the first place and not just put the keys on the Linux machine?

To be fair, an attacker would not be able to steal the keys, and use them to decrypt or sign data offline, not running on the host the HSM is attached to. But we probably want to shoot for better security than that.

Securing workflows, not just keys

Applications connecting to an HSM should only have access to authentication PIN or other credentials if they are trusted. An attacker that can authenticate and request service from the HSM would be able to sign maliciously crafted certificates, approve illegal transactions, get unauthorized access to encrypted data, etc.

We must think about which users or applications are accessing the HSM, and how to control this access. Ideally, we would like to limit access to keys or an HSM that stores them to trusted applications.If we can limit the access to keys, or to authentication credentials for accessing the HSM to specific application identities, we can secure entire workflows end-to-end.

Runtime Security

Anjuna provides a unique approach to securing entire workflows, binding data, and keys to trusted applications using Runtime Security. It leverage secure enclaves based on technologies like Intel® Software Guard Extensions (SGX) and AMD Secure Encrypted Virtualization (SEV) to encrypt sensitive data such as credentials used to authenticate to a network HSM, or the cryptographic keys themselves in a way that the data is only accessible to the authorized applications. This enables protecting the workflow end-to-end, the application that connects to a key-management solution or an HSM and the credentials needed for it to authenticate itself, to the key-management solution itself (if a software key-management system is used). You can learn more about it on Anjuna’s website.

The thing about Hardware Security Modules was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.