21

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.

Improve this question
2
  • Not enough for an answer but Vault may be able to help: github.com/openstack-charmers/vaultlocker
    – Josh
    Commented Mar 31, 2021 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
    – Chris Davies
    Commented Apr 2, 2021 at 8:01

4 Answers 4

Reset to default
19

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.

Improve this answer
8
  • 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
    Commented Apr 1, 2021 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
    Commented Apr 1, 2021 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
    Commented Apr 6, 2021 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
    Commented Apr 6, 2021 at 17:04
  • 1
    @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
    Commented Apr 6, 2021 at 21:23
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.

Improve this answer
5
  • One could also put whole /boot on the USB drive.
    – jpa
    Commented Apr 1, 2021 at 5: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
    Commented Apr 1, 2021 at 5: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
    Commented Apr 7, 2021 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
    Commented Apr 8, 2021 at 2: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
    Commented Apr 8, 2021 at 7: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

Improve this answer
2
  • 1
    I think it's also possible 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
    Commented Apr 7, 2021 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
    Commented Apr 8, 2021 at 2: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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .