is this true

[swfiua at gmail.com]

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

On Thu, Sep 29, 2011 at 10:10 PM, David Vincent
<dvincent at sleepdeprived.ca>wrote:

> http://www.tech-faq.com/linux-**licensing-in-conflict-with-**
> secure-boot-support.html<http://www.tech-faq.com/linux-licensing-in-conflict-with-secure-boot-support.html>
>
> ...
>
> 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
>
>
> --
> ubuntu-ca mailing list
> ubuntu-ca at lists.ubuntu.com
> https://lists.ubuntu.com/**mailman/listinfo/ubuntu-ca<https://lists.ubuntu.com/mailman/listinfo/ubuntu-ca>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-ca/attachments/20111003/40015a4a/attachment.html>