I'm going to jump out of the woodwork to answer this one, because the solution is really obvious.
If secure boot were about securing your computer from third parties (e.g. malware, rootkits cough) installing unauthorized software, then the correct implementation would generate a private key on each machine at the time of 1st boot, used to sign all software before running. This would ensure that the only software that could run on a machine was specifically authorized by the user. In addition, there would be no worry with regards to leaked keys, because the risk of key exposure is a single machine.
Unfortunately, secure boot is not about preventing the spread of malware. It's about securing the computer from you, the owner. It's about DRM, and ensuring that the code running on a computer (e.g. Blu-Ray player) is controlled and trusted by a third-party, who is then able to dictate how certain information available to the machine is processed.
TCPA/TPM's measured/trusted boot gives you basically that.
The problem is users aren't able to tell if a given downloaded piece of code is safe or not, so there is a need for some kind of trusted code distribution system as well. Plus, once you trust a vendor, you probably trust most of their code, or at least most of the updates to specific packages, and may not want to audit it each time yourself.
Disk integrity (which your solution would provide) is necessary but not sufficient for secure computing.
I shudder at the thought of having to generate and store a crypto key for the lifetime of a machine in order to run it. This is why, btw, I've abandoned full-disk encryption: I once lost a key (in shambolic fashion), hence losing an entire disk.
A one-machine-one-key scheme is impractical for so many reasons, one of them being exactly that: onus is on the user to keep the key available but secret. People who blindly double-click on random .exe attachments would supply the key pronto as soon as any malware would ask for it. As all sysadmins know, securing a machine from its owner is often the right thing to do, and in that sense UEFI is not a bad thing.
Besides, if UEFI really becomes a staple of the Windows world, I can see enterprise/sme customers requiring a sanctioned way to add custom cert authorities, to which Microsoft won't be able to say no. Because taiwanese manufacturers like to reuse parts wherever possible, the feature will trickle down to the consumer market.
The more I read about UEFI, the more the scaremongering seems like paranoia.
>As all sysadmins know, securing a machine from its owner is often the right thing to do, and in that sense UEFI is not a bad thing.
It most certainly is. We're not talking about an IT department controlling company-owned machines. We're talking about Microsoft controlling user-owned machines.
There are crypto chips that provide secure storage and signing for private keys. If these are used in UEFI, then the chip can sign e.g. Red Hat's boot certificate without the private key ever touching the CPU.
If secure boot were about securing your computer from third parties (e.g. malware, rootkits cough) installing unauthorized software, then the correct implementation would generate a private key on each machine at the time of 1st boot, used to sign all software before running. This would ensure that the only software that could run on a machine was specifically authorized by the user. In addition, there would be no worry with regards to leaked keys, because the risk of key exposure is a single machine.
Unfortunately, secure boot is not about preventing the spread of malware. It's about securing the computer from you, the owner. It's about DRM, and ensuring that the code running on a computer (e.g. Blu-Ray player) is controlled and trusted by a third-party, who is then able to dictate how certain information available to the machine is processed.
Don't let the name fool you.