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

Encryption is a fundamental mechanism to prevent unauthorized access to data. However, it’s only as good as the safeguards you enforce on access and 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 KMS as you build and operate your cloud applications.

Choices for roots of trust

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

For customers already encrypting data on-premise, using an on-premises hardware security module (HSM) allows you to move existing encrypted data directly into the cloud with little effort and continue using your existing compliance processes. However, the availability and latency of such a solution over time is suboptimal. The critical risk is that if your HSM becomes unavailable, you could experience business-critical outages of your workloads. If your hardware fails or the encryption keys are lost, you could lose access to your data altogether. Thus, your burden of maintenance, monitoring, and durability is disproportionately high in this scenario.

For customers that want to optimize encryption for cloud workloads, consider a transition to a cloud-native approach with a fully managed service like AWS KMS. Using this approach, you’ll gain a high-performance key management system with the “pay as you go” model to lower your costs and reduce your administration burden compared to self-managed HSMs. However, this method can incur some significant upfront effort to re-encrypt your data and possibly alter how you demonstrate regulatory compliance. For example, you may need to change how you show compliance in data erasure and encryption key control. AWS can help you achieve that goal through tooling, compliance audit reports, compliance guidance (such as NIST blueprints), assistance from your account team, AWS Professional Services, and AWS Support.

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 suit 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 in AWS

Every AWS cryptographic service is backed by a FIPS 140-2 validated HSM. With AWS KMS, your keys are generated and managed on AWS operated multi-tenant HSMs. You access these keys and cryptographic operations using the KMS service API. If you need a FIPS 140-3 validated HSM, you can use an AWS CloudHSM that you control with your Amazon Virtual Private Cloud (Amazon VPC). With this approach, you need to develop functionality for your applications to access your CloudHSMs.

KMS also offers complete control over where you generate and store your encryption keys.

If your compliance or internal policies must demonstrate control over your encryption key generation process, such as provable encryption key entropy, AWS KMS offers an option to bring your own key (BYOK). If you want the convenience and integration of KMS but require a single-tenant HSM under your control for the root of trust, KMS offers custom key stores.

Once you create a key in AWS KMS, KMS applies access control through identity and resource policies, integrity checks, and AWS CloudTrail. Using the available AWS technologies, you can ensure that your encryption key usage follows the restrictions you’ve specified and in a manner consistent with cryptographic best practices.

When you use a cloud-native AWS KMS solution, you focus on security policies (permissions to perform cryptographic operations), encryption operations, and audits. With KMS, AWS manages availability, reliability, performance, and logging.

By contrast, if you currently manage HSMs on-premises, you know how expensive and difficult it can be. With CloudHSM, AWS ensures availability, encryption key synchronization, backup, and replacement of failed modules, thus making the administration job more manageable. You still have the overhead of user permissions, scaling, and log management. Consequently, you should only plan to use CloudHSM if your compliance regulations require a single-tenant FIPS 140-2 Level 3 (§1.3) validated HSM under your control since AWS KMS is multi-tenant and—for now—carries FIPS 140-2 Level 2 (§1.2) certification. For other use cases, you should consider using KMS. You might also need to use CloudHSM if you must support portable ciphertext and encryption keys. I discuss this in more detail in the following sections.

AWS KMS crypto services

When choosing AWS KMS related AWS cryptographic services, there are three options for encryption key management:

Figure 1 compares how different architectural approaches impact operational complexity and operational costs. As operational complexity increases, so do operational costs. The following figure shows how different architectures compare to each other as complexity increases.

  • Native AWS KMS—lowest complexity and cost
  • AWS KMS BYOK
  • AWS KMS custom key store
  • AWS CloudHSM
  • On-premises HSM—highest complexity and cost
Figure 1: Comparison of key management solutions and their relative cost

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

“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 comparing “Effort to integrate” among solutions, you should consider how easy it is to use your encryption key management solution. 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/decrypt data locally within their applications. With HSM systems, PKCS#11 integration is, usually, the required approach.

Common BYOK misperceptions

Customers frequently misunderstand the purpose of BYOK in AWS KMS. Whether you import a key into KMS or natively generate it in KMS, the service applies safeguards that ensure that KMS will only decrypt data that KMS has generated.

