key-manager Script and Using Master Key

The task of the key manager script is to provide the symmetric keys to the Storage Daemon to encrypt the Volumes.

The same symmetric key is used for both encryption and decryption of the Volume’s content. To improve security, each volume is expected to be encrypted using a unique symmetric key. When needed, these keys must be generated for each new Volume or when an existing Volume is recycled. This process can lead to a large amount of key files that need to be managed, which must also be backed up or securely stored. To know more about backing up the keys, click here.

The master key is implemented using a public/private key pair. The public key is stored on the Storage Daemon and is used to generate the encrypted version of the symmetric keys by the key-manager.py script.

The private key may be stored outside the Storage Daemon server. It is not necessary for the private key to reside on the Storage Daemon in order to perform backups.

The symmetric key, along with a unique identifier for the Master Key, are stored in the Volume label and in the KEYDIR directory. In this case, the symmetric key is stored in plaintext.

At restore time, these two pieces of information and the Volume name are provided to the key-manager.py script which is responsible for delivering the correct symmetric key and for data decryption.

It is possible to store the symmetric key encrypted in the Volume label and in the KEYDIR directory by using the stealth mode.

The Master Key is intended to offer two primary benefits:

To be able to decrypt multiple Volumes using one, or a set of Master Keys
When the stealth mode is used, the symmetric key is securely stored in an encrypted format alongside the master key on disk. Consequently, any attempt to restore data without the private key becomes impossible. In the event of a server being compromised or stolen, unauthorized individuals will be unable to access your data.

The stealth mode can be configured in the key-manager.py script configuration file.

The key-manager.py script provided with Bacula uses GnuPG to manage the public/private key.

For further information regarding the key-manager.conf file and and the implementation of the key-manager.py script, refer to the relevant documentation: