State of the Boot

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.

Secure Boot with Linux

If you want to use Secure Boot with other operating systems, you have three options:

• Get Microsoft to sign your bootloader.
• Deposit your own KEK key with the hardware manufacturer. Apparently, however, no other operating system vendor on the market has the required political punch to convince hardware manufacturers to install an additional KEK.
• Create your own platform key (PK) and deposit it in the UEFI firmware. Replacing the platform key enables access to all other certificate stores. However, replacing a platform key means having physical access to the system.

All the operating systems we examined that support Secure Boot take the first path. Their bootloaders can be installed on a system with Secure Boot enabled and Microsoft key material installed. To this end, Microsoft offers a signature service, which was originally only intended for signing UEFI drivers. This service has also been extended to include alternative third party bootloaders. The third party sends its bootloader to Microsoft. The company checks the bootloader and sends it back with an Authenticode signature. The signature does not confirm the originator but merely the integrity of the bootloader.

The bootloader is signed with the Microsoft Corporation UEFI CA 2011 certificate. The functionality of the bootloader is not guaranteed on any hardware, because this certificate need not be installed according to the Microsoft specification.

Having Microsoft sign the bootloader basically means two sources of potential risk in production use:

• Microsoft can revoke the certificate. If the certificate were put on the UEFI firmware revocation lists by software updates, the firmware would no longer allow the use of the bootloader.
• The signature is only valid for a certain time. The UEFI firmware can reject the signed bootloader after the signature expires and abort the boot process. If the bootloader is not re-signed, the system cannot boot.

Shim

Microsoft typically uses the Shim bootloader for secure booting with the signature service. Shim is a simple open source bootloader. The Shim bootloader indirectly starts bootloaders that are not signed by Microsoft. You can therefore use Shim as a link between the Microsoft-dominated Secure Boot environment and third-party operating systems (Figure  3).

Figure 3: The boot process when the open source Shim bootloader is in the game.

A publicly accessible Shim version is available online and signed with a Microsoft Corporation UEFI CA 2011 certificate. Thanks to this signature, you can start Shim on any of the hardware platforms we investigated using the standard key material and with Secure Boot enabled. Some Linux systems, such as Ubuntu 13.04 and Fedora 19 install alternative versions of Shim, which have also been signed by Microsoft.

Shim verifies the signature of the next bootloader. The key material for this verification can come from three sources:

• the UEFI certificate stores db and dbx;
• the Machine Owner Key list (MOK list), Shim's own certificate store;
• a certificate or hash deposited in the Shim binary.

The MOK list can store both certificates and hashes. The use of certificates means that the second bootloader is signed. Just like the UEFI-specific certificate store, The MOK list is stored in the NVRAM of the UEFI firmware, but it can typically be modified without authentication during the boot process.

Because certificates can be stored directly in the Shim binary file, the verification process can take place independently of the contents of the certificate store. Linux distributions Ubuntu 13.04 and Fedora 19 take this approach.

If verification of the second bootloader – typically Grub2 – is successful, it is executed. However, if the verification fails, the MokManager application, which is part of Shim, launches. The MokManager allows the user to add certificates or hashes interactively to the MOK list and thus allows execution of the second bootloader.

Analysis

Because Secure Boot technology has far-reaching implications for installing alternative operating systems, we decided to analyze the possibilities and problems in these environments.

The first objective was to analyze the modules, keys, and variables stored in the UEFI pre-boot environment and their influence on the operating system boot process. Our lab subjects were 64-bit x86-compatible platforms by manufacturers HP, Dell, Lenovo, and Medion. We looked into the hardware platform owner's options for influencing the Secure Boot-controlled boot process on these platforms. In particular, we focused on the following questions:

• Can the user disable Secure Boot?
• Can the user define alternative key material in the UEFI firmware?
• What options does the hardware manufacturer offer for modifying the key material?

We also investigated the extent to which a user can install Windows 8 Pro, Red Hat Enterprise Linux 6.4, Ubuntu 13.04, Debian 7.1.0, and Fedora 19 with Secure Boot enabled. We developed some modification steps for using the operating system in combination with Secure Boot.

Finally, we studied Secure Boot in a dual-boot environment composed of Windows 8 Pro and Debian 7.1.0. Among other things, we analyzed how the operating system prevents changes to the Secure Boot configuration and how to keep the operating systems from interfering with one another.

