Ludovic Rousseau's blog: April 2016

Friday, April 22, 2016

OS X El Capitan and CCID driver upgrades

Silent upgrade of the CCID driver

This is part of the series: "OS X El Capitan and smart cards: known bugs".

The first version of El Capitan 10.11 in September, 2015 was provided with the CCID driver version 1.4.14. See "OS X El Capitan and smart cards status" for more details.

I recently discovered that Apple upgraded the CCID driver in the minor upgrades (also thanks to Martin P. for the notice):

Mac OS X 10.11.3 provides the CCID driver version 1.4.20 (driver released 5 August 2015)
Mac OS X 10.11.4 provides the CCID driver version 1.4.21 (driver released 21 October 2015)

OS X 10.11

On Mac OS X 10.11 (or 10.11.0) I have:

$ ls -lR /usr/libexec/SmartCardServices/drivers
total 0
drwxr-xr-x  3 root  wheel  102 23 aoû  2015 ifd-ccid.bundle

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle:
total 0
drwxr-xr-x  5 root  wheel  170  5 oct  2015 Contents

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents:
total 56
-rw-r--r--  1 root  wheel  27616  5 oct  2015 Info.plist
drwxr-xr-x  4 root  wheel    136  2 oct  2015 MacOS
-rw-r--r--  1 root  wheel    471 23 aoû  2015 version.plist

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
total 176
lrwxr-xr-x  1 root  wheel      20  2 oct  2015 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 17 sep  2015 libccid.dylib.1.4.14

OS X 10.11.3

On Mac OS X 10.11.3 I have:

$ ls -lR /usr/libexec/SmartCardServices/drivers
total 0
drwxr-xr-x  3 root  wheel  102 Aug 23  2015 ifd-ccid.bundle

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle:
total 0
drwxr-xr-x  5 root  wheel  170 Jan 28 10:05 Contents

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents:
total 24
-rw-r--r--  1 root  wheel  33873 Sep 23  2015 Info.plist
drwxr-xr-x  5 root  wheel    170 Jan 28 10:05 MacOS
-rw-r--r--  1 root  wheel    469 Sep 23  2015 version.plist

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
total 344
lrwxr-xr-x  1 root  wheel      20 Dec  9 15:06 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 Oct 18  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096 Jan 14 03:06 libccid.dylib.1.4.20

OS X 10.11.4

On Mac OS X 10.11.4 I have:

$ pwd
/Volumes/ElCapitan/usr/libexec/SmartCardServices/drivers

$ ls -lR ifd-ccid.bundle/
total 0
drwxr-xr-x  5 root  wheel  170 Mar 22 13:23 Contents

ifd-ccid.bundle//Contents:
total 24
-rw-r--r--  1 root  wheel  36860 Dec 21 06:05 Info.plist
drwxr-xr-x  5 root  wheel    170 Mar 22 13:23 MacOS
-rw-r--r--  1 root  wheel    470 Dec 21 06:05 version.plist

ifd-ccid.bundle//Contents/MacOS:
total 344
lrwxr-xr-x  1 root  wheel      20 Sep 16  2015 libccid.dylib -> libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  165888 Sep  3  2015 libccid.dylib.1.4.14
-rwxr-xr-x  1 root  wheel  166096 Mar 12 09:30 libccid.dylib.1.4.21

Half upgrade

What is strange is that only the driver Info.plist file has been updated. A new binary driver is installed (libccid.dylib.1.4.20 or libccid.dylib.1.4.21) but not used.

The driver Info.plist file contains:

<key>CFBundleExecutable</key>
 <string>libccid.dylib</string>

So the driver binary is always the file libccid.dylib. And, as you can see from the previous commands libccid.dylib is just a symbolic link to the same libccid.dylib.1.4.14 file.

It looks like the upgrade is not complete:

New readers present in the driver Info.plist file will be recognized
Bugs fixes and new code from versions 1.4.15 to 1.4.21 are not used since the driver binary used is still at version 1.4.14.

