New version of libccid: 1.4.26

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

1.4.26 - 7 January 2017, Ludovic Rousseau

  • Add support of
    • Bit4id Digital DNA Key
    • Bit4id tokenME FIPS v3
    • INGENICO Leo
    • appidkey GmbH ID60-USB
  • PowerOn: the default algorithm is now 5V then 1.8V then 3V then fail.
    It is still possible to change the initial voltage in the Info.plist file.
    Now, in any case, all the values are tried before failing.
  • Negociate maximum baud rate when bNumDataRatesSupported = 0
  • Some minor improvements

The git tag of this version is signed with my 4096-bits GnuPG key. Thanks to Leif Johansson for the suggestion.
You can check the signature using git tag -v:

$ git tag -v ccid-1.4.26
object 666a72c342f433fda1b77ff815fdfe728afc3ce7
type commit
tag ccid-1.4.26
tagger Ludovic Rousseau  1483800659 +0100

gpg: Signature made Sat Jan  7 15:51:00 2017 CET
gpg:                using RSA key 78A1B4DFE8F9C57E
gpg: Good signature from "Ludovic Rousseau " [full]
gpg:                 aka "Ludovic Rousseau " [full]

The tag is also marked as "Verified" at github

pcsc-lite and CVE-2016-10109

Peter Wu discovered that a use-after-free in the pscd PC/SC daemon of PCSC-Lite might result in denial of service or potentially privilege escalation.

I worked with Peter Wu to review and apply his proposed patches. The problem is already fixed in version 1.8.20 of pcsc-lite released 30th December 2016. You should update your pcsc-lite or get a fixed version from your GNU/Linux distribution.


The CVE is not yet public from Common Vulnerabilities and Exposures page CVE-2016-10109 but you can get a copy of the CVE creation request from the oss-sec mailing list archive at CVE Request: pcsc-lite use-after-free and double-free. Bellow is a re-formatted version:

From: Peter Wu
Date: Tue, 3 Jan 2017 13:06:42 +0100

Vulnerability type:
CWE-415, CWE-416


Affected Versions:
PCSC-Lite >= 1.6.0, < 1.8.20

PCSC-Lite[1] is a middleware to access a smart card using the SCard API (PC/SC). It can be used with GnuPG, OpenSC and others for hardware like the Nitrokey and Yubikey. These software use a client library (libpcsclite) which communicate with a daemon (pcscd) that actually accesses the hardware.

The SCardReleaseContext function normally releases resources associated with the given handle (including "cardsList") and clients should cease using this handle. A malicious client can however make the daemon invoke SCardReleaseContext and continue issuing other commands that use "cardsList", resulting in a use-after-free. When SCardReleaseContext is invoked multiple times, it additionally results in a double-free of "cardsList".

The issue allows a local attacker to cause a Denial of Service, but can potentially result in Privilege Escalation since the daemon is running as root while any local user can connect to the Unix socket.

Fixed by patch "SCardReleaseContext: prevent use-after-free of cardsList"[2] which is released with pcsc-lite 1.8.20 on 30 December 2016[3].

This issue was discovered and fixed by Peter Wu (peter () lekensteyn nl).

Additional information:
The issue is confirmed for:

  • Arch Linux (1.8.18-1)
  • CentOS 7 (1.8.8-6.el7)
  • Debian Jessie (1.8.13-1)
using the PoC from

$ python run/pcscd.comm
    [*] Request succeeded, possible vulnerable
    [*] Sending SCARD_RELEASE_CONTEXT (2)
    [+] Daemon crashed, it is vulnerable!

    $ sbin/pcscd --foreground --debug
    00000167 winscard_svc.c:337:ContextThread() Authorized PC/SC client
    00000011 winscard_svc.c:341:ContextThread() Thread is started: dwClientID=6, threadContext @0x610000007f40
    00000009 winscard_svc.c:359:ContextThread() Received command: RELEASE_CONTEXT from client 6
    00000008 winscard.c:226:SCardReleaseContext() Releasing Context: 0x0
    00000008 winscard_svc.c:470:ContextThread() RELEASE_CONTEXT rv=0x0 for client 6
    00000088 winscard_svc.c:359:ContextThread() Received command: RELEASE_CONTEXT from client 6
    00000012 winscard.c:226:SCardReleaseContext() Releasing Context: 0x0
    ==11540==ERROR: AddressSanitizer: heap-use-after-free on address 0x60300000d728 at pc 0x000000410490 bp 
0x7f34ab4dd920 sp 0x7f34ab4dd910
    READ of size 8 at 0x60300000d728 thread T2
        #0 0x41048f in list_clear src/simclist.c:634
        #1 0x4108ba in list_destroy src/simclist.c:303
        #2 0x41843e in MSGRemoveContext src/winscard_svc.c:884
        #3 0x4194f3 in ContextThread src/winscard_svc.c:468


Happy new year 2017

Dear readers,

I wish you a happy new year for 2017.

In 2016 I published 49 articles on this blog (51 articles in 2015. See "Happy new year 2016"). I do plan to continue writing about my smart card and Free Software activities in 2017.

