Server-Side Encryption FAQ

What is Server-Side Encryption (SSE)?

Server-side encryption protects your data by encrypting it before it is stored on disk by Backblaze B2 Cloud Storage. Files that are encrypted using server-side encryption may be accessed using the same API calls as other B2 files (using either our B2 Native API or the S3 Compatible API).

 

How does SSE work?

You have two options for encrypting data with Backblaze B2 Server-Side Encryption. Both options use an extensively-tested and widely-trusted block cipher, 256-bit Advanced Encryption Standard (AES-256), to encrypt the data at rest.

 

The options are Server-Side Encryption with Backblaze-Managed Keys (SSE-B2) and Server-Side Encryption with Customer-Managed Keys (SSE-C).

 

SSE-B2 encrypts each file using a unique encryption key; each file’s encryption key is additionally encrypted with a global key before being saved to decrypt the data when each file is accessed.

 

SSE-C encrypts each file using a unique encryption key; each file’s encryption key is additionally encrypted with the AES-256 encryption key that you manage.

 

With either SSE-B2 or SSE-C, Backblaze B2 Server-Side Encryption encrypts your file data at rest, but not the file metadata. After a file has been uploaded, the only time your data is decrypted is when you access the file (e.g., downloading or copying the file via API calls).

 

If you use SSE-C to encrypt a file, then you must manage and protect your encryption keys yourself. Backblaze does not store the encryption key for SSE-C files; instead, it stores a secure hash value that is used to validate future requests, but which can’t be used to derive the original encryption key or decrypt your file. As a result, if you lose the encryption key for a file encrypted with SSE-C, Backblaze will not be able to recover your key or decrypt the data.

 

Does SSE with Backblaze work the same way as it does with AWS?

From a functionality standpoint, SSE-B2 and SSE-C with Backblaze B2 Cloud Storage work the same way as they do with AWS. Files are encrypted with AES-256.

 

Is there an extra cost to use SSE?

No. No extra cost to encrypt your data, however, you are responsible for the normal charges associated with storing the encrypted file. There are nominal charges for using the Class C API calls to enable / disable / read encryption on a bucket.

 

Can SSE be enabled later on?

Yes. Either via API or web application, encryption may be enabled at the time a bucket is created or at a later date. Please note that the APIs allow you to enable encryption (SSE-B2 or SSE-C) at an individual file level. Once encryption (SSE-B2) is enabled (via API or web application) on a bucket, only files uploaded into (or copied into) that bucket from that point forward will be encrypted. Files in the bucket before encryption is enabled are not encrypted.

 

What happens if I made a mistake and encrypted a file that I didn’t want to?

You may disable encryption by copying the file (using the Copy API call) into the same bucket and deleting the encrypted copy. 

 

Is encryption (SSE-B2) enabled on a bucket by default?

No. By default, encryption is disabled for a bucket. You have the option of enabling encryption via API or web application.

 

Can you tell which file(s) is encrypted and by which mode in the web application?

Yes. Encrypted files are indicated by a lock icon in the Browse Files page within the web application. Lock icons with the letter ‘C’ indicate those files encrypted by SSE-C.

 

What happens if I enable SSE on a bucket and disable SSE at a later date?

Once encryption (SSE-B2) is enabled (via API or web application) on a bucket, only files uploaded into (or copied into) that bucket from that point forward will be encrypted. Files in the bucket before encryption is enabled are not encrypted. If encryption is disabled for that bucket at a later date, files uploaded into (or copied into) that bucket from that point forward will be unencrypted. Files encrypted when the feature was enabled will remain encrypted.

 

What happens if I enable encryption (SSE-B2) on an existing bucket with files in it already?

Once encryption (SSE-B2) is enabled on a bucket, only files uploaded into (or copied into) that bucket from that point forward will be encrypted. Files in the bucket before encryption is enabled are not encrypted.

 

Can I only use SSE with the S3 Compatibility API? 

Both the S3-Compatible and B2 Native APIs support SSE-B2 and SSE-C.

 

May I use the B2 CLI, B2 Java SDK, or B2 Python SDK to enable/disable encryption?

Currently, the B2 CLI and the B2 Python SDK support the SSE-B2 mode. More updates coming soon.

 

Why can’t I download or create a snapshot of an encrypted file in the web application?

At this time, we have taken a very literal interpretation to data encrypted “at rest”. Downloading files and creating snapshots involve additional servers aside from those used to store data at rest. On those servers, the data would have to be in an unencrypted state and this would require them to have access to the encryption key.

 

If a bucket has default encryption turned on, are the encryption headers in an API call required to upload a file and have it stored encrypted?

No. Additional headers are not required to encrypt a file when the bucket that you are uploading into has default encryption turned on. If a bucket has default encryption disabled, then an additional header is required to upload a file and have it encrypted with SSE-B2 encryption.

 

What are the headers and values needed to enable encryption on a file?

To request SSE-B2 encryption for a file using the B2 Native API, include the header X-Bz-Server-Side-Encryption with the value "AES256".

To request SSE-C encryption for a file using the B2 Native API, include the headers X-Bz-Server-Side-Encryption-Customer-Algorithm (value "AES256"), X-Bz-Server-Side-Encryption-Customer-Key (value <base64-encoded AES-256 encryption key>), and X-Bz-Server-Side-Encryption-Customer-Key-Md5 (value <base64-encoded MD5 digest of the key>).

 

What happens if I attempt to download a file and use an invalid encryption key?

If you attempt to download a SSE-B2 encrypted file with an SSE-C encryption key, you will get a 400 error. If you attempt to download an SSE-C encrypted file with the wrong encryption key, you will get a 403 error.

 

Do I need to create a new application key to upload or download files encrypted with SSE-B2 or SSE-C?

No. You may use your existing application key.

 

Do I need to create a new application key if I want to turn on default encryption for a bucket?

Yes. You also need a new application key to view default encryption settings on a bucket.

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk