inventory of generic system and security architectures...

to 83

This report is a result from the IFM Project - a project funded through the 7th EU Framework Program

Inventory of generic system and security architectures, interfaces and processes – Questionnaire

Deliverable 5.1 November 2010

to 83


For further information please contact:

Work package 5 leader Main authors

VDV-Kernapplikations GmbH & Co. KG

Dr. J. Lutgen

Phone +49 221 57979 162

Fax +49 221 57979 8162

E-mail: [email protected]

For further information on the IFM Project please contact:

Coordination Secretariat

ITSO Ltd.

Phone +44 121 634 3700

Fax +44 121 634 3737

E-mail: [email protected]

Visit the webpage www.ifm-project.eu

TÜV Rheinland Consulting GmbH

Phone +49 221 806 4165 Fax +49 221 806 3496 E-mail: [email protected]

to 83


List of abbreviations

AFC Automated Fare Collection

CALYPSO Electronic Ticketing Standard for (microprocessor) contactless Smartcard, designed by a group of European transit operators

CBO Central Back Office

CRL Certificate Revocation Lists

EFM Electronic Fare Management

EN European Norm

HOPS ITSO Back office system

HSM Cryptographic "Hardware Security Module“ it is the secure central element of the Security Management System that generates (and holds) the key pairs and certificates.

IFM Interoperable Fare Management

ISO International Organization of Standardization

ITSO Integrated Transport Smartcard Organisation; UK Standard for nationwide Interoperable Electronic Fare Management

MO mobile operators

PT public transport

OTLIS Consortium of Operators that Specify, Build and Operate the Interoperable Fare Collection System which manages the LisboaViva, 7 Colinas, Viva Viagem and Lisboa Card contactless cards (Lisbon wide Region)

PTO public transport operator

RKF Resekortsföreningen i Norden ekonomisk förening, from January 2007 it is Resekortet i Norden AB

TA Transport Authority

TO Transport operator

VDV-KA VDV Core Application, German Standard for nationwide Interoperable Electronic Fare Management

VDV-KA KG VDV-Kernapplikations GmbH & Co. KG

to 83


Contents

1. Introduction.......................................................................................................................5

2. Definitions and General Descriptions concerning the Questions .....................................7

3. Overview of Questions concerning the Use Cases in ISO 24014-1 ...............................11

3.1. Certification Use Cases ...........................................................................................12

3.2. Registration Use Cases ...........................................................................................13

3.3. Application Management Use Cases.......................................................................13

3.4. Product Management Use Cases ............................................................................14

3.5. Security Use Cases .................................................................................................15

4. Answers of the Schemes to the Questions regarding the Use Cases in ISO 24014-1...17

5. Conclusions....................................................................................................................83

to 83


1. Introduction In this work package we continue the investigation started in the IFM project of a common understanding of interoperability between fare management systems and of possible approaches to making this interoperability work.

To arrive at a common and viable approach to interoperability the expectations of the different participants must be reconciled. In the view of customers, the important aspects of interoperability are

convenience of use, not only concerning the possibility of employing a single technical media, but, perhaps more importantly, with regard to receiving integrated services from retailers (one face to the customer, no need to close several contracts, no need to understand different tariff systems in detail, etc.),

privacy issues and

transparency and accountability (in the sense of being able to trust the system).

In the view of operators and retailers important requirements of interoperability are

consolidation of contracts, applications, sales channels and technical infrastructure (to limit and possibly reduce complexity and costs),

modularisation due to the employment of standard interfaces and the establishment of a market for products and services,

protection of business processes and investments,

retaining autonomy, transparency and accountability.

These complementary expectations lead to constraints on possible viable solutions.

The following Figure 1 sketches a framework for considering the evolution toward increasing levels of interoperability.

At the present there are several different schemes for fare management systems in operation that are not interoperable with each other in any sense of the word.

A first step could be the conception and first implementations of a common interoperable nucleus, a “bridge solution”, as a supplement to the individual standards.

In a next step, the bridge solution could become integrated in the different standards (schemes) themselves, so that all systems operating according to the different standards will include a corresponding interoperable nucleus.

In a final stage the further evolution of the different standards would be guided in part by optimisation, the finding of more common ground and the elimination of redundancies so that a consolidation and at least partial convergence of the standards would take place, resulting in a larger common nucleus and the increased realisation of advantages for operators and retailers.

The goal of this work package (WP5) is to look at potentials for and barriers to the cooperation of systems based on different standards (schemes) at all levels, both organisational and technical, and to collect information needed for a first exploration of possible common goals for a cooperation, i.e. to determine how a bridge could be built so that the different roads may meet there in the future.

to 83


Figure 1 : Bridge for Interoperability

To this end this document contains a series of questions (see Chapter 3) addressed to and to be answered by experts from the schemes Calypso, ITSO and Core Application. In addition, participants in the forum from other countries may give their input.

In work package 4 it was also found that all of these systems have specific national standards for IFM/EFM which can be analysed within the framework of the common IFM System Architecture described in the standard ISO EN 24014-1 (see Figure 2).

For this reason the approach in this questionnaire will be to examine more closely, for each of these systems, how the use cases defined in the Standard ISO EN 24014-1 are realised.

The answers of the schemes to these questions are compiled in the table in Chapter 4.

to 83


Figure 2 : The two IFM domains (operational and management entities)

2. Definitions and General Descriptions concerning the Questions The goal is to collect fundamental information concerning

organisational,

technical and

security

aspects of the realisations of the Use Cases from the standard ISO EN 24014-1.

The questions regarding organisational aspects are subdivided into

a brief description of organisational processes,

statements about the existence and content of a relevant set of rules and

statements about the existence and content of relevant framework agreements

involved in the Use Cases.

The questions regarding technical aspects are subdivided into

statements about the existence and content of standards resp. specifications for data elements used for communication and data storage on the relevant interfaces and

a brief description of the technical communication processes on the interfaces.

The questions about the security aspects are intended to ascertain which security objectives are relevant for the Use Cases in the view of each scheme and what organisational and technical security measures are implemented or planned in order to reach these security objectives.

In general, security objectives can be divided into the following three categories:

to 83


fault tolerance and fail safe properties of systems/services,

availability of systems/services (prevention of unauthorised withholding of systems/services) and

information security.

The following table gives an exhaustive list of basic information security objectives with brief descriptions1.

Information security objectives

Brief descriptions

Privacy or confidentiality

Keeping information secret from all but those who are authorized to see it.

Data integrity Ensuring information has not been altered by unauthorized or unknown means.

Entity authentication or identification

Corroboration of the identity of an entity (e.g., a person, a computer terminal, a credit card, etc.).

Message authentication

Corroborating the source of information; also known as data origin authentication.

Signature A means to bind information to an entity.

Authorization Conveyance, to another entity, of official sanction to do or be something.

Validation A means to provide timeliness of authorization to use or manipulate information or resources.

Access control Restricting access to resources to privileged entities.

Certification Endorsement of information by a trusted entity.

Time-stamping Recording the time of creation or existence of information.

Witnessing Verifying the creation or existence of information by an entity other than the creator.

Receipt Acknowledgement that information has been received.

Confirmation Acknowledgement that services have been provided.

Ownership A means to provide an entity with the legal right to use or transfer a resource to others.

Anonymity Concealing the identity of an entity involved in some process.

Non-repudiation Preventing the denial of previous commitments or actions.

Revocation Retraction of certification or authorization.

Table 1 : General information security objectives

Following the standard ISO EN 24014-1 the following three major objective categories tailored to the setting of fare management systems can be assembled from the constituent security objectives summarised above.

I) Protection of applications, products, templates (for applications and products), usage data, security keys, action and security lists:

o confidentiality of secret information, e.g. secret keys,

1 Taken from “Handbook of Applied Cryptography”, by A. Menezes, P. van Oorschot, and S. Vanstone, CRC Press, 1996.

to 83


o entity authentication or identification,

o integrity und authenticity of data,

o message authentication and signature,

o authorisation,

o access control,

o certification,

o time-stamping,

o receipt,

o confirmation,

o ownership,

o non-repudiation and

o revocation.

II) Protection of customer privacy:

o confidentiality,

o anonymity

III) Protection of system functionality:

o availability,

o fault tolerance and

o fail safe.

In the first investigation considered here the focus will be on the first two categories.

On the basis of these general categories the following set of subordinate security objectives from the viewpoints of the various roles in the role model from ISO EN 24014-1 can be formulated2. These will be used to structure the questions appearing in the next chapter.

