ATR statistics: T0 - Format byte

Article from the series "ATR statistics"

T0 - Format byte

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#Format_byte_T0:

Format byte T0

The Format byte T0 encodes in its 4 low-order bits (4th MSbit to 1st LSbit) the number K of historical bytes Ti, in range [0..15].
It also encodes in its 4 high-order bits the presence of at most 4 other interface bytes: TA1 (resp. TB1, TC1, TD1) follow, in that order, if the 5th (resp. 6th, 7th, 8th) bit of T0 is 1.

T0 # %
0xFF 160 7.72 %
0x9F 145 7.00 %
0x8F 108 5.21 %
0x6F 101 4.87 %
0x7F 87 4.20 %
0x6E 82 3.96 %
0x65 58 2.80 %
0x9E 51 2.46 %
0x7D 45 2.17 %
0x67 43 2.08 %
0xEF 40 1.93 %
0x88 37 1.79 %
0x6D 31 1.50 %
0xFD 28 1.35 %
0x3F 25 1.21 %
0xFA 25 1.21 %
0x68 24 1.16 %
0x04 23 1.11 %
0x3B 22 1.06 %
0x85 22 1.06 %
0xF7 22 1.06 %
0xDB 21 1.01 %
0xBE 20 0.97 %
0xBF 20 0.97 %
0x16 19 0.92 %
0x6B 19 0.92 %
0x8C 19 0.92 %
0xDF 19 0.92 %
0xFB 19 0.92 %
0x8A 18 0.87 %
0xF9 17 0.82 %
0x1F 16 0.77 %
0x66 16 0.77 %
0x69 16 0.77 %
0x7E 16 0.77 %
0x89 16 0.77 %
0x78 15 0.72 %
0x95 15 0.72 %
0xFE 15 0.72 %
0x17 13 0.63 %
0x77 13 0.63 %
0x8E 13 0.63 %
0xDD 13 0.63 %
0xF8 13 0.63 %
0x2F 12 0.58 %
0x6A 12 0.58 %
0x6C 12 0.58 %
0x86 12 0.58 %
0x8B 12 0.58 %
0xE9 12 0.58 %
0x7A 11 0.53 %
0x98 11 0.53 %
0x9A 10 0.48 %
0x9D 10 0.48 %
0xBA 10 0.48 %
0x27 9 0.43 %
0x82 9 0.43 %
0x87 9 0.43 %
0xBC 9 0.43 %
0xE6 9 0.43 %
0x06 8 0.39 %
0x19 8 0.39 %
0x2A 8 0.39 %
0x7B 8 0.39 %
0x84 8 0.39 %
0xF2 8 0.39 %
0xFC 8 0.39 %
0x0F 7 0.34 %
0x26 7 0.34 %
0x3D 7 0.34 %
0x75 7 0.34 %
0x79 7 0.34 %
0xB7 7 0.34 %
0xD5 7 0.34 %
0xEA 7 0.34 %
0xF5 7 0.34 %
0x15 6 0.29 %
0x23 6 0.29 %
0x3C 6 0.29 %
0x76 6 0.29 %
0xA7 6 0.29 %
0x02 5 0.24 %
0x24 5 0.24 %
0x8D 5 0.24 %
0xB2 5 0.24 %
0xE2 5 0.24 %
0xE8 5 0.24 %
0xEE 5 0.24 %
0x05 4 0.19 %
0x18 4 0.19 %
0x7C 4 0.19 %
0x9C 4 0.19 %
0xB3 4 0.19 %
0xD9 4 0.19 %
0xDC 4 0.19 %
0xDE 4 0.19 %
0xE7 4 0.19 %
0xF0 4 0.19 %
0xF6 4 0.19 %
0x07 3 0.14 %
0x12 3 0.14 %
0x1B 3 0.14 %
0x1D 3 0.14 %
0x29 3 0.14 %
0x37 3 0.14 %
0x3E 3 0.14 %
0x5F 3 0.14 %
0x64 3 0.14 %
0x97 3 0.14 %
0x99 3 0.14 %
0x9B 3 0.14 %
0xB9 3 0.14 %
0xBB 3 0.14 %
0xBD 3 0.14 %
0xD2 3 0.14 %
0xD6 3 0.14 %
0xEC 3 0.14 %
0xED 3 0.14 %
0xF4 3 0.14 %
0x0A 2 0.10 %
0x32 2 0.10 %
0x34 2 0.10 %
0x5B 2 0.10 %
0x81 2 0.10 %
0x83 2 0.10 %
0x90 2 0.10 %
0x96 2 0.10 %
0xA8 2 0.10 %
0xAA 2 0.10 %
0xAC 2 0.10 %
0xB0 2 0.10 %
0xB8 2 0.10 %
0xD8 2 0.10 %
0xDA 2 0.10 %
0xE0 2 0.10 %
0xE5 2 0.10 %
0xEB 2 0.10 %
0x00 1 0.05 %
0x09 1 0.05 %
0x0E 1 0.05 %
0x1C 1 0.05 %
0x1E 1 0.05 %
0x28 1 0.05 %
0x2D 1 0.05 %
0x57 1 0.05 %
0x5E 1 0.05 %
0x63 1 0.05 %
0x74 1 0.05 %
0x80 1 0.05 %
0x91 1 0.05 %
0x94 1 0.05 %
0xAB 1 0.05 %
0xAD 1 0.05 %
0xD0 1 0.05 %
0xE3 1 0.05 %
0xF3 1 0.05 %


Doing statistics on the complete T0 byte is not really informative.

Interface nibble

format # %
1 3 0.14 %
0 13 0.63 %
3 15 0.72 %
2 40 1.93 %
4 46 2.22 %
12 72 3.47 %
6 86 4.15 %
9 90 4.34 %
10 107 5.16 %
11 115 5.55 %
8 116 5.60 %
5 128 6.18 %
7 136 6.56 %
13 150 7.24 %
14 212 10.23 %
15 743 35.86 %


Interpretation

In 36% of the ATRs the LSB is equal to 15 (or 1111b in binary) indicating that TA1, TB1, TC1, TD1 are present.

For 10% of ATRs the LSB is equal to 14 (or 1110b in binary) indicating that TB1, TC1, TD1 are present, and TA1 is not present.

For 0.63% of ATRs the LSB is equal to 0 (or 0000b in binary) indicate that TA1, TB1, TC1, TD1 are all absent.

A better way to display the result is to isolate TA1, TB1, TC1, TD1 and count them independently.
interface # %
TA1 996 48.07 %
TB1 1355 65.40 %
TC1 1381 66.65 %
TD1 519 25.05 %


Historic nibble

historic # %
4 0 0.00 %
5 7 0.34 %
10 14 0.68 %
2 52 2.51 %
0 55 2.65 %
3 70 3.38 %
1 77 3.72 %
13 83 4.01 %
11 88 4.25 %
14 100 4.83 %
7 220 10.62 %
9 261 12.60 %
8 293 14.14 %
15 334 16.12 %
6 418 20.17 %


The number of historic bytes is not equally distributed between 0 and 15 bytes. I guess that is because the historic bytes are coded using a TLV format so some sizes are more frequent than others.



Update: 22th March 2020

It looks like the data for the Historic nibble are wrong. You can get correct values in the article "ATR statistics: Historical bytes - Historical bytes Ti (optional)".
Sorry for that mistake.

PCSC framework spy: broken since Mac OS X Yosemite

In "PCSC API spy, on Mac OS X" I proposed a way to spy on all PC/SC calls of an application.

A few months later Yosemite was available and my spying library does not work any more ☹.

PCSC framework replacement: fails

Example of failure:
$ DYLD_FRAMEWORK_PATH=/tmp pcsc_scan
PC/SC device scanner
V /Users/lroussea/Documents/sc/costa/pcsc-tools (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.4.0
SCardEstablishContext: Service not available.

Spy output (in a second terminal window):
$ ./pcsc-spy
SCardEstablishContext
 i dwScope: SCARD_SCOPE_SYSTEM (0x00000002)
 o hContext: 0x00000000
 => Service not available. (SCARD_E_NO_SERVICE [0x8010001D])  [0.000001109]
SCardReleaseContext
 i hContext: 0x00000000
 => Invalid handle. (SCARD_E_INVALID_HANDLE [0x80100003])  [0.000000006]

Results sorted by total execution time
total time: 0.001138 sec
0.001109 sec (  1 calls) 97.45% SCardEstablishContext
0.000006 sec (  1 calls)  0.53% SCardReleaseContext

If I run pcsc_scan alone, with no PC/SC spy, then the command runs as expected.

Something detects the usage of a new PCSC framework and rejects the first call. I guess the culprit is the original PCSC framework itself and this is a new security feature from Yosemite.

Running the application as root (using sudo) does not help.

SIP: System Integrity Protection

A new change since El Capitan is that the use of DYLD_FRAMEWORK_PATH does not work for programs in protected directories, like /usr/bin/.
$ type pcsctest
pcsctest is hashed (/usr/bin/pcsctest)

$ DYLD_FRAMEWORK_PATH=/tmp pcsctest

MUSCLE PC/SC Lite Test Program

Testing SCardEstablishContext    : Command successful.
Testing SCardGetStatusChange 
Please insert a working reader   : Command successful.
Testing SCardListReaders         : Command successful.
Reader 01: Gemalto PC Twin Reader
Enter the reader number          : ^C

Here the command succeeds but nothing is sent over the spy pipe.

In Yosemite I could use DYLD_FRAMEWORK_PATH=/tmp but with the same results as described above. On El Capitan the dynamic linker dyld just ignores DYLD_FRAMEWORK_PATH.

Another way to check that is to use lldb, the debugger provided with Xcode.

$ lldb pcsctest
(lldb) target create "pcsctest"
Current executable set to 'pcsctest' (x86_64).
(lldb) run
error: process exited with status -1 (cannot attach to process due to System Integrity Protection)
(lldb) quit

Conclusion

I know no way to spy the PC/SC calls done by an application on Mac OS X (with version >= 10.10).

This is problematic because PC/SC is still unstable on El Capitan. See "OS X El Capitan and smart cards: known bugs" for example. In some cases it would really help to know what PC/SC call returns an error to be able to:
  • Report the error to Apple if it is a bug in PC/SC
  • Tell the customer that it is a bug on Apple side
  • Try to find a way to avoid the problem, if possible

PySCard 1.9.2 released

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

The PySCard project is available at:


Changes

1.9.2 (February 2016)
  • Fix toBytes regression
  • Fix installation using pip
  • improve pydoc documentation
  • user-guide.rst: use real sample codes
  • minor improvements

I forgot to announce the previous version 1.9.1 on the blog.

1.9.1 (September 2015)
  • Create a new version so that the upload to Pypi does _not_ contain the swig generated files.

Remaining problem

The versions 1.9.1 and 1.9.2 were supposed to fix  a problem when the software is installed using pip. But the problem is still present ☹.

The best way, for now, to install the software from source code is to use:
$ cd pyscard-1.9.2
$ python setup.py install

ATR statistics: TS, initial character

Article from the series "ATR statistics"

TS: initial character

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#Initial_character_TS:

Initial character TS

The initial character TS encodes the convention used for encoding of the ATR, and further communications until the next reset. In direct [resp. inverse] convention, bits with logic value ‘1’ are transferred as a High voltage (H) [resp. a Low voltage (L)]; bits with logic value ‘0’ are transferred as L [resp. H]; and least-significant bit of each data byte is first (resp. last) in the physical transmission by the card.
For  direct   convention, TS is (H) L H H L H H H L L H (H) and encodes the byte ‘3B’.
For inverse convention, TS is (H) L H H L L L L L L H (H) and encodes the byte ‘3F’.
[ (H) represents the idle (High, Mark) state of the I/O line. The 8 data bits are shown in italic. ]
Bits in bytes following TS in the ATR, and further communications until the next reset, are numbered 1st to 8th from low-order to high-order, and their value noted 0 or 1, regardless of the chronological order and electrical representation, defined by TS. The bit following the 8 data bits in these bytes is an even parity bit, that is such that there's an even number of ‘1’ bits (H or L according to the direct or inverse convention defined by TS) among the 8 data bits and the parity bit.
TS also allows the card reader to confirm or determine the ETU, as one third of the delay between the first and second H-to-L transition in TS. This is optional, and the principal definition of ETU in the ATR of standard-compliant asynchronous Smart Cards is 372 periods of the clock received by the card

This first byte is used to indicate how bits and bytes are encoded at the electrical level: direct or inverse convention.

This choice has no impact on performances. As you can see, the vast majority of cards (94%) are using the direct convention (0x3B).

TS # %
0x3B 1945 93.87 %
0x3F 127 6.13 %


New PyKCS11 1.3.2 available

I just released a new version of PyKCS11, a Python wrapper above the PKCS#11 API.

See PyKCS11 introduction for more details about PyKCS11.

Changes:
1.3.2 - January 2016, Ludovic Rousseau

  • Add wrappers for C_Verify, C_WrapKey, C_UnwrapKey
  • PKCS#11 definitions: sync with Cryptoki version 2.30
  • Generate CKM[CKM_VENDOR_DEFINED+x] values on the fly
  • Fix use of a pinpad reader CKF_PROTECTED_AUTHENTICATION_PATH
  • dumpit.py: lots of small fixes
  • Setup call make to build pykcs11_wrap.cpp using SWIG
  • Fix build on Windows
  • Small bugs fixed

I also noticed that I forgot to blog about the previous version: 1.3.1

Changes:
1.3.1 - October 2015, Ludovic Rousseau
  • PKCS#11 definitions: sync with Cryptoki version 2.30
  • Add user type CK_CONTEXT_SPECIFIC
  • Fixes #9, incorrect assignment of pParameter for CK_MECHANISMs.
  • CKA_DERIVE is a CK_BBOOL and not byte array
  • Add digest() and encrypt method to Session class
  • Add samples:
    • key-pair generation
    • key-pair generation + certificate import
    • printing public key modulus
    • computing signature
  • small bugs fixed

ATR statistics: ATR list growth

Article from the series "ATR statistics"

Evolution of the number of ATRs

Since 2002 I add new ATRs in the ATR list, ATRs submitted by users of my tools: ATR_analysis and Smart card ATR parsing. I wanted to know how regularly I did that over the lifetime of the project (more than 14 years now).

I now have 2098 ATR entries in my list.

Graph



I am really surprised by the linearity of the curve.

The curve does not start at 0 ATR because the first versions of the list were stored in CVS Version Control System (I then used Subversion and now GIT). It looks like I lost the CVS history when I moved to Subversion in 2009.




The linear correlation equation is (according to Numbers): y = 6.308e-6 x - 940.4
That is a progression of 6.308x10-6 ATR per second, or 0.54 ATR per day, or 3.8 ATR per week, or 199 ATR per year.

The coefficient of determination R2 is equal to 0.996 (very close to 1) so the linear approximation is quiet good.

Conclusion

The progression may stay constant as new smart cards, with new ATRs, are continuously delivered to users by smart card providers.

Maybe this data is a good indication of the health of the smart card industry? What do you think?

ATR list study

Since 2002 I maintain a list of ATR (Answer-to-Reset). The idea is to identify a smart card given its ATR.

The project started as a Perl script (ATR_analysis from the pcsc-tools project), then moved into a Python script (parseATR.py from parseATR sub-project of pyscard-contrib) and is now a online web application: Smart card ATR parsing.

I now have 2098 ATRs in my list and I think it is time to make some statistics.

Articles

This article is a meta article (as I did with "CCID descriptor statistics") and contains only pointers to other articles:

Documentation

You can read the Wikipedia pages about Answer-to-Reset and ISO 7816.

Or you can pay 178 CHF (162 €) to buy and read the ISO 7816-3 document (the price is the same for a PDF version or a printed version on dead trees).

Yes, I find it stupid to have to pay to read standards. Luckily the Internet is build upon free (as in free beer) Request for Comments (RFC) from The Internet Engineering Task Force (IETF®) and not ISO protocols. But that is not the subject of this article.

New version of libccid: 1.4.22

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

Changes:
1.4.22 - 10 January 2016, Ludovic Rousseau

  • Add support of
    • Aktiv Rutoken PINPad 2
    • Aladdin R.D. JC-WebPass (JC600)
    • Aladdin R.D. JCR-770
    • Aladdin R.D. JaCarta
    • Aladdin R.D. JaCarta Flash
    • Aladdin R.D. JaCarta LT
    • Aladdin R.D. JaCarta U2F (JC602)
    • Athena ASEDrive IIIe Combo Bio PIV
    • Athena ASEDrive IIIe KB Bio PIV
    • GEMALTO CT1100
    • GEMALTO K1100
    • Hitachi, Ltd. Hitachi Biometric Reader
    • Hitachi, Ltd. Hitachi Portable Biometric Reader
    • Nitrokey Nitrokey Storage
    • THURSBY SOFTWARE TSS-PK1
    • Thursby Software Systems, Inc. TSS-PK7
    • Thursby Software Systems, Inc. TSS-PK8
  • Patch for Microchip SEC1110 reader on Mac OS X (card events notification)
  • Patch for Cherry KC 1000 SC (problem was with a T=1 card and case 2 APDU)
  • Fix support of FEATURE_MCT_READER_DIRECT for the Kobil mIDentity visual reader
  • Set timeout to 90 sec for PPDU (Pseudo APDU) commands. This change allows the use of a Secure Verify command sent as a PPDU through SCardTransmit().
  • Fix a crash when reader reader initialization failed
  • Fix initialization bug with Gemalto Pinpad reader on Mac OS X
  • Some minor bugs fixed

Someone is playing with my online ATR parsing tool

I provide a Smart card ATR parsing online tool since 2010. See "Parsing an ATR: now more web 2.0 friendly" for the previous article about it.

The online tool is no more available and you get the error message:


This is because a computer has provided the same ATR (the default one) over and over again until my quota was exceeded.


I know the IP address of the offending computer: 167.114.13.x. It is a computer in an OVH data center in Beauharnois (BHS) Canada.

The quota should be restored every 24 hours so the web application may be available again when you read this.

If you are the owner of the offending computer please stop. It is a denial of service. It is not funny.

For the others, sorry for the inconvenience.