[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Weak tarsnap keys generated on FreeBSD 11-CURRENT
-----BEGIN PGP SIGNED MESSAGE-----
The people affected by this should have seen the FreeBSD mailing list post
already, but in case anyone missed it: FreeBSD 11-CURRENT (but not any of
the releases or stable branches) has had randomness issues since October 30th:
If you have tarsnap keys which were *generated* on FreeBSD 11-CURRENT with an
affected kernel, it is probably possible for me, Amazon, or the NSA to decrypt
archives stored using those keys. See below for instructions on key rotation.
Merely *using* tarsnap on an affected system is not a problem; the only place
tarsnap uses the broken entropy-generation path is during key generation.
Using keys generated on an affected system does not
(a) allow me, Amazon, the NSA, or anyone else to create archives which tarsnap
will accept as being validly signed (there is a signing key which is created
without the broken entropy code path), or
(b) allow anyone else to read, write, or delete your data (the tarsnap API
authentication keys are created without the broken entropy code path).
Obviously, people who have never used FreeBSD, or have only ever used FreeBSD
releases or stable branches are unaffected.
The FreeBSD kernel has several internal "entropy pools" which are used for
different purposes. This bug resulted in the arc4random(9) entropy pool
not being securely seeded, which has cascading effects into arc4random(3)
and then OpenSSL's entropy pool.
The only place where tarsnap relies on OpenSSL for randomness is during the
generation of RSA keys used for block encryption and archive signing. This
was a choice I made for ease of implementation: I would have preferred to
not rely on OpenSSL for randomness at all, but I wanted to use OpenSSL's code
for RSA key generation.
Every other use of entropy in tarsnap -- API authentication keys, the block
MAC key, deduplication parameters, ephemeral AES keys, the encrypted tarsnap
client-server protocol, transaction nonces, and hash tables -- makes use of
tarsnap's internal HMAC_DRBG PRNG, which is seeded from /dev/urandom and not
affected by the FreeBSD bug.
If you have been using keys generated on an affected FreeBSD system, you can
re-encrypt your data with new (securely generated) keys. First, run
# tarsnap-keyregen --keyfile key-file --oldkey old-key-file
--user user-name --machine machine-name
to generate new encryption keys which are "compatible" (for deduplication
purposes) with the old keys. (This is the same command line as tarsnap-keygen
except that it's tarsnap-key*re*gen and there's an added --oldkey parameter.)
# tarsnap-recrypt --oldkey old-key-file --oldcachedir old-cache-dir
--newkey new-key-file --newcachedir new-cache-dir
to download, verify, decrypt, re-encrypt, and re-upload your data.
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----