UEFI and "secure boot"

By Jake Edge

Hardware-based secure boot mechanisms are clearly useful for some users. By determining that firmware, bootloaders, and operating systems are not compromised, these mechanisms can protect systems against rootkits and other low-level attacks. Typically, the way that is done is by cryptographically signing the binaries in question such that they can be verified before being run. But disallowing unsigned binaries from running has a potentially problematic side effect: booting free operating systems becomes difficult or, in the worst case, impossible. It all depends on who holds the signing keys.

The Linux kernel has the integrity measurement architecture (IMA) and the proposed extended verification module (EVM) which could be combined with system hardware—such as the Trusted Platform Module (TPM)—to provide a secure boot environment. There have been concerns about these mechanisms as they can be used for both good and ill: either preventing rootkits and other tampering or preventing users from running code of their choice on their hardware. The unified extensible firmware interface (UEFI) specification has recently added some features that could be used similarly, leading to many of the same concerns. But there is also an additional wrinkle for systems that use the GRUB 2 bootloader.

UEFI is a relatively new standard for firmware that provides the boot environment for computer systems. For x86-64 systems (there are no plans to put UEFI in 32-bit x86 systems), it is aimed at replacing the 20+ year-old BIOS interface that is used to boot systems today. While BIOS is x86-specific, UEFI aims to be cross-architecture, and various vendors of ARM-based systems—Apple is rumored to be among them—have started adopting it. The UEFI 2.3.1 specification [agreement required] has a number of new features, one of which is the optional "secure boot" protocol. So far, UEFI 2.3.1 is not being shipped by any vendor and is only available on evaluation boards, but that will change in time.

The basic idea behind secure boot is to sign executables using a public-key cryptography scheme (RSA with 2048-bit keys with SHA-1 or SHA-256 as the hash). The public part of a "platform key" (PK) can be stored in the firmware for use as a root key. Additional "key exchange keys" (KEKs) can also have their public portion stored in the firmware in what is called the "signature database". That database contains public keys that can be used to verify different components that might be used by UEFI (e.g. drivers) as well as bootloaders, and operating systems that get loaded from external sources (disks, USB devices, network, and so on). The signature database will also contain "forbidden" signatures which correspond to a revocation list of previously valid keys. The signature database is meant to contain the current list of authorized and forbidden keys as determined by the UEFI organization.

Before a PK is loaded into the firmware, UEFI is considered to be in "setup" mode, which allows anyone to write a PK to the firmware. Writing the PK switches the firmware into "user" mode. Once in user mode, PKs and KEKs can only be written if they are signed using the private portion of the PK, though KEKs can be freely written during setup mode. Essentially, the PK is meant to authenticate the platform "owner", while the KEKs are used to authenticate other components, like operating systems.

All of this presents some problems for free software. If device makers create PKs and KEKs for the devices before shipping them to users, and do not provide the private portion of the keys, only entities listed in the signature database will be able to sign bootloaders and OSes. That is a fairly secure option for the device maker, but makes it difficult for those who might want to choose what code gets run on their hardware.

Secure boot is optional, but there is likely to be a fair amount of pressure applied by proprietary OS makers to enable it. One could imagine that those vendors might also provide a way to turn off secure boot (from a BIOS-like menu for example), but that is something that might be exploited by rootkits and other malware, so there may well be resistance to allowing that kind of option. Protecting users from rootkits and the like is certainly useful, but there is a competitive advantage as well. Hardware vendors can ensure that only the code they approve can run on the hardware, and proprietary OS vendors will be largely unaffected because their keys will be in the signature database. One would hope that the protection against malware is the primary motivation, but the ability to lock out free OSes is likely seen as a plus.

It is Linux and other free systems that could suffer most from secure boot implementations. While it would be possible for various distributions to get their keys added, that wouldn't help anyone who wanted to run a tweaked version of the "approved" bootloader or kernel. Distributors would not be able to release their private keys to allow folks to sign their own binaries either. Each key is just as valid as any other, so malware authors would just pick up those keys to sign their wares. Exposed keys would also find their way onto the forbidden list rather quickly one suspects.

But there is another potential pitfall here. The GRUB 2 bootloader, which is finding its way into some distributions, is licensed under GPLv3. One of the attributes of GPLv3 (the so-called "anti-Tivo-ization" language) requires that any keys needed to "install and execute modified versions of a covered work" must be disclosed just like the source code. So, any distribution that wanted to get a key and keep it private so that their systems will boot on locked-down hardware will not be able to do so if it uses GRUB 2.

Platform vendors are likely to use a key from UEFI as the PK, and distribute updated signature databases from the organization signed by that key. While any KEK that gets compromised will be added to the forbidden list, updating the firmware will presumably be optional so that existing hardware will still boot from code signed by compromised keys; newer hardware would get the updated forbidden list. But it would certainly be possible for an OS to "phone home" for the most recent signature database and refuse to run until the database in the firmware is current. That could be seen as reasonable protection (against malware signed by the compromised key) but would also be a fairly effective anti-jailbreaking feature.

It will be important for free software OSes (Linux distributions, the BSDs, etc.) and users to ensure that hardware vendors are aware of their needs here. Microsoft and Apple have no interest in enabling anything other than their own code to boot and run on tomorrow's hardware, and it wouldn't bother them at all to see free software get left out in the cold. In the consumer device space, it is certain that some vendors will take the opportunity to lock down their devices using UEFI, but in the server space, Linux has such a presence that one would guess some kind of solution (perhaps just an "off" switch) will be found. Desktop computers, on the other hand, are dominated by Microsoft (and to a lesser extent Apple), so our leverage there may be insufficient. If we don't keep an eye on it, your next desktop may simply refuse to boot your OS of choice.