Ext4 encryption patches for Android | Hacker News Reader

Ext4 encryption patches for Android

thread.gmane.org

39 pointsxrstf9 comments

Dug in trying to understand what's wrong with dm-crypt (+ LUKS on my desktop) I use on Android already. No real answers.

Interesting quote from dm-crypt dev:

> As the primary DM maintainer I've yet to see a single report about dm-crypt performance being a pain point for android. Yet ext4 developers have gotten to a point where AOSP changes were introduced to use their newly crafted encryption support. Amazing really.

ref: https://lwn.net/Articles/639736/

No real answers or benchmark data. Anyone know why I'd want to use this over dm-crypt?

> Anyone know why I'd want to use this over dm-crypt?

    - mixing unencrypted with encrypted data (why encrypting object files during bulk builds?)
    - file-based, encrypted backups for free (including incremental jobs!)
    - passwords/keys per directory
    - passwords/keys per user
    - passwords/keys per group
    - (...)

People who like encfs/cryptfs will probably like this too.

This is about trying to "catch up" to the encryption Apple has in HFS+. On iOS, there are a number of different policies that can protect a file: it can always be accessible, be accessible only after the user first unlocks their device, or only be accessible while the device is unlocked. The ability to say "I have locked my device: destroy the in-memory keys used to decrypt most of my data" is really powerful and important, as otherwise I can attack your running phone that I steal out of your pocket to obtain your data. This kind of flexibility just doesn't fit at the level of a block device.

Is there a security benefit to encrypting at the filesystem layer as opposed to just encrypting the underlying block device (like dm-crypt)? It seems like whole-disk encryption would be much harder to accidentally implement insecurely.

ArchLinux wiki has a great overview and comparison of disk encryption methods available to Linux:

https://wiki.archlinux.org/index.php/Disk_encryption#Data_en...

In addition it compares encrypting partitions vs specific data.

Whole-disk encryption is simpler, but less secure than filesystem level encryption. Block level encryption can't protect against active attacks because it doesn't have the extra space to store checksums. Algorithms are much more vulnerable when the attacker can make modifications and see the response. This makes disk level encryption only suitable for protecting against your laptop being stolen.

Don't know if ext4 encryption supports it, but the filesystem could allocate extra space for checksums to verify files aren't being modified. It also could store different keys for each file or directory making it possible to lock and unlock portions of the filesystem separately.

> Algorithms are much more vulnerable when the attacker can make modifications and see the response.

That means having access to the block device itself, with the system in an unlocked state.

If you've reached that scenario, then it's game over for whatever data is being encrypted.

Heh, if anyone with access to the design document reads this, I get an "access denied" error on the Google Doc mentioned in the mail.

Try https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa... instead. Or LWN's take at http://lwn.net/SubscriberLink/639427/5357c92c58eb584a/ .

Reply on news.ycombinator.com