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
