[Cryptography] Speeding up Linux disk encryption

Kevin W. Wall kevin.w.wall at gmail.com
Sat Apr 10 17:42:35 EDT 2021


On Sat, Apr 10, 2021 at 5:10 PM Rick Smith <me at cys.me> wrote:

> Regarding disk encryption and access control, Bear notes:
>
> > While the system is running, the disk is mounted, the process of
> > encrypting or decrypting is abstracted away, and every bit of malware
> > that works on unencrypted systems works just fine on encrypted systems.
> > Basically the encryption provides no protection beyond the first login
> > where the disk is mounted. .....
>
> Truth.
>

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, ....
>

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.

-kevin
-- 
Blog: https://off-the-wall-security.blogspot.com/    | Twitter: @KevinWWall
| OWASP ESAPI Project co-lead
NSA: All your crypto bit are belong to us.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210410/d77159e3/attachment.htm>


More information about the cryptography mailing list