Cover Image

Not for Sale



View/Hide Left Panel
Click for next page ( 80


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 79
CHAPTER 7 Findings of Proof of Concept Using Standard API 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

OCR for page 79
80 Smart Card Interoperability Issues for the Transit Industry Exhibit 1. AFC simulator code segment. 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; } 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. Exhibit 2. Standard smartcard reader API. 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");

OCR for page 79
Findings of Proof of Concept Using Standard API 81 Exhibit 3. Standard API compared to proprietary API. 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. 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. 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

OCR for page 79
82 Smart Card Interoperability Issues for the Transit Industry 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. Table 18. Transaction timing charts. Activity DESFire with ASK LDB 215 DESFire with OTI UltraLight with UltraLight with Saturn 5k ASK LDB 215 OTI Saturn 5k Select App 47 ms* 16 ms N/A N/A KEY 94 ms 32 ms N/A N/A Authentication Read Data 47 ms 16 ms 47 ms 55 ms Write Data 47 ms 16 ms 47 ms 55 ms Write Transaction 62 ms 16 ms N/A N/A Record Commit Record 47 ms 16 ms N/A N/A Process T-Purse Transaction DESFire with DESFire with Activities ASK LDB 215 OTI Saturn 5k 1 Polling 100 ms * 390 ms 2 Select Application / Product 47 ms 16 ms 3 Authenticate purse's KEY 94 ms 32 ms 4 Read Data 47 ms 16 ms 5 Write Data 47 ms 16 ms 6 Authenticate record's KEY 94 ms 16 ms 7 Write Transaction Record 62 ms 16 ms 8 Commit Record 47 ms 16 ms Total Transaction Time 438 ms 144 ms (without polling time) Process Trip-Based and Time-Based DESFire with DESFire with Transaction Activities ASK LDB 215 OTI Saturn 5k 1 Polling 100 ms * 390 ms 2 Select Application / Product 47 ms 16 ms 3 Authenticate KEY 94 ms 32 ms 4 Read Data 47 ms 16 ms 5 Write Data 47 ms 16 ms 6 Write Transaction Record 62 ms 16 ms 7 Commit Record 47 ms 16 ms Total Transaction Time 344 ms 112 ms (without polling time) Process Trip-Based and Time-Based UltraLight with UltraLight with Transaction Activities ASK LDB 215 OTI Saturn 5k 1 Polling 100 ms * 390 ms 2 Read Data 68 ms 16 ms 3 Write Data 52 ms 16 ms 4 Write Transaction Record 52 ms 16 ms Total Transaction Time 172 ms 48 ms (without polling time) * ms = milliseconds