Broken upgrade

Some/many people reported that the CCID driver was not working any more after the 10.11.4 upgrade. I have not (yet) reproduce this problem myself.

The driver configuration looks like this:

/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS:
lrwxr-xr-x 1 root wheel         20    3 déc 08:37   libccid.dylib -> libccid.dylib.1.4.20
-rwxr-xr-x 1 root wheel     166096   12 mar 09:30   libccid.dylib.1.4.21

The symbolic link points to a non-existent libccid.dylib.1.4.20 file. So, of course, the driver is not loaded and the support of CCID readers is broken.

Error message in the system log file:

com.apple.ifdreader[219]: Failed to load IFD bundle executable:
'file:///usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/' with error: Error Domain=NSCocoaErrorDomain Code=4 "The bundle “CCIDCLASSDRIVER” couldn’t be loaded because its executable couldn’t be located." UserInfo={NSLocalizedFailureReason=The bundle’s executable couldn’t be located., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSBundlePath=/usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle, NSLocalizedDescription=The bundle “CCIDCLASSDRIVER” couldn’t be loaded because its executable couldn’t be located.}

Proposed solution

Because of System Integrity Protection [or wikipedia], it is forbidden to change/remove/add files in the /usr/ directory.

My proposal to fix the issue, until Apple provides a fix, is to:

disable SIP

fix the symbolic link using some think like

cd /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/MacOS
ln -sf libccid.dylib.1.4.21 libccid.dylib

enable SIP

Another solution

In the Apple developer forums "gtall" reported the same problem in "el capitan 10.11.4 unable to see smartcard" and "Metsma" posted a different workaround.

Maybe Apple will publish a Technical Note to give a better solution or, better, provide a version 10.11.5 with a fix for the CCID driver.

Conclusion

I reported the problem to Apple as bug #25873806 "CCID smart card reader driver update failed in 10.11.4".

That is the first time that Apple updates a smart card component (instead of just fixing bugs) with minor revisions of Mac OS X. Maybe it is a sign that Apple cares about smart cards?

My list of El Capitan known smart card bugs contains 7 unfixed bugs and 3 wanted features. There is still Apple work to do for the next (minor or major) release of Mac OS X.

Update

On 26th April 2016, Apple closed my bug report as a duplicate:

"Engineering has determined that your bug report (25873806) is a duplicate of another issue (25416818) and will be closed."

Wednesday, April 20, 2016

New version of libccid: 1.4.23

I just released a version 1.4.23 of libccid the Free Software CCID class smart card reader driver.

Changes:
1.4.23 - 20 April 2016, Ludovic Rousseau

Add support of

ACS ACR3901U ICC Reader
Alcor Micro AU9560
Cherry SmartTerminal XX44
HID Global OMNIKEY 3x21 Smart Card Reader
HID Global OMNIKEY 5022 Smart Card Reader
HID Global OMNIKEY 6121 Smart Card Reader
IonIDe Smartcard Reader reader
KACST HSID Reader
KACST HSID Reader Dual Storage
KACST HSID Reader Single Storage

Remove support of

VMware Virtual USB CCID

Do NOT add support of

DUALi DE-ABCM6

Fix a busy loop consuming 100% of CPU for some composite USB devices
impacted readers: Yubico Yubikey NEO U2F+CCID and Broadcom BCM5880
Remove support of (unused) option DRIVER_OPTION_RESET_ON_CLOSE
log libusb error name instead of decimal value
Some minor improvements

Tuesday, April 19, 2016

OS X El Capitan bug: SCardGetAttrib() returns SCARD_E_NOT_TRANSACTED when it should not

This is part of the series: "OS X El Capitan and smart cards: known bugs".

SCardGetAttrib() returns SCARD_E_NOT_TRANSACTED when it should not

SCardGetAttrib() does not work correctly any more on El Capitan. SCardGetAttrib() is used to get an attribute value from the IFD Handler (the smart card reader driver).

