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

[Eric Biggers]

On Mon, Aug 28, 2017 at 08:18:55PM +0800, Anand Jain wrote:
> 
> 
> On 08/23/2017 01:36 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:35:20PM +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).
> 
> 
>   Further, below,  is define but not used.
> -
>   #define FS_AES_256_GCM_KEY_SIZE 32
> -
> 
> >>>
> >>>Yes, authenticated encryption with AES-256-GCM was in an older version of 
> >>>the
> >>>ext4 encryption design document.  But unfortunately it was never really 
> >>>thought
> >>>through. The primary problem, even ignoring rollback protection, is that 
> >>>there
> >>>is nowhere to store the per-block metadata (GCM authentication tag and IV) 
> >>>*and*
> >>>have it updated atomicly with the block contents.  Recently, dm-integrity 
> >>>solves
> >>>this at the block device layer, but it uses data journaling which is very
> >>>inefficient.  This maybe could be implemented more efficiently on a COW
> >>>filesystem like BTRFS.  But even after that, another problem is that
> >>>authenticated encryption of file contents only would not stop an attacker 
> >>>from
> >>>swapping around blocks, files, directories, or creating links, etc.
> >>
> >>
> >>  Some of the problems to be solved in this area are quite
> >>interesting and challenging and IMO BTRFS fits nicely. Per extent AE
> >>for BTRFS is drafted, it needs scrutiny and constructive feedback.
> >>
> >>Thanks, Anand
> >>
> >>
> >>>Eric
> >>>
> >
> >Where is the code?  Is there a design document, and it is it readable by 
> >people
> >not as familiar with btrfs?  Is the API compatible with ext4, f2fs, and 
> >ubifs?
> >
> >Eric
> 
>  (sorry for the delay in replay due to my vacation).
> 
>  Eric, No code yet, proposed encryption method is seeking review.
> Link sent to you.
> 
> Thanks, Anand

Thanks, I'll review it when I have time.  Can you please consider sending out a
public link to linux-fscrypt, linux-fsdevel, linux-btrfs, etc. so that other
people can review it too?

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

Hi Anand,

On Tue, Aug 29, 2017 at 11:54:47AM +0800, Anand Jain wrote:
> 
>  BTRFS has an experimental fscrypt implementation[1] which does not
> include the file-name encryption part it should be included but as
> an optional since not all uses cases saves sensitive information in
> the file-name. OR even if the attacker is able to identify a file
> called secrete.txt and break it then its still points at the
> weakness of the file-data encryption. Can we say that ? apparently
> from the discussion here it seems the answer is yes.
> 

Filenames by themselves can be sensitive information, since a filename can serve
as a strong indicator of what a file is.  For example, a filename could be used
as evidence that a person had access to a certain document.

> >Hence, making the encryption of the filenames optional doesn't just to
> >make life easier for backup/restore isn't a compelling argument, since
> >the backup/restore program is going to have to have special case
> >handling for fscrypt protected file systems *anyway*.
> 
>  fscrypt backup and restore does not work even without file-name
> encryption because the Extended Attribute needs special ioctl in the
> fscrypt (I did rise this objection before).
> 
>  But its entirely possible to create a string based encryption
> metadata which can be updated/retrieved using the legacy backup
> tools such as
> 
>   rsync --xattrs
> 
>  That will be a design for fscryptv2 probably..
> 
>  OR I mean to say possible optional file-name encryption is not the
> ground reason for the encrypted backup and restore challenge.
> 

This was already discussed.  You cannot simply add and remove the encryption
xattr from random files and directories; what happens to all the open file
descriptors, memory maps, pagecache pages, dcache entries, etc.?  Are the
existing contents and directory entries supposed to be left unencrypted, or are
they supposed to be already encrypted, or is the filesystem supposed to
automatically encrypt them when the xattr is set?  What about when the xattr is
removed?  Again, you're of course free to propose a design which takes into
account all of this and makes the argument for adding an xattr-based API, but I
haven't seen it yet.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

Hi Anand,

