Advisory - Rsyncrypto maybe affected from Debian OpenSSL reduced entropy problem
Subject: Advisory - Rsyncrypto maybe affected from Debian OpenSSL reduced
entropy problem
Date: Friday 23 May 2008
From: Shachar Shemesh <shachar@xxxxxxxxxx>
To: L-rsyncrypto <rsyncrypto-devel@xxxxxxxxxxxxxxxxxxxxx>
Background
Rsyncrypto[1] is a file encryption tool. It has a single RSA key that
encrypts symmetric AES keys per file. The files themselves are subject
to an encryption method that is based on CBC, but does a
security-performance trade off. In particular, the files are encrypted
in such a way that re-encrypting, using the same key, a file that was
slightly modified will result in slightly modified cypher text. This is
needed so that the file will retain wire efficiency when transferred
using rsync[2].
Rsyncrypto does not generate the RSA itself. Instead, the rsyncrypto
manual instructs the user to use openssl in order to generate a private
key and a X509 certificate, and rsyncrypto will use either one of those.
Vulnerability
Rsyncrypto itself is unaffected by the openssl vulnerability introduced
into Debian[3][4]. The common use scenario, however, will lead users
toward generating predictable keys. This advisory is in place to warn
users about possible exposure.
As with the original advisory, this problem will affect you even if you
are not currently running on a vulnerable machine, or even on a Debian
or derivative OS. If your keys were generated on a vulnerable machine,
then your data is at risk.
Solution
First of all, users should make sure that they are running a version of
openssl that does not exhibit the problem. See the OpenSSL advisory for
your platform for details.
Users should regenerate the RSA key and X509 certificate used, and
re-encrypt all files using the new key. User should perform a clean
re-encryption, disregarding all context files rsyncrytpo saves,
including the file name mapping file and the symmetric key files. This
will, unfortunately, result in an encryption set that will not be
transferable in a rsync friendly way.
Less Secure Solution - Security Performance Trade Off
If the user is 100% sure that no attacker has had a chance to save an
encrypted file for later attack, one can make do with regenerating a new
RSA key and re-encrypting the files using the existing state files (file
name mapping and symmetric key files). This will result in encrypted
files that have only their header different, but otherwise have the same
name and data pay load. This should result in an easy rsync transfer of
the files to the remote location.
Be warned, however, that should the assumption of no malicious access
prove wrong, the attacker could recover the symmetric key used for
encrypting the specific file. This means that the attack could read the
file before the key update (unavoidable), but also read ALL FUTURE
ENCRYPTIONS DONE WITH THE SAME KEY. In other words, if the attacker had
any access to the file in the past, they can read all future versions as
well unless the symmetric key is also replaced.
Mitigating Factors
None that may be relied on.
Rsyncrypto does not broadcast the public key used to encrypt the file.
This makes an attacker's life harder, as she has to guess the key length
as well as the actual key. Be warned, however, that small files leak the
length of the key by nature of their size. Encrypting an empty file, for
example, will always result in a same size cypher text file. Also notice
that key lengths are rarely an arbitrary number. They are usually either
1024, 1536, 2048 or 4096 bits, which means that the attacker only has
two more bits of entropy to go through.
In short, do not rely on any of the mitigating factors.
[1] - http://sourceforge.net/projects/rsyncrypto
[2] - http://samba.anu.edu.au/rsync/
[3] - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166
[4] - http://www.debian.org/security/2008/dsa-1571