CODEWITHSUNDEEP
androidusbsmartcardapdu
SomethingBetter
SomethingBetter

Reputation: 1304

Developing a smartcard reader in Android

We developed a prototype board with a microcontroller, which can communicate with a SmartCard (It can read the ATR, issue and read responses to APDU commands, etc).Now I want to use this hardware with an Android phone or tablet. Our board has a USB connection, through which we can read and write to the MCU via Android.

The end goal is to have a functioning smartcard reader on the Android platform with PKCS #11 support and provide a library to the end-users of the SmartCard reader so they can communicate with their cards.

I have read several discussions on the subject, some of which stated that I would have to build a custom Android to do this. I am not very familiar with the Android architecture to understand why I would have to re-build Android when I can communicate with my peripheral (card reader) via USB. It seems to me that if I provide a library that implements CCID-like interface, the users can then communicate with my reader using the Android USB stack by way of integrating my library to their target .apk file.

Are there any problems with the above plan that we are not aware? I am concerned that we are missing something fundamental about Android or SmartCard readers in general (for example: security) which will cause problems for us as we start implementing the libraries described above.

Upvotes: 11

Views: 5744

Answers (3)

Daniel
Daniel

Reputation: 2554

After doing some more research in this field, there are several solutions available to you:

  1. Make your custom drivers (simple communication, some simple commands to reset the card and power it). In this case you will just have to implement reset/power commands and the T=1 communication protocol, however the big downside to this method is that it will work only with your card readers witch is a big limitation.
  2. Implement CCID interface on the controller and wrap it around APDU commands. This method is scalable and as long as you abide by the specification (a lot of manufacturers don't and this is why the pcsc-lite has the list of supported readers). This method is the most cost efficient if you want to sell a lot of readers. You can find the specification here
  3. Add a CCID chip to your assembly that has already CCID communication implemented. Such chips are manufactured by multiple vendors, STMelectronics has a lot of them, however in such case your final reader will cost more and you will not have full control over the protocol.

As for the Android side, seek offers a port of the pcsc-lite driver, didn't try it but from the source code I can tell that they only modified the usb api from the original driver and used a JNI interface to communicate with the c code.

Upvotes: 3

Daniel
Daniel

Reputation: 2554

I'm not sure about the CCID implementation for the reader, but for android there are some C/C++ ports, not sure if they work though. On the android part is pretty easy to implement the CCID protocol take a look at this. The hardest part is to make your firmware for the reader, there are a lot of small details you need to take care of.

Upvotes: 2

Sylvain Huard
Sylvain Huard

Reputation: 1398

I have integrated USB peripherals in a customized Gingerbread distribution for my custom platform. The only reason why you would customize the Android platform would be to add or modify some drivers that will give you access to your USB device. If your USB device already uses a protocol that is supported by standard Android devices, just enjoy your luck! Your pretty much all set. But before celebrating your victory, I would try it on a variety of devices. At the Android and Kernel level, Google provides a very barebone distribution with a lot of driver source code. It's up to the phone/tablet manufacturer to decide which low level drivers and protocol they will include according to the hardware that their device is using. Since the amount of memory is limited on a phone/tablet, the general rule is to include just what is needed. On a PC-Linux architecture, you don't have the problem since the harddisk space is so large that you include all the drivers that exist and you let the system pick and choose what it needs according to what it discovers.

Hope this simple answer will be helpful.

Upvotes: 2

Related Questions