12

When using LUKS full disk encryption, how would you go about protecting against evil maids ?

The evil maid attack is when someone gets physical access to your computer while you're away and compromises the unencrypted /boot partition to capture your FDE password the next time you start your computer

One of the solutions is to leave your /boot partition on an USB stick that's always with you (the maid can't get to it), but which filesystem should I use on it, and how do I configure my system to gracefully handle removal of the USB stick (and thus the /boot partition itself) ?

I'm using CentOS, but generic, distro-agnostic answers are of course welcome. Thanks.

2 Answers 2

Reset to default
6

Finally figured it out. This still feels really hacky and dirty because the system is never aware that /boot may not be mounted and you'll have to manually mount it before doing anything that might write to it (think system updates, etc), but other than that it works perfectly.

  • prepare your flash drive with a single partition with the boot flag set on it. You may run shred -n 1 -v /dev/sdX on it to erase it completely, including any previous boot sectors; once that's done run fdisk to create a partition and mkfs your filesystem of choice on it.
  • mount your flash drive somewhere, /mnt/boot or even /newboot will do just fine.
  • move over everything from /boot to the flash drive with mv /boot/* /newboot.
  • edit your /etc/fstab and change the original boot partition's UUID (or create an entry if there isn't any) to match the one of your flash drive. You can get the UUID with lsblk -o name,uuid. Also add the noauto option so that the drive won't be mounted automatically to be able to remove it as soon as the system starts booting (once the kernel is loaded) without risking corrupting the FS on it.
  • unmount the original boot partition and the flash drive (umount /boot && umount /newboot) and mount the flash drive; if your fstab entry is correct you can just run mount /boot and it'll automatically mount it based on the UUID specified in the fstab.
  • regenerate your bootloader's configuration to reflect the new partition's UUIDs and "physical" position, for GRUB the flash drive will actually appear as the first hard drive in the computer (hd0). If you're okay with using the default GRUB configuration scripts supplied by most distros, you can run grub-mkconfig -o /path/to/grub.cfg and it'll generate the file according to the currently mounted partitions and/or fstab. Note that for CentOS 7, the correct grub.cfg is actually located in /boot/grub2/grub.cfg.

When doing any operation that may access the boot partition, connect your USB stick and run mount /boot. Once done, you may run umount /boot. Note that the latter command can take moments to complete because it's flushing the buffers to the disk (the disk itself is slow so the kernel buffers some write operations to speed things up).

1
  • Not dirty at all, it's the most obvious way to do that. Thank you for writing it out!
    – dbanet
    Sep 25, 2016 at 17:12
0

Another approach to this particular issue is to use the TPM to store an encryption key, but the defense does rely on the user to make it effective. A rudimentary, RHEL7-based solution is tpm-luks (https://github.com/GeisingerBTI/tpm-luks).

The way it works is on boot, each step of the boot process measures the next and stores this measurement into the PCRs on the TPM. Once the boot process is complete, tpm-luks checks the status of the PCRs against a "known good" configuration. If in a "known good" configuration, the TPM will unseal the LUKS key, and tpm-luks will pass this data to unlock the root LUKS partition.

Because everything important is measured with a crpytographic hash, there's essentially no way for an evil maid to replace your GRUB/kernel/ramdisk to nefariously collect your FDE passphrase. As an added bonus, you don't need an FDE passphrase at all! You could in theory completely remove the human-readable passphrase and rely entirely on the tpm-luks, but if you go that route, it's probably a good idea to store your LUKS header and keep it as a backup.

As I mentioned, this requires some diligence on the user. If you've left the computer unattended, and you are presented with a passphrase prompt, it's probably a Bad Idea to type it in until you've done some investigations. At that point, you should boot into a live CD environment and take a look to see if there's a bug in tpm-luks, or if the /boot partition was truly altered. You still are leaving the /boot partition unencrypted, but if anything important gets altered, the main disk is never decrypted.

You must log in to answer this question.