Smartcard Interoperability Issues for the Transit Industry (2006)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

The importance of contactless smartcards to transit is that these devices serve as secure and convenient vessels for holding the application data elements. The application data elements rep- resent the information required by the AFC system to properly assess fares to passengers and construct transaction records. As discussed in Section 4.2.3, the application layer is the mecha- nism used to retrieve and update the application data elements on the card. The primary responsibility of the transit software application is to implement an application layer to allow this data exchange to occur. The less time and effort that needs to be spent in conforming the execution of the application layer to the proprietary interface of a smartcard reader, the greater the benefit for transit. The objective of this chapter is to show the concept of how hardware independence can be for- warded through the use of a proposed standard smartcard reader API. Currently, contactless smartcard readers typically either have their own proprietary API to communicate between the reader and the application software or merely a framing protocol that must be implemented by a software application. This situation limits a prewritten application from adapting transparently to another type of smartcard reader. In the case of a mass-transit application, when an agency has purchased smartcard-based automatic fare collection (AFC) equipment and needs to upgrade or change its smartcard technology, the agency has to rewrite the application software to communicate with new hardware. By standardizing the smartcard reader API for transit appli- cations, any additional investment in modifying application software to upgrade card reader equipment can be reduced or eliminated. 7.1 Use of Standard API in Proof of Concept To prove this concept, the research team developed a contactless smartcard reader API and an AFC simulator. With experience gained from working with several proprietary readers, the team developed a set of API functions essential to contactless smartcard reader operation. The specification of the API functions is listed in Chapter 6 and will be referred to as the standard API in this report. A subset of the standard API functions was used in the AFC simulator to communicate with the smartcard reader. The team also selected two commercially available readers, the ASK LDB 215 reader and the OTI Saturn 5000 reader, for testing with the AFC simulator. Given that both of these readers use proprietary APIs from their respective manu- facturers, the development of conversion layer software was required in order for the readers to work with the AFC simulator. The conversion layer was designed to convert the proprietary reader API functions to the standard API functions, allowing the AFC simulator to function with smartcards that are compatible with the ASK LDB 215 reader and the OTI Saturn 5000 reader. The simulator is designed with a feature that allows the operator to choose a reader 79 C H A P T E R 7 Findings of Proof of Concept Using Standard API

