KMS in Practice

0. When KMS Actually Becomes Necessary

Not every encryption problem requires a KMS.

KMS becomes necessary when encryption is no longer a purely local concern, but a shared security responsibility across teams, services, or environments.

Typical signals include:

• Multiple services need to encrypt or decrypt sensitive data consistently.
• Keys must be rotated, revoked, or audited without redeploying applications.
• Security boundaries exist between operators, developers, and infrastructure.

At this point, encryption stops being an implementation detail and becomes a governance problem. KMS is designed precisely for this transition: moving from cryptographic correctness to operational control.

1. Authentication: Identity vs. Secrets

To interact with a KMS, you need a “key to the door”—commonly an AKSK (Access Key / Secret Key). However, a critical design principle is to clearly separate identity from encryption resources.

• The Danger of Persistent Keys: Avoid long‑term AKSK, especially those belonging to root or administrator accounts. If a high‑privilege AKSK is leaked, the “blast radius” includes data exfiltration and key deletion.
• The Circular Dependency: AKSKs are identity credentials. They cannot be protected by the KMS they are meant to access. This makes long-term secrets fundamentally fragile.
• Best Practice: Always use temporary credentials by binding roles to compute resources (CVM/EC2, Lambda/SCF). No AKSK should ever appear in source code, configuration files, or CI logs.

2. Key Hierarchy: The Chain of Trust

KMS systems operate as a layered defense, ensuring that the most critical key material never leaves the Hardware Security Module (HSM).

1. Domain Key (Root Key): The ultimate root of trust for the KMS cluster. It exists only in HSM memory and is strictly non-exportable.
2. Customer Master Key (CMK): The primary resource you manage.
   • Symmetric CMKs: These are the workhorses for most cloud operations. They are non-exportable and serve as the parent for DEKs.
   • Asymmetric CMKs: Used for public-key cryptography. Only the public key is exportable; the private key remains sealed in the HSM.
3. Data Encryption Keys (DEKs): Generated by the HSM and protected (wrapped) by a Symmetric CMK. These are used for the actual encryption of data at the application level.

A key hierarchy is not merely a structural convenience — it is an explicit declaration of trust boundaries.

• Customer Master Keys (CMKs) represent policy and authority.
• Data Encryption Keys (DEKs) represent usage and exposure.

CMKs should rarely be touched and even more rarely rotated by application logic.

DEKs, on the other hand, are designed to be created, used, and discarded at scale.

This separation ensures that compromising a DEK never escalates into control over the system, while compromising a CMK remains an operational — not cryptographic — failure.

3. Operations: Envelope Encryption & Memory Hygiene

Choosing the correct encryption pattern is essential for both security and performance.

Envelope Encryption (The Gold Standard)

In typical envelope encryption, the workflow can be summarized as:

1. KMS generates a data encryption key (DEK) under a customer master key (CMK).
2. The application uses the plaintext DEK locally to encrypt or decrypt data.
3. Only the wrapped (encrypted) DEK is stored alongside the encrypted data, while the plaintext DEK is immediately discarded.

In practice, this is implemented via API calls such as GenerateDataKey and Decrypt.

The former returns both a plaintext DEK (for local use) and a ciphertext DEK (for persistence), and the latter unwraps a stored ciphertext DEK back into plaintext for decryption operations.

This pattern ensures high-throughput local crypto performance while keeping long-term key material safely within the KMS.

1

aws kms generate-data-key --key-id arn:aws:kms:ap-northeast-1:353472442111:key/5cfaf9cd-6159-4312-9449-7c57f075e628 --key-spec AES_256

1

aws kms generate-data-key-without-plaintext --key-id arn:aws:kms:ap-northeast-1:353472442111:key/5cfaf9cd-6159-4312-9449-7c57f075e628 --key-spec AES_256

1

aws kms decrypt --ciphertext-blob AQIDAHiY16Xgeax+CvNSL0EmK/0oF7TEiJgrSNe4loO9B2RpQAEMRf3M74ixg3K4jF49Sub+AAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMuJLdAayD0WaXttBtAgEQgDuGdKp9j/yYAU7e4YNubeMXXv9voULjr87IHYkX3x0hnQcoC6Bu6gtiZJ6v4+mPUFJCmFrhPrPdJ0xmTg==

For databases or large files, use Envelope Encryption.

Why not call Encrypt/Decrypt on data directly?

Many KMS services limit direct encrypt/decrypt payload sizes — envelope encryption scales better because the DEK is used locally on arbitrary large data sets, while the CMK enforces master key security and policy control without becoming a performance bottleneck.

This involves using a CMK to wrap a DEK.

• Workflow: Use a CMK to generate a DEK -> Encrypt data locally with the plaintext DEK -> Store the data alongside the DEK Ciphertext.
• Memory Hygiene (Strict Enforcement): The Plaintext DEK must be treated as highly ephemeral.
  • It should exist only in volatile memory during the cryptographic operation.
  • Wipe-on-completion: Once the data is encrypted/decrypted, the plaintext DEK must be purged from memory.
  • Only the Ciphertext DEK should ever be written to persistent storage (disk, databases, or configuration files).

Memory hygiene is often discussed as a best practice, but its real value lies in failure containment.

Systems do not fail gracefully — they crash, dump memory, get paused, or get inspected. When plaintext keys linger longer than necessary, these failure modes turn into data exfiltration vectors.

Treat plaintext DEKs as toxic assets: they should exist only at the moment of use and disappear immediately afterward.

If a system design cannot clearly answer “where does the plaintext live, and for how long?”, it is already unsafe.

Encryption Context

Always use the Encryption Context as a cryptographic binding.

It ensures that a ciphertext cannot be decrypted if it is moved to a different context (e.g., trying to use a “User Profile” record).

Encryption Context is a cryptographic binding and should be treated as part of your key’s identity.

It ensures that ciphertext cannot be decrypted if moved outside its intended logical domain.

1

aws kms generate-data-key --key-id arn:aws:kms:ap-northeast-1:353472442111:key/5cfaf9cd-6159-4312-9449-7c57f075e628 --key-spec AES_256 --encryption-context purpose=user-profile,user_id=bowen

1

aws kms decrypt --ciphertext-blob AQIDAHiY16Xgeax+CvNSL0EmK/0oF7TEiJgrSNe4loO9B2RpQAHFy2fI1zgEoDIvo95oXrjlAAAAfjB8BgkqhkiG9w0BBwagbzBtAgEAMGgGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMmyoTzBsfbtQHHNFmAgEQgDstlUbfpbk2cxOccZg8ktUY+Bmbz5W865lgCWs27IW8awa4s5VOys+qpxcQmT2c73/7jvxpK5MfFfwnfA== --encryption-context '{"purpose":"user-profile","user_id":"bowen"}'

Enhanced Transport Security

For high-assurance environments, some KMS Decrypt APIs allow you to provide a public key for re-encryption. While RSA-2048 is a common standard, modern systems support higher entropy or regional standards such as RSA-3072 or SM2. This ensures the plaintext is only viewable by the final client.

SM2-Re-Encryption

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

❯ tmp_sm2_pub=`cat tmp_sm2_pub.pem`

❯ echo $tmp_sm2_pub
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoEcz1UBgi0DQgAEf9V1uglF/RYBxJxK+PRwA8dauBPi
T/UjfNB5eIRG/gdkq3+rbYVabXkG1lQIAHOiHlTxLD+CkBJFaF3mRCGO7w==
-----END PUBLIC KEY-----

❯ tccli kms Decrypt --CiphertextBlob ZBwHIFlarNJgM+NGhpdTb1DV5eLXeOtABtg7AArzgfogCwS5xFVAPmT/0RZqSFJi824xVoqR7LYugDwNy0atvA==-k-fKVP3WIlGpg8m9LMW4jEkQ==-k-lMRqPtNqVpzYewuqKW8dLIsZqm0mO5hey8upEzqiK5ntqm8vLeMJ9HxOy+OGPW+S1hNuwaYu2l2qJ9qXTtmB9Rq0xtk= --EncryptionPublicKey $tmp_sm2_pub --EncryptionAlgorithm SM2_C1C3C2_ASN1
{
    "KeyId": "7bab23ea-1a0e-11ee-a405-52540078f78b",
    "Plaintext": "MIGIAiBNGgkNbbDGgWRZe1wj8mutmMwX6eWnJq9J2t4bmwet8AIgDQg/Vkzq24M9x8P+Eww8gGKvtQWFNptGOup9iVMyaMcEINJrqMUdMHBn4GvutvY4D63Jk4r1RvFbjCZZUafUq0ymBCBoIpBzK7XxFeulLmsyDgBUBX2uXxXCfLj1s5D4NRGXdQ==",
    "RequestId": "6d3e582a-53af-4b7c-ad11-497e66aafcf0"
}

RSA2048-Re-Encryption

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

❯ tmp_rsa2048_pub=`cat tmp_rsa2048_pub.pem`

