Encryption fundamentals with AWS KMS and CloudHSM
Graham Thompson · Tuesday, July 20th, 2021
This entry is based off a question I recently received in a recent Cloud Security Alliance course delivery. The student wanted to know about Government access to data that uses a Hardware Security Module (HSM) key that has been imported into the AWS KMS system.
As with many things cloud, the answer is “it depends”.
Read on…
Encryption options in AWS
First, we have to understand the encryption options for data at rest in AWS. There are three options for encryption:
Integrated: This system is fully managed by AWS. You simply check a box and your data is encrypted.
Customer Managed Keys with Key Management System (KMS): Allows for the customer to manage the encryption keys and assign usage/administrative permissions.
Hardware Security Module (HSM): Enterprise-class encryption key storage solution. FIPS 140-2 level 3 certified system. Widely considered the most secure key storage solution. The KMS system uses an HSM (more on this later) as the key storage location.
All of these systems use AES-256 encryption and are available to customers for encryption of data at rest so they can address security policies while using AWS. (I’m not going into in-transit encryption with s2n, an AWS proprietary implementation of TLS in this entry).
What is Integrated Encryption?
Let’s start the coverage of the different options with the integrated option.
As stated previously, the integrated option is a fully managed service by AWS and is also known as Server Side Encryption (SSE) with AWS managed keys. For example, in the S3 object storage system, this would be called SSE-S3.
You will also see this in EC2 volume storage as “aws/ebs” as the Master key that can be used to encrypt a volume. Every tenant gets their own keys (and different keys for different services), so it’s not like every AWS customer is using the same encryption key.
You can view the AWS managed keys in the KMS system (select the AWS managed keys section). The main difference between the “set it and forget it” integrated system and the KMS solution is all about management and control.
The benefit to using the integrated approach is ease and meeting compliance.
The disadvantage? If you want to restrict user access to encryption keys, AWS managed keys probably aren’t the right fit. Note: Access permissions to the data itself is dependent on resource policies (e.g. S3 bucket policies).
What is KMS and what are Customer Managed Keys?
The Key Management System (KMS) allows for the creation of your own Customer Managed keys, assign administrators and users and rotate keys manually (you can configure automatic key rotation to occur every year, but you may wish a different frequency). You can use let AWS generate the keys, or you can import your own (we’ll be getting to this shortly).
The nitty gritty technical discussion is really out of scope for this entry. You can read much, much more on everything KMS in the KMS developer guide at https://docs.aws.amazon.com/kms/latest/developerguide/overview.html.
Regardless of the origin source, KMS itself is backed by their own Amazon AWS Key Management Service HSM. This HSM is a FIPS 140-2 (level 2, with some components listed at level 3) certified hardware appliance.
What is CloudHSM?
When HSM was first made available in AWS, you had to purchase your own HSM via AWS (Safenet Luna was the product) and they would manage the device on your behalf. This is now known as the “classic” HSM and is no longer available to new customers. That said, I’m focusing on the newer CloudHSM offering, a virtual HSM backed by a physical HSM.
CloudHSM is a FIPS 140-2 (level 3) offering that is implemented in a VPC. This means it meets a very high bar as far as security standards are concerned. It has multiple physical and virtual safeguards to ensure tamper detection and countermeasures, including zeroizing of the key storage if it detects tampering.
CloudHSM is relatively expensive (a single HSM is more than $1,000/mth, a Customer Managed Key in KMS is $1/mth) and is a solution that is likely only used by very large enterprises. There’s more to CloudHSM than just encryption key storage, but since that’s the focus of this entry, I’ll just point you to the CloudHSM page at Amazon: https://aws.amazon.com/cloudhsm/ if you want to know about all the things CloudHSM can do.
For further info on KMS and HSM, check out the following AWS blog entry explaining both KMS and HSM at a high level: https://aws.amazon.com/blogs/security/importance-of-encryption-and-how-aws-can-help/
AWS access to KMS and CloudHSM
If you look for information on AWS access to encryption keys, you’ll be looking for a while. This is something that AWS doesn’t exactly promote in their documentation.
For example, there isn’t a hint in the KMS Developer Guide that AWS can access encryption keys (their internal controls require multi-party authorization) and use them in the event of a government warrant. Since the introduction of the CLOUD Act, this might be seen as a big issue for non-American companies as well.
On the other hand, AWS cannot, under any circumstances access customer keys held within CloudHSM.
To get a definitive Amazon statement that is publicly accessible, I had to resort to the following discussion forum entry (https://forums.aws.amazon.com/thread.jspa?messageID=603709򓘽). In the response, an AWS employee confirms the following:
“AWS Key Management Service (KMS) stores your master keys in hardened appliances, and Amazon’s access to the keys is controlled by quorum-based processes that are audited and reviewed. We will not disclose customer content unless required to do so to comply with a legally valid and binding order, such as a subpoena or a court order. Amazon is unable to access keys stored using AWS CloudHSM under any circumstances and has no way to comply with a request to provide master keys stored in CloudHSM appliances.”
Bring Your Own Key
The concept of Bring Your Own Key (BYOK) is brought up in both the Cloud Security Alliance Guidance, CCSK Training and CCSP Training. This is fairly straight-forward. BYOK allows you to upload keys so they can be used within KMS. If you want to play with this, there’s a step-by-step lab of sorts in the KMS Developers Guide (https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html)
Essentially, BYOK allows you to create an empty Customer Master Key and then fill it with your own key material. It is limited to symmetric keys and cannot be used with asymmetric keys.
What does this give you from a security perspective? Control over the key material and responsibility to manage the key. You also have the ability to immediately delete keys that you import.
Personally, I have doubt that an AES-256 key you create yourself in OpenSSL is inherently more secure than a key created by AWS. Further, since you are giving AWS a copy of the KMS key and it is being stored in the KMS HSM, AWS would have to provide it to Government in the case a legal warrant is issued.
Note: There are a lot of little “gotcha’s” that change the default behavior of the KMS system if you import your own keys. For example, key rotation isn’t performed on imported keys, that’s your responsibility if you decide to import your own keys. You really need to understand these changes as stated in the KMS Developer Guide before going down this route.
The benefit of BYOK is that you have control over the key material creation. The disadvantage is that you assume a lot more responsibility over management of the keys.
Custom Key Store
The final AWS encryption item to discuss is the Custom Key Store. The Custom Key Store is used to point the KMS system to use your CloudHSM implementation as the key location rather than the standard HSM used by the KMS system. This is described in the KMS FAQ (https://aws.amazon.com/kms/faqs/):
“You can configure your own CloudHSM cluster and authorize AWS KMS to use it as a dedicated key store for your keys rather than the default AWS KMS key store. When you create keys in AWS KMS you can chose to generate the key material in your CloudHSM cluster. CMKs that are generated in your custom key store never leave the HSMs in the CloudHSM cluster in plaintext and all AWS KMS operations that use those keys are only performed in your HSMs.”
The benefit of using the custom key store is that AWS has no ability to access keys stored in the CloudHSM, even if a warrant is issued. The disadvantage is the cost (approximately $24,000 a year for the recommended dual HSM approach).
Exporting keys from CloudHSM
However, keys can be also exported from Cloud HSM and stored in KMS. Why would companies do this? As stated before, AWS CloudHSM is very expensive. In this scenario, you generate the key in CloudHSM, have control over rotation and such, but as the key has been exported from a custom HSM and into KMS, AWS would theoretically have access and therefore can be compelled into accessing your data at rest if warranted. The following quote from an AWS blog on the matter shows why some may choose this approach:
“You can spin up an HSM device, create your key material, export it, import it into AWS KMS for use, and then terminate the HSM (since CloudHSM saves your HSM state using secure backups). Because you’re only billed for the time your HSM instance is active, you can perform all of these steps for less than $15.00 a year!”
The benefit of this approach is cost savings. The disadvantage of this approach is the keys are stored in KMS and can be accessed by AWS in response to a Government request for access to your data.
Conclusion and key takeaway
By default, strong enterprise-level CloudHSM can be used as a custom key store and these keys will never be accessible by AWS, and can never be used to access your data on behalf of a Government agency.
However, if technical staff doesn’t understand the governance impact of doing things “on the cheap”, they may unintentionally expose your company to substantial fines or penalties from a regulator.
It’s hard to blame someone from trying to do what they see as the right thing to do to save the company money. This is an example of what can happen when you don’t equip your people with the knowledge they need to properly architect and design a cloud infrastructure. Our CCSK certification and CCSP certification training solutions equip your staff with the tools they need to succeed.
Additional resource
I’ve always said that if you really want to understand how something works, read the documentation, especially API documentation.
Further in-depth technical reading on how AWS performs KMS encryption can be found at: https://boto3.amazonaws.com/v1/documentation/api/1.9.185/guide/kms-example-encrypt-decrypt-file.html
