The remote attesation is the feature which is in the interests of third parties. I think if this feature were removed the worst of the issues the complaints are around would go away because the remaining features would be under the control of the user, and there would be no way for third parties to discriminate against users who did not use them, or configured them in given ways. The remaining features of note being sealing, and integrity metric based security boot-strapping. However the remote attestation is clearly the feature that TCPA, and Microsoft place most value on (it being the main feature allowing DRM, and allowing remote influence and control to be exerted on users configuration and software choices). So the remote attesation feature is useful for _servers_ that want to convince clients of their trust-worthiness (that they won't look at content, tamper with the algorithm, or anonymity or privacy properties etc). So you could imagine that feature being a part of server machines, but not part of client machines -- there already exists some distinctions between client and server platforms -- for example high end Intel chips with larger cache etc intended for server market by their pricing. You could imagine the TCPA/Palladium support being available at extra cost for this market. But the remaining problem is that the remote attesation is kind of dual-use (of utility to both user desktop machines and servers). This is because with peer-to-peer applications, user desktop machines are also servers. So the issue has become entangled. It would be useful for individual liberties for remote-attestation features to be widely deployed on desktop class machines to build peer-to-peer systems and anonymity and privacy enhancing systems. However the remote-attestation feature is also against the users interests because it's wide-spread deployment is the main DRM enabling feature and general tool for remote control descrimination against user software and configuration choices. I don't see any way to have the benefits without the negatives, unless anyone has any bright ideas. The remaining questions are: - do the negatives out-weigh the positives (lose ability to reverse-engineer and virtualize applications, and trade software-hacking based BORA for hardware-hacking based ROCA); - are there ways to make remote-attestation not useful for DRM, eg. limited deployment, other; - would the user-positive aspects of remote-attestation still be largely available with only limited-deployment -- eg could interesting peer-to-peer and privacy systems be built with a mixture of remote-attestation able and non-remote-attestation able nodes. Adam -- http://www.cypherspace.org/adam/ On Sat, Aug 10, 2002 at 04:02:36AM -0700, John Gilmore wrote:
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. [...]
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com