By Scott Arciszewski

This post, part of a series on cryptography in the cloud, provides an overview of the cloud cryptography services offered within Amazon Web Services (AWS): when to use them, when not to use them, and important usage considerations. Stay tuned for future posts covering other cloud services.

At Trail of Bits, we frequently encounter products and services that make use of cloud providers’ cryptography offerings to satisfy their security goals. However, some cloud providers’ cryptography tools and services have opaque names or non-obvious use cases. This is particularly true for AWS, whose huge variety of services are tailored for a multitude of use cases but can be overwhelming for developers with limited experience. This guide—informed by Trail of Bits’ extensive auditing experience as well as my own experience as a developer at AWS—dives into the differences between these services and explains important considerations, helping you choose the right solution to enhance your project’s security.

Introduction

The cryptography offered by cloud computing providers can be parceled into two broad categories with some overlap: cryptography services and client-side cryptography software. In the case of AWS, the demarcation between the two is mostly clear.

By client-side, we mean that the service runs in your application (the client), rather than in the Service in question. This doesn’t mean that the service necessarily runs in a web browser or on your users’ devices. Even if the client is running on a virtual machine in EC2, the cryptography is not happening at the back-end service level, and is therefore client-side.

Some examples of AWS cryptography services include the Key Management Service (KMS) and Cloud Hardware Security Module (CloudHSM). In the other corner, AWS’s client-side cryptography software (i.e., tools) includes the AWS Encryption SDK, the AWS Database Encryption SDK, and the S3 Encryption Client.

One product from AWS that blurs the line between both categories is the Cryptographic Computing for Clean Rooms (C3R): a client-side tool tightly integrated into the AWS Clean Rooms service. Another is Secrets Manager, which runs client-side but is its own service. (Some powerful features that use cryptography, such as AWS Nitro, will be explored in detail in a future blog post.)

Let’s explore some of these AWS offerings, including when they’re the most useful and some sharp edges that we often discover in our audits.

AWS cryptography services

AWS CloudHSM

You want to use CloudHSM: If industry or government regulations require you to use an HSM directly for a specific use case. Otherwise, prioritize KMS.

You don’t want to use CloudHSM: If KMS is acceptable instead.

CloudHSM is simply an AWS-provisioned HSM accessible in your cloud environment. If you don’t have a legal requirement to use an HSM directly in your architecture, you can skip CloudHSM entirely.

AWS KMS

You want to use KMS: Any time you use Amazon’s services (even non-cryptographic services) or client-side libraries.

You don’t want to use KMS: For encrypting or decrypting large messages (use key-wrapping with KMS instead).

AWS KMS can be thought of as a usability wrapper around FIPS-validated HSMs. It offers digital signatures, symmetric HMAC, and encryption/decryption capabilities with keys that never leave the HSM. However, KMS encryption is intended for key-wrapping in an envelope encryption setup, rather than for the actual encryption or decryption of your actual data.

One important, but under-emphasized, feature of KMS is Encryption Context. When you pass Encryption Context to KMS during an Encrypt call, it logs the Encryption Context in CloudTrail, and the encrypted data is valid only if the identical Encryption Context is provided on the later Decrypt call.

It’s important to note that the Encryption Context is not stored as part of the encrypted data in KMS. If you’re working with KMS directly, you’re responsible for storing and managing this additional data.

Both considerations are solvable by using client-side software for AWS, which are discussed below.

Recently, KMS added support for external key stores, where KMS will call an HSM in your data center as part of its normal operation. This feature exists to comply with some countries’ data sovereignty requirements, and should be used only if legally required. What you gain in compliance with this feature, you lose in durability, availability, and performance. It’s generally not worth the trade-off.

AWS client-side cryptography software

AWS Encryption SDK

You want to use the AWS Encryption SDK: For encrypting arbitrary-length secrets in a cloud-based application.

You don’t want to use the AWS Encryption SDK: If you’re working with encrypting data for relational or NoSQL databases. The AWS Database Encryption SDK should be used instead.

The AWS Encryption SDK is a general-purpose encryption utility for applications running in the cloud. Its feature set can be as simple as “wraps KMS to encrypt blobs of text” with no further considerations, if that’s all you need, or as flexible as supporting hierarchical key management to minimize network calls to KMS in a multi-keyring setup.

Regardless of how your cryptographic materials are managed, the AWS Encryption SDK stores the Encryption Context passed to KMS in the encrypted message header, so you don’t need to remember to store it separately.

