Smart card interface, OpenSC and OpenCT
laurent.pinchart at skynet.be
Tue Jul 26 13:38:25 CEST 2005
> * OpenSC is a huge and complex library with an ever changing API and
> often hidden ABI changes. It just makes too much trouble.
I understand that. Floating APIs/ABIs are very painful.
> * It requires your application to use pthreads which conflicts with
> the use of another threading library; GNU Pth in our case. This is
> the actual show stopper.
Now, that's bad. How are applications/libraries supposed to cooperate when
different threading libraries are used ?
> * We only need to _read_ PKCS#15 structures and not to _create_ them.
> This was actually pretty easy to implement and took me only a few
> days. Still not complete due to the lack of test cards (aside of a
> self-created pkcs15 card I do have only one other card
> (Dienstausweis des BMI).
So we only need a small subset of what OpenSC provides. Ok.
> * OpenSC may only be used by LGPL software because it makes use of
> OpenSSL. It is possible to disable this by losing some
> functionality; no distribution does it.
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.
> > prefered way to interface a smart card reader in GnuPG ? Is it PC/SC ?
> > What about readers with a pin pad ?
> Either direct access via the interanl CCID driver or by PC/SC or
> ctAPI. Adding OpenCT support won't be a problem.
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 ?
> > Zetes (the company that developped the Belgian eID software) contributed
> > LGPLed code to OpenSC to support the eID card. Should this code be ported
> > to GnuPG ?
> AFAIK, the card is a PKCS#15 one so in theory signing should already
> work with gpgsm. A textcard would definitley be helpful.
The card is a PKCS#15 with a few differences:
* 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 ?
* 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 ?
My main concern here is to make sure that distributions can integrate smart
card support in an easy and flexible way. This means that smart card readers
must be managed by a single application/framework/daemon/whatever, namely
PC/SC or OpenCT. Different applications can then communicate with the card,
either directly (like GnuPG) or using a library (libopensc) with a
Comments are appreciate. Feel free to prove me wrong where I'm wrong :-)
More information about the Gnupg-devel