Do you know that you can unlock your full-disk encrypted GNU/Linux PC remotely? Cool, isn’t it? You can directly use SSH to type the password and unlock your PC.

Let’s ask ourselves: is it secure?

The answer is always: it depends.

How the full disk encryption works

To achieve full-disk encryption (aka FDE) on Linux, you usually use dmcrypt. Some filesystem modules (for example, ZFS) supports encrypting the partition content. There are no significant differences between these two solutions, except that dmcrypt will encrypt all details about the filesystem, while filesystem encryption will leak some metadata (such as ZFS pool, in case of ZFS). This leak might be an issue or not, depending on your threat model. In both cases, you don’t have plausible deniability.

dmcrypt is transparent: this means that you can use any filesystem on top of that. For example, you can encrypt an EXT2-3-4 partition or even an LVM PV: dmcrypt provides you a block device to use, and every read/write will be transparently decrypted/encrypted. Filesystem native encryption is slightly different: generally, each data block might be encrypted or not, and the filesystem driver knows which blocks are encrypted or not.

In both cases, the disk encryption is done using a key stored in the disk itself (and encrypted with the passphrase), although there is an option to save the encryption key outside the disk. Some systems support multiple passphrases for key decryption (e.g. LUKS in dmcrypt) or other methods like key files (usually in USB / smart card devices).

What happens at boot time

A typical Linux boot is something like this:

1. The BIOS loads the boot loader using the information inside the MBR. If EFI, it reads the EFI configuration and loads the boot loader directly
2. The boot loader starts and asks for the operating system to boot (or boot directly, depending on its configuration)
3. When an operating system is chosen, the boot loader proceeds to load the kernel and the initial RAM disk
4. The initial RAM disk mounts some filesystems and switch to the init inside the root partition (using chroot syscall)

Instead, when your Linux starts from a full-disk encrypted partition, the boot sequence is something like this:

1. The BIOS loads the boot loader using the information inside the MBR. If EFI, it reads the EFI configuration and loads the boot loader directly
2. The boot loader starts and asks for the operating system to boot (or boot directly, depending on its configuration)
3. When an operating system is chosen, it proceeds to load the kernel and the initial RAM disk
4. The init process inside the RAM disk is started: at some point, it asks for the password to mount the root directory and other filesystems
5. If the password is correct, it mounts some filesystems and switches to the init inside the root partition (using chroot syscall)

In step 4, the password is used to decrypt the disk encryption key. From this moment onwards, the disk-encryption key will be in RAM.

As you can see, the password is needed only in step 4 (never before that point). The reason is that your BIOS/EFI is not capable of doing encryption/decryption, so the first part is always “in clear”. This means that the kernel, the initial RAM disk and the bootloader are in plain-text.

Dropbear and initramfs

To achieve the “remote unlock” capability, the “trick” is pretty simple:

• the initial RAM disk is loaded with an SSH server a script to feed the password to the dmcrypt (or filesystem driver)
• an option is provided to the kernel with the network interface card configuration (DHCP, static IP, gateway, etc.)

When the system is (re)started, the user can connect to the initial RAM disk SSH, launch the script to feed the password and type the password (inside the SSH shell). That’s it! The boot sequence will proceed.

The trick is straightforward, and it seems that nothing is wrong with that. In reality, there are some issues.

No, it’s not a technical issue

The full disk encryption boot-sequence implemented in current FDE setups was made assuming that the attacker cannot physically alter the device because it will be trivial to break the security in case of physical tampering.

So, why do we need “remote unlock” in the first place? If the system that we’re unlocking is outside our control, we’ve already lost: anyone can tamper with the initial RAM disk, replace the script which asks for the password with a custom one and get the password. Our “remote unlock” feature can be turned against us: nothing prevents an attacker from reading the SSH keys of the dropbear server and making an SSH Man-in-the-Middle attack to steal the password.

If you really need FDE on remote devices, you need to (depending on your threat model):

• be sure of the physical security (datacenter with armed guards); or
• avoid restarting a system remotely using “remote unlock”: if the system goes down, someone needs to go there to do a complete audit of all boot components (kernel, init ramdisk, boot loader, etc.) to determine if it’s safe to boot again; or
• your threat model requires FDE only against physical data-stealing (i.e. no tampering is possible, somehow); or
• boot components (kernel, ramdisk, etc.) are stored in a local physical device (e.g. a USB drive): an operator will go to the system, plugs in the USB drive and boots the system using that drive; or
• it’s your PC at home :-)

Assumptions behind a security technology need to be understood before implementing new features. What seems a very lightweight change might result in unknown catastrophic risks.