On May 20, 2010, at 15:07 , Juergen Beisert wrote: > Jim Rees wrote: >> Juergen Beisert wrote: >> >> 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. >> >> You may want to omit the feature for your implementation. My suggestion is >> to add support for pinpad to the api. Someone else may want to use it. > > You miss the point. If one needs this feature, he/she has to implement it in > the userland driver. So, there is no need in kernel driver API for that. > > IMHO it would make the kernel driver way too complex, to handle such pin > input > and do the required communication itself to the attached SmartCard (okay, it > would be more secure then involving userland). > But all other user suggestions here do *any* protocol handling in userland. > And I second this.
Pinpad readers usually are in a tamper-evident casing (well, at least with a hologram sticker or something similar) and what gets verified is the contents of the case (and the external interface). In case of a SoC, if the pinpad and necessary firmware would get "verified" and sealed, it would be the whole box with the Linux software and associated pinpads, displays and whatever else should be included inside the verified box. So I don't think that it is absolutely necessary to address the pinpad concern in the kernel interface. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
