Secure Boot

Secure Boot is a security feature found in the UEFI standard, designed to add a layer of protection to the pre-boot process: by maintaining a cryptographically signed list of binaries authorized or forbidden to run at boot, it helps in improving the confidence that the machine core boot components (boot manager, kernel, initramfs) have not been tampered with.

PackagesPreparations

To determine the current state of Secure Boot execute:

bootctl status

The output looks something like this:

System:
     Firmware: UEFI 2.70 (American Megatrends 5.15)
  Secure Boot: enabled
   Setup Mode: user
 Boot into FW: supported
...

In order to proceed "Secure Boot" should say "enabled" and "Setup Mode" should say "setup".

If the command displays the "Setup Mode" as "user" you need to enter your firmware settings and put the firmware into "setup" mode to proceed. This can usually be achieved by wiping the key store of the firmware.

Installation

Install the following packages for the Secure Boot toolchain:

pacman -S efitools sbsigntools sbctl

PreparationsKernel Command Line Parameters

PrepareFor commandlinethe sake of clarity, all parameters (e.g.are stored in environment variables first and then written to a file with the echo command.

Saving parameters to a file has several advantages:

• We can always refer to this file to verify which parameters are written to the unified kernel image
• Subsequent changes can be made more easily by just editing this file
• The file can easily be included in the configuration of sbupdate and both configurations are cleanly separated from each other

Command substitution ($(command)) makes it easy, reliable and scriptable to find certain values for these variables.

NOTE:For cryptlvmexample, isto usedget asthe anUUID exampleof here.the UseLUKS whatevercontainer yousimply like.

WARNING:(assuming /dev/sda1 is usedthe LUKS container):

export CRYPT_UUID=$(blkid -s UUID -o value /dev/sda1)

The command blkid -s UUID -o value /dev/sda1 just returns the UUID of the given block device. Appending export saves it in an environment variable called CRYPT_UUID which can be read by issuing echo $CRYPT_UUID.

Examples

The following examples show different ways of preparing the final kernel command line to successfully boot a machine with Secure Boot.

busybox-based initramfs

For busybox-based initramfs the LUKS container must be passed with the cryptdevice parameter. The cryptdevice parameter is passed the path to an encrypted block device, followed by a : with the desired device mapper name. Usage of persistent block device naming (i.e. the UUID of the device as returned by blkid) is strongly recommended.

cryptdevice=/dev/VolumeGroupName/LogicalVolumeName:DeviceMapperName

NOTE: By default, dm-crypt does not allow TRIM for SSDs for security reasons (information leak). To override this behavior, append :allow-discards as an exampleoption here.parameter Supplyafter the device filemapper pathname.

For an LVM on LUKS setup (with SWAP for resume) the encryptedvariables LUKScould containerlook forlike CRYPT_UUID. Failing to do so will result in an unbootable system! this:

export CRYPT_UUID=$(blkid -s UUID -o value /dev/sda1)
export CRYPT_NAME=crypt_rootcryptroot
export ROOT=/dev/mapper/vg0-lv_root
export RESUME=/dev/mapper/vg0-lv_swap
export CMDL=rw quiet splash add_efi_memmap
export ROOTFLAGS=subvol=@

echo cryptdevice=UUID=$CRYPT_UUID:$CRYPT_NAME root=$ROOT resume=$RESUME $CMDL rootflags=$ROOTFLAGS > /etc/kernel/cmdline

systemd-based initramfs

For systemd-based:based initramfs the LUKS container must be passed with the rd.luks.* parameter. The LUKS container can either be passed with the rd.luks.uuid or rd.luks.name parameter. Both take the UUID of the LUKS container, with rd.luks.name additionaly taking a parameter for a device mapper name. Usage of persistent block device naming (i.e. the UUID of the device as returned by blkid) is mandatory.

When using rd.luks.name as the boot parameter, rd.luks.uuid can be omitted as it is implied.

NOTE: By default, dm-crypt does not allow TRIM for SSDs for security reasons (information leak). To override this behavior, add rd.luks.options=discard as an additional parameter.

For a LUKS on LVM setup the variables could look like this:

export CRYPT_UUID=$(blkid -s UUID -o value /dev/sda1)
export CRYPT_NAME=crypt_rootcryptroot
export ROOT=/dev/mapper/crypt_root$CRYPT_NAME
export CMDL=rw quiet splash add_efi_memmap
export ROOTFLAGS=subvol=@

echo rd.luks.name=$CRYPT_UUID=$CRYPT_NAME root=$ROOT $CMDL rootflags=$ROOTFLAGS > /etc/kernel/cmdline

Generating keys

GenerateFURTHER READING: The Meaning of all the UEFI Keys

Secure Boot implementations use these keys:

To generate new keys and store them under /usr/share/secureboot/keys/:

sbctl create-keys

Keys will be stored under /usr/share/secureboot/keys/

Downloading and preparing Microsoft's keys

If

1. you plan on dual booting Arch Linux alongside Windows you might also want to add Microsoft's keys to the firmware key store.

   Download Microsoft’s KEK (if desired), and convert it to PEM and ESL format (with Microsoft’s GUID):

   cd /usr/share/secureboot/keys/KEK
   
   curl -L -o MicCorKEKCA2011_2011-06-24.crt 'https://go.microsoft.com/fwlink/?LinkId=321185'
   openssl x509 -inform DER -outform PEM -in MicCorKEKCA2011_2011-06-24.crt -out MicCorKEKCA2011_2011-06-24.pem
   cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorKEKCA2011_2011-06-24.pem MicCorKEKCA2011_2011-06-24.esl
   

2. Download Microsoft’s DB certificates, convert to PEM and ESL (with Microsoft’s GUID):

   cd /usr/share/secureboot/keys
   
   curl -OL https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt
   curl -OL https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt
   
   openssl x509 -inform DER -outform PEM -in MicWinProPCA2011_2011-10-19.crt -out MicWinProPCA2011_2011-10-19.pem
   openssl x509 -inform DER -outform PEM -in MicCorUEFCA2011_2011-06-27.crt -out MicCorUEFCA2011_2011-06-27.pem
   
   cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicWinProPCA2011_2011-10-19.pem MicWinProPCA2011_2011-10-19.esl
   cert-to-efi-sig-list -g 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.pem MicCorUEFCA2011_2011-06-27.esl
   
   mkdir -p /efi/keys/{db,KEK}
   
   cat MicWinProPCA2011_2011-10-19.esl MicCorUEFCA2011_2011-06-27.esl > /usr/share/secureboot/keys/db/microsoft_db.esl
   

3. Sign Microsoft’s keys with your PK and KEK respectively. Again, note the use of the append flag -a:

   sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b \
       -k /usr/share/secureboot/keys/PK/PK.key \
       -c /usr/share/secureboot/keys/PK/PK.pem \
       KEK /usr/share/secureboot/keys/KEK/MicCorKEKCA2011_2011-06-24.esl \
       /efi/keys/KEK/MicCorKEKCA2011_2011-06-24.auth
   
   sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b \
       -k /usr/share/secureboot/keys/KEK/KEK.key \
       -c /usr/share/secureboot/keys/KEK/KEK.pem \
       db /usr/share/secureboot/keys/db/microsoft_db.esl \
       /efi/keys/db/microsoft_db.auth
   

Automate unifying and resigning kernel images on update

1. Install sbupdate from AUR
   1. via yay

      yay -S sbupdate
      

   2. Manually

      cd
      mkdir git && cd git
      git clone https://aur.archlinux.org/sbupdate-git.git
      cd sbupdate-git
      makepkg -si
      

2. Edit /etc/sbupdate.conf and set parameters

   KEY_DIR="/usr/share/secureboot/keys/db"
   ESP_DIR="/efi"
   SPLASH="/dev/null"
   CMDLINE_DEFAULT="$(< /etc/kernel/cmdline)"
   

3. Create symlink for sbupdate

   cd /usr/share/secureboot/keys/db/
   ln -s db.pem db.crt
   

4. Reinstall kernel to trigger sbupdate hook to create unified and signed kernel image

   pacman -S linux
   

Enroll keys in firmware

ATTENTION: Make sure your firmware's Secure Boot mode is set to setup mode! You can do this by going into your firmware settings and wiping the factory default keys.

WARNING: Replacing the platform keys with your own can end up bricking hardware on some machines, including laptops, making it impossible to get into the UEFI/BIOS settings to rectify the situation. This is due to the fact that some device (e.g GPU) firmware (OpROMs), that get executed during boot, are signed using Microsoft's key.

Own keys

To enroll your own keys, simply:

sbctl enroll-keys

Microsoft keys

ViaTo Firmwareenroll the prepared Microsoft keys, you can either try your mainboard's firmware settings or use KeyTool.efi.

Using KeyTool.efi

1. Prepare a directory for KeyTool.efi:

   mkdir /efi/EFI/KeyTool
   

2. Copy a signed version of KeyTool.efi to ESPthe ESP:

   sbsign --key /usr/share/secureboot/keys/db/db.key \
          --cert /usr/share/secureboot/keys/db/db.pem \
          --output /efi/EFI/KeyTool/KeyTool-signed.efi \
          /usr/share/efitools/efi/KeyTool.efi
   

3. Boot KeyTool-signed.efi via Firmwarefirmware or EFI ShellShell:

   NOTE: ifIf using EFI Shell, verify that fs0:\ is the ESP you copied KeyTool-signed.efi and the keys to!

   fs0:\EFI\KeyTool\KeyTool-signed.efi
   

Proceed

4. to

   Addadd Microsoft keys to your motherboard's firmware with KeyTool.efi.

Automate

sbupdate is a tool that greatly simplyfies and streamlines the process of unifying and signing unified kernel images on kernel updates.

Install sbupdate from AUR:

yay -S sbupdate

Edit /etc/sbupdate.conf and set parameters:

KEY_DIR="/usr/share/secureboot/keys/db"
ESP_DIR="/efi"
OUT_DIR="EFI/Arch"
SPLASH="/dev/null"
CMDLINE_DEFAULT="$(< /etc/kernel/cmdline)"

Create a symlink to the db key for sbupdate:

cd /usr/share/secureboot/keys/db/
ln -s db.pem db.crt

Reinstall the kernel to trigger the sbupdate pacman hook to create unified and signed kernel image:

pacman -S linux