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

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

I've gotten past this issue, Ronald.

When generating a non-migratable signing key-pair, I was NOT
creating and assigning a Migration Policy to the key object
since it is a non-migratable key.  For some reason this caused
the pop-up for the Owner's password to appear.

When I create and assign a Migration Policy to the non-migratable
signing key, the pop-up does not appear and the key is generated.
I'm not sure if this is a bug in JTSS or some convoluted logic
in the TCG specifications which I fail to understand (why assign
a migration policy to a non-migratable key?).

Thanks for your help, though.

Arshad Noor
StrongAuth, Inc.

Arshad Noor wrote:
> 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.
>>
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Trustedjava-support mailing list
> Tru...@li...
> https://lists.sourceforge.net/lists/listinfo/trustedjava-support