macOS Sonoma bug: The reader name should include the CCID interface name
This is part of the series: macOS Sonoma and smart cards: known bugs.
If you have a composite smart card reader (one USB device with 2 or more CCID interfaces) it is impossible to identify which interface is which since the reader names are the same (except for a number).
See also
I reported this problem to Apple as FB13259373 "The smart card reader name should include the CCID interface name".
Example
For example with a composite device Gemalto Prox DU with 2 CCID interfaces:
% ./pcsc_scan PC/SC device scanner V 1.7.0 (c) 2001-2022, Ludovic Rousseau <ludovic.rousseau@free.fr> Plug'n play reader name not supported. Using polling every 3600000 ms. Scanning present readers... Waiting for the first reader... found one Scanning present readers... 0: Gemalto Prox Dual USB PC Link Reader 1: Gemalto Prox Dual USB PC Link Reader 01
The problem is that I do not know what interface is the contact reader, and what interface is the contactless reader.
The situation is even worse since the order in which the interfaces are detected/listed is not stable.
To test that I insert a card in the contact reader. I get:
Scanning present readers... 0: Gemalto Prox Dual USB PC Link Reader 1: Gemalto Prox Dual USB PC Link Reader 01 Wed Oct 11 14:02:08 2023 Reader 0: Gemalto Prox Dual USB PC Link Reader Event number: 0 Card state: Card removed, Reader 1: Gemalto Prox Dual USB PC Link Reader 01 Event number: 0 Card state: Card inserted, ATR: 3B 6F 00 00 80 5A 28 13 02 10 12 2B 75 0D D3 82 82 90 00
The first reader (Reader 0) is the contactless interface, the second reader (Reader 1) is the contact interface since that is where the contact card is reported as inserted.
Then I disconnect the USB device and connect it again. This time I get:
Waiting for the first reader... found one Scanning present readers... 0: Gemalto Prox Dual USB PC Link Reader 1: Gemalto Prox Dual USB PC Link Reader 01 Wed Oct 11 14:02:20 2023 Reader 0: Gemalto Prox Dual USB PC Link Reader Event number: 0 Card state: Card inserted, ATR: 3B 6F 00 00 80 5A 28 13 02 10 12 2B 75 0D D3 82 82 90 00 Reader 1: Gemalto Prox Dual USB PC Link Reader 01 Event number: 0 Card state: Card removed,
Note that the 2 reader names are the same as before
Gemalto Prox Dual USB PC Link Reader
and
Gemalto Prox Dual USB PC Link Reader 01
but this second time the
contact card is reported in the first reader instead of the second reader.
The contact reader was named Gemalto Prox Dual USB PC Link Reader 01
but is now named Gemalto Prox Dual USB PC Link Reader
.
It looks like the ordering between the 2 interfaces is random.
pcsc-lite
On a GNU/Linux system I get:
$ pcsc_scan PC/SC device scanner V 1.6.2 (c) 2001-2022, Ludovic Rousseau <ludovic.rousseau@free.fr> Using reader plug'n play mechanism Scanning present readers... 0: Gemalto Prox Dual USB PC Link Reader [Prox-DU Contactless_10500231] 00 00 1: Gemalto Prox Dual USB PC Link Reader [Prox-DU Contact_10500231] 01 00 Wed Oct 4 10:08:20 2023 Reader 0: Gemalto Prox Dual USB PC Link Reader [Prox-DU Contactless_10500231] 00 00 Event number: 0 Card state: Card removed, Reader 1: Gemalto Prox Dual USB PC Link Reader [Prox-DU Contact_10500231] 01 00 Event number: 0 Card state: Card removed,
The CCID interface name (here Prox-DU Contactless_10500231
and
Prox-DU Contact_10500231
) is included in the reader names.
See What is in a PC/SC reader name? for more details about the reader name construction in pcsc-lite.
Windows
On a Windows system I get:
PS C:\Users\Ludovic\Downloads> .\pcsc_scan.exe PC/SC device scanner V 1.7.0 (c) 2001-2022, Ludovic Rousseau <ludovic.rousseau@free.fr> Press shift key to quit Using reader plug'n play mechanism Scanning present readers... 0: Gemalto Prox-DU Contact_10500231 0 1: Gemalto Prox-DU Contactless_10500231 0 Sun Oct 15 09:35:48 2023 Reader 0: Gemalto Prox-DU Contact_10500231 0 Event number: 0 Card state: Card removed, Reader 1: Gemalto Prox-DU Contactless_10500231 0 Event number: 0 Card state: Card removed, Reader 2: \\?PnP?\Notification Event number: 2 Card state:
This is similar to what I have on GNU/Linux.
Workaround
None known.