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.

Figure 1: UEFI Secure Boot defines several different key types.

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).

Figure 2: How the Secure Boot process works. If the bootloader cannot guarantee that it is trustworthy, the system will not start.

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.