fs/crypto: file-name encryption, optional ?

fs/crypto: file-name encryption, optional ?

[Anand Jain]

Hi,

   File-name encryption was optional if I remember it correctly ?
   Now I don't see it as optional anymore, any idea ?

Thanks, Anand

Re: fs/crypto: file-name encryption, optional ?

[Richard Weinberger]

On Thu, Feb 9, 2017 at 3:53 AM, Anand Jain <anand.jain@oracle.com> wrote:
>
> Hi,
>
>   File-name encryption was optional if I remember it correctly ?
>   Now I don't see it as optional anymore, any idea ?

No idea, these days it is not optional.

-- 
Thanks,
//richard

Re: fs/crypto: file-name encryption, optional ?

[Theodore Ts'o]

On Thu, Feb 09, 2017 at 11:05:49AM +0100, Richard Weinberger wrote:
> On Thu, Feb 9, 2017 at 3:53 AM, Anand Jain <anand.jain@oracle.com> wrote:
> >
> > Hi,
> >
> >   File-name encryption was optional if I remember it correctly ?
> >   Now I don't see it as optional anymore, any idea ?
> 
> No idea, these days it is not optional.

You can create a zero-length file, and then set the encrypt flag, and
I believe that will still work.  In that case, the file will be
encrypted, even though the file name will not be encrypted.  It's not
something that we test explicitly, so it's possible it has broken.

Let me explain why we do things the way that we do.  The original
production use case of ext4 and f2fs encryption was for Android.  In
that world, you have a locked bootloader, and the system image is
protected against tampering using dm-verity.  This means that even if
your cell phone is left unattended in your hotel room in Beijing, and
an "Evil Maid" takes your phone, does a "chip off" attack where the
eMMC storage device is desoldered, and then accessed directly, and
then the phone is returned to your hotel room before you get back from
breakfast, they can't tamper with the system to capture data.

OK, but what if in this "Evil Maid" attack, a particular encrypted
directly is replaced with an empty, unencrypted directory (by messing
with the file system metadata), and it's a directory where data ends
up getting stored after its downloaded from the air --- your e-mail,
for example, or maybe the directory where your pictures from the cell
phone camera is stored.

Now a few days later, when you leave your cell phone unattended in
your hotel room in Shanghai, another "Evil Maid" might take your
phone, and harvest the data from the unencrypted directory --- and
since the directory is unencrypted, the newly created files would also
be encrypted.  Win!  The "Evil Maids" can now determine if you're from
that horrible terrorist group, the Falun Gong.  Or maybe the "Evil
Maids" are working for your competitor, and they're just after your
company's business secrets.  :-)

The defense against this is that if a directory is encrypted, the
files and sub-directory must also be encrypted, and by the same key.
This is enforced at lookup and open time.  And the hash of the key of
the top-level directories for each user are stored in a small amount
of "secure storage" available on the phone, and this is verified when
the system is booted.

(An example of such a secure storage might be a small amount of
memory, implemented in hardware where the encryption keys are stored,
and are unlocked by your pin/password.  If the pin/password is entered
incorrectly too many times, the secure storage unit will automatically
erase all of the keys stored inside.)

Cheers,

						- Ted

Re: fs/crypto: file-name encryption, optional ?

[Anand Jain]

Hi Ted,

  IMO not all data center solutions would need file-name encryption,
  its better to bring back the option to disable the file-name
  encryption.

Thanks, Anand


On 02/10/17 03:17, Theodore Ts'o wrote:
> On Thu, Feb 09, 2017 at 11:05:49AM +0100, Richard Weinberger wrote:
>> On Thu, Feb 9, 2017 at 3:53 AM, Anand Jain <anand.jain@oracle.com> wrote:
>>>
>>> Hi,
>>>
>>>   File-name encryption was optional if I remember it correctly ?
>>>   Now I don't see it as optional anymore, any idea ?
>>
>> No idea, these days it is not optional.
>
> You can create a zero-length file, and then set the encrypt flag, and
> I believe that will still work.  In that case, the file will be
> encrypted, even though the file name will not be encrypted.  It's not
> something that we test explicitly, so it's possible it has broken.
>
> Let me explain why we do things the way that we do.  The original
> production use case of ext4 and f2fs encryption was for Android.  In
> that world, you have a locked bootloader, and the system image is
> protected against tampering using dm-verity.  This means that even if
> your cell phone is left unattended in your hotel room in Beijing, and
> an "Evil Maid" takes your phone, does a "chip off" attack where the
> eMMC storage device is desoldered, and then accessed directly, and
> then the phone is returned to your hotel room before you get back from
> breakfast, they can't tamper with the system to capture data.
>
> OK, but what if in this "Evil Maid" attack, a particular encrypted
> directly is replaced with an empty, unencrypted directory (by messing
> with the file system metadata), and it's a directory where data ends
> up getting stored after its downloaded from the air --- your e-mail,
> for example, or maybe the directory where your pictures from the cell
> phone camera is stored.
>
> Now a few days later, when you leave your cell phone unattended in
> your hotel room in Shanghai, another "Evil Maid" might take your
> phone, and harvest the data from the unencrypted directory --- and
> since the directory is unencrypted, the newly created files would also
> be encrypted.  Win!  The "Evil Maids" can now determine if you're from
> that horrible terrorist group, the Falun Gong.  Or maybe the "Evil
> Maids" are working for your competitor, and they're just after your
> company's business secrets.  :-)
>
> The defense against this is that if a directory is encrypted, the
> files and sub-directory must also be encrypted, and by the same key.
> This is enforced at lookup and open time.  And the hash of the key of
> the top-level directories for each user are stored in a small amount
> of "secure storage" available on the phone, and this is verified when
> the system is booted.
>
> (An example of such a secure storage might be a small amount of
> memory, implemented in hardware where the encryption keys are stored,
> and are unlocked by your pin/password.  If the pin/password is entered
> incorrectly too many times, the secure storage unit will automatically
> erase all of the keys stored inside.)
>
> Cheers,
>
> 						- Ted
>

Re: fs/crypto: file-name encryption, optional ?

[Richard Weinberger]

Anand,

Am 10.02.2017 um 16:21 schrieb Anand Jain:
> 
> Hi Ted,
> 
>  IMO not all data center solutions would need file-name encryption,
>  its better to bring back the option to disable the file-name
>  encryption.

do you fear the overhead?
If so, did you measure it?

Thanks,
//richard

Re: fs/crypto: file-name encryption, optional ?

[Theodore Ts'o]

On Fri, Feb 10, 2017 at 04:32:28PM +0100, Richard Weinberger wrote:
> Anand,
> 
> Am 10.02.2017 um 16:21 schrieb Anand Jain:
> > 
> > Hi Ted,
> > 
> >  IMO not all data center solutions would need file-name encryption,
> >  its better to bring back the option to disable the file-name
> >  encryption.
> 
> do you fear the overhead?
> If so, did you measure it?

We did measurements on an android phone; I don't recall the exact
numbers, but it's wasn't anything we were worried about.  Certainly
not with any kind of realistic workload where the dcache means that
it's rare for the user to see the overhead in real life, but we did do
some microbenchmarks[1] as well.

[1] https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/misc/fname_benchmark.c

						- Ted

Re: fs/crypto: file-name encryption, optional ?

[Theodore Ts'o]

On Fri, Feb 10, 2017 at 11:21:17PM +0800, Anand Jain wrote:
> 
>  IMO not all data center solutions would need file-name encryption,
>  its better to bring back the option to disable the file-name
>  encryption.

Why, because you trust the HDD firmware[1]?

[1] https://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/

					- Ted

Re: fs/crypto: file-name encryption, optional ?

[Anand Jain]

On 02/10/17 23:56, Theodore Ts'o wrote:
> On Fri, Feb 10, 2017 at 11:21:17PM +0800, Anand Jain wrote:
>>
>>  IMO not all data center solutions would need file-name encryption,
>>  its better to bring back the option to disable the file-name
>>  encryption.
>
> Why, because you trust the HDD firmware[1]?
>
> [1] https://www.theregister.co.uk/2015/02/17/kaspersky_labs_equation_group/
>
> 					- Ted
>

Hi Ted, Richard,

I think my any other reason for not having file-name encryption is 
easily overridden by the reason that, if file-name encryption is not 
optional now then, it would be a regression as because it was indeed 
optional before, in EXT4.
Here its optional to an extent that, if Andorid finds file-name 
encryption is mandatory protection to effectively secure the file-data 
then, of course the file-name encryption can be enabled for their solutions.
I hope fs/crypto could provide such a flexibility.

Moreover the data center solutions has to worry about the compatibility 
of the tools and applications which may or may not run with the uid of 
the file-data.

Thanks, Anand

Re: fs/crypto: file-name encryption, optional ?

[Theodore Ts'o]

On Mon, Feb 13, 2017 at 01:57:58PM +0800, Anand Jain wrote:
> I think my any other reason for not having file-name encryption is easily
> overridden by the reason that, if file-name encryption is not optional now
> then, it would be a regression as because it was indeed optional before, in
> EXT4.

Are you sure it was optional?  If so, when?  That would have been a
bug, because the inductive requirement of the crypto policy was in the
design from the very beginning of our implementation phase.  There may
have been some design docs that talked about it being optional, but
they date from before we started thinking about how to protect against
Evil Maid attacks.

> Moreover the data center solutions has to worry about the compatibility of
> the tools and applications which may or may not run with the uid of the
> file-data.

Even without file name encryption, some tools and applications
can be blocked due to SELinux; does that mean we should give up on
SELinux because it breaks "compatibility"?

Or if they were expecting to read the data contents, the updatedb(8)
program will break once file encryption is turned on.  That doesn't
mean we should give up on data block encryption.

It perhaps might be more useful if you were to talk about *specific*
tools and applications you are concerned about, instead of trying to
talk about this in the abstract, since by definition enhanced security
techniques will always break *some* compatibility --- of rootkits, and
attack tools used by Evil Maids if nothing else!

Regards,

						- Ted

Re: fs/crypto: file-name encryption, optional ?

[Anand Jain]

On 02/13/17 23:41, Theodore Ts'o wrote:
> On Mon, Feb 13, 2017 at 01:57:58PM +0800, Anand Jain wrote:
>> I think my any other reason for not having file-name encryption is easily
>> overridden by the reason that, if file-name encryption is not optional now
>> then, it would be a regression as because it was indeed optional before, in
>> EXT4.
>
> Are you sure it was optional?  If so, when?  That would have been a
> bug, because the inductive requirement of the crypto policy was in the
> design from the very beginning of our implementation phase.  There may
> have been some design docs that talked about it being optional, but
> they date from before we started thinking about how to protect against
> Evil Maid attacks.

  Ok. I can't locate now. Its confusing.
  Similarly I am corrected about the encryption context not being
  a SElinux attr, not sure where I had seen them, it rather very
  confusing.

Thanks, Anand

Re: fs/crypto: file-name encryption, optional ?

[Anand Jain]

> OK, but what if in this "Evil Maid" attack, a particular encrypted
> directly is replaced with an empty, unencrypted directory (by messing
> with the file system metadata), and it's a directory where data ends
> up getting stored after its downloaded from the air --- your e-mail,
> for example, or maybe the directory where your pictures from the cell
> phone camera is stored.
>
> Now a few days later, when you leave your cell phone unattended in
> your hotel room in Shanghai, another "Evil Maid" might take your
> phone, and harvest the data from the unencrypted directory --- and
> since the directory is unencrypted, the newly created files would also
> be encrypted.  Win!  The "Evil Maids" can now determine if you're from
> that horrible terrorist group, the Falun Gong.  Or maybe the "Evil
> Maids" are working for your competitor, and they're just after your
> company's business secrets.  :-)
>
> The defense against this is that if a directory is encrypted, the
> files and sub-directory must also be encrypted, and by the same key.
> This is enforced at lookup and open time.  And the hash of the key of
> the top-level directories for each user are stored in a small amount
> of "secure storage" available on the phone, and this is verified when
> the system is booted.

  Right. How does file-name encryption comes as a defense for the above
  Evil maid attack ? Sorry looks like I am missing something to be
  convinced.

Thanks, Anand