Re: [Bacula-users] data key rollover strategy

[Devin Reade]

--On Thursday, November 19, 2015 01:03:59 PM + Martin Simmons 
 wrote:

> Does Bacula ever check for expired [data encryption] certs?  I suspect
> not, so the question about rollover strategy is a moot one.

I've empirically verified this to be the case; I performed a backup
using a short-lived data encryption cert, then waited for the cert
expiry date to pass.  I then:

1. Restored files from datasets that had been backed up using the
   cert before the cert had expired (ie: decrypt using an expired
   cert)

2. Modified files and then performed a new backup with the expired
   cert (ie: encrypt using an expired cert)

3. Restored the modified files from (2).  (ie: decrypt using an expired
   cert data that had also been encrypted with an expired cert)

For the test I used a director and storage daemon at version 7.0.5_3
on FreeBSD, and a client daemon at 5.2.13-18 on CentOS 7.1.1503.

However to protect against a change in behavior in the future, I think
that in the future I will create certificates that either have no expiry
date, or have a date that is further in the future than the expected
system life.

Remember, this is only referring to data encryption, not network
encryption.

Thanks everyone for your input.

Devin


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] data key rollover strategy

[Marcin Haba]

Hello Devin,

2015-11-19 0:17 GMT+01:00 Devin Reade :
> My alerting system tells me that I have some file daemons that have been
> merrily encrypting their data for quite a while.  In particular, the
> expiry dates for the data encryption x509 certs are coming up soon.

You can renew your certs. I think that way described on the following
link should be sufficient:

http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/x195.html#AEN215

> Well, this brings up an interesting question that I'd not really
> considered in depth:  Given that you can only specify two keys
> in the bacula-fd.conf file, what is the best strategy during key
> rollover?  That is, that time period after making a new client
> keypair available, and the retention time of the backups that were
> made with the old keypair?

I think that important is understand that data stored by Bacula is not
encrypted by ANY from public keys. Data is encrypted (symetric) by
session keys and these session keys are stored on Bacula volumes in
(asymetric) encrypted (by public keys) form.

So data encryption in Bacula uses session keys stored in encrypted
ASN.1 standard structure. In short it means that you are able to
decrypt session key not by only ONE key, but by Client private key and
private Master Key.

Some time ago I prepared a few diagrams that show Bacula data
encryption algorighm. Here are the diagrams in English version:

http://www.bacula.pl/data_encryption.html

> First off, I think that the master key specification doesn't enter
> the picture; there is still a need for encrypting with the master
> public key, for the usual reasons.
>
> The first section of the data encryption chapter says to not change
> the location of the client keypair.  Fair enough.  This implies that
> the new keypair should be used to overwrite the old.  That's great
> for performing backups, but what about doing restores?

You can do restore as long as you have private Master Key, because in
this case for decrypt session keys from volumes there is used private
Master Key as only one valid. Of course, you have to provide the
private Master Key to your Client.

I hope that it helps.

Best regards.
Marcin Haba (gani)

> I suspect the answer is:
>   1. Save a copy of the old keypair (presumably there are copies
>  offline already, but best to be explicit)
>   2. Overwrite the old client keypair with the new keypair.
>   3. Resume backup operations.
>   4. If you have to restore data from a time after the key replacement,
>  then it's business as usual.
>   5. If you have to restore data from a time prior to the key replacement,
>  then you need to copy the old keypair over top of the new,
>  (presumably) restart the file daemon, perform the restore,
>  copy the new keypair back on top of the old, restart the file daemon,
>  and then continue with normal operations again.
>
> This implies that you also need to keep track of what the flag day
> is when you change the certificate for a given client.  (Although this
> may be recorded in your certificate maintenance system, if any.)
>
> Does anyone have a better procedure?
>
> Devin
>
>
> --
> ___
> Bacula-users mailing list
> Bacula-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bacula-users



-- 
"Większej miłości nikt nie ma nad tę, jak gdy kto życie swoje kładzie
za przyjaciół swoich." Jezus Chrystus

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] data key rollover strategy

[Martin Simmons]

> On Thu, 19 Nov 2015 09:15:36 -0700, Devin Reade said:
> 
> > Some time ago I prepared a few diagrams that show Bacula data
> > encryption algorighm. Here are the diagrams in English version:
> >
> > http://www.bacula.pl/data_encryption.html
> 
> That diagram is a bit simplified in that it implies that the client
> can check an arbitrary number of keypairs instead of the current
> maximum of two.

Actually, 'any number of "Master Keys" may be specified' according to the doc,
because the PKI Master Key option can be repeated.

That only works for encryption though.  Decryption always uses the private key
from the "PKI Keypair" option.

__Martin

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] data key rollover strategy

[Devin Reade]

--On Thursday, November 19, 2015 10:49:07 AM +0100 Marcin Haba 
 wrote:

> You can renew your certs.

True, as long as you're ok with using the old key.  However t won't work,
for example, if you need to expand your key size.

> I think that important is understand that data stored by Bacula is not
> encrypted by ANY from public keys.

