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.

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)

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.

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

Deprecated tokend API is now replaced

In "macOS Sierra and CryptoTokenKit API" I presented the updated CryptoTokenKit API. This API is not completely new but was not really used.

Apple now provides the source code of PIVToken: a token for PIV (Personal Identity Verification) smart cards using the new API instead of the old tokend/CDSA API.

PIVToken : short source code

The code is available at Code sample: PIVToken: Using CryptoTokenKit to add support for new types of tokens.

I used the tools sloccount to count the number of lines of code.

$ sloccount .
SLOC Directory SLOC-by-Language (Sorted)
493     PIVToken        objc=493

Totals grouped by language (dominant language first):
objc:           493 (100.00%)

$ scloccunt --details .
227 objc PIVToken PIVToken/Token.m
162 objc PIVToken PIVToken/TokenSession.m
50 objc PIVToken PIVToken/NSData_Zip.m
14 objc PIVToken PIVToken/TokenSession.h
36 objc PIVToken PIVToken/Token.h
4 objc PIVToken PIVToken/NSData_Zip.h

The token is only 493 lines of Objective-C.

I am not a PIV expert or even user so I can't really tell if all the PIV features are supported in this token.

Subject to changes

" This sample demonstrates how to write an extension for CryptoTokenKit framework to support new types of SmartCards or any other cryptographic token. "

I would not be surprised if the code changes before the final macOS Sierra release.

Conclusion

It is time to study the sample code and work on replacement of existing tokend tokens.

I just released a new version of pcsc-tools, a suite of tools for PC/SC.

Changes:
1.4.27 - 2 July 2016, Ludovic ROUSSEAU

• 72 new ATRs
• ATR_analysis: propose to submit the ATR if not known
• pcsc_scan: Handle "simultaneous" readers removal

macOS Sierra

Apple presented macOS Sierra 10.12 during the World Wide Developer Conference (WWDC) 2016 in June 13, 2016.

https://en.wikipedia.org/w/index.php?curid=50807596

I could not find information about smart cards or CryptoTokenKit API in Apple Sierra preview page or Wikipedia Sierra page. I am not surprised. Smart cards are far less used than Siri for example :-)

I already wrote about the CryptoTokenKit API when this API has been introduced in "OS X Yosemite BETA and smart cards status" in July 2014, 2 years ago.

It looks like the CryptoTokenKit API is more mature now since the documentation is available as web pages (and not just .h header files).

CryptoTokenKit

The API documentation web page is "CryptoTokenKit Access Smart Cards and manage user interactions."

A lot of functions are marked as Beta. So I would expect some/many changes between the beta version(s) of Sierra and the official Sierra release planned for fall 2016.

Beta Software

This documentation contains preliminary information about an API or technology in development. This information is subject to change, and software implemented according to this documentation should be tested with final operating system software.

Conclusion

Only Apple developers have access to this first Sierra beta version. Because of the Apple NDA I can't write about information not already public.

A new beta version of macOS Sierra should be available in July 2016. This time it will be a public beta for everyone. More information to come...

Last year (May 2015) I presented the new UEFI (Unified Extensible Firmware Interface Specification) protocol called "Smart Card Reader Protocol" in the article "UEFI Smart Card Reader Protocol".

I also presented a sample Hello World application in "PCSC sample in C for UEFI".

Source code

The source code of my implementation of the protocol is available in my github edk2 project. Be sure to use the SmartCard branch.

The source code of the Hello World application and some other test/debug tools is available in my github UEFI-SmartCardReader-Samples project.

Integration in TianoCore

My "Smart Card Reader Protocol" implementation is a port of my CCID driver. So the core of the driver uses the same GNU LGPL v2+ license.
I proposed my implementation on the edk2-devel mailing list in "[edk2] [PATCH 0/4] Add an implementation of EFI_SMART_CARD_READER_PROTOCOL".

Unfortunately the copyleft license GNU LGPL v2+ is a problem for some TianoCore members. So my code was not integrated in TianoCore (a reference implementation of UEFI) and I moved to something else.

Conclusion

You can use my implementation of the "Smart Card Reader Protocol". Be careful the GNU LGPL v2+ license is fine with your project.

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

Changes:
1.8.17: Ludovic Rousseau
29 May 2016

• Fix SCardEndTransaction() issue with a SCARD_SHARE_EXCLUSIVE connection
• Fix an issue when used with systemd (problem in signal handler)
• SCardGetAttrib(): set pcbAttrLen when buffer is too small
• Doxygen: SCardGetAttrib() pbAttr can be NULL
• Doxygen: SCardGetAttrib() *pcbAttrLen contains the buffer size
• fix compilation warnings and link errors on SunOS
• Some other minor improvements

I just released a new official version 1.9.4 of pyscard. PySCard is a python module adding smart cards support (PC/SC) to Python.

The PySCard project is available at:

• sourceforge
• pypi
• github

Changes

1.9.4 (May 2016)

• Fix installation using pip and easy_install
• Avoid El Capitan SCardGetAttrib bug
• CardConnection: Add context management
• PCSCCardConnection: raise NoCardException if SCARD_E_NO_SMARTCARD
• Stop CardMonitor monitor thread after traceback print.
• minor improvements

1.9.3 (March 2016)

• Fix SCardControl() on Windows 7
• Fix installation using pip and easy_install