These security safeguards allow AWS KMS to consistently and reliably enforce your policies and restrictions, so you can be confident in using and controlling your encryption keys.

One side effect of these restrictions is that you cannot directly transfer ciphertext between AWS KMS and on-premises cryptographic systems. Applications can encrypt the same plaintext in each environment—such as an on-premises data center—using an appropriate key. The AWS Encryption SDK uses key rings, a tool that will simplify managing multiple keys that encrypt equivalent copies of the data. Alternatively, you can migrate by re-encrypting data keys in KMS if you use envelope encryption; or by re-encrypting data entirely using server-side encryption with KMS’ keys and policies of your choice.

The second side effect of these restrictions is that you cannot use BYOK to exchange master keys between an external partner and your application. For secure key exchange, where keys must reside on an HSM at all times, you have the following options:

  • Have the partner establish an AWS account or workload, create and share an AWS KMS key with them. Usage is logged in both accounts and ciphertext is interoperable across applications.
  • Use CloudHSM directly.
Figure 2: AWS options for key management

Figure 2: AWS options for key management

Why doesn’t AWS KMS support portable ciphertext?

Similar to your on-premises environment, one of the AWS KMS’ security properties is that its keys never leave the FIPS 140-2 HSM boundary. This property is designed to ensure you can’t lose control of your encryption keys when KMS manages them and that only KMS can decrypt your KMS-encrypted data. This process enforces your key and resource access policies consistently and reliably; it ensures that KMS verifies the encryption contexts you create. It also guarantees auditability of your cryptographic operations: that all encryption key operations (generate a key, encrypt, decrypt, sign and verify) that occur in KMS are detailed in your CloudTrail logs. Finally, this security property protects against arbitrary encryption or decryption attacks from the outside. AWS’ Implementation of these security constraints requires you to re-encrypt data for native 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 necessary for KMS to perform decryption, such as the version of the key used to encrypt the data. Additionally, the 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 may be impossible to decrypt one with the other. In general, you should assume that only KMS can decrypt ciphertexts it makes.

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

Because of these safeguards, AWS KMS keys, when used with other AWS services—such as Amazon Simple Storage Service (Amazon S3) and Amazon Elastic Block Store (Amazon EBS)—, have a low risk of encryption key exhaustion as AWS services don’t offer visibility into ciphertext, and data encryption keys are always different. For example, Amazon S3 objects and Amazon EBS volumes have unique data encryption keys.

Selecting the correct path

When choosing a cryptography service offering from AWS, we recommend using native AWS KMS encryption whenever possible and encrypting data using server-side encryption. This pattern allows you to focus on your application and rely on AWS to perform the work, maintain service availability, key hierarchy management, the actual encryption process—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, KMS changes keys annually and will track versions of the encryption keys you used to encrypt your data to select the correct one for decrypt operations.

If you are required to generate your encryption key material and have provable encryption key entropy, you can use AWS KMS import key feature. With imported keys, encryption key rotation and security shifts to your part of the shared responsibility model. AWS doesn’t persist your imported encryption key material to any storage medium, so you must ensure that you have a backup for recovery if there’s a complete power loss.

If you have a mandate for FIPS 140-2 Level 3 compliance or are required to show that your cryptographic system is a single-tenant environment, you can use the AWS KMS custom key store backed by CloudHSM. In this design pattern, you can use all AWS services designed to work with KMS and have CloudHSM perform cryptographic operations.

For complete ciphertext portability, FIPS 140-2 Level 3 compliance requirements, and solutions that require a PKCS #11 interface, CloudHSM is the right choice. CloudHSM is a FIPS 140-2 Level 3 validated service that has native support for PKCS #11 interface. To enable ciphertext portability between CloudHSM and another system, you must synchronize encryption keys between multiple HSMs via a wrapping and unwrapping process or through a custom PKCS #11 code.

With AWS KMS, you also gain an additional AWS Identity and Access Management (IAM) authorization layer where read access to data and permissions to decrypt are needed to access plaintext. If you manage encryption key access permissions through IAM in addition to your data access, you may find it easier to implement separation of duties and containment plans.

For example, as an additional control, by applying IAM and AWS KMS resource policies, you can prevent an identity that writes data from reading it.

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

Review hierarchy, encryption, and decryption

To demonstrate, let’s look at how AWS KMS encrypts customer data and illustrate some elements of its cryptographic operations. More details are available in the AWS Key Management Service whitepaper.

