Martin Paljak wrote: > On May 19, 2010, at 19:35 , Juergen Beisert wrote: > > The list gets longer: > > > > Jim Rees wrote: > >> You might want to add pinpad support. Also think about how you want to > >> handle multiple readers or multiple slots per reader. And card > >> insert/removal notification. > > > > 'pinpad' means a reader's local keyboard? Does it require some kind of > > communication between the SmartCard and the application? Or handled > > locally in the reader device? > > If your device implements it, then it means communication between reader > firmware and smart card. The idea of pinpads is to remove the probably > compromised host computer from the PIN entry process. PC/SC defines a > software interface for pinpads. But you also need support from your > hardware/firmware and you need to implement the support in your ifdhandler > and somehow also in the userspace/kernelspace protocol.
The external card reader device uses a local processor to run its own firmware. But my case is a little bit different than with an external reader device: My regular Linux system is the processor and the firmware (it is the reader itself). So, maybe we should omit such a feature, because its too easy to compromise it. > > 'Multiple readers/multiple slots': My i.MX25 processor provides two > > independent SmartCard interfaces. Are these two physical interfaces > > "multiple readers" or more like "multiple slots"? > > The "compatible" (read: PC/SC) way is to create two reader interfaces. Okay. > > BTW: Are there any preferences how to communicate with the kernel driver? > > It could be done via IOCTLs (the classic way) or via sysfs entries. Just > > an idea: Via sysfs it would be possible to create named entries in a per > > hardware feature. So, only entries exists the hardware really supports. A > > userland application (or openct/PCSC adaption driver) would be able to > > detect hardware's features by scanning the sysfs entries. > > IOCTL-s seem like a more portable way (if it matter at all). For example, > PC/SC defines API-s and structures to query reader (hardware) features as > well, see [1] for a recent blogpost by Ludovic. > > [1] > http://ludovicrousseau.blogspot.com/2010/05/how-to-know-pin-sizes-supported >-by.html Regards, Juergen _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
