Platform boots
Let's now take a closer look at how Secure Boot works. It revolves around four things held in the motherboard's firmware: the Platform Key (PK), the Key Exchange Key (KEK), the signature database (db) and the revoked signatures database (dbx).
None of these are hard-coded on PCs, and they can be changed by a physically present user even if they don't know any of the existing keys (for instance, you have to reboot the system and enter setup, so it can't be done over SSH, VNC or any other remote protocol).
The Platform Key is the highest level key, and can be used to sign new KEKs. The Key Exchange Key comes at the next level. This can be used to sign new entries in the db and dbx. There can be more than one KEK stored by the motherboard. Db and dbx are the main pieces that do the work. Db contains public keys that are trusted by the system to sign code so it can run. Dbx, on the other hand, contains public keys that are explicitly not trusted (for example, ones that are known to be compromised).
By default, when you buy a Windows 8 certified computer, the PK will be the manufacturer's key. There will be one KEK, that is Microsoft's KEK, and there will be one entry in db which will be Microsoft's UEFI key. If you run Windows 8, the motherboard will check the Windows 8 kernel signature against the keys in db and dbx. It will find it matches with the entry in db, and there will be nothing in dbx, so it will allow it to boot.
A choice of three
So, how does Linux work? Well, there are a few options. A distribution could produce it's own KEK that users could manually load into their systems, and then sign all their kernels with that. They could even try and get manufacturers to sign their KEK with their PK, and so distribute it along with their installation media. However, the first of these is quite technical to do, and the latter requires a degree of influence few, if any, distributions have.
There is a third way. For a one-time fee of $99, Microsoft will sign bootable software - but there's a catch: the software must itself be what they describe as secure. That is, it must continue the chain of signatures and not allow untrusted code to take over the machine.
If it weren't for this catch, the Linux community could just get a boot loader signed, and then use that as freely as we currently use Grub. Of course, if it weren't for this catch, and a normal boot loader was signed, virus writers could use this signed boot loader to start their malware and it would defeat the point of secure boot.
The solution most commercially sponsored distros are going with at the moment is to use a shim boot loader. Ubuntu, Fedora and OpenSuse are all doing this. The shim boots before anything else, and does very little other than include an extra key that is specific to the distribution. This extra key can be used to sign a normal Linux bootloader (usually Grub 2), which in turn loads a signed Linux kernel, and the chain of trust is complete.
There are, however, a few problems with this. Firstly, it means that the user can't compile their own Kernels (since they can't sign it using the distribution's key). Secondly, it means that Microsoft could terminate the signature for the shim bootloader (that is, add it to dbx) at any point if they wanted to. Which could potentially leave you right in the lurch.
