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.