436
January 22, 2014

eCryptfs Security Audit

This is the result of a short 10-hour security audit of eCryptfs. The report has been posted to the mailing list, so check there for follow-up.

Thanks to Igor Sviridov for funding this audit. 

-----------------------------------------------------------------------
                        eCryptfs Security Audit
                             Taylor Hornby
                            January 22, 2014
-----------------------------------------------------------------------

1. Introduction

   This document describes the results of a 10-hour security audit on
   the latest version (at time of writing) of the eCryptfs encrypted
   file system. It follows a previous 10-hour audit on EncFS [4].

1.1. What is eCryptfs?

   eCryptfs is an encrypting file system similar to EncFS. The main
   difference is that it runs as a kernel module instead of on top of
   FUSE.

1.2. Audit Results Summary

   Due to the limited amount of time, this audit could only cover
   a small portion of eCryptfs's design and implementation. Analysis of
   the cryptographic design was prioritized.

   Documentation about eCryptfs's crypto design is sparse and
   contradictory. The design has changed dramatically from initial
   (very old) design documents like [3]. The only reliable source is the
   actual source code itself, which takes longer to review.

   Some non-critical issues were discovered while looking over
   eCryptfs's source code. These are documented in the next section.

2. Issues

2.1. ecryptfs-rewrap-passphrase salt reuse

   Exploitability:  Low
   Security Impact: Low

   The ecryptfs-rewrap-passphrase command does not generate a new random
   salt when the password is changed. I'm not sure if this is an
   architectural requirement or not (I don't think so), but a new random
   salt would be better.

2.2. IV is the MD5 hash of key and extract (block) offset.

   Exploitability:  Low
   Security Impact: Low

   The "Root IV" is the MD5 hash of the session encryption key, which is
   a per-file random key. From the Root IV, the IV for an extract
   (portion of the file) is generated by hashing it with the offset.

   This doesn't immediately lead to vulnerabilities, and it's much
   better than the way EncFS does it, but it doesn't seem safe. It would
   be much better to use proper CBC ESSIV mode or XTS mode.

   Correction 12/05/2014: XTS mode is probably not the ideal option, see
   Thomas Ptacek's blog post for good reasons why:

       http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

   There is a comment in the code that derives the IV...

        /* TODO: It is probably secure to just cast the least
         * significant bits of the root IV into an unsigned long and
         * add the offset to that rather than go through all this
         * hashing business. -Halcrow */

   ...which is wrong, and needs to be removed.

2.3. Filename Encryption Does Not Use IVs

   Exploitability:  Low
   Security Impact: Low

   The file name encryption in encfs_write_tag_70_packet uses a zero IV
   for filename encryption. However, "random bytes" are prepended to the
   path before encrypting, and they are supposed to "do the job of the
   IV here." However, they are not actually random bytes, they are the
   hash the "session key encryption key." This key does not appear to
   change, so I doubt these bytes are serving the purpose of an IV.

   This may be required for determinism (so that you can look up a file
   path without iterating through all files in a directory), but it's
   a weird way of doing it. The comment does say "We do not want to
   encrypt the same filename with the same key and IV, which may happen
   with hard links, so we prepend random bits to each filename" ... but
   it doesn't. This needs further analysis.

   Prepending random IVs is not sufficient when using cipher modes other
   than CBC, such as GCM and CTR, which are being discussed on the
   mailing list [1,2].

   Update (February 14, 2014): Filename encryption actually uses ECB
   mode, so the random bytes are useless. Thanks to @samuelks for
   reporting this.

3. Future Work

   The following sections document what should be prioritized in future
   audits.

3.1. The Mailing List is Discussing GCM Mode

   Possible Exploitability:  Medium
   Possible Security Impact: High

   The eCryptfs mailing list is discussing the option of using other
   modes like GCM and CTR. There are already patches submitted that
   allow this, however, as far as I can tell, they haven't made it into
   the git repository.

   Using a stream mode like GCM would destroy eCryptfs's security, since
   the key stream would not depend on the plaintext and an attacker
   could simply XOR snapshots of a ciphertext at two different times to
   learn the XOR of the plaintexts that changed. This is not the case
   with a block mode like CBC (currently the default).

3.2. Authenticated Encryption

   The mailing list is discussing patches for adding authenticated
   encryption (GCM, HMAC, etc). There was not enough time to review
   these proposed changes, and I'm not sure if they're already in the
   released code or not.

3.3. Produce Crypto Documentation

   eCryptfs's current crypto implementation is not well-documented. It
   would be useful to create a document that describes it at a high
   level, so that it is easier for experienced cryptographers to review
   it.

4. Conclusion

   eCryptfs appears to have a better crypto design than EncFS [4], but
   there are some red flags indicating that it was not designed by
   a cryptographer, and has not received enough security review. It
   should be safe to use, but more auditing would be a good idea.

5. References

[1] http://thread.gmane.org/gmane.comp.file-systems.ecryptfs.general/494

[2] http://www.spinics.net/lists/ecryptfs/msg00381.html

[3] http://ecryptfs.sourceforge.net/ecryptfs.pdf

[4] https://defuse.ca/audits/encfs.htm