[Cryptography] Speeding up Linux disk encryption

[Theodore Ts'o]

On Sat, Apr 10, 2021 at 05:42:35PM -0400, Kevin W. Wall wrote:
> I think what people seem to be missing here is "what is the threat model"
> for all of this FDE?
> 
> The main purpose of FDE is--and as far as I know, always has been--to
> protect "smash-and-grab" attacks, where for instance a crook is walking
> past a locked parked car, sees a laptop on the back see, smashes the window
> and grabs the laptop and runs off with it. (It provides similar protection
> if your laptop is powered down and you simply lost it.) If it's advertised
> as anything more than this, chances are, it's just hype.
> 
> Businesses who issued company laptops to their employees were the ones who
> pushed to get FDE deployed because there were way too many news stories
> popping up of stolen or lost company laptops where the employee may have
> had thousands or millions of consumer records containing PII on them and
> this was one way to address that liability. (And more effective than
> telling the employee "not to do that", especially when that employee was a
> C-level executive.)
> 
> > Disk encryption that actually provides the protections people think disk
> > > encryption provides would require a whole new filesystem type, a whole
> > > new OS mostly organized around key management, ....

I'm not sure what "people think disk encryption provides" ---
especially since what seems to be meant is "clueless pointy-hair
bosses" and not necessarily people who understand computer security.

Fancy key management really begs the question, because if the malware
can reliably impersonate a valid user, then the malware will have
access to the user's keys, and how is the OS supposed to distinguish
between a properly authorized request to look at the user's e-mail,
versus a malicious malware program?  Mind-reading?

The best we can do is (a) security patching to deny malware authors to
as many security vulnerabilities as possible, and (b) set things up so
that on a reboot, we can get back to trusted state.  (b) can be
achieved by using trusted boot, so that the firmware will only boot a
validly signed kernel, and then the kernel mounts block device where
all of its contents are protected against tampering via some kind of
integrity protection, such as a merkle tree.  Android and Chrome OS
does this using usign Linux's dm-verity feature, for example.  That
way, even if malware can break into a machine, and carry out a
privilege escalation attack, rebooting will bring the system back into
a known state.  This won't help if there is a security vulnerability
which allows the malware to break back in, but that's where (a) is so
important.

> Rather than FDE, Linux (and probably other OSes as well) offer encryption
> at the file system or even at the home directory (i.e., per user) level,
> the latter which is usually decrypted from a key partially derived from (or
> at least tied to) the user's password. While I've never tested it, I
> suppose one could perhaps tie this to autofs / automount so those
> directories get unmounted after some period of inactivity. The keys would
> of course have to be flushed / scrubbed as well. Not perfect, but it is
> probably better than the default FDE behavior. I think that ecryptfs can
> already be set up that way, but I've never used anything but the default
> because all I really care about is the 'smash-and-grab' attack vector and
> the defaults seem adequate for that.

Chrome OS uses file system-level encryption (fscrypt) where each
user's local state is stored encrypted in a key which is wiped from
memory when the logs out.  There is some cleverness so that a root
process acting on behalf of a user can reach into other users' cache
directory and delete files from the cache directory being able to
access the files' contents or names, and an enterprise adminsitrator
can set things up so that when a user logs out, Chrome OS will
forcibly reboot so that even if a user can break root and leave some
kind of key logger running, it can take advantage of the firmware's
secure boot and read-only root protected using dm-verity to get back
to a known state and wipe any in-memory malware between login sessions.

That way if you let your child borrow your Chrome OS device, and they
access some dubious part of the web, when they log out, the Chrome OS
will quickly reboot and protect the enterprise user from being
affected by any malware that might have been left behind from the
child visiting some p0rn site (for example).

Cheers,

						- Ted