AWS S3 Server Side Encryption

An introduction to AWS S3 Server Side Security

There are two types of encryption mechanisms that you find within AWS S3.

1. Client side encryption — Data is encrypted in the client side before the encrypted data is transferred to the server side (S3). The total key management and the encryption process happens in the client side. Hence there is very limited responsibility to the S3 server side.
2. Server side encryption — The data is encrypted in the server side.

This blog primarily will discuss S3 Server Side Encryption aspects.

S3 Server Side Encryption

There are three types of S3 server side encryption methods (See figure 01).

1. Server side encryption with Customer Provided Keys (SSE-C)
2. Server side encryption with AWS S3 Managed Keys (SSE-S3)
3. Server side encryption with AWS KMS (SSE-KMS) — This further can be divided into two more methods. (AWS Manged CMK and Customer Managed CMK)

Figure 01 — S3 SSE Encryption Methods

Lets dive into all three methods now.

SSE with Client Managed Keys (SSE-C)

In this method, the client keeps the overhead of the key management, and S3 will keep the overhead of the encryption process.

figure 02 — SSE-C Encryption

• The client application needs to provide the unencrypted object and the “encryption key” to S3.
• S3 then uses the “encryption key” to encrypt the object and discards the “encryption key”.
• Before being discarded, the “encryption key” is hashed and stored along with the encrypted object.

Later, if you need to decrypt the object, you need to provide the same “encryption key” again from the client end, since it was initially discarded within S3. Hash is there to verify the encryption key provided.

SSE with S3 Managed Keys (SSE-S3)

figure 03 — SSE-S3 Encryption

In this method, S3 will handle both the key management and the encryption process.

The encryption happens with the help of the AWS S3 generated “root/master key”, which is fully governed by AWS S3.

• This AWS S3 “root/master key” generates a separate “Data Key” for each object, which is uploaded to S3.
• The “Data Key” is used to encrypt the object
• AWS S3 “root/master key is used to encrypt the “Data Key”
• Then both the “encrypted object” and the “encrypted Data Key” are stored alongside in the S3 storage.
• The “Data Key”, which was generated is then discarded just after the encryption process.
• Since this is a symmetric encryption, the decryption of the object is possible by using the AWS S3 “root/master key”. AWS S3 “root/master key” is used to decrypt the encrypted “Data Key”, which then can be used to decrypt the object.

SSE-S3 is the default S3 encryption method for all S3 objects being stored and it uses a strong encryption algorithm, which is AES256.

Though this is the default S3 encryption method, this has a few limitations especially if you adopt into a more regulatory environment such as Government, where Data Protection is a key aspect.

These limitations can be listed as follows.

1. Both the “master/root key” and the respective data keys are fully managed by AWS and the users have no control over them. In a typical regulatory environment, this is an obvious issue.
2. Rotation of keys is not possible — This is a possible security risk in the long run.
3. Role separation is not possible — In SSE-S3, a system administrator who has the S3 full access can decrypt the data easily. That means, with this, you cannot restrict system administrators not to have the decryption ability. This is a serious concern especially in a regulatory environment.

SSE with AWS KMS Keys (SSE-KMS)

figure 04 — SSE-KMS Encryption

In this method, AWS delegates the “root/master key” to AWS “KMS key” (See figure 04) allowing to have a more flexible solution in terms of overcoming some of the shortcomings which were discussed before.

• AWS “KMS key” can generate a unique “Data Key” to encrypt each object that is uploaded to S3. This is quite similar to SSE-S3 method but it basically replaces the SSE-S3 “root/master key” with the AWS “KMS key”.
• With the AWS “KMS Key” approach, you have the ability to create your own “KMS Key”, which is known as the “Customer Managed CMK”. That will basically enable you to apply permissions, rotate keys and have robust role separation.
• The role separation for the AWS “KMS Key” can be done by limiting the AWS administrator role for the assigned AWS “KMS Key”. For more details on how AWS KMS handles its operations please refer to my blog here. [1].

The default bucket level encryption

• If you do specify an encryption method at the bucket level, that encryption method will be taken as the default encryption method if you do not specify a method at the object level.
• If you specify an encryption method at the object level, then that will be taken as the encryption method overriding the default bucket setting.

Conclusion

The above explanation will help anyone who wants to know how SSE-C, SSE-S3 and SSE-KMS differs from each other. Though this is a simple comparison, I can see many gets mixed up with the concepts regularly. Therefore, as cloud architects, it is very important for us to understand these simple concepts when we dive into more serious ones.

Thank You!

References

1. AWS KMS: https://crishantha.medium.com/aws-kms-4cb9bb80c89