+++ /dev/null
-
-\chapter{Data Encryption}
-\label{DataEncryption}
-\index[general]{Data Encryption}
-\index[general]{Encryption!Data}
-\index[general]{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:
-\begin{itemize}
-\item 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 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.
-
-\item The implementation does not encrypt file metadata such as file path
- names, permissions, and ownership. Extended attributes are also currently
- not encrypted. However, Mac OS X resource forks are encrypted.
-\end{itemize}
-
-Encryption and signing are implemented using RSA private keys coupled with
-self-signed x509 public certificates. This is also sometimes known as PKI
-or Public Key Infrastructure.
-
-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.
-{\bf ALWAYS} store a copy of your master keys in a secure, off-site location.
-
-The basic algorithm used for each backup session (Job) is:
-\begin{enumerate}
-\item The File daemon generates a session key.
-\item The FD encrypts that session key via PKE for all recipients (the file
-daemon, any master keys).
-\item The FD uses that session key to perform symmetric encryption on the data.
-\end{enumerate}
-
-
-\section{Building Bacula with Encryption Support}
-\index[general]{Building Bacula with Encryption Support}
-
-The configuration option 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. When configuring Bacula, use:
-
-\begin{verbatim}
- ./configure --with-openssl ...
-\end{verbatim}
-
-\section{Encryption Technical Details}
-\index[general]{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:
-
-\begin{verbatim}
-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
-\end{verbatim}
-
-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.
-
-
-\section{Decrypting with a Master Key}
-\index[general]{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.
-
-You must:
-\begin{itemize}
-\item Concatenate the master private and public key into a single
- keypair file, ie:
- cat master.key master.cert >master.keypair
-
-\item 2) Set the PKI Keypair statement in your bacula configuration file:
-
-\begin{verbatim}
- PKI Keypair = master.keypair
-\end{verbatim}
-
-\item Start the restore. The master keypair will be used to decrypt
- the file data.
-
-\end{itemize}
-
-
-\section{Generating Private/Public Encryption Keys}
-\index[general]{Generating Private/Public Encryption Keypairs}
-
-Generate a Master Key Pair with:
-
-\footnotesize
-\begin{verbatim}
- openssl genrsa -out master.key 2048
- openssl req -new -key master.key -x509 -out master.cert
-\end{verbatim}
-\normalsize
-
-Generate a File Daemon Key Pair for each FD:
-
-\footnotesize
-\begin{verbatim}
- 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
-\end{verbatim}
-\normalsize
-
-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 (x509) 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 X509
-certificate encoding that contains only a single public key.
-
-
-\section{Example Data Encryption Configuration}
-\index[general]{Example!File Daemon Configuration File}
-\index[general]{Example!Data Encryption Configuration File}
-\index[general]{Example Data Encryption Configuration}
-
-{\bf bacula-fd.conf}
-\footnotesize
-\begin{verbatim}
-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
-}
-\end{verbatim}
-\normalsize
projects / bacula / docs / blobdiff