February 14, 2014

PEFS Security Audit

This is the result of a short 13-hour security audit of Private Encrypted File System (PEFS).

Thanks to Matt Olander for funding this audit.

                          PEFS Security Audit
                             Taylor Hornby
                           February 07, 2014

1. Introduction

   This report documents the results of a 13-hour security audit on
   Private Encrypted File System (PEFS). The audit uncovered several
   minor problems, some of which may compromise confidentiality.

1.1. What is PEFS?

   PEFS [1] is an encrypted filesystem similar to EncFS and eCryptFS.
   PEFS is unlike block-level encryption (e.g. TrueCrypt) in that the
   ciphertext mirrors the directory structure of the plaintext.

1.2. Audit Scope

   The audit was performed by reading the PEFS source code [2]. The git
   commit hash of the code that was audited is:


   This audit focused primarily on PEFS's cryptographic design and
   implementation. This includes PEFS's use of crypto primitives, but
   not the implementations of the primitives themselves (i.e. the AES
   implementation). Some integer overflow issues were discovered, but
   looking for memory corruption vulnerabilities was not a priority of
   the audit. Bugs in the file system implementation (pefs_vnops.c) were
   also out of scope.

2. Issues

   This section covers all of the security issues discovered during the
   audit. They are each given a rating in three variables:

   Exploitability: How hard is it for an attacker to exploit?
   Security Impact: How bad is it if an attacker can exploit it?
   Confirmation: Has the vulnerability been confirmed to exist?

2.1. HMAC and Other Secrets Not Compared in Constant Time

   Exploitability: Low
   Security Impact: Low
   Confirmation: Confirmed by inspecting the code.

   On line 357 of pefs_key.c, memcmp() is used to verify an HMAC. This
   introduces a timing attack that an attacker might be able to use to
   compute the HMAC of an arbitrary message. This is the HMAC used when
   encrypting child keys for the key chains feature, not the VMAC (which
   is compared in constant time).

   There are several other non-constant-time comparisons. I am not sure
   if they are relevant to security:

     - The comparison of ptk_tweak in pefs_tkey_cmp() in pefs_vnops.c.

     - Comparison of what might be cleartext filenames in
       pefs_enccn_parsedir() in pefs_vnops.c.

     - The comparisons of pk_keyid in pefs_crypto.c, pefs_ctl.c, and

   In general, when secrets are compared for equality, it should be done
   in constant time so that the running time does not leak information
   about their actual values.

2.2. Same Key Used for HMAC and Encryption

   Exploitability: Very Low
   Security Impact: Low
   Confirmation: Confirmed by inspecting the code.

   This issue affects the key chain system, which is an optional PEFS
   feature. If the key chains feature is not used, the file encryption
   is unaffected.

   The same key is used for encryption and authentication in pefs_key.c.
   This happens in the pefs_key_cipher() procedure. The variable 'key'
   is created by HMACing a distinguisher string with another key called
   pxk_key. The resulting 'key' is used twice: Once to encrypt the data,
   and a second time to HMAC the ciphertext.

   This does not create immediate problems, but using the same key for
   multiple purposes is a bad practice. Instead, use HKDF to generate
   two separate keys for the two different purposes.

