Smart Card Development in Android

Question

We developed a prototype board with a microcontroller that can communicate with SmartCard (it can read ATR, issue and read answers to APDU commands, etc.). Now I want to use this equipment 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 ultimate goal is to have a built-in Android smart card reader with PKCS # 11 support and provide the library with SmartCard reader end users so that they can communicate with their cards.

I read several discussions on this subject, some of which stated that I would need to create my own Android for this. I am not very familiar with the architecture of Android to understand why I will have to rebuild Android when I can communicate with my peripheral device (card reader) via USB. It seems to me that if I provided a library that implements a CCID-like interface, users will be able to communicate with my reader using the Android USB stack by integrating my library into their target .apk file.

Are there any problems with the above plan that we don’t know about? I am worried that we are missing something fundamental with regards to Android or SmartCard devices in general (for example, security), which will cause problems for us when we start implementing the libraries described above.

Answer 1

I have built-in USB peripherals in a custom Gingerbread distribution for my custom platform. The only reason you set up the Android platform is to add or change some drivers that will give you access to your USB device. If your USB device already uses a protocol supported by standard Android devices, just enjoy your luck! You are pretty much everything set up. But before celebrating your victory, I would try it on different devices. At the Android and Kernel level, Google provides very simple content with a large number of driver source codes. It is up to the manufacturer of the phone / tablet to decide which low-level drivers and protocol they will include in accordance with the equipment that their device uses. Since the amount of memory is limited on the phone / tablet, the general rule is to include only what is needed. You have no problem with PC-Linux architecture, since the hard disk space is so large that you include all existing drivers, and you let the system choose and choose what you need, depending on what it detects.

Hope this simple answer is helpful.

Answer 2

I'm not sure about the CCID implementation for the reader, but for Android there are several C / C ++ ports, although I'm not sure if they work. In the android part, it’s pretty easy to implement the CCID protocol, take a look at this one . The most difficult thing is to make the firmware for the reader, there are many small details that need to be taken care of.

Answer 3

After additional research in this area, several solutions will be available to you:

1. Create your own drivers (simple communication, a few simple commands to reset the card and its power). In this case, you just need to implement the reset / power commands and the communication protocol T = 1, however, the big disadvantage of this method is that it will only work with your card readers, which is a big limitation.
2. Implement the CCID interface on the controller and wrap it around APDU commands. This method is scalable and as long as you follow the specification (many manufacturers do not, and that is why pcsc-lite has a list of supported readers). This method is the most economical if you want to sell a lot of readers. You can find the specification here.
3. Add a CCID chip to your assembly that already has CCID enabled. These chips are manufactured by several suppliers, STMelectronics has a lot of them, however in this case your end reader will cost more, and you will not have full control over the protocol.

As for Android, seek offers a pcsc-lite driver port, have not tried it, but from the source code I can say that they only modified the USB-API from the source driver and used the JNI interface to communicate with the c code.