Re: [TrouSerS-users] Load the key with Tspi_Context_LoadKeyByBlob

[Kent Y. <shp...@gm...>]

Hi Gong,

On 4/28/07, JG...@wi... <JG...@wi...> wrote:
> Hi, all
>
> After a series of experiments on my TPM today, I have some personal
> views now.
>
> The Tspi_Context_LoadKeyByBlob is successfully used in this way. We can
> get back the Key that we have created before.
> Tspi_Context_LoadKeyByUUID( hContext, TSS_PS_TYPE_SYSTEM,SRK_UUID, &hSRK
> );
> Tspi_GetPolicyObject( hSRK, TSS_POLICY_USAGE,&srkUsagePolicy );
> Tspi_Policy_SetSecret( srkUsagePolicy, TSS_SECRET_MODE_PLAIN,0, NULL );
> Tspi_Context_CreateObject( hContext,
> TSS_OBJECT_TYPE_RSAKEY,TSS_KEY_SIZE_2048 |TSS_KEY_TYPE_SIGNING
> |TSS_KEY_NOT_MIGRATABLE,&hMSigningKey );
> Tspi_Key_CreateKey( hMSigningKey, hSRK, 0 );
> Tspi_GetAttribData( hMSigningKey,
> TSS_TSPATTRIB_KEY_BLOB,TSS_TSPATTRIB_KEYBLOB_BLOB,&blobLength,
> &migratableSignKeyBlob );
> Tspi_Context_LoadKeyByBlob( hContext, hSRK,blobLength,
> migratableSignKeyBlob, &hKey );

  A slightly simpler way to load the key after calling
Tspi_Key_CreateKey is by calling Tspi_Key_LoadKey instead of
Tspi_GetAttribData then Tspi_Context_LoadKeyByBlob.

> However when I try the following steps, it will fail with the error
> code.
> 1. Create the key under SRK.
> 2. Get its attribute data.
> 3. Store the keydata into a file (key.txt).
> 4. Load the SRK with its policy.
> 5. Load the key by reading the key.txt data back.
>
> After I have studied the byte code sent to TPM. In my opinion, I think
> something used in the parent key authdata is dynamically changed with
> HMAC operation when we close a context and open another one. So if we
> want to load the former keydata info back to retrieve the key, it won't
> succeed.

  This is true, there is random data included in each auth session
with the TPM, but the key blob should be in the clear during a
LoadKeyByBlob, so you should be able to see if the key has been
corrupted between create and load.

> Is there anybody succeed in loading a key with reading the key data from
> another file?

  Yes, I believe several people have done this...

> Any opinions will be welcome!
>
> Best regards
> Gong Jun
>
>
> ===========================================================================================
> The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such  a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Winbond is strictly prohibited; and any information in this email irrelevant to the official business of Winbond shall be deemed as neither given nor endorsed by Winbond.
>


-- 
Kent Yoder
IBM LTC Security Dev.