Specification for Interoperable Electronic Ticketing System

Specification for Interoperable

Electronic Ticketing System

June 10, 2005

Norwegian Public Roads Administration

Preface

Handbook 206 covers electronic ticketing and Interoperable Fare Management (IFM) systems. The first preliminary version of the handbook was issued in 1995 and was then followed by the official first version of Handbook 206 Electronic ticketing in 1998 (in Norwegian only). The development in the electronic ticketing domain requires an updating of the version from 1998 both from a technology point of view as well as from an interoperability point of view.

Handbook 206 Part 1, Part 2 and Part 3 replace the previous 1998 version.

Handbook 206 Part 1 describes electronic ticketing systems using a ticketing media where all

information, e.g. customer data, products and logs are stored electronically. Hence, the Handbook 206 does not cover ticketing systems or equipment used for issuing traditional paper tickets.

Part 2 covers recommendations as regards regional and inter-regional electronic ticketing systems and is based on the same principles as given in part 1 and 3.

Part 3 covers technical requirements and guidelines that shall be used when purchasing and installing ticketing systems. This is to ensure that all new electronic ticketing systems can be interoperable and by this being an attractive alternative for the customers concerning the use of public transport. The handbook has been prepared based on a mandate given by the Ministry of Transport and communications and is financed by the Norwegian Public Roads Administration (NPRA). The main objective is that electronic ticketing systems shall be simplified and by this making it easier for the customer to use public transport. A very important part of the simplification process is establishing local, regional and national interoperability.

Project leader for the Handbook 206 project has been Jacob Trondsen from NPRA. The work on the Handbook 206 has been done in cooperation with a project group with Robert Fjelltun Bøe from NPRA, Hanne Juul from Hordaland County Administration, Trond Myhre from Vestfold kollektivtrafikk (Vestfold Public Transport), Linda Lillestøl and Jan Christiansen from NSB (Norwegian State Railway), Lars Bjønnes from Mobitech, Jørn Hanssen from Oslo Sporveier (Oslo tram, bus and metro), Lilia Halsen Bidar and Stig Rønning from Q-Free Ticketing and Trond Foss from SINTEF.

The target group for this part of the handbook will be personnel purchasing electronic ticketing systems as well as suppliers designing and implementing such systems.

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

Norwegian Public Roads Administration Directorate of Public Roads

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

1 B

ACKGROUND

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

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

2. An alternative to the NORTIC ISO and CEN based specification using a mifare DESFire Contactless IC-card. This specification is called NORTIC TravelContract application for DESFire. The specification is based on the NORTIC specification for DESFire (NSD).

The NORTIC application does not presuppose any specific card. The current description presupposes a smartcard with the ISO-7816 command set implemented. However, the current situation in Norway concerning implementation of electronic ticketing systems has influenced the Norwegian Public Roads Administration also describing how the mifare DESFire IC-card may be used as an alternative to the standardisation based NORTIC specification.

Given the detailed technical nature of this specification, and the fact that valuable experience is gained as the different implementation projects proceed, the specification cannot be finalized yet.

Clarifications, additional material and even minor changes are bound to be released. This means that new versions of the specification will be issued. In order to ensure an orderly and accountable process strict version and change control will be enforced, and new versions will be made available through a comprehensive release process.

2 S

PECIFICATION OF THE

NORTIC

APPLICATION AND

PRODUCT

This chapter includes the definition of the NORTIC Interoperable Product that the Customer may acquire and use as payment means in exchange for use of transport services. The term Product is defined in HB206 Part 1 in accordance with the definition used within the European standardisation bodies CEN TC278/WG3/SG5 (IFM) and CEN TC224/WG11 (IOPTA). Product is defined as a set of usage rules, pricing rules and commercial rules. The requirements of these rules as well as their interpretation and functionality related to the involved entities of the system will be defined.

• NORTIC is the name of the common specification for interoperable electronic ticketing, and

stands for NORwegian Ticketing Interoperable Concept.

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

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

In order to allow the NORTIC product to co-exist with the regional / inter-regional products the NORTIC product is situated in a specific application on the IC-card (DESFire).

2.1 NORTIC INTEROPERABLE PRODUCT

Within the scope of the NORTIC Specification there is one Interoperable Product being of IOPTA type Charge To Account. The Product is called a TravelContract or ‘Reiseavtale’ in Norwegian. The term ProductTC Owner means the entity being responsible for issuing the TravelContract (TC).

The TravelContract is defined to be a pointer to a Central Account managed by the Product Owner. The Central Account is linked to a Customer via a contract between the Product Owner and the Customer. The payment between Customer and the Product Owner is out of the scope of this specification.

IOPTA definition of Charge

To Account: Identifies and provides further information concerning an authorised account which may act as a ticket for a journey or be used to acquire a separate ticket.

Within the NORTIC specification the interoperable TravelContract is treated as being both a payment means and a Product. It is important to note this dual functionality and to understand the meaning of the two concepts. Being a payment mean the TravelContract has the characteristics of a contract agreement between the Customer and the Product Owner, which regulates the settlement of the Customers account. While being a Product, the TravelContract refers to a specific set of usage rules, pricing and commercial rules, which is applied when the Customer is using the TravelContract. Within this specification it is mainly the usage rules that are defined, i.e. how the TravelContract is issued, used and terminated within the system.

The NORTIC TravelContract is issued on a smart card, and offers interoperability for the Customer. Interoperability is:

• The provision for the Customer of a seamless journey1

using the same smart card on different Service Operators.

• The ability of systems to provide services to and accept services from other systems The NORTIC TravelContract, issued on a smart card, offers the Customer the possibility to use the TravelContract as payment means in different Interoperable Fare Management Systems in Norway. Technically, a separation is made between the NORTIC application and the TravelContract product. The NORTIC application is installed on the ticket media (smart card). Ticket Media Accepting Devices (MAD) identifies and selects the NORTIC application on the ticket medium by one unique NORTIC application Identifier. An occurrence of the TravelContract product is loaded in the NORTIC application.

