CCID descriptor statistics: section

Article from the serie "CCID descriptor statistics"

section # %
Should work readers 179 68.32 %
Supported readers 59 22.52 %
Unsupported readers 16 6.11 %
Disabled readers 8 3.05 %

Readers in the Disabled list are either completly bogus or the reader manufacturer requested me to remove them so they are supported by another CCID driver.

If we ignore the readers in the "disabled" list we have:

A large part of the readers (70%) have not been tested by me. It is not a problem if the reader is working correctly. It is more problematic if the reader is bogus. If a user reports a problem I can identify as a bug in the reader then the reader is moved in the "Unsupported list" with a note about the problem.

CCID descriptor statistics

The list of readers that do work with my CCID driver is now big enough (262 readers) to do some statistics.

I don't know how many CCID readers are available worldwide. I guess that with 262 of them I cover a large part of the market.

I do plan to do statistics with these different fields:

I will create a new blog article for each field and update the list above with links to the articles.

New version of libccid: 1.4.10

I just released a version 1.4.10 of libccid the free software CCID class smart card reader driver.

1.4.10 - 16 April 2013, Ludovic Rousseau

  • Add support of
    • ACS APG8201 USB Reader with PID 0x8202
    • GIS Ltd SmartMouse USB
    • Gemalto IDBridge K3000
    • Identive CLOUD 2700 F Smart Card Reader
    • Identive CLOUD 2700 R Smart Card Reader
    • Identive CLOUD 4500 F Dual Interface Reader
    • Identive CLOUD 4510 F Contactless + SAM Reader
    • Identive CLOUD 4700 F Dual Interface Reader
    • Identive CLOUD 4710 F Contactless + SAM Reader
    • Inside Secure AT90SCR050
    • Inside Secure AT90SCR100
    • Inside Secure AT90SCR200
    • SCR3310-NTTCom USB SmartCard Reader
    • SafeTech SafeTouch
    • SpringCard H512 Series
    • SpringCard H663 Series
    • SpringCard NFC'Roll
    • Yubico Yubikey NEO CCID
    • Yubico Yubikey NEO OTP+CCID
  • Add support of time extension for Escape commands

Comments are now disabled

Since the beginning of this blog the comments were possible. The comment introduction text said:

Please, do only post comments related to the article above.

For general questions or bug reports, subscribe to and use the muscle mailing list.

Your comment may be moderated and will not appear until then. No need to repost the same comment.

But many readers of my blog used the comment system to ask for support on subject unrelated to the blog article. Many of the questions should have been asked on the MUSCLE mailing list. Many questions were not accepted in the (manual) moderation step.

My blog is NOT a support forum or something similar. Support request should go to the MUSCLE list. To enforce that I decided to suspend the comments from my blog.

Oracle, javax.smartcardio failures

In the article PCSC sample in Java I presented the javax.smartcardio package to use PC/SC from a Java application. It works except that SUN/Oracle made 2 mistakes related to the same problem: PC/SC is an API not an ABI.


An API is an interface used at the source code level. In C langage, you include a header file and link to the associated library. In the PC/SC case you use something like:

#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#include <winscard.h>

And then use the PC/SC functions as provided in the header file.


The ABI is an interface used at the binary level.
At the API level the type int is used. At the ABI level the representation of int is used. The difference is that the C language do not define what int is. At the ABI level the representation of int is fixed by the compiler.

Evolution of API and/or ABI

The API may evolve if a new function is added, an existing function is removed or a function signature is changed (a function parameter is added or removed for example).

Each time the API change the ABI also changes. The ABI may also evolve even if the API do not change. This is more rare but happened with C++ when GCC changed the way to pass parameters to a function/method.

