exclusive vs. shared smart card access

NIIBE Yutaka gniibe at fsij.org
Tue Sep 1 09:27:45 CEST 2015

On 09/01/2015 03:46 PM, Andreas Schwier wrote:
> 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.

Thank you for your opinion.  I think that it would be true for
smartcard in general.

I am talking specifically for OpenPGPcard and its usage by scdaemon.
The name "scdaemon" would be misleading, it is something like

As one of implementer of (variant of) OpenPGPcard and its user, I were
afraid if shared access were considered as a "practice" for OpenPGPcard.

Admittedly, I understand current way of scdaemon holding and watching
the card-reader/token exclusively forever is not the best thing.  It
should be improved (say, with timeout or more user-friendly way), but
I never consider allowing shared access for OpenPGPcard is a good

In case of Gnuk Token, those applications accessing token are for some
other features which are out of scope of OpenPGPcard specification.  I
think that It's OK to require stopping scdaemon for that.

Perhaps, Nitrokey has some other features, which require shared access
somehow.  However, if it requires the change of the default assumption
of OpenPGPcard access, the impact would be huge.  If possible, please
consider other ways.

> 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.

It seems that you assume shared access to OpenPGPcard is a good thing,
while I don't think so.

More information about the Gnupg-devel mailing list