On Monday, February 14 at 12:22PM, jons...@terra.es wrote: > In the testing process of OpenDNIe I've found a problem related with > concurrent > access to opensc-pkcs11 library. > > In short: as DNIe can only handle one SM at a time (no virtual channel > support), > there is no (known) way to get concurrent pkcs11 access > > This "feature" makes unusable most of signing applets commonly used in many > official sites > > Afaik opensc-pkcs11 is thread/process aware, and non-sm based cards can > successfully > handle "n" processes without any problem noticed. but for DNIe, I need some > way > to "centralize" all SM task in a single process/thread
I am not very familiar with PKCS/11 and even less with OpenSC's implementation. But why don't you store the needed SM-data in the card's private data? This way each card handle has it's own SM context and could access the card with different SM parameters (if supported). If you think about sharing an SM context between different card handles, I think this is not a good idea. This would require you to establish an other mechanism to verify if access is allowed other than using the smart card. Such relaying is in general not a good idea. If you need to do it anyway, you could simply copy the SM context (the card's private data) to an other card handle. > I'm thinking on a sort of "SM daemon" to take care on apdu encoding/decoding Please have a look at victor's repository http://www.opensc-project.org/svn/opensc/branches/vtarasov/opensc-sm.trunk/ He uses relaying to a distant entity to encode/decode SM APDUs. This sounds pretty much like what you have in mind. Greets, Frank.
pgpx6rQRJbw2l.pgp
Description: PGP signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
