Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
87 C H A P T E R 8 The best approach to take when determining the management and organization for a smartcard-based AFC environment will be determined by the existing capabilities of the region. If the region has an agency of good size with a significant level of experience in large-volume smartcard-based fare collection operations, then logically that agency should become the lead agency in developing a fare collection approach for the region. If an existing governing body pre- sides over the transit agencies in the region and has a strong engineering support staff, then log- ically that governing body should lead the regional fare collection effort. If neither of these previous conditions exists, then the project should be led by a management committee that rep- resents each of the agencies in the region. Regarding implementation and operations, the best approach depends on the composition of the agencies in the region. If the region has a lead agency, it may make sense for that agency to become the central provider and integrator for operational services to the other agencies. Thus, the non-lead agencies outsource this function to the lead agency. This is a practical approach because the non-lead agencies lack the experience and depth to perform these functions and with this approach they do not need to commit resources to develop the core competency or expert- ise in this area. The lead agency simply builds on what it already does well and is compensated for this effort. If a region is run by a regional planning organization or a management commit- tee, then a centralized approach is the obvious method. This approach is likely to be the result of the regional planning organization or management committee creating a specification of busi- ness rules derived from the fare policies of the regional agencies. The specification can now be put out to open bid where third-party contractors can propose solutions for program imple- mentation. Regardless of the approach taken, agencies or management committees are best served by employing transit consultants to assist in their planning and implementation efforts. An agency will seldom possess the same level of in-house expertise as does the consulting firm. Regardless of the management approach adopted, a fundamental step is the creation of a par- ticipant agreement acceptable to all participants. This agreement should be viewed as extensible to new participants in the region in the future. Another basic consideration should be an analy- sis of external factors influencing electronic fare payments. For example, if contactless bankcards have been introduced and are held by many patrons in a region, then perhaps the acceptance of contactless bankcards would be a system design imperative. It is always good practice to verify the results of system integration incrementally. Thus, a phased approach is the most responsible method of deploying a regional smartcard-based fare collection program. One approach for phasing this deployment would involve supplementing the Card Interface Device (CID) equipment into fare collection and issuing smartcard fare media initially to agency employees only. This would allow for real live data and statistics to be compiled for system-validation purposes with less risk than a full public deployment. Another strategy Conclusions
would be to introduce only a few fare products initially. This approach also limits the complex- ity of the system analysis and can give an ideal opportunity to uncover weaknesses or problems in the new system. A contracting strategy balances the costs of management of vendor(s) versus the costs of equipment and services provided by vendor(s). Although a single vendor approach is the easiest to manage, the cost of products and services may not be as competitive, because very few single respondents can supply the complement of equipment and services for a regional smartcard- based fare collection system. Multiple vendors may provide a more competitive contract process, but the management is more complex and costlier. Given the many individual schedules that must be coordinated, the multiple vendor contract approach may lead to a longer elapsed time between the project inception and deployment when compared with the single procurement contract model. The decision to use multiple vendors may also be determined by the size of the agency and the scale of the deployment. The larger the project, the higher the degree of com- plexity required to manage the overall project. Financial management issues, such as settlement of payment and funds pool management, should be decided by a finance committee set up by the region. The decision of whether clearing and settlement should be centralized is the decision of the committee. A centralized clearing- house is the easiest approach; however, the overhead required to operate the clearinghouse may be a barrier. A decentralized approach, where agencies must have relationships with each other for reimbursement and transfer privilege, requires greater effort on the part of any given agency to maintain these multiple relationships. This method, however, might be the most financially practical solution. The adoption of one approach over another is best indicated by the level of inter-agency use by patrons. More specifically, if an agency has predominantly single-agency transactions, then centralized clearing is inefficient. Current deployments of smartcard-based fare collection systems throughout the world demonstrate that there is no clear technical or business model for creating an interoperable envi- ronment. Every system studied shows some attempt of using currently available standard fea- tures for smartcard-based systems, but these implementations are mainly proprietary because of waivers granted with respect to the use of these standards. For example, most smartcards com- ply with the ISO/IEC 14443 standard; however differences in the implementation of minute details, such as response timing, can preclude the interoperation of cards and readers. Not all of the readers used in these projects are fully ISO/IEC 14443 compliant, nor do they all support both Type A or B smartcards, and only one agency has implemented a full ISO/IEC 7816-4 command set to define the communication between the card and the reader in a standard manner. With regard to security, smartcard applications, interfaces, and back-end systems, the implementations involve a mixture of schemes, all of which are mainly proprietary. The current system imple- mentations show they can be the first step in effectively moving the transit industry toward inter- operability. The next challenge for smartcard-based systems should be to adopt standards in order to move toward this goal. If transit systems make full compliance to ISO/IEC 14443 and ISO/IEC 7816-4 a procurement requirement from equipment integrators, the problem of smart- card hardware interoperability could, to a large degree, be solved. Almost all current national and international transit implementations of smartcard-based fare collection systems are proprietary. To reach true interoperability and a competitive environment for smartcard-based fare collection solutions, transit must insist on using standards throughout all tiers of the system. Doing so will result in greater availability of multi-source vendors to sup- ply products and services at a greater cost savings to agencies. As standards such as ISO/IEC 14443 and ISO/IEC 7816 become more ubiquitous, transit fare collection components must be built on them. It is projected that form factors for contactless fare media will be expanding from just cards to soon include watches, fobs, and cell phones. Other contactless applications on the 88 Smart Card Interoperability Issues for the Transit Industry
horizon include banking, retail, and building access. Transit must keep standards a priority and look for new form factors and cooperation with other potential issuers like banks or retailers. Limited-use smartcards, also known as memory logic cards, have restricted capabilities and are a low-cost solution for transit agencies. On this class of card, the processor provides read/write and limited or no security for these operations. These cards are best suited for appli- cations that do not require a great deal of data or high security, such as a one-trip ticket or daily pass. At a minimum, these cards should adhere to the ISO/IEC 14443 specification parts 2 through 3. [These parts define the radio frequency power and signaling interface scheme, of which there are two (Type A and B), and define the initialization and anti-collision procedures.] This class of smartcard typically offers a very small amount of memory, on the order of 48 bytes, and they are only suited to applications with limited memory requirements. At this time, no limited-use cards support the ISO/IEC 7816-4 commands and only implement proprietary com- mands. Although this precludes the transparent substitution of limited-use cards from one ven- dor to the product of another vendor, the low cost of these devices is likely to determine their use in emerging AFC systems, despite their inherent lack of interoperability. Full-featured smartcards, which contain a microprocessor, are more expensive, but offer greater capabilities than the limited-use smartcards. These cards are best suited for long-term use, because they offer greater storage capacity, the capability of storing of multiple applications, and a higher security model. These cards should not only offer the same ISO/IEC 14443 Parts 2 through 3 requirements of the limited-use cards, but also be Part 4 compliant. (ISO/IEC 14443 Part 4 defines the transmission protocol and framing for data exchange.) As memory storage size on smartcards increases, the value of a robust transmission protocol will become more evident. The fully featured smartcard should also adhere to the entire APDU set defined in Part 4 of the ISO/IEC 7816 specification, which standardizes a command set used for data exchange between the reader/writer unit and the smartcard. Adopting ISO/IEC 7816 Part 4 and 3DES as the stan- dard security level would standardize the security process for the smartcards. This would solve a major problem with current smartcard implementations, where most security schemes are pro- prietary. Requiring these ISO specifications would virtually turn smartcards into a commodity item and increase the number of smartcard sources available and increase vendor competition. The reader/writer device, also known as a proximity coupling device (PCD) or CID, should also adhere to standards. The difference between a PCD and a CID is that a PCD is a âdumbâ device, commanded by a host controller device such as a single board computer in a faregate or TVM. It is the primary job of the PCD to pass instructions and data between the host controller and a smartcard. Conversely, a CID is a self-contained unit constructed with an embedded processor and code to implement the instructions and business logic and is connected directly to the components responsible for the radio frequency (RF) generation and modulation. A PCD can be an interchangeable device, no matter what model or manufacturer; however, it is also a slower solution for smartcard transactions because of its additional layer of communication to an external host processor. The CID model offers faster smartcard transaction times, but also makes a change in reader/writer deployment more difficult, because a rewrite of the logic will probably be required. In an interoperable environment, both the PCD and CID must be able to work with both Type A and B smartcards as defined in the ISO/IEC 14443 Part 2 specification. Also, the CID must be able to add at least two SAMs in its design. The SAM allows a safe method for both deploying secret key information for authentication and encrypting the data transmit- ted during a secure smartcard transaction. A common data model is also critical to achieve interoperability for smartcard-based systems. A minimum set of data elements common to all systems must be defined and used. This set of data should consist of information about the cardholder, including card identification number, card issuer identification, patron profile code, and card validity period, and information about Conclusions 89
the products, including product identification number, product validity period, and fare amount for electronic purse transactions. This set of data should also contain information about the jour- ney, such as agency identification number, date/time of journey event, entry and exit location of journey, and route number. Also, adopting a regional data standard that meets the minimum data element set, such as the RIS or the Universal Transit Farecard Standards (UTFS), is highly desirable and essential if intra- regional operability between regions is desired. The RIS and UTFS also offer other data items that can be used within other agencies. Another benefit of adopting a published data model stan- dard is that it is easily understood and allows for competitive vendor selection for implementa- tion and further system expansion and maintenance. The data standard adopted by transit should have broad capabilities to allow for many types of electronic fare payments. If it is broad and flexible enough, it can allow non-transit applica- tions such as parking, bridge and highway tolls, retail, access control, movies, and school ser- vices, to share a common purse with transit applications. The RIS has been designed in such a manner and should serve as a preferred path for future implementations based on a stored- value/transit application model. This can be used in addition to the acceptance of bankcards directly. A standard approach for security on both hardware components and data flow throughout the system tiers must be defined and established for smartcard-based fare collection systems. Hardware and communications channels should be as secure as messages between a front-end device and the bank clearinghouse [e.g., the Verifone security model for personal identification number (PIN) pads]. In the PIN pad model, if a hardware device is ever tampered with or altered in order to âsniffâ messages, the unit becomes permanently inoperable. The same level of secu- rity should be applied to PCDs and CIDs. For the software layer, there must be a standard pro- posal to generate a signature for a transaction; this ensures data integrity and fully encrypts the data stream to provide data confidentiality. Current public algorithms such as SHA1 for signa- tures and DES/3DES for encryption would be solid choices for this approach. A standard API was developed for this project and was designed to prove that a software layer with a common command set could be created to work between a host application and different manufacturer/model PCD/CID, which then interface with a smartcard. All smartcards for this project must be at least ISO/IEC 14443 Parts 2 to 3 compliant. Today, virtually no PCD/CID offers a common way to poll (search for) or query/update an ISO/IEC 14443 Part 2- to 3(4)- compliant proximity integrated circuit card (PICC) in the generated RF field. All PCDs/CIDs offer either a very small subset of the ISO/IEC 7816 Part 4 commands or their own proprietary commands. This API proved that the commands supplied by the manufacturer for each of the PCDs/CIDs selected for the project can be translated into a common set of newly defined com- mands, thus forming a seamless layer between the host application and the PCD/CID. If this API is instituted by the PCD/CID manufacturers as a driver or maintained as a TCRP dynamic load library (DLL) module, the API would ensure that any TCRP-compliant PCD/CID could be inter- changed without any affect on the system. Since the inception of this project, technology and industry requirements have changed and the need for the API has diminished. The transit industry is moving from the PCD model toward the CID model, where the business logic is integrated in the device. The CID today is capable of higher processing power and becoming a central component of fare collection device (e.g., fare- gates and TVMs), thus a generalized programming strategy seems more inapplicable than it did at the outset of this project and the API itself may not be the most efficient mechanism moving forward; however, it may prove of great value in the incremental modernization of legacy sys- tems or early proprietary smartcard implementations. 90 Smart Card Interoperability Issues for the Transit Industry
Transit must compel the use of standards as a part of all future procurement efforts to foster the interoperability of smartcard-based AFC systems. Anything short of full compliance to ISO/IEC 14443 and ISO/IEC 7816-4 should no longer be acceptable for transit applications. New and emerging AFC programs must accept and embrace an agreed-on standard data format defin- ing the data elements to be held on the smartcard. The RIS or UTFS are flexible systems ideally suited for this use. If transit agencies collectively resolve to make using these standards a high pri- ority in system development and procurement projects, the cause of smartcard interoperability in transit AFC systems will be greatly advanced. Conclusions 91
