Linux Foundation proposes to use UEFI to make PCs secure and free

UEFI, Secure Boot, and Freedom of choice

Microsoft's proposed use of Unfied Extensible Firmware Interface (UEFI) in Windows 8 could be used to block all other operating systems from Windows 8 systems. The Linux Foundation and partners have a better idea: Secure computers with UEFI and give users freedom of operating system choice.

In the Linux Foundation document, Making UEFI Secure Boot Work With Open Platforms (PDF Link), James Bottomley, CTO of Server Virtualization at Parallels and Linux Foundation Technical Advisory Board Chair Jonathan Corbet, Editor at LWN.net and fellow Linux Foundation Technical Advisory Board Member, after consulting with other Linux leaders, explain how "Linux and other open operating systems will be able to take advantage of secure boot if it is implemented properly in the hardware."

At the same time, Red Hat and Canonical, Ubuntu's parent company, have published UEFI Secure Boot Impact on Linux (PDF Link). This document presents a set of recommendations that will allow users the freedom to choose their software, while retaining the security features of UEFI Secure Boot, and complying with open source licenses used in distributions of Linux."

What's all this about? UEFI is the greatly improved, 21st century version of your PC's BIOS. Its job is initializing your PC's hardware and then handing hardware control over to your operating system. Microsoft plans to UEFI in Windows 8 certified systems to securely boot the system and avoid some malware. Good enough, but Winodws 8's UEFI-based secure boot could also be used to block other operating systems. In particular, Windows 8 clients must be certified with UEFI mod in a way that supports Windows 8's secure boot.

While some Microsoft fans claim that this isn't a problem and that "Linux fanatics want to make Windows 8 less secure," that's not the case. Linux developers see the advantages of UEFI secure boot protection. They just object to Microsoft's specific secure boot UEFI implementation proposals.

In the Linux Foundation document, Bottomley and Corbet explain that "'Secure boot' is a technology described by recent revisions of the UEFI specification; it offers the prospect of a hardware-verified, malware-free operating system bootstrap process that can improve the security of many system deployments. Linux and other open operating systems will be able to take advantage of secure boot if it is implemented properly in the hardware. This document is intended to describe how the UEFI secure boot specification can be implemented to interoperate well with open systems and to avoid adversely affecting the rights of the owners of those systems while providing compliance with proprietary software vendors' requirements."

To keep systems both secure and open, they propose operating system vendors and original equipment manufacturer should follow these recommendations:

• All platforms that enable UEFI secure boot should ship in setup mode where the owner has control over which platform key (PK) is installed. It should also be possible for the owner to return a system to setup mode in the future if needed.
• The initial bootstrap of an operating system should detect a platform in the setup mode,
• install its own key-exchange key (KEK), and install a platform key to enable secure boot.
• A firmware-based mechanism should be established to allow a platform owner to add new key-exchange keys to a system running in secure mode so that dual-boot systems can be set up.
• A firmware-based mechanism for easy booting of removable media.
• At some future time, an operating-system- and vendor-neutral certificate authority should be established to issue KEKs for third-party hardware and software vendors.

They then explain that this system could still work with Microsoft's Windows 8's plans. Since the UEFI secure boot system can be summarized in terms of a two-key system with "a PK, which is designed to be controlled by the Platform Owner (whoever owns the hardware) and a set of KEKs, which are designed to be controlled by the OEM and OS vendors. "Controlled" in this sense means that these keys are public/private key pairs; whoever knows the private key is the key controller, but to install the key, you only need the public piece, which means KEKs may be installed by anybody without controlling them."

Therefore, OEMs shipping Windows 8, or any other system, could ship the PC "with all the KEKs required to allow validation of the firmware and drivers installed in the signature database (section 27.6.1). The signature database will be inactive while the platform is in setup mode, but, once secure boot is activated, the firmware and all of the add in driver components must validate correctly for the platform to progress to boot the Operating System"

Then when you boot an a secure boot OS for the first time the system would detect that the platform is in setup mode and immediately switch the platform to the secure mode by installing a platform key after it has installed the KEK corresponding to the its own code." In the case of an open operating system this would "likely generate a new PK at first boot, install the public component and save the private component to external media for the user."

