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.