Re: [TrouSerS-users] TrustedJava and PrivacyCA.com

[Carolin L. <car...@un...>]

Sorry,
 
the subject is misleading... I do not use TrustedJava with
Privacy.com... I use TrustedJava with the Java Privacy CA (having the
behavior described below)

Carolin

Carolin Latze wrote:
> BTW:
>
> Till now I work with Trusted-Java to obtain my AIK certificates. Using
> Trusted Java, one may chose between using only the Java implementation
> or use Java on top of trousers. If I obtain the AIK without starting
> tcsd, everything works fine. But if I start tcsd and use Java on top of
> it to retrieve the AIK I run into the same problem... So there should be
> difference in the Java-only implementation of the TSS and trousers,
> which causes this error... Perhaps, Martin from TrustedJava has an idea?
>
> Regards
> Carolin
>
> Carolin Latze wrote:
>   
>> Hi Hal,
>>
>> I have no important data on my test machines, so I will try to do what
>> you suggest. As I don't have time this week, I'll do it next week and
>> write whether I was successful or not.
>>
>> Thanks
>> Carolin
>>
>> Hal Finney wrote:
>>   
>>     
>>> Carolin, if you have a chance, take a look at
>>> /usr/local/var/lib/tpm/system.data and dump out the 1st few hundred
>>> bytes in hex. Compare it with what you get if you dump the
>>> system.data.auth and system.data.noauth files in the Trousers dist/
>>> directory. Here are hex dumps of those two files:
>>>
>>> system.data.auth:
>>>
>>> 00000000  01 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> 00000010  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> 00000020  00 00 00 00 00 00 01 2f  01 00 00 00 00 03 00 00  |......./........|
>>> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> *
>>> 00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
>>> 00000130  01 00 06 00 11 00 00 00  00 01 00 00 00 01 00 03  |................|
>>> 00000140  00 01 00 00 00 0c 00 00  08 00 00 00 00 02 00 00  |................|
>>> 00000150  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
>>> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> *
>>> 00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00        |..............|
>>> 0000025e
>>>
>>> system.data.noauth:
>>>
>>> 00000000  01 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> 00000010  00 00 00 00 01 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> 00000020  00 00 00 00 00 00 01 2f  01 00 00 00 00 03 00 00  |......./........|
>>> 00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> *
>>> 00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
>>> 00000130  01 00 06 00 11 00 00 00  00 00 00 00 00 01 00 03  |................|
>>> 00000140  00 01 00 00 00 0c 00 00  08 00 00 00 00 02 00 00  |................|
>>> 00000150  00 00 00 00 00 00 00 00  01 00 00 00 00 00 00 00  |................|
>>> 00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
>>> *
>>> 00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00        |..............|
>>> 0000025e
>>>
>>> The only difference is the 9th byte on the line labeled 00000130. It
>>> is a 01 in system.data.auth, meaning that the SRK requires
>>> authorization, and a 00 in system.data.noauth, meaning that the SRK
>>> does not require authorization. It looks to me from those dumps you
>>> sent that your emulator machine thinks the SRK is no-auth. If you
>>> could dump out /usr/local/var/lib/tpm/system.data then that would be a
>>> helpful clue as to whether this is happening. If so, then assuming
>>> that your SRK on that machine actually does require an auth value, you
>>> could copy dist/system.data.auth onto
>>> /usr/local/var/lib/tpm/system.data and see if that helps. This would
>>> erase any keys you had stored in the system repository, so hopefully
>>> you don't have anything important there.
>>>
>>> Hal
>>>   
>>>     
>>>       
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> TrouSerS-users mailing list
>> Tro...@li...
>> https://lists.sourceforge.net/lists/listinfo/trousers-users
>>   
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> TrouSerS-users mailing list
> Tro...@li...
> https://lists.sourceforge.net/lists/listinfo/trousers-users
>