Amazon S3 Encryption - SSE-C | Overview.

Amazon S3 Encryption – SSE-C (Server-Side Encryption with Customer-Provided Keys) - Overview.

Scope:

• Intro,
• Key Features of SSE-C,
• How SSE-C Works,
•  How to Use SSE-C,
• Sample Encryption request (upload),
• Sample Decryption request (download),
•  Pros (Benefits),
•  Cons (Limitations),
•  When to Use SSE-C

Intro:

• SSE-C allows twtech to encrypt objects in Amazon S3 using keys that twtech provides and manage itself.
• AWS uses twtech SSE-C key to perform encryption and decryption but AWS does not store the key. 
• This offers maximum control over twtech SSE-C encryption keys but also comes with significant operational responsibilities.
• If twtech SSE-C is not well sucured, it could be compromise and it database too.
• If twtech looses its SSE-C key, its data will become unrecoverable (retrieve).

 Key Features of SSE-C

Feature	Description
Encryption type	AES-256
Key management	Fully managed by twtech (the customer)
Key storage	Key is not stored in AWS (must be provided with each request)
Use case	Organizations needing full control over encryption keys, often for regulatory or internal policy reasons
Supported operations	Uploads, downloads, copy (with key), multipart uploads (with extra complexity)
CloudTrail logging	No key usage logging via CloudTrail since AWS doesn’t manage the keys

 How SSE-C Works

1. Upload: twtech sends its encryption key along with the PUT request. AWS uses it to encrypt the object before storing it.
2. Storage: AWS stores only the encrypted object, not your key.
3. Download: twtech must provide the same key in the GET request for AWS to decrypt and return the object.

•  If twtech loses its key, twtech data will become unrecoverable.

 How to Use SSE-C

When uploading or retrieving an object, include these HTTP headers:

• Sample Encryption request (upload):

# vbnet

 

x-amz-server-side-encryption-customer-algorithm: AES256

x-amz-server-side-encryption-customer-key: <base64-encoded-key>

x-amz-server-side-encryption-customer-key-MD5: <base64-encoded-MD5-of-key>

• Sample Decryption request (download):

#  vbnet

 

x-amz-server-side-encryption-customer-algorithm: AES256

x-amz-server-side-encryption-customer-key: <base64-encoded-key>

x-amz-server-side-encryption-customer-key-MD5: <base64-encoded-MD5-of-key>

NB:

• SDKs like AWS CLI or SDK for Python (boto3) support these headers.

 Pros (Benefits)

• twtech retain full control over encryption keys.
• AWS never stores or logs twtech-SSE-C keys.
• Suitable for strict regulatory or internal control requirements.

 Cons (Limitations)

Limitation	Description
Key must be provided with every request	Uploads, downloads, copies, multipart parts – all need the key.
High operational complexity	twtech must manage key distribution, rotation, and security.
No automatic key rotation	Unlike SSE-KMS, SSE-C requires manual rotation processes.
Incompatible with some features	SSE-C cannot be used with: – S3 Replication – S3 Transfer Acceleration – S3 Select – Object Lock – Some S3 event notifications
No CloudTrail logging	Since AWS doesn’t handle the key, it can’t log KMS activity.
Data loss risk	If twtech looses the key, the object is permanently inaccessible.

 When to Use SSE-C

Use SSE-C only if:

• twtech is required by regulation to supply its own keys and not allow AWS to manage them.
• twtech have strong internal key management practices and infrastructure.
• twtech doesn't need features like replication or advanced analytics that aren’t compatible with SSE-C.