Trying out UEFI boot security on a recent Linux system
State of the Boot
Opinions differ on the UEFI boot security system, but one thing is certain: Secure Boot is here to stay. We thought it was time to ask, "How hard is it to boot a popular Linux distribution in a UEFI Secure Boot environment?"
The Unified Extensible Firmware Interface (UEFI) swept into the headlines a couple years ago as a comprehensive replacement for the BIOS system used to boot millions of personal computers around the world. UEFI, which is essentially "a specification that defines a software interface between an operating system and platform firmware," [1] is a vast project, with features that affect device drivers, time services, and many other aspects of computer operation. However, the feature that has captured the most attention is a controversial component known as Secure Boot.
UEFI Secure Boot was billed as a feature for making sure an "unauthorized" operating system doesn't take over the system, and the Linux community quickly realized that "unauthorized" means something more like "non-Microsoft."
Since then, open source coders have developed some techniques for co-existing with UEFI Secure Boot, and some Linux projects have even made their peace with Microsoft to become officially "authorized" through Microsoft's certificate authority.
Now that the smoke has cleared and the leading Linux distros have had time to respond to the challenges of UEFI Secure Boot, we thought it was a good time to take a look at the state of Secure Boot and Linux.
More on UEFI
The UEFI specification supports easily extensible firmware through a variety of modules. These modules include an embedded network module for remote maintenance, as well as modules for digital rights management and BIOS emulation. The Secure Boot technology included with UEFI checks to see whether the bootloader is signed with a cryptographic key that authorizes a firmware contained in the database. By checking the signature of the bootloader, the kernel, and possibly other userspace code, UEFI firmware can prohibit unsigned software from running on the system.
Windows 8, which is the first operating system to implement the full range of UEFI Secure Boot features, can thus prevent the execution of malicious code. However, the owner of the computer can no longer freely choose which operating system to install.
Secure Boot
UEFI Secure Boot validates the boot process. The UEFI specification 2.4 defines the following components and processes for this purpose:
- A programming interface for accessing cryptographically protected UEFI variables in flash memory
- A format for storing X.509 certificates in UEFI variables
- A method for validating the bootloader and the drivers using Authenticode signatures
- A mechanism for revocation of compromised certificates and signatures
UEFI Secure Boot distinguishes between the keys listed in Table 1 and Figure 1.
Table 1
UEFI Keys
Key | Function |
---|---|
Platform Key (PK) |
Usually a key provided by the hardware manufacturer (OEM); the PK allows the manipulation of the KEK. Only one PK is possible. |
Key Exchange Key (KEK) |
Multiple certificates possible; different keys possible for different OS vendors (e.g., Microsoft KEK CA); the KEK allows manipulation of the db and dbx. |
Authorized DB (db) |
Multiple certificates and hashes possible (e.g., Microsoft Windows Production CA); for identifying trusted code. |
Unauthorized DB (dbx) |
Multiple certificates or hashes possible; for identifying compromised code or malicious code. |
Furthermore, the specification describes two modes that Secure Boot can assume. The first is Setup mode. A UEFI firmware system whose Secure Boot implementation is operating in Setup mode does not protect the certificate store against tampering. In Setup mode, it is possible to save certificates and hashes in the UEFI certificate store, or remove them from the store, on a running operating system. This mode is used primarily to set up Secure Boot.
User mode severely restricts manipulation of the certificate store. Changes are no longer possible without authentication from the active operating system. To change the db or dbx certificate store, you need authorization by means of the private key stored in the KEK store of the certificate. Changing the KEK and PK store, however, requires the private key of the deposited platform key certificate.
Switching from User mode to Setup mode is possible by removing the platform keys. Removing a platform key requires knowledge of the private key associated with the platform key. Alternatively, you can use the UEFI Setup interface to change to Setup mode. Entering the Setup interface requires access to the hardware and, if necessary, knowledge of passwords.
UEFI Secure Boot does not prevent the installation of malware or modification of the bootloader, but it does ensure the reliability of the boot process. If the trustworthiness of the bootloader cannot be guaranteed, booting is prevented (shown in simplified form in Figure 2).
Secure Boot with Windows
Microsoft supports Secure Boot as of Windows 8. However, Secure Boot is not mandatory for the functionality of the operating system. You can't use older Microsoft operating systems with an active Secure Boot feature because Microsoft does not provide a signed bootloader for these older systems.
Hardware manufacturers who want to display the Windows 8 logo on their systems must support UEFI Secure Boot and enable the Secure Boot feature on delivery. Therefore, these systems must also have the necessary key material in the UEFI firmware. This key material includes, at a minimum, the Microsoft Windows Production PCA 2011 certificate that is used by Microsoft for signing its own products. Additionally, the hardware manufacturers can store other Microsoft certificates (e.g., the Microsoft Corporation UEFI CA 2011 certificate) and their own certificates in UEFI memory.
UEFI Secure Boot has mainly been used on client systems thus far. Future Microsoft operating systems are likely to make this technology available on server systems or even enforce its use.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
AlmaLinux Now Supports Raspberry Pi 5
If you're looking to create with the Raspberry Pi 5 and want to use AlmaLinux as your OS, you're in luck because it's now possible.
-
Kubuntu Focus Releases New Iterations of Ir14 and Ir16 Laptops
If you're a fan of the Kubuntu Focus laptops or have been waiting for the right time to purchase one, that time might be now.
-
NixOS 24.05 Is Ready for Prime Time
The latest release of NixOS (Uakari) has arrived and offers its usual reproducible, declarative, and reliable goodness.
-
Linux Lite 7.0 Officially Released
Based on Ubuntu 24.04 and kernel 6.8, Linux Lite version 7 now offers more options than ever.
-
KaOS Linux 2024.05 Adds Bcachfs Support and More
With updates all around, KaOS Linux now includes support for the bcachefs file system.
-
TUXEDO Computers Unveils New Iteration of the Stellaris Laptop Line
The Stellaris Slim 15 is the 6th generation and includes either an AMD or Intel CPU
-
KDE Releases Plasma 6.0.5
The latest release of the Plasma desktop has arrived with several improvements and the usual bug fixes.
-
Gnome OS Adopting systemd-sysupdate
Gnome OS is about to undergo a major under-the-hood change that promises enhanced security.
-
Endless OS 6 Now Available
After more than a year since the last update, the latest release of Endless OS is now available for general usage.
-
Fedora Asahi 40 Remix Available for Macs with Apple Silicon
If you've been anticipating KDE's Plasma 6 for your Apple Silicon-powered Mac, then you're in luck.