❯ echo $tmp_rsa2048_pub
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsM7llkzuMC6SGj+GamU1
nSljxWULXLvg0sSaxEy35L58QZWQYpV0+8Gu5jKIUrKmgXu8oBqQ6KPgpJxwZvy3
91OOcZN5Qqb/zEa3N5f3YDeFSudDuV4l0bufFbHa4hTxpqwBQY0p2XxjRSifkErP
YtCaz2oM7XwCzFpi43EASNmqr7/mHgUM5XD4qo7ttC9f20MutCmRkdTMOQM0aAvb
HYXz7P93fgm11+e7xCqhzF/+quC6rEjc8ko4+8kdMNDHVEJZxKMbreYLZ2Og5/au
Af2wKjIXBoTDzevkJQJp3e99DEcSXJbEakJ2XfykJuYl2SFUb2bBBFYzZOVeN0Gg
lwIDAQAB
-----END PUBLIC KEY-----

❯ tccli kms Decrypt --CiphertextBlob ZBwHIFlarNJgM+NGhpdTb1DV5eLXeOtABtg7AArzgfogCwS5xFVAPmT/0RZqSFJi824xVoqR7LYugDwNy0atvA==-k-fKVP3WIlGpg8m9LMW4jEkQ==-k-lMRqPtNqVpzYewuqKW8dLIsZqm0mO5hey8upEzqiK5ntqm8vLeMJ9HxOy+OGPW+S1hNuwaYu2l2qJ9qXTtmB9Rq0xtk= --EncryptionPublicKey $tmp_rsa2048_pub --EncryptionAlgorithm RSAES_OAEP_SHA_256
{
    "KeyId": "7bab23ea-1a0e-11ee-a405-52540078f78b",
    "Plaintext": "RKv4/TqnCHRRpFB2xT5SOJu6ZQCpwGgId1Ucyns8krlGVbcMT8gUpqK8/C3XWXmKmE9uJ2+jnRA3L8/jrv57+Vgll0WuYRsN0Bf0kEjHcmtEr1anA4nrcBJjDXLaxAbsFPcXPZr9oBYzXy0A7eB60cTWYBRjuCsabZtDxft0K/P8iESbCTaYSHCs3NyUu8aANYDEY92xQtSxsC6QF4OsNNPxiNdAdQiVEizKe7c453MS5HXVtQVNeLCP+EAkmTXE3bPQr1g9Bp3vKpqjoE/dMs2SbF8WZYBwDRguYRbvwbn+v0PVnpZpa6VU72DMgdLBixrFq8k+nr0TjDuphNRPBg==",
    "RequestId": "c88ca438-c1ea-4f20-97b7-6cb155f3abe0"
}

4. Advanced Security & Transport

Key rotation: Rotation is often misunderstood as a disruptive operation.In a well-designed KMS architecture, it is neither exceptional nor dangerous.

Rotation improves security by limiting the lifetime of cryptographic material, while preserving system stability through indirection.Applications do not depend on a specific key version — they depend on a logical key identity managed by the KMS.

New encryption operations transparently use the latest key version, while existing ciphertext continues to be decryptable using previous versions.This allows systems to adopt stronger keys over time without requiring data re-encryption or application changes.

From an operational perspective, rotation is a control-plane action, not a data-plane event. When key hierarchy and envelope encryption are properly implemented, rotation becomes a routine security maintenance task rather than a risky system change.

Native Service Integration: Leverage Transparent Data Encryption (TDE) for S3/COS and RDS/CDB to offload key management to the provider’s internal backbone.

5. Secrets Manager: The Identity Boundary

While KMS manages keys, a Secrets Manager manages credentials (passwords, tokens).

• Built on KMS: Every secret is encrypted using a KMS CMK.
• Lifecycle Automation: Secrets Manager can rotate cloud database passwords automatically.
• The Rotation Limit: Note that Secrets Manager cannot rotate the primary AKSK used to access the Secrets Manager itself. This remains a “root of trust” identity issue that must be handled via IAM Role-based temporary credentials to avoid the circular dependency mentioned in Section 1.

The distinction between KMS and Secrets Manager is not about encryption algorithms, but about access patterns.

• KMS protects keys that protect other data.
• Secrets Manager protects data that applications consume directly.

When applications start requesting raw secrets from KMS, or when Secrets Manager begins handling high-frequency cryptographic operations, boundaries are being crossed.

A clean separation keeps KMS focused on authority and control, while Secrets Manager handles distribution and lifecycle.

Closing Thoughts

In practice, KMS is less about cryptography and more about discipline.

It enforces boundaries:

• between identity and secrets
• between authority and usage
• between plaintext and ciphertext

When used correctly, KMS does not make systems faster or simpler — it makes them harder to misuse. And that is often the most important property of a secure system.

Post-quantum cryptography is often discussed in terms of algorithms, key sizes, and timelines.

In practice, its impact on system design is more subtle.While PQC changes how keys are generated and used, it does not fundamentally change why KMS exists.

The core responsibilities of a KMS remain the same:

• Isolating long-term trust anchors from application logic
• Enforcing access control and auditability
• Limiting the exposure of plaintext key material

Whether a key is classical or post-quantum, these boundaries continue to matter.