I know very little about the UEFI implementation, but do know a fair bit about public key cryptography. If the UEFI implementation is done right then the keys that are embedded in the boot loader should be public keys and, by definition, there is no need to keep them secret. The keys that need to be kept secret are the corresponding private keys used to sign the OS'es that you install. This part should not be a problem for linux. I'd expect the main distros to have their own private keys and to provide tools to make it easy to adder their public keys to UEFI. For users experimenting with their own OS, then I assume you can generate your own key pair, load the public key into the boot loader and use the private key to sign your OS. One thing I'm not sure about with UEFI is just what you have to sign. I'd expect the signing to include some sort of checksum on the code it is going to boot -- can anyone point me at the details? John <div class="gmail_quote">On Thu, Sep 29, 2011 at 10:10 PM, David Vincent <<a href="mailto:dvincent@sleepdeprived.ca">dvincent@sleepdeprived.ca</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <a href="http://www.tech-faq.com/linux-licensing-in-conflict-with-secure-boot-support.html" target="_blank">http://www.tech-faq.com/linux-licensing-in-conflict-with-secure-boot-support.html</a> ... That said, the problem would be relatively easy to solve if it wasn’t for certain peculiarities in the way Linux software is typically licensed. Linux vendors could certify a key to be used with UEFI secure boot and include this key in Linux boot loaders so they can pass this security checkpoint. The important thing here is that this key needs to stay secret, and the only way to make sure it stays secret while distributing it as part of Linux boot loaders is for it to be in binary form (no source code). This is where we get to the core of the issue. Most commonly used Linux boot loaders, GRUB and GRUB2 are licensed under GPL, a license which denies embedding proprietary code in it, and requiring a secret key to function. GRUB2 is licensed under GPLv3 which makes this explicitly denied, whereas it is a gray area in GPLv2. As gray as it may be, however, exploiting it would run against the spirit of the license which is what fueled the strictness in GPLv3 to begin with. ... -d<div><div></div><div class="h5"> -- ubuntu-ca mailing list <a href="mailto:ubuntu-ca@lists.ubuntu.com" target="_blank">ubuntu-ca@lists.ubuntu.com</a> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-ca" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-ca</a> </div></div></blockquote></div>