specification for interoperable electronic ticketing system

8/14/2019 Specification for Interoperable Electronic Ticketing System

http://slidepdf.com/reader/full/specification-for-interoperable-electronic-ticketing-system 1/152

Specification for InteroperableElectronic Ticketing System

June 10, 2005

Norwegian Public Roads Administration

Handbook 206-3

Normative



2



NPRA Handbook 206-3 Specification for Interoperable Electronic Ticketing

3

Preface Handbook 206 covers electronic ticketing and Interoperable Fare Management (IFM) systems. Thefirst preliminary version of the handbook was issued in 1995 and was then followed by the official firstversion of Handbook 206 Electronic ticketing in 1998 (in Norwegian only). The development in theelectronic ticketing domain requires an updating of the version from 1998 both from a technology pointof 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 allinformation, e.g. customer data, products and logs are stored electronically. Hence, the Handbook 206does not cover ticketing systems or equipment used for issuing traditional paper tickets.

Part 2 covers recommendations as regards regional and inter-regional electronic ticketing systemsand 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 installingticketing systems. This is to ensure that all new electronic ticketing systems can be interoperable andby 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 andcommunications and is financed by the Norwegian Public Roads Administration (NPRA). The mainobjective is that electronic ticketing systems shall be simplified and by this making it easier for thecustomer to use public transport. A very important part of the simplification process is establishinglocal, regional and national interoperability.

Project leader for the Handbook 206 project has been Jacob Trondsen from NPRA. The work on theHandbook 206 has been done in cooperation with a project group with Robert Fjelltun Bøe fromNPRA, 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), LiliaHalsen 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 ticketingsystems as well as suppliers designing and implementing such systems.

NPRA presuppose that ISO and CEN standards as well as the requirements and recommendationsgiven in Handbook 3 shall be used in projects that are funded by authorities on national and regionallevel. Hence, NPRA recommends that the use of Handbook 206 shall be part of the contract betweenthe authorities and the operators proving public transport services.

Norwegian Public Roads Administration

Directorate of Public Roads

June 10, 2004




4




5

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




6

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




7

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




8

1 BACKGROUND

This part of Handbook 206 contains detailed technical specifications for 2 different interoperableapplications:

1. A national application for purchase of local single tickets, based on a charge-to-accountproduct (NORTIC TravelContract) and international (ISO) and European (CEN) standardsconcerning commands and data elements

2. An alternative to the NORTIC ISO and CEN based specification using a mifare DESFireContactless 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 presupposesa smartcard with the ISO-7816 command set implemented. However, the current situation in Norwayconcerning implementation of electronic ticketing systems has influenced the Norwegian Public RoadsAdministration also describing how the mifare DESFire IC-card may be used as an alternative to thestandardisation based NORTIC specification.

Given the detailed technical nature of this specification, and the fact that valuable experience is gainedas 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 thatnew versions of the specification will be issued. In order to ensure an orderly and accountable processstrict version and change control will be enforced, and new versions will be made available through acomprehensive release process.




9

2 SPECIFICATION OF THE NORTIC APPLICATION AND

PRODUCT

This chapter includes the definition of the NORTIC Interoperable Product that the Customer mayacquire and use as payment means in exchange for use of transport services. The term Product isdefined in HB206 Part 1 in accordance with the definition used within the European standardisationbodies 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, andstands for NORwegian Ticketing Interoperable Concept.

• IFMSA stands for Interoperable Fare Management System Architecture (CEN TC278 WG3standard)

• IOPTA stands for InterOperable Public Transport Application (CEN TC278 WG11standard)

In order to allow the NORTIC product to co-exist with the regional / inter-regional products theNORTIC 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 typeCharge To Account. The Product is called a TravelContract or ‘Reiseavtale’ in Norwegian. The termProductTC 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 theCustomer. The payment between Customer and the Product Owner is out of the scope of thisspecification.

IOPTA definition of ChargeTo Account:

Identifies and provides further information concerning an authorisedaccount which may act as a ticket for a journey or be used to acquirea separate ticket.

Within the NORTIC specification the interoperable TravelContract is treated as being both a paymentmeans 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 contractagreement 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. Withinthis 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:




10

• The provision for the Customer of a seamless journey1

using the same smart card on differentService 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 theTravelContract 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 NORTICapplication Identifier. An occurrence of the TravelContract product is loaded in the NORTICapplication.

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 deliveredthe TravelContract to the User.

Local Product A product offered by a ProductLP Owner that usually is different from theProductTC 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 deliveredthe local product to the Customer.

Requirement

No

Requirement

[R 1] Product owners, e.g. a Public Transport Operator, may install a TravelContracton the ticketing medium offered to Customers. This national interoperableproduct shall be used in connection with purchase of single tickets (localproducts).

[R 2] The TravelContract shall be accepted in any Norwegian electronic ticketingsystem

[R 3] Clearing and settlement of sales and use of the TravelContract shall be donebetween 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 betweenthe ProductLP Retailer and the ProductTC Owner.

[R 5] The EFC transaction shall be protected against manipulation and fraud in sucha manner that the recipient of the claim or a Trusted Third Party (TTP) mayverify that the claim is justified/authentic (not mandatory).

[R 6] It shall be possible to trace any transaction back to its generation origin

1By 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.




11

Requirement

No

Requirement

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 NORTICspecification (TC278 WG3 SG5).

[R 8] The TravelContract shall be valid for two years from its issuing date. Thisrequirement is motivated by the requirement to keep the security listmanageable. It will be up to each ProductTC Owner if he will allow for theTravelContract to be renewed for another two years.

[R 9] The TravelContract defined within the NORTIC shall contain information aboutthe 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 inline 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 bestored 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 thisspecification.

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 areoutside the scope of this specification (Registrar, Security Manager and Collection & Forwardingservice). Within the scope of the NORTIC TravelContract specification we identify the followingentities:

• ProductTC Owner

• ProductLP Retailer

• Service Operator




12

• Customer

Interaction is required between these entities to fulfil interoperability functions of an Interoperable FareManagement System (IFM). An IFM system is a Fare Management System that can provide servicesand 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 TravelContractproduct on the Customers ticket media (IC card (smart card)). The ProductTC Owner holds the contractbetween himself and the Customer. A Contract is the expression of an agreement between theCustomer and the Product Owner, which defines the conditions under which the Customer may usethe NORTIC TravelContract as payment mean and how the central account is kept in balance. TheNORTIC TravelContract shall be issued on the ticket medium by all Product Owners, who whish tooffer this interoperable product to their customers (optional).

Retailer: The Retailer is the entity that sells the product to the Customer on behalf of the ProductOwner. 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 ticketmedia 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 acceptthe 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. TheProductLP 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 transportfunction for the Customer, in other words the actual transport provision (the physical bus, train etc). ACustomer benefits from a transport service and the Service Operator validates the Customers ticketpurchased from the ProductLP Retailer. The Service Operator collects usage data (transactioninformation) 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 andvalidation of the single journey ticket is performed in one operation.

Customer: A person that holds the NORTIC Application (cardholder). The Customer uses theNORTIC TravelContract as payment mean in order to pay for a single journey ticket allowing her toacquire travels provided by the Service Operator.

It is out of this specifications scope to define the Contract between the ProductTC Owner and theCustomer. How the central account is kept in balance is dependent on the agreement between theCustomer and the ProductTC Owner. For example, travels may be pre-or post paid. In the first case theCustomer pay in advance to a centrally held account managed by the ProductTC Owner, and all travelsare charged to this account. In the latter case an external financial institution, e.g. bank or Credit CardCompany, debits the Customers account subsequent to the travels.




13

Figure 1 Simplified sequence diagram for usage of TravelContract

2.4 TRAVELCONTRACT LIFE C YCLE

This section elaborates the life cycle phases of the NORTIC TravelContract. The TravelContract lifecycle 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 theTravelContract 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 theTravelContract. The Contract defines the conditions, under which the Customer may use the

TravelContract as payment mean. The contractual link between the ProductTC Owner and theCustomer also defines how the customers centrally held account is kept in balance. The NORTICTravelContract shall be issued on the Customers ticket medium by all Product Owners, who whish tooffer this product to their customers which means that

TravelContract issuance is not mandatory for Product Owners within public transportation.




14

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 andinitialised 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 andsecurity schema. The requirements to the ticket medium as well as application instalment and loadingthe TravelContract product on the application is specified in Chapter 4 “Smart Card and MediaAccepting 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 alsoprovides data to customer management (outside the scope of this specification). Securitymanagement 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 theTravelContract. Security keys and mechanisms shall be protected and stored in Secure ApplicationModules (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 TravelContractoccurrences. The status of the TravelContract may be open, pending or blocked. An openTravelContract occurrence is valid for use as payment mean at any ProductLP Retailer. BlockedTravelContract occurrences are not valid for use at any ProductLP Retailer. Reasons for blockingTravelContract 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 theProductTC Owner responsibility. Relevant data in a Card Register are (for mandatory data this iswritten in brackets, others are optional):

• Card serial number (mandatory)

• Security system key generation/version (mandatory)

• TravelContract status, as described above (mandatory)

• TravelContract balance




15

• 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

No

Requirement

[R 13] The ProductTC Owner is responsible for issuing the TravelContract on theCustomers ticket medium. The process of TravelContract issuance includesboth NORTIC application instalment and loading the TravelContract on theapplication.

[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 thisspecification when issuing the TravelContract. Security keys and mechanismsshall 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 thestatus 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 theNORTIC application based on an application identifier. Therefore the MAD must be able to identify andselect the NORTIC application on the ticket medium by one unique NORTIC application Identifier.

Requirement

No

Requirement

[R 17] The format of the NORTIC Application Identifier shall be in accordancewith ISO7816-5.

[R 18] The NORTIC Application Owner shall obtain a valid Registered ApplicationProvider Identifier from a Nationally Authorised ISO7816-5 Registration

Authority

After the application selection, the MAD identifies the TravelContract as specified in the TravelContractfile structure.

Requirement

No

Requirement




16

Requirement

No

Requirement

[R 19] TravelContract product identification shall be according to ProductIddefined in 2.7 Identification.

[R 20] The ProductTC Owner shall obtain a valid issuer identification number froma 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 equipmentaccording to the local Product Owners system regulations.

The ProductLP Retailer may accept the TravelContract with or without security mechanisms. TheProductLP Retailer is responsible for collecting product usage data when a TravelContract occurrenceis used. TravelContract usage data is the transaction information generated when the TravelContractis 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 ticketmedium 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. providesinformation that the identity of a source of data received is as claimed. Integrity ensures that thereceived 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 validityperiod)

• 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 theProductTC Owner claims the customer for the price of the single journey ticket or product. If nonpayment from the Customer the ProductTC Owner is still in relation to the ProductLP Retailer TheProductTC 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




17

The set of usage, pricing and commercial rules associated with the TravelContract product are listedbelow.

2.4.3 TravelContract usage, pricing and commercial rules:

Description

Usage rules

The TravelContract is valid for two years from its issuing date. TheProductTC Owner decides renewal for additional periods.

The TravelContract may be used as payment mean in any electronicticketing system in Norway in order to:

• 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 cardTravelContract log. A single journey ticket (proof of travel) may be paper based or electronically stored in the customer’s ticket medium (event login the smart card).

The ProductLP Retailer accepting the TravelContract is responsible for collecting product usage data in order to receive payment from theProductTC Owner. Product usage data (transactions) shall be signed bythe ticket medium, which enables the ProductTC Owner to verify theauthenticity and integrity of the claim from the ProductLP Retailer.

The TravelContract may be accepted as payment mean with or withoutsecurity mechanisms.

Pricing rules

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 pricingrules in the IFM system where the TravelContract is used as paymentmean.

The Customers centrally held account managed by the ProductTC Owner is charged when the TravelContract is used as payment mean. Thecontractual link between the ProductTC Owner and the Customer defineshow the centrally held account is kept in balance.

Commercial rules

The ProductLP Retailer accepting the TravelContract as payment meanforwards a claim to the ProductTC Owner subsequent to the ticketingevent. Settlement between the ProductTC Owner and the ProductLP Retailer is according to the agreement between the parties.

Requirement

No

Requirement

[R 21] Any ProductLP Retailer in Norway shall accept the TravelContract as paymentmean. 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)




18

Requirement

No

Requirement

The ProductLP Retailer writes a transaction into the TravelContract log of thecard.

[R 22] The ProductLP Retailer is responsible for collecting TravelContract usage data.Product usage data is the transaction information generated when the productis used, and includes payment information. The transaction data is forwardedto the ProductTC Owner in order to receive payment for the actual customer travel.

[R 23] The NORTIC ticket medium shall generate a MAC (Message AuthenticationCode), which enables the ProductTC Owner to verify the authenticity andintegrity 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 thesingle journey ticket or product. If non payment from the Customer the

ProductTC Owner is still responsible in relation to the ProductLP Retailer . TheProductTC Owner may deny claims from ProductLP Retailer in the followingsituations:

• The ProductLP Retailer accepts the TravelContract without securitymechanisms

• The ProductLP Retailer has not distributed the security list to theMAD equipment

2.4.4 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 shallprevent 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 followingsteps:

1. De-install the TravelContract on the ticket medium and update product status maintained by theProductTC 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 centrallyheld account and the contractual link between the Customer and the ProductTC Owner assumessettlement of all payment transactions. Completing settlement with ProductLP Retailer and the

Customer is the responsibility of the ProductTC Owner.

Requirement

No

Requirement

[R 25] The ticketing equipment shall prevent use of the TravelContract based onTravelContract information read from the ticketing equipment in situationswhere the validity period is exceeded (two years validity).

[R 26] TravelContract termination is the responsibility of the ProductTC Owner.




19

2.5 TRAVELCONTRACT AND SECURITY KEY MANAGEMENT

Clearing and settlement between the ProductLP Retailer and the ProductTC Owner take placesubsequent to the Customers use of the TravelContract as payment mean. To prevent use of theTravelContract 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 theProductTC Owner to distribute security lists to the ProductLP Retailer accepting the TravelContract aspayment 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 physicalexchange of information between identified entities. Security key management is also considered inthis section.

2.5.1 Clearing and settlement

Clearing and settlement for the use of the NORTIC TravelContract shall be done between theProductTC Owner and the ProductLP Retailer accepting the TravelContract as payment mean. Clearingis the processing and possible consolidation of transaction information passing between the partiesaccepting the NORTIC TravelContract as payment mean on each other’s behalf. This situation isillustrated in Figure 3. The ProductLP Retailer accepts the NORTIC TravelContract as payment meanwhen 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. TheCustomers centrally held account is charged for the price of the product. The transaction informationforwarded from the ProductLP Retailer is a claim directed towards the ProductTC Owner. The actualsettlement between the ProductTC Owner and the ProductLP Retailer is according to the agreementbetween these two parties. In some situations the Product Owner and Retailer may be the sameentity, 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 occurrencesof the TravelContract as payment mean. Figure 4 illustrates a situation where the Customer has usedthe TravelContract as payment mean at several ProductLP Retailer in order to travel with severalService 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 shallbe done according to the agreements between the parties.




20

Figure 4 Settlements between ProductTC Owner and RetailersLP

Requirement

No

Requirement

[R 27] Clearing and settlement for the use of the NORTIC TravelContract shall bedone between the ProductTC Owner and the ProductLP Retailer accepting theTravelContract as payment mean.

2.5.2 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 listof blocked TravelContract occurrences (security list) to the ProductLP Retailer accepting the NORTICTravelContract as payment mean. The security list, also called blacklist, is distributed to the ticketingequipment to prevent use of a blocked TravelContract occurrence. It is the responsibility of theProductTC Owner to maintain the status of the issued TravelContracts. The status of a TravelContractoccurrence 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

No

Requirement

