National Academies Press: OpenBook

Smartcard Interoperability Issues for the Transit Industry (2006)

Chapter: Chapter 4 - Findings of Key Information to be Exchanged Between Agencies

« Previous: Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs
Page 51
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 51
Page 52
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 52
Page 53
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 53
Page 54
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 54
Page 55
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 55
Page 56
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 56
Page 57
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 57
Page 58
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 58
Page 59
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 59
Page 60
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 60
Page 61
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 61
Page 62
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 62
Page 63
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 63
Page 64
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 64
Page 65
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 65
Page 66
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 66
Page 67
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 67
Page 68
Suggested Citation:"Chapter 4 - Findings of Key Information to be Exchanged Between Agencies." National Academies of Sciences, Engineering, and Medicine. 2006. Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press. doi: 10.17226/14012.
×
Page 68

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.

This chapter identifies the key information to be exchanged between public agencies in order to implement an interoperable smartcard-based fare payment system. Using the Interoperabil- ity Model introduced in the Introduction, the subsequent research reviews and analyzes relevant technology standards and specifications and outlines the essential data elements required for two or more smartcard payment systems to exchange data to enable financial settlement for rides between different agencies. The culmination of the policies established between participating agencies are the business rules embedded in the terminals (smartcard read-write devices). As discussed in the Introduction, the business rules allow the proper fare to be deducted from the card and the associated transaction record to be generated and transferred to higher levels in the fare payment system clearinghouse. This chapter identifies the minimum data elements that will be used to generate the informa- tion to be exchanged between the card and card read-writer (terminal), and transferred to the clearinghouse for processing. This chapter consists of the following sections: • Industry Interoperability Analysis—Identifies available standards and specifications devel- oped to address interoperability; • Description of Required Data Elements—Identifies and describes the data elements required for interoperability; and • Gap Analysis—Discusses the differences between the available standards and specifications and the required data elements. 4.1 Industry Interoperability Analysis A detailed literature review of relevant documents was conducted to identify standards and specifications that address interoperability. These standards and specifications have been devel- oped with the same intention as this research effort. In order to conduct the gap analysis, it is important to define the difference between a standard and a specification: • Standards are maintained by nationally or internationally recognized governance bodies such as the American National Standards Institute (ANSI), the Institute of Electrical and Electron- ics Engineers (IEEE), or the International Organization for Standardization (ISO), or by an individual organization such as the American Public Transportation Association (APTA) or Europay, Mastercard, or Visa (EMV). • Specifications address industry or very specific user needs that usually augment a standard. The documents reviewed include specifications and standards developed both in the United States and internationally. Particular focus was given to technology, data, and control standards, and interface specifications from the smartcard and transit industries that attempt to address the 51 C H A P T E R 4 Findings of Key Information to be Exchanged Between Agencies

issue of interoperability. Table 11 lists documents reviewed contributing to interoperability, describes the organizations promulgating the standards or specifications, and describes the scope. Table 12 lists additional literature, potentially related to interoperability. 4.2 Description of Required Data Elements This section discusses the data required to complete a fare payment transaction. The infor- mation exchange required for an interoperable farecollection system is a limited subset of the informational capabilities of these systems. The results of the survey described in Chapter 2 val- idate that interoperability can be accomplished by defining the following four critical layers: • Physical Layer-Includes the form factor of the card itself (particularly relevant for dual inter- face [contact/contactless] card deployments), electrical and radio frequency characteristics, and basic communications and transmission characteristics for Type A and Type B cards; • Data Layer-Defines the essential data elements for the card, the reader, and the back-office system; • Application Layer-Includes the card file structure (“card application”) as well as how data on the card are stored and accessed; and • Security Layer-Includes overall security approach (symmetric or asymmetric) and key man- agement throughout the system. Figure 9 illustrates the critical layers mapped against the minimal data elements. This section of the report addresses each layer, focusing on what is required for interoperability. 4.2.1 Physical Layer At the most basic level, before any information can be exchanged, there must be a physical interface that supports communication. The starting point for this commonality is the ISO, which created standard definitions for communication protocol for smartcards. Smartcards can be contact (i.e., the interface of the card must touch the reader), contactless (i.e., the reader cre- ates a radio field to activate and communicate with the card), or both. ISO 14443 defines the stan- dards for contactless smartcards, and ISO 7816 defines the standards for contact smartcards. Given that ISO 14443 focuses on standardizing aspects of the communication channel between a contactless card and a reader, the next level of commonality focuses on how an appli- cation would interact within the communication channel. The obvious selection for standardiz- ing application interaction would be ISO 7816 Part 4 for application commands. These application commands, normally referred to as APDUs, are an application-based protocol that can be used within the ISO 14443-established communication channel. Although ISO 7816 Part 4 defines the template for each of these APDU commands, the precise implementation of these commands and their specific command options must be defined to ensure interoperability. Agencies implementing disparate options will have difficulty communicating properly. However, supplier interoperability that enables multiple suppliers to supply equipment into the system requires definition at the physical level. Because ISO 14443 and ISO 7816 exist as recognized international standards, they are the logical common denominator for the physical elements. The key information required to ensure interoperability within the physical element are quite simple from a system perspective. The interoperability of fare media requires the exchange of information in the following areas: • Fare media communication protocol and • Application communication protocol 52 Smartcard Interoperability Issues for the Transit Industry

