ATR parsing in JSON

I updated my ATR parsing web site at https://smartcard-atr.apdu.fr/ to add the option to get the result not in an HTML page but as a JSON document.

If you do not yet know this service you can read "Parsing an ATR: new web site URL" to get some history. 

JSON

The URL for the JSON service is https://smartcard-atr.apdu.fr/V1/parse2json?ATR=3BFF9700008131FE4380318065B0846160FB120FFD8290000D.

It is the same as for the HTML output https://smartcard-atr.apdu.fr/parse?ATR=3BFF9700008131FE4380318065B0846160FB120FFD8290000D except you replace "parse" by "V1/parse2json" in the URL.

Of course you update the ATR parameter value to use the ATR value you want to parse.

Examples

You can use it to get the description of a particular field by piping the result in the jq command.

jq is a lightweight and flexible command-line JSON processor.

For example to get the meaning of the TA₁ byte you can use:

$ curl -s https://smartcard-atr.apdu.fr/V1/parse2json?ATR=3B12953606 | jq '.TA."1"'
{
  "description": "Fi=512, Di=16, 32 cycles/ETU (125000 bits/s at 4.00 MHz, 156250 bits/s for fMax=5 MHz)",
  "value": 149
}

Or for just the TA₁ description:

$ curl -s https://smartcard-atr.apdu.fr/V1/parse2json?ATR=3B90160187 | jq '.TA."1".description'
"Fi=372, Di=32, 11.625 cycles/ETU (344086 bits/s at 4.00 MHz, 430107 bits/s for fMax=5 MHz)"

 

Card matching

I also added the possibility to get the cards matching a given ATR.

For example: https://smartcard-atr.apdu.fr/V1/match?ATR=3B8F800180318065B0850300EF120FFE82900072

$ curl -s https://smartcard-atr.apdu.fr/V1/match?ATR=3B8F800180318065B0850300EF120FFE82900072 | jq
{
  "3B 8F 80 01 80 31 80 65 B0 .. .. .. .. 12 0F FE 82 90 00 ..": [
    "IDPrime MD 3810 T=Contactless (Prox DU)"
  ],
  "3B 8F 80 01 80 31 80 65 B0 85 03 00 EF 12 0F FE 82 90 00 72": [
    "Gemalto IDPrime MD 3840",
    "http://www.gemalto.com/dwnld/6891_IDPrimeMD3840_Product_Datasheet_May14.pdf"
  ]
}

Because of the joker mechanism using the character '.' it is possible that one ATR matches more than one "card".

Conclusion

If you have ideas how to improve the service just tell me.

ATR statistics: ATR list growth (part 2)

In January 2016 I started a study of each byte contained in a smart card ATR. See "ATR list study".

My goal was to publish one new article every week. So with 19 bytes that was a job for 5 months. But it took me more than 4 years! I imagine it is because of some lack of time and/or motivation.

My first article was about the ATR list growth. In January 2016 I had 2098 ATRs in the list. Now I have 3316 ATRs in the list and the number is still growing.

Graph

The red line indicates the position in January 2016.

New ATRs only

In 2016 the linear regression for the graph was y = 6.308x10^-6 x - 940.4.
For the last 4 years it is y = 9.381x10^-6 x - 2409.7

The growth is now 48% faster than before. Woah!

I guess that is because it is very simple to submit a new ATR using the web interface at https://smartcard-atr.apdu.fr/. Before I create this service, in 2010, you had to send me a new ATR by email. Now you just (mostly) click on a button.

No, I will not re-compute all the statistics with the new, more complete, ATR list.

Thank you

to all of you who submit new ATRs.

ATR statistics: TCK - Check byte TCK (conditional)

Article from the series "ATR statistics".

TCK - Check byte TCK (conditional)

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

The ChecK byte (if present) allows a check of the integrity of the data in the ATR. If present, TCK is the Exclusive OR of the bytes in the ATR from T0 (included) to TCK (excluded).
TCK shall be present if and only if any of the TD_i present in the ATR encodes a value of T other than 0.

TCK	#	%
	1103	53.23 %
