(fwd) Re: dangers of TCPA/palladium

[Mike Rosing]

On Tue, 6 Aug 2002, Adam Back wrote:

> Response from Peter Biddle on cryptography list.  (I think he is a
> microsoft tech manager involved with palladium from a quick google).
>
> Adam
>
> ----- Forwarded message from "Peter N. Biddle" <peternbiddle at hotmail.com> -----
>
> From: "Peter N. Biddle" <peternbiddle at hotmail.com>
> To: "Cryptography" <cryptography at wasabisystems.com>
> Date: Mon, 5 Aug 2002 16:35:46 -0700
> The current TPM (version 1.1) doesn't have the primitives which we need to
> support Palladium, and the privacy model is different. We are working within
> TCPA to get the instruction set aligned so that Palladium and TCPA could use
> future silicon for attestation, sealing, and authentication, but as things
> stand today the approaches to the two of them are different enough so that
> TCPA 1.1 can't support Pd.

Wow.

> Confusion. The memory isn't encrypted, nor are the apps nor the TOR when
> they are on the hard drive. Encrypting the apps wouldn't make them more
> secure, so they aren't encrypted. The CPU uses HW protections to wall new
> running programs from the rest of the system and from each other. No one but
> the app itself, named third parties, and the TOR can see into this apps
> space. In fact, no one (should the app desire) can even know that the app is
> running at all except the TOR, and the TOR won't report this information to
> anyone without the apps permission. You can know this to be true because the
> TOR will be made available for review and thus you can read the source and
> decide for yourself if it behaves this way.

So the question remains - can an outside controller send an app to
the TOR such that the app does not report its existance to the user?
Possibly not, but if the TCPA hardware allows the link, then Palladium
is off the hook for being part of "the evil empire", and the empire wins
anyway.

> Correct enough for this thread; it is actually the TOR that will manage the
> keys for the apps, as this makes the concept of migration and data roaming
> far more manageable. (Yes, we have thought about this.)

And as long as the user has control of the TOR, that's not a problem.
But with TCPA, does the user still control the TOR?

> Comparing xBox and Pd isn't particularly fruitful - they are different
> problems and thus very different solutions. (Also note that xBox doesn't use
> the PID or any other unique HW key.)

Bummer :-)

> Palladium mostly doesn't care about the BIOS and considers it to be an
> untrusted system component. In Pd the BIOS can load any OS it wants, just
> like today, and in Pd the OS can load any TOR specified by the user. The MS
> TOR will run any app, as specified by the user. The security model doesn't
> depend on some apps being prevented from running.
>
> I believe that there isn't a single thing you can do with your PC today
> which is prevented on a Palladium PC. I am open to being challenged on this,
> so please let me know what you think you won't be able to do on a Pd PC that
> you can do today.

Basicly, MS's point of view is that Palladium is their baby, and they
need solutions to their problems.  TCPA is independent, if they can be
meshed, great (from MS's view), if they can't, so what!

> Palladium doesn't boot strap the OS. Pd loads a secure piece of SW, called
> the TOR, which runs in a secure space and loads other apps that want
> security. Anyone can load an app into this environment and get the full
> protections Pd offers. MS doesn't require that you show them the SW first -
> you wanna run, you get to run - provided the user wants you to run. If a
> user doesn't like the looks of your app, then you (the developer) have a
> problem with that user.

So long as that holds, seems ok.  But what about a virus that loads
into the TOR and tells the TOR "don't tell anyone I'm here".  Seems like
that could be a problem.

> MS will not have the root keys to the world's computers. The TOR won't have
> access to the private keys either. No one but the HW does. The TOR isn't
> "MS" per se - it is a piece of SW written by users but vetted and examined
> by hopefully thousands of parties and found to do nothing other than manage
> the local security model upon which Pd depends. You can read it and know it
> doesn't do anything but effectively manage keys and applications. And if you
> don't trust it, you won't run it.
>
> If you don't trust the TOR, you don't trust Palladium. Trust is the *only*
> feature we are attempting to achieve, so every decision we make will be made
> with trust and security in mind.

then I hope they move slowly and carefully.  People don't trust
microsoft much.

> This is a problem anyone who wants to compete in the security and trust
> space will need to overcome. I don't think that it is particularly new or
> different in a world with Pd. Writing a TOR is going to be really hard and
> will require processes and methods that are alien to many SW developers. One
> example (of many) is that we are generating our header files from specs. You
> don't change the header file, you change the spec and then gen the header.
> This process is required for the highest degrees of predictability, and
> those are cornerstones for the highest degree of trust. Unpredictable things
> are hard to trust.

This implies that anyone can write a TOR as part of their app???
Now I'm really confused!

> Everything in the TCB (Trusted Computing Base) for Pd will be made available
> for review to anyone who wants to review it;  this includes software which
> the MS TOR mandates must be loaded.

I'll believe it when I see it :-)

> This doesn't happen in Pd. There is no secure boot strap feature in Pd. The
> BIOS boots up the PC the same way it does today. Root control is held by the
> owner of the machine. There is no certification master key in Pd.

OK, that's where TCPA becomes a problem.

> I know that we aren't using undocumented API's and that we will strive for
> the highest degree of interoperability and user control possible. Pd
> represents massive de-centralization of trust, not the centralization of it.
>
> I think that time is going to have to tell on this one. I know that this
> isn't true. You think that it is. I doubt that my saying it isn't true is
> going to change your mind; I know that the technology won't do much of what
> you are saying it does do, but I also know that some of these things boil
> down to suspicion around intent, and only time will show if my intent is
> aligned with my stated goals.

Right on.  If you guys want people to trust palladium, you better get the
discussion out in the open in a hurry.  The level of confusion is now
high enough to sink it.

> Pd does not give root control of your machine to someone else. It puts it
> into your hands, to do with as you so desire, including hacking away at it
> to your hearts content.

That would be good :-)

> I think that Pd represents an enhancement to personal freedoms and user
> control over their machines. I hope that over time I will be able to explain
> Pd sufficiently well so that you have all the facts you need to understand
> how and why I say this.

MS will need a "paradigm shift" in how they market things to get
that point across.  Good luck!

Patience, persistence, truth,
Dr. mike