Encrypting Server-Side Objects with SSE-C¶

Rumble Cloud's Object Storage service provides robust options for securing your data with server-side encryption. This guide explains how to implement Server-Side Encryption with Customer-Provided Keys (SSE-C).

Overview of Server-Side Encryption¶

Server-side encryption protects your data at rest in Rumble Cloud's Object Storage service. When you upload an object, the encryption occurs on the server side, ensuring your data is stored securely. When you retrieve the object, it's automatically decrypted.

Rumble Cloud offers server-side encryption with customer provided keys:

Server-Side Encryption with Customer-Provided Keys (SSE-C) - You provide and manage the encryption keys

It's important to note that server-side encryption encrypts only the object data, not the object metadata.

Prerequisites¶

Before implementing server-side encryption with the S3 API, you'll need to:

Create an object storage container using the Rumble Cloud console
Generate S3 credentials through the Rumble Cloud console
Configure your preferred S3-compatible tool with these credentials

SSE-C: Server-Side Encryption with Customer-Provided Keys¶

With SSE-C, you maintain complete control over the encryption keys. Rumble Cloud never stores your encryption keys, providing an additional layer of security. However, you are responsible for managing and protecting these keys.

When you upload an object with SSE-C, Rumble Cloud uses your provided key to apply AES-256 encryption to your data, then removes the encryption key from memory. For validation purposes, Rumble Cloud stores a randomly salted hash value of the encryption key, which cannot be used to derive the original key or decrypt your data.

Requirements for SSE-C¶

HTTPS connections are mandatory for all operations involving SSE-C
You must provide an encryption key with each request (for both upload and download operations)
The encryption key must be 256-bit, Base64-encoded
If you lose your encryption key, you lose access to your object permanently
The ETag in the response is not the MD5 hash of the object data

Using SSE-C with the S3 API¶

When using the S3 API with SSE-C, you need to include specific headers in your requests:

Uploading Objects with SSE-C¶

Bash

aws s3api put-object \
  --bucket your-container-name \
  --key your-object-key \
  --body /path/to/your/file \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "your-base64-encoded-key" \
  --sse-customer-key-md5 "base64-encoded-md5-digest-of-your-encrption-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud

Downloading Objects with SSE-C¶

Bash

aws s3api get-object \
  --bucket your-container-name \
  --key your-object-key \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "your-base64-encoded-key" \
  --sse-customer-key-md5 "base64-encoded-md5-digest-of-your-encrption-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud \
  output-file

Getting Object Metadata with SSE-C¶

When working with SSE-C encrypted objects, retrieving metadata requires the same encryption key that was used to encrypt the object. This is necessary even though the metadata itself is not encrypted, as the key is needed to authenticate and validate the request:

Bash

aws s3api head-object \
  --bucket your-container-name \
  --key your-object-key \
  --sse-customer-algorithm AES256 \
  --sse-customer-key "your-base64-encoded-key" \
  --sse-customer-key-md5 "base64-encoded-md5-digest-of-your-encrption-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud

The response will include object metadata such as: - Content-Length - Last-Modified date - ETag (not the MD5 hash for SSE-C objects) - Content-Type - Any custom metadata you added to the object

If you attempt to retrieve metadata for an SSE-C encrypted object without providing the correct encryption key, you'll receive an "Access Denied" error, if you attempt to retrieve metedata for an SSE-C encrypted object without providing the correct encryption key md5 digest you will recieve a "HTTP 400 Bad Request" error.

Deleting Objects Encrypted with SSE-C¶

Unlike read operations, deleting objects encrypted with SSE-C does not require the encryption key. This is an important security consideration to understand:

Bash

aws s3api delete-object \
  --bucket your-container-name \
  --key your-object-key \
  --endpoint-url https://object.us-east-1.rumble.cloud

Security Implications of Deleting Encrypted Objects¶

The fact that you don't need the encryption key to delete an object has important security implications:

Access Control: Ensure your container access permissions properly restrict who can perform delete operations
Versioning: Consider enabling container versioning to protect against unauthorized or accidental deletions
Audit Logging: Monitor delete operations through audit logs to detect unauthorized deletions

To enable versioning to protect against accidental or malicious deletion):

Bash

aws s3api put-bucket-versioning \
  --bucket your-container-name \
  --versioning-configuration Status=Enabled \
  --endpoint-url https://object.us-east-1.rumble.cloud

Generating a Base64-Encoded Key and the MD5 Digest of the Encryption Key¶

You can generate a 256-bit, Base64-encoded key and the base64-encoded md5 digest of the encryption key using openssl and base64:

Bash

export ENC_KEY=$(openssl rand -base64 32)
export ENC_KEY_MD5=$(echo -n ${ENC_KEY} |base64 -d |openssl dgst -md5 -binary |base64 )

Store this key securely. If you lose the key, you won't be able to decrypt your objects.

Versioning Considerations with SSE-C¶

