Mike Rosing wrote: > Thanks Eugen, It looks like the IBM TPM chip is only a key > store read/write device. It has no code space for the kind of > security discussed in the TCPA. The user still controls the machine > and can still monitor who reads/writes the chip (using a pci bus > logger for example). There is a lot of emphasis on TPM != Palladium, > and TPM != DRM. TPM can not control the machine, and for DRM to work > the way RIAA wants, TPM won't meet their needs. TPM looks pretty useful > as it sits for real practical security tho, so I can see why IBM > wants those !='s to be loud and clear.
Note while Safford downplays remote attestation in the rebuttal paper, TCPA specs include remote attestation, which seems on the face of it mostly a DRM enabling feature. So I would say that Ross Anderson, Lucky and other detractors have it right despite this attempted rebuttal. It is true that the secure boot, key storage features are largely user beneficial features. He says "there is currently no CA, but it is unclear if this is the "privacy CA" or the "endoresement CA". In any case it may just be that early revisions of the software they haven't implemented this feature yet. He also mentions "no one asked for it" (the privacy CA to issue certificates for use with the remote attestation feature one presumes). He says you can turn of the endorsement feature. The main features of TCPA are: - key storage - secure boot - sealing - remote attestation the first 3 are user focussed features, and the last is DRM focussed. Sealing also interacts with remote attestation, in that it frustrates software only (as opposed to hardware hacking) attempts to later by pass restrictions imposed on download with remote attestation. Palladium is more flexible and secure in what it can enforce because of the ring-1 because it offers smaller attack surface (the TOR) instead of the whole kernel and all device drivers with TCPA. Safford also argues that it's not fair to critize TCPA based on DRM friendly features because it's tech neutral and anything can be used for good and bad (whatever your point of view). However I'd argue remote attestation as designed has no really plausible non-DRM use and could easily be dropped without loss of user functionality. There are other applications for remote attestation -- for example VPN server trying to assure security of client machines. However these types of applications can still be provided in ways that are useless for DRM -- eg retaining remote attestation but allowing the user with user present test to put the device in a "debug mode" where the bootstrap hashes don't match what is loaded. This kind of thing would be handy for debugging anyway and does not lose user security of remote attestation if it is only configurable via user present test. TCPA doesn't provide user present test (secure path to keyboard and screen as Palladium does), but there is a TCPA bios, and presumably that could have a flag and is (one hopes!) already design to not be software changeable. Similar arguments apply to the Palladium remote attestation function. MS has also made attempts to downplay DRM centric role of Palladium.
