Another week, another TLA[1]. This time round, it’s Hardware Security Module: an HSM. What, then, is an HSM, what is it used for, and why should I care? Before we go there, let’s think a bit about keys: specifically, cryptographic keys.
The way that most cryptography works these days is that the algorithms to implement a particular primitive[3] are public, and it’s generally accepted that it doesn’t matter whether you know what the algorithm is, or how it works, as it’s the security of the keys that matters. To give an example: I plan to encrypt a piece of data under the AES algorithm[4], which allows for a particular type of (symmetric) encryption. There are two pieces of data which are fed into the algorithm:
- the data you want to encrypt (the cleartext);
- a key that you’ve chosen to encrypt it.
Out comes one piece of data:
- the encrypted text (the ciphertext).
In order to decrypt the ciphertext, you feed that and the key into the AES algorithm, and the original cleartext comes out. Everything’s great – until somebody gets hold of the key.
This is where HSMs come in. Keys are vital, and they are vulnerable:
- at creation time – if I can trick you into creating a key some of whose bits I can guess, I increase my chances of being able to decrypt your ciphertext;
- during use – while you’re doing the encryption or decryption of your data, your key will be in memory, which means that if I can snoop into that memory, I can get it (see also below for information on “side channel attacks”;
- while stored – unless you protect your key while it’s “at rest”, and waiting to be used, I may have opportunities to get it.
- while being transferred – if you store your keys somewhere different to the place in which you’re using it, I may have an opportunity to intercept it as it moves to the place it will be used.
HSMs can help in one way or another with all of these pieces, but why do we need them? The key reason is that there are times when you can’t be certain that the system(s) you are using for creating, using, storing and transferring keys are as secure as you’d like. If the keys we’re talking about are for encrypting a few emails between you and your spouse, well, you might find it embarrassing if they were compromised, but if these keys are ones from which, say, you derive all of the credit cards chip keys for an entire bank, then you have a rather larger problem. When it comes down to it, somebody with sufficient privilege on a standard computing system can look at any part of memory – unless there’s a TEE[5] (Oh, how I love my TEE (or do I?)) – and if they can look at the memory, they can see the key.
Worse than this, there are occasions when even if you can’t see into memory, you might be able to derive enough information about a key – or the ciphertext or cleartext – to be able to mount an attack on it. Attacks of this type are generally called “side channel attacks”, and you can think of them as a little akin to being able to work out the number of cylinders and valves a car[6] engine has by listening to it through the bonnet[7]. The engine leaks information about itself, even though it’s not designed with that in mind. HSMs are (generally) good at preventing both types of attacks: it’s what they’re designed to do.
Here, then, is a definition:
An HSM is piece of hardware with protected storage which can perform cryptographic operations attached to a system – via a network connection or other connection such as PCI – and which has physical protection from various attacks, from side attacks to somebody physically levering open the case and attaching wires to important components so that they can read the electrical signals.
Many HSMs undergo testing to get certification against certain standards such as “FIPS 140” to show their ability to withstand various types of attack.
Here are the main uses for HSMs.
Key creation
Creation of keys is, as alluded to above, a very important operation, and one where side attacks have proved very effective in the past. HSMs can provide safe(r) key generation, and ensure appropriate levels of randomness (entropy) for the required strength of key.
Key storage
HSMs are typically designed so that if somebody tries to break into them, they will delete any keys which are stored within them, so they’re a good place to store your keys.
Cryptographic operations
Rather than putting your keys at risk by transferring them to another system, and away from the safety of the HSM, why not move the cleartext to the HSM (encrypted under a transport key, preferably), get the HSM to do the encryption with the keys that it already holds, and then send the ciphertext back (encrypted under a transport key[8])? This reduces opportunities for attacks during transport and during use, and is a key use for HSMs.
General computing operations
Not all HSMs support this use (almost all will support the others), but if you have sensitive operations with lots of keys and algorithms – which, in the case of AI/ML, for instance, may be sensitive (unlike the cryptographic primitives we were talking about before), then it is possible to write applications specifically to run on an HSM. This is not a simple undertaking, however, as the execution environment provided is likely to be constrained. It is difficult to do “right”, and easy to make mistakes which may leave you with a significantly less secure environment than you had thought.
Conclusion – should I use HSMs?
HSMs are excellent as roots of trust for PKI [9] projects and similar. Using them can be difficult, but most these days should provide a PKCS#11 interface which simplifies the most common operations. If you have sensitive key or cryptographic requirements, designing HSM use into your system can be a sensible step, but knowing how best to use them must be part of the architecture and design stages, well before implementation. You should also take into account that operation of HSMs must be managed very carefully, from provisioning through everyday use to de-provisioning. Use of an HSM in the cloud may make sense, but they are expensive and do not scale particularly well.
HSMs, then, are suited to very particular use cases of highly sensitive data and operations – it is no surprise that their deployment is most common within military, government and financial settings. HSMs are not right for every project, by any means, but form an important part of our armoury for the design and operation of sensitive systems.
1 – Three Letter Acronym[2]
2 – keep up, or we’ll be here for some time.
3 – cryptographic building block.
4 – let’s pretend there’s only one type of AES for the purposes of this example. In fact, there are a number of nuances around this example which I’m going to gloss over, but which shouldn’t be important for the point I’m making.
5 – Trusted Execution Environment.
6 – automobile, for our North American friends.
7 – hood. Really, do we have to do this every time?
8 – why do you need to encrypt something that’s already encrypted? Because you shouldn’t use the same key for two different operations.
9 – Public Key Infrastructure.
Alice, Eve and Bob - a security blog 
Hey Mike – quick question, or maybe you could provide some clarity for a newbie into infosec – in the “General Computing Operations” section, you mentioned that writing applications inside an HSM is hard to do right and often would result in a significantly less secure environment than you had thought. Doesn’t writing an app in an HSM just make it less efficient with its normal functions of securing keys – how does writing an application on an HSM make it less secure?
LikeLike
Fair question. I think the problem is that people misunderstand how correctly to write applications which fit into the HSM environment, and the outcome is that they get a false sense of security with an application which is not designed for the environment it’s actually running on.
LikeLike