Bacula Edition Documentation text image transdoc
Search

Main


Data 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 Public-Key Infrastructure (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, such as a CD placed in a in a fire-proof safe or bank safety deposit box. 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; burn the key pair to a CD and send the CD home with the owner of the machine.

NOTE!!! 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:
  1. The File daemon generates a session key.
  2. The FD encrypts that session key via PKE for all recipients (the file daemon, any master keys).
  3. The FD uses that session key to perform symmetric encryption on the data.

Building Bacula with Encryption Support

To build Bacula with encryption support, you will need the OpenSSL libraries and headers installed. When configuring Bacula, use: 

./configure --with-openssl ...

Please note, the Bacula Enterprise binaries are all built with encryption enabled.

Encryption Technical Details

The implementation uses 128bit AES-CBC, with RSA encrypted symmetric session keys. The RSA key is user supplied. If you are running OpenSSL 0.9.8 or later, the signed file hash uses SHA-256 - otherwise, SHA-1 is used.

End-user configuration settings for the algorithms are not currently exposed - only the algorithms listed above are used. However, the data written to Volume supports arbitrary symmetric, asymmetric, and digest algorithms for future extensibility, and the back-end implementation currently supports:

  • Symmetric Encryption:
    • 128, 192, and 256-bit AES-CBC
    • Blowfish-CBC
  • Asymmetric Encryption (used to encrypt symmetric session keys):
    • RSA
  • Digest Algorithms:
    • MD5
    • SHA1
    • SHA256
    • SHA512

The various algorithms are exposed via an entirely re-usable, OpenSSL-agnostic API (ie, it is possible to drop in a new encryption backend). The Volume format is DER-encoded ASN.1, modeled after the Cryptographic Message Syntax from RFC 3852. Unfortunately, using CMS directly was not possible, as at the time of coding a free software streaming DER decoder/encoder was not available.

Concepts

Data encription is configured in Bacula only in the File Daemon. The Job report that is produced at the end of each job has a line indicating whether or not encryption was enabled: 

VSS:         no
Encryption:  no/yes    <===
Accurate:    no
...

Generating Private/Public Encryption Keys

Generate a Master Key Pair (once) with: 

openssl genrsa -out master.key 2048
openssl req -new -key master.key -x509 -out master.cert

Save these files (master.key and master.cert) as you will need them to create File Daemon keys or in case you loose the File Daemon keys.

Generate a File Daemon Key Pair for each FD: 

openssl genrsa -out fd-example.key 2048
openssl req -new -key fd-example.key -x509 -out fd-example.cert
cat fd-example.key fd-example.cert >fd-example.pem

When configuring the File Daemon (see section (here)), you will need the keys you just generated here, so you will need to transmit them to the machine where the FD is installed.

Note, there seems to be a lot of confusion around the file extensions given to these keys. For example, a .pem file can contain all the following: private keys (RSA and DSA), public keys (RSA and DSA) and (X.509) certificates. It is the default format for OpenSSL. It stores data Base64 encoded DER format, surrounded by ASCII headers, so is suitable for text mode transfers between systems. A .pem file may contain any number of keys either public or private. We use it in cases where there is both a public and a private key.

Typically, above we have used the .cert extension to refer to X.509 certificate encoding that contains only a single public key.

Example Data Encryption Configuration

When configuring the FD, use the keys generated above in a FD configuration file that will look something like the following:

bacula-fd.conf 
FileDaemon {
   Name = example-fd
   FDport = 9102                  # where we listen for the director
   WorkingDirectory = /opt/bacula/working
   Pid Directory = /var/run
   Maximum Concurrent Jobs = 20

   PKI Signatures = Yes            # Enable Data Signing
   PKI Encryption = Yes            # Enable Data Encryption
   PKI Keypair = "/opt/bacula/etc/fd-example.pem"    # Public and Private Keys
   PKI Master Key = "/opt/bacula/etc/master.cert"    # ONLY the Public Key
}

You must restart your File Daemon after making this change to the bacula-fd.conf file.

Note
: the PKIMasterKey directive is not mandatory, but if used will allow you to decrypt the files if ever the FD PKIKeypair is lost. If you loose the FD's PKIKeypair, you will not be able to recover your data unless you have used a PKIMasterKey.

Decrypting with a Master Key

It is preferable to retain a secure, non-encrypted copy of the client's own encryption keypair. However, should you lose the client's keypair, recovery with the master keypair is possible.

First create a keypair with: 

cat master.key master.cert >master.pem

Then modify your File Daemons configuration file to use the master keypair: 

FileDaemon {
   Name = example-fd
   FDport = 9102                  # where we listen for the director
   WorkingDirectory = /opt/bacula/working
   Pid Directory = /var/run
   Maximum Concurrent Jobs = 20

   PKI Signatures = Yes            # Enable Data Signing
   PKI Encryption = Yes            # Enable Data Encryption
   PKI Keypair = "/opt/bacula/etc/master.pem"   # Master Public and Private Keys
}

Restart your File Daemon and you should be able to recover your lost files.