[Box Backup] Advice for users of Debian-derived systems affected by the OpenSSL fiasco -- assume compromise of all data

Ben Summers boxbackup@fluffy.co.uk
Thu, 15 May 2008 12:35:05 +0100


Right then.

The big problem is that this breaks a Box Backup claim that you don't  
need to trust your server administrator, plus it makes the  
authentication method for getting access to your data useless. Since  
the keys used to encrypt your data and log into the server are weak,  
you should consider it exposed to the server administrator and anyone  
who may have logged in with forged certificates.

I advise Box Backup users who generated their certificates/keys on  
affected Debian system to consider the security of their backups  
compromised. The server admin or anyone able to deduce the private key  
of a server or client certificates could have read your data.

If the PRNG in your OpenSSL was insufficiently random, you need to:

  * Regenerate all affected certificates, which have been generated or  
signed on an affected system

  * Regenerate all the data keys (*-FileEncKeys.raw)

  * Destroy the data stored on your server to an appropriate level of  
security (overwrite with zeros at the least, more if you're paranoid)

  * Upload everything again

  * Take appropriate measures under the assumption that you have been  
storing your data in plain text on a public server without  
authentication.

(ie, start from scratch, destroying all trace of the backed up data,  
and take other measures to mitigate the exposure of your secrets)


You need only worry about the systems where:

  * The certificates were generated or signed

  * The .raw keys were generated

  * The client which backed up data

If your server has this flaw, but no key material or signing was done  
on it, you're fine (as I understand it -- if the PRNG affects  
certificate exchanges for authentication then there's a problem).


If your certs are weak but the .raw keys are fine, assume that your  
data has not been read, but that an attacker logged in and corrupted  
your backups. Destroy the data and start again.


If your certs are fine but a client's .raw file isn't OR an affected  
client backed up data, just destroy data for that client and restart  
with that client. Assume that client's data has been exposed to the  
server admin, but not the outside world.


Note when I say the "certs are fine" I mean that all cryptographic  
operations were done on an unaffected machine, including the  
generation of the client certificate keys before signing elsewhere.


I suppose we better post something about this on the home page, after  
someone else has checked these statements.

Ben