| |||||||||||||
|
| |||||||||||||
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Posted Oct 24, 2006 9:41 UTC (Tue) by bojan (subscriber, #14302)In reply to: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) by nim-nim Parent article: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)
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.
(Log in to post comments)
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
|
|
||||||||||||