Hi,

Disclaimer: I haven't used bacula encryption. Just read the 
documentation and used to teach PKI.

Tom Yates wrote:
> I'm curious about encryption; specifically, encrypting the data on the 
> client-side before the storage daemon lays it down to tape.
>
> I've read http://www.bacula.org/en/dev-manual/Data_Encryption.html, and it 
> seems to suggest that the client *requires* both the client's private key 
> and the client's public key.  Certainly, when I give the client a "PKI 
> Keypair =" file which contains only the public key, I get an "Error: 
> openssl.c:86 Unable to read private key from file ERR=error:0906D06C:PEM 
> routines:PEM_read_bio:no start line".
>
> But what I'm trying to do here is make a machine, and its backup tapes, 
> safe from physical seizure.  The root FS of the machine is unencrypted 
> (and so, therefore, is the /etc/bacula directory); the file system I'm 
> worried about is normally encrypted.
>   
With a PKI, you don't usually protect from physical seizure by avoiding 
the user of the private key, but by using its own separate key. If the 
machine is compromised, you simply revoke the FD key server-side. That 
makes the private key worthless. Since the private key is not actually 
used to encrypt the backups, your backups would still be recoverable.
> I've tried giving the FD a .pem file which includes an encrypted private 
> key, in the hope that it would ask for a passphrase at start time (in the 
> manner of apache), but instead I get "openssl.c:86 Unable to read private 
> key from file: ERR=error:0906A068:PEM routines:PEM_do_header:bad password 
> read", so that's not working.
>   
That makes sense, and is really not the best solution anyway.
> The above manual page on data encryption says that the encryption involves 
> three steps:
>
>     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.
>
> None of that seems to me to require the client's private key; only the 
> public one.
Step 2 requires the FD's private key, I think - the documentation isn't 
explicit on which key it uses for the encryption. But the private key is 
the one that would make the most sense here. Otherwise, anybody who has 
access to the public master key could access the backup. It probably 
actually uses double-encryption, using the public master key to keep the 
session key from being read by unauthorized parties.
> Only restoration, or some other act requiring the decryption 
> of the filestream, seems to me to require the client's private key.  Or is 
> there some other signing phase going on, that I'm not catching on to?
>   
Yes, I think so. Remember that the data stream is not encrypted using 
any public or private key at all! Instead, it uses the session key, 
which is a symmetric encryption.

Also, keep track of what, exactly, you are trying to protect against. If 
you are worried about the client data being stolen, and your backup 
accessed remotely through it, you may use a different strategy from if 
you are worried about the backup tapes being compromised. If the server 
tapes are in a secure location, maybe they don't need to be encrypted at 
all? In that case, you could simply use an SSH tunnel to do the actual 
backup and keep the data secure in transit.

The main advantage such a solution would have is that SSH is a 
well-proven and well-understood configuration, so it is less likely that 
you accidentally open security holes.

-- 
Kevin Keane
Owner
The NetTech
Find the Uncommon: Expert Solutions for a Network You Never Have to Think About

Office: 866-642-7116
http://www.4nettech.com

This e-mail and attachments, if any, may contain confidential and/or 
proprietary information. Please be advised that the unauthorized use or 
disclosure of the information is strictly prohibited. The information herein is 
intended only for use by the intended recipient(s) named above. If you have 
received this transmission in error, please notify the sender immediately and 
permanently delete the e-mail and any copies, printouts or attachments thereof.


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users