[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 fromthe ProductTC Owner and shall distribute the security list to all user equipment/MAD.

2.5.3 Physical exchange




21

The actual physical exchange of transactions/claims and security list shall be done according toagreements between the parties involved. Whether an electronic media does the exchange sentthrough the mail system or through advanced communication systems is out of the scope of thisspecification. 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 un-authentic. This introduces the need that ProductLP Retailer accepts TravelContract issued in anauthentic way (TravelContract production data authentication)

The ProductTC Owner and the ProductLP Retailer will often be two different legal organisations andtherefore 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 installedin the ProductLP Retailer MAD for accessing the NORTIC application. The SAM shallensure the confidentiality and integrity of the TravelContract authentication keys.

• The ProductTC Owner must be able to distribute the TravelContract authentication keys tothe ProductLP Retailer MAD SAM. The security includes confidentiality, integrity and peer-to-peer origin authentication. Furthermore the ProductTC Owner must be able to update,invalidate and revalidate authentication keys throughout the TravelContract life cycle. Example: Product

TC Owner typically uses a symmetric method with DES/3-DES and a one-

level diversification of the authentication master key with 8 master key generations.

• The ProductTC Owner must be convinced that the TravelContract authentication keys arekept secret throughout the TravelContract life-cycle (focusing on the SAM segmentintegrity)

• The ProductTC Owner and the ProductLP Retailer must be able to exchange clearing andsettlement data in a secure way. This includes integrity, peer-to-peer authentication andnon-repudiation.

Within NORTIC there will be three master keys generated for handling TravelContracts.

Requirement

No

Requirement

[R 30] The ProductTC Owner is responsible for selecting the appropriate authenticationmechanism of the TravelContract (symmetrical versus asymmetrical) andprovides a secure download of authentication keys to the ticket medium.

[R 31] The ProductTC Owner and ProductLP Retailer MAD SAM shall exchangeauthenticated public keys.




22

Requirement

No

Requirement

[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 responsibilitiesand 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 actualentity.

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 theProductLP Retailer MAD SAM’s.

Yes

TravelContract issuance The ProductTC Owner is responsible for installingthe NORTIC application and the TravelContractoccurrence on the Customers ticket medium

Optional

Contractual link with thecustomer

The Contract between the ProductTC Owner and theCustomer defines the conditions, which under theCustomer may use the TravelContract as paymentmean. The contractual link between the ProductOwner and the Customer also defines how thecustomers centrally held account is kept in balance.

Yes

Collecting Customer data The ProductTC Owner collects Customer data whenthe TravelContract is issued. The ProductTC Owner maintains Customer data in his system.

Yes

Charge centrally heldaccount

The ProductTC Owner is responsible for chargingthe centrally held account when claims are receivedfrom ProductLP Retailer.

Yes

Settlement with Retailers ProductLP Retailer forwards claims to the ProductTC Owner in order to receive payment for travels paidwith TravelContract occurrences. The agreementbetween 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 distributionof security list to ProductLP Retailer accepting the

Yes




23


TravelContract as payment mean. The security listconsists of a list of blocked TravelContractoccurrences.

TravelContract termination The ProductTC Owner terminates TravelContractoccurrences and the centrally held account.

Yes

2.6.2 ProductLP Retailer responsibilities


Security key usage The ProductLP Retailer may authenticate theTravelContract, and shall in that case receive, storeand handle authentication keys from the ProductTC Owner according to his rules.

Optional

TravelContract productusage

Any ProductLP Retailer shall accept theTravelContract product as payment mean.

Yes

Collecting usage data The ProductLP Retailer collects TravelContractusage data (transaction information) when aTravelContract is used as payment mean.

Yes

Claim the ProductTC Owner The ProductLP Retailer forwards collectedTravelContract usage data (transaction) to theProductTC 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 ticketingequipment to prevent use of blocked

TravelContracts.

Optional

2.6.3 Customer responsibilities


Contractual link with theProductTC Owner

The Customer establishes a Contract with theProductTC Owner. The Contract defines theconditions, which under the TravelContract is usedas payment mean, and how the centrally heldaccount 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 centrallyheld account is kept in balance is defined in thecontract between the ProductTC Owner and theCustomer.

Yes




24

2.7 IDENTIFICATION

2.7.1 IntroductionBy identification is meant a set of attributes that describes a specific person or object in a unique andunambiguous way. A person can for instance be described by name, birth date, sex, address etc to beuniquely identified. An object, e.g. a ticketing machine, can be identified by owner, type and serialnumber.

Identification is important in an electronic ticketing system as well as in an Interoperable FareManagement (IFM) system for following main reasons:

Security

Identification of entities, objects, applications, products etc enables the use of Security l ists, e.g.blacklisting a stolen retailer machine or a stolen ticket media. It also enables authentication andmessage integrity, e.g. by using the unique identification in an authentication procedure or includingthe 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 willbe acting as a sender and/or a receiver of information. A unique identification is needed for addressingthe 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 anIFM system, e.g. following a usage transaction from the creation by the service provider until it iscleared and refunded by the product owner. If something goes wrong or any information is changedduring its lifetime it is important being able to investigate what happened and where in the IFM systemit happened.

2.7.2 Numbering schemeAs a minimum the following objects shall have a unique identity in an IFM system:

A. All Applications (implemented and initialised Application Templates)B. All Products (instances of Product Templates)C. All Actors (organisations) involved in the IFM system, e.g. all product and application

owner, retailers, transport service providers and clearing and forwarding operators.D. All Security Sub Systems (SSS), e.g. a SAM with keys used for cryptographyE. All Components handling, storing and transferring IFM information

NOTE 1: The numbering scheme is based the prerequisite that all objects are present within thesame 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 IOPTAapplication 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 compactas possible due to the minimisation of the transaction time between the Customer Mediaand 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 itsnational standardisation body.




26

ComponentOwner is any registered organisation within the IFM system, i.e. a number within0….1.048.575. The ComponentGenericType is a number between 0….127 where the list of genericcomponent 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 buscompany, 45 is the component type, e.g. a validator with ISO 14443 Type A communication, and 789is 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 within0……1.048.575. The ApplicationGenericType is a number between 0…127 where the list of genericapplication types is kept by the Registrar. The Application Owner may have his own set of applicationtypes 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))




27

EXAMPLE:

An Application Template may be uniquely identified by 1089.4.17 where 1089 is the organisationidentity, 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 within0………1.048.575. The ApplicationSequenceNumber is date and time and is the current values as theMAD installs the application on the Customer Media.

The data elements given in the previous paragraph are sufficient to uniquely identify an application onthe Customer Media (who issued, what type, which serial number (when)). However, for securityreasons there is a need to stamp the application. Hence, for the application registration by theRegistrar 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 by1089.4.17.478.478.23.3457.20041130153406 where 1089 is the Application Owner, 4 is theapplication generic type, 17 is the application sub type, 478 is the Application Retailer and componentowner, 23 is the equipment type, 3457 is the equipment serial type and 20041130153406 is thesequence 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.




29

}

DateCompact ::= BIT STRING (SIZE(16))

TimeCompact ::= BIT STRING (SIZE(16))

EXAMPLE:

A product on the Customer Media may be uniquely identified by765.15.167.478.478.123.3214.20041224094534 where 765 is the Product Owner, 15 is the productgeneric type, 167 is the product sub type, 478 is the Product Retailer and Component owner, 123 isthe equipment type, 3214 is the equipment serial type and 2004122409453406 is the sequencenumber (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 Bits in Octet Description

1 00000000

2 00101111ProductOwner

1101

Organisation number 765

3

0001ProductGenericType

111

Product generic type 15

4

10100ProductSubType

111

Product sub type 167

500000

6 00000011ProductRetailer

1011110


7

0

8 00000000

9 00111011ComponentOwner

110


10

11110ComponentGenericType

11

Component generic type 123

11

110010ComponentSerialNumber

001110

Component serial number 3214

12

00

13 01110110

011000

Dec 24, 2004

14 ProductSequenceNumber

01




30

15 00110110

16 110001

2.8.7 Security Sub Systems identification

A Security Sub System, e.g. an IC card, is uniquely identified by a number within the IFM system. Thenumber is the concatenation of SecuritySubSystemOwner, SecuritySubSystemGenericType andSecuritySubSystemSerialNumber.

SecuritySubSystemOwner is any registered organisation within the IFM system, i.e. a number within0….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 theorganisation 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 theApplicationId is given below.

Octet # Data element Bits in Octet Description

1 oooooooo

2 ooooooooApplicationOwner

oooo

IFM Organisation number

0… 1.048.575

3

gggg

4

ApplicationGenericType

ggg

IFM Application generic type

0….127




31

sssssApplicationSubType

ss

Application sub type

0…1275

rrrrrr

6 rrrrrrrrApplicationRetailer

rrrrrr


0… 1.048.575

7

oo

8 oooooooo

9 ooooooooComponentOwner

oo


0… 1.048.575

10

ggggggComponentGenericType

G

IFM Component generic type

0….12711

sssssssComponentSerialNumber

sssss

Component serial number

0….4.09512

yyy

13 yyyymmmm

ddddd

Date in DateCompact format

14

hhh

15 hhmmmmmm

16

ApplicationSequenceNumber

sssss

Time in TimeCompact format




32

3 SECURITY POLICY AND REQUIREMENT

SPECIFICATION

The section outlines the overall security policy and requirements applicable for a nationallyinteroperable ticketing system, NORTIC.

This section contains the security architecture, overall threat analysis, security policy and securityrequirements that apply for the NORTIC system.

A few overall goals have been defined for the NORTIC interoperability specification for electronicticketing

• The NORTIC specification shall enable different levels of security. These levels of securityshall be defined as specific security profiles. The NORTIC specification shall be open toinclude 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 theCustomer 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 supersedespossible financial drawbacks (such as financial costs related to implementation and procedures). Itshall 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 tothe 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 toNORTIC 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 NORTICsystem. For convenience two different security profiles are defined to provide the minimumset of security requirements enhancing the implementation of compliant systems to thisspecification.




33

Each system implementation (or certain system modules) may be certified based on their claimedcompliance to this specification. However, it shall be emphasised that no test or any certificationprocedures 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 risksassociated with implementing and operating a ticketing system according to NORTIC Specifications.

Threat and vulnerability analysis in this specification concerns an overall assessment of the mostprobable threats and the system’s vulnerability to these threats. This will enable the next step, beingthe definition of a security policy that shall countermeasure the threats.




34

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 realisedas successful attacks (resulting into break of integrity and penetration into assets).

The threat analysis includes definition of possible attackers and threat targets (containing assets), andan 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, withstate 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 exploitedby them or any other outsiders.

The classification of attackers (ranging from 1-4) is included to indicate that the higher the class, thehigher is the likelihood that severities of the attack are high. On the other hand, the higher (lower) theclass given, the lower (higher) number of people might be able to carry out the attack. This may usedlater 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 withinthe NORTIC system. These are:

• TravelContract

• MAD of either Application owners and retailers, Product Owners and Retailer and ServiceOperator




35

• 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 theprobability and severity of various attack strategies.

It is the current assessment that since the NORTIC System is intended to providing services againstsome sort of electronic payment, only various forms of financial gain are considered as primary threatobjectives. Generic threats like: ‘misuse of information’, ‘segment integrity breaks’ are considered as apart of the attack strategy. The fact that successful attacks may impose threats to other relatedsystems has been deliberately suppressed in this specification as their vulnerabilities and threatobjects cannot be assessed.

Primary ThreatObjective

Attack Strategy Likely Attacker Necessary attacker class

Sabotage of MAD Customers Class 1Repudiation of ElectronicPayment

Customers Class 1

Replay of Messages Customers Class 2

TravelContractMasquerade

Customers Class 2

Financial gain byevading paymentand/or obtaining freeservice

Cloning of TravelContracts Customers Class 3, possibly alsoClass 4.

Financial gain byreselling products

Cloning of TravelContracts Customers Class 3, possibly alsoClass 4.

Replay of Messages

Cloning of Messages

Financial gain by

claiming refund fromfraudulentTransactions Repudiation of Messages

Service Operators Class 3 in combination

with Class 4

As already indicated, the threat objectives cannot be successfully accomplished without proper attackstrategies 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 thebelow table:

Attack Strategy Primary Attack Methods Secondary Attack Methods

Repudiation Denial of used service None further

Sabotage Set Service Operator MAD into None further




36

non operational state

Eavesdropping None further

Manipulation of data Alteration of HW and/or SW

and/or application data.

Product Masquerade

Disclosure of SensitiveInformation

Theft of MAD

Message Replay Record and Replay Eavesdropping and timingattacks

Product Medium SegmentTampering

Theft of TravelContracts inManufacturing, Distribution or Issuance

Insider Abuse such that valuedinformation (secret keys) aredisclosed.

Alteration of HW and/or SW

Cloning of TravelContracts

Disclosure of Sensitiveinformation

Theft of MAD to retrieve secretkeys

Message Replay Eavesdropping and timingattacks

Insider Abuse such that valuedinformation (secret keys) aredisclosed.

Alteration of HW and/or SWand/or application data

Cloning of Messages

Disclosure of Sensitiveinformation

Theft of MAD to retrieve criticalfunctions (secret keys)

3.3 SECURITY POLICY

The NORTIC System Security Policy addresses how the threats specified in section 3.2 shall becontrolled 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/culturalvalues. 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 publictransport service strategic goals are met.




37

• Fairness of payment:

Customers shall be convinced that everyone is paying the correct amount according tovalid 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 isrelated 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 withinthis document, but should nevertheless be encountered for and followed within any organisationresponsible 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 customerspossessing variable skills (various attack classes) that might lead to security compromises. Thefollowing strategies to minimise financial loss shall be adopted:

1. Unjustifiable denial of used services shall be discouraged. Routines shall be defined thataddress the management of disputes between customer and service operator. Due to thedifferent sizes of the various systems accepting a TravelContract, each systemimplementation 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 inthe ticketing system, shall not be economically viable for the customers. The NORTIC systemshall be prepared to countermeasure extensive attempt to conduct masquerade.

4. Cloning attempts of TravelContracts for unauthorised reselling are regarded as an offence andpotentially detrimental to the integrity of the NORTIC system. Therefore, within reasonablecost boundaries, maximum technical efforts should be considered to avoid cloning of theTravelContract.

3.3.3 Trust Levels

The NORTIC system implementations may be of different levels of magnitude and cover differentregions. Also the exposure levels of the threat may vary not only due to geographical limitations butalso 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 theNORTIC system. The trust level may vary with time, magnitude and geographical location of theNORTIC system. Finally the implementation of a NORTIC system will reflect the fact that trust levelsdetermine security requirements.

For example, due to the fact that there is a limited number of ProductTC Owners in Norway resultinginto a high trust level between them, it is recommendable that ProductTC Owner share a common setof master keys. A Trusted Third Party (TTP) serves as a notary between ProductTC Owners in case of any conflict.




39

• TravelContract SAM may have limited capacity for supporting different Products and willhave 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 commonTravelContract master key set. This TravelContract Master Key set will be generated anddistributed through a Trusted Third Party (TTP) to each authorised ProductTC Owner.

2. Distribution of TravelContract, TravelContract SAM and MAD shall be done in a secureway in the sense that the ProductTC Owner or corresponding entity is responsible that theconcerned modules do not fall into the hands of unauthorised parties. This includes:

• TravelContract must only be distributed to customers identified under a validcontract. The ProductTC Owner is responsible for the security of theTravelContract, including the detection of un-authentic TravelContracts, ensuringadequate measures (such as security listing and introduction of TravelContractSAM 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 theProductTC Owner. The ProductTC Owner is responsible for the administration andlogistics 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 theadministration and logistics of each individual MAD (including keep them protectedagainst 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, securityrequirements 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/Retailer TC shall beenabled through electronic proofs contained in the TravelContract and Transaction Messagesresided in the system. The ProductTC Owner/ ProductTC Retailer is responsible of providingsuch services to the public.

7. Verification of disputes between Product Owners/Retailer/Clearing Houses shall beenabled through electronic proofs contained in the Transaction Messages resided in the




40

system. A duly appointed notary / TTP is responsible of providing such services betweenProduct Owners.

3.4 SECURITY REQUIREMENTS

The security requirements comprise the last step in defining the overall security architecture for theNORTIC 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 aresult of a treat analysis the following chapter define the NORTIC security profile and relatedrequirements.

Requirement

No

Requirement

[R 33] The NORTIC specification shall include a set of security profiles that enablesthe 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 securitymechanisms

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 theauthenticity and integrity, see NOTE 1.

[R 35] TravelContract Master keys shall be protected and stored in TravelContractSecure Application Modules (TravelContract SAM) wherever securitymechanisms 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.6Message 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 uniquelyidentified and registered.

[R 38] TTP shall only distribute TravelContract Master keys to a registered




41

Requirement

No

Requirement

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 3DESalgorithms 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 asecure way.

[R 42] Key management protocol shall be according to the international standard ISO11770 Part 1 and Part 3.

[R 43] The security level of the TravelContract SAM shall be implemented andcertified according to Level 2 of FIPS PUB 140-2.

[R 44] The exact make and type of TravelContract SAM shall be approved by TTPbefore usage.

[R 45] When used to verify the TravelContract, the TravelContract SAM shall supportan 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 asource of data received is as claimed.

Integrity ensures that received data is unchanged or unmanipulated, i.e. protection againstunauthorised 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 trustlevel between them. Also this issue is necessary to enhance a cost effective solution withacceptable security level. A Trusted Third Part (TTP), appointed by the ProductTC Owners,generates the TravelContract Master keys on behalf the ProductTC Owners and isresponsible for ensuring that these keys are distributed to the registered TravelContractSAMs only.




43

[R 55] The MAD shall implement mechanisms that ensure availability andrecovery 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 theProductTC 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 theProductTC Owner and the Customer also defines how the customerscentrally held account is kept in balance.

[R 59] The MAD shall forward all TravelContract data to ProductTC Owner suchthat they may be linked to customers centrally held account (for exampleTravelContract Identifiers). In case data are transferred over an openinterface, the following data protection mechanisms apply:

• Data integrity (message authentication codes)

• Confidentiality (encryption)

• Entity authentication

[R 60] The ProductTC Owner is at all time responsible for keeping the MAD andTravelContract SAM under adequate protection from theft.

Management of Transactions

Requirement

No

Requirement

[R 61] The ProductTC Owner Central System shall be able to authenticate itself toother systems/modules (MAD, Retailer’s and Service Operator’s systems)

[R 62] The ProductTC Owner Central System shall prevent any unauthorisedaccess to any TravelContract related data.

[R 63] The ProductTC Owner shall strictly control the manufacturing, storage,initialisation, personalisation and distribution of critical components of theCentral System.

[R 64] The Central System shall prevent any unauthorised access to anyTravelContract related transaction data.

[R 65] The Central System shall implement mechanisms that ensure availabilityand recovery of any data if it is defect or malfunctioning.




44

[R 66] The Central System shall support access control mechanisms whenoperated 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 todetect any abnormal situation.

[R 68] The Central system shall send a copy of transactions and claims to theTTP.

[R 69] The Central System shall maintain up-to-date security lists of acceptedTravelContracts.

[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 andtheir equipment, typically a MAD.

Requirement

No

Requirement

[R 71] The ProductLP Retailer may authenticate the TravelContract and shall in this caseuse a TravelContract SAM and related verification mechanisms as given in 4Security 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 tothe ProductLP Retailer in order to receive payment for travels that have been paidwith TravelContract occurrences.

[R 74] ProductLP Owner may receive security lists from ProductTC Owners. It is theresponsibility 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 andhis equipment, which is typically a MAD.

There are no security requirements to the Service Operator related to the TravelContract, as thepurchase 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 theabove section.




46

3.4.8 Interface ProductLP Retailer – ProductTC Owner

Requirement

No

Requirement

[R 89] Information exchange between ProductLP Retailer and the ProductTC Owner shallinclude some level of mutual identification of involved parties and communicationshall 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

No

Requirement

[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 suchidentification 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 thisinformation shall be as follows

• Key files (containing TravelContract Master Keys) shall be encryptedusing encryption algorithms based on minimum 3-DES and preferablyRSA with a minimum key length of 2048 bits

• Copies of transaction data shall be encrypted using minimum DES (56bits)




48

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 ICCards.

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 theNORTIC application. The MkeyN-MAC is used by the ProductTC Owner for verifying a claim from aProductLP 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 toProductLP Retailers in case the local product shall be written to the DF NORTIC / EF LOG whichrequires an ICC authentication of the MAD using the ICCkeyN-MAC.

Entity Key storedin

MkeyN-App(G)

MkeyN-Prod(G)

MkeyN-MAC(G)

ICCkeyN-App(G)

ICCkeyN-Prod(G)

ICCkeyN-MAC(G)

NORTICApplication

Owner

SAM

√ √ √

NORTICApplicationRetailer

MAD withSAM or access toSAM

√ √ √

ProductTC Owner (TravelContract)

SAM √ √

ProductTC MAD with √




50

3. Assume that the 15 leftmost bytes of the ApplicationId is ’12 23 45 67 89 1A BF ED AE 1D 7D5C 8C 5F DD’. The rightmost byte is 0111 1bbb2 where b denotes blank bits before the three0-bits are appended to form the 16

thbyte. 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 FDB4 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 a16 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 a16 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 achievinga 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 valuesProd||ComponentId||DateCompact||TimeCompact achieving a 3 x 64 bits data block.




51

6. Calculate the MAC according to ISO 8731-1 Banking – Approved algorithms for messageauthentication Part 1 DEA implying that the MAC will be the 32 leftmost bits of the output of EICCkeyN-MAC (M)




52

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 inthis chapter be broken down and refined into more specific requirements and specifications. The dataelements necessary to provide the functionality and security related to NORTIC are defined. Thesedata 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 ICcard 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 theNORTIC 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 isrecommended that this is the same entity as the ProductTC Owner.

• ProductTC Owner : The entity that owns the product TravalContract installed in the NORTICapplication.

• Customer: The user/holder of the NORTIC media (cardholder).

• NORTIC TTP: This role is responsible for generating and distributing security keys to theactors 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 NORTICsystem.




53

5.3 CUSTOMER MEDIA REQUIREMENTS

Requirement

No

Requirement

[R 98] The Customer media should be a dual-interface IC card and shall by any case beone of the following categories:

Recommended types

• Customer media type 1: Contact interface according to ISO 7816-3and contactless interface according to ISO 14443 Type A

• Customer media type 2: Contact interface according to ISO 7816-3and contactless interface according to ISO 14443 Type B

Alternative types

• Customer media type 3: Contactless interface according to ISO14443 Type A

• Customer media type 3: Contactless interface according to ISO14443 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-3and ISO 14443-2 and –4 (type A and/or B), and initialisation and anti-collisionaccording 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 1General 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 S YSTEM REQUIREMENTS (COS)




54

Requirement

No

Requirement

[R 103] The COS shall be able to have different access rights for reading, writing andcreation/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 tobe 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 theaccess 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 contactpads and antenna, and embedding it in plastic.

2. Pre-personalisation: Still at the manufacturer this is a phase where uploading of transportkeys, and generation of the Master File (MF) happens. Additional operations based on thewishes of the Card Owner can also be performed.

3. Issuing: This phase is done by the Card Owner after the card is received from themanufacturer. Transport keys are replaced with the Card Owner keys and the environment isprepared for one or more applications.

4. Application Issuing / Product Loading: The application file-structure is generated andseparate keys for the application is generated and installed. Then the product is loaded intothe application. The card is now ready to be used.

5. Active: Now the card is in the hands of the Customer (cardholder). By accessing severalkinds of MADs the cardholder loads products into the card, and gains the right to use PTservices offered by Service Operators.

6. Disabled/Blocked/Destroyed: After several years in the active state the card has beenconsidered unsafe, lost or just broken. If possible the card is returned to the Card/ApplicationOwner and destroyed.

5.5.1 Production and Pre-personalisation

These phases have little consequence for the NORTIC application and aremostly an arrangement between the Card Owner and the CardManufacturer. After normal pre-personalisation the file structure will likely be

as presented in the figure o the right

5.5.2 Card Issuing

The Card Owner will have to prepare the card toaccept one or more applications, and the firststep is to replace the manufacturer transport keyswith his own keys.

MF

EF-Key(transport

MF

DFNORTIC

EF-Key(NORTICtransport)

EFApp Dir

EF-Key(card owners)




55

The most practical and secure way to prepare the card for the NORTIC application would be to createthe 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 NORTICTransport 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 tothe 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 theremaining 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 conditionthat 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 onthe 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 thecard, see Figure 8: File structure for NORTIC application on the next page. The TravelContract isstored 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 fullresponsibility of the Card Owner. These keys control the access to creating and deleting elementary-files (EF) and directory-files (DF) under the Master File. They are designated with Card Owner-KeyNand they must exist in a certain number.

NORTIC Transport Key: This key is used when the Card Owner have made the NORTIC-DF ready touse by the Application Owner.

NORTIC Application Keys:

The Application Owner generates and writes the secret keys that are used by the NORTIC applicationto the card during application issuance using the NORTIC Masterkeys:

• ICCkeyN-App

• ICCkeyN-Prod

• ICCkeyN-MAC




56

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

DFNORTIC

DFAnother

Applicatio

EF-Key(NORTIC

Application keys)

EF-TravelContract

EF-Log

EF-Key(card owner)

EF-Local

EFApp Dir

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 anexample is presented for completeness.

Name: 0x3F00Type: MFSize: 2k/4k/8k Bytes (Dependant on card type)

Right Permission Key

DIR Authentication Card Owner-KeyNAccess Rights: DELETE Authentication Card Owner-KeyN

CREATE Authentication Card Owner-KeyN

5.6.4 EF-AppDir

The EF-AppDir is an application directory based on ISO7816-5. If the name of the NORTIC-DF shouldbe variable then the MAD must use the application directory to locate the correct DF.

The format of EF-AppDir is defined in ISO7816-5.




57

5.6.5 DF-NORTIC

The DF-NORTIC directory file must be big enough to contain the other f iles 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: 0x071CType: DFSize: >300 bytes


Access Rights: DIR Authentication ICCkeyN-ProdDELETE Authentication ICCkeyN-AppCREATE Authentication ICCkeyN-App

5.6.6 EF-TRAVELCARD

The file will be the container for both information about the NORTIC application and theTravelContract. Only the NORTIC Application Owner and Product Owner (TravelContract) has therights to alter the information stored here.

Name: 0x0C7AType: FixedFormat: 1 record 32 bytes


READ Always N/AAccess Rights: UPDATE Authenticate ICCkeyN-Prod

REHABILITATE Authenticate ICCkeyN-ProdINVALIDATE Authenticate 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 LOG-file is made of a number of records that is assumed to behave in a “First in, First out” manner. The lastrecord written to will be the first one accessed when reading. Any writings will replace the oldestrecord. This file is considered UNSECURE (meaning that anyone can write to it) and the informationhere must be treated accordingly. The number of records will be dependant on available card memory,but minimum number of records should be 3.

Name: 0x0106Type: CyclicFormat: >3 records 32 bytes


Access Rights: READ Always N/AUPDATE Always N/AREHAB Authenticate ICCkeyN-ProdINVAL Authenticate ICCkeyN-Prod




58

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 Retailer LP can choose other methods to transfer the product tothe customer, e.g. a paper ticket. This file requires authentication before it can be written to, so it isconsidered secure enough for storage of the intended information. Since the file has limited spacethere must be a way to discern if the products already stored in the file can be overwritten by newones.

Name: 0x010CType: CyclicFormat: >3 records 32 bytes


Access Rights: READ Always N/AUPDATE Authenticate ICCkeyN-MACREHAB Authenticate ICCkeyN-ProdINVAL Authenticate ICCkeyN-Prod

Contents of file:

• All Records - LocalProduct

5.6.9 EF-KEYThe content of this file, and even its existence, is mainly dependent on the COS. From therequirements one can say that this file must include at least three different 8 bytes keys and that oneof those keys also is used when the key file is updated. The Card Owner or Application Owner only

updates the file.

Name: COS dependantType: COS dependantFormat: COS dependant


Access Rights: READ Never N/AUPDATE Authenticate ICCkeyN-AppREHAB Authenticate ICCkeyN-AppINVAL Authenticate ICCkeyN-App

Contents of file:• COS dependant.




59

5.7 DESCRIPTION OF A TRAVELCONTRACT USAGE TRANSACTION

Whenever a Customer wants to use his TravelContract for purchasing a local product, e.g. a singleticket for a bus ride, there will be a communication between the IC card (Customer media) and theMAD (Media Accepting Device), e.g. a ticketing machine, operated by the Retailer LP selling the singleticket. 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 cardto speak the same protocol and activate the IC card. After activation, the IC card responds with anATR (for contact communication) or ATS (for contactless communication), which will provide enoughinformation 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 thatparticular card. The following sequence should be performed:

Line

no

Function ISO command

1 Select the DF with the NORTICApplication

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 itscorresponding DF name

5 Select the DF with the NORTICApplication

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 NORTICDF.




60

Lineno


1 Select the EF with the TravelCard data

(EF-TRAVELCARD)

SELECT FILE (0x0C7A)

2 Read the TravelCard data READ RECORD (1strecord, 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 withTravelCard

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 theproposed transaction. The MAD shall at least check the following information:

Lineno


1 Check the mappingType ,keyGeneration and ProductOwner data

elements against lists of values thatthe MAD can or cannot support.

2 Check the ExpiryDate against currentdate

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 aMessage Authentication Code (MAC) from the card for an authentication of the TravelContract.

NOTE: The Retailer LP and the ProductTC Owner may have an agreement that theTravelContract may be used without security, i.e. there is no authentication of theTravelContract.

NOTE: The validation of the TravelCard can be written to the file(s) EF-LOG and the EF-LOCAL (optionally). If the validation of the TravelCard shall be written to the EF-LOCAL the authentication phase is required.




61

IC Card authenticates the MAD (optional)

The IC card challenges the MAD that has to respond with the correct answer. A positive result isrequired for the MAD to write new data to the EF-LOCAL.

Lineno


1 The MAD asks the IC card to return arandom number

GET CHALLENGE (Random Number, 8bytes)

2 The MAD calculates the authenticationdata using a defined algorithm (DES),the random number and the ICCkeyN-MAC that has to be calculated by theMAD based on the MkeyN-MAC andApplicationId.

3 The MAD returns the authentication

data to the IC Card.

EXTERNAL AUTHENTICATION (Reference

to the algorithm (DES), referenceto the ICCkeyN-MAC, authenticationdata)

4 The IC card calculates the sameauthentication data and responds tothe MAD. OK means that the MAD isauthorised to update data in EF-LOCAL, NOK means access is denied.

EXTERNAL AUTHENTICATION Response(OKor 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 (ApplicationRetailer).

Lineno


1 The MAD sends a random number tothe IC card and asks the card to returnauthentication data (response tochallenge)

INTERNAL AUTHENTICATE(Reference tothe algorithm (DES), reference tothe ICCkeyN-MAC, Random Number)

2 The IC Card calculates the‘authentication data’ (response) usinga defined algorithm (DES), the random

number and the ICCkeyN-MAC

3 The IC card returns the ‘authenticationdata’ to the IC Card.

INTERNAL AUTHENTICATE Response(authentication data’)

4 The MAD calculates the sameauthentication data and compares itwith the ‘authentication data’.




62

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 Retailer LP 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.

Lineno


1 The MAD sends a message (seechapter 3 for details on message) tothe IC card and asks the card to returnauthentication data (MAC)

INTERNAL AUTHENTICATE(Reference tothe algorithm (DES), reference tothe ICCkeyN-MAC, message)

2 The IC Card calculates theauthentication data (MAC) using adefined algorithm (DES), the messageand the ICCkeyN-MAC.

3 The IC card returns the authenticationdata (MAC) to the IC Card.

INTERNAL AUTHENTICATE Response(MAC’)

4 The MAD calculates the same MACand compares it with the MAC’.

5.7.4 Data storage

The MAD writes the result of the usage to the IC card. Writing to the EF-LOG is mandatory whilewriting to the EF-LOCAL requires authentication (IC card authenticates MAD) and is by this optional.

Lineno Function ISO command

1 The MAD selects the EF-LOG SELECT FILE (0x0106)

2 The MAD writes the data EventRecordto 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 LocalProductto the file EF-LOCAL (requiresauthentication of the MAD by the ICCard)

WRITE RECORD (LocalProduct)




63

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 salesoffices, ticketing machines and validators.

Requirement

No

Requirement

[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 andcontactless interface according to ISO 14443 Type A and B

Alternative types

• MAD type 2: Contactless interface according to ISO 14443 Type A andB

Ticketing machines and ticketing automats could be of type 1 while validators ontransport means, e.g. a bus could be of type 2.

[R 108] The MAD shall accept IC cards with physical characteristics according to ISO7816- parts 1 & 2 and ISO 14443-1.

[R 109] The contact interface (if present) shall use electronic signals and transmissionprotocols according to ISO 7816-3

[R 110] The contactless interface shall use electronic signals and transmission protocolsaccording to ISO 14443 parts 2 and 4 of Type-A and Type-B), and initialisation andanti-collision according to ISO 14443-3.

[R 111] The MAD and its application should be able to send commands according to ISO7816-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 theEN1545 standard, and a more detailed description of their use may be found there.

Element name Data type name (EN1545) Element descriptionaccountNumber 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




64

Element name Data type name (EN1545) Element description

keyGeneration KeySetVersion Security identifier, tell which algorithm andkey generation to use during authentication

certificate I4 Message Authentication Code (MAC)

mappingType MappingTypeCode Tells which version and variant of thisstandard to use when interpreting the ASN1encoded 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 tothe Transport Service (e.g. Entry, Exit,Validation)

deviceId DeviceId Identifier that will point to the specific device

(MAD) used during the transactionstopId StopId Identifier for the location of the transaction

productData OCTET STRING This is private information is only relevantand understandable by the MADs that willuse the local product

ASN.1 Encoding

Considering the limited storage space on smartcards and the general practice in related standards likeEN1545, it is recommended to use the following the Packed Encoding Rules for transforming datastructures to binary data.

Requirement No Requirement

[R 112] The MAD shall use Packed Encoding Rules (PER) in non aligned mode toencode the ASN.1 datastructures.




65

5.10 NORTIC ASN.1 SPECIFICATION

The following ASN.1 module shall, in combination with the ASN.1 module from EN1545, provide acomplete 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 shouldby 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 EventHeader,

eventDetails Events

}




66

-- structures and building blocks.

NorTicAppInfo ::= SEQUENCE {applicationId ApplicationId

mappingType MappingTypeCode,

keyGeneration KeyGeneration,

}

ApplicationId ::= SEQUENCE {

applicationTemplateId ApplicationTemplateId,

applicationRetailer ApplicationRetailer,


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))




67

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 ProductTemplateId,

productRetailer ProductRetailer,


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




68

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 LocationTypeCode,

location StopId,

price Price OPTIONAL

}

Exception ::= SEQUENCE {

exceptionCode I1,

errorText OCTET STRING

}

StopId ::= ReferenceNumberFour

END




69




70

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 theTravelContract, or bilaterally. The actual physical exchange of data is not within the scope of thisspecification.

6.1 OVERALL INTERFACE REQUIREMENTS

Overall interface requirements are listed in the table below:

Requirement

No

Requirement

[R 113] The Clearing Interface shall be based on the following standards:

o ISO 14904

o EN1545

o CEN TC278/WG3/SG5

[R 114] 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 arefurther detailed in chapter 1. Figure 9 describes the interfaces between the entities. The interfaces arenumbered, and a description of the interfaces is given in Table 6-1.




72

Interface no Description Comments

and contractual information to the ProductTC Owner. This includes:

• Security system keygeneration/version (mandatory)

• TravelContract status, asdescribed above (mandatory)

• TravelContract pre-paymentminimum balance

• TravelContract post-paymentcharge threshold

• Customer/ticket medium holder info; name, address, etc.

• Contract status; pre- or post-paid

• Customer account number

3a The ProductLP Retailer processes theCustomer’s ticket media in order to sell aproduct (ticket) to the customer using theTravelContract as payment mean.

3b The ProductLP Retailer collectsTravelContract usage data (sale of product)

4a The Service Operator validates the ticket soldto the Customer by the ProductLP Retailer

4b The Service Operator collects product usagedata concerning tickets.

5a The ProductLP Retailer forwardsTravelContract usage data to the ProductTC Owner

The TravelContract usage data is aclaim towards the ProductTC Owner in order to receive payment for thesold product (ticket).

5b The ProductTC Owner distributes security liststo the ProductLP Retailer to prevent use of blocked TravelContract occurrences.

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 & forwardingservice is established, data exchange is routed via this service. This situation is illustrated in Figure10.

Product Owner (TravelContract)

Product

Retailer (local product)

National

Collection &

Forwarding

Service

Figure 10: National Collection & Forwarding Service




73

Responsibilities of a National Collection & Forwarding Service:

• Collect TravelContract usage from ProductLP Retailer accepting the TravelContract aspayment 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 aspayment 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

No

Requirement

[R 115] All ProductTC Owners and ProductLP Retailers have to comply with the NORTICClearing Interface specification.

6.3.1 Header The actual data exchange method is not within the scope of this specification. The following dataexchange 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/messageheader marks the start of a file or message.

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

File/Message header

Data section (e.g. TravelContract usage data)




74

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 messagessequentially.

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 iscomposed 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




75

Event data Data elements in event data:

• Service type

• User action

• Price

TravelContract 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

}




76

TravelContractData ::= SEQUENCE {

..applicationId ApplicationId

productID ProductID,

expirationDate DateCompact,

accountNumber Iai OPTIONAL,

transactionLimit Price

}

ProductId ::= SEQUENCE {

productTemplateId ProductTemplateId,

productRetailer ProductRetailer,


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 theTravelContract as payment mean. The security list contains a list of blocked TravelContractoccurrences and is distributed to ProductLP Retailer to prevent use of any blocked TravelContractoccurrence. Any ProductLP Retailer receiving a security list shall acknowledge the reception.




77

Security list data elements:

Data field Description

TravelContract identification Unique card identification. The TravelContract is installed in acard 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 cardphysically

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 theTTP to the Product Owners and from the Product Owners to the Product Retailers. Before anydistribution can occur, the Product Owner must authenticate the Retailer and his TravelContractSAM(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.




78

Retailer Id Identity of ProductLP Retailer that requests a MkeyN-MAC filefrom 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 thepublic key certificate, preferred symmetric key encryptionalgorithm)

TravelContract SAM Public key TravelContract SAM Public key data

TravelContract SAM identification Unique TravelContract SAM identification. EachTravelContract SAM shall be unique identified byTravelContract 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 keycertificate

TravelContract SAM Public key

certificate

Public key certificate of the TravelContract SAM (structure that

include digital signature of the TravelContract SAM, validityperiod of the public key certificate, preferred symmetric keyencryption algorithm, for use as TravelContract SAM keyencryption key )

6.4.2 TravelContract Key File specification

The ProductLP Owner is responsible for distributing authentication key files to all ProductLP Retailersaccepting the TravelContract product as payment mean. The authentication master key files containencrypted authentication master keys. These files are unique for each SAM as different Retailers mayuse over time and various types of SAM. The Master keys are encrypted using an appropriate crypto-algorithm (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 SAMKey file)

Event Timestamp Time of event (time of distribution of the TravelContract SAMKey file)

Retailer Retailer that is receiving the key file for later distribution to theconcerned TravelContract SAM

TravelContract SAM identification Unique TravelContract SAM identification. EachTravelContract SAM shall be unique identified byTravelContract 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 theauthentication master keys

Encrypted set of TravelContract Set of Key Generation and Master Key




80

7 TEST GUIDELINES

7.1 INTRODUCTION

The NORTIC specification defines all the necessary requirements in order to purchase and implementequipment and functionality of the interoperable TravelContract. In order to ensure that theimplementation 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 toobtain 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 NORTICspecifications are handled in this document. Other tests which will be necessary to verify systemfunctionality 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 notcontain 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 RoadsAdministration who shall be responsible for providing necessary tools for performing the tests. Theseare test specifications, test reference equipment, laboratories.

Product Owner – Being responsible for the TravelContract, the ProductTC Owner is also responsiblefor that the system and equipment purchased and installed is compliant to the NORTIC specificationsand achieves the final approval for use.

Retailers – The same requirement applies for the Retailers as those for the Product Owners inrelation 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;




81

• Reference Pre-tests

• Functionality Tests

• Quality Tests

Reference Pre-tests

The reference pre-tests are tests of equipment and their interfaces that verify requirements referencedby standards in this specification. Examples are compliance to interface standards such as ISO7816-3and ISO14443, EMC/EMI standards and security standards such as FIPS140-2. Independent testhouses (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 theNORTIC equipment, claiming conformance to this Specification.

Quality Tests

Quality Tests are related to test procedures that verify certain performance aspects of theTravelContract 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. Themanufacturer of the test object shall -prior to testing- document whether the test object hasbeen 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, field-testing applying the test object in a test environment.

• Verdict criteria; criteria to judge the test object compliant (‘Pass’) or non-compliant (‘Fail’) torequirements. Unless, otherwise stated, the Product Owner is responsible for conducting anddocumenting the verdict according to the stated criteria, and he shall document that he hasaccepted the test object for use in his ticketing system. He is liable for using a test objectproving a later non-compliance of the test object after a Pass verdict

2It 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 behigh, such that a range of tests within this test specification are limited require reports of already completed testsor the manufacturer’s self-declaration of the test object.




82

7.4 REFERENCE PRE-TESTS

This section is dedicated to specific reference pre-test are required to fulfil the TravelContractrequirements. Priority has been given those requirements, which are essential to interoperability withinthe NORTIC system.

Test id Parameters Description

Test Object IC Card and related documentation intended for use as NORTIC paymentmedium.

Part 1 K7 The NORTIC payment medium shall be an IC Cardpreferably 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 beaccording to ISO 7816-2.

Part 1 K10 The electronic signals and transmission protocols shall beaccording to ISO 7816-3 and ISO 14443-2 and –4 (type Aand/or B), and initialisation and anti-collision according toISO 14443-3.

Part 1 K11 File structure shall be according to ISO 7816-4. Commandsshall preferably be according to ISO 7816-4.

Part 1 K12 The ticket medium shall support contactless communicationaccording to ISO 14443 Type Aor

contactless communication according to ISO 14443 Type B.

Preferably the IC card shall support contact communicationaccording 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 minimumof 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, writingand file creation/deletion.

Requirements

Part 1 K17 The security features of the card must support the MACgeneration according to Part 1 Chapter 2.

Prerequisite Available documentation from manufacturer / test reports of Test Object inEvaluation intended to meet the Requirements. The manufacturer shallpro-actively specify any deviation from the requirements to obtain validwaivers from the TravelContract Product Owner.

T-1.

VerificationMethod

Inspection of documentation / test reports. The ProductTC Owner shalldocument that he has inspected available documentation / test reports.




83


Verdict criteria Pass: Inspection of the documentation is identifying the Test Object beingcompliant with the requirement.

Fail: Inspection of the documentation is not identifying the Test Objectbeing compliant with the requirement (or is inconclusive). The IC Card isnot approved to be used in the NORTIC Ticketing system.

Test Object MAD intended for use in the Nortic System and equipped withTravelContract application and the related documentation.

Part 1 K18 The MAD shall support contactless communicationaccording to ISO 14443 Type Aand contactless communication according to ISO 14443 Type B.

Preferably the MAD shall support contact communicationaccording to ISO 7816 -3.

Part 1 K20 The MAD shall accept smart cards with physicalcharacteristics according to ISO 7816- parts 1 & 2 and ISO14443-1.

Part 1 K21 The contact interface (if present) shall use electronicsignals and transmission protocols according to ISO 7816-3

Part 1 K23 The contact less interface shall use electronic signals andtransmission protocols according to ISO 14443 parts 2 and4 of Type-A and/or Type-B), and initialisation and anti-collision according to ISO 14443-3.

Part 1 K24 The MAD and its application shall be able to sendcommands according to ISO 7816-4 over all its interfaces.

Requirements

Part 3 The MAD may contain a TravelContract SAM (optional)

Prerequisite Available documentation / test reports from manufacturer of the TestObject intended to meet the Requirements. The manufacturer shallspecify which of the optional requirements that are fulfilled.

VerificationMethod

Inspection of documentation. The Product Owner (Retailer) shalldocument that he has inspected available documentation / test reports.

T-2.

Verdict criteria Pass: Inspection of the documentation concludes that Test Object iscompliant with the requirements.

Fail: Inspection of the documentation is not identifying that the Test Objectbeing compliant with the requirements (or inspection is inconclusive). TheMAD is not approved used in the NORTIC Ticketing system.

Test Object TravelContract SAM (optional within the NORTIC Ticketing System)

Part 1 K24 Supporting the DES and 3DES algorithms in ECB and CBCmode with full 64bit input and output.

Part 1 K25 Provide secure storage of keys of relevant types, allowingthose keys to be loaded and updated in a secure way.

T-3.

Requirements

Part 1 K26 The SAM shall support both the MAC generation as definedin Part 3 Chapter 2.




84


Part 1 K27 The security level of the SAM shall be implemented andcertified according to Level 2 of FIPS PUB 140-2.

Prerequisites The Test Object shall be accompanied with documentation proving that ithas been tested/verified according to requirement Part 1 K27.Furthermore documentation shall indicate how the SAM may be used in aMAD.

Sample IC Cards and MADs with a TravelContract application shall beavailable for functionality tests and the test object shall be installed intothe MAD according to documentation.

VerificationMethod

Inspection of documentation of the Test Object. The Product Owner isresponsible for declaring that the Test Object fulfils the requirements.

Verdict criteria Pass: The documentation of the Test Object is found to be compliant withthe requirement

Fail: The documentation of the Test Object is not found (or isinconclusively) to be compliant to the requirements

7.5 FUNCTIONALITY TESTS

Functionality tests aim at verifying the TravelContract functionality, essential for interoperability in thesense that it shall be checked that mandatory data are transmitted over relevant interfaces between ICCard, MAD and Clearing modules at the Product Owner, in accordance with the NORTIC specification.

Test Object IC Card - MAD Interface

Part 2 R16 The ProductTC Owner is responsible managing thecustomer data and the status of the TravelContractoccurrences. 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 inaccordance with ISO7816-5.

T-4.

Requirement

Part 2 R23 The NORTIC ticket medium shall generate a MAC

(Message Authentication Code), which enables theProductTC Owner to verify the authenticity and integrity of the claim (transaction).




85

Prerequisite Approved IC Card, according to test T-1 and approved MAD, accordingtest 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 MACaccording to T-3.

• Which optional data from the IC Card that are read

The manufacturer of the MAD shall propose and seek approval from theTravelContract owner for a test log interface, enabling inspection of thetest results.

VerificationMethod

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 shallbe subject to test.

2) The MAD shall read data from the IC Card and generate aTravelContract 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 ICCard.

Fail:

The event of any of the requirements above that is not fulfilled.

Test Object Interface between ProductLP Retailer (MAD) – ProductTC Owner modules

Part 2 R22 The ProductLP Retailer is responsible for collectingTravelContract usage data. Product usage data is thetransaction information generated when the product isused, and includes payment information. The transactiondata is forwarded to the ProductTC Owner in order to receivepayment for the actual customer travel.

Part 2 R28 The ProductTC Owner manages and distributes security lists

to the ProductLP Retailer accepting the TravelContract aspayment mean.

Part 2 R29 The ProductLP Retailer shall acknowledge the reception of security lists from the ProductTC Owner and shall distributethe security list to all user equipment/MAD.

T-5.

Requirement

Part 2 R31 The ProductLP Owner and ProductLP Retailer MAD SAMshall exchange authenticated public keys.




86

Prerequisite All pre-requisites of T-4 also apply for this test. In addition: Approved MADaccording to T-4 with a valid security list but without any generatedtransactions/events. Two IC Card qualified according to T-4. (One IC Cardon the security list and one, which is not).

VerificationMethod

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 thesecurity list and refuse the IC Card on the security list. In both casesthe MAD shall generate a transaction record (payment, event report)

2) Download into the MAD a new security list containing both ICCards

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 theIC Cards

6) Report step 1)

The MAD shall make transactions with both IC Cards and generate atransaction record.

7) The MAD shall have made three transaction records and threeevent reports (refusal of the IC Cards). A transaction file shall besent to the ProductTC Owner.


