Client-Side Encryption

Client-side encryption places the encryption operation before the boundary of the receiving storage service. The client might be a desktop application, an on-premises backup agent, or an application running on cloud compute. It encrypts data locally and sends ciphertext to object storage or a database. On retrieval, an authorized application obtains the necessary key material and decrypts the data. The term describes where encryption happens; it does not necessarily mean that the application runs outside the cloud provider.

A common implementation uses envelope encryption. The application obtains a symmetric data key, encrypts the payload using an authenticated encryption algorithm such as AES-GCM, and protects the data key with a separate wrapping key. It stores the ciphertext, encrypted data key, and required cryptographic metadata together. During retrieval, the application unwraps the data key and decrypts the payload. Use maintained encryption libraries rather than inventing a message format, and follow their requirements for nonces, integrity verification, and algorithm selection. Plaintext data keys must not appear in logs, configuration files, or stored objects, and their lifetime in memory should be minimized.

Key management depends on the requirement. AWS KMS can generate data keys and protect them under a KMS key while the application performs bulk encryption locally. This provides policy enforcement and auditing for KMS operations, but it still relies on a provider-operated key service. If a requirement says that no plaintext key material may leave an HSM, a workflow that returns a plaintext data key to application memory does not satisfy it. AWS CloudHSM supports customer-controlled HSM operations, but engineers must choose an HSM-compatible cryptographic workflow and validate performance and availability. If keys must remain entirely outside the cloud provider, an external key system may be necessary.

For example, a backup agent can encrypt an archive before uploading it to object storage. A storage administrator who can download the object still cannot read the archive without the decryption capability. Keep storage permissions and key-use permissions separate, and restrict decryption to the recovery application. A database application can similarly encrypt sensitive fields before writing records, although queries and indexes cannot operate normally on those ciphertext fields without additional, carefully designed mechanisms.

Client-side encryption differs from server-side encryption, where the receiving service performs encryption after receiving the data. Supplying a customer key to a service for server-side encryption does not make the operation client-side; Amazon S3 SSE-C is an example. Likewise, TLS protects data in transit but does not determine whether the service receives plaintext. Client-side encryption should still use TLS, access controls, and appropriate server-side encryption as complementary protections.

The trade-offs include application CPU usage, larger payloads, encryption-library maintenance, and more complex recovery and key lifecycle management. Losing the required keys can make backups permanently unreadable. Rotating a wrapping key does not automatically re-encrypt existing payloads; the migration strategy depends on the encryption format and key service. Client-side encryption also limits service-side inspection, transformation, and plaintext search. It does not hide unencrypted object names, record attributes, or other exposed metadata, and it cannot protect plaintext from a compromised client that is authorized to decrypt it. For exam scenarios, select it when encryption must occur before storage-service ingestion, then separately evaluate key custody, authorization, and operational requirements.