I’ve written here a couple of times before about efforts to get PCs to boot more quickly, by speeding up the BIOS firmware, as well as guidelines to improve the security of the BIOS code and boot process. One effort that was expected to help in achieving these goals is the development of the Unified Extensible Firmware Interface [UEFI] specification, to improve on the BIOS specification first defined with the introduction of the IBM PC in 1982.
One of the features introduced in the UEFI specification is called Secure Boot; this provides that the machine will only boot using code signed with a trusted cryptographic signature; trusted signature(s) would be pre-configured into the UEFI subsystem. This, in itself, is unobjectionable, and is in line with the recommendations for BIOS security made by the NIST. However, as with so many security issues, the devil is in the details, and as implementation approaches, the devil has definitely appeared on the scene.
The issue revolves around Microsoft’s specified requirements for hardware to be “logo certified” compatible with its forthcoming OS version, Windows 8. Microsoft’s current statement is that new PCs, in order to receive their certification, must ship with Secure Boot enabled, and a Microsoft signing key installed. For PCs based on the traditional Intel x86 architecture, the statement also says that the user must be given a means by which Secure Boot can be disabled, so that any software, signed or not, can be installed locally. It also requires that there be a mechanism by which the user can add or replace trusted keys. (These capabilities are not required, however, for machines with ARM processors, which would include most tablets and smart phones.)
This has raised questions from those involved with free/open-source software (such as the Linux OS). It would mean that, for new x86 PCs with Windows 8 pre-installed, the user would have to bypass Secure Boot in order to install Linux, either to set up a dual-boot system, or to replace Windows entirely. And it might be impossible to do at all on an ARM-based system.
Two large suppliers of Linux distributions have taken steps to address the potential problem. Red Hat, which distributes Fedora Linux, has entered into an agreement with Microsoft and Verisign under which, in essence, Fedora’s first stage boot loader will be signed by Microsoft. Canonical Ltd, distributors of Ubuntu Linux, have taken a different approach. Ubuntu will have its own trusted key, which will be installed in firmware on “Ubuntu Certified” machines; in other cases, it can be installed by the user. (This does not address the problem of ARM-based machines.)
The Free Software Foundation [FSF] has published a white paper that discusses problems with Secure Boot in general, and also takes issue with both the Fedora and Ubuntu solutions. Their key objection, in both cases, is that the approaches require the user to trust Microsoft’s signature, in addition to any others that the user may add. Although I think it highly unlikely that Microsoft would use that trust to somehow “sabotage” machines with Linux installed, the FSF’s objection is certainly valid in principle.
The FSF has an additional beef with the Ubuntu solution, because in designing it Canonical has decided to switch from the GRUB 2 boot loader, licensed under the FSF’s GPLv3 license, to an Intel boot loader, efilinux, with a more permissive license. According to Canonical’s chief executive and founder, Mark Shuttleworth, the change was made because they worried that, if a manufacturer shipped a PC in which Secure Boot could not be disabled, Canonical might be forced, under the terms of the GPLv3 license, to disclose its private signing key. The FSF argues that it was not consulted about this, and would not take such a step in any case. Shuttleworth says that Canonical did receive legal advice.
The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up. As nice as it is that someone at the FSF says they would not, we have to plan for a world where leaders change and institutional priorities change. The FSF wrote a licence that would give them the rights to take specific actions, and it’s hard for them to argue they never would!
It is hard to know what to make of the FSF’s argument; the SFLC is the Software Freedom Law Center, headed by Professor Eben Moglen of Columbia University Law School, former general counsel of the FSF, who was directly involved in drafting the GPLv3 license.
My own reaction to all this is that, if Microsoft sticks to its current statements, the situation with x86 machines, requiring the user to bypass Secure Boot or install additional trusted keys in order to install Linux or other alternative software, is a nuisance, but a bearable one. I am much more concerned about the situation with ARM machines; one of the great virtues of the PC environment is that it is open, and that users can control the machines they own. If you have an Apple iPad, you cannot use any software that does not have’s Apple’s imprimatur. I am not surprised that Microsoft would like to move in that direction, but I can see no reason for users to accept that.