• Raim
  • New member
  • Offline
  • Registered: 2010-12-13
  • Posts: 2

Topic: Supporting readers over PC/SC

Hello,

recently I obtained a "Reiner SCT cyberjack RFID basis" card reader. Actually, a batch of these was given away for free by the German government to increase the acceptance of the new chip-based ID card among the people.

There are more information, some tear down pictures and internals on this wiki page.

The reader is using a PN512 chip, which is currently unsupported by libnfc. But I am able to communicate with the reader and a Mifare DESfire card using PC/SC. I have a proof of concept using SCardConnect, SCardTransmit, etc.

Are there any plans to support more readers like this one in libnfc using the PC/SC interface?

I have read the roadmap and I have seen that some internal changes are already planned. But it doesn't look like this will add support for more readers...

  • rconty
  • Administrator
  • Offline
  • Registered: 2009-04-22
  • Posts: 673

Re: Supporting readers over PC/SC

Hello,

Raim wrote:

Are there any plans to support more readers like this one in libnfc using the PC/SC interface?

Current contributors have ACR122 device or PN531, PN532 or PN533 equipped devices, so libnfc covers theses devices. If new contributor have different device, a new device will be supported...

Raim wrote:

I have read the roadmap and I have seen that some internal changes are already planned. But it doesn't look like this will add support for more readers...

As you can understand, no body will buy a reader and support it without using it... BTW, we already have provided a support for offered devices, so maybe if we have the new device and some spare time...

Romuald Conty
  • Raim
  • New member
  • Offline
  • Registered: 2010-12-13
  • Posts: 2

Re: Supporting readers over PC/SC

Maybe my explanation wasn't clear, of course I won't ask you to implement this, I am trying to verify if my ideas make any sense :-)

As I understand it, PC/SC is an abstraction layer for generic CCID devices. SCardTransmit() sends APDUs directly to the card and receives from it. So it should be possible to write a more generic driver based on PC/SC that handles any device which already has a working CCID driver. You won't be able to emulate anything with such a setup as this will probably only work if a card is inserted in the reader, but it would be possible to examine chipcards.

So my question is, are there any known obstacles preventing such a generic driver?

  • Registered: 2010-12-17
  • Posts: 57

Re: Supporting readers over PC/SC

Hi,

I've got a somewhat related question.
I want to port our application which uses libnfc to a mobile terminal we bought. This terminal runs embedded linux and uses the NXP RC531 chip for the contactless communication. Accessing the RC531 chip directly is not possible according to the manufacturer, but there is both a native SDK and PC/SC support.

If i understand the explanation in the roadmap correctly it should be possible using the libnfc 1.6 architecture to build a generic PC/SC driver which would allow to use libnfc with this and all other readers which are supported by PC/SC / CCID.

What is your opinion on this? Would it make sense to implement this in current libnfc trunk? If yes, what would be the best way to do this? Any advice or comments welcome.

  • rconty
  • Administrator
  • Offline
  • Registered: 2009-04-22
  • Posts: 673

Re: Supporting readers over PC/SC

glenn wrote:

If i understand the explanation in the roadmap correctly it should be possible using the libnfc 1.6 architecture to build a generic PC/SC driver which would allow to use libnfc with this and all other readers which are supported by PC/SC / CCID.

What is your opinion on this?

IMHO, this is not possible to drive generic CCID device using libnfc: almost all libnfc features are not implemented by CCID.
BTW, its possible to write a minimal driver that can use CCID device as a NFC initiator, but that's not a targetted feature since interesting part of NFC is emulation and P2P.

From my point of view, we should not implement driver that use PS/SC, it not the right order of things (even ACR122 should be drop): libnfc can be an ifdhandler of PC/SC (behind PC/SC, as driver backend) and should not be a PC/SC frontend.

glenn wrote:

Would it make sense to implement this in current libnfc trunk? If yes, what would be the best way to do this? Any advice or comments welcome.

IMHO, you could write a dedicated driver for RC531 that use a raw device access. Please note that if you use the SDK, please check the license.
BTW, RC531 is not NFC compiliant neither (as CCID generic device so why do you want to use libnfc to drive it ?

Romuald Conty
  • Registered: 2010-12-17
  • Posts: 57

Re: Supporting readers over PC/SC

rconty wrote:

IMHO, this is not possible to drive generic CCID device using libnfc: almost all libnfc features are not implemented by CCID.
BTW, its possible to write a minimal driver that can use CCID device as a NFC initiator, but that's not a targetted feature since interesting part of NFC is emulation and P2P.

I agree that emulation mode and P2P are very interesting, but for many applications reader mode is a very important feature, for which this minimal driver would suffice i guess. For instance libfreefare and all application build on top of it only require initiator mode, right? It would be good if this generic CCID driver would allow all compliant devices to be used by libnfc even if it is only in reader mode i think. Applications requiring P2P or emulation mode can use a device which has a driver with more capabilities.

rconty wrote:

From my point of view, we should not implement driver that use PS/SC, it not the right order of things (even ACR122 should be drop): libnfc can be an ifdhandler of PC/SC (behind PC/SC, as driver backend) and should not be a PC/SC frontend.

I am not entirely sure what this means..
For instance this is my current 'stack':
myapp < mylib < libfreefare < libnfc < pc/sc < acr122

I assumed that this would allow me to switch to another supported reader (be it pc/sc or not) or platform easily without having to touch the 'upper' layers. Now if libnfc would be a driver backend (in case of PC/SC), would this mean that applications using an ACR122 or another CCID device should be build directly on top of PCSC then, instead of talking to libnfc directly? If the application later decides to switch to a device which has a more capable driver, would this mean the application needs to be rebuild to use libnfc directly instead of PC/SC? Or will libfreefare make an abstraction of this, so applications build on top libfreefare don't have to take this into account? Having such a 'frontend' abstraction layer is really useful i think.

thanks,
Glenn