e Money Security 200305

8/11/2019 e Money Security 200305

1/45

ELECTRONIC MONEYSYSTEM SECURITY

OBJECTIVESACCORDING TO THE COMMON

CRITERIA METHODOLOGY

May 2003

E C

B E

Z B

E

K T

B

C E

E

K P


2/45

ELECTRONIC MONEYSYSTEM SECURITY

OBJECTIVES

ACCORDING TO THE COMMONCRITERIA METHODOLOGY

May 2003


3/45

European Central Bank, 2003

Address Kaiserstrasse 29

D-60311 Frankfurt am Main

Germany

Postal address Postfach 16 03 19

D-60066 Frankfurt am Main

Germany

Telephone +49 69 1344 0

Internet http://www.ecb.int

Fax +49 69 1344 6000

Telex 411 144 ecb d

All rights reserved.

Reproduction for educational and non-commercial purposes is permitted provided that the source is acknowledged.

ISBN 92-9181-361-3 (print)

ISBN 92-9181-362-1 (online)


4/45

3E C B E l e c t r o n i c m o n e y s y s t e m s e c u r i t y o b j e c t i v e s M a y 2 0 03

Table of contents

Introduction and executive summary 5

1 Target of Evaluation description 81.1 E-money system: model 8

1.1.1 Main concepts of the model 81.1.2 Examples of e-money systems 91.1.3 Additional concepts: compensation, transactions, EV life cycle, roles,

actors, and quasi-actors 101.1.4 Interoperability of two e-money systems 16

1.2 Target Of Evaluation 171.2.1 Elements that are part of the TOE 17

1.2.2 Elements that are outside the TOE 18

2 TOE security environment 192.1 Assumptions 202.2 Threats 20

2.2.1 Threat agents 202.2.2 Threats list 21

2.3 Organisational security policies (OSPs) 23

3 Security objectives 253.1 Classification of security objectives 25

3.1.1 Security objectives for the TOE or the environment 253.1.2 Application domains 253.1.3 Naming convention 26

3.2 Security objectives list 263.2.1 Integrity [INT] 263.2.2 Confidentiality [CONF] 263.2.3 Identification [ID] 263.2.4 Authentication [AUTH] 263.2.5 Access control [ACC] 273.2.6 Commitment and validation [COMM] 273.2.7 Atomicity [ATOMICITY] 273.2.8 Transaction order [ORD] 27

3.2.9 Non-evaporation [EVAP] 283.2.10 Limitations [LIM] 283.2.11 Traceability [TRAC] 283.2.12 Detection [DETECTION] 283.2.13 Reaction [REACTION] 293.2.14 Cryptography and protocols [CRYP] 293.2.15 Secret management [MNG] 293.2.16 Trusted path [TRUSTED_PATH] 303.2.17 Trusted location [TRUSTED_LOCATION] 303.2.18 Competence and responsibility [RESP] 303.2.19 Qualification and tests [QUAL] 303.2.20 Assessment [ASSESSMENT] 313.2.21 Security update 313.2.22 Availability [AVAIL] 31


5/45

E C B E l e c t r o n i c m o n e y s y s t e m s e c u r i t y o b j e c t i v e s M a y 2 00 34

3.2.23 Life cycle [LIFE] 313.2.24 Partition [PARTITION] 31

Annex A Sources 32

Annex B Application notes 33B.1 Link with the CC methodology 33B.2 Rationale for the model 35B.3 Strength of function 35B.4 Roles 35

Annex C Acronyms 37

Annex D Glossary 38

Annex E Minimum requirements in the Report on Electronic Money 41

Annex F Cross-reference Table for Security Objectives 42


6/45


1 See Annex E for the list of minimum requirements of the 1998Report on Electronic Money.

Introduction and executive summary

Electronic money (e-money) systems aregradually achieving some level of status as ameans of payment in a number of countries.In the light of the possible impact of thedevelopment of e-money, in 1998 theEurosystem issued the Report on ElectronicMoney, addressing monetary policy effects,level playing field considerations andregulatory concerns, such as the smooth andefficient functioning of payment systems,confidence in payment instruments,

protection of customers and merchants,stability of financial markets and protectionagainst criminal abuse. As part of theiroversight responsibility for payment systems,central banks have to ensure that all relevante-money systems comply with therequirements of the 1998 report. 1

Given the specific importance of IT securitymatters in relation to the conduct of anoverall assessment of the reliability of e-money systems, on the issue of technicalsecurity on the 1998 report was furtherelaborated. The Eurosystems investigationsresulted in the Electronic Money SystemSecurity Objectives (EMSSO) report, whichdetails the Eurosystems expectations in thisfield. The EMSSO report contains acomprehensive risk analysis fore-money systems and a list of securityobjectives that should be fulfilled in order tocover these risks/threats in a givenenvironment. In particular, the analysis

provides an overall description of a typicale-money system and highlights the threatsand organisational guidelines that arise on thebasis of certain assumptions. The securityobjectives are defined broadly enough tocover both hardware and software-basede-money systems, including the newer server-based initiatives. The EMSSO report benefited

This final EMSSO report, which complementsthe 1998 report, will be used by theEurosystems central banks to assess theoverall reliability and technical security of

e-money schemes in the euro area. TheEurosystems security objectives are alsodesigned to level the regulatory playing fieldfor the different schemes. Furthermore, thereport could provide market participants withuseful input for their own risk and securityanalyses and for the definition of their securitypolicies.

The risk analysis and the definition/presentation of the security objectives in the

EMSSO report are based on the CommonCriteria for Information Technology SecurityEvaluation (CC) methodology. Thisinternationally agreed and standardisedmethodology was selected because it providesa coherent framework for describing e-moneysystems and related assumptions, threats andorganisational aspects and for deriving adefinition of security objectives from thisdescription. According to the CCmethodology, the drafting process should alsocover other steps, such as the definition of security requirements, which would result inthe drafting of a Protection Profile and in thedefinition of evaluation and assurancerequirements. However, these additionalsteps are not addressed in this document.

In Chapter 1, the EMSSO report focuses onseveral basic concepts, such as the e-moneysystem, electronic value and sub-systems. Thee-money system is a mechanism that facilitatespayments generally of limited value in

which e-money can be considered as anelectronic surrogate for coins and banknotes.The e-money system is described on the basisof a model with a set of sub-systems throughwhich electronic value (EV) is transferred,under the responsibility of a SystemSupervisor who monitors the security of EVcreation, EV extinguishment and EVcirculation within the system. In the contextof this report, electronic value is defined as a

from a market consultation in March 2002.


7/45


2 This definition is taken from Directive 2000/46/EC.

monetary value represented by a claim on anEV Issuer, which is: (i) stored on an electronicdevice; (ii) issued on receipt of funds for anamount not less in value than the monetaryvalue issued; and (iii) accepted as a means of payment by undertakings other than theissuer. 2

The notion of a sub-system is intentionallyflexible, i.e. the model does not impose anyrestriction on the number of sub-systems thatform an e-money system, and a sub-system isdefined only by:

its capaci ty to send or receive EV amounts; the System Supervisors abil ity to monitor

these amounts.

The sub-systems are capable of generatingReporting Data (RD) and of making this dataavailable (either directly or indirectly via othersub-systems) to the System Supervisor onrequest, thereby allowing EV exchanges to betraced.

After describing the concepts, in Chapter 2the EMSSO report defines the main threatsrelated to the unsecured and untrustedenvironment in which an e-money systemusually works and that this report is intendedto cover. The operation of an e-money systemrequires an adequate handling of risks relatingto counterfeits, damages and criminal events,which can be translated into main threats.Such threats, if not properly managed, canput issuers, merchants and customers at risk.

The main threats against which protection isto be provided are:

Creation of fake EV: Circumstances inwhich it might be possible for an attackerto use fake EV, i.e. EV that does notrepresent an EV Issuer debt.

Illicit ext inguishment of EV: Attacks orincidents that lead to an abnormal andirrevocable EV loss.

Embezzlement of EV: Attacks in which oneactor embezzles EV from its legitimateowner.

EV theft: Opportunities for an attacker tosteal EV.

Abuse of the e-money system: Use of thee-money system to infringe regulationsunrelated to the system.

Interference with the operat ion of thee-money system: Accidental or intentionalmalfunction that may result in the systembeing totally or partially unavailable.

To counter the above threats, the followingsecurity objectives should be met byappropriate technical and organisationalaction. Further details on these objectives,which are listed below, can be found in

Chapter 3 of the report.

Access control: Unauthorised access to allassets is prohibited, even in the case of amalfunction in monitoring or in secretsmanagement. Each identified actor has aclear set of access rights.

Assessment: Important players are subjectto assessment.

Atomicity: Transactions are eithercompleted or undone.

Authentication: EV transactions andmonitoring data exchanges areauthenticated.

Availability: The system ensures serviceavailability, even during maintenance of partof the system.

Commitment and validation: Transactionsare conducted and validated under theterms of a commitment between theparties.

Competence and responsibility: Peopleinvolved in the system know and follow

their own contractual obligations, and havesufficient means, training and informationto perform their role.

Confident iality : Those asset s tha t mustremain confidential are preservedaccordingly.

Cryptography and protocols: State-of-the-art cryptography, protocols and securityprocedures are required.

Detection: The system has the capabilityto:

detect abnormal events, including actualor attempted modification of assets and


8/45


9/45


1 Target of Evaluation description

The intention of this section is to define theTarget of Evaluation (TOE), which is the partof the system that is to be evaluated (i.e. towhich the security objectives are to beapplied).

The TOE is defined in a rather genericmanner, by using a high-level model fore-money systems, in order to cover as manye-money systems as possible and to be ableto deal with interoperability situations, which

are likely to arise in the euro area.

Section 2.1 first introduces the model andthe various concepts related to it. Section 2.2then defines the TOE, which is a subset orpart of this model, with clearly definedtransactions and actors.

1.1 E-money system: model

This section defines the model and severalconcepts that will be relied upon in thisreport. The concepts are first definedformally, then illustrated by a practicalexample.

The three main elements which make up oure-money system model are EV, EV circulationbetween sub-systems and supervision. Puttogether, these elements constitute the coreof the e-money system model. The notions of transactions, compensation, EV life cycle and

actors then complete this model.

1.1.1 Main concepts of the model

The e-money system is modelled as a set of sub-systems through which the EV specific tothe system is transferred, under theresponsibility of a System Supervisor 3 whomonitors the security of EV creation, EVextinguishment and EV circulation within thesystem.

EV4 is a monetary value represented by aclaim on an EV Issuer, which is:

stored on an electronic device; issued on receipt of funds for an amount

not less in value than the monetary valueissued;

accepted as a means of payment byundertakings other than the issuer.

The EV circulation starts with a first phasecalled EV creation, and ends with a final phase

called EV extinguishment.

Figure 1Model of an e-money system

EV creation EV extinguishment

Reporting Data

EV circulation

SystemSupervisor

Sub-system

Sub-system

Sub-system

Sub-system Sub-system

Sub-system

Sub-system

This model does not impose any restrictionon the number of sub-systems that form ane-money system.

3 The term System Supervisor is used within the specific contextof this document and does not relate to the Banking Supervision

Authority.4 This definition is taken from Directive 2000/46/EC of the

European Parliament and of the Council of 18 September 2000on the taking up, pursuit of and prudential supervision of businessof electronic money institutions.


10/45


5 The sub-systems are also subject to other restrictions that will be

explained in the section entitled Transactions.6 Sub-systems need only have the capability to do this upon

request from the System Supervisor; there is no requirement tohave full traceability at all times.

7 AD are data sent to the EV Issuer upon EV creation and extinguishment.

The sub-system notion is intentionally flexible.A sub-system is generally defined by itscapability to: 5

send or receive EV amounts; generate Report ing Data (RD); make this data available (direc tly, or

indirectly via other sub-systems) to theSystem Supervisor on request, therebyallowing EV exchanges to be traced. 6

Furthermore, the System Supervisor isresponsible for monitoring the sub-systems.

A sub-system may be able to aggregate EVreceived into a single amount, the value of which equals the sum of the amountsreceived. Conversely, the EV amount storedin a sub-system may be broken into smalleramounts, the sum of which equals the valueof the EV amount stored.

1.1.2 Examples of e-money systems

The general model is in principle applicableto any type of e-money system, whether card-based or software-based (including server-based/network-based types). An example of both types is illustrated below.

Card-based system

In a card-based system, the sub-systems whichparticipate in the EV flow generally consist of four entities or functions: a loading agent, acustomer, a merchant and a collecting agent.The loading and collecting agents are banksparticipating in the system and the customeruses a smart card to pay at the terminal of the merchant. The customers purse (thesmart card) is a simple, stand-alonesub-system, while the point-of-sale (POS)terminals and the central information systems

to which they are connected constitute amore complex sub-system.

In this example, there is a central entity whichissues EV and operates as a bookkeepingentity to which the creation andextinguishment of EV is reported viaAccounting Data (AD) 7.

Figure 2Example of a card-based system

Reporting Data

EV circulation

Accounting Data

Loading

Payment

Collection

SmartCard Terminal

Loading Agent(Bank)

Customer

Collecting agent(Bank)

Merchant

Bankserver

Bankserver

Bank

SystemSupervisor


Bank

EVIssuer


11/45


Server-based system

In a server-based system, the customer andthe merchant do not keep the EV in devicesheld in their possession. The EV is stored incustomer and merchant accounts on serversaccessed via the internet. The customer andmerchant sub-systems are therefore softwareprocesses running on the central server.

The general model also covers these types of e-money systems, in view of the specificity of the use of centrally stored accounts.

1.1.3 Additional concepts: compensation,transactions, EV life cycle, roles,actors, and quasi-actors

Compensation (CP)

Typically, seen as a model, an e-money systemhas two flows, i.e. the flow of EV (the solidline from left to right in Figure 4) and theflow of value to compensate the EV (thedotted line from right to left).

Figure 4Flows of EV and compensation

EV flow

compensation

SystemSupervisor

The obligation to deliver CP may be fulfilledeither immediately or at some prior point inthe past or in the future. In the case of goodsor services, the related amount might not beknown from the start and may be defined, by

joint agreement, in the course of theprovision of these goods or services.

Figure 3Example of a server-based system

Accounting Data

Customer

Loading

Payment

Collection

WalletWallet

Bank Bank

Merchant

Paym.gateway

Bankserver

EVIssuerBank

SystemSupervisor


Remote access

Customer Merchant

Reporting Data

EV circulation


12/45


8 Elementary operations are executed sequentially. No assumptionis made about their order, other than those explicitly stated.

9 The EV amounts debited and credited are equal.10 This refers to an e-money balance refund.

Transaction CP Shorttype description

Supply with With CP Supplies a loading devicecreation with EV

Loading With CP Loads stocked EV intoa device

Loading with With CP Loads EV into a devicecreation without any need for the

EV to have beenpreviously supplied andstocked

Refund 10 With CP Unloads all the EV storedin a device

Payment With CP Pays for goods or serviceswith EV stored in a device

Collection with With CP Unloads and destroys EVextinguishment received in payment for

goods or services

C ol lecti on With CP Un loads E V received inpayment for goods orservices

Presentat ion With CP Redeems and destroyswith collected EVextinguishment

R ecyc ling Wi th out M odi fie s col lec ted EV soCP that it can be loaded into

devices

Cancellat ion With CP Reloads paid EVof paymenttransaction

Table 1Examples of transactions in ane-money system

Transactions

A transaction is defined as a flow of EV.

The following basic operations and attributesconstitute the minimum characteristics whichmust be present for transactions:

Basic operations constituting EVtransactions 8:

init ialisation; EV debiting; EV credit ing; closure.

Attributes characterising a transaction: the transaction type (payment, loading,

collection, etc.); the identifier of the sub-system from which

EV is debited (hereafter debited sub-system);

the identifier of the sub-system to whichEV is credited (hereafter credited sub-system);

the EV amount exchanged (debited andcredited); 9

the existence of CP.

The RD generated upon request to allow theSystem Supervisor to monitor the systeminclude at least the transaction attributeslisted above.

Two types of transactions can bedistinguished:

A transact ion which involves an interaction

between flows of both exchanges of EVand CP is called a transaction with CP.

Transactions with CP are generated againsta flow of value in return. This may consistof a flow of fiduciary or scriptural moneyas well as of goods or services. A purchasetransaction based on an e-money paymentis an example of a transaction with CP.

A transaction without this interact ionbetween the two flows is called atransaction without CP.

Transactions without CP involve an EVcirculation that is not balanced by acorresponding flow of value. Recycling of EV is a typical example of a transactionwithout CP.

The table below presents, as a rough guide, anon-exhaustive list of the types of transactionsthat can occur in e-money systems:


13/45


11 The existence of an obligation for the player credited to deliver,either immediately or later, represents a CP to the player debited, i.e. for every transaction with CP, a contractual commitment relates the CP to the exchanged EV amount.

