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. 18.104.22.168 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. 22.214.171.124 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.