Specification for Interoperable Electronic Ticketing System
Short Description
Spec for Norway's RFID ticketing system, more secure than the recently-hacked Mifare Classic systems. See Bruce Schn...
Description
Handbook 206-3 Norwegian Public Roads Administration
Normative
Specification for Interoperable Electronic Ticketing System
June 10, 2005
2
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Preface Handbook 206 covers electronic ticketing and Interoperable Fare Management (IFM) systems. The first preliminary version of the handbook was issued in 1995 and was then followed by the official first version of Handbook 206 Electronic ticketing in 1998 (in Norwegian only). The development in the electronic ticketing domain requires an updating of the version from 1998 both from a technology point of view as well as from an interoperability point of view. Handbook 206 Part 1, Part 2 and Part 3 replace the previous 1998 version. Handbook 206 Part 1 describes electronic ticketing systems using a ticketing media where all information, e.g. customer data, products and logs are stored electronically. Hence, the Handbook 206 does not cover ticketing systems or equipment used for issuing traditional paper tickets. Part 2 covers recommendations as regards regional and inter-regional electronic ticketing systems and is based on the same principles as given in part 1 and 3. Part 3 covers technical requirements and guidelines that shall be used when purchasing and installing ticketing systems. This is to ensure that all new electronic ticketing systems can be interoperable and by this being an attractive alternative for the customers concerning the use of public transport. The handbook has been prepared based on a mandate given by the Ministry of Transport and communications and is financed by the Norwegian Public Roads Administration (NPRA). The main objective is that electronic ticketing systems shall be simplified and by this making it easier for the customer to use public transport. A very important part of the simplification process is establishing local, regional and national interoperability. Project leader for the Handbook 206 project has been Jacob Trondsen from NPRA. The work on the Handbook 206 has been done in cooperation with a project group with Robert Fjelltun Bøe from NPRA, Hanne Juul from Hordaland County Administration, Trond Myhre from Vestfold kollektivtrafikk (Vestfold Public Transport), Linda Lillestøl and Jan Christiansen from NSB (Norwegian State Railway), Lars Bjønnes from Mobitech, Jørn Hanssen from Oslo Sporveier (Oslo tram, bus and metro), Lilia Halsen Bidar and Stig Rønning from Q-Free Ticketing and Trond Foss from SINTEF. The target group for this part of the handbook will be personnel purchasing electronic ticketing systems as well as suppliers designing and implementing such systems. NPRA presuppose that ISO and CEN standards as well as the requirements and recommendations given in Handbook 3 shall be used in projects that are funded by authorities on national and regional level. Hence, NPRA recommends that the use of Handbook 206 shall be part of the contract between the authorities and the operators proving public transport services.
Norwegian Public Roads Administration Directorate of Public Roads June 10, 2004
3
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
4
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Table of content 1
BACKGROUND ...................................................................................................................... 8
2
SPECIFICATION OF THE NORTIC APPLICATION AND PRODUCT.................................... 9
2.1
NORTIC INTEROPERABLE PRODUCT ...................................................................................... 9
2.2
OVERALL REQUIREMENTS .................................................................................................... 10
2.3
ENTITIES ............................................................................................................................ 11
2.4
TRAVELCONTRACT LIFE CYCLE ............................................................................................ 13
2.5
TRAVELCONTRACT AND SECURITY KEY MANAGEMENT ........................................................... 19
2.6
RESPONSIBILITIES OF THE ENTITIES ...................................................................................... 22
2.7
IDENTIFICATION ................................................................................................................... 24
2.8 NUMBERING SCHEME FOR COMPONENTS, APPLICATIONS, PRODUCTS AND SECURITY SUB SYSTEMS (SSS) IN NORTIC SYSTEMS............................................................................................................. 25 3
SECURITY POLICY AND REQUIREMENT SPECIFICATION.............................................. 32
3.1
NORTIC SECURITY ARCHITECTURE ..................................................................................... 32
3.2
THREAT AND VULNERABILITY ANALYSIS ................................................................................. 33
3.3
SECURITY POLICY ............................................................................................................... 36
3.4
SECURITY REQUIREMENTS ................................................................................................... 40
4
SECURITY MECHANISMS................................................................................................... 47
4.1
NORTIC SECURITY KEYS..................................................................................................... 47
4.2
NORTIC APPLICATION KEYS STORAGE ................................................................................. 48
4.3
ICCKEYN-APP DIVERSIFICATION........................................................................................... 49
4.4
ICCKEYN-PROD DIVERSIFICATION ........................................................................................ 50
4.5
ICCKEYN-MAC DIVERSIFICATION ......................................................................................... 50
4.6
MESSAGE AUTHENTICATION CODE (MAC) GENERATION ......................................................... 50
5
IC CARD AND MEDIA ACCEPTING DEVICE (MAD) SPECIFICATION .............................. 52
5.1
INTRODUCTION .................................................................................................................... 52
5.2
IC CARD RELATED ROLES AND ENTITIES ................................................................................. 52
5.3
CUSTOMER MEDIA REQUIREMENTS ...................................................................................... 53
5.4
IC CARD OPERATING SYSTEM REQUIREMENTS (COS) ........................................................... 53
5.5
IC CARD LIFECYCLE ............................................................................................................. 54
5.6
FILE STRUCTURE SPECIFICATIONS........................................................................................ 55
5
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.7
DESCRIPTION OF A TRAVELCONTRACT USAGE TRANSACTION .................................................. 59
5.8
MEDIA ACCEPTING DEVICE (MAD) ....................................................................................... 63
5.9
DATA ELEMENTS ................................................................................................................. 63
5.10
NORTIC ASN.1 SPECIFICATION .......................................................................................... 65
6
CLEARING INTERFACE SPECIFICATION.......................................................................... 70
6.1
OVERALL INTERFACE REQUIREMENTS ................................................................................... 70
6.2
INTERFACE DEFINITION ........................................................................................................ 70
6.3
CLEARING INTERFACE SPECIFICATION................................................................................... 73
6.4
SECURITY DATA SPECIFICATION (OPTIONAL) ........................................................................... 77
7
TEST GUIDELINES .............................................................................................................. 80
7.1
INTRODUCTION .................................................................................................................... 80
7.2
ENTITIES AND ROLES ........................................................................................................... 80
7.3
TESTING ............................................................................................................................. 80
7.4
REFERENCE PRE-TESTS ...................................................................................................... 82
7.5
FUNCTIONALITY TESTS ........................................................................................................ 84
7.6
QUALITY TESTS................................................................................................................... 87
8
NORTIC SPECIFICATION FOR MIFARE DESFIRE (NSD).................................................. 91
8.1
DESFIRE GLOBAL STRUCTURE ............................................................................................ 91
8.2
NORTIC DESFIRE MEMORY ORGANISATION ........................................................................ 92
8.3
SECURITY FEATURES ........................................................................................................... 93
8.4
ADDITIONAL FEATURES AND DATA ........................................................................................ 94
8.5
GEOGRAPHICAL DATA CODIFICATION .................................................................................... 95
8.6
EXAMPLE ON VALIDATION PROCESS ...................................................................................... 97
8.7
PRODUCT PRIORITY AND MANAGEMENT ................................................................................ 99
9
NORTIC SPECIFICATION FOR DESFIRE FILE STRUCTURE.......................................... 102
9.1
MASTER FILE .................................................................................................................... 103
9.2
CARDISSUER DIRECTORY (CARDISSUERDF) ....................................................................... 104
9.3
TRANSPORT DIRECTORY .................................................................................................... 106
9.4
NORTICDF........................................................................................................................ 138
9.5
NSD DESFIRE FILE ORGANISATION SUMMARY..................................................................... 138
10
TRAVELCONTRACT TRANSACTION ............................................................................... 141
11
KEY MANAGEMENT.......................................................................................................... 142
11.1
MASTER KEY MANAGEMENT ................................................................................................ 142
11.2
CARD ISSUER INFORMATION ............................................................................................... 142
6
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
11.3
TRANSPORT APPLICATION .................................................................................................. 142
12
CODIFICATION .................................................................................................................. 144
13
TERMINOLOGY AND DEFINITIONS ................................................................................. 145
13.1
DEFINITIONS ..................................................................................................................... 145
13.2
ABBREVIATIONS ................................................................................................................ 148
13.3
REFERENCE STANDARDS ................................................................................................... 149
ANNEX A
COMMON REQUIREMENT SPECIFICATION FOR INTEROPERABILITY (CRSI) 151
A.1
INTRODUCTION .................................................................................................................. 151
A.2
LIST OF REFERENCES ........................................................................................................ 151
7
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
1 BACKGROUND This part of Handbook 206 contains detailed technical specifications for 2 different interoperable applications: 1. A national application for purchase of local single tickets, based on a charge-to-account product (NORTIC TravelContract) and international (ISO) and European (CEN) standards concerning commands and data elements 2. An alternative to the NORTIC ISO and CEN based specification using a mifare DESFire Contactless IC-card. This specification is called NORTIC TravelContract application for DESFire. The specification is based on the NORTIC specification for DESFire (NSD). The NORTIC application does not presuppose any specific card. The current description presupposes a smartcard with the ISO-7816 command set implemented. However, the current situation in Norway concerning implementation of electronic ticketing systems has influenced the Norwegian Public Roads Administration also describing how the mifare DESFire IC-card may be used as an alternative to the standardisation based NORTIC specification. Given the detailed technical nature of this specification, and the fact that valuable experience is gained as the different implementation projects proceed, the specification cannot be finalized yet. Clarifications, additional material and even minor changes are bound to be released. This means that new versions of the specification will be issued. In order to ensure an orderly and accountable process strict version and change control will be enforced, and new versions will be made available through a comprehensive release process.
8
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
2 SPECIFICATION OF THE NORTIC APPLICATION AND PRODUCT This chapter includes the definition of the NORTIC Interoperable Product that the Customer may acquire and use as payment means in exchange for use of transport services. The term Product is defined in HB206 Part 1 in accordance with the definition used within the European standardisation bodies CEN TC278/WG3/SG5 (IFM) and CEN TC224/WG11 (IOPTA). Product is defined as a set of usage rules, pricing rules and commercial rules. The requirements of these rules as well as their interpretation and functionality related to the involved entities of the system will be defined. •
NORTIC is the name of the common specification for interoperable electronic ticketing, and stands for NORwegian Ticketing Interoperable Concept.
•
IFMSA stands for Interoperable Fare Management System Architecture (CEN TC278 WG3 standard)
•
IOPTA stands for InterOperable Public Transport Application (CEN TC278 WG11 standard)
In order to allow the NORTIC product to co-exist with the regional / inter-regional products the NORTIC product is situated in a specific application on the IC-card (DESFire).
2.1 NORTIC INTEROPERABLE PRODUCT Within the scope of the NORTIC Specification there is one Interoperable Product being of IOPTA type Charge To Account. The Product is called a TravelContract or ‘Reiseavtale’ in Norwegian. The term ProductTC Owner means the entity being responsible for issuing the TravelContract (TC). The TravelContract is defined to be a pointer to a Central Account managed by the Product Owner. The Central Account is linked to a Customer via a contract between the Product Owner and the Customer. The payment between Customer and the Product Owner is out of the scope of this specification. IOPTA definition of Charge To Account:
Identifies and provides further information concerning an authorised account which may act as a ticket for a journey or be used to acquire a separate ticket.
Within the NORTIC specification the interoperable TravelContract is treated as being both a payment means and a Product. It is important to note this dual functionality and to understand the meaning of the two concepts. Being a payment mean the TravelContract has the characteristics of a contract agreement between the Customer and the Product Owner, which regulates the settlement of the Customers account. While being a Product, the TravelContract refers to a specific set of usage rules, pricing and commercial rules, which is applied when the Customer is using the TravelContract. Within this specification it is mainly the usage rules that are defined, i.e. how the TravelContract is issued, used and terminated within the system. The NORTIC TravelContract is issued on a smart card, and offers interoperability for the Customer. Interoperability is:
9
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
1
•
The provision for the Customer of a seamless journey using the same smart card on different Service Operators.
•
The ability of systems to provide services to and accept services from other systems
The NORTIC TravelContract, issued on a smart card, offers the Customer the possibility to use the TravelContract as payment means in different Interoperable Fare Management Systems in Norway. Technically, a separation is made between the NORTIC application and the TravelContract product. The NORTIC application is installed on the ticket media (smart card). Ticket Media Accepting Devices (MAD) identifies and selects the NORTIC application on the ticket medium by one unique NORTIC application Identifier. An occurrence of the TravelContract product is loaded in the NORTIC application.
2.2 OVERALL REQUIREMENTS Definitions and specifications related to the national interoperable product should be met by the overall requirements in the table below. The following terms are used: ProductTC Owner:
The entity being responsible for the TravelContract installed on the Customer media, e.g. an IC card.
ProductTC Retailer:
The entity acting on behalf of the ProductTC Owner having sold and delivered the TravelContract to the User.
Local Product
A product offered by a ProductLP Owner that usually is different from the ProductTC Owner, e.g. a PT operator in another city or region.
ProductLP Retailer:
The entity acting on behalf of the ProductLP Owner having sold and delivered the local product to the Customer.
Requirement
Requirement
No [R 1]
Product owners, e.g. a Public Transport Operator, may install a TravelContract on the ticketing medium offered to Customers. This national interoperable product shall be used in connection with purchase of single tickets (local products).
[R 2]
The TravelContract shall be accepted in any Norwegian electronic ticketing system
[R 3]
Clearing and settlement of sales and use of the TravelContract shall be done between the ProductTC Owner and ProductLP Retailer - either bilaterally or through a central clearing service.
[R 4]
The use of the TravelContract, creating an electronic fare collection transaction (EFC) at the point of purchase, shall be used as a claim for payment between the ProductLP Retailer and the ProductTC Owner.
[R 5]
The EFC transaction shall be protected against manipulation and fraud in such a manner that the recipient of the claim or a Trusted Third Party (TTP) may verify that the claim is justified/authentic (not mandatory).
[R 6]
It shall be possible to trace any transaction back to its generation origin
1
By seamless journey we here understand a travel that may consist of using services from several Service Operators, while all payments are made with one single card. This is also characterised as coordinated ticketing.
10
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No enabling the Customer to have the necessary information about the source of transaction, in case of any dispute. [R 7]
Product Owners, Retailers and Service Operators shall be uniquely identified, and numbering and number registration shall be according to the NORTIC specification (TC278 WG3 SG5).
[R 8]
The TravelContract shall be valid for two years from its issuing date. This requirement is motivated by the requirement to keep the security list manageable. It will be up to each ProductTC Owner if he will allow for the TravelContract to be renewed for another two years.
[R 9]
The TravelContract defined within the NORTIC shall contain information about the ProductTC Owner in order for a ProductLP Retailer to forward a claim for payment to this ProductTC Owner.
[R 10]
The NORTIC TravelContract shall be issued on the ticket medium by all Product Owners, who whish to offer this interoperable product to their Customers.
[R 11]
Any ProductLP Retailer shall accept a TravelContract that has been issued in line with the NORTIC specifications.
[R 12]
An electronic ticket shall be written to the NORTIC ticket medium (smart card) as receipt of payment when the TravelContract is used as payment means. This electronic ticket shall be written to the card, i.e. the NORTIC Event log.
The TravelContract may be used for payment of a single journey or, in a local system, to pay for another product. The requirement [R 12] defines that an electronic receipt for the payment shall be stored in the Customers card. If appropriate, the ProductLP Retailer may generate a proof of travel/ticket, which can be verified by the Service Operator (validation/inspection). This Proof of Travel/Ticket may have three optional forms; 1. a paper ticket, 2. an electronic ticket stored within the NORTIC application, or 3. an electronic ticket stored in another (local) application elsewhere in the card. The settlement between the Customer and ProductTC Owner is out of the scope of this specification. The settlement between ProductLP Retailer and ProductTC Owner is out of the scope of this specification.
2.3 ENTITIES An entity is an abstract unit composed of set of functions within public transport. Organisations, companies or persons fulfil the functions of these entities. Some of the entities in the IFM model are outside the scope of this specification (Registrar, Security Manager and Collection & Forwarding service). Within the scope of the NORTIC TravelContract specification we identify the following entities: •
ProductTC Owner
•
ProductLP Retailer
•
Service Operator
11
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Customer
Interaction is required between these entities to fulfil interoperability functions of an Interoperable Fare Management System (IFM). An IFM system is a Fare Management System that can provide services and accept services from other Fare Management Systems. This provides the Customer the opportunity of Seamless Travel. ProductTC Owner: The ProductTC Owner is responsible for issuing the NORTIC TravelContract product on the Customers ticket media (IC card (smart card)). The ProductTC Owner holds the contract between himself and the Customer. A Contract is the expression of an agreement between the Customer and the Product Owner, which defines the conditions under which the Customer may use the NORTIC TravelContract as payment mean and how the central account is kept in balance. The NORTIC TravelContract shall be issued on the ticket medium by all Product Owners, who whish to offer this interoperable product to their customers (optional). Retailer: The Retailer is the entity that sells the product to the Customer on behalf of the Product Owner. Within NORTIC the Retailer has two roles: 1. ProductTC Retailer 2. ProductLP Retailer First the ProductTC Retailer sells the TravelContract to the Customer, and later when using the ticket media as payment means, the ProductLP Retailer sells a local product (single journey ticket or other local product) to the Customer. Any ProductLP Retailer within Fare Management Systems shall accept the TravelContract product that has been issued in line with the NORTIC specification (mandatory). When the Customer has purchased a ticket at the ProductLP Retailer he is entitled to use a service, conformant to the validity of the ticket purchased, at the Service Operator transport means. The ProductLP Retailer collects usage data (transaction information) and forwards it to the ProductLP Owner. Service Operator: The Service Operator (also known as the Service Provider) provides the transport function for the Customer, in other words the actual transport provision (the physical bus, train etc). A Customer benefits from a transport service and the Service Operator validates the Customers ticket purchased from the ProductLP Retailer. The Service Operator collects usage data (transaction information) enabling him to receive payment for the transport services provided. In many systems the ProductLP Retailer and Service Operator is handled by the same organisation, and the purchase and validation of the single journey ticket is performed in one operation. Customer: A person that holds the NORTIC Application (cardholder). The Customer uses the NORTIC TravelContract as payment mean in order to pay for a single journey ticket allowing her to acquire travels provided by the Service Operator. It is out of this specifications scope to define the Contract between the ProductTC Owner and the Customer. How the central account is kept in balance is dependent on the agreement between the Customer and the ProductTC Owner. For example, travels may be pre-or post paid. In the first case the Customer pay in advance to a centrally held account managed by the ProductTC Owner, and all travels are charged to this account. In the latter case an external financial institution, e.g. bank or Credit Card Company, debits the Customers account subsequent to the travels.
12
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Figure 1 Simplified sequence diagram for usage of TravelContract
2.4 TRAVELCONTRACT LIFE CYCLE This section elaborates the life cycle phases of the NORTIC TravelContract. The TravelContract life cycle is defined to consist of the following phases: •
TravelContract Issuance
•
Use of the TravelContract
•
TravelContract termination
TravelContract issuance is the process of issuing the TravelContract on the Customers ticket medium (smart card). The Customer uses the product as payment mean when acquiring paper- or electronically tickets in order to travel. The TravelContract may also be used to acquire other products, e.g. a monthly ticket. TravelContract termination is the process of terminating the use of the TravelContract occurrence on the Customers ticket medium. 2.4.1
TravelContract issuance
The ProductTC Owner is responsible for issuing the TravelContract on the Customers ticket medium. The ProductTC Owner holds the Contract between himself and the Customer for any occurrence of the TravelContract. The Contract defines the conditions, under which the Customer may use the TravelContract as payment mean. The contractual link between the ProductTC Owner and the Customer also defines how the customers centrally held account is kept in balance. The NORTIC TravelContract shall be issued on the Customers ticket medium by all Product Owners, who whish to offer this product to their customers which means that
TravelContract issuance is not mandatory for Product Owners within public transportation.
13
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The TravelContract product shall be valid for two years from its issuing date. It is up to the ProductTC Owner if renewal is allowed for additional periods of two years. The TravelContract is loaded on the NORTIC application, which is installed on the ticket medium (smart card). The process of TravelContract issuance includes both the NORTIC application instalment and loading the TravelContract on the application. The application is an implemented and initialised application template on the ticket medium (smart card). The application template is a master of the application specification for implementation, which is a specification of files, directory entries and security schema. The requirements to the ticket medium as well as application instalment and loading the TravelContract product on the application is specified in Chapter 4 “Smart Card and Media Accepting Device (MAD) Specification”.
Figure 2 Customer media with NORTIC application housing a TravelContract
TravelContract issuance uses and provides data from/to security management. The issuance also provides data to customer management (outside the scope of this specification). Security management shall guarantee the operation, security and reliability of all system processes.
The TravelContract is always issued with security mechanisms, but the ProductLP Retailer may accept the TravelContract as payment mean with or without security mechanisms.
The ProductTC Owner shall use security mechanism described in this specification when issuing the TravelContract. Security keys and mechanisms shall be protected and stored in Secure Application Modules (SAM) wherever security mechanisms are in use in the issuing process. The ProductTC Owner is responsible managing the customer data and the status of the TravelContract occurrences. The status of the TravelContract may be open, pending or blocked. An open TravelContract occurrence is valid for use as payment mean at any ProductLP Retailer. Blocked TravelContract occurrences are not valid for use at any ProductLP Retailer. Reasons for blocking TravelContract occurrences may be: •
The Customer breach the contract with the ProductTC Owner
•
Stolen or lost ticket medium (smart card)
Customer data and status of TravelContract occurrence shall be kept in a Card Register of the ProductTC Owner responsibility. Relevant data in a Card Register are (for mandatory data this is written in brackets, others are optional): •
Card serial number (mandatory)
•
Security system key generation/version (mandatory)
•
TravelContract status, as described above (mandatory)
•
TravelContract balance
14
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
TravelContract pre-payment minimum balance
•
TravelContract post-payment charge threshold
•
Customer/ticket medium holder info; name, address, etc.
•
Contract status; pre- or post-paid
•
Customer account number (e.g. customers bank account)
Requirement
Requirement
No [R 13]
The ProductTC Owner is responsible for issuing the TravelContract on the Customers ticket medium. The process of TravelContract issuance includes both NORTIC application instalment and loading the TravelContract on the application.
[R 14]
The TravelContract is always issued with security mechanisms, but the ProductLP Retailer may accept the TravelContract as payment mean with or without security mechanisms.
[R 15]
The ProductTC Owner shall use security mechanism described in this specification when issuing the TravelContract. Security keys and mechanisms shall be protected and stored in Secure Application Modules (SAM) wherever security mechanisms are in use.
[R 16]
The ProductTC Owner is responsible managing the customer data and the status of the TravelContract occurrences. Mandatory data are: •
Card serial number (unique card ID)
•
Security system key generation/version
•
TravelContract status, as described above
In each transaction, the MAD (Media accepting device) activates the ticket medium and selects the NORTIC application based on an application identifier. Therefore the MAD must be able to identify and select the NORTIC application on the ticket medium by one unique NORTIC application Identifier. Requirement
Requirement
No [R 17]
The format of the NORTIC Application Identifier shall be in accordance with ISO7816-5.
[R 18]
The NORTIC Application Owner shall obtain a valid Registered Application Provider Identifier from a Nationally Authorised ISO7816-5 Registration Authority
After the application selection, the MAD identifies the TravelContract as specified in the TravelContract file structure. Requirement
Requirement
No
15
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No [R 19]
TravelContract product identification shall be according to ProductId defined in 2.7 Identification.
[R 20]
The ProductTC Owner shall obtain a valid issuer identification number from a Nationally Authorised Registration Authority.
2.4.2
Use of the TravelContract
The Customer may use the TravelContract as payment mean to: •
Pay a single journey in order to travel (mandatory)
•
Pay another product loaded on the ticket medium (optional)
The ProductLP Retailer provides the Customer a Proof of Travel/Ticket in one of the following ways: •
a paper ticket,
•
an electronic ticket stored within the NORTIC application, or
•
an electronic ticket stored in another application elsewhere in the card.
The Proof of Travel/Ticket for a single journey may be validated by the Service Operator equipment according to the local Product Owners system regulations. The ProductLP Retailer may accept the TravelContract with or without security mechanisms. The ProductLP Retailer is responsible for collecting product usage data when a TravelContract occurrence is used. TravelContract usage data is the transaction information generated when the TravelContract is used, and includes payment information. The transaction data is forwarded to the ProductTC Owner in order to receive payment for the actual single journey travel or local product. The NORTIC ticket medium shall generate a signature, which enables the ProductTC Owner to verify the authenticity and integrity of the claim (transaction). Authenticity ensures the sender identity (Retailer), i.e. provides information that the identity of a source of data received is as claimed. Integrity ensures that the received data is unchanged or unmanipulated, i.e. protection against unauthorised modification or deletion of information. In detail use of a TravelContract consists of: •
Detection and verification of the NORTIC application on the Customers ticket medium
•
Detection and verification of the TravelContract occurrence in the NORTIC application
•
Verify that the TravelContract occurrence is valid (e.g. not security listed and within validity period)
•
Calculate the price of the single journey ticket or product
•
Write an electronic ticket to the NORTIC Application log and/or print a paper based ticket or write/issue a product into the ticket medium
•
Collection of the TravelContract usage data (transaction information)
•
Forwarding the TravelContract usage data as a claim against the ProductTC Owner
The ProductTC Owner is always economically responsible for a TravelContract, meaning that the ProductTC Owner claims the customer for the price of the single journey ticket or product. If non payment from the Customer the ProductTC Owner is still in relation to the ProductLP Retailer The ProductTC Owner may deny claims from ProductLP Retailer in the following situations: •
The ProductLP Retailer accepts the TravelContract without security mechanisms
•
ProductLP Retailer has not distributed the security list to the MAD equipment 16
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The set of usage, pricing and commercial rules associated with the TravelContract product are listed below. 2.4.3
TravelContract usage, pricing and commercial rules: Description The TravelContract is valid for two years from its issuing date. The ProductTC Owner decides renewal for additional periods. The TravelContract may be used as payment mean in any electronic ticketing system in Norway in order to:
Usage rules
•
Buy single journey tickets (mandatory)
•
Buy other product, e.g. a monthly ticket (optional)
A payment transaction as receipt for payment shall be written into the card TravelContract log. A single journey ticket (proof of travel) may be paper based or electronically stored in the customer’s ticket medium (event log in the smart card). The ProductLP Retailer accepting the TravelContract is responsible for collecting product usage data in order to receive payment from the ProductTC Owner. Product usage data (transactions) shall be signed by the ticket medium, which enables the ProductTC Owner to verify the authenticity and integrity of the claim from the ProductLP Retailer. The TravelContract may be accepted as payment mean with or without security mechanisms. The ProductTC Owner decides the price of the Customers ticket medium, e.g. deposit arrangement or fee. The price of single journey tickets or other products is according to pricing rules in the IFM system where the TravelContract is used as payment mean.
Pricing rules
The Customers centrally held account managed by the ProductTC Owner is charged when the TravelContract is used as payment mean. The contractual link between the ProductTC Owner and the Customer defines how the centrally held account is kept in balance. The ProductLP Retailer accepting the TravelContract as payment mean forwards a claim to the ProductTC Owner subsequent to the ticketing event. Settlement between the ProductTC Owner and the ProductLP Retailer is according to the agreement between the parties.
Commercial rules
Requirement
Requirement
No [R 21]
Any ProductLP Retailer in Norway shall accept the TravelContract as payment mean. The Customer may use the TravelContract in order to: •
Pay a single journey in order to travel (mandatory)
•
Pay another product loaded on the ticket medium (optional)
17
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No The ProductLP Retailer writes a transaction into the TravelContract log of the card. [R 22]
The ProductLP Retailer is responsible for collecting TravelContract usage data. Product usage data is the transaction information generated when the product is used, and includes payment information. The transaction data is forwarded to the ProductTC Owner in order to receive payment for the actual customer travel.
[R 23]
The NORTIC ticket medium shall generate a MAC (Message Authentication Code), which enables the ProductTC Owner to verify the authenticity and integrity of the claim (transaction).
[R 24]
The ProductTC Owner is always economically responsible for a TravelContract, meaning that the ProductTC Owner claims the customer for the price of the single journey ticket or product. If non payment from the Customer the ProductTC Owner is still responsible in relation to the ProductLP Retailer. The ProductTC Owner may deny claims from ProductLP Retailer in the following situations:
2.4.4
•
The ProductLP Retailer accepts the TravelContract without security mechanisms
•
The ProductLP Retailer has not distributed the security list to the MAD equipment
TravelContract termination
The TravelContract is valid for two years from its issuing date. It is up to the ProductTC Owner if renewal is allowed for additional periods. The TravelContract shall not be accepted as payment means when the validity period of the product is exceeded. In this situation the ticketing equipment shall prevent use of the product based on TravelContract information read from the ticket medium. In some cases the Customer triggers termination of the TravelContract issued in his ticket medium. TravelContract termination is the responsibility of the ProductTC Owner and includes the following steps: 1. De-install the TravelContract on the ticket medium and update product status maintained by the ProductTC Owner 2. Terminate the centrally held account 3. Terminate the contractual link between the ProductTC Owner and the Customer The TravelContract may be de-installed immediately from the ticket medium. Terminating the centrally held account and the contractual link between the Customer and the ProductTC Owner assumes settlement of all payment transactions. Completing settlement with ProductLP Retailer and the Customer is the responsibility of the ProductTC Owner. Requirement
Requirement
No [R 25]
The ticketing equipment shall prevent use of the TravelContract based on TravelContract information read from the ticketing equipment in situations where the validity period is exceeded (two years validity).
[R 26]
TravelContract termination is the responsibility of the ProductTC Owner.
18
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
2.5 TRAVELCONTRACT AND SECURITY KEY MANAGEMENT Clearing and settlement between the ProductLP Retailer and the ProductTC Owner take place subsequent to the Customers use of the TravelContract as payment mean. To prevent use of the TravelContract in situations where the Customer has breached the contract with the ProductTC Owner, e.g. the centrally held account is not kept in balance due to non-payment, it is the responsibility of the ProductTC Owner to distribute security lists to the ProductLP Retailer accepting the TravelContract as payment mean. The security list, earlier called black list, contains a list of blocked TravelContracts. This section describes clearing and settlement, security list management and discusses physical exchange of information between identified entities. Security key management is also considered in this section. 2.5.1
Clearing and settlement
Clearing and settlement for the use of the NORTIC TravelContract shall be done between the ProductTC Owner and the ProductLP Retailer accepting the TravelContract as payment mean. Clearing is the processing and possible consolidation of transaction information passing between the parties accepting the NORTIC TravelContract as payment mean on each other’s behalf. This situation is illustrated in Figure 3. The ProductLP Retailer accepts the NORTIC TravelContract as payment mean when the Customer buys a product (paper or electronically ticket) in order to travel. The ProductLP Retailer forwards transaction information, including payment information, to the ProductTC Owner. The Customers centrally held account is charged for the price of the product. The transaction information forwarded from the ProductLP Retailer is a claim directed towards the ProductTC Owner. The actual settlement between the ProductTC Owner and the ProductLP Retailer is according to the agreement between these two parties. In some situations the Product Owner and Retailer may be the same entity, and no settlement between Product Owner and Retailer is required.
Figure 3 Clearing and settlement between ProductTC Owner and RetailerLP The ProductTC Owner will receive claims from ProductLP Retailer that have accepted the occurrences of the TravelContract as payment mean. Figure 4 illustrates a situation where the Customer has used the TravelContract as payment mean at several ProductLP Retailer in order to travel with several Service Operators. The transaction information, which is a claim, is forwarded to the ProductTC Owner from all ProductLP Retailer. Settlement between the ProductTC Owner and the ProductLP Retailer shall be done according to the agreements between the parties.
19
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Figure 4 Settlements between ProductTC Owner and RetailersLP
Requirement
Requirement
No [R 27]
2.5.2
Clearing and settlement for the use of the NORTIC TravelContract shall be done between the ProductTC Owner and the ProductLP Retailer accepting the TravelContract as payment mean. Security list management
The Customer may in some cases breach the contract with the ProductTC Owner, e.g. non-payment of pre-or post paid travels. In this situation it is the responsibility of the ProductTC Owner to distribute a list of blocked TravelContract occurrences (security list) to the ProductLP Retailer accepting the NORTIC TravelContract as payment mean. The security list, also called blacklist, is distributed to the ticketing equipment to prevent use of a blocked TravelContract occurrence. It is the responsibility of the ProductTC Owner to maintain the status of the issued TravelContracts. The status of a TravelContract occurrence may for example be open, pending or blocked. The ProductTC Owner distributes security lists to ProductLP Retailer, who acknowledge the reception of the security list. Requirement
Requirement
No [R 28]
The ProductTC Owner manages and distributes security lists to the ProductLP Retailer accepting the TravelContract as payment mean.
[R 29]
The ProductLP Retailer shall acknowledge the reception of security lists from the ProductTC Owner and shall distribute the security list to all user equipment/MAD.
2.5.3
Physical exchange
20
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The actual physical exchange of transactions/claims and security list shall be done according to agreements between the parties involved. Whether an electronic media does the exchange sent through the mail system or through advanced communication systems is out of the scope of this specification. The format of transaction information and security lists exchanged between ProductTC Owners and ProductLP Retailer shall be in accordance with the format in this specification. 2.5.4
Security key management
The ProductTC Owner is responsible for the security of the: •
Ticket medium (TravelContract data)
•
Transaction process (enabling authentication of TravelContract)
•
Settlement process (enabling mutual non-repudiation of the transactions made)
Some initial assumptions for the security scheme are: The segment integrity of ticket medium is assumed to be trustworthy so that secure information (keys) in the ticket medium is kept secret. However the ticket medium might be issued with publicly known information (i.e. data elements conformant to this Handbook 206-2) so that this information is unauthentic. This introduces the need that ProductLP Retailer accepts TravelContract issued in an authentic way (TravelContract production data authentication) The ProductTC Owner and the ProductLP Retailer will often be two different legal organisations and therefore there might not exist any trust between them. This introduces the need for •
The ProductTC Owner (or Trusted Third Party) shall accredit (authorise) any SAM installed in the ProductLP Retailer MAD for accessing the NORTIC application. The SAM shall ensure the confidentiality and integrity of the TravelContract authentication keys.
•
The ProductTC Owner must be able to distribute the TravelContract authentication keys to the ProductLP Retailer MAD SAM. The security includes confidentiality, integrity and peerto-peer origin authentication. Furthermore the ProductTC Owner must be able to update, invalidate and revalidate authentication keys throughout the TravelContract life cycle. Example: ProductTC Owner typically uses a symmetric method with DES/3-DES and a onelevel diversification of the authentication master key with 8 master key generations.
•
The ProductTC Owner must be convinced that the TravelContract authentication keys are kept secret throughout the TravelContract life-cycle (focusing on the SAM segment integrity)
•
The ProductTC Owner and the ProductLP Retailer must be able to exchange clearing and settlement data in a secure way. This includes integrity, peer-to-peer authentication and non-repudiation.
Within NORTIC there will be three master keys generated for handling TravelContracts.
Requirement
Requirement
No [R 30]
The ProductTC Owner is responsible for selecting the appropriate authentication mechanism of the TravelContract (symmetrical versus asymmetrical) and provides a secure download of authentication keys to the ticket medium.
[R 31]
The ProductTC Owner and ProductLP Retailer MAD SAM shall exchange authenticated public keys.
21
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No [R 32]
The ProductTC Owner shall distribute the TravelContract authentication master keys according to ISO11770 Part 3 – Key Transport Mechanism 3 or higher.
In the case of a Trusted Third Party (TTP) being responsible for security handling, the responsibilities and requirements of the ProductTC Owner, here over mentioned, may be performed by the TTP.
2.6 RESPONSIBILITIES OF THE ENTITIES The column ‘Mandatory’, in tables below, states if the responsibility is mandatory or not for the actual entity. 2.6.1
ProductTC Owner responsibilities
Responsibility
Description
Mandatory
Security key management
The ProductTC Owner is responsible for generation, distribution and maintenance of security keys for the appropriate authentication mechanism chosen. Additionally the ProductTC Owner accredits the ProductLP Retailer MAD SAM’s.
TravelContract issuance
The ProductTC Owner is responsible for installing the NORTIC application and the TravelContract occurrence on the Customers ticket medium
Contractual link with the customer
The Contract between the ProductTC Owner and the Customer defines the conditions, which under the Customer may use the TravelContract as payment mean. The contractual link between the Product Owner and the Customer also defines how the customers centrally held account is kept in balance.
Yes
Collecting Customer data
The ProductTC Owner collects Customer data when the TravelContract is issued. The ProductTC Owner maintains Customer data in his system.
Yes
Charge centrally held account
The ProductTC Owner is responsible for charging the centrally held account when claims are received from ProductLP Retailer.
Yes
Settlement with Retailers
ProductLP Retailer forwards claims to the ProductTC Owner in order to receive payment for travels paid with TravelContract occurrences. The agreement between the ProductTC Owner and ProductLP Retailer defines how settlement is carried out.
Yes
TravelContract status
ProductTC Owner maintains the status of TravelContract occurrences, e.g. blocked.
Yes
Security list management
The ProductTC Owner is responsible for distribution of security list to ProductLP Retailer accepting the
Yes
22
Yes
Optional
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Responsibility
Description TravelContract as payment mean. The security list consists of a list of blocked TravelContract occurrences.
TravelContract termination
The ProductTC Owner terminates TravelContract occurrences and the centrally held account.
2.6.2
Mandatory
Yes
ProductLP Retailer responsibilities
Responsibility
Description
Security key usage
The ProductLP Retailer may authenticate the TravelContract, and shall in that case receive, store and handle authentication keys from the ProductTC Owner according to his rules.
TravelContract product usage
Any ProductLP Retailer shall accept the TravelContract product as payment mean.
Yes
Collecting usage data
The ProductLP Retailer collects TravelContract usage data (transaction information) when a TravelContract is used as payment mean.
Yes
Claim the ProductTC Owner
The ProductLP Retailer forwards collected TravelContract usage data (transaction) to the ProductTC Owner in order to receive payment.
Yes
security list management
Retailers receive security lists from ProductTC Owner. It is the responsibility of the ProductLP Retailer to distribute the security list to the ticketing equipment to prevent use of blocked TravelContracts.
2.6.3
Mandatory Optional
Optional
Customer responsibilities
Responsibility
Description
Mandatory
Contractual link with the ProductTC Owner
The Customer establishes a Contract with the ProductTC Owner. The Contract defines the conditions, which under the TravelContract is used as payment mean, and how the centrally held account is kept in balance.
Yes
Keep the centrally held account in balance
The Customer is responsible for keeping the centrally held account in balance. How the centrally held account is kept in balance is defined in the contract between the ProductTC Owner and the Customer.
Yes
23
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
2.7 IDENTIFICATION 2.7.1
Introduction
By identification is meant a set of attributes that describes a specific person or object in a unique and unambiguous way. A person can for instance be described by name, birth date, sex, address etc to be uniquely identified. An object, e.g. a ticketing machine, can be identified by owner, type and serial number. Identification is important in an electronic ticketing system as well as in an Interoperable Fare Management (IFM) system for following main reasons: Security Identification of entities, objects, applications, products etc enables the use of Security lists, e.g. blacklisting a stolen retailer machine or a stolen ticket media. It also enables authentication and message integrity, e.g. by using the unique identification in an authentication procedure or including the unique ID in a seal, e.g. a message authentication code (MAC). Communication, i.e. addressing entities In an IFM network there will be many entities like organisations, companies and components that will be acting as a sender and/or a receiver of information. A unique identification is needed for addressing the different entities in a communication network. Auditing There is a strong requirement on being able to audit any transaction and any piece of information in an IFM system, e.g. following a usage transaction from the creation by the service provider until it is cleared and refunded by the product owner. If something goes wrong or any information is changed during its lifetime it is important being able to investigate what happened and where in the IFM system it happened. 2.7.2
Numbering scheme
As a minimum the following objects shall have a unique identity in an IFM system: A. B. C.
All Applications (implemented and initialised Application Templates) All Products (instances of Product Templates) All Actors (organisations) involved in the IFM system, e.g. all product and application owner, retailers, transport service providers and clearing and forwarding operators. All Security Sub Systems (SSS), e.g. a SAM with keys used for cryptography All Components handling, storing and transferring IFM information
D. E. NOTE 1:
The numbering scheme is based the prerequisite that all objects are present within the same IFM system. Hence, there is no need to include the identity of the network or the IOPTA application. In case any information is exported to other IFM systems the IOPTA application and network id are added to the entity id as a header.
NOTE 2:
It is of crucial importance that the Application ID and Product ID are as short and compact as possible due to the minimisation of the transaction time between the Customer Media and the MAD. Hence, the number and size of the data elements have been limited.
2.7.3
Registrar
The Registrar registers the IFM specific data and is uniquely identified on a national level by its national standardisation body.
24
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
2.8 NUMBERING SCHEME FOR COMPONENTS, APPLICATIONS, PRODUCTS AND SECURITY SUB SYSTEMS (SSS) IN NORTIC SYSTEMS
Entity ComponentId
Data 1
Data 2
Data 3
Comp onent Owner
Comp onent Generic Type
Comp onent Serial Number
Data 5
Data 6
Data 7
Data 8
Appli cation SubType
Appli cation Retailer
Com ponent
Appli cation Seq uence Number
SAM Num ber
SAM Seq uence Number
Product Retailer
Com ponent
Product Seq uence Number
SAM Num ber
SAM Seq uence Number
Application TemplateId
ApplicationID Appli cation Owner
(implemented and initialised Application Template)
Appli cation Generic Type
Product TemplateId
ProductId (instance of a Product Template)
SSSId
Data 4
Product Owner
Product Generic Type
Product Sub Type
SSS Owner
SAM Generic Type
SAM Serial Number
Table 1: Numbering scheme for entities in IFM systems
2.8.1
Organisation identification
Organisations are uniquely identified by a number within the IFM system. The number is given by the Registrar after having verified the organisation certification. The number is within the range 0….1.048.575 within each IFM system.
IFMOrganisation ::= BIT STRING (SIZE(20)) 2.8.2
Components identification
Components, e.g. validators and ticketing machines, are uniquely identified by a number within the IFM system. The number is the concatenation of ComponentOwner, ComponentGenericType and ComponentSerialNumber.
25
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
ComponentOwner is any registered organisation within the IFM system, i.e. a number within 0….1.048.575. The ComponentGenericType is a number between 0….127 where the list of generic component types is kept by the Registrar. The Component owner adds a serial number, ComponentSerialNumber with a value between 0….4.095.
ComponentId ::= SEQUENCE { componentOwner
ComponentOwner,
componentGenericType
ComponentGenericType,
componentSerialNumber ComponentSerialNumber }
ComponentOwner ::= IFMOrganisation ComponentGenericType ::= BIT STRING (SIZE(7)) ComponentSerialNumber ::= BIT STRING (SIZE(12)) EXAMPLE: A validator may be uniquely identified by 356.45.789 where 356 is the organisation identity, e.g. a bus company, 45 is the component type, e.g. a validator with ISO 14443 Type A communication, and 789 is the serial number of the validator defined by the component owner. 2.8.3
Application Template identification
Application Templates are uniquely identified by a number which is the concatenation of ApplicationOwner, ApplicationGenericType and ApplicationSubType. ApplicationOwner is any registered organisation within the IFM system, i.e. a number within 0……1.048.575. The ApplicationGenericType is a number between 0…127 where the list of generic application types is kept by the Registrar. The Application Owner may have his own set of application types which is added as an ApplicationSubType being a number between 0….127.
ApplicationTemplateId ::= SEQUENCE { applicationOwner
IFMOrganisation,
applicationGenericType
ApplicationGenericType,
ApplicationSubType
ApplicationSubType
} ApplicationGenericType ::= BIT STRING (SIZE(7)) ApplicationSubType ::= BIT STRING (SIZE(7))
26
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
EXAMPLE: An Application Template may be uniquely identified by 1089.4.17 where 1089 is the organisation identity, 4 is the generic application type and 17 is the application owner specific sub type of application. 2.8.4
Application identification
Applications are uniquely identified by a number which is the concatenation of ApplicationTemplate, ApplicationRetailer, Component and ApplicationSequenceNumber. ApplicationRetailer is any registered organisation within the IFM system, i.e. a number within 0………1.048.575. The ApplicationSequenceNumber is date and time and is the current values as the MAD installs the application on the Customer Media. The data elements given in the previous paragraph are sufficient to uniquely identify an application on the Customer Media (who issued, what type, which serial number (when)). However, for security reasons there is a need to stamp the application. Hence, for the application registration by the Registrar the SecuritySubSystemId is added to the application identity. ApplicationId ::= SEQUENCE { applicationTemplateId
ApplicationTemplateId,
applicationRetailer
ApplicationRetailer,
componentId
ComponentId,
applicationSequenceNumber
ApplicationSequenceNumber
} ApplicationRetailer ::= IFMOrganisation ApplicationSequenceNumber ::= SEQUENCE { date
DateCompact
time
TimeCompact
} DateCompact ::= BIT STRING (SIZE(16)) TimeCompact ::= BIT STRING (SIZE(16)) EXAMPLE: An application on the Customer Media may be uniquely identified by 1089.4.17.478.478.23.3457.20041130153406 where 1089 is the Application Owner, 4 is the application generic type, 17 is the application sub type, 478 is the Application Retailer and component owner, 23 is the equipment type, 3457 is the equipment serial type and 20041130153406 is the sequence number (date and time, i.e. Nov 11, 2004, 15:34:06). 2.8.5
Product Template identification
Product Templates are uniquely identified by a number which is the concatenation of ProductOwner, ProductGenericType and ProductSubType.
27
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
ProductOwner is any registered organisation within the IFM system, i.e. a number within 0……1.048.575. The ProductGenericType is a number between 0…127 where the list of generic product types is kept by the Registrar. The Product Owner may have his own set of products types which is added as a ProductSubType being a number between 0….255.
ProductTemplateId ::= SEQUENCE { productOwner
IFMOrganisation,
productGenericType
ProductGenericType,
productSubType
ProductSubType
} ProductGenericType ::= BIT STRING (SIZE(7)) ProductSubType ::= BIT STRING (SIZE(8)) EXAMPLE: A Product Template may be uniquely identified by 7789.15.102 where 7789 is the organisation identity, 15 is the generic product type and 102 is the product owner specific sub type of product.
2.8.6
Product identification
Products are uniquely identified by a number which is the concatenation of ProductTemplate, ProductRetailer, Component and ProductSequenceNumber. ProductRetailer is any registered organisation within the IFM system, i.e. a number within 0………1.048.575. The ProductSequenceNumber is date and time and is the current value as the MAD installs the product on the Customer Media. The data elements given in the previous paragraph are sufficient to uniquely identify a product on the Customer Media (who issued, what type, which serial number (when)). However, for security reasons there is a need to stamp the product. Hence, for the product registration by the Registrar the SecuritySubSystemId is added to the product identity.
ProductId ::= SEQUENCE { productTemplateId productRetailer
ProductTemplateId, ProductRetailer,
componentId
ComponentId,
productSequenceNumber ProductSequenceNumber } ProductRetailer ::= IFMOrganisation ProductSequenceNumber ::= SEQUENCE { date
DateCompact
time
TimeCompact
28
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
} DateCompact ::= BIT STRING (SIZE(16)) TimeCompact ::= BIT STRING (SIZE(16)) EXAMPLE: A product on the Customer Media may be uniquely identified by 765.15.167.478.478.123.3214.20041224094534 where 765 is the Product Owner, 15 is the product generic type, 167 is the product sub type, 478 is the Product Retailer and Component owner, 123 is the equipment type, 3214 is the equipment serial type and 2004122409453406 is the sequence number (date and time, i.e. Dec 24, 2004, 09:45:34). EXAMPLE: Coded in bit format the previous ProductId example will be as in the table below: Octet #
Data element
1 2
Bits in Octet
Description
00000000 ProductOwner
3
00101111
Organisation number 765
1101 ProductGenericType
4
0001
Product generic type 15
111 ProductSubType
5
10100
Product sub type 167
111 00000
6
ProductRetailer
7
00000011
Organisation number 478
1011110 0
8 9
00000000 ComponentOwner
10
00111011
Organisation number 478
110 ComponentGenericType
11
11110
Component generic type 123
11 ComponentSerialNumber
12
110010
Component serial number 3214
001110 00
13 14
01110110 ProductSequenceNumber
011000 01
29
Dec 24, 2004
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
2.8.7
15
00110110
16
110001
Security Sub Systems identification
A Security Sub System, e.g. an IC card, is uniquely identified by a number within the IFM system. The number is the concatenation of SecuritySubSystemOwner, SecuritySubSystemGenericType and SecuritySubSystemSerialNumber. SecuritySubSystemOwner is any registered organisation within the IFM system, i.e. a number within 0….1.048.575. The SecuritySubSystemGenericType is a number between 0….127 where the list of generic types is kept by the Registrar. The Registrar adds a serial number, SecuritySubSystemSerialNumber with a value between 0….32.767.
SecuritySubSystemId ::= SEQUENCE { securitySubSystemOwner
SecuritySubSystemOwner,
securitySubSystemGenericType
SecuritySubSystemGenericType,
securitySubSystemSerialNumber
SecuritySubSystemSerialNumber
}
SecuritySubSystemOwner ::= IFMOrganisation SecuritySubSystemGenericType ::= BIT STRING (SIZE(7)) SecuritySubSystemSerialNumber ::= BIT STRING (SIZE(15)) EXAMPLE: A SAM in a ticketing machine may be uniquely identified by 1489.87.21476 where 1489 is the organisation identity, e.g. a public transport company, 87 is the type, e.g. a SIM card of a certain type, and 21476 is the serial number of the SIM card defined by the Registrar.
2.8.8
Generic ApplicationId coding
The ApplicationId may be used for diversification of security keys. Hence, the generic notation for the ApplicationId is given below. Octet #
Data element
1 2
ApplicationOwner
3
Bits in Octet
Description
oooooooo
IFM Organisation number
oooooooo
0… 1.048.575
oooo ApplicationGenericType
4
gggg ggg
30
IFM Application generic type 0….127
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
ApplicationSubType 5
sssss
0…127
ss rrrrrr
6
ApplicationRetailer
7
Application sub type
rrrrrrrr
IFM Organisation number 0… 1.048.575
rrrrrr oo
8 9
ComponentOwner
10
oooooooo
IFM Organisation number
oooooooo
0… 1.048.575
oo ComponentGenericType
11
gggggg
0….127
G ComponentSerialNumber
12
IFM Component generic type
sssssss sssss
Component serial number 0….4.095
yyy 13 14
ApplicationSequence Number
yyyymmmm
Date in DateCompact format
ddddd hhh
15
hhmmmmmm
16
sssss
31
Time in TimeCompact format
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
3 SECURITY POLICY AND REQUIREMENT SPECIFICATION The section outlines the overall security policy and requirements applicable for a nationally interoperable ticketing system, NORTIC. This section contains the security architecture, overall threat analysis, security policy and security requirements that apply for the NORTIC system. A few overall goals have been defined for the NORTIC interoperability specification for electronic ticketing •
The NORTIC specification shall enable different levels of security. These levels of security shall be defined as specific security profiles. The NORTIC specification shall be open to include new profiles or varieties of defined profiles in the future.
•
The EFC transaction shall be protected against manipulation and fraud in such a manner that the recipient of the claim or a Trusted Third Party (TTP) may verify that the claim is justified/authentic (not mandatory).
•
It shall be possible to trace any transaction back to its generation origin enabling the Customer to have the necessary information about the source of transaction, in case of any dispute.
3.1 NORTIC SECURITY ARCHITECTURE The main motivation by defining the NORTIC Security Architecture is simply that its value supersedes possible financial drawbacks (such as financial costs related to implementation and procedures). It shall be noted that probability of an actual attack on the NORTIC system is currently not quantifiable nor is it possible to assess the severity by means of possible financial loss. This is not only related to the possible successful implementation of the security architecture, but is related to social factors: •
Possible accumulated level of gain if attacks are successful (i.e. loss for the system)
•
Frequency and accuracy of enforcement (level of control of TravelContracts)
•
Level of penalties when attacks are detected and linked to an attacker
•
Availability of resourceful attackers willing to commit attacks
The NORTIC Security Architecture includes the specification of •
Threat analysis, detailing the most probable threats to the ticketing system compliant to NORTIC TravelContract specifications (NORTIC system) and the possible vulnerabilities that such a system might have.
•
Security policy, specifying how the threats to the NORTIC system shall be handled in proactive way.
•
Security requirements, detailing how the security policy shall be realised in the NORTIC system. For convenience two different security profiles are defined to provide the minimum set of security requirements enhancing the implementation of compliant systems to this specification.
32
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Each system implementation (or certain system modules) may be certified based on their claimed compliance to this specification. However, it shall be emphasised that no test or any certification procedures are specified for fulfilling the requirements in this document.
Figure 5 Various processes in the synthesis of security architecture.
The scope of this specification is the threat analysis, security policy and security requirements.
3.2 THREAT AND VULNERABILITY ANALYSIS The main motivation of threat and vulnerability analysis is to proactively minimise the financial risks associated with implementing and operating a ticketing system according to NORTIC Specifications. Threat and vulnerability analysis in this specification concerns an overall assessment of the most probable threats and the system’s vulnerability to these threats. This will enable the next step, being the definition of a security policy that shall countermeasure the threats.
33
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Figure 6 The various stages and terminology in threat and vulnerability analysis. Possible compromises resulting into loss of assets are dependent on that threats actually are realised as successful attacks (resulting into break of integrity and penetration into assets). The threat analysis includes definition of possible attackers and threat targets (containing assets), and an assessment of the targets’ vulnerability towards methods that attackers apply to retrieve assets. Classification of attackers can be done as follows: •
Class 1: Clever outsiders Might be skilled and have tools intended for attacks, but do have insufficient knowledge of the system and exploits known weakness of the system to meeting their objectives.
•
Class 2: Knowledgeable outsiders Possess specialised technical education, experience, and specialised tools intended for attacks, and have potentially access to the whole system.
•
Class 3: Funded organisations Groups of outsiders possessing specialists, possibly also using class 2 attackers, with state of the art tools intended for attacks and sufficient amount of funding.
•
Class 4: Insiders Have got access to sensitive information, processes and modules that might be exploited by them or any other outsiders.
The classification of attackers (ranging from 1-4) is included to indicate that the higher the class, the higher is the likelihood that severities of the attack are high. On the other hand, the higher (lower) the class given, the lower (higher) number of people might be able to carry out the attack. This may used later to assess the likelihood whether threat results into an actual attack. The Threat Targets are identical to the modules or interfaces between modules carrying assets within the NORTIC system. These are: •
TravelContract
•
MAD of either Application owners and retailers, Product Owners and Retailer and Service Operator
34
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Electronic Messages within the system (Transaction/Payment Information, Settlement, Charge to Account)
The definition of Treat Objects/Assets that may be main objective for attacks is made by means of defining overall threat objectives. An initial assessment is done in the table below. The table is sorted pr threat objective and pr attacker class to provide some initial indication of the probability and severity of various attack strategies. It is the current assessment that since the NORTIC System is intended to providing services against some sort of electronic payment, only various forms of financial gain are considered as primary threat objectives. Generic threats like: ‘misuse of information’, ‘segment integrity breaks’ are considered as a part of the attack strategy. The fact that successful attacks may impose threats to other related systems has been deliberately suppressed in this specification as their vulnerabilities and threat objects cannot be assessed. Primary Threat Objective
Attack Strategy
Likely Attacker
Necessary attacker class
Financial gain by evading payment and/or obtaining free service
Sabotage of MAD
Customers
Class 1
Repudiation of Electronic Payment
Customers
Class 1
Replay of Messages
Customers
Class 2
TravelContract Masquerade
Customers
Class 2
Cloning of TravelContracts
Customers
Class 3, possibly also Class 4.
Financial gain by reselling products
Cloning of TravelContracts
Customers
Class 3, possibly also Class 4.
Financial gain by claiming refund from fraudulent Transactions
Replay of Messages
Service Operators
Class 3 in combination with Class 4
Cloning of Messages Repudiation of Messages
As already indicated, the threat objectives cannot be successfully accomplished without proper attack strategies at hand. These strategies involve combination of computer-aided tools, skilled resources (even insiders) to become effective. In addition, the attacks focus on the vulnerabilities of the system. This includes: •
Modules (software, hardware, disk storage) and Interfaces between them
•
Personnel
•
Routines for handling data
•
Routines for access to sensitive areas (offices)
The attack strategies may be decomposed into classical security attacks methods as given in the below table: Attack Strategy
Primary Attack Methods
Secondary Attack Methods
Repudiation
Denial of used service
None further
Sabotage
Set Service Operator MAD into
None further
35
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
non operational state Product Masquerade
Eavesdropping
None further
Manipulation of data
Alteration of HW and/or SW and/or application data.
Disclosure of Sensitive Information
Theft of MAD
Message Replay
Record and Replay
Eavesdropping and timing attacks
Cloning of TravelContracts
Product Medium Segment Tampering
Theft of TravelContracts in Manufacturing, Distribution or Issuance
Disclosure of Sensitive information
Insider Abuse such that valued information (secret keys) are disclosed. Alteration of HW and/or SW Theft of MAD to retrieve secret keys
Cloning of Messages
Message Replay
Eavesdropping and timing attacks
Disclosure of Sensitive information
Insider Abuse such that valued information (secret keys) are disclosed. Alteration of HW and/or SW and/or application data Theft of MAD to retrieve critical functions (secret keys)
3.3 SECURITY POLICY The NORTIC System Security Policy addresses how the threats specified in section 3.2 shall be controlled taking into account aspects such as •
Protection of the Interests of the Public, i.e. Issue of Fairness and Privacy
•
Financial Loss detection and prevention
•
System design constraints (i.e. cost, functionality and technology limitations with TravelContract)
3.3.1
Protections of the interests of the public
The public interests are founded not only on quantifiable financial aspects but also on human/cultural values. Some overall principles of public interests are formulated below: •
Quality of Service: The NORTIC system shall be used as an instrument to ensure that national/local public transport service strategic goals are met.
36
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Fairness of payment: Customers shall be convinced that everyone is paying the correct amount according to valid charging tables.
•
Public Trust: Customers shall be convinced that they pay the correct amount for the desired service.
•
Public Moral: Deliberate sabotage and fraud should be discouraged and is considered illegal. This is related to the principles of fairness and public trust.
•
Privacy: Misuse of information generated by the NORTIC system shall not be possible.
These principles are of general nature and may not be further specified in specific requirements within this document, but should nevertheless be encountered for and followed within any organisation responsible for public transport services. 3.3.2
Detection and prevention of financial loss
Based on the threat analysis made, many viable attack strategies might be attempted by customers possessing variable skills (various attack classes) that might lead to security compromises. The following strategies to minimise financial loss shall be adopted: 1. Unjustifiable denial of used services shall be discouraged. Routines shall be defined that address the management of disputes between customer and service operator. Due to the different sizes of the various systems accepting a TravelContract, each system implementation is free to define the control of valid TravelContracts. 2. Sabotage against service operator’s MAD shall be discouraged and is regarded as an offence. Requirements for sabotage detection (diagnostics) on the MAD shall be detailed. 3. Masquerade attempts against TravelContracts shall be discouraged and are regarded as an offence. Furthermore successful masquerade attacks, such that they lead to financial loss in the ticketing system, shall not be economically viable for the customers. The NORTIC system shall be prepared to countermeasure extensive attempt to conduct masquerade. 4. Cloning attempts of TravelContracts for unauthorised reselling are regarded as an offence and potentially detrimental to the integrity of the NORTIC system. Therefore, within reasonable cost boundaries, maximum technical efforts should be considered to avoid cloning of the TravelContract. 3.3.3
Trust Levels
The NORTIC system implementations may be of different levels of magnitude and cover different regions. Also the exposure levels of the threat may vary not only due to geographical limitations but also might be time dependent. The trust level can be expressed as the goodwill that exists between entities in the NORTIC system that no human imposed anomalies disrupt the behaviour of the NORTIC system. The trust level may vary with time, magnitude and geographical location of the NORTIC system. Finally the implementation of a NORTIC system will reflect the fact that trust levels determine security requirements. For example, due to the fact that there is a limited number of ProductTC Owners in Norway resulting into a high trust level between them, it is recommendable that ProductTC Owner share a common set of master keys. A Trusted Third Party (TTP) serves as a notary between ProductTC Owners in case of any conflict.
37
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Another example, due to the exposure level due the amount of customers and the financial consequences in case of successful fraud (say reselling cloned TravelContracts) it may be recommendable (but not required) to introduce online verification of TravelContracts.
3.3.4
System specific constraints
Performance factors The NORTIC system shall ensure maximum revenues for the Product owners/Retailers and correct service to the customers having a valid TravelContract. This includes performance factors such as (but not limited to) •
MAD Capacity of handling number of customers with valid TravelContracts
•
Flawless implementation of system functions
•
Available system modules
•
TravelContract Transaction time (with ProductLP Retailer MAD)
These factors provide important constraints for formulation of security requirements, most notably those related to real time verification of the authenticity of the TravelContract. System Cost With system cost, is meant the total ownership costs of the NORTIC System including the costs related to: •
Purchase/ implementation/ installation/ distribution
•
Maintenance / operation
•
Financial Loss (due to security compromises or non-available system modules and services)
Naturally, system costs are highly related to the magnitude of the system (and expected revenues). The relevance of considering the system costs within the security policy considerations is that a best possible compromise must be searched in each implementation. The level of trust between the entities in a NORTIC system implementation and the system magnitude will in each case determine the security level. Therefore, and due to the fact that different implementation scenarios of this specification are indeed foreseen, the security requirements must cater for the fact that actual NORTIC system implementations might focus on minimising implementation costs whereas others might focus on maximising the income flow. Cost and Technology limitations As pointed out in the last section, implementation costs may be the most important economical factor in some systems to meet profitability requirements. Some security relevant critical factors are listed below: •
TravelContract media will have a maximum data communication speed and processing capabilities (mainly related to encryption speed and product data access times). Applicable technology may range from dedicated media accommodating for a minimum set of NORTIC functions – to multi-application supporting media accommodating for both TravelContract and other, possibly non-transport, applications.
•
TravelContract Medium Accepting Device (MAD) will have a limited memory capacity for Products and transaction data, limited processing capabilities and it may or may not have support for Secure Application Modules (SAM).
38
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
TravelContract SAM may have limited capacity for supporting different Products and will have a maximum data communication speed and limited processing capabilities
The security requirements shall cater for the above constraints. It shall be noted that it is not mandatory to include a SAM in the Service Operator MAD.
Critical Roles and Responsibilities within the NORTIC System The following roles/responsibilities have been identified as the most critical for the security policy. 1. Issuing of TravelContract and TravelContract SAM shall be possible by ProductTC Owner. However it has been recommended restricting the TravelContracts to share a common TravelContract master key set. This TravelContract Master Key set will be generated and distributed through a Trusted Third Party (TTP) to each authorised ProductTC Owner. 2. Distribution of TravelContract, TravelContract SAM and MAD shall be done in a secure way in the sense that the ProductTC Owner or corresponding entity is responsible that the concerned modules do not fall into the hands of unauthorised parties. This includes: •
TravelContract must only be distributed to customers identified under a valid contract. The ProductTC Owner is responsible for the security of the TravelContract, including the detection of un-authentic TravelContracts, ensuring adequate measures (such as security listing and introduction of TravelContract SAM for online verification). Furthermore the ProductTC Owner is responsible for recovery from related financial loss towards Retailer(s)/Clearinghouse(s).
•
TravelContract SAM must be installed in MAD or at a centralised office of the ProductTC Owner. The ProductTC Owner is responsible for the administration and logistics of each individual SAM (including keeping them protected against theft).
•
MAD must only be distributed and installed at locations intended for control and/or validation of TravelContracts. The ProductTC Owner is responsible for the administration and logistics of each individual MAD (including keep them protected against theft).
3. Management of sensitive data and modules (keys, TravelContract SAM, TravelContracts) involves the following processes: •
Generation
•
Distribution
•
In/Revalidation
•
Destruction
Due to the criticality and nature of the threats to the concerned system modules, security requirements to all these modules and the related processes must be formulated. 4. Authentication of TravelContract is under the responsibility of the ProductLP Owner or ProductLP Retailer respectively, which also might choose to trust TravelContract on his own risk. 5. Authentication of Transaction Messages is under the responsibility of the ProductTC Owner and/or Clearing House, which also might choose to trust TravelContract on its own risk. 6. Verification of disputes between Customer and ProductTC Owner/RetailerTC shall be enabled through electronic proofs contained in the TravelContract and Transaction Messages resided in the system. The ProductTC Owner/ ProductTC Retailer is responsible of providing such services to the public. 7. Verification of disputes between Product Owners/Retailer/Clearing Houses shall be enabled through electronic proofs contained in the Transaction Messages resided in the
39
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
system. A duly appointed notary / TTP is responsible of providing such services between Product Owners.
3.4 SECURITY REQUIREMENTS The security requirements comprise the last step in defining the overall security architecture for the NORTIC system. This section aims at defining specific security requirement related to entities/ modules and interfaces between the modules. 3.4.1
General Requirements
Security requirements stated below concern those related to ticket media and MAD devices. As a result of a treat analysis the following chapter define the NORTIC security profile and related requirements. Requirement
Requirement
No [R 33]
The NORTIC specification shall include a set of security profiles that enables the ProductTC Owner choose between different levels of security. The NORTIC security profiles are defined as follows: 1. TravelContract issued with security mechanisms, and the ProductLP Owner / ProductLP Retailer will accept TravelContract without security mechanisms 2. TravelContract issued with security mechanisms, and the ProductLP Owner / ProductLP Retailer will only accept TravelContract with security mechanisms
[R 34]
The NORTIC ticket media shall generate a Message Authentication Code (MAC) using the method described in 4.6 Message Authentication Code (MAC) generation. The signature enables the recipient of the transaction (claim) to verify the authenticity and integrity, see NOTE 1.
[R 35]
TravelContract Master keys shall be protected and stored in TravelContract Secure Application Modules (TravelContract SAM) wherever security mechanisms are in use, see NOTE 2.
[R 36]
TravelContract SAM shall support the following functionality: 1. Issuing of the TravelContract 2. Verifying signatures from the TravelContract as detailed in 4.6 Message Authentication Code (MAC) generation. 3. Loading TravelContract master keys into another SAM, as detailed in [R 41] and [R 42] 4. Accepting TravelContract master keys from TravelContract SAM, owned by the TTP, as detailed in [R 41] and [R 42]
[R 37]
ProductTC Owner shall ensure that each TravelContract SAM is uniquely identified and registered.
[R 38]
TTP shall only distribute TravelContract Master keys to a registered
40
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No TravelContract SAM. [R 39]
TTP shall be able to invalidate and destruct distributed TravelContract Master keys to TravelContract SAM.
[R 40]
Any TravelContract SAM in the system shall support the DES and 3DES algorithms in ECB and CBC mode with full 64bit input and output.
[R 41]
Any TravelContract SAM in the system shall provide secure management of keys of relevant types, allowing those keys to be loaded and updated in a secure way.
[R 42]
Key management protocol shall be according to the international standard ISO 11770 Part 1 and Part 3.
[R 43]
The security level of the TravelContract SAM shall be implemented and certified according to Level 2 of FIPS PUB 140-2.
[R 44]
The exact make and type of TravelContract SAM shall be approved by TTP before usage.
[R 45]
When used to verify the TravelContract, the TravelContract SAM shall support an execution time that is compliant with the performance requirements set for the TravelContract.
NOTE 1 Authenticity ensures the senders identity, i.e. provides information that the identity of a source of data received is as claimed. Integrity ensures that received data is unchanged or unmanipulated, i.e. protection against unauthorised modification or deletion of information. NOTE 2 The TravelContract SAM requirements are common for all ProductTC Owners (including their involved Retailers and Service Operators) to enhance interoperability and maintain the trust level between them. Also this issue is necessary to enhance a cost effective solution with acceptable security level. A Trusted Third Part (TTP), appointed by the ProductTC Owners, generates the TravelContract Master keys on behalf the ProductTC Owners and is responsible for ensuring that these keys are distributed to the registered TravelContract SAMs only.
41
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
3.4.2
TravelContract
This sections aim at defining security requirements, specific for the TravelContract. Requirement
Requirement
No [R 46]
Each TravelContract shall be uniquely identified and registered in a list of products issued.
[R 47]
Each TravelContract shall comply to one of the two options: 1. TravelContract issued with security mechanisms, and the ProductLP Owner / ProductLP Retailer will accept TravelContract without security mechanisms 2. TravelContract issued with security mechanisms, and the ProductLP Owner / ProductLP Retailer will only accept TravelContract with security mechanisms
[R 48]
The security mechanisms in [R 33] shall be based on the methods described in 4 Security mechanisms
[R 49]
The only keys stored in the TravelContract are diversified keys (diversified using the TravelContract Identifier).
[R 50]
The TravelContract shall not contain flaws in design, implementation or operation.
[R 51]
Unauthorised disclosure of critical data stored in the TravelContract media shall not be possible.
[R 52]
The execution time of a transaction that involved the TravelContract shall comply with overall performance requirements.
3.4.3
ProductTC Owner / ProductTC Retailer
The section aims at defining security requirements for the ProductTC Owner / ProductTC Retailer and their equipment. For convenience, two sub processes/modules have been identified •
Loading TravelContract on the IC Card
•
Management of transactions (i.e. Clearing System)
Loading TravelContract on the IC card Requirement
Requirement
No [R 53]
The MAD shall contain or – have an online interface to – a TravelContract SAM to enable a secure issuing of the TravelContract with security mechanisms.
[R 54]
The MAD shall prevent any unauthorized access to any TravelContract related data.
42
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
[R 55]
The MAD shall implement mechanisms that ensure availability and recovery of any data if it is defect or malfunctioning.
[R 56]
The MAD shall support access control mechanisms when operated by staff and provide auditing of the operations executed.
[R 57]
The MAD shall record and store securely all data related to issuing of the TravelContracts. Data protection mechanisms may include: •
Data integrity (message authentication codes)
•
Confidentiality (encryption)
•
Entity authentication
[R 58]
The ProductTC Owner shall establish framework for a Contract between the ProductTC Owner and the Customer, which defines the conditions, which under the Customer may use the TravelContract as payment mean, including accepting TTP as a notary. The contractual link between the ProductTC Owner and the Customer also defines how the customers centrally held account is kept in balance.
[R 59]
The MAD shall forward all TravelContract data to ProductTC Owner such that they may be linked to customers centrally held account (for example TravelContract Identifiers). In case data are transferred over an open interface, the following data protection mechanisms apply:
[R 60]
•
Data integrity (message authentication codes)
•
Confidentiality (encryption)
•
Entity authentication
The ProductTC Owner is at all time responsible for keeping the MAD and TravelContract SAM under adequate protection from theft.
Management of Transactions Requirement
Requirement
No [R 61]
The ProductTC Owner Central System shall be able to authenticate itself to other systems/modules (MAD, Retailer’s and Service Operator’s systems)
[R 62]
The ProductTC Owner Central System shall prevent any unauthorised access to any TravelContract related data.
[R 63]
The ProductTC Owner shall strictly control the manufacturing, storage, initialisation, personalisation and distribution of critical components of the Central System.
[R 64]
The Central System shall prevent any unauthorised access to any TravelContract related transaction data.
[R 65]
The Central System shall implement mechanisms that ensure availability and recovery of any data if it is defect or malfunctioning.
43
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
[R 66]
The Central System shall support access control mechanisms when operated by staff and provide auditing of the operations executed.
[R 67]
The Central System shall implement adequate measures to collect and monitor the payment flows and check them against predefined values to detect any abnormal situation.
[R 68]
The Central system shall send a copy of transactions and claims to the TTP.
[R 69]
The Central System shall maintain up-to-date security lists of accepted TravelContracts.
[R 70]
The Central System shall maintain up-to-date security lists of stolen devices (TravelContract, TravelContract SAM, MAD) and implement measures for containment of associated security breaches.
3.4.4
ProductLP Owner / ProductLP Retailer
This section aims at defining security requirements for the ProductLP Owner / ProductLP Retailer and their equipment, typically a MAD. Requirement
Requirement
No [R 71]
The ProductLP Retailer may authenticate the TravelContract and shall in this case use a TravelContract SAM and related verification mechanisms as given in 4 Security mechanisms.
[R 72]
The ProductLP Retailer shall forward the collected TravelContract usage data (transaction) to the ProductTC Owner in order to receive payment.
[R 73]
The ProductLP Retailer shall ensure that Service Operators may forward claims to the ProductLP Retailer in order to receive payment for travels that have been paid with TravelContract occurrences.
[R 74]
ProductLP Owner may receive security lists from ProductTC Owners. It is the responsibility of the ProductLP Owner to distribute the security lists to the ProductLP Retailers to prevent use of blocked TravelContracts.
[R 75]
The ProductLP Retailer equipment shall be capable of authenticating itself to other modules (such as the ProductTC Owner equipment)
3.4.5
Service Operator
This section aims at defining security functions that may be implemented by the Service Operator and his equipment, which is typically a MAD. There are no security requirements to the Service Operator related to the TravelContract, as the purchase of the ticket is done at the ProductLP Retailer equipment. Nevertheless, the ProductLP Owner of local tickets may wish to apply certain requirements related to the validation of the ticket (i.e. electronic ticket). These may be of the same nature as for the ProductLP Retailer, described in the above section.
44
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
3.4.6
Trusted Third Party
This section aims at defining requirements for Trusted Third Party (TTP). TTP functions include notary functions in case of disputes between customer and the NORTIC system and between Product Owners. Furthermore TTP service include approval and registration of new TravelContract SAMs in the system such that security level in maintained over time. The exact organisational context of the TTP is not further defined. Requirement
Requirement
No [R 76]
The TTP shall ensure that all TravelContract SAMs used by the ProductTC Owner are registered.
[R 77]
The TTP shall initialise the TravelContract SAM on behalf of the ProductTC Owner.
[R 78]
The TTP shall generate, and store securely TravelContract Master Keys common for all TravelContracts.
[R 79]
The TTP shall authenticate itself against TravelContract SAM that shall receive TravelContract Master Keys.
[R 80]
The TTP shall download TravelContract Master keys to all TravelContract SAM in the NORTIC System.
[R 81]
The TTP shall receive a copy of all transactions, claims and related security data (message authentication code) and store these data securely for 3 months for notary reasons.
[R 82]
Based on disputes the TTP shall verify events resided between parties.
3.4.7
Interface Service Operator/ ProductLP Retailer – TravelContract media
Requirement
Requirement
No [R 83]
The transaction process shall include the identification of the TravelContract.
[R 84]
The transaction process may include a checking against the security list of accepted TravelContracts
[R 85]
The integrity of the TravelContract identity shall be ensured.
[R 86]
The transaction process shall ensure adequate protection against replay.
[R 87]
The Transaction process shall have an anti-tear mechanisms preventing loss of sensitive data
[R 88]
A minimum level of non-repudiation shall be assured through logging of transactions in the TravelContract media and the MAD.
45
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
3.4.8
Interface ProductLP Retailer – ProductTC Owner
Requirement
Requirement
No [R 89]
Information exchange between ProductLP Retailer and the ProductTC Owner shall include some level of mutual identification of involved parties and communication shall be aborted in cause of failure of such identification, see NOTE 1.
[R 90]
The integrity of critical information exchanged shall be ensured.
[R 91]
The information exchange shall be protected against replay.
[R 92]
Adequate protection against sabotage of the interface shall be ensured.
[R 93]
The interface may realise digital signature mechanisms to ensure a proper level of non-repudiation.
NOTE1: Sufficient level of trust is assumed to exist between ProductLP Retailer and the ProductTC Owner to avoid the use of mutual authentication mechanisms. 3.4.9
Interface TTP – ProductLP Owner / ProductTC Owner / Service Operator
Requirement
Requirement
No [R 94]
Information exchange between Service Operator / ProductLP Owner / ProductTC Owner and the TTP shall include identification and mutual authentication of involved parties and communication shall be aborted in cause of failure of such identification and authentication.
[R 95]
The interface shall realise digital signature mechanisms to ensure a proper level of non-repudiation.
[R 96]
The integrity of critical information exchanged shall be ensured.
[R 97]
If information is transmitted over an open interface, the confidentiality of this information shall be as follows •
Key files (containing TravelContract Master Keys) shall be encrypted using encryption algorithms based on minimum 3-DES and preferably RSA with a minimum key length of 2048 bits
•
Copies of transaction data shall be encrypted using minimum DES (56 bits)
46
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
4 SECURITY MECHANISMS 4.1 NORTIC SECURITY KEYS There are three types of Masterkeys in the NORTIC secret key scheme: •
MkeyN-App(G) (Masterkey for the NORTIC Application)
•
MkeyN-Prod(G) (Masterkey for the NORTIC product TravelContract)
•
MkeyN-MAC(G) (Masterkey for the calculation of the message authentication code MAC)
The (G) denotes the key generation.
The three Masterkeys are the same for all Norwegian electronic ticketing systems providing the NORTIC service. It simplifies the key management but make the keys more vulnerable requiring a high level of key protection.
The (G) shall always be the same for all types of keys. If a key is revealed, e.g. the MAC key, also the application and product key generation shall be changed. However, if the key revealed is the MAC the NORTIC Application and products can still be used due to the split of the three masterkeys in three independent keys. The Masterkeys are used for diversifying the keys stored on the IC card (Customer media): The ICCkeyN-App(G) is diversified from the MkeyN-App(G) using the ApplicationId for the diversification. This key controls the creation and deletion of files in the DF NORTIC and the writing of new keys. It is therefore regarded as the most critical regarding application security. The MkeyN-App is only distributed to organisations that act as Application Retailers for the NORTIC application. The ICCkeyN-Prod(G) is diversified from the MkeyN-Prod(G) using the ApplicationId for the diversification. This key allows writing and updating of the protected files in the DF NORTIC, e.g. changing the data in the TravelContract. The ICCkeyN-MAC(G) is diversified from the MkeyN-MAC(G) using the ApplicationId for the diversification. The key is used for generating the Message Authentication Code.
47
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Figure 7 The secret key hierarchy for NORTIC
4.2 NORTIC APPLICATION KEYS STORAGE The Table 2 shows where the different secret keys are stored. For the NORTIC Application: The NORTIC Application Owner keeps all the three Masterkeys for distribution to authorised Application Retailers who need all three keys for the initialisation of the IC Cards. For the TravelContract: The ProductTC Owner keeps the MkeyN-Prod and the MkeyN-MAC. The MkeyN-Prod is distributed to authorised ProductTC Retailers for loading the TravelContract in the NORTIC application. The MkeyN-MAC is used by the ProductTC Owner for verifying a claim from a ProductLP Retailer who has sold a local product to a Customer using the TravelContract. For the local product: The ProductLP Owner (optionally) keeps the MkeyN-MAC for distribution to ProductLP Retailers in case the local product shall be written to the DF NORTIC / EF LOG which requires an ICC authentication of the MAD using the ICCkeyN-MAC. Entity
NORTIC Application Owner
Key stored in
MkeyNApp(G)
MkeyNProd(G)
√
√
√
√
√
√
√
SAM
NORTIC Application Retailer
MAD with SAM or access to SAM
ProductTC Owner
SAM
√
MAD with
√
(TravelContract)
ProductTC
MkeyNMAC(G)
48
ICC keyNApp(G)
ICC keyNProd(G)
ICC keyNMAC(G)
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Entity
Key stored in
Retailer
SAM or access to SAM
(TravelContract)
ProductLP Owner
MkeyNApp(G)
MkeyNProd(G)
MkeyNMAC(G)
SAM
√ 1)
MAD with SAM or access to SAM
√ 1)
ICC keyNApp(G)
ICC keyNProd(G)
ICC keyNMAC(G)
(local product)
ProductLP Retailer (local product)
Customer
IC card
√
√
√
Service Provider Registrar Security Manager (TTP)
SAM
√
√
√
Table 2: Secret keys storage 1) Optionally. Only for those cases where the TravelContract is used with security when purchasing a local product. The three ICC specific keys are diversified when the NORTIC application is installed on the IC card and stored in the EF-key file in the DF NORTIC.
4.3 ICCKEYN-APP DIVERSIFICATION
1. Let MkeyN-App for a given generation (i) be a Triple DES key (16 bytes). 2. Split the MkeyN-App in two 8 bytes DES keys, K1 (byte 9 – 16) and K2 (byte 1 – 8). 3. Get ApplicationId (125 bits), left justify the ApplicationID and append the bits 0002 achieving a 16 bytes block called P. 4. Encrypt-decrypt-encrypt (3DES) the data block P using the K1 for the first and third operation (encryption) and K2 for the second operation (decryption) achieving the 16 bytes block C. 5. Let the leftmost 8 bytes of C be the ICCkeyN-App(i). EXAMPLE: 1. The MkeyN-App is ’11 22 33 44 55 66 77 88 99 AA BB CC DD EE 1A 2A’. 2. Then the K1 is ’11 22 33 44 55 66 77 88’ and K2 is ‘99 AA BB CC DD EE 1A 2A’.
49
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
3. Assume that the 15 leftmost bytes of the ApplicationId is ’12 23 45 67 89 1A BF ED AE 1D 7D 5C 8C 5F DD’. The rightmost byte is 0111 1bbb2 where b denotes blank bits before the three th 0-bits are appended to form the 16 byte. Then P is ’12 23 45 67 89 1A BF ED AE 1D 7D 5C 8C 5F DD 78’ 4. Assume that the outcome C of the EDEK1/K2 (P) is ‘DE C5 67 F4 D3 22 8B B8 9D A4 56 32 FD B4 CA 71’. 5. Then the ICCkeyN-App is ‘DE C5 67 F4 D3 22 8B B8’.
4.4 ICCKEYN-PROD DIVERSIFICATION
1. Let MkeyN-Prod for a given generation (i) be a Triple DES key (16 bytes). 2. Split the MkeyN-Prod in two 8 bytes DES keys, K1 (byte 9 – 16) and K2 (byte 1 – 8). 3. Get ApplicationId (125 bits), left justify the ApplicationID and append the bits 0002 achieving a 16 bytes block called P. 4. Encrypt-decrypt-encrypt (3DES) the data block P using the K1 for the first and third operation (encryption) and K2 for the second operation (decryption) achieving the 16 bytes block C. 5. Let the leftmost 8 bytes of C be the ICCkeyN-Prod(i).
4.5 ICCKEYN-MAC DIVERSIFICATION
1. Let MkeyN-MAC for a given generation (i) be a Triple DES key (16 bytes). 2. Split the MkeyN-MAC in two 8 bytes DES keys, K1 (byte 9 – 16) and K2 (byte 1 – 8). 3. Get ApplicationId (125 bits), left justify the ApplicationID and append the bits 0002 achieving a 16 bytes block called P. 4. Encrypt-decrypt-encrypt (3DES) the data block P using the K1 for the first and third operation (encryption) and K2 for the second operation (decryption) achieving the 16 bytes block C. 5. Let the leftmost 8 bytes of C be the ICCkeyN-MAC(i).
4.6 MESSAGE AUTHENTICATION CODE (MAC) GENERATION
1. Get the ProductId (126 bits) stored in EF TravelCard and remove the 5 leftmost bits achieving a bitstring called Prod with size 121 bits. 2. Get the ComponentId (39 bits) for the MAD selling the local product 3. Get the DateCompact (16 bits) which is the date of the purchase of the local product. 4. Get the TimeCompact (16 bits) which is the time of the purchase of the local product. 5. Compose the message M by concatenating the values Prod||ComponentId||DateCompact||TimeCompact achieving a 3 x 64 bits data block.
50
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
6. Calculate the MAC according to ISO 8731-1 Banking – Approved algorithms for message authentication Part 1 DEA implying that the MAC will be the 32 leftmost bits of the output of EICCkeyN-MAC (M)
51
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5 IC CARD AND MEDIA ACCEPTING DEVICE (MAD) SPECIFICATION 5.1 INTRODUCTION The NORTIC application and TravelContract defined in earlier chapters and their requirements will in this chapter be broken down and refined into more specific requirements and specifications. The data elements necessary to provide the functionality and security related to NORTIC are defined. These data elements will be organised in data structures that will be stored on files in the NORTIC media. The data elements will as far as possible be chosen from existing international standards in the field of Electronic Ticketing. The NORTIC media will in this version of the specification only be IC cards, so all references to IC card or just card means the NORTIC media. The communication interfaces for the IC card is an important issue for implementers and the goal of this handbook is to give the actors involved the maximum flexibility when choosing reader technology, while still fulfilling the requirement that all IC cards shall be readable on all readers. The different phases a IC card goes through from production to destruction and how this relates to the NORTIC application is also described.
5.2 IC CARD RELATED ROLES AND ENTITIES The following entities are related to the IC cards used in electronic fare collection: •
Card Manufacturer: Is not really a participant directly in the NORTIC system since he only supplies the uninitialised media.
•
Card Owner: In most cases regarded as the owner of the media.
•
ApplicationTC Owner: The entity that owns the NORTIC application installed on the card. It is recommended that this is the same entity as the ProductTC Owner.
•
ProductTC Owner: The entity that owns the product TravalContract installed in the NORTIC application.
•
Customer: The user/holder of the NORTIC media (cardholder).
•
NORTIC TTP: This role is responsible for generating and distributing security keys to the actors involved in the NORTIC application and product.
•
NORTIC Registrar: Can easily be combined with the NORTIC TTP, but have the responsibility to register and organise different types of identification-numbers in the NORTIC system.
52
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.3 CUSTOMER MEDIA REQUIREMENTS
Requirement
Requirement
No [R 98]
The Customer media should be a dual-interface IC card and shall by any case be one of the following categories: Recommended types •
Customer media type 1: Contact interface according to ISO 7816-3 and contactless interface according to ISO 14443 Type A
•
Customer media type 2: Contact interface according to ISO 7816-3 and contactless interface according to ISO 14443 Type B
Alternative types •
Customer media type 3: Contactless interface according to ISO 14443 Type A
•
Customer media type 3: Contactless interface according to ISO 14443 Type B
[R 99]
The dimensions and locations of contacts shall be according to ISO 7816-2.
[R 100]
The electronic signals and transmission protocols shall be according to ISO 7816-3 and ISO 14443-2 and –4 (type A and/or B), and initialisation and anti-collision according to ISO 14443-3.
[R 101]
File structure shall be according to ISO 7816-4.
[R 102]
Data groups, data attributes and data elements shall be according to:
•
ENV 1545 Identification card systems – Surface transport Applications Part 1 General data elements and Part 2 Transport Payment related data elements (under revision 2002/2003).
•
PrENV xxxxx Identification Card Systems – Surface Transport Applications – Interoperable Public Transport Application (IOPTA)
5.4 IC CARD OPERATING SYSTEM REQUIREMENTS (COS)
53
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Requirement
Requirement
No [R 103]
The COS shall be able to have different access rights for reading, writing and creation/deletion of Directory Files (DFs) and Elementary Files (EFs) on the card.
[R 104]
The security features of the card must allow for a minimum of 3 security keys to be defined locally for a DF on the card.
[R 105]
The EFs in the DF shall be configurable to connect any of these three keys to the access rights for reading, writing and file creation/deletion.
[R 106]
The security features of the card must support the Message Authentication Code (MAC) Generation Method defined in chapter 2.
5.5 IC CARD LIFECYCLE The lifecycle of an IC card can be described in 6 phases: 1. Production: This is the actual production of the card, bonding the integrated circuit to contact pads and antenna, and embedding it in plastic. 2. Pre-personalisation: Still at the manufacturer this is a phase where uploading of transport keys, and generation of the Master File (MF) happens. Additional operations based on the wishes of the Card Owner can also be performed. 3. Issuing: This phase is done by the Card Owner after the card is received from the manufacturer. Transport keys are replaced with the Card Owner keys and the environment is prepared for one or more applications. 4. Application Issuing / Product Loading: The application file-structure is generated and separate keys for the application is generated and installed. Then the product is loaded into the application. The card is now ready to be used. 5. Active: Now the card is in the hands of the Customer (cardholder). By accessing several kinds of MADs the cardholder loads products into the card, and gains the right to use PT services offered by Service Operators. 6. Disabled/Blocked/Destroyed: After several years in the active state the card has been considered unsafe, lost or just broken. If possible the card is returned to the Card/Application Owner and destroyed. 5.5.1
Production and Pre-personalisation
These phases have little consequence for the NORTIC application and are mostly an arrangement between the Card Owner and the Card Manufacturer. After normal pre-personalisation the file structure will likely be as presented in the figure o the right
MF
EF-Key (transport
5.5.2
Card Issuing
MF
The Card Owner will have to prepare the card to accept one or more applications, and the first step is to replace the manufacturer transport keys with his own keys.
EF-Key (card owners)
54
EF App Dir
DF NORTIC
EF-Key (NORTIC transport)
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The most practical and secure way to prepare the card for the NORTIC application would be to create the DF for the NORTIC application and create some keys that can be used by the Application Owner without needing to reveal the Card Owner Keys to anyone. It is assumed that there exists a NORTIC Transport Key that can be used for this purpose. This method is not necessary if the Card Owner and Application Owner is the same entity. 5.5.3
Application Issuing
The Application Owner receives the IC card in one of three ways: •
Application Owner is the same entity as Card Owner so no transfer is necessary
•
Application Owner receives the cards directly from the Card Owner.
•
The Customer (cardholder) has received the card from the card issuer and brings the card to the Application Owner for the purpose of acquiring a NORTIC Application and product.
The Application Owner has to replace the NORTIC Transport Keys with his own and then create the remaining necessary files according to 5.6 File Structure Specifications. 5.5.4
Product Loading
After the NORTIC Application issuing the TravelContract can be loaded on the card on the condition that the necessary agreements have been made between Customer (cardholder) and ProductTC Owner. The procedure is simply to write the TravelContract information to the TravelContract file on the card.
5.6 FILE STRUCTURE SPECIFICATIONS The IC card operating system (COS) shall support multiple Directory Files and Elementary Files under the Master File. The following file structure is an outline of how the TravelContract is stored on the card, see Figure 8: File structure for NORTIC application on the next page. The TravelContract is stored alone in a file (EF-TravelCard) while the log file is on a separate file (EF-Log). The definitions of Master File, Directory File and Elementary File are found in ISO 7816-4. 5.6.1
Security Keys
There exists several security keys on the IC card, and they have different origins and use. Card Owner Keys: These keys are stored in the key file in the Master File and are the full responsibility of the Card Owner. These keys control the access to creating and deleting elementaryfiles (EF) and directory-files (DF) under the Master File. They are designated with Card Owner-KeyN and they must exist in a certain number. NORTIC Transport Key: This key is used when the Card Owner have made the NORTIC-DF ready to use by the Application Owner. NORTIC Application Keys: The Application Owner generates and writes the secret keys that are used by the NORTIC application to the card during application issuance using the NORTIC Masterkeys: •
ICCkeyN-App
•
ICCkeyN-Prod
•
ICCkeyN-MAC
55
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.6.2
Detailed specification of application file structure for general ISO 7816 cards.
The figure below shows a fully created NORTIC Application in the IC card file structure.
MF
DF Another Applicatio
EF-Key (card owner)
EF App Dir DF NORTIC
EF-Key (NORTIC Application keys)
EFTravelContract
EF-Log
EF-Local
Figure 8: File structure for NORTIC application
5.6.3
Master File (MF)
The master file and its parameters have usually nothing to do with the NORTIC application, but an example is presented for completeness. Name: Type: Size:
Access Rights:
5.6.4
0x3F00 MF 2k/4k/8k Bytes Right DIR DELETE CREATE
(Dependant on card type) Permission Authentication Authentication Authentication
Key Card Owner-KeyN Card Owner-KeyN Card Owner-KeyN
EF-AppDir
The EF-AppDir is an application directory based on ISO7816-5. If the name of the NORTIC-DF should be variable then the MAD must use the application directory to locate the correct DF. The format of EF-AppDir is defined in ISO7816-5.
56
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.6.5
DF-NORTIC
The DF-NORTIC directory file must be big enough to contain the other files that make the application, but extra space is taken up by the COS so the exact space needed will change for different brands of IC cards. Name: Type: Size:
0x071C DF >300 bytes Right DIR DELETE CREATE
Access Rights:
5.6.6
Permission Authentication Authentication Authentication
Key ICCkeyN-Prod ICCkeyN-App ICCkeyN-App
EF-TRAVELCARD
The file will be the container for both information about the NORTIC application and the TravelContract. Only the NORTIC Application Owner and Product Owner (TravelContract) has the rights to alter the information stored here. Name: Type: Format:
Access Rights:
0x0C7A Fixed 1 record
32 bytes
Right READ UPDATE REHABILITATE INVALIDATE
Permission Always Authenticate Authenticate Authenticate
Key N/A ICCkeyN-Prod ICCkeyN-Prod ICCkeyN-Prod
Contents of file: • The ASN.1 data structure NorTicRecord 5.6.7
EF-LOG
The LOG file will contain information of the last transactions done with the TravelContract, The LOGfile is made of a number of records that is assumed to behave in a “First in, First out” manner. The last record written to will be the first one accessed when reading. Any writings will replace the oldest record. This file is considered UNSECURE (meaning that anyone can write to it) and the information here must be treated accordingly. The number of records will be dependant on available card memory, but minimum number of records should be 3. Name: Type: Format: Access Rights:
0x0106 Cyclic >3 records Right READ UPDATE REHAB INVAL
32 bytes Permission Always Always Authenticate Authenticate
57
Key N/A N/A ICCkeyN-Prod ICCkeyN-Prod
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Contents of file: • All Records - EventRecord 5.6.8
EF-LOCAL
This file is created to have a place to store products or travel rights bought with the TravelContract. The use of this file is optional since the RetailerLP can choose other methods to transfer the product to the customer, e.g. a paper ticket. This file requires authentication before it can be written to, so it is considered secure enough for storage of the intended information. Since the file has limited space there must be a way to discern if the products already stored in the file can be overwritten by new ones. Name: Type: Format:
0x010C Cyclic >3 records
Access Rights:
32 bytes
Right READ UPDATE REHAB INVAL
Permission Always Authenticate Authenticate Authenticate
Key N/A ICCkeyN-MAC ICCkeyN-Prod ICCkeyN-Prod
Contents of file: • All Records - LocalProduct 5.6.9 EF-KEY The content of this file, and even its existence, is mainly dependent on the COS. From the requirements one can say that this file must include at least three different 8 bytes keys and that one of those keys also is used when the key file is updated. The Card Owner or Application Owner only updates the file. Name: Type: Format: Access Rights:
COS dependant COS dependant COS dependant Right READ UPDATE REHAB INVAL
Permission Never Authenticate Authenticate Authenticate
Contents of file: • COS dependant.
58
Key N/A ICCkeyN-App ICCkeyN-App ICCkeyN-App
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.7 DESCRIPTION OF A TRAVELCONTRACT USAGE TRANSACTION Whenever a Customer wants to use his TravelContract for purchasing a local product, e.g. a single ticket for a bus ride, there will be a communication between the IC card (Customer media) and the MAD (Media Accepting Device), e.g. a ticketing machine, operated by the RetailerLP selling the single ticket. The purchasing process can be described by four different phases: •
Initialisation
•
Data retrieval and Data evaluation
•
Authentication (optional)
•
Data storage
5.7.1
Initialisation
This will be different for different equipment, but it is simply a question of getting the MAD and IC card to speak the same protocol and activate the IC card. After activation, the IC card responds with an ATR (for contact communication) or ATS (for contactless communication), which will provide enough information to the MAD to ensure correct communication for the rest of the transaction. 5.7.2
Data retrieval and Data evaluation
Finding the NORTIC Application. This requires the MAD to find the correct DF used as storage for the NORTIC application on that particular card. The following sequence should be performed: Line no 1
Function
ISO command
Select the DF with the NORTIC Application
SELECT FILE (0x071C)
In case function in line 1 fails, the following sequence should be performed 2
Select the Application Directory file
SELECT FILE (AppDir=
3
Read the Application Directory file
READ BINARY
4
Find the NORTIC Application and its corresponding DF name
5
Select the DF with the NORTIC Application
)
SELECT FILE (DF-NORTIC=xxxxx)
If the NORTIC application cannot be found directly or by referencing the Application Directory the transaction will be aborted. Reading the TravelContract data Next step is to collect and decode the information stored in the TravelContract file inside the NORTIC DF.
59
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Line no
Function
ISO command
1
Select the EF with the TravelCard data (EF-TRAVELCARD)
SELECT FILE (0x0C7A)
2
Read the TravelCard data
READ RECORD (1st record, 38 octets)
3
Decode ASN.1 encoded information
In certain systems and in a check-in/check-out environment it may be necessary to read old log events and/or local products to calculate the correct price for the transaction. Hence, line 4 – 7 are optional and could be skipped. 4
Select the EF with the log (EF-LOG)
SELECT FILE (0x0106)
5
Read the last event
READ RECORD (last record)
6
Select the file with the Local products (EF-LOCAL) purchased with TravelCard
SELECT FILE (0x010C)
7
Read the last product
READ RECORD (last record)
Evaluating the TravelContract data Based on the information in the TravelContract the MAD can disqualify it from being used in the proposed transaction. The MAD shall at least check the following information: Line no
Function
ISO command
1
Check the mappingType, keyGeneration and ProductOwner data elements against lists of values that the MAD can or cannot support.
2
Check the ExpiryDate against current date
3
Check the ApplicationID and ProductId against the most recent security list
5.7.3
Authentication (optional)
This phase consists of the necessary operations to gain write access to the IC card and to get a Message Authentication Code (MAC) from the card for an authentication of the TravelContract. NOTE:
The RetailerLP and the ProductTC Owner may have an agreement that the TravelContract may be used without security, i.e. there is no authentication of the TravelContract.
NOTE:
The validation of the TravelCard can be written to the file(s) EF-LOG and the EFLOCAL (optionally). If the validation of the TravelCard shall be written to the EFLOCAL the authentication phase is required.
60
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
IC Card authenticates the MAD (optional) The IC card challenges the MAD that has to respond with the correct answer. A positive result is required for the MAD to write new data to the EF-LOCAL. Line no
Function
ISO command
1
The MAD asks the IC card to return a random number
GET CHALLENGE (Random Number, 8 bytes)
2
The MAD calculates the authentication data using a defined algorithm (DES), the random number and the ICCkeyNMAC that has to be calculated by the MAD based on the MkeyN-MAC and ApplicationId.
3
The MAD returns the authentication data to the IC Card.
EXTERNAL AUTHENTICATION (Reference to the algorithm (DES), reference to the ICCkeyN-MAC, authentication data)
4
The IC card calculates the same authentication data and responds to the MAD. OK means that the MAD is authorised to update data in EFLOCAL, NOK means access is denied.
EXTERNAL AUTHENTICATION Response(OK or NOK)
MAD authenticates IC card (optional) The MAD may authenticate the IC card, i.e. verifying that the IC card is carrying the secret data ICCkeyN-MAC indicating that the IC card is issued by an authorised organisation (Application Retailer). Line no
Function
ISO command
1
The MAD sends a random number to the IC card and asks the card to return authentication data (response to challenge)
INTERNAL AUTHENTICATE(Reference to the algorithm (DES), reference to the ICCkeyN-MAC, Random Number)
2
The IC Card calculates the ‘authentication data’ (response) using a defined algorithm (DES), the random number and the ICCkeyN-MAC
3
The IC card returns the ‘authentication data’ to the IC Card.
4
The MAD calculates the same authentication data and compares it with the ‘authentication data’.
61
INTERNAL AUTHENTICATE Response (authentication data’)
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
IC Card generates Message Authentication Code (MAC) (optional) The IC card may generate a MAC that is used as part of the claim from the RetailerLP to the ProductTC Owner verifying that the IC card is authentic and that it has really been used at the time of purchase. See chapter 3 for further details. Line no
Function
ISO command
1
The MAD sends a message (see chapter 3 for details on message) to the IC card and asks the card to return authentication data (MAC)
INTERNAL AUTHENTICATE(Reference to the algorithm (DES), reference to the ICCkeyN-MAC, message)
2
The IC Card calculates the authentication data (MAC) using a defined algorithm (DES), the message and the ICCkeyN-MAC.
3
The IC card returns the authentication data (MAC) to the IC Card.
4
The MAD calculates the same MAC and compares it with the MAC’.
5.7.4
INTERNAL AUTHENTICATE Response (MAC’)
Data storage
The MAD writes the result of the usage to the IC card. Writing to the EF-LOG is mandatory while writing to the EF-LOCAL requires authentication (IC card authenticates MAD) and is by this optional. Line no
Function
ISO command
1
The MAD selects the EF-LOG
SELECT FILE (0x0106)
2
The MAD writes the data EventRecord to the file EF-LOG
WRITE RECORD (EventRecord)
The following functionality is optional 3
The MAD selects the EF-LOCAL
SELECT FILE (0x010C)
2
The MAD writes the data LocalProduct to the file EF-LOCAL (requires authentication of the MAD by the IC Card)
WRITE RECORD (LocalProduct)
62
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.8 MEDIA ACCEPTING DEVICE (MAD) By a Media Accepting Device (MAD) is meant all equipment that shall communicate with the IC card (Customer media). In general this is card-issuing unit at sales offices, IC card readers/writers in sales offices, ticketing machines and validators. Requirement
Requirement
No [R 107]
The Media Accepting Device (MAD) shall be one of the following categories: Recommended type •
MAD type 1: Contact interface according to ISO 7816-3 and contactless interface according to ISO 14443 Type A and B
Alternative types •
MAD type 2: Contactless interface according to ISO 14443 Type A and B
Ticketing machines and ticketing automats could be of type 1 while validators on transport means, e.g. a bus could be of type 2. [R 108]
The MAD shall accept IC cards with physical characteristics according to ISO 7816- parts 1 & 2 and ISO 14443-1.
[R 109]
The contact interface (if present) shall use electronic signals and transmission protocols according to ISO 7816-3
[R 110]
The contactless interface shall use electronic signals and transmission protocols according to ISO 14443 parts 2 and 4 of Type-A and Type-B), and initialisation and anti-collision according to ISO 14443-3.
[R 111]
The MAD and its application should be able to send commands according to ISO 7816-4 over all its interfaces.
5.9 DATA ELEMENTS The following data elements are used in the NORTIC application. Most of the data types are from the EN1545 standard, and a more detailed description of their use may be found there. Element name
Data type name (EN1545)
Element description
accountNumber
Iai
Account number for the TravelContract
issuingDate
DateCompact
Date of Issuing for the application.
expirationDate
DateCompact
Expiration Date for the TravelContract
expDate
DateCompact
Expiration Date for the Local product
expTime
TimeCompact
Expiration Time for the Local product
63
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Element name
Data type name (EN1545)
Element description
keyGeneration
KeySetVersion
Security identifier, tell which algorithm and key generation to use during authentication
certificate
I4
Message Authentication Code (MAC)
mappingType
MappingTypeCode
Tells which version and variant of this standard to use when interpreting the ASN1 encoded data
transportService
TransportServiceCode
Which transport service has the customer bought rights to, (e.g. Ferry, Local Bus, Regional Bus)
userAction
UserActionCode
Which action describes the users relation to the Transport Service (e.g. Entry, Exit, Validation)
deviceId
DeviceId
Identifier that will point to the specific device (MAD) used during the transaction
stopId
StopId
Identifier for the location of the transaction
productData
OCTET STRING
This is private information is only relevant and understandable by the MADs that will use the local product
ASN.1 Encoding Considering the limited storage space on smartcards and the general practice in related standards like EN1545, it is recommended to use the following the Packed Encoding Rules for transforming data structures to binary data. Requirement No
Requirement
[R 112]
The MAD shall use Packed Encoding Rules (PER) in non aligned mode to encode the ASN.1 datastructures.
64
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
5.10 NORTIC ASN.1 SPECIFICATION The following ASN.1 module shall, in combination with the ASN.1 module from EN1545, provide a complete specification for the data elements that is stored in the files on the IC card. An ASN.1 description of some crucial data elements is given in Annex A. However, the reader should by any implementation ensure that the last version of the EN 1545 is used.
--- This ASN1 module includes definitions for the NORTIC Application --- rfu -> Reserved for Future Use -NorTicCard { iso(1) member-body no(578) HB206(1) card(1) } DEFINITIONS ::= BEGIN EXPORTS; IMPORTS DateCompact, TimeCompact, Price, LocationTypeCode, StopId, , ReferenceNumberFour, SequenceNumberTwo, TransportServiceCode, UserActionCode, KeySetVersion FROM CEN1545; -- The three main records of the filestructure NorTicRecord ::= SEQUENCE { appInfo
NorTicAppInfo,
travelContract
TravelContract,
certificate
I4
} LocalProduct ::= SEQUENCE { productId
ProductId,
expDate
DateCompact,
expTime
TimeCompact,
productData
OCTET STRING
} EventRecord ::= SEQUENCE { header eventDetails
EventHeader, Events
}
65
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
-- structures and building blocks. NorTicAppInfo ::= SEQUENCE { applicationId
ApplicationId
mappingType
MappingTypeCode,
keyGeneration
KeyGeneration,
} ApplicationId ::= SEQUENCE { applicationTemplateId
ApplicationTemplateId,
applicationRetailer
ApplicationRetailer,
componentId
ComponentId,
applicationSequenceNumber
ApplicationSequenceNumber
} ApplicationTemplateId ::= SEQUENCE { applicationOwner
IFMOrganisation,
applicationGenericType
ApplicationGenericType,
applicationSubType
ApplicationSubType
} IFMOrganisation ::= BIT STRING (SIZE(20)) ApplicationGenericType ::= BIT STRING (SIZE(7)) ApplicationSubType ::= BIT STRING (SIZE(7)) ApplicationRetailer ::= IFMOrganisation ComponentId ::= SEQUENCE { componentOwner
ComponentOwner,
componentGenericType ComponentGenericType, componentSerialNumber ComponentSerialNumber } ComponentOwner ::= IFMOrganisation ComponentGenericType ::= BIT STRING (SIZE(7)) ComponentSerialNumber ::= BIT STRING (SIZE(12))
66
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
ApplicationSequenceNumber ::= SEQUENCE { date
DateCompact
time
TimeCompact
} MappingTypeCode ::= SEQUENCE { Version
INTEGER(0..15),
Profile
INTEGER(0..15)
} KeyGeneration ::= KeySetVersion TravelContract::= SEQUENCE { productId
ProductId,
expirationDate
DateCompact,
accountNumber
Iai OPTIONAL
transactionLimit
Price OPTIONAL
} ProductId ::= SEQUENCE { productTemplateId productRetailer
ProductTemplateId, ProductRetailer,
componentId
ComponentId,
productSequenceNumber ProductSequenceNumber } ProductTemplateId ::= SEQUENCE { productOwner
IFMOrganisation,
productGenericType productSubType
ProductGenericType, ProductSubType
} ProductGenericType ::= BIT STRING (SIZE(7)) ProductSubType ::= BIT STRING (SIZE(8)) ProductRetailer ::= IFMOrganisation ProductSequenceNumber ::= SEQUENCE { date
DateCompact
67
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
time
TimeCompact
} EventHeader ::= SEQUENCE { sequenceNumber
SequenceNumberTwo,
date
DateCompact,
time
TimeCompact,
eventProvider
IFMOrganisation,
componentId
ComponentId
} Events ::= CHOICE { empty
[0] NULL,
usage
[1] UsageEvent,
checkin
[2] CheckIn,
exception [3] Exception, rfu1
[4] NULL,
rfu1
[5] NULL,
rfu1
[6] NULL,
private
[7] OCTET STRING
} UsageEvent ::= SEQUENCE { ServiceType
TransportServiceCode,
userAction
UserActionCode,
price
Price
} CheckIn
::= SEQUENCE {
locationType location
LocationTypeCode, StopId,
price
Price OPTIONAL
} Exception ::= SEQUENCE { exceptionCode
I1,
errorText
OCTET STRING
} StopId ::= ReferenceNumberFour END
68
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
69
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
6 CLEARING INTERFACE SPECIFICATION This section defines and specifies the interface between the ProductTC Owner and the ProductLP Retailer. Data exchanged between these entities are:
Transaction information (TravelContract usage information)
Security list
Security data
Data exchange may be channelled through a national collection & forwarding service for the TravelContract, or bilaterally. The actual physical exchange of data is not within the scope of this specification.
6.1 OVERALL INTERFACE REQUIREMENTS Overall interface requirements are listed in the table below: Requirement
Requirement
No [R 113]
[R 114]
The Clearing Interface shall be based on the following standards: o
ISO 14904
o
EN1545
o
CEN TC278/WG3/SG5
Data structures shall be defined using ASN.1 (Abstract Syntax Notation number One).
6.2 INTERFACE DEFINITION In chapter 1 the following entities were identified related to the TravelContract product: •
ProductTC Owner
•
ProductLP Retailer
•
Service Operator
•
Customer
Responsibilities of the ProductTC Owner, ProductLP Retailer, Service Operator and Customer are further detailed in chapter 1. Figure 9 describes the interfaces between the entities. The interfaces are numbered, and a description of the interfaces is given in Table 6-1.
70
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Product Retailer
2b
(TravelContract)
2a
1a
Service Operator
Product Owner (TravelContract)
1b
4b
5a
3a
Product Retailer
3b
(local product)
Customer 4a
5b
Product Owner (local product)
Figure 9: Interfaces between entities
There is a link between the following entities in the figure above: •
ProductLP Owner
•
Service Operator
•
ProductLP Retailer
The interface between these entities is not within the scope of this specification. The Service Operator claims the ProductLP Owner in order to receive payment for the provided transport services. The ProductLP Owner claims the ProductLP Retailer in order to receive income of sold tickets. Table 6-1 Interface description Interface no
Description
Comments
1a
The Customer signs a contract with the ProductTC Owner through the ProductTC Retailer. The contract defines how the centrally held account is kept in balance (e.g. relation to a external financial institution)
1b
The TravelContract is delivered to the Customer. The TravelContract is loaded on the NORTIC Application.
2a
The ProductTC Owner authorises the ProductTC Retailer to sell (deliver) the TravelContract to the customer
2b
ProductTC Retailer forward TravelContract
71
The Retailer may be within the same organisation as the TravelContract Owner, or not.
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Interface no
Description and contractual information to the ProductTC Owner. This includes: •
Security system key generation/version (mandatory)
•
TravelContract status, as described above (mandatory)
•
TravelContract pre-payment minimum balance
•
TravelContract post-payment charge threshold
•
Customer/ticket medium holder info; name, address, etc.
•
Contract status; pre- or post-paid
•
Customer account number
3a
The ProductLP Retailer processes the Customer’s ticket media in order to sell a product (ticket) to the customer using the TravelContract as payment mean.
3b
The ProductLP Retailer collects TravelContract usage data (sale of product)
4a
The Service Operator validates the ticket sold to the Customer by the ProductLP Retailer
4b
The Service Operator collects product usage data concerning tickets.
5a
The ProductLP Retailer forwards TravelContract usage data to the ProductTC Owner
5b
The ProductTC Owner distributes security lists to the ProductLP Retailer to prevent use of blocked TravelContract occurrences.
Comments
The TravelContract usage data is a claim towards the ProductTC Owner in order to receive payment for the sold product (ticket).
In the general model there is a direct link between the ProductTC Owner and the ProductLP Retailer direct data exchange between these entities. In a situation where a national collection & forwarding service is established, data exchange is routed via this service. This situation is illustrated in Figure 10.
Product Owner (TravelContract)
National Collection & Forwarding Service
Product Retailer (local product)
Figure 10: National Collection & Forwarding Service
72
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Responsibilities of a National Collection & Forwarding Service: •
Collect TravelContract usage from ProductLP Retailer accepting the TravelContract as payment mean
•
Forward TravelContract usage data to the ProductTC Owner
•
Collect security list from all ProductTC Owners
•
Distribute a complete security list to all ProductLP Retailers accepting the TravelContract as payment mean
6.3 CLEARING INTERFACE SPECIFICATION In this section the data exchange between the ProductTC Owner and ProductLP Retailer is specified. Data exchanged between these entities are: •
TravelContract usage data (transaction information)
•
Security list
•
Security information
Requirement
Requirement
No [R 115]
6.3.1
All ProductTC Owners and ProductLP Retailers have to comply with the NORTIC Clearing Interface specification.
Header
The actual data exchange method is not within the scope of this specification. The following data exchange methods may be used: •
File transfer
•
Message delivery (message service)
The files or messages contain either TravelContract usage data or security list entries. A file/message header marks the start of a file or message. File/Message header Data section (e.g. TravelContract usage data) Figure 11: File/Message header and tail
The file/message header section elements: Header data element
Description
File/Message type
Describes file or message type (TravelContract usage data or
73
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Header data element
Description security list)
Version
File or message version
File date
File creation date
File sender
File sender identification (e.g. ProductLP Retailer )
File receiver
File receiver identification (e.g. ProductTC Owner)
File/Message sequence number
A numbering scheme used to number files or messages sequentially.
File/Message size
Total number of bytes in file or message
Message header ASN.1 definition:
MessageHeader ::= SEQUENCE { messageType
INTEGER(0..255),
version
INTEGER(0..255),
messageDate
DateCompact,
messageSender
CompanyID,
messageReceiver
IFMOrganisation,
messageSerialNumber
INTEGER(0..4294967295) OPTIONAL,
messageSize
INTEGER(0..4294967295) OPTIONAL
} 6.3.2
TravelContract usage data (transaction information) specification
The ProductLP Retailer forwards TravelContract usage data (transaction information) to the ProductTC Owner in order to receive payment for provided transport services. The TravelContract usage data is composed of three parts: •
Event header
•
Event data
•
TravelContract data
TravelContract product usage data description: Data field
Description
Event header
Data elements in event header: •
Sequence number
•
Date of event
•
Time of event
•
Event provider
•
Device ID
74
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Event data
Data elements in event data:
TravelContract
•
Service type
•
User action
•
Price
Data element in TravelContract data: •
ApplicationId (identifies a unique NORTIC Application)
•
ProductId (identifies a unique TravelContract)
•
Expiration date
•
Account number (optional)
•
Transaction limit (optional)
TravelContract usage ASN.1 definition:
TravelContractUsage ::= SEQUENCE { eventHeader
EventHeader,
eventData
UsageEvent,
travelContractData
TravelContractData
} EventHeader ::= SEQUENCE{ sequenceNumber
SequenceNumberTwo,
date
DateCompact,
time
TimeCompact,
eventProvider
IFMOrganisation,
componentId
ComponentId
} UsageEvent ::= SEQUENCE { serviceType
TransportServiceCode,
userAction
UserActionCode,
price
Price
}
75
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
TravelContractData ::= SEQUENCE { ..applicationId
ApplicationId
productID
ProductID,
expirationDate
DateCompact,
accountNumber
Iai OPTIONAL,
transactionLimit
Price
} ProductId ::= SEQUENCE { productTemplateId
ProductTemplateId,
productRetailer
ProductRetailer,
componentId
ComponentId,
productSequenceNumber
ProductSequenceNumber
} ProductTemplateId ::= SEQUENCE { productOwner
IFMOrganisation,
productGenericType
ProductGenericType,
productSubType
ProductSubType
} ProductGenericType ::= BIT STRING (SIZE(7)) ProductSubType ::= BIT STRING (SIZE(8)) ProductRetailer ::= IFMOrganisation ProductSequenceNumber ::= SEQUENCE { date
DateCompact
time
TimeCompact
}
6.3.3
Security list specification
The ProductTC Owner is responsible for distributing security lists to all ProductLP Retailer accepting the TravelContract as payment mean. The security list contains a list of blocked TravelContract occurrences and is distributed to ProductLP Retailer to prevent use of any blocked TravelContract occurrence. Any ProductLP Retailer receiving a security list shall acknowledge the reception.
76
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Security list data elements: Data field
Description
TravelContract identification
Unique card identification. The TravelContract is installed in a card uniquely identified by Card ID.
Block datestamp
Date of blocking
Block timestamp
Time of blocking
List reason
Reason for blocking, e.g. lost card
List Action Code (for future use)
Specifies action to be taken by the MAD, e.g. block the card physically
Security list ASN.1 defintion:
Securitylist ::= SEQUENCE { productId
ProductId,
date
DateCompact,
time
TimeCompact,
listReason
INTEGER (0..255),
actionCode
INTEGER (0..255)
}
6.4
SECURITY DATA SPECIFICATION (OPTIONAL)
The security data include secure distribution of master keys (MkeyN-MAC) from the ProductLP Owner to the ProductLP Retailer SAM based on the assumption that all Masterkeys are distributed from the TTP to the Product Owners and from the Product Owners to the Product Retailers. Before any distribution can occur, the Product Owner must authenticate the Retailer and his TravelContract SAM(s) that are candidates to receive the MkeyN-MAC. Consequently two data files are defined: •
TravelContract SAM Public key certificate
•
MkeyN-MAC file
6.4.1
TravelContract SAM Public key Certificate Specification
The retailer will have to submit to the Product Owner the TravelContract SAM Public key certificates(s) such that the product owner may authenticate the Retailer and his TravelContract SAM(s). TravelContract SAM Public key certificate file data elements: Data field
Description
Retailer Public key
Public portion of the key of the Retailer.
77
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Retailer Id
Identity of ProductLP Retailer that requests a MkeyN-MAC file from the ProductLP Owner
Retailer Public key certificate
Public key certificate of the ProductLP Retailer (structure that include digital signature of the retailer, validity period of the public key certificate, preferred symmetric key encryption algorithm)
TravelContract SAM Public key
TravelContract SAM Public key data
TravelContract SAM identification
Unique TravelContract SAM identification. Each TravelContract SAM shall be unique identified by TravelContract SAM identifier within the NORTIC system.
Start date
First valid date of the TravelContract SAM public key certificate
End date
Last valid date for the TravelContract SAM public key certificate
TravelContract SAM Public key certificate
Public key certificate of the TravelContract SAM (structure that include digital signature of the TravelContract SAM, validity period of the public key certificate, preferred symmetric key encryption algorithm, for use as TravelContract SAM key encryption key )
6.4.2
TravelContract Key File specification
The ProductLP Owner is responsible for distributing authentication key files to all ProductLP Retailers accepting the TravelContract product as payment mean. The authentication master key files contain encrypted authentication master keys. These files are unique for each SAM as different Retailers may use over time and various types of SAM. The Master keys are encrypted using an appropriate cryptoalgorithm (3-DES or RSA or similar). TravelContract Key File Data elements: Data field
Description
ProductLP Owner
Identifies the ProductLP Owner
Event Datestamp
Date of event (data of distribution of the TravelContract SAM Key file)
Event Timestamp
Time of event (time of distribution of the TravelContract SAM Key file)
Retailer
Retailer that is receiving the key file for later distribution to the concerned TravelContract SAM
TravelContract SAM identification
Unique TravelContract SAM identification. Each TravelContract SAM shall be unique identified by TravelContract SAM identifier within the NORTIC system.
Start date
First valid date for the master keys
End date
Last valid date for the master keys
Key Encrypting key
Optional key encrypting key (always encrypted by RSA)
Key Encryption Algorithm Id
Identifier of Encryption algorithm used to encrypt the authentication master keys
Encrypted set of TravelContract
Set of Key Generation and Master Key
78
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Data field authentication master keys
Description
79
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
7 TEST GUIDELINES 7.1 INTRODUCTION The NORTIC specification defines all the necessary requirements in order to purchase and implement equipment and functionality of the interoperable TravelContract. In order to ensure that the implementation is according to the specifications it is necessary to perform various conformance tests, which should be accepted by the appropriate organisation or authority. The purpose of the tests is to obtain approval for use of the NORTIC equipment and the TravelContract. Final approval of an interoperable system will consist of various tests, including, but not limited to, •
Documentation of conformance to specific standards,
•
Performing tests at specific test houses,
•
Performing tests on site in the system environment.
It is important to note that only tests related to interoperability and conformance to these NORTIC specifications are handled in this document. Other tests which will be necessary to verify system functionality is the responsibility of each operator, and are outside the scope of this specification. This specification includes guidelines and proposed methodology for performing tests, it does not contain the final test procedures, which are to be defined later.
7.2 ENTITIES AND ROLES Entities and roles of interoperable fare management systems have been discussed in earlier chapters, and it’s referred to those for descriptions. In this chapter is discussed the particular role with concerns to test and approval. Overall test authority – The Ministry of Transport and Communications and Norwegian Public Roads Administration who shall be responsible for providing necessary tools for performing the tests. These are test specifications, test reference equipment, laboratories. Product Owner – Being responsible for the TravelContract, the ProductTC Owner is also responsible for that the system and equipment purchased and installed is compliant to the NORTIC specifications and achieves the final approval for use. Retailers – The same requirement applies for the Retailers as those for the Product Owners in relation to equipment and system components in use for the TravelContract. Performing the tests consist of different phases and functions, which has to be realised: •
Test description/specifications
•
Test equipment and tools
•
Test execution and reporting
•
Test approval (verdict criteria)
7.3 TESTING Within NORTIC it is relevant to categorise the various tests into the following groups;
80
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Reference Pre-tests
•
Functionality Tests
•
Quality Tests
Reference Pre-tests The reference pre-tests are tests of equipment and their interfaces that verify requirements referenced by standards in this specification. Examples are compliance to interface standards such as ISO7816-3 and ISO14443, EMC/EMI standards and security standards such as FIPS140-2. Independent test houses (preferred option) or the manufacturers themselves can perform these tests. The results of these tests should always be supported by documentation that is verified and signed by a third party. Functionality tests Functionality Tests are related to test procedures, which aim is to verify the functionality of the NORTIC equipment, claiming conformance to this Specification. Quality Tests Quality Tests are related to test procedures that verify certain performance aspects of the TravelContract system and modules. These aspects may include transaction time, error rates (MTTF). All tests are described by means of •
Requirement(s), referring to the requirements in Part 1 and Part 3.
•
Test object, the object (system) under test intend to comply with the requirements. The manufacturer of the test object shall -prior to testing- document whether the test object has been subject to compliance testing or whether he relies on self-declaration.
•
Prerequisite(s), all conditions necessary to carry out the test
•
Verification method(s), method of verification2; inspection of documentation, simulation, fieldtesting applying the test object in a test environment.
•
Verdict criteria; criteria to judge the test object compliant (‘Pass’) or non-compliant (‘Fail’) to requirements. Unless, otherwise stated, the Product Owner is responsible for conducting and documenting the verdict according to the stated criteria, and he shall document that he has accepted the test object for use in his ticketing system. He is liable for using a test object proving a later non-compliance of the test object after a Pass verdict
2 It shall be noted that it is highly recommended that the Product Owner require that the manufacturers perform dedicated tests by independent test -and certification bodies. However, the incurred costs are expected to be high, such that a range of tests within this test specification are limited require reports of already completed tests or the manufacturer’s self-declaration of the test object.
81
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
7.4 REFERENCE PRE-TESTS This section is dedicated to specific reference pre-test are required to fulfil the TravelContract requirements. Priority has been given those requirements, which are essential to interoperability within the NORTIC system.
Test id
Parameters
Description
T-1.
Test Object
IC Card and related documentation intended for use as NORTIC payment medium.
Requirements
Part 1 K7
The NORTIC payment medium shall be an IC Card preferably with a dual interface.
Part 1 K8
The physical characteristics of the ticket medium shall be according to ISO 7816-1 and ISO 14443-1.
Part 1 K9
The dimensions and locations of contacts shall be according to ISO 7816-2.
Part 1 K10
The electronic signals and transmission protocols shall be according to ISO 7816-3 and ISO 14443-2 and –4 (type A and/or B), and initialisation and anti-collision according to ISO 14443-3.
Part 1 K11
File structure shall be according to ISO 7816-4. Commands shall preferably be according to ISO 7816-4.
Part 1 K12
The ticket medium shall support contactless communication according to ISO 14443 Type A or contactless communication according to ISO 14443 Type B. Preferably the IC card shall support contact communication according to ISO 7816 -3.
Part 1 K14
The COS shall be able to have different access rights for reading, writing and creation/deletion of Directory Files (DFs) and Elementary Files (EFs) on the card.
Part 1 K15
The security features of the card must allow for a minimum of 3 security keys to be defined locally for a DF on the card.
Part 1 K16
The EFs in the DF shall be configurable to connect any of these three keys to the access rights for reading, writing and file creation/deletion.
Part 1 K17
The security features of the card must support the MAC generation according to Part 1 Chapter 2.
Prerequisite
Available documentation from manufacturer / test reports of Test Object in Evaluation intended to meet the Requirements. The manufacturer shall pro-actively specify any deviation from the requirements to obtain valid waivers from the TravelContract Product Owner.
Verification Method
Inspection of documentation / test reports. The ProductTC Owner shall document that he has inspected available documentation / test reports.
82
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Test id
Parameters
Description
Verdict criteria
Pass: Inspection of the documentation is identifying the Test Object being compliant with the requirement. Fail: Inspection of the documentation is not identifying the Test Object being compliant with the requirement (or is inconclusive). The IC Card is not approved to be used in the NORTIC Ticketing system.
T-2.
Test Object
MAD intended for use in the Nortic System and equipped with TravelContract application and the related documentation.
Requirements
Part 1 K18
The MAD shall support contactless communication according to ISO 14443 Type A and contactless communication according to ISO 14443 Type B. Preferably the MAD shall support contact communication according to ISO 7816 -3.
Part 1 K20
The MAD shall accept smart cards with physical characteristics according to ISO 7816- parts 1 & 2 and ISO 14443-1.
Part 1 K21
The contact interface (if present) shall use electronic signals and transmission protocols according to ISO 7816-3
Part 1 K23
The contact less interface shall use electronic signals and transmission protocols according to ISO 14443 parts 2 and 4 of Type-A and/or Type-B), and initialisation and anticollision according to ISO 14443-3.
Part 1 K24
The MAD and its application shall be able to send commands according to ISO 7816-4 over all its interfaces.
Part 3
The MAD may contain a TravelContract SAM (optional)
Prerequisite
Available documentation / test reports from manufacturer of the Test Object intended to meet the Requirements. The manufacturer shall specify which of the optional requirements that are fulfilled.
Verification Method
Inspection of documentation. The Product Owner (Retailer) shall document that he has inspected available documentation / test reports.
Verdict criteria
Pass: Inspection of the documentation concludes that Test Object is compliant with the requirements. Fail: Inspection of the documentation is not identifying that the Test Object being compliant with the requirements (or inspection is inconclusive). The MAD is not approved used in the NORTIC Ticketing system.
T-3.
Test Object
TravelContract SAM (optional within the NORTIC Ticketing System)
Requirements
Part 1 K24
Supporting the DES and 3DES algorithms in ECB and CBC mode with full 64bit input and output.
Part 1 K25
Provide secure storage of keys of relevant types, allowing those keys to be loaded and updated in a secure way.
Part 1 K26
The SAM shall support both the MAC generation as defined in Part 3 Chapter 2.
83
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Test id
Parameters
Description Part 1 K27
Prerequisites
The security level of the SAM shall be implemented and certified according to Level 2 of FIPS PUB 140-2.
The Test Object shall be accompanied with documentation proving that it has been tested/verified according to requirement Part 1 K27. Furthermore documentation shall indicate how the SAM may be used in a MAD. Sample IC Cards and MADs with a TravelContract application shall be available for functionality tests and the test object shall be installed into the MAD according to documentation.
Verification Method
Inspection of documentation of the Test Object. The Product Owner is responsible for declaring that the Test Object fulfils the requirements.
Verdict criteria
Pass: The documentation of the Test Object is found to be compliant with the requirement Fail: The documentation of the Test Object is not found (or is inconclusively) to be compliant to the requirements
7.5 FUNCTIONALITY TESTS Functionality tests aim at verifying the TravelContract functionality, essential for interoperability in the sense that it shall be checked that mandatory data are transmitted over relevant interfaces between IC Card, MAD and Clearing modules at the Product Owner, in accordance with the NORTIC specification. T-4.
Test Object
IC Card - MAD Interface
Requirement
Part 2 R16
The ProductTC Owner is responsible managing the customer data and the status of the TravelContract occurrences. Mandatory data are: Card ID Security system key generation/version TravelContract status, as described above
Part 2 R17
The format of the NORTIC Application Identifier shall be in accordance with ISO7816-5.
Part 2 R23
The NORTIC ticket medium shall generate a MAC (Message Authentication Code), which enables the ProductTC Owner to verify the authenticity and integrity of the claim (transaction).
84
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Prerequisite
Approved IC Card, according to test T-1 and approved MAD, according test T-2. If applicable approved SAM according to T-3. The IC Card shall have a TravelContract application (files and data elements) according to Part 1. The manufacturer shall declare which of the Ticket media option that are implemented. The MAD shall have a TravelContract application. The manufacturer shall declare: •
Which ticket media options are implemented.
•
Whether the MAD has got a SAM, intended to verify MAC according to T-3.
•
Which optional data from the IC Card that are read
The manufacturer of the MAD shall propose and seek approval from the TravelContract owner for a test log interface, enabling inspection of the test results. Verification Method
Functionality Test: 1) Depending on the MAD type, the ICC shall be inserted once into (ISO7816) or moved once in front of (in case of ISO14443 A or B), the MAD. All available combinations of IC cards and MADS shall be subject to test. 2) The MAD shall read data from the IC Card and generate a TravelContract transaction.
Verdict criteria
Pass: The MAD retrieves from the IC Card all the requested data If TravelContract SAM declared, the MAD verifies the MAC from the IC Card. Fail: The event of any of the requirements above that is not fulfilled.
T-5.
Test Object
Interface between ProductLP Retailer (MAD) – ProductTC Owner modules
Requirement
Part 2 R22
The ProductLP Retailer is responsible for collecting TravelContract usage data. Product usage data is the transaction information generated when the product is used, and includes payment information. The transaction data is forwarded to the ProductTC Owner in order to receive payment for the actual customer travel.
Part 2 R28
The ProductTC Owner manages and distributes security lists to the ProductLP Retailer accepting the TravelContract as payment mean.
Part 2 R29
The ProductLP Retailer shall acknowledge the reception of security lists from the ProductTC Owner and shall distribute the security list to all user equipment/MAD.
Part 2 R31
The ProductLP Owner and ProductLP Retailer MAD SAM shall exchange authenticated public keys.
85
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Prerequisite
All pre-requisites of T-4 also apply for this test. In addition: Approved MAD according to T-4 with a valid security list but without any generated transactions/events. Two IC Card qualified according to T-4. (One IC Card on the security list and one, which is not).
Verification Method
Functionality tests: 1) Move/Insert the two IC Cards into/in front of the MAD The MAD shall generate one transaction with IC Card not on the security list and refuse the IC Card on the security list. In both cases the MAD shall generate a transaction record (payment, event report) 2) Download into the MAD a new security list containing both IC Cards 3) Repeat step 1) 4) The MAD shall refuse both IC Cards and generate an event report 5) Download into the MAD a new security list containing none of the IC Cards 6) Report step 1) The MAD shall make transactions with both IC Cards and generate a transaction record. 7) The MAD shall have made three transaction records and three event reports (refusal of the IC Cards). A transaction file shall be sent to the ProductTC Owner.
Verdict criteria
Pass: Step 1) through 7) are performed without error and in accordance with format of Chapter 3. Security list correctly received by the MAD. Fail Any of the conditions in step 1) through 7) not fulfilled.
T-6.
Test Object
Interface MAD - Product Owner Module (SAM). This test shall be carried out when MAD is equipped with a SAM.
Requirement
Part 2 R30
The ProductTC Owner is responsible for selecting the appropriate authentication mechanism of the TravelContract (symmetrical versus asymmetrical) and provides a secure download of authentication keys to the IC card.
Part 2 R31
The ProductTC Owner and Retailer MAD SAM shall exchange authenticated public keys.
Part 2 R32
The ProductTC Owner shall distribute the TravelContract authentication master keys according to ISO11770 Part 3 – Key Transport Mechanism 3 or higher.
86
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Prerequisite
All pre-requisites of T-4 also apply for this test. The MAD SAM contains a valid set of authentication master keys. There shall be one IC Card with valid keys and one IC Card without. None of the IC Cards are on the security list.
Verification Method
Functionality Test 1) Move the two IC Cards into/in front of the MAD The MAD shall make transactions with each IC Card and validate the signatures. One IC Card shall be refused whereas one shall be accepted. The transaction file shall log both event (payment and event) 2) ProductTC Owner shall download a new set of TravelContract authentication master keys to the MAD SAM. The valid IC Card becomes invalid whereas the invalid IC Card becomes valid. 3) Repeat step 1 One IC Card shall be refused whereas one shall be accepted. The transaction file shall log both events (payment and event). In total the MAD (SAM) has generated two valid transactions (authentication is OK) and two events (authentication failures) and transmitted them to the Product Owner.
Verdict criteria
Pass: All steps 1) through 3) are completed successfully and in accordance with requirements. Fail Any step 1) through 3) failed or not in accordance with requirements.
7.6 QUALITY TESTS The quality tests are set of tests that affect the overall performance of the system but does not necessarily hamper interoperability. T-7.
Test Object Requirements
IC Card – MAD transaction time Product Owner shall state which transaction time that applies for his system
87
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Prerequisite
MAD completed tests T-1 through T-5. The manufacturer/product owner shall declare whether T-6 is done. One IC Card with TravelContract application shall be available. The manufacturer shall provide necessary equipment necessary to measure the transaction time between the IC Card and MAD and seek approval for the test set up by the Product Owner.
Verification Method
Functionality test: 1) Move the IC Card into/in front of the MAD, which generates a transaction. 2) The transaction time shall be measured.
Verdict criteria
Pass: Transaction time less than equal to requirement. Fail: Transaction time more than requirement
T-8.
Test Object Requirement
MAD Transaction Storage Capacity The Product Owner shall declare the transaction storage capacity that the MAD shall have. (Maximum number of transaction entries before its memory is full)
Prerequisite
MAD completed tests T-1 through T-5. The manufacturer/product owner shall declare whether T-6 is done. One IC Card with TravelContract application shall be available.
Verification Method
Functionality Test: 1) Move the IC Card into/in front of the MAD, which generates a transaction. 2) Repeat step 1) until requirement is reached. The MAD shall be able to store the number of transactions and forward these to the Retailer office/Product Owner
Verdict criteria
Pass: Transaction capacity more than or equal to requirement. Fail: Transaction capacity less than requirement
T-9.
Test Object Requirement
Prerequisite
MAD security list storage capacity The Product Owner shall declare the security list storage capacity that the MAD shall have. (Maximum number of security list entries before its memory is full) MAD completed tests T-1 through T-5 and T-8. The manufacturer/product owner shall declare whether T-6 is done. One IC Card with TravelContract application shall be available.
88
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Verification Method
Functionality Test: 1) Download to the MAD a security list with maximum number of security list entries. 2) Move the ICC into/in front of the MAD 3) Report Step 2) until the maximum number of transactions capacity is reached. The MAD shall be able to store the number of transaction and forward these to the Retailer office/Product Owner
Verdict criteria
Pass: Security list capacity more than or equal to requirements Fail: Security list capacity less than requirements
T-10.
Test Object Requirements
MAD autonomous time of storage/operation The Product owner shall declare maximum time period of autonomous storage/operation that the MAD shall have. E.g. The time the MAD can store data without external power supply.
Prerequisite
All tests T-1 through T-9. The manufacturer/product owner shall declare whether the MAD has got a SAM and whether T-6 is done. The manufacturer shall declare whether the MAD is capable of performing transactions when its external power shut off.
Verification Method
Functionality test: 1) Move IC Card into/in front of the MAD. 2) Repeat step 1) 100 times 3) Shut off the external power 4) If supported as per manufacturer declaration repeat step 1 and 2. 5) Verify storage operation at required maximum autonomous time, by downloading the transaction to retailer / product owner modules
Verdict criteria
Pass: Autonomous storage/operations time more than or equal to requirements Fail: Autonomous storage/operations time
T-11.
Test Object Requirements Prerequisite
MAD duration time The Product Owner shall declare the maximum duration time of the MAD (MTTF) MAD completed test T-1 to T-10. ICC complying with requirements.
89
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Verification Method
Functionality test:
Verdict criteria
Pass: Flawless operation during acceleration tests with a duration time according to requirements
Acceleration test on the MAD should be performed aiming at verifying its critical functions, such as IC Card interface at climatic conditions existing within ticketing environments. This includes high relative humidity (70-95%), temperature ranges (-40 + 85 deg Celsius), temperature variations 40 deg Kelvin/5 minutes and vibrations. With reference to ISO10373 part 3 and part 5, the IC Card manufacturer shall declare the set of tests, to which the MAD has been exposed.
Fail: non-compliance or inconclusiveness
90
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8 NORTIC SPECIFICATION FOR MIFARE DESFIRE (NSD) The NORTIC specification for mifare DESFire (NSD) is based on [19] which covers the smartcard layout and structure for the Oslo projects and is part of the system specification produced for the participants in the Oslo projects (Oslo Sporveier, Stor-Oslo Lokaltrafikk and NSB). Further information is given in Annex A. Only the parts of the specification that is deemed relevant for inter-regional interoperability is included. Some Oslo-specific parts (i.e. the chapter about zone codification) are included in annexes, as they can be used as a basis for developing similar coding schemes for other regions. In the same way, product descriptions are included as annexes – both as descriptions of possible interoperable products, and as a basis for developing new products. The full specification – covering the whole range of issues needed to obtain interoperability - is available as reference material.
8.1 DESFIRE GLOBAL STRUCTURE 8.1.1
Memory Management
The DESFire component has a 4 kbyte Non Volatile memory, which is arranged as a file system as follows : •
28 directories so-called "applications" according to the DESFire terminology, identified by their Application IDentifier (3 byte AID).
•
16 files per “application” at most : o
Files numbered from 0 to 7 feature a transaction backup whereas others (8..15) do not,
o
Each file has a length (in bytes) coded on 3 bytes (0 … 0xFF FF FF)
o
Each file can be managed (creation, suppression, …) at any time i.e. during initialisation, personalisation and in the field.
Thus the directories are similar to DF (Dedicated Files) and files to EF (Elementary Files) as referred to contact IC-cards (see ISO 7816-x standard). Please note that term Application used in the DESFire specification is different from the term Application as defined in the CEN and ISO standard for Interoperable Fare Management System Architecture (IFMSA). It is to be noted that an Anti-tear mechanism is provided which uses the built in transaction backup feature. If backup files are considered as consistent (i.e. transaction is consistent), an external command (commit transaction) will validate these file modification in the corresponding normal files in one shot. for all modified backup files within one application. 8.1.2
File types
The files within an application can be of different types as : •
Standard files,
91
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Backup Data files,
•
Value files with backup,
•
Linear record files with backup,
•
Cyclic record files with backup.
Note that the backup feature doubles the required memory space allocated for each file.
8.2 NORTIC DESFIRE MEMORY ORGANISATION In order to accommodate requirements for both regional, inter-regional and national interoperability, the IC-card must be prepared to accommodate several Dedicated Files (DF): 1. Master File 2. One DF for card issuer identification and information (mandatory) 3. One DF for local, regional and inter-regional use based on the NORTIC DESFire specification 4. One DF for national interoperability based on the NORTIC TravelContract specification 5. Possibly more NORTIC-based applications for specific inter-regional interoperability based on the NORTIC concept (Charge-to-account) 6. There should also be room for future extensions – i.e. multi-leg tickets
Figure 12: Memory organisation The figure above shows how this can be done on a DESFire smartcard. There is sufficient space on the card to accommodate one big application, e.g. the CRSI as well as several smaller (NORTIC, multi-leg tickets, …). There is, however, not enough space to accommodate two different applications of the same size as the CRSI.
92
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8.3 SECURITY FEATURES 8.3.1
Data transmission
Data transmission between the IC-card and the reader can be achieved according to 3 security levels : •
Plain text : Data is exchanged in clear text,
•
MACed : An authentication checksum computed with the session key is added at the end of the data transmission (DES/3 DES MAC computation)
•
Encrypted : Data is enciphered using the session key (DES/3DES).
Communication settings apply on file level and are set up at file creation using the appropriate DESFire command. Adding a MAC or encrypting each transmission can be time consuming, both for the card and for the CAD. As a trade off between performance and security the choices made for the NSD DESFire card is to use MACed communication only for operations on files that are written most of the time. Section 9 gives for each file the communication settings used during communication with each file. 8.3.2 File access conditions Access to data files is granted on application level using a mutual authentication mechanism, which involves a secret key. Prior to data transmission, a mutual three pass authentication is performed between the card and the reader. That allows any further communication to be achieved on three security levels (see 8.3.1 above) For each application, up to 14 different keys can be assigned to control access to data stored in the card. 8.3.3
Access rights
There are 4 different Access rights stored for each file within each application. As seen below, access conditions are command dependant : •
Read access (GetValue, Debit for Values Files),
•
Write Access (GetValue, Debit, LimitedCredit for Value Files),
•
Read&Write access (GetValue, Debit, LimitedCredit, Credit for Value Files),
•
ChangeAccessRights.
Note that commands in brackets refer to Value Files Each access condition is coded thanks to 4 bits. Actually the access code represents the key number, which must be used to perform the DES corresponding operation. Coding convention is as follows :
Access code (4 bits) 0..0xD 0xE 0xF
Meaning Key number which must be used to perform the related operation Always : free access (preceding authentication is not required) Never : access always denied
93
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8.4 ADDITIONAL FEATURES AND DATA 8.4.1
Sequence number
The IC-card (fare medium) state changes each time it is used. Each of these operations are recorded and registered, and uploaded to the Card Issuer and/or Application Owner. In order to check that no transaction is lost, all these states are uniquely numbered, using a Sequence Number, large enough to cover the medium lifetime. The Sequence number is an incremental number starting from 1 (when the medium is delivered, zero is reserved for new media), up to an unreachable* value below 218 -1= 262143. Each time a fare medium is written to its transport application (i.e. its state changes), this sequence number shall be incremented by one, so that the sequence number is representative of each state during the card lifetime. (*) Note : the average guaranteed smart medium lifetime is 100,000 write operations per memory cell and 10,000 write cycles for disposable tickets. 8.4.2
Blocking/Unblocking capabilities
The blocking/Unblocking capability applies to 2 levels: •
Application (e.g. Transport Application) and
•
Product (contract).
The actual involved mechanism will differ slightly upon the considered object (application or products). 8.4.2.1
Application or Product Blocking/Unblocking
The involved mechanisms are reversible in a sense that the blocked object (Application or Product) may be unblocked. To achieve this feature, the system is fitted with 2 sequence numbers : •
USN Unblocking Sequence Number (stored on the card),
•
BSN Blocking Sequence Number (stored in the CAD blacklist).
Thus, each time a CAD detects a card that has an entry in the blacklist, it will compare BSN and USN. If BSN>=USN the related card object will be blocked, USN is set to BSN+1 and the blacklist entry will be removed later on. This mechanism allows the customer to revert his card quickly (at the POST/TVM for instance) in order to reuse it on any CAD. Without this feature, the card would have been blocked once again since the corresponding blacklist entry may not yet be removed. This mechanism is further detailed in section 9. 8.4.3
Currency
All monetary elements on the card (Stored Value parameters, Price,...) are expressed in tenth of NOK (i.e. 0,1 NOK): for instance a price of 123,4 NOK will be represented as the integer 1234 on the card.
94
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8.5 GEOGRAPHICAL DATA CODIFICATION [R 116]
All reference number for zones, domains and stations must be the same for all operators participating in a regional or inter-regional structure.
The following chapter describes the zone and domain codification used in the Oslo/ Akershus area. The chapter can be used as an example and a template for developing codification within another areas. 8.5.1
Example on Zone and domain codification
Zones and domains nomenclature (8 bits, range 0..255, hexadecimal 00..FF) :
+0
+0
+1
+2
+3
+4
+5
+6
+7
+8
0
1
2
3
4
5
6
7
8
00.. —
+ 9 + 10 + 11 + 12 + 13 9
A
B
C
D
+ + 14 15 E F
D01 D02 D03 D04 D05 D06 D07
..0F
+ 16 10.. C01 C02 C03 C04
..1F
+ 32 20.. N05 N06 N07 N08 N09 N10 N11 N12 N13 N14 N15 N16 N17 N18
..2F
+ 48 30.. NØ09 NØ10 NØ11 NØ12 NØ13 NØ14 NØ15 NØ16 NØ17
..3F
+ 64 40.. ØN08 ØN09 ØN10 ØN11 ØN12 ØN13
..4F
+ 80 50.. Ø03 Ø04 Ø05 Ø06 Ø07 Ø08 Ø09 Ø10 Ø11 Ø12 Ø13 Ø14 Ø15 Ø16
..5F
+ 96 60.. ØS07 ØS08 ØS09 ØS10 ØS11 ØS12 ØS13 ØS14
..6F
+ 112 70.. SØ04 SØ05 SØ06 SØ07
..7F
+ 128 80.. S03 S04 S05 S06 S07 S08 S09
..8F
+ 144 90.. SV03 SV04 SV05
..9F
+ 160 A0..
..AF
+ 176 B0.. V02 V03 V04 V05 V06 V07 V08 V09 V10 V11 V12
..BF
+ 192 C0.. VN04 VN05
..CF
+ 208 D0.. NV04 NV05 NV06
..DF
+ 224 E0..
..EF
+ 240 F0..
..FF 0
1
2
3
4
5
6
7
8
9
Table 2 Example on Zone codification For example, zone Ø16 is encoded 5D (hexadecimal) or 93 (decimal).
95
A
B
C
D
E F
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
This nomenclature is extensible to 0..1023. range
Id.
01..07 10..13 20..2D
D C N
domains sector sector
D01=NSB; D02=OS; D04=SL; D06=OS+SL. Oslo City provision to 4 zones North
30..38 40..45 50..5D 60..67 70..73
NØ ØN Ø ØS SØ
sector sector sector sector sector
North-East East-North East East-South South-East
80..86 90..92 —– B0..BA C0..C1
S SV VS V VN
sector sector sector sector sector
South South-West West-South West West-North
D0..D2 E0..3FF
NV
sector
North-West RFU Table 3 Extended zone codification
Special case : when a ticket destination is C01 (Oslo centre, zone 1), transfer is allowed to any point of Oslo City. That means that real ticket destination is in fact D01 (Oslo domain), and shall be encoded so. Ticket with a destination encoded as C01 will allow transfers inside C01 only, using the same rule as any other zone. Location nomenclature (16 bits, range 0..65535, hexadecimal 0000..FFFF) : Range
Size
Meaning
0000..03FF
1024
location is a zone or a domain (validity information)
0400..0FFF 1000..13FF 1400..17FF 1800..1FFF 2000..FFFF
3072 1024 1024 2048 57344
R.F.U. NSB location identifiers (T.B.D.) OS location identifiers (T.B.D.) SL location identifiers (T.B.D.) R.F.U. Table 4 Location codification
Other Data Service operator reference : •
OS = 2,
•
SL = 3,
•
NSB = 4.
96
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8.6 EXAMPLE ON VALIDATION PROCESS 8.6.1
Typical validation process
Wait for fare medium. On card detection : Read card information : card identifier (chip manufacturer, card manufacturer, card serial number) Read Environment Read Holder Read SequenceNumber Read EventLog.1 (process tele-renew if needed) IF current journey to process THEN → (current travel is part of current journey) INCREASE SequenceNumber (by one) UPDATE last EventLog ELSE → (If not current journey to process) → (current travel begins a new journey) Read ContractList LOOP for all possible contracts in the priority order specified by ContractList Read Contract.n -- (process auto-renew if needed) IF contract applies THEN EXIT LOOP END LOOP (for all possible contracts in the order specified by ContractList) IF contract applies THEN → (uses the first applying contract for this journey) DEPENDING ON Contract properties (cases non exclusive) CASE Contract is used for the first time WRITE Contract.n (Validity start date, Status) UPDATE ContractList (possible transaction split) CASE Travel Rights must be debited Read Counter.n DECREASE Counter.n by one travel and as many period as needed CASE 'Stored Value' must be debited Read StoredValueCounter (process auto-reload if needed) DECREASE StoredValueCounter by journey price CASE Contract list must be updated UPDATE ContractList END (depending on Contract properties) INCREASE SequenceNumber (by one) APPEND new EventLog ELSE IF implicit journey applies → (automatic use of 'Stored Value') Read StoredValueCounter (process auto-reload if needed) DECREASE StoredValueCounter by journey price INCREASE SequenceNumber (by one) APPEND new EventLog ELSE (if no contract applies) → (validition fails) END (if no contract applies)
97
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
END (If not current journey to process) 8.6.2
Auto-reload process
Processed if IOHolder.storedValueAutoReloadData is present, with non zero storedValueAutoReloadAmount and storedValueAutoReloadEndDate > today. (Read StoredValueCounter already performed) Read SpecialEventLog.1 IF eventData (storedValueAutoReloadData) is present, and is compatible with IOHolder.storedValueAutoReloadData with non zero storedValueAutoReloadAmount and storedValueAutoReloadEndDate > today, and if 'StoredValue' ≤ storedValueAutoReloadGround, THEN INCREASE SequenceNumber (by one) INCREASE StoredValueCounter by storedValueAutoReloadAmount (possible transaction split) UPDATE SpecialEvent2 (auto-reload information) (possible transaction split) APPEND new EventLog (auto-reload information) END (if eventData ...) 8.6.3
Auto-renew process
This is a vending operation, which is not detailed in this study. Updates are : INCREASE SequenceNumber (by one) UPDATE Counter.n UPDATE Contract.n (possible transaction split) UPDATE ContractList UPDATE SpecialEvent2 (renew information) (possible transaction split) APPEND new EventLog (renew information) 8.6.4
Tele-renew process
This is a vending operation, which is not detailed in this study. Structure SpecialEvent1 (storedValueAutoReloadData) is read to check if tele-renew operation(s) have already been performed or not. Updates are : INCREASE SequenceNumber (by one) UPDATE Counter.n UPDATE Contract.n (possible transaction split) UPDATE ContractList UPDATE SpecialEvent1 (tele-renew information : serial number) (possible transaction split) APPEND new EventLog (renew information)
98
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
8.7 PRODUCT PRIORITY AND MANAGEMENT 8.7.1
Generality
The IC-card card will hold several products, but only one may be useful at any validation. To process the card rapidly during validation, the choice of the product to use must be easy and must not need any customer interaction. For this, a simple rule understandable by customers must be defined. In all cases, priority is given to current journey as long as it is active : validation inside the geographical validity domain and before transfer time is reached, is by default a transfer validation (free interchange); traveller may override this choice and buy a connection ticket, which anyway will take any period pass product in account (extension). The connection to an unused slicing period travel is forbidden. 8.7.2
Automatic and explicit selection
Automatic selection : If after applying the rules defined above there is no product stored on smart the card that apply, then, if automatic (implicit) journey purchase (using 'Stored Value') applies, this automatic ticket is then sold and used. Explicit selection : Selection for immediate use is proceeded by a vending or dedicated machine, which writes down to the card a Travel Right pointing to the specified product. Explicit selection is when the product is sold and marked for immediate usage; this product by-passes the usual priority rules and is used in any cases. 8.7.3
Priority Processing at validation
The priority processing at CAD (for validation process) is based on the following criteria : •
•
contract list information which tells •
if the contract is already in use or not,
•
which is the contract priority (may be defined by the user)
detailed information checked from the contracts •
Temporal validity (start date / Time, end date / time, period right to travel)
•
Geographical validity (start point, stop points, start zone, destination zone…)
for more details, refer to section 9.3.4.5 "Contract list structure description" 8.7.4
Priority processing at point of sale
Several products may be present on a card at the same time. Conflicts that may happen between them are not managed by validators (transaction time optimisation) and have to be avoided when products are sold. To make conflict management understandable by customers, following rules must apply :
99
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
It is not be possible to put more than two period pass of same type except if : •
The product is flexible product. In this case, the second will be valid after the first.
•
Date of start of validity of product is after date of end of validity of first product.
•
It is not possible to put more than one limited period pass except if it is the same type with precedent restriction.
•
It is not possible to put more than one unlimited period pass for the same product owner if there is more than one not used.
•
If a customer wants to have an unlimited period pass which begins after another one, a date of start of validity must be given.
•
It is not possible to put more than one single ticket except for immediate use and except for automatic 'Stored Value' single tickets. If there is more than one person who want to travel, they must be all registered in the same single ticket.
Case example with more than one product: A customer has a NSB monthly period pass and an OS daily pass. •
When validating in OS bus in OS domain, OS daily pass will be used.
•
When validating in SL bus in OS domain, OS daily pass will be used.
•
When validating in NSB train in OS domain, NSB monthly pass will be used.
•
When validating in NSB train in NSB domain, NSB monthly pass will be used.
8.7.5
Action list usage and rules (Tele renew)
To be written. 8.7.6
Removal of a product
This paragraph shows when a product can be removed from the card. Note that a contract can be cancelled when : •
Product has been used and product end of validity has been reached.
•
Product has never been used and maximum date for refund is reached (end of version validity more than 1 year).
•
Product has never been used, product end of validity has been reached and product is not refundable.
•
Product has never been used, maximum date for validation has been reached (end of version validity is more than 3 months) and product is not refundable.
In other cases, product cannot be cancelled from the card. If an equipment doesn’t have the description of the product in his parameter tables, it cannot remove the product. This test will be made :
100
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
At each sale operation for all the products.
•
At each use of this product.
101
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
9 NORTIC SPECIFICATION FOR DESFIRE FILE STRUCTURE This chapter describes the file structure and content for the directories and files to be implemented on the NDS DESFire cards. [R 117]
The NDS DESFire IC-card shall enable the implementation of the following directories: •
MF (Masterfile)
•
CardIssuerDF (directory used by card issuer at the time of card initialisation)
•
TransportDF (directory used for storage of data elements required for local, regional and inter-regional interoperable fare management)
•
NorticDF (directory used for storage of data elements for the national interoperable product NORTIC TravelContract)
The free memory left may be used to host additional applications/directories in the future. The following table gives the card file breakdown structure. Each directory is highlighted in grey. Each 'file' is given a name, a type and record(s). The record content column relates, either to key content or data element structures. Note that the Master file stands for the PICC itself. Application Directory/File name #
0x578000 (hexadeci mal)
0x000000
Record* : contents
MF (Master File) PICC Master Key
DF key
³
CardIssuerDF CI_Keys
DF
key
³
CI_Header
standard
TransportDF T_Keys 0x578001 (hexadecimal)
Type
9.1 Keys (M) 9.2 Keys (4 keys) CardHeader
DF
key
³
Described in
9.2.1 9.3
Keys (7 keys) 0
T_Environment
standard
Environment
T_CardHolder
standard
Holder
9.3.2 9.3.3
T_ProductRetailer
backup
Contract [1..8]
T_ServiceProvider
backup
Counter [1..8] 9.3.4.1 ContextsAndSequenceNumbers 9.3.4.3 9.3.4.5 ContractList
T_SpecialEvent
backup
T_StoredValue T_GeneralEventLog
SpecialEventLog [1..8]
9.3.5.1.1
SpecialEventList
9.3.5.1.2
value
StoredValue
9.3.6
cyclic
GeneralEventLog [1..8]
9.3.7
102
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Application Directory/File name #
t.b.d (hexadecimal)
T_SVReloadLog NorticDF Nortic_Keys
Type
Record* : contents
cyclic
StoredValueReloadLog [1..2]
DF
key
³
Described in 9.3.8 9.2
Keys (x keys)
t.b.d t.b.d
Table 5 NSD DESFire data layout Notation : In the following sections, each record is described using 2 descriptions : •
detailed encoding : these tables give all the necessary details related to the data elements, sizes, data types and initials values. To be noted that the dot at the left part of each field means "mandatory" and the numbers identifies the optional number according to the presence bitmap indicator.
•
ASN.1 representation which uses the PER encoding / bit aligned. When conflicting, ASN.1 prevails.
•
Fields marked as "unused" will be ignored by the CAD Software
The structure follows the recommendations in ENV-1545 as closely as possible. Structures or fields that are specific for the NDS – either in that it does not exist in ENV-1545 or because it is used differently – is prefixed with “IO” – IO stands for “Interoperability Organisation”. NOTE:
The prefix IO should be discussed and finally defined enabling a more general prefix than the one used in the Oslo projects where the tasks of the Application Owner, Registrar, Security Manager and Collection and Forwarding operator are allocated to the Interoperable Organisation.
9.1 MASTER FILE Please note that term Application used in the DESFire specification is different from the term Application as defined in the CEN and ISO standard for Interoperable Fare Management System Architecture (IFMSA). Application in DESFire terms means DF.
The application is the default application of the card and represents the card level itself (PICC). This 'Application', even if always present on the card, is not used by the transport application. Its main characteristics are :
103
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
AID : 0x00 00 00 (refers to the PICC itself),
•
KeySettings : 0x0B (configuration changeable, no free create/delete file, free directory list, master key changeable),
•
Number of keys : 1 (Master key M #0).
9.2 CARDISSUER DIRECTORY (CARDISSUERDF) Please note that term Application used in the DESFire specification is different from the term Application as defined in the CEN and ISO standard for Interoperable Fare Management System Architecture (IFMSA). Application in DESFire terms means DF.
This application is created using the "CreateApplication" command whose parameters are set as follows : •
AID : 0x578000 CardIssuer application :given here as hexadecimal value (ie 0x57 is the MSB and 0x00 is the LSB)
•
Key settings : 0x12 (configuration not changeable, no free create/delete file, free directory list, master key not changeable, other key changeable using key # 1).
•
number of 3DES keys : 4 (Master key (M, #0), card Issuer key (I, #1), Card retailer key (C, #2), and Read key (R, #3).
The Card Issuer directory is designed to host 4 keys (M, I, C, R) and to handle one file. i.e. the CI_Header. 9.2.1
CI_Header file
The CI_Header file is created on the DESFire card to hold the Issuer fixed information. It contains a unique IOCardHeader-A structure. This file is a standard data file (DESFire file type 0x00) with a file ID set to 0xC . It is created with a size of 32 bytes, even if less is needed. Its access rights and security level are as follows : • Read : always ; read is free and no key is required •
Write : never
•
Read&Write : never
•
Change Config : Only the Card Issuer can update this file (using the Card Issuer key which is key#1 in the application key set)
•
Security level : plain text. (communication settings = 0x00)
This file is created during the personalization process and is never written to during normal process. It is 32 bytes long (256 bits) and contains one IODESfireCardHeader-IO- A data element Note that the card number is a 32 bits serial number that makes the cards unique within the IO ticketing system. This number is stored in the chip during the card manufacturing process and is under the card issuer responsibility. NB: Even if the definition below allows room for other ID (IODESfireCardIdNumberISO7812), the IO cards at first will have only a 32 bits serial number.
104
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
NOTE:
The prefix IO should be discussed and finally defined enabling a more general prefix than the one used in the Oslo projects where the tasks of the Application Owner, Registrar, Security Manager and Collection and Forwarding operator are allocated to the Interoperable Organisation. Also the numbering scheme for NDS DESFire cards has to be discussed and settled avoiding cards in different IFM systems in Norway having the same cardIDNumber.
CardHeader structure description : Encoding tutorial (ASN.1 definition prevails when conflicting). presence bit # Data element identifier
Data type
IOCardHeader-A preamble • country
SEQUENCE OF SEQUENCE OF 0..999
• format data • cardIdNumber Ó choice bitmap 0 cardIdNumberISO14443
0..1048575 SEQUENCE OF SEQUENCE OF 0..2
1 cardIdNumberISO7812 2 cardIdNumber32bits
Size (bits) 0 10 20 0 0 2 0 0
0..4294967295
32
DateCompact
14
0..1048575 0..1048575
20 20
0..15
4
• cardValidityEndDate
• owner • retailer • cardKeyVersion
122
initial value, comment
578 0 : this format version
2 (= cardIdNumber32bits) unused unused Application wide unique serial number, set up at prepersonalization The day the card is no more valid. Date is set up a prepersonalization and is computed in number of days counted from the starting date (January 1 st, 1997):may be for instance manufacture date + n years. Application owner Company Retailer organisation Used to identify which keys are in use. Initial = 1. This number is managed cyclically. TOTAL size
Table 6 IODESfireCardHeader-A data fields Remark : the cardIdNumber is a 32 bit number which is set during the card initialisation process. It is up to the IO system to ensure it's uniqueness within the transport application. Do not confuse the cardIdNumber with the card serial number (7 byte long) which is set during the chip manufacturing process and therefore not used in this Application Note.
105
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
ASN.1 description is as follows : IODESfireIdentifier ::= INTEGER(0..1048575) -- GENERIC HEADER TYPES IODESfireCardHeaderGeneric ::= SEQUENCE { country INTEGER(0..999), -- ISO 3166-1 country numeric id. format IODESfireIdentifier -- as defined by country registration authority. } IODESfireCardHeaderPreamble(theCountry INTEGER, theFormat IA5String) ::= IODESfireCardHeaderGeneric WITH COMPONENTS ({country (theCountry), format (theFormat)}) IODESfireCardIdNumberISO7812 ::= SEQUENCE(SIZE(10..19)) OF NumericString (FROM “0”..”9”) as defined by ISO 7812/CCITT E.118. IODESfireCardIdNumber32bits ::= INTEGER(0..4294967295) -- as usually managed by ticketing devices, and as usual S/N. IODESfireCardIdNumber ::= CHOICE { cardIdNumberISO14443 NULL, cardIdNumberISO7812 IODESfireCardIdNumberISO7812, cardIdNumber32bits IODESfireCardIdNumber32bits } IODESfireCardHeaderData-IO-A ::= SEQUENCE { -- uses registration defined by (countryNumber = 578, format = 0) -- IODESfireCardIdNumber is for the moment only the 32 bits S/N variant -- IMPORT DateCompact FROM ENV1545-1 : 1998 – day count from Jan. 1st, 1997. cardIdNumber IODESfireCardIdNumber, cardValidityEndDate DateCompact, -- the day the card is no more valid. owner IODESfireIdentifier, -- card owner (brand owner). retailer IODESfireIdentifier -- card retailer. cardKeyVersion INTEGER(0..15) -- Key version in use (4 bits) } -- IO CARD HEADER DEFINITION for Norway (578) -:- IO-A -- country = Norway = 578, format = 0 -- This is the initial format definition. IOCardHeader-A ::= SEQUENCE { preamble IODESfireCardHeaderPreamble (country 578, format 0), data IODESfireCardHeaderData-IO-A }
9.3 TRANSPORT DIRECTORY Please note that term Application used in the DESFire specification is different from the term Application as defined in the CEN and ISO standard for Interoperable Fare Management System Architecture (IFMSA). Application in DESFire terms means DF. The Transport application is created using the "CreateApplication" using the following parameters : •
AID = 0x578001, given here as hexadecimal value (ie 0x57 is the MSB and 0x00 is the LSB)
•
Key settings : 0x12 (configuration not changeable, no free create/delete file, free directory list, master key not changeable, other key changeable using key # 1),
•
Number of keys : 8 (Master key (M, #0), application Owner/issuer key (O, #1), Application retailer key (A, #2), Card retailer key (C, #3), Product retailers key (P, #4), add-Value key (V, #5), Service providers key (S, #6) and Read key (R, #7)).
The Transport directory is designed to handle up to 8 files which are :
106
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
T_Environment
•
T_CardHolder,
•
T_PoductRetailer,
•
T_ServiceProvider,
•
T_SpecialEvent,
•
T_StoredValue,
•
T_GeneralEventLog,
•
T_SVReloadLog.
9.3.1
T_Environment file
The T_Environment file is file #0xA in the Transport Application (AID=0x578001). It is a standard file not backed-up which is configured at creation to contain a maximum of 256 bits. Access conditions and security level are as follows : •
Read : this right allows only the ReadRecords command after having presented the Transport Read Key (key #7 in Application 0x578001 key set).
•
Write : never
•
Read&Write : this right is controlled by the Transport Application Owner key (key #2 in AID 0x578001 key set).
•
Change Config : controlled by the Application Owner key (key#1 in AID 0x578000 application key set). This access should normally never be used.
•
Security level : plain text (communication settings = 0x00)
This file contains one Environment structure The free space after the only IOApplicationIssuer structure is padded with 0x00. The ASN.1 definition is then : IOApplicationIssuer ::= environment IODESfireEnvironment
9.3.1.1
-- defined in 0
Environment structure description
This card data element contains : •
Application data format. (envVersionNumber). 0 means this fare and card structure definition.
•
Current applying network (envNetworkId) : Represents the IO network. 578xxx (578=Norway).
•
Application retailer (envApplicationIssuerId) : One of the company identifier that is registered as Application Retailer, the value is taken from Company Identifier table below
•
Application expiry date (envApplicationEndDate) : should be after the card expiry date
•
There is no data element that marks the application as invalidated (e.g. because blacklisted). This information cannot be managed by the ticketing application for security reasons : blocking has to be done by any CAD that detects a fault, while unblocking shall not be done before diagnostic and verification is performed. Cf. 8.4.2.
107
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The Environment structure is compatible with the Environment structure defined in the ENV15451:1998 standard, which defines 7 optional fields (envNetworkId, envApplicationIssuerId, envApplicationEndDate, envPayMethod, envAuthenticator, envSelectList and envData) In order to be implemented in Norway, the NSD-cards cards should implement fields 0,1 and 2 only in the Environment structure. Note that the Application is identified by the CardId number. Therefore the IO Environment structure is described as follows :
presence bit # data element IOEnvironment Ó presence bitmap
data type
size (bits)
SEQUENCE bit string
0 7
Initial value and comments 0000111
• 0
envVersionNumber envNetworkId
0..63 NetworkId
6 24
1
envApplicationIssuerId
Company
16
2
envApplicationEndDate DateCompact
14
3
envPayMethod
0
0 (refers to the current application version) 0x578000 Company code as defined in Table 8 Company Identifiers Last day of validity for the transport application unused
4
envAuthenticator
0
unused
5
envSelectList
0
unused
6
envData
0
unused
PayMethod OCTET STRING SEQUENCE OCTET STRING
67
TOTAL
Table 9 IOEnvironment data fields There is no data element that marks the application as invalidated (e.g. because blacklisted). This information cannot be managed by the ticketing application for security reasons : blocking must be possible by any CAD that detects a fault, while unblocking shall not be done before diagnostic and verification is performed. Cf. 8.4.2. The Environment structure is compatible with the Environment structure defined in the ENV1545 standard, which defines 7 optional fields (envNetworkId, envApplicationIssuerId, envApplicationEndDate, envPayMethod, envAuthenticator, envSelectList and envData) The IOEnvironment structure is derived from the ENV1545-1 Environment structure and is as follows : IOEnvironment ::= SEQUENCE 0000111 (binary) EnvVersionNumber version envNetworkId envApplicationIssuerId envApplicationEndDate envPayMethod
{
-- 7 bits in the bit-field always
VersionNumber, [0]NetworkId [1]Company [2]DateCompact [3]PayMethod
-- 6 bits 000000 (binary) = this OPTIONAL3, -- 24 bits always 0x578000 OPTIONAL3, -- 16 bits present OPTIONAL3, -- 14 bits present 4 OPTIONAL , -- unused
3 OPTIONAL in ENV1545 but present and mandatory for NSD cards. 4 OPTIONAL in ENV1545 but absent from the NSD card layout. 108
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
envAuthenticator [4]Authenticator OPTIONAL4, -- unused envSelectList [5]SEQUENCE SIZE(1..10) OF Pointer OPTIONAL4, envData [6]OCTET STRING(SIZE(0..255)) OPTIONAL4 } -- TOTAL : 67 bits used.
-- unused -- unused
Company ApplicationIssuerId are listed below: NOTE:
The table below includes only the IO in Oslo and the three main operators in Oslo linked to the IO. Hence, there is a need for defining a national registrar for the whole of Norway. It shouls also be noted that the numbering scheme is not in line with the requirements in 2.7 Identification. Company
Code for envApplicationIssuerId
IO OS SL NSB
1 2 3 4 Table 8 Company Identifiers
9.3.2
T_cardHolder File
The CardHolder file is file number 0xC in the Transport Application. It is a standard file not backed-up which is configured at creation to contain a maximum of 32 bytes (256 bits). Access conditions and security level are as follows : •
Read : this right allowss only the ReadRecords command after having presented the Transport Read Key (key #7 ).
•
Write : never
•
Read&Write : this right is controlled by the Transport Card Retailer key (key #3).
•
Change Config : controlled by the Application Owner key (key#1). This access should normally never be used.
•
Security level : plain text. (communication settings = 0x00) Note that in normal use, this file is always read.
9.3.2.1
Holder structure description
The holder file contains one Holder structure which is described in a structure that is derived from the 'Holder' structure defined in the ENV1545 standard. presence bit # data element identifier IOHolder.base Ó presence bitmap 0 holderName 1 HolderBirth
data type SEQUENCE bit string SEQUENCE SEQUENCE
109
size (bits) 8 0 0
Initial value and comments
unused Only the Date Of Birth is used
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
presence bit # data element identifier • HolderBirthDate
size (bits)
data type
Initial value and comments
Datef
• year
4 × BDC 0..9
16
YYYY
• month
2 × BDC 0..9
8
MM
• day
2 × BDC 0..9
8
DD
IA5String
0
unused , set to an empty string
0..255
8
zero
• HolderBirthPlace • length • component × length 2 HolderBirthName 3 holderIdNumber
character 0..127
0
unused
IA5String IA5String
0 0
unused unused
4 holderCountryAlpha
PrintableString
21
5 holderCompany 6 holderProfiles
Company SET OF
0 0
• length
0..15
4
• Profiles Ó presence bitmap 0 holderNetworkId 1 holderProfileNumber 2 holderProfileDate
SEQUENCE bit string NetworkId CustomerProfile DateCompact
0 3 24 6 14
OCTET STRING 0..255
7 holderData • length • component × length IOHolder.extension Ó presence bitmap
0
• StoredValueAutoreloadEndDate 1 holderPlusRFU-1 2 holderPlusRFU-2
can be 0, 1 or 2, depending on subtypes, see below 0b111 0x578000 for Norway see profile table below End of validity for this profile Optional, present only for Agent profiles
8
octet
0 storedValueAutoReloadData • StoredValueAutoreloadGround • StoredValueAutoreloadAmount
3 characters 0..127, set to "NOR" according to ISO 3166-1 in order to identify the country unused
8xn n = length
bit string
3
SEQUENCE Integer Integer
16 16
Integer
14
NULL NULL
0 0
initial = 0 Indicates the last day the auto-reload process is still available. Day count from starting date (January 1st 1997).
Table 11 NSD DESfireHolder data fields It is inserted into IOHolder.storedValueAutoReloadData and into SpecialEvent[1].eventData (running values).
storedValueAutoReloadGround
IOHolder
SpecialEvent[1].eventData
initial minimum value
running minimum value
110
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
storedValueAutoReloadAmount
initial maximum value
running maximum value
storedValueAutoReloadEndDate
expiry date
suspension date
Table 12 Stored-Value data repartition If the structure is empty, all values are implicitly zero, i.e. no “auto-reload” allowed. In case of inconsistency, SpecialEvent[1].eventData items that conflict are replaced by Holder.holderData limiting ones. The Holder information are put on the card when issued. But the customer may decide to change its Store 'Value parameters' (Ground, Amount, for instance through some sales devices). In this case the values in the SpecialEvents take precedence on the data in the Holder structure, but SpecialEvent[1].eventData cannot be greater than Holder.holderData. 9.3.2.2
Profiles
holderProfileNumber is a profile identifier (see below), the validity of which may optionally be limited by its expiration date in holderProfileDate, according to standard. Two profiles are allocated to IO nonstandard purposes. IO Profile
Type
Non personalized Personalised without data
none
Adult Child ( 67 years)
Implicit Implicit
Number
Implicit
Disabled (blind, wheel chair user) Employees (all providers). Military Young (< 20 years) Deaf-Blind Dog Primary school student
unspecified adult child student oldAgePensioner Disabled Not Further Specified staff
9 10 32 33 34 35
Implicit
College student Police. Guide Dog Trainers. Congress participant Company worker Intervention card (all providers)
0 1 2 3 4 5 for envApplicationIssuerId
ENV1545 : 1998 profile
military
36 37 41 43 44 for envApplicationIssuerId
63
staff
Table 13 IO Profiles Remarks : •
When a profile is indicated as implicit, that means it is calculated according to birthday date.
•
Additional info on profile usage / passenger category!!!! 111
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Cards may store •
an age profile (implicit) computed from the birth date,
•
up to 2 extra profile (s).
NOTE:
The table above is not in line with the requirements in Håndbok 206 Elektronisk billettering, Del 1, Chapter 3.5 Price Calculation. Hence, there is a need for redefining Table 13 IO Profiles.
ASN.1 description IOHolder ::= SEQUENCE{ base Holder -- from ENV1545-1:1998 -(WITH COMPONENTS { holderBirth (WITH COMPONENTS {holderBirthDate PRESENT}) OPTIONAL, holderCountryAlpha PRESENT, -- Always "NOR" holderProfiles (SIZE(0..2)) OPTIONAL, -- 4+nx47 bits (n=0..2), holderData OPTIONAL }), extension IOHolderPlus } IOStoredValueAutoReloadData ::= SEQUENCE { storedValueAutoReloadGround Amount, storedValueAutoReloadAmount Amount, storedValueAutoReloadEndDate DateCompact } -- TOTAL 46 bits
-- 16 bits -- 16 bits -- 14 bits
IOHolderPlus ::= SEQUENCE { -- 3 bits bitfield storedValueAutoReloadData IOStoredValueAutoReloadData OPTIONAL, -- 46 bits holderPlusRFU-1 NULL OPTIONAL, -- RFU (absent). holderPlusRFU-2 NULL OPTIONAL -- RFU (absent). }
EXAMPLE: IO specific Use of the holderData element : •
This element is dedicated to intervention card and may be used to store agent information (like profile, agentId, ....). This element (up to 18 byte long) is deliberately unformatted to let each Transport Operator use it as they will. The format and data stored here are not interoperable.
IO Stored value reload information •
if present : StoredValue auto-reload information (limits) and StoredValueAutoReloadData (see Special events, below) describe the 'Stored Value' parameters,
•
if absent : No Stored Value auto-reload facility.
The IOStoredValueAutoReloadData structure is not part of ENV1545:1998, and is therefore IO specific, its ASN.1 definition is : It is inserted into IOHolder.storedValueAutoReloadData and into SpecialEvent[1].eventData (running values). Therefore, the ASN.1 definition related to the Holder structure used for the IO CSC cards is defined as follows:
112
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
HolderBirth and HolderProfile are here defined as in the ENV1545 standard, and the comments describe the IO mandatory fields (field marked IO mandatory). Derived from these base types the IO card structures defines 4 derived Holder structures for the IO cards : •
IOAnonymousHolder : that has only a country field ("N" for Norway, by default).
•
IOProfiledHolder : structure that contains a profile but no date of birth
•
IOPersonalisedHolder : structure that contains at least one profile.
•
IOEmployeeHolder : that can have from 1 to 2 profile with at least one having ProfileId #9 (staff).
•
IOAgentHolder : for people in charge of the equipments and system maintenance (ProfileId is 63).
Options used (refer to Table 8)
Anonymous Holder
Profiled Holder
Personal Holder
Employee Holder
Agent Holder
4
4, 6
1, 4, 6
4, 6
4, 6, 7
These structures are defined below : IOAnonymousHolder ::= IOHolder (WITH COMPONENTS { base (WITH COMPONENTS holderCountryAlpha PRESENT
-- 8 bits (Holder bit-field) -- 21 bits -- all other fields not present
}) }) -- TOTAL : 29 bits max used. IOPersonalisedHolder ::= IOHolder (WITH COMPONENTS { base (WITH COMPONENTS { bit-field) holderBirth PRESENT, holderCountryAlpha PRESENT, holderProfiles (SIZE(0..2) WITH COMPONENTS { Holder Profile)
--
8 bits (Holder
-- 40 bits -- 21 bits -- 4 bits (0..2 --
3 bits
bitmap holderNetworkId OPTIONAL, –- 24 bits holderProfileNumber (ALL EXCEPT 63) PRESENT, -- 6 bits holderProfileDate OPTIONAL, -- 14 bits OPTIONAL, -- 94 bits max used
}) (0..2)x47 bits }) -- holderData is not used }) -- TOTAL : 167 bits max used.
IOEmployeeHolder ::= IOPersonalisedHolder (WITH COMPONENTS { base (WITH COMPONENTS { bit-field) holderBirth PRESENT, present holderCountryAlpha PRESENT, holderProfiles (SIZE(1..2)) PRESENT with
--
8 bits (Holder
-- 40 bits when -- 21 bits -- 4 + (1..2)x47 bits --
a mandatory
profile #9 (staff) }) }) -- TOTAL : 167 bits max used. IOAgentHolder ::= IOHolder (WITH COMPONENTS { base (WITH COMPONENTS { holderCountryAlpha mandatory
113
PRESENT,
-- 8 bits bitfield -- 21 bits : IO
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
holderProfiles (SIZE(1) WITH COMPONENTS {
--
4 bits (=1) -- 3 bits
bitmap holderNetworkId holderProfileNumber (63) holderProfileDate }) }), holderData (SIZE(0..18)) }) -- TOTAL : 232 bits max used.
OPTIONAL, –- 24 bits PRESENT,5 -- 6 bits OPTIONAL , -- 14 bits PRESENT, -- 47 bits max used PRESENT
-- 8 + 8×18 bits
Anonymous and Personalised cards •
A-card (anonymous card) has no birth date information nor profile.
•
P-card (personalized card) has either a birth date information or up to 2 profile(s) to allow concession tariffs.
P-card with a DOG or Bicycle profile give automatic selection of a DOG/BICYCLE supplement for the Check in process. Profiles combination A P-card may store : •
1 implicit profile : birth date (age based profile),
•
up to 2 profiles •
physical (Disabled, deaf-blind)
•
occupation (primary school, college, university, police, military, intervention, employers, guide dog trainer, company worker, congress participant).
9.3.3
T_ProductRetailer file
The ProductRetailer file is file #1 in the Transport Application (AID=0x578001). It is a back-up file which is configured at creation to contain a maximum of 384 bytes (but the total amount of memory used on the card is twice this amount : 768 bytes). Access conditions and security level are as follows : •
Read : this right allows only the ReadRecords command after having presented the Transport Read Key (key #7 in Application 0x578001 key set).
•
Write : never
•
Read&Write : this right is controlled by the Product Retailer key (key #4 in AID 0x578001 key set).
•
Change Config : controlled by the Transport Application Owner key (key#1 in AID 0x578001 application key set). This access should normally never be used.
•
Security level : plain text.with MAC computation (communication settings = 0x01)
The file is not a record file, but its linear content is logically organised in 8 blocks of 48 bytes (384bits) each. Each of these record contains one Contract data element (described in 9.3.3.1 and 9.3.3.2). This way the reader can access directly the adequate contract by computing easily the offset of the record to read. The first record always starts at byte 0 from the beginning of the file. An empty record slot will be totally filled with 0x00
5 May be absent, for profile that don't have end of validity for this holder.
114
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The unused memory (either between contract structures or at the end of the file) is filled with 0x00. Basically, the ProductRetailer file contains up to 8 Contracts. The IOContractList data structure contained in the ContractList part of the ServiceProvider file gives the contract mapping in ProductRetailer file (i.e. which contract slots are used or not). 9.3.3.1
Contract structure description
Structure is defined as follows : contractNetworkId
NetworkId if different from Envionment.networkId
contractProvider contractTariff contractSerialNumber
Product owner Product type Product identifier in the card. Full product identifier is the couple card number & product identifier. Its value is the sequence number that was on card before the contract is written to the medium. Maximum passenger count.
ContractPassengerTotal contractServices contractPriceAmount contractRestrictProduct
contractValidityStartDate contractValidityEndDate contractValidityEndTime contractValidityDuration
contractValidityZones
Transportation modes eg : Bus, metro, train, boat, night bus, dog, bicycle … Price paid for the contract expressed in the system currency Indicates the factor to multiply with full fare to have the price for all the group. it is the passenger and luggage count minus all the concessions applied. (granularity is 5%) Product start of validity, present if contractValidityDuration is absent. When absent, counterEndDate is used instead When absent, counterEndTime is used instead Validity period count (according to contractTariff) up to contractValidityEndDate + contractValidityEndTime, present if contractValidityStartDate is absent. Used in place of contractValidityStartDate if contract structure is too big to fit into record. Origin, via and destination zones (as needed)
contractJourneyOrigin Origin station. contractJourneyDestination Destination station. contractStatus 1=unused, 33=running, 88=disabled When absent, counterStatus is used instead. ContractUnblokingNumber Used in accordance with the blacklist Blocking Sequence Number in order to revert the blocked status. ContractPlusAuto-Renew If this structure is present, this feature has been subscribed. If AutoRenewLastDate is not yet reached, the contract may be renewed (an Auto-Renewed other contract is created). Once this is done AutoRenewLastDate is set to AutoRenewLast Date zero to prevent any subsequent auto renew. Auto-Renewed set to true means the contract comes from an autorenew feature otherwise it has been bought at a POST or TVM. Contract Plus Passengers Number of passengers per category for group purposes (5 categories max) (Exact usage must be specified)
115
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Table 14 Contract data fields
presence bit #
data element identifier
IOContract Ó presence bitmap
data type SEQUENCE bit string
size (bits)
initial values and comments
··· 20
—— 0 6 BCD digits 'CCCNNN' 'CCC' is 578 24 for Norway according to ISO3166-1 and NNN is the network number—— 16 —— 16 —— uses the 32 applicationSequenceNumber ··· —— unused ——
0 contractNetworkId
NetworkId
1 contractProvider 2 contractTariff
Company 0..65535
3 contractSerialNumber
Int4
4 contractCustomerInfo Ó presence bitmap
SEQUENCE bit string
0 contractCustomerProfile 1 contractCustomerNumber 5 contractPassengerInfo Ó presence bitmap 0 contractPassengerClass
CustomerProfile unused Int4 unused SEQUENCE ··· bit string 2 SEQUENCE ···
—— —— —— —— ——
• classQualifier • custProfile 1 contractPassengerTotal 6 contractVehicleClassAllowed 7 contractPaymentPointers
0..255 0..65535 SET OF
unused unused 8 unused ···
—— —— —— —— ——
0 ..5 SEQUENCE bit string PointerQualifier PointerData
unused ··· unused unused ···
—— —— —— ——
• length
1..16
unused
——
• component × length
octet
unused
——
Ptag
···
——
0..4
unused
——
octet
unused
——
Company PayMethod
unused unused
—— ——
16
identifies the transportation modes related to the contract or any related contract service (renew) or any pay method capability. For more details refer to the ENV 1545-2:1998 standard.
• length • component x length Ó presence bitmap • pointerQualifier • pointerData
0 ptag • length • component × length 1 provider 8 contractPayMethod
9 contractServices
Services
116
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
size (bits)
initial values and comments
Amount PayUnit SEQUENCE bit string
16 unused ··· 7
—— —— —— ——
TimeCompact TimeCompact RestrictDOW 0..255 0..255
unused unused unused unused unused
—— —— —— —— ——
0..65535 16 SEQUENCE ··· 0..255 unused OCTET STRING ··· 0..255 unused
—— —— —— —— ——
octet
unused
——
bit string
9
—— ——
0 contractValidityStartDate
DateCompact
14
1 contractValidityStartTime
TimeCompact
unused
presence bit #
data element identifier
10 contractPriceAmount 11 contractPriceUnit 12 contractRestriction Ó presence bitmap 0 1 2 3 4
contractRestrictStart contractRestrictEnd contractRestrictDay contractRestrictTimeCode contractRestrictCode
5 contractRestrictProduct 6 contractRestrictLocation • qualifier • locationData • length • component × length 13 ContractValidityInfo Ó presence bitmap
data type
2 contractValidityEndDate
DateCompact
14
3 4 5 6
TimeCompact 0..255 DateCompact SET OF 0..10
11 8 Unused
contractValidityEndTime contractValidityDuration contractValidityLimitDate contractValidityZones • length
• component × length 7 contractValidityJourneys 8 contractPeriodJourneys 14 contractJourneyData Ó presence bitmap
IOZone 0..65535 0..65535 SEQUENCE
bit string 0 contractJourneyOrigin 0..65535 1 contractJourneyDestination 0..65535 2 contractJourneyRouteNumbers SET OF
Starting validity date (counted in days) Starting validity time (minutes counted from midnight) ——
4
—— —— Unused —— length=3
10
Total = 30 bits for 3 zones
unused unused
—— —— ——
8 16 16 ···
—— —— —— ——
• length
0..10
unused
——
• component × length
0..65535
unused
——
3 contractJourneyRouteVariants • length
SET OF 0..10
··· unused
—— ——
• component × length 4 contractJourneyRun 5 contractJourneyVia
0..255
unused
——
0..65535 0..65535
unused 16
—— ——
117
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
presence bit #
data element identifier
6 contractJourneyDistance 7 contractJourneyInterchanges 15 contractSaleData Ó presence bitmap
data type
size (bits)
initial values and comments
0..65535 0..255 SEQUENCE bit string
16 unused unused
—— —— —— ——
unused unused unused unused
—— —— —— ——
2
see ASN.1 description below
17 contractLoyaltyPoints
DateCompact TimeCompact Company DeviceId ENUMERATED {1,33,63,88} 0..2047
unused
——
18 contractAuthenticator • length
OCTET STRING 0..127 unused
—— ——
• component × length 19 contractData
0..255
unused
——
0 1 2 3
contractSaleDate contractSaleTime contractSaleAgent contractSaleDevice
16 contractStatus
OCTET STRING
——
• length
0..127
Unused
——
• component × length
0..255 (length=4) unused
——
IOContractPlus Ó presence bitmap
bit string
2
• ContractUnblockingNumber
0 ..15
4
0 ContractPlusAutoRenew
SEQUENCE
• autorenewed
BOOLEAN
1
• autorenewLastDate
DateCompact
14
1 ContractPlusPassengers • length=5 • component x length
SEQUENCE 5 0..63
30
initial = 0. at most, 15 unblocking facilities for each contract. set to True if the contract is renewed automatically i.e. not bought at Post or TVM. last day the contract may be renewed. When auto renew process is completed, this date is set to 0. 5 categories
Table 15 Contract data fields
Note that actual data elements used will depend upon the related product i.e : •
Zone-to-zone based or area based period contract,
•
Station-to-station based period contract,
•
Station-to-station and zone or area based period contract,
•
Zone-to-zone based or area based single journey, •
Station-to-station based single journey.
118
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Note : Contract structure can be written by sale machines only, while counters can be updated by both sale machines, gates and validators. Note : Contract and Counter files must have the same record count. The product owner has the responsibility of product management : •
He defines product prices,
•
He defines product rules (in accordance with other providers if it is an interoperable product),
•
He manages agreement with other operators for product selling and refunding.
ASN.1 description is as follows : IOContract ::= SEQUENCE { -- 20 bits contractNetworkId [0]NetworkId OPTIONAL, -- 24 bits contractProvider [1]Company OPTIONAL, -- 16 bits contractTariff [2]INTEGER(0..65535) OPTIONAL, -- 16 bits contractSerialNumber [3]Int4 OPTIONAL, -- 32 bits contractCustomerInfo [4]ContractCustomerInfo OPTIONAL, -- unused -- contractCustomerProfile CustomerProfile -- unused -- contractCustomerNumber Int4 -- unused contractPassengerInfo [5]ContractPassengerInfo OPTIONAL, -- 2 bits -- contractPassengerClass PassengerClass -- unused -- classQualifier INTEGER(0..3) -- unused -- custProfile CustomerProfile -- unused -- contractPassengerTotal -- 8 bits contractVehicleClassAllowed [6] INTEGER(0..65535) OPTIONAL, -- unused contractPaymentPointers [7]SET SIZE(0..15) OF Pointer OPTIONAL, -- unused contractPayMethod [8]PayMethod OPTIONAL, -- unused contractServices [9]Services OPTIONAL, -- 16 bits contractPriceAmount [10]Amount OPTIONAL, -- 16 bits contractPriceUnit [11]PayUnit OPTIONAL, -- unused contractRestriction [12]ContractRestriction OPTIONAL, -- 7 bits -- contractRestrictStart TimeCompact -- unused -- contractRestrictEnd TimeCompact -- unused -- contractRestrictDay RestrictDOW -- unused -- contractRestrictTimeCode INTEGER(0..255) -- unused -- contractRestrictCode INTEGER(0..255) -- unused -- contractRestrictProduct INTEGER(0..65535) -- 16 bits -- contractRestrictLocation LocationReference -- unused contractValidityInfo [13]ContractValidityInfo OPTIONAL, -- 9 bits -- contractValidityStartDate DateCompact OPTIONAL, -- 14 bits -- contractValidityStartTime TimeCompact OPTIONAL, -- unused -- contractValidityEndDate DateCompact OPTIONAL, -- 14 bits -- contractValidityEndTime TimeCompact OPTIONAL, -- 11 bits -- contractValidityDuration INTEGER(0.255) OPTIONAL, -- 8 bits -- contractValidityLimitDate DateCompact OPTIONAL, -- unused -- contractValidityZones SET SIZE(0..10) OF IOZone OPTIONAL,-- 4+3×10 bits = 34bits -- contractValidityJourneys INTEGER(0..65535) OPTIONAL, -- unused -- contractPeriodJourneys INTEGER(0..65535) OPTIONAL, -- unused contractJourneyData [14]ContractJourneyData OPTIONAL, -- 8 bits -- contractJourneyOrigin INTEGER(0..65535) -- 16 bits -- contractJourneyDestination INTEGER(0..65535) -- 16 bits -- contractJourneyRouteNumbers SET SIZE(0.10) OF INTEGER(0..255) -- unused -- contractJourneyRouteVariants SET SIZE(0.10) OF INTEGER(0..65535) -- unused -- contractJourneyRun INTEGER(0..65535) -- unused -- contractJourneyVia INTEGER(0..65535) -- 16 bits -- contractJourneyDistance INTEGER(0..65535) -- 16 bits -- contractJourneyInterchanges INTEGER(0..65535) -- unused contractSaleData [15]contractSaleData OPTIONAL, -- unused -- contractSaleDate -- unused -- contractSaleTime -- unused -- contractSaleAgent -- unused -- contractSaleDevice -- unused contractStatus [16]Status OPTIONAL, -- 2 bits contractLoyaltyPoints [17]LoyaltyPoints OPTIONAL, -- unused contractAuthenticator [18]Authenticator OPTIONAL, -- unused contractData [19]OCTET STRING OPTIONAL -- unused
119
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
IOContractPlus ::=SEQUENCE { bitmap contractUnblockingNumber contractPlusAutoRenew { autoRenewed autorenewLastDate } present auto-renew is available contractPlusPassengers } -- TOTAL : 384 bits max.
-- 2 bits Integer(0..15) SEQUENCE BOOLEAN DateCompact
-- 4 bits}
OPTIONAL
-- 1 bit -- 14 bits -- when
SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL
IOZone ::= INTEGER(0..1023) -- replaces INTEGER(0..255) in ENV1545-2:1998. -- This is provision to extension for up to 1000 zones in interoperation area. Services ::= BIT STRING(SIZE(16)) -- from ENV1545-2:1998 -- bit 15 = IO (urban bus) -- bit 14 = IO (interurban bus) -- bit 13 = IO (metro) -- bit 12 = IO (tramway) -- bit 11 = IO (train) -- bit 10 = IO boat (ferry) -- bit 09 = (toll) -- bit 08 = (parking) -- bit 07 = (taxi) -- bit 06 = (tunnel) -- bit 05 = IO night bus at journey first validation -- bit 04 = IO dog -- bit 03 = IO bicycle -- bit 02 = RFU -- bit 01 = RFU -- bit 00 = IO auto-renew (contract renew / pay method change capability) Status ::= ENUMERATED { enabled(1), pending(33), suspended(63), disabled(88) }----
------
ENV1545-1 : 1998 IO : still unused IO : running, i.e. used at list once IO : (no meaning) IO : disabled (e.g. because was blacklisted)
PER encoding : according to ENV1545:1998 with ASN.1 PER encoding, be careful to ISO8825-2 clause 13.1 while ISO7816-4 § 6.6.1 & 6.6.2 (WRITE RECORD) apply ‘enabled’ is encoded ‘00’binary, pending ‘01’binary, and disabled ‘11’binary.
9.3.3.2 9.3.3.2.1
Implementation cases of contract description Zone-to-zone based or area based period contract
ContractZonalPeriodTicket ::= [APPLICATION]Contract (WITH COMPONENTS { contractNetworkId OPTIONAL, -- 24 bits contractProvider PRESENT, -- 16 bits contractTariff PRESENT, -- 16 bits contractSerialNumber PRESENT, -- 32 bits contractPassengerInfo (WITH COMPONENTS { contractPassengerTotal PRESENT -- 8 bits }) OPTIONAL, -- 2 bits contractServices, PRESENT -- 16 bits contractValidityInfo (WITH COMPONENTS { contractValidityStartDate OPTIONAL, -- 14 bits contractValidityEndDate, OPTIONAL, -- 14 bits contractValidityEndTime, OPTIONAL, -- 11 bits contractValidityDuration OPTIONAL, -- 8 bits contractValidityZones PRESENT -- 4 + 3×10 bits = 34 bits max. }) -- 9 bits contractStatus PRESENT -- 2 bits }) IOContractPlus ::= SEQUENCE { contractUnblockingNumber contractPlusAutoRenew
Integer(0..15) SEQUENCE
120
--
4 bits
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
{
autoRenewed autorenewLastDate
BOOLEAN DateCompact
-- 1 bit -- 14
bits } contractPlusPassengers
OPTIONAL SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL
}
When it is Zone-to-zone based with a VIA zone : ContractValidityZones -- count -- startzone -- endzone -- viazone --
SET SIZE(0..10) OF INTEGER(0..1023) (0..10) 4 bits(value=3) INTEGER(0..1023) 10 bits INTEGER(0..1023) 10 bits INTEGER(0..1023) 10 bits TOTAL : 34 bits
When it is Zone-to-zone based without a VIA zone : ContractValidityZones -- count -- startzone -- endzone --
SET SIZE(0..10) OF INTEGER(0.. (0..10) INTEGER(0..1023) INTEGER(0..1023) TOTAL :
1023) 4 bits(value=2) 10 bits 10 bits 24 bits
When it is Area based : ContractValidityZones -- count -- area --
SET SIZE(0.10) OF INTEGER(0.. 1023) (0..10) 4 bits(value=1) INTEGER(0..1023) 10 bits TOTAL : 14 bits
9.3.3.2.2 Station-to-station based period contract ContractODPeriodTicket ::= [APPLICATION]Contract (WITH COMPONENTS { contractNetworkId OPTIONAL, -- 24 bits contractProvider PRESENT, -- 16 bits contractTariff PRESENT, -- 16 bits contractSerialNumber PRESENT, -- 32 bits contractPassengerInfo (WITH COMPONENTS { contractPassengerTotal PRESENT, -- 8 bits }) OPTIONAL, -- 2 bits contractServices, -- 16 bits contractValidityInfo (WITH COMPONENTS { contractValidityStartDate OPTIONAL, -- 14 bits contractValidityEndDate, OPTIONAL, -- 14 bits contractValidityEndTime, OPTIONAL, -- 11 bits contractValidityDuration OPTIONAL, -- 8 bits contractValidityLimitDate OPTIONAL -- Unused }) -- 9 bits contractJourneyData (WITH COMPONENTS { contractJourneyOrigin, -- 16 bits contractJourneyDestination -- 16 bits contractJourneyVia -- 16 bits }) -- 8 bits contractStatus, -- 2 bits }) IOContractPlus ::=SEQUENCE { contractUnblockingNumber Integer(0..15) -- 4 bits contractPlusAutoRenew SEQUENCE { autoRenewed BOOLEAN -- 1 bit autorenewLastDate DateCompact -- 14 bits } OPTIONAL contractPlusPassengers SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL }
9.3.3.2.3
Station-to-station and zone or area based period contract
ContractODZonalPeriodTicket ::= [APPLICATION]Contract contractNetworkId OPTIONAL, contractProvider, contractTariff, contractSerialNumber, contractPassengerInfo (WITH COMPONENTS { contractPassengerTotal
121
(WITH -- 24 -- 16 -- 16 -- 32
COMPONENTS { bits bits bits bits
-- 8 bits
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
}) OPTIONAL, -- 2 bits (bit string) contractServices, -- 16 bits contractValidityInfo (WITH COMPONENTS { contractValidityStartDate OPTIONAL, -- 14 bits contractValidityEndDate, OPTIONAL, -- 14 bits contractValidityEndTime, OPTIONAL, -- 11 bits contractValidityDuration OPTIONAL, -- 8 bits contractValidityLimitDate OPTIONAL, -- Unused contractValidityZones -- 4 + 1×10 bits = 14 bits }) -- 9 bits (bit string) contractJourneyData (WITH COMPONENTS { contractJourneyOrigin, contractJourneyDestination, contractJourneyVia }) contractStatus,
------
16 bits 16 bits 16 bits 8 bits 2 bits
})
When it is Zone-to-zone based (no VIA zone allowed) : ContractValidityZones SET SIZE(0.10) OF INTEGER(0.. 1023) OPTIONAL, -- count (0..10) 4 bits(value=2) -- startzone INTEGER(0..1023) 10 bits -- endzone INTEGER(0..1023) 10 bits -TOTAL : 24 bits When it is Area based : ContractValidityZones SET SIZE(0.10) OF INTEGER(0..1023) -- count (0..10) 4 bits(value=1) -- area INTEGER(0..1023) 10 bits -Total 14 bits contractJourneyDestination and startzone (or area) have to be consistent: contractJourneyDestination should represent a station that has to be in the startzone (if Zone to zone based) or in the area (if area based) of the journey. IOContractPlus ::=SEQUENCE { contractUnblockingNumber contractPlusAutoRenew { autoRenewed autorenewLastDate bits } contractPlusPassengers }
9.3.3.2.4
Integer(0..15) SEQUENCE BOOLEAN DateCompact
4 bits -- 1 bit -- 14
OPTIONAL SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL
Zone-to-zone based or area based single journey
ContractZonalSingleJourney ::= [APPLICATION]Contract (WITH COMPONENTS { contractNetworkId OPTIONAL, -- 24 bits contractProvider, -- 16 bits contractTariff, -- 16 bits contractSerialNumber, -- 32 bits contractPassengerInfo (WITH COMPONENTS { contractPassengerTotal -- 8 bits }) -- 2 bits contractServices, -- 16 bits contractPriceAmount, -- 16 bits contractRestriction (WITH COMPONENTS { contractRestrictProduct -- 16 bits }) -- 7 bits contractValidityInfo (WITH COMPONENTS { contractValidityZones OPTIONAL, -- 4 + 2×10 bits = 24 bits }) -- 9 bits contractStatus, -- 2 bits }) IOContractPlus ::= SEQUENCE { contractUnblockingNumber contractPlusAutoRenew { autoRenewed
Integer(0..15) SEQUENCE BOOLEAN
122
4 bits -- 1 bit
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
autorenewLastDate
DateCompact
-- 14
bits } contractPlusPassengers
OPTIONAL SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL
} When it is Zone-to-zone based (no VIA zone allowed) : ContractValidityZones SET SIZE(0.10) OF INTEGER(0.. 1023) OPTIONAL, -- count (0..10) 4 bits(value=2) -- startzone INTEGER(0..1023) 10 bits -- endzone INTEGER(0..1023) 10 bits -TOTAL : 24 bits When it is Area based : ContractValidityZones SET SIZE(0.10) OF INTEGER(0..1023) -- count (0..10) 4 bits(value=1) -- area INTEGER(0..255) 10 bits -Total 14 bits
9.3.3.2.5
Station-to-station based single journey
ContractODSingleJourney ::= [APPLICATION]Contract (WITH COMPONENTS { contractNetworkId OPTIONAL, -- 24 bits contractProvider, -- 16 bits contractTariff, -- 16 bits contractSerialNumber, -- 32 bits contractPassengerInfo (WITH COMPONENTS { contractPassengerTotal -- 8 bits }) OPTIONAL, -- 2 bits contractServices, -- 16 bits contractPriceAmount OPTIONAL, -- 16 bits contractRestriction (WITH COMPONENTS { contractRestrictProduct -- 16 bits }) OPTIONAL, -- 7 bits contractJourneyData (WITH COMPONENTS { contractJourneyOrigin OPTIONAL, -- 16 bits contractJourneyDestination -- 16 bits contractJourneyVia -- 16 bits }) OPTIONAL, -- 8 bits contractStatus, -- 2 bits }) IOContractPlus ::= SEQUENCE { contractUnblockingNumber contractPlusAutoRenew { autoRenewed autorenewLastDate bits } contractPlusPassengers }
Integer(0..15) SEQUENCE BOOLEAN DateCompact
4 bits -- 1 bit -- 14
OPTIONAL SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL
Journeys with via : remark: according to the contract description previously detailed , contractJourneyVia is available for all the contracts except for the Zone to zone based or area based single journey. 9.3.4
T_ServiceProvider file
This file is file #2 in the Transport Application. It is a backup file which is configured at creation to host a maximum of 128 bytes but the actual used size on the card is twice this amount i.e. 256 bytes. Access conditions and security level are as follows : •
Read : this right allows only the ReadRecords command after having presented the Transport Read Key (key #7),
•
Write : devices that have the service Provider key (key #6) are allowed to write in this file,
•
Read&Write : this right is controlled by the Product Retailer key (key #4),
123
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Change Config : controlled by the Transport Application Owner key (key#1). This access should normally never be used.
•
Security level : plain text.with MAC computation. (communication settings = 0x01)
The ServiceProvider is the placeholder of the following data structures : •
Counter [1..8] : eight 72 bit records are provided,
•
ContextsAndSequenceNumbers (one 64 bit record),
•
ContractList (one 384 bit record reserved),
9.3.4.1
Counter Structure Description
Each contract is associated with a counter that counts remaining journeys, remaining rights to travel and other variable information for each contract. counterAuthenticator
Unused
counterStatus
see contractStatus, used for contracts that may slip or be refunded if not used Used for contracts that may slip.
counterEndDate counterEndTime counterPeriods
counterPeriodJourneys
CounterJourneyTravels other counter... items
Used for contracts that may slip. Number of periods remaining before the total exhaustion of the product. Used for frequency limited contracts, e.g. 2 journeys per day or 10 journeys per week. Remaining period count. Number of valid journeys for the current period. Used for frequency limited contracts, e.g. 2 journeys per day or 10 journeys per week. For not frequency limited contract (= only one period), this is the remaining journey count if relevant. Number of valid remaining travels for the current journey R.F.U. Table 16 Counter data fields
The available information on counters are defined as follows IOCounter data elements : presence bit # data element identifier
data type
IOCounter Ó presence bitmap
SEQUENCE bit string
0 1 2 3 4
counterAuthenticator counterStatus counterEndDate counterEndTime counterPeriods
IOAuthenticator ENUMERATED{1,33,63,88} DateCompact TimeCompact 0..1023
5 6 7 8 9
counterPeriodJourneys counterJourneyTravels counterUsagePoints counterLoyaltyPoints-1 counter LoyaltyPoints-2
0..1023 0..63 0..8191 0..2047 0..2047 124
size (bits)
initial values and comments
··· 13
—— 0
unused —— 2 see contract status 14 —— 11 —— 10 —— 10 6 13 11 11
—— —— RFU RFU RFU
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
presence bit # data element identifier 10 counterRFU-11 11 counterRFU-12 12 counterRFU-13
data type NULL NULL NULL
size (bits)
initial values and comments
unused unused unused
—— —— ——
Table 17 Counter data fields IOCounter ::= SEQUENCE {
-- 13 bits –- linked to same index (contractListPointer) contract. counterAuthenticator [0]IOAuthenticator OPTIONAL, -- unused 32 bits counterStatus [1]Status OPTIONAL, -- 2 bits see contractStatus. counterEndDate [2]DateCompact OPTIONAL, -- 14 bits slipping product. counterEndTime [3]TimeCompact OPTIONAL, -- 11 bits slipping product. counterPeriods [4]INTEGER(1..1023) OPTIONAL, -- 10 bits remaining count. counterPeriodJourneys [5]INTEGER(1..1023) OPTIONAL, -- 10 bits remaining count. counterJourneyTravels [6]INTEGER(1..63) OPTIONAL, -- 6 bits remaining count. counterUsagePoints [7]INTEGER(1..8191) OPTIONAL, -- Unused 13 bits RFU . counterLoyaltyPoints-1 [8]INTEGER (0..2047) OPTIONAL, -- Unused 11 bits RFU . counterLoyaltyPoints-1 [9]INTEGER (0..2047) OPTIONAL,-- Unused 11 bits RFU . counterRFU-11 [10]NULL OPTIONAL, -- bitmap padding RFU (unused). counterRFU-12 [11]NULL OPTIONAL, -- bitmap padding RFU (unused). counterRFU-13 [12]NULL OPTIONAL, -- bitmap padding RFU. (unused) } –- TOTAL : 66 bits max
9.3.4.2
Product blocking/unblocking
•
Product blocking : Any CAD, provided it has the Service Provider key (key #6) may block a product if there is an entry in the blacklist and if it's BSN is greater (or equal) to the ContractUnblokingNumber. This state is stored within the product by setting the relevant CounterStatus to "blocked".
•
Product unblocking :The blocked product may revert to the "enabled" stat. The relevant status (counterStatus) must be updated accordingly by the sale equipment with the use of the ServiceProvider key. (key #6). ContractUnblockingNumber is incremented using the the ProductRetailer key (Key#4).
9.3.4.3
ContextAndSequenceNumber structure description
This structure provides the IO application with information related to : •
Application context information and
•
Transaction sequence Number.
The Application context information provides mainly blocking/unblocking capabilities. The Sequence number is an incremental number starting from 1 (when the card is delivered). Each time a card is written to its transport application (its state changes), this sequence number shall be incremented, so that the sequence number is representative of each state during the card lifetime. Cf 8.4.1.
125
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
size (bits)
initial values and comments
IOContextsAndSequenceNumber SEQUENCE
···
——
presence bitmap Ó 0 authenticator • length
1
initial = 0
OCTET STRING 4
unused unused
—— ——
• component × length • applicationContext • applicationStatus • applicationSequenceNumber
octet
unused
——
SEQUENCE IOApplicationStatus 1..262143
··· 2 18
—— initial =0; refers to ASN.1 below initial =1 initial = 0. Allows 255 application unblockings at most initial =0, used to manage the action list. Process is similar to the application Unblocking Number.
presence bit #
data element identifier
data type
bit string
• applicationUnblockingNumber 1..255
8
• applicationLastServedOrder 1..262143
18
Table 18 ContextsAndSequenceNumber data fields The ASN.1 definition of this structure is as follows : IOContextsAndSequenceNumber ::= SEQUENCE { authenticator IOAuthenticator, OPTIONAL -- unused + 1 presence bitmap, applicationContext IOApplicationContext -- 46 bits } -- grand total = 47 bits IOApplicationContext ::= SEQUENCE { applicationStatus IOApplicationStatus, -- 2 bits applicationSequenceNumber IOTransactionSequenceNumber, -- 18 bits applicationUnblockingNumber IOUnblockingSequenceNumber, -- 8 bits applicationLastServedOrder IOTransactionSequenceNumber, -- 18 bits } -- total = 46 bits IOApplicationStatus ::= IOContextStatus IOContextStatus ::= ENUMERATED { IOContextStatusInitialized IOContextStatusEnabled IOContextStatusDisabled IOContextStatusBlocked }
9.3.4.4
(0), (1), (2), (3),
Application Blocking/Unblocking capabilities
The Transport Application (Application number 578001) may be blocked by setting the Application status to "blocked" according to the mechanism described in section 2. As mentioned earlier, this mechanism is reversible and involves : •
USN and BSN sequence numbers,
•
Application status
Any CAD that detects a fault, or a blacklisted fare medium, has to block it. Once it is done, the medium number may be removed from the blacklist. The re-validation is performed by setting the Application status to "enabled" .
126
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Note that blocking and unblocking processes involve the Service Provider key (key #6). 9.3.4.5
ContractList structure description
This structure replaces BestContract and BestContracts from ENV1545-2:1998 ; its purpose is to store contract priority information. This structure is used in priority management contractListNetworkId The contract network ID it is present only if the Contract.networkId is different from 'EnvNetworkId' in the Environment file Registered identifier of the Product set, which gives indication for a behaviour, a usage price level, the product owner and the applying Service Provider(s). contractList Products of a product set only differ by their profile concession and fare table ProductTemplate version. Each Service Provider maintains a preference order of applying contractListProductTemplate values, which prioritises contracts together according to Service Provider’s preference. When a contract is validated the first time, this flag shall be set. If this feature is contractListIsUsed not used (e.g. non refundable contract), this flag is set when sold (reduces transaction duration). This criterion is used to prioritise contracts together according to traveller’s contractListPreference preference. Default value is oioContractListPreference-Normal. Contract record index (the contract record position in the Contract file, contractListPointer 1..IOContractCount i.e.1 for the pointer refers to contract 0). Table 19 Contract list data fields To determine the best contract to use, the validation equipment (gate or validator) has to proceed as follows: •
Read the whole ContractList file.
•
Disregard contracts associated to a Contract List User Preference = “suspended”.
•
Disregard contracts associated to a non allowed Product Template by the service provider.
•
Sort the remaining ContractList entry :
•
•
By Contract List "Is used" indicator first,
•
Then by Contract List User Preference field,
•
Then by the priority level associated to each Product template (this association is done thanks to a specific table EOD included in the level 1 equipment set of parameters) *.
•
Then by the initial place of the ContractList entry in the ContractList file.
Test Geographical and temporal validity of contracts as they appear in this list (if any) after this multi-criteria sorting.
The first valid contract found (geographical and time validity OK, read in the Product Instance) is the one to be used and validated. (*) This mechanism, which uses an association table between the Product templates and the priority level that are attributed to, allows to manage a same Product with different priority level as the association table may be different for each Service Provider. Note that in this case contractlistProduct template is always > 0 strictly (pointed to contract is valid)
127
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
The field 'contractListNetworkId' is used to encode foreign product instances, when interoperating on foreign Transport networks. It allows to sort quickly the contracts that belong to other networks and to use only those that are in the same or recognized network. presence bit # data element identifier IOContractList • length •
size (bits)
initial values and comments
0..IOContractCount
··· 4
length max = 8
data type SEQUENCE OF
component × length Ó presence bitmap
SEQUENCE
···
——
1 24 14 4
—— ——
1 2
—— ——
0 • •
ContractListNetworkId contractListProductTemplate contractListPointer
bit string NetworkId 0..16383 InstancePointer
• •
contractListIsUsed contractListPreference
BOOLEAN ENUMERATED Table 20 Contract list data fields
ContractlistPreference (priority) • • • •
Disliked : 0, Normal : 1, Preferred : 2, Selected : 3,
IOContractList ::= SET SIZE(0..IOContractCount) OF IOContractListElement -- TOTAL : 4 + 8x46 = 372 bits at maximum -- (i.e. 4 bits to store the Nb of elements + 46 bits max per element) IOContractListElement ::= SEQUENCE { -contractListNetworkId NetworkId [0]OPTIONAL, –always present contractListProductTemplate INTEGER(0..16383), -contractTariff behaviour contractListPointer InstancePointer, -contractListIsUsed BOOLEAN, -'has been -already used' contractListPreference IOContractListPreference, -} – TOTAL : 22 or 46 bits IOContractListPreference ::= ENUMERATED { oioContractListPreference-Disliked oioContractListPreference-Normal oioContractListPreference-Preferred oioContractListPreference-Selected } -- 2 bits
1 bit bit-field. 24 bits NetworkId 14 bits 4 bits 1 bit means 2 bits see below
(0), (1), (2), (3)
-- Initial (empty) value for the contractlist zone on all Cards. oioContractList IOContractList ::= { -- No item. } -- IOContractList initial (empty) value for all Cards. IOContractCount ::= 8 –- the DESFire card can hold up to 8 contracts.
9.3.5
T_SpecialEvent File
128
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
This file is file #3 in the Transport Application. It is a backup file which is configured at creation to host a maximum of 288 bytes but the actual used size on the card is twice this amount i.e. 576 bytes. Access conditions and security level are as for T_ServiceProvider file. The SpecialEvent File is the placeholder of the following data structures : •
SpecialEventLog [1..8] : eight 256bit records are provided,
•
SpecialEventList (3 + 3x19 = 60 bits at maximum).
9.3.5.1
Special events : SpecialEventLog & SpecialEventList
Special events are used for non-volatile events. Unlike EventLog (see 9.3.7), which are stored in a cyclic file, and deleted when several new events are appended, the special events are stored until a new similar event will replace it with the new relevant information. They are managed using the specialeventlist record. Two special events are presently managed. Others available are R.F.U. 9.3.5.1.1
SpecialEventLog structure description
This structure is duplicated 8 times in a linear way ; only 2 structures are currently used (others are RFU). It uses the same definition of Special events as PaymentEvent and EventLog (cf. 9.3.7). It's objective is to store the last reload or auto-renew that occurred on the card, therefore, it is a list containing 2 possible structures corresponding to the 2 possible events: •
Last reload by Action list (tele-renew information)
•
Last auto-renew of period product : SpecialEvent2 structure
; SpecialEvent1 structure
Note that the appearance of these fields is used to determine which event is concerned.
presence bit #
data element identifier
IOSpecialEventLog.Generic Ó presence bitmap • eventDateStamp
data type
size (bits)
initial value and comments
SEQUENCE bit string DateCompact
28 14
0 0
TimeCompact Integer (0 .. 255) NetworkId PayEventCode
11 0 24 0
0 unused Optional, 0x578000 if present unused
• payServicePoint • payServicePointInfo 3 eventResult 4 eventServiceProvider 5 eventNotOkCounter
0..14 0..6 Result Company 0..255
0 0 0 16 0
unused used for SpecialEvent2 only unused
6 eventSerialNumber
0..16777215
24
7 eventDestination
0..65535
0
• 0 1 2
eventTimeStamp eventDisplayData eventNetworkId eventCode
129
equals to application Sequence Number unused
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
data element identifier
presence bit #
size (bits)
data type
initial value and comments
8 eventLocationId
LocationId (0..65535) (16bits)
16
9 eventLocationGate 10 eventDevice
0..255 DeviceId (224-1)
0 0
used for SpecialEvent2 in static CAD (gates, TVM,...) and only if eventVehicleId is absent unused unused
11 eventRouteNumber 12 eventRouteVariant 13 eventJourneyRun
0 0 0
unused unused unused
0
used for SpecialEvent2 in mobile CAD (bus, boat,...) and only if eventLocationId is absent
15 eventVehicleClass 16 eventLocationType 17 eventEmployee
0..65535 0..255 0..65535 VehicleId (0..65535) (16bits) 0..255 0..31 IA5String
0 0 0
unused unused unused
18 19 20 21 22
eventLocationReference eventJourneyInterchanges eventPeriodJourneys eventTotalJourneys eventJourneyDistance
SEQUENCE 0..255 0..65535 0..65535 0..65535
0 0 0 0 0
unused unused unused unused unused
23 24 25 26 27
eventPriceAmount eventPriceUnit eventContractPointer eventAuthenticator eventData
Amount PayUnit InstancePointer OCTET STRING OCTET STRING
16 0 4 0 56
used for SpecialEvent2 only unused used for SpecialEvent2 only unused Used only in SpecialEvent 1
209
TOTAL
14 eventVehicleId
Table 21 SpecialEventLog data fields According to the SpecialEvent type, used fields vary as follows : SpecialEvent1
SpecialEvent2
1, 6, 27
1, 4, 6, 8 or 14, 23, 25
Options # used
Table 22 Options used for SpecialEvent1 and SpecialEvent2 ASN.1 definition of these 2 structures is : SpecialEvent1 ::= [APPLICATION]PaymentEvent (WITH -- 28 eventDateStamp, -- 14 eventTimeStamp, -- 11 eventNetworkId OPTIONAL, -- 24 eventSerialNumber PRESENT, -- 24 eventData IOStoredValueAutoReloadData
PRESENT
--
COMPONENTS { bits bit field bits bits bits bits : application sequence number
8+48 bits :
-- Current StoredValue auto-reload information }) -- TOTAL : 157 bits used.
130
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
-- Note: the eventData field will contain an IOStoredValueAutoReloadData that is 46 bits long. -- This structure is always put in the event data as an 'OCTET STRING' of length 6 (a string of 6 -- 8 bits characters). The remaining 2 bits after the IOStoredValueAutoReloadData are set to 0. SpecialEvent2 ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bit field -- Last contract renew/download event (auto-renew or manual renew), remanent eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventServiceProvider PRESENT, -- 16 bits eventSerialNumber PRESENT, -- 24 bits (eventLogSerialNumber) eventLocationId OPTIONAL, -- 16 bits ¡ one and only one of the two .. eventVehicleId OPTIONAL, -- 16 Bits ! .. should be present. eventPriceAmount PRESENT, -- 16 bits (debited amount) eventContractPointer PRESENT -- 4 bits }) -- TOTAL : 169 bits used.
9.3.5.1.2
SpecialEventList structure description
presence bit # data element identifier IOSpecialEventList • IOSpecialEventList • length
data type SEQUENCE SET OF 0..8
size (bits)
initial values and comments
···
——
4
length=2
• Component x length Ó presence bitmap 0 eventNetworkId 1 eventServiceProvider 2 eventSeriousness
SEQUENCE bit string NetworkId ServiceProvider seriousness (0..3)
4 24 12 2
1110 unused —— ——
3 eventPointer
InstancePointer
4
——
Table 23 IOSpecialEventList structure description The ASN.1 definition of this structure is as follows : IOSpecialEventCount = 8 IOSpecialEventList ::= field
SEQUENCE (SIZE(0..8))
-- 4 bits bit
OF IOSpecialEvent
-- 22 bits each
-- TOTAL : 3..179 bits -- SpecialEvent from ENV1545-2:1998 SpecialEvent ::= SEQUENCE { specialEventNetworkId [0]NetworkId specialEventProvider [1]ServiceProvider specialEventSeriousness [2]Seriousness specialEventPointer [3]InstancePointer } } -- TOTAL : 22 bits used.
OPTIONAL, OPTIONAL, OPTIONAL, OPTIONAL
IOSpecialEvent ::= [APPLICATION] SpecialEvent (WITH COMPONENT { -- 4 bits bit field = 0111 for IO specialEventProvider PRESENT,-- 12 bits specialEventSeriousness PRESENT, -- 2 bits specialEventPointer PRESENT, -- 4 bits }) -- TOTAL : 22 bits used
131
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
This file is R.F.U. and initialised as follows : oioSpecialEventList IOSpecialEventList ::= { { { specialEventSeriousness information, specialEventPointer 1 } -- reserved for last reload by Action list (tele-renew information) } { { specialEventSeriousness information, specialEventPointer 2 } -- reserved for last renew of period product } } specialEventSeriousness ::= ENUMERATED { none (0) information (1) warning (2) fault (3) }
9.3.6
T_StoredValue file
The StoredValue file is file #4 in the Transport Application (AID=0x578001). It is a Value file which is used to hold the running value of the card Store Value. The value file is created with a null LowerLimit and a UpperLimit that is set to the system absolute maximum allowed value. The value in the different Stored Value data (including StoredValue event data, IOHolder StoredValue data and StoredValue files ) are stored in tenth of NOK (0,1 NOK). Access conditions and security level are as follows : •
Read : this right allows Debit and GetValue commands after having presented the Transport Read Key (key #7 in Application 0x578001 key set).
•
Write : never
•
Read&Write : this right allows the GetValue, Debit, LimitedCredit and Credit commands. This right is controlled by the Transport Add-Valuer key (key #5 in AID 0x578001 key set).
•
Change Config : controlled by the Transport Application Owner key (key#1 in AID 0x578001 application key set). This access should normally never be used.
•
Security level : plain text.with MAC computation. (communication settings = 0x01)
The LimitedCredit functionality is not used and the file is created without this functionality. 9.3.7
T_GeneralEventLog file
The ProductRetailer file is file #5 in the Transport Application. It is a cyclic file which is configured at creation to contain a maximum of 288 bytes (8 records of 288 bits). As this file features a backup mechanism, the total amount of memory used on the card is twice this amount i.e. 576 bytes. Access conditions and security level are as follows : •
Read : this right allows only the ReadRecords command after having presented the Transport Read Key (key #7).
•
Write : Devices having the ServiceProvider Validation key (key #6) can write to this file.
•
Read&Write : never.
132
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
•
Change Config : controlled by the Transport Application Owner key (key#1). This access should normally never be used.
•
Security level : plain text.
This file contains exactly 8 validation records that keep track of the different validations that the card was subject to. Each event can be of different subtypes, but always uses the same 256bit space. The generic structures used in this file are described below and may be implemented in 6 sub events : •
Period ticket event : Validation of period pass product,
•
Renew or Add new contract event (Common to all products),
•
Immediate (or automatic) single journey event,
•
Immediate extension single journey event,
•
Single journey contract use event,
•
Event when reloading the 'Stored Value'.
The unused memory (either between contract structures or at the end of the file) are filled with 0x00.
General event structure description
eventDateStamp
Event date stamp
eventTimeStamp eventNetworkId eventCode.payServicePoint
Event time stamp if different from Environment.networkId related to the transportation mode ("not further described", "urban bus", "metro", "tram", …) according to the ENV 1545-2 :1998 standard. eventCode.payServicePointInfo 0=unspecified, 1=entry, 2=exit, 6=interchange eventServiceProvider eventSerialNumber
eventDestination eventLocationId eventDevice eventVehicleId eventJourneyRun eventJourneyInterchanges eventTotalJourneys eventJourneyDistance
eventPriceAmount
For information • special event # 1 : Sequence number. • special event # 2: Sequence number. • event log : Ticket Serial number Destination if needed Event location identifier refers to the device that has stored the event If applies (Optional) copy of contractTariff, or its equivalent if no contract applies Duration (minutes) for last validation (transfer duration) 256 × max passenger count + current count This field is used when a group buys a ticket and not everybody in the group has the same concession. It indicates for inspector the factor of full fare paid globally by the group. it is the passenger and luggage count minus all the concessions applied. (granularity is 5%) This field is not used for price calculation. Debited Amount for this travel.
133
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
eventContractPointer
Applying contract number, or period ticket which a single ticket extension is made with.
eventData
unused Table 24 Event Data Fields
The Sequence number is an incremental number starting from 1 (when the card is delivered). Each time a card is written to its transport application (i.e. its state changes), this sequence number shall be incremented, so that the sequence number is representative of each state during the card lifetime. Cf § 8.4.1. The General Event structure is described as follows : presence bit #
data element identifier
data type
size (bits)
Initial values and comments
IOGeneralEventLog Ó presence bitmap • eventDateStamp • eventTimeStamp
SEQUENCE bit string DateCompact TimeCompact
28 14 11
0 1 2
eventDisplayData eventNetworkId eventCode • payServicePoint • payServicePointInfo
0 .. 255 NetworkId PayEventCode 0..14 0..6
0 24 0 4 3
unused 0x578000
3
eventResult
Result
0
4
eventServiceProvider
Company
16
5 6 7
eventNotOkCounter eventSerialNumber eventDestination
0 24 16
8
eventLocationId
9
eventLocationGate
0..255 0..16777215 0..65535 LocationId (0..65535) 0..255
unused Id of the company owning the event creator (equipment) unused equals to the application serial number.
10 11 12 13
eventDevice eventRouteNumber eventRouteVariant eventJourneyRun
14 eventVehicleId 15 eventVehicleClass 16 eventLocationType 17 18 19 20 21
24
DeviceId (2 -1) 0..65535 0..255 0..65535 VehicleId (0..65535) 0..255 0..31
eventEmployee IA5String eventLocationReference SEQUENCE eventJourneyInterchanges0..255 eventPeriodJourneys 0..65535 eventTotalJourneys 0..65535
22 eventJourneyDistance
0..65535
Date of the event Time of the event
16 0
unused
24 0 0 16
unused unused
16 0 0
unused unused
0 0 8 0 16
unused unused
16
134
unused
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
presence bit #
data element identifier
23 eventPriceAmount 24 eventPriceUnit 25 eventContractPointer 26 eventAuthenticator 27 eventData
data type Amount PayUnit InstancePointer OCTET STRING OCTET STRING
size (bits)
Initial values and comments
16 0 4
unused
0
unused
0
unused
272
TOTAL
Table 25 Event Data Fields
IOGeneralEventLog ::= SEQUENCE eventDateStamp eventTimeStamp eventDisplayData eventNetworkId eventCode eventResult eventServiceProvider eventNotOkCounter eventSerialNumber eventDestination eventLocationId eventLocationGate eventDevice eventRouteNumber eventRouteVariant eventJourneyRun eventVehicleId eventVehicleClass eventLocationType eventEmployee eventLocationReference eventJourneyInterchanges eventPeriodJourneys eventTotalJourneys eventJourneyDistance eventPriceAmount eventPriceUnit eventContractPointer eventAuthenticator eventData }.
{ DateCompact TimeCompact [0]INTEGER(0.255) [1]NetworkId [2]PayEventCode [3]Result [4]Company [5]INTEGER(0.255) [6]INTEGER(0..16777215) [7]INTEGER(0.65535) [8]INTEGER(0.65535) [9]INTEGER(0.255) 24 [10]INTEGER(0. 2 -1) [11]INTEGER(0.65535) [12]INTEGER(0.255) [13]INTEGER(0.65535) [14]INTEGER(0.65535) [15]INTEGER(0.255) [16]PayLocationType [17]IA5String(SIZE(0.255)) [18]LocationReference [19]INTEGER(0.255) [20]INTEGER(0.65535) [21]INTEGER(0.65535) [22]INTEGER(0.65535) [23]Amount [24]PriceUnit [25]InstancePointer [26]Authenticator [27]OCTET STRING(SIZE(0..255))
9.3.7.1.1
Generic Event Type Description
9.3.7.1.2
Event sub-types
-- 28 bits --OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL, -OPTIONAL --
14 bits 11 bits unused 24 bits 7 bits unused 16 bits unused 24 bits 16 bits 16 bits unused 24 bits unused unused 16 bits 16 bits unused unused unused unused 8 bits unused 16 bits 16 bits 16 bits unused 4 bits unused unused
Event type selection is made by checking various attributes (eventCode,..) in the structure along with the presence or absence of some elements in the structure (presence bitfield) 9.3.7.1.2.1
Period ticket event : Validation of period pass product
EventLogPeriodTicket ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits
135
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
eventCode, eventServiceProvider, eventSerialNumber, eventLocationId, eventDevice, eventJourneyRun eventVehicleId eventJourneyInterchanges, eventTotalJourneys, eventPriceAmount eventContractPointer, }) -- TOTAL : 240 bits used.
9.3.7.1.2.2
-----OPTIONAL, -OPTIONAL, ---OPTIONAL, ---
7 16 24 16 24 16 16 8 16 16 4
bits bits bits bits bits bits bits bits bits bits bits
(period right to travel)
Renew or Add new contract event (Common to all products)
EventLogContractRenew ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventServiceProvider, -- 16 bits eventSerialNumber, -- 24 bits eventLocationId, -- 16 bits eventDevice, -- 24 bits eventJourneyRun OPTIONAL, -- 16 bits eventVehicleId OPTIONAL, -- 16 bits eventPriceAmount, -- 16 bits (debited amount) eventContractPointer, -- 4 bits }) -- TOTAL : 209 bits used. EventLogContractAutoRenew ::= [APPLICATION]EventLogContractRenew
9.3.7.1.2.3
Immediate (or automatic) single journey event
EventLogSingleJourneyImmediate ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventCode, -- 7 bits eventServiceProvider, -- 16 bits eventSerialNumber, -- 24 bits eventDestination, -- 16 bits eventLocationId, -- 16 bits eventDevice, -- 24 bits eventJourneyRun OPTIONAL, -- 16 bits eventVehicleId OPTIONAL, -- 16 bits eventJourneyInterchanges, -- 8 bits eventTotalJourneys, -- 16 bits eventJourneyDistance, -- 16 bits eventPriceAmount, -- 16 bits }) -- TOTAL : 268 bits used.
9.3.7.1.2.4
Immediate extension single journey event
EventLogPeriodTicketExtension ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventCode, -- 7 bits eventServiceProvider, -- 16 bits eventSerialNumber, -- 24 bits eventDestination, -- 16 bits eventLocationId, -- 16 bits eventDevice, -- 24 bits eventJourneyRun OPTIONAL, -- 16 bits eventVehicleId OPTIONAL, -- 16 bits eventJourneyInterchanges, -- 8 bits
136
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
eventTotalJourneys, eventJourneyDistance, eventPriceAmount, eventContractPointer, }) -- TOTAL : 272 bits used.
9.3.7.1.2.5
-- 16 bits -- 16 bits -- 16 bits -- 4 bits
Single journey contract use event
EventLogSingleJourneyAdvance ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventCode, -- 7 bit eventServiceProvider, -- 16 bits eventSerialNumber, -- 24 bits eventLocationId, -- 16 bits eventDevice, -- 24 bits eventJourneyRun OPTIONAL, -- 16 bits eventVehicleId OPTIONAL, -- 16 bits eventJourneyInterchanges, -- 8 bits eventTotalJourneys, -- 16 bits eventJourneyDistance, -- 16 bits eventContractPointer, -- 4 bits }) -- TOTAL : 240 bits used.
9.3.7.1.2.6
Event when reloading the 'Stored Value'
EventLogStoredValueReload ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bitfield eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventServiceProvider, -- 16 bits eventSerialNumber, -- 24 bits eventLocationId, -- 16 bits eventDevice, -- 24 bits eventVehicleId OPTIONAL, -- 16 bits eventPriceAmount, -- 16 bits (credited amount) }) -- TOTAL : 189 bits used. EventLogStoredValueAutoReload ::= [APPLICATION] EventLogStoredValueReload
9.3.8
T_SVReloadLog file
The SVReloadLog file is file #6 in the Transport Application (AID=0x578001). It is a cyclic file which is configured at creation to contain a maximum of 512 bits (64 bytes) record. As this file is provided with the backup mechanism, the total amount of memory used on the card is twice i.e. 128 bytes). Access conditions and security level are as follows: •
Read : this right allows only the ReadRecords command after having presented the Transport Read Key (key #7 in Application 0x578001 key set).
•
Write : Devices having the Add-Value key (key #5 in the transport Application key set) can write to this file.
•
Read&Write : never.
•
Change Config : controlled by the Transport Application Owner key (key#1 in AID 0x578001 application key set). This access should normally never be used.
•
Security level : plain text. (communication settings = 0x00)
137
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
This file contains up to 2 Log structures (IOStoredValueReloadEvent) relevant to add-value reload. Since this file is managed cyclically, only the current and last value Logs are available.
StoredValueReloadLog structure description The Log structure used in this file is a sub set of the SpecialEventLog generic structure (see 9.3.5.1.1). It's ASN.1 description is detailed below. The unused memory (either between contract structures or at the end of the file) is filled with 0x00. -- Last Stored Value reload event (auto-reload or manual reload), non-volatile IOStoredValueReloadEvent ::= [APPLICATION]PaymentEvent (WITH COMPONENTS { -- 28 bits bit field eventDateStamp, -- 14 bits eventTimeStamp, -- 11 bits eventNetworkId OPTIONAL, -- 24 bits eventServiceProvider PRESENT, -- 16 bits eventSerialNumber PRESENT, -- 24 bits (eventLogSerialNumber) eventLocationId OPTIONAL, -- 16 bits ¡ one and only one of the two .. eventDivice OPTIONAL, -- 24 bits eventVehicleId OPTIONAL, -- 16 Bits ! .. should be present. eventPriceAmount PRESENT -- 16 bits (credited amount) }) -- TOTAL : 165 bits used.
9.4 NORTICDF To be defined
Record : contents R&W Chg
—
MF (Master File)
DF
—
Keys
key
³
—
CardIssuerDF
DF
³
—
CI_Keys
key
0xC
CI_Header
std
—
TransportDF
Nb of Records Record length (bytes) Comm. settings
type
File #
File/Directory name
Access Conditions*
ROW
578001(hexadeci 578000(hex) mal)
000000
Application #
9.5 NSD DESFIRE FILE ORGANISATION SUMMARY
alwneverneverI
DF
³
— Keys (M)c
—
1 —
— —
—
—
Keys (M, I, C, R)d
4
—
CardHeader
1
16 0
—
—
—
Keys (M, O, A, C, P, V, S, R)
8
—
—
—
T_Keys
key
0xA
T_Environment
std
R neverA
O
Environment
1
16 0
0xC
T_CardHolder
std
R neverC
O
Holder
1
32 0
138
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Access Conditions* 0x1
T_ProductRetailer bkup R neverP
0x2 T_ServiceProvider
bkup R S
O
P
O
Contract
8
48 1
Counter
8
9
ContextsAndSequenceNumbers 1
8
ContractList
1
48
SpecialEventLog
8
32
SpecialEventList
1
32
StoredValue
—
—
1
0x3 T_SpecialEvent
bkup R S
P
O
0x4
T_StoredValue
value R neverV
O
0x5
T_GeneralEventLog cyclicR S
neverO
GeneralEventLog
8
36 0
0x6
T_SVReloadLog
neverO
StoredValueReloadLog
2
32 0
NORTICDF
cyclicR V
1 1
DF
To be defined
Table 26 NSD DESFire data layout Note : green lines (light-grey) show files that have backup : ,T_ProductRetailer, T_ServiceProvider, T_SpecialEvent, T_StoredValue, T_GeneralEventLog and T_SVReloadLog are backup files. Whereas CI_Keys, CI_Header, TransportDF, T_Keys, T_Environment and T_CardHolder aren't. (*) : File Access Conditions are given by four columns : ‘RO, W, R&W, Chg’, giving which key is required for following access method : 'RO' for read-only (s read+debit), 'W' for write-only (s read+canceldebit, ↔ append), 'R&W' for read & write (s read+credit, ↔ read+clearfile), 'Chg' for change-configuration. Key description key
MF (Master File)
CardIssuerDF (application #0x578000)
TransportDF (application #0x578001)
NorticDF
M A C I
Master key (0) — — —
Master key (0) — Card Retailer key (2) Card Issuer key (1)
Master key (0) Application Retailer key (2) Card Retailer key (3) —
To be defined
O P R S V
— — — — —
— — Read key (3) — —
Application Owner key (1) Product retailers key (4) Read key (7) Service Providers key (6) Add-Value key (5)
Table 27 DESFire key set
139
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Master key (M) is owned by a trusted third party. It is used by the initialisation system, in particular for the unique cardIdNumber insertion (if this feature is used, cf. card header definition). Key usage and associated rights are described in this document. Key management is devoted to level 4 and is therefore out of the Application note scope. Note that the keys are not diversified.
140
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
10 TRAVELCONTRACT TRANSACTION This chapter shall describe a complete transaction with the DESFire card in the same way as described in 5.7 Description of a TravelContract usage transaction. Security measures and mechanisms are also to be included.
141
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
11 KEY MANAGEMENT 11.1
MASTER KEY MANAGEMENT
Access to the master key should be restricted to those parties that strictly need it – i.e. card manufacturers. A strict regime describing master key issuing and management must be made.
11.2
CARD ISSUER INFORMATION
The company / party issuing a Smartcard will need the Card Issuer key (key #1 for the Card Issuer Directory) in order to generate and write the CI_Header file. This file is written during the card initialisation process. The file can be read without any key. This means that this key can be confined to the card issuer, and never needs to be distributed.
11.3
TRANSPORT APPLICATION
The Master key (#0) can be retained by the card issuer, who will initiate the Transport application. The Application Owner Key (#1) can be used to modify all the files in the Transport Application, by allowing the key holder to change the configurations of all files. This possibility should never be used as part of the normal operations. The key should be retained by the application issuer, and only be used for special corrective actions or operations. The Application Retailer Key (#2) is used to write to the T_Environment file. This file holds static data about the transport application and network, and should be retained by the application issuer. All files in the Transport application can be read using the Read key (#7). The same key can be used for debiting the stored value file (T_StoredValue). This means that the Read Key should be distributed to all devices that need to read information and / or to debit the value file. Since no updating of any file (except debiting the value file) is possible with this key, the only possible operaions for a device holding only this key is to check the validity of a “ticket” – a contract or event log entry. The Card Retailer key (#3) is necessary to write or change cardholder information, and should be available for the application issuer both for initialisation and for subsequent updates. This key should never be available for end-user devices. The Product Retailer key (#4) is necessary to hold for all devices that shall update the contract strucure – i.e. to sell or install a new product in the contract list. As all the contracts are held in one file, this means that this key must be available for all companies accessing the contract structure – that is all companies included in a set of connected interoperable regions. Usage of a contract is possible without the Product Retailer key, as usage information is updated using the Service Provider key. The Add-value key (#5) is necessary to hold for all devices that shall increment the value file (“Travel purse”). The Service Provider key (#6) is used to write to the Service provider file. This file contains counters that contain variable information for a contract. The same key is used to write to the Special Event file. This file currently contains information related to reload and auto-renew actions. This means that all devices that will update counters, or that are able to perform an auto-renew or –reload, must have access to this key.
142
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Because all contracts and logs can contain interoperable products, the following keys must be global: •
The Read key (#7) – for all parties using the Transport application
•
The Product Retailer key (#4) – for all parties selling or modifying contracts
•
The Card Retailer key (#3) – for all parties writing or modifying card owner data
•
The Service Provider key (#6) – for all parties providing transport services
The Add-value-key (#5) must also be global for all parties having an agreement to allow use of the value purse. A closed interoperability region can issue local keys. This will make these cards impossible to use for inter-regional products and “foreign” products, however. In order to control and keep global keys secure they should be issued by a common Trusted Third Party.
143
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
12 CODIFICATION In order to guarantee interoperability all code fields that can cause misunderstandings must be allocated centrally. These code fields are included: Code field
Size
Usage
Card number
32 bits numeric
Identifies the physical card.
NetworkID
24 bits BCD
Denotes the network owning the application. All network IDs should have the form 578xxx – 578 denotes Norway.
Company
16 bits numeric
Denotes a company. 1-4 are used by the Oslo system.
ContractTariff
16 bits numeric
Identifies a specific contract tariff. must be unique within an interoperability area. Full identification of a product is NetworkID+contractProvider+contractTariff.
ContractListProductTemplate
14 bits numeric
Identifies a product template. This – in conjunction with the ContractTariff – defines a specific product. This identifier must be unique within an interoperability area.
eventData
8+48 bits
Denotes what kind of event is logged in one of the special event logs (for example autorenew or autoreload)
IOProfile
6 bits
Identifies a holder. Follows ENV1545, but extends it with specific codes
144
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
13 TERMINOLOGY AND DEFINITIONS 13.1
DEFINITIONS
Term
Definition
Comment
(Electronic) Transaction
Authorised generation of payment data upon using a valid payment medium.
(Security) key
Key involved in security mechanisms involving cryptographic algorithms in the NORTIC system.
(Security) key management
The process of ensuring the confidentiality and integrity of (security) keys in the NORTIC system.
Application
The application is an implemented and initialised template on the smart card (ticket medium). The application template is a master of the application specification for implementation, which is specification of files, directory entries and security schema.
Application Keys
Required keys to access an application on the ticket medium.
Application owner
The party (- parties) that possesses the property rights of the Application.
Application Retailer
Entity that installs the application on the IC card on behalf of the Application Owner
Authentication
The process of verifying the claimed identify of an identity.
Card manufacturer
Supplier of the ticket media (smart card).
Card owner
Owner of the ticket media (smart card).
Card owner keys
Required keys to access information controlled by the card owner.
Clearing
The processing and possible consolidation of transaction information passing between the parties accepting tickets (products) or payments on each other’s behalf.
Collection & Forwarding service
A service responsible for the process of collection and forwarding data in an IFM system
Customer
A person that holds the ticket medium (card holder).
Interoperability
1) The provision for the Customer of a seamless journey using the same ticket
145
Security mechanisms involve authentication of products and transactions.
A transport application on the smart card process and stores information about the customer and the transport products the customer are using, the history of rides taken.
Identity could be smart card, MAD etc.
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Term
Definition medium (IC card) on different Service Operators.
Comment
2) The ability of systems to provide services to and accept services from other systems. Master key
Key that through an encryption process is used to generate diversified (security) keys.
Product Owner
Entity that specifies the pricing, usage rules and commercial rules related to a product at all points where a product is sold or used.
Product Retailer
Entity that sells a product to the Customer on behalf of the Product Owner, e.g. a single journey ticket.
Product Usage Transaction
Electronic Transaction at a MAD and successful clearing of the payment upon usage of ticket medium.
ProductLP Owner
Responsible for the local product on the Customer media, .i.e. his IC card.
ProductLP Retailer
Acting on behalf of the ProductLP Owner issuing the local product on the Customer media, .i.e his IC card. Holds the contract between himself and the Customer.
ProductTC Owner
Responsible for the NORTIC TravelContract on the Customer media, .i.e his IC card. Holds the contract between himself and the Customer.
ProductTC Retailer
Acting on behalf of the ProductTC Owner issuing the NORTIC TravelContract on the Customer media, .i.e. his IC card. Holds the contract between himself and the Customer.
Registrar
Entity responsible for registering information ensuring uniqueness of entities in the ticketing system
Security list
List of blocked cards and/or product occurrences (earlier called black list or Blist).
Security policy
Addresses how threats shall be controlled taking into account aspects such as:
Service Operator
•
Protection of the Interest of the Public
•
Financial loss detection an prevention
•
System design constraints
Provides the transport function for the Customer, in other words the actual
146
Diversified keys are contained in the ticket medium. Master keys are kept in SAM/MAD.
Information include product id, Mad Id etc.
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Term
Definition transport provision.
Comment
Threat and vulnerability analysis
An overall assessment of the most probable threats and the system’s vulnerability to these threats.
Transport keys
Key used to ensure confidentiality and integrity of (Security Keys) within the NORTIC system
Trusted Third Party (TTP)
Responsible for notary functions in case of disputes between the customer and the IFM system and between product owners. TTP is also responsible for generating and distributing security keys to the parties in the IFM system (product owners, service operators and retailers)
147
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
13.2
ABBREVIATIONS
Abbreviation
Definition
Comment
3DES
Triple Data Encryption Standard
AID
Application Identifier (3 bytes used for the DESfire)
BSN
Blocking Sequence Number
CAD
Card Accepting Device
CCHS
Central Clearing House System
CL
Contact less
COS
Card Operating System
CSC
Contactless Smart Card
CT
Contactless Ticket
CTA
Charge to Account
DES
Data Encryption Standard
DF
Directory File
DF
Dedicated File
EF
Elementary File
IFM
Interoperable Fare Management
IO
Oslo Interoperability Organisation
IOPTA
Interoperable Public Transport Application
MAC
Message Authentication Code
MAD
Media Accepting Device
MF
Master File
NOK
Norwegian Kroner
NORTIC
Norwegian Ticketing Interoperable Concept
OTP
One Time Programming
PCD
Proximity Coupling Device
PER
Packed Encoding Rule
PICC
Proximity Integrated Circuit Card
POST
Point Of Sale Terminal
PVU
Portable Verifying Unit
R/W
Reader/Writer
RFU
Reserved for Future Use
SAM
Secure Application Module
SP
Service Provider
Abbreviation changed to MAD
148
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Abbreviation
Definition
TSN
Transaction Sequence Number
TTP
Trusted Third Party
USN
Unblocking Sequence Number
13.3
Comment
REFERENCE STANDARDS
13.3.1 Normative References Referenced standards are: Ref No. 1
Document Number. ENV1545-1
2
ISO7816-1
3 4 5 6
ISO7816-2 ISO7816-3 ISO7816-4 ISO7816-5
7 8
ISO7816-6 ISO10373-3
9 10
ISO10373-5 ISO 11770-1
11 12
ISO 11770-2 ISO14443-1
13 14 15
ISO14443-2 ISO14443-3 ISO 14816
16 17
CEN TC 224/WG 11 CEN TC 278/WG 3
18
FIPS PUB 140-2
Document name Identification card systems: Surface transport applications: Part 1 – Elementary data types, general codes and general data elements Identification Cards – Integrated Circuit Cards with Contacts: Part 1 – Physical Characteristics Part 2 – Dimension and location of contacts Part 3 – Electronic signals and transmission protocol Part 4 – Inter-Industry commands for interchange Part 5 – Numbering systems and registration procedure for application identifiers Part 6 – Inter-Industry data elements Identification cards – Test methods – Part 3: Integrated circuit(s) cards with contacts and related interface devices Identification cards -- Test methods -- Part 6: Proximity cards Information technology – Security techniques – Key management: Part 1 – Framework Part 2 – Mechanisms using asymmetric techniques Identification Cards – Contactless integrated circuit cards – Proximity Cards (PICC): Part 1 - Physical Characteristics Part 2 – Radio Frequency power and signal interface Part 3 – Initialisation and Anticollision Road Traffic and Transport Telematics (RTTT), Automatic vehicle and equipment identification, Numbering and data structures IOPTA – Interoperable Public Transport Application IFMSA – Interoperable Public Transport Fare Management System Architecture Security Requirements for Cryptographic Modules (25.05.02)
149
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
13.3.2 Informative References Referenced standards are: Ref No. 19
Document Number. 4020 12018
Document name Common specifications for interoperability – Smart media Application note, Thales 18/02/2005
20
150
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
Annex A Common Requirement Specification for Interoperability (CRSI) A.1 Introduction In 2002, the three co-operating Public Transport service providers within the Oslo city and Akershus county : •
AS Oslo Sporveier (OS),
•
Stor-Oslo Lokaltrafikk AS (SL), and
•
Norges Statsbaner AS (NSB).
set up Common Specifications for Interoperability for the Automatic Fare Collection Systems. This effort concerned the following areas: •
Security : described in [D2],
•
Interoperability Organisation : described in [D3],
•
Apportionment Rules : described in [D4],
•
Interfaces between Central Clearing House System and each Operator’s System, described in [D5],
•
Fare Structure and smart media structure : described in [D6].
The present document – written by Thales for the three service providers - gives implementation details on the card layout sketched out in the "Fare Structure and smart media structure" document ([D6]). This document will describe the data structures on the chosen card type: •
Philips DESFire : File by File memory organisation
A.2 List of References Ref
Reference Number
Ind. Author
Title
[D1]
4020 13250
B
C. Bronchain
Common specifications for Interoperability within Automatic Fare Collection in the Oslo Region
[D2]
4020 13251
A
G. Kekenbosch
Security Policy
[D3]
4020 13252
B
T. d'Athis
Interoperability Organisation
[D4]
4020 13253
C
T. d'Athis
Apportionment Rules
[D5]
4020 13254
B
T. d'Athis
CCHS to operator's System Interfaces
[D6]
4020 12985
E
T. d'Athis
Fare Structure and Smart Media Structure
[D7]
ENV1545-1
1998 CEN
Identification card systems - Surface Transport applications - Part 1 : General data elements
[D8]
ENV1545-2
1998 CEN
Identification card systems - Surface Transport
151
NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing
applications - Part 2 : Transport payment related data elements [D10]
2.0
Philips
Mifare DESFire - Contactless Multi-Application with DES and 3DES Security - MF3 IC D40 - Preliminary Specification
152
View more...
Comments