12 Depending on the organisation of the e-money system,transactions between two sub-systems may also exist withoutCP.

A particular specification of the model is thatthe System Supervisor 11 must be able tomonitor transactions between two sub-systems. Transactions inside a sub-system arenot monitored by the system supervisor. Sub-systems must be defined so that flows withcompensation are made outside of these sub-systems.

In an e-money system conforming to themodel, the EV amount created is equal to thesum of the extinguished EV amount and theEV amount in circulation. If more EV is

extinguished than the amount created, falseEV is introduced into the system. One role of supervision is to try to detect such a situation;

observing all transactions with compensationmakes it easier to perform such supervision.

EV circulates inside a sub-system viatransactions without CP. Generally, EVcirculates between two sub-systems viatransactions with CP. 12

Figure 5Transactions inside and outside of sub-systems

SystemSupervisor

SystemSupervisor


14/45


13 The debited sub-system is the sub-system which will be debited.For example, in a card-based system, the first debited sub-system is the loading agent. In a loading transaction, the loading agent is debited and the purse is credited.

EV life cycle

In the e-money system, the EV life cyclemoves through the following EV states:

1. initial (or source) state, in which EV isinjected in the system;

2. one or more active states, in which EVremains in the system;

3. final (or sink) state, in which EV is drainedfrom the system.

The EV life cycle evolves through three statechanges: creation, circulation andextinguishment, each of which is associatedwith a transaction.

EV creation

EV is created via specific transactions withCP, which include two additional basicoperations:

creation of an EV amount in the debitedsub-system; 13

transmission, to a player called the EVIssuer, of AD, which report the EV creat ionand initiate the obligation of the actorwhose sub-system created the EV todeliver an equivalent amount (i.e. the CP)to the EV Issuer.

With this state change, EV enters the

system and reaches an active state.

EV circulation

EV circulates inside a sub-system (viatransactions without CP) and between twosub-systems via transactions with CP.

With this state change, EV moves betweentwo active states.

EV extinguishment

EV is extinguished via specific transactionswith CP, which include two additional basicoperations:

extinguishment of an EV amount in thecredited sub-system;

transmission to the EV Issuer of AD, whichreport the EV extinguishment and giveeffect to the obligation for the EV Issuerto deliver an equivalent CP amount to the

player whose sub-system extinguished EV.

With this state change, EV leaves thesystem.

Throughout the remainder of thisdocument, transactions do not include EVcreation or extinguishment unless this isexplicitly stated.

Figure 6 describes, as a rough guide, theEV life cycle in an e-money system, i.e. thetransitions from one state to anotherresulting from transactions with CP typicalof an e-money system. The initial state isthe creation of EV, after which this isloaded on the customers purse (i.e. on asmart card or computer memory). Thisloading may take place directly from theissuer to the customer or, alternatively,through a bank or Electronic MoneyInstitution (ELMI; as defined in Directive2000/46/EC) where the EV may be kept in

stock before being loaded on the purse.The customer can decide either to makepayments with the EV or to refund the EVto the issuer. A payment may also be


15/45


Figure 6Different EV states in an e-money system

Transaction State changeSupply EV creation

Loading-1 EV creation Loading-2 EV circu lation Refund EV circula tion

Payment EV circulationCancellation EV circulationCollection EV circulation

Recycling EV circula tion Restitution EV extinguishment

14 The players responsibility for a sub-system implies that the hehas control over, and takes care of, the sub-system concerned.

15 Liquidity risk refers to the risk that the institution is temporarily unable to meet its payment obligations.

16 Compliance risk refers to the risk associated with non-compliance with laws, rules, regulations, prescribed practicesor ethical standards.

17 Reputation risk refers to the risk that the reputation of aninstitution might deteriorate following specific events.

In Stock

Initial state

Final state

AcceptedLoaded

Supply

Payment

Loading-1 Loading-2

Refund

Collection

Restitution

Cancellation

Recycling

Active state

State change

cancelled, after which the EV is transferredback to the purse. The acquiring bank orELMI ultimately collects the EV and eitherkeeps it in stock to recycle and reload ona purse or else extinguishes it and therebycompletes its life cycle.

Roles, actors, quasi-actors

Setting objectives for an e-money systemrequires the definition of a general securityframework, which includes organisationalstructure, policies, planning activities,responsibilities, practices, procedures,

processes and resources.

In this report this challenge is addressedby allocating responsibility to those whocan most efficiently reduce the risk: systemadministrators and operators.

The model takes into account all playersthat are relevant for security and grantseach a certain trust level. The co-operationof all players involved in the system isessential for globally effective security.

A player having responsibility 14 for a sub-system is referred to in this document as

an actor. The model defines theresponsibilities of the different actors, eachbeing responsible for a sub-system in theEV circulation. An actor is directly involvedin the exchange of EV (e.g. EV Issuer,Loading Agent, etc.).

A player that is not responsible for a sub-system is defined as a quasi-actor. A quasi-actor does not interact directly in theexchange of EV (e.g. IT provider, etc.).

Different roles for actors and quasi-actors

are distinguished. The concept of role isrelated to players responsibilities. Theirrespective roles depend on skills, businessobjectives and the level of risk that theyassume. A specific task and a particulartrust level are associated with each role.

The roles defined in this report areAdministrator, Operator and User:

AdministratorThe Administrator is responsible for definingand managing the overall security of the e-money system. This means defining thepolicy statement, identifying risks, selectingsecurity controls and managing theimplementation and operation thereof.Generally the Administrator bears all lossesof the system and it is assumed that relevantlegislation applies strict requirements toAdministrators, for example as regards thecompanys activities, its financial stability,recruitment policy, accounting practices,

access to its premises, access to data anddata processing. Main risks incurred by anAdministrator could be: i) liquidity risks 15;ii) compliance risks 16 and iii) reputationalrisks17. The Administrator enjoys a high trustlevel because he bears the ultimateresponsibility for security.


16/45


Table 2Examples of players in a card-basede-money system

Actor Role Short description

EV Issuer Administrator Issues and guaranteesEV

Loading Operator Loads EV onto aAgent device

Acquirer Operator Collects EV fromService Providers

EV Holder User Pays in EV through a(Purse Holder) device (Customer)

Service User Accepts payments inProvider EV (Merchant)(Merchant)

Quasi-actors Role Short description

System Administrator Monitors the flow of Supervisor EV

IT Provider Operator Provides ITinfrastructure to thee-money system

18 Operational risk refers to the risk that deficiencies in internal controls and information systems might result in unexpected losses.

OperatorThe Operator participates inimplementing and operating the securityof the e-money system. Generally theoperator is bound to an Administrator bycontractual obligations. Moreover anOperator must comply with relevantlegislation and best practices,requirements that, although similar tothose which apply to an Administrator,are less stringent. Main risks incurred byan Operator could be: i) operationalrisks18; ii) compliance risks and; iii)

reputational risks. He enjoys a moderatetrust level, because the operator isresponsible for security implementationunder the Administrators co-ordination.

UserA User is a customer of the e-moneysystem contractually bound to anOperator. The contract does not requirethat the User implements procedureswhich contribute to technical security.However, it does require that he/she usesapproved devices and follows the rightsecurity procedures. Main risks incurredby Users could be: i) frauds in EVtransactions; ii) fraud in EV storage andiii) privacy breaches. To ensure simple,friendly and cost effective system usability,only a few, user-friendly securityobligations should be assigned to theUser. As a result, Users enjoy a low trustlevel, leaving the main security-relatedmanagement and operating tasks to

Administrators and Operators.

Thus, the trust level granted toAdministrators is greater than that grantedto Operators, which in turn is greater thanthat granted to Users.

When a player subcontracts part of hisactivity in the e-money system, he passesthe relevant e-money system obligationson to his subcontractor.

A player may have more than one role in

relation to the same device, depending onthe transaction(s) being performed. Inevery instance, the player enjoys the trustlevel corresponding to the role he plays ata given time (i.e. the players trust levelmust be consistent with his role at alltimes).

All roles are carried out by identifiedplayers, with the possible exception of theEV Holder, who can remain anonymous.

The tables below present, as a rough guide,a non-exhaustive list of actors and quasi-actors, together with their typical roles incard-based and software-based systems. Aplayer may incorporate several actors/roles, e.g. a player may be both an EVIssuer (and play the role of Administrator)and an IT Provider (and enjoy the trustlevel of Operator).


17/45


Actor Role Brief description

EV Issuer Administrator Issues and guaranteesEV

Loading Operator Loads EV onto aAgent device

