dangers of TCPA/palladium

[Peter N. Biddle]

In-line

----- Original Message -----
From: "bear" <bear at sonic.net>
To: "AARG!Anonymous" <remailer at aarg.net>
Cc: <adam at cypherspace.org>; <cryptography at wasabisystems.com>
Sent: Tuesday, August 06, 2002 8:29 AM
Subject: Re: dangers of TCPA/palladium


>
>
> On Mon, 5 Aug 2002, AARG!Anonymous wrote:
>
> >> Anonymous writes:
> >> > And nobody's got the root key to my computer.  You make this claim
> >> > in many places in the document.  What exactly is this "root key" in
> >> > TCPA terms?  The endorsement key?  It's private part is generated
> >> > on-chip and never leaves the chip!
> >>
> >> The "root key" to your computing environment is the private key of the
> >> CA that signs the software updates.
> >
> >What software updates, exactly?  Spec reference?
>
> The TCPA hardware and Palladium Software make it possible.  It's not
> in the spec per se, but given the possibility, it will be done.

TCPA and Palladium are different.

> >I was talking about the optional TPM_FieldUpgrade function described on
> >page 251 of the spec.  It is apparently intended for bug fixes and such.
> >I doubt that there will be that many bug fixes, or that users will
> >install them that often.  And if an upgrade does obvious bad things
> >like the various despotic features you fear, keeping you from booting
> >Linux or whatever, people can avoid installing it.
>
> Uh-huh.  At the expense of their "trusted machine" status and causing
> every last bit of TCPA-disabled software they've got to quit operating
> correctly, and locking them out of their own confidential data which
> they've got stored in sealed areas on the machine.  To say that this
> gives them the choice to "avoid installing it" is at best fatuous.

In the Pd case your existing data will probably be sealed (provided you
decided to seal it) under the control of the current TOR. The TOR thus has
to agree to be upgraded in order to name a new TOR to receive it's secrets.
In the case of the MS TOR the decision to upgrade will be under the control
of the user. As the TOR will be highly reviewed and the source made
available, you can look at the it yourself (or talk with others who have
done so) and see that Pd can't be forced into an upgrade.

> Moreover, we're not that worried about *obvious* bad things... we're
> worried about very, very *subtle* bad things.  Keyboard sniffers, screen
> dumpers, web-cache readers, and other snoopware, if it has a "sealed"
> data space to hide its malicious code and stolen data, runs without a
> single detectable trace.  And, if it has an unmonitorable encrypted pipe
> to the outside world (which it gets every time someone
remote-authenticates
> your machine) it can deliver that stolen data to untrusted parties.
>
> The hardware supports installing such snoopware remotely as part of a
> "bug fix".  Nobody can tell whether the content of a "bug fix" is or
> isn't what's claimed.  Why should we assume that these businesses,
> *knowing that nobody can find out*, won't screw everybody to the max?

Pd explicitly negates the efficacy of keyboard sniffers, screen dumpers,
web-cache readers, and other related snoopware, but it only negates it for
new software. Existing software is backwards compatible, and thus continues
to run the way is always has. This means it doesn't gain or lose anything in
a Pd system.

Some options to if you are concerned about the trustworthiness of Pd SW
would be to only run code that:

has been made available for review to people you trust
    and/or
has certs from people you trust
    and/or
you have compiled yourself
    and/or
you wrote yourself

Of course making this a local policy is up to you; the TOR will enforce that
policy.

<snipped a bunch of TCPA specific stuff>

Peter
++++



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