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

2002-08-15 Thread Joseph Ashwood

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.

- Original Message -
From: Adam Back [EMAIL PROTECTED]
 Phew... the document is certainly tortuous, and has a large number of
 similarly and confusingly named credentials, certificates and keys,
 however from what I can tell this is what is going on:

I wholeheartedly agree. 332 pages to say 5 pages worth of real information
is not helpful.


 Summary: I think the endorsement key and it's hardware manufacturers
 certificate is generated at manufacture and is not allowed to be
 changed.
[Search criteria endorsement]
While I haven't found any solid evidence either way, they seem to almost
deliberately avoid that discussion on Page 22 I found a fatal errorcode
TCPA_NO_ENDORSEMENT at TCPA_BASE+35 The TPM does not a EK installed
attempting to interpret the bad grammar, I believe this should state The
TPM does not [have] an [Endorsement Key] installed which seems to indicate
that the platform may ship without one.

On page 35 the endorsement key is listed as persistent data. Which at first
would indicate that the endorsement key happens before shipping, but since
there is also an RNG state variable stored persistently, my confidence in
this is undermined. Adding to the complications, down near the end of the
page, in the table it says This is the TPM's endorsement key pair. See 9.2.
The default value is manufacturer-specific which indicates that it does
ship with an endorsement key, but that the key can be changed by the owner.

Page 38, the existance of the CBKPUsed flag hints that the endorsement key
pair need not always be present. Unfortunately the spec goes on to say
NOTE: This flag has no default value as the key pair MUST be created by one
or the other mechanism. Which certainly confuses things.

Page 41 TPM_CreateEndorsementKey may be called before TPM_Startup. This is
necessary because TPM_Startup will fail unless an endorsement key exists is
of no help either way. As with all the others, it states that there may
exist conditions where the EK may not exist, but does not give any hints
whether this is before or after the TPM leaves the plant.

On page 79, the EK is metioned twice. The first time if useless for our
purpose. The second time states This SHALL be the TPM endorsement
credential which indicates that an endorsement credential must exist. Other
locations though seem to hint that a void endorsement credential may be
possible.

Starting on Page 84 is section 4.32.1, which seems to be as close to an
authority on the EK as possible, but lacks a statement of whether the EK is
shipped with or added later. It does however clearly indicate that the
creation of the EK occurs before the Privacy CA is contacted, which was
already agreed on.

[somewhere around here I stopped addressing everyt occurance of the word
endorsement because most of them are frivolous]

Page 135, Section 5.11.1, clearly states The new owner MUST encrypt the
Owner authorization data and the SRK authorization data using the PUBEK.
Which clearly indicates that the EK must exist before ownership can be
taken. Other places have hinted that ownership may be taken and then the EK
updated, which completely contradicts the one-timeness, or this statement.

Page 135 If no EK is present the TPM MUST return TCPA_NO_ENDORSEMENT which
indicates that one can at least attempt to take ownership before an EK is
present, which would contradict the requirement that the EK come from the
factory.

Page 178, Section 7.3 I am only mentioning because it presents a rather
interesting possibility. It hints that under some circumstances it may be
acceptable for a manufacturer to copy the data from one TCPA to another.
This portion begins with The manufacturer takes the maintainance blob . .
. This may however only be to update an existing one to address flaws or
meet new capabilities.

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.

Page 213 section 8.10 clearly states that if the owner clears the TCPA,
everthing is cleared except the endorsement key pair. Which would indicate
that this is truly a one-shot deal.

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.

Section 9.2, page 261, states that TPM_CreateEndorsementKeyPair 

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

2002-08-15 Thread Adam Back

I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer).  For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not the endorsement key), so that apparent
conflict goes away.  (I originally thought this particular one was a
conflict also, until I noticed that.)  I see anonymous found the same
thing.

But anyway this extract from the CC PP makes clear the intention and
an ST based on this PP is what a given TPM will be evaluated based on:

http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-PP-TPM1_9_4.pdf

p 20:
| The TSF shall restrict the ability to initialize or modify the TSF 
| data: Endorsement Key Pair [...] to the TPM manufacturer or designee.

(if only they could have managed to say that in the spec).

Adam
--
http://www.cypherspace.org/adam/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]