2.2 OVERALL REQUIREMENTS

Definitions and specifications related to the national interoperable product should be met by the overall requirements in the table below. The following terms are used:

ProductTC Owner: The entity being responsible for the TravelContract installed on the Customer

media, e.g. an IC card.

ProductTC Retailer: The entity acting on behalf of the ProductTC Owner having sold and delivered

the TravelContract to the User.

Local Product A product offered by a ProductLP Owner that usually is different from the

ProductTC Owner, e.g. a PT operator in another city or region.

ProductLP Retailer: The entity acting on behalf of the ProductLP Owner having sold and delivered

the local product to the Customer.

Requirement No

Requirement

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

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

[R 3] Clearing and settlement of sales and use of the TravelContract shall be done between the ProductTC Owner and ProductLP Retailer - either bilaterally or

through a central clearing service.

[R 4] The use of the TravelContract, creating an electronic fare collection transaction (EFC) at the point of purchase, shall be used as a claim for payment between the ProductLP Retailer and the ProductTC Owner.

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

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

1

By seamless journey we here understand a travel that may consist of using services from several Service Operators, while all payments are made with one single card. This is also characterised as coordinated ticketing.

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

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

TravelContract to be renewed for another two years.

[R 9] The TravelContract defined within the NORTIC shall contain information about the ProductTC Owner in order for a ProductLP Retailer to forward a claim for

payment to this ProductTC Owner.

[R 10] The NORTIC TravelContract shall be issued on the ticket medium by all Product Owners, who whish to offer this interoperable product to their Customers.

[R 11] Any ProductLP Retailer shall accept a TravelContract that has been issued in

line with the NORTIC specifications.

[R 12] An electronic ticket shall be written to the NORTIC ticket medium (smart card) as receipt of payment when the TravelContract is used as payment means. This electronic ticket shall be written to the card, i.e. the NORTIC Event log.

The TravelContract may be used for payment of a single journey or, in a local system, to pay for another product. The requirement [R 12] defines that an electronic receipt for the payment shall be stored in the Customers card. If appropriate, the ProductLP Retailer may generate a proof of

travel/ticket, which can be verified by the Service Operator (validation/inspection). This Proof of Travel/Ticket may have three optional forms;

1. a paper ticket,

2. an electronic ticket stored within the NORTIC application, or

3. an electronic ticket stored in another (local) application elsewhere in the card.

The settlement between the Customer and ProductTC Owner is out of the scope of this specification.

The settlement between ProductLP Retailer and ProductTC Owner is out of the scope of this

specification.

2.3 ENTITIES

An entity is an abstract unit composed of set of functions within public transport. Organisations, companies or persons fulfil the functions of these entities. Some of the entities in the IFM model are outside the scope of this specification (Registrar, Security Manager and Collection & Forwarding service). Within the scope of the NORTIC TravelContract specification we identify the following entities:

• ProductTC Owner

• ProductLP Retailer

• Customer

Interaction is required between these entities to fulfil interoperability functions of an Interoperable Fare Management System (IFM). An IFM system is a Fare Management System that can provide services and accept services from other Fare Management Systems. This provides the Customer the

opportunity of Seamless Travel.

ProductTC Owner: The ProductTC Owner is responsible for issuing the NORTIC TravelContract

product on the Customers ticket media (IC card (smart card)). The ProductTC Owner holds the contract

between himself and the Customer. A Contract is the expression of an agreement between the Customer and the Product Owner, which defines the conditions under which the Customer may use the NORTIC TravelContract as payment mean and how the central account is kept in balance. The NORTIC TravelContract shall be issued on the ticket medium by all Product Owners, who whish to offer this interoperable product to their customers (optional).

Retailer: The Retailer is the entity that sells the product to the Customer on behalf of the Product

Owner. Within NORTIC the Retailer has two roles: 1. ProductTC Retailer

2. ProductLP Retailer

First the ProductTC Retailer sells the TravelContract to the Customer, and later when using the ticket

media as payment means, the ProductLP Retailer sells a local product (single journey ticket or other

local product) to the Customer. Any ProductLP Retailer within Fare Management Systems shall accept

the TravelContract product that has been issued in line with the NORTIC specification (mandatory). When the Customer has purchased a ticket at the ProductLP Retailer he is entitled to use a service,

conformant to the validity of the ticket purchased, at the Service Operator transport means. The ProductLP Retailer collects usage data (transaction information) and forwards it to the ProductLP

Owner.

Service Operator: The Service Operator (also known as the Service Provider) provides the transport

function for the Customer, in other words the actual transport provision (the physical bus, train etc). A Customer benefits from a transport service and the Service Operator validates the Customers ticket purchased from the ProductLP Retailer. The Service Operator collects usage data (transaction

information) enabling him to receive payment for the transport services provided. In many systems the ProductLP Retailer and Service Operator is handled by the same organisation, and the purchase and

validation of the single journey ticket is performed in one operation.

Customer: A person that holds the NORTIC Application (cardholder). The Customer uses the

NORTIC TravelContract as payment mean in order to pay for a single journey ticket allowing her to acquire travels provided by the Service Operator.

It is out of this specifications scope to define the Contract between the ProductTC Owner and the

Customer. How the central account is kept in balance is dependent on the agreement between the Customer and the ProductTC Owner. For example, travels may be pre-or post paid. In the first case the

Customer pay in advance to a centrally held account managed by the ProductTC Owner, and all travels

are charged to this account. In the latter case an external financial institution, e.g. bank or Credit Card Company, debits the Customers account subsequent to the travels.

Figure 1 Simplified sequence diagram for usage of TravelContract

2.4 TRAVELCONTRACT LIFE CYCLE

This section elaborates the life cycle phases of the NORTIC TravelContract. The TravelContract life cycle is defined to consist of the following phases:

