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 scriptor.pl(1) but with a Perl-Gtk2 GUI.

An equivalent of ATR_analysis is available online http://smartcard-atr.appspot.com/

Changes:
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

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:

• TianYu CCID SmartKey
• XIRING MyLeo

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

Effects

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.

Results

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.

Conclusion

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.

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.

FEATURE_WRITE_DISPLAY, FEATURE_GET_KEY and FEATURE_VERIFY_PIN_START

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.

Conclusion

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.

libusb-1.0.9-rc3

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

• The bug has been identified and a fix was proposed in April 2010.
• libusb-1.0.8 has been released in 4th May 2010 without the bug fixed.
• A fix has been committed in libusb git repository in September 10th, 2011.
• libusb 1.0.9-rc3 with the fix has not moved since September 22th, 2011.
• The patch is not yet available in the master branch, only in the testing branch.

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

• "new" version of libusb, March 30, 2011
• "new" version of libusb, part 2, May 5, 2011
• libusb 1.0.9-rc1, September 18, 2011
• and now libusb-1.0.9-rc3, December 3, 2011

How to get a fixed libusb?

$ git clone git://git.libusb.org/libusb.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 http://ludovic.rousseau.free.fr/softwares/pcsc-lite/libusb-1.0.9-rc3.tar.bz2.

Conclusion

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.

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.