14:58 Sun, 05 Mar 2006 PST -0800

Bacula File Daemon Encryption Complete

Introduction

I'm pleased to announce that Bacula's File Daemon now has complete support for signing and encrypting data prior to sending it to the Storage Daemon, and decrypting said data upon receipt from the Storage Daemon.

The code has been committed to Bacula CVS; usage instructions follow.

WARNING: The on-disk data format may change prior to the next Bacula release. Do not use data encryption for production backups until the on-disk format has been declared "stable", or you risk losing access to previous backups.

Implementation Overview

The File Daemon encryption code implements file data encryption and signing 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.

However, it is very important to specify what this implementation does NOT do:

Encryption and signing are implemented using RSA private keys coupled with self-signed x509 public certificates. Each File Daemon should be given its own private/public key pair. In addition to this key pair, any number of "Master Keys" may be specified -- these are keypairs 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.

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.

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

Acquiring the Code

The encryption code lives in the Bacula SourceForge CVS repository. Check out the latest version of code using CVS:

 cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula login
 cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bacula co -P bacula

If CVS requests a password, simply hit Enter.

Building Bacula with Encryption Support

The autoconf flag for enabling OpenSSL / Encryption Support has not changed since Bacula 1.38. To build Bacula with encryption support, you will need the openssl libraries and headers installed. If you're using a recent release of FreeBSD, OpenSSL is included in the base system. If you're using Ubuntu, these are installed via the libssl-dev and libssl packages.

Configuring Bacula (with sqlite) on FreeBSD:

 ./configure --with-sqlite3=/usr/local --with-openssl=yes

Generating Private/Public Encryption Keypairs

Generate a Master Key Pair:

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

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

Configuring the File Daemon

Example bacula-fd.conf:

FileDaemon {
	Name = example-fd
	FDport = 9102                  # where we listen for the director
	WorkingDirectory = /var/bacula/working
	Pid Directory = /var/run
	Maximum Concurrent Jobs = 20
 
	PKI Signatures = Yes		# Enable Data Signing
	PKI Encryption = Yes		# Enable Data Encryption
	PKI Keypair = "/etc/bacula/fd-example.pem"    # Public and Private Keys
	PKI Master Key = "/etc/bacula/master.cert"    # ONLY the Public Key
}

[/code/bacula] permanent link