Findings of Key Inform ation to be Exchanged Betw een Agencies 53 Table 11. Description of primary references. (continued on next page) Organization Description Calypso Specification for Contactless Smart Cards and Card Readers The Calypso standard is a privately owned European licensable specification that describes the transaction between a contactless card and card reader. The specification offers a standardized approach that is supplier independent and provides the following benefits to transit operators: • Multi-modal (management of different interconnected transit systems) • Interoperable (enables sharing between different transit operators) • Multi-application (supports other card applications beyond transit ticketing) Calypso is also available to all industrial partners (card manufacturers, chip manufacturers, systems integrators, etc.) through a license agreement. This facilitates open development according to the Calypso standards. CEN ENV 1545 1545-1–Codification of data elements for public transport 1545-2–ID Card systems 1545-3–Tachograph-related data elements 1545-4–Driving license-related data elements 1545-5–Freight ID-related data elements 1545-6–Vehicle-related data elements CWA FINREAD Parts 1–8 CWA13987: Smart Card Systems: Interoperable Citizen Services: User-Related Information Part 1–Definition of User-Related Information Part 2–Implementation Guidelines Part 3–Guidelines for Creating, Operating, and Maintaining an Interoperable Card Community CEN/ISS Application Interface for Smartcards Used as Secure Signature Creation Devices, Part 1–Basic Requirements The European Committee for Standardization (CEN) is the European counterpart to the ISO, charged with planning, developing, and adopting European standards. The organization develops and maintains standards for over 16 broad areas of business. A sample of the CEN specifications are listed below: • CEN ENV 1545 addresses public transit ticketing data elements. • CEN Workshop Agreement (CWA) FINREAD is a set of technical specifications for a secure card reader connected to a PC to carry out, essentially but not exclusively, payment and global financial as well as e-commerce transactions on the Internet. • CEN Workshop Agreement (CWA) 13987 addresses user-related information for interoperable citizen services within smart card systems EMV 2000 Integrated Circuit Specification for Payment Systems, Version 4.0 EMV 2000 is an integrated circuit specification that ensures single terminal and card approval processes are developed at a level that will allow cross payment system interoperability through compliance with the “EMV” specifications (Europay Mastercard Visa Integrated Chip Card Standard). Document Title

54 Sm artcard Interoperability Issues for the Transit Industry Table 11. (Continued). Organization Description Global Platform Global Platform Card Specification, Version 2.1.1 Global Platform is an international smartcard association, responsible for creating and advancing interoperable technical specifications for smartcards, acceptance devices, and systems infrastructure. Formed in 1999, it is made up of a cross-industry member base comprising over 50 organizations. ISO ISO 7816 The International Organization for Standardization (ISO) is a 148-member country body charged with developing worldwide standards. ISO standards include ISO 14443 (parts 1-4), the standard that governs contactless smartcards, and ISO 7816 (parts 1-6), the standard that describes integrated circuit cards with contacts. ITSO Interoperable Public Transport Specification The International Ticketing SmartCard Organization (ITSO), founded in 1998, is a collaboration between various UK passenger transport authorities addressing the lack of suitable standards for interoperable smart card ticketing. ITSO was formed to build and maintain a specification for secure end-to-end interoperable ticketing transactions, utilizing relevant ISO and emerging CEN standards. MTC San Francisco Bay Area TransLink Project– Conformed Statement of Work, June 1999 The Metropolitan Transportation Commission (MTC) is the transportation planning, coordinating, and financing agency for the nine-county San Francisco Bay Area. MTC is responsible for administering the Bay Area’s TransLink smartcard project. A data message and format specification owned by MTC and participating operators defines data elements in the system. PANYNJ Regional Interoperability Standard (RIS) The Port Authority of New York and New Jersey (PANYNJ) Regional Interoperability Standard (RIS) identifies and defines the required operations and data elements between a contactless smartcard and card interface device. RKF RKF Travel Card Travel Card Specification Requirement Specification, Version 2.00 Technical Requirements Specification Implementation Specification Details Type 1, Version 2.00 Implementation Guide RKF Type CL-1 The Resekortisforeningen I Norden (RKF) is an association of transit operators in Denmark, Norway, and Sweden. The purpose of the RKF travel card is to facilitate one travel card within the public transport in the Nordic countries. The RKF Travel Card Technical Requirement Specification identifies requirements for selected IC-card technologies for the RKF travel card. WMATA Washington, DC SmarTrip Regional Customer Service Center Contract Book and Draft SmarTrip Interoperability Regional Specification The Washington Metropolitan Area Transit Authority (WMATA) is developing the SmarTrip Interoperability Regional Specification (SIRS) that defines the interface between agency equipment and the third-party service provider of the SmarTrip Regional Customer Service Center (RCSC). Document Title ISO 14443

