| |||||||||||||
Garrett: UEFI Secure boot in Fedora: status updateGarrett: UEFI Secure boot in Fedora: status updatePosted Sep 6, 2012 4:18 UTC (Thu) by theophrastus (guest, #80847)Parent article: Garrett: UEFI Secure boot in Fedora: status update
I still wish one of you kindly experts would concoct a block diagram ("comic-book") description of the functional blocks involved in the exchange of information/keys that is expected to normally happen during a "UEFI Secure Boot" process.
Even "Alice and Bob" (http://en.wikipedia.org/wiki/Alice_and_Bob) would be sufficient. For instance, it's the case that under this system all kernel compiles have to be signed by a "Peggy", "Victor", "Trent" or "Walter"? in this case Red Hat Inc?
(Log in to post comments)
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 8:15 UTC (Thu) by ledow (guest, #11753) [Link]
I believe it's something like:
Shim (signed by a key known to the PC's BIOS)
The idea being that the shim is the only thing needing "approval" by an outside process (UEFI) and never changes, and the bootloader can be one of multiple bootloaders (GRUB, LILO or whatever can support UEFI), and the bootloader can (optionally, I believe) verify the integrity of the kernel and decide whether to continue booting or not.
So users of the original distro to sign code will be able to replace the kernel with whatever they want (in theory) so long as they configure the bootloader to approve it. They can also choose any of the "approved" bootloaders.
Users of other distros can "borrow" the shim and (depending on how it's designed) boot their own bootloaders, or boot the verified bootloaders from the original distro which can then boot any kernel (maybe even signed, I think, but just not signed by the original distro).
It's all a bit of a mess, to be honest, and doesn't really stop any of the problems experienced in daily life (just how often is your kernel compromised on BOOT compared to anything else? And why did you not just enable BIOS boot-sector protection with a verified-clean bootloader that could do kernel verification for you?) while providing perfect incentive to lock devices down to supplied-kernels that can never, ever be changed (smartphones, set-top boxes, etc.).
Notice that the only part that needs outside approval is the shim loader (and how they go about verifying that no-one can use that shim to boot other things or subvert another operating system by booting into malware is an interesting question about their whole approval process) which is also the only key that needs to be in the PC BIOS (and that's contentious in itself because surely it's up to the manufacturer what keys they use and also how do you update old machines with new keys? And if you can just add-a-key to the BIOS - which is the standard line about "retaining control" on your PC - why do we need the approval process at all when we could all just enter the relevant key into the BIOS for the OS we want to use?)
Everywhere else is signed by something known to the shim (which *SHOULD* allow you to sign anything you like and store the key into the shim somewhere), or something known to the bootloader (which *SHOULD* allow you to sign anything you like and store the key into the bootloader somewhere).
It's a huge, big, complicated muddle to do something that I've never considered in a problem in thousands of deployed desktops, hundreds of servers and dozens of personal machines but that create ENORMOUS problems when it comes to me buying new hardware, booting the OS of my choice, and preventing monopolistic actions by large corporations.
We will see just how many companies ship with the Red Hat key in their BIOS or options to add it / disable signed booting. Until then, no sensible person can really touch that hardware.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 9:54 UTC (Thu) by njwhite (subscriber, #51848) [Link]
Thanks for that explanation, it was very helpful.
> And if you can just add-a-key to the BIOS - which is the standard line about "retaining control" on your PC - why do we need the approval process at all when we could all just enter the relevant key into the BIOS for the OS we want to use?
So we can give a Fedora CD to somebody who doesn't know what a BIOS is, and installing it will Just Work.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 15:39 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
It should, yes. That's one of the primary reasons we are jumping through all these hoops.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 12:56 UTC (Thu) by pbonzini (subscriber, #60935) [Link]
> which is also the only key that needs to be in the PC BIOS (and that's contentious in itself because surely it's up to the manufacturer what keys they use and also how do you update old machines with new keys?
You don't need the shim key in the PC BIOS.
You need the shim to be signed with a key, whose public part is in the PC BIOS. Microsoft runs a signing program which will roughly use the same key used to sign Windows (i.e. you're pretty much sure that the key is in the PC BIOS).
> Everywhere else is signed by something known to the shim (which *SHOULD* allow you to sign anything you like and store the key into the shim somewhere),
It won't allow you, unless you have the shim's private key to do this. Modifying the private key requires one of: 1) asking (paying) Microsoft to sign the new shim; 2) adding your own key to the BIOS, and using it to sign the shim; 3) disabling secure boot altogether.
You cannot use Fedora's shim to run something not signed by Fedora.
> or something known to the bootloader (which *SHOULD* allow you to sign anything you like and store the key into the bootloader somewhere).
Similarly, you will have to sign the new kernel with the bootloader's private key, and you may not have it.
(Actually, to make it more complicated, they will probably provide a mechanism to add keys to the shim. However, it will not be possible for _the kernel_ to do that, so you cannot subvert the chain of trust just by exploiting the kernel. So the kernel can replace the shim/bootloader/kernel, but only with new components whose keys are already trusted).
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 17:14 UTC (Thu) by iabervon (subscriber, #722) [Link]
I believe you're describing how people originally thought it would work. But SuSE's clever idea is that the shim has a method for adding new keys to it; it's kind of like how the BIOS is supposed to allow adding keys, but distros know what the shims UI is like, whereas the BIOS method is probably in some poorly-named menu that's different on every motherboard. It turns out the UEFI has some storage for keys that the shim can write to but nothing later can affect, which means that the shim can trust this storage to only contain what it put in there and not keys that were installed by a rootkit. And the shim manages the keys in accordance with the machine owner's instructions, trusting whatever the machine owner says to trust (and only at boot time, before any code other than the shim has run).
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:33 UTC (Thu) by dashesy (subscriber, #74652) [Link]
Thanks for the nice explanation, I was wondering how SuSE's shim is going to save the keys, now it is more clear. Do you know if this safe place is mandatory for all UEFI implementations?
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 23:41 UTC (Thu) by iabervon (subscriber, #722) [Link]
I believe it is, at least for implementations that support Secure Boot. Of course, I don't know if Microsoft or Apple will use them in their boot code, or if Windows or OS X will try to access them post-boot and freak out if that works, so it's possible that it'll be the sort of mandatory feature that doesn't actually work in practice.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 14:30 UTC (Thu) by JEFFREY (subscriber, #79095) [Link]
Thank you for explaining this...
I'll be turning "Secure Boot" off in my UEFI/BIOS settings.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 6, 2012 15:19 UTC (Thu) by theophrastus (guest, #80847) [Link]
Hear hear. and also, Thank you to ledow for the explanation! It helps.
though if anyone wants to make a video involving finger puppets labeled "BIOS", "Bootloader", "Kernel", "Nebulous Signing Authority", and "Feckless User", (handing off to each other a magical onion named "shim"), i would buy 'em a beer.
Garrett: UEFI Secure boot in Fedora: status update Posted Sep 10, 2012 20:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> just how often is your kernel compromised on BOOT compared to anything else
As anti-malware and OS security gets better malware is forced deeper into the system. There are already demonstrations of compromising the kernel, boot loader and firmware. Like the Blue Pill reference below it is technically possible to make malware in the lower layers that is undetectable by the higher layers.
> And why did you not just enable BIOS boot-sector protection with a verified-clean bootloader that could do kernel verification for you?
Isn't that a fair description of what Secure Boot accomplishes? All the crypto and key verification are just to make the scheme difficult to subvert, a naive implementation without the crypto could be undetectably subverted.
> It's a huge, big, complicated muddle to do something that I've never considered in a problem
That doesn't mean that there isn't a problem or that this isn't a reasonable solution. This is about trying to fix a whole class of security problem while there still are only a few bits of malware that rely on it. The funny thing about malware, including US-built cyber-weapons, is that as different techniques get discovered entire classes of security problems are detected and anti-malware gets far more sophisticated preventing any of those techniques from being used a second time.
|
|||||||||||||