TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)

[Mike Rosing]

On Thu, 15 Aug 2002, Joseph Ashwood wrote:

> This is going to be a very long, and very boring message. But it should
> highlight why we have differing opinions about so very many capabilities of
> the TCPA system. For the sake of attempting to avoid supplying too little
> information, I have simply searched for the term and will make comments on
> each location that it appears.

I actually read the whole thing.  Thanks for the effort.
I just want to focus in on one part for now.

> Page 183, hints that even the manufacturer is not allowed to known EK public
> key, which complicates things no end, because the Privacy CA certainly
> cannot at that point be permitted to view it. This would indicate that even
> if the EK is shipped with the system, it can never leave the system. This
> would limit the ability of the EK to simply certifying the owner, if that is
> true then it confuses me even further.

Then how can the manufacturer sign the endorsement key?  That can't make
any sense - is a misprint maybe and they mean the private key?

> Page 240, states "This is a dead TPM. It has failed it's startup smoke test.
> It should not leave the factory floor." This indicates that the EK must be
> created before the TPM leaves the factory.

What's the context of the "smoke test"?

> Section 9.2, page 261, states that TPM_CreateEndorsementKeyPair can only be
> called once, but does not state if this is done by the owner, or by the
> plant. Later on the page is a hint that it may be shipped with it. "The
> PRIVEK and PUBEK MAY be created by a process other than the use of
> TPM_CreateEndorsementKeyPair" and related statements, which indicate rather
> well that the endorsement key created before shipping. It also states that
> the credential could be stored after "an Owner has taken ownership of the
> platform," confusing the matter even more. Of course at the end of this
> section they change the mandatory return value for
> TPM_CreateEndorsementKeyPair (beginning TCPA_FAIL, end TCPA_DISABLED_CMD).

So the spec allows for a one time write option - the manufacturer
MAY build a list of keys.  But they don't have to.

> Result: I have no idea whatsoever about where/when the EK is created, there
> are a number of conflicting statements regarding it, and at least once where
> they even change the return value of a function.

Yeah, that makes discussion difficult.  Obviously the spec is
flawed!!

> > The creation and certification process is 1) create
> > endorsement key pair,
>
> > 2) export public key endorsement key,
>
> Only to the owner, the manufacturer is not supposed to have a copy

Then anyone can create a TPM?  What does the manufacturer
know about the thing it created?  If they know the endorsement key
(since they put it in) they can compute the public key.  If they
don't know either key, then anyone can create TPM's and get them
certified!!

I guess I can't argue with that :-)

> > 3)
> > hardware manufacturer signs endorsement public key to create an
> > endorsement certificate (to certify that that endorsement public key
> > belongs to this TPM), 4) the certificate is stored in the TPM (for
> > later use in communications with the privacy CA.)
>
> The privacy CA never recieves a copy of the PUBEK, the PUBEK is only to be
> seen by the owner.

If the manufacturer signs the endorsement pubkey, how can they
not see it?  I think there must be a lot of confusion in the
spec about which key does what and where it is used.  That's a
different kind of flaw, but clearly the spec has a lot of problems.

Keep hacking at it guys.  Maybe the authors will re-write it
so it makes sense (or give up and toss the whole thing in
the trash).

Patience, persistence, truth,
Dr. mike