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 https://en.wikipedia.org/wiki/Answer_to_reset#Interface_byte_TB1 (with some edition to remove extra details):

TB₁, if present, is global. The usage of TB₁ is deprecated since the 2006 edition of the standard, which prescribes that cards should not include TB₁ in the ATR, and readers shall ignore TB₁ if present. EMV still requires that the card includes TB₁ = ‘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 (V_PP) 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 TB₁ other than ‘00’ in the cold ATR, and handling any TB₁ in a warm ATR as if it was ‘00’.

TB₁ was previously indicating (coarsely) the programming voltage V_PP 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 V_PP. In the 1997 and earlier editions of the standard:

• The low 5 bits of TB₁ (5th MSbit to 1st LSbit) encode PI1; if TB₂ is absent, PI1 = 0 indicates that the C6 contact (assigned to V_PP) is not connected in the card; PI1 in range [5..25] encodes the value of V_PP 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 V_PP within 5% of the V_CC voltage, up to 20 mA); if TB₂ is present, it supersedes the indication given by TB₁ in the PI1 field, regarding V_PP connection or voltage.
• The high bit of TB₁ (8th bits) is reserved, shall be 0, and can be ignored by the reader.
• The 6th and 5th bits of TB₁ encode the maximum programming current (assuming neither TB₁ nor TB₂ indicate that V_PP 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.

TB1	#	%
0x00	1228	59.27 %
	776	37.45 %
0x25	61	2.94 %
0x2F	2	0.10 %
0x35	2	0.10 %
0x20	1	0.05 %
0x3F	1	0.05 %
0xFF	1	0.05 %

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

The TB₁ 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 TB₁ = 0x25 are PayTV cards. maybe TB₁ is using a non standard value to confuse the smart card reader.

Broadcom CCID readers

Par inconnu — http://www.broadcom.com/company/factsheet.php?source=top, marque déposée, https://fr.wikipedia.org/w/index.php?curid=1691847

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

Par Dell — Dell, Domaine public, https://commons.wikimedia.org/w/index.php?curid=10341993

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.

Conclusion

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)

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.

Benefit

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.

Thanks

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

Conclusion

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

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.

Changes:
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