[ale] best practices for key management w/encrypted backups

Robert Reese~ ale at sixit.com
Wed May 13 10:33:39 EDT 2009


Hi Sid,

> I have been tasked w/reviewing/testing/etc our processes for
> managing encrypted backups & it got me to thinking "what's the
> right # of keys to deploy (global master pair?  one per client? 
> one per application?)?  how often should they be rotated? 
> where/how should they be stored?", etc.
>
> my 1st inclination is to write a script to generate a metric 5h1+-
> ton of key pairs, burn them onto a bunch of CDs and distribute them
> to clients for one-time use but is that thermonuclear overkill? 
> obviously nobody wants to end up on /. but on the other hand ending
> up w/a backup you can't decrypt/restore is arguably worse (far IMO).


Then why bother encrypting it at all?  I heartily disagree that not being able 
to restore is worse.  It is certainly a less likely possibility than having your 
security compromised!  You don't mention what the encryption is protecting, but 
I'm going to assume that its leakage would cause irreparable harm to the company 
and/or to clients and/or consumers, or that it breaks regulations and statutes 
somewhere along the lines.   Ending up on /. can not only kill the company's 
reputation and possibly the business itself but can lead to lawsuits against the 
business and against the company or person(s) responsible for the security of 
that data.  Hint, hint.   Not to mention criminal charges and fines, possibly 
even jail or prison time for the responsible parties. 

If you are an employee of this company, what are your chances of gaining 
similarly-positioned employment after you get fired or the company goes under?  
Or worse, what if you find that the company survives by laying off a vast swath 
of employees?  OTOH, I suppose jail or prison and/or fine is worse than getting 
fired or sued, or being responsible for killing off a company or losing people 
their jobs.

It bears reminding that it would be very irresponsible if there were only one 
backup that could be used for restoration.  Sure, you lose a week's worth of 
work but the alternatives make that sound pretty palatable.  Furthermore, it is 
irresponsible to lose the private key or forget the passphrase which is your 
fear.

But not to worry.... you came to the right place. ;c)  As far as the keys go, 
you don't specify which encryption platform you are using.   IMnshO, PGP 
Enterprise is the way to go.  With PGP Enterprise, you can distribute a few keys 
that require more than one person's key or even multiple persons keys to open 
the encryption.  You can also use the same setup to include back door decryption 
of employee keys.

I'd use perhaps four keys in your position - the backup manager's, one that is 
divided among second-level execs and one that is divided among the top execs.  I 
would not require that all persons receiving key parts be required to decrypt 
but I would require at least three people's key parts to decrypt the backup.  
The fourth key's responsible for creating a secure container in which reside the 
backup manager's key and passphrase.  Obviously that too should have keyparts 
assigned to multiple people requiring at least three keyparts to open.  This 
scenario gives plenty of options in decrypting the backups but leaves the amount 
of keys very low.

As for the life of the key, that only affects when something can be used to 
encrypt to the public key as well as whether at the time of signing the key was 
not expired.  It does not affect whether or not something can be decrypted with 
it.  In that case the backups should be destroyed after a time period.


Of course, your question begs another: what is protecting the data on the site's 
machines?  Am I to assume the only protected data is that which is backed up?  
What system is in place to prevent the data from being leaked or otherwise 
acquired?  If encryption is being used, what is being used and how?  How can 
that system be used to model the backup system?

If you need, I probably can get you in touch with with Will Price or Jon Callas 
at PGP Corp., if just briefly.  However, I think if you go to pgp.com and look 
at their PGP Enterprise stuff you will find every question you have answered 
already, including the ones you did not ask or didn't know you had.

Cheers,
Robert~



More information about the Ale mailing list