Asterrr's Handbook
5 · Data protection

Key material and HSMs

Imported versus KMS-generated key material, rotating and expiring imported keys, CloudHSM clusters, and KMS custom key stores backed by CloudHSM or an external key manager.

Exam tasks: 5.2.1 (choose between CloudHSM and KMS), 5.3.2 (import and remove key material, external key stores), 5.3.3 (imported versus AWS generated key material)

The decision: where must the key material be created, where must it live, who can destroy it, and how much availability and operational work are you willing to take on to get that control?

The ladder of control

AWS runs itYou run it
  1. KMS, AWS generated
    origin AWS_KMS

    KMS creates, stores, rotates and backs up the material in its multi-tenant FIPS 140-3 Level 3 HSMs. You control the policy.

  2. KMS, imported (BYOK)
    origin EXTERNAL

    You generate the material and import a copy. You can expire or delete it instantly, and you keep the master copy.

  3. CloudHSM key store
    origin AWS_CLOUDHSM

    KMS keys whose material lives in a CloudHSM cluster you own. Single-tenant, still works with AWS services.

  4. External key store (XKS)
    origin EXTERNAL_KEY_STORE

    Material never enters AWS. Every encrypt and decrypt goes to your key manager outside AWS.

  5. CloudHSM direct
    PKCS#11, JCE, CNG

    Your application talks to the HSM itself. No KMS integration with AWS services.

Imported vs AWS generated material

AWS generated (AWS_KMS)Imported (EXTERNAL)
Who creates the materialKMS HSMsYou, with your own entropy source
Key typesSymmetric, asymmetric, HMACSymmetric, asymmetric (except ML-DSA), HMAC
Automatic rotationYes (symmetric)No
On-demand rotationYesYes, after you import new material (symmetric only)
ExpirationNeverOptional expiry date you choose
Remove material without deleting the keyNot possibleDeleteImportedKeyMaterial, effective at once
Waiting period to destroy7–30 days (delete the key)None for the material; reimport restores it
DurabilityAWSYou: lose your copy after it expires and the data is gone
Custom key storesSupportedNot supported
Multi-RegionMaterial copied to replicas by KMSYou import the same material into each replica

Exam signal

"We must be able to make the data unreadable immediately, and restore access later" means imported key material: delete the material now, reimport the same material later. Scheduling key deletion can't be undone after the waiting period, and disabling a key leaves the material inside AWS.

How import works

Create a key with no material. CreateKey with origin EXTERNAL. The key sits in PendingImport.

Download the wrapping public key and import token. GetParametersForImport returns an RSA public key and a token that are valid for 24 hours.

Wrap your material. Encrypt it with the public key using RSAES-OAEP or RSA-AES key wrap, on your own HSM.

Import. ImportKeyMaterial with the token, the wrapped material and an optional expiration time.

  • The ciphertext is bound to the KMS key, not just the material. If you delete the KMS key, importing the same material into a new key doesn't decrypt old data. Keep the key; only remove the material.
  • Only the same material can be reimported into a key, unless you are staging new material for on-demand rotation.
  • Set a CloudWatch alarm on the SecondsUntilKeyMaterialExpiration metric so an expiry doesn't surprise you.
  • When imported material expires or is deleted, the key becomes unusable. AWS services that cached a data key (an attached EBS volume, for example) keep working until the data key is needed again.

Rotating imported material

  1. Generate new material and import it into the same key. It shows as pending rotation.
  2. Call RotateKeyOnDemand. New encryptions use the new material, and old ciphertext still decrypts with the old material, which stays attached to the key.
  3. Every material version must stay present and unexpired. Losing any of them makes the whole key unusable.

Rotating BYOK the old way

Older material taught "create a new KMS key, import new material, move the alias" as the only way to rotate imported keys. That still works, but it leaves a second key to manage and applications that stored the key ARN break. On-demand rotation of imported material now keeps the same key ID.

AWS CloudHSM

  • A cluster of single-tenant HSMs in your VPC, FIPS 140-3 Level 3 validated. AWS manages the hardware, patching and backups; you manage HSM users, keys and policies. AWS can't see or recover your keys.
  • Put at least two HSMs in different Availability Zones. Keys synchronise across the cluster, and a lone HSM is a single point of failure.
  • CloudHSM takes automatic encrypted backups at least once a day. You can copy backups to another Region for DR.
  • Users on the HSM: admins manage users; crypto users create and use keys. Lose all admin credentials and nobody, including AWS, can recover access.
  • Access is through the client SDK: PKCS#11, JCE, OpenSSL Dynamic Engine, and KSP/CNG on Windows.