One idea of SCardGetAttrib() is to use a double call:

1st call to get the correct buffer size to store the attribute
2nd call to fill the allocated buffer with the requested attribute value

The program then looks like:

rv = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, NULL, &attrLen);
  attr = malloc(attrLen);
  rv = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, attr, &attrLen);

On the first call the pbAttr pointer is NULL because no buffer is used. This call will just but the correct buffer size in the pcbAttrLen parameter (named attrLen here).
A big enough buffer is allocated to store the attribute value.
On the second call the buffer is passed as argument and is filled by the SCardGetAttrib() call.

I discovered that the first call to SCardGetAttrib() fails and returns SCARD_E_NOT_TRANSACTED if the value in attrLen (given to the function) is lower than the needed buffer size.

This input value (buffer size) should just be ignored by PC/SC since the buffer pointer is NULL (no buffer is used). The parameter is used to get a value from the function, not to give a value to the function.

Sample code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#ifdef __APPLE__
#include <PCSC/winscard.h>
#include <PCSC/wintypes.h>
#else
#include <winscard.h>
#endif

#define SCARD_ATTR_VALUE(Class, Tag) ((((ULONG)(Class)) << 16) | ((ULONG)(Tag)))
#define SCARD_CLASS_ICC_STATE       9   /**< ICC State specific definitions */
#define SCARD_ATTR_ATR_STRING SCARD_ATTR_VALUE(SCARD_CLASS_ICC_STATE, 0x0303) /**< Answer to reset (ATR) string. */

#define RED "\33[01;31m"
#define NORMAL "\33[0m"
#define pcsc_error(fct) printf(RED fct ": %s 0x%08X\n" NORMAL, pcsc_stringify_error(err), err)

int main(void)
{
    SCARDCONTEXT hContext;
    LPSTR mszReaders;
    DWORD err = SCardEstablishContext(SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
    if (err != SCARD_S_SUCCESS) {
        pcsc_error("ScardEstablishedContext");
        return -1;
    }
    DWORD cchReaders = 0;
    err = SCardListReaders(hContext, "SCard$AllReaders", NULL, &cchReaders);
    if (err != 0) {
        pcsc_error("ScardListReaders");
        return -1;
    }
    mszReaders = calloc(cchReaders, sizeof(char));
    if (!mszReaders) {
        pcsc_error("calloc\n");
        return -1;
    }
    err = SCardListReaders(hContext,"SCard$AllReaders", mszReaders, &cchReaders);
    if (err != SCARD_S_SUCCESS) {
        pcsc_error("ScardListReaders");
        return -1;
    }

    printf("Reader: %s\n", mszReaders);

    SCARDHANDLE hCard;
    DWORD dwActiveProtocol;
    err = SCardConnect(hContext, mszReaders, SCARD_SHARE_SHARED, SCARD_PROTOCOL_RAW, &hCard, &dwActiveProtocol);
    if (err != SCARD_S_SUCCESS) {
        pcsc_error("ScardConnect");
    } else {
        unsigned char attr[33] = { 0 };
        unsigned int i;
        DWORD attrLen;

        attrLen = 22;
        err = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, NULL, &attrLen);
        printf("attrLen: %d\n", attrLen);
        if (err != SCARD_S_SUCCESS) {
            pcsc_error("SCardGetAttrib");
        }

        attrLen = 123456;
        err = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, NULL, &attrLen);
        printf("attrLen: %d\n", attrLen);
        if (err != SCARD_S_SUCCESS) {
            pcsc_error("SCardGetAttrib");
        }

        attrLen = sizeof attr;
        err = SCardGetAttrib(hCard, SCARD_ATTR_ATR_STRING, attr, &attrLen);
        printf("attrLen: %d\n", attrLen);
        if (err != SCARD_S_SUCCESS) {
            pcsc_error("SCardGetAttrib");
        } else {
            for (i=0; i<attrLen; i++)
                printf("%02X ", attr[i]);
            printf("\n");
        }
    }
    SCardDisconnect(hCard, SCARD_LEAVE_CARD);
    SCardReleaseContext(hContext);
    return 0;
}

