"Palladium" and TCPA

[Markus Kuhn]

Ross Anderson wrote on 2002-06-28 16:19 UTC:
> Information about Palladium continues to pour in. I can confirm that
> there will be mechanisms to revoke content as well as keys; needed, so
> Hollywood says, to trash any widely distributed bootleg, and capable of
> being indexed by file contents, ID of signing key, ID of machine that
> created it, and a number of other options (or combinations). I discussed
> this with Lucky Green yesterday and he came up with the delightful term
> `document revocation list'.

Of course there has to be a revokation list for content keys that
involves a long-term memory in the user's system, otherwise how could
you ever transfer a licence from one CPU to another? Any content
protection scheme that offers users to transfer a licence from one piece
of hardware to the next will need a trustable mechanism that ensures
that the licence to run the software on the old hardware has been
revoked. To end a licence on one system, the user has to be able to
demonstrate that she won't be able to continue using the previous
licence.

Even the simple TrustNo1 processor, an early TCPA-like content
protection concept that I designed half a decade ago as an undergraduate
project had already such a content key revocation mechanism built in,
even in a form that allows to revoke keys from defect hardware:

  http://www.cl.cam.ac.uk/~mgk25/trustno1.pdf

There is nothing devious or dangerous about this. It is an essential
ingredient in any practically useable content protection mechanism, and
it would have been foolish for the designers not to add a revokation
mechanism for content keys.

> This will clearly get used to suppress porn,
> then libel, then goodness knows all what

How? Neither TCPA nor Palladium contain any mechanism whatsoever
preventing you from photographing yourself or Tony naked and posting the
result here on the list. You know as well as I do that such technology
is well beyond the state of the art ...

Unless you decide to copy protect your porn and libel, we will all have
no problems forwarding it on our TCPA/Palladium enabled mailing list
servers, because TCPA/Palladium remains completely ignorant of any
actual content being processed.

> - and bear in mind that a US
> court has ruled the Fishman affidavit the copyright of the Scientologists.

And was there really anything wrong with this? Whether we like
Scientology or not, whatever they author *is* rightly protected by
copyright. Why should your book be protected from being posted, but Mr.
Hubbard's not? If someone posts Scientology's crap against their
permission to the USENET, then this is illegal, and it is fine with me
if my tax money is used to go after people who violate copyright,
because I expect the same government service to be available if someone
steals my work. Even Scientologists have rights, independent of what we
all might think about the intellectual value of their holly scripture.
The particular case in question also was clearly not a case of fair use,
because the posting in question was just the full text and not a
scholarly or even satirical comment with a few relevant excerpts.

> How can you expect that it won't appear on everyone's DRL?

In all the proposals that I have seen, what will be revoked are keys
that can be used to decrypt protected content. You can't revoke content
automatically, because robust content fingerprinting, watermarking, or
matching etc. are at the moment unsolved engineering problems. And even
if you could, all this is many layers above where TCPA operate and has
nothing to do with TCPA. What you are so scared of is *well* beyond the
state of the art.

The only thing that you might accuse the Palladium people of is that
they have implied in recent interviews a level of protection that they
are very unlikely to be able to deliver to their users. All I saw in
these bits of information were unrealistic assurances to get "Hollywood"
interested in the technology. I have seen similar overrated claims of
protection for Macrovision and DVD before ...

> There are also going to be mechanisms for secure time. These are needed,
> we're told, so that corporations in future can cause all emails to
> evaporate after a fixed period of time. Clearly, this would have been of
> great help to M$ in the antitrust case, and Arthur Andersen too. (Are you
> comfortable with the public policy aspects of this?)

I don't think the concerns you hint at here have really anything to do
with TCPA. TCPA is just yet another mechanism to control or prevent
access to information. You can also use fire, shredders, or locked doors
to destroy or deny access to documents, but I assume you have no problem
with matches or shredders or locks. You can already today request that
people can see documents only at a specified place, but not make
physical copies (e.g., that's common practice with students being
allowed to see corrected exam papers). TCPA attempts to make all this
slightly more convenient to do remotely via a PC. It's an ambitious
engineering project, and might indeed be very useful for new
applications, but it doesn't offer a fundamentally new capability
unknown to socienty.

If you are worried about long-term records being kept properly for
certain transactions, then you have to campaign for legal requirements
to keep these long-term records properly and in an accessible form. This
has really nothing to do with particular technologies like TCPA. There
are far larger dangers to long-term record keeping than TCPA
(incompetence in making backups is probabaly number one), and it is easy
to legally require mandatory archiving of records. Internal revenue
services have done this since I can think.

> Secure time is also intended to enable offline application rental. In
> future, instead of paying $200 for office you might pay 50c per hour. This
> can be enforced online simply enough; offline, Fritz comes to the rescue.

If there are people willing to pay for that usage model, then what's
wrong with that? Let the market decide, what sort of pricing models
users prefer. 50c per hour sounds not competetive for a word processor
that I use daily. It would be an extremely attractive offer for some
specialist software that I need only temporarily and very rarely, but
that I can currently not use at all as a poor student, because the only
licence available is the one for $5000 that allows me to use it
infinitely what I need only for a single afternoon.

TCPA gives software companies more alternatives to differentiate prices.
From what little I know about modern economic theory, price
differentiation must in general be seem to be a GoodThing[TM], because
it increases efficiency and access. If you charge everyone exacly what
they are able to pay, more people can afford to use your product and
everyone pays less than they would have to with a simple one-fits-all
pricing scheme.

Do you have any serious argument for why TCPA/Palladium is a danger to
society? I can see behind your arguments an underlying concern that
Microsoft's and Intel's de-facto monopoly over at least some part of our
global computing infrastructure might be harmful to society, and I'm the
first to agree. But then, why not address this underlying problem,
instead of transfering all concern on what is really nothing but yet
another copy protection mechanism. Sounds like a battle on the wrong
front to me. Preventing monopolies is a legal, not a technical issue.

Similarly with differential pricing. You might not see it's benefits,
but in the end, whether sellers can use it is a legal, not a technical
issue. Differential pricing is already legally forbidden in many areas
where society considers it harmful.

I am surprised that you are not focusing on the real problem with TCPA,
namely that, from all we know, the actual level of protection that it
will be able to provide is significantly weaker than what some of the
executive-summary announcements released recently try to suggest. Many
of the things they claim, especially the high robustness against
break-all-run-anywhere is simply far from technologically feasible.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>