Information leakage from the ecryptfs filesystem

Question

I'm wondering what information might be leaked from the ecryptfs filesystem. This is what Ubuntu uses if you check the box for "encrypted home directory" when using the desktop installer, so is probably quite widely used. Key characteristics of it:

• each file is encrypted individually and stored in the underlying filesystem
• each file is padded in size to be a multiple of 4096 bytes, with a minimum of 12288 (except for directories and soft links)
• file and directory names are encrypted
• the directory structure is maintained

(Note I haven't found a spec about the above, this is worked out from observing my own filesystem - it's stored in /home/.ecryptfs/USERNAME/.Private if you want to examine your own).

So assuming you can't break the encryption keys then you can't examine the contents of the files. However there is still some information left to examine, and just as traffic analysis can deduce useful information from encrypted communications data, I'm wondering how much someone might be able to work out from the directory structure and approximate file sizes.

Certainly you could work out which directories and files contained music, video and photographs from file size. You might even be able to work out what music and videos existed. You could probably work out some of the applications in use due to their pattern of config/cache directories - firefox vs chrome etc.

Is there anything else? Is there a standard analysis of what could be deduced? Does anything else spring to mind?

(I must admit I assumed there was no padding of file sizes when I started writing this question - I'm reassured that there is).

Answer 1

^{(Disclosure: I'm the author of the functionality that you're asking about (good question!).)}

Ubuntu's Encrypted Home Directory feature uses eCryptfs as the filesystem encryption technology. eCryptfs is a layered filesystem built directly into the Linux kernel. It mounts one directory on top of another. The top directory is really just a "virtual" mountpoint. Applications (and humans) can operate within that directory and read and write data without needing to know or be bothered by the encryption that's happening underneath. The lower directory is where the actual encrypted files are stored on disk.

This approach has several advantages. Unlike dmcrypt or full disk encryption, you don't have to pre-allocate a fixed amount of space dedicated to encryption. You can also limit what gets encrypted a bit more to the information that's truly unique to you (improving overall system performance and power consumption). There is some privilege separation between users, with each user having their own unique mount point and encryption keys. And this particular feature is hooked into PAM, so that your directory is mounted automatically when you login, and unmounted when you logout. Also, each and every file is encrypted with a unique, randomly generated key called the 'fek' (which is stored in the header of the file, and wrapped with the MOUNT passphrase). What this means is that two cleartext files that are binary equivalent encrypt to two completely different ciphertexts!

On the flip side, there are a few things that you should be aware of -- now to the meat of your question!

• The upper and lower file structure is pretty much identical, and some file names might be deduced (based on the default Ubuntu home directory skeleton)
• File permissions, file ownerships, and file timestamps are not encrypted (so files with weird permissions, like 0123 might stand out)
• Encrypted filenames limit the upper cleartext filename to about 160 characters (as the filename encryption requires some padding)
• Swap should absolutely be encrypted, if you're using Ubuntu Encrypted Home, as anything in memory can be swapped to disk at any time (and certainly is, if you hibernate a system)
• When the filesystem is actively mounted, only Unix run time Discretionary Access Controls protect you from other users on the system (note that the home directory is permission 0700)
• When the filesystem is actively mounted, eCryptfs does NOT protect you from the root user
• Unless you move your ~/.ecryptfs/wrapped-passphrase off the local system and onto removable media (like a usb stick or flash disk), your LOGIN passphrase is the weak point of the encryption

Now, all that said, I still believe that Ubuntu's Encrypted Home delivers an outstanding balance of security and usability. It's trivial to setup, and with a good login password, it provides extremely strong protection of all of your data in $HOME against off line attacks. In other words, if someone physically steals your laptop, boots a live CD and starts digging around your $HOME/.Private encrypted data, they might glean some information about your filenames, directory structure, and timestamps. But to obtain the contents of any particular file, they will need one of:

1. your LOGIN passphrase and your wrapped-passphrase file
2. the cleartext, 128-bit long, random MOUNT passphrase (stored inside of the wrapped-passphrase file)
3. enough time to brute force the 128-bit key in 2.
4. flaws in AES256

For more information, I've written magazine articles and a running series of blog posts on eCryptfs.

Answer 2

eCryptfs information leakage can occur through various channels. The most serious and common leakage point has been the swap. As mentioned, Ubuntu now encrypts that, but I am told that hibernate is broken with that enabled. Other distros don't necessarily go out of their way to make sure swap is encrypted when eCryptfs is used.

eCryptfs makes no special effort to prevent key proliferation in memory. You can see how bad that problem is by running eCryptfs in a VM, saving state, and searching for your key material in the memory image. Storing your key on a USB drive won't help you much against any user (such as root) that has access to process/kernel memory. Without additional kernel hardening and/or MAC, eCryptfs is totally ineffective against a malicious root user. I also won't rehash the cold boot or DMA attacks that nearly every crypto system for general-purpose computers is susceptible to.

As others have mentioned, applications can write sensitive data anywhere, including places under /tmp or /var. Trying to pin that down on a per-app basis is intractable.

You can certainly use profiling and machine learning techniques to deduce information about the type of data being written and the applications writing the data. For instance, I've successfully applied a kNN model with the features being only number of eCryptfs reads and writes over epochs of time. If/when eCryptfs works on NFS/SMB, that will be a leak. Other features that are more readily observable, such as the approximate file sizes, the approximate file name lengths, and the directory structure, can reveal what type of data you're storing. For example, I would be able to trivially determine whether you had the source code for Tor or TrueCrypt on your box, since the number of files/directory structure for that is very low-entropy.

The CBC attacks in the presentation that Ninefingers referred to don't apply to eCryptfs or BitLocker, which both have 4096-byte CBC extents and non-predictable IVs. I have looked over the XTS spec, and I don't see how it is any more secure than BitLocker with AES-CBC and the Elephant diffuser.

Despite eCryptfs' weaknesses, it's better than nothing, and the ease of eCryptfs deployment makes it much more likely that people will encrypt rather than not encrypt. That said, if you want just about the best protection you can get for the confidentiality of your data-at-rest on a physical drive in your box, I recommend deploying FVE using Win7+BitLocker+TPM rather than per-file encryption using Linux+eCryptfs.

(edit: Someone told me I should state my creds on posts like this. I designed/implemented eCryptfs' crypto, and I was a senior dev on the Microsoft BitLocker team for a couple of years.)

Answer 3

So I answered this on security SE, then quickly realised I'd totally misread the question and explained everything you already know.

The question in my mind can be summarised succinctly by - does encrypting data on a per-file basis as opposed to a whole disk basis add any risk to the cryptographic security of the whole (negating for a moment the fact that if an application writes to /tmp... we know that and that problem is true of all partially encrypted systems).

I am going to say no - in fact the opposite. Whole disk encryption under CBC can be a problem. I make this assertion on the basis that whilst you can deduce information about a file from its size and therefore roughly guess contents, including delimiters such as magic numbers, known patterns, paddings etc, CBC mode is designed precisely to negate the repetition-of-key-schedule problem. Specifically, taking AES as an example, your key undergoes key expansion to form a key schedule, a longer piece of data used in the cipher. If you choose a piece of data as long as this schedule and repeat it X times then encrypt it, you should see X amounts of the same ciphertext. This property is what makes ECB problematic as the data set grows in size.

CBC mode does not have that problem to the same extent - the previous ciphertext is xor'd with the next plaintext block before encryption, meaning the plaintext does not repeat in line with the key schedule any more.

It does however have some problems. This presentation is all about disk encryption challenges and features several problems with CBC when applied to a full disk. Of note is the birthday paradox conclusion - that after a certain size ($2^{b/2}$ where $b$ is the size of the blocks) by the pigeonhole principle you run out of unique combinations and bytes begin to repeat, leaking information. There is, therefore, an upper limit to which CBC is viable, depending on configuration.

Encrypting on a per-file basis using CBC where the files themselves don't reach these values is therefore probably more secure. Modern full disk encryption techniques look at other methods such as XTS which aim to solve such problems as well as solve the encrypt-in-parallel problem (namely, you can't) with CBC.