ARN

UEFI president: We need more key providers

UEFI Forum chief Mark Doran explains how UEFI works and addresses the criticisms around Microsoft's use of UEFI Secure Boot

Since its introduction, the Unified Extensible Firmware Interface has created a fair amount of controversy. UEFI was created through an industry consortium as an evolutionary step up from BIOS, the simple firmware long used when starting a computer to initialize all the components and load the operating system. Among its advanced features, UEFI includes an option called Secure Boot, which requires that any software used before the operating system starts, or after it shuts down, has been signed by a certificate authority.

For Windows 8, Microsoft required OEMs (original equipment manufacturers) to support Secure Boot in their machines. This immediately created a problem for other operating systems, most notably Linux-based ones, that many users routinely install on machines in place of Windows. Many viewed Microsoft's embrace of Secure Boot as anticompetitive behavior because it makes it more difficult for users to install other operating systems on a machine with Secure Boot enabled.

IDG News Service spoke with the UEFI Forum President Mark Doran, who is also an Intel senior principal engineer, about what UEFI does, how Secure Boot works, and the reaction that Microsoft has gotten from its use of UEFI.

IDGNS: What is UEFI? And how is it different from BIOS?

Doran: A BIOS initializes the machine components, and transfers control of the machine to the operating system. An implementation of the UEFI specification does the same thing. But with UEFI, we wanted to evolve the state of platform, and the firmware that supports it.

We wanted to decouple the development of the firmware from the operating system. So if we change the way the firmware is screwed together, it should be transparent to the operating system. And that has allowed us to go through and re-engineer all of the code that implements that pre-OS environment. As a result, operating systems have to do a whole lot less work to understand platform specifics that affect boot today than they would have had to do in previous generations.

In conventional BIOS you can't make assumptions about what the operating system does or doesn't know. It initializes everything in the platform, because the operating system might need it. In the UEFI spec, we ask the operating system to indicate -- through a persistent environment variable -- how to boot. Typically, operating systems do their own device initialization once they are run. So as a means to avoid duplication of work, in the pre-OS, all the platform touches is the set of devices it needs to boot.

IDGNS: What is the UEFISecure Boot option?

Doran: We're were trying to figure out a way to armor the platform against attack in that pre-OS space.

There have been a number of documented instances of people trying to introduce [code] that usurps control of the platform before the operating system gets in to run. The operating system thinks it is on a pristine platform, when in fact there is malware lurking between the platform and the operating system. It could be either persistent in the shape of a virtual machine living between the operating system and the hardware, or the malware could be a boot loader that introduces malware into the pre-OS space.

We wanted to figure out a way to make sure only code that can be trusted will run in that pre-OS space. With the motherboard ROM, you have to be careful about what gets updated there. And you have to make sure that any code that executes on the path between the reset vector and the entry point of the operating system loader is also trusted.

We're asking the add-in card [manufacturers] to sign the driver images with keys that the platform knows. So that when the operating system installer has indicated that it is using this card for a boot device, the platform can check the UEFI driver that lives on the card to see if it signed. You can have a reasonable amount of trust in that.

With UEFI, the platform stores a set of well-known public keys that it could use in a typical crypto signature check routine. So when an Option ROM [pre-OS code that can be called by the system's ROM to make an add-in card usable as a boot device] comes along, the platform can use the public key to compare against the signature that is on the driver.

In essence, the firmware carries the public key information for well-known keys. It is used to check an Option ROM each time the platform is run. Same thing for the loader. Once you get to the operating system, UEFI makes sure that control is being handed to the loader that the user intended, and not to a malware loader. Secure Boot gives you an assurance that the bag of bits you are about to run -- the Option ROM or the boot loader -- came from who it said it came from.

The idea is to have a platform that is more resistant to attack at all stages of its lifecycle. And that is what we are trying to achieve with Secure Boot. It gives the operating system a more solid foundation to start from.

IDGNS: If I'm an operating system provider, how do I get a signature to match one of the public keys in the firmware?

Doran: An operating system vendor can make a number of different choices as to how it wants to use the mechanism.

A platform could not do signature check at all, so it will not enable the Secure Boot feature. On the other end, it can only run trusted code between the operating system and the reset vector, making sure everything is installed by keys in the platform.

So if you have an operating system and you want to get the benefit of this pre-OS malware protection, you want to land on systems that are Secure Boot-enabled, and you want to make sure the keys used to sign code you want to run are on the platform.

There are two ways of doing that. Any operating system vendor can ask system manufacturers to pre-install its keys. You can also sign [your Option ROM] with a set of keys that will typically be present in most or all systems.

The UEFI Forum looked at the possibility of setting up a certificate authority and a portal that would allow us to hand out keys, but it turned out it would be a difficult and expensive proposition.

We've been looking around for existing certificate authority players to help us with that problem. To date, there is only one that has signed up. Microsoft agreed to put up one of these portals for all comers to sign images with a set of keys that are well-known, published and provided to system manufacturers. So most platforms going out the door at least have keys for Windows and for the Microsoft-run UEFI certificate authority.

It'd be nice to get at least one more certificate authority, so we'll have multiple sources. I've talked with a number of others.

The third option to get keys on a platform is to roll your own, so to speak. If you are a vertically integrated shop, and you are building your own platform, firmware and operating system, and you wanted to use our infrastructure, you could roll your own key, put that into your own firmware, and sign your own boot loader with it.

A developer for an open-source operating system can do the same thing. Get a platform that has the ability to install keys -- many of them do -- then become the platform owner by installing your own platform key and self-signing your own images. For ordinary users, the self-signing is probably a little too technically involved. But those skilled at the art of open-source operating systems might have no problem doing this.

IDGNS: Why can't the malware creators generate their own keys?

Doran: It takes a private key to generate the signature [public key]. We only put the public key in the firmware, so we don't arm the bad guys with the means to generate their own signatures. You have to go to the signature authority to get an image signed successfully.

Of course, most companies trade on their reputation, so if for some reason a bad actor inside one of those companies generates a signature and puts a product out the door that gets into the ecosystem, that would be very bad for the company. But it would be identified pretty quickly.

Part of the mechanism we define in the specification includes revocation. In the firmware there is a so-called white list, which is a collection of keys that represent signing authorities. And there is also a black list that has images that we know to be bad actors. So when the system [encounters] a bad image, it won't run it. And if malware gets out, we have a way to handle it pretty quickly, without significant updates to the firmware.

IDGNS: Microsoft has demanded the hardware partners use Secure Boot, and in doing so it has been accused of trying to lock out other operating systems in the market. Did you anticipate this problem?

Doran: I'm not surprised people are looking at this with a critical eye, but I think there is much smoke but not much fire.

If you read the requirements Microsoft published on what it takes to build a platform that is ready for Windows 8, it actually specifies that an end user must be able to turn off Secure Boot as a feature. The vast majority of general-purpose platforms that have Secure Boot have a way to disable that. And many have a way to install new keys. So when you get one of these things, you have a choice.

Joab Jackson covers enterprise software and general technology breaking news for The IDG News Service. Follow Joab on Twitter at @Joab_Jackson. Joab's e-mail address is Joab_Jackson@idg.com