11.3 Imported Key Material (BYOK) & CloudHSM Key Stores

11.3 Imported Key Material (BYOK) & CloudHSM Key Stores

While standard AWS KMS customer managed keys meet the security and compliance requirements of most cloud workloads, highly regulated industries—such as banking, healthcare, government defense, and sovereign public sectors—face mandates that forbid generating cryptographic keys within multi-tenant cloud environments.

To satisfy these stringent regulatory requirements, AWS provides three specialized cryptographic architectures: Imported Key Material (Bring Your Own Key / BYOK), AWS CloudHSM, and KMS Custom Key Stores (including CloudHSM-backed key stores and External Key Stores / XKS). Understanding how each architecture handles key entropy, lifecycle durability, administrative boundaries, and disaster recovery is critical for passing the AWS Certified Security – Specialty exam.

---

Bring Your Own Key (BYOK): Architecture & Import Workflow

By default, when you create a customer managed key in AWS KMS, KMS generates the underlying 256-bit cryptographic key material inside its own FIPS 140-2/140-3 Level 3 HSMs using a hardware-based random number generator. The Origin attribute of such a key is AWS_KMS.

When compliance regulations mandate that cryptographic keys must be generated inside an on-premises Hardware Security Module or a commercial Key Management Interoperability Protocol (KMIP) appliance, AWS KMS supports Imported Key Material (BYOK). Keys created with imported key material have an Origin attribute of EXTERNAL.

Loading diagram...

The 5-Step Import Process

Importing external key material into AWS KMS requires a secure, multi-step cryptographic handshake:

1. Create the KMS Key Container: You call kms:CreateKey, specifying Origin: EXTERNAL and a key spec (for example SYMMETRIC_DEFAULT; RSA, ECC, and HMAC specs are also supported). The KMS key container is created without any cryptographic key material. Its status is PendingImport, and it cannot perform any cryptographic operations.
2. Obtain Wrapping Parameters: You invoke kms:GetParametersForImport, specifying the KMS KeyId, wrapping algorithm (e.g., RSAES_OAEP_SHA_256, RSAES_OAEP_SHA_1, or RSA_AES_KEY_WRAP_SHA_256), and wrapping key spec (e.g., RSA_2048, RSA_3072, RSA_4096).
3. KMS Emits Parameters with a 24-Hour TTL: KMS returns two critical assets:
   • Public Wrapping Key: A temporary RSA public key generated inside the KMS HSM.
   • Import Token: A cryptographic token containing metadata that binds the wrapping key to the specific KMS key container.
   • Critical Constraint: Both the wrapping key and import token expire in exactly 24 hours. If the import is not completed within 24 hours, new parameters must be generated.
4. Wrap the Key Material On-Premises: Inside your on-premises HSM or using an approved cryptographic utility (such as OpenSSL), you encrypt (wrap) your 256-bit raw symmetric key material using the downloaded AWS public wrapping key using the agreed-upon algorithm.
5. Execute kms:ImportKeyMaterial: You upload the wrapped key material and the import token to AWS KMS. The KMS HSM validates the import token, unwraps the key material using its private wrapping key inside the HSM, and loads the key material into volatile HSM memory. The key state transitions to Enabled.

Expiration Settings for Imported Keys

When executing ImportKeyMaterial, you configure the key's expiration model:

• KEY_MATERIAL_DOES_NOT_EXPIRE: The key material remains loaded indefinitely until explicitly deleted.
• KEY_MATERIAL_EXPIRES: You define a specific UNIX epoch timestamp. When the expiration timestamp is reached, AWS KMS automatically wipes the key material from all HSMs. The key transitions back to the PendingImport state. Any workloads attempting to use the key fail immediately until the key material is re-imported.

---

Durability, Revocation & Lifecycle Management for Imported Keys

Managing imported key material introduces fundamental architectural trade-offs compared to native KMS keys.

The Durability Caveat (Zero AWS Backup)

For standard keys (Origin: AWS_KMS), AWS KMS stores encrypted copies of key material in systems designed for 99.999999999% (11 9s) durability.

Critical Core Principle: AWS KMS keeps imported key material highly available but does not maintain its durability at the same level as key material it generates. If the material expires, is deleted, or is lost in a rare failure, you must reimport it from your own copy.

The customer bears 100% of the responsibility for maintaining external, durable backups of the original key material. If you lose your on-premises copy of the key material and the key material is cleared from AWS KMS, all data encrypted under that KMS key is permanently and irreversibly lost. AWS Support cannot recover, regenerate, or extract imported key material.

Immediate Revocation via kms:DeleteImportedKeyMaterial

