What are the threats in letting an AWS service manage the encryption of your data instead of creating a Customer Managed Key?

That's the sort of question I get asked a lot. I've built a threat model for AWS KMS symmetric keys. Although when looking at the threat model using trust boundary lenses there aren't major differences, in AWS KMS' threat model between symmetric, asymmetric and signing keys.

I've focused on symmetric keys. We'll start with how AWS KMS works, then jump straight into an attack tree. The attack tree will walk us through the threats and mitigations that all different options of managing a key gets you. From what happens when an adversary gets physical access to what happens when an AWS region is down. However, I'm going to take it a step further and draw the trust boundaries between all the components on a typical workload. You can find all diagrams in this repo. If you have any recommendations feel free to open a PR, or raise an issue.

Let's start with how AWS KMS works. I'll be using the terms 'you' and 'the customer' interchangeably.

Basic concepts

Most AWS products will give you a couple of options when it comes to encrypting data at rest. Using DynamoDB as an example, we have three options:

1. AWS owns and manages the key. You have no visibility of any of this, it happens transparently. This is an AWS Owned Key.
2. AWS managed key. You have visibility of the key. You cannot edit the key policy, and CloudTrail won't tell you when the key was used. Normally services will create this key on your behalf. This is an AWS managed key.
3. You own the key. You have visibility of the key, you can edit the key policy and have CloudTrail visibility of when the key is used. This is a Customer Managed Key (CMK).

AWS publishes a handy list of the services that integrate with AWS KMS. If a service - like DynamoDB - integrates with AWS KMS then we can expect that these keys are backed by an HSM (Hardware Security Module) and interfaced through the AWS KMS service.

The keys that exist within the HSM are a Domain Key and an HBK (HSM Backed Key). The DomainKey lives in the HSM, never leaves the HSM and exists so that it can encrypt the HBK, so that the HBK can move around to other storage.

The diagram below, courtesy of AWS crypto details paper, shows the logical hierarchy of keys. After the HBK, it's the customer's part of the envelope encryption that you might be familiar with.

The CDK (Customer Data Key) derived from the HBK is returned in CT (CipherText) or plaintext.



HSM Key Hierarchy, courtesy of AWS KMS crypto details.
 

Here's what we can imagine the high level journey of encrypting data for use outside of AWS, using AWS KMS with a customer managed key would look like:

 

1. Create a customer managed key, which creates an HBK, and get back the KeyId
2. Call the AWS KMS API to GenerateDataKey. Pass the KeyId
3. A CDK is created from the HBK
4. Three fields are returned. Confirmation of the KeyId, the encrypted CDK that we requested - using the HBK, and the plaintext CDK
5. We encrypt using the plaintext CDK
6. We store the encrypted CDK
7. We destroy the plaintext CDK

From the workflow above we can see that your choices start with the HBK.

I've ranked the key management options from least customer responsibility to most customer responsibility.

You can use:  

1. An AWS shared HSM, this is your 'standard' KMS key
2. An AWS dedicated HSM ,  CloudHSM
3. Your own HSM - Host Your Own Key (HYOK) 

If you go with the first option - AWS Shared HSM:  

• You can let a service own and manage the key
• You can let an AWS Service manage the key and its policy on your behalf
• You can add your own key material - Bring Your Own Key (BYOK)
• You can manage the key and its policy

In all other cases of HBK you get a customer managed key. For the rest of this article, I will pretend that AWS owned keys don't exist. The customer has no visibility or control of either the keys, or the actions performed with them.

For a lot more in depth information, I suggest reading the below two articles:

• Demystifying KMS keys operations, bring your own key (BYOK), custom key store, and ciphertext portability
• Introduction to the cryptographic details of AWS KMS - AWS Key Management Service (amazon.com)

 

Attack Trees

This is the attack tree for AWS KMS.



Things that I have implied and have excluded:

