A hardware security module (HSM) is a tamper-resistant device that creates, stores and uses cryptographic keys inside secure hardware, so a private key never appears in plain form in application memory, files or backups. A crypto API puts a simple service in front of the HSM, so applications can ask it to sign, encrypt or verify data without ever handling the key themselves.
This article explains why software keys are risky, what HSM key protection gives you, how applications talk to an HSM, and how a central crypto service makes HSMs easier to use at scale. For a short definition of the device itself, see our glossary entry What is an HSM?
What an HSM is
An HSM is a dedicated device built to generate and use keys inside a protected boundary. It comes as a network appliance, a PCIe card or a cloud HSM service. It is designed to detect or resist physical tampering, and many models erase their keys if the device is opened or tampered with.
The key idea is simple: keys go in, results come out. You send data or a hash to the HSM, and it returns a signature, ciphertext or plaintext. The private key itself does not leave the device in plain form.
HSMs are tested against standards such as FIPS 140-3 or Common Criteria. NIST’s Cryptographic Module Validation Program states that FIPS 140-2 validated modules could be used for new systems until 21 September 2026, after which those validations move to its Historical list. For a new HSM purchase, look for a FIPS 140-3 validation.
Why software keys are risky
A private key stored in a file, a configuration setting, an environment variable or a code repository is easy to copy. It ends up in backups, virtual machine images, container layers and laptops, and every copy is a new place to steal it from.
Memory scraping, stolen administrator credentials or a careless insider can take a software key without anyone noticing. There is often no reliable log of who used the key and when, so you may not know it was misused until a forged signature or a decrypted file turns up.
What HSM key protection gives you
- Non-exportable keys. Keys can be marked so they never leave the HSM in plain form.
- Strong access control. Roles, separation of duties and multi-person (M of N) approval for sensitive actions such as key backup or deletion.
- Audit trails. Logs of key use and administrative actions that are hard to tamper with.
- Dedicated performance. Hardware built for signing and encryption at high volume.
- Compliance. Many rules require hardware key protection.
Two examples come from the CA/Browser Forum. The TLS Baseline Requirements require publicly trusted CAs to protect their private keys in a device validated to at least FIPS 140-2 Level 3, FIPS 140-3 Level 3, or Common Criteria EAL 4 or higher. The Code Signing Baseline Requirements have required, since 1 June 2023, that subscribers’ code signing keys are generated, stored and used in a suitable hardware crypto module.
How applications talk to an HSM
PKCS#11
PKCS#11 is the most widely used standard interface for HSMs and is maintained by OASIS. CAs, TLS servers and signing tools use it. Each application needs the vendor’s library, slot and token settings, and its own session handling.
Java JCE, Microsoft CNG and OpenSSL providers
Java applications reach an HSM through a JCE provider, Windows applications through Microsoft CNG, and many tools through OpenSSL providers. These work well, but each platform is configured and upgraded separately.
KMIP and vendor REST APIs
KMIP, also an OASIS standard, covers key management between systems, such as creating, rotating and retiring keys. Many vendors also offer REST APIs, which are easy to call but tie your code to one vendor.
The problem at scale
Ten applications that each talk to the HSM directly means ten sets of libraries, credentials, failover rules and upgrade plans. Every team has to learn the cryptography again, and small mistakes add up.
What a crypto API does
A crypto API, sometimes called a crypto service layer, is one central service in front of one or more HSMs. Applications call it over REST with simple requests such as “sign this hash with key X” or “encrypt this with key Y”. The service handles the HSM sessions, and policy, authentication and audit live in one place.
It also makes change easier. When algorithms change centrally, applications do not need new code. That matters for the move to post-quantum cryptography, which we cover in our post-quantum migration plan for PKI.
Typical operations
- Encryption and decryption
- Digital signing and verification
- Hashing and message authentication (HMAC)
- Key wrapping and unwrapping
A common pattern: envelope encryption
With envelope encryption, data is encrypted with a data key, and the data key is then wrapped (encrypted) by a master key that never leaves the HSM. You store the wrapped data key next to the data. Rotating the master key means re-wrapping the small data keys, not re-encrypting all of your data at once.
Design tips for a crypto service
- Send hashes, not whole files, for signing. It is faster and keeps document content out of the service.
- Authenticate every caller with mutual TLS or OAuth tokens, and give each application access only to its own keys.
- Run HSMs in a high-availability pair or cluster, and test failover before you need it.
- Send audit logs to your SIEM, and never log plaintext, secrets or key material.
- Plan the whole key lifecycle from day one: generation, rotation, archival and destruction.
HSM vs cloud KMS vs software keystore
| Factor | On-premises HSM | Cloud KMS or cloud HSM | Software keystore |
|---|---|---|---|
| Key protection | Tamper-resistant hardware | Provider-run hardware, often HSM-backed | Files or memory on a server |
| Who controls the hardware | You | The cloud provider | You, on general-purpose servers |
| Compliance fit | Strong, when the model is validated for the use case | Depends on the service and its validation | Weak for high-assurance use |
| Cost model | Hardware purchase plus operations | Pay as you go | Lowest |
| Portability | High, through standard interfaces | Often tied to one provider | High |
| Best for | CAs, signing services, regulated workloads | Cloud-native workloads | Development and testing |
Software keystores still have a place. The DictaLabs CA product page, for example, lists software-based keystores for development, testing and non-HSM environments next to its HSM integrations.
How the DictaLabs crypto service fits
The DictaLabs cryptographic APIs follow the crypto service pattern described above. According to the product page, the service:
- is a REST-based service for key management, HSM integration and cryptographic operations, so applications do not handle keys directly;
- integrates with HSMs through PKCS#11, JCE and vendor-specific interfaces, supports on-premises and cloud HSMs, and supports high-availability and failover configurations with separation of duties;
- covers key generation, rotation, archival and destruction, with policy-based key usage and audit logging for all operations;
- deploys on-premises, in a private cloud or in a hybrid model, and works on its own or with DictaLabs CA, Certinium CLM and vScrawl.
If you run your own certificate authority, the DictaLabs CA HSM integrations are listed by name: PKCS#11 integration with Thales Luna, Entrust nShield, Utimaco CryptoServer, AWS CloudHSM, and Azure Key Vault or Managed HSM.
Next step
Choosing an HSM and designing the service around it is a decision you live with for years. The DictaLabs HSM architecture and key management consulting team helps with HSM selection and secure architecture design, or you can contact our crypto experts with your questions.