AWS KMS key hierarchy

The fundamental purpose of KMS is to securely create, provide, and protect data keys. AWS KMS uses encryption key hierarchy to protect your data. Key types can be a key-encryption key or data encryption key.

When you create an AWS KMS symmetric key:

  1. AWS KMS generates key metadata—key ID, key version, ARN, and alias. While key ID is unique to the AWS Region where you create your KMS key. You can use the same alias in multiple Regions.
  2. AWS KMS creates an HSM backing key (HBK)—a 256-bit Advanced Encryption Standard (AES) key.

With AWS KMS, you can use one of three ways to create an HBK:

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

Encryption and decryption process for AWS KMS

Knowledge of how AWS KMS uses HBK and data keys will give you the power to use the technology in your implementations successfully. The following sequence illustrates encryption and decryption operations

During an encrypt operation, AWS KMS:

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

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

During a decrypt operation, AWS KMS:

  1. Opens the message.
  2. Verifies the message signature. If the verification fails, the operation fails.
  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 using the key ID and key version.
  5. Uses the HBK and the random value to re-create the data encryption key using the reverse of NIST 800-108 key derivation function.
  6. Decrypts the data.

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

Encryption and decryption process for AWS KMS managed keys with custom key store

For AWS KMS custom key store, the process is similar to the one described in the preceding paragraph, with one exception:

HBK generation and storage, and data encryption and decryption occur on CloudHSM instead of AWS KMS service-managed HSMs, so you need to ensure adequate performance and availability. Also, KMS and CloudHSM integration has different performance characteristics than KMS services and requires a minimum of two CloudHSM devices in separate Availability Zones.

Takeaways

Developing your application to take advantage of cloud-native encryption will typically pay dividends in the form of easier operations, better performance, and more straightforward, more robust access control. When deciding how to deploy AWS KMS and which options to use, remember that:

  • AWS KMS uses key material—HBK—not for data encryption, but to derive a one-time encryption key. The benefit of the BYOK process is limited to compliance, where you need to prove a reliable key entropy process. As BYOK keys aren’t used for your data encryption in KMS, but to encrypt other keys, you cannot decrypt ciphertext that you create externally with the imported equivalent of that key in KMS—and vice versa. Similarly, if you import the same key into KMS individually and into different Regions, the resultant ciphertext won’t be identical or interoperable due to region information being a part of the metadata included in KMS’ message format.
  • AWS KMS incorporates safeguards designed to prevent misuse and overuse of your keys. KMS always uses HBK and unique randomness for each transaction. Even multiple calls to KMS to encrypt the same plaintext with the same key result in different ciphertexts. Additionally, KMS ciphertexts include integrity checks, so it won’t attempt to decrypt arbitrary data—this protects keys from brute force discovery attacks. These safeguards are why you cannot interoperate ciphertext inside and outside of KMS. For hybrid deployment or cross-regional deployments in AWS, you can—and should—re-encrypt data using keys and formats appropriate to wherever your data lives.
  • The benefit of AWS KMS custom key store is limited to compliance where you require FIPS 140-2 Level 3 HSM or encryption key isolation. KMS custom key store inherently incurs the penalty of running a CloudHSM cluster, where responsibility for performance, monitoring, and user administration shifts to your side of the shared responsibility model.

Conclusion

When you design your encryption scheme, we recommend considering AWS KMS service first and using it whenever possible. KMS can help you to integrate and manage your encryption in a secure, reliable, and highly available way. Also, because other AWS services use KMS for encryption, you have one place to manage your encryption keys, security policies, and access logs. If you have specialized compliance (such as FIPS 140-2 Level 3, or single tenancy) or development requirements (such as PKCS #11), BYOK, AWS CloudHSM, and AWS KMS custom key store options are available.

To learn more, you can review additional content such as AWS KMS Cryptographic Details whitepaper, AWS Key Management Service Best Practices, 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.

Author

Arthur Mnev

Arthur is a Senior Specialist Security Architect for Global Accounts. He spends his day working with customers and designing innovative approaches to help customers move forward with their initiatives, increase their security posture, and reduce security risks in their cloud journeys. Outside of work, Arthur enjoys being a father, skiing, scuba diving, and Krav Maga.