The Linux Foundation also points out that Microsoft's take on secure boot and UEFI, where a user puts all his or her trust into the Windows 8 system "runs counter to the UEFI recommendation that the platform owner be the PK controller and would ensure that the Windows operating system would then become the only bootable operating system on the platform." Nevertheless, the Linux Foundation doesn't want to turn this into a Windows-Linux fight.

Bottomley and Corbet state that if a user wants to let Microsoft lock them into Windows 8, "we must agree that it is a legitimate choice for an informed user to make voluntarily." In the Linux Foundation plan, OEMs and users can still do this. "It is enabled in our blueprint above by allowing the Microsoft OEM ignition system to install the OEM PK instead of generating a new PK specific to the installation. This can be achieved simply and securely because only the public half of the PK needs to be carried by the ignition system to affect this lockdown of the platform."

Red Hat and Canonical take a somewhat stronger view, but it's one that both Microsoft and OEMs should be able to live with. In addition to recommending hardware be shipped in setup mode. They recommend that:

• All OEMs allow secure boot to be easily disabled and enabled through a firmware configuration interface.
• All OEMs (with assistance from BIOS vendors) provide a standardized
• mechanism for configuring keys in system firmware.

While this addresses the initial problem of certified Windows 8 PCs operating system lock up, it still leaves what Bottomley and Corbet say, is one of the "few shortcomings in the UEFI model (and it is a deliberate omission because of the complexity of running a certification system) is that there's no designated root of trust in the current proposals."

Bottomley and Corbet would like to address this problem by using a trust certification system that UEFI already allows: "X.509 [an ITU-I and IETF public key infrastructure security system] certificates to be present in the signature database. The X.509 trust model, which is the one upon which web server and browser security certificates are based, allows signatures and signing keys to be traced back to a single root of trust. This would allow for one (or more) Certificate Authority keys to be placed in the UEFI signature database and would then allow the designated Certificate Authorities to issue both KEKs (and even signing keys that allow the production of KEKs) to third parties that would still validate back to the original CA root of trust. The UEFI specification (section 27.7.1) even allows for the revocation of KEKs should the original authorized user have lost control of them, which is all the necessary machinery you need to operate a fully functional CA."

So, the Linux Foundation proposes "that all the interested parties establish a Certificate Authority whose key should be placed in the UEFI firmware table by default; this authority would become responsible for handing out signed KEKs to UEFI device vendors (for their UEFI drivers), UEFI OEM platform vendors (for their firmware images) and OS vendors (for securely booting their OSs). The operation of such a CA would have to be platform- and OS-neutral and would have to adhere to the usual standards of trust and security (presumably by having a controlling board made up of representatives from the various parties), but it would solve a greater part of the driver and OS verification problem because anything signed with an un-revoked KEK traceable back to the CA root key would be automatically trusted by the UEFI firmware for secure boot."

This lack of a Certificate Authority isn't a problem just for smaller operating system vendors. OEMs are also concerned about the costs of Windows 8's proposed UEFI secure boot and its lack of a X.509 certificate.

Even if operating system vendors and OEMs can't come to an agreement on a certificate authority, that doesn't have to block independent operating systems from UEFI secure boot protected systems. Bottomley and Corbet point out that "The establishment of an independent certificate authority for the creation of KEKs would make interoperation easier, but is not necessary for these platforms to support open systems." Instead, "In the absence of the establishment of a trust model, we therefore recommend that non-verifying external media be booted with a simple firmware based present user permission check when the system is in user mode with secure boot enabled."

So in the end, the Linux Foundation and its allies conclude that "while some observers have expressed concerns that secure boot could be used to exclude open systems from the market … there is no need for things to be that way. If vendors ship their systems in the setup mode and provide a means to add new KEKs to the firmware, those systems will fully support open operating systems while maintaining compliance with the Windows 8 logo requirements." The ball is now in Microsoft's court.

Related Stories:

Windows 8 to increase PC production costs

Microsoft isn't the enemy when it comes to blocking Linux on Windows 8 PCs

Free Software Foundation urges OEMs to say no to mandatory Windows 8 UEFI cage

Microsoft to stop Linux, older Windows, from running on Windows 8 PCs

Microsoft: Don't blame us if Windows 8's secure boot requirement blocks Linux dual-boot

Image by opensourceway, CC 2.0.