Findings of Key Information to be Exchanged Between Agencies 55 Organization American Pubic Transit Association (APTA) Business Issues Guidelines for Regional Transportation Payment Systems and Clearinghouse (draft) Work Package #4 Functional Interface Description (draft) Applied Security Technologies Security Standards for Smartcards Smartcard Lifecycle– Security Guidelines Government Data Standards Catalogue Volume 1–General Principles Volume 2–Data Standards The e-Government Interoperability Framework (e-GIF) mandates the adoption of XML and the development of XML schemas as the basis of the government interoperability and integration strategy. In addition, the Government Data Standards (GDS) catalogue specifies the rationale, approach for using XML schema, and other interchange processes. e-Government Interoperability Framework (e-GIF) Part 1–Framework Part 2–Technical Policies and Specifications Version 5.1 eEurope Smart Card (eESC) Open SmartCard Infrastructure for Europe Volume 2–Contactless Technology Volume 9–Referenced Standards e-Europe Smart Cards (eESC) is an initiative developed by the European Commission to further the development of smart cards across Europe and promote the following objectives: • Interoperability • Multi-application cards • Secure transactions • User acceptance • Accessibility National Institute of Science and Technology (NIST) Government SmartCard Interoperability Specification, Version 2.1 Smart Card Alliance Transit and Retail Payment: Opportunities for Collaboration and Convergence Report 10–Fare Policies, Structures, and Technologies Transit Cooperative Research Program (TCRP) Report 32–Multipurpose Transit Payment Media Developing a Recommended Standard for Automated Fare Collection of Transit Multipurpose Fare Media: Developments and Issues TCRP–Research Results Digest Coordinated Intermodal Transportation Pricing and Funding Strategies Document Title Table 12. Additional literature reviewed. 4.2.1.1 Fare Media Communication Protocol ISO 14443 was established as the standard from which contactless smartcards establish a communication protocol with con- tactless smartcard readers. Within ISO 14443, there are four parts: • Part 1: Physical Characteristics-Defines the physical and electrical specification for smartcards in a standard credit card format. • Part 2: RF Power and Signal Interface-Defines two types of RF modulation scheme known as Type A and Type B. • Part 3: Initialization and Anti-collision-Defines the initial communications when the smartcard is brought into the RF field of the smartcard reader. Also defines the anti-collision scheme to allow multiple cards to enter the field simultaneously—

determining which card to select for communication. Type A uses bit-wise anti-collision, Type B uses slotted anti-collision. • Part 4: Transmission Protocol-Defines the communication protocol and framing for data exchange. Because of its transparency, it can encapsulate any application command, which per- mits a variety of functionality and flexibility. 4.2.1.2 Application Command Protocol ISO 7816 was established as the standard from which contact readers and smartcards were to enable application interaction. Although ISO 7816 establishes the framework for application commands, the data and parameters contained in each of these ISO commands can be exclusive to an application and are not defined by ISO. One objective of this report is to identify the sub- set of ISO 7816 commands to use for a transit application and then define the data and param- eters that will be contained within these commands for transit interoperability. In the ISO 7816 standard, there are six parts, of which only Part 4 applies to this discussion. In Part 4 of ISO 7816, the following subset of application-related commands is provided: • SELECT FILE—Selects files, directories, or applications on the smartcard file system for read and update operations. • READ BINARY—Retrieves data from a transparent (non-record-based) file on the smartcard. • WRITE BINARY—Writes data to a transparent (non-record-based) file on the smartcard. • UPDATE BINARY—Modifies existing data within a transparent (non-record-based) file on the smartcard. • READ RECORD—Retrieves data from a record-based (non-transparent-based) file on the smartcard. • WRITE RECORD—Writes data to a record-based (non-transparent-based) file on the smartcard. 56 Smartcard Interoperability Issues for the Transit Industry Card Datar t ƒ ¤Card Identification Number ƒ ¤Card Issuer Identification ƒ ¤Patron Profile Code ƒ ¤Card Validity Period r I tific ti r r Iss r I tific ti tr r fil rd alidity ri d Product Datar ct ata ƒ ¤Product Identification Number ƒ ¤Product Validity Period ƒ ¤Electronic Purse r ct I tific ti r r ct li ity ri l ctr ic rs Journey Data 1r t 1 ƒ ¤Agency Identification Number 1 ƒ ¤Date & Time of journey event 1 ƒ ¤Entry and Exit location of journey 1 ƒ ¤Route from number 1 cy I tific ti r 1 t i f j r y v t 1 try xit l c ti f j r y 1 t fr r 1 Journey DataNr t ƒ ¤Identification number N Information Exchange Layers I f r ti r Physical Layeri l r Data Layert r Application Layerli ti r Security Layerrit r ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ ❒ number N Figure 9. Critical interoperability elements matrix.