• TravelContract Issuance • Use of the TravelContract • TravelContract termination

TravelContract issuance is the process of issuing the TravelContract on the Customers ticket medium (smart card). The Customer uses the product as payment mean when acquiring paper- or

electronically tickets in order to travel. The TravelContract may also be used to acquire other products, e.g. a monthly ticket. TravelContract termination is the process of terminating the use of the

TravelContract occurrence on the Customers ticket medium.

2.4.1 TravelContract issuance

The ProductTC Owner is responsible for issuing the TravelContract on the Customers ticket medium.

The ProductTC Owner holds the Contract between himself and the Customer for any occurrence of the

TravelContract. The Contract defines the conditions, under which the Customer may use the TravelContract as payment mean. The contractual link between the ProductTC Owner and the

Customer also defines how the customers centrally held account is kept in balance. The NORTIC TravelContract shall be issued on the Customers ticket medium by all Product Owners, who whish to offer this product to their customers which means that

The TravelContract product shall be valid for two years from its issuing date. It is up to the ProductTC

Owner if renewal is allowed for additional periods of two years.

The TravelContract is loaded on the NORTIC application, which is installed on the ticket medium (smart card). The process of TravelContract issuance includes both the NORTIC application

instalment and loading the TravelContract on the application. The application is an implemented and initialised application template on the ticket medium (smart card). The application template is a master of the application specification for implementation, which is a specification of files, directory entries and security schema. The requirements to the ticket medium as well as application instalment and loading the TravelContract product on the application is specified in Chapter 4 “Smart Card and Media Accepting Device (MAD) Specification”.

Figure 2 Customer media with NORTIC application housing a TravelContract

TravelContract issuance uses and provides data from/to security management. The issuance also provides data to customer management (outside the scope of this specification). Security

management shall guarantee the operation, security and reliability of all system processes.

The TravelContract is always issued with security mechanisms, but the ProductLP Retailer may

accept the TravelContract as payment mean with or without security mechanisms.

The ProductTC Owner shall use security mechanism described in this specification when issuing the

TravelContract. Security keys and mechanisms shall be protected and stored in Secure Application Modules (SAM) wherever security mechanisms are in use in the issuing process.

The ProductTC Owner is responsible managing the customer data and the status of the TravelContract

occurrences. The status of the TravelContract may be open, pending or blocked. An open TravelContract occurrence is valid for use as payment mean at any ProductLP Retailer. Blocked

TravelContract occurrences are not valid for use at any ProductLP Retailer. Reasons for blocking

TravelContract occurrences may be:

• The Customer breach the contract with the ProductTC Owner

• Stolen or lost ticket medium (smart card)

Customer data and status of TravelContract occurrence shall be kept in a Card Register of the ProductTC Owner responsibility. Relevant data in a Card Register are (for mandatory data this is

written in brackets, others are optional): • Card serial number (mandatory)

• Security system key generation/version (mandatory) • TravelContract status, as described above (mandatory) • TravelContract balance

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

Customers ticket medium. The process of TravelContract issuance includes both NORTIC application instalment and loading the TravelContract on the application.

[R 14] The TravelContract is always issued with security mechanisms, but the ProductLP Retailer may accept the TravelContract as payment mean with or

without security mechanisms.

[R 15] The ProductTC Owner shall use security mechanism described in this

specification when issuing the TravelContract. Security keys and mechanisms shall be protected and stored in Secure Application Modules (SAM) wherever security mechanisms are in use.

[R 16] The ProductTC Owner is responsible managing the customer data and the

status of the TravelContract occurrences. Mandatory data are: • Card serial number (unique card ID)

• Security system key generation/version • TravelContract status, as described above

In each transaction, the MAD (Media accepting device) activates the ticket medium and selects the NORTIC application based on an application identifier. Therefore the MAD must be able to identify and select the NORTIC application on the ticket medium by one unique NORTIC application Identifier.

Requirement No

Requirement

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

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

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

Requirement No

Requirement No

Requirement

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

[R 20] The ProductTC Owner shall obtain a valid issuer identification number from

a Nationally Authorised Registration Authority.

2.4.2 Use of the TravelContract

The Customer may use the TravelContract as payment mean to: • Pay a single journey in order to travel (mandatory)

• Pay another product loaded on the ticket medium (optional)

The ProductLP Retailer provides the Customer a Proof of Travel/Ticket in one of the following ways:

• a paper ticket,

• an electronic ticket stored within the NORTIC application, or

• an electronic ticket stored in another application elsewhere in the card.

The Proof of Travel/Ticket for a single journey may be validated by the Service Operator equipment according to the local Product Owners system regulations.

The ProductLP Retailer may accept the TravelContract with or without security mechanisms. The

ProductLP Retailer is responsible for collecting product usage data when a TravelContract occurrence

is used. TravelContract usage data is the transaction information generated when the TravelContract is used, and includes payment information. The transaction data is forwarded to the ProductTC Owner

in order to receive payment for the actual single journey travel or local product. The NORTIC ticket medium shall generate a signature, which enables the ProductTC Owner to verify the authenticity and

integrity of the claim (transaction). Authenticity ensures the sender identity (Retailer), i.e. provides information that the identity of a source of data received is as claimed. Integrity ensures that the received data is unchanged or unmanipulated, i.e. protection against unauthorised modification or deletion of information. In detail use of a TravelContract consists of:

• Detection and verification of the NORTIC application on the Customers ticket medium • Detection and verification of the TravelContract occurrence in the NORTIC application • Verify that the TravelContract occurrence is valid (e.g. not security listed and within validity

period)

• Calculate the price of the single journey ticket or product

• Write an electronic ticket to the NORTIC Application log and/or print a paper based ticket or write/issue a product into the ticket medium

• Collection of the TravelContract usage data (transaction information)

• Forwarding the TravelContract usage data as a claim against the ProductTC Owner

