Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[Theodore Ts'o <tytso@mit.edu>]

On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote:
> 
>   I think AE is the only good solution for this, File-name encryption at
> this stage won't solve any kind of Evil Maid attack, (as it was quoted
> somewhere else in ML).

AE doesn't help at all against the Evil Maid attack, since the Evil
Maid is trying get the user's keying material, and what kind of
encryption you are using is pretty much irrelevant.

The typical attack (where the user's keys are available to the host
CPU) involves compromising the system software --- and system software
is public (everyone can get a copy of the Android system image for a
particular device), so encryption is pointless.  That's why the system
image is protected using dm-verity, which provides data integrity, but
not confidentiality.

The bootloader will protect against installing a new system image
unless you have the private key of the handset manufacturer to sign
said system image.  But the Evil Maid can carry out a "chip off"
attack, where flash chip is desoldered and the system image, and the
dm-verity information can be written directly without the bootloader
being able to prevent it.

This is why using AE isn't going to help you.  Sure, the Evil Maid
could try to diddle directories and use complicated crypto attacks.
But why bother when they can just simply steal the user's keys, at
which point all the AE in the world doesn't help a whit.

Cheers,

						- Ted