Remote attestation has use in applications requiring accountability of the user, as a way for cooperating processes to satisfy themselves that configurations and state are as they're expected to be, and not screwed up somehow. There are many business uses for such things, like checking to see if locked down kiosk computers have been modified (either hardware or software), verifying that users have not excercised their god-given right to install spy-ware and viruses (since they're running with administrative priviledges, aren't they?), and satisfying a consumer that the server they're connected to is (or isn't) running software that records has adequate security domain protections to protect the users data (perhaps backup files) the user entrusts to the server. What I'm not sure of is whether there are any anonymous / privacy enhancing scenarios in which remote attestation is useful. Well, the last case, above, where the server is attesting to the client could work. But what about the other way around. The assumption I have is that any remote attestation, even if anonymous, still will leave a trail that might be used by forensic specialists for some form of traffic analysis, if nothing else. In that case, you'd need to "trust" your "trusted computing system" not to provide remote attestation without your explicit assent. I'd really like to see an open source effort to provide a high assurance TPM implementation, perhaps managed through a Linux 2.6 / LSM / TPM driver talking to a TPM module. Yes, the TPM identity and integrity will still be rooted in its manufacturer (IBM, Intel, Asus, SiS, whomever). But hell, we're already trusting them not to put tcpstacks into the BIOS for PAL chips to talk to their evil bosses back in [fill in location of your favorite evil empire, here]. Oh, wait a minute - Phoenix is working on that, too, aren't they? I see the TPM configuration management tool as a way to provide a trusted boot path, complete with automagical inventory of "approved" hardware devices, so that evaluated operating systems, like Solaris and Linux, can know whether they're running on hardware whose firmware and circuitry are known (or believed) not to have been subverted, or to have certain EMI / Tempest characteristics. Mass market delivery of what are ususally statically configured systems that still retain their C2/CC-EAL4 ratings. But more important is where TPM and TCPA lead Intel and IBM, towards increasing virtualization of commodity hardware, like Intel's LeGrand strategy to restore a "trusted protection ring" (-1) to their processors, which will make it easier to get real, proper virtualization with trusted hypervisors back into common use. The fact that Hollywood thinks they can use the technology, and thus they're willing to underwrite its development, is fortuitous, as long as the trust is based on open transparent reviews and certifications. Maybe the FSF and EFF will create their own certification program, to review and bless TPM "ring -1" implementations, just to satsify the slashdot crowd... Maybe they should. Ed
>>> William Arbaugh <[EMAIL PROTECTED]> 12/18/2003 5:33:00 PM >>> On Dec 16, 2003, at 5:14 PM, David Wagner wrote: > Jerrold Leichter wrote: >> We've met the enemy, and he is us. *Any* secure computing kernel >> that can do >> the kinds of things we want out of secure computing kernels, can also >> do the >> kinds of things we *don't* want out of secure computing kernels. > > I don't understand why you say that. You can build perfectly good > secure computing kernels that don't contain any support for remote > attribution. It's all about who has control, isn't it? > > There is no control of your system with remote attestation. Remote attestation simply allows the distant end of a communication to determine if your configuration is acceptable for them to communicate with you. As such, remote attestation allows communicating parties to determine with whom they communicate or share services. In that respect, it is just like caller id. People should be able to either attest remotely, or block it just like caller id. Just as the distant end can choose to accept or not accept the connection. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