The ProductTC Owner is always economically responsible for a TravelContract, meaning that the

ProductTC Owner claims the customer for the price of the single journey ticket or product. If non

payment from the Customer the ProductTC Owner is still in relation to the ProductLP Retailer The

ProductTC Owner may deny claims from ProductLP Retailer in the following situations:

• The ProductLP Retailer accepts the TravelContract without security mechanisms

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

2.4.3 TravelContract usage, pricing and commercial rules:

Description

Usage rules

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

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

• Buy single journey tickets (mandatory)

• Buy other product, e.g. a monthly ticket (optional)

A payment transaction as receipt for payment shall be written into the card TravelContract log. A single journey ticket (proof of travel) may be paper based or electronically stored in the customer’s ticket medium (event log in the smart card).

The ProductLP Retailer accepting the TravelContract is responsible for

collecting product usage data in order to receive payment from the ProductTC Owner. Product usage data (transactions) shall be signed by

the ticket medium, which enables the ProductTC Owner to verify the

authenticity and integrity of the claim from the ProductLP Retailer.

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

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 pricing rules in the IFM system where the TravelContract is used as payment mean.

The Customers centrally held account managed by the ProductTC Owner

is charged when the TravelContract is used as payment mean. The contractual link between the ProductTC Owner and the Customer defines

how the centrally held account is kept in balance.

Commercial rules

The ProductLP Retailer accepting the TravelContract as payment mean

forwards a claim to the ProductTC Owner subsequent to the ticketing

event. Settlement between the ProductTC Owner and the ProductLP

Retailer is according to the agreement between the parties.

Requirement No

Requirement

[R 21] Any ProductLP Retailer in Norway shall accept the TravelContract as payment

mean. The Customer may use the TravelContract in order to: • Pay a single journey in order to travel (mandatory)

Requirement No

Requirement

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

card.

[R 22] The ProductLP Retailer is responsible for collecting TravelContract usage data.

Product usage data is the transaction information generated when the product is used, and includes payment information. The transaction data is forwarded to the ProductTC Owner in order to receive payment for the actual customer

travel.

[R 23] The NORTIC ticket medium shall generate a MAC (Message Authentication Code), which enables the ProductTC Owner to verify the authenticity and

integrity of the claim (transaction).

[R 24] The ProductTC Owner is always economically responsible for a TravelContract,

meaning that the ProductTC Owner claims the customer for the price of the

single journey ticket or product. If non payment from the Customer the ProductTC Owner is still responsible in relation to the ProductLP Retailer. The

ProductTC Owner may deny claims from ProductLP Retailer in the following

situations:

• The ProductLP Retailer accepts the TravelContract without security

mechanisms

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

MAD 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 shall prevent use of the product based on TravelContract information read from the ticket medium. In some cases the Customer triggers termination of the TravelContract issued in his ticket medium. TravelContract termination is the responsibility of the ProductTC Owner and includes the following

steps:

1. De-install the TravelContract on the ticket medium and update product status maintained by the ProductTC Owner

2. Terminate the centrally held account

3. Terminate the contractual link between the ProductTC Owner and the Customer

The TravelContract may be de-installed immediately from the ticket medium. Terminating the centrally held account and the contractual link between the Customer and the ProductTC Owner assumes

settlement of all payment transactions. Completing settlement with ProductLP Retailer and the

Customer is the responsibility of the ProductTC Owner.

Requirement No

Requirement

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

2.5 T

C

S

K

M

Clearing and settlement between the ProductLP Retailer and the ProductTC Owner take place

subsequent to the Customers use of the TravelContract as payment mean. To prevent use of the TravelContract in situations where the Customer has breached the contract with the ProductTC Owner,

e.g. the centrally held account is not kept in balance due to non-payment, it is the responsibility of the ProductTC Owner to distribute security lists to the ProductLP Retailer accepting the TravelContract as

payment mean. The security list, earlier called black list, contains a list of blocked TravelContracts. This section describes clearing and settlement, security list management and discusses physical exchange of information between identified entities. Security key management is also considered in this section.

2.5.1 Clearing and settlement

Clearing and settlement for the use of the NORTIC TravelContract shall be done between the

ProductTC Owner and the ProductLP Retailer accepting the TravelContract as payment mean. Clearing

is the processing and possible consolidation of transaction information passing between the parties accepting the NORTIC TravelContract as payment mean on each other’s behalf. This situation is illustrated in Figure 3. The ProductLP Retailer accepts the NORTIC TravelContract as payment mean

when the Customer buys a product (paper or electronically ticket) in order to travel. The ProductLP

Retailer forwards transaction information, including payment information, to the ProductTC Owner. The

Customers centrally held account is charged for the price of the product. The transaction information forwarded from the ProductLP Retailer is a claim directed towards the ProductTC Owner. The actual

settlement between the ProductTC Owner and the ProductLP Retailer is according to the agreement

between these two parties. In some situations the Product Owner and Retailer may be the same entity, and no settlement between Product Owner and Retailer is required.

Figure 3 Clearing and settlement between ProductTC Owner and RetailerLP

The ProductTC Owner will receive claims from ProductLP Retailer that have accepted the occurrences

of the TravelContract as payment mean. Figure 4 illustrates a situation where the Customer has used the TravelContract as payment mean at several ProductLP Retailer in order to travel with several

Service Operators. The transaction information, which is a claim, is forwarded to the ProductTC Owner

from all ProductLP Retailer. Settlement between the ProductTC Owner and the ProductLP Retailer shall

Figure 4 Settlements between ProductTC Owner and RetailersLP

Requirement No

Requirement

[R 27] Clearing and settlement for the use of the NORTIC TravelContract shall be done between the ProductTC Owner and the ProductLP Retailer accepting the

TravelContract as payment mean.

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 list

of blocked TravelContract occurrences (security list) to the ProductLP Retailer accepting the NORTIC

