Re: [Bacula-users] client-side data encryption without routine access to private key
On Wed, 18 Feb 2009, Martin Simmons wrote:
> Does the private key have to be the one associated with the public key?
> It looks like the code loads them separately, so perhaps another
> solution is to use two key pairs and make a pem file containing the
> public key of one and the private key of the other (assuming openssl
> allows that)?
Elegant, and it works. I made two keypairs (risby-sign and risby-encrypt)
and put risby-sign.key and risby-encrypt.cert) into the PEM file specified
in "PKI Keypair =".
The fd process restarted fine, did a test backup fine. When I tried a
test restore, it fails (as it should) with "restore.c:488 Failed to
initialize decryption context for
/tmp/bacula-restores/big/home/madhatta/TESTFILE".
When I replace the PEM file with one containing both halves of the
encryption key (risby-encrypt.key and risby-encrypt.cert) and restart the
FD, the restore still errors on validating the signature ("restore.c:839
Signature validation failed for file
/tmp/bacula-restores/big/home/madhatta/TESTFILE: ERR=Signature is
invalid") (which is expected, because now it has *neither* part of the
signing keypair), but the file restores correctly:
4bed0f14512d1290931529b1bc233a0bfe362614 /big/home/madhatta/TESTFILE
4bed0f14512d1290931529b1bc233a0bfe362614
/tmp/bacula-restores/big/home/madhatta/TESTFILE
As I say: elegant - and thank you!
--
Tom Yates - http://www.teaparty.net
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
On Feb 18, 2009, at 10:43 AM, Landon Fuller wrote: ... and signatures could still be verified. Spoke a little too soon. Signatures are written out with the x509 subjectkeyidentifier from the public key. A mismatched pair would need to have matching subjects for validation, and that assumes that recipient info continues to be encoded in the same way. If the issuer and serial number were used instead, this would fail. -landonf PGP.sig Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
On Feb 18, 2009, at 3:26 AM, Martin Simmons wrote: On Tue, 17 Feb 2009 20:24:02 -0800, Landon Fuller said: The private key is needed during backup if you use PKI Signatures. Right. Currently, enabling PKI encryption also enables signing, but the encryption implementation does not require this, and the private key is not necessary for encrypting the backups. However -- if you disable signing, there is no other validation mechanism. One could add HMAC support without too much effort, but you lose non-repudiation of the backups, as any recipient that can verify the HMAC may also generate a valid one. Does the private key have to be the one associated with the public key? It looks like the code loads them separately, so perhaps another solution is to use two key pairs and make a pem file containing the public key of one and the private key of the other (assuming openssl allows that)? Interesting -- I believe that would work. The only time the public/ private keypair are associated is when decrypting the session key on restore, so a truly "asymmetric" pair (heh) should simply cause restore to fail -- and signatures could still be verified. -landonf PGP.sig Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
> On Tue, 17 Feb 2009 20:24:02 -0800, Landon Fuller said: > > > The private key is needed during backup if you use PKI Signatures. > > Right. Currently, enabling PKI encryption also enables signing, but > the encryption implementation does not require this, and the private > key is not necessary for encrypting the backups. > > However -- if you disable signing, there is no other validation > mechanism. One could add HMAC support without too much effort, but you > lose non-repudiation of the backups, as any recipient that can verify > the HMAC may also generate a valid one. Does the private key have to be the one associated with the public key? It looks like the code loads them separately, so perhaps another solution is to use two key pairs and make a pem file containing the public key of one and the private key of the other (assuming openssl allows that)? __Martin -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
> On Wed, 18 Feb 2009 07:44:04 + (GMT), Tom Yates said: > > Would you know if I can disable signing in the configuration, or must I > recompile; and if the latter, is it a config option or will I need to mess > with the source myself? You would need to modify the source. __Martin -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
On Tue, 17 Feb 2009, Landon Fuller wrote: > On Feb 17, 2009, at 8:48 AM, Martin Simmons wrote: > >> That sounds backwards to me. Shouldn't the encrypter (backup) use the >> public key to keep the data safe? Then only the decrypter (restore) >> can read the data, using the private key. > > Right. A symmetric session key is used for each backup run, which is > encrypted for all provided public keys and stored along-side the > encrypted data. This is how the "master" public key feature is > implemented. Thanks to Martin and Landon both for confirming this. I was aware of the existence of the session key, but stupidly skated over it in my original post. >> The private key is needed during backup if you use PKI Signatures. > > Right. Currently, enabling PKI encryption also enables signing, but the > encryption implementation does not require this, and the private key is > not necessary for encrypting the backups. > > However -- if you disable signing, there is no other validation > mechanism. One could add HMAC support without too much effort, but you > lose non-repudiation of the backups, as any recipient that can verify > the HMAC may also generate a valid one. I can live with that; data authentication isn't as important to me as encryption (ie, I'm more worried that real data will get into the wrong hands than that wrong data will get into the real hands). Would you know if I can disable signing in the configuration, or must I recompile; and if the latter, is it a config option or will I need to mess with the source myself? Thanks to all who have tried to help me with this so far. Tom Yates Cambridge, UK. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
On Feb 17, 2009, at 8:48 AM, Martin Simmons wrote: That sounds backwards to me. Shouldn't the encrypter (backup) use the public key to keep the data safe? Then only the decrypter (restore) can read the data, using the private key. Right. A symmetric session key is used for each backup run, which is encrypted for all provided public keys and stored along-side the encrypted data. This is how the "master" public key feature is implemented. The private key is needed during backup if you use PKI Signatures. Right. Currently, enabling PKI encryption also enables signing, but the encryption implementation does not require this, and the private key is not necessary for encrypting the backups. However -- if you disable signing, there is no other validation mechanism. One could add HMAC support without too much effort, but you lose non-repudiation of the backups, as any recipient that can verify the HMAC may also generate a valid one. Cheers, -landonf PGP.sig Description: This is a digitally signed message part -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
> On Tue, 17 Feb 2009 07:07:19 -0800, Kevin Keane said: > > > 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. That sounds backwards to me. Shouldn't the encrypter (backup) use the public key to keep the data safe? Then only the decrypter (restore) can read the data, using the private key. The private key is needed during backup if you use PKI Signatures. __Martin -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] client-side data encryption without routine access to private key
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] client-side data encryption without routine access to private key
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. 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. 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. 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? Am I missing something, or is the only way to make this work to put the bacula FD's keys in plaintext, inside the encrypted filesystem? Tom Yates Cambridge, UK. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
