Smart card interface, OpenSC and OpenCT

[Werner Koch]

On Tue, 26 Jul 2005 13:38:25 +0200, Laurent Pinchart said:

> Now, that's bad. How are applications/libraries supposed to cooperate when 
> different threading libraries are used ?

That is actually a non-trivial problem and the only solution is to
have callbacks for all basic threading functions.  The actual
application may then decide how to implement it.

For some things a wrapper process works but this requires an easy
interface and can't be done with a complex API like the one of OpenSC.

> Right. libopensc only requires OpenSSL for the GPK-4000 and Oberthur cards. It 
> can be disabled at compile time, in which case sc_pkcs15_wrap_data and 
> sc_pkcs15_unwrap_data won't be available.

The problem here is with the distributions:  They would need to
provide two different versions of the library.

> OpenCT is (in my opinion) a cleaner API than PC/SC (which was designed for 
> Microsoft Windows). I'd rather see the CCID readers supported through OpenCT 
> and/or PC/SC than directly by GnuPG, as OpenCT and PC/SC can share a reader 
> between separate applications. Any opinion about that ?

I also like OpenCT more than PC/SC but GnuPG smartcard support
predates OpenCT.  Another reason why PC/SC is a requirement is that
GnuPG also runs on Windows and there we have no other choice. Of
course OpenCT could be ported but the reader vendors distribute
drivers for PC/SC.

The way GnuPG currently works is that it requires exclusive access to
the reader, thus PC/SC non-exclusive access feature doesn't matter.  I
have not yet come to a conclusion how to allow shared access to a
reader.  My current line of thinking is to provide this on an
application level (i.e. trough the interface scdaemon provides).

> * The SELECT FILE doesn't return any FCI, so the file size isn't know. This 
> doesn't seem to matter as GnuPG doesn't use the FCI. On a side note, 
> iso7816_read_binary doesn't handle status bytes 6Cxx (Wrong Le field). 
> Shouldn't it reissue the READ BINARY command with Le=xx ?

I have not yet come across this error code; will implement it as required.

> * The NonRep key needs a VERIFY PIN before each time it is used for a 
> signature. Zetes enforced that by popping a GUI window up every time a 
> signature was made. I don't like that solution, and it seems that GnuPG 
> performs the VERIFY command before every signature anyway. Could anyone 
> confirm that ?

The new pkcs#15 code is very basic and definitely needs some
polishing.  For OpenPGP we keep track of sent VERIFY commands and also
take care of the flag indicating that a PIN should not be cached.
It's a matter of tests with a real card.

BTW, the current versions of GnuPG 1.9.17 as well as 1.9.18 have some
design problems with PIN caching.  This is due to reset commands send
at the end of each session; it is connected to the above mentioned
question on exclusive access to smartcards.  Needs more thinking.


Shalom-Salam,

   Werner