Support for quasi(?)-CCID compliant EZ100PU card reader

[drinkcat]

Not really an issue, more of a progress report, and looking for advise/ideas on next steps.

EZ100PU smartcard readers are still very popular in Taiwan, and commonly used to read NHI (health insurance) cards to access services (tax payment, health insurance data, etc.).

There is (was?) a binary driver at this URL, but the link is now dead (it's, however, possible to find at least one mirror). And I thought it'd still be nice to have an opensource driver, e.g. to be able to support non-x86 platforms.

My goal is just to replicate enough of the driver to support the basic features required by the NHI service mLNHIICC.

I started an implementation from scratch in this repo, but as I was going, I started to realize that a lot of the protocol looks very similar to standard USB CCID.

So instead, I went and hacked the CCID code to make it support the reader. The fork is here, dirty branch. Changes I had to make:

• The reader doesn't advertise CCID class in USB descriptor, so I had to skip a few check, and manually return a fake CCID desciptor in get_ccid_device_descriptor (copied the values from Castle's EZCCID, no idea if any of this is correct...)
• The endianess of dwLength field is... flipped. It's big endian instead of little endian. I hacked i2dw and cmd_dw2i. I'm not sure if any of the other fields are flipped...
  • When responding to the power up command (62h), the returned ATR is prefixed by a 0x00.

And that's... basically it. With those changes, I could get pcsc_scan -s to work with a bunch of random cards I have, and, most importantly for my purpose, the NHI service appears to work and I can login on one of the websites.

I also dumped USB traces and compared logs between the binary driver and my hacked driver when using pcsc_scan. Some minor differences (see gist for details):

• The binary driver sends a 60h command (NULL command?) on init, and gets back some identification string for the device.
• The binary driver use 62h/PC_to_RDR_IccPowerOff to poll for card status. The hacked driver uses 65h/PC_to_RDR_GetSlotStatus, but that seems to work too.
• The binary driver uses automatic voltage (0x00) in 62h/PC_to_RDR_IccPowerOn but the hacked driver forces 5V (0x01). That's fine I guess.
• Command order is a bit different, but that doesn't seem to matter.

So now, I'm not quite sure what to do as next steps:

• More testing? I think I'm mostly done for the purpose I had in mind, but if there's some more advanced testing you'd suggest, I'm happy to try (I guess I'll need some useful smartcard, instead of a bunch of expired cards I have lying around...)

• It should be possible to clean up my hacks and actually integrate my changes into CCID codebase without breaking existing card readers (through some sort of quirk detection mechanism). Is this something you'd be willing to take in (if it doesn't end up looking too ugly that is)? Or should I just maintain a fork? (I'd probably just remove all other cards from supported_readers.txt in that case, so that the 2 drivers can coexist)

  Thanks!

[drinkcat]

(pushed a few commits on my master branch with some possible way to support this somewhat cleanly: https://github.com/drinkcat/CCID/commits/master/)

[LudovicRousseau]

It is fine for me if you have your driver as a fork of my CCID driver. I don't like to include code I can't test myself in a project I maintain.

ACS also has its own fork for their "custom" readers at https://github.com/acshk/acsccid

[drinkcat]

Sounds good, thanks! I'll keep opening PRs if I find things that can be useful for both projects, thanks for merging the few I sent over.

Renamed my repo, added a bit of documentation, and made the fork able to coexist with this driver: https://github.com/drinkcat/ezCCID .

I'd also be happy to ship you a couple of those readers if you are interested (they literally sell them like candies here ,-P), let me know and we can coordinate.

Closing this for now. Thanks!

[LudovicRousseau]

I already have a lot of readers :-) But if you think that could help to have a EZ100PU you can contact me privately. My email is available from https://blog.apdu.fr/articles/about_me/