On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
> 
> 
> On 08/23/2017 01:07 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
> >>
> >>
> >>On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >>>On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> 
> Hi Eric,
> 
>    How about a section on the threat model specific to the file-name ?
> 
>    (Sorry if I am missing something).
> 
> Thanks, Anand
> >>>
> >>>It's already mentioned that filenames are encrypted: "fscrypt protects the
> >>>confidentiality of file contents and filenames in the event of a single
> >>>point-in-time permanent offline compromise of the block device content."
> >>>There's not much more to it than that; all the other points in the "Threat
> >>>model" section (offline manipulations, timing attacks, access control, key
> >>>eviction, etc.) are essentially the same between contents and filenames
> >>>encryption.
> >>
> >>  Do you think if application does not keep the sensitive information
> >>in the file-name, would that remove the file-name from the list of
> >>items that should be protected ?
> >>
> >
> >If *no* applications care whether the filenames are encrypted or not, sure.
> >But are you absolutely sure that no applications care?  How do you know?  
> >And what
> >is the advantage of not encrypting the filenames anyway?  It is better to
> >encrypt by default.
> >
> >Eric
> 
>  (sorry for the delay in reply due to my vacation).
> 
>  It all depends on the use case, Android is one such use case. Some
> data center use a known set of application. Again it all depends on
> the use case.
> 
>  File-name is a kind of File-system semantic and altering based on
> the on the user key context does not guarantee the system will be
> compatible with all their legacy applications.
> 

You really need to give more detail about why filename encryption specifically
is a problem.  What "legacy applications" is a problem for, and why?  What do
you mean by a "data center" use case?  Isn't contents encryption a "problem" for
some "legacy applications" as well?  Contents encryption changes filesystem
semantics as well.

>  Also a section on backup and restore in this doc will be a good
> idea. As I think that will be affected IMO. And needing to have the
> user master key to restore encrypted file isn't practical in some
> data center multi tenanted solutions. Albeit it may work in some
> cases but hard to generalize.
> 

The proposed documentation already mentions that there is no way to backup the
raw ciphertext currently.  I'll try to make this a bit clearer, but in any case
I am documenting the current state of things; the new documentation file is
*not* a plan for things that don't exist yet.  If/when someone proposes a
patchset which adds a backup+restore API they can propose a documentation update
along with it.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

If *no* applications care whether the filenames are encrypted or not, sure.
But are you absolutely sure that no applications care?  How do you know?  And 
what
is the advantage of not encrypting the filenames anyway?  It is better to
encrypt by default.


  File-name is a kind of File-system semantic and altering based on the on
the user key context does not guarantee the system will be compatible with
all their legacy applications.


In theory we could make it optional whether or not file names are
encrypted.  But that means extra complexity, and extra complexity
means potential bugs and vulnerabilities --- both potential
implementation bugs, vulnerabilities caused by users getting confused
by how they configure the system settings.  So in general with
security systems it's better to limit the complexity to the bare
minimum.


 That's right from the dev perspective. But for every security fix 
there is a convenience that is being sacrificed by the user. Providing a 
security fix even if there is no threat just adds pain to the 
user/solution and nothing else. Of course it all depends on the use case.



 BTRFS has an experimental fscrypt implementation[1] which does not 
include the file-name encryption part it should be included but as an 
optional since not all uses cases saves sensitive information in the 
file-name. OR even if the attacker is able to identify a file called 
secrete.txt and break it then its still points at the weakness of the 
file-data encryption. Can we say that ? apparently from the discussion 
here it seems the answer is yes.


 [1]
   Kernel: https://github.com/asj/linux-btrfs-fscryptv1




The only case which you've come up with in terms of potential
vulnerabilities is backup and restore, and backup and restore is
complicated for a number of numbers, since you need to be able to
backup and restore not just the file name and the encrypted data
blocks, but also the encrypted per-file key.



 So getting this right
will almost certainly require that the backup/restore software be
fscrypt aware.


 Not necessarily, as below..


Hence, making the encryption of the filenames optional doesn't just to
make life easier for backup/restore isn't a compelling argument, since
the backup/restore program is going to have to have special case
handling for fscrypt protected file systems *anyway*.


 fscrypt backup and restore does not work even without file-name 
