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 67
Findings of Key Information to be Exchanged Between Agencies 67 DATA · Market survey Business Process · Internet Analysis · Newspaper articles · Technical and scientific journals Threat Technology Assessment Assessment Risk Analysis & Cost Benefit Recommendation Analysis Figure 11. Threat and risk assessment. · Authentication--This is the process of ensuring the message received is the message sent and preventing message modification. · Non-repudiation--This guarantees that the message sender cannot deny having sent the message. Combining these elements is a function of the business processes, system design, and the expo- sure associated with the risks. The smartcard fare payment system security is analyzed during the system design-review process. The research team's findings indicate that a uniform security approach to support interoper- ability has not yet been developed. As an example, the transit industry has not yet adopted the use of standard Federal Information Processing Standards (FIPS), compliant security algorithms, or keys. The current lack of a standard has not hindered regional systems because a single sup- plier can provide an end-to-end fare payment system; however, multi-supplier interoperability will require the adoption of a uniform security protocol for smartcard-based fare collection sys- tems. At a minimum, the cryptographic security algorithms used in a regional system between a card and reader will need to be defined and shared to enable the opportunity for interoperabil- ity of cards and readers or the readers will need to accommodate multiple algorithms. In addi- tion to the algorithms, the use of symmetric cryptography will require the exchange of key data for interoperability. 4.3 Gap Analysis Critical gaps exist in current smartcard deployments in the United States and Canada. ISO 14443 and 7816 remove some barriers to interoperability, but even when combined with the minimal essential data set identified through this research, they alone are not enough to achieve full interoperability.
OCR for page 68
68 Smartcard Interoperability Issues for the Transit Industry Interoperability is accomplished through proprietary solutions at the application and security layers. Proprietary elements are embedded even into data elements governed by standards. For true supplier-independent interoperability, public domain standards, code, APIs, or some com- bination thereof will need to be openly available. Smartcard technology has introduced new features to both the transit patron and the transit agency. Some of these features, such as autoload, are popular with both the patrons and the agen- cies. Despite the popularity of these features, they are not critical to fare payment interoperabil- ity. However, a transit application that does not accommodate data fields for the more popular features is less likely to be embraced by the transit industry. Optional services that are emerging as key factors of smartcard acceptance for patrons and value creation for transit agencies include the following: · The use of a credit card- or bank account-backed autoload feature is a convenience to both patrons and agencies. However, because it is a convenience feature, autoload elements should be part of the optional, rather than essential data set. · Balance protection and the ability to change a card status to "ineligible" is a similar popular feature for protecting the incorrect use of monetary value in the smartcard e-purse. As with autoload, the elements associated with this feature should also be optional. · IRS-defined tax benefits for transportation and commuter parking are gaining momentum and are expected to conform as they are controlled by Treasury regulations. However, because the requirements to support a transit-related tax-benefits program may be complex, the ele- ments associated with this feature should also be optional. · Audit mechanisms for recording transaction history on the card, as well as for tracing trans- actions throughout the system, are beneficial but vary across implementations. Two ways in which smartcard-based fare payment implementations CURRENTLY perform transaction auditing are Audit Registers-As part of the transaction stream, require that separate and distinct data ele- ments be identified for transaction auditing. Transaction Transmission-Where elements of the previous transaction are sent concurrently with the current transaction thereby minimizing the possibility for lost or incomplete transactions. · A minimum level of system auditability may be achieved without having to define separate and distinct data elements. From a regional perspective, the selection of a standard audit mech- anism is key to interoperability within that particular region. As these features proliferate, it becomes increasingly important to expand the interoperable capabilities as needed to accommodate one or more of these features. Many of these functions have become "de facto standard" requirements for nearly all smartcard fare payment systems, although these functions are not required to achieve interoperability.