Blog moved to

I moved my blog from to . Why? I wanted to move away from Blogger (owne...

Saturday, November 29, 2014

CCID descriptor statistics: completed!

The previous article "CCID descriptor statistics: dwFeatures" was the last of a series of 35 blog articles about CCID descriptor statistics. I started this series in April 2013 (19 months ago). It was not supposed to take so long to complete the series and study each and every field in a CCID USB structure.


I originally did plan to write one article per week (or one per day?). So I should have finished after only 9 months. My real "performance" is one blog article every 2.2 week. Not too bad after all.

My main problem is the lack of free time. I still have many ideas of blog articles but not enough free time and motivation to write them.


When I started this work in April 2013 only 262 readers where present in my list. 19 months later there are 322 readers. That is 60 or 23% more readers.

All the numbers are from the initial 262 readers. I don't think that the 60 new readers would have significantly change of the results.


If you want to support me work and encourage me please consider donations. See "How to help my projects? Send me bitcoins!". Thanks.

Friday, November 28, 2014

CCID descriptor statistics: dwFeatures

Article from the serie "CCID descriptor statistics".

The dwFeatures field is a number value from the CCID USB descriptor:
This value indicates what intelligent features the CCID has. The value is a bitwise OR operation performed on the following values:
  • 00000000h No special characteristics
  • 00000002h Automatic parameter configuration based on ATR data
  • 00000004h Automatic activation of ICC on inserting
  • 00000008h Automatic ICC voltage selection
  • 00000010h Automatic ICC clock frequency change according to active parameters provided by the Host or self determined
  • 00000020h Automatic baud rate change according to active parameters provided by the Host or self determined
  • 00000040h Automatic parameters negotiation made by the CCID (use of warm or cold resets or PPS according to a manufacturer proprietary algorithm to select the communication parameters with the ICC)
  • 00000080h Automatic PPS made by the CCID according to the active parameters
  • 00000100h CCID can set ICC in clock stop mode
  • 00000200h NAD value other than 00 accepted (T=1 protocol in use)
  • 00000400h Automatic IFSD exchange as first exchange (T=1 protocol in use)
Only one of the following values may be present to select a level of exchange:
  • 00010000h TPDU level exchanges with CCID
  • 00020000h Short APDU level exchange with CCID
  • 00040000h Short and Extended APDU level exchange with CCID
  • If none of those values is indicated the level of exchange is character.
Only one of the values 00000040h and 00000080h may be present. When value 00000040h is present the host shall not try to change the FI, DI, and protocol currently selected.

When an APDU level for exchanges is selected, one of the values 00000040h or 00000080h must be present, as well as the value 00000002h.

To support selective suspend:
  • 00100000h USB Wake up signaling supported on card insertion and removal
When bit 20th, as shown above, is set bit D5 in bmAttributes of the Standard Configuration Descriptor must be set to 1.

0x000102303614.17 %
0x000100BA2710.63 %
0x00020840207.87 %
0x000207B2197.48 %
0x00010030187.09 %
0x000204BA114.33 %
0x0002047E103.94 %
0x000404B2103.94 %
0x000406BA103.94 %
0x000404BE93.54 %
0x000404BA83.15 %
0x000204BE62.36 %
0x0001033051.97 %
0x0004004251.97 %
0x000101BA41.57 %
0x000102BA41.57 %
0x0000084031.18 %
0x000100B631.18 %
0x0002047231.18 %
0x000400FE31.18 %
0x0000003020.79 %
0x0001007A20.79 %
0x0001020020.79 %
0x0001023C20.79 %
0x0002004020.79 %
0x0002067220.79 %
0x000206BA20.79 %
0x0004047E20.79 %
0x000404B020.79 %
0x000004B210.39 %
0x0001000010.39 %
0x0001000210.39 %
0x0001007010.39 %
0x0001013010.39 %
0x0001013810.39 %
0x0001023810.39 %
0x0001023A10.39 %
0x000102B810.39 %
0x000103B110.39 %
0x000104BA10.39 %
0x0002004210.39 %
0x0002004E10.39 %
0x0002005E10.39 %
0x0002043010.39 %
0x000204B210.39 %
0x000205B210.39 %
0x000205B810.39 %
0x0002087010.39 %
0x000405F210.39 %
0x0004067210.39 %
0x0004084010.39 %

The dwFeatures field is the most complex field in a CCID descriptor. The numerical value is not really informative. You have to parse the value to extract every bit of information.

We will now parse dwFeatures field by field. I will not explain each possible value. Have a look at the CCID specification or my CCID driver file ifdhandler.c in the function IFDHSetProtocolParameters().

No special characteristics: 00000000h

No reader.

Undocumented bit: 00000001h

1 reader: OMNIKEY CardMan 1021

Automatic parameter configuration based on ATR data: 00000002h

151 readers

Automatic activation of ICC on inserting: 00000004h

37 readers

Automatic ICC voltage selection: 00000008h

108 readers

Automatic ICC clock frequency change according to active parameters provided by the Host or self determined: 00000010h

217 readers

Automatic baud rate change according to active parameters provided by the Host or self determined: 00000020h

216 readers

Automatic parameters negotiation made by the CCID: 00000040h

60 readers

Automatic PPS made by the CCID according to the active parameters: 00000080h

126 readers

CCID can set ICC in clock stop mode: 00000100h

34 readers

NAD value other than 00 accepted (T=1 protocol in use): 00000200h

87 readers

Automatic IFSD exchange as first exchange (T=1 protocol in use): 00000400h

102 readers

ICCD: 00000800h

25 readers

level of exhange

Character62.36 %
TPDU11344.49 %
Short APDU8332.68 %
Short and Extended APDU5220.47 %

USB Wake up signaling supported on card insertion and removal: 00100000h

No reader

Data analysis

It is difficult to say if a reader should or should not support a particular feature.

One easy case is the level of exchange. As explained in Extended APDU support not all readers can support extended APDUs. If your application and your card is using extended APDU you shall use a reader with extended APDU support. That is either a TPDU or a short and extended APDU reader. 44.49 % + 20.47 % = 64.96% of the readers support extended APDU.

Regarding the other features the choice is between:
  • a feature implemented by the reader
    • Simpler driver
    • Impossible to patch in the driver if the reader firmware or a smart card is bogus
  • a feature implemented by the driver
    • More complex driver
    • Possible to modify the driver to adapt the feature to special cases (bogus reader firmware or bogus smart card)

My CCID driver is already "complex" with support of most the features. Some features are not yet supported but nobody asked from them. So I imagine they are not important.

So, except for the extended APDU support, the other features presented here are not so important. It may be more important for you to check if the reader supports the communication speed of your smart card, or the voltage of your card.

Wednesday, November 26, 2014

CCID descriptor statistics: features

Article from the serie "CCID descriptor statistics"

The features field is NOT a value from the CCID USB descriptor. It is a field I added to indicate special features of some readers.

features PIN Verification3915.35 %
features PIN Modification3614.17 %
features contactless3112.20 %
features ICCD259.84 %
features Multi interface reader145.51 %
features 2 slots114.33 %
features Second interface72.76 %
features biometric72.76 %
features 3 slots31.18 %
features 5 slots31.18 %
features ExpressCard31.18 %
features firewall31.18 %
features 4 slots10.39 %
features serial10.39 %

Some features can be extracted from the USB descriptor like PIN Verification, PIN Modification, ICCD, number of slot. But the other features are added manually.

A majority of readers have no special feature. It is not directly visible from the table above because some readers have 2 or more features at the same time. For example all readers with PIN modification can also do PIN verification. But the reverse is not true. 3 readers can do PIN verification but not PIN modification.

If you want to find readers with a special feature, like contactless, I recommend to sort the reader matrix by 'features' field. It is then easy to find the readers with the feature you are looking for.

Monday, November 24, 2014

CCID descriptor statistics: wLcdLayout

Article from the serie "CCID descriptor statistics"

The wLcdLayout field is a number value from the CCID USB descriptor:
Number of lines and characters for the LCD display used to send messages for PIN entry.
XX: number of lines
YY: number of characters per line. XXYY=0000h no LCD.

0x000023793.31 %
0x021062.36 %
0x021151.97 %
0x020C41.57 %
0x081810.39 %
0x100210.39 %

The majority (93,31%) of readers do not have a display so 0 lines and 0 characters per line.

We then have pinpad readers with a display. The most common configurations are 2 lines of 12, 16 or 17 characters.

One reader, VASCO DP865, has a big display with 8 lines and 24 characters per line.

One reader, REINER SCT cyberJack go, is bogus and has XX and YY reversed. The screen has 2 lines of 16 characters and not 16 lines of 2 characters. It is obvious when looking at the reader picture.

Tuesday, November 18, 2014

OS X Yosemite and smart card source code

Apple released the source code of the open source components they use in Yosemite (OS X 10.10 released October 2014). The components are available at OS X 10.10 Source.

The smart card related components are:
  • SecurityTokend
  • SmartCardServices
  • SmartcardCCID
  • Tokend
See "OS X Yosemite and smart cards status" for a general discussion of the changes in Yosemite.


The version changed from 55005 in Mavericks to 55008 in Yosemite.

This reflect the change of the CCID driver from version 1.3.11 to version 1.4.14.
Apple also upgraded libusb from version 0.1.13b to version 1.0.9.

The CCID driver is now compiled with USE_COMPOSITE_AS_MULTISLOT option. That explains why composite devices are now supported.
It would have been better to support composite devices at the pcscd (or equivalent, level. USE_COMPOSITE_AS_MULTISLOT is a hack that does work only for Gemalto Prox DU and Prox SU readers.


The version changed from 55111 in Mavericks to ... 55111 in Yosemite.

The version have not changed dven if Apple made large changes in the PC/SC middleware: pcscd has been removed and replaced by something even more bizarre and inexplicable. So it is surprising to see that SmartCardServices has not been updated.


Tokend and CDSA was deprecated since Lion (10.7 released in July 2011) more than 3 years and 4 major releases ago. See "Mac OS X Lion and tokend".

The Tokend component is no more delivered since its deprecation in 10.7. The latest version is 36720 from Mac OS X 10.6 (Snow Leopard).

This component contains (or contained) the BELBIC, CAC, MuscleCard and PIV tokend.


The version of SecurityTokend changed from 55107 to 55108.

The change is really minimal. The script changed to use the command xcrun (xcrun - Run or locate development tools and properties) to run the command mig (mig - Mach Interface Generator).

The tokend is deprecated but still maintained (a bit). This project provides the SecurityTokend framework used by the different tokend in the Tokend component. The SecurityTokend framework is still provided by Xcode in /Applications/


New version of the CCID driver.

New PC/SC layer. The source code of the replacement of pcsc-lite ( and is not (yet) available. Maybe Apple will never release it. So only Apple will be able to fix the numerous bugs present in this new component.

I do not like the evolution of the smart card layer to a closed source software.

Sunday, November 16, 2014

CCID descriptor statistics: dwMaxCCIDMessageLength

Article from the serie "CCID descriptor statistics"

The dwMaxCCIDMessageLength field is a number value from the CCID USB descriptor:
For extended APDU level the value shall be between 261 + 10 (header) and 65544 +10, otherwise the minimum value is the wMaxPacketSize of the Bulk-OUT endpoint.

271 bytes18472.44 %
1034 bytes93.54 %
263 bytes93.54 %
512 bytes93.54 %
261 bytes72.76 %
272 bytes62.36 %
270 bytes51.97 %
1400 bytes20.79 %
273 bytes20.79 %
278 bytes20.79 %
432 bytes20.79 %
65550 bytes20.79 %
1014 bytes10.39 %
1024 bytes10.39 %
1041 bytes10.39 %
138 bytes10.39 %
2048 bytes10.39 %
2100 bytes10.39 %
256 bytes10.39 %
262 bytes10.39 %
266 bytes10.39 %
280 bytes10.39 %
288 bytes10.39 %
522 bytes10.39 %
536 bytes10.39 %
586 bytes10.39 %
64 bytes10.39 %

The standard value for dwMaxCCIDMessageLength is 271.

On the 271 bytes :
  • 10 bytes are used for the CCID header
  • 4 bytes are used for the CLA, INS, P1, P2 APDU header
  • 1 byte for the data size
  • 256 bytes for the data

In the PC_to_RDR_XfrBlock CCID CCID command we note:
The block should never exceed the dwMaxCCIDMessageLength-10 in the Class Descriptor.
The value dwMaxCCIDMessageLength is related to dwMaxIFSD. See also "CCID descriptor statistics: dwMaxIFSD".

CCID Readers with dwMaxCCIDMessageLength < 271 and that are Short APDU level exchange readers are suspect. They are:
  • Aktiv Co., ProgramPark Rutoken Magistra: 261 bytes and ICCD Version B
  • Gemalto PDT: 261 bytes and ICCD Version B
  • IIT E.Key Almaz-1C: 264 bytes
  • OCS ID-One Cosmo Card USB Smart Chip Device: 261 bytes and ICCD Version B
  • Philips Semiconductors JCOP41V221: 261 bytes and ICCD Version B
  • Philips Semiconductors SmartMX Sample: 261 bytes and ICCD Version B
ICCD Version B devices are a special version of CCID and in this case the normal value is 261 bytes since the CCID header is not used. The command is sent using a control request and not a bulk message.

So only the IIT E.Key Almaz-1C reader is bogus and limited to a maximum of 249 bytes of data in an APDU.

Saturday, November 15, 2014

How to help my projects? Send me bitcoins!

After I explained why flattr was not a so good option in "My Flattr experience", I now try a new experiment with bitcoin.

It is now possible to send me bitcoins at 14iqwd2wEATig6JJD6zwkpvq7AYaECgtng or using the QR code:

Since my bitcoin address is public you can follow the money transfers at

I do not expect to get very rich in bitcoin. I offer you the possibility to support me and my activities without paying banks and intermediaries.

Friday, November 7, 2014

New version of pcsc-lite: 1.8.13

I just released a new version of pcsc-lite 1.8.13.
pcsc-lite is a Free Software implementation of the PC/SC (or WinSCard) API for Unix systems.

pcsc-lite-1.8.13: Ludovic Rousseau
7 November 2014
  • fix a systemd + libudev hotplug bug introduced in version 1.8.12.
    The list of readers was not (yet) available just after the start of pcscd
  • Make the license more 3-clause BSD like
  • Fix a rare race condition in the (non default) libusb hotplug
  • Some other minor improvements and bug corrections

Monday, November 3, 2014

OS X Yosemite and smart cards status

Yosemite (OS X 10.10) is now out since October 16th, 2014.

This article is the continuation of "OS X Yosemite BETA and smart cards status".

CCID driver

The CCID driver is still in /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle.

The driver has been updated from version 1.3.11 (released 28 July 2009) in Mavericks to version 1.4.14 (released 25 November 2013).
$ grep -A 1 CFBundleShortVersionString /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist 

See the CCID driver README file for a list of the changes between 1.3.11 and 1.4.14. I will not list 4 years of changes here.

New readers supported

121 readers have been added between 1.3.11 and 1.4.14. They are:
  • Access IS ePassport Reader
  • ACS ACR101 ICC Reader
  • ACS AET65
  • ACS APG8201 PINhandy 1
  • ACS APG8201 USB Reader with PID 0x8202
  • ACS CryptoMate64
  • Akasa AK-CR-03, BZH uKeyCI800-K18
  • Aktiv Rutoken lite readers
  • Aktiv Rutoken PINPad Ex
  • Aktiv Rutoken PINPad In
  • Alcor Micro AU9522
  • Alcor Micro AU9540
  • Ask CPL108
  • Atmel AT90SCR050
  • Atmel AT90SCR100
  • Atmel VaultIC420
  • Atmel VaultIC440
  • Atmel VaultIC460
  • Avtor SC Reader 371
  • Avtor SecureToken
  • BIFIT iBank2Key
  • BIFIT USB-Token iBank2key
  • Bit4id CKey4
  • Bit4id cryptokey
  • Bit4id iAM
  • Bit4id miniLector
  • Bit4id miniLector-s
  • Broadcom 5880
  • C3PO LTC36
  • CCB eSafeLD
  • Cherry SmartTerminal XX7X
  • Covadis Auriga
  • Dectel CI692
  • Feitian ePass2003 readers
  • Feitian SCR310 reader (also known as 301v2)
  • Free Software Initiative of Japan Gnuk token readers
  • Fujitsu SmartCase KB SCR eSIG
  • Gemalto Ezio CB+
  • Gemalto Ezio Shield
  • Gemalto Ezio Shield Branch
  • Gemalto Ezio Shield PinPad
  • Gemalto Ezio Shield PinPad reader
  • Gemalto GemCore SIM Pro firmware 2.0 (using USB)
  • Gemalto Hybrid Smartcard Reader
  • Gemalto IDBridge CT30
  • Gemalto IDBridge K30
  • Gemalto IDBridge K3000
  • Gemalto SA .NET Dual
  • Gemalto Smart Guardian (SG CCID)
  • German Privacy Foundation Crypto Stick v1.2
  • Giesecke & Devrient StarSign CUT
  • GIS Ltd SmartMouse USB
  • GoldKey PIV Token
  • id3 CL1356T5
  • 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
  • Ingenico WITEO USB Smart Card Reader (Base and Badge)
  • Inside Secure AT90SCR050
  • Inside Secure AT90SCR100
  • Inside Secure AT90SCR200
  • Inside Secure VaultIC 420 Smart Object
  • Inside Secure VaultIC 440 Smart Object
  • Inside Secure VaultIC 460 Smart Object
  • Kingtrust Multi-Reader
  • KOBIL mIDentity 4smart
  • KOBIL mIDentity 4smart AES
  • KOBIL mIDentity 4smart fullsize AES
  • KOBIL mIDentity fullsize
  • KOBIL mIDentity visual
  • KOBIL Smart Token
  • KOBIL Systems IDToken
  • Macally NFC CCID eNetPad reader
  • Neowave Weneo
  • new Neowave Weneo token
  • NXP PR533
  • Oberthur ID-ONE TOKEN SLIM v2
  • OmniKey 6321 USB
  • Planeta RC700-NFC CCID
  • Precise Sense MC reader (with fingerprint)
  • REINER SCT cyberJack go
  • ReinerSCT cyberJack RFID basis
  • SafeTech SafeTouch
  • SCM Microsystems Inc. SCL010 Contactless Reader
  • SCM Microsystems Inc. SDI011 Contactless Reader
  • SCM SCL011
  • SCM SCR3500
  • SCM SDI 011
  • SCR3310-NTTCom USB SmartCard Reader
  • SCR3310-NTTCom USB (was removed in version 1.4.6)
  • SecuTech SecuTech Token
  • Smart SBV280
  • SpringCard H512 Series
  • SpringCard H663 Series
  • SpringCard NFC'Roll
  • Teridian TSC12xxF
  • THRC reader
  • Tianyu Smart Card Reader
  • Todos AGM2 CCID
  • Todos CX00
  • Ubisys 13.56MHz RFID (CCID)
  • Vasco DIGIPASS 920
  • Vasco DIGIPASS KEY 101
  • Vasco DIGIPASS KEY 200
  • Vasco DIGIPASS KEY 200
  • Vasco DIGIPASS KEY 860
  • Vasco DIGIPASS KEY 860
  • Vasco DP855
  • Vasco DP865
  • Xiring Leo v2
  • Xiring MyLeo
  • Yubico Yubikey NEO CCID
  • Yubico Yubikey NEO OTP+CCID

PC/SC known bugs fixed in Yosemite

This new version of PC/SC fixes some bugs present in the previous version of OS X (Mavericks and before).

This list is not exhaustive. I had a look at the bugs I reported at (also known as radar) and that were closed by Apple.
Maybe you reported to Apple some PC/SC problems I do not know and these problems are now fixed in Yosemite. Feel free to tell me about it.

Extended APDU case 2 no more limited to 1958 bytes

It is now possible to get up to 64k bytes from a card using an extended APDU.
(radar bug #9983001)

Possibility to use composite CCID devices

It is now possible to use a USB device with more than 1 CCID interface.

For example the Gemalto Prox Dual USB PC Link Reader provides 2 CCID interfaces (1 contact interface and 1 contactless interface). In previous Mac OS X versions only the first interface was usable (unless you use a specially compiled CCID driver).
(radar bugs #17841224, #10469006)

Suspend/resume with 2 readers connected

Suspend and resume now works when you have 2 readers connected.

With the previous OS X versions the pcscd daemon was sometimes locked in a bad state at resume. You had to do a card movement to "wake up" pcscd.
(radar bug #16711906)

No more limited to 16 PC/SC card contexts

It is now possible to call SCardConnect() more than 16 times consecutively.

My test program now blocks at around 750 simultaneous opened card contexts. The application should get a PC/SC error instead of blocking. Still a bug but this one should not happen often in the field.

(radar bug #10038432 and

PC/SC new internal Architecture

Maybe I am completely wrong about my interpretation. We will know for sure when/if the source code of PC/SC is published at

This is what I found for now.


The daemon /usr/sbin/pcscd is no more present and has been replaced by something more complex (and with new bugs).

PCSC framework

Binary is /System/Library/Frameworks/PCSC.framework/PCSC.

This file is still present and is used by a PC/SC application. It is the entry point for any PC/SC application on OS X.

Binary is /System/Library/Frameworks/PCSC.framework/Versions/A/XPCServices/

The process is started (directly or indirectly) by the PC/SC framework linked to the application.

For example when the (still present) test program pcsctest.
$ ps -Aj | grep pcsc
root              110     1   110      0    0 Ss     ??    0:00.02 /System/Library/Frameworks/PCSC.framework/Versions/A/XPCServices/
lroussea         2282     1  2282      0    0 Ss     ??    0:00.01 /System/Library/Frameworks/PCSC.framework/Versions/A/XPCServices/
lroussea         2281  1410  2281      0    1 S+   s002    0:00.00 pcsctest

One is run by root (process id 110) and is started at boot.

One is run by lroussea (process id 2282). pcsctest (process id 2281) is also run by lroussea.

Using the strings(1) command line tool on the binary we note some results:
  • /SourceCache/SmartCardServices/CryptoTokenKit-22.1.3/PCSC/ctkpcscd/main.m
    I guess the source code of will be published (soon?) in the SmartCardServices project.
  • It looks like Apple completely rewrote pcsc-lite, and in Objective C this time (.m file extension).
  • "Refusing sandboxed PCSC.framework client without entitlement"
    A new entitlement is necessary to use the PC/SC API? Or just to use CryptoTokenKit?
  • TKPcscContext, TKPcscChangeItem, TKPcscStateChangeItem, TKPcscSlotArrivalItem, TKPcscChangeSet, TKPcscCard are new functions. See below.
The process uses the libray (binary /System/Library/Frameworks/CryptoTokenKit.framework/Versions/A/CryptoTokenKit).

Binary is /System/Library/CryptoTokenKit/

This process loads the smart card reader driver (for example ifd-ccid.bundle in /usr/libexec/SmartCardServices/drivers/) and is in relation with

This process also uses the library (binary /System/Library/Frameworks/CryptoTokenKit.framework/Versions/A/CryptoTokenKit).


How to get logs from a reader driver? It was easy to use /usr/sbin/pcscd --debug --forground to get the driver debug messages in the terminal. It is no more available :-(

PC/SC in JavaScriptAppleEvents?

I found the file /System/Library/PrivateFrameworks/JavaScriptAppleEvents.framework/Versions/A/Resources/BridgeSupportCache/PCSC.plist. This file contains a description of the PC/SC functions (like SCardTransmit) and also old libMuscleCard functions (like MSCWriteObject).

I don't know yet what can be done with this file. But since it is in PrivateFrameworks I do not expect to find much documentation.


As presented in the previous article  "OS X Yosemite BETA and smart cards status" a new framework is provided: CryptoTokenKit


The headers files are in /System/Library/Frameworks/CryptoTokenKit.framework/Headers. The API is in Objective C language. I would have preferred the new Apple programming language Swift (or just plain C).

Dirk-Willem van Gulik provides a sample application CryptoTokenKit-TrivialExample-OpenSC.

Relation with PC/SC

When running the sample application mentioned above I note that no is started. So the CryptoTokenKit library may talk directly to and not use PC/SC at all.
Apple wants to replace PC/SC by a new API?

The CryptoTokenKit API definesTKSmartCard* functions. But not TKPcsc* functions as found in What are these TKPcsc* functions?

It looks like CryptoTokenKit will replace PC/SC on OS X. I was hopping for a replacement of tokend and CDSA that are deprecated since Lion (3 OS X versions from now).

PC/SC evolutions

When I wrote "Evolution of Apple pcsc-lite (from Jaguar to Mavericks)" and "Differences between Apple pcsc-lite and the "official" pcsc-lite" I was still expecting a merge of Apple pcsc-lite and the offcial pcsc-lite. Now my hopes are over. A merge will be very hard since the two projects have diverge so much.

CryptoTokenKit is a new API. Maybe it will be available on other systems than OS X (like GNU/Linux). But since the API is in Objective C I don't think it will interest much people to work on such an API.

It will be more difficult to write a project that would build and run on Windows, GNU/Linux and OS X if the smart card API is not the same on the 3 systems. The PC/SC API has not yet been deprecated. So it is still possible to use this API for now.

PC/SC new bugs

Apple made big changes in the smart card layer. With big changes comes bugs and regression.

I plan to list the known bugs and regressions in another article (this one is already too long). If you know a regression in Yosemite regarding the smart card layer, please tell me so I can add it to the list.


Still a lot of unanswered questions. Some new bugs in the new PC/SC layer. And no news about the tokend replacement.

The main question is: why has Apple replaced PC/SC by a new API? What is the plan? Will CryptoTokenKit be available also on iOS to talk to a secure element?