TPM unusable for DRM

Hello gentlemen,

took me lots of time to digest TPM Part 1 Design Principles ver 1.2
Conclusion: TPM is system owner's watchdog.
Whoever owns the system installs the root certificate.

If he chooses to run software emulator no program
executing on the system shall not be able to tell this.

No third party can not be sure system owner is not cheating.

No one can build DRM with this sort of TPM chip.
No one can protect himself from system owner.

End of debate?

Anton Tagunov

Re: TPM unusable for DRM

On Sat, 2006-11-04 at 03:15 +0300, Anton Tagunov wrote:
> Hello gentlemen,
> 
> took me lots of time to digest TPM Part 1 Design Principles ver 1.2
> Conclusion: TPM is system owner's watchdog.
> Whoever owns the system installs the root certificate.
> 
> If he chooses to run software emulator no program
> executing on the system shall not be able to tell this.
> 
> No third party can not be sure system owner is not cheating.
> 
> No one can build DRM with this sort of TPM chip.
> No one can protect himself from system owner.
> 
> End of debate?

Unfortunately not. First, it would be very helpful if you would identify
the volume (which part) and section number where the handling of the
"root certificate" is described. Especially since the term "root
certificate" does not actually appear in the document at all.

In the following note I will deal first with purely technical issues
without regard to questions of "ideology of property". I will then
attempt to explain why the Hurd community disagrees about who is in
control, but my explanation will surely be less than perfect.

TECHNICAL DISCUSSION

All of my section references below refer to "TPM Main Part 1 Design

Re: TPM unusable for DRM

>      FSF probably would agree with my tariff argument but would argue
>      that it isn't the essential point. The essential point is that
>      (in their view) ownership of bits is simply wrong.

This is not correct (at least neither to my understanding of the FSF
standpoint nor to my personal one): it is completely ok to have
non-disclosed bits on ones computer, which then do fulfill the
characterization of "owning" used here.
The point is actually, that if one hands away a copy of these bits, one
should not be able to control what happens to this copy.
--
-ness-

Re: TPM unusable for DRM

Hi Jonathan,

thanks for this summary, it contains many good points.  I will only
add a very few.

I am not sure how fair it is to attribute any of this to the FSF per
se, or the FSF community.  The FSF has articulated a position on DRM
in the context of systems incorporating free software, trying to
implement rules in the GPL v3 that make sure that the spirit of the
GPL license as a "copyleft" license is not violated via technical
restriction measures.  In this context, what matters most is what
constitutes "distribution" of a work.  DRM is challenging the GPL
because it enables modes of distribution where use of a software is
separated from control (such modes already exist, but they have not
been a practical concern so far to justify action).

I have heard RMS in the past to argue broadly that distribution of
information which is of benefit to the general public should not be in
control of a few.  However, it is not clear to me that there is a
general consensus about what such generally useful information
includes specifically (for every possible type of information).  In
fact, it seems to me that there is a wide range of opinions on that
matter.

Thus, I recognize the position you are describing in some aspects, but
I am not sure that there is a single label under which supporters of
this position group and march.  Maybe the EFF?

At Sat, 04 Nov 2006 12:07:43 -0500,
"Jonathan S. Shapiro" <shap <at> eros-os.org> wrote:

Subject: Yes TPMs are evil

Sorry I've been proven wrong.
I've been missing the point of "remote attestation".
A third party CAN very what soft I'm running via tpm.

cheers

Section "report" here http://www.zurich.ibm.com/security/daa/
has opened my eyes on what purpose AIK keys really serve.

Subject: Re: Yes TPMs are evil

On Mon, 2006-11-06 at 14:04 +0300, Anton Tagunov wrote:
> Sorry I've been proven wrong.
> I've been missing the point of "remote attestation".
> A third party CAN very what soft I'm running via tpm.

Exactly. However:

In order for attestation to work, the local OS must cooperate with the
remote attestation request. In principle, it is possible to *enable* the
TPM chip and then operate in one of the following ways:

  1. OS never replies to an attestation request
  2. OS only supports attestation with user permission
  3. OS always responds to attestation without consulting
     user.

