Storage Daemon Data Volume Encryption

When using the Device directive Volume Encryption = yes, the blocks in the volumes are encrypted using the BLOCK_CIPHER_AES_128_XTS or BLOCK_CIPHER_AES_256_XTS cipher algorithm. These symmetrical ciphers are fast, and used by most applications that need to perform symmetrical encryption of blocks.

Every block is encrypted using a key that is unique for the volume and an IV (Initialization Vector) - the block number that is saved in the block header. The XTS ciphers are specifically designed to support an IV with a low entropy.

The first block of the volume that holds the Volume Label is not encrypted because certain fields such as the Volume Name are required to manage the volume and the encryption. A user has an option to obfuscate the fields that are not required which might hold critical information, e.g. hostname. These fields are replaced by the string “OBFUSCATED”.

The header of the block is not encrypted. This 24-byte header does not hold user information. See the content of the header:

32bit header option bit field
32bit block length
32bit block number
BB03 string
32bit volume session id
32bit volume session time.

The Volume session time is the time of the Storage Daemon at startup. The Volume session id is reset to zero when the daemon starts and is incremented at every backup by the Storage Daemon.

The 64bit XXH64 checksum is encrypted with the data. The block must be be decrypted to verify the checksum. If the checksum matches, Bacula uses the right encryption key and the block is not modified. It is currently not possible to verify the integrity of the block without the encryption key.

If data spooling is enabled, the data in the data spool is not encrypted.

Important

Do not store the data spool on an unsafe storage.