Encrypted filesystem on linux

March 17, 2020 — March 18, 2020

computers are awful
POSIX
Figure 1

See encrypting file systems for a run-down on why to encrypt a file system and general theory etc. There are lots of ways you can do this and lots of levels at which to do it.

In Ubuntu, from 19.04, LUKS/dm-crypt whole disk encryption is the default option. For per-user encryption fscrypt seems not too much trouble. It works OK on the desktop.

Downside: you need to type 2 passwords to log in, the hard drive decrypt key, plus the user key. fscrypt doesn’t have this problem; I can log in and use my keychain to decrypt specific user data. But on the other hand, if my whole disk (well, at least the swap disk) is not encrypted, I am vulnerable to people sniffing the encryption keys from my swap file, so this method is convenient for my attackers as well as me.

Encrypting the whole disk is probably better in the sense that if it is stolen it will be hard to crack it. Both methods are vulnerable to evil maid attacks where someone installs a key-logger on your computer while you are out to lunch.

I probably want to go with LUKS because there is less for me to mess up in that the automatic installer configures it for me, and just deal with the horrible double-password situation.

NB the ubuntu encrypted FS docs are outdated on this issue at the time of writing, but are being replaced by an updated Full Disk Encryption howto.

0.1 Filesystem stacked encryption

Ideally, you want magical transparent encrypted disks which decrypt when they log in. There are lots of user-space encryption methods you could use.

Normal files full of garbled encrypted stuff that magically turn into real data if you enter the passphrase.

Is it worth trying FUSE alternatives, gocryptfs or encfs or will they simply be too slow? Perhaps not. encfs was considered insecure in a famous security audit. It is still considered insecure by Ubuntu in 2019; I’m unclear if the later versions of encfs fix that. fscrypt has also been recommended; I’m not sure where it fits in this hierarchy.

Note that file sync app rclone can encrypt files in local mode and mount the encrypted FS, albeit with some restrictions. That might be a convenient way of doing things, since everyone should always have rclone installed just in case, although it might not be well optimized for this use case.

It’s probably easier to use a friendly GUI; Cryptomator is one cuddly friendly option. zulucrypt seems popular on Ubuntu.

All these options are free and simple.

If you do this you probably want to also have your swap memory encrypted in case your computer gets taken by the star chamber, but this requires, AFAICT, kernel-level disk encryption of the swap (see below) which, with things as they currently are, means you still need to have a fancy passphrase to decrypt the machine and thus have an extra password to forget.

0.2 Encrypted disk

luks, a.k.a. cryptsetup seems to be a popular whole-partition encryption solution for Linux, working on top of dm-crypt. Possible still messy for the boot partition but otherwise fine if you like full disk encryption. This is the default for Ubuntu now, and it works smoothly except that you need to type in a password every time you boot the machine, and that password must be long and difficult.

See also Veracrypt, which will do this plus bonus extra-crazy tinfoil hat stuff, and has the advantage of working on Windows and macOS.

0.3 dmcrypt + LVM

If you are using LVM with encryption there are a couple of layers to deal with at once and I get the various steps in the intricate dance confused.

The best how-to guides for fiddly I found were the following.

NB if you are partitioning your entire disk the installer will probably take care of it. It does for Ubuntu. The HOWTOs are only in case of dual-booting Windows.

1 When my laptop goes to sleep is encrypted data safe?

Unverified advice from LawrenceC suggests that the risk calibration runs as follows

Full disk encryption, by necessity, needs the key in RAM to encrypt/decrypt data in real time.

So —

  • Firewire has a DMA-like mode that basically allows one to scan the entire RAM of the system. Full disk keys may be recovered from a target system’s RAM if it’s connected via Firewire to a host running the right software and the target system has a Firewire driver that supports this. Your system is vulnerable to this if it is locked. I’m not sure if it’s possible to Firewire-read your RAM while it is asleep.
  • If your system is hibernating, all RAM is dumped to a hibernation file before power off. I believe Truecrypt marks pages of its driver somehow to prevent this, but as long as you keep the hibernation file on an encrypted volume you should be safe.
  • DRAM takes a while to decay after power off. Theoretically it’s possible for an adversary to remove the RAM from your system, possibly spray it with canned air to lower the temperature and lengthen the decay rate, and put it in a system or tool that scans the RAM and extracts the keys from there. It also may be possible to power cycle your system, boot off of a live CD, and recover the keys from RAM that way.

If the RAM is powered off and has decayed sufficiently, it’s not possible to get keys from it, and your encrypted data is safe in this situation.

Of course the first and third items are tinfoil-hat level stuff, but to prevent against it you should power your system down completely when you are not using it, and run Memtest86+ or your system diagnostics to clear RAM. At least one security-focused Linux distribution does this before power off, I can’t think of the name of it.

More esoteric workarounds are listed the security stack exchange, which lead one to think there might be other unadvertised tricks to get into a locked encrypted machine, and some things you should check your OS has done correctly.

So, depends on your threat profile. An option for the paranoid is to set the machine to hibernate instead of sleeping. However, this does not clear the RAM per default; that would be wise as well for a sufficiently paranoid person.