Standard KMS keys enforce a mandatory 7-to-30-day waiting period before key material can be destroyed (kms:ScheduleKeyDeletion). In contrast, imported keys provide an emergency revocation capability:

• An administrator can invoke kms:DeleteImportedKeyMaterial at any time.
• Deletion occurs immediately and instantaneously (zero waiting period).
• The key material is erased from all KMS HSMs in the Region, and the key state reverts to PendingImport.
• This allows security teams to respond instantly to active compromise: by deleting the imported key material, all access to encrypted data across all AWS services is severed in seconds.

Strict Re-Import Rules

If you delete imported key material or allow it to expire, you can restore functionality by calling ImportKeyMaterial again. However, KMS enforces an immutable cryptographic restriction:

• Reimport restores the same key material: When you reimport (ImportType: EXISTING_KEY_MATERIAL), KMS verifies that it matches the material previously imported; different bytes fail with IncorrectKeyMaterialException.
• Asymmetric and HMAC keys are permanently bound to their original key material; you can't import different material into them.
• Symmetric encryption keys can take new material for on-demand rotation (see below).

Absence of Automatic Key Rotation

Imported keys do not support automatic key rotation, because AWS KMS doesn't generate the material. Two rotation methods remain:

• On-demand rotation (symmetric encryption keys): Call ImportKeyMaterial with ImportType: NEW_KEY_MATERIAL, then call RotateKeyOnDemand. The new material becomes current for encryption, and earlier imported materials still decrypt existing ciphertext, so the key ID and aliases don't change. For multi-Region keys, import the same new material into every replica before rotating the primary.
• Manual rotation (all key types): Create a new KMS key, import new material, and repoint the alias or application. This is the only option for asymmetric and HMAC keys.

AWS CloudHSM: Dedicated FIPS 140-3 Level 3 Hardware Architecture

While AWS KMS provides a multi-tenant cryptographic service (where multiple customers share the same physical HSM fleet, with logical isolation enforced by hardware firmware and KMS microkernels), certain compliance frameworks demand single-tenant isolation.

AWS CloudHSM provides dedicated, single-tenant physical Hardware Security Modules under the customer's direct administrative control. CloudHSM instances are provisioned directly inside your private Amazon VPC subnets.

Loading diagram...

Architectural Characteristics of CloudHSM

1. FIPS 140-3 Level 3 Validation: The current hsm2m.medium HSMs are FIPS 140-3 Level 3 validated (they can also run in a non-FIPS mode); the older hsm1.medium type (FIPS 140-2 Level 3) reached end of support on March 31, 2026.
2. Single-Tenant Hardware: The physical HSM appliance is dedicated entirely to your account. No other AWS customer's keys or operations touch your hardware.
3. Direct VPC Placement: Each CloudHSM instance attaches an Elastic Network Interface (ENI) directly into your private VPC subnet, communicating over private IP addresses.
4. Zero AWS Administrative Visibility: AWS personnel manage the hardware chassis, power, and physical networking, but AWS has zero logical access to the HSM. AWS cannot view, export, or recover your keys, and AWS has no administrative accounts inside the HSM.

CloudHSM User Roles

Authentication inside CloudHSM bypasses AWS IAM entirely (IAM controls only the cluster API, such as creating HSMs and backups). CloudHSM maintains its own user database; Client SDK 5 names the roles below (SDK 3 called the admin a crypto officer, or CO):

• Unactivated admin (PRECO): The default administrator before cluster activation; activation sets its password.
• Admin (CO): Creates, manages, and deletes HSM users and manages quorum settings. An admin cannot perform cryptographic operations with keys.
• Crypto User (CU): The operational user. A CU creates, uses, encrypts with, decrypts with, and shares cryptographic keys. Applications authenticate to CloudHSM using CU credentials.
• Appliance User (AU): A user that AWS uses to clone and synchronize HSMs in the cluster. It can't create or use keys.

Standard Cryptographic APIs

Unlike AWS KMS, which uses proprietary AWS REST APIs (kms:Encrypt, kms:Decrypt), CloudHSM exposes industry-standard cryptographic interfaces:

• PKCS#11: The standard cryptographic token interface library for C/C++ applications.
• Java Cryptography Extension (JCE): Standard provider for Java enterprise workloads.
• Microsoft Cryptography Next Generation (CNG) and KSP: Standard cryptographic providers for Windows Server environments.
• OpenSSL Dynamic Engine: Offloads TLS and other OpenSSL operations on Linux.

High Availability & Multi-AZ Clustering

A single CloudHSM instance represents a single point of failure. Enterprise architectures mandate deploying a CloudHSM Cluster spanning at least two Availability Zones. The CloudHSM service automatically synchronizes keys and user states between cluster members across AZs. Encrypted daily backups are automatically stored in Amazon S3, encrypted with an ephemeral hardware key that can only be decrypted by another CloudHSM instance in your cluster.

KMS Custom Key Stores: CloudHSM & External Key Store (XKS)

Many organizations desire the seamless integration of AWS KMS with native AWS services (such as EBS, RDS, S3, and Redshift) but are legally prohibited from storing master keys inside multi-tenant KMS HSMs.

AWS KMS Custom Key Stores bridge this divide by pairing the AWS KMS management API with a dedicated cryptographic backend. AWS KMS supports two types of custom key stores:

1. AWS CloudHSM Key Stores
2. External Key Stores (XKS)

CloudHSM-Backed Custom Key Stores

When you create a CloudHSM-backed custom key store, KMS associates with an active AWS CloudHSM cluster in your VPC:

• When you create a KMS key in this store (Origin: AWS_CLOUDHSM), KMS creates the key material inside your dedicated CloudHSM cluster.
• When an AWS service calls kms:GenerateDataKey or kms:Decrypt, KMS proxies the cryptographic operation to your CloudHSM cluster over private ENIs.
• Limitations: CloudHSM-backed key stores do not support asymmetric keys, HMAC keys, or Multi-Region Keys. Furthermore, performance is constrained by the throughput capacity of your CloudHSM instances.

External Key Store (XKS): Sovereign Key Management

For organizations subject to national data sovereignty regulations (such as EU data localization directives), cryptographic keys must never reside in cloud data centers, even in dedicated cloud HSMs.

AWS KMS External Key Store (XKS) allows AWS KMS to use cryptographic keys that exist exclusively in an external key manager located outside of AWS (typically in an on-premises data center or colocation facility).

Loading diagram...

The XKS Proxy Architecture

Because external HSMs do not speak AWS KMS API protocols, XKS relies on an intermediary component: the XKS Proxy.

1. The XKS Proxy Specification: An open-source, customer-maintained REST API service running on an EC2 instance, ECS container, or on-premises appliance. It translates KMS XKS requests into vendor-specific HSM calls.
2. Secure Connectivity: KMS communicates with the XKS Proxy via an AWS PrivateLink VPC Endpoint Service (recommended for security) or over the public internet via HTTPS.
3. Authentication & Integrity: AWS KMS signs every request to the proxy with SigV4 using a proxy authentication credential (an access key ID and secret key that you create on the proxy and register with KMS). The proxy authenticates itself to KMS with a TLS server certificate from a public certificate authority, over TLS 1.2 or later.

Severe Operational & Architectural Trade-offs of XKS

While XKS delivers absolute data sovereignty, it introduces severe operational hazards that are heavily tested on the specialty exam:

• No Local Caching in AWS: AWS KMS never caches or stores external key material. Every single cryptographic request (such as decrypting an EBS volume block or reading an S3 object) requires a real-time round-trip network call to the external on-premises HSM.
• Network Latency Overhead: Network transit times across Direct Connect or VPN links add 20 to 100+ milliseconds of latency to every cryptographic operation, severely impacting database I/O performance.
• Availability Dependency & Workload Outage Risk: If your corporate on-premises data center experiences a power failure, fiber cut, or HSM crash, all dependent AWS workloads fail immediately. Encrypted EBS volumes will freeze, RDS databases will crash, and S3 read requests will fail with KMS exceptions.

Specialty Exam Pitfalls & Architectural Traps

1. Reimport vs New Material: Reimporting (EXISTING_KEY_MATERIAL) must use the same bytes, or KMS returns IncorrectKeyMaterialException. To rotate a symmetric imported key in place, import with NEW_KEY_MATERIAL and call RotateKeyOnDemand; asymmetric and HMAC imported keys still need a new KMS key and an alias update.
2. Expecting AWS to Recover Lost Imported Keys: If an on-premises disaster destroys your local key backups, and an imported key expires or is deleted in KMS, AWS Support cannot assist. AWS KMS does not provide its usual durability for imported key material, so your own copy is the only recovery source.
3. The 24-Hour Wrapping Parameter Window: Wrapping keys and import tokens obtained from GetParametersForImport are valid for exactly 24 hours. If an automation pipeline downloads parameters on Friday but executes the import on Monday, the import fails.
4. Instant Deletion vs Waiting Periods: Standard KMS keys require a 7-to-30-day waiting period. Imported key material can be deleted instantaneously using kms:DeleteImportedKeyMaterial, providing immediate revocation during an active breach.
5. XKS Network Failure Impact: XKS does not feature a local fallback cache in AWS. If the on-premises connection drops, all AWS services relying on that key will fail immediately.