Encrypting Server-Side Objects with SSE-C or SSE-OMK¶

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) and Server-Side Encryption with Object Management Keys (SSE-OMK).

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 two primary methods for server-side encryption:

Server-Side Encryption with Customer-Provided Keys (SSE-C) - You provide and manage the encryption keys
Server-Side Encryption with Object Management Keys (SSE-OMK) - Rumble Cloud manages the encryption keys for you

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 \
  --server-side-encryption-customer-algorithm AES256 \
  --server-side-encryption-customer-key "your-base64-encoded-key" \
  --endpoint-url https://s3.us-east-1.rumble.cloud

Downloading Objects with SSE-C¶

Bash

aws s3api get-object \
  --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://s3.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 \
  --server-side-encryption-customer-algorithm AES256 \
  --server-side-encryption-customer-key "your-base64-encoded-key" \
  --endpoint-url https://s3.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.

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://s3.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
MFA Delete: For highly sensitive data, consider enabling MFA Delete at the container level for additional protection
Audit Logging: Monitor delete operations through audit logs to detect unauthorized deletions

To enable MFA Delete protection (requires versioning):

Bash

aws s3api put-bucket-versioning \
  --bucket your-container-name \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "device-serial-number MFA-code" \
  --endpoint-url https://s3.us-east-1.rumble.cloud

Generating a Base64-Encoded Key¶

You can generate a 256-bit, Base64-encoded key using OpenSSL:

Bash

openssl rand -base64 32

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.

Replication and SSE-C¶

Rumble Cloud supports replication of objects encrypted with SSE-C. When configuring replication for SSE-C encrypted objects, the objects remain encrypted with the same customer-provided key in the destination container.

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://s3.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://s3.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://s3.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://s3.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://s3.us-east-1.rumble.cloud

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

SSE-OMK: Server-Side Encryption with Object Management Keys¶

With SSE-OMK, Rumble Cloud manages the encryption keys for you. This option simplifies key management while still providing strong encryption for your data.

SSE-OMK encrypts each object with a unique key. As an additional safeguard, Rumble Cloud encrypts the key itself with a root key that it regularly rotates. SSE-OMK uses AES-256, one of the strongest block ciphers available, to encrypt your data.

Using SSE-OMK with the S3 API¶

When using the S3 API with SSE-OMK, you need to include a specific header in your PUT requests:

Bash

aws s3api put-object \
  --bucket your-container-name \
  --key your-object-key \
  --body /path/to/your/file \
  --server-side-encryption AES256 \
  --endpoint-url https://s3.us-east-1.rumble.cloud

No special parameters are needed when downloading objects encrypted with SSE-OMK.

Copying Objects with SSE-OMK¶

When copying objects with SSE-OMK, you can specify whether to apply encryption to the destination object:

Bash

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

Multipart Uploads with SSE-OMK¶

For multipart uploads with SSE-OMK:

Bash

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

# Upload parts and complete as normal

Setting Default Encryption for a Container¶

You can configure a container to apply server-side encryption automatically to all new objects:

Bash

aws s3api put-bucket-encryption \
  --bucket your-container-name \
  --server-side-encryption-configuration '{
    "Rules": [
      {
        "ApplyServerSideEncryptionByDefault": {
          "SSEAlgorithm": "AES256"
        }
      }
    ]
  }' \
  --endpoint-url https://s3.us-east-1.rumble.cloud

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

Common Issues with SSE-OMK¶

Encryption not applied: Verify that the correct server-side encryption headers are included in your requests
Permission issues: Ensure that your user has the proper permissions to use server-side encryption
Container policy conflicts: Check if your container access policy has any restrictions on encryption methods

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

For SSE-OMK¶

While Rumble Cloud manages the encryption keys, you should still implement proper access controls
Use container access controls to restrict who can access encrypted objects
Consider using container policies to enforce encryption for all objects

When to Choose Each Encryption Option¶

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
Choose SSE-OMK when:
You want simplicity in implementation and management
You don't want to bear the risk of losing encryption keys
You need a solution that's easy to implement across multiple applications
You trust your cloud provider with key management
You need seamless integration with other Rumble Cloud services

Conclusion¶

Server-side encryption provides an essential layer of security for your sensitive data stored in Rumble Cloud's Object Storage service. Whether you choose to manage your own keys with SSE-C or let Rumble Cloud handle key management with SSE-OMK, your data remains protected at rest.