encryption because the Extended Attribute needs special ioctl in the 
fscrypt (I did rise this objection before).


 But its entirely possible to create a string based encryption metadata 
which can be updated/retrieved using the legacy backup tools such as


  rsync --xattrs

 That will be a design for fscryptv2 probably..

 OR I mean to say possible optional file-name encryption is not the 
ground reason for the encrypted backup and restore challenge.


Thanks, Anand


Cheers,

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Theodore Ts'o]

On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
> > If *no* applications care whether the filenames are encrypted or not, sure.
> > But are you absolutely sure that no applications care?  How do you know?  
> > And what
> > is the advantage of not encrypting the filenames anyway?  It is better to
> > encrypt by default.
> > 
>  File-name is a kind of File-system semantic and altering based on the on
> the user key context does not guarantee the system will be compatible with
> all their legacy applications.

In theory we could make it optional whether or not file names are
encrypted.  But that means extra complexity, and extra complexity
means potential bugs and vulnerabilities --- both potential
implementation bugs, vulnerabilities caused by users getting confused
by how they configure the system settings.  So in general with
security systems it's better to limit the complexity to the bare
minimum.

The only case which you've come up with in terms of potential
vulnerabilities is backup and restore, and backup and restore is
complicated for a number of numbers, since you need to be able to
backup and restore not just the file name and the encrypted data
blocks, but also the encrypted per-file key.  So getting this right
will almost certainly require that the backup/restore software be
fscrypt aware.

Hence, making the encryption of the filenames optional doesn't just to
make life easier for backup/restore isn't a compelling argument, since
the backup/restore program is going to have to have special case
handling for fscrypt protected file systems *anyway*.

Cheers,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

On 08/23/2017 01:07 AM, Eric Biggers wrote:

On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:



On 08/22/2017 10:55 AM, Eric Biggers wrote:

On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:


Hi Eric,

   How about a section on the threat model specific to the file-name ?

   (Sorry if I am missing something).

Thanks, Anand


It's already mentioned that filenames are encrypted: "fscrypt protects the
confidentiality of file contents and filenames in the event of a single
point-in-time permanent offline compromise of the block device content."
There's not much more to it than that; all the other points in the "Threat
model" section (offline manipulations, timing attacks, access control, key
eviction, etc.) are essentially the same between contents and filenames
encryption.


  Do you think if application does not keep the sensitive information
in the file-name, would that remove the file-name from the list of
items that should be protected ?



If *no* applications care whether the filenames are encrypted or not, sure.
But are you absolutely sure that no applications care?  How do you know?  And 
what
is the advantage of not encrypting the filenames anyway?  It is better to
encrypt by default.

Eric


 (sorry for the delay in reply due to my vacation).

 It all depends on the use case, Android is one such use case. Some 
data center use a known set of application. Again it all depends on the 
use case.


 File-name is a kind of File-system semantic and altering based on the 
on the user key context does not guarantee the system will be compatible 
with all their legacy applications.


 Also a section on backup and restore in this doc will be a good idea. 
As I think that will be affected IMO. And needing to have the user 
master key to restore encrypted file isn't practical in some data center 
multi tenanted solutions. Albeit it may work in some cases but hard to 
generalize.



Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

On 08/23/2017 01:36 AM, Eric Biggers wrote:

On Tue, Aug 22, 2017 at 11:35:20PM +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).


  Further, below,  is define but not used.
-
  #define FS_AES_256_GCM_KEY_SIZE   32
-



Yes, authenticated encryption with AES-256-GCM was in an older version of the
ext4 encryption design document.  But unfortunately it was never really thought
through. The primary problem, even ignoring rollback protection, is that there
is nowhere to store the per-block metadata (GCM authentication tag and IV) *and*
have it updated atomicly with the block contents.  Recently, dm-integrity solves
this at the block device layer, but it uses data journaling which is very
inefficient.  This maybe could be implemented more efficiently on a COW
filesystem like BTRFS.  But even after that, another problem is that
authenticated encryption of file contents only would not stop an attacker from
swapping around blocks, files, directories, or creating links, etc.



  Some of the problems to be solved in this area are quite
