TCPA/Palladium user interst vs third party interest (Re: responding to claims about TCPA)
Ben Laurie
ben at algroup.co.uk
Wed Aug 14 12:49:58 PDT 2002
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
More information about the Testlist
mailing list