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@xxxxxxxxxx> 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