interesting and challenging and IMO BTRFS fits nicely. Per extent AE
for BTRFS is drafted, it needs scrutiny and constructive feedback.

Thanks, Anand



Eric



Where is the code?  Is there a design document, and it is it readable by people
not as familiar with btrfs?  Is the API compatible with ext4, f2fs, and ubifs?

Eric


 (sorry for the delay in replay due to my vacation).

 Eric, No code yet, proposed encryption method is seeking review. Link 
sent to you.


Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

On Tue, Aug 22, 2017 at 11:35:20PM +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).
> >>
> >>
> >>  Further, below,  is define but not used.
> >>-
> >>  #define FS_AES_256_GCM_KEY_SIZE   32
> >>-
> >>
> >
> >Yes, authenticated encryption with AES-256-GCM was in an older version of the
> >ext4 encryption design document.  But unfortunately it was never really 
> >thought
> >through. The primary problem, even ignoring rollback protection, is that 
> >there
> >is nowhere to store the per-block metadata (GCM authentication tag and IV) 
> >*and*
> >have it updated atomicly with the block contents.  Recently, dm-integrity 
> >solves
> >this at the block device layer, but it uses data journaling which is very
> >inefficient.  This maybe could be implemented more efficiently on a COW
> >filesystem like BTRFS.  But even after that, another problem is that
> >authenticated encryption of file contents only would not stop an attacker 
> >from
> >swapping around blocks, files, directories, or creating links, etc.
> 
> 
>  Some of the problems to be solved in this area are quite
> interesting and challenging and IMO BTRFS fits nicely. Per extent AE
> for BTRFS is drafted, it needs scrutiny and constructive feedback.
> 
> Thanks, Anand
> 
> 
> >Eric
> >

Where is the code?  Is there a design document, and it is it readable by people
not as familiar with btrfs?  Is the API compatible with ext4, f2fs, and ubifs?

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
> 
> 
> On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> >>
> >>Hi Eric,
> >>
> >>   How about a section on the threat model specific to the file-name ?
> >>
> >>   (Sorry if I am missing something).
> >>
> >>Thanks, Anand
> >
> >It's already mentioned that filenames are encrypted: "fscrypt protects the
> >confidentiality of file contents and filenames in the event of a single
> >point-in-time permanent offline compromise of the block device content."
> >There's not much more to it than that; all the other points in the "Threat
> >model" section (offline manipulations, timing attacks, access control, key
> >eviction, etc.) are essentially the same between contents and filenames
> >encryption.
> 
>  Do you think if application does not keep the sensitive information
> in the file-name, would that remove the file-name from the list of
> items that should be protected ?
> 

If *no* applications care whether the filenames are encrypted or not, sure.  But
are you absolutely sure that no applications care?  How do you know?  And what
is the advantage of not encrypting the filenames anyway?  It is better to
encrypt by default.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

+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. ?



_However_, an "Evil Maid" attacker can probably still do other, perhaps much
more effective attacks --- e.g.

::

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


   In specific, the scenario I had in mind was the above threat.


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.


   OK.


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


  Further, below,  is define but not used.
-
  #define FS_AES_256_GCM_KEY_SIZE   32
-



Yes, authenticated encryption with AES-256-GCM was in an older version of the
ext4 encryption design document.  But unfortunately it was never really thought
through. The primary problem, even ignoring rollback protection, is that there
is nowhere to store the per-block metadata (GCM authentication tag and IV) *and*
have it updated atomicly with the block contents.  Recently, dm-integrity solves
this at the block device layer, but it uses data journaling which is very
inefficient.  This maybe could be implemented more efficiently on a COW
filesystem like BTRFS.  But even after that, another problem is that
authenticated encryption of file contents only would not stop an attacker from
swapping around blocks, files, directories, or creating links, etc.



 Some of the problems to be solved in this area are quite interesting 
and challenging and IMO BTRFS fits nicely. Per extent AE for BTRFS is 
drafted, it needs scrutiny and constructive feedback.


Thanks, Anand



