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 > >
