exclusive vs. shared smart card access

[Andreas Schwier]

It's OK to claim exclusive access to a smart card during a session, but
the software must release access if it's no longer needed.

This is not the case with scdaemon that keeps the card locked as long as
it runs, effectively blocking access from other applications.

There is a DISCONNECT in scdaemon, but no application is really using
it. Asking the user to terminate scdaemon before any other application
can access the card is not a good user experience.

And the one application controlling access to the card is the PC/SC
daemon and *not* scdaemon. scdaemon is *one* of the applications
accessing the card via PC/SC.

Andreas


On 09/01/2015 03:29 AM, NIIBE Yutaka wrote:
> Hello, Jan and all,
> 
> On 09/01/2015 01:20 AM, Jacob Appelbaum wrote:
>> I feel like I must not understand something or something is very wrong
>> with the best practices.
> 
> Jan, I have addressed this issue multiple times since 2010.  We have
> disagreement or we pushed different efforts.  I think you sought
> PKCS#11, PC/SC, and opensc, while I have focused on OpenPGPcard and
> GnuPG.
> 
> While I understand it enable closing some bug reports, I don't think
> shared access to smartcard is a practice.
> 
> Let me explain current situation and my position.
> 
> I think that access to smartcard/token should be controlled by a
> single application.  In case of OpenPGPcard (and compatibles), it's
> GnuPG scdaemon.
> 
> I know there are some utilities accessing smartcard/token.  PIV
> utility of Yubikey, or firmware upgrade utility of Gnuk comes into my
> mind.
> 
> For use of those utilities, GnuPG scdaemon should be killed
> beforehand.  It would make sense that such a utility even had a
> feature killing GnuPG scdaemon beforehand (if user wants to do so).
> 
> There are other kinds of tools like Poldi and Scute.  It communicates
> through GnuPG scdaemon.  This is another solution.
> 
> I think that this is the practice.  I mean, there is a single
> responsible application (= GnuPG scdaemon) and there are two ways for
> utilities:
> 
>   (a) stop the single application beforehand
>   (b) communicate to the single application
> 
> Please note that we are open to implement some other features in GnuPG
> scdaemon for (b).  IIUC, Werner addressed this to Simon two weeks ago,
> wrt PIV utility.
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com