Yes, that is true.  However you need the keypair to get at the
ephemeral key.  My original question was made, and still stands,
with that understanding.  Talking about encrypting something with
an assymmetric key is usually made with the assumption that the
reader knows that there is an ephemeral key being used for symmetric
encryption.

> In short it means that you are able to
> decrypt session key not by only ONE key, but by Client private key and
> private Master Key.
[...]
> You can do restore as long as you have private Master Key, because in
> this case for decrypt session keys from volumes there is used private
> Master Key as only one valid. Of course, you have to provide the
> private Master Key to your Client.

Understood, but if one postulates that the master key has a similar
expiry date then having yet another keypair doesn't solve the problem.
(It doesn't have the same date in my case, but in the general case
it might be the same, or your master key may expire before the
client key.  The situation with the master key is really an analog
to the situation with the client key.  Solve one and you solve the other.)

Besides, the master key is special in that it is typically the same
for all clients, so you wouldn't want to put the private master key
on a client permanently just in case you find the need to restore something.

> Some time ago I prepared a few diagrams that show Bacula data
> encryption algorighm. Here are the diagrams in English version:
>
> http://www.bacula.pl/data_encryption.html

That diagram is a bit simplified in that it implies that the client
can check an arbitrary number of keypairs instead of the current
maximum of two.  If it was in fact an arbitrary number one could solve
the problem by listing both the old and the new client keypair.
However, even if the fd code will do this today (I don't know; I've
not checked the source), it appears that you can't specify more than
two keypairs in the fd configuration file anyway, so there's no way
to trigger it.

I don't have an issue with the diagram as an explanation, it's just
that it describes the (AFAIK non-existent) general case solution.

Devin


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] data key rollover strategy

[Martin Simmons]

> On Wed, 18 Nov 2015 16:17:20 -0700, Devin Reade said:
> 
> My alerting system tells me that I have some file daemons that have been
> merrily encrypting their data for quite a while.  In particular, the
> expiry dates for the data encryption x509 certs are coming up soon.
> 
> Well, this brings up an interesting question that I'd not really
> considered in depth:  Given that you can only specify two keys
> in the bacula-fd.conf file, what is the best strategy during key
> rollover?  That is, that time period after making a new client
> keypair available, and the retention time of the backups that were
> made with the old keypair?

Does Bacula ever check for expired certs?  I suspect not, so the question
about rollover strategy is a moot one.

__Martin

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] data key rollover strategy

[Heitor Faria]

>> On Wed, 18 Nov 2015 16:17:20 -0700, Devin Reade said:
>> 
>> My alerting system tells me that I have some file daemons that have been
>> merrily encrypting their data for quite a while.  In particular, the
>> expiry dates for the data encryption x509 certs are coming up soon.
>> 
>> Well, this brings up an interesting question that I'd not really
>> considered in depth:  Given that you can only specify two keys
>> in the bacula-fd.conf file, what is the best strategy during key
>> rollover?  That is, that time period after making a new client
>> keypair available, and the retention time of the backups that were
>> made with the old keypair?
> 
> Does Bacula ever check for expired certs?  I suspect not, so the question
> about rollover strategy is a moot one.

Hello Martin: I know it checks for expired certs when using communication 
encryption, probably when initializing the TLS context.
Don't know if its the same when encrypting data.

> __Martin

Regards,
=== 
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems Certified 
Administrator II 
Do you need Bacula training? http://bacula.us/video-classes/ 
I do Bacula training and deploy in any city of the world. More information: 
http://bacula.us/ 
+55 61 8268-4220 
Site: http://bacula.us FB: heitor.faria 
===

--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

[Bacula-users] data key rollover strategy

[Devin Reade]

My alerting system tells me that I have some file daemons that have been
merrily encrypting their data for quite a while.  In particular, the
expiry dates for the data encryption x509 certs are coming up soon.

Well, this brings up an interesting question that I'd not really
considered in depth:  Given that you can only specify two keys
in the bacula-fd.conf file, what is the best strategy during key
rollover?  That is, that time period after making a new client
keypair available, and the retention time of the backups that were
made with the old keypair?

First off, I think that the master key specification doesn't enter
the picture; there is still a need for encrypting with the master
public key, for the usual reasons.

The first section of the data encryption chapter says to not change
the location of the client keypair.  Fair enough.  This implies that
the new keypair should be used to overwrite the old.  That's great
for performing backups, but what about doing restores?

I suspect the answer is:
  1. Save a copy of the old keypair (presumably there are copies
 offline already, but best to be explicit)
  2. Overwrite the old client keypair with the new keypair.
  3. Resume backup operations.
  4. If you have to restore data from a time after the key replacement,
 then it's business as usual.
  5. If you have to restore data from a time prior to the key replacement,
 then you need to copy the old keypair over top of the new,
 (presumably) restart the file daemon, perform the restore,
 copy the new keypair back on top of the old, restart the file daemon,
 and then continue with normal operations again.

This implies that you also need to keep track of what the flag day
is when you change the certificate for a given client.  (Although this
may be recorded in your certificate maintenance system, if any.)

Does anyone have a better procedure?

Devin


--
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users