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