Security with geli encrypted drives mounted at boot time

Hi,

at first I want to say that I have been reading these forums for quite some time and I really appreciate the work you guys do.

My question is about security with geli(8) encrypted disks at boot time.

The operating system is installed on an SSD ada0 and is not encrypted, but I have the following setup for a storage pool:
Two similar SATA disks ada1and ada2, each encrypted with geli(8) using the same keyfile. From ada1.eli and ada2.eli I created a zpool(8) mirror:

Code:
        NAME          STATE     READ WRITE CKSUM
        TANK          ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            ada1.eli  ONLINE       0     0     0
            ada2.eli  ONLINE       0     0     0

Everything works fine so far.
Since I intend to use jails that shall reside on TANK I need this configuration to be enabled while booting the server. The point is, to attach the encryption key to the drives I need to provide a password. Now I know there is the option of geli init -P which does not request a password, but where is the security by only using a key which is stored on ada0?
In my opinion encrypted drives make sense if there is a chance that the physical server hardware can be stolen, including the disks. Now ada1 and ada2 are encrypted which is fine, but if someone steals ada1 and ada2 he can also steal ada0 which contains the key. Attach ada0 to a different system to which the thief has root access and he can extract the key and use it to decrypt ada1 and ada2.

So where is the point in using encrypted drives that are mounted after boot? Or is there another option?

cheers,
Michael
 
I'm not particularly up on full disk encryption but I'm under the impression that most users either configure it to request a pass-phrase or store the key on something like removable USB that is only plugged in to boot (and kept on their person at other times)?
 
Hi usdmatt,

thanks for your reply. I know that geli(8) can be used to encrypt drives with either a keyfile or a passphrase or both. The point is, that even if I omit the key and use only a passphrase, if I reboot the server remotely I have no possibility to enter the passphrase. Seen from this perspective it is therefore not possible to mount the drives at startup --> zpool can not mount --> jails can not start.

I also read that the passphrase can also be stored in a file somewhere, but thats no extra in security, because this file must also reside on some disk (ada0)

cheers,
Michael
 
if I reboot the server remotely I have no possibility to enter the passphrase

My simple view on that would be that, yes, it seems you give up the ability to remotely restart a computer if you want the root filesystem encrypted, or have encrypted disks mounted automatically. Which makes sense.

On a server you just wouldn't bother encrypting the root and store all data on separate disks or partitions that you mount when the system is up. Obviously you'd have to start any services relying on the filesystems manually afterwards. One of the problems with wanting to encrypt data but I can't see any way round it. You either have to store the key somewhere the system can get to it, which anyone else can get to, or provide the password manually.
 
michaelmichael said:
In my opinion encrypted drives make sense if there is a chance that the physical server hardware can be stolen, including the disks.
Exactly. Encrypted drives won't help at all if the server gets owned. It is also useless if the attacker knows what he's doing and has physical access to the machine while it is still running because then the keys can be extracted from memory (e.g. DMA via FireWire or a cold boot attack).

Full disk encryption with geli() is nice for notebooks, for example. If some random thief grabs your notebook bag and runs off he won't be able to access your precious data.
 
I think I will reconsider the whole thing then and mount everything by hand if I have to reboot. It will probably not happen that someone hacks my server on-site, because it is located in my flat. Chances are, however, that soneone breaks in and steals the whole box. In that case I want to be sure theres no way to access data on these drives without brute-force breaking them.

Can we safely say then it is not possible to provide real security with disk encryption for mount at boot time?

cheers,
Michael
 
You could use the following setup which protects your data in the "random thief steals your server" situation:

  • The partitions on the hard drives are encrypted and non-bootable. They contain the operating system and the data. Tell the BIOS to boot from USB only.
  • The system is bootstrapped from a USB stick which is obviously bootable and just contains a /boot directory (ie. kernel, modules, loader.conf, etc.) and the geli() keys. The USB stick can (and should) be removed once the kernel starts initializing devices, i.e. right after the boot menu.
I've been using such a setup on my notebook for several years now and it works great. However, care must be taken when the kernel gets updated! Just remember to update the USB stick's /boot folder every time the one on the disk gets updated (e.g. after running freebsd-update()). It is also advisable to have an identical backup USB stick stored away in a safe place (and to remember to update this one, too).
 
For the server this is not applicable, since I mostly reboot it from a remote location, so I can not plug in or out USB sticks. This is, however, a good idea, I will try this on my netbook (which is portable and prone to be stolen).

Besides, is there another way of encrypting the whole drive without the need of a USB stick? Maybe with a password only? On my Windows laptop I use TrueCrypt for whole drive encryption and it promts for a password on powerup or reboot.

Cheers,
Michael
 
geli(8) can be set up to ask for a password on boot.

The BIOS disk password can be used on a notebook. geli(8) is not needed then, and there is no performance overhead. The data on the disk is not encrypted, but anyone who steals it will not be getting to that data without some non-trivial effort, like moving the disk platters into another drive and then getting them to work there.

Actually, some drives do encrypt the data on the disk: http://www.computerweekly.com/featu...kept-secret-in-hard-drive-encryption-security. Even Newegg has these now, from Toshiba and Seagate. Some of the fancier SSDs also support it.
 
Back
Top