Acquirer Operator Collects EV fromService Providers

EV Holder Operator Pays in EV through(Customer its account

account) (Customer)Service Operator Accepts EV paymentsProvider in its account(Merchant (Merchant)account)

Quasi-actors Role Short description

System Administrator Monitors the flow of Supervisor EV

IT Provider Operator Provides ITinfrastructure to thee-money system

Customer (outside of The Customerthe TOE) accesses his/her

account fromoutside the system

Merchant (outside of The Merchant t he TOE) accesses his/her

account fromoutside the system

Table 3Examples of players in asoftware-based e-money system(see also Figure 3)

Generally, the IT Provider provides the actorswith a functional e-money system, i.e. heprovides the Information Technologies (IT)for all of the sub-systems, especially the Purse

Holders device application.

The System Supervisor and the IT Providerare quasi-actors, as they are not responsiblefor sub-systems through which EV circulates.Nevertheless, the System Supervisor enjoysan Administrator trust level, and the ITProvider an Operator trust level.

1.1.4 Interoperability of two e-money systems

This section explains how to apply the modeldefined above in cases where several e-money

systems interoperate. Two possible cases areconsidered: composition of systems, andsharing of a sub-system between e-moneysystems.

Composition of two e-money systems

In a situation where EV circulates betweenseveral sub-systems which belong to differente-money systems, the set of all sub-systemsbelonging to each e-money system should beregarded as another e-money system under

the responsibility of a System Supervisor.

Thus, this situation is covered by the modeland will not be mentioned further in thisdocument.

Figure 7 Composition of two e-money systems

Global system

EV creation

EV extinguishment

SS

SSSystem 1 SS System 2

When there is commercial interoperabilitybetween several e-money systems, whichall comply with the definition given in thisEMSSO, the interoperable elements of thesystems constitute another e-moneysystem compliant with this EMSSO only if there is a global System Supervisor whomonitors the security of all EV. In practice,the System Supervisors could carry outglobal supervision jointly, either on a co-operative basis or by mutual acceptance of an appropriate contractual agreement.


18/45


Figure 8Shared sub-system

19 Interoperability with shared sub-systems may be achieved by

defining the security and functional aspects of the sub-systems.For example, the Common Electronic Purse Standards (CEPS)specifications describe the technical (functional) interoperability requirements for sub-systems of card-based systems.

20 Including the links between the sub-systems.

SystemSupervisor

SystemSupervisor

Sharing of a sub-system

A sub-system may be shared with one orseveral other systems, not all of which neednecessarily be e-money systems. In suchcircumstances, the shared sub-system isregarded as any other sub-system, regardlessof the other system(s) in which it takes part.

For example, the terminal infrastructurecould be shared by two or more differentcard-based e-money systems that use thesame technology but do not share the EV. 19

1.2 Target Of Evaluation

The Target Of Evaluation (TOE) is generallydefined as the part of the system that will beevaluated. The definition of the Target Of Evaluation is based on the e-money system as

elaborated in the previous section.

According to the Common Criteria, theelements that are not part of the TOE (butare necessary to the TOE to satisfy itssecurity objectives) are called the TOEenvironment. For evaluation, the TOE mustbe run in an environment that is compliantwith the security objectives for theenvironment.

1.2.1 Elements that are part of the TOE

Model

The model, as defined in the previous section,is part of the TOE: Sub-systems EV circulation 20 RD flows and system supervision

A sub-system can be composed of one ormore hardware and/or software device(s).

For each device in each sub-system, the TOEincludes the following phases: initialisation(including the personalisation and activationof the device), operation and termination.

Several kinds of security devices can beidentified: the security module of the servers that

store and process sensitive data relating tothe whole e-money system (e.g. personaldata, secrets) which must be kept secure;

the devices that store and process sensitivedata which relate to only one sub-system(e.g. derived keys);

the security enclosures of intermediarydevices, such as manned or self-serviceterminals, that store and process sensitivedata which may relate to the wholee-money system or to only one sub-system.

Transactions

The TOE comprises the following

transactions: creation; loading; payment; collection; refund; exinguishment.


19/45


Actors and quasi-actors

The TOE includes the following actors/quasi-actors: the Loading Agent; the Acquirer; the EV Holder; the Service Provider; the System Supervisor; the EV Issuer; the IT Provider.

1.2.2 Elements that are outside the TOE

In general, all aspects that are not in the TOEare part of the TOE environment.

System development and manufacturing(before EV creation), together with theclearing and settlement procedures (whichtake place after EV extinguishment), areoutside the scope of the TOE, and are alsonot considered part of the environment.Development and manufacturing may becovered by dedicated PPs.

The compensation flows are not part of theTOE.


20/45


21 Source: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model (1998),paragraph 120.

22 Source: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model (1998),Paragraph 71: Data created by and for the User that does notaffect the operation of the TSF.

2 TOE security environment

This section aims to describe the TOEsecurity environment, which, as defined inthe Common Criteria 21, describes the securityaspects of the environment in which the TOEis intended to be used and the manner inwhich it is expected to be employed.

The TOE security environment descriptionincludes:

a statement of assumptions that are to be

met by the TOE environment in order forthe TOE to be considered secure. Thisstatement can be accepted as axiomaticfor the TOE evaluation.

a statement of threats to the security of the assets, identifying all the threatsperceived by the security analysis asrelevant to the TOE.

The CC characterise a threat in terms of athreat agent, a presumed attack method,any vulnerabilities that form the foundationfor the attack, and identification of theasset under attack. An assessment of risksto security would qualify each threat withan assessment of the likelihood of such athreat developing into an actual attack, thelikelihood of such an attack provingsuccessful, and the consequences of anydamage that may result.

a sta tement of applicable organisat iona l

security policies, identifying relevantpolicies and rules.

In order to establish the TOE securityenvironment the following have to be takeninto account: the TOE physical environment,the assets requiring protection by theelements of the TOE to which securityrequirements or policies will apply and theTOE purpose, which would address theproduct type and the intended usage of theTOE.

The assets to be protected are:

all hardware and software that are relatedto the TOE Security Function (TSF) (e.g.chip of a smart card);

data used by the end-user (User data) 22

(data for the normal operation of thesystem):

the data which result in EV crea tion andthe data which result from its

extinguishment;For example, these could be the datarelating to a request for authorisationto create EV in real time while loadingan e-money system; they could also bethe data that define, within a sub-systemdedicated to EV creation, the terms andconditions applying to supplying EV to aloading sub-system.

the at tributes of a transaction, especiallythe EV exchanged between two sub-systems and stored in a sub-system;

the Accounting Data (AD);

the parameters of the sub-systems,including access data where these arerelevant;These are the data that define the limitswithin that a device operates (forexample, the frequency of a periodicprocess or limits such as the maximum

and minimum amounts). Access dataallows access to the sub-system (e.g.identification data);


21/45


23 Source: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model (1998),Paragraph 68: Data created by and for the TOE that mightaffect the operation of the TOE.

24 The Organisational Security Policies (Section 2.3) cover themonitoring of all relevant events taking place between sub-systems.

the System Supervisor information.These are the data obtained from RDprocessing and centralised by theSystem Supervisor, some of whichmight be sensitive in terms of amalicious or excessive use of thesystem;

TSF data 23 (data for security mechanisms):

the RD intended for the SystemSupervisor;

the secre ts.Secrets refers to cryptographic keys,passwords, authentication data, etc.

2.1 Assumptions

Assumptions describe the security aspects of the environment in which the TOE will beused or is intended to be used. This includesthe following:

information about the intended usage of the TOE, including such aspects as theintended application, potential asset valueand possible limitations of use;

information about the environment of useof the TOE, including physical, personneland connectivity aspects.

The following assumptions are made:

All actors and quasi-actors know and fulfil

their own contractual obligations (as wellas their reciprocal obligations) with regardto regulations, finances and security.[A.Responsibility]For example, the card-based system is notrequired to protect the Purse Holderagainst theft of his card. A contractdescribes the Purse Holders obligationsand benefits.

All actors and quasi-actors have sufficientmeans, training and information to performtheir functions. [A.Competence]

This heading would typically includedocumentation (specifications, user manual,maintenance manual, operational rules,etc.), regular updates of thedocumentation, regular training and regulardrills simulating exceptional events.

When a sub-system under the responsibilityof an Administrator or System Supervisorincludes security devices, those devices arelocated in a physically protected (or trusted)environment. [A.Trusted_Location]

RD accurately reflect transactions with CP.AD accurately reflect transactions with EV