Additionally, if you use an Algorithm Suite that includes ECDSA, it will generate an ephemeral keypair for each message, and the public key will be stored in the Encryption Context. This has two implications:

1. Because Encryption Context is logged in CloudTrail by KMS, service operators can track the flow of messages through their fleet without ever decrypting them.
2. Because each ECDSA keypair is used only once and then the secret key discarded, you can guarantee that a given message was never mutated after its creation, even if multiple keyrings are used.

One important consideration for AWS Encryption SDK users is to ensure that you’re specifying your wrapping keys and not using KMS Discovery. Discovery is an anti-pattern that exists only for backwards compatibility.

If you’re not using the hierarchical keyring, you’ll also want to look at data key caching to reduce the number of KMS calls and reduce latency in your cloud applications.

AWS Database Encryption SDK

You want to use the AWS Database Encryption SDK: If you’re storing sensitive data in a database, and would prefer to never reveal plaintext to the database.

You don’t want to use the AWS Database Encryption SDK: If you’re not doing the above.

As of this writing, the AWS Database Encryption SDK exists only for DynamoDB in Java. The documentation implies that support for more languages and database back ends is coming in the future.

The AWS Database Encryption SDK (DB-ESDK) is the successor to the DynamoDB Encryption Client. Although it is backwards compatible, the new message format offers significant improvements and the ability to perform queries against encrypted fields without revealing your plaintext to the database service, using a mechanism called Beacons.

At their core, Beacons are a truncated instance of the HMAC function. Given the same key and plaintext, HMAC is deterministic. If you truncate the output of the HMAC to a few bits, you can reduce the lookup time from a full table scan to a small, tolerable number of false positives.

Extra caution should be taken when using Beacons. If you cut them too short, you can waste a lot of resources on false positive rejection. If you don’t cut them short enough, an attacker with access to your encrypted database may be able to infer relationships between the beacons—and, in turn, the plaintext values they were calculated from. (Note that the risk of relationship leakage isn’t unique to Beacons, but to any techniques that allow an encrypted database to be queried.)

AWS provides guidance for planning your Beacons, based on the birthday bound of PRFs to ensure a healthy distribution of false positives in a dataset.

Disclaimer: I designed the cryptography used by the AWS Database Encryption SDK while employed at Amazon.

Other libraries and services

AWS Secrets Manager

You want to use AWS Secrets Manager: If you need to manage and rotate service passwords (e.g., to access a relational database).

You don’t want to use AWS Secrets Manager: If you’re looking to store your online banking passwords.

AWS Secrets Manager can be thought of as a password manager like 1Password, but intended for cloud applications. Unlike consumer-facing password managers, Secrets Manager’s security model is predicated on access to AWS credentials rather than a master password or other client-managed secret. Furthermore, your secrets are versioned to prevent operational issues during rotation.

Secrets Manager can be configured to automatically rotate some AWS passwords at a regular interval.

In addition to database credentials, AWS Secrets Manager can be used for API keys and other sensitive values that might otherwise be committed into source code.

AWS Cryptographic Computing for Clean Rooms (C3R)

You want to use AWS C3R: If you and several industry partners want to figure out how many database entries you have in common without revealing the contents of your exclusive database entries to each other.

You don’t want to use AWS C3R: If you’re not doing that.

C3R uses server-aided Private Set Intersection to allow multiple participants to figure out how many records they have in common, without revealing unrelated records to each other.

For example: If two or more medical providers wanted to figure out if they have any patients in common (i.e., because they provide services that are not clinically safe together, but are generally safe separately), they could use C3R to calculate the intersection of their private sets and not violate the privacy of the patients that only one provider services.

The main downside of C3R is that it has a rather narrow use-case.

Wrapping up

We hope that this brief overview has clarified some of AWS’s cryptography offerings and will help you choose the best one for your project. Stay tuned for upcoming posts in this blog series that will cover other cloud cryptography services!

In the meantime, if you’d like a deeper dive into these products and services to evaluate whether they’re appropriate for your security goals, feel free to contact our cryptography team. We regularly hold office hours, where we schedule around an hour to give you a chance to meet with our cryptographers and ask any questions.

*** This is a Security Bloggers Network syndicated blog from Trail of Bits Blog authored by Trail of Bits. Read the original post at: https://blog.trailofbits.com/2024/02/14/cloud-cryptography-demystified-amazon-web-services/