cryptboot

Encrypted boot partition manager with UEFI Secure Boot support

Description

With encrypted boot partition, nobody can see or modify your kernel image or initramfs. systemd-boot supports booting from encrypted boot partition, but you would be still vulnerable to Evil Maid attacks.

One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don't want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign boot loader with them. Evil maid would be unable to boot modified boot loader (not signed by your keys) and whole attack is prevented.

cryptboot simply makes this easy and manageable.

Requirements

• Linux (x86_64)
• UEFI firmware with enabled Secure Boot
• cryptsetup
• openssl
• efitools
• sbsigntools
• efibootmgr
• systemd-boot

On Arch Linux, use doas pacman -S efitools sbsigntools efibootmgr.

Installation

0. Before you enroll your own keys, you can backup the ones which are currently deployed

efi-readvar -v PK -o old_PK.esl
efi-readvar -v KEK -o old_KEK.esl
efi-readvar -v db -o old_db.esl
efi-readvar -v dbx -o old_dbx.esl

1. Install your favorite Linux distribution according to its documentation.

2. Boot into UEFI firmware setup utility (frequently but incorrectly referred to as "BIOS"), enable Secure Boot and clear all preloaded Secure Boot keys (Microsoft and OEM). By clearing all Secure Boot keys, you will enter into Setup Mode (so you can enroll your own Secure Boot keys later).

   You must also set your UEFI firmware supervisor password, so nobody can simply boot into UEFI setup utility and turn off Secure Boot.

3. Generate your new UEFI Secure Boot keys:

   cryptboot-efikeys create
   

4. Enroll your newly generated UEFI Secure Boot keys into UEFI firmware:

   cryptboot-efikeys enroll
   

5. Sign boot loader with your new UEFI Secure Boot keys:

   cryptboot systemd-boot-sign
   

6. Reboot your system, you should be completely secured against evil maid attacks from now on!

Help

cryptboot

Usage: cryptboot systemd-boot-sign

Encrypted boot manager with UEFI Secure Boot support

Commands:
    systemd-boot-sign  systemd-boot-sign  Sign kernel with UEFI secure boot keys

cryptboot-efikeys

Usage: cryptboot-efikeys {create,enroll,sign,verify,list} [file-to-sign-or-verify]

Manage UEFI Secure Boot keys

Commands:
    create  Generate new UEFI Secure Boot keys
    enroll  Enroll new UEFI Secure Boot keys to your UEFI firmware
            (you have to clear old keys in your UEFI firmware setup utility first)
    sign    Sign EFI boot image file with your UEFI Secure Boot keys
    verify  Verify signature of EFI boot image file with your UEFI Secure Boot keys
    list    List all UEFI Secure Boot keys enrolled in your UEFI firmware
    status  Check if UEFI Secure Boot is active or inactive

Default configuration (/etc/cryptboot.conf)

# EFI System partition mount point (has to be specified in /etc/fstab)
EFI_DIR="/efi"

# Path to boot loader EFI file (relative to EFI_DIR)
## format: ("a" "b")
EFI_PATHS=("EFI/systemd/systemd-bootx64.efi" "EFI/BOOT/BOOTX64.EFI")

# Path to kernel images
## format: ("a" "b")
KERNEL_PATHS=("EFI/Linux")

# UEFI Secure Boot keys directory
EFI_KEYS_DIR="/etc/secureboot/keys"

Limitations

• If there is backdoor in your UEFI firmware, you are out of luck. It is GAME OVER.

  Old laptops unfortunately regularly had backdoors in BIOS:

  BIOS Password Backdoors in Laptops

  New laptops (as of 2016) should be hopefully more secure, but I am only sure about Lenovo ThinkPads (there are no known backdoor passwords and Lenovo is reportedly replacing whole system board if user forgets his supervisor password).

• You should never use same UEFI firmware supervisor password as your encryption password, because on some old laptops, supervisor password could be recovered as plaintext from EEPROM chip.

  New Lenovo ThinkPads (T440, T450, T540, X1 Carbon gen2/3, X240, X250, W540, W541, W550 and newer models) should be safe, see e.g. this presentation:

  ThinkPad BIOS Password Design for UEFI

• Attacker can also directly reflash your UEFI firmware with his own modified evil firmware, but this can be prevented by physical means (e.g. epoxy resin ;-)).

  There are also procedures how to reset supervisor password even on modern ThinkPads with SPI serial flash programmer. Again, you can use physical means for prevention.

• If you have encrypted boot partition, you can't easily use another TPM-based trusted / verified boot solution like tpmtotp or anti-evil-maid.

  This is because these solutions rely on running code from initramfs before you enter decryption password. But if you have encrypted boot partition, you have to enter decryption password before loading initramfs, so it would be already too late for these solutions to have any effect (evil firmware / boot loader will already have your password at that point).

  This can be fixed by implementing TPM support and tpmtotp or anti-evil-maid like functionality directly in the boot loader.

  The question is if this is really needed? If you don't trust UEFI firmware, why should you trust TPM? But nevertheless it would be nice to have double-check against evil maids.

Further reading

• UEFI (Secure_Boot) - https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot
• How to boot Linux using UEFI with Secure Boot? - https://ubs_csse.gitlab.io/secu_os/tutorials/linux_secure_boot.html