• UPDATE RECORD—Modifies existing data within a record-based (non-transparent-based) file on the smartcard. • EXTERNAL AUTHENTICATE—Used with GET CHALLENGE to authenticate the terminal to the smartcard. • INTERNAL AUTHENTICATE —Used to authenticate the smartcard to the reader device. • GET CHALLENGE—Used with the EXTERNAL AUTHENTICATE to authenticate the ter- minal to the smartcard. Despite the existence of the ISO 7816 standard, some suppliers have implemented smartcard application commands that use the distinct advantages of their own specific platforms and thus offer an advantage to their particular product lines and barriers to entry for other suppliers. This defeats the purpose of interoperability between suppliers. Therefore, it is critical to require and then examine the card application requirements that will lead to the definition of the application commands in a manner that complies with the ISO standard. 4.2.2 Data Layer The key essential data elements of a regionally interoperable system include information for front-end components (e.g., the smartcard and the smartcard reader) as well as infor- mation for back-office systems (e.g., the data collection equipment). Starting with a super- set of all data from the four primary reference interoperability specifications (i.e., RIS, ITSO, CEN, and RKF) a conceptual model was created. All data elements were tested against the working definition of interoperability. This information is summarized in the following two questions: • Does this data element enable multiple transit agencies to offer a common smartcard appli- cation for transit-fare payment? • Would the lack of this data element prevent multiple transit agencies from offering a common smartcard application for transit-fare payment? If the answer to both of these questions was yes, the data element was considered essential. This information is categorized as follows: • Cardholder information (information unique to the card itself); • Fare information (information regarding a particular fare product); and • Transaction information (information about the particular trip). During the development phase of this project, additional essential data elements may be iden- tified. Such discoveries are expected in iterative prototype development, and we will update this paper with these elements should it be necessary. Table 13 depicts the data fields defined in the four primary standard specifications (RIS, ITSO, CEN, and RKF) for each of the three categories (card/holder information, fare infor- mation, and transaction information). Each of these standards has many other types of data beyond these three categories; however, only the data for the three categories relevant to data element interoperability have been included. Table 13 does not suggest that ALL of the included data fields in each specification in the three categories are required. In fact, the oppo- site is true, and the subset of fields that must be standardized for minimal interoperability are identified following this table. Table 14 defines the data elements listed in Table 13 based on the RIS. Of the data elements listed, most are not required to be exchanged between agencies for interoperability to work. Many elements are exchanged between the agencies for business Findings of Key Information to be Exchanged Between Agencies 57

reasons or to accommodate policies such as allowing the agencies to gather information to bet- ter run their businesses. The following are the essential elements that need to be exchanged for interoperability: • Card/Holder Information is primarily information associated with an individual card and cardholder. This information is required in transaction data to allow the back-office systems to validate, process, and deliver the necessary data for clearing and settlement between agen- cies. It also allows the reader to validate the transaction and perform the service (allow entrance or exit) to the patron. The essential card/holder data elements are – Card Identification Number—Uniquely identifies the card within the interoperable sys- tem. One purpose of the card ID is to ensure the integrity of a card’s total value in the system. – Card Issuer Identification Number—Uniquely identifies the issuer of the card within the sys- tem. The card issuer ID is required in order to perform inter-system funds settlement. 58 Smartcard Interoperability Issues for the Transit Industry CARD/HOLDER INFORMATION RIS v. 1.0 Card/Transit Information PICCTestUse OpsMaintenanceUse CountryID PICCValidityPeriod RegionID IssuerID TransitExpirationDate EndDate NA KeySetIdentifier ManufactureID TransitPICCID IssuingDeviceID DeviceID Base data type of SerialNumbers Base type of Device Holder Information ProfileBirthDate DateTime ProfileStartDate DateTime ProfileExpireDate DateTime ProfileLanguage Language UserRegistered ProfileCode DiscountLevel PassengerClass DiscountCounter DiscountLevel DiscountType PassengerType DepositPaid PICCHolderGender PICCHolderDescription CardHolderDescription BirthName Forename Surname HolderName Employee CompanyName Birthplace NA ITSO v. 1.2 NA NA NA NA ValidUntil (VUT) ITSOOperatorsIDNumber ITSOShellExpiryDate KeyVersionCode MID or CSN IssuerIdentificationNumber ISAMID DateOfBirth NA ExpiryDate Language NA CustomerProfile ShellDeposit IDFlags NA PersonID CEN v. 1.0 NA NA NA NA NA NA NA NA NA NA RKF v. 2.0 CardValidityEndDate Country ID ApplicationIssuerID CardProvider Base data type of MACKeyID MACKeyIdentifier ManufacturerData CardSerialNumber Base data type of BirthDate Base data type of StartDate Base data type of EndDate Base data type of LanguageID DialoguePreferences NA NA NA NA NA EntitlementType PassengerType Deposit UserData Table 13. All data fields available in selected categories.