Signal in the questionWhy CloudHSM
Oracle TDE or SQL Server TDE on EC2 with an HSM-held master keyDatabases integrate through PKCS#11 or EKM, not KMS
TLS offload on web servers with the private key in an HSMNGINX, Apache or IIS integration
Root key of a Windows or self-run certificate authorityCNG or PKCS#11
Contract requires single-tenant HSM and customer-only adminOnly you hold HSM admin credentials
Symmetric algorithms or key types KMS doesn't offerDirect HSM API

FIPS alone doesn't mean CloudHSM

KMS HSMs are already FIPS 140-3 validated, and KMS offers FIPS endpoints. "Must use FIPS-validated cryptography" is satisfied by KMS. Choose CloudHSM only when the question adds single tenancy, customer-exclusive control, or an interface such as PKCS#11.

KMS custom key stores

CloudHSM key store

  • KMS keys whose material is generated and kept in your CloudHSM cluster. KMS calls the cluster as a special crypto user named kmsuser.
  • The cluster must have at least two active HSMs in different AZs before KMS can connect.
  • Supports symmetric encryption keys only. No automatic or on-demand rotation, no imported material, no multi-Region keys.
  • AWS services integrate exactly as with any customer managed key. Every use also appears in the HSM audit logs.
  • If the cluster loses its HSMs or you disconnect the key store, the keys become unavailable until you fix it.

External key store (XKS)

  • KMS keys backed by a key manager outside AWS: an on-premises HSM, another cloud, or a vendor service. KMS never sees your external key.
  • KMS talks to an XKS proxy that you run, over a public endpoint or a VPC endpoint service (preferred when you want traffic off the internet).
  • Double encryption: KMS encrypts with its own per-key material, then your key manager encrypts again, so neither side alone can decrypt.
  • Disconnect the key store (or cut the proxy) and every dependent AWS resource loses access to its keys. This is the "kill switch" some sovereignty regulations demand.
  • You own availability, latency (aim for a round trip under 35 ms to the Region) and durability. Symmetric keys only, and no rotation of the KMS key itself.
KMS standardCloudHSM key storeExternal key storeCloudHSM direct
TenancyMulti-tenant HSMsSingle-tenantYour own systemSingle-tenant
Works with S3, EBS, RDS...YesYesYesNo
Material inside AWSYesYes, in your clusterNoYes, in your cluster
Who keeps it availableAWSYou (cluster size, AZs)You (proxy, network, HSM)You
RotationAutomatic or on demandManual onlyIn your key managerYou script it
24 hours
Validity of the wrapping key and import token from GetParametersForImport.
2 HSMs, 2 AZs
Minimum CloudHSM cluster for a KMS CloudHSM key store.
10
Custom key stores per account per Region, CloudHSM and external combined.
35 ms
Recommended maximum round trip between the Region and an external key manager.

Scenarios

Scenario
A European insurer must prove to its regulator that it can make all of its data in Amazon S3 and Amazon EBS unreadable to AWS at any moment, and that the key material never resides in AWS. The insurer runs a certified HSM cluster in its own data centres. What should a security engineer implement?
Scenario
A bank imported 256-bit key material into a symmetric KMS key two years ago. Its policy now requires the key material to change every year without changing the key ARN that dozens of applications reference. What should the security engineer do?
Scenario
A retailer runs Oracle Database Enterprise Edition on EC2 and must keep the TDE master encryption key in a single-tenant HSM that only the retailer's staff administer. What should the retailer use?

Further reading

KMS key management

KMS key types and ownership, key policies, grants and condition keys, envelope encryption, rotation, multi-Region and cross-account keys, and safe deletion.

Encryption in transit

Load balancer TLS policies and where TLS terminates, mutual TLS, ACM and AWS Private CA across Regions, CloudFront protocol policies, inter-node encryption for EMR, EKS and SageMaker AI, Nitro encryption, and forcing TLS on AWS APIs.

On this page

The ladder of controlImported vs AWS generated materialHow import worksRotating imported materialAWS CloudHSMKMS custom key storesCloudHSM key storeExternal key store (XKS)ScenariosFurther reading