From: Thomas W. <tc...@to...> - 2007-08-20 09:17:50
|
Hello, > Yes, the SRK secret is currently hardwired in JTT to TSS_WELL_KNOWN_SECRET, > this should be a command line option. However, if the SRK secret is wrong > the error would come from the TPM layer during CollateIdentity (because > loading of the key fails) Well - hardwired is probably not the right word. The default is TSS_WELL_KNOWN_SECRET but you can override it using the "-s" command line parameter. > These are two different things, the secret used for the key itself and > the hashing used for securing the communication with the TPM. Correct. However, there are some pitfalls behind the scenes. In TPM emulator there are some issues with the LoadKey2 function. jTSS therefore detects the emulator and falls back to the LoadKey function. This has been tested and is known to work. > It is the duty of both communication endpoints, TPM and TSS to check > whether the exchange has been tampered with. If you just override > the check in the TSS, well, of course it always works. Exactly. One way to debug this problem is to add debut statements to the TcTspInternal.TspLoadKeyByBlob_Internal method. You could do hexdumps of the data being sent to the TPM and received from the TPM and compare this data to the TPM spec. > There is still no hint why it fails for you. > TPMemu 0.5 + JTss 0.3, ok. > Java version? > 32bit or 64bit Linux? > Which Linux? GCC version? ... > Maybe we can spot a difference... Yes, a full list describing your setup would be helpful. Regards, -- Thomas Winkler e-mail: tc...@to... |