Unfortunately I can't get nice statistics about articles from the blog for the year 2016 as I did last year. I can get data for last month or since the blog started, but not for last year.

One nice graph is the blog global view since 2010:

Thank you

Thank you to you, readers.

This blog has no advertising. If you want to support it you can send me some bitcoins. If you want to send $ or € instead of bitcoins then contact me.

ATR statistics: TB2 - Global, deprecated

Article from the series "ATR statistics"

TB2 - Global, deprecated

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
TB2, if present, is global. The usage of TB2 is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB2 in the ATR, and readers shall ignore TB2 if present.

In the 1997 edition of the standard, TB2 (8th to 1st bit) encode PI2, which when in range 50..250 (other values being RFU) encode VPP in increments of 0.1 V, and subsumes the coarser indication given by PI1 of TB1. Refer to that section for why modern Smart Cards have no use of VPP, and thus of TB2.

Historical note: Provision for TB2 did not exist in ISO/IEC 7816-3:1989, and was introduced because VPP = 12.5 V became a popular value in EEPROM technology, replacing 25 V and 21 V.

TB2 # %
2070 99.90 %
0x3F 1 0.05 %
0x45 1 0.05 %

Only 2 cards use a TB2 value.
I agree these 2 ATRs are quiet unusual.

ATR statistics: TA2 - Global, specific mode byte

Article from the series "ATR statistics"

TA2 - Global, specific mode byte

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
Interface byte TA2, if present, is global, and is named the specific mode byte.

Presence of TA2 commands that the reader use specific mode as defined by TA2 and earlier global bytes, rather than negotiable mode when TA2 is absent.

TA2 encodes in its 4 low-order bits an integer T defining the protocol required by the card, in the convention used for TD1 (EMV prescribes that a card which T encoded in TA2 does not match that in TD1 shall be rejected).

The 5th bit is 0 to encodes that the required ETU duration is Fi/Di clock cycles as defined by TA1 (or its default value if absent); or 1 to indicate that the ETU duration is implicitly known (by some convention, or setting of the reader; EMV prescribes that such card shall be rejected).

The 6th and 7th bit are reserved for future use; 0 indicates not used.

The 8th bit is 1 to indicate that the card is unable to change the negotiable/specific mode (that is, does not propose other settings); or 0 to indicate that card has that ability (perhaps after a warm ATR).

Historical note: Provision for specific mode did not exist in ISO/IEC 7816-3:1989. Back then, the interface character TA2 had no particular name or function, and was specific (to the protocol introduced by TD1). ISO/IEC 7816-3:1997 introduced the specific mode and the specific mode byte, with interim note helping cards with specific mode byte TA2 in their ATR dealing with a reader that did not implement specific mode.

TA2 # %
1983 95.70 %
0x81 48 2.32 %
0x80 31 1.50 %
0x00 10 0.48 %

TA2 is used by only 4.30% of cards. 95.70% of smart cards in my list have no TA2 defined.

  • 0x81 indicates "Protocol to be used in spec mode: T=1 - Unable to change - defined by interface bytes".
    • The 4 low-order bits are set to 0001b so T=1 protocol.
    • The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
  • 0x80 indicates "Protocol to be used in spec mode: T=0 - Unable to change - defined by interface bytes"
    • The 4 low-order bits are set to 0000b so T=0 protocol.
    • The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
  • 0x00 indicates "Protocol to be used in spec mode: T=0 - Capable to change - defined by interface bytes"
    • The 4 low-order bits are set to 0000b so T=0 protocol.
    • The 8th bit set to 0 to indicate the card is able to change the negotiable/specific mode

New version of pcsc-lite: 1.8.19

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

1.8.19: Ludovic Rousseau
9 December 2016

  • SCardGetStatusChange(): Fix a (rare) race condition
  • Doxygen:
    • SCardGetStatusChange() may return SCARD_E_UNKNOWN_READER
    • SCardConnect() and SCardReconnect() will never return SCARD_E_NOT_READY
  • pcsc-spy:
    • fix display of execution time
    • log the thread number in the results
  • Some other minor improvements

macOS Sierra and pam_smartcard

In Sierra a new smart card component has been introduced: pam_smartcard. PAM is Pluggable Authentication Modules.

The source code is available at macOS 10.12 Source and is part of the pam_modules component.


The pam_smartcard(8) manage is:
pam_smartcard(8)          BSD System Manager's Manual         pam_smartcard(8)

     pam_smartcard -- Smartcard PAM module

     [service-name] function-class control-flag pam_smartcard [options]

     The Smartcard PAM module supports authentication function class.  In
     terms of the function-class parameter, this is ``auth.''

   The Smartcard Authentication Module
     This module permits or denies users based on smartcard authentication
     support in the Open Directory database, and the presence of an appropri-
     ate smartcard in the reader attached to the local machine. When a card is
     locked, the user is asked to unlock it with his PIN.

   The following options may be passed to this account management module:
             Continues evaluation even if user's shell is not valid. Normally,
             users with a shell like /usr/bin/false are considered as dis-

     Adding the following line on the top of the /etc/pam.d/sudo enables smartcard support for sudo:
             auth   sufficient

     pam.conf(5), pam(8) SmartCardServices(7)

