# Booting with encrypted root fs and passphrase on external USB stick



## giorgiob (Jul 20, 2019)

I have just installed a fresh FreeBSD 12.0 on a PC following this guide to create an encrypted root filesystem.
The system boots and works correctly. Each time I boot, I have to type in the passphrase needed to attach
the geli partition.

geli also offers the option -j to specify the passphrase on the command line. So I wonder if it is possible to store
the passphrase on an external USB stick and have geli read it from there at each boot. In this way, the usb stick
would serve as the key to unblock the system.

Is there a way to do this? I haven't found any documentation or HOWTO describing this scenario.


----------



## ralphbsz (Jul 21, 2019)

The purpose of encrypting the file system is so "attackers" can't read it. Exactly how one does this depends on which attack one is worried about.

In your case, you seem to be saying that you want the root file system encrypted, but always unlocked right after booting. OK, this implies that you are not worried about attackers who log into the running system (whether authorized login or not), nor about attackers who hack into the system and can get to the file system through the OS. It also implies that you have some defense left: If you detect that an attack is coming (for example, you see the black helicopters on the horizon), you quickly shut your machine down.

That implies to me that you are only worried about attackers who can physically take control of the machine. For example a burglar who comes and steals your computer. Or a guy with a black helicopter who comes in, sits down, and reboots the machine. Now, if you store the passphrase on a USB stick that is always physically attached to your machine, you have lost nearly all defense: both the burglar and the guy with the black helicopter can unlock your file system; all they need is the server box and the USB stick. At that point, encryption no longer makes any sense at all, just stop using encryption.

OK, it is a little more complicated. In theory, you could when you see the attacker coming take the USB stick out, and flee with it (and make sure you can run faster than a helicopter can fly). Or you could take a hammer and destroy the USB stick. But that's silly: If you have a hammer, you can also destroy the disk itself, which accomplishes the same thing.

What I'm really trying to say here is this: Security (of which encryption is a part) only works if you think through possible attacks, and how they will be handled. The boot password adds security, by requiring your body (and brain and fingers) to be physically present when booting. Take that requirement away, and encryption no longer adds any security.

By the way, this does NOT mean that I'm saying that disk encryption is utterly useless. There are scenarios where it is valuable. For example for laptops, where a human password entry is required. Usually in modern production systems, that is actually implemented using two-factor authentication: to unlock the disk requires both the human to enter a password, plus the human to have a physical item, like an encryption dongle, or a finger that matches the fingerprint scanner. That helps handle the case where the rightful owner of the password had to give it up, because they were being tortured. The other way it can help is with automated mounting, if the place that stores the passphrase is guaranteed to be secure. For example, I know of military and national security facilities that use encrypted disks (today typically using SED = self-encrypting disks, which handle security in hardware), and for automatic mounting they have a KMS = Key Management Server, which on demand distributes the equivalent of passphrases. But these places typically install the KMS hardware in metal cages that are virtually impossible to break into, and then typically station guards with machine guns in front of those cages (this is not a joke, I've worked with sites where every sys admin has an assault weapon on their back, for safety reasons). Such a setup can give you good security. Having the passphrase in cleartext on a USB stick turns security into a joke.

Finally, if you (in spite of everything) really want to do this, here is how: Don't actually encrypt the root file system, because that one needs to be unlocked during booting, and I don't know how to modify the boot loader to get the passphrase from elsewhere. Instead, encrypt only the /home file system. After all, everything other than /home just contains a copy of a FreeBSD installation. Then don't auto-mount home, but mount it using a little script that is started after booting (using cron or a rc.d service), and which first mounts the USB stick and retrieves the passphrase, then manually mounts the file system. Ultimately, it comes down to "cat /mnt/usb/passphrase | mount -o ... /home".


----------



## giorgiob (Jul 22, 2019)

Thanks for the detailed answer. The attack scenario I have in mind is a burglar who breaks into my house when I am not at home and steals my home server. The USB-stick will always be with me and I would attach it only when I have to boot / reboot the server: attaching a USB stick is faster than typing in a 40-character passphrase.