Step 1) through 7) are performed without error and in accordance withformat of Chapter 3. Security list correctly received by the MAD.

Fail

Any of the conditions in step 1) through 7) not fulfilled.

Test Object Interface MAD - Product Owner Module (SAM). This test shall be carriedout when MAD is equipped with a SAM.

Part 2 R30 The ProductTC Owner is responsible for selecting theappropriate authentication mechanism of theTravelContract (symmetrical versus asymmetrical) andprovides a secure download of authentication keys to the ICcard.

Part 2 R31 The ProductTC Owner and Retailer MAD SAM shallexchange authenticated public keys.

T-6.

Requirement

Part 2 R32 The ProductTC Owner shall distribute the TravelContractauthentication master keys according to ISO11770 Part 3 –Key Transport Mechanism 3 or higher.




87

Prerequisite All pre-requisites of T-4 also apply for this test. The MAD SAM contains avalid set of authentication master keys. There shall be one IC Card withvalid keys and one IC Card without. None of the IC Cards are on thesecurity list.

VerificationMethod

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 thesignatures. One IC Card shall be refused whereas one shall beaccepted. The transaction file shall log both event (payment andevent)

2) ProductTC Owner shall download a new set of TravelContractauthentication master keys to the MAD SAM. The valid IC Cardbecomes invalid whereas the invalid IC Card becomes valid.

