exclusive vs. shared smart card access
simon at josefsson.org
Tue Sep 1 09:23:16 CEST 2015
NIIBE Yutaka <gniibe at fsij.org> writes:
> I think that access to smartcard/token should be controlled by a
> single application. In case of OpenPGPcard (and compatibles), it's
> GnuPG scdaemon.
That works in the OpenPGP-only context. The problem hits as soon as
card support more than one application, which almost all smartcard does.
Currently, PCSC takes the role of controlling the smartcard, and allows
multi-protocols. GnuPG's scdaemon could take that role too, but it is
not supported today, and you would still have the conflict with PCSC.
> I know there are some utilities accessing smartcard/token. PIV
> utility of Yubikey, or firmware upgrade utility of Gnuk comes into my
There is U2F too which is supported by Chrome (works in Debian Stable).
> 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).
Yes -- killing scdaemon appears to be best recommend practice now. It
is what I'm using when switching between GnuPG and PIV, see for example:
> 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
> (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.
It would be great if there were a PIV PKCS#11 library that talked to
scdaemon. I'm not sure if it is possible to build that without changes
in scdaemon, do you have an opinion on that? Since you can send
arbitrary APDUs, it should probably be possible, but I'm not certain.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 472 bytes
Desc: not available
More information about the Gnupg-devel