I have been using a similar solution with Linux (LUKS) and it has worked fine so far on my laptop: the USB key is attached to my key ring together with my house door key. I am trying to have a similar solution on my home server with FreeBSD. It may a bit of an overkill for a home server but if it worked I would consider using it for my laptop as well (moving my laptop from Linux to FreeBSD).

The Linux solution is quite similar to what you have sketched for the home partition: there is a script that is executed when the kernel tries to mount the root filesystem: this will look for an attached filesystem with a given label, mount it, and cat the passphrase to the program that attaches the encrypted volume. Actually, in FreeBSD it should be even easier, because geli has an option to read a passphrase from a file (no need to use cat). So I imagine it should be possible to do something similar for FreeBSD.


----------



## ralphbsz (Jul 22, 2019)

That's sensible; you are fundamentally using the USB stick as a 2FA device (two factor authentication). One wonders whether using a USB stick is optimal, since it can be easily cloned; a cryptographic security token (in the style of a YubiKey) might be better.

No, I don't know how to do this with geli for the root file system, nor how to have geli do it automatically for other file systems (the manual solution with a script you'd have to write is explained above). I'm actually surprised that LUKS implements this; when I had to use LUKS (about 3-4 years ago) it was quite primitive; I guess things have changed.


----------



## giorgiob (Jul 22, 2019)

ralphbsz said:


> That's sensible; you are fundamentally using the USB stick as a 2FA device (two factor authentication). One wonders whether using a USB stick is optimal, since it can be easily cloned; a cryptographic security token (in the style of a YubiKey) might be better.


You are right: I'd have to learn about this and how to use it. I only know that this solution exists but never tried it out.
Of course, as soon as someone gets access to my USB stick, all security is gone.


> No, I don't know how to do this with geli for the root file system, nor how to have geli do it automatically for other file systems (the manual solution with a script you'd have to write is explained above). I'm actually surprised that LUKS implements this; when I had to use LUKS (about 3-4 years ago) it was quite primitive; I guess things have changed.


I have followed this tutorial and adapted it a little bit. The basic point is that it is possible to specify a script that will be used to read the passphrase during system initialization. So I do not think it is some LUKS feature but rather of the Linux initialization procedure.


----------



## PMc (Jul 23, 2019)

ralphbsz said:


> Finally, if you (in spite of everything) really want to do this, here is how: Don't actually encrypt the root file system, because that one needs to be unlocked during booting, and I don't know how to modify the boot loader to get the passphrase from elsewhere. Instead, encrypt only the /home file system. After all, everything other than /home just contains a copy of a FreeBSD installation. Then don't auto-mount home, but mount it using a little script that is started after booting (using cron or a rc.d service), and which first mounts the USB stick and retrieves the passphrase, then manually mounts the file system. Ultimately, it comes down to "cat /mnt/usb/passphrase | mount -o ... /home".



That appears to be an affordable and practical solution indeed, with a few caveats: think about /tmp, where user files will appear to be written. Probably think about /var/log also, and maybe a lot more things in /var (mail, printer, ...).

I went that way recently, encrypting everything except the base installation (/, /usr, /var), putting most of the directories under /var into separate filesystems, and joining /tmp and /var/tmp and putting it on a separate filesystem also. My rationale is to stop "spilled data": that I can throw away a broken disk without consideration, that I can send in a broken disk for warranty without considerations, etc. Plus the burglar case. (Scientology Church, for instance, has a famous record of analyzing other people's waste baskets.)

But now I have the issue, when there is a power outage while I'm away, the server machine cannot come up again. And there seems to be no solution to that, except the mentioned -very expensive- additional security unit (e.g. KMS, mercenary troop, ...) - and each of these brings along more new problems than it solves.


----------



## k.jacker (Jul 24, 2019)

PMc said:


> But now I have the issue, when there is a power outage while I'm away, the server machine cannot come up again. And there seems to be no solution to that,


For a home server that idles at around 50 watts or so, an oversized 1000 watts UPS does a good job kepping the server up, even through extended power outages.


----------