Short designation of security objective

Roles for which the objective is relevant

Description

Protection of personal information

Customer,

Product and application retailer,

Operator,

Collecting and Forwarding

Certain personal information of customers may be stored in the user media or in other parts of the fare management system.

The misuse, manipulation or unauthorised circulation of such information must be prevented.

Personal data collected by retailers must be handled confidentially and may only be used for the agreed purposes.

Non-anonymous, personal information collected in connection with the use of services may only be used by retailers and operators with the customers consent. Only those specific data needed for the declared purpose and for a specified time may be collected and stored.

In particular, the unauthorised collection of usage data for the

2 Based on “Technische Richtlinie für den sicheren RFID-Einsatz – Teildokument 1: Einsatzgebiet eTicketing im öffentlichen Personenverkehr”, Bundesamt für Sicherheit in der Informationstechnik.

to 83


purpose of tracking personal movement must be prevented.

Relevant basic information security objectives: confidentiality, anonymity

Protection of applications and application templates

Application owner,

Application retailer

Manipulation of the application during transport to the user media and unauthorised use must be prevented, i.e. the integrity and authenticity of the application data (identification of the source) must be achieved during transport between the application owner and the user media and the application owner must be able to authorise other entities to use the application. It must be possible to revoke the application.

To prevent unauthorised copying of the application and to protect possibly security relevant aspects of the implementation the confidentiality of the application data should be protected during transport to the user media.

An application must be uniquely identifiable during its entire life cycle.

Corruption or compromise of the application resulting from a multi-application / multi-issuer environment in the user media must be prevented.

Relevant basic information security objectives: confidentiality, entity authentication, integrity und authenticity of data, authorisation, access control, ownership, revocation.

Protection of products and product templates

Customer,

Product retailer,

Operator,

Product owner

Counterfeiting and unauthorised issuance, use and manipulation of products must be prevented. Otherwise serious commercial losses for product retailers, operators or product owners are possible.

It must be possible to revoke products. A product must be uniquely identifiable during its entire life cycle.

Unauthorised manipulation of products can also lead to damages for customers that are however likely to be limited, since the service can usually nevertheless be accessed assuming the customer can show that a valid product was purchased.

Relevant basic information security objectives: entity authentication, integrity und authenticity of data, authorisation, ownership, revocation.

Protection of usage data

Customer,

Product retailer,

Operator,

Product owner,

Collection and Forwarding

The manipulation, forgery, unrecognised loss or replay of usage data (concerning the issuance of products or the use of post-paid products or other services) must be prevented. Otherwise serious commercial losses for customers, product retailers, operators or product owners are possible.

The integrity, authenticity and uniqueness of the data must be guaranteed.

Relevant basic information security objectives: integrity und authenticity of data, confirmation, non-repudiation.

Protection of secret keys

Security Manager,

Application owner,

Product owner,

Product retailer,

Application retailer,

The confidentiality and integrity of secret key data must be protected during storage and transport. Key owners must be able to authorise other entities to use keys and to revoke these authorisations. The source of key data must be authenticated during transport and only the intended recipient shall be able to access or use the key data.

The intended access rights for the usage of secret keys must be

to 83


Service operator realised by all components containing them, e.g. user media.

Relevant basic information security objectives: confidentiality entity authentication, integrity und authenticity of data, authorisation, access control, ownership, revocation.

Protection of security lists

Security manager

Application owner,

Product owner,

Product retailer,


Service operator

The manipulation, forgery and replay of security lists must be prevented. Furthermore, the availability of security lists and their receipt by the intended addressees must be assured. Otherwise it may be possible to prevent the timely revocation of compromised or invalid components, applications, products or keys or, in the case of such a failure, to deny having received the list.

The lists must be unique and include information on its time of creation. The source of the list must be identified and the contents its must be bound to the source.

Relevant basic information security objectives: entity identification, integrity und authenticity of data, signature, time-stamping, receipt, non-repudiation

Reliable accounting and billing

Customer,


Service operator,

Product and application owner

Billing data must be transparent and reliable.

In usage data relevant for billing to the customer the time, place and service operator must be recognisable to the customer.

The correct allocation of revenues from the sale of applications and products to the product owner and the service operator according to the services delivered must be guaranteed.

3. Overview of Questions concerning the Use Cases in ISO 24014-1 The following sections list the Use Cases from the Standard ISO 24014-1 according to groups.

For each Use Case the recipients of the questionnaire will be asked to indicate whether the Use Case is realised in their scheme and, if so, to provide information on

• Organisational aspects,

• Technical aspects and

• Security aspects.

With regard to the organisational aspects the recipients should briefly describe the organisational processes involved in the realisation of the Use Case including the relevant Set of Rules and framework agreements.

With regard to the technical aspects the recipients should indicate whether there are standards or specifications describing the data elements resp. protocols and processes for communication.

With regard to the security aspects the recipients are asked to describe briefly the technical and organisational security measures that are planned and / or implemented to assure the reaching of each of the relevant Security Goals. These Goals are specific to the individual Use Cases and therefore are listed explicitly under each of the Use Cases below.

to 83


3.1. Certification Use Cases Use Case: Certification of Organisations The relevant Security Goals (role specific) are the following.

Security Goal Relevant roles

Protection of personal information Customer,


Operator,

Collecting and Forwarding


Application owner,

Application retailer


Customer,

Product retailer,

Operator,

Product owner

Protection of usage data Customer,

Product retailer,

Operator,

Product owner,

Collection and Forwarding

Protection of secret keys Security Manager,

Application owner,

Product owner,

Product retailer,


Service operator

Protection of security lists Security manager

Application owner,

Product owner,

Product retailer,


Service operator

Reliable accounting and billing Customer,


Service operator,

Product and application owner

Use Case: Certification of Components Use Case: Certification of Application Specifications and Templates

to 83


Use Case: Certification of Product Specifications and Templates

3.2. Registration Use Cases Use Case: Registration of Organisations Use Case: Registration of Components Use Case: Registration of Application templates Use Case: Registration of Applications Use Case: Registration of Product templates Use Case: Registration of Products

3.3. Application Management Use Cases Use Case: Dissemination of Application Templates The relevant Security Goal(s) are the following:

• Protection of applications and application templates

Use Case: Acquisition of Applications The relevant Security Goal(s) are the following:


• Protection of secret keys

• Reliable accounting and billing

Use Case: Regular Termination of Application Template The relevant Security Goal(s) are the following:


Use Case: Forced Termination of Application Templates The relevant Security Goal(s) are the following:


• Protection of security lists

Use Case: Regular Termination of Application The relevant Security Goal(s) are the following:

• Protection of personal information



Use Case: Forced Termination of Application The relevant Security Goal(s) are the following:




to 83



3.4. Product Management Use Cases Use Case: Dissemination of Product Template The relevant Security Goal(s) are the following:

• Protection of products and product templates

Use Case: Regular Termination of Product Template The relevant Security Goal(s) are the following:


Use Case: Forced Termination of Product Template The relevant Security Goal(s) are the following:



Use Case: Management of Action Lists The relevant Security Goal(s) are the following:




Use Case: Acquisition of Product The relevant Security Goal(s) are the following:





Use Case: Modification of Product Parameters The relevant Security Goal(s) are the following:




Use Case: Regular Termination of Product The relevant Security Goal(s) are the following:




Use Case: Forced Termination of Product The relevant Security Goal(s) are the following:


to 83





Use Case: Use and Inspection of Product The relevant Security Goal(s) are the following:



• Protection of usage data


Use Cases: Collection and Forwarding of Data The relevant Security Goal(s) are the following:




Use Case: Generation and Distribution of Clearing Reports The relevant Security Goal(s) are the following:




3.5. Security Use Cases Use Case: Monitoring of IFM Processes and IFM Data Life Cycle The relevant Security Goal(s) are the following:


Use Case: Management of IFM Security Keys The relevant Security Goal(s) are the following:


Use Case: Provision of Security Lists The relevant Security Goal(s) are the following:


Use Case: Updating Security List Data The relevant Security Goal(s) are the following:


Use Case: Add or remove a component to/from security list The relevant Security Goal(s) are the following:


Use Case: Add or remove an application template to/from security list

to 83


The relevant Security Goal(s) are the following:


Use Case: Add or remove an application to/from security list The relevant Security Goal(s) are the following:


Use Case: Add or remove a product template to/from security list The relevant Security Goal(s) are the following:


Use Case: Add or remove a product to/from security list The relevant Security Goal(s) are the following:


to 83


