AWS Key Management Service (KMS) lets you easily manage encryption for AWS cloud products. Server-side encryption (SSE) is one approach to securing data, in which the server that hosts the data is also tasked with encrypting the data. The alternative is client-side encryption (CSE), where the user’s device encrypts the data so that the contents are not available to the server. KMS and SSE are not opposing ideas—rather, KMS offers SSE as one approach for encrypting data.
This article will discuss how encryption strategies like SSE and CSE work in the context of AWS KMS, use cases for SSE and CSE, and best practices to implement when securing data in the cloud.
Summary of key KMS and SSE concepts
The following table outlines key concepts discussed in this article:
| AWS Key Management Service (KMS) | The AWS Key Management Service (KMS) generates and stores key material used for encryption and decryption. |
|---|---|
| Server-side encryption (SSE) | Data is transmitted securely to the AWS service (e.g. S3 via HTTPS) and then encrypted as it is written to server storage. |
| Client-side encryption (CSE) | Data is first encrypted on the client before it is transmitted securely to the server storage. |
| Customer Managed Key (CMK) | A customer managed key is used by AWS to encrypt small amounts of data, including data encryption keys. Formerly known as a “customer master key.” |
| Envelope encryption | A data key is used to encrypt data. The data key is then encrypted with the CMK, and both the data and the encrypted data key are stored together, like a letter in an envelope. |
| End-to-end encryption (E2EE) | True end-to-end encryption is when data is encrypted at the source and only decrypted once it reaches its destination. |
| Encryption at rest | A term used to indicate that data is encrypted while it resides on a storage device. |
| Encryption in transit | A term used to indicate that data is encrypted as it transfers across a network. |
| AWS SDK | The AWS Software Development Kit (SDK) provides language-specific access to APIs to assist developers in leveraging AWS services. |
Encryption for AWS
Encryption works by concealing plaintext data by converting it into seemingly unintelligible “ciphertext” using a key generated using a complex mathematical algorithm. Each key is unique to the person or process that creates it.
In symmetric encryption, the same key both encodes and decodes data, so it is imperative that this key be kept secure. In asymmetric encryption, an algorithm generates two mathematically linked keys. Information is encrypted using the public key, which can be shared freely with others. Once encrypted with the public key, only the matching private key can decrypt that data. It is the private key, therefore, that must be kept secure. Asymmetric encryption is beneficial when sharing data between two parties since each side can share their public keys for the other to encrypt data and can keep their private keys secure to use when decrypting the data.
AWS supports using both symmetric and asymmetric encryption, though symmetric is more common within AWS because AWS services that integrate with AWS KMS only use symmetric keys. This article on rotating keys with KMS discusses this concept in more detail.
Envelope encryption
Another concept used within AWS is envelope encryption. A key used for decryption must be unencrypted, leaving it unprotected. For the key to be protected, it has to be stored very securely or perhaps encrypted with another key. At some point, there must be a securely stored unencrypted key to begin the decryption process, however, and this is where envelope encryption can be helpful.
An example of envelope encryption in AWS
As shown in the diagram above, with envelope encryption, a data key encrypts the data. Then a managed key encrypts the data key. AWS calls this managed key the Customer Managed Key (CMK) and stores this in AWS’s own FIPS-validated hardware security modules in KMS. The data key is stored along with the encrypted data. When the data is required, the data key is decrypted by the CMK, and the plaintext data key can then decrypt the data.
Note that this plaintext data key is only stored temporarily in memory. Once the decryption process completes, AWS deletes it to maintain the key’s integrity.
An example of decryption in AWS.
AWS KMS
AWS KMS integrates with more than 100 AWS services to make it easier for customers to encrypt their data. KMS provides a central store for generating, managing, and controlling cryptographic keys used for the encoding and decoding of data and works with other services to perform this process without any user interaction.
However, not all encryption types are alike! One key difference is where that encryption takes place. With AWS encryption, two options are available:
- Server-side encryption (SSE)
- Client-side encryption (CSE)
Server-side encryption (SSE)
Very simply, server-side encryption is when unencrypted data is transferred to the “server” and is encrypted at the point it is written to the storage on the “server side” of the transfer. With SSE, AWS encrypts data on the server side “transparently” as it writes the data to the storage device; there is little to no effort required on the part of the AWS customer.
As seen in the diagram below, you should separately encrypt the data as it is “in transit”, e.g. using HTTPS or across a VPN. This is a separate encryption process using different keys from those used in the “at rest” encryption.
An overview of server-side encryption in AWS using S3
AWS offers three server-side encryption types, as described in the table below.
| Encryption Type | Description |
| SSE-S3 | The data encryption keys are managed by the Amazon S3 service, i.e., they are not generated and stored in AWS KMS. S3 will automatically encrypt and decrypt data for anyone with permission to access the S3 object. |
| SSE-KMS | As the name suggests, the data encryption keys are generated and stored within AWS KMS. These could be AWS-managed keys or customer-managed keys. The latter involves a higher cost but gives the customer complete control of the key, including key rotation periods. |
| SSE-C | Client-provided data encryption keys are used for this type of encryption. Since AWS does not store these keys, for each encrypt and decrypt operation, the data encryption key must also be provided in the request. However, the actual encryption/decryption process still occurs on the server side. |
Note that all of the above use envelope encryption, i.e., the data keys are generated and stored with the data they encrypt, and the managed keys are then used to encrypt these data keys.
Client-side encryption (CSE)
With CSE, data is encrypted using software available to the client (e.g., the AWS SDK or via the S3 API). This encryption process happens before the transmission of data to AWS. Unlike SSE, client-side encryption requires manual effort on the part of the AWS customer.
An overview of client-side encryption in AWS using S3
As the diagram shows, encryption takes place within the client application before being uploaded to AWS. In most instances, the data should still be encrypted separately in transit, such as via HTTPS.
AWS supports two client-side encryption types.
| Encryption Type | Description |
|---|---|
| CSE-KMS | AWS generates a data encryption key in KMS via a request sent by the client with an appropriate KMS key id. The client then downloads and uses the generated data key to encrypt the object and uploads this encrypted object into S3. |
| CSE-C | A separate “root” key must be created and made accessible to the client. The client generates a random data key itself and encrypts the data with this data key. It encrypts the data key with the root key and then uploads both the encrypted data key and the encrypted object into S3. |
Note that in the examples above, the “client” refers to an application built potentially using the AWS Software Development Kit (SDK).
The diagram below shows the primary differences between the two types of client-side encryption.
Detailed diagram of client-side encryption in AWS
- AWS generates and stores the CMK in KMS, and the client requests and downloads a data key. The client uses this data key to encrypt the data object and uses the CMK to encrypt the data key. Finally, the application uploads both the encrypted object and data key to the S3 bucket.
- The client has access to a “root” key locally. It generates the data key, which it uses to encrypt the data object, and uses the local “root” key to encrypt the data key. Finally, the application uploads both the encrypted object and data key to the S3 bucket.
Best practices for SSE and CSE
So, when should you use these different types of encryption? Here are some more suggestions and best practices to help you decide.
Server-side encryption within AWS offers vastly reduced complexity and is often faster and more efficient since the processing is completed by AWS services internally. For this reason, it is often the best choice for many use cases.
There are different levels of security within AWS for server-side encryption:
- The least secure option is SSE-S3 because the AWS customer has no visibility of the keys used to encrypt, and AWS also share these keys between different AWS accounts. This increases the usage of these keys and thus the potential risk of compromise.
- Theoretically, the most secure is SSE-C, since customers can generate their own managed keys, which are never stored in AWS, protecting them from a malicious or accidental cloud employee breach. However, this relies on customer action to maintain that security.
Client-side encryption gives the AWS customer complete control over the encryption process and offers the highest level of security when viewed purely from the encryption point of view.
End-to-end encryption (E2EE) is sometimes advertised for highly secure systems. For true E2EE, the data must be encrypted on the client side and not be able to be decrypted until it has reached its destination—there can be no server-side encryption or decryption within the entire flow of the data. So, if true end-to-end encryption is required, client-side encryption is the only way to achieve this.
An overview of the protection provided by different encryption types against various access control breaches (source)
It appears client-side encryption is always the most secure – why choose anything else?
- As noted, client-side encryption is more complex and takes more effort to implement. There are many use cases where that security level is unnecessary, so it makes sense to apply the correct level based on the classification of the data to be encrypted.
- In any scenario where the client generates the managed/root key(s) and stores them, there must be a high level of security to prevent the compromise or loss of these managed keys. This is difficult to achieve and, if done inappropriately, could result in lower overall security than server-side encryption, where keys are stored in the cloud provider’s highly secure vault.
Identify, prioritize and remediate the most important cloud security risks.
Correlate findings across your existing tools: CSPM + Infrastructure + App Vulnerabilities
Reduce alert fatigue by up to 50% and lower your overall risk profile by up to 25%
Conclusion
The fundamental difference between server-side and client-side encryption is where the encryption takes place. Within AWS, there are several options for the type of key material used for encryption and where this is generated and stored. Most AWS services support SSE. However, some highly sensitive applications and data may need CSE to satisfy compliance requirements or provide true end-to-end encryption.
There are cloud services available that can assist with this, such as AWS CloudHSM. You can also examine using free and open-source tools like Paladin Cloud’s open-source Cloud Security Posture Management (CSPM) platform. CSPM improves your visibility and awareness of the cloud with continuous monitoring, unified visibility, proactive threat detection of risks (such as a change in KMS key permissions and also potentially unauthorised usage of KMS keys), and automated remediation of security violations.