creation or extinguishment. [A.Data]Coherence is required between the variousdata relating to a single event in the system.It is assumed that specific securitymeasures enforce coherence betweentransaction data and corresponding RD andAD.

All security relevant events within a sub-system are traced. 24 [A.Log]

2.2 Threats

This section describes the threats to theassets against which specific protection withinthe TOE or its environment is required. Notethat not all possible threats that may beencountered in the environment need to belisted, only those that are relevant for secureTOE operation.

2.2.1 Threat agents

The e-money system must protect itself against all types of attackers, regardless of whether they are staff, users or partiesexternal to the system.


22/45


25 As opposed to natural EV losses, which would result from theaccidental loss or destruction of cards.

Attackers fall into four classes, according totheir objectives:

swindlers who attempt to penetra te thesystem or to misuse some of its functionsfor financial profit;

vandals , saboteurs or, in an extreme case,terrorists who attempt to destroy all orpart of the system;

hackers who attempt to demonstrate theirknow-how with regard to the security of the system;

those who misuse the system in order to

facilitate the commission of illegal acts;

The e-money system must also protect itself against inadvertent malfunctioning as a resultof carelessness.

2.2.2 Threats list

Creation of fake EV

This category covers all circumstances inwhich it might be possible for an attacker toobtain CP in exchange for fake EV, i.e. EVthat does not represent an EV Issuer debt.

Attacks in this category resort to classicalmethods such as forgery (fake amounts of EV), illicit repudiation (illicit denial of atransaction, or part of a transaction, with theintention of being improperly credited withEV as a result).These threats directly affect the financial

equilibrium of the EV Issuer.

Creation of fake EV can result from thefollowing:

unauthorised third parties gainingknowledge of secrets of the sub-system;[T.Disclosure_Creat]

modificat ion of transaction attributes,AD and data related to EV creationand extinguishment, or secrets;[T.Modification_Creat]

the usurpa tion of anothers privilegesthrough the misuse of secrets;[T.Usurpation_Creat]

the creation of fake transactions byduplication of authentic attributes orauthentic AD, duplication of parameters of a sub-system, or duplication of data relatingto EV creation or extinguishment extractedfrom an authentic transaction. Similarly, thecreation of fake transactions with falseattributes, false AD, or false data relatingto EV creation or extinguishment;[T.Counterfeiting_Creat]

a players illicit denial of his part icipationin all or part of a transaction, if accepted(e.g. A quasi-actors illicit denial of initiation

of the transaction). [T.Repudiation_Extin]

Illicit extinguishment of EV

This category covers all attacks or incidentsthat lead to an abnormal 25 and irrevocable EVloss.

These attacks benefit the EV Issuer byreducing his debt, but constitute a majorthreat to the credibility of the system andcan lead to numerous disputes.Attacks perpetrated by criminals rely onlogical destruction (erasure of programs,viruses, scrambling), forgery (creation of fake amounts of EV).

Illicit extinguishment of EV can result fromthe following:

unauthorised third parties gainingknowledge of sub-system secrets;

[T.Disclosure_Extin] the modification of transaction att ributes,

AD, data related to EV creation andextinguishment, or secrets;[T.Modification_Extin]

the usurpa tion of anothers privilegesthrough the misuse of secrets;[T.Usurpation_Extin]

the creation of fake transactions byduplication of authentic attributes orauthentic AD, duplication of parameters of


23/45


a sub-system, or duplication of data relatingto EV creation or extinguishment extractedfrom an authentic transaction. Similarly, thecreation of fake transactions with falseattributes, false AD, or false data relatingto EV creation or extinguishment.[T.Counterfeiting_Extin]

Embezzlement of EV

This category covers all attacks in which oneactor embezzles EV from its legitimate owner.

These attacks do not affect the financialequilibrium of the EV Issuer.Actors perpetrate attacks in the system withmalicious intent to defraud. They resort tosubstitution, diversion, or the use of covertcommunication channels in the system.

Embezzlement of EV can result from thefollowing:

transferring, during a transaction with CP,an EV amount differing from the amountagreed in the contractual commitment;[T.Modification_Embez]

repeating an authentic transaction withoutany contractual commitment other thanthat of the original transaction.[T.Replay_Embez]

EV theft

This category covers all opportunities for anattacker to steal EV. 26

These attacks do not affect the EV Issuersfinancial equilibrium.Attacks result in transactions in which thecontractual commitment with regard to CP isnot honoured. They resort to swindling whenthe transaction is being carried out.

26 Theft of EV indicates that, during a communication, the EV isrouted to a place unknown to the User. Theft could be compared with EV embezzlement, but in the latter event the EV is routed to a place known to the User, e.g. an internet site which does notdeliver the goods/services required.

EV theft can result from the following:

the illici t modification of transactionattributes, AD, data related to EVcreation and extinguishment or secrets;[T.Modification_Theft]

the usurpation of anothers privilegesthrough the misuse of secrets.[T.Usurpation_Theft]

Abuse of the e-money system

This category arises from the use of thee-money system for the purposes of infringingregulations unrelated to the system.

These attacks do not affect the EV Issuersfinancial equilibrium or the EV/CP equilibriumof transactions.Examples of such threats are moneylaundering, the withdrawal of capital andbreaches of privacy.

Abuse of the e-money system can result fromthe following:

the use of RD or Sys tem Superv isorinformation for purposes other thanmonitoring the e-money system, orunauthorised third parties gainingknowledge of sub-system secrets;[T.Disclosure_Abuse]

the illici t modificat ion of sub-systemsparameters, System Supervisor informationor a secret; [T.Modification_Abuse]

the usurpation of anothers privilegesthrough the misuse of secrets.[T.Usurpation_Abuse]


24/45


25/45


from whom EV is debited enjoys a lowertrust level than the actor to whom EV iscredited (e.g. in the case of a refund of EV), EV is transferred before the CP thatfulfils the obligation of the actor to whomEV is credited. When the actor to whomEV is credited enjoys a lower trust levelthan the actor from whom EV is debited(e.g. in the case of loading of EV), EV istransferred after the CP that fulfils theobligation of the actor to whom EV iscredited. [OSP.Sequence]

All of the secrets used in the TOE have a

limited life span in accordance with theirusage and are renewed when required.[OSP.SecretLifespan]

The security level is maintained during thelife cycle of the devices through securityupdates. This includes the maintenance of hardware and software necessary for thefunctioning of the e-money system.[OSP.Maintenance]

All of the secrets can be replaced. Sub-systems can be replaced either in whole or

in part. Replacement must be performedin such a way as to minimise the impact onservice availability. [OSP.Evolution]

There is a technical and organisational end-of-life procedure for every devicecontaining EV. This procedureincludes[OSP.EVPresentation]:

presentation and ext inguishment of EV; communication of RD to the System

Supervisor; communication of AD to the EV Issuer.

Authorised and identified personnelperform the installation, initialisation,

administration and operation of all sub-systems. The TOE enforces organisationaland technical procedures that restrictaccess to assets to authorised personnel.[OSP.Access]

Every sub-system preserves the integrityof the stored amount of EV. The maximumEV amount that can be debited from a sub-system must not exceed the EV amountwith which it has been credited.[OSP.Equilibrium]


26/45


Figure 9Security objectives derivation

TOE

Environment

Assumptions

Threats

Policies

EstablishSecurity

Objectives

SecurityObjectives

28 The transaction domain focuses on the dynamic aspect of theRD, i.e. sending of the RD to the System Supervisor. Themonitoring domain (see below) focuses more on the non-dynamic aspect, i.e. on use by the System Supervisor of the RD and theSystem Supervisor information.

29 Monitoring is related to the operation and handling of RD and System Supervisor information by the System Supervisor. Thedynamic side is covered in other domains.

3 Security objectives

This section defines the security objectivesfor the TOE and its environment. The securityobjectives aim at countering the identifiedthreats and at addressing identifiedorganisational security policies andassumptions (see Annex F for a cross-reference table).

3.1 Classification of security objectives

3.1.1 Security objectives for the TOE or theenvironment

The purpose of determining securityobjectives is to address all of the securityconcerns and to declare which securityaspects are addressed either directly by theTOE or by its environment. Thus, the securityobjectives are of two types: security objectives for the TOE, traced

back to aspects of identified threats to becountered by the TOE and/ororganisational security policies to be metby the TOE;

security objectives for the environment,traced back to aspects of identified threatsnot completely countered by the TOEand/or organisational security policies orassumptions not completely met by theTOE.

3.1.2 Application domains

The scope of the security objectives isspecified on the basis of domains. Thefollowing domains are defined:

E-money System (SYS): These objectivesconcern the whole e-money system.