BSD                             August 27, 2015                            BSD

I guess this is related to the introduction of the native support of PIV cards in Sierra. See "macOS Sierra and PIVToken source code".

The pam_smartcard PAM module is used by two services by default:
  • authorization_ctk
  • screensaver_ctk
$ grep pam_smartcard /etc/pam.d/*
/etc/pam.d/authorization_ctk:auth       required  use_first_pass
/etc/pam.d/screensaver_ctk:auth       required  use_first_pass

$ cat /etc/pam.d/authorization_ctk 
# ctk: auth 
auth       required   use_first_pass
account    required

$ cat /etc/pam.d/screensaver_ctk 
# ctk: auth 
auth       required  use_first_pass
account    required
account    sufficient
account    required no_warn group=admin,wheel fail_safe
account    required no_warn deny group=admin,wheel ruser fail_safe


Another interesting man page is SmartCardServices(7). Here is an extract:
SmartCardServices(7) BSD Miscellaneous Information Manual SmartCardServices(7)

     SmartCardServices -- overview of smart card support

     SmartCardServices is a set of components for OS X smart card support.

     Any smart card which supports the PIV standard is supported natively by
     OS X. Access to smart card items is possible using the keychain inter-
     face. Applications can install additional drivers for smart cards that
     are not natively supported.

     Smart card certificates are automatically added to user's keychain when a
     smart card is inserted. Smart card certificates can be listed with
     security using the list-smartcards or export-smartcard commands. Keychain
     Access GUI cannot be used to manipulate or list these certificates.

     To associate users with smart cards, the system can be set up for either
     fixed key mapping or attribute based mapping. For fixed key use
     sc_auth(8) or use the dialog which appears automatically when an unasso-
     ciated smartcard is inserted into a reader. This dialog can be globally
     suppressed by:

           sudo defaults write /Library/Preferences/ UserPairing -bool NO

     Attribute matching can be set up using the appropriate AttributeMapping
     section in the configuration file as described below. There is no default
     configuration. If no AttributeMapping exists or the configuration file is
     missing, attribute matching is not used. If both fixed key mapping and
     attribute mapping are able to associate the inserted smart card with a
     user, attribute mapping takes precedence.

     By default certificates do not need to be trusted to allow association.
     Certificate trust can be globally enforced by setting:

           sudo defaults write /Library/Preferences/ checkCertificateTrust -bool YES



Since PAM is available in macOS maybe the PAM PKCS#11 module can be used without too much changes? This module is for GNU/Linux but may be adapted for macOS.

In this case, adding support for smart card login in macOS, if you already have a PKCS#11 library for your card, should be easy.


The use of smart card in macOS for high level services (like authentication) is easier in Sierra, at least for PIV smart cards.

I imagine that the support of other smart cards models will be proposed by third parties "soon".

macOS Sierra and smart card source code

Apple released the source code of the open source components they use in Sierra (OS X 10.12 released in September 2016). The components are available at OS X 10.12 Source.

As I did for El Capitan in "OS X El Capitan and smart card source code" I will document what I found.

The smart card related components are:

See "macOS Sierra and smart cards status" for a general discussion of the changes in El Capitan.


The version changed from 55108 in El Capitan to 55111 in Sierra.

The changes are very limited:
  • the Xcode project uses Security.framework
  • 1 bug fixed "to prevent uninitialized value when following CALL ends with exception" according to the source code comment

 SecurityTokend-55111/SecurityTokend.xcodeproj/project.pbxproj    |    6 ++++++
 SecurityTokend-55111/lib/transition.cpp                          |    1 +
 SecurityTokend-55111/security_tokend_client/transition.cpp       |    1 +
 3 files changed, 8 insertions(+)


The version changed from 55008.40.1 in El Capitan (10.11.4) to 55013 in Sierra.

No change:
  • the same libusb version 1.0.9 is used. This version was released in 2012-04-02. The latest libusb version is 1.0.21 released in 2016-10-01.
  • the CCID driver provided by Apple has 4 patches. These patches are related to the way Apple builds the driver.


No disruptive changes this time.

The source code of CryptoTokenKit (introduced in Yosemite. See "OS X Yosemite BETA and smart cards status") is not provided. That is not surprising since this it is an Apple only component and not a fork of an existing free software.

OS X El Capitan and CCID evolution

In a previous blog article "OS X El Capitan and CCID driver upgrades" I mentioned the evolution of the CCID driver for the same major release of OS X 10.11.x.

With the availability of the source code at Apple Open Source it is easy to see what happened.

OS X Version SmartcardCCID CCID
10.11 SmartcardCCID-55008 1.4.14
10.11.1 SmartcardCCID-55008 1.4.14
10.11.2 SmartcardCCID-55008.20.1 1.4.20
10.11.3 SmartcardCCID-55008.20.1 1.4.20
10.11.4 SmartcardCCID-55008.40.1 1.4.21
10.11.5 SmartcardCCID-55008.40.1 1.4.21
10.11.6 SmartcardCCID-55008.40.1 1.4.21

I will try to closely follow the evolution of macOS Sierra (10.12) source code to avoid surprises in the future.