![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59The 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
Date: 2012-08-16 05:57 pm (UTC)[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
Date: 2012-08-17 09:38 am (UTC)Good, but complicated
Date: 2012-08-16 06:32 pm (UTC)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
Date: 2012-08-16 06:39 pm (UTC)Re: Good, but complicated
Date: 2012-08-16 06:46 pm (UTC)But I wish Canonical would sign major players' code.
The anticipated unanticipated
Date: 2012-08-16 06:54 pm (UTC)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
Date: 2012-08-16 07:04 pm (UTC)Code signing for anyone - it just does not make sense
Date: 2012-08-16 07:39 pm (UTC)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
Date: 2012-08-26 12:08 am (UTC)The WinQual requirements state you must be a company. So, first you must form a company, handing over all sorts of details to your government so they can determine that, yes, you really are you.
Next, you need a Class 2 verified certificate from Verisign, so you're essentially handing copies of your passport and driving license to them, plus the company's registration documents.
As Verisign are administering this service, I'd be very surprised if they hadn't agreements with numerous world governments which they can use to verify the authenticity of these documents; and validating company registration documents isn't difficult
So, you're going to give Verisign a picture of your passport and driving license and registration documents for this company, and then you're going to give Microsoft the same.
And then you're going to sign contracts saying that you're not going to do nefarious things, probably with large financial penalties, then do nefarious things?
Nothing's perfect, but this goes a long way.
Re: Code signing for anyone - it just does not make sense
Date: 2012-08-26 11:46 am (UTC)There will be a market of signed loaders, with the person whose code was submitted either non-existing or not knowing anything about it.
Ok, maybe you have ruled out to some extent (literally) "non-existing", I agree that there are obstacles. The second possibility may be weaker in chain: it is enough to compromise a signing system in any way just as systems are compromised nowadays, including but not limited to "I do not know who used my system to sign this" being a fake statement, which is really hard to prove. It does not take a lot of money to register a SomeName Ltd., use that for credentials and go bankrupt. Are you certain that in all countries this scheme will swiftly end in criminal prosecution? The TCO is not much higher than the fee for WinQual.
At best the thing will slighty modify the dynamics. If a system gets hacked using such loader one can assume they have not been hacked by kids but by more serious guys - what a consolation.
I am not arguing that this is not an obstacle - I just don't buy any marketing hype that this is cryptographically secure when it is not, and it is not because almost anyone can have a loader with a genuine signature (genuine is the right word here, right?).
Signing the firmware
Date: 2012-08-16 09:57 pm (UTC)Re: Signing the firmware
Date: 2012-08-16 10:48 pm (UTC)Re: Signing the firmware
Date: 2012-08-17 12:21 am (UTC)Then I wonder about how such a check can possibly be implemented. As far as I can tell, there is no standard way for a computer to request a device to send its firmware, and no enforceable way to prevent a card responding with something other than its true firmware.
Re: Signing the firmware
Date: 2012-08-17 12:26 am (UTC)Or you can ...
Date: 2012-08-17 03:33 am (UTC)Here's the link
Date: 2012-08-17 03:34 am (UTC)Re: Here's the link
Date: 2012-08-19 02:25 am (UTC)