Secrets (SEC): These objectives concernkeys, passwords and authentication data,as well as their management: generation,deletion, revocation, distribution, storageand use.

Transactions (TRANS): These objectivesconcern the transaction domain, i.e. basicoperations, the devices of the sub-systemsinside or between which EV circulates, theactors in charge of those sub-systems andthe following assets:

transaction attributes, especially the EVexchanged between two sub-systemsand stored in a sub-system;

the functional parameters of sub-systems;

RD generated for a transaction andcommunicated to the SystemSupervisor. 28

EV creation and extinguishment (CREXT):These objectives concern the elementsdedicated to EV creation andextinguishment, i.e. basic operationsdedicated to EV creation orextinguishment, related sub-systems,actors in charge of those sub-systems andthe following assets:

the data which result in EV creation andthe data which result from itsextinguishment;

the parameters related to EV creation orextinguishment;

AD genera ted for a transaction andcommunicated to the EV Issuer.

Monitoring (MON): These objectivesconcern the RD and the System Supervisorinformation. 29


27/45


3.1.3 Naming convention

The security objectives below are named asfollows:

OT|OE..[.],where :

OT|OE indicates whether the objectiveconcerns the TOE (OT) or theenvironment (OE).

is one of SYS, SEC,TRANS, CREXT and MON.

indicates the generalobjective under which this objective isclassified.

is an opt ionalrefinement for this objective

3.2 Security objectives list

A list of 24 Security objectives in presentedbelow.

Each security objective is first introduced in ageneral manner, then broken down intospecific objectives for the various domains.

3.2.1 Integrity [INT]

The integrity of the assets is preserved, inparticular EV amounts.

Every sub-system preserves the integrity

of the stored EV amounts. [OT.SYS.INT.EVSTORAGE]

Only authorised transactions can modifythe EV amount stored in a sub-system.[OT.SYS. INT.EVTRANSAC]

For every transaction the EV amountdebited from one sub-system equals theEV amount credited to the other.[OT.TRANS. INT.EQUALITY]

The EV amount created or extinguishedequals the EV amount exchanged in therelated transaction.[OE.CREXT. INT.EQUALITY]

3.2.2 Confidentiality [CONF]

The assets that must remain confidential arepreserved accordingly.

The TOE preserves the confidentiality of all secrets. [OT.SEC.CONF.SEC]

The TOE preserves the confidentiality of the System Supervisor information.[OT.MON.CONF.SSI]

RD and the System Supervisor informationare known solely by those with a need toknow.

[OE.MON.CONF.NEEDTOKNOW]

3.2.3 Identification [ID]

An unambiguous identification is required forsome components of the e-money system

Each of the following elements of the TOE isunambiguously defined by a unique identifier[OT.SYS.ID].:

the System Supervisor; the EV Issuer; the sub-systems and, through them, the

actors in charge of each sub-system; the transactions; the transaction types; the secrets; the quasi-actors (if applicable).

3.2.4 Authentication [AUTH]

EV transactions and monitoring dataexchanges are authenticated.

For each transaction the sub-systemdebited with EV and the sub-systemcredited with EV authenticate each other.[OT.TRANS.AUTH.SUBSYS]

For each transaction, the sub-systemcredited with EV authenticates the EVstemming from the debited sub-system.[OT.TRANS.AUTH.EV]

For each transaction, the sub-systemdebited with EV delivers proof of itsparticipation in the transaction to the sub-


28/45


29/45


30 In a timely manner refers to the time needed to allow processing of data to meet all deadlines relevant to the process

goal.

3.2.9 Non-evaporation [EVAP]

Only authorised sub-systems can performextinguishment transactions.

The TOE rest ricts EV extinguishment totransactions between two authorised sub-systems of the TOE. [OT.CREXT.EVAP]

3.2.10 Limitations [LIM]

EV amounts are limited during the EV life

cycle.

For each sub-system, parameters set are: the maximum EV amount which the sub-

system can store; the maximum EV amount which can be

exchanged in a transaction; the maximum EV amount which can be

created in a transaction. (This relates onlyto the issuing sub-system.)

[OT.SYS.LIM.EVLIMITS]

3.2.11 Traceability [TRAC]

The System Supervisor is able to trace andaudit all strategic events. Sub-systems recordand keep the data required by the SystemSupervisor for as long as required. Traceabledata accurately reflects recorded events.

The generation, deletion, revocation andreplacement of secrets are strategic events:

these events are recorded in order thatthey can be audited by the SystemSupervisor. [OT.SEC.TRAC.AUDIT]

The initialisation and the modification of the sub-systems functional parameters arestrategic events. These events are recordedso that they can be audited by the SystemSupervisor. [OT.TRANS.TRAC.AUDIT]

Initia lisation and modification of theparameters relating to EV creation andextinguishment are strategic events. Theseevents are recorded in order that they canbe audited by the System Supervisor.[OT.CREXT.TRAC.AUDIT]

The TOE provides means, when required,to communicate RD to the SystemSupervisor in a timely manner. 30[OT.TRANS.TRAC. TIMELY]

Every sub-system that produces RD forthe System Supervisor keeps, for as longas required, a record of the transactionsthat it has performed and a record of theRD to be communicated to the SystemSupervisor. [OT.TRANS.TRAC.RECORD]

RD accurate ly ref lec t transactions.[OT.TRANS.TRAC.TRUE]

Every sub-system that produces AD keeps,

for as long as required, a record of the ADcommunicated to the EV Issuer.[OT.CREXT.TRAC.RECORD]

AD accurately reflect transactions involvingEV creation or extinguishment.[OE.CREXT.TRAC. TRUE]

3.2.12 Detection [DETECTION]

The system has the capability to:

detect abnormal events, including actualor attempted modification of assets andcounterfeiting of transaction attributes;

communicate to the Systems Supervisorall information which traces theseabnormal events.

In particular:

The TOE provides means to detectattempted or actual occurrences of illicit

access to secrets, modification or illicit useof secrets. [OT.SEC.DETECTION]

The TOE provides means: to detect attempted or actual

occurrences of modification of thetransactions domain assets;

to detect attempted or actualoccurrences of transaction attributecounterfeiting;

to provide RD to the System Supervisorto enable these abnormal events to betraced to their source;


30/45


31 The SOF qualification of a TOE expresses the minimum effortsassumed necessary to defeat a systems expected security behaviour by directly attacking its underlying security mechanisms.In the Common Criteria framework, the SOF and its level (high,medium and low) are not part of the security objectives.

to detect attempts to replay authentictransactions (or a part thereof).

[OT.TRANS.DETECTION] The TOE provides means to detect

attempted or actual occurrences of modification or counterfeiting of thecreation and extinguishment domain assets.[OT.CREXT.DETECTION]

The TOE provides means to detectattempted or actual occurrences of illicitaccess and modification of the monitoringdomain assets. [OT.MON.DETECTION]

3.2.13 Reaction [REACTION]

The system provides means to limit or undothe consequences of an abnormal or illicitaction.

The TOE provides means to ensure servicecontinuity by limiting the consequences of illicit access to secrets, modification orillicit use of secrets. [OT.SEC.REACTION]

The TOE provides means to implementthe reactions ordered by the SystemSupervisor to limit or suppress the effectsof a detected or suspected malfunctionin relation to the assets.[OT.TRANS.REACTION]

The TOE cancels every transactioninvolving a malfunction.[OT.TRANS.REACTION.UNDO]

The TOE provides means to implementthe reactions ordered by the SystemSupervisor to limit or suppress the effects

of a detected or suspected malfunction.[OT.CREXT.REACTION]

The TOE provides means to react againstattempted or actual occurrences of modification or counterfeiting of themonitoring domain assets.[OT.MON.REACTION]

3.2.14 Cryptography and protocols [CRYP]

State-of-the-art cryptography, protocols andsecurity procedures are required.

The security architecture of the TOE isbased on standardised, publicly andextensively reviewed, state-of-the-artcryptographic algorithms and cryptographickey management. The TOE does not usecryptographic algorithms, which mustremain confidential for security reasons.[OT.SYS.CRYP.CRYPTO]

The SOF 31 for the use of cryptography andprobabilistic mechanisms must be high.[OT.SYS.CRYP.SOF]

The communication architecture of theTOE is based on standardised protocols

and security procedures.[OT.SYS.CRYP.PROTOCOL]

3.2.15 Secret management [MNG]

The confidentiality and integrity of secrets ispreserved by correct generation anddistribution, physical storage protection,limited life span and renewal.

