Here is the encryption flow of Server-side encryption with S3 managed keys (SSE-S3)
(this picture is from Oreilly)
The client selects their object(s) to upload to S3 and indicates the encryption mechanism of SSE-S3 during this process.
S3 then takes control of the object and encrypts it with a plaintext data key that's generated by S3. The result is an encrypted version of the object, which is then stored within your chosen S3 bucket.
The plaintext data key that used to encrypt the object is then encrypted with an S3 master key, resulting in an encrypted version of the key. This now encrypted key is also stored on S3 and has an association to the encrypted data object. Finally, the plaintext data key is removed from memory in S3.
As you can see, SSE-S3 use a unique data key to encrypt the object, rather than the master key.
I heard a lot that SSE-KMS is envelope encryption, my question is:
Is SSE-S3 envelop encryption too?
Reference
Stack Overflow: Does AWS KMS use envelope encryption?
AWS KMS Envelope Encryption
AWS Encryption-At-Rest(server-side encryption) uses Envelope Encryption irrespective of what key is used. Not just for S3, for every service at AWS. Here is a nice blog about it.
Only difference is who manages data key and encryption key.
SSE-S3 Both keys are managed by AWS
SSE-KMS We manage CMK, where as AWS manages data key. Gives us more control on rotation, access, etc.
SSE-C We manage both encryption key and data key(we can choose to not use data key but use same key), we provide data key and algorithm, AWS encrypts for us and we need to keep track of which key is used for which object.
Related
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.
If the answer is no, how to deal with the data encryption when migrating your data from aws cloud to another cloud someday?
e.g. S3 object that has been encrypted by SSE-S3
Its not possible. From docs:
By default, AWS KMS creates the key material for a CMK. You cannot extract, export, view, or manage this key material.
The exception is when you import your own keys into KMS. Since you import the key material, you can use the same one in the other provider if it supports importing keys.
When you copy your objects to other storage provider, AWS will transparently decrypt them. The new provider will have to encrypt your data using their own keys.
So basically, the migration involves, decryption of your data, transfer of the data to a new provider, and encryption using a new key.
The only way to transport encrypted data from s3 is if you use SSE-C in S3, which stands for customer-provided encryption. In this case you are fully responsible for encryption and decryption of your files. AWS and the new provider only store the encrypted files:
Using server-side encryption with customer-provided encryption keys (SSE-C) allows you to set your own encryption keys.
Typically, data is not encrypted using the keys stored in a Key Management Service (KMS).
Instead, when a file needs to be encrypted:
A random encryption key is generated that is specific to that file only
The file is encrypted using that key
The key is then encrypted using the keys stored in the KMS and the encrypted key is stored with the encrypted data
Later, when the file needs to be decrypted:
The encrypted key is decrypted using the KMS
The file is decrypted using the decrypted key
Thus, if you wish to move encrypted data to a different system, you merely need to decrypt the file-specific encryption keys using the KMS and re-encrypt them using the new KMS. The encrypted files can then be copied to the new system without needing to be decrypted.
Here's a picture from Server-side encryption with KMS managed keys (SSE-KMS) - AWS Certified Solutions Architect - Associate Guide [Book]:
I am reading AWS encrypt cli document from https://docs.aws.amazon.com/cli/latest/reference/kms/encrypt.html and https://docs.aws.amazon.com/cli/latest/reference/kms/decrypt.html. I found that I am able to encrypt/decrypt without creating a data key. When I read https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html, it says that I need to use KMS CMK to generate a data key which is used to encrypt my data.
So I am confused about whether I need a data key at all?
CMK is designed to encrypt/decrypt the data keys. Therefore, there is a limit of 4 KB on the amount of plaintext that can be encrypted in a direct call to the encrypt function. You can easily test this by passing in message larger than 4 KB.
These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.
You are likely using a default CMK that was created by another AWS service that uses KMS encryption.
Of course all encryption and decryption operations require a key. If you did not explicitly create one for your application, then you are using the current default key.
Ensure that KMS Customer Master Keys (CMKs) are used by your AWS services and resources instead of default KMS keys, in order to have full control over data encryption/decryption process and meet compliance requirements. A KMS default master key is used by an AWS service such as RDS, EBS, Lambda, Elastic Transcoder, Redshift, SES, SQS, CloudWatch, EFS, S3 or Workspaces when no other key is defined to encrypt a resource for that service. The default key cannot be modified to ensure its availability, durability and security. On the other side, a KMS Customer Master Key (CMK) provides the ability to create, rotate, disable, enable and audit the encryption key used to protect the data.
See https://www.cloudconformity.com/knowledge-base/aws/KMS/default-key-usage.html
I'm writing a serverless function on AWS Lambda.
On certain instances I need to use kms:GenerateDataKey* permissions.
What exactly is the purpose of this. I checked the AWS documentation but it is too cryptic. Can someone give a practical example of where this is used?
A Lambda function that requires kms:GenerateDataKey permission is most likely encrypting large amounts of data using a symmetric data key.
kms:GenerateDataKey is used to implement envelope encryption, which is the process of encrypting a key with another key. Symmetric key algorithms are faster and produce smaller ciphertexts than public key algorithms, whereas public key algorithms provide inherent separation of roles and easier key management. Envelope encryption combines the strengths of each strategy.
Envelope Encryption in AWS
Create a Customer Master Key in KMS. Even though a CMK can be used to encrypt data up to 4K in size, it is primarily used to encrypt/decrypt data encryption keys.
Generate a Data Encryption Key - Used to encrypt data by using symmetric encryption algorithms.
Encrypt the data key by using the CMK.
Store encrypted data and encrypted data key together.
When a user calls kms:GenerateDataKey, KMS generates a data key, encrypts it with the CMK and finally returns plaintext and encrypted data key pair back (steps 2 & 3 above).
The user is responsible for managing these keys. Plaintext data key is usually discarded immediately after encrypting data, whereas encrypted data key is stored together with encrypted data. Data encryption key must be decrypted by using kms:decrypt before decrypting data.
I'm not familiar with permission itself, but I found this in the documentation:
From Using Key Policies in AWS KMS - AWS Key Management Service:
kms:GenerateDataKey* – Allows key users to successfully request data encryption keys (data keys) to use for client-side encryption. Key users can choose to receive two copies of the data key—one in plaintext form and one that is encrypted with this CMK—or to receive only the encrypted form of the data key.
When I SSE-S3 encrypt the bucket (objects) with AES256 and make it public. The contents of the bucket are visible. However, this is not the case with AWS KMS which throws the following error:
Requests specifying Server Side Encryption with AWS KMS managed keys require AWS Signature Version 4.
How is the end-user able to view the object in AES256 encrypted?
Use Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) – Each
object is encrypted with a unique key employing strong multi-factor
encryption. As an additional safeguard, it encrypts the key itself
with a master key that it regularly rotates. Amazon S3 server-side
encryption uses one of the strongest block ciphers available, 256-bit
Advanced Encryption Standard (AES-256), to encrypt your data.
According to this, my understanding is, if an object is encrypted it requires the decryption keys or in AWS world access to the key that is decrypting it. Please explain how AES256 is different from KMS. (Other than key policies provided by AWS on KMS)
Server-Side Encryption in S3 is always AES256, whether you are using SSE-S3 or SSE-KMS.
In both cases, S3 uses a key to transparently encrypt the object for storage and decrypt the object on request. The user accessing the object does not see the encrypted object in either case.
With SSE-S3, S3 owns and controls the keys, so permission to upload or download includes implicit permission for S3 to access the keys that it needs in order to access the object.
The level of encryption is the same whether you use SSE-S3 or SSE-KMS, but SSE-KMS imposes more stringent security constraints on accessing the objects, including mandatory use of HTTPS and Signature Version 4.