AWS Client-side encryption | Overview.

AWS Client-side encryption - Overview.

Scope:

• Intro,
• Core components and tools,
• How AWS client-side encryption works,
• Key considerations,
• The concept of Client-Side Encryption (deep dive),
• Key Concepts,
• Types of Client-Side Encryption in AWS & Use cases,
• AWS Encryption SDK,
• Encryption (Write Path),
• Decryption (Read Path),
• Sample S3 Client-Side Encryption Flow,
• when to use AWS KMS APIs (KMS-backed),
• Security Characteristics for Client-Side Encryption & Server-Side Encryption,
• Advantages of Client-Side Encryption,
• Challenges of Client-Side Encryption,
• Sample Architecture for Client-Side Encryption,
• Best Practices.

Intro:

• AWS client-side encryption is the practice of encrypting data within twtech application before sending it to AWS services. 
• AWS client-side encryption ensures data is encrypted both in transit and at rest, and that AWS never has access twtech plaintext data. 

Core components and tools

• AWS Encryption SDK: A high-level library designed to help developers implement client-side encryption using industry standards and best practices.
• Amazon S3 Encryption Client: A specific library for encrypting objects before uploading them to Amazon S3.
• AWS Database Encryption SDK: Used for attribute-level encryption in DynamoDB and other databases. 

How AWS client-side encryption works

1. Key management: twtech chooses how to manage its wrapping keys (master keys). twtech can use AWS Key Management Service (KMS) to store these keys or manage them in its own infrastructure.
2. Envelope encryption: The SDK typically generates a unique, symmetric data key for each data object. The data is encrypted with this key, and the data key itself is then encrypted (wrapped) with twtech master key.
3. Storage: The encrypted data and the encrypted data key are stored together. For S3, the encrypted data key is often stored as object metadata.
4. Decryption: To read the data, the client retrieves the encrypted data and data key. It uses the master key to decrypt the data key, which then decrypts the data. 

Key considerations

• Shared responsibility: Under the AWS Shared Responsibility Model, twtech is responsible for managing the encryption process and the security of its keys when using client-side encryption.
• Performance: Encryption and decryption happen on twtech own hardware, using its client-side CPU resources.
• Incompatibility: Ciphertexts produced by the AWS Encryption SDK, the S3 Encryption Client, and the Database Encryption SDK are generally not compatible with each other due to different message formats.
• Searchability: Encrypting data before storage makes it difficult to search or index those specific fields directly in the database without first decrypting them.

NB:

• This complements Server-Side Encryption (SSE).
• However, Client-Side Encryption gives twtech full control of encryption keys and the encryption process before data even reaches AWS.
•  In this scenario, twtech does not trust the server (AWS) to handle the encryption/decryption process.
• Therefore, AWS never has access to twtech unencrypted data or encryption keys.

 The concept of Client-Side Encryption (deep dive)

• Client-Side Encryption (CSE) means that data is encrypted by twtech application before it is sent to AWS, and  data decrypted by twtech only after it’s retrieved.
• AWS services store and transmit only ciphertext, and never plaintext.

 Key Concepts

1. Data Encryption Key (DEK)

• Symmetric key used to encrypt twtech data locally.
• Generated and managed by twtech (or optionally by AWS SDK with KMS).

2. Master Key (CMK / Customer Key)

• Used to encrypt (wrap) the DEK.
• Stored securely in AWS KMS, CloudHSM, or your own key management system.

3. Envelope Encryption

Same as with SSE — but all happens client-side:

• Generate a DEK
• Encrypt data locally using DEK
• Encrypt DEK with Master Key
• Upload:
• Ciphertext data
• Encrypted DEK (metadata)

Types of Client-Side Encryption in AWS & Use cases

Encryption Mode	Key Source	Managed By	Use Case
AWS SDK CSE (with KMS)	KMS CMK	AWS KMS + SDK	Easy hybrid control (twtech manage CMK, SDK handles DEK)
AWS SDK CSE (Custom Keys)	Locally managed	twtech	Full key control, no AWS key dependency
S3 Encryption Client (deprecated)	Local key/KMS	twtech/AWS	Used before AWS Encryption SDK
AWS Encryption SDK	Local key/KMS	twtech/AWS	Current best practice for client-side encryption

 AWS Encryption SDK

A client library designed for application-level encryption that:

• Uses envelope encryption automatically
• Can integrate with AWS KMS or local keys
• Provides data key caching, key commitment, and multi-key wrapping

NB:

• Supported languages: Python, Java, JavaScript, C, and more.
• Encryption/Decryption Flow (Client-Side Encryption)
• Step-by-Step Flow (with AWS Encryption SDK + KMS)

Encryption (Write Path):

1. Application requests encryption.
2. AWS Encryption SDK:
• Calls KMS GenerateDataKey to get:
• Plaintext DEK
• Encrypted DEK (ciphertext key)
3. Encrypts data locally using DEK (AES-256-GCM).
4. Stores or uploads:
• Encrypted data
• Encrypted DEK
• Encryption context metadata
5. Discards plaintext DEK immediately.

Decryption (Read Path):

1. Application downloads encrypted object + metadata.
2. SDK extracts the encrypted DEK.
3. Calls KMS Decrypt to get plaintext DEK.
4. Decrypts the ciphertext locally.
5. Discards plaintext DEK again after use.

 Sample S3 Client-Side Encryption Flow

when to use AWS KMS APIs (KMS-backed),

• GenerateDataKey
• Decrypt
• Encrypt
• ReEncrypt
• DescribeKey
• ListKeys

 Security Characteristics for Client-Side Encryption & Server-Side Encryption

Feature	Client-Side Encryption	Server-Side Encryption
Key control	Full customer control	AWS-managed (optionally customer-managed CMK)
Encryption location	In application (client)	In AWS service
AWS access to plaintext	❌ Never	✅ Temporarily (before storage)
Performance overhead	Higher (client CPU/memory)	Minimal
Compliance	Strongest isolation	Meets AWS compliance standards

Advantages of Client-Side Encryption 

•  Zero trust on AWS storage — AWS never sees plaintext.
•        Meets strict regulatory or internal compliance (FIPS, GDPR, PCI-DSS).
•  Integrates seamlessly with AWS Encryption SDK and KMS.
•  Portable — can be encrypted before uploading to any storage (S3, EFS, on-prem).

 Challenges of Client-Side Encryption 

•  Key management complexity — must handle secure rotation and backup.
•  Client-side performance overhead — encryption/decryption done locally.
•  Loss of key = loss of data — no recovery if the key is lost.
•  No AWS-side features like S3 Select or Athena on encrypted data.

Sample Architecture for Client-Side Encryption 

Best Practices

• Use AWS Encryption SDK instead of manual crypto.
• Enforce Encryption Contexts — prevent key misuse.
• Cache data keys securely using the Data Key Caching feature.
• Regularly rotate CMKs and archive old keys.
• Log all KMS operations in CloudTrail.
• Use envelope encryption for scalability.