Ubuntu ODM UEFI requirements for secure boot

[mjg59]

Updated 22/06/2012: Reference to Canonical's response

A couple of people have asked me about the Ubuntu ODM UEFI requirements, specifically the secure boot section. This is aimed at hardware vendors who explicitly want to support Ubuntu, so it's not necessarily the approach Canonical will be taking for installing Ubuntu on average consumer hardware. But it's still worth looking at.

In a nutshell, the requirements for secure boot are:

• The system must have an Ubuntu key preinstalled in each of KEK and db
• It must be possible to disable secure boot
• It must be possible for the end user to reconfigure keys

It's basically the same set of requirements as Microsoft have, except with an Ubuntu key instead of a Microsoft one.

The significant difference between the Ubuntu approach and the Microsoft approach is that there's no indication that Canonical will be offering any kind of signing service. A system carrying only the Ubuntu signing key will conform to these requirements and may be certified by Canonical, but will not boot any OS other than Ubuntu unless the user disables secure boot or imports their own key database. That is, a certified Ubuntu system may be more locked down than a certified Windows 8 system.

(Practically speaking this probably isn't an issue for desktops, because you'll need to carry the Microsoft key in order to validate drivers on any PCI cards. But laptops are unlikely to run external option ROMs, so mobile hardware would be viable with only the Ubuntu key)

There's two obvious solutions for this:

1. Canonical could offer a signing service. Expensive and awkward, but obviously achievable. However, this isn't a great solution. The Authenticode format used for secure boot signing only permits a single signature. Anything signed with the Ubuntu key cannot also be signed with any other key. So if, say, Fedora wanted to install on these systems without disabling secure boot first, you'd need to have two sets of install media - one signed with the Ubuntu key for Ubuntu hardware, one signed with the Microsoft key for Windows hardware.
2. Require that ODMs include the Microsoft key as well as the Ubuntu key. This maintains compatibility with other operating systems.

This kind of problem is why we didn't argue for a Fedora-specific signing key. While it would have avoided a dependence on Microsoft, it would have created an entirely different kind of vendor lock-in.

Update: Canonical have now provided their full plans. They won't be providing a signing service, but will be requiring that all Ubuntu-certified hardware ship with the Microsoft key

Comments

Different ways

[(Anonymous)]

I wonder who and when will start reconsidering.

Wish them good luck...

[misc.id.fedoraproject.org]

When I see the discussion on fedora-devel for just using a certificate signed by Microsoft, i can only imagine the discussions that will erupt on their lists for that.

And for system76 ?

[misc.id.fedoraproject.org]

System76 have said not support by default secureboot. Yet, they sell Ubuntu pre installed. So they will never be able to become certified system ?

However, after reading 3 times, I do not see where this is written that secureboot must be enabled by default. Did I missed something ?

[(Anonymous)]

Well, this is a hilarious logical conclusion of the existence of secure boot ..

It is a no-win situation

[alanbell [launchpad.net]]

This is one of several solutions competing to be the least-worst option. I truely can understand why Canonical don't want their OEM pre-installed systems to be signed with a Microsoft key, or to compel OEMs to carry the Microsoft key (I think it is still an option for the OEMs to do so and I am fairly certain they will unless Microsoft prevent them). Depending on what Canonical do for the regular aftermarket CD this might make it equally tricky to install an Ubuntu CD on these computers as it would be for any other distribution.

Every option sucks.

[hub]

"Canonical could offer a signing service."

Thawte anyone?

Disabling secureboot

[(Anonymous)]

If you disable secureboot, do you have basically the situation you have now (the ability to boot practically any x86 OS)?

That sounds like a very simple solution to me. What are the disadvantages of asking users to disable secure boot when they want to install a different OS?

Isn't there a key difference from Microsoft's requirements?

[(Anonymous)]

It must be possible for the end user to reconfigure keys

As I understand this issue, Microsoft rather coyly does not in fact include this (ie. a requirement that the user (owner) be able to manage Secure Boot keys in their UEFI) in the Windows certification requirements -- which is the substantial basis for it being an issue in the first place.

If the user can reliably manage keys in the UEFI (or even just "reconfigure" "a" key, which would be less satisfactory but not really horribly broken), then doesn't the fundamental problem go away?

Ubuntu wouldn't need to supply a signing service, because users could sign their own software (or maybe even use some key supplied by some other particular distro -- even one from Fedora or Red Hat).

Of course, Microsoft is already insisting that Windows-certified ARM hardware shall not permit key management or even disabling Secure Boot.

B. Swiss

[gerald_duck]

Would it not make sense for there to be open, neutral code signing bodies? Maybe two or three of the CAs would like to do it.

Being cynical, Microsoft has no incentive to do that, and the hardware vendors have little incentive to do anything beyond what Microsoft wants. Possibly the EU will in due course insist on something happening to avoid this constituting an anti-competitive practice?

No worries, it will all work out

[(Anonymous)]

I follow the lead of Linux on this topic: no need to worry too much, it will all magically fix itself if we close our eyes and wish it.

One thought...

[(Anonymous)]

Well, on the less evil side, one thing Canonical has over Microsoft in this case is that one can be pretty sure that Canonical is never going to change the x86/x64 requirements to be like Microsoft's WRT ARM hardware.

I certainly have a dreadful feeling that at some point in time Microsoft will attempt to require the evil restrictions they impose on ARM for future x86/x64 Windows certification (no disabling secure boot, no changing keys).

The more OEMs who include Canonical's (and other free OS people's) key, the better it will be for the lot of us in the future.