3) Repeat step 1

One IC Card shall be refused whereas one shall be accepted. Thetransaction 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) andtransmitted them to the Product Owner.


All steps 1) through 3) are completed successfully and in accordance withrequirements.

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 notnecessarily hamper interoperability.

Test Object IC Card – MAD transaction timeT-7.

Requirements Product Owner shall state which transaction time thatapplies for his system




88

Prerequisite MAD completed tests T-1 through T-5. The manufacturer/product owner shall declare whether T-6 is done. One IC Card with TravelContractapplication shall be available.

The manufacturer shall provide necessary equipment necessary tomeasure the transaction time between the IC Card and MAD and seekapproval for the test set up by the Product Owner.

VerificationMethod

Functionality test:

1) Move the IC Card into/in front of the MAD, which generates atransaction.

2) The transaction time shall be measured.

Verdict criteria Pass: Transaction time less than equal to requirement.

Fail: Transaction time more than requirement

Test Object MAD Transaction Storage Capacity

Requirement The Product Owner shall declare the transaction storagecapacity 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 TravelContractapplication shall be available.

Verification

Method

Functionality Test:

1) Move the IC Card into/in front of the MAD, which generates atransaction.

2) Repeat step 1) until requirement is reached.

The MAD shall be able to store the number of transactions and forwardthese to the Retailer office/Product Owner

T-8.

Verdict criteria Pass: Transaction capacity more than or equal to requirement.

Fail: Transaction capacity less than requirement

T-9. Test Object MAD security list storage capacity

Requirement The Product Owner shall declare the security list storagecapacity that the MAD shall have. (Maximum number of security list entries before its memory is full)

Prerequisite MAD completed tests T-1 through T-5 and T-8. The manufacturer/productowner shall declare whether T-6 is done. One IC Card with TravelContractapplication shall be available.




89

VerificationMethod

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 capacityis reached.

The MAD shall be able to store the number of transaction and forwardthese 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

Test Object MAD autonomous time of storage/operation

Requirements 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 externalpower supply.

Prerequisite All tests T-1 through T-9. The manufacturer/product owner shall declarewhether the MAD has got a SAM and whether T-6 is done. Themanufacturer shall declare whether the MAD is capable of performingtransactions when its external power shut off.

VerificationMethod

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

T-10.

Verdict criteria Pass: Autonomous storage/operations time more than or equal torequirements

Fail: Autonomous storage/operations time

Test Object MAD duration time

Requirements The Product Owner shall declare the maximum durationtime of the MAD (MTTF)

T-11.

Prerequisite MAD completed test T-1 to T-10. ICC complying with requirements.




90

VerificationMethod

Functionality test:

Acceleration test on the MAD should be performed aiming at verifyingits critical functions, such as IC Card interface at climatic conditions

existing within ticketing environments. This includes high relativehumidity (70-95%), temperature ranges (-40 + 85 deg Celsius),temperature variations 40 deg Kelvin/5 minutes and vibrations. Withreference to ISO10373 part 3 and part 5, the IC Card manufacturer shall declare the set of tests, to which the MAD has been exposed.

Verdict criteria Pass: Flawless operation during acceleration tests with a duration timeaccording to requirements

Fail: non-compliance or inconclusiveness




91

8 NORTIC SPECIFICATION FOR MIFARE DESFIRE

(NSD)

The NORTIC specification for mifare DESFire (NSD) is based on [19] which covers the smartcardlayout and structure for the Oslo projects and is part of the system specification produced for theparticipants in the Oslo projects (Oslo Sporveier, Stor-Oslo Lokaltrafikk and NSB). Further informationis 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 theycan 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 interoperableproducts, and as a basis for developing new products. The full specification – covering the wholerange 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 asfollows :

• 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) donot,

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. duringinitialisation, personalisation and in the field.

Thus the directories are similar to DF (Dedicated Files) and files to EF (Elementary Files) as referredto 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 backupfeature. If backup files are considered as consistent (i.e. transaction is consistent), an externalcommand (commit transaction) will validate these file modification in the corresponding normal files inone 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,




92

• 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 onthe 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 onthe 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 applicationsof the same size as the CRSI.




93

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 appropriateDESFire command.

Adding a MAC or encrypting each transmission can be time consuming, both for the card and for theCAD. 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 9gives for each file the communication settings used during communication with each file.

8.3.2 File access conditionsAccess to data files is granted on application level using a mutual authentication mechanism, whichinvolves a secret key. Prior to data transmission, a mutual three pass authentication is performedbetween 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 thecard.

8.3.3 Access rights

There are 4 different Access rights stored for each file within each application. As seen below, accessconditions 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) Meaning

0..0xD Key number which must be used to perform the related operation

0xE Always : free access (preceding authentication is not required)

0xF Never : access always denied




94

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 recordedand registered, and uploaded to the Card Issuer and/or Application Owner. In order to check that notransaction is lost, all these states are uniquely numbered, using a Sequence Number, large enoughto cover the medium lifetime.

The Sequence number is an incremental number starting from 1 (when the medium is delivered, zerois reserved for new media), up to an unreachable* value below 2

18-1= 262143. Each time a fare

medium is written to its transport application (i.e. its state changes), this sequence number shall beincremented by one, so that the sequence number is representative of each state during the cardlifetime.

(*) Note : the average guaranteed smart medium lifetime is 100,000 write operations per memory celland 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 willbe removed later on. This mechanism allows the customer to revert his card quickly (at thePOST/TVM for instance) in order to reuse it on any CAD. Without this feature, the card would havebeen 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.




95

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 + 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13+14

+15

0 1 2 3 4 5 6 7 8 9 A B C D E F

+ 0 00.. — 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Ø13NØ14NØ15NØ16NØ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 A B C D E F

Table 2 Example on Zone codification

For example, zone Ø16 is encoded 5D (hexadecimal) or 93 (decimal).




96

This nomenclature is extensible to 0..1023.

range Id.

01..07 D domains D01=NSB; D02=OS; D04=SL; D06=OS+SL.

10..13 C sector Oslo City provision to 4 zones

20..2D N sector North

30..38 NØ sector North-East

40..45 ØN sector East-North

50..5D Ø sector East

60..67 ØS sector East-South

70..73 SØ sector South-East

80..86 S sector South

90..92 SV sector South-West

—– VS sector West-South

B0..BA V sector West

C0..C1 VN sector West-North

D0..D2 NV sector North-West

E0..3FF 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 encodedso. Ticket with a destination encoded as C01 will allow transfers inside C01 only, using the same ruleas 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 3072 R.F.U.

1000..13FF 1024 NSB location identifiers (T.B.D.)

1400..17FF 1024 OS location identifiers (T.B.D.)

1800..1FFF 2048 SL location identifiers (T.B.D.)

2000..FFFF 57344 R.F.U.

Table 4 Location codification

Other Data

Service operator reference :

• OS = 2,

• SL = 3,

• NSB = 4.




97

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 serialnumber)Read EnvironmentRead 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 ContractListLOOP 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 timeWRITE Contract.n (Validity start date, Status)UPDATE ContractList

(possible transaction split)CASE Travel Rights must be debited

Read Counter.nDECREASE Counter.n by one travel and as many period asneeded

CASE 'Stored Value' must be debitedRead StoredValueCounter (process auto-reload if needed)DECREASE StoredValueCounter by journey price

CASE Contract list must be updatedUPDATE 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 priceINCREASE SequenceNumber (by one)APPEND new EventLog

ELSE (if no contract applies)→ (validition fails)

END (if no contract applies)




99

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 processthe card rapidly during validation, the choice of the product to use must be easy and must not needany 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 thegeographical 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 willtake 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 soldand used.

Explicit selection :

Selection for immediate use is proceeded by a vending or dedicated machine, which writes down tothe card a Travel Right pointing to the specified product. Explicit selection is when the product is soldand marked for immediate usage; this product by-passes the usual priority rules and is used in anycases.

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 betweenthem are not managed by validators (transaction time optimisation) and have to be avoided whenproducts are sold.

To make conflict management understandable by customers, following rules must apply :




100

• 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 withprecedent 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 validitymore than 1 year).

• Product has never been used, product end of validity has been reached and product is notrefundable.

• Product has never been used, maximum date for validation has been reached (end of versionvalidity 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 removethe product.

This test will be made :




101

• At each sale operation for all the products.

• At each use of this product.




102

9 NORTIC SPECIFICATION FOR DESFIRE FILE

STRUCTURE This chapter describes the file structure and content for the directories and files to be implemented onthe 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 andinter-regional interoperable fare management)

• NorticDF (directory used for storage of data elements for the national interoperableproduct 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 recordcontent column relates, either to key content or data element structures.

Note that the Master file stands for the PICC itself.

Application#

Directory/File name Type Record* : contentsDescribed in

MF (Master File) DF 9.1

0x000000 PICC Master Key key Keys (M)

CardIssuerDF DF 9.2

CI_Keys key Keys (4 keys)

0 x 5 7 8 0 0 0

( h e x a d e c i

m a l )

CI_Header standard CardHeader 9.2.1

TransportDF DF 9.3

T_Keys key Keys (7 keys)

T_Environment standard Environment0

T_CardHolder standard Holder 9.3.2

T_ProductRetailer backup Contract [1..8] 9.3.3

Counter [1..8] 9.3.4.1

ContextsAndSequenceNumbers 9.3.4.3T_ServiceProvider backup

ContractList 9.3.4.5

SpecialEventLog [1..8] 9.3.5.1.1T_SpecialEvent backup

SpecialEventList 9.3.5.1.2

T_StoredValue value StoredValue 9.3.6

0 x 5 7 8 0 0 1 ( h e x a d e c i m a l )

T_GeneralEventLog cyclic GeneralEventLog [1..8] 9.3.7




103

Application#

Directory/File name Type Record* : contentsDescribed in

T_SVReloadLog cyclic StoredValueReloadLog [1..2] 9.3.8

NorticDF DF 9.2

Nortic_Keys key Keys (x keys)

t.b.d

t.b.d

t . b . d

( h e x a d e c i m a l )

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 fieldmeans "mandatory" and the numbers identifies the optional number according to the presencebitmap indicator.

• ASN.1 representation which uses the PER encoding / bit aligned. When conflicting, ASN.1prevails.

• 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 fieldsthat are specific for the NDS – either in that it does not exist in ENV-1545 or because it is useddifferently – 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 maincharacteristics are :




104

• 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)


This application is created using the "CreateApplication" command whose parameters are set asfollows :

• AID : 0x578000 CardIssuer application :given here as hexadecimal value (ie 0x57 is the MSBand 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. theCI_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 aunique 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 asize 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 fi le (using the Card Issuer key which iskey#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. Itis 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 IOticketing 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 IOcards at first will have only a 32 bits serial number.




105

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 typeSize(bits)

initial value, comment

IOCardHeader-A SEQUENCE OF

preamble SEQUENCE OF 0

• country 0..999 10 578

• format 0..1048575 20 0 : this format version

data SEQUENCE OF 0

• cardIdNumber SEQUENCE OF 0

choice bitmap 0..2 2 2 (= cardIdNumber32bits)

0 cardIdNumberISO14443 0 unused

1 cardIdNumberISO7812 0 unused

2 cardIdNumber32bits0..4294967295 32

Application wide unique serialnumber, set up atprepersonalization

• cardValidityEndDate

DateCompact 14

The day the card is no morevalid.

Date is set up aprepersonalization and iscomputed in number of dayscounted from the starting date(January 1

st, 1997):may be for

instance manufacture date + nyears.

• owner 0..1048575 20 Application owner Company

• retailer 0..1048575 20 Retailer organisation

• cardKeyVersion0..15 4

Used to identify which keys arein use. Initial = 1. This number ismanaged cyclically.

122 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 isup to the IO system to ensure it's uniqueness within the transport application. Do not confuse thecardIdNumber with the card serial number (7 byte long) which is set during the chip manufacturingprocess and therefore not used in this Application Note.




106

ASN.1 description is as follows :

IODESfireIdentifier ::= INTEGER(0..1048575)

-- GENERIC HEADER TYPESIODESfireCardHeaderGeneric ::= 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


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), Applicationretailer 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 :




107

• 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 filenot 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 TransportRead 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 AID0x578001 key set).

