[Cryptography] WIPEONFORK in Linux 4.14

Theodore Ts'o tytso at mit.edu
Tue Nov 28 12:29:37 EST 2017


On Mon, Nov 27, 2017 at 01:07:25PM -0800, Henry Baker wrote:
> At 08:08 AM 11/25/2017, Jerry Leichter wrote:
> >Granted, for some media, the only alternative may be file-specific encryption (which reduces, but doesn't eliminate, the problem:
> >
> >You still need to ensure that when you erase the key, it's *really* gone).
> 
> OK, guys, I'll bite.  What would be a simple design for an
> encryption system *whose only purpose is to avoid having to zero out
> file blocks when the file is deleted*?

It's not clear whether you are assuming that there should be a
per-user key.  So I'll describe the solution used in Android's File
Based Encryption (FBE) which uses ext4 encryption as implemented by
Michael Halcrow (who also was the architect of Bitlocker, and Linux's
ecryptfs --- for which he considers ext4 encryption to be his apology
:-) and I.

The user key is a random key which is either stored in a secure
element, or encrypted using the user's passphrase or Android PIN.
(Yes, PIN's are crappy, so for devices with secure elements which zap
the PIN after so many bad tries, that's the solution to *that*
problem).

Each file is encrypted in a per-file key which is either encrypted in
one or more user keys (the original V1 format, which also was spec'ed
supported symmetric key encrpytion, but that was never implemented) or
which is derived from a nonce and the user key (what we now use
because we wanted the encryption and SELinux information to fit in the
inode table and not in an external block, and there was no product
need for multi-user/multi-key access).  The nonce or the wrapped key
is stored in an extended attribute for the file.

Directories and symlinks are similarly protected.  Because we assume
that applications are encryption oblivious, we have a security policy
which requires that if the parent directory is encrypted, its
subdirectories and files must be protected using the same key as the
parent directory.  The top-level per-user encrypted directory
hierarchies have the key identifier used to protected verified at boot
time from trusted storage to make sure they are encrypted using the
expected per-user key.  All of this is to protect against certain
chip-off attacks that might be carried out by an evil maid.

The original devices that featured FBE didn't have a secure element,
so we weren't proof evil maid attacks, but the architecture was
designed to take advantage of the appropriate hardware features to
provide protection against such attacks when available.

The result of *all* of this is precisely such that if you have a
device which has enterprise management, and the user loses their
Android or Chrome device, or the user leaves the company, the
enterprise manager can arrange to have all of the corp data wiped by
destruction of the per-user key stored on the device, without having
to do a full secure erase of the flash storage, which would wipe out
the personal data stored on the phone.

I don't know if you consider this to be a "simple" solution, but it's
a real-world deployed solution used to protect corporate data at work
today, and it's available wherever fine Android / ChromeOS devices
with FBE are for sale, and the enterprise management features are part
of Google's G Suite for Work.  :-)

Cheers,

						- Ted


More information about the cryptography mailing list