Taylor Hornby
2014-01-22 18:01:44 UTC
Hi eCryptfs users and developers,
I was hired to do a quick 10-hour security audit on eCryptfs. I didn't
find any critical bugs, but there are a few things that can be improved.
My report is included below. Your comments are appreciated.
I only had time to look at a tiny portion of the code in detail.
Hopefully I will get funding to continue the 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.
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].
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
I was hired to do a quick 10-hour security audit on eCryptfs. I didn't
find any critical bugs, but there are a few things that can be improved.
My report is included below. Your comments are appreciated.
I only had time to look at a tiny portion of the code in detail.
Hopefully I will get funding to continue the 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.
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].
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
--
Taylor Hornby
Taylor Hornby