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.