Re: STM32 SmartCard mode happening right now!
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 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 > > 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
Re: STM32 SmartCard mode happening right now!
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 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
Re: STM32 SmartCard mode happening right now!
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 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 > >
STM32 SmartCard mode happening right now
HI, No idea why this message did not make it through. Resending with small updates. 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 one IOCTL, like is done for LIN, single wire, and 485: +#define TIOCSSMARTCARD _TIOC(0x0038) /* Set Smart Card mode */ +#define TIOCGSMARTCARD _TIOC(0x0039) /* Get Smart Card mode */ The parameter given to the IOCTL must be able to: -ENABLE smart card mode with a bool parameter to enable or disable, default disabled -START or STOP the clock signal -Define the communication convention -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. -Define the character guard time, which is a delay between transmitted characters. This will return a ENOTTY error if a particular uart does not support Smart Card mode. 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. Does anyone have suggestion about this uart mode? Thank you for your reading and comments Sebastien
STM32 SmartCard mode happening right now!
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
