Demystifying AWS KMS key operations, bring your own key (BYOK), custom key store, and ciphertext portability

October 4, 2024: This post has been updated to cover the following changes: FIPS 140-2 Level 3 validation of AWS Key Management Service (AWS KMS), the addition of the external key store service to AWS KMS, and FIPS 140-3 validation of AWS CloudHSM.

As you prepare to build or migrate your workload on Amazon Web Services (AWS), designing your encryption scheme can be challenging—and sometimes confusing. This blog post gives you a framework for selecting the right AWS cryptographic services and tools for your application. It covers common repeatable cryptographic patterns, addresses common misconceptions, and explain the security safeguards that AWS Key Management Service (AWS KMS) includes. In this post, I focus on how you should build your workload to take advantage of these safeguards, to help you avoid common mistakes, make informed design choices early in your process, and simplify your development.

Encryption is a fundamental mechanism to help prevent unauthorized access to data. However, it’s only as good as the safeguards you enforce on access and the use of data encryption keys. Using proven cryptography and industry best practices to restrict access to your data, managing your encryption keys, and monitoring their usage are crucial to long-term security. It’s also important to realize that your workloads’ availability and reliability are as important as their security. You must account for both operational and confidentiality aspects of AWS KMS as you build and operate your cloud applications.

Root of trust options for AWS workloads

One of your first considerations is whether to choose a service or hardware root of trust to secure your keys. When making that choice, you need to balance interoperability and management overhead with latency, availability, and reliability.

For customers that already encrypt data on-premises, an on-premises hardware security module (HSM) offers the advantage of moving existing encrypted data directly into the cloud with little effort, allowing you to continue using your existing compliance processes. However, the availability and latency of such a solution over time is suboptimal. If your HSM becomes unavailable, you might experience significant disruptions to your workloads. If your hardware fails or encryption keys are lost, you might lose access to your data altogether. Consequently, the burden of maintenance and monitoring for HSMs is disproportionate in comparison to a cloud-based solution or a managed cloud service.

If you want to optimize encryption for cloud workloads, consider a transition to a cloud-centered approach with a fully managed service like AWS KMS. With this approach, you’ll gain a high-performance key management system that uses a “pay as you go” model to lower costs and reduce the administration burden compared to self-managed HSMs. However, this transition might require some initial effort to re-encrypt your data and adjust how you demonstrate adherence to regulatory requirements such as data erasure and encryption key control.

Customers usually transition to the cloud somewhere between these two ends of the spectrum and then progress in their cloud journey. AWS offers several options to help with your constraints and needs. In the next section, I discuss the options that AWS cryptographic services offer for your data encryption needs and how you can make the right choice for your use case. I then review the common challenges and how to overcome them.

Cryptography for data security in AWS

Every AWS cryptographic service is backed by a FIPS 140-2 or FIPS 140-3 validated HSM. With AWS KMS, your keys are generated and managed on AWS operated multi-tenant HSMs. You access these keys and cryptographic operations by using the AWS KMS service API. Most customers find the high-level API for generating keys, encrypting, signing, Hash-based Message Authentication Code (HMAC), and Elliptic Curve Diffie Hellman (ECDH) operations in AWS KMS the simplest way to use a managed service for cryptography. For use cases that require integration with SDKs such as PKCS #11 and Java Cryptographic Extension (JCE), single-tenancy HSMs under customer control, or more specialized cryptographic algorithms, we recommend AWS CloudHSM.

If your regulatory or internal compliance policies require you to demonstrate control over your encryption key generation process, AWS KMS offers an option to bring your own key (BYOK). If you want the convenience and integration of AWS KMS, but require a single-tenant HSM under your control for the root of trust, AWS KMS offers custom key stores by using a customer-controlled CloudHSM cluster that generates the encryption keys and performs cryptographic operations. In addition, AWS KMS also offers external key store integration with external HSMs through an external key store (XKS) proxy, through which it delegates cryptographic operations to a third-party HSM. To learn more about the external key store integration with AWS KMS, see the blog post Announcing AWS KMS External Key Store (XKS).

After you create a key in AWS KMS, AWS enforces access to your encryption key through identity and resource policies, with logging provided by AWS CloudTrail. By using available AWS technologies, you can make sure that your encryption key usage follows your specified restrictions and aligns with cryptographic best practices such as granular access control, comprehensive auditing, and verification of key disposal, in line with the NIST 800-88 guidelines for cryptographic erase.

When you use the cloud-based AWS KMS solution, you can focus on security policies (permissions to perform cryptographic operations), encryption operations, and audits, while AWS manages encryption key availability, reliability, performance, and logging.

By contrast, if you currently manage HSMs on-premises, you know how expensive and difficult it can be. With AWS CloudHSM, AWS provides availability, encryption key synchronization, backup, and replacement of failed modules, thus making your administration job more manageable—however, you still have the overhead of managing user permissions, scaling, and logs. For this reason, we recommend that you only plan to use CloudHSM if your compliance regulations require a single-tenant FIPS 140-3 Level 3 validated HSM under your control or if you need access to the PKCS #11 or JCE programmatic interfaces. AWS KMS is multi-tenant and does not have PKCS interfaces. You might also need to use CloudHSM if you must support portable ciphertext and encryption keys. For other use cases, consider using AWS KMS.

Choosing AWS KMS crypto services

When you choose which AWS KMS related cryptographic services to use, there are four options for encryption key management:

• AWS KMS with standard customer managed keys
• AWS KMS with Bring Your Own Keys (BYOK) (KMS import key)
• AWS KMS with a custom key store with keys protected by CloudHSM
• AWS KMS with an external key store where keys are stored in a system that is external to AWS KMS.

Figure 1 compares how different architectural approaches impact operational complexity, operational costs, and risks. As operational complexity increases, so do operational costs. In addition, operational risks rise with the introduction of extended components such as CloudHSM, or an external key store that requires a customer-managed HSM and an HSM proxy.

Figure 1: Comparison of key management solutions and their relative cost

The diagram in Figure 1 illustrates the general relationships between risk, integration, and costs across various AWS KMS deployment options:

• Baseline AWS KMS — The lowest complexity and cost, compared to the other options presented here
• AWS KMS BYOK — Low-level complexity, low cost, and mildly increased level of risk
• AWS KMS custom key store – Medium-level complexity, costs, and risk
• AWS CloudHSM — High level of complexity, increased costs compared to AWS KMS custom key store, and medium-level risk
• On-premises HSM — Very high complexity, cost, and risk
• On-premises HSM used as an external key store – The highest complexity, cost, and risk, compared to the other options presented here

“Effort to manage” increases with the amount of time and effort needed to maintain a solution in an operational state. For example, you should consider how much time your administrators will spend managing the appliances, controlling access permissions, and performing data synchronization, backup, restoration, and audit.

When you compare “Effort to integrate” among solutions, consider how simple it is to use your encryption key management solution and the level of operational complexity you will face. AWS KMS is natively integrated with many AWS services to encrypt data at rest or facilitate signing and verification. The functionality is also available through the AWS encryption SDK for developers who need to encrypt or decrypt data locally within their applications. With HSM systems, PKCS #11 or JCE integration is usually the required approach.

When you review the risk of interruption, evaluate the technical components and specific responsibilities associated with each part of your solution. For example, managing mission-critical HSMs and proxies, along with maintaining reliable connectivity to external sites, can increase the risk of interruption. In multi-site deployments, these challenges are amplified by added complexity, where latency and the rate of cryptographic transactions can affect reliability, contributing to the overall risk of disruption.

Common BYOK misperceptions

A common misconception of BYOK in AWS KMS is the distinction between importing a key and natively generating one in AWS KMS. In both cases, AWS KMS applies the same safeguards that specify that it will only decrypt data that it has encrypted, consistently enforcing your policies and restrictions. The main difference lies in the source of the cryptographic material and where cryptographic operations take place. When you use the BYOK mechanism and effectively lease your key to AWS, a system under your control generates the key while AWS KMS handles the cryptographic operations, such as encrypt and decrypt. In contrast, with HSM-based key management, the HSM generates the key and performs the cryptographic calculations.

One important consequence of the restriction imposed by the security design of AWS KMS is that decryption is tied to the encryption key ID and the key material used by AWS KMS during the encryption process. AWS KMS binds the encryption key ID to the ciphertext, so that the data can only be decrypted by the AWS KMS encryption key with the same ID and key material. This restriction becomes more apparent with BYOK because you manage the key material, but AWS KMS still enforces the same security guardrails. Even if you manage and have access to your key material externally, such as through an HSM hosted elsewhere, the ciphertext produced by AWS KMS cannot be decrypted outside of AWS KMS, which limits ciphertext portability.