(3), obviously, would be a very bad outcome. (2) is likely in the same
sense that your browser asks you things like "do you want to send
information over an insecure connection?" -- the user will always say
yes. (1) is what I expect the hurd will do.

Given the position that the Hurd team has adopted, Hurd basically has
two options:

  0. Ignore the TPM chip
  1. Do not support TPM attestation functions

My recommendation is that Hurd should consider a third position: adopt
(1) with **very limited** attestation functions. Specifically:

regarding "HURD"

yesterday, i searched last months archives of this mailing list which
gave me an insight into the the conversation happened here & also i
came to know some very interesting things. just stay with me here &
before i go on i must tell you my reason of writing this email:

http://www.coyotos.org/pipermail/coyotos-dev/2006-August/000624.html

why i am doing this? because *technically* Linux was possible because
of GNU. i am talking about tools & resources, not about freedom. even
if you cut away the freedom part GNU still wins the technical ground &
i am running a Linux based GNU system as my Desktop. that was possible
because of (tools + GPL) of GNU. i want to give a contribution in
return & i have decided that i will only work on "copyleft" softwares.
i & this whole world owe many thanks to RMS.

now i will get down to the point:

i am always *fascinated* by the idea of a microkernel based OS
especially these 2 things always mesmerised me:

http://www.gnu.org/software/hurd/hurd-paper.html
http://l4ka.org/projects/pistachio/

i have never worked for any project, i dont even know a programming
language completely. i just know some Common Lisp, 50% of C & right
now learning C++. i dont have any idea of system programming, device
drivers, GUIs, UIs, Algorithms, Data-Structures etc etc. still i spent
whole 5 months (March-August 2006) reading articles on L4, FIASCO,
HURD, OSs etc from different online resources. i feel attached to "OS
programming".

Re: regarding "HURD"

> There are sometimes good reasons to not make software copyleft. You
> shouldn't say that you will never work on non-copyleft software.

yes, i agree e.g if FBI or ATF wantes to use some secret software to
track down terrorists by intruding their privacy to protect Americans.
in that case, it is really essential to keep software non-free. see
down here.

> It's fair enough to say that you will never work (directly) on non-free
> software though.

this is exactly what i meant.

> GNU has it's own micro-kernel it's called GNU Mach, this is the official
> micro-kernel of the Hurd. Maybe you should work on that?[1] I don't
> think there are too many people who are willing to work on a completely
> new micro-kernel, and you'd be hard pressed to write a decent one by
> yourself.

IIRC, GNU Mach is derived from CMU Mach. so we have not built our own
from scratch according to our own design principles.

>  [1] http://hurd.gnufans.org/bin/view/Mach/GNUMachRevivalProject

i will check it before i post anything further.

> Regards,
> Daniel.

thanks Daniel 

Re: regarding "HURD"

Arnuld:

Daniel's reply did not go to the list. Did he intend that it should be
private?

[I assume Daniel writes:]
> > GNU has it's own micro-kernel it's called GNU Mach, this is the official
> > micro-kernel of the Hurd. Maybe you should work on that?[1] I don't
> > think there are too many people who are willing to work on a completely
> > new micro-kernel, and you'd be hard pressed to write a decent one by
> > yourself.
> 
> IIRC, GNU Mach is derived from CMU Mach. so we have not built our own
> from scratch according to our own design principles.
> 
> >  [1] http://hurd.gnufans.org/bin/view/Mach/GNUMachRevivalProject
> 
> i will check it before i post anything further.

There is a long list of things this group does not completely agree
about: DRM, GPLv3, design of a new operating system. One thing that the
group *does* agree about -- and most notably, the architects of the
original Hurd system agree about this -- is that the Mach kernel has
failed us.

shap

list administration trivia (was: regarding "HURD")

Hello!

On Wed, Nov 08, 2006 at 08:57:01AM -0500, Jonathan S. Shapiro wrote:
> Daniel's reply did not go to the list. Did he intend that it should be
> private?

No.  It's hanging in the list's waiting-for-moderation queue, as it was
posted from a so-far unknown email address.  I'll be able to moderate it
through as soon as I'm back home, which will be in a few hours.

Regards,
 Thomas

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd