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