Eric


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

On 08/22/2017 10:55 AM, Eric Biggers wrote:

On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:


Hi Eric,

   How about a section on the threat model specific to the file-name ?

   (Sorry if I am missing something).

Thanks, Anand


It's already mentioned that filenames are encrypted: "fscrypt protects the
confidentiality of file contents and filenames in the event of a single
point-in-time permanent offline compromise of the block device content."
There's not much more to it than that; all the other points in the "Threat
model" section (offline manipulations, timing attacks, access control, key
eviction, etc.) are essentially the same between contents and filenames
encryption.


 Do you think if application does not keep the sensitive information in 
the file-name, would that remove the file-name from the list of items 
that should be protected ?


Thanks, Anand

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

On Tue, Aug 22, 2017 at 10:22:13AM +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. ?
> 
> > _However_, an "Evil Maid" attacker can probably still do other, perhaps much
> > more effective attacks --- e.g.
> ::
> > .  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.
> 
>   In specific, the scenario I had in mind was the above threat.
> 
> > 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.
> 
>   OK.
> 
> 
>   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).
> 
> 
>  Further, below,  is define but not used.
> -
>  #define FS_AES_256_GCM_KEY_SIZE  32
> -
> 

Yes, authenticated encryption with AES-256-GCM was in an older version of the
ext4 encryption design document.  But unfortunately it was never really thought
through.  The primary problem, even ignoring rollback protection, is that there
is nowhere to store the per-block metadata (GCM authentication tag and IV) *and*
have it updated atomicly with the block contents.  Recently, dm-integrity solves
this at the block device layer, but it uses data journaling which is very
inefficient.  This maybe could be implemented more efficiently on a COW
filesystem like BTRFS.  But even after that, another problem is that
authenticated encryption of file contents only would not stop an attacker from
swapping around blocks, files, directories, or creating links, etc.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Theodore Ts'o]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> 
> Hi Eric,
> 
>   How about a section on the threat model specific to the file-name ?
> 
>   (Sorry if I am missing something).
> 
> Thanks, Anand

It's already mentioned that filenames are encrypted: "fscrypt protects the
confidentiality of file contents and filenames in the event of a single
point-in-time permanent offline compromise of the block device content."
There's not much more to it than that; all the other points in the "Threat
model" section (offline manipulations, timing attacks, access control, key
eviction, etc.) are essentially the same between contents and filenames
encryption.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

Hi Eric,

  How about a section on the threat model specific to the file-name ?

  (Sorry if I am missing something).

Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

+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. ?



_However_, an "Evil Maid" attacker can probably still do other, perhaps much
more effective attacks --- e.g.

::

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


  In specific, the scenario I had in mind was the above threat.


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.


  OK.


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



 Further, below,  is define but not used.
-
 #define FS_AES_256_GCM_KEY_SIZE32
-


Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Eric Biggers]

On Sat, Aug 19, 2017 at 10:32:27PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> > On Aug 18, 2017, at 1:47 PM, Eric Biggers  wrote:
> > > +Key hierarchy
> > > +=
> > > +
> > > +Master Keys
> > > +---
> > > +
> > > +Userspace should generate master keys either using a cryptographically
> > > +secure random number generator, e.g. by reading from ``/dev/urandom``
> > > +or calling getrandom(), or by using a KDF (Key Derivation Function).
> > > +Note that whenever a KDF is used to "stretch" a lower-entropy secret
> > > +such as a passphrase, it is critical that a KDF designed for this
> > > +purpose be used, such as scrypt, PBKDF2, or Argon2.
> > 
> > One minor suggestion - when generating a master key for a filesystem,
> > I'd think it is preferable to use /dev/random instead of /dev/urandom
> > to ensure there is enough entropy.
> 
> I would just say "use getrandom" and be done with it.  More
> importantly, we probably just want to direct users to use either
> https://github.com/google/fscrypt or Android key management system at
> the beginning of the file.
> 
> If the readers of this documentation file need to be told how to get
> good random number generators, they're very likely to make any number
> of other basic security mistakes.  If people don't think the fscrypt
> user program isn't user-friendly or flexible enough to encompass their
> use case, it's probably better to encourage them to submit
> enhancements to an existing open source key management system such as
> google/fscrypt.  If we minimize the number of userspace
> implementations, the easier it will be to make sure they are
> appropriately audited for security issues...
> 

