4

I am using winscard.dll within my Dotnet smart card application. My reader, an Omnikey 5321 has both a contact and a contactless interface, which are detected as two different readers. The contactless has the letters "CL" within it's name. I have no problems manually selecting the readers and doing everything I need to with them.

Is there a reliable way however, using SCardGetAttrib or another call, to determine which of these readers supports ISO14443 - i.e. EMV contactless? I would ultimately like a quick "Select Contactless settings" button, which would be generic enough to work with all PC/SC readers, and therefore also allow me to disable contactless options if such an interface is not present.

John W
  • 73
  • 4
  • Those are detected as two different readers/interfaces because technically underneath those are two different pieces of hardware. When the card is inserted you will get the ATR which is going to be quite different if contact or -less. – Alex D Sep 10 '15 at 16:58
  • Thanks. The problem is though, without continual scanning of both readers for a card, the user needs to select one or the other and then connect to the card in that specific reader. It would be really great to know what each reader can do before connecting to the card. – John W Sep 10 '15 at 17:20
  • In this case I believe there is no other way but to go down to the device itself. All readers are usb interface based so look into usb descriptor of the actual device/reader may be parsing it you would be able to find a distinctive feature. – Alex D Sep 10 '15 at 17:52
  • What do you get when you look at `SCARD_ATTR_CURRENT_PROTOCOL_TYPE` and especially ` `SCARD_ATTR_CHARACTERISTICS`? – Maarten Bodewes Sep 14 '15 at 12:37
  • SCARD_ATTR_CHARACTERISTICS deals with card capture, swallowing and ejection. SCARD_ATTR_CURRENT_PROTOCOL_TYPE deals with T=0, T=1 etc. – John W Sep 26 '15 at 00:10

2 Answers2

2

No, there is no such method simply for the reason, that PCSC is older than contactless technology (ancient contactless chips were older but required special readers and drivers, so there was no overlap). Therefore only the naming convention for the reader name provides this information ina manufacturer dependent way. In practice, this does not matter. You don't label your readers, so that the user is able to select the correct one but typically simply demand, that the user plugs in/lays on the card to the reader. PCSC will then allow to detect, which reader is loaded, as long as it is only one.

guidot
  • 5,095
  • 2
  • 25
  • 37
  • OK. Thank you for confirming. – John W Sep 10 '15 at 21:59
  • What about table 3.1 in "Interoperability Specification for ICCs and Personal Computer Systems Part 3. Requirements for PC-Connected Interface Devices"? It seems to be retrieved through `IFD_Get_Capabilities` – Maarten Bodewes Sep 14 '15 at 12:28
0

You can use Advanced Query Syntax to search for devices exposing smartcard interface class and having NFC enabled.

string query = "System.Devices.InterfaceClassGuid:=\"{DEEBE6AD-9E01-47E2-A3B2-A66AA2C036C9}\"";
if (readerKind != SmartCardReaderKind.Any)
{
   query += " AND System.Devices.SmartCards.ReaderKind:=" + (int)readerKind;
}

DeviceInformationCollection devices = await DeviceInformation.FindAllAsync(query);

where readerKind is of Windows Runtime type Windows.Devices.SmartCards.SmartCardReaderKind. Code snippet comes from official Microsoft NFC UWP example (PscsUtils.cs).

grzegorz
  • 331
  • 3
  • 16