Sunday, December 18, 2011

new version of pcsc-tools: 1.4.18

I just released a new version of pcsc-tools. No new feature but some enhancements.

If you do not know what pcsc-tools is, it contains 4 tools:
  • pcsc_scan(1) regularly scans every PC/SC reader connected to the host if a card is inserted or removed a "line" is printed.
  • ATR_analysis(1) is a Perl script used to parse the smart card ATR. This script is called (by default) by pcsc_scan.
  • scriptor(1) is a Perl script to send commands to a smart card using a batch file or stdin.
  • gscriptor(1) the same idea as but with a Perl-Gtk2 GUI.

An equivalent of ATR_analysis is available online

1.4.18 - 18 December 2011, Ludovic ROUSSEAU
  • gscriptor: Display hex dumps in lines of 16 bytes instead of 17
  • gscriptor: Display bytes of value 0x20 as ' ' instead of '.'
  • scriptor: Display lines of 16 bytes instead of 24
  • 223 new ATRs
  • pcsc_scan: Correctly detect reader Plug and Play support

Wednesday, December 14, 2011

Short APDU readers supporting limited extended APDUs

Because of a bug report on the OpenSC mailing list I discovered that some CCID readers declare to support Short APDU only but can in fact accept APDU with more than 256 bytes of data.

I found only 2 readers with this particularity in my list:

Technical details

These 2 readers declare in the USB descriptor (the .txt file):
  • Short APDU level exchange in dwFeatures
  • a dwMaxCCIDMessageLength greater than 271 bytes


These readers declare to be short APDU so they should not be able to send or receive more than 256 bytes of data. 256 bytes of data + 5 bytes of header (CLA, INS, P1, P2, Lc) = 261 bytes. With the 10 bytes of CCID header we have the 271 bytes indicated in dwMaxCCIDMessageLength for all the (normal) Short APDU readers.

Up to version 1.3.12 (May 2010) my CCID driver would not support APDU bigger than 261 bytes with these readers. For example Mac OS X provides the CCID driver version 1.3.8 (June 2008). But in version 1.3.12 I modified the buffer size from 261 bytes to 64k bytes. This was needed for extended APDU readers.

The side effect of the change in version 1.3.12 is that the CCID driver will not reject APDU commands greater than 261 bytes.


The Xiring MyLeo reader will support APDU of up to 512 bytes (522 minus 10 bytes for the CCID header).

The TianYu CCID SmartKey reader/token will support APDU of up to 502 bytes (512 minus 10 bytes for the CCID header).

If you want to use (limited) extended APDU with these readers on Mac OS X you have to upgrade the CCID driver to at least version 1.3.12.


These two readers are using a strange CCID combination. I do not say it is illegal but it is clearly a hack to support some form of (limited) extended APDU.

Monday, December 12, 2011

PC/SC workgroup, November 2011 meeting results

The PC/SC workgroup, November 2011 meeting is now over. The meeting minutes are available to PC/SC members. But this document is not public.

Here are the results about issues I reported for the meeting.

Extended APDU support reported by PC/SC

See the previous article Extended APDU support reported by PC/SC. The idea to for an application to be able to know if a reader+driver do support extended APDU.

The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
  • The application uses SCardControl(FEATURE_GET_TLV_PROPERTIES, ...) and look for the tag dwMaxAPDUDataSize.
  • The value of dwMaxAPDUDataSize gives the maximum APDU data size supported by the reader+driver.
This proposal has been accepted.

Identifying a reader model

See the previous article Identifying a reader model. The idea is to be able to precisely identify a reader model before sending (potentially dangerous) SCardControl() commands.

The new version of PC/SC v2 part 10 describing the solution is not yet available. But the solution works like this:
The application uses SCardControl(FEATURE_GET_TLV_PROPERTIES, ...) and look for the tags PCSCv2_PART10_PROPERTY_idVendor and PCSCv2_PART10_PROPERTY_idProduct. These are the USB vendor ID and product ID of the device.

This proposal has been accepted.

Changes in PC/SC workgroup documents

Request: The PC/SC workgroup specifications contain a "Revision History" section with a brief description of the changes. It would be even better to have all the changes directly visible within the document.

The documents will be available as Word files in the member only area of the web site. Changes will be available as track changes.

No good news for non PC/SC workgroup members. You will have to compare two versions of the specification by hand (as before).

Firewalled pinpad

Request: The PC/SC workgroup should define the status word (SW1 and SW2) to be reported by the reader if a command is rejected by the firewall.

This is outside the scope of the PC/SC workgroup.


Request: Document how FEATURE_WRITE_DISPLAY, FEATURE_GET_KEY and FEATURE_VERIFY_PIN_START should or could be implemented at the CCID level.

A subcommittee will be created to work on the question.

Unblock PIN feature and PIN merge feature

This is outside the scope of the PC/SC workgroup. You should contact the manufacturer if the reader is not working as expected.


My two main issues have been accepted.

The other requests have been discussed but rejected. It is not really surprising since the proposals were not described in details. For example the code returned by PC/SC when a command is refused by a firewalled pinpad may be accepted at a later meeting if correctly presented and described.

Saturday, December 3, 2011


The libusb 1.0.9 adventure is still ongoing. In a previous article "libusb 1.0.9-rc1" I announced that the 1.0.9 official/stable version was expected for 21st of September 2011. Of course this did not happen :-(

With the upgrade of the Linux kernel in lots of distributions it looks like the 60 seconds delay issue is more present and/or occurs more often. So I get more bug reports. The problem is not pcsc-lite or the CCID driver. The bug is in libusb.

History of the bug #56

This is the 4th article about this libsub bug. We already had:

How to get a fixed libusb?

$ git clone git://
$ cd libusb
$ git branch testing origin/testing
$ git checkout testing

If you want to use an already prepared .tar.bz2 archive I provide one at


A lot of time and energy is lost by users of smart cards reporting bugs, and by me answering to bugs.

The bad news is that I don't see any positive signal for the future of libusb. I will continue to refer to the this article for any bug report mentioning a 60 seconds delay.

Thursday, December 1, 2011

EMV-CAP article now available online

In a previous article "EMV-CAP in MISC Magazine n°56" I presented a paper published in the French magazine MISC. The paper is now available online.

Thanks to Philippe Teuwen, co-author of the article, for the info.