Visual overview
IAM determines who may request key operations, KMS enforces key policy and cryptography, and CloudTrail records KMS API activity including non-secret encryption context.
Technical reference
KMS is easiest to reason about as two layers: cryptographic mechanism and authorization to invoke that mechanism.
GenerateDataKey can return a plaintext data key for local encryption and a CiphertextBlob containing the same data key encrypted under the KMS key.
The common KMS symmetric encryption key spec is used by many AWS service integrations; asymmetric specs expose different algorithm choices.
The KMS Encrypt API is intended for small plaintext payloads; use envelope encryption for larger application data.
Every KMS key has exactly one key policy; IAM policies and grants operate within the access model the key policy permits.
A grant can authorize selected cryptographic operations and can use EncryptionContextEquals or EncryptionContextSubset constraints.
For symmetric encryption operations, context is AAD and can be referenced by policy conditions; matching context is required for decryption.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
KMS separates key control from bulk data encryption
AWS Key Management Service (AWS KMS) creates and controls cryptographic KMS keys used directly by KMS APIs and by integrated AWS services. The key material behind a KMS key is protected inside the KMS security boundary; applications identify the key through its ARN, key ID, or alias rather than retrieving symmetric key material from an ordinary customer-managed KMS key. Customer managed keys give customers policy and lifecycle controls that AWS managed or AWS owned key models expose differently.
For large data, the important pattern is envelope encryption. A short-lived data key encrypts the application data locally or inside an integrated service. That data key is then encrypted under a KMS key. The ciphertext can store the encrypted data key next to the encrypted payload because the encrypted data key is not useful until an authorized Decrypt operation unwraps it. This avoids sending every byte of a large object through the KMS Encrypt API.
Encryption context binds non-secret metadata to cryptographic operations
For symmetric encryption KMS keys, an encryption context is an optional set of non-secret key/value pairs. KMS uses it as additional authenticated data (AAD). If encryption used a particular context, the required matching context must be supplied for decryption. Policies and grant constraints can also test the encryption context, which makes it useful for binding permission to an application, tenant, or resource identifier without putting that identifier inside the ciphertext format.
Encryption context is logged in AWS CloudTrail and therefore must not contain confidential data. Cryptographic key type also matters. KMS supports symmetric encryption keys for common AWS-service encryption and asymmetric key types for operations such as RSA encryption/signing, elliptic-curve signing/key agreement, and other supported algorithms. KeyUsage determines whether a given asymmetric key is for encryption/decryption, signing/verification, MAC operations, or key agreement as applicable; it is not a general-purpose key that performs every operation.
Key takeaways
- 01
Envelope encryption uses data keys for bulk data and a KMS key to protect those data keys.
- 02
Every KMS key has a key policy; IAM permissions only work within the access model permitted by that policy.
- 03
KMS grants can delegate selected key operations without rewriting the key policy for every temporary use.
- 04
Encryption context is authenticated, policy-addressable metadata and must not contain secrets because it is logged.
- 05
Key spec and KeyUsage determine which cryptographic operations and algorithms a KMS key supports.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.