Issue with differentiating B & B' cards in the Java PCSC plugin libraries

[ThomasParenteau]

Description

We’re facing an issue when trying to distinguish between type B and type B prime transport cards in the PCSC plugin java lib (using the 2.5.2 version).

Until now, we filtered cards using their AID, so we didn’t need to explicitly distinguish between B and B prime. However, we now have type B and type B prime cards sharing the same AID, which forces us to distinguish them by protocol, using their ATR.

When implementing protocol-based differentiation, we noticed that, in the PCSC plugin, some B prime cards are matched with protocol ISO_14443_4 instead of INNOVATRON_B_PRIME, based on their ATR.

---

ATR examples

Type B cards:

• 3B 88 80 01 00 00 00 00 91 71 71 00 98

Type B prime cards:

• 3B 8F 80 01 80 5A 08 06 08 20 02 00 10 49 67 55 82 90 00 89
• 3B 8F 80 01 80 5A 08 06 08 20 02 00 10 49 67 59 82 90 00 85

---

Current regex in the PCSC library

In PcscCardCommunicationProtocol.java

  ISO_14443_4("3B8[0-9A-F]8001(?!.*5A0A)(?!804F0CA000000306).*"),
  INNOVATRON_B_PRIME("3B8.8001(80)?5A0A.*"),

---

Observed behavior

• The ATRs of our B prime cards (see above) match the ISO_14443_4 regex.
• They do not match the INNOVATRON_B_PRIME regex.

The main reason: in our ATRs, we have 5A 08 at the relevant bytes, while the INNOVATRON_B_PRIME regex explicitly expects 5A0A.

Example for one B prime card:

3B 8F 80 01 80 5A 08 06 08 20 02 00 10 49 67 59 82 90 00 85

→ as a continuous string:
3B8F8001805A0806082002001049675982900085

• This string matches the ISO_14443_4 regex.
• It does not match the INNOVATRON_B_PRIME regex because of 5A08 instead of 5A0A.

We confirmed this behavior using regex testing tools (e.g. regex101).

---

Expected behavior

• These B prime cards should not be classified as ISO_14443_4 based on their ATR.
• Ideally, they should be recognized as INNOVATRON_B_PRIME, or at least not falsely categorized as ISO_14443_4.

---

Questions / possible directions

• Is the INNOVATRON_B_PRIME regex (...5A0A.*) too strict or outdated for some B prime cards that now use 5A 08 in their ATR?
• Should we:
  • relax the INNOVATRON_B_PRIME regex, or
  • adjust the ISO_14443_4 regex to exclude those cases, or
  • introduce a specific rule for B prime cards with 5A 08?

Any clarification on the intended protocol detection logic and the proper way to distinguish these cards in the library would be very helpful.

Thanks in advance!

[pterr]

For ISO B or B' type protocols, the ATR value returned by a PC/SC reader is a simulated value generated by the reader: this value may vary depending on the reader or card product. In Keyple's PC/SC plugin, the PcscCardCommunicationProtocol enumeration provides "examples" of regular expressions to try to identify a specific communication protocol based on ATR data. We defined the INNOVATRON_B_PRIME value based on the test cards and readers we had on hand.

• You can set your own value to identify a reader communication protocol: here is an example UseCase3_ChangeProtocolRules that illustrates this implementation.

• Otherwise, feel free to contribute by suggesting new values for ISO_14443_4 or INNOVATRON_B_PRIME?

Regarding how to manage B' cards:

• for Calypso REV1 cards that did not support AID selection, it was necessary to adapt a specific DF file selection mode → in this case, it is useful to distinguish between B' and ISO card processing. In addition, for these B' cards, it was also necessary to retrieve the card serial number at the ATR level.

• For your B' cards that support AID selection: do you really need to distinguish between processing for B' cards and ISO cards?

[ThomasParenteau]

Thank you for the quick reply! It’s true that adapting the regex for the B′ cards we have could be a solution.

I’ve only just learned that the ATR values are simulated / generated by the reader, which makes our card differentiation mechanism based on ATR regex matching a bit fragile.

• For your B' cards that support AID selection: do you really need to distinguish between processing for B' cards and ISO cards?

In our case, the problem is that we need to decode two types of cards that share the same AID: one is a type B card and the other is an Innovatron B′ card. Initially, I wanted to distinguish them based on which files we are able to read on each card, since there are some differences in how they are instantiated. However, this becomes problematic when we pass the cardSelectionManager to the cardSelectionScenario (the issue is that the files selected in the cardSelectionManager for a card that has a given AID are also selected for a card that does not have them, which causes an error).

The goal of differentiating ISO and B′ cards was precisely to rely on filterByCardProtocol when creating the IsoCardSelector.