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. > > 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. > > 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. > >> Q1: Does the engine support being used from multiple threads? I've >> been looking > > Yes. > OK, >> at the C_Initialize calls, and all of them pass NULL_PTR as a >> parameter. That, >> according to the PKCS#11 spec, means: >> >> "The application ... will not be accessing the library concurrently from >> multiple threads, and so the library need not worry about performing any >> type of locking for the sake of thread-safety." >> >> So I guess we are not supposed to call it from multiple threads, is this >> correct? If we wanted to add multithread support, will supplying the >> right > > No. OpenSSL PKCS#11 engine works with threads just fine. ... > 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. >> 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... > > 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. > >> Q3: Is there a way to completely disable the automatic slot selection? >> (without > > Currently no. OK, thanks. > >> 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. > > 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. Thanks for your help, I will keep looking into this.
