In this blog, we are going to learn what is AWS S3 Encryption? What are it’s types? And Comparison between different AWS S3 Encryption types. S3 supports both client side encryption and server side encryption for protecting data at rest.
Using Server-Side Encryption, S3 encrypts the object before saving it on disks in its data centers and decrypt it when the objects are downloaded
Using Client-Side Encryption, data is encrypted at client-side and uploaded to S3. In this case, the encryption process, the encryption keys, and related tools are managed by the user.
Server-Side Encryption:
Server-side encryption is about data encryption at rest.
Server-side encryption encrypts only the object data. Any object metadata is not encrypted.
S3 handles the encryption (as it writes to disks) and decryption (when objects are accessed) of the data objects.
There is no difference in the access mechanism for both encrypted or unencrypted objects and is handled transparently by S3.
- Server-Side Encryption with S3-Managed Keys (SSE-S3)
- Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS)
- Server-Side Encryption with Customer-Provided Keys (SSE-C)
1) Server-Side Encryption with S3-Managed Keys (SSE-S3):
Each object is encrypted with a unique data key employing strong multi-factor encryption.
SSE-S3 encrypts the data key with a master key that is regularly rotated.
S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt the data.
Whether or not objects are encrypted with SSE-S3 can’t be enforced when they are uploaded using pre-signed URLs, because the only way server-side encryption can be specified is through the AWS Management Console or through an HTTP request header.
2) Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS):
SSE-KMS is similar to SSE-S3, but it uses AWS Key management Services (KMS) which provides additional benefits along with additional charges
KMS is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud.
KMS uses customer master keys (CMKs) to encrypt the S3 objects.
Master key is never made available.
KMS enables you to centrally create encryption keys, define the policies that control how keys can be used/
Allows audit use of key usage to prove they are being used correctly, by inspecting logs in AWS CloudTrail.
Allows keys to temporarily disabled and re-enabled.
Allows keys to be rotated regularly/
Security controls in AWS KMS can help meet encryption-related compliance requirements.
SSE-KMS enables separate permissions for the use of an envelope key (that is, a key that protects the data’s encryption key) that provides added protection against unauthorized access of the objects in S3.
SSE-KMS provides the option to create and manage encryption keys yourself, or use a default customer master key (CMK) that is unique to you, the service you’re using, and the region you’re working in.
Creating and Managing CMK gives more flexibility, including the ability to create, rotate, disable, and define access controls, and to audit the encryption keys used to protect the data.
Data keys used to encrypt your data are also encrypted and stored alongside the data they protect and are unique to each object
Process flow:
- An application or AWS service client requests an encryption key to encrypt data and passes a reference to a master key under the account.
- Client requests are authenticated based on whether they have access to use the master key.
- A new data encryption key is created, and a copy of it is encrypted under the master key.
- Both the data key and encrypted data key are returned to the client.
- Data key is used to encrypt customer data and then deleted as soon as is practical.
- Encrypted data key is stored for later use and sent back to AWS KMS when the source data needs to be decrypted.
3) Server-Side Encryption with Customer-Provided Keys (SSE-C):
Encryption keys can be managed and provided by the Customer and S3 manages the encryption, as it writes to disks, and decryption, when you access the objects.
When you upload an object, the encryption key is provided as a part of the request and S3 uses that encryption key to apply AES-256 encryption to the data and removes the encryption key from memory.
When you download an object, the same encryption key should be provided as a part of the request. S3 first verifies the encryption key and if matches decrypts the object before returning back to you
As each object and each object’s version can be encrypted with a different key, you are responsible for maintaining the mapping between the object and the encryption key used.
SSE-C request must be done through HTTPS and S3 will reject any requests made over HTTP when using SSE-C.
For security considerations, AWS recommends to consider any key sent erroneously using HTTP to be compromised and discarded or rotated
S3 does not store the encryption key provided. Instead, it stores a randomly salted HMAC value of the encryption key which can be used to validate future requests. The salted HMAC value cannot be used to derive the value of the encryption key or to decrypt the contents of the encrypted object. That means, if you lose the encryption key, you lose the object.
Client Side Encryption:
Client library such as the Amazon S3 Encryption Client
Clients must encrypt data themselves before sending to S3
Clients must decrypt data themselves when retrieving from S3
Customer fully manages the keys and encryption cycle
Client-side encryption refers to encrypting data before sending it to Amazon S3 and decrypting the data after downloading it.
In Client-side encryption, the data is encrypted before sending it to the S3 bucket. To implement Client-side encryption in S3, we have the following two options:
- Use a CMK (customer master key) stored in AWS KMS (Key Management Service)
- Use a Customer provided master key stored in the customer’s proprietary application
1) AWS KMS-managed Customer Master Key (CMK):
Customer can maintain the encryption CMK with AWS KMS and can provide the CMK id to the client to encrypt the data
Uploading Object:
AWS S3 encryption client first sends a request to AWS KMS for the key to encrypt the object data
AWS KMS returns a randomly generated data encryption key with 2 versions a plain text version for encrypting the data and cipher blob to be uploaded with the object as object metadata
Client obtains a unique data encryption key for each object it uploads.
AWS S3 encryption client uploads the encrypted data and the cipher blob with object metadata
Download Object:
AWS Client first downloads the encrypted object from S3 along with the cipher blob version of the data encryption key stored as object metadata
AWS Client then sends the cipher blob to AWS KMS to get the plain text version of the same, so that it can decrypt the object data.
2) Client-Side master key
Encryption master keys are completely maintained at Client-side
Uploading Object:
S3 encryption client ( for e.g. AmazonS3EncryptionClient in the AWS SDK for Java) locally generates randomly a one-time-use symmetric key (also known as a data encryption key or data key).
Client encrypts the data encryption key using the customer provided master key
Client uses this data encryption key to encrypt the data of a single S3 object (for each object, the client generates a separate data key).
Client then uploads the encrypted data to Amazon S3 and also saves the encrypted data key and its material description as object metadata (x-amz-meta-x-amz-key) in Amazon S3 by default
Downloading Object:
Client first downloads the encrypted object from Amazon S3 along with the object metadata.
Using the material description in the metadata, the client first determines which master key to use to decrypt the encrypted data key.
Using that master key, the client decrypts the data key and uses it to decrypt the object
Client-side master keys and your unencrypted data are never sent to AWS
If the master key is lost the data cannot be decrypted
Comparison between different S3 Encryption types:
| SSE-S3 | SSE-KMS | SSE-C | Client side Encryption |
| • SSE-S3: encryption using keys handled & managed by Amazon S3
• Object is encrypted server side
• AES-256 encryption type
• Must set header: “x-amz-server-side-encryption“: “AES256 |
• SSE-KMS: encryption using keys handled & managed by KMS
• KMS Advantages: user control + audit trail • Object is encrypted server side
• Must set header: “x-amz-server-side-encryption”: ”aws:kms” |
• SSE-C: server-side encryption using data keys fully managed by the customer outside of AWS
• Amazon S3 does not store the encryption key you provide
• HTTPS must be used
• Encryption key must provided in HTTP headers, for every HTTP request made |
• Client library such as the Amazon S3 Encryption Client
• Clients must encrypt data themselves before sending to S3
• Clients must decrypt data themselves when retrieving from S3
• Customer fully manages the keys and encryption cycle |
Encryption in transit (SSL/TLS):
- Amazon S3 exposes:
HTTP endpoint: non encrypted
HTTPS endpoint: encryption in flight
- You’re free to use the endpoint you want, but HTTPS is recommended
- Most clients would use the HTTPS endpoint by default
- HTTPS is mandatory for SSE-C
- Encryption in flight is also called SSL / TLS
S3 Security:
User based:
IAM policies – which API calls should be allowed for a specific user from IAM console
Resource Based:
Bucket Policies – bucket wide rules from the S3 console – allows cross account
Object Access Control List (ACL) – finer grain
Bucket Access Control List (ACL) – less common
Note: an IAM principal can access an S3 object if the user IAM permissions allow it OR the resource policy ALLOWS it AND there’s no explicit DENY
Networking:
Supports VPC Endpoints (for instances in VPC without www internet)
Logging and Audit:
S3 Access Logs can be stored in other S3 bucket
API calls can be logged in AWS CloudTrail
User Security:
MFA Delete: MFA (multi factor authentication) can be required in versioned buckets to delete objects
Pre-Signed URLs: URLs that are valid only for a limited time (ex: premium video service for logged in users)
Related Posts:
Amazon Web Service – AWS Tutorial
Top 13 Reasons to Why Learn AWS in 2022