TCPA/Palladium user interst vs third party interest (Re: responding to claims about TCPA)

[Ben Laurie]

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