AWS Key Management Service (KMS)

  1. Why keys need a home

  2. Encryption turns readable data into ciphertext by applying an algorithm with a secret called an encryption key.
  3. Anyone who obtains that encryption key can normally reverse the encryption, so protecting the key is as important as protecting the ciphertext.
  4. Protecting one key with another creates a hierarchy whose highest key still needs a trusted home.
  5. AWS Key Management Service is a managed AWS service that creates and controls keys used to encrypt or sign data.
  6. A KMS key is a logical AWS resource that combines an identifier, key material, lifecycle state, and access policy.
  7. AWS-generated KMS key material is protected in FIPS 140-3 Security Level 3 validated hardware security modules.
  8. A KMS key never leaves AWS KMS unencrypted, so software uses it through authenticated KMS API calls.
  9. Resting point Encryption only moves the protection problem onto a key. AWS KMS gives the top of that key hierarchy a managed boundary.

  10. The envelope pattern

  11. Applications usually encrypt bulk data locally with a short-lived symmetric key called a data key.
  12. Envelope encryption uses the data key for the payload and a KMS key for the data key.
  13. GenerateDataKey asks a symmetric encryption KMS key to create a new data key.
  14. The GenerateDataKey response contains a plaintext data key for immediate use plus an encrypted copy of the same key for storage.
  15. The application uses the plaintext data key with a cryptographic library to encrypt its plaintext locally.
  16. The application should remove the plaintext data key from memory as soon as that local encryption finishes.
  17. Keeping the encrypted data key beside the ciphertext forms a portable envelope that only an authorized KMS call can open.
    AWS KMS envelope encryption flow KMS returns a plaintext data key and an encrypted data key, the application encrypts data locally, and the encrypted data key is stored beside the ciphertext for later decryption AWS KMS GenerateDataKey Plaintext data key use, then discard Encrypted data key Local encryption Stored envelope ciphertext + encrypted data key To decrypt later encrypted data key → KMS Decrypt plaintext data key → local decryption
    KMS around the data key, local cryptography around the payload
  18. To decrypt later, the application sends the encrypted data key to Decrypt and receives plaintext key material only after authorization succeeds.
  19. The application uses that recovered data key to decrypt the ciphertext locally.
  20. Envelope encryption lets KMS handle a small data key instead of the bulk payload.
  21. Each request to recover a data key becomes a central checkpoint for control and audit.
  22. Resting point The durable KMS key wraps disposable data keys. Applications keep high-volume encryption local while KMS governs every unwrap.

  23. Who may use the boundary

  24. Every KMS request is made by an AWS identity such as an IAM role, user, or AWS service.
  25. Every KMS key has exactly one key policy that acts as its primary resource policy.
  26. An IAM allow becomes effective only when the key policy permits the account to delegate access through IAM.
  27. A grant supplies temporary or scoped KMS-key permissions without rewriting the key policy.
  28. Integrated AWS services commonly use grants to obtain narrowly scoped permission to use a key on a customer's behalf.
  29. An encryption context is an optional set of non-secret key-value pairs that symmetric encryption operations bind to ciphertext as additional authenticated data.
  30. Decryption fails unless the caller supplies the same encryption context that protected the ciphertext.
  31. Policies and grants can require particular encryption-context values to restrict a key to a defined workload.
  32. Encryption context must never contain secrets because AWS KMS records it in plaintext in AWS CloudTrail.
  33. By default, CloudTrail records KMS management and cryptographic API calls.
  34. AWS KMS omits sensitive fields such as plaintext and cryptographic responses from CloudTrail records.
  35. An alias such as alias/orders is a movable friendly name for a KMS key rather than the key material itself.
  36. Resting point KMS is a policy enforcement point as much as a cryptographic one. An identity must be allowed to use a specific key in a specific context, and the resulting API activity is auditable.

  37. Choosing and operating keys

  38. A KMS key's type determines the cryptographic job that AWS KMS can perform with it.
    1. A symmetric encryption KMS key performs encryption and decryption with secret key material that never leaves KMS unencrypted.
    2. An asymmetric KMS key keeps its private key protected inside KMS while allowing its public key to be downloaded.
    3. An HMAC KMS key generates and verifies message authentication codes for integrity and authenticity.
  39. GenerateDataKey specifically requires a symmetric encryption KMS key.
  40. The party that manages a key determines how much lifecycle control and visibility the customer receives.
    1. A customer managed key gives the customer control over its policy and lifecycle.
    2. An AWS managed key lives in the customer's account but can be used only through its owning AWS service.
    3. An AWS owned key stays in an AWS service account with no customer-visible policy or usage audit trail.
  41. A standard KMS key is a Regional resource whose ARN includes its AWS Region and owning account.
  42. Related multi-Region keys share interoperable key material across selected Regions.
  43. Rotating a KMS key creates new backing key material for future protection operations.
  44. Rotation leaves the logical KMS key's identifier unchanged.
  45. For AWS-generated keys, AWS KMS retains older backing material so the rotated key can decrypt ciphertext created before rotation.
  46. KMS key rotation does not re-encrypt existing data or rotate the data keys that already protect it.
  47. AWS KMS is therefore a controlled cryptographic boundary where durable top-level keys stay protected while authorized and logged calls govern the keys that encrypt application data.
  48. Resting point KMS does not replace application encryption. It makes the hardest key in the hierarchy durable, governable, and auditable.