Encrypting Objects In-Transit and At-Rest

Relying on the underlying storage hardware to manage encryption keys implicitly trusts the infrastructure provider with the confidentiality of the payload. While server-side encryption with provider-managed keys protects against physical drive theft, it offers zero defense against a compromised storage control plane or an insider threat within the hosting environment. Establishing a strict cryptographic boundary requires shifting key management to the client or a dedicated, isolated Key Management Service (KMS), ensuring that the storage layer only ever handles encrypted ciphertext.

The Limits of Provider-Managed Keys

When utilizing Server-Side Encryption with Provider-Managed Keys (SSE-S3 or SSE-KMS), the storage platform automatically generates, rotates, and stores the cryptographic material. While this reduces operational overhead, it means the storage provider possesses the technical capability to decrypt the data. In highly regulated industries, or when utilizing third-party managed service providers, this shared responsibility model is unacceptable. Organizations must retain absolute, unilateral control over the key lifecycle to guarantee that no external entity can access the plaintext data, even under legal duress.

Server-Side Encryption with Customer-Provided Keys (SSE-C)

SSE-C shifts the cryptographic burden entirely to the client. During an object upload, the client application generates a secure encryption key, encrypts the payload locally, and transmits both the ciphertext and the raw key material over a strictly enforced TLS 1.3 tunnel. The storage server uses the provided key to verify the integrity of the upload and stores the ciphertext, but it immediately discards the key from its volatile memory. When the client subsequently requests the object, they must present the exact same key in the HTTP headers; without it, the storage engine returns only indecipherable binary noise.

Envelope Encryption for Large Payloads

Transmitting raw encryption keys in HTTP headers for every single API call introduces severe latency and security risks. To optimize performance while maintaining strict key isolation, enterprise workloads utilize envelope encryption. The client requests a short-lived Data Encryption Key (DEK) from their isolated KMS, uses the DEK to encrypt a massive object locally, and then encrypts the DEK itself using a master key. Only the encrypted DEK and the ciphertext are uploaded to the object store. This ensures that the storage platform never sees the plaintext DEK, while the client avoids the overhead of continuous KMS API calls.

# Uploading an object using Server-Side Encryption with Customer-Provided Keys (SSE-C)
# The raw key must be base64 encoded and transmitted over a secure TLS channel

RAW_KEY=$(openssl rand -base64 32)
KEY_MD5=$(echo -n "$RAW_KEY" | base64 -d | md5sum | awk '{print $1}' | xxd -r -p | base64)

curl -X PUT "https://s3.private.srrrs.internal/secure-vault/financial-records.db" \
     -H "x-amz-server-side-encryption-customer-algorithm: AES256" \
     -H "x-amz-server-side-encryption-customer-key: $RAW_KEY" \
     -H "x-amz-server-side-encryption-customer-key-MD5: $KEY_MD5" \
     -H "Content-Type: application/octet-stream" \
     --data-binary "@local-financial-records.db"

Summary

True data confidentiality in shared or managed infrastructure requires decoupling the storage plane from the cryptographic plane. By implementing SSE-C and envelope encryption, organizations ensure that their object storage acts purely as a dumb, highly durable repository for ciphertext. SRRRS integrates seamlessly with enterprise KMS platforms, enabling zero-trust encryption models where the storage provider has absolutely no visibility into the underlying data payloads.