If your container has versioning enabled, each object version you upload can have its own encryption key. You are responsible for tracking which encryption key was used for which object version.

Copying Encrypted Objects with SSE-C¶

When copying objects encrypted with SSE-C, you must provide both the source object's encryption key and the destination encryption key (which can be the same or different):

Bash

aws s3api copy-object \
  --copy-source your-container-name/source-object \
  --bucket your-container-name \
  --key destination-object \
  --copy-source-server-side-encryption-customer-algorithm AES256 \
  --copy-source-server-side-encryption-customer-key "source-object-key" \
  --server-side-encryption-customer-algorithm AES256 \
  --server-side-encryption-customer-key "destination-object-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud

Multipart Uploads with SSE-C¶

For large objects, you might need to use multipart uploads. When using SSE-C with multipart uploads, you must provide the same encryption key for all parts:

Bash

# Initiate multipart upload
aws s3api create-multipart-upload \
  --bucket your-container-name \
  --key your-object-key \
  --server-side-encryption-customer-algorithm AES256 \
  --server-side-encryption-customer-key "your-base64-encoded-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud

# Upload parts (repeat for each part)
aws s3api upload-part \
  --bucket your-container-name \
  --key your-object-key \
  --part-number 1 \
  --upload-id "upload-id-from-create-multipart-upload" \
  --body part1.bin \
  --server-side-encryption-customer-algorithm AES256 \
  --server-side-encryption-customer-key "your-base64-encoded-key" \
  --endpoint-url https://object.us-east-1.rumble.cloud

# Complete multipart upload
aws s3api complete-multipart-upload \
  --bucket your-container-name \
  --key your-object-key \
  --upload-id "upload-id-from-create-multipart-upload" \
  --multipart-upload file://parts.json \
  --endpoint-url https://object.us-east-1.rumble.cloud

Using Pre-signed URLs with SSE-C¶

When creating pre-signed URLs for objects encrypted with SSE-C, you need to include the encryption headers in the signature. However, you should never include the actual encryption key in the URL. Instead, the client must provide the key when using the pre-signed URL:

Bash

# Generate pre-signed URL for GET
aws s3 presign s3://your-container-name/your-object-key \
  --endpoint-url https://object.us-east-1.rumble.cloud

When using the pre-signed URL, the client must include the encryption key in the request headers.

Using Encryption with the OpenStack Swift API¶

Rumble Cloud's object storage is compatible with both S3 and OpenStack Swift APIs. If you're using the OpenStack Swift API, you can implement server-side encryption as follows:

SSE-C with Swift API¶

Bash

swift upload container file.txt \
  --header "X-Object-Meta-Encryption-Key: your-base64-encoded-key" \
  --header "X-Object-Meta-Encryption-Algorithm: AES256" \
  --os-auth-url https://identity.us-east-1.rumble.cloud \
  --os-username your-username \
  --os-password your-password \
  --os-project-name your-project

Access Control with Encrypted Objects¶

For encrypted objects, the same access control mechanisms apply as with non-encrypted objects, but with additional security provided by the encryption. You can set containers to public or private access using the Rumble Cloud console, or use more granular permissions with the S3 API.

Best Practices for Server-Side Encryption¶

Key Management: If using SSE-C, implement a robust key management system to prevent key loss
HTTPS Only: Always use HTTPS connections when working with encrypted objects
Audit Logs: Regularly review access logs for your encrypted objects
Versioning: Consider enabling container versioning to protect against accidental deletions or corruptions
Access Control: Implement strict container access controls to restrict who can access encrypted objects
Key Rotation: For SSE-C, establish a process for periodic key rotation to enhance security
Key Mapping: Maintain a secure mapping of which key was used to encrypt which object
Backup Keys: Maintain secure backups of your encryption keys
Test Recovery: Regularly test your key recovery procedures
Documentation: Document your encryption strategy and key management procedures

Troubleshooting¶

Common Issues with SSE-C¶

"KMS KeyId not found" error: Verify that the encryption key is correctly formatted and encoded
"Access Denied" error: Ensure that you're providing the correct encryption key for retrieval
Connection errors: Confirm that you're using HTTPS, not HTTP
ETag validation failures: Remember that ETags for SSE-C objects are not MD5 hashes of the object data
Multipart upload failures: Ensure you're using the same encryption key for all parts of a multipart upload

Security Considerations¶

For SSE-C¶

Never transmit your encryption keys over insecure channels
Rotate your encryption keys periodically
Implement a secure key management solution
Consider using a hardware security module (HSM) for key storage
Implement access controls for your key management system

When to Choose SSE-C¶

Choose SSE-C when:
You require complete control over encryption keys
You have specific compliance requirements mandating customer key management
You have an existing key management infrastructure
You need to ensure that your cloud provider cannot access your data
Your security policy requires that encryption keys never leave your control

Conclusion¶

Server-side encryption provides an essential layer of security for your sensitive data stored in Rumble Cloud's Object Storage service. When you use SSE-C, your data remains protected at rest.