Friday, September 30, 2016

New version of libccid: 1.4.25

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

1.4.25 - 30 September 2016, Ludovic Rousseau
  • Add support of
    • Aladdin R.D. JaCarta (idProduct: 0x0402)
    • Broadcom Corp 5880 (idProduct: 0x5832)
    • Broadcom Corp 5880 (idProduct: 0x5833)
    • Broadcom Corp 5880 (idProduct: 0x5834)
    • ESMART Token GOST X2 ET1020-A
    • Feitian VR504 VHBR Contactless & Contact Card Reader
    • Feitian bR500
    • Gemalto K50
    • appidkey GmbH ID100-USB  SC Reader
    • appidkey GmbH ID50 -USB
  • Remove suport of
    • Broadcom Corp 5880 (idProduct: 0x5800)
    • Broadcom Corp 5880 (idProduct: 0x5805)
    • KEBTechnology KONA USB SmartCard
  • macOS: Fix composite device enumeration
  • Fix crash with GemCore Pos Pro and GemCore Sim Pro
  • Some minor improvements

Wednesday, September 28, 2016

pam_pkcs11: new/last version 0.6.9


From the project wiki page:
This Linux-PAM login module allows a X.509 certificate based user login. The certificate and its dedicated private key are thereby accessed by means of an appropriate PKCS #11 module. For the verification of the users’ certificates, locally stored CA certificates as well as either online or locally accessible CRLs are used.

The idea is to use a smart card and its corresponding PKCS#11 library to login (and more) into a GNU/Linux system.


This version has many changes. The previous version 0.6.8 was released in April 2012. Thanks to all the contributors that provided patches.
  • Support many certificates
  • Italian translation
  • When searching LDAP, filter on the certificate
  • Add an LDAP "uid_attribute", use it to speed up
  • Add "attribute_map" to LDAP mapping
  • Treat "attribute_map" as a list of ANDed clauses
  • Do not fail if card was already unlocked, e.g. by a previous PAM module
  • Add CERT_SERIAL "serial" as a valid option
  • Support OpenSSL 1.1.x
  • Other minor changes


Download the .tar.gz archive from


I am the maintainer of pam_pkcs11 but it do not use this software any more and have no time to take care of this project. A new maintainer is welcome.

Tuesday, September 27, 2016

macOS Sierra and smart cards status

macOS Sierra (macOS 10.12) is now available since 20th September, 2016.

API Differences between 10.11 and 10.12

The differences are listed in the developer page macOS Sierra 10.12. The page only document big changes. Regarding smart cards we only have:

Support for Smart Card Driver Extensions

You can now create NSExtension-based smart card drivers, allowing the contents of certain types of smart cards to be presented as part of the system keychain. This mechanism is intended to replace the deprecated Common Data Security Architecture, although for macOS 10.12, both architectures are supported.

The driver extensions are limited to read-only mode, so that it is not possible to alter the contents of a smart card using the standard keychain interface. For more information, see CryptoTokenKit Framework Reference.

See also a previous blog article "macOS Sierra: Smart Card Driver Extensions". I guess I will write again about this new technology in future blog articles.

Updates on CryptoTokenKit framework, PCSC framework and CCID driver are not listed in this high level page.


Since Yosemite (10.10) the PC/SC layer is no more a fork of pcsc-lite. So comparing versions with pcsc-lite is useless.

$ cat /System/Library/Frameworks/PCSC.framework/Versions/A/Resources/version.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
The BuildVersion changed from 13 on El Capitan to 65 on Sierra, and SourceVersion changed from 79001001000000 to 196001003000000. I have no idea what the SourceVersion "number" is.

It looks like Apple made 65-13 = 52 builds of the PC/SC framework since Yosemite 10.11.0.

PC/SC Bugs fixed

These bugs were found in El Capitan and are now fixed in Sierra:
  1. SCardGetAttrib() returns SCARD_E_NOT_TRANSACTED when it should not
  2. Connecting a CT700 Gemalto smart card reader renders PC/SC useless
Some bugs reported on El Capitan are still present in Sierra. I updated the page "OS X El Capitan and smart cards: known bugs".

CCID driver

Driver version 1.4.24.
El Capitan had: 1.4.14 in 10.11.0 and 1.4.21 in 10.11.6

