Thursday, October 28, 2010

GnuPG v2 card and extended APDU

A user reported a problem with a GnuPG v2 card and a OmniKey 4321 ExpressCard smart card reader. The same card works fine with a SCM SCR33x reader.

GnuPG v2 card

The card ATR is: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C and is known as GnuPG card V2.

According to the GnuPG v2 specification:

Reader (informative)
  • A common driver (CCID, PC/SC or CT-API) shall be supported.
  • The driver should be available for several platforms (e.g. Win32, Linux, Macin­
  • T=1 and T=0 shall be supported for cards with contacts.
  • High-Speed protocols should be supported.
  • Extended length shall be supported.

The important point is highlighted. Of course you do not read the card user manual before buying a smart card reader for your card. And the notion of "Extended length" can be quiet obscure for a user.

Extended length APDU

The difference between the two readers is that:

  • The OMNIKEY CardMan 4321 is a "Short APDU level exchange" reader
  • The SCM Microsystems Inc. SCR33x USB Smart Card Reader is a "TPDU level exchange" reader

I tried to document the problems with extended APDU in a special page Extended APDU support of the CCID driver.

But this is also obscure for a normal smart card user.

PC/SC and extended APDU

One major problem is that an application at the PC/SC level has no way to know if the reader does or does not support extended APDU.

I tried to propose a mechanism so that an application can know if the reader support extended APDU. The idea is that the application can display a human readable error message. That would avoid me to receive bug reports. But the idea was more or less refused by the PC/SC workgroup. Short APDU should be defined before defining extended APDU. And short APDU are not yet defined by the PC/SC workgroup :-(

One day I will blog about the PC/SC workgroup.


Extended APDU are more and more common. Maybe I should add a clear indication of the support or not of extended APDU in the reader matrix. If you have an idea of logo or presentation then just tell me.

Flattr this

Tuesday, October 26, 2010

PCSC sample in PHP

In PC/SC sample in different languages I "promised" to give the implementation of the same sample program in many different programing languages. I am now less motivated and some languages have not yet been treated. PHP is one of them.

Wrapper for PHP

SCardSCR is a PC/SC wrapper for PHP4. As indicated on the web page:
SCardSCR is a PHP4 based project, and for many (good) reasons, it primarily targets Microsoft Windows (Win32/i386).

And since I am not an expert or even user of Windows I do not think I will ever work on this wrapper. I am also not a user of PHP.


The project is dated 17/01/2005 and is for PHP4. PHP5 is available since 2004. So maybe the SCardSCR  project is not really active/maintained anymore.

Note that my name is in the Credits :-)
Thanks to Ludovic Rousseau for his pcsc-tools package (C program and Perl scripts) that is the basis of most SCardSCR sample scripts.


I left as an exercise the writing of the sample.php program in PHP. If you write it just tell me so I can add it here.

Flattr this

Sunday, October 24, 2010

Card auto power on and off

pcsc-lite 1.6.5 (not yet released but the code is available in the subversion repository or here) contains a new feature that was described in the TODO file as:
power on the card only if an application requests a connection. See Alioth bug #301965. That could be implemented by polling the reader only if an application requests it.

How to power off a card

In previous versions of pcsc-lite, a card, when inserted, was always powered on. The only way to power off a card is to call SCardDisconnect(SCARD_UNPOWER_CARD), SCardEndTransaction(SCARD_UNPOWER_CARD) or SCardReconnect(SCARD_UNPOWER_CARD).

After the SCardEndTransaction(SCARD_UNPOWER_CARD) or SCardReconnect(SCARD_UNPOWER_CARD) calls the card is still used by the application. The power off action is just to force a cold reset to the card. So the card is powered on right after the power off.

Auto power off

After SCardDisconnect() the card is not used since the connection with the card is closed. It is the only case where the card may stay in the powered off.

dwDisposition argument of SCardDisconnect() can be:

  • SCARD_LEAVE_CARD - Do nothing.
  • SCARD_RESET_CARD - Reset the card (warm reset).
  • SCARD_UNPOWER_CARD - Unpower the card (cold reset).
  • SCARD_EJECT_CARD - Eject the card.

SCARD_EJECT_CARD is not used. I do not know any smart card reader with mechanical features to eject a card.
If SCARD_UNPOWER_CARD is used the card is and will stay powered off
If SCARD_LEAVE_CARD or SCARD_RESET_CARD is used the card is still powered but is subject to a power off.

Auto power on

Once the card has been powered off it must be powered on again on the next use.
The only way to "use" a card is to call SCardConnect(). So when SCardConnect() is called and the card is not powered then the card is powered on first.

Smarter auto power off

The described scheme works great. One side effect is that the card may be powered off just before being used.

For example imagine the following scenario:
  1. you insert a card in the reader
  2. the card is powered on to get its ATR
  3. the card is not used by any application so the card is powered off
  4. an application was waiting in SCardGetStatusChange() and is now notified that a card is present
  5. the application call SCardConnect() to use the card
  6. the card is powered on again

To avoid the double power on action a delay is used before powering off the card in step 3. The card is powered off only if the card is not used during 5 seconds.

For the same reason the card is not powered off just at SCardDisconnect() but after being unused during 5 seconds.

Compilation options

The compilation options are in the file src/

/** time to wait before powering down an unused card */
#define PCSCLITE_POWER_OFF_GRACE_PERIOD 5*1000 /* 5 second */

/* Uncomment the next line if you do NOT want to use auto power off */

/* Uncomment the next line if you do not want the card to be powered on when inserted */

You can change the 5 seconds delay before the automatic power off: PCSCLITE_POWER_OFF_GRACE_PERIOD. It looks like on Windows the delay is 15 seconds.

If you do not like the new feature then define DISABLE_ON_DEMAND_POWER_ON and you will continue to have the previous behavior.

If you do not want the card to be powered on on insertion then define DISABLE_AUTO_POWER_ON. With this option the card will be powered on only when SCardConnect() is called, not when the card is inserted in the reader. This has side effects and is not an innocent choice. SCardGetStatusChange() will report a card is present but will not report the card ATR. To get the card ATR you have to use SCardStatus() or call SCardGetStatusChange() once again after the card has been powered off using SCardConnect().

Impacts on the reader drivers

In order to respect the 5 seconds of delay I had to replace TAG_IFD_POLLING_THREAD by TAG_IFD_POLLING_THREAD_WITH_TIMEOUT and add a timeout parameter.

I modified my CCID driver to use the new function. I do not know any other driver supporting TAG_IFD_POLLING_THREAD and needing an upgrade.

If your reader driver does not support TAG_IFD_POLLING_THREAD the delay before powering off the card will be 400 milliseconds (PCSCLITE_STATUS_POLL_RATE) instead of 5 seconds.


The power consumption of the smart card reader should be reduced a bit when the card is not powered on.

Some readers have a LED to indicate the state of the reader. For example the Gemalto GemPC Twin reader has a blinking LED when the reader is connected and a still LED when the card is powered on. I generally use the LED to know if the CCID driver and pcsc-lite are working correctly. A still LED indicates the PC/SC layer is working correctly. With the new mechanism the LED is useful only during 5 seconds after inserting the card. A blinking instead of still LED does not, always, indicates a broken PC/SC layer any more.

Powering off the card is also a new step on the road to suspending the reader at the USB level, and further reduce the power consumption.

Flattr this

Tuesday, October 19, 2010

pcsc-lite upgrade and Ubuntu special configuration

Ubuntu uses a special configuration of pcsc-lite. The library is not in /usr/lib but in /lib. See the file list of the libpcsclite1 Ubuntu package for example. This is because is used by the wpa_supplicant software and this software should be accessible before /usr is mounted. See Debian bug #531592 "libpcsclite1: move to /lib" and Ubuntu bug #44194 "wpasupplicant doesn't start when the network start"

The problem

By default pcsc-lite install its files in /usr/local but this path can be changed using the --prefix= argument. The standard way to install a software is to use:
./configure --prefix=/usr
sudo make install

This will install the daemon pcscd in /usr/sbin/pcscd and the library in /usr/lib.

The daemon provided by the pcscd package is replaced by the new one. But the new library does not replace the old one. So the system will have:

  • /usr/sbin/pcscd: new version
  • /lib/ old version
  • /lib/ old version
  • /usr/lib/ new version
  • /usr/lib/ new version

Of course programs provided by Ubuntu are linked with /lib/ so they will not use the new version. The old libpcslite will try to communicate with the new pcscd and since I changed the communication protocol that will fail. A typical example can be found in the support request [#312772] RPC Transport error:

$ pcsc_scan
PC/SC device scanner
V 1.4.16 (c) 2001-2009, Ludovic Rousseau <>
Compiled with PC/SC lite version: 1.5.3
SCardEstablishContext: RPC transport error.

The solution

The solution is to install the new version and also replace the old one. It is not possible to remove the /lib/* files since they are used by Ubuntu compiled programs.

For example pcsc_scan uses /lib/

$ ldd -r /usr/bin/pcsc_scan =>  (0x00b71000) => /lib/ (0x003f3000) => /lib/tls/i686/cmov/ (0x00836000) => /lib/tls/i686/cmov/ (0x00cee000) => /lib/tls/i686/cmov/ (0x001a1000)
/lib/ (0x009e3000)

So it is not a good idea to remove the libpcsclite1 package since that will also remove other packages (because of dependencies) like libccid libpcsc-perl libpcsclite1 network-manager network-manager-gnome pcsc-tools pcscd ubuntu-desktop wpasupplicant. It is not a good idea to install a non packaged software. But many people do this without knowing what they do. So I propose to help them and avoid answer the many bug report I get because of the special Ubuntu configuration.

Install the new pcsc-lite

$ make install

Fix the old pcsc-lite

$ cd /lib
$ ln -sf /usr/lib/

This will repace /lib/ by a symbolic link to /usr/lib/ /lib/ is already a symbolic link to /lib/

The Ubuntu wrong solution

wpa_supplicant is linked with /lib/ so can be run even if /usr is not yet mounted. But the daemon pcscd is in /usr/sbin so can't be used yet. So the smart card part of wpa_supplicant can't be used without /usr mounted.

Ubuntu solved the compilation problem. But it does not solve the usability problem.

You can also note that the libpcsclite1 Ubuntu package is in main but the pcscd Ubuntu package is in universe. That is strange since the two packages are generated from the same source archive.

The correct solution

The correct solution would be to load the at run time using an explicit dlopen() only if the smart card is used by wpa_supplicant.
The smart card could only be used after /usr is mounted. But I think that is a very reasonable limitation.


Diverting from a standard (library in /usr/lib in the present case) has a cost. The problem is that the cost is not payed by the one diverting from the standard. The cost is payed by other people (me, in the present case) that get support requests.

In economy that is called a externality. In the present case it is a negative externality.

Update, May 2017

Ubuntu (for example version 14.04 and later) installs the library in the directory
  • /lib/x86_64-linux-gnu/ on a Intel/AMD 64-bits system
  • /lib/i386-linux-gnu/ on an Intel/AMD 32-bits system

While Debian uses:
  • /usr/lib/x86_64-linux-gnu/
  • usr/lib/i386-linux-gnu/

So be careful to use the correct ./configure arguments when re-building pcsc-lite.

Saturday, October 16, 2010

MUSCLE mailing list statistics for 2009

In my previous blog I posted statistics from the MUSCLE mailing list mailing list for the complete period 2005-2010. I now publish statistics for the year 2009 only.

I am still the number one for the number of messages posted :-).

Statistics from 1.1.2009 to 30.12.2009

People who have written most messages:

 Author  Msg  Percent 
1ludovic.rousseau@gmail.com11418.91 %
2squalyl@gmail.com325.31 %
3s.ferey@wanadoo.fr304.98 %
4mstjohns@comcast.net294.81 %
5countzero@sapo.pt274.48 %
6eerbalibera@gmail.com213.48 %
7rsc@runtux.com193.15 %
8martin@paljak.pri.ee152.49 %
9aj@dungeon.inka.de132.16 %
10daniel@benoy.name111.82 %
11Michael.Bender@sun.com111.82 %
12goister@gmail.com111.82 %
13gilles.bernabe@gmail.com101.66 %
14tedtheologian@gmail.com91.49 %
15petcoradipewjepknu@jbohm.dk91.49 %
16aquamaniac@gmx.de81.33 %
17yjfpb04@163.com71.16 %
18puneet.maillist@gmail.com71.16 %
19boltateshaev@gmail.com71.16 %
20tmiller@mitre.org71.16 %
21deengert@anl.gov71.16 %
22ruben.lagar@gmail.com71.16 %
23cucinotta@sssup.it61.00 %
24angella.andrea@gmail.com61.00 %
25knife@toaster.net61.00 % %
27linux@tarottoni.com50.83 %
28martin.paljak@gmail.com50.83 %
29gt-dev@gthomas.homelinux.org50.83 %
30alexander.griesser@lkh-vil.or.at40.66 %
other15024.88 %

Best authors, by total size of their messages (w/o quoting):

 Author  KBytes 

Best authors, by average size of their message (w/o quoting):

 Author  bytes 

Table showing the most successful subjects:

 Subject  Msg  Percent 
1[Muscle] Cyberflex e-gate 32k install error 6A80325.31 %
2[Muscle] Current state of HAL-support?203.32 %
3[Muscle] GlobalPlatform keys182.99 %
4[Muscle] Protecting a PIN with keyed hashing?172.82 %
5[Muscle] Multiple threads and SCardGetStatusChange152.49 %
6[Muscle] pkcs11?152.49 %
7[Muscle] Export RSA public key out of the card142.32 %
8[Muscle] Gemalto Serial Smartcard Reader Chip121.99 %
9[Muscle] inexpensive pci express card that works with muscle111.82 %
10[Muscle] Can ATR be used for identification?111.82 %
11[Muscle] Re: new (beta) version of pcsc-lite 1.5.6-svn-4527111.82 %
12[Muscle] Support of Ricoh smart card reader111.82 %
13[Muscle] Encrypted contactless data transmission?101.66 %
14[Muscle] help needed rdesktop and etoken91.49 %
15[Muscle] Installing pcscd and stuff on a Thinclient81.33 %
16[Muscle] Door locks81.33 %
17[Muscle] Oberthur Cosmo 5.4 token support81.33 %
18[Muscle] How can I know what's the type of a card through it's61.00 %
19[Muscle] Fly Clear - Registered Traveler smartcard61.00 %
20[Muscle] Re: Oberthur token problem on linux61.00 %
21[Muscle] Favorite contactless reader?61.00 %
22[Muscle] Mobile Security Card and Muscle Apple61.00 %
23[Muscle] How can I know what's the type of a card through50.83 %
24[Muscle] contactless reader and card support under linux50.83 %
25[Muscle] testpcsc not working when not root50.83 %
26[Muscle] muscletools compile error50.83 %
27[Muscle] muscletools and sign50.83 %
28[Muscle] Gemalto Smart Enterprise Guardian50.83 %
29Requestging reader features and card related return codes50.83 %
30[Muscle] support for iso 7816-3/450.83 %
other30350.25 %

Most used email clients:

 Mailer  Msg  Percent 
1(unknown)27846.10 %
2Thunderbird (Windows/20090302)335.47 %
3Mutt335.47 %
4QUALCOMM Windows Eudora294.81 %
5KMail284.64 %
6Internet Messaging Program (IMP) H3 (5.0-cvs)274.48 %
7Apple Mail (2.930.3)142.32 %
8Apple Mail (2.1077)142.32 %
9Evolution 2.24.5 111.82 %
10Thunderbird (Windows/20081209)101.66 %
11Thunderbird (Windows/20090812)101.66 %
12Coremail Webmail Server Version XT_Ux_snapshot build81.33 %
13Evolution 2.24.5 (2.24.5-1.fc10) 71.16 %
14VM 8.0.9 under Emacs 22.2.1 (i486-pc-linux-gnu)50.83 %
15Mozilla/5.x50.83 %
16Thunderbird (X11/20090817)50.83 %
17Mozilla-Thunderbird (X11/20090103)40.66 %
18Thunderbird (X11/20090409)40.66 %
19Thunderbird (X11/20090608)40.66 %
20Evolution 2.6.3 40.66 %
21Microsoft Outlook Express 6.x40.66 %
22Apple Mail (2.1076)40.66 %
23Thunderbird (X11/20091010)40.66 %
24Postbox 1.1.0 (Macintosh/20091201)40.66 %
25YahooMailRC/1155.45 YahooMailWebService/ %
26Thunderbird (X11/20081209)30.50 %
27Thunderbird (X11/20090320)30.50 %
28Zimbra 5.0 (ZimbraWebClient - FF3.030.50 %
29Thunderbird (X11/20090605)30.50 %
30Thunderbird (Windows/20090605)30.50 %
other365.97 %

Table of maximal quoting:

 Author  Percent 
1widerstand@t-online.de88.33 % %
3mdsale@matts-workshop.com82.03 %
4rera_raja@yahoo.com77.27 %
5fschiava@libero.it74.15 %
6christiancatalano@interfree.it72.49 %
7petcoradipewjepknu@jbohm.dk71.99 %
8andreas.schwier@cardcontact.de68.89 %
9alon.barlev@gmail.com66.18 %
10nick@beastbox.net62.00 %
11reet@codelabs.ch59.23 %
12ludovic.rousseau@gmail.com58.10 %
13deengert@anl.gov57.30 %
14mstjohns@comcast.net56.95 %
15home_pw@msn.com54.99 %
16fabeisageek@googlemail.com54.81 % %
18gilles.bernabe@gmail.com49.40 %
19tommaso.cucinotta@sssup.it48.86 %
20joao.poupino@gmail.com48.42 %
21knife@toaster.net45.42 %
22sujatadoshi@gmail.com44.83 %
23asaf@lingnu.com41.36 %
24countzero@sapo.pt40.72 %
25goister@gmail.com40.69 %
26linuxprocess@free.fr39.13 %
27cuibapmy@gmail.com38.58 %
28jonas.gulle@gmail.com37.26 %
29s.ferey@wanadoo.fr36.98 %
30chaljan@gmail.com36.77 %
average30.41 %

Graph showing number of messages written during hours of day:

hour 01234567891011121314151617181920212223

Graph showing number of messages written during days of month:

day 12345678910111213141516171819202122232425262728293031

Graph showing number of messages written during days of week:



Warning: 2 message(s) not counted.

Maximal quoting:

Author :
Subject : [Muscle] Re: Oberthur token problem on linux
Date : Tue, 14 Apr 2009 10:43:00 +0200
Quote ratio: 94.06% / 4109 bytes

Longest message:

Author :
Subject : [Muscle] Cyberflex e-gate 32k install error 6A80
Date : Wed, 27 May 2009 22:08:17 +0200
Size : 28689 bytes

Most successful subject:

Subject : [Muscle] Cyberflex e-gate 32k install error 6A80
No. of msgs: 32
Total size : 127085 bytes

Final summary:

Total number of messages: 603
Total number of different authors: 118
Total number of different subjects: 195
Total size of messages (w/o headers): 1865346 bytes
Average size of a message: 3093 bytes

Input file last updated: Sat Oct 16 14:43:02 2010Generated by MailListStat v1.3

Flattr this