• Change Config : controlled by the Application Owner key (key#1 in AID 0x578000 applicationkey 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 -- defined in 0

9.3.1.1 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 registeredas 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 : blockinghas to be done by any CAD that detects a fault, while unblocking shall not be done beforediagnostic and verification is performed. Cf. 8.4.2.




108

The Environment structure is compatible with the Environment structure defined in the ENV1545-1: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 inthe 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 data type size (bits) Initial value and comments

IOEnvironment SEQUENCE 0

presence bitmap bit string 7 0000111

• envVersionNumber 0..63 6 0 (refers to the current application version)

0 envNetworkId NetworkId 24 0x578000

1 envApplicationIssuerId Company 16Company code as defined in Table 8Company Identifiers

2 envApplicationEndDate DateCompact 14Last day of validity for the transportapplication

3 envPayMethod PayMethod 0 unused

4 envAuthenticator OCTETSTRING

0 unused

5 envSelectList SEQUENCE 0 unused

6 envDataOCTETSTRING

0 unused

67 TOTALTable 9 IOEnvironment data fields

There is no data element that marks the application as invalidated (e.g. because blacklisted). Thisinformation cannot be managed by the ticketing application for security reasons : blocking must bepossible by any CAD that detects a fault, while unblocking shall not be done before diagnostic andverification is performed. Cf. 8.4.2.

The Environment structure is compatible with the Environment structure defined in the ENV1545standard, 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 { -- 7 bits in the bit-field always0000111 (binary)

EnvVersionNumber VersionNumber, -- 6 bits 000000 (binary) = thisversion

envNetworkId [0]NetworkId OPTIONAL3, -- 24 bits always 0x578000envApplicationIssuerId [1]Company OPTIONAL3, -- 16 bits presentenvApplicationEndDate [2]DateCompact OPTIONAL3, -- 14 bits presentenvPayMethod [3]PayMethod OPTIONAL4, -- unused

3 OPTIONAL in ENV1545 but present and mandatory for NSD cards.

4 OPTIONAL in ENV1545 but absent from the NSD card layout.




109

envAuthenticator [4]Authenticator OPTIONAL4, -- unusedenvSelectList [5]SEQUENCE SIZE(1..10) OF Pointer OPTIONAL4, -- unusedenvData [6]OCTET STRING(SIZE(0..255)) OPTIONAL4 -- unused

} -- TOTAL : 67 bits used.

Company ApplicationIssuerId are listed below:

NOTE: The table below includes only the IO in Oslo and the three main operators in Oslolinked 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 therequirements in 2.7 Identification.

Company Code for envApplicationIssuerId

IO 1

OS 2

SL 3NSB 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-upwhich is configured at creation to contain a maximum of 32 bytes (256 bits).


• Read : this right allowss only the ReadRecords command after having presented the TransportRead 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 normallynever be used.


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 data typesize(bits)

Initial value and comments

IOHolder.base SEQUENCE

presence bitmap bit string 8

0 holderName SEQUENCE 0 unused

1 HolderBirth SEQUENCE 0 Only the Date Of Birth is used




111

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 limitingones.

The Holder information are put on the card when issued. But the customer may decide to change itsStore 'Value parameters' (Ground, Amount, for instance through some sales devices). In this case thevalues in the SpecialEvents take precedence on the data in the Holder structure, butSpecialEvent[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 byits expiration date in holderProfileDate, according to standard. Two profiles are allocated to IO non-standard purposes.

IO Profile Type Number ENV1545 : 1998 profile

Non personalized none

Personalised without data 0 unspecified

Adult Implicit 1 adult

Child (<16 years) Implicit 2 child

University student 3 student

Senior (> 67 years) Implicit 4 oldAgePensioner

Disabled (blind, wheel chair user) 5 DisabledNot Further Specified

Employees (all providers). for envApplicationIssuerId 9 staff

Military 10 military

Young (< 20 years) Implicit 32

Deaf-Blind 33

Dog 34

Primary school student 35

College student 36

Police. 37

Guide Dog Trainers. 41

Congress participant 43

Company worker 44

Intervention card (all providers) 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!!!!




112

• 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 Elektroniskbillettering, Del 1, Chapter 3.5 Price Calculation. Hence, there is a need for redefiningTable 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, -- 16 bitsstoredValueAutoReloadAmount Amount, -- 16 bitsstoredValueAutoReloadEndDate DateCompact -- 14 bits

} -- TOTAL 46 bits

IOHolderPlus ::= SEQUENCE { -- 3 bits bit-field

storedValueAutoReloadData IOStoredValueAutoReloadData OPTIONAL, -- 46 bitsholderPlusRFU-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 (likeprofile, agentId, ....). This element (up to 18 byte long) is deliberately unformatted to let eachTransport 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 (seeSpecial 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 IOspecific, its ASN.1 definition is :

It is inserted into IOHolder.storedValueAutoReloadData and into SpecialEvent[1].eventData (runningvalues).

Therefore, the ASN.1 definition related to the Holder structure used for the IO CSC cards is defined asfollows:




113

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).

AnonymousHolder

ProfiledHolder

PersonalHolder

EmployeeHolder

AgentHolder

Options used

(refer toTable 8)

4 4, 6 1, 4, 6 4, 6 4, 6, 7

These structures are defined below :

IOAnonymousHolder ::= IOHolder (WITH COMPONENTS {base (WITH COMPONENTS -- 8 bits (Holder bit-field)

holderCountryAlpha PRESENT -- 21 bits-- all other fields not present

})}) -- TOTAL : 29 bits max used.

IOPersonalisedHolder ::= IOHolder (WITH COMPONENTS {base (WITH COMPONENTS { -- 8 bits (Holder

bit-field) holderBirth PRESENT, -- 40 bitsholderCountryAlpha PRESENT, -- 21 bitsholderProfiles (SIZE(0..2) WITH COMPONENTS { -- 4 bits (0..2

Holder Profile)-- 3 bits

bitmapholderNetworkId OPTIONAL, –- 24 bitsholderProfileNumber (ALL EXCEPT 63) PRESENT, -- 6 bitsholderProfileDate 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 { -- 8 bits (Holder

bit-field)holderBirth PRESENT, -- 40 bits when

presentholderCountryAlpha PRESENT, -- 21 bitsholderProfiles (SIZE(1..2)) PRESENT -- 4 + (1..2)x47 bits

with-- a mandatory

profile #9 (staff)})

}) -- TOTAL : 167 bits max used.

IOAgentHolder ::= IOHolder (WITH COMPONENTS {base (WITH COMPONENTS { -- 8 bits bitfield

holderCountryAlpha PRESENT, -- 21 bits : IOmandatory




114

holderProfiles (SIZE(1) WITH COMPONENTS { -- 4 bits (=1)-- 3 bits

bitmapholderNetworkId OPTIONAL, –- 24 bitsholderProfileNumber (63) PRESENT, -- 6 bitsholderProfileDate OPTIONAL5, -- 14 bits

}) PRESENT, -- 47 bits max used}),

holderData (SIZE(0..18)) PRESENT -- 8 + 8×18 bits}) -- TOTAL : 232 bits max used.

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 allowconcession tariffs.

P-card with a DOG or Bicycle profile give automatic selection of a DOG/BICYCLE supplement for theCheck in process.

Profiles combinationA 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, guidedog 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 filewhich is configured at creation to contain a maximum of 384 bytes (but the total amount of memoryused on the card is twice this amount : 768 bytes).



• Write : never

• Read&Write : this right is controlled by the Product Retailer key (key #4 in AID 0x578001 keyset).

• Change Config : controlled by the Transport Application Owner key (key#1 in AID 0x578001application 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 therecord to read. The first record always starts at byte 0 from the beginning of the file. An empty recordslot will be totally filled with 0x00

5 May be absent, for profile that don't have end of validity for this holder.




115

The unused memory (either between contract structures or at the end of the file) is f illed with 0x00.

Basically, the ProductRetailer file contains up to 8 Contracts. The IOContractList data structurecontained 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 Product owner

contractTariff Product type

contractSerialNumber Product identifier in the card. Full product identifier is the couple cardnumber & product identifier.

Its value is the sequence number that was on card before the contract is

written to the medium.ContractPassengerTotal Maximum passenger count.

contractServices Transportation modes eg : Bus, metro, train, boat, night bus, dog, bicycle…

contractPriceAmount Price paid for the contract expressed in the system currency

contractRestrictProduct Indicates the factor to multiply with full fare to have the price for all thegroup.

it is the passenger and luggage count minus all the concessions applied.(granularity is 5%)

contractValidityStartDate Product start of validity, present if contractValidityDuration is absent.

contractValidityEndDate When absent, counterEndDate is used instead

contractValidityEndTime When absent, counterEndTime is used instead

contractValidityDuration Validity period count (according to contractTariff) up tocontractValidityEndDate + contractValidityEndTime, present if contractValidityStartDate is absent.

Used in place of contractValidityStartDate if contract structure is too bigto fit into record.

contractValidityZones 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 inorder to revert the blocked status.

ContractPlusAuto-Renew

Auto-Renewed

AutoRenewLast Date

If this structure is present, this feature has been subscribed. If AutoRenewLastDate is not yet reached, the contract may be renewed (another contract is created). Once this is done AutoRenewLastDate is set tozero to prevent any subsequent auto renew. Auto-Renewed set to truemeans the contract comes from an autorenew feature otherwise it hasbeen bought at a POST or TVM.

Contract Plus Passengers Number of passengers per category for group purposes (5 categoriesmax)(Exact usage must be specified)




116

Table 14 Contract data fields

presence bit #data element

identifier data type

size(bits)

initial values and comments

IOContract SEQUENCE ··· ——


0 contractNetworkId NetworkId 246 BCD digits 'CCCNNN' 'CCC' is 578for Norway according to ISO3166-1and NNN is the network number——

1 contractProvider Company 16 ——

2 contractTariff 0..65535 16 ——

3 contractSerialNumber Int4 32

uses the

applicationSequenceNumber

4 contractCustomerInfo SEQUENCE ··· ——

presence bitmap bit string unused ——

0 contractCustomerProfile CustomerProfile unused ——

1 contractCustomerNumber Int4 unused ——

5 contractPassengerInfo SEQUENCE ··· ——

presence bitmap bit string 2 ——

0 contractPassengerClass SEQUENCE ··· ——

• classQualifier unused ——

• custProfile unused ——

1 contractPassengerTotal 0..255 8 ——

6 contractVehicleClassAllowed 0..65535 unused ——

7 contractPaymentPointers SET OF ··· ——

• length 0 ..5 unused ——

• component x length SEQUENCE ···


• pointerQualifier PointerQualifier unused ——

• pointerData PointerData ··· ——

• length 1..16 unused ——

• component × length octet unused ——

0 ptag Ptag ··· ——



1 provider Company unused ——

8 contractPayMethod PayMethod unused ——

9 contractServices Services 16

identifies the transportation modesrelated to the contract or any relatedcontract service (renew) or any paymethod capability. For more details

refer to the ENV 1545-2:1998standard.




117



size(bits)


10 contractPriceAmount Amount 16 ——

11 contractPriceUnit PayUnit unused ——

12 contractRestriction SEQUENCE ··· ——


0 contractRestrictStart TimeCompact unused ——

1 contractRestrictEnd TimeCompact unused ——

2 contractRestrictDay RestrictDOW unused ——

3 contractRestrictTimeCode 0..255 unused ——

4 contractRestrictCode 0..255 unused ——

5 contractRestrictProduct 0..65535 16 ——

6 contractRestrictLocation SEQUENCE ··· ——

• qualifier 0..255 unused ——

• locationData OCTET STRING ··· ——



13 ContractValidityInfo ——


0 contractValidityStartDate DateCompact 14Starting validity date (counted in

days)

1 contractValidityStartTime TimeCompact unusedStarting validity time (minutes

counted from midnight)

2 contractValidityEndDate DateCompact 14 ——

3 contractValidityEndTime TimeCompact 11 ——

4 contractValidityDuration 0..255 8 ——

5 contractValidityLimitDate DateCompact Unused Unused

6 contractValidityZones SET OF ——

• length 0..10 4 length=3

• component × length IOZone 10 Total = 30 bits for 3 zones

7 contractValidityJourneys 0..65535 unused ——

8 contractPeriodJourneys 0..65535 unused ——

14 contractJourneyData SEQUENCE ——


0 contractJourneyOrigin 0..65535 16 ——

1 contractJourneyDestination 0..65535 16 ——

2 contractJourneyRouteNumbers SET OF ··· ——


• component × length 0..65535 unused ——

3 contractJourneyRouteVariants SET OF ··· ——



4 contractJourneyRun 0..65535 unused ——

5 contractJourneyVia 0..65535 16 ——




118



size(bits)


6 contractJourneyDistance 0..65535 16 ——

7 contractJourneyInterchanges 0..255 unused ——

15 contractSaleData SEQUENCE ——


0 contractSaleDate DateCompact unused ——

1 contractSaleTime TimeCompact unused ——

2 contractSaleAgent Company unused ——

3 contractSaleDevice DeviceId unused ——

16 contractStatusENUMERATED{1,33,63,88}

2 see ASN.1 description below

17 contractLoyaltyPoints 0..2047 unused ——

18 contractAuthenticator OCTET STRING ——



19 contractData OCTET STRING ——

• length 0..127 Unused ——

• component × length 0..255 (length=4) unused ——

IOContractPlus


• ContractUnblockingNumber 0 ..15 4initial = 0. at most, 15 unblocking

facilities for each contract.

0 ContractPlusAutoRenew SEQUENCE

• autorenewed BOOLEAN 1

set to True if the contract is renewed

automatically i.e. not bought at Postor TVM.

• autorenewLastDate DateCompact 14last day the contract may be

renewed. When auto renew processis completed, this date is set to 0.

1 ContractPlusPassengers SEQUENCE

• length=5 5 5 categories

• component x length 0..63 30

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.




119

Note : Contract structure can be written by sale machines only, while counters can be updated by bothsale machines, gates and validators. Note : Contract and Counter files must have the same recordcount.

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 bitscontractNetworkId [0]NetworkId OPTIONAL, -- 24 bitscontractProvider [1]Company OPTIONAL, -- 16 bitscontractTariff [2]INTEGER(0..65535) OPTIONAL, -- 16 bitscontractSerialNumber [3]Int4 OPTIONAL, -- 32 bitscontractCustomerInfo [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 bitscontractVehicleClassAllowed [6] INTEGER(0..65535) OPTIONAL, -- unusedcontractPaymentPointers [7]SET SIZE(0..15) OF Pointer OPTIONAL, -- unusedcontractPayMethod [8]PayMethod OPTIONAL, -- unusedcontractServices [9]Services OPTIONAL, -- 16 bitscontractPriceAmount [10]Amount OPTIONAL, -- 16 bitscontractPriceUnit [11]PayUnit OPTIONAL, -- unusedcontractRestriction [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 -- unusedcontractValidityInfo [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, -- unusedcontractJourneyData [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) -- unusedcontractSaleData [15]contractSaleData OPTIONAL, -- unused-- contractSaleDate -- unused-- contractSaleTime -- unused-- contractSaleAgent -- unused-- contractSaleDevice -- unusedcontractStatus [16]Status OPTIONAL, -- 2 bitscontractLoyaltyPoints [17]LoyaltyPoints OPTIONAL, -- unusedcontractAuthenticator [18]Authenticator OPTIONAL, -- unusedcontractData [19]OCTET STRING OPTIONAL -- unused




120

IOContractPlus ::=SEQUENCE { -- 2 bitsbitmap

contractUnblockingNumber Integer(0..15) -- 4 bits}contractPlusAutoRenew SEQUENCE{ autoRenewed BOOLEAN -- 1 bit

autorenewLastDate DateCompact -- 14 bits} OPTIONAL -- when

present auto-renew is availablecontractPlusPassengers SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL

} -- TOTAL : 384 bits max.

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 { -- ENV1545-1 : 1998enabled(1), -- IO : still unusedpending(33), -- IO : running, i.e. used at list oncesuspended(63), -- IO : (no meaning)disabled(88) -- 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 Implementation cases of contract description

9.3.3.2.1 Zone-to-zone based or area based period contractContractZonalPeriodTicket ::= [APPLICATION]Contract (WITH COMPONENTS {

contractNetworkId OPTIONAL, -- 24 bitscontractProvider PRESENT, -- 16 bitscontractTariff PRESENT, -- 16 bitscontractSerialNumber PRESENT, -- 32 bitscontractPassengerInfo (WITH COMPONENTS {

contractPassengerTotal PRESENT -- 8 bits}) OPTIONAL, -- 2 bitscontractServices, PRESENT -- 16 bitscontractValidityInfo (WITH COMPONENTS {

contractValidityStartDate OPTIONAL, -- 14 bitscontractValidityEndDate, OPTIONAL, -- 14 bitscontractValidityEndTime, OPTIONAL, -- 11 bitscontractValidityDuration OPTIONAL, -- 8 bitscontractValidityZones PRESENT -- 4 + 3×10 bits = 34 bits

max.}) -- 9 bitscontractStatus PRESENT -- 2 bits

})

IOContractPlus ::= SEQUENCE {contractUnblockingNumber Integer(0..15) -- 4 bitscontractPlusAutoRenew SEQUENCE




121

{ autoRenewed BOOLEAN -- 1 bitautorenewLastDate DateCompact -- 14

bits} OPTIONAL

contractPlusPassengers SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL

}

When it is Zone-to-zone based with a VIA zone :

ContractValidityZones SET SIZE(0..10) OF INTEGER(0..1023)-- count (0..10) 4 bits(value=3)-- startzone INTEGER(0..1023) 10 bits-- endzone INTEGER(0..1023) 10 bits-- viazone INTEGER(0..1023) 10 bits-- TOTAL : 34 bits

When it is Zone-to-zone based without a VIA zone :

ContractValidityZones SET SIZE(0..10) OF INTEGER(0.. 1023)-- 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

9.3.3.2.2 Station-to-station based period contractContractODPeriodTicket ::= [APPLICATION]Contract (WITH COMPONENTS {

contractNetworkId OPTIONAL, -- 24 bitscontractProvider PRESENT, -- 16 bitscontractTariff PRESENT, -- 16 bitscontractSerialNumber PRESENT, -- 32 bitscontractPassengerInfo (WITH COMPONENTS {

contractPassengerTotal PRESENT, -- 8 bits}) OPTIONAL, -- 2 bitscontractServices, -- 16 bitscontractValidityInfo (WITH COMPONENTS {

contractValidityStartDate OPTIONAL, -- 14 bitscontractValidityEndDate, OPTIONAL, -- 14 bitscontractValidityEndTime, OPTIONAL, -- 11 bitscontractValidityDuration OPTIONAL, -- 8 bitscontractValidityLimitDate OPTIONAL -- Unused

}) -- 9 bitscontractJourneyData (WITH COMPONENTS {

contractJourneyOrigin, -- 16 bitscontractJourneyDestination -- 16 bitscontractJourneyVia -- 16 bits

}) -- 8 bitscontractStatus, -- 2 bits

})IOContractPlus ::=SEQUENCE {

contractUnblockingNumber Integer(0..15) -- 4 bitscontractPlusAutoRenew SEQUENCE


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 contractContractODZonalPeriodTicket ::= [APPLICATION]Contract (WITH COMPONENTS {

contractNetworkId OPTIONAL, -- 24 bitscontractProvider, -- 16 bitscontractTariff, -- 16 bitscontractSerialNumber, -- 32 bitscontractPassengerInfo (WITH COMPONENTS {

contractPassengerTotal -- 8 bits




122

}) OPTIONAL, -- 2 bits (bit string)contractServices, -- 16 bitscontractValidityInfo (WITH COMPONENTS {

contractValidityStartDate OPTIONAL, -- 14 bitscontractValidityEndDate, OPTIONAL, -- 14 bitscontractValidityEndTime, OPTIONAL, -- 11 bitscontractValidityDuration OPTIONAL, -- 8 bitscontractValidityLimitDate OPTIONAL, -- UnusedcontractValidityZones -- 4 + 1×10 bits = 14 bits

}) -- 9 bits (bit string)

contractJourneyData (WITH COMPONENTS {contractJourneyOrigin, -- 16 bitscontractJourneyDestination, -- 16 bitscontractJourneyVia -- 16 bits

}) -- 8 bitscontractStatus, -- 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 bitsWhen 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 thestartzone (if Zone to zone based) or in the area (if area based) of the journey.

IOContractPlus ::=SEQUENCE {contractUnblockingNumber Integer(0..15) 4 bitscontractPlusAutoRenew SEQUENCE


bits} OPTIONAL

contractPlusPassengers SEQUENCE(SIZE(5)) OF INTEGER(0..63) OPTIONAL}

9.3.3.2.4 Zone-to-zone based or area based single journey

ContractZonalSingleJourney ::= [APPLICATION]Contract (WITH COMPONENTS {contractNetworkId OPTIONAL, -- 24 bitscontractProvider, -- 16 bitscontractTariff, -- 16 bitscontractSerialNumber, -- 32 bitscontractPassengerInfo (WITH COMPONENTS {

contractPassengerTotal -- 8 bits}) -- 2 bitscontractServices, -- 16 bitscontractPriceAmount, -- 16 bitscontractRestriction (WITH COMPONENTS {

contractRestrictProduct -- 16 bits}) -- 7 bitscontractValidityInfo (WITH COMPONENTS {

contractValidityZones OPTIONAL, -- 4 + 2×10 bits = 24 bits}) -- 9 bitscontractStatus, -- 2 bits

})

IOContractPlus ::= SEQUENCE {contractUnblockingNumber Integer(0..15) 4 bitscontractPlusAutoRenew SEQUENCE

{ autoRenewed BOOLEAN -- 1 bit




123

autorenewLastDate DateCompact -- 14bits

} OPTIONALcontractPlusPassengers 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 bitsWhen 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 journeyContractODSingleJourney ::= [APPLICATION]Contract (WITH COMPONENTS {

contractNetworkId OPTIONAL, -- 24 bitscontractProvider, -- 16 bitscontractTariff, -- 16 bitscontractSerialNumber, -- 32 bitscontractPassengerInfo (WITH COMPONENTS {

contractPassengerTotal -- 8 bits}) OPTIONAL, -- 2 bitscontractServices, -- 16 bitscontractPriceAmount OPTIONAL, -- 16 bitscontractRestriction (WITH COMPONENTS {

contractRestrictProduct -- 16 bits}) OPTIONAL, -- 7 bitscontractJourneyData (WITH COMPONENTS {

contractJourneyOrigin OPTIONAL, -- 16 bitscontractJourneyDestination -- 16 bitscontractJourneyVia -- 16 bits

}) OPTIONAL, -- 8 bitscontractStatus, -- 2 bits

})

IOContractPlus ::= SEQUENCE {contractUnblockingNumber Integer(0..15) 4 bits

contractPlusAutoRenew SEQUENCE{ autoRenewed BOOLEAN -- 1 bit

autorenewLastDate DateCompact -- 14bits

} OPTIONALcontractPlusPassengers 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 basedsingle 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 hosta maximum of 128 bytes but the actual used size on the card is twice this amount i.e. 256 bytes.


• Read : this right allows only the ReadRecords command after having presented the TransportRead Key (key #7),

• Write : devices that have the service Provider key (key #6) are allowed to write in this fi le,

• Read&Write : this right is controlled by the Product Retailer key (key #4),




124

• Change Config : controlled by the Transport Application Owner key (key#1). This access shouldnormally 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 traveland other variable information for each contract.

counterAuthenticator UnusedcounterStatus see contractStatus, used for contracts that may slip or be refunded if not

used

counterEndDate Used for contracts that may slip.

counterEndTime Used for contracts that may slip.

counterPeriods 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.

counterPeriodJourneys Number of valid journeys for the current period. Used for frequency limitedcontracts, 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.

CounterJourneyTravels Number of valid remaining travels for the current journeyother counter... items R.F.U.

Table 16 Counter data fields

The available information on counters are defined as follows IOCounter data elements :


initial values andcomments

IOCounter SEQUENCE ··· ——


0 counterAuthenticator IOAuthenticator unused ——

1 counterStatus ENUMERATED{1,33,63,88} 2 see contract status2 counterEndDate DateCompact 14 ——

3 counterEndTime TimeCompact 11 ——

4 counterPeriods 0..1023 10 ——

5 counterPeriodJourneys 0..1023 10 ——

6 counterJourneyTravels 0..63 6 ——

7 counterUsagePoints 0..8191 13 RFU

8 counterLoyaltyPoints-1 0..2047 11 RFU

9 counter LoyaltyPoints-2 0..2047 11 RFU




125



10 counterRFU-11 NULL unused ——



Table 17 Counter data fields

IOCounter ::= SEQUENCE { -- 13 bits–- linked to same index (contractListPointer) contract.

counterAuthenticator [0]IOAuthenticator OPTIONAL, -- unused 32 bitscounterStatus [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 remainingcount.

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 aproduct if there is an entry in the blacklist and if it's BSN is greater (or equal) to theContractUnblokingNumber. This state is stored within the product by setting the relevantCounterStatus 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 theServiceProvider key. (key #6). ContractUnblockingNumber is incremented using the theProductRetailer 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). Eachtime a card is written to its transport application (its state changes), this sequence number shall beincremented, so that the sequence number is representative of each state during the card lifetime. Cf 8.4.1.




126



size(bits)


IOContextsAndSequenceNumber SEQUENCE ··· ——

presence bitmap bit string 1 initial = 0

0 authenticator OCTET STRING unused ——

• length 4 unused ——


• applicationContext SEQUENCE ··· ——

• applicationStatus IOApplicationStatus 2 initial =0; refers to ASN.1 below

• applicationSequenceNumber 1..262143 18 initial =1

• applicationUnblockingNumber 1..255 8initial = 0. Allows 255 application

unblockings at most

• applicationLastServedOrder 1..262143 18 initial =0, used to manage the actionlist. Process is similar to the applicationUnblocking Number.

Table 18 ContextsAndSequenceNumber data fields

The ASN.1 definition of this structure is as follows :

IOContextsAndSequenceNumber ::= SEQUENCE{ authenticator IOAuthenticator, OPTIONAL -- unused + 1 presencebitmap,

applicationContext IOApplicationContext -- 46 bits} -- grand total = 47 bits IOApplicationContext ::= SEQUENCE{ applicationStatus IOApplicationStatus, -- 2 bits

applicationSequenceNumber IOTransactionSequenceNumber, -- 18 bitsapplicationUnblockingNumber IOUnblockingSequenceNumber, -- 8 bits

applicationLastServedOrder IOTransactionSequenceNumber, -- 18 bits} -- total = 46 bitsIOApplicationStatus ::= IOContextStatus

IOContextStatus ::= ENUMERATED{ IOContextStatusInitialized (0),

IOContextStatusEnabled (1),IOContextStatusDisabled (2),IOContextStatusBlocked (3),

}

9.3.4.4 Application Blocking/Unblocking capabilities

The Transport Application (Application number 578001) may be blocked by setting the Applicationstatus 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 mediumnumber may be removed from the blacklist.

The re-validation is performed by setting the Application status to "enabled" .




127

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 storecontract priority information. This structure is used in priority management

contractListNetworkId The contract network ID it is present only if the Contract.networkId is differentfrom 'EnvNetworkId' in the Environment file

contractListProductTemplate

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).

Products of a product set only differ by their profile concession and fare tableversion. Each Service Provider maintains a preference order of applyingcontractListProductTemplate values, which prioritises contracts together according to Service Provider’s preference.

contractListIsUsed

When a contract is validated the first time, this flag shall be set. If this feature is

not used (e.g. non refundable contract), this flag is set when sold (reducestransaction duration).

contractListPreferenceThis criterion is used to prioritise contracts together according to traveller’spreference. Default value is oioContractListPreference-Normal.

contractListPointer Contract record index (the contract record position in the Contract file,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 asfollows:

• 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 thanksto 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 thismulti-criteria sorting.

The first valid contract found (geographical and time validity OK, read in the Product Instance) is theone to be used and validated.

(*) This mechanism, which uses an association table between the Product templates and the prioritylevel that are attributed to, allows to manage a same Product with different priority level as theassociation table may be different for each Service Provider.

Note that in this case contractlistProduct template is always > 0 strictly (pointed to contract is valid)




128

The field 'contractListNetworkId' is used to encode foreign product instances, when interoperating onforeign Transport networks. It allows to sort quickly the contracts that belong to other networks and touse only those that are in the same or recognized network.

presence bit # data element identifier data type size(bits)


IOContractList SEQUENCE OF ···

• length 0..IOContractCount 4 length max = 8

• component × length SEQUENCE ··· ——


0 ContractListNetworkId NetworkId 24

• contractListProductTemplate 0..16383 14 ——

• contractListPointer InstancePointer 4 ——

• contractListIsUsed BOOLEAN 1 ——

• contractListPreference ENUMERATED 2 ——

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 { -- 1 bit bit-field.contractListNetworkId NetworkId [0]OPTIONAL, –- 24 bits NetworkId

always presentcontractListProductTemplate INTEGER(0..16383), -- 14 bits

contractTariff behaviourcontractListPointer InstancePointer, -- 4 bitscontractListIsUsed BOOLEAN, -- 1 bit means

'has been --already used'

contractListPreference IOContractListPreference, -- 2 bits see below} – TOTAL : 22 or 46 bits

IOContractListPreference ::= ENUMERATED {oioContractListPreference-Disliked (0),oioContractListPreference-Normal (1),oioContractListPreference-Preferred (2),oioContractListPreference-Selected (3)

} -- 2 bits

-- 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




129

This file is file #3 in the Transport Application. It is a backup file which is configured at creation to hosta 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 acyclic file, and deleted when several new events are appended, the special events are stored until anew similar event will replace it with the new relevant information. They are managed using thespecialeventlist 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 areRFU). It uses the same definition of Special events as PaymentEvent and EventLog (cf. 9.3.7). It'sobjective is to store the last reload or auto-renew that occurred on the card, therefore, it is a listcontaining 2 possible structures corresponding to the 2 possible events:

• Last reload by Action list (tele-renew information) ; SpecialEvent1 structure

• Last auto-renew of period product : SpecialEvent2 structure

Note that the appearance of these fields is used to determine which event is concerned.



size(bits)

initial value and comments

IOSpecialEventLog.Generic SEQUENCE


• eventDateStamp DateCompact 14 0

• eventTimeStamp TimeCompact 11 0

0 eventDisplayData Integer (0 .. 255) 0 unused

1 eventNetworkId NetworkId 24 Optional, 0x578000 if present

2 eventCode PayEventCode 0 unused

• payServicePoint 0..14 0

• payServicePointInfo 0..6 0

3 eventResult Result 0 unused

4 eventServiceProvider Company 16 used for SpecialEvent2 only

5 eventNotOkCounter 0..255 0 unused

6 eventSerialNumber 0..16777215 24equals to application SequenceNumber

7 eventDestination 0..65535 0 unused




130



size(bits)

initial value and comments

8 eventLocationId LocationId(0..65535) (16bits) 16

used for SpecialEvent2 in static

CAD (gates, TVM,...) and only if eventVehicleId is absent

9 eventLocationGate 0..255 0 unused

10 eventDevice DeviceId (224

-1) 0 unused

11 eventRouteNumber 0..65535 0 unused

12 eventRouteVariant 0..255 0 unused

13 eventJourneyRun 0..65535 0 unused

14 eventVehicleId

VehicleId(0..65535)

(16bits)

0used for SpecialEvent2 in mobileCAD (bus, boat,...) and only if eventLocationId is absent

15 eventVehicleClass 0..255 0 unused

16 eventLocationType 0..31 0 unused17 eventEmployee IA5String 0 unused

18 eventLocationReference SEQUENCE 0 unused

19 eventJourneyInterchanges 0..255 0 unused

20 eventPeriodJourneys 0..65535 0 unused

21 eventTotalJourneys 0..65535 0 unused

22 eventJourneyDistance 0..65535 0 unused

23 eventPriceAmount Amount 16 used for SpecialEvent2 only

24 eventPriceUnit PayUnit 0 unused

25 eventContractPointer InstancePointer 4 used for SpecialEvent2 only

26 eventAuthenticator OCTET STRING 0 unused

27 eventData OCTET STRING 56 Used only in SpecialEvent 1209 TOTAL

Table 21 SpecialEventLog data fields

According to the SpecialEvent type, used fields vary as follows :

SpecialEvent1 SpecialEvent2

Options # used 1, 6, 27 1, 4, 6, 8 or 14, 23, 25

Table 22 Options used for SpecialEvent1 and SpecialEvent2

ASN.1 definition of these 2 structures is :

SpecialEvent1 ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {-- 28 bits bit fieldeventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventSerialNumber PRESENT, -- 24 bits : application sequence number

eventData PRESENT -- 8+48 bits :IOStoredValueAutoReloadData

-- Current StoredValue auto-reloadinformation

}) -- TOTAL : 157 bits used.




131

-- Note: the eventData field will contain an IOStoredValueAutoReloadData that is 46bits 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 IOStoredValueAutoReloadDataare set to 0.

SpecialEvent2 ::= [APPLICATION]PaymentEvent(WITH COMPONENTS { -- 28 bits bit field-- Last contract renew/download event (auto-renew or manual renew), remanenteventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventServiceProvider PRESENT, -- 16 bitseventSerialNumber 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


9.3.5.1.2 SpecialEventList structure description



IOSpecialEventList SEQUENCE ··· ——

• IOSpecialEventList SET OF

• length 0..8 4 length=2

• Component x length SEQUENCE


0 eventNetworkId NetworkId 24 unused

1 eventServiceProvider ServiceProvider 12 ——

2 eventSeriousness seriousness (0..3) 2 ——

3 eventPointer InstancePointer 4 ——

Table 23 IOSpecialEventList structure description

The ASN.1 definition of this structure is as follows :

IOSpecialEventCount = 8

IOSpecialEventList ::= SEQUENCE (SIZE(0..8)) -- 4 bits bitfield

OF IOSpecialEvent -- 22 bits each-- TOTAL : 3..179 bits

-- SpecialEvent from ENV1545-2:1998

SpecialEvent ::= SEQUENCE {specialEventNetworkId [0]NetworkId OPTIONAL,specialEventProvider [1]ServiceProvider OPTIONAL,specialEventSeriousness [2]Seriousness OPTIONAL,specialEventPointer [3]InstancePointer OPTIONAL

}} -- TOTAL : 22 bits used.

IOSpecialEvent ::= [APPLICATION] SpecialEvent (WITH COMPONENT {-- 4 bits bit field = 0111 for IO

specialEventProvider PRESENT,-- 12 bitsspecialEventSeriousness PRESENT, -- 2 bitsspecialEventPointer PRESENT, -- 4 bits

}) -- TOTAL : 22 bits used




132

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 isused to hold the running value of the card Store Value. The value file is created with a null LowerLimitand a UpperLimit that is set to the system absolute maximum allowed value. The value in the differentStored Value data (including StoredValue event data, IOHolder StoredValue data and StoredValuefiles ) are stored in tenth of NOK (0,1 NOK).


• Read : this right allows Debit and GetValue commands after having presented the Transport ReadKey (key #7 in Application 0x578001 key set).

• Write : never

•

Read&Write : this right allows the GetValue, Debit, LimitedCredit and Credit commands. This rightis controlled by the Transport Add-Valuer key (key #5 in AID 0x578001 key set).


• 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 atcreation to contain a maximum of 288 bytes (8 records of 288 bits). As this file features a backupmechanism, the total amount of memory used on the card is twice this amount i.e. 576 bytes.


• Read : this right allows only the ReadRecords command after having presented the TransportRead Key (key #7).

• Write : Devices having the ServiceProvider Validation key (key #6) can write to this file.

• Read&Write : never.




133

• Change Config : controlled by the Transport Application Owner key (key#1). This access shouldnormally never be used.

• Security level : plain text.

This file contains exactly 8 validation records that keep track of the different validations that the cardwas subject to. Each event can be of different subtypes, but always uses the same 256bit space. Thegeneric 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 fil led with 0x00.

General event structure description

eventDateStamp Event date stamp

eventTimeStamp Event time stamp

eventNetworkId if different from Environment.networkId

eventCode.payServicePoint related to the transportation mode ("not further described", "urbanbus", "metro", "tram", …) according to the ENV 1545-2 :1998standard.

eventCode.payServicePointInfo 0=unspecified, 1=entry, 2=exit, 6=interchangeeventServiceProvider For information

eventSerialNumber • special event # 1 : Sequence number.

• special event # 2: Sequence number.

• event log : Ticket Serial number

eventDestination Destination if needed

eventLocationId Event location identifier

eventDevice refers to the device that has stored the event

eventVehicleId If applies

eventJourneyRun (Optional) copy of contractTariff, or its equivalent if no contractapplies

eventJourneyInterchanges Duration (minutes) for last validation (transfer duration)

eventTotalJourneys 256 × max passenger count + current count

eventJourneyDistance This field is used when a group buys a ticket and not everybody inthe group has the same concession. It indicates for inspector thefactor of full fare paid globally by the group.

it is the passenger and luggage count minus all the concessionsapplied. (granularity is 5%)

This field is not used for price calculation.

eventPriceAmount Debited Amount for this travel.




134

eventContractPointer Applying contract number, or period ticket which a single ticketextension 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). Eachtime a card is written to its transport application (i.e. its state changes), this sequence number shall beincremented, 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 :



size(bits)

Initial values and comments

IOGeneralEventLog SEQUENCE


• eventDateStamp DateCompact 14 Date of the event

• eventTimeStamp TimeCompact 11 Time of the event

0 eventDisplayData 0 .. 255 0 unused

1 eventNetworkId NetworkId 24 0x578000

2 eventCode PayEventCode 0

• payServicePoint 0..14 4

• payServicePointInfo 0..6 3

3 eventResult Result 0 unused

4 eventServiceProvider Company 16Id of the company owning the event creator (equipment)

5 eventNotOkCounter 0..255 0 unused

6 eventSerialNumber 0..16777215 24 equals to the application serial number.

7 eventDestination 0..65535 16

8 eventLocationIdLocationId(0..65535)

16

9 eventLocationGate 0..255 0 unused

10 eventDevice DeviceId (224

-1) 24

11 eventRouteNumber 0..65535 0 unused

12 eventRouteVariant 0..255 0 unused

13 eventJourneyRun 0..65535 16

14 eventVehicleIdVehicleId(0..65535)

16

15 eventVehicleClass 0..255 0 unused16 eventLocationType 0..31 0 unused

17 eventEmployee IA5String 0 unused

18 eventLocationReference SEQUENCE 0 unused

19 eventJourneyInterchanges0..255 8

20 eventPeriodJourneys 0..65535 0 unused

21 eventTotalJourneys 0..65535 16

22 eventJourneyDistance 0..65535 16




136

eventCode, -- 7 bitseventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bitseventLocationId, -- 16 bitseventDevice, -- 24 bitseventJourneyRun OPTIONAL, -- 16 bitseventVehicleId OPTIONAL, -- 16 bitseventJourneyInterchanges, -- 8 bitseventTotalJourneys, -- 16 bitseventPriceAmount OPTIONAL, -- 16 bits (period right to travel)eventContractPointer, -- 4 bits


9.3.7.1.2.2 Renew or Add new contract event (Common to all products)

EventLogContractRenew ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {-- 28 bits bitfield

eventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bits

eventLocationId, -- 16 bitseventDevice, -- 24 bitseventJourneyRun OPTIONAL, -- 16 bitseventVehicleId OPTIONAL, -- 16 bitseventPriceAmount, -- 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 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bits

eventCode, -- 7 bitseventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bitseventDestination, -- 16 bitseventLocationId, -- 16 bitseventDevice, -- 24 bitseventJourneyRun OPTIONAL, -- 16 bitseventVehicleId OPTIONAL, -- 16 bitseventJourneyInterchanges, -- 8 bitseventTotalJourneys, -- 16 bitseventJourneyDistance, -- 16 bitseventPriceAmount, -- 16 bits


9.3.7.1.2.4 Immediate extension single journey event

EventLogPeriodTicketExtension ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {-- 28 bits bitfieldeventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventCode, -- 7 bitseventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bitseventDestination, -- 16 bitseventLocationId, -- 16 bitseventDevice, -- 24 bitseventJourneyRun OPTIONAL, -- 16 bitseventVehicleId OPTIONAL, -- 16 bitseventJourneyInterchanges, -- 8 bits




137

eventTotalJourneys, -- 16 bitseventJourneyDistance, -- 16 bitseventPriceAmount, -- 16 bitseventContractPointer, -- 4 bits


9.3.7.1.2.5 Single journey contract use event

EventLogSingleJourneyAdvance ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {-- 28 bits bitfield

eventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventCode, -- 7 biteventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bitseventLocationId, -- 16 bitseventDevice, -- 24 bitseventJourneyRun OPTIONAL, -- 16 bitseventVehicleId OPTIONAL, -- 16 bitseventJourneyInterchanges, -- 8 bitseventTotalJourneys, -- 16 bits

eventJourneyDistance, -- 16 bitseventContractPointer, -- 4 bits


9.3.7.1.2.6 Event when reloading the 'Stored Value'

EventLogStoredValueReload ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {-- 28 bits bitfield

eventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventServiceProvider, -- 16 bitseventSerialNumber, -- 24 bitseventLocationId, -- 16 bitseventDevice, -- 24 bits

eventVehicleId OPTIONAL, -- 16 bitseventPriceAmount, -- 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 isconfigured at creation to contain a maximum of 512 bits (64 bytes) record. As this file is provided withthe 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:


• Write : Devices having the Add-Value key (key #5 in the transport Application key set) can write tothis file.

• Read&Write : never.






138

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 atthe end of the file) is filled with 0x00.

-- Last Stored Value reload event (auto-reload or manual reload), non-volatileIOStoredValueReloadEvent ::= [APPLICATION]PaymentEvent (WITH COMPONENTS {

-- 28 bits bit fieldeventDateStamp, -- 14 bitseventTimeStamp, -- 11 bitseventNetworkId OPTIONAL, -- 24 bitseventServiceProvider PRESENT, -- 16 bitseventSerialNumber 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)


9.4 NORTICDF

To be defined

9.5 NSD DESFIRE FILE ORGANISATION SUMMARY

AccessConditions*

A p p

l i c a

t i o n

#

F i l e #

File/Directory name t y p e

ROW R&W Chg

Record : contents

N b o

f R e c o r d s

R e c o r d

l e n g

t h

C o m m .

s e

t t i n g s

— MF (Master File) DF — — —

0 0 0 0 0 0

— Keys key Keys (M) 1 —

— CardIssuerDF DF — — —

— CI_Keys key

Keys (M, I, C, R)

4 —

5 7 8 0 0 0 ( h

e x

)

0xC CI_Header std alwneverneverI CardHeader 1 16 0

— TransportDF DF — — —

— T_Keys key Keys (M, O, A, C, P, V, S, R) 8 — —

0xA T_Environment std R neverA O Environment 1 16 0

5 7 8 0 0 1 ( h e x a

d e c

i

0xC T_CardHolder std R neverC O Holder 1 32 0




139

AccessConditions*

0x1 T_ProductRetailer bkup R neverP O Contract 8 48 1

Counter 8 9

ContextsAndSequenceNumbers 1 80x2 T_ServiceProvider bkup R S P O

ContractList 1 48

1

SpecialEventLog 8 320x3 T_SpecialEvent bkup R S P O

SpecialEventList 1 321

0x4 T_StoredValue valueR neverV O StoredValue — — 1

0x5 T_GeneralEventLog cyclicR S neverO GeneralEventLog 8 36 0

0x6 T_SVReloadLog cyclicR V neverO StoredValueReloadLog 2 32 0

NORTICDF 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 fi les. WhereasCI_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 isrequired for following access method :

'RO' for read-only ( read+debit),

'W' for write-only ( read+canceldebit,↔ append),

'R&W' for read & write ( read+credit,↔ read+clearfile),

'Chg' for change-configuration.

Key description

key MF (Master File) CardIssuerDF(application #0x578000)

TransportDF(application #0x578001)

NorticDF

M Master key (0) Master key (0) Master key (0) To be defined

A — — Application Retailer key (2)

C — Card Retailer key (2) Card Retailer key (3)

I — Card Issuer key (1) —O — — Application Owner key (1)

P — — Product retailers key (4)

R — Read key (3) Read key (7)

S — — Service Providers key (6)

V — — Add-Value key (5)

Table 27 DESFire key set




140

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.




141

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.




142

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. cardmanufacturers. 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 cardinitialisation process. The file can be read without any key. This means that this key can be confined tothe 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, byallowing the key holder to change the configurations of all files. This possibility should never be usedas part of the normal operations. The key should be retained by the application issuer, and only beused for special corrective actions or operations.

The Application Retailer Key (#2) is used to write to the T_Environment file. This file holds static dataabout 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 usedfor 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 deviceholding 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 beavailable for the application issuer both for initialisation and for subsequent updates. This key shouldnever be available for end-user devices.

The Product Retailer key (#4) is necessary to hold for all devices that shall update the contractstrucure – i.e. to sell or install a new product in the contract l ist. 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 isall companies included in a set of connected interoperable regions.

Usage of a contract is possible without the Product Retailer key, as usage information is updatedusing the Service Provider key.

The Add-value key (#5) is necessary to hold for all devices that shall increment the value file (“Travelpurse”).

The Service Provider key (#6) is used to write to the Service provider file. This file contains countersthat contain variable information for a contract.

The same key is used to write to the Special Event file. This file currently contains information relatedto reload and auto-renew actions. This means that all devices that will update counters, or that areable to perform an auto-renew or –reload, must have access to this key.




143

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 thevalue 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 ThirdParty.




144

12 CODIFICATION

In order to guarantee interoperability all code fields that can cause misunderstandings must beallocated 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 Oslosystem.

ContractTariff 16 bits numeric Identifies a specific contract tariff.must be unique within an interoperability area.Full identification of a product isNetworkID+contractProvider+contractTariff.

ContractListProductTemplate 14 bits numeric Identifies a product template. This – inconjunction with the ContractTariff – defines aspecific product. This identifier must be uniquewithin 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, butextends it with specific codes




145

13 TERMINOLOGY AND DEFINITIONS

13.1 DEFINITIONS

Term Definition Comment

(Electronic) Transaction Authorised generation of payment dataupon using a valid payment medium.

(Security) key Key involved in security mechanismsinvolving cryptographic algorithms in theNORTIC system.

Security mechanismsinvolve authentication of products and transactions.

(Security) keymanagement

The process of ensuring the confidentialityand integrity of (security) keys in theNORTIC system.

Application The application is an implemented andinitialised template on the smart card (ticketmedium). The application template is amaster of the application specification for implementation, which is specification of files, directory entries and security schema.

A transport application onthe smart card process andstores information aboutthe customer and thetransport products thecustomer are using, thehistory of rides taken.

Application Keys Required keys to access an application onthe 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 identifyof an identity.

Identity could be smartcard, MAD etc.

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 informationcontrolled by the card owner.

Clearing The processing and possible consolidationof transaction information passing between

the parties accepting tickets (products) or payments on each other’s behalf.

Collection & Forwardingservice

A service responsible for the process of collection and forwarding data in an IFMsystem

Customer A person that holds the ticket medium (cardholder).

Interoperability 1) The provision for the Customer of aseamless journey using the same ticket




146


medium (IC card) on different ServiceOperators.

2) The ability of systems to provide servicesto and accept services from other systems.

Master key Key that through an encryption process isused to generate diversified (security) keys.

Diversified keys arecontained in the ticketmedium. Master keys arekept in SAM/MAD.

Product Owner Entity that specifies the pricing, usage rulesand commercial rules related to a productat 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. asingle journey ticket.

Product UsageTransaction

Electronic Transaction at a MAD andsuccessful clearing of the payment uponusage of ticket medium.

ProductLP Owner Responsible for the local product on theCustomer 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 contractbetween himself and the Customer.

ProductTC Owner Responsible for the NORTICTravelContract on the Customer media, .i.e

his IC card. Holds the contract betweenhimself and the Customer.

ProductTC Retailer Acting on behalf of the ProductTC Owner issuing the NORTIC TravelContract on theCustomer media, .i.e. his IC card. Holds thecontract between himself and theCustomer.

Registrar Entity responsible for registeringinformation ensuring uniqueness of entitiesin the ticketing system

Information include productid, Mad Id etc.

Security list List of blocked cards and/or productoccurrences (earlier called black list or B-list).

Security policy Addresses how threats shall be controlledtaking into account aspects such as:

• Protection of the Interest of the Public

• Financial loss detection an prevention

• System design constraints

Service Operator Provides the transport function for theCustomer, in other words the actual




147


transport provision.

Threat and vulnerability

analysis

An overall assessment of the most probable

threats and the system’s vulnerability tothese threats.

Transport keys Key used to ensure confidentiality andintegrity of (Security Keys) within theNORTIC system

Trusted Third Party (TTP) Responsible for notary functions in case of disputes between the customer and the IFMsystem and between product owners. TTPis also responsible for generating anddistributing security keys to the parties inthe IFM system (product owners, serviceoperators and retailers)




148

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 Abbreviation changedto MAD

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




149

Abbreviation Definition Comment

TSN Transaction Sequence Number

TTP Trusted Third Party

USN Unblocking Sequence Number

13.3 REFERENCE STANDARDS

13.3.1 Normative References

Referenced standards are:

Ref No. Document

Number. Document name1 ENV1545-1

Identification card systems: Surface transport applications: Part1 – Elementary data types, general codes and general dataelements

2 ISO7816-1 Identification Cards – Integrated Circuit Cards with Contacts:Part 1 – Physical Characteristics

3 ISO7816-2 Part 2 – Dimension and location of contacts4 ISO7816-3 Part 3 – Electronic signals and transmission protocol5 ISO7816-4 Part 4 – Inter-Industry commands for interchange6 ISO7816-5 Part 5 – Numbering systems and registration procedure for

application identifiers7 ISO7816-6 Part 6 – Inter-Industry data elements8 ISO10373-3 Identification cards – Test methods – Part 3: Integrated circuit(s)

cards with contacts and related interface devices9 ISO10373-5 Identification cards -- Test methods -- Part 6: Proximity cards10 ISO 11770-1 Information technology – Security techniques – Key

management: Part 1 – Framework11 ISO 11770-2 Part 2 – Mechanisms using asymmetric techniques12 ISO14443-1 Identification Cards – Contactless integrated circuit cards –

Proximity Cards (PICC): Part 1 - Physical Characteristics13 ISO14443-2 Part 2 – Radio Frequency power and signal interface14 ISO14443-3 Part 3 – Initialisation and Anticollision15 ISO 14816 Road Traffic and Transport Telematics (RTTT), Automatic

vehicle and equipment identification, Numbering and datastructures

16 CEN TC 224/WG11

IOPTA – Interoperable Public Transport Application

17 CEN TC 278/WG 3 IFMSA – Interoperable Public Transport Fare ManagementSystem Architecture

18 FIPS PUB 140-2 Security Requirements for Cryptographic Modules (25.05.02)




151

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 Akershuscounty :

• 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 implementationdetails 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 ReferenceNumber

Ind. Author Title

[D1] 4020 13250 B C. Bronchain Common specifications for Interoperability withinAutomatic 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 Transportapplications - Part 1 : General data elements

[D8] ENV1545-2 1998 CEN Identification card systems - Surface Transport

specification for interoperable electronic ticketing system

Documents