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 [EMAIL PROTECTED]