Normaly on arch linux there is no way to know wheater someone took out your ssd and modified the files on the ESP or the root partition.
By encrypting the root partition you can prevent modifications to it but the ESP has to stay unencrypted.
So we will use secure boot (with our own keys) and unified kernel images to prevent tampering with the kernel and initramfs and TPM to verify that secure boot was not disabled.
We will also use kernel lockdown mode in confidentiality mode to prevent loading unsigned kernel modules or reading kernel memory.
After following this guide, you will not have to manualy sign files with secure boot.
I AM NOT RESPONSIBLE FOR YOU BREAKING STUFF BY FOLLOWING THIS GUIDE!!
This guide assumes you already installed archlinux with a ESP mounted at /boot/ that is located at /dev/nvme0n1p1 and a LUKS2 encryped root partition that is located at /dev/nvme0n1p2and are using mkintcpio and the `linux` kernel and the fish shell and you have sudo installed and set up to let you execute commands as root.
Set up unified kernel images.
- Install
tpm2-tsswith pacman. - Set the contents of /etc/kernel/cmdline to:
rd.luks.name=uuid=root root=/dev/mapper/root rw zswap.enabled=0 rd.luks.options=tpm2-device=auto,tpm2-measure-pcr=yesreplacing uuid with the UUID of the LUKS2 root partition. (This file will define the kernel command line.) - Set /etc/mkinitcpio.d/linux.preset to
# mkinitcpio preset file for the 'linux' package #ALL_config="/etc/mkinitcpio.conf" ALL_kver="/boot/vmlinuz-linux" PRESETS=('default' 'fallback') #default_config="/etc/mkinitcpio.conf" default_image="/boot/initramfs-linux.img" default_uki="/boot/EFI/Linux/arch-linux.efi" default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp" #fallback_config="/etc/mkinitcpio.conf" fallback_image="/boot/initramfs-linux-fallback.img" fallback_uki="/boot/EFI/Linux/arch-linux-fallback.efi" fallback_options="-S autodetect" -
Set the hooks line in /etc/mkinitcpio.conf to
HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck). -
Run
sudo mkdir -p /boot/EFI/Linux. -
Run
sudo mkinitcpio -P. - Run
sudo efibootmgr --create --disk /dev/nvme0n1p1 --part 1 --label "Arch Linux" --loader '\EFI\Linux\arch-linux.efi' --unicodechanging the devices to the ones actually in use. - Reboot.
Set up UEFI for secure boot.
The exact steps for this depend on your hardware.Enter your UEFI firmware. If it has a option to delete specific keys then delete the Platform key and all microsoft keys. You may also delete the device manufactuer's keys but I do not recommend it because it may make firmware updates harder. If your UEFI does not let you delete specific keys than just delete all of them.
Then set a βAdministrator Passwordβ in your UEFI firmware configurator and store the password somewhere safe. You may have to enable secure boot in this step.
I also reccomend using some sort of tamper evidence to detect if someone opened the device to disable secure boot to get the password. (I use glitter nail polish and stickers over the screws and the blink comparison android app.)
Set up secure boot with sbctl
- Install the sbctl pacman package
- Run
sudo sbctl create-keys. - Run
sudo mkinitcpio -P. - Run
sudo sbctl enroll-keys -f --yes-this-might-brick-my-machine - Enable enforcement of secure boot in UEFI
- Reboot
Set up TPM based decryption of the root partition.
- Run
sudo systemd-cryptenroll /dev/nvme0n1p2 --wipe-slot=password --recovery-keyand save the recovery key securly. - Run
sudo systemd-cryptenroll /dev/nvme0n1p2 --wipe-slot=empty --tpm2-device=auto --tpm2-pcrs=7+15:sha256=0000000000000000000000000000000000000000000000000000000000000000 --tpm2-with-pin=yesand set the pin to whatever secret you want to be needed to decrypt the disk. Remove`--tpm2-with-pin=yes`if you do not want a secret to have to be entered in-person (like on a server). - Reboot
Set up lockdown mode.
- Make sure you do not use any unsigned kernel modules.
- Add
lockdown=confidentialityto/etc/kernel/cmdline. - Run
sudo mkinitcpio -P. - Restart the system
This setup does have some slight vulnerabilities.
For example this only secures against a attacker with root accses until a reboot becuase the secure boot keys are stored on the device.
However this setup does stop a attacker who just has accses to the SSD and not the decryption key from making it run malware.
I recommend entering a random ammount of incorrect decryption passwords incase the attacker has disabled secure boot and is trying to get your password.