0x00	123	5.94 %
0x12	9	0.43 %
0x28	9	0.43 %
0x05	8	0.39 %
0x89	8	0.39 %
0x99	8	0.39 %
0xC1	8	0.39 %
0x03	7	0.34 %
0x09	7	0.34 %
0x0E	7	0.34 %
0x16	7	0.34 %
0x1C	7	0.34 %
0x38	7	0.34 %
0x43	7	0.34 %
0x65	7	0.34 %
0x88	7	0.34 %
0x8C	7	0.34 %
0xA5	7	0.34 %
0xB7	7	0.34 %
0x06	6	0.29 %
0x0D	6	0.29 %
0x15	6	0.29 %
0x1B	6	0.29 %
0x4A	6	0.29 %
0x52	6	0.29 %
0x59	6	0.29 %
0x5A	6	0.29 %
0x62	6	0.29 %
0x6A	6	0.29 %
0x6D	6	0.29 %
0x76	6	0.29 %
0x77	6	0.29 %
0x7A	6	0.29 %
0x7F	6	0.29 %
0x83	6	0.29 %
0x90	6	0.29 %
0x9C	6	0.29 %
0xA1	6	0.29 %
0xA9	6	0.29 %
0xF3	6	0.29 %
0xFF	6	0.29 %
0x-1	5	0.24 %
0x0A	5	0.24 %
0x0F	5	0.24 %
0x14	5	0.24 %
0x18	5	0.24 %
0x1E	5	0.24 %
0x31	5	0.24 %
0x3A	5	0.24 %
0x3C	5	0.24 %
0x45	5	0.24 %
0x58	5	0.24 %
0x6B	5	0.24 %
0x75	5	0.24 %
0x7E	5	0.24 %
0x80	5	0.24 %
0x84	5	0.24 %
0x8F	5	0.24 %
0x98	5	0.24 %
0xB6	5	0.24 %
0xBD	5	0.24 %
0xC4	5	0.24 %
0xCC	5	0.24 %
0xD2	5	0.24 %
0xDA	5	0.24 %
0xFE	5	0.24 %
0x07	4	0.19 %
0x17	4	0.19 %
0x19	4	0.19 %
0x1A	4	0.19 %
0x1D	4	0.19 %
0x21	4	0.19 %
0x24	4	0.19 %
0x32	4	0.19 %
0x39	4	0.19 %
0x3F	4	0.19 %
0x49	4	0.19 %
0x4C	4	0.19 %
0x5C	4	0.19 %
0x5E	4	0.19 %
0x60	4	0.19 %
0x63	4	0.19 %
0x68	4	0.19 %
0x6C	4	0.19 %
0x70	4	0.19 %
0x71	4	0.19 %
0x74	4	0.19 %
0x79	4	0.19 %
0x86	4	0.19 %
0x8A	4	0.19 %
0x91	4	0.19 %
0x95	4	0.19 %
0x9B	4	0.19 %
0x9D	4	0.19 %
0x9F	4	0.19 %
0xA0	4	0.19 %
0xA2	4	0.19 %
0xA6	4	0.19 %
0xB0	4	0.19 %
0xB4	4	0.19 %
0xBE	4	0.19 %
0xC9	4	0.19 %
0xD0	4	0.19 %
0xD6	4	0.19 %
0xE0	4	0.19 %
0xE1	4	0.19 %
0xE9	4	0.19 %
0xEC	4	0.19 %
0xF8	4	0.19 %
0x01	3	0.14 %
0x02	3	0.14 %
0x08	3	0.14 %
0x0C	3	0.14 %
0x1F	3	0.14 %
0x2A	3	0.14 %
0x30	3	0.14 %
0x33	3	0.14 %
0x3D	3	0.14 %
0x47	3	0.14 %
0x4D	3	0.14 %
0x4E	3	0.14 %
0x4F	3	0.14 %
0x53	3	0.14 %
0x55	3	0.14 %
0x57	3	0.14 %
0x5B	3	0.14 %
0x6F	3	0.14 %
0x72	3	0.14 %
0x78	3	0.14 %
0x7B	3	0.14 %
0x7D	3	0.14 %
0x82	3	0.14 %
0x92	3	0.14 %
0x94	3	0.14 %
0x97	3	0.14 %
0x9A	3	0.14 %
0x9E	3	0.14 %
0xA8	3	0.14 %
0xAA	3	0.14 %
0xAB	3	0.14 %
0xAD	3	0.14 %
0xB1	3	0.14 %
0xB9	3	0.14 %
0xBC	3	0.14 %
0xC2	3	0.14 %
0xC5	3	0.14 %
0xCF	3	0.14 %
0xD3	3	0.14 %
0xD4	3	0.14 %
0xD7	3	0.14 %
0xDF	3	0.14 %
0xEF	3	0.14 %
0xF2	3	0.14 %
0xF4	3	0.14 %
0xF7	3	0.14 %
0xFA	3	0.14 %
0x10	2	0.10 %
0x11	2	0.10 %
0x13	2	0.10 %
0x22	2	0.10 %
0x25	2	0.10 %
0x26	2	0.10 %
0x27	2	0.10 %
0x29	2	0.10 %
0x2B	2	0.10 %
0x2D	2	0.10 %
0x2E	2	0.10 %
0x35	2	0.10 %
0x36	2	0.10 %
0x3B	2	0.10 %
0x40	2	0.10 %
0x41	2	0.10 %
0x48	2	0.10 %
0x50	2	0.10 %
0x51	2	0.10 %
0x54	2	0.10 %
0x5D	2	0.10 %
0x5F	2	0.10 %
0x64	2	0.10 %
0x66	2	0.10 %
0x67	2	0.10 %
0x69	2	0.10 %
0x73	2	0.10 %
0x7C	2	0.10 %
0x85	2	0.10 %
0x87	2	0.10 %
0x8B	2	0.10 %
0x8D	2	0.10 %
0x8E	2	0.10 %
0xAC	2	0.10 %
0xAF	2	0.10 %
0xBA	2	0.10 %
0xBB	2	0.10 %
0xC3	2	0.10 %
0xC7	2	0.10 %
0xC8	2	0.10 %
0xD5	2	0.10 %
0xD8	2	0.10 %
0xDC	2	0.10 %
0xDD	2	0.10 %
0xDE	2	0.10 %
0xE4	2	0.10 %
0xE5	2	0.10 %
0xE8	2	0.10 %
0xEA	2	0.10 %
0xEB	2	0.10 %
0xF0	2	0.10 %
0xF6	2	0.10 %
0xFB	2	0.10 %
0xFC	2	0.10 %
0xFD	2	0.10 %
0x04	1	0.05 %
0x0B	1	0.05 %
0x23	1	0.05 %
0x2C	1	0.05 %
0x2F	1	0.05 %
0x3E	1	0.05 %
0x42	1	0.05 %
0x46	1	0.05 %
0x56	1	0.05 %
0x61	1	0.05 %
0x81	1	0.05 %
0x93	1	0.05 %
0x96	1	0.05 %
0xA3	1	0.05 %
0xA7	1	0.05 %
0xAE	1	0.05 %
0xB2	1	0.05 %
0xB3	1	0.05 %
0xB5	1	0.05 %
0xC6	1	0.05 %
0xCA	1	0.05 %
0xCB	1	0.05 %
0xCE	1	0.05 %
0xD1	1	0.05 %
0xD9	1	0.05 %
0xDB	1	0.05 %
0xE2	1	0.05 %
0xE3	1	0.05 %
0xEE	1	0.05 %
0xF1	1	0.05 %
0xF5	1	0.05 %
0xF9	1	0.05 %

A large part (53%) or ATR do not have a TCK. These cards are T=0 only.

Some ATR have a TCK of 0 but this value is invalid. For example with 3B 88 80 01 00 00 00 00 77 83 95 00 00.
In most cases the TCK has a value of 0 but that is because a pattern is used in the ATR matching. For example with 3B 8C 80 01 04 43 FD 00 00 00 00 00 00 00 00 00 00. The pattern used to match the ATR is "3B 8C 80 01 04 43 FD .. .. .. .. .. .. .. .. .. .." to accept any value for the "." but my program replaced any "." by a "0".

Some ATR should have an ATR but do NOT contain it. For example with 3B 9E 96 80 1F C7 80 31 E0 73 FE 21 1B 66 D0 01 77 97 0D 00. My parsing program indicates TCK = 0x-1 in this case but that is only a way to indicate a missing TCK. Only 4 ATRs are in this category.

Since the TCK is a checksum no special value is expected. So it is not surprising that the values from 1 to 255 have a mostly equal distribution.

ATR statistics: Historical bytes - Historical bytes Ti (optional)

Article from the series "ATR statistics"

Historical bytes Ti (optional)

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

Historical Characters T_i for i≥1, if present (as defined by K coded in T0), typically hold Information about the Card Builder, Type of Card (Size etc.), Version number and the State of the Card.

You can read the previous article about the T0 byte at ATR statistics: T0 - Format byte.

Regarding the T0 high nibble values we have:

hbn	#	%
0x0F	743	35.86 %
0x0E	212	10.23 %
0x0D	150	7.24 %
0x07	136	6.56 %
0x05	128	6.18 %
0x08	116	5.60 %
0x0B	115	5.55 %
0x0A	107	5.16 %
0x09	90	4.34 %
0x06	86	4.15 %
0x0C	72	3.47 %
0x04	46	2.22 %
0x02	40	1.93 %
0x03	15	0.72 %
0x00	13	0.63 %
0x01	3	0.14 %

A large part (38%) of the ATR have 15 (0x0F) historical bytes, i.e. the maximum size.

The bytes can contain application information like for 3B 6F 00 FF 00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00

Historical bytes

00 56 72 75 54 6F 6B 6E 73 30 20 00 00 90 00

Category indicator byte: 0x00

