| |||||||||||||
Garrett: UEFI Secure boot in Fedora: status updateGarrett: UEFI Secure boot in Fedora: status updatePosted Sep 6, 2012 12:56 UTC (Thu) by pbonzini (subscriber, #60935)In reply to: Garrett: UEFI Secure boot in Fedora: status update by ledow Parent article: Garrett: UEFI Secure boot in Fedora: status update
> 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).
(Log in to post comments)
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.
|
|||||||||||||