Should the ATS and ATR be the same from the same card on a contactless and contact reader? Does a JavaCard application on a dual interface card responding with a different ATS and ATR impact the execution of that applet?
There is another question along these lines here: Difference between contact card and contactless(RF) card which seems to indicate they can be the same if they use the same transport protocol.
For a specific example, I have a JavaCard J3H145 that provides a different ATR (displayed via pcsc_scan) over a contactless reader and a contact reader. Does this mean the reader is doing something on its own (the Identiv 3700f)? I have several javacard applets that work over contact but not contactless. When I trace the ADPU's through pcscd everything is Attempting PTS to T=1 (does that require a reader translation from T=CL?).
Edit: additional research
There are some relevant questions that begin to tell the story:
details the procedure of converting between ATR and ATQ-A and ATQ-B, while
show that Historical Bytes can be changed from the GP API (and therefore the ATS/ATR is edit-able), so I assume there is a way to fix them the same manually.
I have tested the J3H145 on a PN532 shield as well (testing my specific reader translation), and I get a seemingly truncated ATR: 3B 80 80 01 01 (ISO 14443 Type B without historical bytes) and over contact (when everything works great!) ATR: 3B DC 18 FF 81 91 FE 1F C3 80 73 C8 21 13 66 05 03 63 51 00 02 50 (JCOP3 SecID P60 CS (JavaCard))
For completeness, I am trying to run https://github.com/ANSSI-FR/SmartPGP over contactless interface, and this currently works over the contact interface on the dual-interface card. Is the difference in ATR/ATS the culprit?
Relevant SO Question: ATR command when programming PC/SC reader
This is a complicated issue.
Superficially simple answer: They can't be the same, since their formats are entirely different. ATR starts with 3B/3F, followed by T0, TAx/TBx/TCx/TDx (for x in [1..4]), up to 15 historical bytes and a single byte checksum. Depending on whether your card talks type A or type B of ISO 14443 you will get an ATS or an ATQB, which have distinct formats but both end with a two-byte checksum.
Now things become complicated, since PCSC urgently needs an ATR and therefore a synthetic one is created for contactless readers (typically by reader or driver). This synthetic ATR is typically very short (just complying to the format) and will not have striking similarity to ATR/ATS/ATQB. Since transmission rate negotiation occurs between reader and card, the synthetic ATR irrelevant for the application. While the reader will use the original ATS/ATQB for collision resolution etc, you will not see it on the host. The friendly reader name is sufficient to channel the information to the correct reader interface.