search

PeculiarVentures / webcrypto-local

webcrypto-local is a cross platform service that provides access to PKCS#11 implementations over a protocol we call webcrypto-socket.
https://peculiarventures.github.io/webcrypto-local/
MIT License
18 stars 13 forks source link

Multi sessions for pkcs11 modules #14

Open microshine opened 7 years ago

microshine commented 7 years ago

@rmhrisk

I've got some problems with opening multi sessions for one PKCS#11 token.

SoftHSM module throws error Error: CKR_USER_ALREADY_LOGGED_IN:256 Yubico module throws error Error: CKR_SESSION_COUNT:177

node-webcrypto-p11 uses

const mod = graphene.Module.load()
mod.initialize()

I can't use initialize twice for one module, even I use Module.load for each time. Because JS load native module only once.

To fix it we have to load native in its own thread for each new Module.load

if we use current version of node-webcrypto-p11, then user can enter PIN only once and use this PKCS11 session for each 2key session.

microshine commented 7 years ago

PKCS#11 spec v.2.3

CK_RV C_Initialize ( CK_VOID_PTR pInitArgs ) ;

C_Initialize initializes the Cryptoki library.

Parameters: pInitArgs either has the value NULL_PTR or points to a CK_C_INITIALIZE_ARGS structure containing information on how the library should deal with multi-threaded access. If an application will not be accessing Cryptoki through multiple threads simultaneously, it can generally supply the value NULL_PTR to C_Initialize (the consequences of supplying this value will be explained below). If pInitArgs is non-NULL_PTR, C_Initialize should cast it to a CK_C_INITIALIZE_ARGS_PTR and then dereference the resulting pointer to obtain the CK_C_INITIALIZE_ARGS fields CreateMutex, DestroyMutex, LockMutex, UnlockMutex, flags, and pReserved. For this version of Cryptoki, the value of pReserved thereby obtained must be NULL_PTR; if it's not, then C_Initialize should return with the value CKR_ARGUMENTS_BAD. If the CKF_LIBRARY_CANT_CREATE_OS_THREADS flag in the flags field is set, that indicates that application threads which are executing calls to the Cryptoki library are not permitted to use the native operation system calls to spawn off new threads. In other words, the library's code may not create its own threads. If the library is unable to function properly under this restriction, C_Initialize should return with the value CKR_NEED_TO_CREATE_THREADS.

A call to C_Initialize specifies one of four different ways to support multi-threaded access via the value of the CKF_OS_LOCKING_OK flag in the flags field and the values of the CreateMutex, DestroyMutex, LockMutex, and UnlockMutex function pointer fields:

If the flag isn't set, and the function pointer fields aren't supplied (i.e., they all have the value NULL_PTR), that means that the application won't be accessing the Cryptoki library from multiple threads simultaneously.

If the flag is set, and the function pointer fields aren't supplied (i.e., they all have the value NULL_PTR), that means that the application will be performing multi-threaded Cryptoki access, and the library needs to use the native operating system primitives to ensure safe multi-threaded access. If the library is unable to do this, C_Initialize should return with the value CKR_CANT_LOCK.

If the flag isn't set, and the function pointer fields are supplied (i.e., they all have non-NULL_PTR values), that means that the application will be performing multi-threaded Cryptoki access, and the library needs to use the supplied function pointers for mutex-handling to ensure safe multi-threaded access. If the library is unable to do this, C_Initialize should return with the value CKR_CANT_LOCK.

If the flag is set, and the function pointer fields are supplied (i.e., they all have non-NULL_PTR values), that means that the application will be performing multi-threaded Cryptoki access, and the library needs to use either the native operating system primitives or the supplied function pointers for mutex-handling to ensure safe multi-threaded access. If the library is unable to do this, C_Initialize should return with the value CKR_CANT_LOCK.

If some, but not all, of the supplied function pointers to C_Initialize are non-NULL_PTR, then C_Initialize should return with the value CKR_ARGUMENTS_BAD. A call to C_Initialize with pInitArgs set to NULL_PTR is treated like a call to C_Initialize with pInitArgs pointing to a CK_C_INITIALIZE_ARGS which has the CreateMutex, DestroyMutex, LockMutex, UnlockMutex, and pReserved fields set to NULL_PTR, and has the flags field set to 0.

C_Initialize should be the first Cryptoki call made by an application, except for calls to C_GetFunctionList. What this function actually does is implementation-dependent; typically, it might cause Cryptoki to initialize its internal memory buffers, or any other resources it requires.

If several applications are using Cryptoki, each one should call C_Initialize. Every call to C_Initialize should (eventually) be succeeded by a single call to C_Finalize. See Section 6.6 for more details.