Re: Question about multiple applications

One more comment.

It should also be possible to use ScardEndTransaction() with SCARD_RESET_CARD or SCARD_UNPOWER_CARD
at the end of the C_InitToken transaction.


On 12/28/2018 7:20 AM, Douglas E Engert wrote:
> I will deffer to others on the use critical section. But it my understanding that opensc locking is meant
> for a single process. There is no intent to do a global lock across other processes in the system. PCSC is
> used to do that.
> 
> I still contend that what you may be seeing is Application A that just did a C_InitToken should
> do a SCardDisconnect() with SCARD_RESET_CARD or SCARD_UNPOWER_CARD so other applications that are waiting
> for an event will be notified by PCSC that a reset was done.
> 
> reader-pcsc.c in pcsc_disconnect() has:
> 606 if (!priv->gpriv->cardmod && !(reader->ctx->flags & SC_CTX_FLAG_TERMINATE)) {
> That may be the problem on windows.
> 
> opensc.conf also has "disconnect_action = leave|reset|unpower;" but what is missing is a way to do a
> SCARD_RESET_CARD or SCARD_UNPOWER_CARD only in special situations such as C_InitToken. And all the
> actions required to do C_InitToken need to be done under one transaction or the session needs to be
> exclusive rather then shared.
> 
> 
> 
> On 12/27/2018 10:00 PM, Bob Backlund wrote:
>> Hi Douglas,
>>
>> Thank you for your reply.
>>
>> I understand that the "OpenSC PKCS#11 relies on the PCSC layer to lock access" but I think the issue lies on the lock used for the Windows system, on the pkcs11-global.c, I can see that the type of 
>> lock used is Critical Section as opposed to Mutex. It was mentioned on the Microsoft documentation that ;
>> /A critical section object provides synchronization similar to that provided by a mutex object, except that a critical section can be used *only by the threads of a single process*. Critical section 
>> objects *cannot be shared across processes*.
>> /
>>
>> Correct me if I'm wrong, but I think, to be able to handle "multiple applications" we may need to use Mutex instead of the default Critical Section. If that is the case how am able to do it in the 
>> OpenSC layer, do I just change the implementation to use Mutex instead of Critical Section (by changing the flow in the function pointer)?
>>
>> I am not sure if what I am saying makes sense, my apologies if this is something I over complicate.
>>
>> I appreciate your help on this.
>>
>> *Source: https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects*
>>
>>
>> Thanks,
>>
>> Jared
>>
>> On Wed, Dec 19, 2018 at 9:05 PM Douglas E Engert <[email protected] <mailto:[email protected]>> wrote:
>>
>>     The OpenSC PKCS#11 relies on the PCSC layer to lock access to the card across multiple applications.
>>
>>     https://github.com/OpenSC/OpenSC/wiki/PCSC-and-pcsc-lite
>>
>>     http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
>>
>>     https://docs.microsoft.com/en-us/windows/desktop/secauthn/smart-card-and-reader-access-functions
>>
>>     In regards to one application modifying the card while another application is waiting for events,
>>     the event will contain a SCARD_W_* return.
>>
>>     The application (A) that modified the card in such a drastic way should do a card reset,
>>     that will cause the the event returned to (B) will cause (B) to start over.
>>
>>     https://docs.microsoft.com/en-us/windows/desktop/SecAuthN/authentication-return-values
>>
>>     Doing do a C_InitToken is like formatting your hard drive. Most applications can not copy with this.
>>     In other words don't do it while other applications are running.
>>
>>
>>     On 12/18/2018 9:06 PM, Bob Backlund wrote:
>>      > Hi,
>>      >
>>      > Just some question about how the OpenSC PKCS# 11 (DLL) handles the multiple applications using it.
>>      >
>>      > The scenario is I have two applications, application A and application B loading the same DLL.
>>      >
>>      > Application B loops continuously, calling C_WaitForSlotEvent and C_GetTokenInfo, basically it just checks for the insert and remove events from the smart card.
>>      >
>>      > Application A can call C_InitPIN and C_InitToken.
>>      >
>>      > The conflict happens when, while the application B is checking for smart card events, application A then calls C_InitToken, which deletes the smart card contents, and formats it to be a new
>>     card, (and
>>      > possibly deleting the PKCS# 15 objects) and the next call to C_OpenSession fails returning CKR_TOKEN_NOT_PRESENT error.
>>      >
>>      > When I try to check the logs, the state of the smart card become ABSENT , I can see this during the C_InitToken, when sc_detect_card_presence is called.
>>      >
>>      > When I try to run application A, and call C_InitToken without the application B running, I do not encounter this issue, and the smart card does not become ABSENT but instead I can see from the
>>     logs
>>      > that its state become CHANGED.
>>      >
>>      > I am not sure if this is the expected behavior or where or how I should handle it. I am not sure if this is also an issue on the OpenSC PKCS# 11 DLL or the smart card. I tried to look at the
>>     available
>>      > documentation but couldn't find an answer to this,
>>      >
>>      > Your expert opinion is greatly appreciated.
>>      >
>>      >
>>      > Thanks,
>>      >
>>      > fightingsibuyas
>>      >
>>      >
>>      > _______________________________________________
>>      > Opensc-devel mailing list
>>      > [email protected] <mailto:[email protected]>
>>      > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>      >
>>
>>     --
>>        Douglas E. Engert  <[email protected] <mailto:[email protected]>>
>>
>>
>>
>>     _______________________________________________
>>     Opensc-devel mailing list
>>     [email protected] <mailto:[email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
> 

-- 

  Douglas E. Engert  <[email protected]>



_______________________________________________
Opensc-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensc-devel