In the following documentation, AWS refers to a concept called key material.
AWS KMS Documentation: Using a custom key store
AWS KMS supports custom key stores backed by AWS CloudHSM clusters. When you create an AWS KMS customer master key (CMK) in a custom key store, AWS KMS generates and stores non-extractable key material for the CMK in an AWS CloudHSM cluster that you own and manage.
Take an asymmetric encryption key pair in KMS as an example, what is key material? what is CMK? what's the difference between CMK and key material?
For asymmetric key, the "key material" would be your private key. You could generate it yourself using AWS CloudHSM Dynamic Engine if you were using your own CloudHSM cluster at AWS, not AWS-owned cluster used for KMS.
Since you are using KMS, you have no direct access to the private key as it is "non-extractable".
Customer master key (CMK) is an AWS resource allowing you to manage and indirectly use the key material (i.e. private key for asymmetric). So because you can't directly see nor operate on your private key, you use CMK resource to use it. Since CMK is a resource, it provides a lot of additional functionality build around the key material, such as:
automated key rotation
KMS key policies and IAM policies
transparent integration with numerous AWS services, such as S3, EBS, RDS,
and others.
CMK is the logical container, which contains:
key material, which is used to encrypt data and decrypt data.
key-id
ARN
other stuff.
Reference
https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#master_keys
AWS KMS is replacing the term customer master key (CMK) with AWS KMS key and KMS key. The concept has not changed. To prevent breaking changes, AWS KMS is keeping some variations of this term.
Related
I have a multi-region trail defined with Terraform that I'm trying to encrypt with KMS. My trail covers four AWS regions: us-east-1, us-west-2, eu-west-2, and eu-central-1 and I'm creating a KMS key for encrypting the log files and adding the appropriate permissions per the AWS docs. However, it's not clear whether or not this needs to be a multi-region key. If the KMS key I use needs to be multi-region, do I need to make a replica key for each additional region that my trail covers?
The docs say CloudTrail supports KMS multi-region keys, but the appropriate situation(s) to use MRKs w/ CloudTrail isn't straightforward. If I could get that far, then I do know that related MRKs do not share key policies and that I would need to define a specific policy for each should I need them.
It is not mandatory to use multi region keys with CloudTrail. When you configure a trail and want to encrypt the CloudTrail log files, you can use a single KMS key to encrypt the files. Just make sure the KMS key is in the same region as the S3 bucket where you're sending the log files to.
Can you please help me understand the meaning of sentence from KMS documentation
https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
automatic key rotation has no effect on the data that the KMS key protects.
It does not rotate the data keys that the KMS key generated
or re-encrypt any data protected by the KMS key,
**and it will not mitigate the effect of a compromised data key.**
what does
... it will not mitigate the effect of a compromised data key.
mean in this context.
I need to enable KMS Rotation in multiple repos and I want to be 100% sure
Your CMK can create data keys, which you can use outside of AWS to manually encrypt and decrypt your data. The important thing about data keys is that they are symmetric. Which means same key is used for encryption and decryption of a secret.
If AWS rotation happens, it affects only key material stored in KMS. Any data keys generated before that, are not affected as they are for external use and are symmetric. The rotation only applies to the keys stored in KMS itself, not to data keys that you generated and used outside of AWS.
So if anyone has your data key, it can be used to decrypt your secretes, as rotation do not apply to these keys.
"It does not mitigate the effect of compromised key means"
For understanding sake consider KMS Key is a logic unit of two components
1.Key attributes (Key metadata) - Key ID, Key Specification , Key Usage etc
2.Reference to Key material
(In essence a KMS key means these two things)
There are three types of KMS Keys.
AWS owned keys - used by AWS for internal purpose
AWS managed Keys - used by AWS services - only metadata can be accessed
AWS CMK Keys - Customer can control the key but is managed by AWS on behalf of the customer
Data keys are generated from AWS KMS CMK Keys.
Firstly we have to understand What are data keys and how they are generated ?
Ans: As known KMS Keys do not leave the KMS modules. So the maximum file can encrypt is of the only 4KB. To encrypt more data we will be using a data key that is generated form the KMS Keys. Using envelope encryption the data key encrypts the data objects in EBS or S3 while data key is encrypted by KMS Key and stored where the data is stored unlike KMS Keys that do not leave the AWS KMS HSM Modules.
Now in case of key-rotation you are changing the key material you are not changing the Key metadata nor reference to the key material i.e .AWS will decrypt the data key by the KMS Key that it was encrypted aka the previous version of the KMS Key. We cannot instruct a particular version of KMS Key.
I like to share the image across accounts but the image is encrypted with an AWS managed key and I was wondering how I can transfer this image to another account.
I gather an image encrypted with custome keys is transferrable, and is it the same with the image with an AWS key?
KMS
With KMS you have AWS Managed Key and Customer Managed Key (CMK).
To allow another account to use your key it needs to be a CMK, because you need to allow it on your key police.
https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html
You can't change police on AWS Managed Key. Which means you can't allow other accounts to use an AWS Managed Key.
So you can't share your encrypted AMI with another account when it is using AWS Managed Key.
AMI
An AMI can't be transferred, but you share it with another account. When it is encrypted you need to share the key as well. See documentation below.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html
As your current AMI is encrypted with AWS Managed Key, what you can do is create a new AMI without encryption or encrypted with CMK and share it. See documentation below.
https://aws.amazon.com/premiumsupport/knowledge-center/account-transfer-ec2-instance/
I'm using the tool created by aws at https://github.com/awslabs/aurora-snapshot-tool to copy aurora snapshots from one account to another account. However, I just don't understand what to enter for KmsKeySource & KmsKeyDestination while creating a destination account. I have checked the CMK pages mentioned on the site but still unable to understand. Could anyone give a clear explanation?
For KmsKeySource I have entered the CMK which my DB cluster is using in the Source account. Is it correct?
For aurora snapshot to be able to copy between accounts, you cannot use default AWS managed keys in KMS for at rest encryption, you need to create customer managed CMKs in KMS and use that CMK in your Aurora db at rest encryption. The KmsKeySource here means the kms cmk key id you use for source db, thats correct.
The KmsKeyDestination is only required if you are copying the snapshot between different AWS regions, as KMS CMKs are regional resources, you need to provide the destination region CMK key id if your source and target region are different. In such case AWS handling the copying of encrypted snapshot from region A to B, and re-encrypt it using region B's CMK.
If the source and target region are the same, then KmsKeyDestination is optional, as the target db can simply use the same CMK key as source, which is specified in KmsKeySource.
Question # 0: AWS console displays AWS managed keys and Customer Managed Keys; it doesn't display AWS owned CMKs as an item in the list. As per documentation, customers cannot view or manage AWS-owned CMKs. However, under AWS managed keys, I see keys that were not created by me either implicitly or explicitly. Particularly I see this key with the alias aws/dynamodb. When I created DynamoDB tables, I used default settings which means, it will use AWS-owned CMKs for encryption at rest. Does this mean, "aws/dynamodb" is an AWS-owned CMK? It is a bit ambiguous. Is there a field in aws kms describe-key that displays the type?
The default option in us-east-1 is AWS owned CMK
Question # 1: Other than rotation policy, ownership, and the cost, is there a fundamental difference in the way AWS-owned CMKs encrypt/decrypt data when compared to AWS-managed CMKs?
Question # 2: As per the documentation, AWS-owned CMK usage is not limited to one particular account, this means there is a possibility that AWS uses the same CMK across multiple different accounts Is this understanding correct?
Question # 3: What services besides DynamoDB use AWS-owned CMKs for encryption at rest? In the picture, I see some more keys, and those are corresponding services that I tried.
Appreciate any help. Thanks in advance.
Does this mean, "aws/dynamodb" is an AWS-owned CMK?
No. AWS-owned CMKs don't show in your KMS console. The aws/dynamodb is AWS-managed CMK which is not free. It is the second option in DynamoDB table creation:
Q1. From the cryptographic point of view there is not difference, at least I'm not aware of any. But practical difference is that you can't use AWS-owned CMKs on your own. You can't use it to decrypt/encrypt your own data using AWS CLI or SDK, as the CMK is only used by AWS. The other difference is that it can be easier to move encrypted data between accounts, as AWS will use same AWS owned key on both accounts, rather then you managing different keys on different accounts.
Q2. Yes, that's correct. AWS can re-use the same key for multiple customers.
Q3. I think S3 is the most common service using AWS-owned key SSE-S3.