The Linux kernel and digital rights management

Posted May 1, 2003 21:27 UTC (Thu) by iabervon (subscriber, #722)
Parent article: The Linux kernel and digital rights management

It would probably violate the GPL to embed in the kernel a signature by a key not available to recipients. But that would be a silly idea anyway. A better idea would be to compile the kernel without the use of a private key, and distribute it. Then someone, either the same company or a different company, could examine the kernel binary and decide to sign it. The hardware then checks that a signature is available (not linked into the kernel, which doesn't have any reason to check its own authenticity), and loads the kernel if a suitable signature is found.

The question, then, is whether a signature is a work derived from the work it is a signature for, in which case it would seem to fall under the GPL, requiring that the key used to create the signature itself be made available. But this is unlikely; signing a work probably falls under fair use, in which case the people compiling and shipping the kernel are following the GPL, and the people signing the image and checking the signature aren't bound by it.

The Linux kernel and digital rights management

Posted May 8, 2003 12:03 UTC (Thu) by scharkalvin (guest, #7372) [Link] (1 responses)

There are two reasons to run a 'signed' kernel, and to have the hardware force you to ONLY run a signed kernel. Both reasons involve trust, but from different points of view. In one case, it protects the computer user (and the computer) from running software obtained from an untrusted source, software that might contain viri and due damage to the user. In this case if I compile my own kernel, I need the key for my computer so I can run linux. I could see the maker of the computer suppling the owner with the binary key so he could sign his own kernel. It would be unique to each computer, and only allow me to run the kernel I built on a single computer, the one whose Key I know.

The second reason for the signed kernel is trust for the providers of any software content I might wish to view on my computer. With this key my kernel could use DRM hardware to unlock content to view on my computer. This is the dark side that worries us, because we see being locked out of using our OWN content as the DRM hardware/software bytes back at NON-PIRATE uses of the machine.

The Linux kernel and digital rights management

Posted May 16, 2003 19:19 UTC (Fri) by iabervon (subscriber, #722) [Link]

Experts generally feel that the second use won't actually work, because it's too hard to protect the chain of trust from the computer manufacturer to the content provider, to manage trust of the software involved, and to manage security of the key over its potential lifetime.

There's a third use, as well: hardware vendors who want to use the flexibility of a general purpose computer in their device without giving that flexibility to the end user. Consider a car manufacturer who uses an embedded processor to control the car, rather than using a PIC or an FPGA, so that it is easier to write the firmware and deploy changes. The manufacturer doesn't want to let the user modify the firmware arbitrarily, because it opens up all kinds of liability problems. They could build a car with a public key embedded in it, and only allow kernels signed with the corresponding private key; these kernels being the ones they are willing to be liable for.

So it makes sense to have DRM in cases where it limits the risk of embedding a general computer in something which does not need to be a general computer.