Hi Sebastien, Thanks for your reply!
You wrote: > For the moment I am focused on uart smartcard support only. Once you have something that I could start to port to the STM32U5, please let me know. Bye, Michael Sebastien Lorquet <sebast...@lorquet.fr> schrieb am Mo., 22. Mai 2023, 10:07: > Hi, > > First of all I need reliable communication with a particular brand of > card I cant disclose, and I dont think any certification is on the scope :) > > But EMV certification is probably possible with a bit more dedication. > Usually the complexities are around timeouts, error behaviour, and a lot > of idiosyncrasies. > > You could help by porting to your platform, and testing the code that > will be common to all platforms. > > I believe implementing the pcsclite de-facto standard would benefit a > wider community, since it would allow interoperability with linux > programs that use smartcards? > > For the moment I am focused on uart smartcard support only. > > Thanks for your interest, > > Sebastien > > > Le 17/05/2023 à 16:17, Michael Jung a écrit : > > Hi Sebastien, > > > > one of the projects I am working on requires an EMV 4.3d level 1 > compliant > > smartcard reader on an STM32U5. So I would be very interested in the > work > > you are planning to do. I have a lot of background knowledge on EVM > > compliant contactless card readers, but unfortunately not so for the > > contact cards. We do have people in the team that do have this > knowledge, > > though. > > > > Do you think your approach would allow to get EMV 4.3d certification? > > Would it be possible to get early access to your code? Could I help you > in > > developing this? > > > > Thanks! > > Michael > > > > > > On Tue, May 9, 2023 at 7:13 PM Sebastien Lorquet <sebast...@lorquet.fr> > > wrote: > > > >> Hi, > >> > >> it is time! > >> > >> > >> I am, right now, starting to implement the smart card mode for STM32 > >> USART, starting with STM32H7, this will be portable to other STM32 chips > >> I guess. > >> > >> The UART mode will just configure the uart for smartcard shenanigans, > >> eg, put it in working order for this mode. > >> > >> Smart card contact protocols (T=0, T=1) will go into a user space app > >> that manages readers, similar to pcsclite daemon in linux. > >> > >> > >> So the smart card mode of the stm32 usarts is just an activation of the > >> proper registers, that will : > >> > >> -wire the hardware as expected: enable the clock output, define one > >> single full duplex IO line > >> > >> -reconfigure the uart character framing, including parity generation and > >> detection, which is a fundamental mechanism, required for protocol > >> compliance testing. > >> > >> > >> The exchanges will still be made with the read() and write() primitives > >> (protocol is a kind of IPC), so I am expecting to add just a few IOCTLs: > >> > >> -ENABLE smart card mode with a bool parameter to enable or disable, > >> default disabled > >> > >> -START or STOP the clock signal (if possible, I did not dive in the RM > yet) > >> > >> -Define the communication speed in terms of ETU (clock pulses per bit, > >> which is different from the baud rate and the industry standard way to > >> define smart card comm speeds). This need to be modifiable, the speed is > >> negotiated dynamically at card insertion. > >> > >> This will return a ENOTTY error if a particular uart does not support > >> Smart Card mode. > >> > >> > >> > >> However, to be future proof, another way is possible. > >> > >> USB CCID smart card readers are also a thing. In pcsclite (linux), these > >> are managed via libusb from userspace. > >> > >> But we can do something special in NuttX, like defining a smart card > >> "lower half" that can be implemented by both the stm32 uart in smart > >> card mode, or by the future usb ccid driver. I do not plan to *port* the > >> full pcsclite, but I will do something that tend to be compatible, while > >> being much smaller. > >> > >> The great question is then how to manage the "upper half" of such > drivers. > >> > >> If it was just me, it would be a character device, that would have > >> IOCTLs to enumerate lower halves (eg card readers) so a user space app > >> can dispatch commands to multiple readers. But I know NuttX despise > >> character devices. So, I am going to need some inspiration here. Sockets > >> do not seem appropriate to how things work in the smart card world, I > >> can tell that from 13 years of professional experience :) > >> > >> If NuttX has a libusb-like protocol now or later, then we dont need to > >> be concerned by this lower half and char dev, this can all happen in the > >> management daemon. > >> > >> There are also modular card readers that use plain old serial protocols, > >> these would also be handled from the user space daemon via specific > >> drivers. > >> > >> > >> > >> So, this is the correct time to define this in a way that please > >> everyone and will be useful for a long time. We need compromises between > >> imperative needs of this mode and the NuttX way of doing things. > >> > >> The goal is to facilitate the upstreaming of this feature. > >> > >> I know smart cards are unusual and quite niche, you can ask me as many > >> questions as needed to understand smart card context, behaviour, and > >> habits. > >> > >> > >> Thank you for your reading and comments > >> > >> Sebastien > >> > >> >
