Menu
▾
▴
trustedjava-support
|
From: Arshad N. <ars...@st...> - 2009-09-16 04:35:49
|
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. |
|
From: Ronald T. <ron...@ia...> - 2009-09-16 08:07:45
Attachments:
smime.p7s
|
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. -- Dipl.-Ing. Ronald Tögl phone +43 316/873-5502 Trusted Computing Labs fax +43 316/873-5520 IAIK ron...@ia... Graz University of Technology http://www.iaik.tugraz.at |
|
From: Arshad N. <ars...@st...> - 2009-09-16 15:04:38
|
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. > > |
|
From: Arshad N. <ars...@st...> - 2009-09-17 02:25:18
|
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 |
