A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.

Hardware security modules are physical devices with auditing and encryption capabilities and are used to protect sensitive information such as encryption keys, as well as for their performance in encrypting/decrypting information. Once you load an encryption key into it, it can only be accessed/used by the authorized party, and each access/use is recorded and can be audited. This offers a very significant benefit when having to store code signing keys, master encryption certificates for a top-level certification authority, or other important keys that are used to protect valuable digital assets.

Scenario 1: You’re a software development firm that produces a piece of software used in financial transaction processing, and you maintain the software and send updates to your customers.

Under this scenario, to protect your clients from receiving software updates from someone else claiming to be you, you would choose to digitally sign the executables and DLLs as well as any updates you send your clients (especially when using an automated delivery method). But now the certificate you use to digitally sign the code becomes valuable to an attacker. How do you guarantee that a former disgruntled employee didn’t save a copy of your certificate, and an attacker didn’t get a copy from an old backup, where do you keep it to be able to use it, etc? If it was used by an unauthorized party, how do you know?

This is exactly what these devices were designed for.

Depending on the industry you’re working with, and especially if in a highly regulated industry, then the certification level and type of the Hardware Security Module can become important, which directly influences features and pricing.

NIST

The National Institute of Standards and Technology (NIST) is a metrology laboratory and a non-regulatory agency of the United States Department of Commerce. Its mission is to promote innovation and industrial competitiveness.

FIPS 140-2

The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS PUB 140-2) is a U.S. government computer security standard used to approve cryptographic modules. The title is Security Requirements for Cryptographic Modules. See: https://en.wikipedia.org/wiki/FIPS_140-2

FIPS 140-2 defines 4 levels of HSMs, with level 1 just requiring basic encryption capabilities with approved algorithms (production-grade equipment of course and with algorithms tested by an external entity), to level 4 being able to detect almost any type of digital or physical attack vector and erase the keys if compromised. Levels 2 and 3 are the most common though, so I’ll go in a bit of detail on those.

FIPS 140-2 Level 2 Hardware Security Module

While Level 1 is capable of cryptographic operations, Level 2 HSMs require features that show evidence of both physical and digital tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module. Level 2 also requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and access the corresponding set of services.

FIPS 140-2 Level 3 Hardware Security Module

In addition to the tamper-evident physical security mechanisms required at  Level 2,  Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module. The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeros all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.

NIST Cryptographic Module Validation Program

https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Validated-Modules/Search

What do these devices look like, and what are my options?

This depends of course heavily on your needs. But there are some major options to consider. First, note that if you’re trying to secure some encryption keys, then backing them up also needs to be secure, so HSM-protected content can only be backed up to another HSM in most cases. Afterward, availability and latency become important considerations.

Dedicated HSMs

Concerns

• High upfront cost (usually >$4,000+ per device for a FIPS 140-2 Level 2 HSM, or double that for a Level 3, and you might need several units)
• Hosting costs/complex to manage - they take up space in your data center, and you need engineers familiar with how they work
• A high number of devices might be needed for redundancy and off-site backup
• Sometimes difficult for developers to integrate or requires specialized knowledge - each vendor can have their own interface and SDK, but usually, support PKCS#11
• Pricy to maintain QA/STG environments

Benefits

• By far the most secure option since you control everything around the device when configured properly
• On-premise/colocated in datacenter next to the application
• Managed by you/your IT
• Dedicated hardware, so only your stuff is on it

Some great options include Thales nShield Edge and SafeNet Network HSM (formerly Luna SA), and although not FIPS 140-2 Certified, YubiHSM is worth keeping an eye on.

Hosted HSMs

####Concerns

• Externally hosted / dependent on a vendor for service
• Traffic between your application and vendor
• Shared hardware
• Latency could be a concern in a cloud-hybrid environment
• HSMs usually require some specialized knowledge, so working with them correctly is always a concern

Benefits

• Lower up-front cost
• Vendor manages backups / replication / guarantees availability
• Vendor manages security and updates

A great option for this is AWS CloudHSM, which is a FIPS 140-2 Level 3 HSM

Hosted services backed by HSMs

Instead of owning your own HSM, another option is using a service that abstracts the communication with the HSM, while still maintaining the security.

Concerns

• Externally hosted / dependent on a vendor for service
• Traffic between your application and vendor
• Latency could be a concern in a cloud-hybrid environment
• Shared hardware

Benefits

• Very low overall cost, with some services it’s almost not there
• Vendor manages backups / replication / guarantees availability
• Vendor manages security and updates
• Straightforward for developers to integrate, APIs are usually simple and don’t require specialized knowledge

Some great options include Azure KeyVault and AWS Key Management Service (KMS).

And finally, if need to own your HSM and control everything, but also want the benefits of the APIs of a service backed by HSMs, HashiCorp Vault Enterprise is a great option