Ludovic Rousseau's blog (Posts about ATR)

ATR parsing in JSON

Ludovic Rousseau — Fri, 20 May 2022 19:55:00 GMT

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)

Ludovic Rousseau — Sun, 22 Mar 2020 15:42:00 GMT

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)

Ludovic Rousseau — Sun, 22 Mar 2020 15:02:00 GMT

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)

Ludovic Rousseau — Sun, 22 Mar 2020 14:12:00 GMT

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 ()

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

Ludovic Rousseau — Sat, 21 Mar 2020 21:23:00 GMT

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"

Ludovic Rousseau — Sun, 02 Feb 2020 17:33:00 GMT

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:

What is strange with these 2 ATRs is that:

I already have a shorter version in my list

they have 4 extra bytes at the end

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

Ludovic Rousseau — Wed, 09 Oct 2019 17:11:00 GMT

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

Ludovic Rousseau — Thu, 05 Sep 2019 23:11:00 GMT

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

Ludovic Rousseau — Thu, 30 May 2019 21:46:00 GMT

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

Ludovic Rousseau — Sun, 17 Mar 2019 18:49:00 GMT

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 %