TravelContract as payment mean. The security list, also called blacklist, is distributed to the ticketing equipment to prevent use of a blocked TravelContract occurrence. It is the responsibility of the ProductTC Owner to maintain the status of the issued TravelContracts. The status of a TravelContract

occurrence may for example be open, pending or blocked.

The ProductTC Owner distributes security lists to ProductLP Retailer, who acknowledge the reception of

the security list.

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

the ProductTC Owner and shall distribute the security list to all user

equipment/MAD.

The actual physical exchange of transactions/claims and security list shall be done according to agreements between the parties involved. Whether an electronic media does the exchange sent through the mail system or through advanced communication systems is out of the scope of this specification. The format of transaction information and security lists exchanged between ProductTC

Owners and ProductLP Retailer shall be in accordance with the format in this specification.

2.5.4 Security key management

The ProductTC Owner is responsible for the security of the:

• Ticket medium (TravelContract data)

• Transaction process (enabling authentication of TravelContract)

• Settlement process (enabling mutual non-repudiation of the transactions made) Some initial assumptions for the security scheme are:

The segment integrity of ticket medium is assumed to be trustworthy so that secure information (keys) in the ticket medium is kept secret. However the ticket medium might be issued with publicly known information (i.e. data elements conformant to this Handbook 206-2) so that this information is un-authentic. This introduces the need that ProductLP Retailer accepts TravelContract issued in an

authentic way (TravelContract production data authentication)

The ProductTC Owner and the ProductLP Retailer will often be two different legal organisations and

therefore there might not exist any trust between them. This introduces the need for

• The ProductTC Owner (or Trusted Third Party) shall accredit (authorise) any SAM installed

in the ProductLP Retailer MAD for accessing the NORTIC application. The SAM shall

ensure the confidentiality and integrity of the TravelContract authentication keys.

• The ProductTC Owner must be able to distribute the TravelContract authentication keys to

the ProductLP Retailer MAD SAM. The security includes confidentiality, integrity and

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: ProductTC 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 are

kept secret throughout the TravelContract life-cycle (focusing on the SAM segment integrity)

• The ProductTC Owner and the ProductLP Retailer must be able to exchange clearing and

settlement data in a secure way. This includes integrity, peer-to-peer authentication and non-repudiation.

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

Requirement No

Requirement

[R 30] The ProductTC Owner is responsible for selecting the appropriate authentication

mechanism of the TravelContract (symmetrical versus asymmetrical) and provides a secure download of authentication keys to the ticket medium. [R 31] The ProductTC Owner and ProductLP Retailer MAD SAM shall exchange

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 responsibilities and requirements of the ProductTC Owner, here over mentioned, may be performed by the TTP.

2.6 R

The column ‘Mandatory’, in tables below, states if the responsibility is mandatory or not for the actual entity.

2.6.1 ProductTC Owner responsibilities

Responsibility Description Mandatory

Security key management The ProductTC Owner is responsible for generation,

distribution and maintenance of security keys for the appropriate authentication mechanism chosen. Additionally the ProductTC Owner accredits the

ProductLP Retailer MAD SAM’s.

Yes

TravelContract issuance The ProductTC Owner is responsible for installing

the NORTIC application and the TravelContract occurrence on the Customers ticket medium

Optional

Contractual link with the

customer The Contract between the ProductCustomer defines the conditions, which under the TC Owner and the Customer may use the TravelContract as payment mean. The contractual link between the Product Owner and the Customer also defines how the customers centrally held account is kept in balance.

Yes

Collecting Customer data The ProductTC Owner collects Customer data when

the TravelContract is issued. The ProductTC Owner

maintains Customer data in his system.

Yes

Charge centrally held

account The Productthe centrally held account when claims are received TC Owner is responsible for charging from ProductLP Retailer.

Yes

Settlement with Retailers ProductLP Retailer forwards claims to the ProductTC

Owner in order to receive payment for travels paid with TravelContract occurrences. The agreement between the ProductTC Owner and ProductLP

Retailer defines how settlement is carried out.

Yes

TravelContract status ProductTC Owner maintains the status of

TravelContract occurrences, e.g. blocked. Yes Security list management The ProductTC Owner is responsible for distribution

of security list to ProductLP Retailer accepting the

Responsibility Description Mandatory TravelContract as payment mean. The security list

consists of a list of blocked TravelContract occurrences.

TravelContract termination The ProductTC Owner terminates TravelContract

occurrences and the centrally held account. Yes

2.6.2 ProductLP Retailer responsibilities

Responsibility Description Mandatory

Security key usage The ProductLP Retailer may authenticate the

TravelContract, and shall in that case receive, store and handle authentication keys from the ProductTC

Owner according to his rules.

Optional

TravelContract product usage

Any ProductLP Retailer shall accept the

TravelContract product as payment mean.

Yes Collecting usage data The ProductLP Retailer collects TravelContract

usage data (transaction information) when a TravelContract is used as payment mean.

Yes

Claim the ProductTC Owner The ProductLP Retailer forwards collected

TravelContract usage data (transaction) to the ProductTC Owner in order to receive payment.

Yes

security list management Retailers receive security lists from ProductTC

Owner. It is the responsibility of the ProductLP

Retailer to distribute the security list to the ticketing equipment to prevent use of blocked

TravelContracts.

Optional

2.6.3 Customer responsibilities

Responsibility Description Mandatory

Contractual link with the ProductTC Owner

The Customer establishes a Contract with the ProductTC Owner. The Contract defines the

conditions, which under the TravelContract is used as payment mean, and how the centrally held account is kept in balance.

Yes

Keep the centrally held

account in balance The Customer is responsible for keeping the centrally held account in balance. How the centrally held account is kept in balance is defined in the contract between the ProductTC Owner and the

Customer.

2.7 IDENTIFICATION

2.7.1 Introduction

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

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

Security

