[Cryptography] Speeding up Linux disk encryption

Jerry Leichter leichter at lrw.com
Fri Apr 9 20:40:32 EDT 2021


> My problem with disk encryption systems is that they tend to protect the
> disk contents right up until the system boots up, and not so much while
> it's running.
> 
> 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.
> 
> What disk encryption protects against is people stealing the machine or
> hard drive, and while that's a real threat, it's not the universal kind
> of threat that disk encryption is (usually) considered to protect against.
The way this is usually stated is that disk encryption provides protection for data at rest.  Of course, you have to stretch the meaning of "not at rest" a bit to make it fit, but, yes, this is exactly what disk encryption gives you.

> 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, and APIs that
> applications have to *use* (or else the application DOESN'T WORK) to
> specifically encrypt writes and decrypt reads.  'Reading' keys (half a
> symmetric pair) would be available in accounts having read permission to
> some file, and 'Writing' keys (both sides of a symmetric pair) would be
> available in accounts having write permissions to the file.
How exactly does the distinction work?  In the end, unless the system itself prevents writes unless you have the "writing" key, at best what the "writing" key gives you is integrity:  Someone without it can still *destroy* all your data; what they can't do is fool you into thinking it's valid when it no longer is.

> If it's an executable or a script, then it requires a different pair of keys;
> 'execute' permission would have half a symmetric pair and 'write
> executable' would have both halves.
You're still going to need enforcement somewhere - just key material won't do it.

I can think of a couple of very different systems with the kinds of properties you are describing:

1. In MacOS, you can create file systems within files, which can be password-protected.  Yes, when mounted, the entire file system is unencrypted - but it could contain exactly one file.

2. gMail is stored encrypted, with a unique key per user.  When you're using gMail, a machine gets assigned to your server somewhere out there.  Based on your login credentials, that server asks a key server to transfer your key to the file server holding you mail files.  This grants your server no ability read other user's email.

The thing this highlights is that what's most important is understanding the security properties your encryption scheme provides.  The important ones here are: (a) because of the centralized key server, all uses of a user's keys are audited; (b) even if someone takes over a server, they can't get access to arbitrary email:  Without being able to convince the key server that they are acting for the user, they won't be given the key.  To be able to attack a particular user, you'd have to take over the particular server their email is being served from.  What properties do you want your file system encryption scheme to have?

3. There was a very neat paper published a coupld of years ago that used the virtualization hardware on x86's chips to "turn virtualization inside out."  The problem it attacked was how to run a trusted process on an untrusted OS.  Very roughly, when a process was actually running in user mode, its memory was unencrypted.  Whenever it switched to the operating system, the hypervisor encrypted all its memory.  So the OS never had access to unencrypted contents of a process's memory space.  (The encryption was authenticated, so if the OS tried to change things, on the next switch back to it, that would be noticed.)  Since file I/O has to go through the OS, as I recall the process's files would end up containing only encrypted data as well.

I wish I had a reference.  I suspect the research was done at Microsoft, which actually supports broadly similar kinds of things (e.g., processes that are shielded against even the most privileged operators of a cloud data center) in Azure.

                                                        -- Jerry



More information about the cryptography mailing list