Linux: What is Secure Boot?

At its start a computer runs a specific program to detect and initialize its hardware components. Traditionally, IBM-compatible PCs use the Basic Input Output System (BIOS). In contrast Macs use OpenFirmware, Android has a boot loader, only, and a Raspberry Pi starts from a firmware kept in the System on a chip (SoC). This initial step includes hardware checks as well as searching for available operating systems on storage media that are part of the computer like a hard disk, CDROM/DVD, or an SD card, or connected to it via network (Network File System (NFS), PXE Boot).

The actual search order depends on the BIOS settings of the computer. Figure 2 shows a list of available devices to boot from.

At the end a list of available operating systems with specific parameters (called “available boot options”) is displayed in a menu from which you choose the desired operating system to start.

Since 2012 Secure Boot is in use. This article will explain what it is, what is the intention behind it, and how it works. Furthermore, we will answer the question if Secure Boot is needed for Linux-only-based machines, and how Linux distributions handle this case.

What is Secure Boot?

Secure Boot is about trust. The general idea behind it is starting the machine in a safe way in order to prevent the computer from running with malware right from the beginning. In general, a clean start with a reliable system is an approach to be strongly supported.

Secure Boot is part of the Unified Extensible Firmware Interface (UEFI) —  a central interface between the firmware, the individual components of the computer and the operating system [3]. For a period of about five years it was developed by Intel and Microsoft as a replacement for the BIOS. In 2012, version 2.3.1 of UEFI was introduced with Microsoft Windows 8. Microsoft made it compulsory for computer manufactures to implement UEFI if they would want to obtain a Windows 8 certification for their newly build machines [15].

But why is Secure Boot called Secure Boot? What makes it a secure booting option? Secure Boot only allows booting from previously assigned bootloaders and therefore is intended to prevent malware or other unwanted programs from starting. A traditional BIOS would boot any software. It even would allow malware, such as a rootkit, to replace your boot loader. The rootkit would then be able to load your operating system and stay completely invisible and undetectable on your system. Whereas with Secure Boot the system firmware first checks if the system boot loader is signed with a cryptographic key. The cryptographic key is a key that has been authorized by a database contained in the firmware. Only if the key is recognized it will allow the system to boot. Such a valid signature has to follow a specification by the Microsoft UEFI Certificate Authority (CA).

Different Perspectives

At first sight this sounds quite good, but there are always two sides of a coin. As usual advantages and disadvantages coexist. Press reviews either praise or demonize Secure Boot depending on who is writing the review.

First, keep in mind that the authority over the cryptographic keys is in the hands of a single global player — Microsoft. To give power to millions of machines to a single company is never a good idea. That way Microsoft secures itself complete control of your machine. With a single decision Microsoft is able to block the entire market with a single stroke and to bar both its competitors and you as a customer. E.g. if you would want to install hardware from a different manufacturer at a later stage, you would need to ensure that the key of the new component has been stored in the database system. Leaving you with restricted flexibility and choices — especially if you are a developer.

Second, not only are your hardware choices restricted but also the choices of your operating system is intended to be limited due to UEFI technology introduced by Windows. This means it is making life difficult for the Linux community. Before its usage on UEFI-based hardware, Linux boot loaders like GRUB have first to be certified and therefore it slows down rather quick developments as the Open Source community is known for. Nobody knows what happens if the central validator makes a mistake during the validation or blocks the release of an updated software.

Third, what does the term malware mean today and tomorrow? Does it include operating systems from competitors [5] or are they excluded? The validation process runs behind the curtains and nobody can prove it.

Fourth, there are reservations regarding security. According to current developments the length of the cryptographic keys is relatively short. Secure Boot only allows X509 certificates and RSA keys with a fixed length of 2048 bits [16]. In the near future, with the usage of mass parallelization and further computing power based on virtualization, this level of security is expected to be broken. Today, cryptographic keys with a length of 4096 bits are recommended.

Fifth, it looks like as if software, that is both offered by a big vendor and certified is safe and without errors. As history shows we all know this is not true, software always contains bugs. A certification just lulls you into false sense of security.

Solutions for Open Source

But where there is a problem, there is a solution as well. Microsoft generously offers the opportunity for Linux distributors to access their Microsoft Sysdev portal in order to have their boot loaders signed [17]. This service nevertheless comes with a price tag.

Linux distributions only have a “shim” [11] signed at the Microsoft portal. The shim is a small boot loader which boots the Linux distributions main GRUB boot loader. Microsoft only checks the signed shim and thereafter your Linux distribution boots normally. This helps to maintain the Linux system as usual.

As reported from various sources, (U)EFI works fine with Fedora/RedHat, Ubuntu, Arch Linux and Linux Mint. For Debian GNU/Linux there is no official support regarding Secure Boot [9]. Anyway, there is an interesting blog post on how to set this up [18] , as well as a description in the Debian Wiki [14].

Alternatives to UEFI

UEFI is not the only successor of the PC BIOS — there are alternatives. You may have a closer look at OpenBIOS [4], libreboot [7], Open Firmware [8,9], and coreboot [10]. For this article we did not test them but it is helpful to know that alternative implementations exist and are working smoothly.

Conclusion

As mentioned before the key question is trust. With respect to computers ask yourself which parts of your system do you trust — the hardware components (firmware, chips, TPM), and/or the software components (boot loader, operating system, software that is in use). You can not debug the entire system. It may help to know that your operating system does not work against your interests and that you get the things done for which you have bought the system for — in a safe way without being controlled by a monopolist.

Links and References

• [1] Kristian Kißling: Debian 9 Stretch ohne Secure Boot, Linux-Magazin
• [2] UEFI Nachbearbeitung
• [3] EFI and Linux: the future is here, and it’s awful – Matthew Garrett
• [4] OpenBIOS, https://openbios.info/Welcome_to_OpenBIOS
• [5] Hendrik Schwartke, Ralf Spenneberg: Einlaßkontrolle. UEFI-Secure-Boot und alternative Betriebssysteme, ADMIN-Magzin 03/2014
• [6] Bootvorgang eines Apple Mac
• [7] Libreboot, https://libreboot.org/
• [8] Open Firmware (Wikipedia)
• [9] Open Firmware, https://github.com/openbios
• [10] Coreboot, https://www.coreboot.org/Welcome_to_coreboot
• [11] SHIM (Github), https://github.com/rhboot/shim
• [12] Thorsten Leemhuis: UEFI Secure Boot und Linux, FAQ
• [13] Bom Cromwell: How Does Linux Boot? Part 3: UEFI to Shim to the Next Link in the Chain
• [14] SecureBoot on Debian, https://wiki.debian.org/SecureBoot
• [15] Chris Hoffman: How Secure Boot Works on Windows 8 and 10, and What It Means for Linux
• [16] James Bottomley: The Meaning of all the UEFI Keys
• [17] Microsoft Hardware Developer Center, UEFI Firmware Signing
• [18] Secure Boot with Debian Testing

Acknowledgements

Frank Hofmann and  Mandy Neumeyer are co-authors of the article.  The authors would like to thank Justin Kelly for his help and critical comments while writing this article.