18

Is it possible to encrypt the boot disk but not require users to input a password when the system boots? I have some headless boxes in remote locations for which I cannot guarantee they will be securely disposed off.

I want to avoid somebody being able to take out the disk drive and hook it up to another device and look what is on it but at the same time the system must be able to (re)boot without user interaction.

I have very little experience with encryption but I was thinking about something along the lines of storing the key in the UEFI but I am unable to find any information on whether such a thing is possible.

I'm using Ubuntu 18.04 LTS, but I could upgrade if required.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
sjaak
  • 564
  • 2
  • 8
  • 17
  • Not enough for an answer but Vault may be able to help: https://github.com/openstack-charmers/vaultlocker – Josh Mar 31 '21 at 16:24
  • I used to use an on-mobo usb stick (one of the really tiny ones). Disks on the system could be decrypted using the key stored there but if you separated the disks from the mobo they were useless – roaima Apr 02 '21 at 08:01

4 Answers4

18

To tie a disk drive to a given host, and allow it to be decrypted without requiring a manually-entered passphrase, you’d typically rely on storing or tying the encryption key to the host’s TPM (trusted platform module) or equivalent. With such a setup, the disk can’t be decrypted if it’s removed from its host.

Another possible solution, if the network is trusted, is to tie the encryption key to the network (strictly speaking, some sort of key server on the network). With such a setup, the disk can’t be decrypted if its host isn’t on the correct network.

Both of these are supported by Clevis. Clevis can use TPM2 or Tang for key binding, and can even combine multiple key sources using Shamir secret sharing. In both cases, confidentiality is ensured by using an inaccessible key at some point in the process: keys stored in the TPM can’t be extracted from it, nor can keys stored on a host elsewhere on the network.

Other tools exist, for example TPM-LUKS.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • If they notice that the key is stored in the TPM before they steal the drive, then can't they read the key out of the TPM and *then* use the drive in another host now that they know the key? – psusi Apr 01 '21 at 18:44
  • @psusi the whole point of a TPM is that you can’t extract keys from it. You can encrypt and decrypt data using keys stored in a TPM, but you can’t extract the keys from the TPM. (For disk encryption, it’s usually the disk encryption key that’s encrypted using the TPM, not the disk data itself; the TPM is too slow to encrypt/decrypt large amounts of data.) – Stephen Kitt Apr 01 '21 at 20:51
  • Ahh, but then you are back to having to provide a password to decrypt the disk key that is stored in the TPM, and avoiding that was the whole point. – psusi Apr 06 '21 at 16:30
  • @psusi how so? The TPM provides the key used to decrypt the disk encryption key, instead of the manually-entered passphrase. – Stephen Kitt Apr 06 '21 at 17:04
  • @psusi just to be clear, I have Clevis running on a number of systems; encrypted disks are made available at boot without no manual intervention if the key server is accessible, or (on the one test system set up in this way) if the disk is in the system with the right TPM. The passphrase is a failsafe if ever the key server is inaccessible or I need to access the data in a different system. One can even remove the passphrase slot to tie the data to a system with no workaround. – Stephen Kitt Apr 06 '21 at 21:23
  • You said that you can't just read the key out of the TPM; you have to provide it with a password then it decrypts the key and hands it over. If it will hand over the key without requiring a password, then we're back to my original point that if the machine can normally just read the key out of the TPM so it can boot, then an attacker can do the same and once they have the key, they can take it with the drive to a new machine. – psusi Apr 07 '21 at 15:37
  • @psusi where did I say “with a password”? The TPM never hands over the key. It’s a black box; you can feed it data to encrypt or decrypt, the key that’s used stays in the TPM. For disk encryption, you generate the disk encryption key, encrypt *that* with the TPM, and store the encrypted encryption key. It’s the same principle as a passphrase: a `dm-crypt` passphrase is used to decrypt a disk encryption key, and a TPM (or a network key server) can be used instead of a passphrase to decrypt a key. – Stephen Kitt Apr 07 '21 at 16:46
  • If an attacker has sufficient access to read the disk encryption key while the system is running, you’ve lost anyway (they can also read the decrypted data). The protection offered here covers data at rest, not while the system is running. Likewise, if an attacker steals the complete system, you’ve lost too, unless you use a network key server. – Stephen Kitt Apr 07 '21 at 16:51
7

Store the encryption key on a USB flash drive.

This is not as secure as a TPM solution, because the key is just a binary file in a standard filesystem, but if your goal is to just make the drives disposable separately from the rest of the computer, it's good enough.

Unfortunately you can't use the third column in /etc/crypttab because the flash drive would have to already be mounted and it can't, because your fstab is on an encrypted partition - creating a chicken and egg problem. But you should be able to use a keyscript (see man crypttab) or initramfs hooks.

Please note that no matter what approach you choose, the first stage of the boot process (kernel+initramfs) must remain unencrypted. That's generally not much of a problem unless you're using super-secret kernel patches (ekhm GPL ekhm ;) ) or storing something sensitive in the initramfs. So don't store the encryption key directly in the keyscript or hooks, because these get embedded inside initramfs.

gronostaj
  • 678
  • 1
  • 8
  • 18
  • One could also put whole `/boot` on the USB drive. – jpa Apr 01 '21 at 05:19
  • @jpa And the bootsector or EFI system partition too, probably. I'm not sure if that helps though, because then you can't dispose of the USB drive without wiping it. – gronostaj Apr 01 '21 at 05:53
  • GPL only causes problems if you distribute the derived work (the software with those secret patches). If you just install a device somewhere, while keeping ownership and control of it, it seems to me in no way obvious that it would be distribution. Even if that somewhere is in the premises of a client. – ilkkachu Apr 07 '21 at 13:03
  • Thank you, I will look into this further as my goal is to avoid the disk being readable when simply taking out the drive. Using a TPM chip would be best but I discovered A) not all our hardware has such a chip and B) I think this will cause problems when imaging a new device? I think using a usb stick containing the key will make decrypting the drive difficult enough that some normal user isn't going to take the time to figure it out. Are the better ways if all I need is the home dir encrypted and automatically unlocked on boot? – sjaak Apr 08 '21 at 02:58
  • @sjaak Encrypting just `/home` (on a separate partition) will be easier because you can mount the USB drive with keyfile in fstab and then use 3rd column in crypttab to unlock the home partition. This is well documented in `man crypttab`. – gronostaj Apr 08 '21 at 07:13
0

Divide OS from the DISK. Load the OS in RAM from the NET. You will send the OS with the key for the DISK. When the computer is turned on it will looking for OS by net (PXE). If someone turn off the computer don't have the OS and you will recognize that the computer has been hacked.
https://superuser.com/questions/484849/is-it-possible-to-boot-from-internet

Max
  • 1
  • 1
    I think it's also [possible](https://www.arminpech.de/2019/12/23/debian-unlock-luks-root-partition-remotely-by-ssh-using-dropbear/) to have an initramfs with an SSH server, and then connect with SSH to unlock the drive. Then again, I think both solutions would either require user interaction to enter the password or enable the network boot, or would make it somewhat simple for an attacker with access to the machine to boot it with some modifications and intercept the keys as they come over the network. Harder than just pulling the disks, of course, so depends on the threat model. – ilkkachu Apr 07 '21 at 13:08
  • Unfortunately I can't rely network boot or SSH servers as the remote location my boxes are installed in do not allow that. It needs to be a fully contained way of encrypting disks, a usb containing the key is about as "external" I can get. The goal is to avoid simply popping out a disk being enough to see what is on it. – sjaak Apr 08 '21 at 02:50
0

There is the option of having dropbear (a minimalistic SSH server) in your initramfs - and booting to a dropbear-enabled mode, that waits for you to SSH to it and provide the encryption key.

Check this example blog post.

ttsiodras
  • 2,301
  • 1
  • 21
  • 26