Identification of entities, objects, applications, products etc enables the use of Security lists, e.g. blacklisting a stolen retailer machine or a stolen ticket media. It also enables authentication and message integrity, e.g. by using the unique identification in an authentication procedure or including the unique ID in a seal, e.g. a message authentication code (MAC).

Communication, i.e. addressing entities

In an IFM network there will be many entities like organisations, companies and components that will be acting as a sender and/or a receiver of information. A unique identification is needed for addressing the different entities in a communication network.

Auditing

There is a strong requirement on being able to audit any transaction and any piece of information in an IFM system, e.g. following a usage transaction from the creation by the service provider until it is cleared and refunded by the product owner. If something goes wrong or any information is changed during its lifetime it is important being able to investigate what happened and where in the IFM system it happened.

2.7.2 Numbering scheme

As a minimum the following objects shall have a unique identity in an IFM system: A. 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 cryptography

E. All Components handling, storing and transferring IFM information

NOTE 1: The numbering scheme is based the prerequisite that all objects are present within the same IFM system. Hence, there is no need to include the identity of the network or the IOPTA application. In case any information is exported to other IFM systems the IOPTA application and network id are added to the entity id as a header.

NOTE 2: It is of crucial importance that the Application ID and Product ID are as short and compact as possible due to the minimisation of the transaction time between the Customer Media and the MAD. Hence, the number and size of the data elements have been limited.

2.7.3 Registrar

The Registrar registers the IFM specific data and is uniquely identified on a national level by its national standardisation body.

2.8 N

,

,

P

Entity Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 ComponentId Comp onent Owner Comp onent Generic Type Comp onent Serial Number Application TemplateId ApplicationID (implemented and initialised Application Template) Appli cation Owner Appli cation Generic Type Appli cation SubType Appli cation Retailer Com ponent Appli cation Seq uence Number SAM Num ber SAM Seq uence Number Product TemplateId ProductId (instance of a Product Template) Product Owner Product Generic Type Product Sub Type Product Retailer Com ponent Product Seq uence Number SAM Num ber SAM Seq uence Number SSSId SSS Owner SAM Generic Type SAM Serial Number

Table 1: Numbering scheme for entities in IFM systems

2.8.1 Organisation identification

Organisations are uniquely identified by a number within the IFM system. The number is given by the Registrar after having verified the organisation certification. The number is within the range

0….1.048.575 within each IFM system.

IFMOrganisation ::= BIT STRING (SIZE(20))

2.8.2 Components identification

Components, e.g. validators and ticketing machines, are uniquely identified by a number within the IFM system. The number is the concatenation of ComponentOwner, ComponentGenericType and ComponentSerialNumber.

ComponentOwner is any registered organisation within the IFM system, i.e. a number within 0….1.048.575. The ComponentGenericType is a number between 0….127 where the list of generic component types is kept by the Registrar. The Component owner adds a serial number,

ComponentSerialNumber with a value between 0….4.095.

ComponentId ::= SEQUENCE { componentOwner ComponentOwner, componentGenericType ComponentGenericType, componentSerialNumber ComponentSerialNumber } ComponentOwner ::= IFMOrganisation

ComponentGenericType ::= BIT STRING (SIZE(7))

ComponentSerialNumber ::= BIT STRING (SIZE(12))

EXAMPLE:

A validator may be uniquely identified by 356.45.789 where 356 is the organisation identity, e.g. a bus company, 45 is the component type, e.g. a validator with ISO 14443 Type A communication, and 789 is the serial number of the validator defined by the component owner.

2.8.3 Application Template identification

Application Templates are uniquely identified by a number which is the concatenation of ApplicationOwner, ApplicationGenericType and ApplicationSubType.

ApplicationOwner is any registered organisation within the IFM system, i.e. a number within

0……1.048.575. The ApplicationGenericType is a number between 0…127 where the list of generic application types is kept by the Registrar. The Application Owner may have his own set of application types which is added as an ApplicationSubType being a number between 0….127.

ApplicationTemplateId ::= SEQUENCE {

applicationOwner IFMOrganisation,

applicationGenericType ApplicationGenericType,

ApplicationSubType ApplicationSubType

}

ApplicationGenericType ::= BIT STRING (SIZE(7))

EXAMPLE:

An Application Template may be uniquely identified by 1089.4.17 where 1089 is the organisation identity, 4 is the generic application type and 17 is the application owner specific sub type of application.

2.8.4 Application identification

Applications are uniquely identified by a number which is the concatenation of ApplicationTemplate, ApplicationRetailer, Component and ApplicationSequenceNumber.

ApplicationRetailer is any registered organisation within the IFM system, i.e. a number within

0………1.048.575. The ApplicationSequenceNumber is date and time and is the current values as the MAD installs the application on the Customer Media.

The data elements given in the previous paragraph are sufficient to uniquely identify an application on the Customer Media (who issued, what type, which serial number (when)). However, for security reasons there is a need to stamp the application. Hence, for the application registration by the Registrar the SecuritySubSystemId is added to the application identity.

ApplicationId ::= SEQUENCE { applicationTemplateId ApplicationTemplateId, applicationRetailer ApplicationRetailer, componentId ComponentId, applicationSequenceNumber ApplicationSequenceNumber } ApplicationRetailer ::= IFMOrganisation ApplicationSequenceNumber ::= SEQUENCE { date DateCompact time TimeCompact }

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

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

EXAMPLE:

An application on the Customer Media may be uniquely identified by

1089.4.17.478.478.23.3457.20041130153406 where 1089 is the Application Owner, 4 is the

application generic type, 17 is the application sub type, 478 is the Application Retailer and component owner, 23 is the equipment type, 3457 is the equipment serial type and 20041130153406 is the sequence number (date and time, i.e. Nov 11, 2004, 15:34:06).

2.8.5 Product Template identification

Product Templates are uniquely identified by a number which is the concatenation of ProductOwner, ProductGenericType and ProductSubType.