Why doesn’t AWS KMS support portable ciphertext?

One of the AWS KMS security properties is that its keys never leave the FIPS 140-2 HSM boundary in plain text. This process helps AWS KMS to enforce access to your key in a consistent and reliable way—it makes sure that AWS KMS verifies the encryption contexts you create. It also enables auditability of your cryptographic operations: Encryption key operations (generate a key, encrypt, decrypt, sign and verify, and delete key) that occur in AWS KMS are detailed in your CloudTrail logs. Finally, by keeping the encryption key securely within the HSM and disallowing access to its plain text form, AWS KMS mitigates the risk of unauthorized encryption or decryption attempts from external sources. This means that even if a threat actor obtains the ciphertext, they have no means of decrypting it without accessing AWS KMS, which controls the cryptographic operations. The result of the AWS implementation of these security constraints is that you must re-encrypt data for native AWS KMS implementations.

All cryptosystems generate output ciphertext in a certain message format, and different formats are not interoperable. The ciphertext message format used by AWS KMS contains metadata that is necessary for AWS KMS to perform decryption, such as the version of the key that was used to encrypt the data. Additionally, the AWS KMS ciphertext message format is subject to change from time to time. Each HSM vendor and cloud encryption service produces different kinds of ciphertext formats. Even if two cryptographic service providers use identical key material to produce ciphertext, it might be impossible to decrypt one with the other. In general, you should assume that only AWS KMS can decrypt ciphertexts it makes.

To validate that it is operating on a self-generated ciphertext, AWS KMS computes the ciphertext signature. AWS KMS uses signature verification to make decryption attempts of arbitrary data infeasible and, therefore, to minimize the potential of encryption key exhaustion. Although it’s possible to develop a system that would decompile the AWS KMS envelope, this would open a path for an outside party to decrypt your data and might introduce potential errors if the AWS KMS service adds metadata parameters or evolves its encryption algorithm in the future.

Selecting the correct path

When you’re choosing among the cryptography services offered by AWS, we recommend that you use native AWS KMS encryption whenever possible and encrypt data by using server-side encryption. This pattern allows you to focus on your application and rely on AWS for service availability, key hierarchy management, the encryption process (including algorithm selection), plaintext to ciphertext conversion, and logging. When you use AWS KMS with customer managed keys, you can enable key rotation. With encryption key rotation enabled, AWS KMS will automatically change your keys annually and track versions of the encryption keys used to encrypt your data, selecting the correct one for decryption.

The non-exhaustive diagram in Figure 2 demonstrates several approaches for using AWS KMS with customer managed keys and S3. Although we use Amazon Simple Storage Service (Amazon S3) for demonstration in the diagram, this deployment pattern applies to other AWS or custom services. In our four examples, the interaction pattern between a consumer service, such as Amazon S3, and AWS KMS is always the same: The consumer service requests a data encryption key from AWS KMS and then uses the key in a way appropriate to the service—in the case of Amazon S3, to encrypt an object stored in S3. Across the four different example use cases, the differences between these use cases are where the main encryption keys are stored and how they are accessed by AWS KMS.

In an AWS KMS only scenario, AWS KMS hosts and manages the encryption keys by using its internal HSMs. In a custom key store scenario, AWS KMS manages the keys by instructing CloudHSM to perform cryptographic actions, such as creating keys or decrypting data. With the BYOK leased key approach, customers provide their own key material, which AWS KMS temporarily hosts in volatile memory and never persists in cleartext. In the external key store option, customers manage their keys outside of AWS by using an external key management system; similar to the CloudHSM approach, AWS KMS instructs the external system which cryptographic actions to perform.

Figure 2: AWS options for key management

Consider importing your key into AWS KMS by using the BYOK mechanism if you are looking for security properties such as the following:

• An instantly deletable key
• A key that can be set to expire and be automatically removed
• An encryption key that cannot be recovered offline in AWS KMS

When you lease your key to AWS by using the BYOK mechanism, remember that AWS doesn’t persist your imported encryption key material to any storage medium. Therefore, you must make sure that you have a backup for recovery in case of a complete power loss.

When you’re required to demonstrate that your cryptographic system is a single-tenant environment where you have exclusive control over your encryption keys, you can use the AWS KMS custom key store backed by CloudHSM. In this design pattern, you can use the AWS services that are integrated with AWS KMS, while CloudHSM handles cryptographic operations.