Yes, the intent wasn't really to start a debate about /dev/random vs.
/dev/urandom vs. getrandom().  I'll probably just remove the text "e.g. by
reading from /dev/urandom or calling getrandom()".

I agree that we should recommend the 'fscrypt' userspace tool more strongly as
well.  I did mention it at the beginning of the document, but I didn't
explicitly say something like "use this instead of writing your own tool".

Either way, the kernel API should still be fully documented.  And part of that
is documenting that the master key needs to be a good pseudorandom key.
Otherwise I could imagine someone mistakenly thinking that the filesystem does
key stretching for them, for example.  (Yes, that person probably wouldn't read
the documentation and would screw up anyway, but we might as well try.)

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Theodore Ts'o]

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

In order to answer that question it's important to be specific about
threat model is like; exactly what powers does the Evil Maid actually
have?

One of the stronger form of the Evil Maid attack posits that the Evil
Made can remove the device from your hotel room, modify the hardware
undetectably (up to and including desoldering the flash chip so it can
be read and write directly), then replace it back to your hotel room,
wait for you to login, and then later on, steal your phone and
desolder the flash chip again.

This sort of attack is going to require a combination of hardware and
software features.  Without talking about future product features on
any specific future device being shipped by Google or any other
company --- theoretically, if the keys are stored a hardware device
which only disgorges the keys sends them directly to the in-line
crypto engine without letting the keys be visible to the Linux kernel
(or the Host CPU in any way at all), then it makes these sorts of Evil
Maid much more difficult.

Of course, if the Evil Maid can somehow insert something to tap the
communications channel between the key storage device and the
inline-crypto engine, then all bets are off.  Presumably, though, this
could be made harder; for example, by putting them on the
system-on-a-chip.

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Anand Jain]

+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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Theodore Ts'o]

On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> On Aug 18, 2017, at 1:47 PM, Eric Biggers  wrote:
> > +Key hierarchy
> > +=
> > +
> > +Master Keys
> > +---
> > +
> > +Userspace should generate master keys either using a cryptographically
> > +secure random number generator, e.g. by reading from ``/dev/urandom``
> > +or calling getrandom(), or by using a KDF (Key Derivation Function).
> > +Note that whenever a KDF is used to "stretch" a lower-entropy secret
> > +such as a passphrase, it is critical that a KDF designed for this
> > +purpose be used, such as scrypt, PBKDF2, or Argon2.
> 
> One minor suggestion - when generating a master key for a filesystem,
> I'd think it is preferable to use /dev/random instead of /dev/urandom
> to ensure there is enough entropy.

I would just say "use getrandom" and be done with it.  More
importantly, we probably just want to direct users to use either
https://github.com/google/fscrypt or Android key management system at
the beginning of the file.

If the readers of this documentation file need to be told how to get
good random number generators, they're very likely to make any number
of other basic security mistakes.  If people don't think the fscrypt
user program isn't user-friendly or flexible enough to encompass their
use case, it's probably better to encourage them to submit
enhancements to an existing open source key management system such as
google/fscrypt.  If we minimize the number of userspace
implementations, the easier it will be to make sure they are
appropriately audited for security issues...

- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Andreas Dilger]

On Aug 18, 2017, at 1:47 PM, Eric Biggers  wrote:
> +Key hierarchy
> +=
> +
> +Master Keys
> +---
> +
> +Userspace should generate master keys either using a cryptographically
> +secure random number generator, e.g. by reading from ``/dev/urandom``
> +or calling getrandom(), or by using a KDF (Key Derivation Function).
> +Note that whenever a KDF is used to "stretch" a lower-entropy secret
> +such as a passphrase, it is critical that a KDF designed for this
> +purpose be used, such as scrypt, PBKDF2, or Argon2.