– Patron Profile Code—Represents the discount allowance, if any, for the individual bearing the card. Without the patron profile code, discounts for special fares such as for those with disabilities or for students could not be supported. • Fare Information describes the fare product being used. It is required for the fare equipment and the back-office systems to validate and process fare payment transactions. Fare informa- tion, at a minimum, consists of the following: – Fare Product Identification Number—Uniquely identifies the logical fare product used in the transaction to enable appropriate clearing and settlement. Even in a system where only the e-purse is used as the form of payment, the e-purse must be uniquely identified. – Product Validity Period—Identifies the time and/or date period that the product is valid. – Transaction Value—Identifies the fare amount if a stored value e-purse is to be used. • Transaction Information is a concatenation of card, fare, and specific transaction information. It is normally referred to as the transaction data for a specific patron’s journey. This is the pri- mary information used by back-office systems to validate and process fare payment transac- tions for establishing end-of-day net-settlement positions. When the day’s transactions are processed and net-settlement positions established, funds will either be sent to or received Findings of Key Information to be Exchanged Between Agencies 59 Table 13. (Continued). (continued on next page) FARE INFORMATION RIS v. 1.0 ITSO v. 1.2 Stored Value Information AutoSubscribe ValueExpires RemValueSign RemValue ExpRecurDate RecurringAutoloadType AutoThreshold SVThreshloadLoadAmount SVRecurringLoadAmount CurrencyCode CIDTransactionNumber Number CIDID DeviceID Base data type of SerialNumbers Device Pass/Transfer Information AutoloadSubscribed PaymentType LocationEncodingType RemTripRidesTransfers ExpDate EndDate Base data type of EndTime Base data type of Base data type of DateTime ExpTime DateTime RenewedInAdvance AutoThreshold ProdID LocationEncoding CIDTransactionNumber Number CIDID DeviceID Base data type of SerialNumbers Device ValueATPAFlags EndDate NA NA NA NA NA NA Threshold TopUpAmount NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA PlaceNA DeviceTransactionNA NA ThresholdAmount NA AuthorizedProduct ContractSerial Number NA NA Balance Base data type of Base data type of NA Date Value AutoloadLoad Status NA AutoloadValue NA AutoloadValue NA CurencyUnit NA Device Transaction EndDate CEN v. 1.0 RKF v. 2.0 Value ValueCurrencyCode TransactionSequenceNumber SAMID SAMID TYP9Flags AmountPaidMethodOfPayment CountUsesAvailable ExpiryDate TransactionType ValidFrom / ValidTo TransactionSequenceNumber

from partner agencies, as determined by these settlement positions. Transaction information, at a minimum, consists of five data elements presented above and three additional data ele- ments described below: – Agency Identification Number—Uniquely identifies the agency that provided the service for this transaction. The agency ID is necessary for the proper settlement of funds. – Date and Time of the specific transaction—Date and time information is required to uniquely identify transactions for reporting and troubleshooting. – Entry and/or Exit Location of the patron—Entry and/or exit information is required for fare calculation in distance-based or zone-based fare structures. 4.2.3 Application Layer A standard “application data element”definition does not exist today in an open, accessible form in the transit industry. However, from an information exchange perspective, the application layer for a smartcard and reader is primarily the software and/or data structure on a smartcard and reader that allows for the exchange and capture of data that will be used for clearing and settlement. The captured data are ultimately transferred from the reader through the agency’s system hierarchy to another system (partner agency or central system) for clearing and settling that transaction. 60 Smartcard Interoperability Issues for the Transit Industry Table 13. (Continued). TRANSACTION INFORMATION RIS v. 1.0 ITSO v. 1.2 CEN v. 1.0 RKF v. 2.0 Add Value History Information LoadType NA NA ValueExpires NA NA AgencyID ProductOwner NA Date Date Time Base datatype of DateTime Time DataTimeStamp NA Base datatype of DateTime RecurringAutoloadType NA NA SVTransaction NA NA SVTransactionNegative NA NA RegionID NA NA LocationID LocationData Place CIDTransactionNumber ReceiptFlag TransactionNumber CIDID SAMID SAMID Base datatype of DeviceID Base datatype of SerialNumbers Device Transaction History Information TransactionType TransactionType TransactionType NA NA In_Out NA NA ProdID_or_RegionID ProductID ContractSerialNumber AgencyID ServiceOperator Basetype of CardProvider LocationID LocationData Place DateStamp DateTimeStamp Date Base datatype of DateTime TimeStamp DateTimeStamp Time Base datatype of DateTime TransactionLinked NA NA TransferStartTime NA NA NA NA NA Time Base datatype of DateTime TransValue FareDeducted MoneyAmount TransValueSign NA NA TransferCode NA NA Special NA NA ValueAPTAFlags Value EndDate IssuerID DateTimeStamp NA NA NA NA NA NA TransactionSequenceNumber ActualAmount

