"Why not just use Coreboot?"

[mjg59]

Why not just avoid the entire Secure Boot problem by using Coreboot? Because the reason we have the Secure Boot problem is because Microsoft's Windows 8 certification requirements mean vendors have to ship a UEFI implementation with Secure Boot. You could satisfy that by using Coreboot with a Tiano payload, but it'll still have Secure Boot enabled so you still have the same set of problems. But maybe you could just reflash your system with Coreboot? No, because another part of the requirements states that all firmware updates have to be cryptographically signed now. The only way to reflash will be to attach a flash programmer directly to your motherboard.

So why not just use Coreboot? Because it doesn't help solve this problem in any way.

Comments

UEFI key management application

[ayers [launchpad.net]]

Clearly having a key signed by any unrelated software vendor is an unfortunate workaround to this issue. Putting all the bashing aside, what would the ideal solution look like? How can the situation be fixed... now or in the future?

Let's assume, that users want to insure that their boot sequence has been verified and signed by the trusted vendor of their choice, yet still keep themselves in control to override the upstream signatures. How should that be set up?

There could be some centrally maintained list of 'root' keys that each hardware vendor imports as the default list. The signing format must be updated to allow multiple signatures on binaries. That way, the user can choose which vendor keys to trust and distributions can decide to have there code signed by multiple vendors who choose to take responsibility for the security of the code. The UEFI implementation must provide a simple application to manage those keys. This simple applications must provide a consistent user experience over all UEFI implementations. It would probably be best to provide this simple application in the reference implementation. The management must allow the user to trust and distrust keys, to remove keys and to add keys from external media and to prioritize keys in a list to resolve potential conflicts of binaries whose signatures have been revoked by some vendors but not by others. There should probably also be an easy way to restore the default list. Yet there must be another application for the operating systems for every day users to generate there own key and install it on external media to add it to the UEFI key management, so that they can position their own key on top and override the vendor keys. It should also be trivial for the user to sign boot loaders, kernels, drivers they trust.

The major distributions could use a single organization like the Linux Foundation to manage a root key in the default list. Yet it would allow other distributions to distribute their own root key independently via their websites. The user would store them on external media to install them via the UEFI key management. This should allow the user to control the system while using secure boot to keep whatever integrity secure boot offers.

Re: UEFI key management application

[(Anonymous)]

Instead of the Linux Foundation, perhaps the organization could be CAcert? I would think it would be a matter of persuading the OEMs to include the CAcert root keys in the default list. CAcert is a non-profit certificate authority that uses a worldwide web-of-trust model to verify identities. You can sign up as a community member for free, have your identity verified by their assurers at no cost, and then sign all the distros you want.

Re: UEFI key management application

[mjg59]

CACert still haven't passed an external audit. It's also not just about identity verification - you need someone to handle revocation.