4. Answers of the Schemes to the Questions regarding the Use Cases in ISO 24014-1

German Core Application ITSO Calypso French Implementation

6. Use Cases from ISO 24014‐1

6.1 Certification Use Cases

6.1.1 Certification of Organisations Organisational Aspects Brief description of organisational processes

Organisations intending to take part in the core application IFM must go through a process of certification after which they are assigned an Organisation‐ID and corresponding rights to take part in the security infrastructure. For transport operators this requires the signing of standard "participation agreements" (Teilnahmeverträge) with the Registrar (VDV KA KG) according to the roles they will be playing in the IFM. For suppliers and service operators this requires the signing of standard agreements concerning the use of the system (Nutzungsvereinbarungen) with the Registrar (VDV KA KG). These usage agreements are generally augmented by descriptions of the specific security measures applied by the suppliers in their processes which are worked out jointly with and have to be approved by the Security Manager (VDV KA KG). An audit process based on these descriptions is to be implemented.

n.a. N.A., no requirement exist about organisations.

No certification of organisations

to 83



6. Use Cases from ISO 24014‐1 Set of Rules The relevant rules are contained in the participation and usage

agreements. There are rules relevant to this use case. There is an ITSO Licensed Membership Document available under http://www.itso.org.uk/content/documents/ITSO_Ltd_Membership_Agreement_2008‐9_18page.pdf

N.A., no set of rules exist about organisations.

Relevant framework agreements

In the next step certified organisations intending to use the security infrastructure must sign a set of standard contracts with the security service operator employed by the Security Manager (VDV KA KG) in order to gain access to the required services.

There are framework agreements relevant to this use case. The ITSO Licensed Operator Agreement can be found under http://www.itso.org.uk/content/documents/ITSO‐OpLicence‐EGM%2027.03.2007%20[Final%20Revision].pdf

Technical Aspects

to 83



6. Use Cases from ISO 24014‐1 Standards or specifications for data elements, protocols and processes for communication

The processes are based on the exchange of standard documents (agreements, forms) signed in paper form or alternatively in electronic form with qualified digital signatures according to the German signature law (SigG). In conjunction with the signing of the contracts for one or more of the parts PKI, Key Management resp. SAMs of the security infrastructure certified organisations must identify themselves by submitting a notarised current excerpt from the German commercial register. All forms are submitted authentically using the "PostIdent" procedure (in Germany).

The data elements comprise the POST‐HOPS interface and the Message sets that are used to communicate between them. This is not covered by a protocol as these messages can be internal to an organisation. however for HOPS‐HOPS they are set and we provide a VPN with certificates. See ITSO Spec parts 4,6 and 9

In France, organisations are similar from region to region, as best practises.

6.1.2 Certification of Components

Organisational Aspects

to 83



6. Use Cases from ISO 24014‐1 Brief description of organisational processes

Currently the IFM Manager (VDV KA KG) conducts certifications of SAMs and User Media and issues reports and certificates. Terminals are evaluated in regional projects on the basis of requirements formulated in the project tender procedure. In the future at least one test house, but possibly more, will be accredited by the IFM Manager for the certification of User Media, SAMs and the various types of terminals.

ITSO has an accredited Test House which produces a Report of Testing based upon a standard Test Setup , Test Tool and set of Test Scripts.

