Ext4 encryption

Posted Apr 12, 2015 6:01 UTC (Sun) by tytso (subscriber, #9993)
In reply to: Ext4 encryption by fandingo
Parent article: Ext4 encryption

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).