Re: [Trustedjava-support] Difference in createKey() for Binding vs Signing keys

[Arshad N. <ars...@st...>]

Thanks for the response, Ronald.

I do have the key-hierarchy set reasonably correctly, I believe.
There is an SRK which is the root of the non-migratable signing
key as well as the migratable Binding Key.  The only difference
is that I've set the SRK to have a real password as opposed to
the TSS_WELL_KNOWN_SECRET.

The TPM Usage policy (with the owner's password) is assigned to
the TPM; the RK Usage policy (with its password) is assigned to
the SRK before the keys are generated.  Each of the new keys has
their Usage policy and password assigned to their containers
before the createKey(srk, null) method is called.

This works correctly without the pop-up for the Binding key but
not for the signing key.  I can even generate a migratable
Storage key (with the SRK as its parent) without the pop-up.
That is what puzzles me.  However, I will read the chapter again
in the book you suggested.  Thanks.

(As an aside, while I realize that each new key - Storage, Signing
and Binding - will have their Usage and Migration policies/passwords
typically established before the keys are generated, I fail to
understand why it is permissible for the SRK to have a "well known
secret".  Any rationalization for this?  Thanks).

Arshad Noor
StrongAuth, Inc.



Ronald Tögl wrote:
> Hi,
> 
> First of all, there should not be a difference - I do not understand why 
> it is there and will look into this.
> 
> Second: Your key hierarchy is not correct. The TPM owner authorisation 
> is only needed for a few restricted operations, not for everyday 
> application key creation.
> 
> A pop-up will always appear if a policy to some object is missing. The 
> root for key creation should be the Storage Root Key, which needs to be 
> designated as parent at key creation. Here you need to have the SRK 
> object with the proper usage policy (by convention using 
> TSS_WELL_KNOWN_SECRET) assigned.
> 
> A good reading on how to handle TPM keys is
> "A Practical Guide to Trusted Computing" by David Challener; Kent Yoder; 
> Ryan Catherman; David Safford; Leendert van Doorn
> 
> hth,
> Ronald
> 
> Arshad Noor wrote:
>> Hi,
>>
>> Is there a reason why the creation of a Signing key-pair always
>> prompts for the TPM Owner's password through a pop-up even though
>> the password is set in a BlobData structure and the Usage policy
>> for the TPM (set with the TPM Owner's password) is assigned to the
>> TPM?  The signing keys are set to be non-migratable.
>>
>> This behavior is markedly different from creating migratable Binding
>> keys where the same secret and policy settings do not prompt for the
>> TPM Owner's password.
>>
>> Any pointers to an explanation, and a suggestion for how to avoid
>> the pop-up for the signing-key creation, would be appreciated.
>> Thanks.
>>
>> Arshad Noor
>> StrongAuth, Inc.
> 
>