On 03/ 2/10 02:28 AM, Nikolay Elenkov wrote: > On 2010/03/01 21:01, Vladimir Kotal wrote: >> On 03/ 1/10 08:15 AM, Nikolay Elenkov wrote: > >>> I've been looking at the PKCS#11 engine and evaluating if we can use >>> it with a >>> specific HSM. It (mostly) works, but I've some questions about the >>> code. I hope >>> this is the right place to ask. I am using openssl-0.9.8l. Here goes. >> >> Sort of, crypto-discuss might be better place to ask this sort of >> questions. > > Thanks, I'll post there as well. BTW, this is the address for feedback in the > README.pkcs1.
Okay, I will talk to Jan to change it :) >> >> Are you using the patch or the libraries supplied with OpenSolaris ? > > I should have said before: I am using the patch. Right now I am testing on > Solaris 10 (not OpenSolaris), but it will eventually be used on Linux, I > think. Using custom OpenSSL libraries on (Open)Solaris is definitely not supported by Sun/Oracle so I will only respond to generic issues. As for the support of the patch itself I will let Jan to answer this one. >> >> Could you be more specific about the HSM ? > > Unfortunately not at this time. Its neither of the two originally supported by > the patch, it's from one of the major HSM vendors. Fair enough. What matters in the context of this discussion is whether it's plugged into Solaris Crypto Framework (as a provider). <snip> >> PKCS#11 engine does not supply its own primitives, that's all. >> > > It doesn't work with the HSM in question. And as far as the spec goes, > not passing NULL_PTR is equivalent to saying "I am not going to call this from > multiple threads". The PKCS#11 library detects this and returns an error. If > the > engine is not specifying its own primitives, it should at least set > CKF_OS_LOCKING_OK in CK_C_INITIALIZE_ARGS. In Solaris Crypto Framework, supplying pInitArgs set to NULL_PTR to C_Initialize() means to use internal locking primitives. See the following: http://docs.sun.com/app/docs/doc/816-4863/chapter2-9d?a=view http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/pkcs11/libpkcs11/common/pkcs11General.c#C_Initialize In overall, I think it's nothing against nothing :) By supplying NULL_PTR the app says it does not care about threads but by linking against SCF libraries it knows the threading will be handled well via internal functions so there is no need to supply its own locking functions. >>> Q2: Why does the engine call C_Destroy object on finalization? If I am >>> reading >> >> To prevent memory leaks. > > Well, destroying the private key is hardly the way to prevent memory leaks. > If, say, it were a smart card, with keys generated on the card, calling > C_DestroyObject will the destroy the only copy of the key on the card. And > that > is not good... But for non-token objects it does matter very much :) The key-by-ref project addresses this issue. >> You might want to use the PKCS#11 URI and key-by-reference handling for >> accessing tokens. See http://arc.opensolaris.org/caselog/PSARC/2009/555/ >> for details. > > > Yes, I've seen this. But keys are going to be generated by an external program > and used from another program linked with OpenSSL. Neither of those know about > key URI's, so we have to stick with 'simple' labels. AFAIK it works just fine with pktool(1) (or any other tool using PKCS#11 API via libpkcs11.so to generate the key). The URI will have the key label embedded in it so the C_Find*() ops will be able to find the key. >>> re-writing the code, of course). The 'SLOT' command seems like the >>> way to go, >> >> Which command are you referring to ? > > PK11_CMD_SLOT. I should have been more specifiy, command as in 'OpenSSL engine > command', not executable. Can't see this one in the current version of the patch "released" by Jan on his blog (http://blogs.sun.com/janp/entry/pkcs_11_engine_patch_including). It seems to be an artifact of the old PKCS#11 engine patch (which has number of problems related to threads, BTW). However this does not match with the README.pkcs11 reference above. What version of the patch are you using exactly ? >> >> AFAIK CK_SLOT_ID is always integer type. > > Not with our HSM though. BTW the spec says: 'CK_SLOT_ID is a Cryptoki-assigned > value that identifies a slot'; also: 'A priori, any value of CK_SLOT_ID can > be a > valid slot identifier'. So we cannot really expect it to be a simple slot > index > integer. and right below that it (v2.20rc3) says: It is defined as typedef CK_ULONG CK_SLOT_ID; and also: in particular, a system may have a slot identified by the value 0. So, I would tend to think that the "any value" is meant within the scope of the type, in this case CK_ULONG which is at least 32-bit integer type (chapter 5 of the spec). If there is anyone with serious PKCS#11 knowledge who thinks otherwise please correct me. v.