The need to access the application data elements in an interoperable equipment independent fashion is another objective of this research project. The objective is to develop an implementa- tion of a transit application using a standard API to serve as a proof of concept of interoperabil- ity between the smartcard readers and the transit application software. The application layer should use ISO/IEC 7816-4 to address the need for a standard approach. Chapter 7 contains the details of the standard approach. 4.2.4 Security Layer Security for interoperable fare collection systems should be implemented at multiple lay- ers of the overall system. Security may be as simple as implementing a security mechanism Findings of Key Information to be Exchanged Between Agencies 61 Table 14. Definition of RIS data elements. (continued on next page) Card/Transit Info Description Field Indicates the test or revenue PICC OpsMaintenanceUse CountryID Numeric value that identifies the country in which this PICC was issued PICCValidityPeriod Card validity period in years RegionID Numeric value that identifies the metropolitan region of a country in which this PICC was issued and intended for the majority of its use. There are 256 possible regions that can be defined on a PICC within each country IssuerID Designates the card and ticketing application of issuing nation, state/region, or agency TransitExpirationDate Represents the transit application’s expiration date KeySetIdentifier Represents a logical pointer to a key set that is contained on a PICC to support the transit application. (Note: The actual physical location of the keys, as well as access to the keys, is protected and managed by the specific PICC’s operating system) ManufactureID Represents the manufacturer ID code TransitPICCID Represents the unique printed serial number assigned by the PICC manufacturer based upon instructions of the ordering regional clearinghouse IssuingDeviceID Indicates the PICC issuing/encoding device containing the CID ID ProfileBirthDate Represents birth date of the customer to assist with identifying the customer’s eligibility for discounts and recording demographics (Format ddmmyy) ProfileStartDate Provides the date this profile becomes valid for use (Format ddmmyy) ProfileExpireDated Provides the expiration date of this customer profile and associated discount if applicable (Format ddmmyy) ProfileLanguage Enables an automatic language of preference to display on smart PICC devices [e.g., PCD (reader), faregate, vending machine, touch-pads at non-transit outlets, etc.]. Different regions can assign other languages, but if a customer travels to a different region and the language code is not supported in the standard, a patron can always select English as a default Indicates the revenue or operations/maintenance

between the card and reader or implementing multiple security mechanisms in parallel at each layer in the fare payment system architecture. These mechanisms may include one or a combination of the following: • Security on each component of the system; • Security between each component of the system (i.e., card and reader); and • Security extending throughout the system. Security protections may be implemented at the component, application, and network per- spective. The most common areas of protection are • Ensuring that the fare products on the smartcard are not changed by an unauthorized entity, • Authenticating the use of a card and application within the system, and 62 Smartcard Interoperability Issues for the Transit Industry Table 14. (Continued). Card Holder Information Field Description ProfileBirthDate Represents the birth date of the customer to assist with identifying the customer’s eligibility for discounts and recording demographics (Format ddmmyy) ProfileStartDate Provides the date this profile becomes valid for use (Format ddmmyy) ProfileExpireDate Provides the expiration date of this customer profile and associated discount if applicable (Format ddmmyy) ProfileLanguage Enables an automatic language of preference to display on smart PICC devices [e.g., PCD (reader), faregate, vending machine, touch-pads at non-transit outlets, etc.]. Different regions can assign other languages, but if a customer travels to a different region and the language code is not supported in the standard, a patron can always select English as a default UserRegistered Indicates that the cardholder has registered prior to card issue ProfileCode Numeric code that represents a patron’s specific discount and/or demographic profile if appropriate and available. Although standard profile codes and demographic codes should be recognized by different participating regions for consistency, the criteria defining the profiles may not be consistent between regions and at times may be region specific. As such, profile codes should be processed according to intra- regional and inter-regional policies, or default to adult full fare DepositPaid Indicates that the deposit has been paid PICCHolderGender PICC holder gender description PICCHolderDescription Provided for future assignment at the national, state, or regional level CardHolderDescription Provided for additional PICC holder description such as full name, weight, or other PICC holder required information to gain access to a site, facility, transit system, or building AutoSubscribe Represents the autoload subscription indicator for this load ValueExpires Indicates that this is a Single Load SV product that expires on the date indicated by ExpRecurDate RemValueSign Value designates a positive or negative balance RemValue Provides remaining currency value ExpRecurDate Provides the date that this product expires or last recurring load date (Format ddmmyy) RecurringAutoloadType Used to differentiate SV Recurring Autoload types

