Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
From: owner-cypherpunks@lne.com [mailto:owner-cypherpunks@lne.com] On Behalf Of John Gilmore Sent: Saturday, August 10, 2002 4:03 AM To: cypherpunks@lne.com; cryptography@wasabisystems.com; gnu@toad.com Subject: Re: responding to claims about TCPA > 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. 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. (I have advised Intel about its security and privacy initiatives, under a modified NDA, for a few years now. Ross Anderson has also. Dave Farber has also. It was a win-win: I could hear about things early enough to have a shot at convincing Intel to do the right things according to my principles; they could get criticized privately rather than publicly, if they actually corrected the criticized problems before publicly announcing. They consult me less than they used to, probably because I told them too many things they didn't want to hear.) 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. If it's all a mishmash, then consumers will have to reject all of it, and Intel can't even improve the security of their machines FOR THE OWNER, because of their history of "security" projects that work against the buyer's interest, such as the Pentium serial number and HDCP. 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. 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. 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." 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). 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. 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. 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. 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. 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. John