[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