For complete ciphertext portability and solutions that require a PKCS #11 or JCE interface, we recommend that you use CloudHSM. CloudHSM is a FIPS 140-3 Level 3 validated HSM that has native support for PKCS programmatic interfaces. To enable ciphertext portability between CloudHSM and another system, you must synchronize encryption keys between multiple HSMs through a wrapping and unwrapping process or custom code.

Finally, if you need to host an HSM under your control outside of your AWS KMS environment, you can use an AWS KMS external key store. When you use this approach, we strongly encourage you to evaluate the associated risks and benefits. The availability of your KMS encryption keys is a limiting factor for workloads that rely on those keys. Additionally, when you use an external AWS KMS key store, you introduce network latency and HSM proxy dependencies—components that might have varying performance and availability levels.

With AWS KMS, you also gain additional authorization layers through AWS Identity and Access Management (IAM) and resource policies, where both read access to data and decryption permissions are required to access plaintext data. By integrating authorization to use the encryption keys into your data access management strategy, you might find it easier to implement separation of duties and incident response plans. For example, you can use AWS IAM and AWS KMS resource policies as an additional control to prevent a security principal that writes data from reading it, or to deny access to data by restricting AWS KMS key usage, even if your resource policy is overly permissive.

This defense-in-depth strategy also allows you to disable or deny access to an encryption key as a part of a containment strategy during a security event. Restricting access to or disabling AWS KMS encryption keys results in plaintext data becoming inaccessible, even if a third party gains access to ciphertext.

Review hierarchy, encryption, and decryption

In this section, we explore how AWS KMS operates on data and highlight the essential steps involved in its cryptographic processes. More details are available in the AWS Key Management Service whitepaper.

AWS KMS key hierarchy

The fundamental purpose of AWS KMS is to help you securely create, manage, and protect encryption materials. AWS KMS uses an encryption key hierarchy that is designed to protect your data. The two key types are key-encryption key (KEK) or data encryption key (DEK).

When you create an AWS KMS symmetric key, the following steps take place:

1. AWS KMS generates key metadata—such as the key ID, version, ARN, and alias. The key ID is unique to the AWS Region where you create it.
2. AWS KMS creates an HSM backing key (HBK), which is a 256-bit Advanced Encryption Standard (AES)

There are four ways to create an HBK with AWS KMS:

• AWS KMS managed keys: KMS managed HSMs create an HBK.
• BYOK: You generate an HBK key and import it into an AWS KMS HSM through an API.
• Custom key store: The HBK is generated on a customer-controlled CloudHSM cluster through AWS KMS during custom key store provisioning.
• AWS KMS external key store: KMS managed HSMs create an HBK, which is used in conjunction with the key on customer’s HSM for double encryption of plaintext data.

The result of establishing an AWS KMS key is a 256-bit HBK AES key, which is combined with a one-time random number to generate a data encryption key that is used to encrypt data.

The encryption and decryption process for AWS KMS

Understanding how AWS KMS uses HBK and data keys empowers you to successfully use this technology in your solutions. The following sequence illustrates encryption and decryption operations.

During an encrypt operation, AWS KMS does the following:

1. Locates the HBK with the specified ID and version number within service-managed HSMs.
2. Generates a random value.
3. Uses the HBK and the random value to create a data encryption key by invoking the NIST 800-108 key derivation function.
4. Encrypts the data with the derived data key.
5. Combines the following metadata:
   1. Key ID
   2. Key version
   3. The random value used to generate the key
   4. Other service metadata
6. Signs the combined data with the AWS KMS key.

The output of this step is the return value of your AWS KMS encrypt API call.

During a decrypt operation, AWS KMS does the following:

1. Opens the message.
2. Verifies the message signature. If the verification fails, the operation stops.
3. Extracts the key ID, version, random value, and ciphertext stored in the metadata envelope during the encrypt operation.
4. Locates HBK within its service-managed HSM by using the key ID and key version.
5. Uses the HBK and the random value to recreate the data encryption key by using the reverse of NIST 800-108 key derivation function.
6. Decrypts the data.

The output of this step is the return value of your AWS KMS decrypt API call.

The encryption and decryption process for AWS KMS managed keys with a custom key store

