Contactless Smart Cards
Date: Monday, October 27, 2014
These cards, similar to recently introduced contactless payment cards, allow for a simplified transaction process whilst providing a richer experience for the end customer.
We have been dealing with one of the most common types of smart card on the market, the MIFARE DESFire. The DESFire is a hard plastic card with an internal chip that can store a variety of data, and is most commonly used to store products that a customer can expend e.g. travel passes. In this particular instance, Village has been utilising ITSO part 11 services to add travel rights and passes onto smart cards for use on a variety of public transport throughout the UK.
In order to store values on a DESFire, it is necessary to learn the surrounding smart card technology and associated protocols. Application Protocol Data Units (APDUs for short), are small packets of information that are sent to the card in order to instruct it to perform read/write operations as necessary. To communicate with the smart card we must construct and send APDU packets. The smart card then returns reponse data in the form of APDU response bytes, which are then parsed and handled as necessary. The response packets are interrogated carefully as they contain status codes which indicate whether there is more data to read from the card, allowing us to continue or terminate execution as necessary. This requires a level of understanding that can only be gained through lots of exploration in to how the technology works - something which Village has invested the time in and has become more proficient over the past 12 months. Addtionally, as each part 11 service operates in a slightly different manner, we have the experience of integrating with a number of different environments whilst still providing the same level of functionality.
In order communicate with the contactless smart cards, you need to use hardware that is capable of doing the job. Village has first-hand experience of communicating via several MIFARE-ready readers including the ViVOPay Kiosk II, Newbury Data Printer ND4030 and (primarily for developmental purposes) the Omnikey 5321.
One of the more challenging aspects of using these card readers is managing the way we communicate to them. Each device exposes a different physical interface (e.g. serial port or USB), and in most cases require device-specific commands in order to access the deeper functionality of the readers. This complexity requires a deeper understanding of the hardware and the careful management of bits and bytes to ensure data is correctly transmitted to and from the card. When you combine these device-specific requirements + the understanding of ITSO + the utilisation of APDUs and their responses, it is apparent that Village has a considerable amount of knowledge in the area.