| |||||||||||||
|
| |||||||||||||
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Posted Oct 23, 2006 1:04 UTC (Mon) by bojan (subscriber, #14302)In reply to: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) by bronson Parent article: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)
> The problem is that, if a hardware manufacturer creates a hardware platform that will only run signed binaries, the GPLv3 requires the manufacturer to give away his private keys.
Excellent summary of the problem. In essence, the hardware manufacturer is supposed to go through all the trouble of desiging and manufacturing the hardware (in such a way that it is extremely difficult to find those private keys inside it) and then signing the binaries, only to give the very private keys away to millions of customers in a plain file. I would venture a guess that not one manufacturer is going to do this, as it is just plain silly.
(Log in to post comments)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 11:46 UTC (Mon) by nim-nim (subscriber, #34454) [Link] > In essence, the hardware manufacturer is supposed to go through all the> trouble of desiging and manufacturing the hardware (in such a way that it > is extremely difficult to find those private keys inside it) and then > signing the binaries, only to give the very private keys away to millions > of customers in a plain file. I would venture a guess that not one > manufacturer is going to do this, as it is just plain silly.
What's plain silly is pretending that DRM is a life-and-death for manufacturers, that manufacturers will design a complete expensive system, but it won't be able to perform the simplest operations (like handling several keys)
To read some people here DRM is rocket science but its limitations pile up:
Choose your ground guys, either your DRM will be a botched dirt-cheap CSS-like implementation (in which case it's not really the GPLv3 problem) or the manufacturer will go to the "trouble" of designing a solid system. In which case the GPLv3 requirements are not much different from the ones needed to :
The "one key to rule your all" postulate is no more true in the proprietary software world than in one exposed to the GPLv3
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 21:19 UTC (Mon) by bojan (subscriber, #14302) [Link] I really don't understand what your post. The question is why would someone design a secretive hardware system (regardless of how many secrets there may be) and then give those secrets away wholesale. It doesn't make sense.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 7:01 UTC (Tue) by nim-nim (subscriber, #34454) [Link] Because the security of a system and the autorisation granularity are two different things? (and note I'm using security there not secretivity wich is an altogether different and worthless concept)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 9:41 UTC (Tue) by bojan (subscriber, #14302) [Link] Correct me if am wrong, but the basic premise of trusted computing (i.e. DRM hardware) is that there is a piece of hardware that holds secrets (keys) that are very difficult to get to using "conventional" means (i.e. you have to hack the hardware to fetch them).
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
So, if there is a GPLv3 software in operation on this platform, why have the keys at all? They are pretty much public in the case of say a mobile phone (i.e. millions of people would have them), so the ones kept in hardware (whether they can be changed, expired and what not) are no longer secret, no matter how you look at it, as it is the requirement of the GPLv3 that every user gets those keys. In essence, from the point of view of the TC hardware, GPLv3 is untrusted software.
So, the authorisation granularity here boils down to "don't trust this, everybody has *these* keys". Therefore, it is more or less meaningless to distribute to large amounts of "uncontrolled" users all those keys and still have the hardware that supposedly verifies things based on the secrecy of those keys.
PS. I'm not commenting here in the validity of the TC as a security, authentication or autorisation system.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 11:29 UTC (Tue) by nim-nim (subscriber, #34454) [Link] Of course not.You don't authorize a key for everything. You authorize a key for specific level of accesses.
If your system is properly designed :
Again, the GPLv3 is only a problem for blanket one-for-all *stupid* and *dangerous* DRM (akin to deploying thousands of systems running every service as root using the same password)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 13:45 UTC (Tue) by bojan (subscriber, #14302) [Link] > You authorize a key for specific level of accesses.
But that's the rub here. The keys shipped with GPLv3 software are practically public, making them completely untrustworthy, therefore having zero level access.
And that's the argument I'm trying to make: GPLv3 and TC (i.e. DRM hardware) are for most purposes incompatible.
So, not many would go through the trouble of implementing such a system.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 14:48 UTC (Tue) by nim-nim (subscriber, #34454) [Link] In what way a device-specific key (as is this specific device with this specific device number) is incompatible with TC (i.e. DRM hardware) or GPLv3 ?
Except as locking the owner out that is.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:12 UTC (Tue) by bojan (subscriber, #14302) [Link] > In what way a device-specific key (as is this specific device with this specific device number) is incompatible with TC (i.e. DRM hardware) or GPLv3?
The key is not incompatible with anything. The GPLv3 software is (for most practical intents and purposes) incompatible with TC (DRM hardware), because it requires that the very keys that are supposed to be secret are to be given away to just about everyone. It's that simple.
Why on earth would someone have a secret embedded in hardware only to give it away in a plain file, therefore making the secret, well, not secret any more? They may as well treat GPLv3 software as completely not trusted (from the TC platform point of view) - it's just about the same.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 21:26 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] TC is not entirely incompatible with GPL v3. For instance, suppose I have a machine-specific secret key and a notion of "secure level." I, the user, have to perform some action to unlock the system--that is, lower the secure level. When it's unlocked, I can add/remove/change software and then re-lock it. (The lock could even have a physical aspect, such as a jumper or switch.)
When re-locking, the machine then signs each of the added/changed software using its secret, machine-specific key, and subsequently refuses to run any software with invalid signatures. That is, until it's unlocked.
This seems like a great way to harden servers.
It should be possible to run GPL v3 software on such a system. Making a key available doesn't mean telling the person what the key is.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:11 UTC (Tue) by bojan (subscriber, #14302) [Link] > I, the user, have to perform some action to unlock the system--that is, lower the secure level.
TC relies on the machine (i.e. hardware) to do this. The machine doesn't trust you to do it, but only itself. Letting users unlock anything defeats the purpose of TC immediately.
You are just replacing one secret with another here and this is explicitly not how TC platforms are designed to work.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:39 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] The TPM technology underlying TC does not rule out owner-override. Unfortunately, no TC stack provider wants to provide it. I was speaking from this technical aspect. GPL v3 software should be just fine on a TC box with owner-override. You STILL don't get to see the key with owner-override, which was my main point. But you do get (indirect) access to it.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 23:43 UTC (Tue) by bojan (subscriber, #14302) [Link] > Unfortunately, no TC stack provider wants to provide it.
Yeah, that's the key here (excuse the pun). They don't want to trust users - that's why they are keen to implement TC in the first place.
A consumer device manufacturer or service provider that starts shipping TC on their devices is unlikely to give users the power to override anything, as it would defeat the purpose of having TC on the platform (i.e. they want to ensure that only software approved by *them* runs there). I know, that's bad and all, but that's what they want. I think in such a scenario, they are very unlikely to ship GPLv3 software on such hardware, as it would defeat the purpose of building such a platform.
Basically, FSF may as well have specified in the GPLv3 draft that you are not allowed to ship signed binaries that would run only on designated hardware. The whole thing with "you can do it, but you have to give away the keys" is a bit silly (an attempt at sarcasam by FSF? :-). Not many are going to take "advantage" of that.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 9:59 UTC (Thu) by nim-nim (subscriber, #34454) [Link] So they won't ship GPLv3 software. Or more accurately they will have to think about the consequences of blanket DRM (I'm not at all convinced all of them will rather get in bed with a difficult parter like MS just to avoid following the GPLv3 license)
Right now they can eat their cake and keep it too - but it's no entitlement
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 15:50 UTC (Tue) by farnz (guest, #17727) [Link] My reading of the GPLv3 (and I could be a non-lawyer misunderstanding it here) is that the manufacturer doesn't have to give away their private keys. Instead, they could allow the owner to add their own key, so long as this gives the same access as the manufacturer's key.This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 0:01 UTC (Wed) by bojan (subscriber, #14302) [Link] > This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
Which is just about the same as allowing unsigned software run on the same device - you just don't trust it. And since the TC hardware doesn't trust it, it may disable functionality of say 90% of the device, including the ability to connect to the network, see the address book etc.
If that's what FSF had in mind, then this is the same as asking the hardware manufacturers to design their hardware to be capable of running unsigned binaries. That's all cool by me, but I don't think user's freedom is completely preserved here, as the device effectively becomes crippled, making the whole thing a sham.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 8:14 UTC (Wed) by farnz (guest, #17727) [Link] Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back. It's not useful for (e.g.) preventing the user from watching movies unless they're running your authorised software.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 21:20 UTC (Wed) by bojan (subscriber, #14302) [Link] > Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.
And there lies the problem - this will never happen. The whole idea of TC is that you only trust things sign with vendor's keys. The user is by definition an untrusted party.
> Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back.
Or, you can just run a quick md5sum/sha1sum against the binaries and find out the same.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 8:34 UTC (Thu) by farnz (guest, #17727) [Link] In other words, TC means that the vendor doesn't want the user to be free to exercise the four freedoms that Stallman wants all users to have. No wonder the GPLv3 stops this.And how exactly do you get a trustworthy md5sum/sha1sum from a device in a user's hands without TC? I was thinking in terms of a mobile phone or ADSL modem, where you might well want to not offer support if you can't confirm that the right software's running on the device; being able to check this from the other end of a phone line or e-mail conversation quickly, and avoid wasting 10 minutes while you try and support a user who's changed the software. In the TC case, you can just insist that they boot with your software before they get support.
|
|
||||||||||||