Hardware Platforms

All the systems we investigated allow changes to the certificate stores on which the Secure Boot process is based. For this purpose, however, you often need additional software, such as the EFI Tools, which are available under a free license. Using UEFI Setup, you can load the keys originally shipped by the manufacturer into the certificate store on all systems to revert to the initial state as defined by the manufacturer. Also, the UEFI Setup interface lets you change to the Setup mode in all cases and thus modify the certificate store.

Out of the systems we tested, only the Dell system supported targeted insertion or removal of individual certificates or hashes using UEFI Setup. For all computers, it was at least possible, however, to modify the certificate store in Setup mode using the EFI tools.

All systems provided the ability to disable Secure Boot. Furthermore, all the manufacturers provided the certificates required by the Windows Hardware Certification Requirements, including the optional Microsoft Corporation UEFI CA 2011 certificate. Some manufacturers additionally installed their own certificates.

The software pre-installed on the EFI partition is essentially no more than diagnostic software by the vendors.

The user can influence the Secure Boot functionality on any system. Users can disable Secure Boot, switch to Setup mode, and load their own key material. You can use the UEFI setup for this process. In most cases, however, you need to resort to other tools, such as EFI Tools.

Practical Test

To check the extent to which current operating systems can run on the selected hardware platforms while using Secure Boot, we performed a number of test installations on each platform. We also checked to see whether the system starts properly after installation and is thus basically functional.

If the operating system supported Secure Boot, we analyzed its implementation. If Secure Boot support was not present, we took additional steps to make the system suitable for enabling Secure Boot.

We tested the following operating systems:

• Microsoft Windows 8 Pro
• Red Hat Enterprise Linux 6.4
• Ubuntu 13.04
• Debian 7.1.0
• Fedora 19
• FreeBSD 9.2

Results

In spite of the relatively new technology and the comprehensive specification, Secure Boot works on all tested platforms with the operating systems we used. Starting a signed UEFI application such as a bootloader works, provided that the appropriate certificate is included in the db certificate store of the UEFI firmware. Launching such an application is denied if a suitable certificate does not exist in the certificate store. Similarly, verification of UEFI applications based on hashes works well.

Furthermore, it is possible to install and run the Windows 8 Pro, Ubuntu 13.04, and Fedora 19 operating system with Secure Boot enabled. The other operating systems we looked at  – Red Hat Enterprise Linux 6.4, FreeBSD 9.2, and Debian 7.1.0  – do not support Secure Boot and are therefore installed with Secure Boot disabled. However, we found that we could modify these systems relatively easily to support Secure Boot.

We found significant differences in how the various systems actually integrated the Secure Boot security enhancements. For instance, the security gains are low if you use Ubuntu 13.04. Although the bootloader is verified, an effective review of the kernel, including its modules, does not take place. In contrast, Fedora 19 not only verifies the bootloader but also the kernel and its modules.

FreeBSD is planning an implementation similar to the one already introduced by Fedora. Although Windows 8 Pro also performs a check of the bootloader and the kernel, an assessment of the effectiveness of protective measures is considerably more difficult than in the Linux systems we examined. The difficulty is mainly due to the complex procedure for verifying loadable kernel components such as drivers. To detect malicious software, Microsoft relies on collaboration between the kernel and anti-malware products.

The effectiveness of the protections depends on the quality of the product you use. We didn't include Microsoft's recent ELAM technology in this study because of its complexity. Furthermore, the changes listed below for Debian 7.1.0, which can also be performed on Red Hat Enterprise 6.4 and FreeBSD 9.2, only offer minor security gains. The results of these tests appear in Table 2.

With Your Own Keys

The following section shows how to install and configure Debian 7.1.0 in a dual Secure Boot environment alongside Windows  8 Pro. The intent is for the Debian system to be operational, independent of certificates by Microsoft, with Secure Boot enabled and without affecting the operability of Windows  8 Pro. We do not want either of the two systems to be able to modify the UEFI certificate store.

Once installation of the operating systems is completed successfully, the bootloader on the Debian system needs to be signed or its hash added to the db certificate store. Signing the installed bootloader, however, would entail a significant disadvantage: When the system updates the bootloader, it does not have a valid signature or the hash is invalid, which means subsequent boot operations will fail. For this reason, we create another bootloader, which we call the Secure Boot preloader. We change the system configuration so that the Secure Boot preloader is executed by the UEFI firmware instead of the bootloader, which is set up during the installation of Debian. The Secure Boot preloader then loads the original bootloader without any further validation. As a result, only the preloader has to be signed. To set up the Secure Boot preloader, you can use the commands in Listing 1.

