Adam Back wrote: > 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.
A wild thought that occurs to me is that some mileage could be had by using remotely attested servers to verify _signatures_ of untrusted peer-to-peer stuff. So, you get most of the benefits of peer-to-peer and the servers only have to do cheap, low-bandwidth stuff. I admit I haven't worked out any details of this at all! Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ Available for contract work. "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff