Docs

Torch Object Storage

Server-side encryption

Overview

With server-side encryption, TOS encrypts your uploaded data at the object level before storing it. When you download these objects, TOS automatically decrypts the data and sends it back to you.

Use cases

Server-side encryption is ideal for applications that need to encrypt stored data or comply with regulatory requirements. It provides effective data protection, and encrypted objects are automatically decrypted when accessed. Accessing encrypted and unencrypted objects is identical.

Encryption methods

TOS offers several server-side encryption methods. Select the appropriate method based on your use case.

Encryption method	Description	Use cases	Billing notes	Supported regions
Server-side encryption with TOS-managed keys (SSE-TOS)	TOS manages encryption keys. TOS uses a unique key to encrypt each object with either AES-256 or SM4, and it regularly rotates the master key.	When basic encryption is enough and self-managed keys are not necessary	Free	Supported regions for SSE-TOS vary by encryption algorithm: AES-256: All regions. For more information, see Regions and endpoints. SM4: China (Beijing), China (Guangzhou), and China (Shanghai).
Server-side encryption with customer-provided keys (SSE-C)	Users manage encryption keys. TOS uses customer-provided keys to encrypt data with AES-256 during the upload process.	When you need to encrypt data using keys that you manage yourself	Free	All regions. For more information, see Regions and endpoints.
Server-side encryption with Volcano Engine KMS keys (SSE-KMS)	Key Management Service (KMS) manages encryption keys. TOS uses customer master keys, hosted by KMS, to generate unique data keys. These keys are then used to encrypt data with AES-256 or SM4 algorithms.	When you need the cloud service provider to manage the keys while retaining the ability to create, manage, and designate your own customer master keys for data encryption	Charged. For more information, see KMS Billing Overview.	Supported regions for SSE-KMS vary by encryption algorithm: AES-256: All regions. For more information, see Regions and endpoints. SM4: China (Beijing), China (Guangzhou), and China (Shanghai).

Using server-side encryption with TOS-managed keys (SSE-TOS)

SSE-TOS is an encryption method where TOS manages the keys. SSE-TOS employs strong multi-factor encryption to ensure that each object is encrypted with a unique key. SSE-TOS supports the AES-256 and SM4 algorithms for encrypting data. The keys themselves are encrypted using a regularly rotated master key. There are several ways to apply SSE-TOS to your objects.

Using the TOS console

You can enable SSE-TOS when uploading objects. For instructions, see Uploading objects.

You can enable SSE-TOS for a bucket when you create it or after it is created. For instructions, see Creating buckets or Setting bucket encryption.

When you set a bucket's encryption to SSE-KMS, all objects uploaded to that bucket will automatically inherit its encryption settings, unless otherwise specified.

Using REST APIs

When uploading objects with server-side encryption via API, you must include the x-tos-server-side-encryption header in the request. The following APIs support this header:

PutObject

PostObject

CreateMultipartUpload

CopyObject

tip

When uploading a large object via multipart upload, you can specify the server-side encryption method by adding the x-tos-server-side-encryption header to the CreateMultipartUpload request.

When copying an existing object, the target object will not be encrypted, regardless of whether the source object is encrypted, unless you explicitly specify the server-side encryption method in the request.

When an object's encryption method is set to SSE-TOS, the following REST APIs include the x-tos-server-side-encryption header in their responses.

PutObject

CreateMultipartUpload

CopyObject

PostObject

UploadPart

UploadPartCopy

CompleteMultipartUpload

GetObject

HeadObject

warning

When using a POST operation to upload an object, instead of providing the request header, you provide the same information in the form fields. For more information, see PostObject.

If your object uses SSE-TOS, do not include the x-tos-server-side-encryption header in GET and HEAD requests. Including this header results in an HTTP 400 Bad Request error.

Using server-side encryption with customer-provided keys (SSE-C)

SSE-C uses customer-managed keys to encrypt data. You provide the key, and then TOS encrypts the data using AES-256 during the upload process. To use SSE-C, you must provide encryption key information in the following request headers.

Header	Description
x-tos-server-side-encryption-customer-algorithm	Specifies the encryption algorithm. The value must be "AES256".
x-tos-server-side-encryption-customer-key	Specifies the 256-bit, Base64-encoded encryption key used to encrypt or decrypt your data.
x-tos-server-side-encryption-customer-key-MD5	Specifies the Base64-encoded, 128-bit MD5 digest of the encryption key according to RFC 1321. TOS uses this header to perform a message integrity check and ensure that the encryption key was transmitted without error.

Using REST APIs

You can apply SSE-C to objects by providing the x-tos-server-side-encryption-customer-* headers in PUT and POST requests. To decrypt objects encrypted with SSE-C in GET or HEAD requests, you must provide the x-tos-server-side-encryption-customer-* headers. The following APIs support these headers:

GetObject

HeadObject

PutObject

CreateMultipartUpload

UploadPart

PostObject

CopyObject

UploadPartCopy

When you copy an object, you have both a source object and a target object.

To encrypt the target object with SSE-C, provide the necessary encryption information using the three headers described in the above table.

If the source object is encrypted with SSE-C, provide the encryption key information using the following headers so that TOS can decrypt the object for copying.

Header	Description
x-tos-copy-source-server-side-encryption-customer-algorithm	Specifies the algorithm used to decrypt the source object. The value must be "AES256".
x-tos-copy-source-server-side-encryption-customer-key	Specifies the Base64-encoded encryption key used to decrypt the source data. The key must match the one used when creating the source object.
x-tos-copy-source-server-side-encryption-customer-key-MD5	Specifies the Base64-encoded, 128-bit MD5 digest of the encryption key according to RFC 1321. TOS uses this header to perform a message integrity check and ensure that the encryption key was transmitted without error.

warning

You must use HTTPS when specifying SSE-C headers in your requests.

TOS never stores the encryption keys you provide. Instead, it stores an HMAC value of the key along with randomly generated data. This value is then used to validate access requests. TOS cannot derive the encryption key or decrypt the object content from the HMAC value and random data. Therefore, if you lose the encryption key, you will not be able to retrieve the object.

When using a POST operation to upload an object, instead of providing the x-tos-server-side-encryption-* header, you provide the same information in the form fields. For more information, see PostObject.

SSE-C can only be used via the API and is not supported in the console.

Using server-side encryption with Volcano Engine KMS keys (SSE-KMS)

TOS uses customer master keys, which are managed by KMS, to generate unique data keys. These keys are then used to encrypt data with AES-256 or SM4 algorithms. SSE-KMS uses envelope encryption to secure user data. First, TOS encrypts the data with the plaintext data key. Then, the plaintext key is discarded and only the encrypted data key is retained.

What is KMS

KMS is an all-in-one key management and data encryption platform powered by Volcano Engine. It provides user-friendly encryption interfaces that help you securely manage keys and protect critical cloud data. KMS implements access control and log tracking for all key operations. This ensures that usage records are maintained for each key, thus satisfying auditing and compliance requirements. You can create keys independently via the KMS console or import external keys into KMS. Learn more in KMS Quick start.

Notes

If you are using SSE-KMS for server-side encryption for the first time, you must first activate KMS. Although activating KMS is free, using the service incurs charges. Using SSE-KMS for server-side encryption generates API call fees, and creating KMS keys generates key management fees. These fees are charged by KMS. For more information, see KMS Billing Overview.

Currently, SSE-KMS only supports custom KMS keys and does not support default keys managed by TOS.

SSE-KMS only encrypts object data, not metadata.

To upload objects with SSE-KMS, you need the kms:GenerateDataKey permission. To download SSE-KMS-encrypted objects, you need the kms:Decrypt permission.

SSE-KMS-encrypted objects do not support anonymous access. To access SSE-KMS-encrypted objects, you must activate KMS and have permission to access the master key. Requests must also be signed using valid credentials.

Using the TOS console

You can enable SSE-KMS when uploading objects. For instructions, see Uploading objects.

You can enable SSE-KMS for a bucket when you create it or after it is created. For instructions, see Creating buckets or Setting bucket encryption.

When you set a bucket's encryption to SSE-KMS, all objects uploaded to that bucket will automatically inherit its encryption settings, unless otherwise specified.

Using REST APIs

To apply SSE-KMS to objects via REST APIs, you must provide the x-tos-server-side-encryption, x-tos-server-side-data-encryption, and x-tos-server-side-encryption-kms-key-id headers in the requests.

The following APIs support SSE-KMS headers:

PutObject

PostObject

CreateMultipartUpload

CopyObject

tip

When uploading a large object via multipart upload, you can specify SSE-KMS by adding the x-tos-server-side-encryption, x-tos-server-side-data-encryption, and x-tos-server-side-encryption-kms-key-id headers to the CreateMultipartUpload request.

When copying an existing object, the server-side encryption method of the source object will not be automatically applied to the target object. You must explicitly specify the server-side encryption method in the CopyObject request.

When an object's encryption method is set to SSE-KMS, the following REST APIs include the x-tos-server-side-encryption and x-tos-server-side-encryption-kms-key-id headers in their responses.

PutObject

CreateMultipartUpload

CopyObject

PostObject

UploadPart

UploadPartCopy

CompleteMultipartUpload

GetObject

HeadObject

warning

You must use HTTPS when specifying SSE-KMS headers in your requests.

When using a POST operation to upload an object, instead of providing the request header, you provide the same information in the form fields. For more information, see PostObject.

If your object uses SSE-KMS, do not include the x-tos-server-side-encryption header in GET and HEAD requests. Including this header results in an HTTP 400 Bad Request error.

Last updated: 2026.10.09 14:43:43