example: secure computing kernel needed

[Ed Reed]

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 <waa at cs.umd.edu> 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
majordomo at metzdowd.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com