2.3. Zero IV Used with CTR Mode in pefs_key.c

   Exploitability: Medium (Depends on the use case.)
   Security Impact: High
   Confirmation: Confirmed by inspecting the code.

   This issue affects the key chain system, which is an optional PEFS
   feature. If the key chains feature is not used, the file encryption
   is unaffected.

   The pefs_key_cipher() procedure in pefs_key.c encrypts data using AES
   in CTR mode with a zero IV. This means that if multiple messages are
   encrypted with the same key, they are XORed with the same keystream.

   Here's an example of how this can be exploited to reveal the context
   of another user's files:

     The key chain graph looks like:

        A -> Z
        A -> S
        B -> S

     The 'Z' key is encrypted with a parent key that only Alice knows.
     The 'S' key is encrypted with Alice's parent key as well. Bob also
     has access to 'S'.

   In this scenario, Bob knows S, so he can XOR the known value of
   S with Alice's encryption of S to get the key stream generated by
   Alice's parent key. Bob can then XOR this with Alice's Z ciphertext
   to get Z. If Bob did not know S, he could learn Z XOR S by XORing the
   two ciphertexts together.

   This is a problem whenever a parent key encrypts two or more children
   keys. Instead of using a NULL IV, a random IV should be generated at
   encryption time and stored in the ciphertext (remember to HMAC the IV

2.4. No Salt Used When Hashing Password

   Exploitability: Medium
   Security Impact: Medium
   Confirmation: Confirmed by inspecting the code.

   When deriving a key from a password, PEFS does not use salt. This is
   necessary, otherwise an attacker can use pre-computation attacks
   (lookup tables, rainbow tables, etc.) to significantly speed up the
   process of cracking PEFS-encrypted directories with weak passwords.

   Not using a salt was an explicit design decision to avoid having to
   store metadata. I recommend adding an (optional?) mode with metadata
   to support having a salt, so that if it fits the user's use case,
   they can benefit from the additional security.

2.5. Ambiguous Filename Encryption Padding

   Exploitability: Very Low
   Security Impact: Very Low
   Confirmation: Confirmed by inspecting the source code.

   The filename encryption routine pads the plaintext with null bytes.
   This is fine, since file names can't contain null bytes in UNIX, but
   if this code is reused for something else, it could become a problem.
   Pad the plaintext unambiguously by using a padding mode like PKCS#7.

2.6. Filename Encryption is Not Randomized When Files are Renamed

   Exploitability: Medium (Depends on how the user renames files.)
   Security Impact: Low
   Confirmation: Confirmed by inspecting the source code.

   PEFS uses a random 64-bit value, called the tweak, to differentiate
   between encrypted files. This value is actually re-used for three
   things. It's used as part of the XTS mode tweak, to "randomize" the
   filename encryption, and as the VMAC IV (after being encrypted).
   For the filename encryption, the tweak value is used as a substitute
   for an IV. Filenames are encrypted by first prefixing the tweak, then
   encrypting them in CBC mode with a zero IV.

   This is a problem, because the tweak does not change when files are
   renamed. With CBC mode, the IV has to be chosen randomly at the time
   of encryption, or it isn't IND-CPA secure. If the filename is
   changed, the new ciphertext will be identical to the old ciphertext
   up to the block that contains the first difference. See the third
   part of this image for an awesome visual demonstration:


   There are plans to solve this problem by encrypting filenames with
   wide-block encryption like EME2. This should be an adequate solution,
   but it needs more analysis.

   There may be other problems with the tweak design as well. More
   analysis is recommended in Section 5.3

2.7. Part of Files Encrypted with CTR Mode

   Exploitability: High
   Security Impact: Medium-High
   Confirmation: Confirmed by inspecting the code.

   If a file's size in bytes is not evenly divisible by 16, the last
   block of bytes (up to 15 bytes) is encrypted with CTR mode. If the
   last block is ever changed, and an attacker has the ciphertexts from
   before and after the change, they can XOR both ciphertexts together
   to learn the XOR of the old and new plaintexts. If the attacker knows
   (or can guess) the old plaintext, they can get the new plaintext.

   The relevant code is in xts_smallblock() in pefs_xts.c.

   The only good remediation for this (that I can think of) involves
   increasing the file size so that it is divisible by 16 bytes. I think
   the severity vulnerability justifies the increase in complexity.

2.8. gf_mul128() Does Not Execute In Constant Time

   Exploitability: Low
   Security Impact: Low
   Confirmation: Confirmed by inspecting the source code.

   The gf_mul128() procedure, part of the XTS implementation in
   pefs_xts.c, branches on a value related to its input, which could
   enable side channel attacks:

        static __inline void
        gf_mul128(uint64_t *dst, const uint64_t *src)
            static const uint8_t gf_128_fdbk = 0x87;
            int carry;

            carry = shl128(dst, src);
            if (carry != 0)  // <-- time difference could leak 'carry'
                ((uint8_t *)dst)[0] ^= gf_128_fdbk;

   I don't know if this leaks enough information to break the encryption
   (very probably not), but it's better to be safe and do it in constant
   time anyway. A constant time conditional XOR is given in [3].

2.9. Memory Corruption / Integer Overflows

   Exploitability: Unknown
   Security Impact: High (If exploitable)
   Confirmation: Not confirmed.

   I noticed several bits of code with integer overflow and
   signed/unsigned problems. I didn't have time to check if any of these
   are exploitable, or are even values controlled by the attacker, but
   I will list them here to err on the side of caution:

     - In pefs_name_encrypt(), the "+ 1" in the file name size check
       could overflow the integer and make the check pass even if
       the filename is too long:

         r = PEFS_NAME_NTOP_SIZE(pefs_name_padsize(size)) + 1;
         if (r > MAXNAMLEN) {
             return (-ENAMETOOLONG);

     - In pefs_enccn_set(), the variable encname_len is a *signed*
       integer. It is checked to be less than MAXPATHLEN then passed to
       memcpy(). When it gets passed to memcpy(), it is cast to
       a size_t, which is unsigned. If encname_len has a negative value,
       it will pass the first check, then memcpy will interpret it as
       a large unsigned value:

             if (encname_len >= MAXPATHLEN)
            panic("pefs_enccn_set: invalid encrypted name length: %d",
         // ...
         memcpy(pec->pec_buf, encname, encname_len);
         ((char *) pec->pec_buf)[encname_len] = '\0';
         pec->pec_cn.cn_namelen = encname_len;

    - Several possibilities for integer overflows in pefs_xbase64.c:

             if (datalength + 1 > targsize)
                return (-1);
         // ...
         target[tarindex]   |=  (pos - Base64) >> 4;
         if ((size_t)tarindex + 1 < targsize)
             target[tarindex+1] =
                 ((pos - Base64) & 0x0f) << 4 ;
         // ...
         target[tarindex]   |=  (pos - Base64) >> 2;
         if ((size_t)tarindex + 1 < targsize)
                     target[tarindex+1] =
                    ((pos - Base64) & 0x03) << 6;

    - Another in pefs_write_int() that could cause the
      vnode_pager_setsize() call to be skipped, which might lead to
      memory corruption down the road:

             nsize = fsize;
             MPASS(uio->uio_offset <= fsize);
             if (uio->uio_offset + uio->uio_resid > nsize) {
                PEFSDEBUG("pefs_write: extend: 0x%jx (old size: 0x%jx)\n",
                    uio->uio_offset + uio->uio_resid, nsize);
                nsize = uio->uio_offset + uio->uio_resid;
                vnode_pager_setsize(vp, nsize);

3. Commendations

   PEFS does a lot of things right. It uses standard constructions like
   XTS mode, PBKDF2, and HKDF. It also diligently zeroes buffers that
   once contained sensitive information. This makes auditing easier.

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


4. Recommendations

   There are some things that PEFS could do better:

     - Instead of re-implementing CBC mode in pefs_name_enccbc(), it
       would be better to use a well-tested implementation from a crypto

     - Use test vectors in unit tests and runtime tests to make sure the
       crypto algorithms (XTS, HKDF, PBKDF2, AES, SHA, etc.) are

     - Make pefs_hkdf_expand() take a uint8_t instead of an int for the
       'idx' parameter, so that there is a compiler warning when the
       function is used incorrectly. Or check that 'idx' is between
       0 and 255.

5. Future Work

5.1. Memory Corruption Vulnerabilities

   This audit did not focus on "classic" memory corruptions
   vulnerabilities. Because of the integer overflow issues documented in
   Issue 2.9, I think PEFS could benefit from an audit that specifically
   focuses on these concerns.

5.2. The Tweak's Triple Burden

   The 64-bit random tweak is re-used for three different purposes:

        1. It acts like an IV for the filename encryption.
        2. It is part of the XTS mode tweak.
        3. (After being Encrypted) The VMAC IV.

   There was not enough time in the audit to determine whether any of
   these three uses interact in negative ways that would, for example,
   lead to at least one of filename encryption, file contents
   encryption, or the VMAC being broken. More analysis is needed.

   The VMAC's IV appears to be taken from its input, which probably
   causes problems. This issue was not investigated in this audit since
   the VMAC is only used as a non-cryptographic checksum, and should not
   be relied on for security.

6. Conclusion

   This audit found several issues, the most significant of which are
   issues 2.3, 2.6, and 2.7. The possible existence of memory corruption
   bugs (Issue 2.9) is worrisome as well, since this code runs in kernel

   PEFS would benefit from more auditing time.

7. References

   [1] https://wiki.freebsd.org/PEFS

   [2] https://github.com/glk/pefs

   [3] http://www.iacr.org/archive/ches2009/57470001/57470001.pdf