File Daemon Data Encryption

Important

This section describes file data encryption and signing within the File Daemon. If you are interested in encryption within the Storage Daemon at the volume level (encryption of data at rest) more information can be found in Storage Daemon Data Volume Encryption.

Bacula permits file data encryption and signing within the File Daemon (or Client) prior to sending data to the Storage Daemon. Upon restoration, file signatures are validated and any mismatches are reported. At no time does the Director or the Storage Daemon have access to unencrypted file contents.

It is very important to specify what this implementation does NOT do:

There is one important restore problem to be aware of, namely, it’s possible for the director to restore new keys or a Bacula configuration file to the client, and thus force later backups to be made with a compromised key and/or with no encryption at all. You can avoid this by not changing the location of the keys in your Bacula File daemon configuration file, and not changing your File daemon keys. If you do change either one, you must ensure that no restore is done that restores the old configuration or the old keys. In general, the worst effect of this will be that you can no longer connect the File daemon.
The implementation does not encrypt file metadata such as file path names, permissions, and ownership. Extended attributes are also currently not encrypted. However, Mac OSX resource forks are encrypted.

Encryption and signing are implemented using RSA private keys coupled with self-signed X.509 public certificates. This is also sometimes known as PKI.

Each File Daemon should be given its own unique private/public key pair. In addition to this key pair, any number of “Master Keys” may be specified – these are key pairs that may be used to decrypt any backups should the File Daemon key be lost. Only the Master Key’s public certificate should be made available to the File Daemon. Under no circumstances should the Master Private Key be shared or stored on the Client machine.

The Master Keys should be backed up to a secure location. The Master Keys should never be kept on the same machine as the Storage Daemon or Director if you are worried about an unauthorized party compromising either machine and accessing your encrypted backups.

While less critical than the Master Keys, File Daemon Keys are also a prime candidate for off-site backups.

Important

If you lose your encryption keys, backups will be unrecoverable. ALWAYS store a copy of your master keys in a secure, off-site location.

The basic algorithm used for each backup session (Job) is:

The File daemon generates a session key.
The FD encrypts that session key via PKE for all recipients (the file daemon, any master keys).
The FD uses that session key to perform symmetric encryption on the data.