ProductOwner is any registered organisation within the IFM system, i.e. a number within

0……1.048.575. The ProductGenericType is a number between 0…127 where the list of generic product types is kept by the Registrar. The Product Owner may have his own set of products types which is added as a ProductSubType being a number between 0….255.

ProductTemplateId ::= SEQUENCE {

productOwner IFMOrganisation,

productGenericType ProductGenericType, productSubType ProductSubType

}

ProductGenericType ::= BIT STRING (SIZE(7))

ProductSubType ::= BIT STRING (SIZE(8))

EXAMPLE:

A Product Template may be uniquely identified by 7789.15.102 where 7789 is the organisation identity, 15 is the generic product type and 102 is the product owner specific sub type of product.

2.8.6 Product identification

Products are uniquely identified by a number which is the concatenation of ProductTemplate, ProductRetailer, Component and ProductSequenceNumber.

ProductRetailer is any registered organisation within the IFM system, i.e. a number within

0………1.048.575. The ProductSequenceNumber is date and time and is the current value as the MAD installs the product on the Customer Media.

The data elements given in the previous paragraph are sufficient to uniquely identify a product on the Customer Media (who issued, what type, which serial number (when)). However, for security reasons there is a need to stamp the product. Hence, for the product registration by the Registrar the

SecuritySubSystemId is added to the product identity.

ProductId ::= SEQUENCE { productTemplateId ProductTemplateId, productRetailer ProductRetailer, componentId ComponentId, productSequenceNumber ProductSequenceNumber } ProductRetailer ::= IFMOrganisation ProductSequenceNumber ::= SEQUENCE { date DateCompact time TimeCompact

}

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

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

EXAMPLE:

A product on the Customer Media may be uniquely identified by

765.15.167.478.478.123.3214.20041224094534 where 765 is the Product Owner, 15 is the product generic type, 167 is the product sub type, 478 is the Product Retailer and Component owner, 123 is the equipment type, 3214 is the equipment serial type and 2004122409453406 is the sequence number (date and time, i.e. Dec 24, 2004, 09:45:34).

EXAMPLE:

Coded in bit format the previous ProductId example will be as in the table below:

Octet # Data element Bits in Octet Description

1 00000000 2 ProductOwner 00101111 1101 Organisation number 765 3 0001 ProductGenericType 111

Product generic type 15 4

10100 ProductSubType

111

Product sub type 167 5 00000 6 ProductRetailer 00000011 1011110 Organisation number 478 7 0 8 00000000 9 ComponentOwner 00111011 110 Organisation number 478 10 11110 ComponentGenericType 11

Component generic type 123 11

110010 ComponentSerialNumber

001110

Component serial number 3214 12 00 13 01110110 011000 Dec 24, 2004 14 ProductSequenceNumber 01

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. The number is the concatenation of SecuritySubSystemOwner, SecuritySubSystemGenericType and SecuritySubSystemSerialNumber.

SecuritySubSystemOwner is any registered organisation within the IFM system, i.e. a number within 0….1.048.575. The SecuritySubSystemGenericType is a number between 0….127 where the list of generic types is kept by the Registrar. The Registrar adds a serial number,

SecuritySubSystemSerialNumber with a value between 0….32.767.

SecuritySubSystemId ::= SEQUENCE { securitySubSystemOwner SecuritySubSystemOwner, securitySubSystemGenericType SecuritySubSystemGenericType, securitySubSystemSerialNumber SecuritySubSystemSerialNumber } SecuritySubSystemOwner ::= IFMOrganisation

SecuritySubSystemGenericType ::= BIT STRING (SIZE(7))

SecuritySubSystemSerialNumber ::= BIT STRING (SIZE(15))

EXAMPLE:

A SAM in a ticketing machine may be uniquely identified by 1489.87.21476 where 1489 is the

organisation identity, e.g. a public transport company, 87 is the type, e.g. a SIM card of a certain type, and 21476 is the serial number of the SIM card defined by the Registrar.

2.8.8 Generic ApplicationId coding

The ApplicationId may be used for diversification of security keys. Hence, the generic notation for the ApplicationId is given below.

Octet # Data element Bits in Octet Description

1 oooooooo

2 ApplicationOwner oooooooo

oooo

IFM Organisation number 0… 1.048.575 3 gggg 4 ApplicationGenericType ggg

IFM Application generic type 0….127

sssss ApplicationSubType

ss

Application sub type 0…127

5

rrrrrr

6 ApplicationRetailer rrrrrrrr

rrrrrr

IFM Organisation number 0… 1.048.575 7 oo 8 oooooooo 9 ComponentOwner oooooooo oo

IFM Organisation number 0… 1.048.575

10

gggggg ComponentGenericType

G

IFM Component generic type 0….127

11

sssssss ComponentSerialNumber

sssss

Component serial number 0….4.095

12

yyy

13 yyyymmmm

ddddd

Date in DateCompact format 14 hhh 15 hhmmmmmm 16 ApplicationSequence Number sssss

3 S

ECURITY

P

OLICY AND

R

EQUIREMENT

S

PECIFICATION

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

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

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

• The NORTIC specification shall enable different levels of security. These levels of security shall be defined as specific security profiles. The NORTIC specification shall be open to include new profiles or varieties of defined profiles in the future.

• The EFC transaction shall be protected against manipulation and fraud in such a manner that the recipient of the claim or a Trusted Third Party (TTP) may verify that the claim is justified/authentic (not mandatory).

• It shall be possible to trace any transaction back to its generation origin enabling the Customer to have the necessary information about the source of transaction, in case of any dispute.

3.1 NORTIC SECURITY ARCHITECTURE

The main motivation by defining the NORTIC Security Architecture is simply that its value supersedes possible financial drawbacks (such as financial costs related to implementation and procedures). It shall be noted that probability of an actual attack on the NORTIC system is currently not quantifiable nor is it possible to assess the severity by means of possible financial loss. This is not only related to the possible successful implementation of the security architecture, but is related to social factors:

• Possible accumulated level of gain if attacks are successful (i.e. loss for the system) • Frequency and accuracy of enforcement (level of control of TravelContracts) • Level of penalties when attacks are detected and linked to an attacker • Availability of resourceful attackers willing to commit attacks

The NORTIC Security Architecture includes the specification of

• Threat analysis, detailing the most probable threats to the ticketing system compliant to

NORTIC TravelContract specifications (NORTIC system) and the possible vulnerabilities that such a system might have.

• Security policy, specifying how the threats to the NORTIC system shall be handled in

proactive way.

• Security requirements, detailing how the security policy shall be realised in the NORTIC

system. For convenience two different security profiles are defined to provide the minimum set of security requirements enhancing the implementation of compliant systems to this specification.

Each system implementation (or certain system modules) may be certified based on their claimed compliance to this specification. However, it shall be emphasised that no test or any certification procedures are specified for fulfilling the requirements in this document.

Figure 5 Various processes in the synthesis of security architecture.

The scope of this specification is the threat analysis, security policy and security requirements.

3.2 THREAT AND VULNERABILITY ANALYSIS

The main motivation of threat and vulnerability analysis is to proactively minimise the financial risks associated with implementing and operating a ticketing system according to NORTIC Specifications. Threat and vulnerability analysis in this specification concerns an overall assessment of the most probable threats and the system’s vulnerability to these threats. This will enable the next step, being the definition of a security policy that shall countermeasure the threats.

Figure 6 The various stages and terminology in threat and vulnerability analysis.

Possible compromises resulting into loss of assets are dependent on that threats actually are realised as successful attacks (resulting into break of integrity and penetration into assets).

The threat analysis includes definition of possible attackers and threat targets (containing assets), and an assessment of the targets’ vulnerability towards methods that attackers apply to retrieve assets. Classification of attackers can be done as follows:

• Class 1: Clever outsiders

Might be skilled and have tools intended for attacks, but do have insufficient knowledge of the system and exploits known weakness of the system to meeting their objectives. • Class 2: Knowledgeable outsiders

Possess specialised technical education, experience, and specialised tools intended for attacks, and have potentially access to the whole system.

• Class 3: Funded organisations

Groups of outsiders possessing specialists, possibly also using class 2 attackers, with state of the art tools intended for attacks and sufficient amount of funding.

• Class 4: Insiders

Have got access to sensitive information, processes and modules that might be exploited by them or any other outsiders.

The classification of attackers (ranging from 1-4) is included to indicate that the higher the class, the higher is the likelihood that severities of the attack are high. On the other hand, the higher (lower) the class given, the lower (higher) number of people might be able to carry out the attack. This may used later to assess the likelihood whether threat results into an actual attack.

The Threat Targets are identical to the modules or interfaces between modules carrying assets within the NORTIC system. These are:

• TravelContract

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

• Electronic Messages within the system (Transaction/Payment Information, Settlement, Charge to Account)

The definition of Treat Objects/Assets that may be main objective for attacks is made by means of defining overall threat objectives. An initial assessment is done in the table below.

The table is sorted pr threat objective and pr attacker class to provide some initial indication of the probability and severity of various attack strategies.

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

Primary Threat Objective

Attack Strategy Likely Attacker Necessary attacker class

Sabotage of MAD Customers Class 1

Repudiation of Electronic Payment

Customers Class 1 Replay of Messages Customers Class 2 TravelContract

Masquerade Customers Class 2

Financial gain by evading payment and/or obtaining free service

Cloning of TravelContracts Customers Class 3, possibly also Class 4.

Financial gain by

reselling products Cloning of TravelContracts Customers Class 3, possibly also Class 4. Replay of Messages

Cloning of Messages Financial gain by

claiming refund from fraudulent

Transactions Repudiation of Messages

Service Operators Class 3 in combination with Class 4

As already indicated, the threat objectives cannot be successfully accomplished without proper attack strategies at hand. These strategies involve combination of computer-aided tools, skilled resources (even insiders) to become effective. In addition, the attacks focus on the vulnerabilities of the system. This includes:

• Modules (software, hardware, disk storage) and Interfaces between them • Personnel

• Routines for handling data

• Routines for access to sensitive areas (offices)

The attack strategies may be decomposed into classical security attacks methods as given in the below table:

Attack Strategy Primary Attack Methods Secondary Attack Methods

Repudiation Denial of used service None further

non operational state

Eavesdropping None further

Manipulation of data Alteration of HW and/or SW and/or application data. Product Masquerade

Disclosure of Sensitive

Information Theft of MAD

Message Replay Record and Replay Eavesdropping and timing attacks

Product Medium Segment

Tampering Theft of TravelContracts in Manufacturing, Distribution or Issuance

Insider Abuse such that valued information (secret keys) are disclosed.

Alteration of HW and/or SW Cloning of TravelContracts

Disclosure of Sensitive information

Theft of MAD to retrieve secret keys

Message Replay Eavesdropping and timing attacks

Insider Abuse such that valued information (secret keys) are disclosed.

Alteration of HW and/or SW and/or application data Cloning of Messages

Disclosure of Sensitive information

Theft of MAD to retrieve critical functions (secret keys)

3.3 S

P

The NORTIC System Security Policy addresses how the threats specified in section 3.2 shall be controlled taking into account aspects such as

• Protection of the Interests of the Public, i.e. Issue of Fairness and Privacy • Financial Loss detection and prevention

• System design constraints (i.e. cost, functionality and technology limitations with TravelContract)

3.3.1 Protections of the interests of the public

The public interests are founded not only on quantifiable financial aspects but also on human/cultural values. Some overall principles of public interests are formulated below:

• Quality of Service:

The NORTIC system shall be used as an instrument to ensure that national/local public transport service strategic goals are met.