Result (on El Capitan)

$ CFLAGS="-framework PCSC" make main
cc -framework PCSC    main.c   -o main

Reader: Gemalto PC Twin Reader
attrLen: 22
SCardGetAttrib: Transaction failed. 0x80100016
attrLen: 23
attrLen: 23
3B FD 94 00 00 81 31 20 43 80 31 80 65 B0 83 02 04 7E 83 00 90 00 B6

Here the requested attribute is the card ATR (dwAttrId = SCARD_ATTR_ATR_STRING) with a size of 23 bytes. If the first call to SCardGetAttrib() uses a value of 22 (or less) then the function returns with the error SCARD_E_NOT_TRANSACTED (0x80100016)

Expected result (on Debian)

$ CFLAGS=`pkg-config --cflags libpcsclite` LDFLAGS=`pkg-config --libs libpcsclite` make main
cc -pthread -I/usr/include/PCSC    -lpcsclite    main.c   -o main

Reader: Gemalto PC Twin Reader (70D7E2EE) 00 00
attrLen: 23
attrLen: 23
attrLen: 23
3B FD 94 00 00 81 31 20 43 80 31 80 65 B0 83 02 04 7E 83 00 90 00 B6

Known workaround

Do not use a random value for attrLen on the first call (or you will get random results). But initialize the variable to a big enough value. A value of 65535 should be good enough in most cases.

Update: 27th September 2016

This bugs is fixed in macOS Sierra 10.12.0.

Saturday, April 2, 2016

ATR statistics: TA1 - Global, encodes Fi and Di

Article from the series "ATR statistics"

TA1 - Global, encodes Fi and Di

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

From Wikipedia https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TA1 (with some edition to remove extra details):

Interface byte TA₁, if present, is global, and encodes the maximum clock frequency f_max supported by the card, and the number of clock periods per ETU that it suggests to use after the ATR, expressed as the ratio Fi/Di of two integers. When TA₁ is absent, it's assumed default value is ‘11’, corresponding to f_max = 5 MHz, Fi = 372, Di = 1.

The 4 low-order bits of TA₁ (4th MSbit to 1st LSbit) encode Di as:

4th to 1st bits 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Di RFU 1 2 4 8 16 32 64 12 20 RFU RFU RFU RFU RFU RFU

The 4 high-order bits of TA₁ (8th MSbit to 5th LSbit) encode f_max and Fi as:

8th to 5th bits 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Fi 372 372 558 744 1 116 1 488 1 860 RFU RFU 512 768 1 024 1 536 2 048 RFU RFU

f_max (MHz) 4 5 6 8 12 16 20 — — 5 7.5 10 15 20 — —

TA1	#	%
	932	44.98 %
0x18	241	11.63 %
0x96	202	9.75 %
0x94	167	8.06 %
0x95	158	7.63 %
0x13	136	6.56 %
0x11	124	5.98 %
0x00	18	0.87 %
0x91	16	0.77 %
0x12	15	0.72 %
0x98	15	0.72 %
0x14	14	0.68 %
0x21	8	0.39 %
0x15	7	0.34 %
0x97	6	0.29 %
0x38	4	0.19 %
0x01	1	0.05 %
0x04	1	0.05 %
0x16	1	0.05 %
0x32	1	0.05 %
0x36	1	0.05 %
0x3F	1	0.05 %
0xA8	1	0.05 %
0xD6	1	0.05 %
0xFF	1	0.05 %

The TA₁ value indicates the maximal communication speed between the card and the reader supported by the card. The reader may not support such a high speed. A lower speed will then be used (negotiated by the reader itself or by the reader driver).

Data rate (communication speed)

To know the speed value we need to convert the TA₁ value in Fi/Di into a speed value in bit/s.