(compact TLV data object) Tag: 5, Len: 6 (card issuer's data) Card issuer data: 72 75 54 6F 6B 6E "ruTokn" Tag: 7, Len: 3 (card capabilities) Selection methods: 48 - DF selection by file identifier - DF selection by path Data coding byte: 32 - Behaviour of write functions: proprietary - Value 'FF' for the first byte of BER-TLV tag fields: valid - Data unit in quartets: 0 Command chaining, length fields and logical channels: 0 - Logical channel number assignment: No logical channel - Maximum number of logical channels: 1 Mandatory status indicator (3 last bytes) LCS (life card cycle): 0 (No information given) SW: 90 00 ()

or contain only the card name like for 3B 6F 00 FF 52 53 41 53 65 63 75 72 49 44 28 52 29 31 30

Historical bytes	52 53 41 53 65 63 75 72 49 44 28 52 29 31 30
Category indicator byte: 0x52	(proprietary format) "SASecurID(R)10"

I do not think it is important to detail all the possible information contained in the historical bytes.

For those who are interested you can read the ISO 7816-4 (note: not the 7816-3) chapter "8.1.1 Historical bytes".

ATR statistics: TC4

Article from the series "ATR statistics".

TC4

TC4 should have the same meaning as TC3.

For T = 1: type of error detection code used

Bit 1 of the first TC for T=1 indicates the error detection code to be used:

• CRC if bit 1 is set to 1;
• LRC (default value) if bit 1 is set to 0.

Bits 8 to 2 of the first TC for T=1 are reserved for future use and shall be set to 0.

TC4	#	%
	2072	100.00 %

In my list of ATR none of them defines an TC₄.

User eXperience fixes for "Smart card ATR parsing"

Smart card ATR parsing

My web site/service "Smart card ATR parsing" is used to parse smart card ATR. You can read the previous article "Parsing an ATR: new web site URL" to get some background history.

If you have an ATR I do not already have in my database you can submit it with a description of the corresponding smart card.

Problem

I sometimes receive strange ATR to be added the list. For example I just received these 2 ATRs:

• 3B 6F 00 00 80 66 B0 07 01 01 07 07 53 02 31 24 82 90 00 3B 02 14 50
• 3B 6E 00 00 80 31 80 66 B0 84 0C 01 6E 01 83 00 90 00 3B 02 14 50

What is strange with these 2 ATRs is that:

1. I already have a shorter version in my list
•  3B 6F 00 00 80 66 B0 07 01 01 07 07 53 02 31 24 82 90 00
•  3B 6E 00 00 80 31 80 66 B0 84 0C 01 6E 01 83 00 90 00
2. they have 4 extra bytes at the end
3. these 4 extra bytes "3B 02 14 50" look like another ATR

At first I thought of a corrupted ATR or a bogus reader or driver that mixes 2 ATRs.
But then I realised that the value "3B 02 14 50" is the default value I use for the ATR input field. So if you copy & paste a new ATR value without removing the default value then the default value is appended to your ATR.

Solution

The solution is now obvious. The problem is with my web site.
The value "3B 02 14 50" is now a placeholder= and not a value=. You can copy & paste a new ATR in the input field and the "3B 02 14 50" will disappear.

Conclusion

I was aware of this problem. I used to first select the default value "3B 02 14 50" to replace it with the real ATR. I thought every body would do the same as me. I was wrong and the User eXperience was bad.

The web site should now be more useful to my users and also easier to use.
Do not hesitate to complain if you find a bug or want to suggest a UX improvement.

Parsing an ATR: old site decommisionned

I modified the web site at https://smartcard-atr.appspot.com/ to automatically redirect to https://smartcard-atr.apdu.fr/ (after 10 seconds so you have some time to read the message).

The idea is to tell people that the service has moved. You should use only the new site now. See also "Parsing an ATR: new web site URL".

I do not want to use Google App Engine (GAE) any more and do not plan to maintain the old web site (hosted at GAE). So instead of giving access to an unmaintained code I redirect to the new and maintained web site.

Please update your bookmarks.

Parsing an ATR: new web site URL

History

Since the beginning (in 2009) the Smart card ATR parsing service was hosted on Google App Engine. This is because the Google service is/was free of charge and was a new technology to discover.

You can see the GUI evolution of the ATR parsing service in time from my previous blog articles:

• Parsing an ATR (2010)
• ATR not (yet) in my database (2010)
• Parsing an ATR: now in color (2012)
• New UI design for the online ATR parser (2012)
• Parsing an ATR: now more web 2.0 friendly (2013)

Then I received an email from Google:

We’re writing to you to let you know that the legacy standalone App Engine SDK (appcfg) will be deprecated as of July 30, 2019, in favor of the Generally Available Google Cloud SDK (Cloud SDK).

You will need to migrate your projects off the legacy standalone SDK (appcfg) before the shutdown date of July 30, 2020. Projects included in this email will be whitelisted to use the legacy standalone SDK (appcfg) until July 30, 2020, but any new projects will not be able to use the legacy standalone SDK (appcfg) from July 30, 2019.

Migration

In the migration to the Google Cloud SDK I wanted to also migrate from Python 2 to Python 3, and from Bootstrap 3 to Bootstrap 4.  But then I discovered that I would have to migrate from webapp to Flask (not a bad idea) and that some Google API I used were not available for Python 3:

• user identification
• sending email

I also discovered that it is not possible to deploy an application using the new SDK without creating a billing account. I had to give my credit card number to Google. Google offers US $300 for 1 year but I do not plan to play extra money for this free service.

Note: if you want to help me see "How to help my projects? Send me bitcoins!" or contact me directly.

Problem

The problem is that I use mail service to send me an email when a new ATR is submitted, and I use the user identification service to get the user login so I can contact him/her in case the card description is incorrect.

Backup plan

I tried to use the smtplib Python module to send emails. The code works fine in local/debug mode but not when deployed in Google cloud. I have no idea why it failed.
Problem: I deployed the non-working solution over the normal service (yes, bad idea). So the service was broken and I needed a solution (very) quickly.

Self hosting

Since no Google services I used was available any more, the new solution was using only free software dependencies. And the smtplib solution was not working on Google cloud.

The solution was to host the ATR parsing service myself.

New service

The service is now available at https://smartcard-atr.apdu.fr/.

The old URL https://smartcard-atr.appspot.com/ is still available for now. I plan to change the main page with a redirection to the new URL at some point.

Contact me if you find a problem or want to discuss an evolution of the service.

Conclusion

Google forced me to migrate.
I don't think it was in their plans to force me to migrate outside of their cloud services 😉.

Surprising request from a law firm

A few weeks ago I received this email:

From: legal@axur.com
To: Ludovic.Rousseau@gmail.com
Subject: [high priority] [19444663] Content Removal - SENSITIVE DATA

Dear Sir/Madam,

Our company, AXUR, represents C.......R in issues involving the violation of intellectual property and fraud on the Internet.

C.......R is the only company authorized to use the trademark and owns or licenses numerous trademark registrations worldwide, including, but not limited to the following registration number 825503736.

The trademarks, logos, words and phrases registered by C.......R shall be exclusively used by C.......R and any other use by a third party constitutes a trademark infringement.

It has come to our attention that the reported content provides related content (see attached) to the trademark without having obtained prior written authorization from C.......R . More specifically, this content disclosures SENSITIVE DATA from our client or its customer, creating a Likelihood of Confusion between the trademark and the reported content.

Furthermore, by misusing the trademark on your website, you are also diluting its use, because it weakens the ability of brand identification as a single source of research and may lead consumers to believe that there is some association between C.......R and your website.

Official Website: https://www.c.......rsolucoes.com.br/

Considering the violation of intellectual property rights of C.......R on your website, we kindly request that you remove all content available on the attached URL(s) which use the above mentioned trademark without having obtained prior authorization.

In order to avoid a lawsuit from a federal court, please, send confirmation that this email was received along with your guarantee to comply with the requests reported above.

Under penalty of perjury, we affirm that AXUR is authorized to act on behalf of the C.......R and this notification is in accordance with International Regulations of Internet and Intellectual Property Offices.

Should you require further information or should you prefer to discuss this issue, please do not hesitate to contact us through the e-mail address listed on the signature of this message.

Sincerely,

AXUR
Legal Team
legal@axur.com

ATTACHMENT:
https://raw.githubusercontent.com/LudovicRousseau/pcsc-tools/master/smartcard_list.txt

I replaced the real trademark by "C.......R" to avoid receiving a new email asking to remove this blog article :-)