• Malicious AWS staff/insiders . There are no mechanisms for anyone, including AWS service operators, to export or view the key material or HSM encryption keys in plaintext. - https://docs.aws.amazon.com/kms/latest/developerguide/data-protection.html . The HSM's are managed by AWS' supplier https://www.marvell.com/products/security-solutions/nitrox-hs-adapters.html
• Other crypto and process threats. For example, what happens during the replication of a multi-region KMS key
• The complexity of IAM policies and grants. I've grouped the scenarios under 'KMS policy is overly permissive'
• Auditors are not part of this threat model

It otherwise aims to be exhaustive, including availability and durability threats. The main goals are data loss and data compromise. 

Gray = fact, pink = threat and blue = mitigation. I've used deciduous.app, and I quite like the result.

The Trust Boundary model

While walking through the attack trees is useful, it helps to build a different perspective by understanding the trust boundaries of the service. This way we can build a mental model about where we draw the line of trust. It's a more compact representation based in an imaginary application that is composed of a Lambda function inside a VPC that encrypts/decrypts data and stores them in another AWS Service inside the same AWS account. 
 
We can then dig deeper on where we stand on the shared responsibility model and be able to answer questions like, 'if we must have BYOK, can we ensure the availability in an AWS Shared HSM?'.

This threat model is not exhaustive, it's component based, and it mostly focuses on rationalising the trust boundaries of the Customer, AWS, and of course KMS. It combines all AWS KMS options available to customers and the newly announced Host Your Own Key (HYOK).

Threat references

The 'root' threats are the same to the ones in the attack tree, but grouped when it comes to availability threats - in order to aid the visualisation. Let's break down the threat models, to the customer's respective choices.

AWS Managed Keys

The trust boundary here between KMS and the AWS Service is one and the same, since this is managed options, the customer has no responsibility or say in this configuration. Looking at T02 - If the service or the data gets compromised, the customer doesn't have sufficient control in mitigating. Looking at T01 - if someone grabbed a hard disk from an AWS datacentre, they would still get encrypted data.

AWS Customer Managed Keys - Shared HSM

Here looking at T02 the customer has control over the key policies. Therefore, a trust distinction from a customer's perspective can be made between AWS KMS and the customer's AWS account. The customer will end up with a Customer Managed Key, in most cases.

BYOK

This BYOK method is based on importing key material directly to an AWS KMS key. With BYOK, the customer is now responsible for providing the key material to KMS. This means that the AWS KMS trust extends to whatever is providing the key material. The new threat , T09,  is about availability and durability. In an AWS region-wide event, the customer is now responsible for the availability of the key. AWS would store your key in volatile memory, you must have your key material available to be re-imported.

CloudHSM

CloudHSM places the responsibility on the customer on managing a dedicated HSM, again availability threats emerge from taking over that responsibility. Worth noting that you could also build a BYOK solution in AWS CloudHSM. In this model you trust AWS to provision your HSM, and the HSM vendor to manage the physical infrastructure. However, the customer is responsible for the availability and durability of the HSM, and the HSM backed keys.

HYOK

In HYOK, AWS KMS and the customer's HSM, is responsible for encrypting the data key. The data key is double encrypted and as with each encrypt operation, each decrypt operation would require a call to the customer's HSM. The availability threat here is amplified, as the connection between AWS KMS and the customer's HSM is what keeps the data alive. Another threat on this model, T08, is that of AWS caching for longer than necessary or not destroying the plaintext data key in time. If you trust AWS with not caching the key for longer than necessary, what happens when a compelled access request takes place? Since it's KMS generating the decryption request, you wouldn't be able to differentiate between a normal and a compelled access request. The key control is monitoring and canaries.

You need to establish a baseline of what normal looks like and create canaries around your data. So for example in S3 you'd create a an object in a bunch of buckets that should never get accessed by any of your workloads. If you get a KMS decrypt request for that object you now know that it's not you requesting access to the data.

A helpful flowchart

I would suggest expanding on the threat models above and establishing your trust boundaries. If you take nothing else from this, I've also created a flow diagram to help you decide from a trusted perspective which of these models is adequate for you. Follow the path, and feel free to reach out.

 

AWS Systems Integration and Security Partner of the Year awarded to Airwalk Reply Read more