$ grep -A 1 CFBundleShortVersionString /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist
 You can have a look at the CCID README file to know what changes between version 1.4.21 and version 1.4.24.

Note that the CCID driver version 1.4.24 provided in macOS Sierra is the latest available version (as I write this blog). version 1.4.24 has been released in May 2016 (4 months ago only).

It is important to note that Apple regularly upgrades the CCID driver. I guess Apple will continue to upgrade the CCID driver in minor versions of Sierra, as they did with minor versions of El Capitan.


  • Some PC/SC framework bugs fixed.
  • Updated version of the CCID driver.
  • Support for Smart Card Driver Extensions (replacing tokend)

Saturday, September 17, 2016

ATR statistics: TC1 - Global, encodes N

Article from the series "ATR statistics"

TC1 - Global, encodes N

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 (with some edition to remove extra details):

TC1, if present, is global, and encodes the Extra Guard Time integer (N), from 0 to 255 (8th MSbit to 1st LSbit); otherwise, N = 0. N defines how much the Guard Time that the reader must apply varies from a baseline of 12 ETU (corresponding to 1 start bit, 8 data bits, 1 parity bit, and 2 stop bits; with the second stop bit possibly used for an error indication by the receiver under protocol T = 0). The Guard Time is the minimum delay between the leading edge of the previous character, and the leading edge of the next character sent.
Except when N is 255, the Guard Time is: GT = 12 ETU + R*N/f
  • f is the clock frequency being generated by the reader;
  • R is some number of clock cycles, either:
    • per ETU, R = F/D, if T = 15 is absent from the ATR;
    • defined by TA1, R = Fi/Di (or its default value), if T = 15 is present in the ATR.
N = 255 has a protocol-dependent meaning: GT = 12 ETU during PPS (Protocol and Parameters Selection) and protocol T = 0, GT = 11 ETU under protocol T = 1 (corresponding to 1 start bit, 8 data bits, 1 parity bit, and 1 stop bit; with no error indication).
Except under protocol T = 1, the card transmits with a Guard Time of 12 ETU, irrespective of N. Under protocol T = 1, the Guard Time defined by N is also the Character Guard Time (CGT), and applies to card and reader for characters sent in the same direction.
Note: The reader remains bound by the Guard Time GT defined by N when other prescriptions specify another minimum delay between leading edges of characters in different directions, even when that minimum is lower than GT.

Historical note: ISO/IEC 7816-3:1989 only defined that N code the EGT as a number of ETU, the method now used when T = 15 is absent from the ATR. With this convention, cards that allow negotiation of a reduced number of clock cycles per ETU after PPS must also allow a proportionally reduced number of clock cycles for the EGT, which does not match with a common EGT motivation: account for delays before the card can receive the next character. The 1997 edition of the standard introduced that when T = 15 is present in the ATR, N code the EGT as a multiple of the number of clock cycles per ETU coded by TA1, making the EGT effectively independent of the number of clocks cycles per ETU negotiated, while maintaining compatibility with former readers at least if they did not change the number of clock cycles per ETU.

To make it short TC1 defines a time value between characters transmitted the card and the reader. The default value correspond to a Guard Time of 12 ETU. But the card can specify a bigger value (the card is not fast enough).

91043.92 %
0x0079238.22 %
0xFF28713.85 %
0x02291.40 %
0x03180.87 %
0x01150.72 %
0x0860.29 %
0x0540.19 %
0x0430.14 %
0x0B20.10 %
0x0910.05 %
0x1010.05 %
0x3F10.05 %
0x6410.05 %
0x8110.05 %
0xFE10.05 %

The default value is 0. But 38.22% of cards explicitly define TC1=0.
A total of 82.14% of cards use the default value.
TC1=255 is also a special value not far from the default value of 12 ETU.

The real number of cards that are not fast enough to use the full speed is only of 4.00% (84 cards).

Friday, September 16, 2016

Smart Card Services moved from an Apple server to

Mac OS Forge

Apple had a software forge to host Free Software they used in Mac OS X. The site is and now indicates:
macOS forge hosted open source projects closely related to macOS.

One of the hosted project is:
Smart Card Services
The Smart Card Services project is comprised of several components which, when combined, provide the necessary abstraction layer and integration of smart cards into Apple’s CDSA implementation.

Smart Card Services contains different parts:

Alive projects?

