What is a hardware security module?
A hardware security module is dedicated hardware that holds cryptographic keys and performs operations with them without ever releasing them. An application asks the module to sign or to decrypt something, and the key material remains inside a tamper-resistant boundary. Compromising the application therefore does not yield the key.
Also called: HSM
Why the location of a key decides who is in control
The question comes from a bank's security architecture review, and it is rarely about encryption strength. They want to know who can read the data if the vendor is compelled to produce it, which is a question about where the keys live rather than which algorithm is in use. A customer-managed key held inside the customer's own module gives the enterprise a lever it can pull unilaterally. That lever is what makes the rest of the security discussion short.
- Key custody determines who can decrypt data, independently of who stores it.
- An enterprise holding its own keys can revoke access without the vendor's cooperation.
- Operations performed inside the module leave a record the enterprise controls.
- Several regimes require key custody to be demonstrable rather than contractual.
How a hardware security module works
- Keys are generated inside the module and never exported in usable form.
- Applications authenticate to the module and request an operation on a named key.
- The module performs the operation and returns only the result.
- Every operation is logged with the identity that requested it.
- Key rotation is scheduled, with each previous key retained for stored data.
- Revocation renders the protected data unreadable, which is tested deliberately.
How a hardware security module is evaluated
A module is assessed on custody and on what happens when it is unavailable. Examine the following against the deployment as configured:
- certification level of the module against the applicable standard
- proportion of keys generated inside the module rather than imported
- completeness of the operation log, including failed authentications
- recovery time when the primary module is unreachable
- elapsed time from a revocation request to data becoming unreadable
Limitations, risks and common failure modes
- Keys are generated elsewhere and imported, which defeats the custody argument.
- Application credentials to the module are stored beside the application itself.
- Revocation is never tested, so nobody knows what it actually disables.
- A single module without a replica makes the whole service dependent on one device.