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

[David Wagner]

Rick Wash  wrote:
>There are many legitimate uses of remote attestation that I would like to
>see.  For example, as a sysadmin, I'd love to be able to verify that my
>servers are running the appropriate software before I trust them to access
>my files for me.  Remote attestation is a good technical way of doing that.

This is a good example, because it brings out that there are really
two different variants of remote attestation.  Up to now, I've been
lumping them together, but I shouldn't have been.  In particular, I'm
thinking of owner-directed remote attestation vs. third-party-directed
remote attestation.  The difference is who wants to receive assurance of
what software is running on a computer; the former mechanism allows to
convince the owner of that computer, while the latter mechanism allows
to convince third parties.

If I understand correctly, TCPA and Palladium provide third-party-directed
remote attestation.  Intel, or Dell, or someone like that will generate
a keypair, embed it inside the trusted hardware that comes with your
computer, and you (the owner) are never allowed to learn the corresponding
private key.  This allows your computer to prove to Intel, or Dell, or
whoever, what software is running on your machine.  You can't lie to them.

In owner-directed remote attestation, you (the owner) would generate the
keypair and you (the owner) would learn the private key -- not Intel, or
Dell, or whoever.  This allows your computer to prove to you what software
is running on your machine.  However, you can't use this to convince Intel,
or Dell, or anyone else, what software is running your machine, unless they
know you and trust you.

I -- and others -- have been arguing that it is remote attestation that
is the key, from a policy point of view; it is remote attestation that
enables applications like DRM, software lock-in, and the like.  But this
is not quite right.  Rather, it is presence of third-party-directed remote
attestation that enables these alleged harms.

Owner-directed remote attestation does not enable these harms.  If I know
the private key used for attestation on my own machine, then remote attestation
is not very useful to (say) Virgin Records for DRM purposes, because I could
always lie to Virgin about what software is running on my machine.  Likewise,
owner-directed remote attestation doesn't come with the risk of software
lock-in that third-party-directed remote attestation creates.

So it seems that third-party-directed remote attestation is really where
the controversy is.  Owner-directed remote attestation doesn't have these
policy tradeoffs.

Finally, I'll come back to the topic you raised by noting that your
example application is one that could be supported with owner-directed
remote attestation.  You don't need third-party-directed remote
attestation to support your desired use of remote attestation.  So, TCPA
or Palladium could easily fall back to only owner-directed attestation
(not third-party-attestation), and you'd still be able to verify the
software running on your own servers without incurring new risks of DRM,
software lock-in, or whatever.

I should mention that Seth Schoen's paper on Trusted Computing anticipates
many of these points and is well worth reading.  His notion of "owner
override" basically converts third-party-directed attestation into
owner-directed attestation, and thereby avoids the policy risks that so
many have brought up.  If you haven't already read his paper, I highly
recommend it.  http://www.eff.org/Infra/trusted_computing/20031001_tc.php

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