Hello, I am not trying answer the user's question (I believer previous posts already did), but I would like to straighten out some misconceptions here.
I should start by saying that a TPM's functionality is not equivalent to that of other hardware tokens, such as smart cards. A TPM only provides a subset of the functionality of a regular PKCS#11 token. A TPM, however, also providers things that PKCS#11 tokens don't deal with - measuring software components and remote attestation. Keys stored into the TPM may be bound to "trusted" software configurations of the local host. For example, a user running a compromised OS may not be able to access a key inside the TPM because the TPM considers the host's software untrusted. Many people have cried out that this can be used to lock data to particular software applications, but this is a different topic and we should not go into it. Trousers's PKCS#11 module uses a software-based PKCS#11 data store protected with a key hierarchy described in http://trousers.sourceforge.net/pkcs11.html. The root of this hierarchy a wrapped using a key generated and stored inside the TPM. Therefore, the PKCS#11 module mainly interacts with this software-based data store. For example, I believe that tpmtoken_import() imports key/cert pairs into the software-based data store, not into the TPM. The TPM simply doesn't have the capability to store certificates, sign CSR's etc. Neither can it export PKCS#12 items. It provides some PKCS#11-friendly functions, such as wrapping symmetric keys and a more secure random number generator, that Trousers' may directly use in its PKCS#11 module, but a lot of PKCS#11 functionality is not provided by the TPM and has to be implemented in software. Best Regards, Peter Djalaliev
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