I also received the same email but with a different subject "[high priority] [19444667] Content Removal" for the same list but with a different URL: https://github.com/LudovicRousseau/pcsc-tools/blob/master/smartcard_list.txt

Actions

I updated the list of ATR to remove any mention of "C.......R".

I asked confirmation from legal@axur.com that the ATR list was OK now. I got no answer.

I also wrote them I would blog about it and got no answer as well.

ATR statistics: TA4

Article from the series "ATR statistics"

TA4

The first TA for T=15 encodes the clock stop indicator (X) and the class indicator (Y). The default values are X = "clock stop not supported" and Y = "only class A supported".

bits 8 and 7 indicate whether the card supports clock stop (≠ 00) or not (= 00) and, when supported, which state is preferred on the electrical circuit CLK when the clock is stopped.

• 00b: Clock stop not supported
• 01b: State L
• 10b: State H
• 11b: No preference

bits 6 to 1 indicate the classes of operating conditions accepted by the card. Each bit represents a class: bit 1 for class A, bit 2 for class B and bit 3 for class C.

• 00 0001b: A only
• 00 0010b: B only
• 00 0100b: C only
• 00 0011b: A and B
• 00 0110b: B and C
• 00 0111b: A, B and C
• Any other value: RFU

TA4	#	%
	2009	96.96 %
0x03	27	1.30 %
0x83	15	0.72 %
0xC3	12	0.58 %
0x07	6	0.29 %
0x43	2	0.10 %
0xC7	1	0.05 %

Clock stop	#	%
not supported	33	52.38 %
state L	2	3.17 %
state H	15	23.81 %
no preference	13	20.63 %

The class defines the current voltage the card can use:

• class A: 5 V
• class B: 3 V
• class C: 1.8 V

Some readers can't provide a tension of 5V. For example the Gemalto CT1100 reader does only provide 3 V. The default value for TA₄ is "only class A supported". Some (old) cards require a voltage of 5 V to work and will not work with a CT1100. That can be surprising.

Class	#	%
A & B	56	88.89 %
A & B & C	7	11.11 %

ATR statistics: TD3 - Structural, encodes Y4 and T

Article from the series "ATR statistics"

TD3 - Structural, encodes Y4 and T

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

Refer to TD1 - Structural, encodes Y2 and T since the definition of TD₃ is identical to TD₁.

TD3	#	%
	2009	96.96 %
0x1F	61	2.94 %
0x3F	2	0.10 %

TD₃ (as the other TD_i bytes) is structural and indicates:

• How to interpret the other ATR bytes
• What communication protocol the card wants to use

For 96.96% of the ATRs no TD₃ is present. So no other TA₄, TB₄, TC₄ or TD₄ is present and no new protocol is defined so the protocol(s) defined by TD₁ and TD₂ will be used.

For 2.94% of the ATRs TD₃ = 0x1F. The high nibble is 0001b so TA₄ is present and T=15 protocol is defined. One such ATR is 3B 94 18 81 B1 80 7D 1F 03 19 C8 00 50 DC.

For 0.10% of the ATRs TD₃ = 0x3F. The high nibble is 0001b so TA₄ and TB₄ are present and T=15 protocol is defined. One such ATR is 3B DE 18 FF 81 F1 FE 43 00 3F 07 83 44 45 53 46 69 72 65 38 20 53 41 4D 2D 58 17.

ATR statistics: TC3

Article from the series "ATR statistics".

TC3

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

For T = 1: type of error detection code used

Bit 1 of the first TC for T=1 indicates the error detection code to be used:

• CRC if bit 1 is set to 1;
• LRC (default value) if bit 1 is set to 0.

Bits 8 to 2 of the first TC for T=1 are reserved for future use and shall be set to 0.

TC3	#	%
	2017	97.35 %
0x00	55	2.65 %

In my list of ATR the only redundancy code used if LRC. I found no card using CRC.

LRC is the default algorithm. But 55 cards explicitly set it. I have no explanation for that.

ATR statistics: TB3 - Global after T=15 in TDi–1

Article from the series "ATR statistics".

TB3 - Global after T=15 in TD_i–1

For T=1 protocol the first TB_i encodes Block Waiting Integer and Character Waiting Integer. The high nibble encodes BWI. The low nibble encodes CWI.

For T=15 protocol TB_i the coding is defined in the document ETSI TS 102 221 V10.0.0 (2011-12) chapter "6.3.3 Global Interface byte"

TB3	#	%
	1565	75.53 %
0x45	288	13.90 %
0x55	38	1.83 %
0x47	23	1.11 %
0x5D	21	1.01 %
0x43	18	0.87 %
0x40	17	0.82 %
0x75	14	0.68 %
0x65	11	0.53 %
0x42	9	0.43 %
0x58	9	0.43 %
0x7D	8	0.39 %
0x4D	7	0.34 %
0x9F	7	0.34 %
0xA0	5	0.24 %
0x35	4	0.19 %
0x15	3	0.14 %
0x34	3	0.14 %
0x57	3	0.14 %
0x37	2	0.10 %
0x44	2	0.10 %
0x49	2	0.10 %
0x52	2	0.10 %
0x67	2	0.10 %
0x24	1	0.05 %
0x41	1	0.05 %
0x53	1	0.05 %
0x59	1	0.05 %
0x63	1	0.05 %
0x69	1	0.05 %
0x6D	1	0.05 %
0x73	1	0.05 %
0x9E	1	0.05 %

