responding to claims about TCPA

[AARG!Anonymous]

AARG! wrote:
> I asked Eric Murray, who knows something about TCPA, what he thought
> of some of the more ridiculous claims in Ross Anderson's FAQ (like the
> SNRL), and he didn't respond.  I believe it is because he is unwilling
> to publicly take a position in opposition to such a famous and respected
> figure.

John Gilmore replied:
>
> Many of the people who "know something about TCPA" are constrained
> by NDA's with Intel.  Perhaps that is Eric's problem -- I don't know.

Maybe, but he could reply just based on public information.  Despite this
he was unable or unwilling to challenge Ross Anderson.


> One of the things I told them years ago was that they should draw
> clean lines between things that are designed to protect YOU, the
> computer owner, from third parties; versus things that are designed to
> protect THIRD PARTIES from you, the computer owner.  This is so
> consumers can accept the first category and reject the second, which,
> if well-informed, they will do.

I don't agree with this distinction.  If I use a smart card chip that
has a private key on it that won't come off, is that protecting me from
third parties, or vice versa?  If I run a TCPA-enhanced Gnutella that
keeps the RIAA from participating and easily finding out who is running
supernodes (see http://slashdot.org/article.pl?sid=02/08/09/2347245 for
the latest crackdown), I benefit, even though the system technically is
protecting the data from me.

I wrote earlier that if people were honest, trusted computing would not
be necessary, because they would keep their promises.  Trusted computing
allows people to prove to remote users that they will behave honestly.
How does that fit into your dichotomy?  Society has evolved a myriad
mechanisms to allow people to give strong evidence that they will keep
their word; without them, trade and commerce would be impossible.  By your
logic, these protect third parties from you, and hence should be rejected.
You would discard the economic foundation for our entire world.


> TCPA began in that "protect third parties from the owner" category,
> and is apparently still there today.  You won't find that out by
> reading Intel's modern public literature on TCPA, though; it doesn't
> admit to being designed for, or even useful for, DRM.  My guess is
> that they took my suggestion as marketing advice rather than as a
> design separation issue.  "Pitch all your protect-third-party products
> as if they are protect-the-owner products" was the opposite of what I
> suggested, but it's the course they (and the rest of the DRM industry)
> are on.  E.g. see the July 2002 TCPA faq at:
>
>   http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf
>
>   3. Is the real "goal" of TCPA to design a TPM to act as a DRM or
>      Content Protection device? 
>   No.  The TCPA wants to increase the trust ... [blah blah blah]
>
> I believe that "No" is a direct lie.

David Grawrock of Intel has an interesting slide presentation on
TCPA at http://www.intel.com/design/security/tcpa/slides/index.htm.
His slide 3 makes a good point: "All 5 members had very different ideas
of what should and should not be added."  It's possible that some of
the differences in perspective and direction on TCPA are due to the
several participants wanting to move in different ways.  Some may have
been strictly focused on DRM; others may have had a more expansive
vision of how trust can benefit all kinds of distributed applications.
So it's not clear that you can speak of the "real goal" of TCPA, when
there are all these different groups with different ideas.

> Intel has removed the first
> public version 0.90 of the TCPA spec from their web site, but I have
> copies, and many of the examples in the mention DRM, e.g.:
>
>   http://www.trustedcomputing.org/docs/TCPA_first_WP.pdf  (still there)
>
> This TCPA white paper says that the goal is "ubiquity".  Another way to
> say that is monopoly.

Nonsense.  The web is ubiquitous, but is not a monopoly.

> The idea is to force any other choices out of
> the market, except the ones that the movie & record companies want.
> The first "scenario" (PDF page 7) states: "For example, before making
> content available to a subscriber, it is likely that a service
> provider will need to know that the remote platform is trustworthy."

That same language is in the Credible Interoperability document presently
on the web site at
http://www.trustedcomputing.org/docs/Credible_Interoperability_020702.pdf.
So I don't think there is necessarily any kind of a cover-up here.


>   http://www.trustedpc.org/home/pdf/spec0818.pdf     (gone now)
>
> Even this 200-page TCPA-0.90 specification, which is carefully written
> to be obfuscatory and misleading, leaks such gems as: "These features
> encourage third parties to grant access to by the platform to
> information that would otherwise be denied to the platform" (page 14).
> "The 'protected store' feature...can hold and manipulate confidential
> data, and will allow the release or use of that data only in the
> presence of a particular combination of access rghts and software
> environment.  ... Applications that might benefit include ... delivery
> of digital content (such as movies and songs)."  (page 15).

Yes, DRM can clearly benefit from TCPA/Palladium.  And you might be
right that they are downplaying that now.  But the reason could be
that people have focused too much on it as the only purpose for TCPA,
just as you have done here.  So they are trying to play up the other
possibilities so as to get some balance in the discussion.


