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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 21 Aug 2017 16:08:21 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Anand Jain <anand.jain@...cle.com>
Cc:     "Theodore Y . Ts'o" <tytso@....edu>, linux-fscrypt@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>,
        Richard Weinberger <richard@....at>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] fscrypt: add a documentation file for filesystem-level
 encryption

On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote:
> 
> 
> >+fscrypt is not guaranteed to protect confidentiality or authenticity
> >+if an attacker is able to manipulate the filesystem offline prior to
> >+an authorized user later accessing the filesystem.
> 
>  How does fscrypt / Android protect against Evil Maid attack. ?
> 
> Thanks, Anand

As Ted mentioned, it really depends on the type of attack.

If we assume that the attacker can *only* change the contents of disk, then
there is a protection against a specific type of attack.  Android has Verified
Boot, which verifies the integrity and authenticity of the kernel and the
'system' partition: https://source.android.com/security/verifiedboot/

>From there, the vold binary (which has been authenticated using dm-verity) is
able to unwrap the encryption keys (which are authenticated using AES-GCM), then
check that the encrypted directories have the correct encryption policies.  The
filesystem then enforces the one-policy-per-tree constraint, as described in my
proposed documentation:

    Except for those special files, it is forbidden to have unencrypted
    files, or files encrypted with a different encryption policy, in an
    encrypted directory tree.  Attempts to link or rename such a file into
    an encrypted directory will fail with EPERM.  This is also enforced
    during ->lookup() to provide limited protection against offline
    attacks that try to disable or downgrade encryption in known locations
    where applications may later write sensitive data.

So on Android, an "Evil Maid" attacker cannot simply replace an encrypted
directory with an unencrypted one, causing a program to write unencrypted files
to that directory.

_However_, an "Evil Maid" attacker can probably still do other, perhaps much
more effective attacks --- e.g. installing a hardware "key logger", or perhaps
installing a binary into /data in such a way that it gets auto-executed and
compromises the system after the user logs in.  Or they could attack the actual
file contents encryption which is not authenticated.  Or they could mess around
with filesystem metadata on the userdata partition, which is neither encrypted
nor authenticated.

I suppose that dm-integrity could be used to protect against some of those
attacks, but of course it would not protect against hardware key loggers, etc.

Eric