From the list above most of the projects are now dead.
  • Since Yosemite, pcsc-lite is no more used and has been replaced in 2014 by Crypto Token Kit.
    See "OS X Yosemite BETA and smart cards status"
  • tokend architecture is deprecated since Lion in 2011
    See "Mac OS X Lion and tokend"
  • CCID driver is no more updated to reflect what is installed in current macOS versions.
    El Capitan provides the version 1.4.21 but the site still provides version 1.3.8.


The project Smart Card Services is interesting mainly for historical reasons. The development of smart card components available in macOS is now done elsewhere., i.e. internally at Apple and the source code is no more public.

Tuesday, September 13, 2016

macOS Sierra: Smart Card Driver Extensions

macOS Sierra is not yet available. But Apple already provides documentation about what is new.

Smart Card Driver

For example the page talks about the Smart Card Driver Extensions that will replace tokend:

Support for Smart Card Driver Extensions

You can now create NSExtension-based smart card drivers, allowing the contents of certain types of smart cards to be presented as part of the system keychain. This mechanism is intended to replace the deprecated Common Data Security Architecture, although for macOS 10.12, both architectures are supported.

The driver extensions are limited to read-only mode, so that it is not possible to alter the contents of a smart card using the standard keychain interface. For more information, see CryptoTokenKit Framework Reference.

Important points

"for macOS 10.12, both architectures are supported"

The good news is that both tokend and Smart Card Driver are supported in 10.12.

Note that Apple does not say what will happen in 10.13. I guess the message here is that support of tokend will be removed in 10.13.

tokend is deprecated since Mac OS X Lion (10.7 released in 2011. See "Mac OS X Lion and tokend"). tokend support may disappear in 2017 with 10.13. So that would be 6 years of deprecation.

"limited to read-only mode"

As with tokend the new token is also in read-only mode.


macOS Sierra will provide new technologies to play with. The smart card integration should be better.

PC/SC sample in go

To continue the list of PC/SC wrappers initiated in 2010 with "PC/SC sample in different languages" I now present a sample in go.

scard go wrapper

I used the scard go wrapper from Michael Gehring.

The github project does not provide any documentation. You can get some help from a previous project go.pcsclite also from Michael Gehring.

The scard wrapper API has a nice godoc page.


The installation is quiet simple.
$ cd foobar
$ export GOPATH=$(pwd)

$ go get

I used the default golang-go package on Debian stable (jessie 8.5).
$ go version
go version go1.3.3 linux/amd64

Sample source code

package main

import (

func main() {
    // Establish a PC/SC context
    context, err := scard.EstablishContext()
    if err != nil {
        fmt.Println("Error EstablishContext:", err)

    // Release the PC/SC context (when needed)
    defer context.Release()

    // List available readers
    readers, err := context.ListReaders()
    if err != nil {
        fmt.Println("Error ListReaders:", err)

    // Use the first reader
    reader := readers[0]
    fmt.Println("Using reader:", reader)

    // Connect to the card
    card, err := context.Connect(reader, scard.ShareShared, scard.ProtocolAny)
    if err != nil {
        fmt.Println("Error Connect:", err)

    // Disconnect (when needed)
    defer card.Disconnect(scard.LeaveCard)

    // Send select APDU
    var cmd_select = []byte{0x00, 0xa4, 0x04, 0x00, 0x0A, 0xA0,
  0x00, 0x00, 0x00, 0x62, 0x03, 0x01, 0x0C, 0x06, 0x01}
    rsp, err := card.Transmit(cmd_select)
    if err != nil {
        fmt.Println("Error Transmit:", err)

    // Send command APDU
    var cmd_command = []byte{0x00, 0x00, 0x00, 0x00}
    rsp, err = card.Transmit(cmd_command)
    if err != nil {
        fmt.Println("Error Transmit:", err)
    for i := 0; i < len(rsp)-2; i++ {
        fmt.Printf("%c", rsp[i])


You can get another sample code example_test.go in the scard project. This sample code greatly helped me implement my own sample code.


$ go run hello_world.go
Using reader: Gemalto PC Twin Reader (70D7E2EE) 00 00
[144 0]
[72 101 108 108 111 32 119 111 114 108 100 33 144 0]
Hello world!


The github project scard has no documentation or README file. After discussion with Michael Gehring it is on purpose.

This blog article should give more visibility to the project.