![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Building personal trust with UEFI Secure Boot
The biggest objection that most people have to UEFI Secure Boot as embodied in the Windows 8 certification requirements is the position of Microsoft as the root of trust. But we can go further than that - putting any third party in a position of trust means that there's the risk that your machine will end up trusting code that you don't want it to trust. Can we avoid that?
It turns out that the answer is yes, although perhaps a little more complicated than ideal. The Windows 8 certification requirements insist that (on x86, at least) the key databases be completely modifiable. That means you can delete all the keys provided by your manufacturer, including Microsoft's. However, as far as the spec is concerned, a system without keys is in what's called "Setup Mode", and in this state it'll boot anything - even if it doesn't have a signature.
So, we need to populate the key database. This isn't terribly difficult. James Bottomley has a suite of tools here, including support for generating keys and building an EFI binary that will enrol them into the key databases. So, now you have a bunch of keys and the public half of them is in your platform firmware. What next?
If you've got a system with plug-in graphics hardware, what happens next is that your system no longer has any graphics. The firmware-level drivers for any plug-in hardware also need to be signed, and won't run otherwise. That means no graphics in the firmware. If you're netbooting off a plug-in network card, or booting off a plug-in storage controller, you're going to have similar problems. This is the most awkward part of the entire process. The drivers are all signed with a Microsoft key, so you can't just enrol that without trusting everything else Microsoft have signed. There is a way around this, though. The typical way to use Secure Boot is to provide a list of trusted keys, but you can also provide trusted hashes. Doing this involves reading the device ROM, generating a SHA256 hash of it and then putting that hash in the key database.
This is, obviously, not very practical to do by hand. We intend to provide support for this in Fedora by providing a tool that gets run while the system is in setup mode, reads the ROMs, hashes them and enrols the hashes. We'll probably integrate that into the general key installation tool to make it a one-step procedure. The only remaining problem is that swapping your hardware or updating the firmware will take it back to a broken state, and sadly there's no good answer for that at the moment.
Once you've got a full set of enrolled keys and the hashes of any option ROMs, the only thing to do is to sign your bootloader and kernel. Peter Jones has written a tool to do that, and it's available here. It uses nss and so has support for using any signing hardware that nss supports, which means you can put your private key on a smartcard and sign things using that.
At that point, assuming your machine implements the spec properly everything that it boots will be code that you've explicitly trusted. But how do you know that your firmware is following the spec and hasn't been backdoored? That's tricky. There's a complete open implementation of UEFI here, but it doesn't include the platform setup code that you'd need to run it on any x86 hardware. In theory it'd be possible to run it on top of Coreboot, but right now that's not implemented. There is a complete port to the Beagleboard hardware, and there's instructions for using it here. The remaining issue is that you need a mechanism for securing access to the system flash, since if you can make arbitrary writes to it an attacker can just modify the key store. On x86 this is managed by the flash controller being switched into a mode where all writes have to be carried out from System Management Mode, and the code that runs there verifies that writes are correctly authenticated. I've no idea how you'd implement that on ARM.
There's still some work to be done in order to permit users to verify the entire stack, but Secure Boot does make it possible for the user to have much greater control over what their system runs. The freedom to make decisions about not only what your computer will run but also what it won't is an important one, and we're doing what we can to make sure that users have that freedom.
It turns out that the answer is yes, although perhaps a little more complicated than ideal. The Windows 8 certification requirements insist that (on x86, at least) the key databases be completely modifiable. That means you can delete all the keys provided by your manufacturer, including Microsoft's. However, as far as the spec is concerned, a system without keys is in what's called "Setup Mode", and in this state it'll boot anything - even if it doesn't have a signature.
So, we need to populate the key database. This isn't terribly difficult. James Bottomley has a suite of tools here, including support for generating keys and building an EFI binary that will enrol them into the key databases. So, now you have a bunch of keys and the public half of them is in your platform firmware. What next?
If you've got a system with plug-in graphics hardware, what happens next is that your system no longer has any graphics. The firmware-level drivers for any plug-in hardware also need to be signed, and won't run otherwise. That means no graphics in the firmware. If you're netbooting off a plug-in network card, or booting off a plug-in storage controller, you're going to have similar problems. This is the most awkward part of the entire process. The drivers are all signed with a Microsoft key, so you can't just enrol that without trusting everything else Microsoft have signed. There is a way around this, though. The typical way to use Secure Boot is to provide a list of trusted keys, but you can also provide trusted hashes. Doing this involves reading the device ROM, generating a SHA256 hash of it and then putting that hash in the key database.
This is, obviously, not very practical to do by hand. We intend to provide support for this in Fedora by providing a tool that gets run while the system is in setup mode, reads the ROMs, hashes them and enrols the hashes. We'll probably integrate that into the general key installation tool to make it a one-step procedure. The only remaining problem is that swapping your hardware or updating the firmware will take it back to a broken state, and sadly there's no good answer for that at the moment.
Once you've got a full set of enrolled keys and the hashes of any option ROMs, the only thing to do is to sign your bootloader and kernel. Peter Jones has written a tool to do that, and it's available here. It uses nss and so has support for using any signing hardware that nss supports, which means you can put your private key on a smartcard and sign things using that.
At that point, assuming your machine implements the spec properly everything that it boots will be code that you've explicitly trusted. But how do you know that your firmware is following the spec and hasn't been backdoored? That's tricky. There's a complete open implementation of UEFI here, but it doesn't include the platform setup code that you'd need to run it on any x86 hardware. In theory it'd be possible to run it on top of Coreboot, but right now that's not implemented. There is a complete port to the Beagleboard hardware, and there's instructions for using it here. The remaining issue is that you need a mechanism for securing access to the system flash, since if you can make arbitrary writes to it an attacker can just modify the key store. On x86 this is managed by the flash controller being switched into a mode where all writes have to be carried out from System Management Mode, and the code that runs there verifies that writes are correctly authenticated. I've no idea how you'd implement that on ARM.
There's still some work to be done in order to permit users to verify the entire stack, but Secure Boot does make it possible for the user to have much greater control over what their system runs. The freedom to make decisions about not only what your computer will run but also what it won't is an important one, and we're doing what we can to make sure that users have that freedom.
ARM TrustZone
(Anonymous) 2012-08-16 05:57 pm (UTC)(link)[misposted this to 16387.html, please delete the other one | also, your OpenID coupling seems to be giving problems with the captcha validation]
Re: ARM TrustZone
(Anonymous) - 2012-08-17 09:38 (UTC) - ExpandGood, but complicated
(Anonymous) 2012-08-16 06:32 pm (UTC)(link)be a PITA, just another administrative task in the best case and a real PITA if anything goes wrong, and it sometimes will.
Is there any slightest chance of buying hardware for Ubuntu (was it Ubuntu that made their own hardware requirements?) and somehow getting Fedora bootable by their keys? Not that it really sounds like a viable option for many reasons (like actually obtaining a needed hardware with the Ubuntu keys)
Re: Good, but complicated
Re: Good, but complicated
(Anonymous) - 2012-08-16 18:46 (UTC) - ExpandThe anticipated unanticipated
(Anonymous) 2012-08-16 06:54 pm (UTC)(link)Both the UEFI spec and Microsoft's hardware requirements look good on paper, but I already know some HP BIOSes, EFI ones, that did not quite implement the standard, or rather implemented some "additional features". That did make booting almost anything other than preinstalled problematic - there were workarounds for that, but anything short of wiping the whole drive for a fake container partition did not have a chance to boot. On laptops.
We'll see I guess.
Linux Foundation
(Anonymous) 2012-08-16 07:04 pm (UTC)(link)Code signing for anyone - it just does not make sense
(Anonymous) 2012-08-16 07:39 pm (UTC)(link)Microsoft will sing code for anyone. This cannot ever be secure. First, I don't buy the argument that they can track who signed it. There will be a market of signed loaders, with the person whose code was submitted either non-existing or not knowing anything about it.
So, Microsoft will blacklist them: when? When there is a known exploit? It seems a little late for a cryptographically "safe" feature. No one else has the list of keys that were signed. Maybe they will blacklist everything they sign except own - there are two problems with that. Space overflow in blacklists will limit the count of keys they can sign. Second: this would mean that the Fedora shim loader would be useless.
My point is that the signing service will either be insecure - also for Fedora - or will be limited or will be terminated. I now value what you just described for making own keys, otherwise the whole feature is pretty useless.
Re: Code signing for anyone - it just does not make sense
Re: Code signing for anyone - it just does not make sense
(Anonymous) - 2012-08-26 11:46 (UTC) - ExpandSigning the firmware
(Anonymous) 2012-08-16 09:57 pm (UTC)(link)Re: Signing the firmware
Re: Signing the firmware
(Anonymous) - 2012-08-17 00:21 (UTC) - ExpandRe: Signing the firmware
Or you can ...
(Anonymous) 2012-08-17 03:33 am (UTC)(link)Here's the link
(Anonymous) 2012-08-17 03:34 am (UTC)(link)Re: Here's the link
(Anonymous) - 2012-08-19 02:25 (UTC) - Expand