from a list of readers at run time to demonstrate the interoperability of the AFC simulator by using the standard API. Exhibit 1 is a code segment and an excerpt from the source code of the AFC simulator. It shows how the simulator loads the code that implements the standard API as a dynamic library when a reader is selected at run time. The simulator loads the API for the chosen reader and configures the reader settings. The module that is loaded is the conversion layer with the standard API func- tions embedded so that the simulator application can make the same function calls, regardless of which reader has been selected. Exhibit 2 is a code segment that loads the standard smartcard reader API functions from the conversion layer software. These functions are used throughout the simulator to communicate with the selected reader. Standardizing the API not only provides the ability of interchangeable readers but also sim- plifies the structure of application software. Any smartcard application developed through the use of a standard API can communicate through driver software to any reader that complies with the API. Through the use of one set of common communication functions, the business rules of the application software can be performed through one common process for all the readers. Unlike using the standard API, an application developed by using a proprietary API has to imple- ment different ways of communicating to the readers for one set of business rules when the appli- cation is required to communicate with multiple types of readers or when the application must now support the upgrade of a reader. Exhibit 3 shows the differences in the implementation of an application using the standard API and the proprietary API. 80 Smart Card Interoperability Issues for the Transit Industry if(Reader == "ask"){ reader_dll = LoadLibrary("TCRP"); // load converted API of ASK readerConf.nDevice = 0x01; readerConf.nCommType = 0x02; card.nTimeout = 0x19; updatePTR(reader_dll, 1); if(whichReader == 1) reader1 = 1; } else if(Reader == "oti"){ reader_dll = LoadLibrary("OTISaturn5k"); // load converted API of OTI readerConf.nDevice = 0x02; readerConf.nCommType = 0x01; readerConf.cUsbName = ""; readerConf.nComPort = 0; readerConf.nID = 0; card.nTimeout = 25; updatePTR(reader_dll, 2); if(whichReader == 1) reader1 = 1; } Exhibit 1. AFC simulator code segment. readerOpen = (int (*)(PCD*))GetProcAddress(reader_dll, "OpenReader"); readerClose = (int (*)(PCD*))GetProcAddress(reader_dll, "CloseReader"); readerPoll = (int (*)(PICC*, PCD))GetProcAddress(reader_dll, "Poll"); readerTransmit = (int (*)(Command_Frame, Response_Frame*,BYTE,PCD)) GetProcAddress(reader_dll, "TransmitToCard"); Exhibit 2. Standard smartcard reader API.

One potential development aspect of this project was the proposal of a new APDU specific for transit applications. The impetus for this work was the uncertainty of the suitability of the ISO/IEC 7816-4 Interindustry Command Set for transit applications. The 7816-4 Command Set was developed for contact smartcards and was not widely supported initially by manufacturers Findings of Proof of Concept Using Standard API 81 Implementation Process of Using Standard API for Multiple Devices Load the driver with standard API. Initiate the communication with the reader. Configure the application data unit. If opening reader is successful { Poll for a card If a card is found { Perform a set of business rules. } } Else if opening reader is failed { Error Message. } Unload the driver. Exhibit 3. Standard API compared to proprietary API. Implementation Process of Using Proprietary API for Multiple Devices Load the driver with proprietary API. Initiate the communication with the reader. If the reader is type 1 { Configure the application data unit for type 1 reader. If opening reader is successful { Poll for a card If a card is found { Perform a set of business rules. } } Else if opening reader is failed { Error Message. } } Else if the reader is type 2 { Configure the application data unit for type 2 reader. If opening reader is successful { Poll for a card If a card is found { Perform a set of business rules. } } Else if opening reader is failed { Error Message. } } Else if … … … Unload the driver.

of equipment for the contactless interface. When the research topic was being developed this was a legitimate concern, however, since then there has been a dramatic shift in contactless smart cards toward support for the 7816-4 Command Set and away from proprietary commands. This is good news for transit, because the cards are moving toward interoperability. In addition, work has been performed in testing a proof of concept, the Regional Interoperability Specification for Electronic Fare Payment (RIS) that shows the 7816-4 Command Set can work well and within a reasonable timeframe for transit. A custom APDU for transit is no longer necessary or desirable, based on the utility and usability of the ISO/IEC 7816-4 Command Set and the movement among smartcard manufacturers to support that standard command set. Table 18 shows the transaction times of fare tickets with AFC simulator using 7816-4 commands within projected execution time. 82 Smart Card Interoperability Issues for the Transit Industry Activity DESFire with ASK LDB 215 DESFire with OTI Saturn 5k UltraLight with ASK LDB 215 UltraLight with OTI Saturn 5k Select App 47 ms* 16 ms N/A N/A KEY Authentication 94 ms 32 ms N/A N/A Read Data 47 ms 16 ms 47 ms 55 ms Write Data 47 ms 16 ms 47 ms 55 ms Write Transaction Record 62 ms 16 ms N/A N/A Commit Record 47 ms 16 ms N/A N/A Process T-Purse Transaction Activities DESFire with ASK LDB 215 DESFire with OTI Saturn 5k Polling 100 ms1 * 390 ms 100 ms 390 ms 100 ms 390 ms Select Application / Product 47 ms 16 ms 47 ms 16 ms 16 ms 16 ms 16 ms 16 ms 16 ms 32 ms 47 ms 16 ms 47 ms 16 ms 47 ms 47 ms 2 Authenticate purse’s KEY 94 ms 32 ms 94 ms 3 Read Data4 Write Data5 Authenticate record’s KEY6 Write Transaction Record7 Commit Record 94 ms 62 ms 16 ms 68 ms 16 ms 52 ms 16 ms 52 ms 16 ms 62 ms 8 Total Transaction Time (without polling time) 438 ms 144 ms Process Trip-Based and Time-Based Transaction Activities DESFire with ASK LDB 215 DESFire with OTI Saturn 5k Polling1 * Select Application / Product2 Authenticate KEY3 Read Data4 Write Data5 Write Transaction Record6 Commit Record7 Total Transaction Time (without polling time) 344 ms 112 ms Process Trip-Based and Time-Based Transaction Activities UltraLight with ASK LDB 215 UltraLight with OTI Saturn 5k Polling1 * Read Data2 Write Data3 Write Transaction Record4 Total Transaction Time (without polling time) 172 ms 48 ms * ms = milliseconds 47 ms 16 ms 47 ms Table 18. Transaction timing charts.

7.2 Development of AFC Simulator The simulator is designed to perform the AFC functions such as processing the fare tickets based on the type of tickets, the issuing agencies, validation periods, reading and updating purse balances, and issuing the fare tickets. Three types of fare tickets (i.e., trip-based, time-based, and purse) can be processed with the simulator. The data structure design of each type of ticket is based on the minimum data requirement of transit fare ticket and is a set of common data derived from an analysis of the four primary standard specifications: Regional Interoperability Standard for Electronic Transit Fare Payments (RIS), ITSO, CEN, and RKF. Table 19 shows the data fields of the card. The data structure has been implemented on both a Philips Mifare DESFire smartcard and Philips Mifare UltraLight smartcard. Because of the differing capabilities of the operating sys- tems of each card, the fare ticket’s data structure is implemented differently on each type of card. The DESFire Card Operating System (COS) supports a file structure, and the data structure of the fare ticket on this card is implemented as a file system with a security key on each file. Access- ing and updating the card’s information requires authentication of the security key. Because of the secure file system feature, the electronic purse fare product is implemented on this card. Trip-based pass and time-based pass products have also been implemented on the DESFire card for use as reusable fare tickets. Figure 16 shows the file structure of fare tickets on Mifare DESFire card. The Philips Mifare UltraLight COS supports a memory block architecture to store the data. The fare ticket’s data structure is implemented as a block, and can be configured to be irreversible when the card is issued from the AFC simulator. Since the fare ticket information on this card Findings of Proof of Concept Using Standard API 83 Card Holder Information Fare Ticket Information Transaction Information • Unique Card Number • Name • Birth Date • Profile Code • Card Validity Period • Ticket Type • Balances • Validity Period • Issued Agency • Electronic Purse • Date and Time • Type of Transaction • Transaction Amount • Original Balance Table 19. Data fields of fare tickets. Fare Ticket Directory File 1 Card Holder Information • Name • Birth Date • Profile Code • Card Validity Period • Type of Fare Ticket File 5 Transaction Information • Date and Time • Type of Transaction • Transaction Amount • Original Balance File 2 Time-Based Pass • Validity Period Issued Agency Code File 3 Trip-Based Pass • Trip Balance Issued Agency Code File 4 Electronic Purse • Current Balance Issued Agency Code Figure 16. File structure of fare ticket on Mifare DESFire card.

cannot be changed once it is written, the card can be issued as a one-time used-fare ticket. The trip-based and time-based pass products on this card are designed to be used up to the maxi- mum number of trips issued or within a period of time that has been written to the card. Because of the lack of data security, the electronic purse should not be implemented on this card. Infor- mation sensitive to the privacy of the cardholder or issuing agency should not be implemented on this card because the data can be read without requiring any authentication. In the AFC sim- ulator, the irreversible data setting was disabled to limit the consumption of UltraLight cards during demonstration. Figure 17 shows the simulator program flow. Business Rule application during transaction processing with the Mifare DESFire is shown in Figure 18. Business Rule application during transaction processing with the Mifare UltraLight is shown in Figure 19. An overview of the soft- ware architecture for the simulator is displayed in Figure 20. 84 Smart Card Interoperability Issues for the Transit Industry Figure 17. Simulator program flow chart. Select a reader. Initialize reader 1. Initialize reader 2. Select product type and agencies to accept. Poll for card until card detected by reader. Business Rules Display transaction information. Card Found.

Findings of Proof of Concept Using Standard API 85 Authenticate the Security Key (Triple DES) Check Agency Read data Update data Write transaction history Fail Success Agency's ticket declined Agency's ticket accepted Exit Figure 18. Business rules for Mifare DESFire Check Agency Read data Update data Write transaction history Agency's ticket declined Agency's ticket accepted Exit Figure 19. Business rules for Mifare UltraLight. 7.3 Demonstration The following steps are required to run the simulator: • Hardware Requirement  ASK LDB 215 contactless smartcard reader (RS-232 serial support) or OTI Saturn 5000 contactless smartcard reader (USB support)  Philips Mifare DESFire and Mifare UltraLight contactless smartcards • Installing the simulator  Double click on “TCRP Installer.msi”.  Follow the Acumen Setup Wizard instructions and click “Next”. The simulator is named “TCRPSimulator.exe”. • Running the simulator  Connect a reader to the computer.  Run the simulator by clicking “TCRPSimulator.exe”.  Click “Issue PICC” tab to issue a fare ticket on the smartcard.  Click “Monitor” tab for simulation.

– Select a reader. – Select agencies to accept its fare tickets. – Click “Poll” button to start polling a fare ticket at the selected reader.  Present the smartcard at the selected reader.  The transaction information will show on the simulator. 7.4 Conclusion Creating a standard contactless smartcard reader API for transit applications is feasible. Analysis of more contactless smartcard readers is needed to develop a broader and more scalable standard API. 86 Smart Card Interoperability Issues for the Transit Industry GUI Application (EXE) TCRP API for ASK LDB 215 OTI Proprietary API ASK Proprietary API OTI Reader ASK Reader Transit Applications on Smart Card • Time-Based pass • Trip-Based pass • Purse Simulator TCRP API for OTI Saturn 5000 Card Card Figure 20. Simulator’s components layout.