Key Management / Architecture
HSM & KMS
An HSM is a cryptographic module and protection boundary; a KMS is a wider management system for keys, metadata, policy, authorization, and lifecycle operations. A KMS may use HSMs, but the terms are not interchangeable. This page explains that boundary, how FIPS 140-3 validation should be read, how PKCS #11 expresses key attributes, and how envelope encryption limits direct use of high-value wrapping keys.
HSMs protect key operations; KMSs manage the wider lifecycle
A Hardware Security Module (HSM) is hardware that protects sensitive security parameters and performs cryptographic operations within a defined module boundary. A Key Management Service (KMS) coordinates the policies, procedures, roles, metadata, interfaces, and components used to manage keys. The KMS can place high-value keys in an HSM while keeping policy and workflow logic outside that module.
| Boundary | HSM | KMS |
|---|---|---|
| Primary concern | Protect key material and execute cryptographic operations | Govern keys and bound metadata across their lifecycle |
| Typical controls | Module authentication, sensitive-parameter handling, physical protection, self-tests | Inventory, state transitions, authorization, rotation, recovery, audit, and incident workflow |
| Relationship | Can operate alone or as a KMS component | May use software modules, HSMs, or external key services |
| Assurance question | What exact module, version, environment, mode, and certificate were evaluated? | Does the complete service enforce the required policy and operational controls? |
FIPS 140-3 validates an exact cryptographic module
FIPS 140-3 defines four qualitative security levels across eleven requirement areas, including module interfaces, roles and authentication, physical security, sensitive security parameter management, self-tests, and lifecycle assurance. It does not validate an algorithm by itself or automatically validate every product or cloud service that embeds a validated module.
| Validation question | Correct interpretation | Check before relying on the claim |
|---|---|---|
| What was evaluated? | A specific cryptographic module implementation, not a product category. | Module name, version or part number, vendor, and certificate number. |
| Where is it valid? | Software and firmware modules are evaluated in stated operational environments. | The deployed environment and configuration match the certificate and security policy. |
| Which behavior is covered? | A module may support approved and non-approved modes. | The service operates in the approved mode and observes every certificate caveat. |
| Is the whole application validated? | Correct use of an embedded validated module is outside the module validation boundary. | The application routes all claimed cryptographic services through the validated module and handles keys safely outside it. |
| Is the validation current? | Active, historical, and revoked certificates have different evidentiary value. | Current CMVP status, sunset date, caveats, and applicable transition rules. |
The Cryptographic Module Validation Program (CMVP) FAQ is the decision point for interpreting a vendor claim. A product name or a claimed level is not enough.
PKCS #11 attributes constrain API behavior
PKCS #11 exposes key-object attributes that a conforming token uses to control API operations. Non-extractability reduces the ordinary export path, but it is not proof against implementation flaws, privileged code outside the interface, invasive attacks, or side channels. Whether raw key bytes enter host memory depends on how the key was generated, imported, restored, and used.
PKCS #11 core attributes
| PKCS #11 attribute | Meaning when CK_TRUE |
Evidence boundary |
|---|---|---|
CKA_SENSITIVE |
The object is sensitive; secret components cannot be revealed through the PKCS #11 interface in plaintext. | Describes current API treatment. |
CKA_EXTRACTABLE |
Required for the key to be wrapped; CK_TRUE is necessary but not sufficient — the key type, the requested mechanism, token policy, and other attribute constraints can still disallow it. When CK_FALSE, PKCS #11 wrapping is always disallowed. |
Governs wrapping through the token interface, not every possible compromise path. |
CKA_ALWAYS_SENSITIVE |
The key has always had CKA_SENSITIVE=CK_TRUE. |
Records attribute history defined by PKCS #11. |
CKA_NEVER_EXTRACTABLE |
The key has never had CKA_EXTRACTABLE=CK_TRUE. |
Does not independently prove that the key was never exposed by another mechanism. |
Envelope encryption separates bulk data from high-value keys
Envelope encryption uses a short-lived or narrowly scoped data-encryption key (DEK) for the payload and a key-encryption key (KEK) to wrap the DEK. This pattern keeps bulk cryptography local to the workload and limits the KMS or HSM operation to a small key object.
A KMS coordinates the KEK's use, but the KEK itself lives in a separate cryptographic protection boundary — an HSM, a software module, or an external key service, as described above — not the KMS as a whole.
- Generate a DEK with an approved random-bit generator or ask the KMS to generate one.
- Encrypt the payload with an authenticated-encryption mode such as AES-GCM and a nonce that is unique for that DEK.
- Bind immutable payload context—such as tenant, object identifier, content algorithm, and envelope-format version—as authenticated additional data (AAD) where the protocol supports it.
- Wrap the DEK under a KEK using a specified key-wrapping mechanism such as an approved method in NIST SP 800-38F.
- Store the ciphertext, authentication tag, nonce, encrypted DEK, KEK identifier and version, algorithm identifiers, authenticated payload context, and envelope-format metadata together.
- Minimize the lifetime and number of plaintext DEK copies in memory. A cache trades KMS availability and latency for a larger exposure window, so bound it by time, use count, data volume, and tenant or security context.
AES-GCM authenticates its AAD, so changing payload AAD invalidates the authentication tag. Mutable wrapping metadata—such as KEK identifier, KEK material version, wrapping algorithm, and encrypted DEK—should therefore not be placed in the payload AAD when the design promises rewrapping without changing the payload ciphertext. Protect that metadata with a separately updateable authenticated-envelope mechanism, such as a provider wrapping operation that binds an encryption context or a signed or MAC-protected envelope header. If a design instead authenticates wrapping metadata as payload AAD, changing it requires recomputing payload authentication and is not a rewrap-only operation.
Changing the KEK can mean rewrapping the encrypted DEK without re-encrypting the bulk ciphertext when the envelope’s integrity construction supports that update. Changing the DEK requires decrypting and re-encrypting the bulk data. If the referenced KEK version is disabled, unavailable, or destroyed, the encrypted DEK cannot be unwrapped; destruction therefore requires dependency checks and a tested recovery decision.
Client-Side Envelope Encryption Simulator (DEK / KEK)
This browser-only logic simulation generates a local AES-KW key and an extractable AES-GCM DEK, then wraps the DEK and encrypts the payload. It does not call a KMS, use an HSM, or prove hardware-backed storage. This implementation sets the DEK as extractable so Web Crypto can wrap it.
Custody labels describe different control boundaries
Provider terminology varies, so architecture decisions should be based on who generates the key material, where plaintext key material can exist, who authorizes operations, who can disable or destroy the key, and what happens when an external dependency is unavailable.
| Custody model | Operational boundary | Control retained by the customer | Important limitation |
|---|---|---|---|
| Provider-managed key | Provider creates and operates the key for an integrated service. | Usually little direct policy or lifecycle control. | Exact isolation, rotation, deletion, and audit behavior is service-specific. |
| Customer-managed key (CMEK) | Customer configures a key in the provider KMS and authorizes a service to use it. | Policy, service grants, disablement, and often rotation scheduling. | Does not by itself mean exclusive custody or prove a compliance outcome. |
| Bring your own key (BYOK) | Key material originates outside the provider and is imported under a documented wrapping process. | Generation provenance and, if retained, an external recovery copy. | The imported material is still available to the destination service’s cryptographic boundary during use. |
| Hold your own key (HYOK) or external KMS | Key operations or release authorization depend on a customer-controlled external system. | Stronger operational control over availability and authorization. | Adds network, latency, quota, failover, and emergency-access dependencies. |
Browser non-extractability and PKCS #11 mapping simulation
Web Crypto Non-Extractability Simulator
This demonstration creates a browser CryptoKey with extractable: false, shows a conceptual mapping to PKCS #11 attributes, and signs a test payload. It does not run SoftHSM2 or PKCS #11, and Web Crypto does not guarantee that the key is hardware-backed.
An HSM protects cryptographic operations inside a module boundary; a KMS governs keys and metadata across a wider operational lifecycle. Verify the exact module certificate and deployment context, treat non-extractability as a bounded API property, and preserve every dependency needed to unwrap an encrypted DEK.
Primary references
- NIST FIPS 140-3: Security Requirements for Cryptographic Modules — verified the validation scope, four-level model, and eleven requirement areas.
- NIST CMVP FAQ — verified certificate, version, operational-environment, approved-mode, and embedded-module caveats.
- NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management — verified that key management extends beyond storage to lifecycle protection and operational controls.
- NIST SP 800-130: A Framework for Designing Cryptographic Key Management Systems — verified the KMS boundary of policies, procedures, components, devices, keys, and metadata.
- NIST SP 800-133 Rev. 2: Recommendation for Cryptographic Key Generation — verified key-generation and random-bit-generator requirements in the NIST federal profile.
- NIST SP 800-38D: Galois/Counter Mode — verified that AES-GCM authenticates additional data and that changing authenticated context invalidates tag verification.
- NIST SP 800-38F: Recommendation for Block Cipher Modes of Operation—Methods for Key Wrapping — verified approved AES key-wrapping methods.
- OASIS PKCS #11 v3.1 — verified the exact meanings of sensitive and extractability attributes.
- OASIS KMIP v2.1 — verified the broader managed-object lifecycle and metadata model used for interoperable key management.