National Academy of Sciences | 150 Year Anniversary

Questions? Call 800-624-6242

| Items in cart [0]

The National Academies Press

Rights & Permissions

topleft topright

TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry (2007)
Transit Cooperative Research Program (TCRP)

Citation Manager

Transportation Research Board. "4.2.4 Security Layer." TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press, 2007.

Please select a format:

BibTeX EndNote RefMan


Page
61
bottomleft bottomright
Page
61
Front Matter (R1-R9)
Summary (1-2)
Chapter 1 - Introduction (3-3)
1.2 Elements of Fare Payment Interoperability (4-4)
1.3 Interoperability Across Regions (5-5)
1.4 Interoperability Beyond Transit (6-6)
1.5.1 Acceptance of Contactless Bank Cards (7-8)
1.5.3 Multiple Payment-Enabled Devices (9-9)
1.6 Hypothetical Examples - Interoperability Between WMATA and TransLink (10-10)
1.6.1 Information to Be Exchanged for Payment (11-12)
1.6.3 Process for Determining the Net-Settlement Position (13-13)
2.1 Management and Organizational Issues (14-14)
2.1.1 Establishing a Governing Body or Project Sponsor (15-16)
2.1.2 Identifying and Mitigating Operational Differences (17-17)
2.1.3 Establishing a Framework for Program Funding (18-18)
2.1.4 Creating a Rollout Schedule (19-19)
2.1.5 Developing a Contracting Strategy (20-21)
2.2.2 Funds Pool Management (22-22)
2.2.3 Financial Exposure and Risk Associated with Advanced Features (23-23)
2.3.2 New Processes (24-24)
2.4 Equipment Design Issues (25-25)
2.5.2 Supplier Behavior (26-26)
2.5.3 Supplier Compliance with Available Standards (27-27)
Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs (28-28)
3.1.1 SmarTrip (29-33)
3.1.2 TransLink (34-34)
3.1.3 Chicago Card (35-35)
3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project (36-36)
3.1.5 Go-To Card (37-37)
3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) (38-38)
3.1.7 Go Ventura (39-39)
3.1.8 Transit Access Pass (TAP) (40-40)
3.1.9 Compass (41-41)
3.1.10 Octopus (42-42)
3.1.11 EZ-Link (43-43)
3.1.12 Oyster (44-44)
3.2.1 Commonalities and Differences (45-46)
3.2.2 Current Trends and New Developments (47-47)
3.4.2 SmarTrip (48-48)
3.5 Summary (49-50)
4.1 Industry Interoperability Analysis (51-51)
4.2.1 Physical Layer (52-56)
4.2.2 Data Layer (57-59)
4.2.3 Application Layer (60-60)
4.2.4 Security Layer (61-66)
4.3 Gap Analysis (67-68)
5.1 Development of Conceptual Fare Payment System Architecture (69-69)
5.2 Identification of the Data Types (70-70)
5.3.2 Operation Data Flows (71-73)
6.1 Scope of the Data-Management Policy (74-74)
6.2.1 Data Location (75-75)
6.3 Identification of Stakeholders and Their Roles and Responsibilities (76-76)
6.4 Other RequirementsPrivacy (77-77)
6.5 Current Trends (78-78)
7.1 Use of Standard API in Proof of Concept (79-82)
7.2 Development of AFC Simulator (83-84)
7.3 Demonstration (85-85)
7.4 Conclusion (86-86)
Chapter 8 - Conclusions (87-91)
Appendix A - Set of Functionality for a Standard API (92-99)
Abbreviations used without definitions in TRB publications (100-100)

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 61
Findings of Key Information to be Exchanged Between Agencies 61 Table 14. Definition of RIS data elements. Card/Transit Info Field Description Indicates the test or revenue PICC OpsMaintenanceUse Indicates the revenue or operations/maintenance 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 (continued on next page) 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

OCR for page 62
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 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

OCR for page 63
Findings of Key Information to be Exchanged Between Agencies 63 Table 14. (Continued). 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) (continued on next page) · 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.

OCR for page 64
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 Code representing the time in advance that a threshold load will occur (N/A for Transfers) 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. 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.

OCR for page 65
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 · 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;

OCR for page 66
66 Smartcard Interoperability Issues for the Transit Industry Embarrassment Loss of Credibility Fraud Theft Insolvency Loss of Profit Privacy Virus Violation Attack Confidentiality Accidental Strikes Damage Hardware Failure Data Sabotage Integrity Availability Software Communications Failure Failure Operating Wiretapping Prison System Alteration Loss of Emanations Insertion of Customer Interception Data Dismissal Competition 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.