The TOE generates and distr ibutes secretsin accordance with standardisedprocedures.[OT.SEC.MNG.INITIALISATION]

Secrets are generated in such a way thattheir value cannot be predicted.[OT.SEC.MNG.PREDICTABILITY]

Every secret has a limited life spanaccording to its usage.[OT.SEC.MNG.LIFESPAN]

The TOE provides means to generate newvalues to replace secrets at any time.

[OT.SEC.MNG.REPLACEMENT] Every secret dedicated to one security

function must only be used for thatfunction. [OE.SEC.MNG.SEPARATION]

Relevant secrets are transported andstored in devices that resist physicaltampering and interference. Relevantsecrets must never be found in clear textoutside such devices. Private and secretcryptographic keys to be used outside of


31/45


such devices must be reduced to a strictminimum and must not be essential tosecurity. Private (asymmetrical)cryptographic keys and symmetrical Masteror Root Keys in a hierarchical keystructure are essential to security.[OT.SEC.MNG.TAMPER]

All procedures and associated elementsused for generating secrets are known onlyby those with a need to know. Secrets aredistributed only to those who need them.[OE.SEC.MNG.NEEDTOKNOW]

3.2.16 Trusted path [TRUSTED_PATH]

Interaction with the system is achievedthrough protected communication means.

The TOE provides a trusted path betweenauthorised quasi-actors and sub-systems inorder to protect exchanged assets(transaction data, access data, etc.) frommodification by, or disclosure to, untrustedapplications. The trusted path is capable of ensuring that a quasi-actor is communicatingwith the correct sub-system, and vice versa.[OT.SYS.TRUSTED_PATH]

3.2.17 Trusted location[TRUSTED_LOCATION]

A physically protected environment isrequired for sensitive security devices.

Securi ty devices, when under theresponsibility of an Administrator orOperator, are located in a physicallyprotected (or trusted) environment.[OE.SYS.TRUSTED_LOCATION]

3.2.18 Competence and responsibility [RESP]

People involved in the system know andfollow their own contractual obligations, andhave sufficient means, training and informationto perform their role.

The actors and quasi-actors know andfollow their contractual obligations as wellas their reciprocal obligations with regardto regulations, finances and security.[OE.SYS.RESP.RESPONSIBILITY]

Those in charge of the following functionshave the necessary competence andexpertise in the relevant field:

management of secrets ; instal lat ion, administration and

operation of sub-systems.They have sufficient means, training andinformation to perform their role.

[OE.SYS.RESP.COMPETENCE] A state-of-the-art hiring policy, control of access to company premises and a securityawareness programme apply to thepersonnel of all companies dealing in theproduction and the distribution of devicesor software used by the TOE.[OE.SYS.RESP.PERSONNEL]

3.2.19 Qualification and tests [QUAL]

System components are tested, before and/or during operation.

Hardware devices, software andorganisational procedures have passedfunctional qualification tests. Hardwaredevices have also passed physical resistancetests. [OE.SYS.QUAL.QUALIFICATION]

During its operation phase, every devicecan undergo functional testing without thisaffecting the availability of the e-money

system. [OE.SYS.QUAL.OPERTEST] Before it is put into operation, every device

is tested, first in isolation and thenfollowing integration into the TOE.[OE.SYS.QUAL.DEVELTEST]

Every sub-system is subjec t to aqualification procedure which verifies thereliability of the following functionswhenever they are supported:

amounts of EV received are aggregatedinto a single amount, the value of whichequals the sum of the amounts received;

the stored EV amount is broken intosmaller amounts, the sum of which


32/45


equals the stored EV amount.[OE.SYS.QUAL.RELIABLE]

3.2.20 Assessment [ASSESSMENT]

Important players are subject to assessment.

The Administrator and the Operator arereviewed to provide assurance thatpractices properly reflect the securitypolicy. [OE.SYS.ASSESSMENT]

3.2.21 Security update

A periodic security update is required for allsensitive parts of the system.

In order to maintain a constant securitylevel, a periodic security update forhardware and software is necessary.[OE.SYS.MAINTENANCE]

3.2.22 Availability [AVAIL]

The system ensures service availability, evenduring maintenance of a part of the system.

The TOE ensures small servicediscontinuity when one or more (oreven all) secrets of the TOE arereplaced.[OT.SEC.AVAIL.AVAILABILITY]

The TOE provides means to create and

extinguish EV continuously, in particularwhile some or all of the devices whichstore and process AD are beingreplaced.[OT.CREXT.AVAIL.AVAILABILITY]

A business continuity plan limits theimpact of any malfunction of thee-money system, or any part thereof,on service availability.[OE.SYS.AVAIL.AVAILABILITY]

The TOE provides means for continuousmonitoring, particularly while some orall of the devices which store andprocess RD are being replaced.[OT.MON.AVAIL.AVAILABILITY]

Assets and data are stored in deviceswhich prevent their deterioration overtime. [OT.SYS.AVAIL.PERENNIALITY]

3.2.23 Life cycle [LIFE]

State-of-the-art security procedures are usedduring the life cycle of the EV and sub-systems.

Sta te-of- the-ar t physical and logicalprotection applies to all premises upon

which devices and software used by theTOE are initialised.[OE.SYS.LIFE.INITIALISED]

Sub-systems are init ialised in compliancewith stateof-the-art security procedures.[OE.SYS.LIFE.INITIALISATION]

Sta te-of-the-art security applies to thepackaging, distribution and installation of all devices and software used by the TOE.[OE.SYS.LIFE.DISTRIBUTION]

Circulation of EV in a sub-system isrestricted in accordance with well-definedcriteria. [OT.TRANS.LIFE.CIRCULATION]

The TOE enforces a technica l andorganisational end-of-life procedure forevery device which contains EV. Thisprocedure includes:

presentation and extinguishment of EV; communication of RD to the System

Supervisor; communication of AD to the EV Issuer.

[OT.SYS.LIFE.TERMINATION]

3.2.24 Partition [PARTITION]

When a sub-system uses applications otherthan the e-money application, separation isenforced between the applications.

When an e-money system shares one ormore devices with other applications, thesedevices must isolate the e-money systemfrom those other applications. Onlyprocesses internal to the e-money systemcan modify data belonging to the e-moneysystem. [OE.SYS.PARTITION]


33/45


34/45


B Application notes

A number of aspects of the EMSSO aredescribed below, including the general modelof an e-money system and the general threatsto the system.

B.1 Link with the CC methodology

In defining security objectives, the report usesthe framework and terminology of the CCstandard. It broadly follows the outline

defined in the CC. However, this does notimply that the CC standard should be used indefining concrete security functions and inthe evaluation/assessment phase.

Several steps may be followed under the CCmethodology in order to compile acomprehensive list of security objectives (forthe system that is subject to evaluation, orTOE). Figure 10 below illustrates thesedifferent steps.

Firstly, the security environment thecontext in which it is intended to use thesubject or TOE should be defined includingall of the organisational issues, expertise andknowledge deemed relevant.

In particular, the TOE physicalenvironment, assets and TOE purpose haveto be taken into account:

TOE physical environment: identifies allaspects of the TOEs operatingenvironment relevant to TOE security,including known physical and personnelsecurity arrangements;

assets requiring protection: includesassets that are directly referred to, suchas files and databases, and assets thatare indirectly related, such asauthorisation credentials and the ITimplementation itself.

TOE purpose: may relate to the producttype and intended usage of the TOE 32.

Thereafter, investigations into the threats,risks and security policies provide a morespecific representation of the:

Assumptions: The assumptions must bemet by the TOE environment in order forthe TOE to be considered secure. Thisstatement can be accepted as axiomaticfor the TOE evaluation.

Threats: this includes all threats perceivedby the security analysis as relevant to the

TOE. The CC characterises the threat interms of a threat agent, a presumed attack method, any vulnerabilities forming thefoundation for the attack, and identificationof the asset under attack.

Organisational security policy: this includesall relevant policies and rules. For a system,such policies may be explicitly identified.

The results of the analysis of the securityenvironment could then be used to state thesecurity objectives designed to counter theidentified threats and to address theorganisational security policies andassumptions identified.

The EMSSO report is structured as follows:

the Target Of Evaluation (TOE); the security environment of the TOE,

including the assets to be protected andthe potential threats to the TOE or itsenvironment, the assumptions made and

the organisational policies used; the security objectives for the TOE and itsenvironment.

The following figure gives an overview of theCommon Criteria process for derivingrequirements and specifications and the parts(shown in darker shading) which are coveredby this document.

32 Source: Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model (1998).


35/45


36/45


B.2 Rationale for the model

