SAP-C03 Encryption and Key Management: KMS Keys and Rotation, ACM and Private CA, CloudHSM and Post-Quantum Cryptography

Encryption at rest with AWS KMS means each AWS service encrypts your data with a data key, and a KMS key that never leaves KMS's hardware security modules encrypts (wraps) that data key. This pattern is called envelope encryption. You choose who controls the KMS key by choosing its type:

A customer managed key is the only type that gives you control over the key itself: its policy, its rotation schedule and whether other accounts may use it. AWS managed keys are convenient but fixed: you cannot change their rotation, edit their policy or let another account use them.

Envelope encryption and its consequences

With GenerateDataKey, KMS returns a plaintext data key and the same key encrypted under the KMS key. The application (or service) encrypts the data with the plaintext key, discards it and stores the encrypted data key with the data. To read, it sends the encrypted data key to Decrypt. Two consequences follow:

• Rotating, disabling or re-policying the KMS key acts on the wrapping layer. It does nothing about a plaintext data key that has already leaked. AWS documents that rotation does not mitigate a compromised data key: the only remedy is to decrypt the affected data, encrypt it under fresh data keys and remove the old ciphertext (including old object versions).
• Because KMS only handles small data keys, bulk data volume never travels to KMS; the request count, not the data size, drives KMS cost and throttling.

KMS rotation replaces the key material behind a KMS key while the key keeps its key ID, ARN, aliases and policy. KMS keeps every earlier version of the material, so data encrypted before a rotation stays readable without re-encryption, and applications never reference key versions. Rotation also does not re-encrypt data or existing data keys. What you can do depends on the key's type and origin:

Manual rotation with an alias

Manual rotation means creating a new KMS key and moving an alias to it, so callers that use the alias switch keys without code changes. The old key must stay enabled while data or signatures that depend on it remain in use, because decrypt and verify need the original key. For a signing key, verifiers hold the public key, so you publish both public keys until everything signed with the old key has expired.

The key policy is the primary access control for a KMS key: no principal, not even the account root, can use a key unless the key policy allows it directly or delegates to IAM. The default key policy contains a statement for the account principal that delegates authorization to IAM policies. That is convenient, but it means anyone who can edit IAM can give themselves key use, including kms:PutKeyPolicy.

Separating key users from IAM administrators

To stop account administrators (for example, holders of AdministratorAccess) from ever decrypting data, remove the delegation statement and name principals explicitly: a key administrator role with management actions only, and the application role with cryptographic actions only. Always keep a key administrator in the policy, or the key becomes unmanageable. An IAM deny or a key policy deny added while the delegation remains does not help, because the administrators can remove it.

Cross-account use

A principal in another account can use a customer managed key only when both policies allow it: the key policy in the key owner's account (naming the account or, for least privilege, the specific role) and an IAM policy in the caller's account that allows the KMS action on the key's ARN. Things that do not work:

• Aliases are account-scoped: you cannot create an alias for another account's key, and cross-account calls must use the key ARN.
• SCPs never grant permissions; they only limit.
• AWS managed keys cannot be shared. RDS refuses to share a snapshot encrypted with aws/rds, and an AMI whose snapshots use aws/ebs cannot be shared. Copy the snapshot under a customer managed key, admit the other account in that key's policy and share the copy (the recipient usually copies it again under its own key).

Grants for services and service-linked roles

A grant is a scoped, revocable permission on one key for one grantee principal. Services such as EBS create grants for themselves. Grants also solve a cross-account case that policies cannot: EC2 Auto Scaling launches with its service-linked role, whose permissions policy you cannot edit. When an Auto Scaling group uses an AMI or volumes encrypted with another account's key, create a grant on that key, from the account that owns the Auto Scaling group, naming its service-linked role as grantee. The key policy must allow that account to create grants.

Condition keys that scope key use

Encryption context is non-secret additional authenticated data: decryption succeeds only with the same context, and it appears in CloudTrail. It is a control on how the key is used, not a secret. Network conditions such as aws:SourceVpce do not fit service-made calls: when EBS or S3 calls KMS on your behalf, the request does not travel through your VPC endpoint, so such a condition breaks the service. Match the scope of a condition to the set of callers that should use the key: organization-wide conditions such as aws:PrincipalOrgID fit keys every member account may use, while a key for a few named accounts lists those accounts explicitly.

Amazon S3 offers four server-side encryption modes; the choice depends on who controls the key and how many layers are required:

S3 Bucket Keys

An S3 Bucket Key is a short-lived bucket-level key that S3 derives from your KMS key and uses to create data keys for many objects, so S3 calls KMS far less often. It is a bucket setting that cuts KMS request charges sharply with no application change and while keeping the customer managed key. Side effects to design for:

• S3 passes the bucket ARN, not the object ARN, as the aws:s3:arn encryption context. A key policy that tests the context for an object prefix stops matching and requests fail with AccessDenied. Condition on the bucket ARN and enforce per-prefix access with the bucket policy and IAM policies instead.
• CloudTrail shows fewer KMS events, with the bucket ARN as context.
• Principals still need kms:Decrypt (and kms:GenerateDataKey to write): Bucket Keys reduce calls, not permissions.

Replicating SSE-KMS objects

S3 Replication skips KMS-encrypted objects unless the rule enables the SSE-KMS encrypted objects selection criterion (SseKmsEncryptedObjects). The rule must then name a replica KMS key (ReplicaKmsKeyID), in same-Region and cross-Region replication alike; for a different Region it must be a key in the destination Region. Then and allow the replication role kms:Decrypt on the source key and kms:Encrypt on the destination key in both its IAM policy and the key policies. S3 decrypts and re-encrypts each object; it treats a multi-Region key as a single-Region key, so switching to one does not avoid this work.

Most storage services fix encryption at creation, so existing unencrypted resources are moved to new encrypted copies; only some switch keys in place:

EBS encryption by default is a Regional, per-account setting, so a multi-Region estate enables it in every Region with that Region's key; it never touches existing volumes or other services such as EFS.

A multi-Region key is a set of KMS keys in different Regions that share the same key ID (beginning mrk-) and the same key material, so data encrypted in one Region can be decrypted in another without a cross-Region call and without re-encryption. You create a primary key and replicate it; each replica has its own Regional ARN.

• Where they pay off: client-side encryption (AWS Encryption SDK, AWS Database Encryption SDK) of data that moves or is replicated between Regions, such as items in DynamoDB global tables. The application in the second Region uses the local replica ARN in its keyring and keeps working when the first Region is down.
• Where they do not: AWS services such as S3 replication, and many service-level copies, treat a multi-Region key as a single-Region key and decrypt and re-encrypt anyway. Plan service-level replication with a destination key instead.
• Independent policies: each replica has its own key policy, grants and aliases; KMS never synchronizes them. Shared properties are the key material, key ID and rotation. A role that works with the primary needs the replica's key policy to allow it and an IAM policy whose Resource includes the replica ARN (or an arn:aws:kms:*:account-id:key/mrk-... pattern).
• Not a substitute: two single-Region keys with the same alias name have different material and cannot decrypt each other's data. UpdatePrimaryRegion changes which key is primary; it does not copy policies.
• Keys in a custom key store (CloudHSM or external) cannot be multi-Region. KMS will not replicate them, so any multi-Region availability for such keys has to be designed Region by Region.

AWS Certificate Manager (ACM) provisions, deploys and renews TLS certificates for integrated services such as Elastic Load Balancing, CloudFront and API Gateway, and AWS Private CA runs your own private certificate authority for internal names and client certificates.

ACM public certificates

• Regional: a certificate can be attached only to resources in the Region where it was requested. CloudFront uses certificates from us-east-1, so a distribution with an origin in another Region needs a second certificate for the same name in us-east-1.
• Managed renewal: ACM-issued certificates with DNS validation renew without human action as long as the validation CNAME record stays in DNS (simple when Route 53 hosts the zone). Email validation needs someone to approve renewal.
• Imported certificates (bought from another CA) are never renewed by ACM; ACM only emits expiry events. Replacing them with ACM-issued certificates removes the renewal chore.
• Exportable public certificates let you use an ACM public certificate on your own servers, but the private key then lives on those hosts.
• ACM for Nitro Enclaves lets NGINX or Apache on an enclave-enabled EC2 instance terminate TLS with an ACM public certificate whose private key stays inside the enclave, so OS administrators cannot read it and ACM still renews it. Use it when TLS must end on the instance (for example, behind an NLB with TCP listeners).

AWS Private CA for internal PKI

• A central CA in a security account, shared through AWS RAM, lets every workload account request private certificates in its own ACM. ACM renews private certificates it issued. Public certificates cannot cover private names such as payments.corp.internal.
• CA modes: general-purpose mode issues certificates of any validity. Short-lived certificate mode issues certificates valid for up to 7 days at a lower per-certificate price, which suits high-volume, short-lived workloads (for example, containers using mutual TLS) and avoids revocation lists. Short-lived certificates are issued directly through the Private CA API, not through ACM; ACM-managed certificates have a lifetime that ACM sets.

Mutual TLS on an Application Load Balancer

For client-certificate authentication, the ALB uses a trust store built from your CA certificate bundle uploaded to S3 (optionally with revocation lists). The HTTPS listener's mutual TLS mode decides who validates:

Partners receive client certificates issued by your Private CA through a secure channel. Server certificates on the listener prove the load balancer's identity to clients; only a trust store with a mutual TLS mode authenticates the clients themselves.

Encryption in transit is enforced at each hop: the TLS versions a listener accepts, re-encryption to the targets, and policies that reject plaintext requests.

Load balancer security policies

On Application and Network Load Balancers, the listener's security policy is the only control over negotiated TLS versions and ciphers; listener rules cannot filter on the TLS version.

End to end

• An ALB terminates TLS. To keep traffic encrypted to EC2 instances or containers, use HTTPS target groups with a certificate on each target; the ALB does not validate target certificates, so self-signed ones work. Security groups restrict who can connect but do not encrypt.
• An NLB with TCP listeners passes TLS through to the targets (end to end) but loses HTTP features such as path-based routing and AWS WAF. An NLB TLS listener terminates TLS at the load balancer.
• Certificates on the listener come from ACM, so they renew automatically.

Rejecting unencrypted requests to AWS APIs

To make S3 refuse plain HTTP from any principal in any account, add a bucket policy statement that denies all S3 actions when aws:SecureTransport is false. Because the deny sits in the resource policy, it applies to every caller, including principals in other accounts, whatever their own IAM policies allow.

Standard AWS KMS already generates and uses keys inside HSMs validated at FIPS 140-3 Level 3, integrates natively with S3, EBS, RDS and other services, and rotates keys automatically. A requirement for FIPS-validated HSMs alone is therefore met by KMS with the least overhead. Choose a dedicated or external option only when a rule asks for something KMS's multi-tenant service cannot provide:

CloudHSM essentials

• Single tenancy and exclusive control: AWS manages the hardware, but only your HSM users can use or manage the keys. The current hsm2m.medium type is FIPS 140-3 Level 3 validated.
• Interfaces: PKCS#11, Java (JCE) and the OpenSSL Dynamic Engine (used by NGINX or Apache for SSL/TLS offload, so a non-extractable TLS private key stays in the HSM), plus database transparent data encryption (for example, Oracle TDE through the PKCS#11 library).
• Separation of duties: admins (formerly crypto officers) manage users; crypto users create and use keys. Give applications crypto user credentials and keep admin credentials with the security team.
• High availability: a cluster synchronizes keys and users across its HSMs, and the client SDK load-balances and fails over between them. Run at least two HSMs in different Availability Zones for production. A second, separate cluster shares nothing, and restoring from backups means downtime.

Keys in any custom key store rotate manually (new key plus alias). A CloudHSM key store cannot hold asymmetric keys, so asymmetric uses such as TLS private keys go to CloudHSM directly.

A post-quantum strategy protects against two different future quantum threats, and the fixes differ:

Prioritize by exposure: confidentiality of data in transit on the internet first (because recording is happening now), then long-lived signatures. Hybrid key exchange is backward compatible, so older clients keep negotiating classical groups. Protection of recorded traffic comes from the key exchange, not from the protocol version or the certificate: a certificate authenticates the server, it does not decide whether recorded sessions can be decrypted later. Public clients also trust only certificates that chain to public roots, so private ML-DSA certificates serve internal PKI.

Migrating long-lived signatures

Devices or verifiers that trust only RSA cannot suddenly verify ML-DSA. Sign each release with both the classical key and a new ML-DSA key and ship both signatures, then deliver (with a classically signed update) the new trust anchor to devices while they can still be updated securely.

ML-DSA and ML-KEM keys in AWS KMS

AWS KMS offers two post-quantum asymmetric key types: ML-DSA (FIPS 204) for digital signatures and ML-KEM (FIPS 203) for establishing shared secrets. The private key never leaves KMS; the public key can be downloaded and used anywhere.

Signing large messages with ML-DSA

KMS accepts RAW messages of up to 4 KB. RSA and ECC keys handle larger data with the DIGEST message type, but ML-DSA keys use EXTERNAL_MU instead: the caller computes the 64-byte mu value locally as FIPS 204 defines it (from the message and the public key) and sends it to Sign. The result is a standard ML-DSA signature over the full message, verifiable like any other.

Key establishment with ML-KEM

The partner downloads your ML-KEM public key, encapsulates a 32-byte shared secret locally and sends you the ciphertext. Your service calls Decapsulate in KMS to recover the same secret, and both sides derive encryption keys from it with a key derivation function. The receiving role needs only kms:Decapsulate.

Decapsulate does not prove the ciphertext was made for your key: as FIPS 203 specifies (implicit rejection), a correctly sized ciphertext for another key, or a tampered one, still returns a 32-byte value, just the wrong one. A successful call is therefore no evidence that the ciphertext was meant for you. AWS therefore advises a key confirmation step: both sides derive a confirmation value (for example, an HMAC over a fixed label with a key derived from the secret) and compare it before processing any data.