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.

Sunday, August 28, 2016

ATR statistics: TB1 - Global, deprecated

Article from the series "ATR statistics"

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

TB1, if present, is global. The usage of TB1 is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB1 in the ATR, and readers shall ignore TB1 if present. EMV still requires that the card includes TB1 = ‘00’, and that remains common practice; doing so explicitly indicates that the card does not use the dedicated contact C6 for the purpose of supplying a programming voltage (VPP) to the card; the cards might however use C6 for Standard or Proprietary Use (SPU), such as communicating with a NFC front end by the Single Wire Protocol (SWP). On the reader side, EMV requires making a warm ATR for cards with TB1 other than ‘00’ in the cold ATR, and handling any TB1 in a warm ATR as if it was ‘00’.

TB1 was previously indicating (coarsely) the programming voltage VPP and maximum programming current required by some cards on the dedicated contact C6 during programming of their EPROM memory. Modern Smart Cards internally generate the programming voltage for their EEPROM or Flash memory, and thus do not use VPP. In the 1997 and earlier editions of the standard:
  • The low 5 bits of TB1 (5th MSbit to 1st LSbit) encode PI1; if TB2 is absent, PI1 = 0 indicates that the C6 contact (assigned to VPP) is not connected in the card; PI1 in range [5..25] encodes the value of VPP in Volt (the reader shall apply that voltage only on specific demand by the card, with a tolerance of 2.5%, up to the maximum programming current; and otherwise leave the C6 contact used for VPP within 5% of the VCC voltage, up to 20 mA); if TB2 is present, it supersedes the indication given by TB1 in the PI1 field, regarding VPP connection or voltage.
  • The high bit of TB1 (8th bits) is reserved, shall be 0, and can be ignored by the reader.
  • The 6th and 5th bits of TB1 encode the maximum programming current (assuming neither TB1 nor TB2 indicate that VPP is not connected in the card).

7th and 6th bits 00 01 10 11
Maximum programming current 25 mA 50 mA RFU(#) RFU
(#) This was 100 mA in ISO/IEC 7816-3:1989.

0x00122859.27 %
77637.45 %
0x25612.94 %
0x2F20.10 %
0x3520.10 %
0x2010.05 %
0x3F10.05 %
0xFF10.05 %

Only 68 ATRs (3.2%) have a TB1 different from 0x00.

The TB1 value found are (in order of appearance):
  • 0x25 "Programming Param P: 5 Volts, I: 50 milliamperes"
  • 0x2F "Programming Param P: 15 Volts, I: 50 milliamperes"
  • 0x35 "Programming Param P: 21 Volts, I: 50 milliamperes"
  • 0x20 "VPP is not electrically connected"
  • 0x3F "Programming Param P: 31 Volts, I: 50 milliamperes"
  • 0xFF "Programming Param P: 31 Volts, I: RFU"

Most of the smart cards with TB1 = 0x25 are PayTV cards. maybe TB1 is using a non standard value to confuse the smart card reader.

Wednesday, August 24, 2016

Broadcom CCID readers

logo de Broadcom Corporation
Par inconnu —, marque déposée,

Broadcom updated the firmware of some of their (bogus) devices. For example the reader Broadcom Corp 5880 (idProduct 0x5805) is bogus. The problem is that frames bigger than 64 bytes (wMaxPacketSize) fails on the contact reader.

Broadcom 5880

The 5880 device name is used by all the 8 Broadcom devices in my list. So it is not easy to know exactly what device is present in a computer. You can use the GNU/Linux command line lsusb or my program parse to have more details.

Dell laptops

logo de Dell
Par Dell — Dell, Domaine public,

The Broadcom devices are often present in Dell laptop.

For example the Dell Latitude E5570 has one such Broadcom 5880 device. This is the version idProduct 0x5805 with the bug described above.

Firmware upgrade

Dell now provides a firmware upgrade Dell ControlVault2 Driver and Firmware that includes a fix for the smart card reader. After the firmware upgrade the smart card reader has a new idProduct 0x5834.

This device is already in the "should work" list and will be included in the CCID driver version 1.4.25 (available soon).

Contactless reader

The Broadcom 5880 in the Dell Latitude E5570 (with idProduct 0x5805 and 0x5834 after the upgrade) also provides a contactless interface. But this contactless interface is still not supported by my CCID driver.

I guess the interface is not really CCID compliant and no RF (radio frequency) field is emitted by the reader. I guess a special command has to be send to the reader to activate the RF field, maybe to limit the power consumption when no contactless card is used.


3 Broadcom 5880 devices are in the "unsupported" list. Maybe the firmware upgrade will fix all of them. At least the upgrade fixes 2 of them (the 0x5805 as above and also the 0x5800 converted in 0x5832)

Friday, August 12, 2016

pcsc-lite: (much) faster SCardDisconnect()

Since pcsc-lite 1.8.18 the function SCardDisconnect() has a new behaviour.

Some history

Always on

At the beginning of pcsc-lite (circa 1999) the card was always powered on when inserted in a smart card reader. The code was simple: when a card is inserted in a reader then power on the card. This worked great.

At that time the USB 1.1 was quite new and most smart card readers were using a serial port and an external power supply.

Auto power off

In 2010 most of the smart card readers were connected using USB and used the USB cable to get the power. So it was a good idea to power off a smart card that is not used to reduce the power consumed in particular when you use a laptop computer.

So I implemented a mechanism to automatically power off an unused card. The card is powered off if it is not used 5 seconds after the power on. See "Card auto power on and off" for more details.

SCardDisconnect(..., SCARD_UNPOWER_CARD) would power off the card, power it on again and 5 seconds later, if not used, power off the card.

Remove extra power on

SCardDisconnect(..., SCARD_UNPOWER_CARD) would not return before the power on succeeds. This operation takes time because the reader has to get the ATR from the card. The application specifically used SCARD_UNPOWER_CARD so we can expect the card will not be used after that.

Since the card auto power on and off mechanism was already implemented in 2010 the card was already automatically powered on when needed. It was simple to modify the pcsc-lite code and remove the useless power on.


The benefit is simple: SCardDisconnect(..., SCARD_UNPOWER_CARD) is now much faster. I included some numbers in the patch commit message.

Before the change: SCardDisconnect(SCARD_UNPOWER_CARD) in 61 ms
After the change: SCardDisconnect(SCARD_UNPOWER_CARD) in 1.4 ms

Speedup (for the card used) = 61/1.4 = x44
If you use a card that is slower to power up then the gain is even higher.

I think a speedup of x10 or x100 on a PC/SC function deserve a blog article, even if SCardDisconnect(..., SCARD_UNPOWER_CARD) is not always on the performance critical path of an application.


I would like to thank Christophe FERRANDO from Sylyca for the implementation of this feature.


If you want to get a change or an improvement in pcsc-lite, just contact me.