Mike Rosing wrote: > > - secure boot > > - sealing > > - remote attestation > > It does *not* do these parts.
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. (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".) > That's why IBM wants the TPM != TCPA to be loud and clear. That's > why the RIAA can't expect it to solve their "problem". 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.