To avoid incompatibility problems on GNU/Linux the library contains an versioning. It is called soname. Applications using the old API/ABI will use libfoo version n. Applications using the new API/ABI will use libfoo version n+1. It is possible to have the two library versions installed at the same time (I don't know if it is possible to do that on a Windows system).

The JVM problems

SUN/Oracle made 2 mistakes in its use of the PC/SC library.

Direct use of

As written above a library is versioned. In the case of PC/SC the library is called on a GNU/Linux system. The previous version was I changed the API in version 1.2.9-beta1 (May 2004). I then increased the ABI version from 0 to 1.

The file is a symbolic link pointing to the version corresponding to the installed header files. Only the linker should use that file when building an application. On a Debian (or Ubuntu) system the file is provided by the libpcsclite-dev package and not by the libpcsclite1 package.

The Oracle JVM tries to loads directly. This is wrong because:
  • This file is not installed by default when the PC/SC library is installed
  • This file do not reference a particular library version. So if the PC/SC API change again then the JVM will miserably fail.

I get many bug reports because of that. But the problem is not on the pcsc-lite side. So I can't do much.

Direct definition of DWORD

Oracle think a DWORD is a 64-bit entity on a 64-bit system. This is not always the case and is wrong on Mac OS X in 64-bits mode.

Apple defines DWORD as:
typedef uint32_t DWORD;

On Linux it is defined as:
typedef unsigned long DWORD;

If the application (the JVM in this case) and the library (PCSC framework) do not agree on the ABI (the size of a DWORD parameter) then bad things happen.

See the bug report javax.smartcardio package not working in Java 7 on OS X ML for a solution to this problem.


I wrote this blog article so that I can refer people at it. And so that you can refer Oracle at it.

I do not use Java. I do not know how to report a JVM bug at Oracle. If you know then please send them a link of this article.

Smart Card authentication on Mac OS X Lion and OpenDirectory

In a mail on the SmartcardServices-Users mailing list I found a reference to an article (in French sorry) from April 2012 written by Yoann Gini about Smart Card authentication on Mac OS X Lion and OpenDirectory.

The french title is "Utiliser des cartes à puce pour s’authentifier sur OS X Lion avec un OpenDirectory".

Yoann writes about the configuration of a Feitian smart card + OpenSC to login on Mac OS X Lion.

Yoann also improved the command line tool sc_auth to add OpenDirectory support (the command binary is provided but I can't find the corresponding source code).

Note: sc_auth is not a compiled binary but a bash script. So the source code is the program itself. I should have checked that before.

OpenSC server migration


The OpenSC project is/was hosted at Andreas Jellinghaus was the OpenSC maintainer for a long time and managed the project server.

Andreas changed his job and could not invest the needed time to administer the server any more.


OpenSC is a project name and also an organization hosting sub-projects. From the main web page:

" OpenSC effort consists of various sub-projects that can be used independently as well, without OpenSC:
  • engine_pkcs11 is an OpenSSL engine to use PKCS#11 providers, either from command line or from applications
  • libp11 is a small C wrapper library for working with PKCS#11 modules.
  • pkcs11-helper eases working with PKCS#11 modules, by implementing common tasks.
  • PAM-PKCS#11 implements various authentication methods
  • pam_p11 is a small and simple PAM module for local authentication
  • OpenCT implements a reader driver interface for various non-standard readers on Linux, meant to be used with OpenSC.
  • OpenSC-Java is a Java<->OpenSC bridge? "

New services

Source code

The source code repository of the OpenSC project and sub-projects is now at github:

Migration status: done

Bug tracker

Bug are stored in the Trac instance and are not easy to migrate. One option is to use github issues feature.

Migration status: not done


The wiki pages are also hosted at github:

Migration status: done

Mailing lists

The mailing lists are hosted at the OpenSC project at SourceForge:

You have to subscribe yourself to the new lists. We do not plan to do an automatic migration to:

Migration status: DIY (Do It Yourself)

Nightly builds

Tarball releases also provides tarball releases but these archives contain only the source code and not the generated ./configure scripts. So they are not really useful.

Continuous integration


The old server is now mostly done. The migration should be finished.

The bad news is that the bug reports are lost in the migration. Maybe they may appear at a later date.

New version of libccid: 1.4.9

I just released a version 1.4.9 of libccid the free software CCID class smart card reader driver.

1.4.9 - 16 January 2013, Ludovic Rousseau

  • Add support of
    • Aktiv Rutoken PINPad In
    • Aktiv Rutoken PINPad Ex
    • REINER SCT cyberJack go
  • Info.plist: Correctly handle reader names containing &

New version of pcsc-lite: 1.8.8

I just released a new version of pcsc-lite 1.8.8.

pcsc-lite-1.8.8: Ludovic Rousseau
16 January 2013

  • /etc/reader.conf: handle FRIENDLYNAME with no " delimiters (serial readers)
  • Info.plist: Correctly handle reader names containing & (USB readers)