• Ensuring that the transaction data are unaltered when transferring within an agency and between agencies. The appropriate security mechanisms will depend on several factors. At a minimum, these factors are • Assessment of the functionalities and capabilities of a specific system element and its components, • A risk and risk mitigation cost model for the element, • A risk assessment and threat analysis performed by the region and its agencies of the specific system element and its relevance upon the overall system, and • The complexity of encryption algorithms and key management structure. Findings of Key Information to be Exchanged Between Agencies 63 Table 14. (Continued). (continued on next page) Stored Value Information Field Description AutoloadThreshold Indicates when the T-Purse will be threshold-loaded and a funds charge transaction will be sent to the customer’s bank. SVThreshholdLoadAmount Indicates value to add for a threshold autoload SVRecurringLoadAmount Indicates value to add for a recurring autoload CurrencyCode Provides the currency of the value of this product. The currency code is considered fixed and permanent where indicated and consistent for all regions that recognize and adhere to this transit smart PICC Regional Interoperability Standard. The fare collection system conforming to these specifications will recognize the defined currency and deduct the equivalent of that currency from the T-purse CIDTransactionNumber Represents the LSB of the Event Identifier assigned by the issuing machine’s CID CIDID Represents the issuing machine CIDID, used to identify the encoding equipment AutoSubscribe Represents the autoload subscription indicator for this load ValueExpires Indicates that this is a Single Load SV product that expires on the date indicated by ExpRecurDate RemValueSign Value designates a positive or negative balance RemValue Provides remaining currency value ExpRecurDate Provides the date that this product expires or last recurring load date (Format ddmmyy) AutoSubscribe Represents the autoload subscription indicator for this load ValueExpires Indicates that this is a Single Load SV product that expires on the date indicated by ExpRecurDate RemValueSign Value designates a positive or negative balance RemValue Provides remaining currency value AutoloadSubscribed Provides the autoload type PaymentType Represents the payment code. Indicates the manner in which revenue is collected or returned LocationEncodingType Describes the type of location validity encoding depicted by LocationEncoding Field RemTripRidesTransfers Indicates the number of remaining transit trips/rides/ transfers (maximum number of trips = 255)

Based on the research team’s experience, technology and system suppliers make products as secure as the procuring agency specifies them to be. For any IT system, a threat and vulnerability analysis is the first step in determining the security features required to mitigate the security risk. The objective of this discussion is to define security and provide a framework for establishing a smartcard fare payment system security policy that meets system needs cost effectively.As discussed, a smartcard fare payment is an automated data-collection system, thus an information systems secu- rity framework applies. The Information Security Handbook defines security as three components: • Confidentiality of information is ensuring that any information exchanged between two or more parties remains private to the authorized entities. 64 Smartcard Interoperability Issues for the Transit Industry Table 14. (Continued). Pass/Transfer Info Field Description ExpDate Indicates the expiry date for the product ExpTime Indicates the time this product expires. Time in minutes past midnight RenewedInAdvance Indicates that this product has been renewed in advance of its expiry date AutoThreshold (N/A for Transfers) Code representing the time in advance that a threshold load will occur ProdID Product code specifically owned by the transit agency of use. The code is defined by the transit agency within the region and posted to the PICC when the customer buys the product either at any add-value vending machine, ticket booth, or other device in the future. There are 255 possible product codes for each Agency of use. These codes are not fixed and permanent and can be changed by the owning transit agency within the region via tables/fare rules. The code is captured by the faregate reader and used for accounting, demographic reporting, and other downstream fare collection system processing LocationEncoding Represents the valid locations indicator CIDTransactionNumber Represents the LSB of Event Identifier assigned by the issuing machine’s CID CIDID Indicates the issuing machine CIDID used to identify the Encoding equipment LoadType Represents the payment type code. Indicates how revenue was collected or returned ValueExpires Represents the expiry indicator. Indicates that this is the load of a Single Load SV product AgencyID For agency-specific SV purses, this is set to the relevant Agency ID The Agency ID for the Regional T-Purse is set to 0 Date Indicates the purchase date (Format ddmmyy) Time Indicates the purchase time in minutes past midnight RecurringAutoloadType Used to differentiate SV Recurring Autoload types SVTransaction Indicates the value added or deducted inclusive of any bonus for cash, bank card, directed autoload, or threshold autoload transactions SVTransactionNegative 0 = Positive, 1 = Negative RegionID Provides the value of the regional ID LocationID Represents the unique location of the device within the regional system.