TA1	Fi	Di	cycles/ETU	bits/s at 4 Mhz	Fmax Mhz	bits/s at Fmax
0x01	372	1	372	10752	4	10752
0x04	372	8	46	86956	4	86956
0x16	372	32	11	363636	5	454545
0x32	744	2	372	10752	8	21505
0x36	744	32	23	173913	8	347826
0x3F	744	RFU	RFU	RFU	RFU	RFU
0xA8	768	12	64	62500	7.5	117187.5
0xD6	2048	32	64	62500	20	312500
0xFF	RFU	RFU	RFU	RFU	RFU	RFU
0x38	744	12	62	64516	8	129032
0x97	512	64	8	500000	5	625000
0x15	372	16	23	173913	5	217391
0x21	558	1	558	7168	6	10752
0x14	372	8	46	86956	5	108695
0x12	372	2	186	21505	5	26881
0x98	512	12	42	95238	5	119047
0x91	512	1	512	7812	5	9765
0x00	372	RFU	RFU	RFU	RFU	RFU
0x11	372	1	372	10752	5	13440
0x13	372	4	93	43010	5	53763
0x95	512	16	32	125000	5	156250
0x94	512	8	64	62500	5	78125
0x96	512	32	16	250000	5	312500
0x18	372	12	31	129032	5	161290
0x11	372	1	372	10752	5	13440

The table provides the data rate value for a clock of 4 Mhz. We have seen in "CCID descriptor statistics: dwDefaultClock" that 4 Mhz is the default clock of 48% of the CCID readers in my list.

You can note that there is different values of Fi and Di that give the same data rate. For example TA₁=0xA8 and TA₁=0xD6 both give a data rate of 62500 bits/s when using a clock at 4 MHz.

Population

We can count the number of ATR for each value of TA₁. We get the table bellow:

TA₁	bits/s at 4 Mhz	bits/s at Fmax	#
0x01	10752	10752	1
0x04	86956	86956	1
0x16	363636	454545	1
0x32	10752	21505	1
0x36	173913	347826	1
0x3F	RFU	RFU	1
0xA8	62500	117187.5	1
0xD6	62500	312500	1
0xFF	RFU	RFU	1
0x38	64516	129032	4
0x97	500000	625000	6
0x15	173913	217391	7
0x21	7168	10752	8
0x14	86956	108695	14
0x12	21505	26881	15
0x98	95238	119047	15
0x91	7812	9765	16
0x00	RFU	RFU	18
0x11	10752	13440	124
0x13	43010	53763	136
0x95	125000	156250	158
0x94	62500	78125	167
0x96	250000	312500	202
0x18	129032	161290	241
	10752	13440	932

We can draw a graph of the number of ATR for a given data rates to get an idea of the repartition:

In the graph I merged the results for a same data rate. So for the value 10 752 bits/s we get the sum of TA₁=0x11 and no TA₁ so the default value of 0x11. The total is then 932+124=1056.

We can also compute and display the median value:

Half of the cards have a data rate below 86 956 bits/s and the other half has a data rate above 86 956 bits/s.

Using Fmax

The Fi value also gives the maximal clock speed supported by the smart card. The value goes from 4 Mhz to 20 MHz. If we reuse the same examples the maximal clock speed for TA₁=0xA8 is 7.5 Mhz and for TA₁=0xD6 it is 20 Mhz. The data rates using the maximal clock speed are then quite different: we have 11 7187.5 bits/s for TA₁=0xA8 and 312 500 bits/s for TA₁=0xD6.

So we get another distribution graph:

And another median:

This time the median value is 113 871 bits/s.

Reader max clock speed

Note that only 4 readers have a clock that can go up to 20 Mhz (or more). But I guess they are bogus readers.
The highest "common" clock speed is more likely 16 Mhz with 16 readers (3.95%).

Ludovic Rousseau's blog

Important!

Blog moved to https://blog.apdu.fr/