Afterward, you need to sign the Secure Boot preloader with:

sbsign --key db.key --cert db.pem.crt/boot/efi/EFI/debian/secure-boot-preloader.efi

The sbsign tool takes care of signing the bootloader; sbsign comes with the sbsigntools toolbox.

This command assumes the private key used for signing UEFI applications resides in the db.key file and that the associated certificate resides in db.pem.crt. The signing step should not take place on the affected system itself, but in a safe working environment, to keep the private key secure.

After setting up the bootloader, you need to modify the certificate store of the UEFI firmware. We used the EFI tools to modify the certificate store. To this end, you need to create a bootable USB stick containing the efitools package. A suitable image is provided by the author of efitools [2]. You can use the tool dd to copy it to a USB stick then convert both the Microsoft Windows Production PCA 2011 certificate and the keys belonging to your own key material (PK, KEK, db) to a format that the UEFI firmware can process. The cert-to-efi-sig-list command from the EFI Tools handles this conversion.

To make the changes to the certificate store, you now need to switch the Secure Boot system on the platform to Setup mode using UEFI Setup. The exact procedure for switching to Setup mode is platform specific.

After that, boot from the prepared USB stick. In the UEFI shell, enter the following commands to launch KeyTool. KeyTool provides a rudimentary text-based interface for modifying the UEFI certificate store:

fs0:
cd EFI
cd BOOT
KEYTOOL.EFI

The menu item Edit Keys opens a submenu that lets you modify the PK, KEK, db, dbx, and MOK list certificate stores as follows:

• MOK list – Remove any existing certificates and hashes.
• db – Remove any existing certificates and hashes; add the Microsoft Windows Production PCA 2011 certificate. Add your own certificate for signing UEFI applications. Alternatively, you can add a hash of the bootloader.
• dbx – No changes necessary.
• KEK – Remove any existing certificates and hashes; add your own KEK certificate.
• PK – Add the certificate for your own platform keys.

Note that the modification of the PK certificate store must be the last step, in that adding a platform key quits Setup mode and changes to User mode. Subsequent manipulation of the certificate store is then only possible using signed updates or deleting the platform keys with UEFI Setup. After this step, you can launch Debian with Secure Boot enabled.

Conclusions

The UEFI implementations of the platforms we investigated faithfully kept to the Secure Boot specification – or at least to the extent we investigated in this article. The Microsoft Windows Production 2011 PCA certificate required by Microsoft as part of Windows Hardware Certification Program and the optional Microsoft Corporation UEFI CA 2011 certificate are provided by all the PC vendors we investigated. The UEFI CA 2011 certificate basically ensures the functionality of operating systems from vendors other than Microsoft with Secure Boot enabled.

Many current operating systems, such as Windows 8 Pro, Ubuntu 13.04, and Fedora 19 already provide support for Secure Boot. The actual security benefit, however differs strongly among the operation systems we investigated. The investigated operating systems that do not natively support Secure Boot  – more specifically, Debian 7.1.0 and Red Hat Enterprise Linux 6.4  – can be talked into running with Secure Boot enabled with very little effort on all investigated hardware platforms.

Secure Boot has the potential to protect a system against unauthorized tampering. Although a number of challenges exist and further measures are needed for complete protection, Secure Boot can still help the owner retain sovereignty over the IT system.

Another strength of Secure Boot is that the owner of the IT system can decide which specific protection measures they want to implement. Users can therefore create custom security solutions and optimize the overhead to security ratio.

One major disadvantage of Secure Boot is that you absolutely need UEFI. Developers currently have very little practical experience with security for UEFI-compatible firmware. Thus, there is a real risk that the potential safety benefits of Secure Boot will be compromised by (intentional or unintentional) implementation errors in the firmware. In particular, the flexible extensibility and the feature scope give manufacturers an easy option for implementing backdoors. Additionally, the success of any potential safety gain depends on the ability to integrate Secure Boot into the operating system. Although Secure Boot is freely configurable on all the platforms we investigated, future implementations might restrict this ability and bind devices to a vendor's software.