Skip to content
LearnHardware security module (HSM)

What is a hardware security module (HSM)?

Example. Kiteline is a fictional company.
On this page

A hardware security module (HSM) is a dedicated, tamper-resistant device that generates and stores cryptographic keys and performs operations with them internally, so that applications can sign or decrypt with a key without the key ever leaving the device in usable form.

What it is

NIST defines an HSM as "a physical computing device that safeguards and manages cryptographic keys and provides cryptographic processing" (NIST glossary). Another NIST definition stresses "tamper-evident and intrusion-resistant safeguarding" of keys. Many teams use HSMs only indirectly, inside a cloud service: AWS says the keys in its KMS are protected by FIPS 140-3 Security Level 3 validated HSMs (AWS KMS).

The property that matters is non-exportability. You can ask the HSM to use a key; you can't ask it for the key.

Where HSMs are used

  • Root keys of key management services, which in turn protect data keys for databases and secret stores.
  • Certificate authorities, whose signing keys must never be copied.
  • Code signing for release builds; see signed release.
  • Auto-unseal of server-side vaults, where an HSM holds the key that opens the vault's storage; see vault unsealing.

What an HSM doesn't do

An HSM protects the key, not the decision to use it. Anyone or anything that can send requests to the HSM, with the right credentials, can have it decrypt or sign. If the application that talks to the HSM is compromised, the attacker can use the key through it for as long as they keep access, even though they can never take the key away.

That is why "protected by an HSM" doesn't answer "who can decrypt my data?" It answers "can the key be stolen?" For a cloud secret manager, an HSM-backed KMS key still decrypts values whenever an authorized principal asks, which includes the service itself.

Common mistakes

  • Equating HSM-backed with end-to-end. The service holding the HSM still reads the data.
  • Weak access to the HSM. A single API credential that can use the key from anywhere is the real secret.
  • No plan for loss. If the only copy of a key is in one device, losing the device loses the data.

Crunu and HSMs

Crunu has no HSM. It doesn't store keys in hardware modules, and it doesn't integrate with a cloud KMS for value encryption. Keys are generated and used in the browser through WebCrypto and in the crunu agent. Your account key is derived from your password and a Secret Key on your device; environment keys are sealed to each recipient's public key.

The protection comes from where the keys are, not from hardware: the server never holds a key that decrypts values, so there is nothing on it for an HSM to protect. The trade-off is that keys on devices are only as safe as those devices; Crunu can't protect against malware on a machine where keys are in use. The comparison of models is in who can decrypt your secrets?.

Sources

From the blog

  • Security

    Customer-managed keys don't stop the cloud from decrypting

    With a customer-managed key, AWS, Google Cloud and Azure still decrypt your secrets to serve them. What CMEK really controls, and when that is enough.

    Who can decrypt guide

  • Teams

    Removing someone from git-crypt, SOPS or Ansible Vault

    None of the three can take back access someone already had. What each tool does when a person leaves, in what order, and why old commits stay readable.

    Offboarding guide

  • Secrets

    Should you commit .env files? What belongs in Git

    Commit the template, never the values. Which .env files go in Git, what frameworks say, encrypted .env files, and where the real values should live.

    Sharing .env files guide