For an AWS KMS custom key store, the process is similar to the one described earlier, with one important difference: HBK generation, storage, data encryption, and decryption occur on CloudHSM rather than on AWS KMS service-managed HSMs. CloudHSM cluster size and performance are controlled by customers, so you need to ensure adequate performance and availability. Additionally, the integration between AWS KMS and CloudHSM has different performance characteristics compared to AWS KMS services and requires at least two CloudHSM devices in separate Availability Zones.

Takeaways

When you develop your applications to use cloud-based encryption, you can reduce your operational burden, improve performance, and strengthen access control. As you decide how to deploy AWS KMS and which options to use, keep in mind the following:

• AWS KMS uses key material—HBK—not for data encryption, but to derive a one-time encryption key. The benefit of leasing the key material to AWS through the BYOK process is primarily related to compliance, where you need to demonstrate that your key generation process meets entropy requirements. Additionally, BYOK provides the ability to instantly delete keys, set them to expire and be automatically removed, and help prevent the encryption key from being recovered offline in AWS KMS. Because BYOK keys aren’t used for your data encryption in AWS KMS, but are combined with a random number to derive the data encryption key, you cannot decrypt ciphertext created externally with the imported equivalent of that key in AWS KMS—and vice versa. Furthermore, if you import the same key into AWS KMS in two different Regions, the resultant ciphertext won’t be identical or interoperable due to differences in metadata information that is included in the AWS KMS message format.
• AWS KMS incorporates safeguards to help prevent misuse and overuse of your keys. AWS KMS uses HBK and unique randomness for each transaction, so that even if you make multiple calls to encrypt the same plaintext with the same key, the resulting ciphertext will differ each time. Additionally, AWS KMS ciphertexts include integrity checks, which helps to prevent decryption attempts on arbitrary data and helps to protect your keys from brute force discovery attacks. These safeguards are also the reason why ciphertext cannot be interoperated between AWS KMS and external systems. For hybrid deployment, you can—and should—re-encrypt data by using keys and formats that are appropriate to wherever your data resides.
• The custom key store in AWS KMS is most beneficial for customers who need encryption key isolation, proof of entropy mechanism, or access to PKCS cryptographic interfaces for reasons of compliance. This approach allows organizations to adhere to specific regulatory requirements such as having an instantly deletable key, or ensuring that the encryption key cannot be recovered offline within AWS KMS. However, when you use an AWS KMS custom key store, you inherently incur the penalties and limitations associated with running and communicating to a CloudHSM cluster. This includes the shift of responsibility for performance, monitoring, and user administration to your side of the shared responsibility model.
• The AWS KMS external key store feature provides flexibility for customers who need to integrate with their own on-premises or third-party HSMs. This can be a valuable option in specific, specialized scenarios, but it requires careful evaluation of the trade-offs, especially for mission-critical or time-sensitive operations.

  For example, using an external AWS KMS key store to encrypt the Amazon Elastic Block Store (Amazon EBS) volumes of a Microsoft Windows domain controller or the data secrets stored in AWS Secrets Manager can lead to cascading failures if there is a reachability issue with the external key storage. In such cases, a failure in a cryptographic operation could prevent access to critical services necessary for remediation. Therefore, we recommend that you use AWS KMS native encryption keys for critical workloads. The complexity and potential points of failure introduced by an external key store might outweigh its benefits when cryptographic operations are on the critical path of your application’s functionality.

Conclusion

When you design your encryption scheme, we recommend that you consider AWS KMS as your primary option. AWS KMS offers FIPS 140-2 Level 3 compliant encryption that is reliable and highly available. Additionally, because many other AWS services rely on AWS KMS for encryption, you can centralize the management of your encryption keys, security policies, and access logs. If your use case requires specialized compliance, such as single tenancy, or if you have specific development requirements such as PKCS #11, JCE, BYOK, or FIPS 140-3 Level 3 compliance, the AWS CloudHSM and AWS KMS custom key store options are available.

Furthermore, while the AWS KMS external key store offers flexibility for integrating with external HSMs, it comes with greater costs in terms of performance, latency, and the increased complexity of managing external systems, which can be especially significant for critical workloads.

To learn more, you can review additional content such as the AWS KMS Cryptographic Details whitepaper, AWS Key Management Service Best Practices whitepaper, AWS Key Management Service Documentation, and AWS KMS Workshop. We also recommend that you engage your AWS account team for detailed reviews and specialized engagements.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS KMS forum or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.