Message-Id: <201008261405.19069.micha@povworld.org>
Date: Thu, 26 Aug 2010 14:05:18 +0200
From: Micha Riser <micha@...world.org>
To: encfs-users@...ts.sourceforge.net
Cc: full-disclosure@...ts.grok.org.uk, vgough@...ox.com
Subject: Multiple Vulnerabilities in EncFS

EncFs is a file system encryption solution for Linux and can be found on 
http://www.arg0.net/encfs

A security analysis of EncFS has revealed multiple vulnerabilities:
(1) Only 32 bit of file IV used
(2) Watermarking attack
(3) Last block with single byte is insecure

1.  Only 32 bit of file IV used
-------------------------------------
By default, EncFS adds an 8byte random value as header of each encrypted file. 
These bytes are supposed to be used to randomize the initialization vectors of 
the blocks. However, we have noticed that from these 8 bytes, only 4 bytes are 
actually used for this purpose. The other 4 bytes get lost as a uint64 
datatype is handled over as a 32-bit integer argument.

2. Watermarking attack
--------------------------
Watermarking is an attack which does not give any secrets to the attacker but
allows him to prove that the user of the encrypted file system has a certain
file stored on his drive. The file has previously been specially prepared by the
attacker.

Following [1], data encrypted with the CBC cipher mode is vulnerable to 
watermarking attacks under some circumstances. Consider a file which is divided 
into file blocks B1 , ..., Bk of blocksize which are individually encrypted 
using CBC and AES (whereas each file block consists of blocksize/16 cipher 
blocks) (as in EncFS). The attack succeeds if the attacker is able to 
calculate the XOR of the initialization vectors (IV) for some Bi and Bj , i != 
j. If so, the attacker prepares the first plain text blocks of block i and j 
such:
  Pi1 XOR Pj1 = IV(i) XOR IV(j)
and therefor
  Pi1 XOR IV(i) = Pj1 XOR IV(j)
This causes that 
 Ci1  = Enc(Pi1 XOR IV(i)) = Enc(Pj1 XOR IV(j)) = Cj1
i.e. the first cipher block of file blocks i and j are identical. Therefore, the 
attacker can test the cipher blocks Ci1 and Cj1 and conclude with high 
probability whether this is his prepared file or not.

We analyzed the distribution of IV(i) XOR IV(j) for a randomly chosen blocks 
and a random so-called fileIV which is used to make the IVs different from file 
to file. This showed that IV(i) XOR IV(j) is not at all uniformly distributed. 
There is a certain value for IV(i) XOR IV(j) which is highly more probable 
that expected for a uniform distribution (2*10^-4).

We then watermarked a file such that the even file blocks start with the found 
value and the odd file blocks with all zero. So, the encrypted file is 
successfully recognized by testing whether there are two consecutive file 
blocks that start with the same cipher block. Using a file with 50000 blocks we 
achieved a probability of > 99.9% of recognizing the watermarked file.

3. Last block with single byte is insecure
-------------------------------------------------------
The CFB cipher mode is insecure if it is used twice with the same 
initialization vector. In CFB, the first block of the plain text is XOR-ed with 
the encrypted IV:
  C0 = P0 XOR Ek (IV )
Therefore, for two cipher blocks C0 and C0' encrypted with the same IV, it 
holds that:
  C0 XOR C0' = (P0 XOR Ek (IV )) XOR (P0' XOR Ek (IV )) = P0 XOR P0'
This means that an attacker gets the XOR of the two plain texts. EncFs uses a 
modified version of CFB which additionally shuffles and reverses bytes. It is not 
clear however, if the modifications generally help against this problem.

A security problem arises definitely if the last block contains only a single
byte and an attacker has two versions of the last block. Operating on a single
byte, the shuffle and reverse operation do nothing. What remains is a double
encryption with CFB and XOR-ing the two cipher bytes gives the XOR of the
two plain text bytes due to the reason described above. Encrypting the last 
block with a stream cipher instead of a block cipher saves at most 16 bytes 
(one cipher block). We think it would be better to sacrifice these bytes and in 
exchange rely only on a single encryption mode for all blocks which simplifies 
both the crypto analysis and the implementation.


References:

[1] Clemens Fruhwirth. New methods in hard disk encryption. Technical 
reportInstitute for Computer Languages, Vienna University of Technology, 2005.

Download attachment "watermark-attack-encfs.tar.gz" of type "application/x-compressed-tar" (99988 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists