There’s been some hubbub lately about Secure Boot, a hardware-verified, malware-free operating system bootstrap process that aims to improve the overall security of computers. Part of the UEFI specification which is slated to replace the aging BIOS with which many of us are familiar, Secure Boot can forbid the loading and execution of unsigned operating systems. Microsoft is requiring that Secure Boot be activated and enforced for any OEM systems that want to use the “Designed for Windows 8” logo. The nature of the technology, and Microsoft’s recommended implementation of it, could remove control of the overall system from the end user, and in this configuration Secure Boot may prevent Free Software operating systems from loading.
After some initial hysteria on Slashdot (where else?), calmer minds have prevailed, and have reviewed the UEFI Secure Boot specification in some detail. It’s a pretty marked change from the old BIOS: the use of public key cryptography makes the whole thing considerably more complex. But there’s nothing about Secure Boot, prima facie, that specifically locks out Free Software operating systems.
The Linux Foundation has released a paper titled “Making UEFI Secure Boot Work With Open Platforms” written by Technical Advisory Board members James Bottomley, CTO, Server Virtualization at Parallels and Jonathan Corbet, Editor at LWN.net. Concurrently, Bottomley has collaborated with Canonical’s Technical Architect, Jeremy Kerr, and Red Hat’s Senior Software Engineer, Matthew Garret, to develop another paper titled “UEFI Secure Boot Impact on Linux“.
The former document is a pretty high level analysis of the situation (only four pages), with some overall recommendations on how OEMs can ship hardware that will work with both proprietary and Free Software operating systems. The latter document is a little more technical (eight pages!), with some slightly more specific recommendations for OEMs.
The whole thing can be a little confusing if you’re not already familiar with some of the basics of public key cryptography. Platform Keys, Key Exchange Keys, signature databases. Is this all more trouble than it’s worth? I fired off a few questions to the Linux Foundation for clarification, and James Bottomley responded.
TechCrunch: First and foremost, what’s the real-world effect to end users? If SecureBoot is as complicated at the document makes me feel it is, won’t many people just decide to leave their systems in “Setup” mode and avoid the whole thing?
James Bottomley: Leaving the system in setup mode is equivalent to the current state (no secure boot). However, we know from the microsoft blog that Users who accept the Windows 8 preinstallation won’t be given the option and their systems will be locked down. The idea for users who wish to install open source is that they will be given the option of moving to the more secure user mode or remaining where they are. The point of shipping in setup mode is that handling the complexity of this choice becomes the job of the operating system install or ignition system, which we believe to be the best place for this. We anticipate that the problems potentially caused by first ship of secure boot will be resolved over time and the benefits of booting securely will outweigh the initial teething troubles.
TC: Propping up a full public key infrastructure is a great idea, but well beyond the technical prowess of many hardware manufacturers. It’s not their core competency, so who is to say they’ll do it right?
JB: It wouldn’t be done by the Hardware Manufacturers, and indeed given the security implications, it should be outsourced to an entity for whom it is a core competency. The current effect of the Microsoft Windows 8 logo proposals is that the OEMs are required to manage a list of key exchange keys, which is also not their core competency, so offloading key management to an entity whose core business it is should make the whole process less error prone.
TC: We know that Certificate Authorities are not beyond compromise, as the DigitNotar business has recently pointed out. If a security-lax hardware manufacturer gets compromised, what’s the result to end users?
JB: So this is a problem. The UEFI system contains a mechanism for revoking certificates (which is the same mechanism used in the internet to remedy the DigiNotar intrusion). However, a system which relied on a revoked key in the path of trust would refuse to boot and would either have to be switched out of secure mode or have its UFI updated to remedy the situation. However, such a compromise isn’t really any more likely (and is possibly less likely since it would be a core business interest of the CA) than an OEM key being compromised, so the problem is the same or less troublesome than the situation where there’s no CA.
The promise of “initial teething troubles” doesn’t sound particularly fun, but as with any new technology adoption it’s largely unavoidable. I do look forward to seeing Secure Boot prove successful.