T=1 protocol

The list above is not really informative since both BWI and CWI are coded in the same byte.

BWI

BWI	#	%
4	349	73,01 %
5	73	15,27 %
7	22	4,60 %
6	16	3,35 %
3	9	1,88 %
9	6	1,26 %
1	2	0,42 %
2	1	0,21 %

CWI

CWI	#	%
5	343	72 %
13	36	8 %
7	30	6 %
3	18	4 %
0	15	3 %
2	10	2 %
8	9	2 %
4	6	1 %
15	5	1 %
9	4	1 %
1	1	0 %
14	1	0 %

T=15 protocol

I my list I have only 5 cards with a TB₃ for T=15. They all have the value TB₃ = 0xA0 for "UICC-CLF interface supported as defined in TS 102 613".

ATR statistics: TA3 - Specific to T after T from 0 to 14 in TDi–1

Article from the series "ATR statistics".

TA3 - Specific to T after T from 0 to 14 in TDi–1

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

For T = 1: maximum block size the card can receive. Encodes IFSC.
If T = 15: supported supply voltages and low power modes

TA3	#	%
	1379	66.55 %
0xFE	388	18.73 %
0xC7	109	5.26 %
0xC3	35	1.69 %
0x80	24	1.16 %
0x20	19	0.92 %
0x43	14	0.68 %
0x3C	9	0.43 %
0x47	8	0.39 %
0x86	7	0.34 %
0xA0	7	0.34 %
0x00	6	0.29 %
0x03	6	0.29 %
0x50	6	0.29 %
0x42	5	0.24 %
0xC6	5	0.24 %
0x40	4	0.19 %
0x60	4	0.19 %
0x70	4	0.19 %
0x66	3	0.14 %
0x90	3	0.14 %
0xFC	3	0.14 %
0xFF	3	0.14 %
0x46	2	0.10 %
0x76	2	0.10 %
0xF0	2	0.10 %
0xFA	2	0.10 %
0xFB	2	0.10 %
0x07	1	0.05 %
0x26	1	0.05 %
0x3A	1	0.05 %
0x3D	1	0.05 %
0x52	1	0.05 %
0x64	1	0.05 %
0x7C	1	0.05 %
0x83	1	0.05 %
0x87	1	0.05 %
0xC2	1	0.05 %
0xEF	1	0.05 %

The interpretation of TA₃ depends on the protocol in use.

19% of ATRs have TA₃ = 0xFE :

• In most case the interpretation is that TA₃ gives the value of IFSC (maximum size of information field of blocks that can be received by the card) for T=1. One example is 3B 97 11 C0 FF B1 FE 35 1F 83 A5 05 01 01 02 A3 01 5F with IFSC = 0xFE or 254 bytes.
• For 2 ATRs AT₃ gives the supported supply voltages and low power modes for T=0. One example is 3B D9 18 00 C0 09 10 FE 54 59 46 4F 4E 45 00 00 00

IFSC

The IFSC repartition is as follows:

IFSC	#	%
254	366	75,78 %
128	21	4,35 %
32	19	3,93 %
60	9	1,86 %
134	7	1,45 %
160	7	1,45 %
80	6	1,24 %
0	5	1,04 %
64	4	0,83 %
96	4	0,83 %
112	4	0,83 %
66	3	0,62 %
102	3	0,62 %
144	3	0,62 %
252	3	0,62 %
255	3	0,62 %
70	2	0,41 %
118	2	0,41 %
240	2	0,41 %
250	2	0,41 %
251	2	0,41 %
38	1	0,21 %
58	1	0,21 %
82	1	0,21 %
100	1	0,21 %
124	1	0,21 %
239	1	0,21 %

With a logarithmic scale:


75% of ATRs with a IFSC defined in TA₃ (so T=1 cards only) defines IFSC = 254.

Supported supply voltages

It is also possible to get the repartition of the class:

Class	#	%
A 5V B 3V C 1.8V	114	49,57 %
A 5V B 3V	106	46,09 %
B 3V C 1.8V	5	2,17 %
B 3V	3	1,30 %
B 3V C 1.8V D RFU E RFU	2	0,87 %

50% of ATRs defining the class supports the 3 classes: A, B and C for 5 Volts, 3 Volts and 1.8 Volt.

46% of ATRs defining the class supports the classes A and B but not C.

2 cards declare the support of classes D and E that are RFU. They are 3B D9 18 00 C0 09 10 FE 54 59 46 4F 4E 45 00 00 00 and 3B DD 96 00 80 10 FE 80 31 80 63 01 FF C0 73 B3 21 1B 81 05. It may be a bug in the parsing since the class is defined only after T=15 protocol. But in the two examples the latest defined protocol is T=0. The ATRs may not be valid.

ATR statistics: TD2 - Structural, encodes Y3 and T

Article from the series "ATR statistics"

TD2 - Structural, encodes Y3 and T

The ISO 7816-3 specification is not public. So I can't copy/paste part of the text. I will use Wikipedia instead.

Refer to TD1 - Structural, encodes Y2 and T since the definition of TD₂ is identical to TD₁.

TD2	#	%
	1123	54.20 %
0x31	393	18.97 %
0x01	250	12.07 %
0x1F	178	8.59 %
0x71	50	2.41 %
0xB1	48	2.32 %
0x91	10	0.48 %
0x21	6	0.29 %
0x3F	5	0.24 %
0xF1	5	0.24 %
0x10	2	0.10 %
0x11	2	0.10 %

TD₂ (as the other TD_i bytes) is structural and indicates:

• How to interpret the other ATR bytes
• What communication protocol the card wants to use

For 54% of the ATRs no TD₂ is present. So no other TA₃, TB₃, TC₃ or TD₃ is present and no new protocol is defined so the protocol defined by TD₁ (if any) will be used.

For 19% of the ATRs TD₂ = 0x31. The high nibble is 0011b so TA₃, TB₃ are present and T=1 protocol is defined. One such ATR is 3B 82 81 31 76 43 C0 02 C5.

For 12% of ATRs TD₂ = 0x01. The high nibble is 0000b so no other TA₃, TB₃, TC3 or TD₃ is present and T=1 protocol is defined. One such ATR is 3B 84 80 01 00 00 90 00 95.

0.10% of cards have TD₂ = 0x10 and so (re)define the use of T=0. In fact what is important here is the high nibble of TD₂ 0001b that defines that TA₃ is present. One such ATR is 3B DD 96 00 80 10 FE 80 31 80 63 01 FF C0 73 B3 21 1B 81 05.

I will not document all the other cases. I let this exercise to the reader.

ATR statistics: TC2 - Specific to T=0

Article from the series "ATR statistics"

TC2 - Specific to T=0

If present in the Answer-to-Reset, the interface byte TC₂ encodes the waiting time integer WI over the eight bits, except the value '00' reserved for future use. If TC₂ is absent, then the default value is WI = 10.

TC2	#	%
	1889	91.17 %
0x0A	47	2.27 %
0xFF	20	0.97 %
0x10	19	0.92 %
0x14	18	0.87 %
0x0F	14	0.68 %
0x96	11	0.53 %
0x20	10	0.48 %
0x80	9	0.43 %
0x60	5	0.24 %
0x18	4	0.19 %
0x1E	4	0.19 %
0x2A	3	0.14 %
0x78	3	0.14 %
0x00	2	0.10 %
0x23	2	0.10 %
0x32	2	0.10 %
0x3E	2	0.10 %
0xF0	2	0.10 %
0x09	1	0.05 %
0x1C	1	0.05 %
0x28	1	0.05 %
0x64	1	0.05 %
0xFA	1	0.05 %
0xFE	1	0.05 %

TC₂ is only for T=0 cards.
It is surprising that 47 cards declare TC₂=0x0A knowing that this is the default value.
It is also surprising that 2 cards (3B 95 15 40 00 68 01 02 00 00 and 3B A7 00 40 00 80 65 A2 08 00 00 00) are using the reserved value 0.

ATR statistics: TB2 - Global, deprecated

Article from the series "ATR statistics"

TB2 - 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_TB2

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.

In the 1997 edition of the standard, TB₂ (8th to 1st bit) encode PI2, which when in range 50..250 (other values being RFU) encode V_PP in increments of 0.1 V, and subsumes the coarser indication given by PI1 of TB₁. Refer to that section for why modern Smart Cards have no use of V_PP, and thus of TB₂.

Historical note: Provision for TB₂ did not exist in ISO/IEC 7816-3:1989, and was introduced because V_PP = 12.5 V became a popular value in EEPROM technology, replacing 25 V and 21 V.

TB2	#	%
	2070	99.90 %
0x3F	1	0.05 %
0x45	1	0.05 %

Only 2 cards use a TB₂ value.

• 3B FF 00 FF 81 31 00 45 65 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
• TB₂= 0x45 Programming param PI2 (PI1 should be ignored): 69 (dV)
• This card also has TB₁ = 0xFF Programming Param P: 31 Volts, I: RFU 
• 3F FF 3F 3F 3F 3F 00 3F 3F FF 3F 3F 3F 3F 3F FF 3F FF 95 3F FF 95 3F FF
• TB₂ = 0x3F Programming param PI2 (PI1 should be ignored): 63 (dV)
• This card also has TB₁ = 0x3F Programming Param P: 31 Volts, I: 50 milliAmperes  

I agree these 2 ATRs are quiet unusual.

ATR statistics: TA2 - Global, specific mode byte

Article from the series "ATR statistics"

TA2 - Global, specific mode 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#Interface_byte_TA2

Interface byte TA₂, if present, is global, and is named the specific mode byte.

Presence of TA₂ commands that the reader use specific mode as defined by TA₂ and earlier global bytes, rather than negotiable mode when TA₂ is absent.

TA₂ encodes in its 4 low-order bits an integer T defining the protocol required by the card, in the convention used for TD₁ (EMV prescribes that a card which T encoded in TA₂ does not match that in TD₁ shall be rejected).

The 5th bit is 0 to encodes that the required ETU duration is F_i/D_i clock cycles as defined by TA₁ (or its default value if absent); or 1 to indicate that the ETU duration is implicitly known (by some convention, or setting of the reader; EMV prescribes that such card shall be rejected).

The 6th and 7th bit are reserved for future use; 0 indicates not used.

The 8th bit is 1 to indicate that the card is unable to change the negotiable/specific mode (that is, does not propose other settings); or 0 to indicate that card has that ability (perhaps after a warm ATR).

Historical note: Provision for specific mode did not exist in ISO/IEC 7816-3:1989. Back then, the interface character TA₂ had no particular name or function, and was specific (to the protocol introduced by TD₁). ISO/IEC 7816-3:1997 introduced the specific mode and the specific mode byte, with interim note helping cards with specific mode byte TA₂ in their ATR dealing with a reader that did not implement specific mode.

