On Thu, 6 Feb 2003, Anonymous via the Cypherpunks Tonga Remailer wrote: > I think you may have been mislead by the slant of paper. > > Quoting from the paper: > > http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf > > you will see: > > | The TCPA chip is not particularly suited to DRM. While it does have > | the ability to report signed PCR information, and this information > | could be used to prevent playback unless a trusted operating system > | and application were in use, this type of scheme would be a > | nightmare for content providers to manage. Any change to the BIOS, > | the operating system, or the application would change the reported > | values. How could content providers recognize which reported PCR > | values were good, given the myriad platforms, operating system > | versions, and frequent software patches? > > which clearly admits that the IBM TPM does implement the full set of > TCPA functionality as specified in the openly published TCPA spec, and > for the purposes of our discussion specifically as you see it does > implement the remote attestation feature.
They can say all they want in a white paper. I was looking at the source code. That can only query the tpm chip. The chip itself contains no rom, you can't jump into it. In order to meet the requirement of tcpa it needs a secure execution region, and the IBM TPM simply doesn't have it. > (Though the author makes some unimaginative claims that it is "not > suited for DRM" because of upgrades may make that difficult to manage. > Any sane software architecture built on top of this tech can easily > tackle that "problem".) And any hacker can bypass it, which is what the guys at IBM are saying. > I'd think the more likely reason they want to downplay that TCPA is a > DRM enabling technology is because it's bad publicity for a hardware > manufacturer. I doubt it. If they could do what RIAA wants they could make a lot of money. Morals come second to money. Patience, persistence, truth, Dr. mike
