Unified Extensible Firmware Interface/Secure Boot: Difference between revisions
(Replaced Archboot homepage link; previous URL was 404) |
m (typo) |
||
(75 intermediate revisions by 28 users not shown) | |||
Line 1: | Line 1: | ||
[[Category:Boot process]] | [[Category:Boot process]] | ||
[[ja:セキュアブート]] | [[ja:Unified Extensible Firmware Interface/セキュアブート]] | ||
[[zh-hans:Unified Extensible Firmware Interface/Secure Boot]] | [[zh-hans:Unified Extensible Firmware Interface/Secure Boot]] | ||
{{Related articles start}} | {{Related articles start}} | ||
Line 8: | Line 8: | ||
{{Related articles end}} | {{Related articles end}} | ||
[[Wikipedia: | [[Wikipedia:Unified Extensible Firmware Interface#Secure Boot|Secure Boot]] is a security feature found in the [[UEFI]] standard, designed to add a layer of protection to the [[Arch boot process|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. | ||
As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[ | As such it can be seen as a continuation or complement to the efforts in [[Security|securing]] one's computing environment, reducing the attack surface that other software security solutions such as [[dm-crypt/Encrypting an entire system|system encryption]] cannot easily [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|cover]], while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and [[Wikipedia:Unified Extensible Firmware Interface#Secure Boot_2|cons]]. | ||
{{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] | {{Note|For a deeper overview about Secure Boot in Linux, see [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Rodsbooks' Secure Boot] article and [[#See also|other online resources]]. This article focuses on how to set up Secure Boot in Arch Linux.}} | ||
== Checking Secure Boot status == | == Checking Secure Boot status == | ||
Line 30: | Line 30: | ||
{{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}} | {{Note|There is no need to be using systemd-boot as your boot manager for this command to work, it is more akin to the others *ctl systemd utilities (localectl, timedatectl...) and will not touch your configuration.}} | ||
{{ | {{hc|$ bootctl| | ||
System: | System: | ||
Firmware: UEFI 2.80 (American Megatrends 5.26) | |||
Firmware Arch: x64 | |||
Secure Boot: enabled (user) | |||
TPM2 Support: yes | |||
Boot into FW: supported | |||
... | ... | ||
}} | }} | ||
Here we see that Secure Boot is enabled and enforced; other values are {{ic|disabled}} for Secure Boot and {{ic| | Here we see that Secure Boot is enabled and enforced (in user mode); other values are {{ic|disabled (setup)}} for Setup Mode, {{ic|disabled (disabled)}} if Secure Boot is disabled and {{ic|disabled (unsupported)}} if the firmware does not feature Secure Boot. | ||
Another way to check whether the machine was booted with Secure Boot is to use this command: | Another way to check whether the machine was booted with Secure Boot is to use this command: | ||
Line 60: | Line 61: | ||
== Booting an installation medium == | == Booting an installation medium == | ||
The official installation image does not support Secure Boot ({{Bug|53864}}). Secure Boot support was initially added in {{ic|archlinux-2013.07.01-dual.iso}} and later removed in {{ic|archlinux-2016.06.01-dual.iso}}. At that time ''prebootloader'' was replaced with {{pkg|efitools}}, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since. | |||
Secure Boot | In order to boot an installation medium in a Secure Boot system, you will need to either disable Secure Boot or modify the image in order to add a signed boot loader. | ||
[https:// | [https://archboot.com Archboot] images provide a way to use secure boot on installation media. | ||
=== Disabling Secure Boot === | === Disabling Secure Boot === | ||
Line 74: | Line 75: | ||
Note that some motherboards (this is the case in a Packard Bell laptop and recent Xiaomi laptops) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot]. | Note that some motherboards (this is the case in a Packard Bell laptop and recent Xiaomi laptops) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also [https://www.rodsbooks.com/efi-bootloaders/secureboot.html#disable Rod Smith's Disabling Secure Boot]. | ||
=== | === Repacking the installation image === | ||
See [[#ISO repacking]]. | |||
=== Editing the installation medium === | |||
If you are using a [[USB flash installation medium]], then it is possible to manually edit the [[EFI system partition]] on the medium to add support for Secure Boot. | |||
Plug in the USB drive, then [[mount]] the partition: | |||
# mount /dev/disk/by-label/ARCHISO_EFI /mnt | |||
Then follow the instructions in [[#Using a signed boot loader]] to install any signed boot loader. For example, to install [[#PreLoader]]: | |||
{{bc| | |||
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi | |||
# cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI | |||
# cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi | |||
}} | |||
== Implementing Secure Boot == | == Implementing Secure Boot == | ||
Line 86: | Line 101: | ||
# UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]] | # UEFI considered mostly trusted (despite having some well known [[Wikipedia:Unified_Extensible_Firmware_Interface#Criticism|criticisms]] and vulnerabilities[https://www.uefi.org/sites/default/files/resources/UEFI%20Firmware%20-%20Security%20Concerns%20and%20Best%20Practices.pdf]) and necessarily [[#Protecting Secure Boot|protected by a strong password]] | ||
# Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/] | # Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[https://habr.com/ru/post/446238/] | ||
# UEFI directly loads a user-signed [[EFISTUB]] | # UEFI directly loads a user-signed [[EFISTUB]]-compatible [[unified kernel image]] (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface | ||
# Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine. | # Use of [[dm-crypt/Encrypting an entire system|full drive encryption]], so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine. | ||
# Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement. | # Some further improvements may be obtained by using a [[TPM]], although tooling and support makes this harder to implement. | ||
A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party. | A simple and fully self-reliant setup is described in [[#Using your own keys]], while [[#Using a signed boot loader]] makes use of intermediate tools signed by a third-party. | ||
Using the [[GRUB]] bootloader requires extra steps before enabling secure boot, see [[GRUB#Secure Boot support]] for details. | |||
=== Using your own keys === | === Using your own keys === | ||
Line 108: | Line 125: | ||
Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using ''sign-efi-sig-list'') with a higher level key. Platform key can be signed by itself. | Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using ''sign-efi-sig-list'') with a higher level key. Platform key can be signed by itself. | ||
==== Backing up current variables ==== | ==== Backing up current variables ==== | ||
Line 117: | Line 130: | ||
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error. | Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error. | ||
[[Install]] the {{Pkg|efitools}} package, then run the following commands to backup all four of the principal Secure Boot variables: | |||
$ | $ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done | ||
If you perform | If you perform this command on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft. | ||
==== | ==== Putting firmware in "Setup Mode" ==== | ||
Secure Boot is in Setup Mode when the Platform Key is removed. To put firmware in Setup Mode, enter firmware setup utility and find an option to delete or clear certificates. How to enter the setup utility is described in [[#Before booting the OS]]. | |||
==== Assisted process with sbctl ==== | |||
[https://github.com/Foxboron/sbctl sbctl] is a user-friendly way of setting up secure boot and signing files. | |||
{{Note|sbctl does not work with all hardware. How well it will work depends on the manufacturer.}} | |||
To use it, [[install]] {{Pkg|sbctl}}. See also the [https://github.com/Foxboron/sbctl#sbctl---secure-boot-manager upstream README] and {{man|8|sbctl}}. | |||
===== Creating and enrolling keys ===== | |||
Before starting, go to your firmware settings and set secure boot mode to [[#Putting firmware in "Setup Mode"|Setup mode]]. This is different for each device: see {{man|8|sbctl|USAGE}}. | |||
Once you log back in, check the secure boot status: | |||
$ sbctl status | |||
You should see that sbctl is not installed and secure boot is disabled. | |||
Then create your custom secure boot keys: | |||
# sbctl create-keys | |||
Enroll your keys, with Microsoft's keys, to the UEFI: | |||
# sbctl enroll-keys -m | |||
{{Warning|Some firmware is signed and verified with Microsoft's keys when secure boot is enabled. Not validating devices could brick them. To enroll your keys without enrolling Microsoft's, run: {{ic|sbctl enroll-keys}}. Only do this if you know what you are doing.}} | |||
Check the secure boot status again: | |||
$ sbctl status | |||
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created. | |||
===== Signing ===== | |||
Check what files need to be signed for secure boot to work: | |||
# sbctl verify | |||
For example | Now sign all the unsigned files. Usually the [[kernel]] and the [[boot loader]] need to be signed. For example: | ||
# | # sbctl sign -s /boot/vmlinuz-linux | ||
# | # sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI | ||
The files that need to be signed will depend on your system's layout, kernel and boot loader. | |||
{{Tip|Especially if you are dual-booting with Windows, there may be a lot of files that need to be signed. The process of signing all needed files using sbctl can be done with [[sed]]: | |||
# sbctl verify {{!}} sed 's/✗ /sbctl sign -s /e' | |||
This example assumes that the outputted file paths are relative to {{ic|/boot}}. | |||
}} | |||
Now you are done! Reboot your system and turn secure boot back on in the firmware settings. If the boot loader and OS load, secure boot should be working. Check with: | |||
$ sbctl status | |||
==== | ===== Automatic signing with the pacman hook ===== | ||
sbctl comes with a [[pacman hook]] that automatically signs all new files whenever the [[Linux kernel]], [[systemd]] or the [[boot loader]] is updated. | |||
{{Tip|If you use [[Systemd-boot]] and {{ic|systemd-boot-update.service}}, the [[boot loader]] is only updated after a reboot, and the sbctl [[pacman hook]] will therefore not sign the new file. As a workaround, it can be useful to sign the [[boot loader]] directly in {{ic|/usr/lib/}}, as {{ic|bootctl install}} and {{ic|update}} will automatically recognize and copy ''.efi.signed'' files to the [[ESP]] if present, instead of the normal ''.efi'' file. See {{man|1|bootctl}}. | |||
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi | |||
}} | }} | ||
==== Manual process ==== | |||
===== Install efitools ===== | |||
Nearly all of the following sections require you to [[install]] the {{Pkg|efitools}} package. | |||
===== Creating keys ===== | |||
To generate keys, perform the following steps. | |||
You | You will need private keys and certificates in multiple formats: | ||
; ''.key'': PEM format '''private''' keys for EFI binary and EFI signature list signing. | |||
; ''.crt'': PEM format certificates for {{man|1|sbsign}}, {{man|1|sbvarsign}} and {{man|1|sign-efi-sig-list}}. | |||
; ''.cer'': DER format certificates for firmware. | |||
; ''.esl'': Certificates in an EFI Signature List for {{man|1|sbvarsign}}, {{man|1|efi-updatevar}}, ''KeyTool'' and firmware. | |||
; ''.auth'': Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for {{man|1|efi-updatevar}}, ''sbkeysync'', ''KeyTool'' and firmware. | |||
Create a [[Wikipedia:Globally unique identifier|GUID]] for owner identification: | |||
$ uuidgen --random > GUID.txt | |||
Platform key: | |||
$ openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Platform Key''/" -out PK.crt | |||
$ openssl x509 -outform DER -in PK.crt -out PK.cer | |||
$ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl | |||
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth | |||
Sign an empty file to allow removing Platform Key when in "User Mode": | |||
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth | |||
Key Exchange Key: | |||
$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Key Exchange Key''/" -out KEK.crt | |||
$ openssl x509 -outform DER -in KEK.crt -out KEK.cer | |||
$ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl | |||
$ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth | |||
Signature Database key: | |||
= | $ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Signature Database key''/" -out db.crt | ||
$ openssl x509 -outform DER -in db.crt -out db.cer | |||
$ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl | |||
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth | |||
====== Helper script ====== | |||
A helper/convenience script is offered by the author of the reference page on this topic[https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#creatingkeys] (requires [[python]]). A mildly edited version is also packaged as {{AUR|sbkeys}}. | |||
In order to use it, simply create a folder in a secure location (e.g. {{ic|/etc/efi-keys/}} if later use of {{AUR|sbupdate-git}} to automate unified kernel image creation and signing is planned) and run it: | |||
# mkdir /etc/efi-keys | |||
# cd !$ | |||
# curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh | |||
# chmod +x mkkeys.sh | |||
# ./mkkeys.sh | |||
''Enter a Common Name to embed in the keys, e.g. "Secure Boot"'' | |||
This will produce the required files in different formats. | |||
==== Enrolling keys in firmware ==== | ===== Enrolling keys in firmware ===== | ||
Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates. | Use one of the following methods to enroll '''db''', '''KEK''' and '''PK''' certificates. | ||
Line 274: | Line 276: | ||
{{Warning|Enrolling Platform Key sets Secure Boot in "User Mode", leaving "Setup Mode", so it should be enrolled last in sequence.}} | {{Warning|Enrolling Platform Key sets Secure Boot in "User Mode", leaving "Setup Mode", so it should be enrolled last in sequence.}} | ||
===== Using sbkeysync ===== | ====== Using sbkeysync ====== | ||
Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure - | Install {{Pkg|sbsigntools}}. Create a directory {{ic|/etc/secureboot/keys}} with the following directory structure - | ||
Line 292: | Line 294: | ||
If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use: | If you want to verify the changes {{ic|sbkeysync}} will make to the system's UEFI keystore, use: | ||
# sbkeysync --pk --dry-run --verbose | # sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose | ||
Finally, use {{ic|sbkeysync}} to enroll your keys. | Finally, use {{ic|sbkeysync}} to enroll your keys. | ||
# sbkeysync --verbose | # sbkeysync --keystore /etc/secureboot/keys --verbose | ||
# sbkeysync --verbose --pk | # sbkeysync --keystore /etc/secureboot/keys --verbose --pk | ||
{{Tip|1= <nowiki/> | {{Tip|1=<nowiki/> | ||
* If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}. | * If {{ic|sbkeysync}} returns write errors, first run {{ic|1=chattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*}} prior to issuing commands with {{ic|sbkeysync}} to temporarily change file attributes, enabling writing of the EFI keys within the {{ic|efivars}} directory. See {{man|1|chattr}}. | ||
* If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}. | * If you get a {{ic|permission denied}} error for {{ic|PK.auth}}, you can enroll it with command {{ic|efi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK}}. | ||
Line 321: | Line 323: | ||
On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy. | On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy. | ||
===== Using firmware setup utility ===== | ====== Using firmware setup utility ====== | ||
Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files ('''except''' {{ic|noPK.auth}}) to a [[FAT]] formatted file system (you can use [[EFI system partition]]). | Copy all {{ic|*.cer}}, {{ic|*.esl}}, {{ic|*.auth}} files ('''except''' the {{ic|noPK.auth}} file!) to a [[FAT]] formatted file system (you can use [[EFI system partition]]). | ||
{{Warning|'''Do not''' copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC! If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with their own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a safe place where only you have access to. A safe place for the noPK.auth file are: | {{Warning|'''Do not''' copy the {{ic|noPK.auth}} file to the [[EFI system partition]] (ESP) of your PC! If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with their own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the {{ic|noPK.auth}} file. Therefore keep the {{ic|noPK.auth}} file in a secret, safe place where only you have access to. A safe place for the noPK.auth file are: | ||
* an external USB stick with an [[EFI system partition]] when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage. | * an external USB stick with an [[EFI system partition]] when using {{ic|KeyTool}}. Unfortunately, {{ic|KeyTool}} can only read files from unencrypted storage. | ||
Line 337: | Line 339: | ||
If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''. | If the used tool supports it prefer using ''.auth'' and ''.esl'' over ''.cer''. | ||
===== Using KeyTool ===== | ====== Using KeyTool ====== | ||
{{ic|KeyTool.efi}} is in {{Pkg|efitools}} package, copy it to ESP. To use it after enrolling keys, sign it with {{ic|sbsign}}. | {{ic|KeyTool.efi}} is in {{Pkg|efitools}} package, copy it to ESP. To use it after enrolling keys, sign it with {{ic|sbsign}}. | ||
Line 347: | Line 349: | ||
See [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] for explanation of KeyTool menu options. | See [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html#keytool Replacing Keys Using KeyTool] for explanation of KeyTool menu options. | ||
===== Using systemd-boot ===== | ====== Using systemd-boot ====== | ||
Since systemd version 252, [[systemd-boot]] can be used to enroll keys. To enroll keys, copy the {{ic|db.auth}}, {{ic|KEK.auth}} and {{ic|PK.auth}} to the special folder on the ESP: | Since systemd version 252, [[systemd-boot]] can be used to enroll keys. To enroll keys, copy the {{ic|db.auth}}, {{ic|KEK.auth}} and {{ic|PK.auth}} to the special folder on the ESP: | ||
Line 356: | Line 358: | ||
After copying the keys and enabling the secure boot setup mode a new entry would appear in the boot menu that would read {{ic|Enroll Secure Boot keys: MYKEYS}}. Activating this entry would enroll the secure boot keys. | After copying the keys and enabling the secure boot setup mode a new entry would appear in the boot menu that would read {{ic|Enroll Secure Boot keys: MYKEYS}}. Activating this entry would enroll the secure boot keys. | ||
===== Signing EFI binaries ===== | |||
When ''Secure Boot'' is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, [[Unified Extensible Firmware Interface#UEFI drivers|drivers]], [[unified kernel image]]s) can be launched. | |||
====== With sbsigntools ====== | |||
Install {{Pkg|sbsigntools}} to sign EFI binaries with {{man|1|sbsign}}. | |||
{{Tip| | |||
* To check if a binary is signed and list its signatures use {{ic|sbverify --list ''/path/to/binary''}}. | |||
* The [[rEFInd]] boot manager's {{ic|refind-install}} script can sign rEFInd EFI binaries and copy them together with the db certificates to the ESP. See [[rEFInd#Using your own keys]] for instructions. | |||
}} | |||
{{Note|If running ''sbsign'' without {{ic|--output}} the resulting file will be {{ic|''filename''.signed}}. See {{man|1|sbsign}} for more information.}} | |||
To sign your kernel and boot manager use ''sbsign'', e.g.: | |||
# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux | |||
# sbsign --key db.key --cert db.crt --output ''esp''/EFI/BOOT/BOOTx64.EFI ''esp''/EFI/BOOT/BOOTx64.EFI | |||
{{Warning|Signing kernel only will not protect the initramfs from tampering. See [[Unified kernel image]] to know how to produce a combined image that you can then manually sign with ''sbsign''.}} | |||
====== Signing the kernel with a mkinitcpio post hook ====== | |||
You can also use a [[mkinitcpio]] post hook to sign the kernel when the initramfs gets generated. | |||
[[Create]] the following file an make it [[executable]]: | |||
{{hc|/etc/initcpio/post/kernel-sbsign|2= | |||
#!/usr/bin/env bash | |||
kernel="$1" | |||
<nowiki>[[ -n "$kernel" ]] || exit 0 | |||
# use already installed kernel if it exists | |||
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki> | |||
keypairs=(''/path/to/''db.key ''/path/to/''db.crt) | |||
for (( i=0; i<${#keypairs[@]}; i+=2 )); do | |||
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}" | |||
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then | |||
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel" | |||
fi | |||
done | |||
}} | |||
Replace {{ic|''/path/to/''db.key}} and {{ic|''/path/to/''db.crt}} with the paths to the key pair you want to use for signing the kernel. | |||
If you are using systemd-boot, there is a [[systemd-boot#Automatic update|dedicated pacman hook]] doing this task semi-automatically. | |||
====== Signing unified kernel images with a mkinitcpio post hook ====== | |||
See [[Unified kernel image#Signing the UKIs for Secure Boot]]. | |||
===== Fully automated unified kernel generation and signing with sbupdate ===== | |||
{{Note|''sbupdate'' was created long before [[mkinitcpio]] and other [[initramfs]] generators acquired the ability to generate [[unified kernel image]]s, providing much appreciated ease to this formerly cumbersome process. Nowadays, consider using instead the [[#Assisted process with sbctl]].}} | |||
[https://github.com/andreyv/sbupdate sbupdate] is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through [[pacman hooks]]. | |||
Install {{AUR|sbupdate-git}} and configure it following the instructions given on the project's homepage.[https://github.com/andreyv/sbupdate#sbupdate] | |||
{{Tip|If using [[systemd-boot]], set {{ic|1=OUT_DIR="EFI/Linux"}} to get your signed kernel images directly recognized without needing configuration. See {{man|7|systemd-boot|FILES}} and [[systemd-boot#Adding loaders]].}} | |||
Once configured, simply run {{ic|sbupdate}} as root for first-time image generation. | |||
{{Note|''sbupdate'' output often contains errors such as {{ic|warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?}}. Those are harmless and can be safely ignored.[https://github.com/andreyv/sbupdate/issues/30]}} | |||
==== Updating keys ==== | |||
Once Secure Boot is in "User Mode" any changes to KEK, db and dbx need to be signed with a higher level key. | |||
For example, if you wanted to replace your db key with a new one: | |||
# [[#Creating keys|Create the new key]], | |||
# Convert it to EFI Signature List, | |||
# Sign the EFI Signature List, | |||
# Enroll the signed certificate update file. | |||
$ cert-to-efi-sig-list -g "$(< GUID.txt)" ''new_db''.crt ''new_db''.esl | |||
$ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth | |||
If instead of replacing your db key, you want to '''add''' another one to the Signature Database, you need to use the option {{ic|-a}} (see {{man|1|sign-efi-sig-list}}): | |||
$ sign-efi-sig-list '''-a''' -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db ''new_db''.esl ''new_db''.auth | |||
When {{ic|''new_db''.auth}} is created, [[#Enrolling keys in firmware|enroll it]]. | |||
==== Dual booting with other operating systems ==== | ==== Dual booting with other operating systems ==== | ||
Line 365: | Line 456: | ||
It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables: | It is usually '''not''' possible to boot Windows by signing its bootloader ({{ic|EFI/Microsoft/Boot/bootmgfw.efi}}) with a [[#Creating keys|custom, personal key]] with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables: | ||
* if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot | * if {{ic|bootmgfw.efi}} contains a signature '''both''' from the "Microsoft Windows Production PCA 2011" '''and''' from your own Secure Boot db key (so '''two signatures'''), then UEFI firmware implementations like ''INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66)'' will not launch {{ic|bootmgfw.efi}} and will throw a security violation error ('''{{ic|Selected boot image did not authenticate. Press ENTER to continue.}}'''): UEFI firmware implementation like this can probably only read the '''first''' signature - not the '''second''' one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails. | ||
* if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot | * if the "Microsoft Windows Production PCA 2011" signature from the {{ic|bootmgfw.efi}} file is stripped/removed, and only a signature from your own Secure Boot db key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature on {{ic|bootmgfw.efi}} file is missing). | ||
So to [[dual boot with Windows]], | So to [[dual boot with Windows]], | ||
* you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic| | * you either have to add the hash of {{ic|bootmgfw.efi}} to the list of allowed hashes in the {{ic|db}} variable; and you have to update the {{ic|db}} variable every time a Windows Update changes {{ic|bootmgfw.efi}}. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition). | ||
* or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has | * or you have to add Microsoft's certificates to the UEFI Secure Boot variables [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance#14-signature-databases-db-and-dbx Microsoft has four db certificates and two KEK certificates]: | ||
** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] must be included in the {{ic| | ** The [https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt Microsoft Windows Production PCA 2011 certificate] and [https://www.microsoft.com/pkiops/certs/windows%20uefi%20ca%202023.crt Windows UEFI CA 2023] must be included in the {{ic|db}} variable in order to allow the Windows Operating System to load. | ||
** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] aka the Microsoft 3rd Party UEFI CA | ** The [https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI CA 2011 certificate] and [https://www.microsoft.com/pkiops/certs/microsoft%20uefi%20ca%202023.crt Microsoft UEFI CA 2023] aka the Microsoft 3rd Party UEFI CA certificates should be included in the {{ic|db}} variable in order to use third-party binaries like UEFI drivers, option ROMs, {{Pkg|shim}}, etc. | ||
** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic| | ** The [https://www.microsoft.com/pkiops/certs/MicCorKEKCA2011_2011-06-24.crt Microsoft Corporation KEK CA 2011 certificate] and [https://www.microsoft.com/pkiops/certs/microsoft%20corporation%20kek%202k%20ca%202023.crt Microsoft Corporation KEK 2K CA 2023] should be included in the {{ic|KEK}} variable, in order to "enable revocation of bad images by updating the {{ic|dbx}} and potentially for updating {{ic|db}} to prepare for newer Windows signed images". However, Windows will also boot without them. | ||
Create EFI Signature Lists from Microsoft's DER format {{ic| | Create EFI Signature Lists from Microsoft's DER format {{ic|db}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}) and combine them in one file for simplicity: | ||
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output | $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt | ||
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output | $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt' | ||
$ cat | $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt | ||
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt' | |||
$ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl | |||
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} | Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format {{ic|KEK}} certificates using Microsoft's GUID ({{ic|77fa9abd-0359-4d32-bd60-28f4e78f784b}}): | ||
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt | |||
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt' | |||
$ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl | |||
Sign a {{ic| | Sign a {{ic|db}} variable update with your {{ic|KEK}}. Use {{ic|sign-efi-sig-list}} with option {{ic|-a}} to '''add''' not replace a {{ic|db}} certificate: | ||
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth | $ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth | ||
Line 400: | Line 495: | ||
Using a signed boot loader means using a boot loader signed with Microsoft's key. There are two known signed boot loaders: PreLoader and shim. Their purpose is to chainload other EFI binaries (usually [[boot loader]]s). Since Microsoft would never sign a boot loader that automatically launches any unsigned binary, PreLoader and shim use an allowlist called Machine Owner Key list, abbreviated MokList. If the SHA256 hash of the binary (Preloader and shim) or key the binary is signed with (shim) is in the MokList they execute it, if not they launch a key management utility which allows enrolling the hash or key. | Using a signed boot loader means using a boot loader signed with Microsoft's key. There are two known signed boot loaders: PreLoader and shim. Their purpose is to chainload other EFI binaries (usually [[boot loader]]s). Since Microsoft would never sign a boot loader that automatically launches any unsigned binary, PreLoader and shim use an allowlist called Machine Owner Key list, abbreviated MokList. If the SHA256 hash of the binary (Preloader and shim) or key the binary is signed with (shim) is in the MokList they execute it, if not they launch a key management utility which allows enrolling the hash or key. | ||
{{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader. | {{Warning|What Microsoft calls "Secured-core PCs" do not ship with Microsoft 3rd Party UEFI CA certificate (Microsoft Corporation UEFI CA 2011 or Microsoft UEFI CA 2023) enrolled.[https://docs.microsoft.com/en-us/windows/security/information-protection/secure-the-windows-10-boot-process#secure-boot]. The only enrolled DB certificate is the Microsoft Windows Production PCA 2011 certificate which is exclusively used to sign the Windows boot loader. | ||
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate. | The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate. | ||
Line 498: | Line 593: | ||
* If you use [[#shim with hash]], each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash. | * If you use [[#shim with hash]], each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash. | ||
* Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details. | * Since version 15.3, shim will not launch EFI binaries without a valid {{ic|.sbat}} section. Run {{ic|objdump -j .sbat -s ''/path/to/binary.efi''}} to verify if an EFI binary has it. See the [https://github.com/rhboot/shim/blob/main/SBAT.md SBAT documentation] for details. | ||
* | * If you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with {{ic|mokutil --disable-validation}}. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows with {{ic|chainloader}} in grub. | ||
}} | }} | ||
Line 513: | Line 608: | ||
Copy ''shim'' and ''MokManager'' to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for {{ic|shimx64.efi}}: | Copy ''shim'' and ''MokManager'' to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for {{ic|shimx64.efi}}: | ||
{{Note| | {{Note|Make sure you do '''not''' copy {{ic|fbx64.efi}} (which is under the same directory) unless you actually have a valid {{ic|bootx64.csv}} to use. Otherwise shim will '''not''' execute {{ic|grubx64.efi}} but will appear to fail to work and just reset the machine.}} | ||
}} | |||
# cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI | # cp /usr/share/shim-signed/shimx64.efi ''esp''/EFI/BOOT/BOOTx64.EFI | ||
Line 549: | Line 642: | ||
Create a Machine Owner Key: | Create a Machine Owner Key: | ||
$ openssl req -newkey rsa: | $ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days ''3650'' -subj "/CN=''my Machine Owner Key''/" -out MOK.crt | ||
$ openssl x509 -outform DER -in MOK.crt -out MOK.cer | $ openssl x509 -outform DER -in MOK.crt -out MOK.cer | ||
{{Note|It seems that shim will not support adding a 4096 RSA key to the MokList (it might freeze when loading and verifying the {{ic|grubx64.efi}} binary), so make sure you use a 2048 key for now. See [[Debian:SecureBoot#Generating a new key]].}} | |||
Sign your boot loader (named {{ic|grubx64.efi}}) and kernel: | Sign your boot loader (named {{ic|grubx64.efi}}) and kernel: | ||
Line 557: | Line 652: | ||
# sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi | # sbsign --key MOK.key --cert MOK.crt --output ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/grubx64.efi | ||
You will need to do this each time they are updated. You can automate the kernel signing with a [[ | You will need to do this each time they are updated. You can automate the kernel signing with a [[mkinitcpio]] post hook. [[Create]] the following file and make it [[executable]]: | ||
{{hc|/etc/ | {{hc|/etc/initcpio/post/kernel-sbsign|2= | ||
#!/usr/bin/env bash | |||
[ | kernel="$1" | ||
<nowiki>[[ -n "$kernel" ]] || exit 0 | |||
# use already installed kernel if it exists | |||
[[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION"</nowiki> | |||
keypairs=(''/path/to/''MOK.key ''/path/to/''MOK.crt) | |||
for (( i=0; i<${#keypairs[@]}; i+=2 )); do | |||
key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}" | |||
if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then | |||
sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel" | |||
fi | |||
done | |||
}} | }} | ||
Line 586: | Line 681: | ||
====== shim with key and GRUB ====== | ====== shim with key and GRUB ====== | ||
See [[GRUB#Shim-lock]] for instructions. | |||
===== Delete enrolled hash/key ===== | |||
Every entry of hash/key enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hash/key to free the space and to prevent outdated programs from booting. | |||
MOK database can be managed with {{Pkg|mokutil}} | |||
List enrolled keys & hashes | |||
# mokutil --list-enrolled | |||
Remove hash from database. | |||
The password entered here will be asked for confirmation to delete in MOK manager. | |||
# mokutil --delete-hash <hash to remove from above command> | |||
Input password: | |||
Remove key from database | |||
# mokutil --delete MOK.cer | |||
List hashes/keys to be deleted on next reboot | |||
# | # mokutil --list-delete | ||
On next reboot, MOK manager will be initiated with option to Enroll/Delete hashes/keys. | |||
More details {{man|1|mokutil}} | |||
===== Remove shim ===== | ===== Remove shim ===== | ||
Line 633: | Line 712: | ||
== Protecting Secure Boot == | == Protecting Secure Boot == | ||
The only way to prevent anyone with physical access | The only way to prevent anyone with physical access from disabling Secure Boot is to protect the firmware settings with a password. Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings. | ||
Consider enabling [[Security#Kernel lockdown mode|kernel lockdown mode]]. See [https://stackoverflow.com/a/60104165]. | |||
== Tips and tricks == | == Tips and tricks == | ||
=== | === ISO repacking === | ||
It is possible to unpack and repack the official installation image using {{Pkg|libisoburn}} and {{Pkg|mtools}}. This way, you can create an image that supports Secure Boot, either with custom keys or with a signed boot loader. | |||
==== Sign the official ISO with custom keys ==== | |||
=== Sign the official ISO with custom keys === | |||
Support for Secure Boot using custom keys can be added to the official ISO by simply extracting the boot loader ({{ic|BOOTx64.EFI}} and {{ic|BOOTIA32.EFI}}), kernel, UEFI shell, signing them and then repacking the ISO with the signed files. | Support for Secure Boot using custom keys can be added to the official ISO by simply extracting the boot loader ({{ic|BOOTx64.EFI}} and {{ic|BOOTIA32.EFI}}), kernel, UEFI shell, signing them and then repacking the ISO with the signed files. | ||
First extract the relevant files and El Torito boot images: | First extract the relevant files and El Torito boot images: | ||
Line 720: | Line 742: | ||
$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux | $ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux | ||
Sign the files | Sign the files. To do so with {{Pkg|sbsigntools}}, for example: | ||
$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI | $ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI | ||
Line 739: | Line 761: | ||
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \ | $ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \ | ||
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \ | -outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \ | ||
-map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \ | -map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \ | ||
-map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \ | -map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \ | ||
-map_l ./ / shellx64.efi shellia32.efi | -map_l ./ / shellx64.efi shellia32.efi -- \ | ||
-boot_image any replay \ | |||
-append_partition 2 0xef eltorito_img2_uefi.img | |||
}} | }} | ||
Boot the resulting {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}}. | Boot the resulting {{ic|archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso}}. | ||
==== Replacing the boot loader with PreLoader ==== | |||
Another way to add Secure Boot support to the official ISO is by extracting the boot loader and replacing it with [[#PreLoader]]. | |||
{{Note|The ISO's GRUB EFI binary ({{ic|EFI/BOOT/BOOTx64.EFI}}) is built with {{ic|--disable-shim-lock}} so it cannot be used with shim. This is a GRUB limitation where it can either be compatible with shim or with custom signatures, but not both at the same time.}} | |||
First, extract the boot loader and the El Torito boot image: | |||
{{bc| | |||
$ osirrox -indev archlinux-''YYYY.MM.DD''-x86_64.iso \ | |||
-extract_boot_images ./ \ | |||
-cpx /EFI/BOOT/BOOTx64.EFI ./ | |||
}} | |||
Replace the {{ic|BOOTx64.efi}} file with PreLoader: | |||
{{bc| | |||
$ mv BOOTx64.EFI loader.efi | |||
$ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI | |||
$ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi | |||
}} | |||
Add the new files to the boot image: | |||
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/ | |||
Finally, repack the ISO using the modified boot image and the new boot loader files: | |||
{{bc| | |||
$ xorriso -indev archlinux-''YYYY.MM.DD''-x86_64.iso \ | |||
-outdev archlinux-''YYYY.MM.DD''-x86_64-Secure_Boot.iso \ | |||
-map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \ | |||
-boot_image any replay \ | |||
-append_partition 2 0xef eltorito_img2_uefi.img | |||
}} | |||
=== Enrolling Option ROM digests === | |||
[[Wikipedia:Option ROM|Option ROMs]] (OpROMs), i.e. device firmware that is executed during boot, must be signed for Secure Boot otherwise the devices will not be initialized. Typically OpROMs are signed with the Microsoft 3rd Party UEFI CA certificate which may prevent implementing Secure Boot with only your own keys. To solve this, the SHA256 digests of OpROMs can be enrolled instead. | |||
{{Warning|Preventing essential devices from initializing by removing the Microsoft 3rd Party UEFI CA certificate can end up bricking hardware on some machines, including laptops, making it impossible to get into the firmware settings to rectify the situation.}} | |||
On systems with a [[TPM]], it is possible to acquire Option ROM SHA256 digests from the [https://docs.kernel.org/security/tpm/tpm_event_log.html TPM event log]. | |||
[[Install]] {{Pkg|tpm2-tools}} and {{AUR|digest-to-efi-sig-list}}. | |||
Use {{man|1|tpm2_eventlog}} to read {{ic|/sys/kernel/security/tpm0/binary_bios_measurements}} and look for the digests of {{ic|BOOT_SERVICES_DRIVER}}.[https://github.com/Foxboron/sbctl/wiki/FAQ#option-rom] | |||
For example: | |||
{{hc|# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements| | |||
... | |||
- EventNum: 9 | |||
PCRIndex: 2 | |||
EventType: EV_EFI_BOOT_SERVICES_DRIVER | |||
DigestCount: 1 | |||
Digests: | |||
- AlgorithmId: sha256 | |||
Digest: "'''''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'''''" | |||
... | |||
- EventNum: 10 | |||
PCRIndex: 2 | |||
EventType: EV_EFI_BOOT_SERVICES_DRIVER | |||
DigestCount: 1 | |||
Digests: | |||
- AlgorithmId: sha256 | |||
Digest: "'''''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'''''" | |||
... | |||
}} | |||
Use ''digest-to-efi-sig-list'' to create an EFI signature list for each OpROM digest you find: | |||
$ digest-to-efi-sig-list ''0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef'' OpROM1.esl | |||
$ digest-to-efi-sig-list ''fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210'' OpROM2.esl | |||
In case you have multiple OpROMs, combine their EFI signature lists into one so that it could be signed as a single file: | |||
$ cat OpROM1.esl OpROM2.esl > OpROM.esl | |||
Sign the EFI signature list for appending to the Signature Database: | |||
$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth | |||
[[#Enrolling keys in firmware|Enroll it]]. | |||
The final and most dangerous step is to remove Microsoft 3rd Party UEFI CA certificate from the Signature Database and see if the system still boots and all devices still work. | |||
== See also == | == See also == | ||
* [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore | * [https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/ Understanding the UEFI Secure Boot Chain] by tianocore | ||
* [[Wikipedia:Unified Extensible Firmware Interface#Secure | * [[Wikipedia:Unified Extensible Firmware Interface#Secure Boot]] | ||
* [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith | * [https://www.rodsbooks.com/efi-bootloaders/secureboot.html Dealing with Secure Boot] by Rod Smith | ||
* [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] by Rod Smith | * [https://www.rodsbooks.com/efi-bootloaders/controlling-sb.html Controlling Secure Boot] by Rod Smith | ||
Line 760: | Line 869: | ||
* [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation recommendations for free operating system distributions considering Secure Boot] | * [https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/campaigns/secure-boot-vs-restricted-boot/whitepaper-web Free Software Foundation recommendations for free operating system distributions considering Secure Boot] | ||
* [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial] | * [https://web.archive.org/web/20150928202110/https://firmware.intel.com/messages/219 Intel's UEFI Secure Boot Tutorial] | ||
* [http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries] | * [https://web.archive.org/web/20200205044007/http://dreamhack.it/linux/2015/12/03/secure-boot-signed-modules-and-signed-elf-binaries.html Secure Boot, Signed Modules and Signed ELF Binaries] | ||
* National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization] | * National Security Agency docs: [https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-uefi-defensive-practices-guidance.pdf UEFI Defensive Practices Guidance] and unclassified [https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF/CTR-UEFI-SECURE-BOOT-CUSTOMIZATION-20200915.PDF UEFI Secure Boot customization] | ||
* [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr | * [http://jk.ozlabs.org/docs/sbkeysync-maintaing-uefi-key-databases/ sbkeysync & maintaining uefi key databases] by Jeremy Kerr | ||
* [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07) | * [https://nwildner.com/posts/2020-07-04-secure-your-boot-process/ Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux] (2020-07) | ||
* [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange) | * [https://security.stackexchange.com/questions/29122/how-is-hibernation-supported-on-machines-with-uefi-secure-boot How is hibernation supported, on machines with UEFI Secure Boot?] (Security StackExchange) | ||
* [ | * [https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html Authenticated Boot and Disk Encryption on Linux] by Lennart Poettering (2021-09-23) | ||
* The tool {{AUR|cryptboot}} simplifies the whole process and is easy to use |
Latest revision as of 22:19, 27 March 2024
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.
As such it can be seen as a continuation or complement to the efforts in securing one's computing environment, reducing the attack surface that other software security solutions such as system encryption cannot easily cover, while being totally distinct and not dependent on them. Secure Boot just stands on its own as a component of current security practices, with its own set of pros and cons.
Checking Secure Boot status
Before booting the OS
At this point, one has to look at the firmware setup. If the machine was booted and is running, in most cases it will have to be rebooted.
You may access the firmware configuration by pressing a special key during the boot process. The key to use depends on the firmware. It is usually one of Esc
, F2
, Del
or possibly another Fn
key. Sometimes the right key is displayed for a short while at the beginning of the boot process. The motherboard manual usually records it. You might want to press the key, and keep pressing it, immediately following powering on the machine, even before the screen actually displays anything.
After entering the firmware setup, be careful not to change any settings without prior intention. Usually there are navigation instructions, and short help for the settings, at the bottom of each setup screen. The setup itself might be composed of several pages. You will have to navigate to the correct place. The interesting setting might be simply denoted by secure boot, which can be set on or off.
After booting the OS
An easy way to check Secure Boot status on systems using systemd is to use systemd-boot:
$ bootctl
System: Firmware: UEFI 2.80 (American Megatrends 5.26) Firmware Arch: x64 Secure Boot: enabled (user) TPM2 Support: yes Boot into FW: supported ...
Here we see that Secure Boot is enabled and enforced (in user mode); other values are disabled (setup)
for Setup Mode, disabled (disabled)
if Secure Boot is disabled and disabled (unsupported)
if the firmware does not feature Secure Boot.
Another way to check whether the machine was booted with Secure Boot is to use this command:
$ od --address-radix=n --format=u1 /sys/firmware/efi/efivars/SecureBoot-*
If Secure Boot is enabled, this command returns 1
as the final integer in a list of five, for example:
6 0 0 0 1
Note, however, that the kernel may be unaware of Secure Boot (even if it is enabled in the firmware) if an insufficiently capable boot loader is used. This can be verified by checking the kernel messages shortly after the system starts up:
# dmesg | grep -i secure
[ 0.013442] Secure boot disabled [ 0.013442] Secure boot could not be determined
The kernel messages will otherwise read Secure boot enabled
.
Booting an installation medium
The official installation image does not support Secure Boot (FS#53864). Secure Boot support was initially added in archlinux-2013.07.01-dual.iso
and later removed in archlinux-2016.06.01-dual.iso
. At that time prebootloader was replaced with efitools, even though the latter uses unsigned EFI binaries. There has been no support for Secure Boot in the official installation medium ever since.
In order to boot an installation medium in a Secure Boot system, you will need to either disable Secure Boot or modify the image in order to add a signed boot loader.
Archboot images provide a way to use secure boot on installation media.
Disabling Secure Boot
The Secure Boot feature can be disabled via the UEFI firmware interface. How to access the firmware configuration is described in #Before booting the OS.
If using a hotkey did not work and you can boot Windows, you can force a reboot into the firmware configuration in the following way (for Windows 10): Settings > Update & Security > Recovery > Advanced startup (Restart now) > Troubleshoot > Advanced options > UEFI Firmware settings > restart.
Note that some motherboards (this is the case in a Packard Bell laptop and recent Xiaomi laptops) only allow to disable secure boot if you have set an administrator password (that can be removed afterwards). See also Rod Smith's Disabling Secure Boot.
Repacking the installation image
See #ISO repacking.
Editing the installation medium
If you are using a USB flash installation medium, then it is possible to manually edit the EFI system partition on the medium to add support for Secure Boot.
Plug in the USB drive, then mount the partition:
# mount /dev/disk/by-label/ARCHISO_EFI /mnt
Then follow the instructions in #Using a signed boot loader to install any signed boot loader. For example, to install #PreLoader:
# mv /mnt/EFI/BOOT/BOOTx64.EFI /mnt/EFI/BOOT/loader.efi # cp /usr/share/preloader-signed/PreLoader.efi /mnt/EFI/BOOT/BOOTx64.EFI # cp /usr/share/preloader-signed/HashTool.efi /mnt/EFI/BOOT/HashTool.efi
Implementing Secure Boot
There are certain conditions making for an ideal setup of Secure boot:
- UEFI considered mostly trusted (despite having some well known criticisms and vulnerabilities[1]) and necessarily protected by a strong password
- Default manufacturer/third party keys are not in use, as they have been shown to weaken the security model of Secure Boot by a great margin[2]
- UEFI directly loads a user-signed EFISTUB-compatible unified kernel image (no boot manager), including microcode (if applicable) and initramfs so as to maintain throughout the boot process the chain of trust established by Secure Boot and reduce the attack surface
- Use of full drive encryption, so that the tools and files involved in the kernel image creation and signing process cannot be accessed and tampered with by someone having physical access to the machine.
- Some further improvements may be obtained by using a TPM, although tooling and support makes this harder to implement.
A simple and fully self-reliant setup is described in #Using your own keys, while #Using a signed boot loader makes use of intermediate tools signed by a third-party.
Using the GRUB bootloader requires extra steps before enabling secure boot, see GRUB#Secure Boot support for details.
Using your own keys
Secure Boot implementations use these keys:
- Platform Key (PK)
- Top-level key.
- Key Exchange Key (KEK)
- Keys used to sign Signatures Database and Forbidden Signatures Database updates.
- Signature Database (db)
- Contains keys and/or hashes of allowed EFI binaries.
- Forbidden Signatures Database (dbx)
- Contains keys and/or hashes of denylisted EFI binaries.
See The Meaning of all the UEFI Keys for a more detailed explanation.
To use Secure Boot you need at least PK, KEK and db keys. While you can add multiple KEK, db and dbx certificates, only one Platform Key is allowed.
Once Secure Boot is in "User Mode" keys can only be updated by signing the update (using sign-efi-sig-list) with a higher level key. Platform key can be signed by itself.
Backing up current variables
Before creating new keys and modifying EFI variables, it is advisable to backup the current variables, so that they may be restored in case of error.
Install the efitools package, then run the following commands to backup all four of the principal Secure Boot variables:
$ for var in PK KEK db dbx ; do efi-readvar -v $var -o old_${var}.esl ; done
If you perform this command on a new computer or motherboard, the variables you extract will most likely be the ones provided by Microsoft.
Putting firmware in "Setup Mode"
Secure Boot is in Setup Mode when the Platform Key is removed. To put firmware in Setup Mode, enter firmware setup utility and find an option to delete or clear certificates. How to enter the setup utility is described in #Before booting the OS.
Assisted process with sbctl
sbctl is a user-friendly way of setting up secure boot and signing files.
To use it, install sbctl. See also the upstream README and sbctl(8).
Creating and enrolling keys
Before starting, go to your firmware settings and set secure boot mode to Setup mode. This is different for each device: see sbctl(8) § USAGE.
Once you log back in, check the secure boot status:
$ sbctl status
You should see that sbctl is not installed and secure boot is disabled.
Then create your custom secure boot keys:
# sbctl create-keys
Enroll your keys, with Microsoft's keys, to the UEFI:
# sbctl enroll-keys -m
sbctl enroll-keys
. Only do this if you know what you are doing.Check the secure boot status again:
$ sbctl status
sbctl should be installed now, but secure boot will not work until the boot files have been signed with the keys you just created.
Signing
Check what files need to be signed for secure boot to work:
# sbctl verify
Now sign all the unsigned files. Usually the kernel and the boot loader need to be signed. For example:
# sbctl sign -s /boot/vmlinuz-linux # sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
The files that need to be signed will depend on your system's layout, kernel and boot loader.
# sbctl verify | sed 's/✗ /sbctl sign -s /e'
This example assumes that the outputted file paths are relative to /boot
.
Now you are done! Reboot your system and turn secure boot back on in the firmware settings. If the boot loader and OS load, secure boot should be working. Check with:
$ sbctl status
Automatic signing with the pacman hook
sbctl comes with a pacman hook that automatically signs all new files whenever the Linux kernel, systemd or the boot loader is updated.
systemd-boot-update.service
, the boot loader is only updated after a reboot, and the sbctl pacman hook will therefore not sign the new file. As a workaround, it can be useful to sign the boot loader directly in /usr/lib/
, as bootctl install
and update
will automatically recognize and copy .efi.signed files to the ESP if present, instead of the normal .efi file. See bootctl(1).
# sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi
Manual process
Install efitools
Nearly all of the following sections require you to install the efitools package.
Creating keys
To generate keys, perform the following steps.
You will need private keys and certificates in multiple formats:
- .key
- PEM format private keys for EFI binary and EFI signature list signing.
- .crt
- PEM format certificates for sbsign(1), sbvarsign(1) and sign-efi-sig-list(1).
- .cer
- DER format certificates for firmware.
- .esl
- Certificates in an EFI Signature List for sbvarsign(1), efi-updatevar(1), KeyTool and firmware.
- .auth
- Certificates in an EFI Signature List with an authentication header (i.e. a signed certificate update file) for efi-updatevar(1), sbkeysync, KeyTool and firmware.
Create a GUID for owner identification:
$ uuidgen --random > GUID.txt
Platform key:
$ openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt $ openssl x509 -outform DER -in PK.crt -out PK.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
Sign an empty file to allow removing Platform Key when in "User Mode":
$ sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null noPK.auth
Key Exchange Key:
$ openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt $ openssl x509 -outform DER -in KEK.crt -out KEK.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
Signature Database key:
$ openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db.crt $ openssl x509 -outform DER -in db.crt -out db.cer $ cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth
Helper script
A helper/convenience script is offered by the author of the reference page on this topic[3] (requires python). A mildly edited version is also packaged as sbkeysAUR.
In order to use it, simply create a folder in a secure location (e.g. /etc/efi-keys/
if later use of sbupdate-gitAUR to automate unified kernel image creation and signing is planned) and run it:
# mkdir /etc/efi-keys # cd !$ # curl -L -O https://www.rodsbooks.com/efi-bootloaders/mkkeys.sh # chmod +x mkkeys.sh # ./mkkeys.sh Enter a Common Name to embed in the keys, e.g. "Secure Boot"
This will produce the required files in different formats.
Enrolling keys in firmware
Use one of the following methods to enroll db, KEK and PK certificates.
Using sbkeysync
Install sbsigntools. Create a directory /etc/secureboot/keys
with the following directory structure -
/etc/secureboot/keys ├── db ├── dbx ├── KEK └── PK
For example using:
# mkdir -p /etc/secureboot/keys/{db,dbx,KEK,PK}
Then copy each of the .auth files that were generated earlier into their respective locations (for example, PK.auth
into /etc/secureboot/keys/PK
and so on).
If you want to verify the changes sbkeysync
will make to the system's UEFI keystore, use:
# sbkeysync --keystore /etc/secureboot/keys --pk --dry-run --verbose
Finally, use sbkeysync
to enroll your keys.
# sbkeysync --keystore /etc/secureboot/keys --verbose # sbkeysync --keystore /etc/secureboot/keys --verbose --pk
- If
sbkeysync
returns write errors, first runchattr -i /sys/firmware/efi/efivars/{PK,KEK,db}*
prior to issuing commands withsbkeysync
to temporarily change file attributes, enabling writing of the EFI keys within theefivars
directory. See chattr(1). - If you get a
permission denied
error forPK.auth
, you can enroll it with commandefi-updatevar -f /etc/secureboot/keys/PK/PK.auth PK
. - If this fails, it might be due to the firmware locking BIOS settings. On Dell & Lenovo systems, you may need to reset the BIOS password: Sysfs Firmware Authentication Documentation
On Lenovo systems:
# cat > /sys/class/firmware-attributes/thinklmi/authentication/Admin/current_password
my-super-secret-password
^D
On Dell systems:
# cat > /sys/class/firmware-attributes/dell-wmi-sysman/authentication/Admin/current_password
my-super-secret-password
^D
and try again.On next boot the UEFI should be back in User Mode and enforcing Secure Boot policy.
Using firmware setup utility
Copy all *.cer
, *.esl
, *.auth
files (except the noPK.auth
file!) to a FAT formatted file system (you can use EFI system partition).
noPK.auth
file to the EFI system partition (ESP) of your PC! If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with their own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the noPK.auth
file. Therefore keep the noPK.auth
file in a secret, safe place where only you have access to. A safe place for the noPK.auth file are:
- an external USB stick with an EFI system partition when using
KeyTool
. Unfortunately,KeyTool
can only read files from unencrypted storage. - encrypted storage on your PC when using
sbkeysync
.
The EFI system partition of your PC must not be encrypted according to the UEFI specifications and can be mounted and read on another PC (if your PC is stolen and if the hard drive is taken out and connected to another PC). Copying the noPK.auth
file to the ESP of your PC and deleting it afterwards is also not advisable, because deleted files on the FAT32 EFI system partition can be recovered with tools like PhotoRec.
Launch firmware setup utility and enroll db, KEK and PK certificates. Firmwares have various different interfaces, see Replacing Keys Using Your Firmware's Setup Utility for example how to enroll keys.
If the used tool supports it prefer using .auth and .esl over .cer.
Using KeyTool
KeyTool.efi
is in efitools package, copy it to ESP. To use it after enrolling keys, sign it with sbsign
.
# sbsign --key db.key --cert db.crt --output esp/KeyTool-signed.efi /usr/share/efitools/efi/KeyTool.efi
Launch KeyTool-signed.efi
using firmware setup utility, boot loader or UEFI Shell and enroll keys.
See Replacing Keys Using KeyTool for explanation of KeyTool menu options.
Using systemd-boot
Since systemd version 252, systemd-boot can be used to enroll keys. To enroll keys, copy the db.auth
, KEK.auth
and PK.auth
to the special folder on the ESP:
# cp db.auth KEK.auth PK.auth esp/loader/keys/NAME/
Where NAME can be any unique name you assign, such as MYKEYS
.
After copying the keys and enabling the secure boot setup mode a new entry would appear in the boot menu that would read Enroll Secure Boot keys: MYKEYS
. Activating this entry would enroll the secure boot keys.
Signing EFI binaries
When Secure Boot is active (i.e. in "User Mode"), only signed EFI binaries (e.g. applications, drivers, unified kernel images) can be launched.
With sbsigntools
Install sbsigntools to sign EFI binaries with sbsign(1).
- To check if a binary is signed and list its signatures use
sbverify --list /path/to/binary
. - The rEFInd boot manager's
refind-install
script can sign rEFInd EFI binaries and copy them together with the db certificates to the ESP. See rEFInd#Using your own keys for instructions.
--output
the resulting file will be filename.signed
. See sbsign(1) for more information.To sign your kernel and boot manager use sbsign, e.g.:
# sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux # sbsign --key db.key --cert db.crt --output esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/BOOTx64.EFI
Signing the kernel with a mkinitcpio post hook
You can also use a mkinitcpio post hook to sign the kernel when the initramfs gets generated.
Create the following file an make it executable:
/etc/initcpio/post/kernel-sbsign
#!/usr/bin/env bash kernel="$1" [[ -n "$kernel" ]] || exit 0 # use already installed kernel if it exists [[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION" keypairs=(/path/to/db.key /path/to/db.crt) for (( i=0; i<${#keypairs[@]}; i+=2 )); do key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}" if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel" fi done
Replace /path/to/db.key
and /path/to/db.crt
with the paths to the key pair you want to use for signing the kernel.
If you are using systemd-boot, there is a dedicated pacman hook doing this task semi-automatically.
Signing unified kernel images with a mkinitcpio post hook
See Unified kernel image#Signing the UKIs for Secure Boot.
Fully automated unified kernel generation and signing with sbupdate
sbupdate is a tool made specifically to automate unified kernel image generation and signing on Arch Linux. It handles installation, removal and updates of kernels through pacman hooks.
Install sbupdate-gitAUR and configure it following the instructions given on the project's homepage.[4]
OUT_DIR="EFI/Linux"
to get your signed kernel images directly recognized without needing configuration. See systemd-boot(7) § FILES and systemd-boot#Adding loaders.Once configured, simply run sbupdate
as root for first-time image generation.
warning: data remaining[26413568 vs 26423180]: gaps between PE/COFF sections?
. Those are harmless and can be safely ignored.[5]Updating keys
Once Secure Boot is in "User Mode" any changes to KEK, db and dbx need to be signed with a higher level key.
For example, if you wanted to replace your db key with a new one:
- Create the new key,
- Convert it to EFI Signature List,
- Sign the EFI Signature List,
- Enroll the signed certificate update file.
$ cert-to-efi-sig-list -g "$(< GUID.txt)" new_db.crt new_db.esl $ sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth
If instead of replacing your db key, you want to add another one to the Signature Database, you need to use the option -a
(see sign-efi-sig-list(1)):
$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db new_db.esl new_db.auth
When new_db.auth
is created, enroll it.
Dual booting with other operating systems
Microsoft Windows
It is usually not possible to boot Windows by signing its bootloader (EFI/Microsoft/Boot/bootmgfw.efi
) with a custom, personal key with Secure Boot Mode enabled, without enrolling the "Microsoft Windows Production PCA 2011" key in the UEFI Secure Boot variables:
- if
bootmgfw.efi
contains a signature both from the "Microsoft Windows Production PCA 2011" and from your own Secure Boot db key (so two signatures), then UEFI firmware implementations like INSYDE Corp. 4096.01 (UEFI Version 2.31, Version F.70, Release Date: 07/18/2016, BIOS Revision 15.112, Firmware Revision: 29.66) will not launchbootmgfw.efi
and will throw a security violation error (Selected boot image did not authenticate. Press ENTER to continue.
): UEFI firmware implementation like this can probably only read the first signature - not the second one. Only the certificate for the second signature is enrolled in the UEFI Secure Boot variables, so the Secure Boot verification fails. - if the "Microsoft Windows Production PCA 2011" signature from the
bootmgfw.efi
file is stripped/removed, and only a signature from your own Secure Boot db key is added to the file, then UEFI will launch the file - but Windows will launch a recovery/repair environment: Windows complains that the Windows installation is broken (because the "Microsoft Windows Production PCA 2011" signature onbootmgfw.efi
file is missing).
So to dual boot with Windows,
- you either have to add the hash of
bootmgfw.efi
to the list of allowed hashes in thedb
variable; and you have to update thedb
variable every time a Windows Update changesbootmgfw.efi
. This is very tedious, error-prone and not supported by Microsoft; and for example Bitlocker will not work properly anymore with this setup (Bitlocker will ask for your recovery password every time to decrypt your Windows partition). - or you have to add Microsoft's certificates to the UEFI Secure Boot variables Microsoft has four db certificates and two KEK certificates:
- The Microsoft Windows Production PCA 2011 certificate and Windows UEFI CA 2023 must be included in the
db
variable in order to allow the Windows Operating System to load. - The Microsoft Corporation UEFI CA 2011 certificate and Microsoft UEFI CA 2023 aka the Microsoft 3rd Party UEFI CA certificates should be included in the
db
variable in order to use third-party binaries like UEFI drivers, option ROMs, shim, etc. - The Microsoft Corporation KEK CA 2011 certificate and Microsoft Corporation KEK 2K CA 2023 should be included in the
KEK
variable, in order to "enable revocation of bad images by updating thedbx
and potentially for updatingdb
to prepare for newer Windows signed images". However, Windows will also boot without them.
- The Microsoft Windows Production PCA 2011 certificate and Windows UEFI CA 2023 must be included in the
Create EFI Signature Lists from Microsoft's DER format db
certificates using Microsoft's GUID (77fa9abd-0359-4d32-bd60-28f4e78f784b
) and combine them in one file for simplicity:
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2011.esl MicWinProPCA2011_2011-10-19.crt $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_db_2023.esl 'windows uefi ca 2023.crt' $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2011.esl MicCorUEFCA2011_2011-06-27.crt $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_UEFI_db_2023.esl 'microsoft uefi ca 2023.crt' $ cat MS_Win_db_2011.esl MS_Win_db_2023.esl MS_UEFI_db_2011.esl MS_UEFI_db_2023.esl > MS_db.esl
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Create an EFI Signature List from Microsoft's DER format KEK
certificates using Microsoft's GUID (77fa9abd-0359-4d32-bd60-28f4e78f784b
):
$ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2011.esl MicCorKEKCA2011_2011-06-24.crt $ sbsiglist --owner 77fa9abd-0359-4d32-bd60-28f4e78f784b --type x509 --output MS_Win_KEK_2023.esl 'microsoft corporation kek 2k ca 2023.crt' $ cat MS_Win_KEK_2011.esl MS_Win_KEK_2023.esl > MS_Win_KEK.esl
Sign a db
variable update with your KEK
. Use sign-efi-sig-list
with option -a
to add not replace a db
certificate:
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k KEK.key -c KEK.crt db MS_db.esl add_MS_db.auth
Optional (for strict conformity with Microsoft UEFI Secure Boot requirements): Sign a KEK
variable update with your PK
. Use sign-efi-sig-list
with option -a
to add not replace a KEK
certificate:
$ sign-efi-sig-list -a -g 77fa9abd-0359-4d32-bd60-28f4e78f784b -k PK.key -c PK.crt KEK MS_Win_KEK.esl add_MS_Win_KEK.auth
Follow #Enrolling keys in firmware to enroll add_MS_db.auth
and for strict conformity with Microsoft UEFI Secure Boot requirements add_MS_Win_KEK.auth
into the UEFI Secure Boot Database variables.
Using a signed boot loader
Using a signed boot loader means using a boot loader signed with Microsoft's key. There are two known signed boot loaders: PreLoader and shim. Their purpose is to chainload other EFI binaries (usually boot loaders). Since Microsoft would never sign a boot loader that automatically launches any unsigned binary, PreLoader and shim use an allowlist called Machine Owner Key list, abbreviated MokList. If the SHA256 hash of the binary (Preloader and shim) or key the binary is signed with (shim) is in the MokList they execute it, if not they launch a key management utility which allows enrolling the hash or key.
The enrollment of the Microsoft 3rd Party UEFI CA certificate needs to be enabled in firmware settings to launch EFI binaries and OpROMs signed with this certificate.
PreLoader
When run, PreLoader tries to launch loader.efi
. If the hash of loader.efi
is not in MokList, PreLoader will launch HashTool.efi
. In HashTool you must enroll the hash of the EFI binaries you want to launch, that means your boot loader (loader.efi
) and kernel.
refind-install
script can copy the rEFInd and PreLoader EFI binaries to the ESP. See rEFInd#Using PreLoader for instructions.Set up PreLoader
PreLoader.efi
and HashTool.efi
in efitools package are not signed, so their usefulness is limited. You can get a signed PreLoader.efi
and HashTool.efi
from preloader-signedAUR or download them manually.Install preloader-signedAUR and copy PreLoader.efi
and HashTool.efi
to the boot loader directory; for systemd-boot use:
# cp /usr/share/preloader-signed/{PreLoader,HashTool}.efi esp/EFI/systemd
Now copy over the boot loader binary and rename it to loader.efi
; for systemd-boot use:
# cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/systemd/loader.efi
Finally, create a new NVRAM entry to boot PreLoader.efi
:
# efibootmgr --unicode --disk /dev/sdX --part Y --create --label "PreLoader" --loader /EFI/systemd/PreLoader.efi
Replace X
with the drive letter and replace Y
with the partition number of the EFI system partition.
This entry should be added to the list as the first to boot; check with the efibootmgr
command and adjust the boot-order if necessary.
Fallback
If there are problems booting the custom NVRAM entry, copy HashTool.efi
and loader.efi
to the default loader location booted automatically by UEFI systems:
# cp /usr/share/preloader-signed/HashTool.efi esp/EFI/BOOT/ # cp esp/EFI/systemd/systemd-bootx64.efi esp/EFI/BOOT/loader.efi
Copy over PreLoader.efi
and rename it:
# cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/BOOT/BOOTx64.EFI
For particularly intransigent UEFI implementations, copy PreLoader.efi
to the default loader location used by Windows systems:
# mkdir -p esp/EFI/Microsoft/Boot # cp /usr/share/preloader-signed/PreLoader.efi esp/EFI/Microsoft/Boot/bootmgfw.efi
bootmgfw.efi
first as replacing it may cause problems with Windows updates.As before, copy HashTool.efi
and loader.efi
to esp/EFI/Microsoft/Boot/
.
When the system starts with Secure Boot enabled, follow the steps above to enroll loader.efi
and /vmlinuz-linux
(or whichever kernel image is being used).
How to use while booting?
A message will show up that says Failed to Start loader... I will now execute HashTool.
To use HashTool for enrolling the hash of loader.efi
and vmlinuz.efi
, follow these steps. These steps assume titles for a remastered archiso installation media. The exact titles you will get depends on your boot loader setup.
- Select OK
- In the HashTool main menu, select Enroll Hash, choose
\loader.efi
and confirm with Yes. Again, select Enroll Hash andarchiso
to enter the archiso directory, then selectvmlinuz.efi
and confirm with Yes. Then choose Exit to return to the boot device selection menu. - In the boot device selection menu choose Arch Linux archiso x86_64 UEFI CD
Remove PreLoader
Uninstall preloader-signedAUR and simply remove the copied files and revert configuration; for systemd-boot use:
# rm esp/EFI/systemd/{PreLoader,HashTool}.efi # rm esp/EFI/systemd/loader.efi # efibootmgr --unicode --bootnum N --delete-bootnum # bootctl update
Where N
is the NVRAM boot entry created for booting PreLoader.efi
.
Check with the efibootmgr command and adjust the boot-order if necessary.
Delete enrolled hash
Every entry of hashes enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hashes to free the space and to prevent outdated programs from booting.
Install efitools and copy KeyTool.efi
:
# cp /usr/share/efitools/efi/KeyTool.efi esp/EFI/systemd/KeyTool.efi
Manage to boot to Preloader and you will see the KeyTool entry. You can then edit hashes in the MOK database.
shim
When run, shim tries to launch grubx64.efi
. If MokList does not contain the hash of grubx64.efi
or the key it is signed with, shim will launch MokManager (mmx64.efi
). In MokManager you must enroll the hash of the EFI binaries you want to launch (your boot loader (grubx64.efi
) and kernel) or enroll the key they are signed with.
- If you use #shim with hash, each time you update any of the binaries (e.g. boot loader or kernel) you will need to enroll their new hash.
- Since version 15.3, shim will not launch EFI binaries without a valid
.sbat
section. Runobjdump -j .sbat -s /path/to/binary.efi
to verify if an EFI binary has it. See the SBAT documentation for details. - If you are not actually interested in the security brought by Secure Boot and are only enabling it to meet the requirements posed by Windows 11, you may want to consider disabling the validation process in shim with
mokutil --disable-validation
. In that case you will not need to sign grub (sbat probably still needed) or the kernel images and at the same time be able to boot Windows withchainloader
in grub.
Set up shim
refind-install
script can sign rEFInd EFI binaries and copy them along with shim and the MOK certificates to the ESP. See rEFInd#Using shim for instructions.Install shim-signedAUR.
Rename your current boot loader to grubx64.efi
# mv esp/EFI/BOOT/BOOTx64.EFI esp/EFI/BOOT/grubx64.efi
Copy shim and MokManager to your boot loader directory on ESP; use previous filename of your boot loader as as the filename for shimx64.efi
:
fbx64.efi
(which is under the same directory) unless you actually have a valid bootx64.csv
to use. Otherwise shim will not execute grubx64.efi
but will appear to fail to work and just reset the machine.# cp /usr/share/shim-signed/shimx64.efi esp/EFI/BOOT/BOOTx64.EFI # cp /usr/share/shim-signed/mmx64.efi esp/EFI/BOOT/
Finally, create a new NVRAM entry to boot BOOTx64.EFI
:
# efibootmgr --unicode --disk /dev/sdX --part Y --create --label "Shim" --loader /EFI/BOOT/BOOTx64.EFI
shim can authenticate binaries by Machine Owner Key or hash stored in MokList.
- Machine Owner Key (MOK)
- A key that a user generates and uses to sign EFI binaries.
- hash
- A SHA256 hash of an EFI binary.
Using hash is simpler, but each time you update your boot loader or kernel you will need to add their hashes in MokManager. With MOK you only need to add the key once, but you will have to sign the boot loader and kernel each time it updates.
shim with hash
If shim does not find the SHA256 hash of grubx64.efi
in MokList it will launch MokManager (mmx64.efi
).
In MokManager select Enroll hash from disk, find grubx64.efi
and add it to MokList. Repeat the steps and add your kernel vmlinuz-linux
. When done select Continue boot and your boot loader will launch and it will be capable launching the kernel.
shim with key
Install sbsigntools.
You will need:
- .key
- PEM format private key for EFI binary signing.
- .crt
- PEM format certificate for sbsign.
- .cer
- DER format certificate for MokManager.
Create a Machine Owner Key:
$ openssl req -newkey rsa:2048 -nodes -keyout MOK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Machine Owner Key/" -out MOK.crt $ openssl x509 -outform DER -in MOK.crt -out MOK.cer
grubx64.efi
binary), so make sure you use a 2048 key for now. See Debian:SecureBoot#Generating a new key.Sign your boot loader (named grubx64.efi
) and kernel:
# sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux # sbsign --key MOK.key --cert MOK.crt --output esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/grubx64.efi
You will need to do this each time they are updated. You can automate the kernel signing with a mkinitcpio post hook. Create the following file and make it executable:
/etc/initcpio/post/kernel-sbsign
#!/usr/bin/env bash kernel="$1" [[ -n "$kernel" ]] || exit 0 # use already installed kernel if it exists [[ ! -f "$KERNELDESTINATION" ]] || kernel="$KERNELDESTINATION" keypairs=(/path/to/MOK.key /path/to/MOK.crt) for (( i=0; i<${#keypairs[@]}; i+=2 )); do key="${keypairs[$i]}" cert="${keypairs[(( i + 1 ))]}" if ! sbverify --cert "$cert" "$kernel" &>/dev/null; then sbsign --key "$key" --cert "$cert" --output "$kernel" "$kernel" fi done
Copy MOK.cer
to a FAT formatted file system (you can use EFI system partition).
Reboot and enable Secure Boot. If shim does not find the certificate grubx64.efi
is signed with in MokList it will launch MokManager (mmx64.efi
).
In MokManager select Enroll key from disk, find MOK.cer
and add it to MokList. When done select Continue boot and your boot loader will launch and it will be capable launching any binary signed with your Machine Owner Key.
shim with key and GRUB
See GRUB#Shim-lock for instructions.
Delete enrolled hash/key
Every entry of hash/key enrolled in the MOK database eats up a little piece of space of NVRAM. You may want to delete useless hash/key to free the space and to prevent outdated programs from booting.
MOK database can be managed with mokutil
List enrolled keys & hashes
# mokutil --list-enrolled
Remove hash from database. The password entered here will be asked for confirmation to delete in MOK manager.
# mokutil --delete-hash <hash to remove from above command> Input password:
Remove key from database
# mokutil --delete MOK.cer
List hashes/keys to be deleted on next reboot
# mokutil --list-delete
On next reboot, MOK manager will be initiated with option to Enroll/Delete hashes/keys. More details mokutil(1)
Remove shim
Uninstall shim-signedAUR, remove the copied shim and MokManager files and rename back your boot loader.
Protecting Secure Boot
The only way to prevent anyone with physical access from disabling Secure Boot is to protect the firmware settings with a password. Most UEFI firmwares provide such a feature, usually listed under the "Security" section in the firmware settings.
Consider enabling kernel lockdown mode. See [7].
Tips and tricks
ISO repacking
It is possible to unpack and repack the official installation image using libisoburn and mtools. This way, you can create an image that supports Secure Boot, either with custom keys or with a signed boot loader.
Sign the official ISO with custom keys
Support for Secure Boot using custom keys can be added to the official ISO by simply extracting the boot loader (BOOTx64.EFI
and BOOTIA32.EFI
), kernel, UEFI shell, signing them and then repacking the ISO with the signed files.
First extract the relevant files and El Torito boot images:
$ osirrox -indev archlinux-YYYY.MM.DD-x86_64.iso \ -extract_boot_images ./ \ -cpx /arch/boot/x86_64/vmlinuz-linux \ /EFI/BOOT/BOOTx64.EFI \ /EFI/BOOT/BOOTIA32.EFI \ /shellx64.efi \ /shellia32.efi ./
xorrisofs(1) option -rational-rock
as used by mkarchiso makes the files on ISO 9660 read-only which persists after extracting them. Make the files writable so that they can be modified:
$ chmod +w BOOTx64.EFI BOOTIA32.EFI shellx64.efi shellia32.efi vmlinuz-linux
Sign the files. To do so with sbsigntools, for example:
$ sbsign --key db.key --cert db.crt --output BOOTx64.EFI BOOTx64.EFI $ sbsign --key db.key --cert db.crt --output BOOTIA32.EFI BOOTIA32.EFI $ sbsign --key db.key --cert db.crt --output shellx64.efi shellx64.efi $ sbsign --key db.key --cert db.crt --output shellia32.efi shellia32.efi $ sbsign --key db.key --cert db.crt --output vmlinuz-linux vmlinuz-linux
Copy the boot loader and UEFI shell to eltorito_img2_uefi.img
. It will be used as the EFI system partition and will be listed as an El Torito UEFI boot image. The size of eltorito_img2_uefi.img
is fixed, but there is 1 MiB free space added by mkarchiso for the purposes of rounding/alignment and to account for reserved sectors, so the size increase from the signatures should not be an issue.
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI BOOTIA32.EFI ::/EFI/BOOT/ $ mcopy -D oO -i eltorito_img2_uefi.img shellx64.efi shellia32.efi ::/
Repack the ISO using the modified El Torito UEFI boot image and add the signed boot loader files, UEFI shell and kernel to ISO 9660:
$ xorriso -indev archlinux-YYYY.MM.DD-x86_64.iso \ -outdev archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso \ -map vmlinuz-linux /arch/boot/x86_64/vmlinuz-linux \ -map_l ./ /EFI/BOOT/ BOOTx64.EFI BOOTIA32.EFI -- \ -map_l ./ / shellx64.efi shellia32.efi -- \ -boot_image any replay \ -append_partition 2 0xef eltorito_img2_uefi.img
Boot the resulting archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso
.
Replacing the boot loader with PreLoader
Another way to add Secure Boot support to the official ISO is by extracting the boot loader and replacing it with #PreLoader.
EFI/BOOT/BOOTx64.EFI
) is built with --disable-shim-lock
so it cannot be used with shim. This is a GRUB limitation where it can either be compatible with shim or with custom signatures, but not both at the same time.First, extract the boot loader and the El Torito boot image:
$ osirrox -indev archlinux-YYYY.MM.DD-x86_64.iso \ -extract_boot_images ./ \ -cpx /EFI/BOOT/BOOTx64.EFI ./
Replace the BOOTx64.efi
file with PreLoader:
$ mv BOOTx64.EFI loader.efi $ cp /usr/share/preloader-signed/PreLoader.efi BOOTx64.EFI $ cp /usr/share/preloader-signed/HashTool.efi HashTool.efi
Add the new files to the boot image:
$ mcopy -D oO -i eltorito_img2_uefi.img BOOTx64.EFI loader.efi HashTool.efi ::/EFI/BOOT/
Finally, repack the ISO using the modified boot image and the new boot loader files:
$ xorriso -indev archlinux-YYYY.MM.DD-x86_64.iso \ -outdev archlinux-YYYY.MM.DD-x86_64-Secure_Boot.iso \ -map_l ./ /EFI/BOOT/ BOOTx64.EFI loader.efi HashTool.efi -- \ -boot_image any replay \ -append_partition 2 0xef eltorito_img2_uefi.img
Enrolling Option ROM digests
Option ROMs (OpROMs), i.e. device firmware that is executed during boot, must be signed for Secure Boot otherwise the devices will not be initialized. Typically OpROMs are signed with the Microsoft 3rd Party UEFI CA certificate which may prevent implementing Secure Boot with only your own keys. To solve this, the SHA256 digests of OpROMs can be enrolled instead.
On systems with a TPM, it is possible to acquire Option ROM SHA256 digests from the TPM event log.
Install tpm2-tools and digest-to-efi-sig-listAUR.
Use tpm2_eventlog(1) to read /sys/kernel/security/tpm0/binary_bios_measurements
and look for the digests of BOOT_SERVICES_DRIVER
.[8]
For example:
# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements
... - EventNum: 9 PCRIndex: 2 EventType: EV_EFI_BOOT_SERVICES_DRIVER DigestCount: 1 Digests: - AlgorithmId: sha256 Digest: "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" ... - EventNum: 10 PCRIndex: 2 EventType: EV_EFI_BOOT_SERVICES_DRIVER DigestCount: 1 Digests: - AlgorithmId: sha256 Digest: "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210" ...
Use digest-to-efi-sig-list to create an EFI signature list for each OpROM digest you find:
$ digest-to-efi-sig-list 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef OpROM1.esl $ digest-to-efi-sig-list fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210 OpROM2.esl
In case you have multiple OpROMs, combine their EFI signature lists into one so that it could be signed as a single file:
$ cat OpROM1.esl OpROM2.esl > OpROM.esl
Sign the EFI signature list for appending to the Signature Database:
$ sign-efi-sig-list -a -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db OpROM.esl OpROM.auth
The final and most dangerous step is to remove Microsoft 3rd Party UEFI CA certificate from the Signature Database and see if the system still boots and all devices still work.
See also
- Understanding the UEFI Secure Boot Chain by tianocore
- Wikipedia:Unified Extensible Firmware Interface#Secure Boot
- Dealing with Secure Boot by Rod Smith
- Controlling Secure Boot by Rod Smith
- UEFI secure booting (part 2) by Matthew Garrett
- UEFI Secure Boot by James Bottomley
- efitools README
- Will your computer's "Secure Boot" turn out to be "Restricted Boot"? — Free Software Foundation
- Free Software Foundation recommendations for free operating system distributions considering Secure Boot
- Intel's UEFI Secure Boot Tutorial
- Secure Boot, Signed Modules and Signed ELF Binaries
- National Security Agency docs: UEFI Defensive Practices Guidance and unclassified UEFI Secure Boot customization
- sbkeysync & maintaining uefi key databases by Jeremy Kerr
- Secure your boot process: UEFI + Secureboot + EFISTUB + Luks2 + lvm + Arch Linux (2020-07)
- How is hibernation supported, on machines with UEFI Secure Boot? (Security StackExchange)
- Authenticated Boot and Disk Encryption on Linux by Lennart Poettering (2021-09-23)
- The tool cryptbootAUR simplifies the whole process and is easy to use