Extended APDU status per reader

Extended APDU are more and more used by applications and cards. But an application has no way to know if the reader is capable of supporting extended APDU. So an application + card may work with one reader and fail with another reader.

Extended APDU

An extended APDU is an command to the card with a data or response of more than 256 bytes. It is not easy to detect an extended APDU unless you talk ISO 7816-3 fluently. I will not go into details here.

PC/SC limitation

PC/SC (also called WinSCard) is the standard API to use smart card reader and a smart card. Unfortunately PC/SC can't tell the application if the reader will, or not, support extended APDU.

I proposed an evolution to the standard to add such a feature (adding a new tag to FEATURE_GET_TLV_PROPERTIES) but the PC/SC workgroup was not really enthusiastic about the idea. An application could have displayed an error message to the user indicating that the reader does not support extended APDU and that another reader should be used instead.

What we get instead is a PC/SC error to the application and bug reports to me and others.

Reader support

Not all readers will support extended APDU. I created a web page to explain the situation when using my CCID driver. But the page may be do hard to find.

So, after yet another bug report about a failing application because of extended APDU, I modified the reader lists (supported, should work, unsupported, disabled) and the reader matrix to contain the information: does this reader support extended APDU?

Examples

The user in the latest bug report was using a Xiring MyLeo reader. If you go to the description of this reader at http://pcsclite.alioth.debian.org/ccid/supported.html#0x0F140x0037 you will now see:

 XIRING MyLeo

USB descriptor: readers/Xiring_MyLeo.txt

Features: PIN Verification, PIN Modification

Limitations: No extended APDU

In CCID release: 1.4.2

The new field is "Limitations" (in red).

The reader matrix contains a new column 'limitations'. As with any column it is possible to sort the matrix using this 'limitations' column. You then get 2 groups of readers: those supporting extended APDU, and this NOT supporting extended APDU.

It will not help user determine why the application failed to work correctly. But at least it will indicate that the reader they are using is "limited".

Conclusion

If you plan to buy a new reader you should take care of the reader ability to supported extended APDU.

If you have an application failure you can check if the reader you use does support extended APDU.

If you have other ideas to solve the problem just contact me or the MUSCLE mailing list.

"new" version of libusb, part 2

I an previous blog article I talked about the situation of libusb:

• a stable libusb has not been released since May 2010 (exactly one year ago)
• bugs are still open even if they have patches attached in the bug report

Impacts on libccid

The bug [PATCH] Fix a race condition in io.c libusb_handle_events_timeout() (also known as ticket #56) has a great impact on users of my CCID driver by blocking the USB transfer for 60 seconds in some cases.

It looks like that bug #56 happens more often on recent Linux kernels, like the Linux kernel provided with Ubuntu 11.04. So it is now more-or-less urgent to fix the problem in libusb.

The bug has been reported since 8 months. A fix is available since April 2010 but is not yet applied in upstream libusb git repository. So I fixed it in my libusb repository on github to not forget it and because I needed a fixed version for myself.

libusb git snapshot x2

I already provide a git snapshot of the upstream (official) repository in the file libusb-1.0.8-git.tar.bz2 from http://ludovic.rousseau.free.fr/softwares/pcsc-lite/.

I now also provide a git snapshot of my own github version with ticket #56 fixed in the file libusb-1.0.8-github.tar.bz2.

Conclusion

So before reporting a bug in libccid first try a newer version of libusb. If the bug is at the communication level it may already be solved in the upstream libusb snapshot version or my patched version.

Man In Remote (or PKCS#11 redirection)

I found a paper from the "Hackito Ergo Sum" 2011 security conference called:
" Man In Remote,
Remotely using the Spanish National Electronic ID,
by Gabriel Gonzalez Garcia "

The paper describes a man in the middle attack by adding a network redirection at the PKCS#11 API level.

Gabriel talked about his paper on his blog Man In Remote and the source code is available online at github.