| |||||||||||||
|
| |||||||||||||
Wiring DRM into the systemWiring DRM into the systemPosted Aug 4, 2005 4:58 UTC (Thu) by JoeBuck (subscriber, #2330)Parent article: Wiring DRM into the system Claims that the GPL could force people to give up the private keys they used to sign a GPLed binary with are nonsense, and this is fortunate. Otherwise Red Hat has to give up their private key (that they use to sign RPMs with). Even if a legal argument of this kind could be found, there's the problem that the program that checks a Linux kernel's signature is likely to be the boot loader, and that program doesn't have to be GPLed. There doesn't appear to be much we can do to keep people from adding DRM to the kernel, and then trying to prevent the device from booting unsigned kernels. The only consolation is that they have to release the full source code, so that everyone can figure out just what the DRM is doing. Attempts to impose terms forbidding reverse engineering of a GPLed program would be a violation of the terms of the GPL. Many Linux-based products already attempt to detect modification and refuse to boot (Tivo does this), but so far the protection has been easily crackable. It doesn't seem to me that the new Intel features are really necessary to make a device that is much harder to modify, though.
(Log in to post comments)
Wiring DRM into the system Posted Aug 4, 2005 8:53 UTC (Thu) by MathFox (guest, #6104) [Link] Claims that the GPL could force people to give up the private keys they used to sign a GPLed binary with are nonsense, and this is fortunate. Otherwise Red Hat has to give up their private key (that they use to sign RPMs with).You are correct for RPMs because it is possible to install unsigned packages. The moment that a kernel only runs signed binaries (the signature is essential for a program to run) it can be argued that creating a signature is an essential step in the process of building a program and a developer can invoke section 3 of the GPL: For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.I feel that there's a fair chance that a distributor of signed GPL binaries can be forced to hand over his keys (or stop distribution.) We won't know until the dust has settled.
Giving up your keys Posted Aug 4, 2005 10:35 UTC (Thu) by man_ls (subscriber, #15091) [Link] IANAL, but it is easy to argue this one out. The keys are not essential to the build process; Red Hat uses their own keys, just as you could use yours. You might build a Red Hat clone with your own keys (some people do that already) and it would work just as well.And, given that a "key" in this case is a prime number chosen at random (or similar mathematical artifact) there is no shortage of them that you might require Red Hat's; you might as well ask for the developer's password.
Giving up your keys Posted Aug 4, 2005 11:12 UTC (Thu) by MathFox (guest, #6104) [Link] IANAL either, but I see that I was not clear in my previous comment.If the key is not essential to the ability to run a binary, I see no reason to force someone to provide the key (like the RedHat signature on some RPMs).
When someone provides an "trusted" platform that requires signed executables signing the executable is an essential step in the building and installation process. Under those circumstances the distributor of an GPL application running on the trusted platform might be forced to provide a key that allows signing of modified binaries, so that they can run on the platform.
Giving up your keys Posted Aug 4, 2005 18:01 UTC (Thu) by man_ls (subscriber, #15091) [Link] My point, apart from being a bit bogus itself, was not clear either. It may be integral to the process that you sign the executable; but the particular key that you use is not. You can choose a prime number (or a couple of them) at random, and you can use that to sign the package / executable / kernel / whatever. If you need a signed certificate, go to whomever signs them.And then you complain that you cannot run it on your machine, because your hardware vendor is an evil company and has locked it up. The software vendor will say: "Well, that is not my problem; find another machine which accepts your signature (credentials) or build it yourself or forget about it. You have the source code, so suit yourself." You are in the jury; what would you say? You can build a case for a judge, but IMHO you might as well complain that you need the root password to build and install a program, and Red Hat did not provide it.
Giving up your keys Posted Aug 6, 2005 22:30 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I believe the argument that GPL requires the distributor to supply his signing key is this:GPL says that if I give you a binary, I must also give you all the source material needed to build that binary. Not just a similar binary; the one I actually gave you. I have to give you the scripts that contain the linker options I used, for one thing. Giving you the signing key isn't much of a stretch from that. You can argue technically either way, but the spirit of the GPL is that the recipient of a binary is supposed to be able to make useful modifications. Shipping a binary that works only because it's signed with a key the recipient doesn't know clearly does an end run around that goal and produces the same result as shipping object code without source.
Wiring DRM into the system Posted Aug 4, 2005 19:02 UTC (Thu) by jonabbey (subscriber, #2736) [Link] A more interesting question is the relationship between private and public keys. To wit, is a private key considered in some way necessary source for a matching public key embedded in a Linux kernel?
I don't see any other reason why a Linux kernel could not be legally made to run only signed binaries. The public key used to verify the signatures would have to be made available under the GPL, obviously, but possession of that public key wouldn't make it possible to produce binaries that such an (unmodified) kernel would load and run.
So, if the hardware were to contain a public key to verify signed kernel binaries, and the kernels that were so signed contained a public key to validate software to be loaded on that kernel, then you've got a fairly decent lock down of the software that can be run.
|
|
||||||||||||