Ext4 encryption

Posted Apr 9, 2015 16:19 UTC (Thu) by fandingo (guest, #67019)
Parent article: Ext4 encryption

> Each individual file is encrypted with its own key, which is derived from the master key and a per-file random nonce value (which is stored in an extended attribute attached to the file's inode).

I wish there was a little more discussion on this topic. It seems like an interesting choice that must be made for some specific reason. Yet, neither the article nor any of the links discuss this design choice. Is it to minimize seeking (to pull the directory master key), memory use (caching directory master key), or attempting to keep the total amount of data encrypted by a single key small?

Perhaps I'm not familiar enough with other disk encryption, but I'm not aware of other products that use a similar technique.

A longer discussion on key management would have been nice as well. There is mention of dealing with multiple users, so I wonder if keys will be managed more in line with LUKS, although the phrase "master key" is used quite often. In LUKS, there are up to 8 key slots that can be used to unlock the actual master key. Will there be a similar implementation where ext4 can store multiple key slots, and only the kernel gets access to the actual key?

Of course that leads to more complexity. Assuming that there can be multiple passphrases to access a single master key (which of course links to multiple directory master keys and multiple file keys), is it also possible to have multiple master master master keys (the kernel keyring logon keys)? It seems necessary for any sort of complex policy. Here's an example of what I mean.

3 Users -- Alice, Bob, and Eve -- are sharing a computer. Each one needs *one* and only one unique password (because password sharing is wrong) that they use to both sign into the computer and access their encrypted data. Each has their home directory encrypted, but only Alice and Bob have access to the encrypted data in /var/lib/mysql.

Do the keys and passphrases work out like this?

Eve: passphrase --> kernel logon key (serial number 0) --> /home/eve directory key --> ...
Alice: passphrase --> kernel logon key (serial number 1) --> /home/alice directory key --> ...
Alice: passphrase (same as above) --> kernel logon key (serial number 2) --> /var/lib/mysql directory key --> ...
Bob: passphrase --> kernel logon key (serial number 2) --> /home/bobdirectory key --> ...
Bob: passphrase (same as above) --> kernel logon key (serial number 1) --> /var/lib/mysql directory key --> ...

Basically, is there a mechanism for Bob and Alice to access the logon key #1 without sharing a password? I worry that if that's left to user space, a secure place to store the LUKS-style keyslot management data is lacking.

Ext4 encryption

Posted Apr 9, 2015 18:41 UTC (Thu) by fandingo (guest, #67019) [Link] (5 responses)

Another pass through the design document answered my question:

> Our present proposal allows for a single key to protect any given directory or file.

That's incredibly disappointing, although it's not completely surprising that a feature going to Android first has such fundamental limitations.

Usually "policy" means more than on/off.

So you can encrypt an arbitrary assortment of your new, empty directories, but they're all going to be based off the same key. Sounds like a proof-of-concept.

Ext4 encryption

Posted Apr 11, 2015 1:34 UTC (Sat) by mhalcrow (guest, #17371) [Link]

This meets requirements for Chromium OS and Android while keeping the total inode size within 256 bytes. So we don't need to spill over the default amount allocated for an inode, and we get a performance boost from being able to use what's already being read in.

Based on the prevalent usage patterns I've been seeing for eCryptfs, which lets you specify one policy per mount point, this per-top-level-directory approach to policy will work fine. My initial prototype let you specify file-granular policies with fancy things like synthesizing multiple keys, but it took too much xattr space and didn't seem to address any compelling requirements.

Ext4 encryption

Posted Apr 12, 2015 6:01 UTC (Sun) by tytso (subscriber, #9993) [Link] (3 responses)

It's fairer to say that this is a "Minimum Viable Product". It solves a number of important use cases for Chrome OS and for Android in the near term.

We've talked about in the future adding public key crypto, in which case there will be a per-inode key that would get encrypted once so that Alice's private key will be able to obtain the per-inode key, and once so that Bob's private key could obtain the per-inode key.

In the initial prototype, we had this support w/o public key crypto, and it didn't add a lot of value, since it meant that at the time when you created the file, you would need to have Alice and Bob's symmetric key in memory, and for both Android and Chrome OS, an important design principle is that if a user is not logged in, their key is not available (at least not in decrypted form) anywhere on the system.

The other problem is that in the initial prototype, even when you had a single per-inode key wrapped with a single user's symmetric key, the resulting size of the extended attribute, combined with the size of the SELinux policy xattr (which is a _pig_; it uses a very verbose ascii string), the resulting xattrs would require an external 4k block for each inode. This was considered extremely unfortunate.

So hence we decided to fall back to using a very compact encoding for files that were encrypted for only a single user. In the future we'll add a version 2 on-disk structure which will allow for a file to use a per-file key encrypted by multiple users' public keys. Public key is also a pig, so at that point you will definitely need to go to an external xattr block --- but the assumption is that the number of shared files that would need to be accessible by multiple users will be relatively small. Or maybe we could do something by adding another layer of indirection. We'll see. The bottom line is that there's a pretty tight deadline for getting kernel changes in for the 'M' release, and what we have is sufficient for the use cases articulated to us by both the ChromeOS and Android teams.

What might get supported in releases beyond that will be a different question, but we have plenty of time to figure that out. Consider this the first step in a journey, not the end point.

Ext4 encryption

Posted Apr 13, 2015 1:38 UTC (Mon) by fandingo (guest, #67019) [Link] (1 responses)

Thanks for the detailed reply.

This gets back to a question I had in another comment: What made the developers decide on the per-file protector? I can't wrap my head around what the actual goal of it is, and without a per-file protector, the size (and therefor performance) xattr considerations don't come into play. Obviously, there would still be a performance impact with multiple protectors on directories, and I'm not sure how much of a problem that would be in practice (plus the mechanism to iterate over multiple protectors to find the proper one for the user's key(s)).

Ext4 encryption

Posted Apr 13, 2015 3:00 UTC (Mon) by tytso (subscriber, #9993) [Link]

Why use a separate key for each file? There are a couple of advantages for doing things that way:

1) It makes it easier for us to later on migrate to allowing multiple users access to a file. Example: Alice owns a file which is encrypted in a unique key which is derived from Alice's logon key plus a unique per-file nonce. In the future, when we support public key crypto, Alice wants to allow Bob to access the file as well; so we can update the policy structure to include the per-file key encrypted using Bob's public key. If all of the files owned by Alice are encrypted directly by Alice's logon key, we wouldn't be able to do this without decrypting and re-encrypting the file in a new unique key (since otherwise Bob would have access to all of Alice's files).

2) It simplifies the XTS Tweak Value (think IV or ESSIV value if we were using CBC mode), since we can just use the logical block number of the file as the basis for the generation of the XTS Tweak value or CBC IV value. If all of the files are encrypted directly with the same key, we would have to do something such as include the inode number as part of the XTS Tweak / IV value. That in turn would break the ability to resize file systems (since sometimes the inode number could change on for some files after a resize2fs shrink operation).

Ext4 encryption

Posted Apr 13, 2015 23:37 UTC (Mon) by nix (subscriber, #2304) [Link]

Or maybe we could do something by adding another layer of indirection.

That's what LUKS does, but of course it has somewhere where it can store that sort of thing (the LUKS header). If you're storing everything on a per-file basis, it's harder: there's no obvious location to store stuff like intermediate keys (which is, in effect, how you'd implement multiple passphrases).