El jue, 17-02-2011 a las 16:50 +0100, Frank Morgner escribió: > 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.
(from a previous mail from Douglas) > Does the card impose some CKA_ALWAYS_AUTHENTICATE restriction, such as > the PIN must be presented before each crypto operation for some > private key, with no intervening operations? Yes: DNIe enforces user authentication before any access to any object stored in card) > > 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). Sorry I can't: AFAIK DNIe is "read only", at least at user level Ideally, virtual channels should be used, but not enought documentation on card to make sure that DNIe supports them. Need to test... So cannot store sm context in card > 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 know. I was thinking on a SM daemon connected to opensc by mean of Unix Domain sockets (that can handle user permissions byself) to assure that only one user can access to encoding daemon. But this solution is not portable to Windows > > 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. I'll take a look. Actually I know about 4 different approaches - Use virtual channels. But need to test for feature availability on DNIe card - Handle SM channel at pcsc -or ccid- level. (too complicated for me) - Find a way to share sm context to all applications that concurrently try to access the card - Convince every one to stop using signing applets, and just work with Firefox's "crypto.signText()" funcion :-). But this does still makes collide firefox with other apps (ie: openoffice) ¿Ideas? BTW. Martin told me about trying to find a portable, simple, no external libraries dependent way to ask user for PIN or Signature Confirmation as a previous task for DNIe integration into OpenSC Mainstream. Anyone working on this? Volunteers? :-) Juan Antonio
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
