Re: TPM unusable for DRM

[Jonathan S. Shapiro]

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
Principles", Specification Version 1.2, Revision 62, 2 October 2003.

I *think* you are referring to the discussion in section 5.1, and the
behavior of TPM_TakeOwnership throughout the document. Unfortunately, I
think you haven't understood this correctly. It is definitely tricky.

First, take note of section 3: the discussion of Endorsement Key (EK)
Creation. Note that the chip comes pre-shipped with an endorsement key.
Once generated, this key CANNOT BE REPLACED. Also: "The entity that
causes EK generation is also the entity that will create a credential
attesting to the validity of the TPM and the EK."

Next, take note of Section 9.1, 1.a: The cryptographic identity of the
RTR is the Endorsement Key.

So: you are correct that the user must *enable* the TPM.

Now, let us consider your statement about DRM:

0. The conceptual DRM design based on the TPM relies on *positive*
permission. That is: unless a successful, checkable endorsement is
performed by the TPM, permissions are not granted.

1. If the TPM is not enabled, it will not endorse, and permissions will
not be granted by the provider.

2. If the TPM *is* enabled, then it can endorse and the service provider
can validate (via the EK certificate, which is obtained by external
means) that the endorsement is valid.

3. Local software can perform these operations, refusing to decrypt
content unless an acceptable endorsement is provided by the TPM.

4. No emulator will have access to the EK. In consequence, no emulator
can simulate a valid endorsement.

  Caveat: the seller could agree to accept the emulator master key as a
     valid endorsement -- I can imagine contracts between [e.g.] VMWare
     and seller that might enable this. If the emulator is built on top
     of the TPM mechanisms, the emulator key can be (transitively)
     protected using the TPM encryption mechanisms and TPM-supplied
     secure storage.

So: from a technical perspective DRM can be made to work. There are some
overwhelming technical deficiencies. Primarily: an effective solution
requires a secure OS. A secure OS requires that either (a) all drivers
be identified in the attestation or (b) drivers be partitioned in such a
way that they cannot impact the security of the core system. Option (b)
is technically feasible in principle, but not in the current-generation
PC architecture. Option (a) is technically feasible, but it creates an
*overwhelming* configuration management problem: there are literally
*millions* of possible attestation values, because there are many
versions of many drivers, and many combinations of versions of drivers
that must be attested. As a practical matter, this creates an
overwhelming configuration management problem -- one that the vendors
simply cannot manage.

Until (b) is solved, DRM isn't going to happen based on TPM -- or if it
does, it will be based on some much weaker assessment basis. For
example: "trust the machine if it is running the Windows kernel, without
regard to drivers". Even here the problem of patch tracking is
overwhelming.

Solutions for (b) may be coming, but I won't get in to that right now.


IDEOLOGY OF PROPERTY

First, please note that I do not agree with FSF's view. This is my
attempt to describe the issues in a way that is fair to FSF, but it is
likely that I will get it wrong.

First: what is "ownership"? This is a potentially long debate, but there
are some fairly common points of agreement:

  In order for a thing to be "owned", it must be the case (at least
  initially) that the owner's rights are not subordinate to someone
  else's rights. It *may* be possible for an owner to transfer or
  lease (through contract) some or all of their rights, but in order
  for this to be sensible the owner must initially be in control of
  those rights.

  If an owner "owns" something without having this type of initial
  control, then they are not really an owner.

Second, what is the objective of DRM? This is also a long debate, but
let me try to state it briefly:

  The objective of DRM is to provide a technical means by which two
  *legal* objectives can be achieved:

    1. Replace all user ownership of digital media (or other protected
       content) with *license to use* that content. That is: the primary
       rights over "your" copy of a music file would remain with the
       seller.

    2. Provide a technical foundation on which the terms of the license
       can be enforced.

Some specific rights of ownership that DRM advocates are trying to take
away: (1) right to transfer content from one device to another, (2)
right to re-record/RIP for personal use.

When the FSF community says that "DRM removes control from the owner",
they are speaking imprecisely, but with merit. The argument is a bit
subtle, and it has three parts:

   1. Ownership of digital content is being replaced with license of
      digital content.
   2. While the owner must agree to license (in a de jure sense), the
      monopoly power over digital content distribution means that the
      choice is very one-sided: you can choose to accept the license
      or you can choose not to have music/movies/etc. That is: there
      is no choice in any meaningful (de facto) sense.
   3. Under current law it appears that none of this content will 
      *ever* become open for public use.

In addition to these issues, which I think are hard to deny, there are
two major "ideology" objections to this very "all or nothing" choice:

  1. It deprives society of open access to creative works. This
     impoverishes society. At best, it is a fundamental violation
     of the balances of ownership that have supported creativity
     in our society for the last 500 years.

  2. The FSF community feels that ownership of copies of digital media
     should rest entirely with the recipient, and that control on
     redistribution is improper.

     There are many arguments supporting this view. The most compelling,
     in my view, is the argument that the marginal cost of copying
     digital media is zero. Creating a legislated means for imposing
     a cost introduces an economic externality. In general, this type
     of externality is bad. In effect, the legislation creates a
     wholly artifitial protective tariff similar conceptually to an
     import or export tariff. In the history of such tariffs, there are
     NO examples of a tariff that actually achieved any long-term
     benefit for the society that it was supposed to protect. All
     examined and documented cases can be divided into two groups:

       Tariffs that went away before they could cause lasting
       damage.

       Tariffs that actively harmed the society they were designed
       to protect.

     Example: the end effect of the DRAM import duties was that the US
     exited the DRAM industry.

     A parallel argument can be made for digital media, though it does
     take some care.

     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.

So to summarize:

DRM *can* be implemented on TPM (technically).

There remain overwhelming administrative impediments to doing this in
practice.


shap