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 47
Findings of Peer Review of Interoperable Smartcard Programs 47
capability for future implementation. This integration is not fully automated and usually
requires manual input by the employer or smartcard system operator.
3.2.1.4 Security Elements
The security architecture varies across each implementation. The research found that most
projects use either a variation of the Data Encryption Standard (DES) or a variation of the Triple
Data Encryption Standard (3DES) as a cryptographic algorithm within their card and device
tier. To achieve interoperability, at a minimum, the cryptographic security algorithms used
for communication between the card and reader will need to be defined. In addition to the
algorithms, the use of symmetric cryptography will require the exchange of key data to achieve
interoperability.
In general, each region has unique keys for accessing the data on its cards. To achieve higher
order interoperability, a mechanism needs to be established that allows cards with keys from dif-
ferent regions to be accessed in a single system. Key management is one of the most significant
barriers to higher order interoperability because of the unique way each supplier handles secu-
rity keys. All systems may use the same key. However, if the single key is compromised, then all
keys need to be exchanged, which is time consuming and costly.
3.2.1.5 Optional Data Elements
The survey indicates that the use of optional data elements for increasing the utility of the card
beyond transit fare payment is not typically available. The most common uses beyond transit fare
payment include
· Identification for access control (e.g., to agency facilities or university campus services);
· Transit and non-transit loyalty programs;
· Bridge and highway toll payment;
· Non-transit retail payment; and
· Parking payment.
The approach to implementing optional card features varies widely and will be affected by the
systems and equipment design of the participants. Most specifications require the system sup-
plier to be able to add these capabilities in the future. Because of the card design, at a minimum,
the cards will need to be exchanged if the capability was not demonstrated during the design
review. Moreover, if the transaction data need to be transferred to or through the transit central
clearinghouse, costly software modifications will likely be required.
3.2.2 Current Trends and New Developments
A trend for interoperable smartcard programs is using the stored-value purse for non-transit
payments, such as payment for parking and bridges and highway tolls. Since the inception of
transit smartcard programs, it has been envisioned that the transit card will be used with finan-
cial institutions, for retail payment, and/or for secure access control.
European and Asian transit smartcard systems are more mature than U.S. and Canadian sys-
tems. Since U.S. and Canadian programs are only now beginning to be rolled out, the use of the
card is limited to transit. However, the vision of most U.S. and Canadian agencies is to expand
the utility of the card with other applications.
The following two sections summarize the current trends and new developments in Asia and
The United States and Canada. Given that Oyster only recently rolled out and where prolifera-
tion beyond transport payment has not started, the discussion on the United States and Canada
contained in Section 3.4 would apply.
