Key Management Service (KMS)

Automates the creation, rotation, and revocation of cryptographic material across their entire lifecycle. A KMS enforces policies that transition keys through states: pending import, enabled, disabled, and scheduled for destruction. This eliminates the risk of hard-coded secrets in source code or configuration files. Key metadata, such as creation date and algorithm type, is tracked immutably.

• Automated Rotation: Keys can be rotated annually or on-demand without application downtime.
• Versioning: Maintains multiple versions of a key simultaneously to support seamless decryption of legacy data.
• Import Capability: Supports bring-your-own-key (BYOK) workflows for organizations requiring proprietary key generation.

Generates true random entropy using FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs). Unlike software-based pseudo-random number generators, a KMS leverages physical silicon processes to create non-deterministic keys. The private key material never leaves the HSM boundary in plaintext. Operations such as encrypt, decrypt, and sign are executed inside the hardware module, returning only the result.

• FIPS 140-2 Level 3: Physical tamper-evident seals and automatic key zeroization on intrusion.
• Entropy Source: Uses ring oscillators or quantum phenomena for true randomness.
• Non-Exportable Keys: Private keys are bound to the hardware that generated them.

Implements a hierarchical key model to separate data protection from key protection. A Customer Master Key (CMK) stored in the KMS encrypts Data Encryption Keys (DEKs). The DEK encrypts the actual data. The encrypted DEK is stored alongside the ciphertext. This architecture allows high-throughput data encryption without hitting KMS rate limits, as the CMK is only used for the lightweight operation of wrapping the DEK.

• CMK: Resides in KMS; never leaves the service.
• DEK: Generated locally; used for bulk AES-256-GCM encryption.
• Ciphertext Blob: Contains the encrypted DEK and metadata for decryption routing.

Integrates with identity and access management systems to define fine-grained permissions on who can administer keys versus who can use them. Every API call—Encrypt, Decrypt, CreateKey, ScheduleKeyDeletion—is logged to a tamper-proof audit trail. This provides cryptographic proof of data access for compliance frameworks like HIPAA and PCI-DSS.

• Key Policy: A resource-based JSON document defining principals and allowed actions.
• Grants: Temporary, programmatic delegation of key usage to specific AWS services.
• CloudTrail Integration: Logs source IP, identity, and timestamp of every cryptographic operation.

Manages both symmetric keys for bulk encryption and asymmetric key pairs (RSA, ECC) for digital signing and public-key cryptography. Symmetric keys are used for envelope encryption, while asymmetric keys enable use cases where the encrypting party cannot be trusted with decryption capability. The private key of an asymmetric pair remains permanently within the KMS.

• Symmetric: Single key for encrypt/decrypt; ideal for data at rest.
• Asymmetric: Separate public and private keys; supports signing and verification.
• ECC P-256: Elliptic curve cryptography for compact signatures and low compute overhead.

Creates a primary key and automatically replicates it to multiple geographic regions as a multi-region key. Each replica shares the same key ID and cryptographic material but acts as a fully independent regional resource. This enables disaster recovery, global client-side encryption, and active-active database encryption without cross-region API calls to a single key endpoint.

• Active-Active: Applications encrypt data in any region using the local replica.
• Consistent ARN: The key identifier remains identical across all replicas.
• Failover: Seamless decryption of data replicated to a secondary region.

The automated process of generating a new version of a cryptographic key and retiring the old one for encryption operations while retaining it for decryption. KMS makes this a one-click policy.

• Automatic rotation typically occurs annually (e.g., AWS KMS)
• On-demand rotation is triggered manually after a security incident
• Old key versions remain available to decrypt previously encrypted ciphertexts
• Rotation does not re-encrypt existing data; it only changes the key used for new operations
• Reduces the blast radius of a potential key compromise

A TEE-specific operation that encrypts data and binds it to the exact enclave identity and platform that generated it. Unlike KMS-managed keys, sealed data can only be decrypted by the same enclave on the same hardware.

• Binds data to the enclave's cryptographic identity (MRENCLAVE)
• Optionally binds to the enclave author's identity (MRSIGNER)
• Used for persisting state across enclave restarts
• Complements KMS for local, platform-bound secrets
• Critical for Confidential Container state management