All IFM systems in France are based on micro‐processor based components for security reasons and on open specifications for multi‐suppliers industrial policy. Only Calypso applications answer these two requirements. Compliance to the international standards and to Calypso is requested in all tenders issued from the different transport operators or authorities In the Ile de France region, a certification process has been set up to test the cards comply to a regional spec (RCTIF référentiel commun d'interopérabilité) that gathers all these specs,

to 83



6. Use Cases from ISO 24014‐1 Set of Rules According to the participation and usage contracts already

mentioned under 6.1.1 participating organisations are only allowed to use components certified by the IFM Manager (VDV KA KG) in their core application systems. Certifications are based on the successful passing of test procedures documented in the standard and implemented by a test suite as well as additional requirements. For user media an evaluation according to Common Criteria to the level EAL4+ based on the protection profile BSI‐PP0002 and a Passport eConformity Test with standardised core application extensions are required. For the SAM evaluations according to Common Criteria to the level EAL5+ based on the protection profile BSI‐PP0002 as well as further evaluations of operating system and applications are required.

Yes, there are corresponding rules. The details of the basic process are described in http://www.itso.org.uk/content/documents/ITSO_ICTm02v1.4_C&T_Manual_.pdf. There is also a self testing option which is described in http://itso.org.uk/content/documents/ITSO_self_testing_process_v1‐1_Jul07.pdf

N.A.


Currently, no additional agreements are needed. In the future there will be standard contracts between the suppliers and the test house(s).

The Certification and Testing Manual contains details of the relevant contract with the Test House.

N.A.

Technical Aspects

to 83




The processes are based on the exchange of standard documents (agreements, forms) signed in paper form or alternatively in electronic form with qualified digital signatures according to the German signature law (SigG).

See part 9 of ITSO Spec The Calypso specifcations are freely available on the Calypso Netwrok Association web site. Some sensitive specifcation regarding security and SAMs are only availble to licenced CNA members. They are based on ISO 14 443 , 7816‐3 / 7816 ‐4 communications,

All AFC systems in France are based on ISO 14 443 , 7816‐3 / 7816 ‐4 communications

6.1.3 Certification of Application Specifications and Templates


to 83




At any given time there is only one valid application specification which is part of the documentation managed and supplied by the IFM Manager. So the certification of the specification is implicit.

The Licensed Operator applies to the Registrar to have keys for the Application.

Calypso networks association certifies the external specs of cards are compliant to Calypso specs,

No certification

Set of Rules According to the participation and usage agreements only certified components may be used or issued by participating organisations. Part of the certification process is the verification that the implementations of applications are correct according to the current specification.

Subject of the License Agreement.

N.A.


No additional agreements are needed. ITSO License covers Application issuing

N.A.

Technical Aspects

to 83




Standards or specifications for data elements, protocols and processes for communication

Current specification are provided via download from a website following a short registration and payment of fees.

Covered essentially by Part 2 of the Specification.

All AFC systems in France are based on EN 1545, The file structures and data model have been defined in the INTERCODE national standard, Each regional implemention instantiates this standard with the regional description of the networks and fares for example.

6.1.4 Certification of Product Specifications and Templates


to 83




In the case of interoperable products in the core application IFM, specifications must be submitted to and certified by the Registrar (VDV KA KG). Only organisations that are certified and registered in the core application IFM as Product Owners may submit such specifications for approval.

A Licensed Operator must apply to the Registrar for keys.

N.A. Regional test rooms verify the equipments and cards and softwares are compatible.

Set of Rules The participation agreement for Product Owners and the Data model specification provide the corresponding regulations for interoperable products.

Subject of the License Agreement.

N.A.


No additional agreements are needed. ITSO License covers Application issuing

N.A.

Technical Aspects



Covered essentially by part 5 of the ITSO Specification.

N.A same as above

6.2 Registration Use Cases

6.2.1 Registration of Organisations

to 83





Brief description of organisational processes

The registration of an organisation, carried out by VDV KA KG as Registrar, entails the assignment of an Organisation‐ID and corresponding rights to an organisation and follows the certification procedure as described under 6.1.1.

The Application is managed by the Registrar.

transport authorities are registered in a national standard The other entities are registered at regional level,

Set of Rules Relevant rules are those connected with the certification. The relevant rules are contained in the ITSO Operator License.

the national standard is managed by the French transport organisation CERTU, the regional entities are registered in two regional documents, one is functionnal, the other one tehnical.

to 83



6. Use Cases from ISO 24014‐1 Relevant framework agreements

No additional agreements are needed. Part of the ITSO Operator License.

Multi lateral agreements exist at regional or local level between Transport Authorities for enabling application interoperability. They are called "Charte d'interoperabilité" ‐ (Interoperability charter).

Technical Aspects



Covered essentially by part 6 of the ITSO Specification.

ID for authorities is provided according to a geographical arborescence.

6.2.2 Registration of Components


to 83




The Registrar and Security Manager require that the components SAM and User Medium as well as Certificates be registered during production. In the case of the SAM each physical component contains only one application and the Security Manager receives production reports from the security service provider on the SAM applications produced. In the case of user media the issuers are required to register the identification of the physical component in connection with the issued applications. The Security Manager generally only receives reports from the issuers on the applications issued (Application‐ID etc.).

Components must be certified before a Licensed Operator may use them.

For plastic serial, a range of number is allocated to each card manufacturer.

the identification of each type of cards is defined by Intercode

Set of Rules Participation and usage agreements set down rules for issuance of media by transport operators resp. service providers and suppliers (e.g. concerning reporting of Application‐IDs and other information).

The relevant rules are contained in the ITSO Operator License.

see above.


Framework agreements between the Security Manager and the security service provider describe the services to be provided and the conditions for their provision. These services, e.g. the PKI, are needed during issuance of all certificates; in particular, for user media and SAMs, and so can be used to control the issuance of applications

The ITSO License sets out how operators will interact.

No, predefiend allotment.

Technical Aspects

to 83



6. Use Cases from ISO 24014‐1 Standards or specifications for data elements, protocols an processes for communication

The interfaces to the security infrastructure needed during issuance processes are contained in the standard documentation provided by the Security Manager to participating organisations. These specifications provide for strong end‐to‐end encryption of communications and dynamic authentication of users. Access rights to the security infrastructure are administered in the back office of the security infrastructure and can be revoked by the Security Manager at any time. The certificate requests needed for issuance automatically lead to a registration of basic component data (identification as well as begin and end of validity) and their status (valid, revoked) in the security infrastructure (certificate directory).

ITSO provides a VPN but Operators can use proprietary communications.

Yes, see above. For data encoding each used structure is identified by an ID defined by Intercode.

6.2.3 Registration of Application Template


to 83




Comment: In the core application the application template is the actual program code or applet implemented by a supplier according to the specifications and provided for loading onto user media. These are subject to a certification which is part of the component certification above, although it can also have a "stand alone" certification for a whole range of physical media. Such certified "application templates" are registered by the Registrar according to the relevant specification version as well as a unique software version defined by the supplier.

Licensed Operator requests keys from Registrar

Calypso Networks Association directly drives the evolutions of the Calypso Specifications.

Set of Rules Participation and usage agreements restrict the employment of application templates to certified and registered application templates.

The relevant rules are contained in the License agreement.

work packages, work groups and ballot.


No additional agreements are needed. The specifications describes the details and the License agreement requires Operators to follow them.

Yes

Technical Aspects



ITSO provides communications but this is not compulsory.

Yes, Calypso specification rev 02 rev 3.1

to 83




6.2.4 Registration of Application



Comment: In the core application the "application" is a specific instance of an application template (code) uniquely identifiable by an Application‐ID and loaded onto a medium. See the description under 6.2.2.

A Licensed Operator must apply to the Registrar for permission.

Each application is uniquely identified by a Calypso Serial Number. The Calypso SN is provided by the CPP SAM.

Interoperable keys are regional

Set of Rules See the description under 6.2.2. The relevant rules are part of the License agreement.

No, predefiend allotment.

Regional set of rules define the rules to keep the keys safely and operate the processes for distributing them.


See the description under 6.2.2. License has framework; actual application forms are on the web.

suppliers of cards and readers must be Calypso licensed.

Technical Aspects

Standards or specifications for data elements, protocols and processes for

See the description under 6.2.2. The ITSO Specifications sets data elements and communication to the media.

Yes, Calypso SAM requirements. According Calypso spec, different

to 83



6. Use Cases from ISO 24014‐1 communication SAMs are used.

There is one SAM per function: ‐ CPP SAM for application issuing‐ CL SAM for application intialisation ‐ CP SAM for appli perso ‐ CV SAM for product validationAddtionally there are SAM for configuring the SAMs listed above:‐ SPP SAM for pre‐personalizing the SAMs ‐ SP SAM for personalizing SAMs ‐ SL SAM for loading keys in SAMs

to 83




6.2.5 Registration of Product Template



In the case of interoperable products in the core application IFM, following their certification (see 6.1.4) by the IFM Manager, they are assigned unique Product‐IDs by the Registrar. Local, non‐interoperable products can be defined and registered by Product Owners themselves within their Organisation‐ID Domains.


Product data structure and product data coding are specified by Intercode rel. 1 & 2 standards. The definition of local or regional product is done by assigning a dedicated product ID and defining the associated data dictionary. For interoperable products, product ID and data dictionary must be shared between the different Product Owners.

to 83



6. Use Cases from ISO 24014‐1 Set of Rules The participation agreement for Product Owners and the Data

model specification provide the corresponding regulations for interoperable products.

The relevant rules are part of the License agreement.

Intercode standard complemented with the Product data dictionnary provides the necessary set of rules for ensuring product interoperability.


No additional agreements are needed. License has framework. The "Interoperability Charter" usually list the products that must be interoperable between the parties.

Technical Aspects

Standards or specifications for data elements, protocols an processes for communication


Set in the ITSO Specification part 2.

Based on Intercode standards

6.2.6 Registration of Product


to 83




Retailers are responsible for providing Product Owners with reports on the issuance of their products. The IFM Manager is not involved directly.


in the regional tehnical agreement

Set of Rules The participation agreement for Retailers provide the corresponding regulations for all products.



No additional agreements are needed. License has framework.

Technical Aspects


Products can only be issued to user media using SAMs equipped with the appropriate keys. The SAM is used to supply the user medium with the role and product specific keys. These are used in turn by the user medium to generate secured, unique transactions regarding the issuance of the product which are forwarded to the Product Owner. The SAM maintains internal counters concerning the issuance of products.

Set in the ITSO Specification part 2.

instantiation of INTERCODE

6.3 Application Management Use Cases

6.3.1 Dissemination of Application

to 83



6. Use Cases from ISO 24014‐1 Template



The Application Owner and the Application Retailer agree on conditions for the provision of application templates.

The Registrar distributes keys.

The application production process remains under the control of the Applicaiton Owner which controls the distribution of production SAM needed for disseminating applications from a given application template.

The Application Owner and the Application Retailer agree on conditions for the provision of application templates.

to 83



6. Use Cases from ISO 24014‐1 Set of Rules The provision of application templates generally is subject to the

conditions of the participation agreements for Retailers and the usage agreements for suppliers and service providers set out by the IFM Manager. Accordingly, only application templates certified and registered by the IFM Manager may be disseminated by Application Retailers. Essential aspects of the technical process of dissemination are governed by the usage agreement, which is necessary in order to be able to use the PKI to initialise applications.


Local rules are part of the Interoperability Charter. They define the procedures to issue applications and SAMs


No additional agreements are needed. License has framework. Commercial agreement between Application Owner and Application Retailers

Technical Aspects


The interfaces to the PKI and Key management systems for obtaining certificates and loading application keys (using the SAM) are defined in the specification documents for PKI, Key management and SAM.

ITSO Specifications part 2 and 5.

Calypso SAM requirements and Calypso Application Downloading

key management is highly secured

Security Aspects

to 83



6. Use Cases from ISO 24014‐1 Protection of applications and application templates

Processes for loading of code and generation of RSA key pairs are subject to the usage agreement with the Security Manager; in particular, the protection of the confidentiality of the private keys and the integrity of the application code. The authenticity and the confidentiality of the certificate and application key loading processes are part of the core application specifications and are implemented in the security infrastructure of the core application.

All applications are encoded by an ISAM which uses keys distributed by the ITSO Registrar using the ITSO Security Management Service, in turn managed by the Security Manager.

CPP SAM dedicated for issuing product are used to create application instances.

6.3.2 Acquisition of Application



Application Retailers are responsible for providing the Application Owner and the Security Manager with reports on the issuance of applications.

The Retailer requests permission from Owner; owner instructs Registrar to distribute keys to this Registrar.

Application Retailer intiates application

Set of Rules

The participation agreement for Retailers provides the corresponding regulations.

ITSO License Local rules or part of Interoperability Charter.


No additional agreements are needed. ITSO License CNA Licence

Technical Aspects

to 83




Applications can only be issued to user media using SAMs equipped with the appropriate keys. The SAM is used to supply the user medium with the role and product specific keys. These are used in turn by the user medium to generate secured, unique transactions regarding the issuance of the application which are forwarded to the Security Manager and Application Retailer. The SAM maintains internal counters concerning the issuance of products.

ITSO Specification part 3 Calypso Perso SAM are used to intiate application. For the future, for non preloaded application, Calypso Application Downloading specifications are already available.

Security Aspects


See the description under 6.3.1. The issuance procedure is closed by the generation of an issuance transaction between the application on the user medium and an authorised SAM.

All data are encoded by an ISAM which uses keys distributed by the ITSO Registrar using the ITSO Security Management Service, in turn managed by the Security Management.

Applications can only be initiated using a Perso SAM. Counters can be used to monitor the number of applications one SAM can initiate.

to 83



6. Use Cases from ISO 24014‐1 Protection of secret keys

Master keys are only present in a secured offline system in the Trust Center used by the security infrastructure and in SAMs. Derived keys are present in the user media. The distribution of master keys from the key management system to a SAM (using a SAM specific end‐to‐end encryption and signature) can only be triggered by the key owner who must authenticate himself for this purpose. The keys themselves are not known to any participants including the key owner unless the key owner requests the export of a key from the key management system (in which case it will only be known to the key owner). Derived keys are generated in SAMs and distributed to user media in a secure end‐to‐end communication using a certificate based authentication with session key agreement.

Key pairs are stored in Security Management Service and distributed by the Registrar to ISAMs registered by Licensed Operators.

Application keys are diversified from a SAM. SAM to media exchanges are protected thanks to a session key based on a media challenge. The Application keys are unique to a media and cannot be used on another media.

see above


Authentic transactions are generated between User Medium and SAM during the issuance procedure which are delivered to the Security Manager and can be verified.

All transactions are loss‐less (i.e. not deleted until acknowledged securely) and ultimately held for 16 months by owner of data. ITSO is not involved in billing.

Calypso is not involved in billing.

no automatic clearing at this stage,

6.3.3 Regular Termination of Application Template

to 83






In case an application template is no longer to be used for loading applications onto user media, the Application Owner will inform the relevant Retailers and the Security Manager of the termination of this template. The termination of instances of a certain application template version already in the field is covered by 6.3.5.

The owner requests the Registrar to withdraw keys which are then revoked through the Security Management Service to each ISAM holding that key.

not envisaged,

Set of Rules Relevant rules for the Retailers are set in the participation agreement.

Set in the License agreement.


No additional agreements are needed. ITSO License

Technical Aspects


Direct communication with organisations authorised by the Application Owner to load and initialise applications on his behalf.

ITSO Spec part 4

Security Aspects

to 83



6. Use Cases from ISO 24014‐1 Protection of applications and application templates

The continued distribution of terminated application templates is to be prevented. The Application Owner and the Security Manager can control the implementation of the change by inspecting issuance transactions. It may or may not be necessary to terminate instances of the application template already in the field. If necessary, it is done according to 6.3.5.

All applications are encoded by an ISAM which uses keys distributed by the ITSO Registrar using the ITSO Security Management Service, in turn managed by the Security Manage; process is reversed to remove keys.

6.3.4 Forced Termination of Application Template



If necessary, the IFM Manager can terminate a specific application template and revoke its certification. The IFM Manager will inform the relevant Application Owners who will then inform the relevant Application Retailers. The termination of instances of a certain application template version already in the field is covered by 6.3.6.

The Licensed Operator writes a Hot List and this is distributed HOPS‐HOPS. Action Lists can be used to kill product instances, applications or media.

not envisaged,

Set of Rules Relevant rules for the Retailers are set in the participation agreement.

ITSO License agreement.

to 83




No additional agreements are needed. ITSO License agreement.

Technical Aspects


Direct communication with Application Owners. ITSO Spec part 4

Security Aspects


The continued distribution of terminated application templates is to be prevented. The possibility of terminating (or revoking) an application template is an essential part of the security objective "protection of applications and application templates". The Security Manager can control the implementation of the change by inspecting issuance transactions. It may or may not be necessary to terminate instances of the application template already in the field. If necessary, it is done according to 6.3.6.

Applications and templates are protected by signature by the ISAM.


Not relevant in this case. All Hot Lists and Action Lists are encoded by the ISAM which uses keys distributed by the ITSO Registrar.

6.3.5 Regular Termination of

to 83



6. Use Cases from ISO 24014‐1 Application



The customer can submit a termination request to the Application Retailer who can perform the termination and inform the Application Owner.

All keys are set with start and end dates.

Application is not desinstalled but can be blocked and the Calypso SN added to a black list.

Currently only one application template exists per medium. Regular termination is the same date for application and medium,

Set of Rules Participation agreement for Retailers. ITSO License Local rules or part of Interoperability Charter. The customer can submit a termination request to the Application Retailer who can perform the termination and inform the Application Owner.


Not relevant in this case. ITSO License

Technical Aspects

to 83




The processes are defined in the Interface specification of the core application. The communication between customer and Application Retailer is not fixed in the standard.

ITSO Specification part 2 Calypso Card specification

Action lists (green list) can cahnge expiration date, National standard (INTERBOB) defines the structure of the messages of action lists

Security Aspects


It is required that customer data be handled confidentially during the termination process.

All Applications and data are encoded by an ISAM which uses keys distributed by the ITSO Registrar.

There is no personal data into the media.

complies to privacy regulations


The possibility of terminating (or revoking) an application is an essential part of the security objective "protection of applications and application templates".

All applications and their templates are encoded by an ISAM which uses keys distributed by the ITSO Registrar.


The processes here enable e.g. the prevention of the accumulation of costs for an application which is valid but no longer in use, and thus support the security objective "reliable accounting and billing".

ITSO does not directly support billing but all data is distributed to relevant owners.


Most of the products loaded into application are prepaid. Refunding policy is defined by Application Owner.

to 83



6. Use Cases from ISO 24014‐1 6.3.6 Forced Termination of Application



A termination request can be submitted (e.g. by the Security Manager or the Customer) to the Application Retailer who forwards this to the Application Owner. The Application Owner sends a termination order to the relevant Control Service who converts the order into a termination entry in the relevant security list which is distributed to all participants. An organisation encountering the application will perform the termination and send a corresponding confirmation of termination to the Control Service which will remove the entry from the security list and forward the confirmation of termination to the Application Owner and the Application Retailer as well.

ITSO Licensee raises Hot List and/or action list

The customer can submit a termination request to the Application Retailer who can perform the termination and inform the Application Owner. Application is not desinstalled but can be blocked and the Calypso SN added to a black list.

Action lists can blacklist (non reversible) or brown list (reversible) applications or media,

Set of Rules Participation agreements for organisations in the various roles. Organisations are required to download current security lists.


to 83




Contract for services between Control Service and Security Manager.

ITSO License

Technical Aspects


The processes are defined in the Interface specification of the core application. There are also definitions of the data structures to be used for security lists and their entries. The communication between customer and Application Retailer is not fixed in the standard.

Application deletion is a standard use case; owner has key to initiate.

Calypso Card specification

National standard (INTERBOB) defines the structure of the messages of action lists

Security Aspects


Security lists do not contain personal information; nevertheless, they can be encrypted. Customer data must be handled confidentially during the termination request process.

The owner raises delete application instruction through Action List and signed by same ISAM key as original used to create the application

N.A. There is no personal data into the media.

complies to privacy regulations


The possibility of terminating (or revoking) an application is an essential part of the security objective "protection of applications and application templates". Participating organisations are required to download current security lists and perform the terminations.

Protected by keys

to 83



6. Use Cases from ISO 24014‐1 Protection of security lists

Security lists are signed by the Control Service and can be encrypted. The confirmations of termination are signed by the organisations performing the terminations.

Protected within ISAM


The processes here enable the prevention of misuse of an application, and thus support the security objective "reliable accounting and billing".

All data transactions are loss‐less (i.e. not deleted until signed acknowledgement received). Data owner then holds these for 16 months.

same as above

6.4 Product Management Use Cases

6.4.1 Dissemination of Product Template


to 83




Following the registration of a product template the Product Owner signs and distributes the template to all relevant Product Retailers and Service Operators. Furthermore, the Product Owner must provide the Product Retailers with the associated master key needed for the issuance process.

The Owner requests the Registrar to distribute keys.

Following the registration of a product template the Product Owner distributes the template to all relevant Product Retailers and Service Operators.

Set of Rules Participation agreements for Product Owners, Product Retailers and Service Operators.




Technical Aspects


The standard includes a Data model and XML‐Schemes for the definition of product templates. The security infrastructure provides the specifications and mechanisms for generating signatures and for supplying SAMs with the necessary master keys.

ITSO specification part 2 Product template are based on EN 1545 & Intercode for data structure and coding, and includes a dedicated data model defined by the Product Owner.

Security Aspects

to 83



6. Use Cases from ISO 24014‐1 Protection of products and product templates

The templates are signed by the issuing Product Owner and thus are authenticated. The Product Owner administers the rights of other organisations to load his master key to their SAMs in the key management system of the core application security infrastructure. The transportation of the keys is authentic and end‐to‐end encrypted to the individual SAMs.

All products and templates are encoded by an ISAM which uses keys distributed by the ITSO Registrar.

Product retailers need a Reloading SAM for loading products into Calypso application.

6.4.2 Regular Termination of Product Template



In case a product template is no longer to be used for loading products onto user media, the Product Owner will inform the relevant Product Retailers of the termination of this template. The termination of instances of a certain product template already in the field is covered by 6.4.7.

All products have end dates.

In case a product template is no longer to be used for loading products onto user media, the Product Owner will inform the relevant Product Retailers of the termination of this template.

Set of Rules Relevant rules for the Product Owner and Retailers are set in the participation agreement.


to 83




No additional agreements are needed. ITSO License No additional agreements are needed.

Technical Aspects


Direct communication with Retailers authorised by the Product Owner to load the product on his behalf.

ITSO Specification part 3

Security Aspects


The continued use of terminated product templates is to be prevented. The Product Owner can control the implementation of the change by inspecting the issuance transactions received from the Product Retailers. It may or may not be necessary to terminate instances of the product template already in the field. If necessary, it is done according to 6.4.7.

All products and templates are encoded by an ISAM which uses keys distributed by the ITSO Registrar. A key is set to create, accept, modify or delete.

Product loading is performed via "Calypso secure session". Security is ensured by a loading SAM (CL SAM).

6.4.3 Forced Termination of Product Template


to 83




If necessary, the IFM Manager can terminate a specific product template and revoke its certification. The IFM Manager will inform the relevant Product Owner who will then inform the relevant Product Retailers. The termination of instances of a certain product template version already in the field is covered by 6.4.8.

Owner raises Action List Managed by product owner.

Set of Rules Relevant rules for the Product Owner and Retailers are set in the participation agreement.




Technical Aspects


Direct communication with Product Owners. ITSO Specification

Security Aspects

to 83




The continued use of terminated products templates is to be prevented. The possibility of terminating (or revoking) a product template is an essential part of the security objective "protection of applications and application templates". The Product Owner can control the implementation of the change by inspecting issuance transactions. It may or may not be necessary to terminate instances of the application template already in the field. If necessary, it is done according to 6.4.8.

All products are encoded by an ISAM which uses keys distributed by the ITSO Registrar including delete.

Product loading is performed via "Calypso secure session". Security is ensured by a loading SAM (CL SAM).


Not relevant in this case. Encoded and signed by same owner key.

6.4.4 Management of Action Lists



This is the responsibility of the Product Owner. Responsibility of Product Owner.

This is the responsibility of the Product Owner.

Set of Rules

The rules in the participation agreements relevant for products continue to apply here, but there are currently no further specific rules.

ITSO License same natures of action lists as above for applications



Technical Aspects

to 83





A standard for action lists based on the data structures and processes of the German core application and integrating the security infrastructure is currently in work.

ITSO Specification parts 4 and 6

Security Aspects


As with Acquisition of Product! Data are signed by an ISAM which uses keys distributed by the ITSO Registrar.

No personal data stored in User Medium


As with Acquisition of Product! Data are signed by an ISAM which uses keys distributed by the ITSO Registrar.

Based on "Calypso secure session" and loading SAM (CL SAM)


As with Acquisition of Product! All data is loss‐less; ITSO does not support billing.

Additional bilateral agreements with the Product Retailer concerning the conditions for the product may be required by the Product Owner which are outside the scope of the IFM Management.

to 83



6. Use Cases from ISO 24014‐1 6.4.5 Acquisition of Product



Products can only be issued to user media using SAMs equipped with the appropriate keys. As preparation the product template must have been disseminated to the Product Retailer by the Product Owner. This includes the distribution of necessary master keys belonging to the Product Owner to the SAM of the Product Retailer as described in 6.4.1. In a similar fashion the SAM of the Product Retailer must be equipped with the necessary system keys belonging to the Security Manager. Following a certificate based authentication with session key agreement between the SAM of the Product Retailer and a User Medium, the product data, including the organisation and product specific derived keys, can be securely written to the User Medium. The Product Retailer must perform a product issuance transaction with the User Medium and forward the transaction data to the Product Owner.

The Product Owner authorises the Registrar to distribute necessary keys.

Products can only be issued to user media using Calypso Reloading SAMs. Each Product Retailer must be equipped with reloading SAM.

Set of Rules The participation agreements for Product Owners and Retailers provide the basic regulations.

ITSO License Commercial agreement between Product Owner and Product Retailers

to 83




Additional bilateral agreements with the Product Retailer concerning the conditions for the product may be required by the Product Owner which are outside the scope of the IFM Management.

ITSO License Additional bilateral agreements with the Product Retailer concerning the conditions for the product may be required by the Product Owner which are outside the scope of the IFM Management.

Technical Aspects


The relevant documents are the SAM and User Medium specifications, the interface specification and data model.

ITSO Specification parts 3 and 4

Security Aspects


Access to personal information of the Customer, to the extent that they are present at all, is restricted to the Customer and the Product Retailer, who is only to access the data on an absolute need to know basis and are treated confidentially.

Data are signed by an ISAM which uses keys distributed by the ITSO Registrar.


to 83




See the description under 6.4.1. The issuance procedure is closed by the generation of an issuance transaction between the user medium and an authorised SAM.




Master keys are only present in a secured offline system in the Trust Center used by the security infrastructure and in SAMs. Derived keys are present in the user media. The distribution of master keys from the key management system to a SAM (using a SAM specific end‐to‐end encryption and signature) can only be triggered by the key owner who must authenticate himself for this purpose. The keys themselves are not known to any participants including the key owner unless the key owner requests the export of a key from the key management system (in which case it will only be known to the key owner). Derived keys are generated in SAMs and distributed to user media in a secure end‐to‐end communication using a certificate based authentication with session key agreement. The SAM maintains internal counters concerning the usage of keys and the performance of transactions.

Held by Security Management Service and distributed to ISAMs.

All keys are hold and remain in the SAM. SAM key provisioning itself is perfomed in a secure way via another SAM (cf. 6.2.4). All SAM functions are limited either in time or to a ceiling amount and monitored by a SSSR SAM (Supervisor SAM)

to 83



6. Use Cases from ISO 24014‐1 Reliable accounting and billing

Authentic transactions are generated between User Medium and SAM during the issuance procedure which are delivered to the Product Owner and can be verified. In this way the Product Owner can monitor the process and verify that only authorised products are being issued. The Product Owner can also set a usage limit for his key in the SAMs of Product Retailers to restrict the issuance of products (including offline).

Data is loss‐less but ITSO do not support accounting and billing.

Calypso is not involved in billing. Nevertheless, SAM counters can be used to monitor the number of loaded products.

6.4.6 Modification of Product Parameters



The process is analogous to 6.4.5. In particular, according to the participation agreements of the German core application, electronic tickets may not be modified. A change of a ticket requires that it be completely deleted and reloaded, i.e. a repetition of the process 6.4.5. Other kinds of entitlements (e.g. for post‐paid automatic fare collection systems) can be modified, but only by the issuing Product Retailer and the process is the same as above with the exception that only a part of the product data are (re‐)written.

The Owner requests the Registrar to distribute modify keys relevant to that product to ISAMs authorised to accept it

Idem 6.4.5 Idem 6.4.5

Set of Rules See 6.4.5. ITSO License Idem 6.4.5 Idem 6.4.5


See 6.4.5. ITSO License Idem 6.4.5 Idem 6.4.5

Technical Aspects

to 83




See 6.4.5. ITSO Specification Idem 6.4.5 Idem 6.4.5

Security Aspects


See 6.4.5. Data are signed by an ISAM which uses keys distributed by the ITSO Registrar.

Idem 6.4.5 Idem 6.4.5


See 6.4.5. Data are signed by an ISAM which uses keys distributed by the ITSO Registrar.

Idem 6.4.5 Idem 6.4.5


See 6.4.5. All data loss‐less but ITSO do not support accounting and billing.

Idem 6.4.5 Idem 6.4.5

6.4.7 Regular Termination of Product



The customer can submit a termination request to the Product Retailer who can perform the termination and inform the Product Owner by sending the corresponding termination transaction.

All product keys have end date.

All products have end date.

to 83



6. Use Cases from ISO 24014‐1 Set of Rules Participation agreement for Retailers. ITSO License



Technical Aspects


The processes are defined in the Interface specification of the core application. The communication between customer and Product Retailer is not fixed in the standard.

ITSO Specification part 2 Intercode standard complemented with the local data model provides the necessary set of rules for ensuring product interoperability.

Security Aspects


It is required that customer data be handled confidentially during the termination process.




The possibility of terminating (or revoking) a product is an essential part of the security objective "protection of products and product templates".




The processes here enable e.g. the prevention of the accumulation of costs for a product which is valid but no longer in use, and thus support the security objective "reliable accounting and billing".

ITSO does not support accounting and billing.


to 83



6. Use Cases from ISO 24014‐1 6.4.8 Forced Termination of Product



Product Owners, Retailers, Service Operators or Customers can submit termination requests for a product / entitlement to the Product Retailer who then decides whether it should be forwarded as a termination order to the Control Service (under contract of the Security Manager). The Product Retailer can send such revocation orders on his own accord. The Control Service converts the order into a termination entry in the relevant security list which is distributed to all participants. An organisation encountering the application will perform the termination and send a corresponding confirmation of termination to the Control Service which will remove the entry from the security list and forward the confirmation of termination to the Product Retailer.

The owner distributes action lists.

The customer can submit a termination request to the Product Retailer who can perform the termination and inform the Product Owner. Product is not desinstalled but application can be blocked and the Calypso SN added to a black list.

Set of Rules Participation agreements for organisations in the various roles. Organisations are required to download current security lists.




ITSO License

Technical Aspects

to 83




The processes are defined in the Interface specification of the core application. There are also definitions of the data structures to be used for security lists and their entries. The communication between customer and Product Retailer is not fixed in the standard.

ITSO specification part 2 Intercode standard complemented with the local data model provides the necessary set of rules for ensuring product interoperability.

Security Aspects


Security lists do not contain personal information; nevertheless, they can be encrypted. Customer data must be handled confidentially during the termination request process.




The possibility of terminating (or revoking) a product is an essential part of the security objective "protection of products and product templates". Participating organisations are required to download current security lists and perform the terminations.




Security lists are signed by the Control Service and can be encrypted. The confirmations of termination are signed by the organisations performing the terminations.

Data are encoded by an ISAM which uses keys distributed by the ITSO Registrar.

to 83




The processes here enable the prevention of misuse of a product, and thus support the security objective "reliable accounting and billing".

ITSO does not support accounting and billing.


6.4.9 Use and Inspection of Product



Service Providers check the authenticity and validity of products / entitlements during usage by the Customer and generate authentic transactions documenting the usage or inspection. The transaction data are forwarded by the Service Provider to the relevant Product Owner, who in turn forwards the data to the issuing Retailer. For post‐paid products these transaction data form the basis for the clearing between Product Retailer, Product Owner and Service Provider.

The owner requests the Registrar to distribute relevant keys to specific ISAMs.

The procedure for checking user's product and the nature of the information for identifying rpoduct holder are defined by the Product Owner, and vary from one network to another. Checking user identity for concessionary product is generally based on the user's photo and name printed on the card.

to 83



6. Use Cases from ISO 24014‐1 Set of Rules Participation agreements for organisations in the various roles. ITSO License Local rules or part of

Interoperability Charter.


Additional agreements with the Product Retailer and Service Provider regarding concerning the conditions for the product may be required by the Product Owner which are outside the scope of the IFM Management.

ITSO License Not relevant in this case.

Technical Aspects


The relevant documents are the SAM and User Medium specifications, the interface specification and data model.

ITSO Specifications parts 2 and 3

Calypso Card specifcation

Security Aspects


Access to personal information of the Customer, to the extent that they are present at all, is restricted to the Customer and the Service Provider who is only to access the data on an absolute need to know basis (e.g. in connection with the inspection of personalised products) and are to be treated confidentially.



to 83




The procedures here prevent the unauthorised use genuine products resp. the use of unauthorised products and so are essential to the security objective "Protection of products and product templates".


Based on "Calypso secure session" but generally product checking does not require keys for reading the data.


The usage and inspection transactions are equipped with message authentication codes issued by the User Medium using derived keys specific to the entitlement and application based on masterkeys owned by the involved parties (Product Owner and Retailer). This prevents the manipulation of the data. The transactions also contain unique identifiers and application resp. entitlement specific counters, so that replay attacks can be prevented and gaps in data (i.e. missing transactions) can be detected.

Data are signed by an ISAM which uses keys distributed by the ITSO Registrar and are not deleted until acknowledgement is securely received.


The ability to draw usage transactions from User Media whose completeness and correctness can be verified by the parties involved financially in the distribution and use of the corresponding product is of central importance for the performance of correct accounting and billing.

All data is loss‐less, but ITSO does not support accounting and billing.

6.4.10 Collection and Forwarding of Data


to 83




This is the responsibility of Product Owners. Licensed Operator applies for permission to carry out function from Registrar and keys are sent to him.

virtual function, performed by the different entities,

Set of Rules Participation agreements for organisations in the various roles regarding the use of interoperable products apply.



Additional agreements between Product Retailer, Service Provider and Product Owner regarding the collection and forwarding of data may be required which are outside the scope of the IFM Management.

ITSO License

Technical Aspects


The German core application supplies data and interface specifications. The use of the security infrastructure provides the necessary transaction security as a basis for collection and forwarding.

ITSO Specifications parts 4, 6, 9

national standard INTERBOB specifies the structure of the messages

Security Aspects

to 83



6. Use Cases from ISO 24014‐1 Protection of personal information

Personal information of the Customer, to the extent that they are present at all, are only to be used by the Product Retailer on a need to know basis to collect accumulated charges from the Customer and must be otherwise separated from the usage data. In particular, the Product Owner and Service Operator do not store these data in their systems. Generally speaking these data are to be treated confidentially with regard to storage and communication.

Data are encoded by an ISAM which uses keys distributed by the ITSO Registrar.


See 6.4.9. Data are encoded by an ISAM which uses keys distributed by the ITSO Registrar.


See 6.4.9. not supported

6.4.11 Generation and Distribution of Clearing Reports



This is the responsibility of Product Owners. All data is securely distributed for clearing.

not implemented,

to 83



6. Use Cases from ISO 24014‐1 Set of Rules Participation agreements for organisations in the various roles

regarding the use of interoperable products apply. ITSO License


Additional agreements between Product Retailer, Service Provider and Product Owner regarding the collection and forwarding of data may be required which are outside the scope of the IFM Management.

No relevant framework agreements.

Technical Aspects


The German core application supplies data and interface specifications. The use of the security infrastructure provides the necessary transaction security as a basis for the preparation of clearing reports.

ITSO Specification parts 4, 6

N.A.

Security Aspects



No personal data are exchanged via Collection and Forwarding process.



N.A.

to 83




See 6.4.9. not directly supported N .A.

6.5 Security Use Cases

6.5.1 Monitoring of IFM Processes and IFM Data Life Cycle


to 83




The issuance of SAMs is monitored by the Security Manager. The issuance of Certificates and applications is monitored by the Security Manager and the respective Application Owners. The issuance of products is monitored by the respective Product Owners and Retailers. The usage of products is monitored by the respective Service Operators, Product Owners and Retailers. A Central Control Service is commissioned by the Security Manager for the handling of termination orders and the distribution of security lists.

Carried out by the security manager in conjunction with Registrar.

The issuance of SAMs is monitored by the Security Manager. The issuance of applications is managed by the respective Application Owners and Retailers. The issuance of products is monitored by the respective Product Owners and Retailers. The usage of products is monitored by the respective Service Operators, Product Owners and Retailers. A Central Control Service is commissioned by the Security Manager for the handling of termination orders and the distribution of security lists.

Set of Rules Participation agreements for organisations in the various roles. ITSO License

to 83





No relevant framework agreements.

Technical Aspects


The relevant documents are the data model and the interface specification of the core application.

ITSO Spec part 7, 8 N.A.

Security Aspects


The data collected for monitoring purposes are anonymous and must be separated from any personal data in back office systems (needed e.g. for billing).

Not managed by IFM; left to individual Product Owners.

N.A. No personal data are exchanged.

6.5.2 Management of IFM Security Keys


to 83




Every key in the IFM has a designated owner (always a certified and registered organisation). The owners are responsible for the management of their own keys and can do this in their own systems. The core application security infrastructure provides a common platform for the secure transport and usage of all keys outside the key owners own system (PKI, SAMs). To enable interoperability the Security Manager also owns and manages a series of keys (in the key management system of the core application security infrastructure). The Security Manager has opened this service to use by all certified and registered organisations for the management of their own keys.

The Registrar manages keys; Security System audited by Security manager.

key ceremonies issue master keys and produce master SAMs

Set of Rules Participation and usage agreements. License and ITSO procedures

Local rules or part of Interoperability Charter. Ressponsibility is always parted between at least two entities,


Contract for services between security service provider and Security Manager.

ITSO procedures N.A.

Technical Aspects

to 83




Core Application Security Infrastructure specifications for the Key Management system and the SAM.

Security Management System specification and use cases

Calypso Card and Key Management specs

Security Aspects


The mechanisms defined and implemented assure the confidentiality of secret keys during their creation and administration in the key management system as well as their distribution to and usage in SAMs. Any process regarding a certain key can only be initiated by the key owner.

The ISAM is validated by Common Criteria EAL4+; independent ITSO Security Management Committee reviews all Security Procedures and benchmarks using external academics.

All keys are stored in SAM and provisionned via key ceremonies under the control of a Master SAM (cf 6.2.4). A new entity can be easily provided with SAMs for issuing, loading, cards etc… by creating and provisioning new SAMs from the Master SAM.

6.5.3 Provision of Security Lists


to 83




Current security lists are processed and made available to all participating organisations by the Control Service (under contract of the Security Manager) in regular intervals. It is the responsibility of the participating organisations to retrieve the current lists in defined maximum intervals. Security lists in the core application contain information about the revocation (or termination) of specific components, applications, products and keys.

The Registrar distributes security lists securely between Security Management Service and individual ISAMs including secure acknowledgement.

Information is based on Calypso Serial Number only, allowing to exchange list for anonymous product.

see above

Set of Rules Participation agreements for organisations in the various roles. ITSO Specification part 8 Local rules or part of Interoperability Charter.




Technical Aspects


The processes are defined in the Interface specification of the core application. There are also definitions of the data structures to be used for security lists and their entries.

ITSO Specification part 8 National standard Interbob

Security Aspects

to 83




Security lists are signed by the Control Service by the Control Service using a certificate issued by the Security Manager / security infrastructure and can be verified as authentic by all participants. Furthermore the lists can be encrypted. The systems of the Control Service used to administer and process security lists must operate in a secure environment and have their own backup und monitoring functions.

Data are encoded by Security Management Service

6.5.4 Updating Security List Data



Based on termination (or revocation) orders and confirmations received (see 6.5.5) since the generation of the last security list the Control Service (under contract of the Security Manager) generates a new list within a defined maximum time interval which is then provided according to 6.5.3.

Messages are sent by the Registrar (or other Licensed Operator) through Security Management Service then through C&F to each ISAM.

Set of Rules Participation agreements for organisations in the various roles. ITSO License and Specification part 8

Local rules or part of Interoperability Charter.




to 83




Technical Aspects



ITSO Specification part 8 National standard Interbob

Security Aspects


See 6.5.3. Data are encoded by Security management Service

6.5.5 Add or Remove a Component to/from Security List


to 83




Service Operators and Retailers can submit revocation requests for a SAM to the Security Manager who then decides whether it should be forwarded as a revocation order to the Control Service (under contract of the Security Manager). The Security Manager can send such revocation orders on his own accord. The Security Manager, Retailers or Service Operators can submit revocation requests for an application to the Application Owner who then decides whether it should be forwarded as a revocation order to the Control Service. Application terminations resulting from the revocation of the corresponding certificate must be converted by the Application Owner to a revocation order. Product Owners, Retailers, or Service Operators can submit revocation requests for a product / entitlement to the Product Retailer who then decides whether it should be forwarded as a revocation order to the Control Service. The Product Retailer can send such revocation orders on his own accord. Service Operators, Retailers and Product Owners can submit revocation requests for an organisation or a key to the IFM Manager resp. Security Manager who then decides whether it should be forwarded as a revocation order to the Control Service. The IFM Manager resp. Security Manager can send such revocation orders on his own accord. Revocation (or termination) orders are converted by the Control Service into a corresponding new entry in the relevant security list. Terminations performed by organisations are reported to the Control Service by way of a termination confirmation message. The Control Service uses these messages to remove the corresponding entries from the security list.

A Licensed Operator applies through his HOPS to Security Management service.

to 83



6. Use Cases from ISO 24014‐1 Set of Rules Participation agreements for organisations in the various roles. License and ITSO

Specification part 8 Local rules or part of

Interoperability Charter.



Specification parts 4, 8

Technical Aspects



Specification parts 4, 8 National standard Interbob

Security Aspects


Orders and conformations are signed by the corresponding organisations using certificates issued by the Security Manager / security infrastructure and can be verified as authentic by all participants. The systems of the Control Service used to administer and process security lists must operate in a secure environment and have their own backup und monitoring functions.

Data are encoded by ISAM which uses keys distributed by ITSO Registrar

6.5.6 Add or Remove an Application Template to/from Security List


to 83




The German core application does not currently specify the administration of application templates in security lists. See 6.3.3 and 6.3.4 as well as 6.5.4 and 6.5.5 above.

Operator applies to Registrar.

not envisaged as a normal procedure

Set of Rules n.a. ITSO License


n.a. ITSO License

Technical Aspects


n.a.. ITSO specifications parts 2, 4

Security Aspects


n.a. Data are encoded by ISAM which uses keys distributed by ITSO Registrar

6.5.7 Add or Remove an Application to/from a Security List


to 83




See 6.5.5 above. The Licensed Operator contacts Registrar.

In case several Transport Operators are operating on the same IFMs, they usually exchange security list and periodic updates directly in a bilateral mode. Information is based on Calypso Serial Number only, allowing to exchange list for anonymous product.

Set of Rules See 6.5.5 above. ITSO License Local rules or part of Interoperability Charter.


See 6.5.5 above. ITSO License No additional agreements are needed.

Technical Aspects


See 6.5.5 above. ITSO specification parts 2, 4

to 83




Security Aspects


See 6.5.5 above. Data are encoded by ISAM which uses keys distributed by ITSO Registrar.

6.5.8 Add or Remove a Product Template to/from Security List



The German core application does not currently specify the administration of product templates in security lists. See 6.4.2 and 6.4.3 as well as 6.5.4 and 6.5.5 above.

The licensed operator applies to Registrar.

Not applicable. No security list for products.

Set of Rules n.a. ITSO License


n.a. ITSO License and procedures

Technical Aspects


n.a. ITSO specifications parts 2, 4

Security Aspects

to 83




n.a. Data are encoded by ISAM which uses keys distributed by ITSO Registrar.

6.5.9 Add or Remove a Product to/from Security List



See 6.5.5 above. operator applies to Registrar to remove cancel keys

not applicable. No security list for products.

Set of Rules See 6.5.5 above. ITSO License


See 6.5.5 above. ITSO License and procedures

Technical Aspects


See 6.5.5 above. ITSO specifications parts 2, 4

Security Aspects


See 6.5.5 above. Data are encoded by ISAM which uses keys distributed by ITSO Registrar.

to 83


5. Conclusions Initially the idea of the work package was to try and select parts of the individual schemes according to “best practices” or “best of breed” approaches and then to directly describe the intended EU IFM at a systems level in a fairly detailed way by combining these parts.

The information collected here was to be used to support the selection procedure and eventually the integration of the parts.

With the progression of the various work packages in the project and the intensification of the discussions between the scheme members it was realized that

due to essential differences at the technical systems level it would be impracticable to excise only certain parts of the various schemes for common integration and

the level of detail that could be expected from the other work packages in the IFM project would not provide the needed level of detail to actually substantiate the choices that needed to be made and to describe the technical EU IFM system.

As consequence the first approach had to be abandoned and a new approach worked out. Instead, the Deliverable 5.2 would provide a general framework for analysing the interaction of systems needed for the increasing levels of interoperability in the various scenarios identified in the IFM road map.

For each of the scenarios identified in the road map, the system processes and actors involved would be analysed within the standard model, including in particular the processes spanning the stages Provision of secure elements, Provision of applications, Provision of products and Usage of products. The processes that require interaction would be identified in each case and documented. The more advanced the scenario is in the road map the more processes will have to interact. For these “interactive processes” the requirements to assure effective interaction would be analysed and documented. In each case it would be considered which aspects need to be standardised.

The information collected here would then be used in a different way in the next steps in the realization of an EU IFM; namely, to determine, for each of the aspects where a need for standardisation was identified, whether common solutions already exist which could be leveraged in the interoperable context and to estimate the work involved.

inventory of generic system and security architectures...

Documents