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 80
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 81
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 82
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
