Encryption with SSE-C

SSE-C

To use SSE-C (Server-Side Encryption with Customer-Provided Keys), you must manage your own encryption keys. Data can only be retrieved by providing the original key used during upload. Therefore, you must store your keys in a durable and highly available manner, as Exoscale does not store or recover your keys.

The keys must be 256-bit AES keys and provided to the SOS API in base64-encoded format. An example command to generate such a key is:

openssl rand -out my_personal_sse-c.key 32

Transferring objects with SSE-C:

Uploading and downloading encrypted objects works similarly to standard operations. You use the cp operation, passing the encryption key as a command-line parameter. It is your responsibility to track which key is used for each object.

The following command generates the 256-bit base64-encoded string for use as the encryption key:

cat /dev/urandom | head -c 32 | base64 -

Object upload:

mc cp encrypted_file_to_upload.txt myminio/mylockedbucket/encrypted_file_uploaded.txt --encrypt-key "myminio/mylockedbucket/=wMEoiDXcIAh/uxEQ4vAKaoNwrOQmK5yrseIKieUO494="

If you attempt to display the content of the encrypted object without supplying the encryption key, you should receive the following error to confirm that it has been server-side encrypted correctly.

mc cat myminio/mylockedbucket/encrypted_file_uploaded.txt

Output:

mc: Unable to read from myminio/mylockedbucket/encrypted_file_uploaded.txt. 400 Bad Request.

Limitations

  • No CLI or Portal support: SSE-C is not currently supported through the Exoscale Portal or standard CLI interfaces. Use tools that natively support SSE-C.
  • No key rotation via copy: SOS does not support copying objects using different keys. To change keys, you must download the object locally and re-upload it with the new key.
  • No replication: Objects encrypted with SSE-C cannot be replicated using SOS Bucket Replication.