Thx a lot,

But what if I just want to "hardcode" the use of another token, without any ability to choose the one sdr should use? My first idea was to replace slot = GetInternalModule() by slot = GetSlotByName(const char * name); because they're declared to be of the same type/struct. The first ist named "get...Module", the second "get... Slot", so I guess this is maybe because the internal module has just one slot with one token attached?

Another idea would be to replace the internal token by an Opencryptoki - token (IBM Trousers-> TPM), if available. Check if available, if no, use software token, if yes, use opencryptoki->Trousers->TPM by default, without the ability to choose. By default, use Opencryptoki/the TPM. If there is none, continue to use the NSS software one. That would be transparent and older applications would still work, if there's no need to choose a token, and if the app doesn't use pkcs11 functions that are not implemented in trousers.

At that point, my goal is to achieve that the tpm takes care of my keys instead of NSS's softtoken, in the simplest possible way, so mozStorage uses tpm-protected keys to encrypt/decrypt in Firefox. I wonder if it would be a better idea to use IBM's Trousers API inside the softtoken-libraries instead of trying to use pkcs11/opencryptoki to access the TPM via Trousers with NSS, and replace the softtoken. So I wouldn't have to fix anything in NSS, just tell the softtoken to use the API to "hide" its keys in the TPM if one is available. What do you think? Which way would be the fastest/simplest to implement?


Marc





"Robert Relyea" <[email protected]> schrieb im Newsbeitrag news:[email protected]...
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to