TA2	#	%
	1983	95.70 %
0x81	48	2.32 %
0x80	31	1.50 %
0x00	10	0.48 %

TA₂ is used by only 4.30% of cards. 95.70% of smart cards in my list have no TA₂ defined.

• 0x81 indicates "Protocol to be used in spec mode: T=1 - Unable to change - defined by interface bytes".
• The 4 low-order bits are set to 0001b so T=1 protocol.
• The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
• 0x80 indicates "Protocol to be used in spec mode: T=0 - Unable to change - defined by interface bytes"
• The 4 low-order bits are set to 0000b so T=0 protocol.
• The 8th bit set to 1 to indicate unable to change the negotiable/specific mode
• 0x00 indicates "Protocol to be used in spec mode: T=0 - Capable to change - defined by interface bytes"
• The 4 low-order bits are set to 0000b so T=0 protocol.
• The 8th bit set to 0 to indicate the card is able to change the negotiable/specific mode

ATR statistics: TD1 - Structural, encodes Y2 and T

Article from the series "ATR statistics"

TD1 - Structural, encodes Y2 and T

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

Interfaces bytes TD_i for i≥1, if present, are structural.
TD_i encodes in its 4 high-order bits the presence of at most 4 other interface bytes: TA_i+1 (resp. TB_i+1, TC_i+1, TD_i+1) follow, in that order, if the 5th (resp. 6th, 7th, 8th) bit of TD_i is 1.
TD_i encodes in its 4 low-order bits (4th MSbit to 1st LSbit) an integer T, in range [0..15]. T = 15 is invalid in TD₁, and in other TD_i qualifies the following TA_i+1 TB_i+1, TC_i+1, TD_i+1 (if present) as global interface bytes. Other values of T indicates a protocol that the card is willing to use, and that TA_i+1 TB_i+1, TC_i+1, TD_i+1 (if present) are specific interface bytes applying only to that protocol. T = 0 is a character-oriented protocol. T = 1 is a block-oriented protocol. T in the range [3..14] is RFU.
Historical note: provision for dynamically qualifying interface bytes as global using T = 15 did not exist in ISO/IEC 7816-3:1989.

TD1	#	%
	899	43.39 %
0x80	459	22.15 %
0x81	372	17.95 %
0x40	95	4.58 %
0x00	69	3.33 %
0x91	46	2.22 %
0xC0	45	2.17 %
0xC1	27	1.30 %
0x10	22	1.06 %
0x50	16	0.77 %
0x01	9	0.43 %
0x0E	8	0.39 %
0x11	2	0.10 %
0x1F	1	0.05 %
0x31	1	0.05 %
0x3F	1	0.05 %

TD1 (as the other TDi bytes) is structural and indicates:

• How to interpret the other ATR bytes
• What communication protocol the card wants to use

For 43% of the ATRs no TD₁ is present. So no other TA₂, TB₂, TC₂ or TD₂ is present and no protocol is defined so the default T=0 will be used.

For 22% of ATRs TD₁ = 0x80 so bit 8 is set to indicate that a TD₂ is present and T=0 is used. One such ATR is 3B 80 80 01 01.

For 17% of ATRs TD₁ = 0x81 so, as in the previous case, TD₂ is present but T=1 is used. One such ATR is 3B 82 81 31 76 43 C0 02 C5

For 5% of ATRs TD₁ = 0x40 so TC₂ is present and T=0 is used. One such ATR is 3B 85 40 20 68 01 01 00 00

I will not document all the other cases. I let this exercise to the reader.

One special case is TD₁ = 0x?E to indicate the T=14 protocol.

From ISO 7816-3:

The type T refers to a transmission protocol and/or qualifies interface bytes.

• T=0 refers to the half-duplex transmission of characters specified in clause 10.
• T=1 refers to the half-duplex transmission of blocks specified in clause 11.
• T=2 and T=3 are reserved for future full-duplex operations.
• T=4 is reserved for an enhanced half-duplex transmission of characters.
• T=5 to T=13 are reserved for future use by ISO/IEC JTC 1/SC 17.
• T=14 refers to transmission protocols not standardized by ISO/IEC JTC 1/SC 17.
• T=15 does not refer to a transmission protocol, but only qualifies global interface bytes.

As you can see in the list above "T=14 refers to transmission protocols not standardized by ISO/IEC JTC 1/SC 17." In my list T=14 is used only by pay TV cards like 3B 9F 21 0E 49 52 44 45 54 4F 20 41 43 53 03 83 95 00 80 55.

TD₁ = 0x?F is also another special case to indicate T=15, which is not a protocol, and will change the interpretation of the following ATR bytes.

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

TC₁, 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
where:

• 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 TA₁, R = F_i/D_i (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 TA₁, 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 TC₁ defines a time value between characters transmitted between 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).

TC1	#	%
	910	43.92 %
0x00	792	38.22 %
0xFF	287	13.85 %
0x02	29	1.40 %
0x03	18	0.87 %
0x01	15	0.72 %
0x08	6	0.29 %
0x05	4	0.19 %
0x04	3	0.14 %
0x0B	2	0.10 %
0x09	1	0.05 %
0x10	1	0.05 %
0x3F	1	0.05 %
0x64	1	0.05 %
0x81	1	0.05 %
0xFE	1	0.05 %

The default value is 0. But 38.22% of cards explicitly define TC₁=0.
A total of 82.14% of cards use the default value.
TC₁=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).