One minor suggestion - when generating a master key for a filesystem,
I'd think it is preferable to use /dev/random instead of /dev/urandom
to ensure there is enough entropy.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

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

[Eric Biggers]

From: Eric Biggers 

Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory.  The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc, but with
many improvements made, including:

- Reflect the reality that it is not specific to ext4 anymore.
- More thoroughly document the design and user-visible API/behavior.
- Replace outdated information, such as the outdated explanation of how
  encrypted filenames are hashed for indexed directories and how
  encrypted filenames are presented to userspace without the key.
  (This was changed just before release.)

For now the focus is on the design and user-visible API/behavior, not on
how to add encryption support to a filesystem --- since the internal API
is still pretty messy and any standalone documentation for it would
become outdated as things get refactored over time.

Signed-off-by: Eric Biggers 
---
 Documentation/filesystems/fscrypt.rst | 587 ++
 Documentation/filesystems/index.rst   |  11 +
 MAINTAINERS   |   1 +
 3 files changed, 599 insertions(+)
 create mode 100644 Documentation/filesystems/fscrypt.rst

diff --git a/Documentation/filesystems/fscrypt.rst 
b/Documentation/filesystems/fscrypt.rst
new file mode 100644
index ..633d859a0ab1
--- /dev/null
+++ b/Documentation/filesystems/fscrypt.rst
@@ -0,0 +1,587 @@
+=
+Filesystem-level encryption (fscrypt)
+=
+
+Introduction
+
+
+fscrypt is a library which filesystems can hook into to support
+transparent encryption of files and directories.
+
+Note: "fscrypt" in this document refers to the kernel-level portion,
+implemented in ``fs/crypto/``, as opposed to the userspace tool
+`fscrypt `_.  This document only
+covers the kernel-level portion.  For command-line examples of how to
+use encryption, see the documentation for the userspace tool `fscrypt
+`_.
+
+Unlike dm-crypt, fscrypt operates at the filesystem level rather than
+at the block device level.  This allows it to encrypt different files
+with different keys and to have unencrypted files on the same
+filesystem.  This is useful for multi-user systems where each user's
+data-at-rest needs to be cryptographically isolated from the others.
+However, except for filenames, fscrypt does not encrypt filesystem
+metadata.
+
+Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated
+directly into supported filesystems --- currently ext4, F2FS, and
+UBIFS.  This allows encrypted files to be read and written without
+caching both the decrypted and encrypted pages in the pagecache,
+thereby halving the memory used and bringing it in line with
+unencrypted files.  Similarly, half as many dentries and inodes are
+needed.  eCryptfs also limits filenames to 143 bytes, causing
+application compatibility issues; fscrypt allows the full 255 bytes
+(NAME_MAX).  Finally, unlike eCryptfs, the fscrypt API can be used by
+unprivileged users, with no need to mount anything.
+
+fscrypt does not support encrypting files in-place.  Instead, it
+supports marking an empty directory as encrypted.  Then, after
+userspace provides the key, all regular files, directories, and
+symbolic links created in that directory tree are transparently
+encrypted.
+
+Threat model
+
+
+Offline attacks
+---
+
+Provided that userspace chooses a strong encryption key, fscrypt
+protects the confidentiality of file contents and filenames in the
+event of a single point-in-time permanent offline compromise of the
+block device content.  fscrypt does not protect the confidentiality of
+non-filename metadata, e.g. file sizes, file permissions, file
+timestamps, and extended attributes.  Also, the existence and location
+of holes (unallocated blocks which logically contain all zeroes) in
+files is not protected.
+
+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.
+
+Online attacks
+--
+
+fscrypt (and storage encryption in general) can only provide limited
+protection, if any at all, against online attacks.  In detail:
+
+fscrypt is only resistant to side-channel attacks, such as timing or
+electromagnetic attacks, to the extent that the underlying Linux
+Cryptographic API algorithms are.  If a vulnerable algorithm is used,
+such as a table-based implementation of AES, it may be possible for an
+attacker to mount a side channel attack against the online system.
+
+After an encryption key has been provided, fscrypt is not designed to
+hide the plaintext file contents or filenames from other users on the
+same system,