AWS Encryption types
Notes on encryption types in AWS (server-side, client-side, KMS, etc.) and how it works. Trying to keep it simple, but it’s not a simple subject.
All the different types of Encryption in AWS come down to a combincation of two factors:
- Encryption process, where it is done, server-side or client-side
- Server-side means AWS encrypts and decrypts.
- Client-side means the object is sent to AWS already encrypted.
- Encryption key, where it’s stored and how it’s managed:
- Fully managed by the client, either on their side or using HSM
- Managed using KMS, either by the client or by AWS. For example, an RDS instance can be encrypted:
- With a custom KMS key generated by the client, in which case the client has granular control over who can use the key and how.
- With the
aws\rds key that is automatically created in every account. The key is controlled and managed by AWS as needed, the client can see its ID, but that’s it.
- Fully managed by AWS. For example AWS SSE-S3 encryption, which uses a key stored and managed on AWS side, client doesn’t have any kind of access to it.
Depending on the combination of the above the encryption process either involved envelope enryption or not. Envelope encryption is explained below.
Envelope encryption basically means using a separate key for each object, but each of those keys is also encrypted using a single master key. In order to decrypt the object, the key used on it must be decrypted first, which in turn means that access to the master key is needed.
Let’s say we want to encrypt then decrypt some files. An encryption key is created to be used as master_key. Amazon also refer to this as a “customer master key”, or CMK. Access to this key is needed in order to decrypt the files. Once we have the key, encryption follows some steps:
- Create another encryption key, called a data_key.
- Encrypt file with the data_key, resulting in encrypted_file.
- Encrypt the data_key with the master_key, resulting in an encrypted_data_key
- Discard the data_key. This is important. After this step we’re left with the master_key, the encrypted_file and the encrypted_data_key. The only unencrypted bit is the master key, so in order to decrypt, access to the master key is required.
- Store encrypted_file together with encrypted_data_key. Repeat steps 1 to 5 for each file.
When the files are decrypted, the process is basically reversed:
- Retrieve encrypted_file and encrypted_data_key.
- Decrypt encrypted_data_key with master_key, resulting in data_key.
- Decrypt encrypted_file with data_key, resulting in file.
- Discard data_key.
Encryption is done by the client prior to sending the object to AWS. The AWS documentation has details, but there are basically two cases.
- The encryption key is stored in KMS and provided to the client on request. Provides key management and audit through CloudTrail, but the fact that the key is stored on AWS can be regarded as a risk from a security standpoint.
- Customer provided key. The key (client-side key) is managed by the customer and never sent to Amazon. Data is encrypted on the client side, so unencrypted data is never sent to Amazon.
The AWS SDKs, or at least the Java one, provide functions for easy access to envelope encryption when using the client-side options.
Encryption is done by AWS. The client sends the text or object to be encrypted, the key is provided either by the client or an AWS service. In cases where the object is stored on AWS, decryption is done automatically provided the client has access. Compute cycles needed for encryption/decryption are spent by Amazon instead of the client.
Server-Side Encryption with Client-Provided Key (SSE-C)
- The key is managed by the client
- The client provides the key in the encryption request. It doesn’t involve envelope encryption, the provided encryption key is used directly. Similarily, the key will have to be provided in order to decrypt.
- Encryption key is not stored by AWS. A randomly salted HMAC value of the key is saved together with the encrypted object, in order to validate future requests.
- Cloud HSM can be used to manage encryption keys.
Server-Side Encryption with KMS-Managed Key
- Goes through the envelope encryption process.
- Encryption key is managed in KMS.
- Multiple master keys can be used and stored in KMS.
- Access to a KMS key is subject to IAM policies and can be used as an additional layer of control. For example, in order to read the data contained in an object stored in an S3 bucket using KMS encryption, the user would have to (1) have access to the object and (2) have access to the KMS key in order to decrypt the object contents.
- Master keys (as opposed to data keys) never leave KMS, they are never seen. So, for example, there is no need to rotate keys when an employee leaves the business, since there is no way for the employee to get the key.
- All access to keys is logged in CloudTrail, so an audit log can be provided.
Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3)
- Goes through the envelope encryption process.
- Master key is managed by Amazon’s S3 service, with no involvement from the client.
- Data is encrypted and decrypted transparently for users that are procvided access to that data via IAM policies.