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.

Wednesday, August 10, 2016

New version of pcsc-lite: 1.8.18

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

1.8.18: Ludovic Rousseau
10 August 2016
  • SCardDisconnect(): much faster with SCARD_UNPOWER_CARD
  • SCardConnect(): Fix a possible duplicated hCard context
  • Fix compilation on FreeBSD
  • Fix compilation on Solaris
  • Some other minor improvements