What is a key management system?
A key management system (KMS) is a central service that looks after cryptographic keys for many applications at once. Instead of every server keeping its own keys in files, applications ask the KMS to create keys, use them and retire them, and the KMS enforces who may do what and records every operation. Cloud platforms offer this as a managed service, such as AWS KMS, Azure Key Vault and Google Cloud KMS. Enterprise key managers do the same for on-premises storage arrays, databases, tape libraries and backup systems, often through the OASIS Key Management Interoperability Protocol (KMIP).
What a KMS does across the key life cycle
- Generation: creates keys from a strong random source, often inside hardware security modules, so key material never sits in an application's configuration files.
- Access control: key policies decide which users, roles and services may encrypt, decrypt, sign or administer each key.
- Rotation: replaces key material on a schedule while keeping older versions available to decrypt data written under them.
- Auditing: logs every request with the caller's identity and the time, so unusual use stands out.
- Destruction: deletes keys deliberately, often after a waiting period, because data encrypted under a destroyed key can't be recovered.
NIST SP 800-57 is the usual reference for these stages, and most organizational key management policies are built on it.
Envelope encryption in practice
A KMS rarely encrypts bulk data itself. Applications use envelope encryption: they ask the KMS for a fresh data key, encrypt locally with it, and keep a wrapped copy of that data key, encrypted under a master key that never leaves the KMS. With the AWS command-line tools the request looks like this:
aws kms generate-data-key --key-id alias/payroll --key-spec AES_256
The response carries the same 256-bit key in two forms. Plaintext is what the application uses to encrypt a file before erasing it from memory, and CiphertextBlob is what it saves beside the encrypted file. To read the file later, the application sends the blob back with a decrypt request, which succeeds only if the caller's role is allowed to use the master key and which lands in the audit log. An attacker who steals the file and the blob together still gets nothing without permission in the KMS.
Separation of duties and customer-managed keys
Because keys live apart from the data, a KMS lets an organization split control. A storage administrator can manage encrypted volumes without being able to decrypt them, and a key administrator can manage policies without touching the data. In the cloud, customer-managed keys put the master key under the customer's own policies, bring your own key (BYOK) lets the customer generate the material and import it, and some providers support external key stores that keep the key in the customer's own HSM. Disabling a customer-managed key cuts off every object encrypted under it, which is a powerful control and a serious availability risk if done by mistake. AWS KMS, for example, makes key deletion wait 7 to 30 days so an error can be caught.
KMS vs. HSM vs. secrets manager vs. TPM
| Tool | What it is | Typical job |
|---|---|---|
| HSM | Tamper-resistant hardware that stores and uses keys | Guards the most valuable keys; often the engine inside a KMS |
| KMS | Management service and policy layer | Creates, rotates, authorizes and logs keys for many applications |
| Secrets manager | Vault for passwords, API keys and tokens | Hands credentials to applications at run time |
| TPM | Chip in a single device | Device identity, disk encryption keys, boot measurements |
Key management system on the CompTIA Security+ exam
SY0-801 no longer names key management systems as a cryptographic tool. Generating, storing, rotating and destroying keys is still taught with the other cryptographic tools under objective 1.3, the cryptographic solutions objective. Poor key handling also counts as a cryptographic vulnerability under objective 2.4: one key copied to many servers, keys stored beside the data they protect, or keys that are never rotated. Wording such as "centrally manage and rotate encryption keys for many cloud services", "log every use of a key" or "keep key administrators separate from data administrators" points to a KMS. Distractors include a TPM, which protects one device, a secrets manager, which stores credentials rather than managing encryption keys, and a stronger algorithm, which doesn't help when the key itself is mishandled.