For the general question (I know the TPM very well): After just the "createwrapkey" command, there is no way to prove that the key was created in a hardware TPM. I have a TPM software simulator, and the key could have been created there.
You need more of a protocol: Read (nv_readvalue) the EK certificate where the TPM vendor certifies that the EK is in a hardware TPM. This is your security root. You have to trust the TPM vendor, and you get the TPM vendor CA certificate out of band. Make an identity key (makeidentity) and use activateidentity to prove that the identity key is in the TPM. Create (createwrapkey) your key. Have the identity key certify (certifykey) that your key is non-migratable. At the end, you have your key and a certificate chain back to the TPM vendor CA certificate. For the specific trousers questions (I am not a trousers expert) There are several parts to the TSS: The upper layer is per application. The next layer (tcsd) is a daemon process, one per TPM, that schedules applications. The communication between the application layer and tcsd is some sort of RPC. In the tcsd, there is a transmit function that talks to the TPM device driver. tcsd can also talk to the software TPM, which I recommend for debugging. On 7/28/2015 11:53 AM, Julie P wrote: > I'm a student in internship and one of my tasks is to PROVE that : > 1) when we create a key via "create_tpm_key.c" (from the > libengine-openssl), it's really generated from the TPM and inside the TPM > 2) and that the SRK and the key - during it's creation 1) - are not > visible/readable in memory (I guess mutex is not enough?) ------------------------------------------------------------------------------ _______________________________________________ TrouSerS-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/trousers-users
