January 22, 2014
eCryptfs Security Audit
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 . 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 . 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 , 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  http://thread.gmane.org/gmane.comp.file-systems.ecryptfs.general/494  http://www.spinics.net/lists/ecryptfs/msg00381.html  http://ecryptfs.sourceforge.net/ecryptfs.pdf  https://defuse.ca/audits/encfs.htm