> Of course, they can't help writing in the DRM mindset regardless of
> their intent to confuse us.  In that July 2002 FAQ again:
>
>   9. Does TCPA certify applications and OS's that utilize TPMs? 
>   
>   No.  The TCPA has no plans to create a "certifying authority" to
>   certify OS's or applications as "trusted".  The trust model the TCPA
>   promotes for the PC is: 1) the owner runs whatever OS or
>   applications they want; 2) The TPM assures reliable reporting of the
>   state of the platform; and 3) the two parties engaged in the
>   transaction determine if the other platform is trusted for the
>   intended transaction.
>
> "The transaction"?  What transaction?  They were talking about the
> owner getting reliable reporting on the security of their applications
> and OS's and -- uh -- oh yeah, buying music or video over the Internet.

You are reading an awful lot into this one word "transaction".  That
doesn't necessarily mean buying digital content.  In the abstract sense
"transaction" is sometimes used to refer to any exchange of information in
a protocol.  Even if we do stick to its commercial meaning, it can mean
a B2B exchange or any of a wide range of other e-commerce activities.
It's not specific to DRM by any means.


> Part of their misleading technique has apparently been to present no
> clear layman's explanations of the actual workings of the technology.
> There's a huge gap between the appealing marketing sound bites -- or
> FAQ lies -- and the deliberately dry and uneducational 400-page
> technical specs.  My own judgement is that this is probably
> deliberate, since if the public had an accurate 20-page document that
> explained how this stuff works and what it is good for, they would
> reject the tech instantly.

I agree that the documentation is a problem, but IMO it probably reflects
lack of resources rather than obfuscation.  I believe that TCPA has many
more applications than you and other critics are giving it credit for,
and that a good, clear explanation of what it could do would actually
gain it support.  Do a blog search at daypop.com to see what people are
really thinking about TCPA.  They read Ross Anderson's TCPA FAQ and take
it for gospel.  They believe TCPA has serial number revocations and all
these other features that are not described in any documents I have seen.
A good clear TCPA description could only improve its reputation, which
certainly can't go any lower than it is.


> Perhaps we in the community should write such a document.  Lucky and
> Adam Back seem to be working towards it.  The similar document about
> key-escrow (that CDT published after assembling a panel of experts
> including me, Whit, and Matt Blaze) was quite useful in explaining to
> lay people and Congressmen what was wrong with it.  NSA/DoJ had
> trouble countering it, since it was based on the published facts, and
> they couldn't impugn the credentials of the authors, nor the
> document's internal reasoning.

I agree in principle, but I am appalled that you believe that Lucky in
particular is heading in the right direction.  Adam on the other hand
has at least begun to study TCPA and was asking good questions about
Palladium before Peter Biddle flew the coop.  Will this document say
that TCPA is designed to support intelligence agency access to computers?
to kill free software?  and other such claims from Lucky's presentation?
If so, you will only hurt your cause.  On the other hand, if you do
come up with factual and unbiased information showing both good and bad
aspects of TCPA, as I think Adam has come close to doing a few times,
then it could be a helpful document.


> Intel and Microsoft and anonymous chauvanists can and should criticize
> such a document if we write one.  That will strengthen it by
> eliminating any faulty reasoning or errors of public facts.  But they
> had better bring forth new exculpating facts if they expect the
> authors to change their conclusions.

Conclusions should be based on technology.  TCPA can be rightly
criticized for weak protections of privacy, for ultimately depending on
the security of a few central keys and of possibly-weak hardware, and on
other technical grounds.  But you should not criticize it for supporting
DRM, or for making reverse engineering more difficult, because people
are under no obligation to give their creative works away for free,
or to make it easy for other people to copy their software.  Leave your
values at home and just present the facts.


> They're free to allege that "No
> current Microsoft products have Document Revocation Lists", but that
> doesn't undermine the conclusion that their architectures make it easy
> to secretly implement that feature, anytime they want to.

No one has made any such allegation, although presumably it happens to
be true.  The point in contention is whether TCPA has DRLs!  Lucky has
claimed this, and Ross claimed the related serial number revocation
list, SNRL.  Both of them have linked this technology to TCPA/Palladium.
Yet as Ross admitted in
http://www.chiark.greenend.org.uk/pipermail/ukcrypto/2002-June/019463.html,
SNRL's do not need TCPA!

In fact, you are perfectly correct that Microsoft architectures would
make it easy at any time to implement DRL's or SNRL's.  They could do
that tomorrow!  They don't need TCPA.  So why blame TCPA for this feature?
TCPA is a technology.  You can't take every bad thing Microsoft ever
will do and say that TCPA is at fault.

I don't even see that TCPA would particularly help with a SNRL, except
insofar as TCPA can generally strengthen security in all respects.
But remote attestation and sealing, the core TCPA technologies, don't
have anything to do with SNRLs.

The association of TCPA with SNRLs is a perfect example of the bias and
sensationalism which has surrounded the critical appraisals of TCPA.
I fully support John's call for a fair and accurate evaluation of this
technology by security professionals.  But IMO people like Ross Anderson
and Lucky Green have disqualified themselves by virtue of their wild and
inaccurate public claims.  Anyone who says that TCPA has SNRLs is making
a political statement, not a technical one.  For a credible evaluation,
you need people who have no track record of bias with regard to the
technology.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com