• Integrity of information is to guarantee that changes to information due to entering and edit- ing errors, faulty data transmission, and unauthorized modifications are detected and if pos- sible corrected. • Availability of information is to balance availability to those allowed access against information- protection measures. Figure 10 identifies the most common breaches in security and provides an overview of the associated effects. To determine the level of security required for a transit smartcard fare pay- ment system, the methodology presented in Figure 11 provides a systematic approach to assess- ing the threats and associated risks. The methodology consists of the following key activities: • Analyzing business processes to provide the basis for identifying weak links and vulnerabili- ties to fraud and exploitation; • Assessing threats to identify how the smartcard fare payment system may be misused, which depends on card use. The most common forms of misuse are – Counterfeiting—Creation of a duplicate card, – Misrepresentation—Using someone else’s access authorization or card, – Alteration—Unauthorized modification of data, and – Collusion—Circumventing procedures and technology through illegal arrangements; Findings of Key Information to be Exchanged Between Agencies 65 Table 14. (Continued). Add Value History Info Field Description CIDTransactionNumber Represents the LSB of the event identifier assigned by the issuing machine’s CID CIDID Represents the issuing machine CIDID used to identify the encoding equipment TransactionType Denotes the type of transaction In/Out Indicates in or out of “paid area” for closed systems ProdID Or RegionID Provides the product ID for in-region product use or region ID for out-of- region T-Purse use AgencyID Represents the service providing agency/agencies for the associated product LocationID Represents the unique location of the device within the regional system DateStamp Indicates the date of transaction (Format: ddmmyy) TimeStamp Indicates the time of transaction. Time in minutes past midnight when transaction occurred (Format: mmm [0–1339]) TransactionLinked Provides linkage to previous transaction TransferStartTime Indicates the transfer start time for the journey and used to determine transfer validity. Time in minutes past midnight. Set to Time of Use if not applicable TransValue Indicates the value of the SV transaction, where applicable TransValueSign Value designates a positive or negative transaction value TransferCode Provides the transfer service code Special Indicates the bits reserved for agency-specific usage

66 Smartcard Interoperability Issues for the Transit Industry Fraud Theft Virus Attack Accidental Damage Sabotage Communications Failure Wiretapping Insertion of Data Emanations Interception Operating System Alteration Software Failure Hardware Failure Strikes Privacy Violation Availability Confidentiality Integrity Dismissal Prison Competition Loss of Customer Insolvency Loss of Credibility Embarrassment Loss of Profit Data Figure 10. Data security breaches and impacts. • Assessing technology to identify inherent vulnerabilities that present system risks. According to the orange book, vulnerabilities include – Modification, – Unavailability, – Data corruption, and – Data exposure; • Analyzing risks and developing options to provide the basis for conducting the cost-benefit analysis. The objective of this activity is to develop a set of logically sequenced metrics that identify countermeasures and risk mitigation strategies as follows: – Threat vulnerability and countermeasures and – Security versus risk and mitigation measures; and • Conducting cost-benefit analysis to determine the most cost-effective solution for the per- ceived risks Security in a smartcard fare payment system is achieved by combining the following three basic elements: • Encryption—This is the transformation of data that is only readable through the use of a secret key.

• 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. Findings of Key Information to be Exchanged Between Agencies 67 Figure 11. Threat and risk assessment. DATA • Market survey • Internet • Newspaper articles • Technical and scientific journals Technology Assessment Risk Analysis & Recommendation Threat Assessment Business Process Analysis Cost Benefit Analysis

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. 68 Smartcard Interoperability Issues for the Transit Industry

Next: Chapter 5 - Findings of Data Flows Between Agencies »
Smartcard Interoperability Issues for the Transit Industry Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB Transit Cooperative Research Program (TCRP) Report 115: Smartcard Interoperability Issues for the Transit Industry explores interoperability; identifies information needed by public agencies to implement smartcard payment systems interoperability; examines the necessary information flows; and outlines a set of functions needed for a standard public domain application programming interface (API) that may be used in the development of a uniform application protocol data unit (APDU). The report also includes a prototype for an API and an APDU that demonstrates this “proof of concept” for International Organization for Standardization-compliant Type A and Type B cards.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!