dangers of TCPA/palladium

[Mike Rosing]

On Mon, 12 Aug 2002, AARG! Anonymous wrote:

> I don't believe that is an accurate paraphrase of what Mike Rosing said.
> He said the purpose (not effect) was to remove (not reduce) his control,
> and make the platform trusted to one entity (not "for the benefit of
> others").  Unless you want to defend the notion that the purpose of TCPA
> is to *remove* user control of his machine, and make it trusted to only
> *one other entity* (rather than a general capability for remote trust),
> then I think you should accept that what he said was wrong.

That does seem to be the purpose - but may not be what was planned - it
could simply be a "fortuitous accident".  There are way too many unknowns
really, so conjecture is all we've got to go on.  So far we know that
the guys writing Palldium are not happy with TCPA - it doesn't solve
their problems the way they like.  We know less about the TPM.  What's
"right" or "wrong" about vaporware is kind of hard to pin down.  There
are some basic conceptual things we do know, and we know there are already
commercial solutions to problems that TCPA claims to attempt to solve.

I'm working from what I know about those existing devices and project that
onto TCPA.  I may well be wrong, and hopefully somebody who's actually
building TCPA and TPM can give us concrete answers.

> And Mike said more than this.  He said that if he could install his own
> key into the TPM that would make it a very useful tool.  This is wrong;
> it would completely undermine the trust guarantees of TCPA, make it
> impossible for remote observers to draw any useful conclusions about the
> state of the system, and render the whole thing useless.  He also talked
> about how this could be used to make systems "phone home" at boot time.
> But TCPA has nothing to do with any such functionality as this.

I have to disagree.  If I control the content of the TPM, *I* can trust
it,  and anybody who trusts *me* can trust it too.  What other remote
observers of my system are there than the ones *I* trust?  Or to put
in another way - I only want remote observers that I trust to have the
ability to check my TPM.

This is what it all boils down to - "who is in charge of what?"  If I
create a fixed key, I can authenticate myself via multiple channels and
build trust to multiple and independent parties.  That is how TPM becomes
useful.

If somebody else controls the TPM, they may well *not* trust me, and they
may put my computer to work doing something I don't like.  In that case,
I can not trust my computer, because my computer does not trust me.  (I
said may, just because it's possible doesn't mean it will happen.)

What started this very long and interesting discussion was the fear
that TCPA is going to be mandated by law.  That is a very bad idea,
and as long as the fear is real, we need some very good arguments to
prevent it from happening.  The main one is economic, the secondary
one is that we don't need it - you can buy hardware that does the same
thing off the shelf and plug it in to any generic PC.

If the authors of Palladium want their software to work, they should
look at the commercial hardware security computing platforms already
available and get their stuff to work with it.  Ditch TCPA and get your
stuff on the market now, and see how people really deal with it.  It will
be an interesting experiment.

Patience, persistence, truth,
Dr. mike