Wan-Teh Chang wrote, On 2008-07-29 09:51: > NSS treats its own software crypto module (softoken) as a > PKCS #11 module.
... because it IS a PKCS#11 module. :) > NSS calls the functions of a PKCS #11 > module through function pointers. Here is an example: > http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11skey.c#1233 > > 1233 crv = PK11_GETTAB(slot)->C_Encrypt(session,data->data,data->len, > 1234 outKey->data, &len); > > PK11_GETTAB(slot)->C_Encrypt is a function pointer pointing > to the C_Encrypt function of 'slot'. Which will be either a pointer to NSC_Encrypt or FC_Encrypt, depending on which table of function pointers is being used. > Finally, let's see how NSS gets the table of function pointers > for its own softoken in FIPS mode. It looks up the FC_GetFunctionList > function by name and invokes the function: > http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11load.c#288 > > 286 if (mod->isFIPS) { > 287 entry = (CK_C_GetFunctionList) > 288 PR_FindSymbol(softokenLib, "FC_GetFunctionList"); > 289 } else { > 290 entry = (CK_C_GetFunctionList) > 291 PR_FindSymbol(softokenLib, "NSC_GetFunctionList"); > 292 } That's OK for NSS's PK11wrap code, but what about third party code that uses the PKCS#11 API directly according to the PKCS#11 spec? Neither of those labels (NSC_ or FC_) is defined in the spec. How is software like Sun's Java JCE provider, that is really a JNI wrapper for PKCS#11, that is supposed to work with any PKCS#11 module, supposed to get FIPS mode operation out of softoken without using non-standard entry points (at least for _GetFunctionList)? (I'm hoping the answer is not: it can't, it must call special entry points.) _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
