Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

David Wagner daw at taverner.cs.berkeley.edu
Sat Jan 3 23:46:52 EST 2004

Jerrold Leichter  wrote:
>All of this is fine as long as there is a one-to-one association between
>machines and "owners" of those machines.  Consider the example I gave
>earlier:  A shared machine containing the standard distribution of the
>trusted computing software.  All the members of the group that maintain the
>software will want to have the machine attest, to them, that it is properly
>configured and operating as intended.

I think you may be giving up too quickly.  It looks to me like
this situation can be handled by owner-directed attestation (e.g.,
Owner Override, or Owner Gets Key).  Do you agree?

To see why, let's go back to the beginning, and look at the threat
model.  If multiple people are doing shared development on a central
machine, that machine must have an owner -- let's call him Linus.  Now
ask yourself: Do those developers trust Linus?

If the developers don't trust Linus, they're screwed.  It doesn't how
much attestation you throw at the problem, Linus can always violate their
security model.  As always, you've got to trust "root" (the system
administrator); nothing new here.

Consequently, it seems to me we only need to consider a threat model
where the developers trust Linus.  (Linus need not be infallible, but the
developers should believe Linus won't intentionally try to violate their
security goals.)  In this case, owner-directed attestation suffices.
Do you see why?  Linus's machine will produce an attestation, signed
by Linus's key, of what software is running.  Since the developers trust
Linus, they can then verify this attestation.  Note that the developers
don't need to trust each other, but they do need to trust the owner/admin
of the shared box.  So, it seems to me we can get by without third-party

This scenario sounds pretty typical to me.  Most machines have a single
owner.  Most machines have a system administrator (who must be trusted).
I don't think I'm making unrealistic assumptions.

>You're trying to make the argument that feature X (here, remote attestation for
>multiple mutually-suspicious parties) has no significant uses.  Historically,
>arguments like this are losers.

Yes, this is a fair point.  I suppose I would say I'm arguing that
feature X (third-party attestation) seems to have few significant uses.
It has some uses, but it looks like they are in the minority; for the
most part, it seems that feature X is unnecessary.  At the same time,
many people are worried that feature X comes with significant costs.

At least, this is how it looks to me.  Maybe I've got something wrong.
If these two points are both accurate, this is an interesting observation.
If they're inaccurate, I'd be very interested to hear where they fail.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com

More information about the cryptography mailing list