Why We Use Hardware Security Modules

[Updated 5/22/2013] My statement, in the summary, about the limited value of an HSM when using soft keys was poorly articulated.

Hardware Security Modules (HSMs) are a security device that adds a lot of expense, man hours, and complexity to a data processing system. As security and usability are always a trade-off, let’s look at when you want to make the trade. First off, what do HSMs to at a basic level? An HSM is a device used for key management and encryption and decryption of data. The HSM holds the key material on the device and there is no way to export the keys in a usable format. This keeps and attacker from copying your encrypted database and then taking the key and decrypting the data offsite, on his own time, where he is less likely to be caught. Used correctly, this is a big security gain.

There are a few guiding principles to keep in mind when looking at the threats to your data and the protections that the proper use on an HSM can bring.

• Encryption is easy, key management is very hard.
• A computer is only as secure as the administrator is trustworthy.
• Encrypted data is only as secure as the decryption key.
• If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.
• A data processing system, in terms of security, is like a chain. It is only as strong as the weakest link.
• There are some risks that are too big to be accepted by any one person or department. Requiring multiple people for some operations raises the security bar.

When considering how to implement key management, the other option we look at is software based keys. Let’s take a quick look at the trade-offs of each. As you will see, HSMs are not a silver bullet.

	HSM	Software Keys
Someone with physical access to your server can take your keys*	Maybe	Yes
An attacker who can execute code on your servers can copy your keys	No	Yes
A rogue administrator can copy your keys	No	Yes
Use adds considerable extra expense	Yes	No
Use adds considerable complexity	Yes	No
Someone with root level access to your app server can see data before it is encrypted	Yes	Yes

*Properly configured, the keys are unusable even if the HSM is stolen.

While there are hundreds of specific threats and attack vectors against your data processing systems, it is important to align your controls to specific threats. In the case of using hardware encryption modules, there are three basics threats that might make us consider the use of an HSM over software based keys.

1. The rogue administrator.
2. Attackers with physical access to servers.
3. Attackers who have root access on servers.

While there may be some other benefits offered by an HSM, they are ancillary and redundant to other controls that should be in place.

We need to understand a couple of basic HSM concepts before we can see what they do for us.

• The Security World – This is a logical concept that can span more than one HSM. It is a group of HSMs that all share a common master key. Members of a security world can share application keys from other members in the world. Keys can be copied to security world members without possibility of comprise.
• Smart Cards – The security world is run by and protected with smart cards. These cards are actually small computers that that can create keys, store them and perform operations using them. The cards can be protected with a PIN for additional security. The cards are designed to make it very difficult to copy a card in a short time and without destroying it.
• k of n card sets – Many operations on an HSM require a high level of assurance, so the HSM can be setup to require more than one smartcard be used to perform an operation. The card set is sized and distributed so that it is unlikely that cardholders will be able to collaborate on subversive actions. The number of cards required to perform actions is called a quorum. A large n ensures that if cards are lost or destroyed enough can still be found to maintain uptime. k of n is based on Shamir’s Secret Sharing algorithm.
• Administrator Card Set - The ACS cards run the security world, in conjunction with the HSM. ACS cards are used to backup and restore the security world. This includes adding new HSMs to the security world. The key that decrypts the backup file for disaster recovery and adding devices to the security world is base on the ACS and protected with the secret sharing algorithm.
• Operator Cards – The OCS cards are used to access application keys. These are the keys that actually encrypt and decrypt the data. The OCS k of n can be different from the ACS k of n.
• HSM Soft keys – The HSM soft keys these are application keys that can be used with no action from an OCS card set. All you need to do is boot the server holding the HSM, or the netHSM. If an attacker takes the HSM, they have unrestricted use of the key. They can’t export the key, but they can use the key at will to decrypt any stolen encrypted data.

When properly configured, the HSM keeps and attacker with privileged access or a rogue administrator from taking a copy of your encrypted data and copy of your key and decrypting your data at their leisure. The best the attacker can do is to grab data before it is encrypted or send encrypted data to the HSM for decryption. When looked at in conjunction with proper audit logs and some sort of IDS or IPS solution, this should significantly limit the time that the attacker has access to gather plaintext data.

If an attacker manages to steal an HSM they cannot copy your security worlds as they lack the ACS quorum. They cannot use OCS protected keys without the OCS quorum. HOWEVER, anything protected by HSM soft keys can be decrypted by simply putting the stolen HSM online in a new system.

The bottom line is this:

• If you use an HSM with HSM Soft keys, you probably are wasting your money as you are not reducing risk when attackers have physical access. You can get the same logical access value with keys stored in the file system of the appropriate application tier. [Update] The HSM still provides lots of value, as a stolen HSM should go noticed.  You still do need to keep in mind that your operations, both physical and logical, may have a weak link that can lower the security of your overall system. 
• If the attacker has root access at the right tier in your application, at a minimum, they can copy off the data before it is encrypted and worse case, they can call APIs to decrypt data at will.

HSMs are awesome, but don’t assume just they will solve your problems. In my experience, the biggest holes are created by the applications and APIs that rely on the HSMs.