Many factors should be taken into accountwhen formulating the security objectives, e.g.the players in the system, the organisationalprocedures, etc. A model of a typical e-moneysystem could enhance the readersunderstanding of the subject by illustrating allthe relevant information in a manner that iseasy to understand. The model presented inSection 1.1 (E-money system: model)describes an e-money system as an IT systemdesigned to allow the transfer of EV in a

transaction between electronic devices (sub-systems).

The general model is in principle applicableto any type of e-money system, whether acard-based or software-based e-moneysystem (including server-based/network-basedtypes). The System Supervisor is a specialplayer who is responsible for the properfunctioning of the system as a whole. He is incharge of EV security management and checksthat no more EV is extinguished than iscreated. Indeed, in an e-money systemconforming to the model, the EV amountcreated is equal to the sum of theextinguished EV amount and the EV amountin circulation. If more EV is extinguished thatthe amount that was created, then false EVhas been introduced into the system.

As explained in Section 2.1.3 (Additionalconcepts: compensation, transactions, EV lifecycle, roles, actors), two types of transaction

can be identified: transactions withcompensation and transactions withoutcompensation. In general, a payment is alwaysdefined as a transaction with compensation,because each payment normally correspondsto a delivery of goods or services (acompensation). However, in some specificcases e-money systems could also define somepayment transactions as transactions withoutcompensation. An e-money system could,for example, decide (for commercial reasons)to define the person-to-person payments astransactions without compensation, which donot therefore have to report to the SystemSupervisor. However, it is possible to impose

restrictions on person-to-person payments,such as confining them to members of thesame family.

B.3 Strength of function

Reference has been made in the present paperto the SOF in order to point out that, forsome areas, the SOF must in any case behigh. This must be considered when acomplete PP is to be produced. Following theCC approach and document structure, the

SOF should be specified within later chaptersof a PP (security requirements, etc.) and notin security needs or security objectives.

For the CC approach, a SOF is typically anassurance requirement for a probabilistic orpermutational mechanism (for example a PIN,password or the generation of keys).

In addition, the security objectives do notinclude any assurance requirement. As withthe SOF, it is necessary to specify when acomplete PP will be produced in specificchapters of such a document. The level of assurance requirements for an e-moneysystem is not under discussion at the presenttime.

B.4 Roles

Roles and trust levels deeply impact onthe system assessment, which should take

into account product evaluation and processevaluation. These two evaluation types raisedifferent issues, depending on the rolesinvolved.

As regards Administrators, security in theirarea of competence area stems largely froman effective security system definition andmanagement. Products must be used in aprotected and trusted environment with adirect and controlled management.

On the other hand, security in the Usercompetence area is mainly based on productsthat help Users, who work in an untrusted


37/45


38/45


C Acronyms

AD Accounting Data

CC Common Criteria

CP Compensation

EMI Electronic Money Institution

EMSSO Electronic Money System Security Objectives

EV Electronic Value

OSP Organisational Security Policy

PP Protection Profile

RD Reporting Data

SF Security Function

SFP Security Function Policy

SOF Strength Of Function

ST Security Target

TOE Target Of Evaluation

TSF TOE Security Function

TSP TOE Security Policy


39/45


34 The Glossary is based on the Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model (November 1998) and Security of electronic money by the CPSS and the Group of Computer Experts of the Central Banks of the Groupof Ten Countries (August 1996).

D Glossary 34

Accounting Data (AD) : Data sent to the EV Issuer upon EV creation and extinguishment.

Acquirer : In an e-money system, the entity or entities (typically banks) that hold depositaccounts for merchants and to which transaction data are transmitted.

Actor : See the paragraph headed Roles, actors, quasi-actors, page 13.

Assets : Information or resources to be protected by counter-measures of a TOE.

Assurance : Grounds for confidence that an entity meets its security objectives.

Authentication data : Information used to verify the claimed identity of a User.

Availability : The ability of services and information to be accessed by Users when requested.

Common Criteria (CC) : [to be added].

Compensation : See page 10.

Component : The smallest selectable set of elements that may be included in a PP, ST or apackage.

Cryptography : The application of mathematical theory to develop techniques and algorithmsthat can be applied to data to ensure the achievement of goals such as confidentiality, dataintegrity and/or authentication.

Electronic Value (EV) : See page 8.

Electronic Money Institution (EMI) : Defined in Directive 2000/46/EC as an undertakingor legal person other than a credit institution which issues means of payments in the form of e-money.

Evaluation : Assessment of a PP, ST or a TOE against defined criteria.

External IT entity : Any IT product or system, untrusted or trusted, outside of the TOE thatinteracts with the TOE.

Integrity : The quality of being protected against accidental or fraudulent alteration or of indicating whether or not alteration has occurred.

Organisational security policy (OSP) : One or more security rules, procedures, practicesor guidelines imposed by an organisation upon its operations.

Product : A package of IT software, firmware and/or hardware providing functionality designedfor use or incorporation within a multiplicity of systems.


40/45


Protection Profile (PP) : An implementation-independent set of security requirements for acategory of TOEs that meet specific customer needs.

Protocol : Procedures for the interchange of electronic messages between communicatingdevices.

Reporting Data (RD) : Data sent to the System Supervisor by sub-systems in order to allowEV circulation monitoring.

Role : A predefined set of rules establishing the interactions allowed between a User and theTOE. See the paragraph headed Roles, actors, quasi-actors.

Secret : Information which can only be known to authorised users and/or the TOE Security

Functions (TSF; see below) in order to enforce a specific Security Function Policy (SFP; seebelow).

Security function (SF) : A part or parts of the TOE that have to be relied upon to enforce aclosely related subset of rules from the TSP.

Security Function Policy (SFP) : The security policy enforced by an SF.

Security objective : A statement of intent to counter identified threats and/or satisfyidentified organisational security policies and assumptions.

Security Target (ST) : A set of security requirements and specifications to be used as thebasis for the evaluation of an identified TOE.

Server : A computer that provides services through a network to other computers.

Strength of Function (SOF) : A qualification of a TOE security function which expressesthe minimum efforts assumed necessary to defeat its expected security behaviour by directlyattacking its underlying security mechanisms.

Sub-system : See page 8.

System : A specific IT installation with a particular purpose and operational environment.

System Supervisor : Special player in the e-money system who is responsible for the properfunctioning of the system as a whole. He is in charge of EV security management and monitorsEV flows.

System Supervisor information : Data obtained from RD processing and centralised by theSystem Supervisor.

Tamper-resistant : The capacity of devices to resist physical attack up to a certain point.

Target Of Evaluation (TOE) : An IT product or system and its associated administratorand user guidance documentation that is subject to evaluation.

TOE environment : All elements which are not part of the TOE but are necessary to theTOE to satisfy its security objectives.


41/45


TOE Security environment : Security aspects of the environment in which the TOE isintended to be used and manner in which it is expected to be employed.

TOE security function (TSF) : A set consisting of all hardware, software and firmware of the TOE that must be relied upon for the correct enforcement of the TSP (see below).

TOE Security Policy (TSP) : A set of rules that govern how assets are managed, protectedand distributed within a TOE.

Traceability : In e-money systems, the degree to which value transfer transactions can betraced to the originator(s) or the recipient(s) of the transfer.

Trusted path : A means by which a User and a TSF can communicate with the necessary

confidence to support the TSP.

User : Any entity (i.e. human user or external IT entity) outside of the TOE that interacts withthe TOE.

User data : Data created by and for the User that does not affect the operation of the TSF.


42/45


E Minimum requirements in the Report on Electronic Money

Requirement 1: Prudential supervision

Issuers of electronic money must be subject to prudential supervision.

Requirement 2: Solid and transparent legal arrangements

The rights and obligations on the part of the respective participants (customers, merchants,issuers and operators) in an electronic money scheme must be clearly defined and disclosed.Such rights and obligations must be enforceable under all relevant jurisdictions.

Requirement 3: Technical security

Electronic money schemes must maintain adequate technical, organisational and proceduralsafeguards to prevent, contain and detect threats to the security of the scheme, particularlythe threat of counterfeits.

Requirement 4: Protection against criminal abuse

Protection against criminal abuse, such as money laundering, must be taken into account whendesigning and implementing electronic money schemes.

Requirement 5: Monetary statistics reporting

Electronic money schemes must supply the central bank in each relevant country withwhatever information may be required for the purposes of monetary policy.

Requirement 6: Redeemability

Issuers of electronic money must be legally obliged to redeem electronic mon

e Money Security 200305

Documents

Transcript of e Money Security 200305