electronic money system security objectives, may 2003

ELECTRONIC MONEYSYSTEM SECURITY

OBJECTIVESACCORDING TO THE COMMON

CRITERIA METHODOLOGY

May 2003

EC

B

EZ

B

EK

T

BC

E

EK

P

ELECTRONIC MONEYSYSTEM SECURITY

OBJECTIVESACCORDING TO THE COMMON

CRITERIA METHODOLOGY

May 2003

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

3ECB • 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 • May 2003

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 171.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] 273.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

ECB • 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 • May 20034

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


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 ofe-money systems, on the issue of technicalsecurity on the 1998 report was furtherelaborated. The Eurosystem’s investigationsresulted in the Electronic Money SystemSecurity Objectives (EMSSO) report, whichdetails the Eurosystem’s 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 analysisprovides 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 theEurosystem’s central banks to assess theoverall reliability and technical security of

e-money schemes in the euro area. TheEurosystem’s 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 theEMSSO 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 ofsecurity 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 – inwhich 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.


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 ofpayment 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 capacity to send or receive EV amounts;– the System Supervisor’s ability 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 extinguishment 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 operation 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 inChapter 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 followtheir own contractual obligations, and havesufficient means, training and informationto perform their role.

– Confidentiality: Those assets that 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 actual

or attempted modification of assets and


counterfeiting of transaction attributes;– communicate all relevant information

which traces these abnormal events tothe System Supervisor.

– Identification: An unambiguousidentification is required for somecomponents of the e-money system.

– Integrity: The integrity of the assets ispreserved, in particular EV amounts.

– Life cycle: State-of-the-art securityprocedures are used during the life cycleof the EV and sub-systems.

– Limitations: EV amounts are limited duringthe EV life cycle.

– Non-evaporation: Only authorised sub-systems can perform extinguishmenttransactions.

– Partition: When a sub-system usesapplications other than the e-moneyapplication, separation is enforced betweenthe applications.

– Qualification and tests: System componentsare tested before and/or during operation.

– Reaction: The system provides means tolimit or undo the consequences of anabnormal or illicit action.

– Secret management: Correct generation,correct distribution, physical storage

protection, limited life span and renewalall preserve the confidentiality and integrityof secrets.

– Security update: A periodic security updateis required for all sensitive parts of thesystem.

– Traceability: The System Supervisor is ableto trace and audit all strategic events (asdefined in the report). Sub-systems recordand keep the data required by the SystemSupervisor for as long as required. Tracedata accurately reflect recorded events.

– Transaction order: Every transactionconsists of a set of basic operationsexecuted in a predefined order.

– Trusted location: A physically protectedenvironment is required for sensitivesecurity devices.

– Trusted path: Interaction with the systemis achieved through protectedcommunication means.

Additional information is provided in theannexes, such as the rationale for the model,a list of acronyms used in the document, aglossary, and a cross-reference table linkingthe security objectives with the relevantassumptions, threats and organisational issues.


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, whichare 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 oftransactions, compensation, EV life cycle andactors then complete this model.

1.1.1 Main concepts of the model

The e-money system is modelled as a set ofsub-systems through which the EV specific tothe system is transferred, under theresponsibility of a System Supervisor3 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 phasecalled 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 SupervisionAuthority.

4 This definition is taken from Directive 2000/46/EC of theEuropean Parliament and of the Council of 18 September 2000on the taking up, pursuit of and prudential supervision of businessof electronic money institutions.


5 The sub-systems are also subject to other restrictions that will beexplained in the section entitled “Transactions”.

6 Sub-systems need only have the capability to do this uponrequest 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 andextinguishment.

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

– send or receive EV amounts;– generate Reporting Data (RD);– make this data available (directly, 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 ofwhich 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 ofboth types is illustrated below.

Card-based system

In a card-based system, the sub-systems whichparticipate in the EV flow generally consist offour 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 ofthe merchant. The customer’s purse (thesmart card) is a simple, stand-alonesub-system, while the point-of-sale (POS)terminals and the central information systemsto 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


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 ofe-money systems, in view of the specificity ofthe 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, byjoint agreement, in the course of theprovision of these goods or services.

Figure 3Example of a server-based system

Accounting Data

Customer

Loading

Payment

Collection

Wallet Wallet

Bank Bank

Merchant

Paym.gateway

Bankserver

EVIssuerBank

SystemSupervisor


Remote access

Customer Merchant

Reporting Data

EV circulation


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

Refund10 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

Collection With CP Unloads EV received inpayment for goods orservices

Presentation With CP Redeems and destroyswith collected EVextinguishment

Recycling Without Modifies collected EV soCP that it can be loaded into

devices

Cancellation 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 EVtransactions8:

– initialisation;– EV debiting;– EV crediting;– 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 transaction which involves an interactionbetween 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 interactionbetween the two flows is called atransaction without CP.

Transactions without CP involve an EVcirculation that is not balanced by acorresponding flow of value. Recycling ofEV 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:


11 The existence of an obligation for the player credited to deliver,either immediately or later, represents a CP to the playerdebited, i.e. for every transaction with CP, a contractualcommitment 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 Supervisor11 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 isextinguished than the amount created, falseEV is introduced into the system. One role ofsupervision 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


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 loadingagent 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 creationand 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 thesystem 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 theplayer 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 customer’s 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 instock 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


Figure 6Different EV states in an e-money system

Transaction State changeSupply EV creationLoading-1 EV creationLoading-2 EV circulationRefund EV circulationPayment EV circulationCancellation EV circulationCollection EV circulationRecycling EV circulationRestitution EV extinguishment

14 The player’s 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 temporarilyunable 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 responsibility14 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-actorsare 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 thecompany’s 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 risks15;ii) compliance risks16 and iii) reputationalrisks17. The Administrator enjoys a high trustlevel because he bears the ultimateresponsibility for security.


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

IT Provider Operator Provides ITinfrastructure to thee-money system

18 Operational risk refers to the risk that deficiencies in internalcontrols and information systems might result in unexpectedlosses.

– 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 Administrator’s 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 toAdministrators 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 inrelation 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 player’s 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).


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 accountaccount) (Customer)

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

Quasi-actors Role Short description

System Administrator Monitors the flow ofSupervisor 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 the 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 PurseHolder’s 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-moneysystems

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 underthe responsibility of a System Supervisor.

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

Figure 7Composition 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 ifthere is a “global” System Supervisor whomonitors the security of all EV. In practice,the System Supervisors could carry out“global” supervision jointly, either on a co-operative basis or by mutual acceptance ofan appropriate contractual agreement.


Figure 8Shared sub-system

19 Interoperability with shared sub-systems may be achieved bydefining the security and functional aspects of the sub-systems.For example, the Common Electronic Purse Standards (CEPS)specifications describe the technical (functional) interoperabilityrequirements 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 OfEvaluation is based on the e-money system aselaborated 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 circulation20

• 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 followingtransactions:• creation;• loading;• payment;• collection;• refund;• exinguishment.


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.


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

22 Source: Common Criteria for Information Technology SecurityEvaluation 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 Criteria21, 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 bemet 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 ofthe 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 statement of applicable organisationalsecurity 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 creation and

the data which result from itsextinguishment;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 attributes 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 maximumand minimum amounts). Access dataallows access to the sub-system (e.g.identification data);


23 Source: Common Criteria for Information Technology SecurityEvaluation 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 data23 (data for security mechanisms):

– the RD intended for the SystemSupervisor;

– the secrets.Secrets refers to cryptographic keys,passwords, authentication data, etc.

2.1 Assumptions

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

– information about the intended usage ofthe 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 fulfiltheir 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 Holder’s 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 EVcreation 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 itselfagainst all types of attackers, regardless ofwhether they are staff, users or partiesexternal to the system.


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 penetrate 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 ofthe system;

– those who misuse the system in order tofacilitate the commission of illegal acts;

The e-money system must also protect itselfagainst 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 ofEV), 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 financialequilibrium 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]

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

– the usurpation of another’s privilegesthrough the misuse of secrets;[T.Usurpation_Creat]

– the creation of fake transactions byduplication of authentic attributes orauthentic AD, duplication of parameters ofa 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 player’s illicit denial of his participationin all or part of a transaction, if accepted(e.g. A quasi-actor’s illicit denial of initiationof the transaction). [T.Repudiation_Extin]

Illicit extinguishment of EV

This category covers all attacks or incidentsthat lead to an abnormal25 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 offake 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 attributes,AD, data related to EV creation andextinguishment, or secrets;[T.Modification_Extin]

– the usurpation of another’s privilegesthrough the misuse of secrets;[T.Usurpation_Extin]

– 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_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 Issuer’sfinancial 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 comparedwith EV embezzlement, but in the latter event the EV is routedto 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 illicit modification of transactionattributes, AD, data related to EVcreation and extinguishment or secrets;[T.Modification_Theft]

– the usurpation of another’s 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 Issuer’sfinancial 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 System Supervisorinformation for purposes other thanmonitoring the e-money system, orunauthorised third parties gainingknowledge of sub-system secrets;[T.Disclosure_Abuse]

– the illicit modification of sub-systemsparameters, System Supervisor informationor a secret; [T.Modification_Abuse]

– the usurpation of another’s privilegesthrough the misuse of secrets.[T.Usurpation_Abuse]


27 The SOF qualification of a TOE expresses the minimum effortsassumed necessary to defeat a system’s expected securitybehaviour 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.

Interference with the operation of the e-moneysystem

This category covers accidental or intentionalmalfunction that may result in the systembeing totally or partly unavailable.

Such malfunction may result from an actorunwittingly failing to comply with e-moneysystem regulations, or from a terroristattempting to harm the system.Terrorists could resort to logical orphysical destruction, to espionage and todisclosure of confidential data.

Interference with the operation of thee-money system can result from the following:

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

– the modification of all or part of the system(especially of an asset), of a sub-system’sparameters, of RD or System Supervisorinformation or of a secret;[T.Modification_Malfunc]

– the usurpation of another’s privilegesthrough the misuse of secrets;[T.Usurpation_Malfunc]

– late arrival of RD. [T.TimeLimits_Malfunc]

2.3 Organisational security policies(OSPs)

Organisational security policies (OSPs) aredescribed in the cc framework as securityrules, procedures, practices and guidelineswith that the TOE must comply:

– Supervision of the security of the TOEdetects attempts and occurrences ofmalfunction in the TOE, whether or notthese are intentional. [OSP.Detection]

– Supervision of the security of the TOE isused to define actions to limit or suppressthe effects of a detected or suspectedmalfunction (intentional or not).[OSP.Reaction]

– The e-money system security events listedhereunder are recorded in order that they

can be traced to their source [OSP.Log]:– generation of secrets;– revocation of secrets;– renewal of secrets;– initialisation of sub-system parameters;– modification of sub-system parameters;– initialisation and modification of the

parameters related to EV creation andextinguishment.

– The security architecture of the TOE isbased on standardised, publicly known andextensively reviewed, state-of-the-artcryptographic algorithms and cryptographickey management. The TOE does not usecryptographic algorithms that must remainconfidential for security reasons. TheStrength of Function (SOF27) for the use ofcryptography must be high. [OSP.Crypto]

– The communication architecture of theTOE is based on standardised protocolsand security procedures. [OSP.Protocol]

– Hardware devices, software andorganisational procedures have passedfunctional qualification tests and hardwaresecurity tests. [OSP.Qualification]

– For every transaction with CP, acommitment relates the CP to the EVamount exchanged. The terms of thiscommitment are known to both partiesbefore the initialisation of the transaction.[OSP.Commitment]

– Every transaction with CP is validated byboth parties. The validation procedurecomplies with the terms of thecommitment and both parties take note ofthe commitment prior to initialisation ofany transaction. [OSP.Validation]

– Every transaction with CP can be recordedso that each of the parties can check allrelevant details a posteriori. Both partiesare aware of how to check a transaction.[OSP.Verification]

– In the course of a transaction, EV debitalways precedes EV credit. When the actor


from whom EV is debited enjoys a lowertrust level than the actor to whom EV iscredited (e.g. in the case of a refund ofEV), 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 alimited 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 ofhardware 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 extinguishment 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]


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-dynamicaspect, 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 andSystem 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 EV

exchanged 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 generated for a transaction andcommunicated to the EV Issuer.

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


3.1.3 Naming convention

The security objectives below are named asfollows:

OT|OE.<domain_code>.<general_objective>[.<specific_objective>],where :– OT|OE indicates whether the objective

concerns the TOE (OT) or theenvironment (OE).

– <domain_code> is one of SYS, SEC,TRANS, CREXT and MON.

– <general_objective> indicates the generalobjective under which this objective isclassified.

– <specific_objective> is an optionalrefinement 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 integrityof 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 ofall secrets. [OT.SEC.CONF.SEC]

– The TOE preserves the confidentiality ofthe 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-


system credited with EV and vice versa.[OT.TRANS.AUTH.PROOF]

– The sub-system sending RD to the SystemSupervisor authenticates the SystemSupervisor when sending the RD.

– The System Supervisor authenticates theRD that he receives.[OT.TRANS.AUTH.RD]

– The TOE provides means to communicateAD to the EV issuer in an authenticatedmanner and to verify that they have beenreceived.

– The EV Issuer authenticates the AD thathe receives. [OE.CREXT. AUTH.AD]

3.2.5 Access control [ACC]

Unauthorised access to all assets is prevented,even in the case of a malfunction inmonitoring or in secrets management. Everyidentified actor has a clear set of access rights.

– The TOE implements security functionsthat prevent illicit access to secrets in theevent of a malfunction in secretsmanagement. [OT.SEC.ACC.SEC]

– In the event of a monitoring malfunction,the TOE implements security functions thatprevent illicit access to the SystemSupervisor information.[OT.MON.ACC.SSI]

– Every identified actor within the systemhas a clear set of access rights.[OE.SYS.ACC.PRIVILEGES]

3.2.6 Commitment and validation[COMM]

Transactions are conducted and validatedunder the terms of a commitment betweenthe parties.

– Transaction initialisation is possible onlyafter the actors in charge of the sub-systems to be credited and debited withEV have validated a commitment. Thiscommitment fixes the EV amount to beexchanged.[OE.TRANS.COMM.COMMITMENT]

– For each commitment there is only onetransaction. The EV amount exchanged inthis transaction is equal to the EV amountdefined in the commitment.[OE.TRANS.COMM.AMOUNT]

– Every transaction must be validated by thetwo parties. The validation procedurecomplies with the commitment terms.Both parties are aware of thecommitment prior to any transaction.[OE.TRANS.COMM.VALIDATION]

3.2.7 Atomicity [ATOMICITY]

Transactions are either completed or undone.

– The TOE enforces security functions thatallow a transaction to either be completedor undone as long as the closure operationhas not been performed.[OT.TRANS.ATOMICITY]

3.2.8 Transaction order [ORD]

Every transaction consists of a set of basicoperations executed in a predefined order.

– Every transaction contains only one singleoccurrence of every basic operation that itconsists of.[OT.TRANS.ORD.OCCURRENCE]

– For every transaction, basic operations areexecuted in the following order:– initialisation;– EV debiting precedes EV crediting;– closure.[OT.TRANS.ORD.ORDER]

– For every transaction involving EV creationor extinguishment, basic operations areexecuted in the following order:– EV creation or extinguishment precedes

closure;– AD transmission to the EV Issuer takes

place after EV creation orextinguishment;

– AD can be processed only if and whenthe transaction has been completed.[OT.CREXT.ORD.ORDER]


30 “In a timely manner” refers to the time needed to allowprocessing of data to meet all deadlines relevant to the processgoal.

3.2.9 Non-evaporation [EVAP]

Only authorised sub-systems can performextinguishment transactions.

– The TOE restricts 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 lifecycle.

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 ofthe sub-systems’ functional parameters arestrategic events. These events are recordedso that they can be audited by the SystemSupervisor. [OT.TRANS.TRAC.AUDIT]

– Initialisation 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 for

the 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 accurately reflect 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 illicitaccess to secrets, modification or illicit useof secrets. [OT.SEC.DETECTION]

– The TOE provides means:– to detect attempted or actual

occurrences of modification of thetransaction’s 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;


31 The SOF qualification of a TOE expresses the minimum effortsassumed necessary to defeat a system’s expected securitybehaviour 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 ofmodification 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 ofillicit 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 effectsof a detected or suspected malfunction.[OT.CREXT.REACTION]

– The TOE provides means to react againstattempted or actual occurrences ofmodification 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 SOF31 for the use of cryptography andprobabilistic mechanisms must be high.[OT.SYS.CRYP.SOF]

– The communication architecture of theTOE is based on standardised protocolsand 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 distributes 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 securityfunction 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


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

– Security 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;– installation, 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 ofaccess 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-moneysystem. [OE.SYS.QUAL.OPERTEST]

– Before it is put into operation, every deviceis tested, first in isolation and thenfollowing integration into the TOE.[OE.SYS.QUAL.DEVELTEST]

– Every sub-system is subject to aqualification procedure which verifies thereliability of the following functionswhenever they are supported:– amounts of EV received are aggregated

into 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


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

– State-of-the-art physical and logicalprotection applies to all premises uponwhich devices and software used by theTOE are initialised.[OE.SYS.LIFE.INITIALISED]

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

– State-of-the-art security applies to thepackaging, distribution and installation ofall 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 technical 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]


A Sources

Annexes

This report is based on the following sources:

• [CC-1] Common Criteria for InformationTechnology Security Evaluation Part 1:Introduction and General Model Version2.1 ISO/IEC 15408-1;

• [CC-2] Common Criteria for InformationTechnology Security Evaluation Part 2:Security Functional Requirements Version2.1 ISO/IEC 15408-2;

• [CC-3] Common Criteria for InformationTechnology Security Evaluation Part 3:Security Assurance Requirements Version2.1 ISO/IEC 15408-3;

• Information Technology – SecurityTechniques – Guide for the Production ofProtection Profiles and Security Targets,Draft, ISO/IEC PDTR 15446;

• CEM 97/017 Common Methodology forInformation Technology SecurityEvaluation, Part 1: Introduction andGeneral Model;

• CEM 99/045 Common Methodology forInformation Technology SecurityEvaluation, Part 2: Evaluation Methodology;

• Report on Electronic Money, ECB, 1998;

• Security of Electronic Money, Report bythe Committee on Payment and SettlementSystems and the Group of ComputerExperts of the Central Banks of the Groupof Ten Countries, 1996;

• Directive 2000/46/EC of the EuropeanParliament and of the Council of 18September 2000 on the taking up, pursuitof and prudential supervision of thebusiness of e-money institutions.


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 outlinedefined 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 TOE’s 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 TOE32.

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 theTOE. The CC characterises the threat interms of a threat agent, a presumed attackmethod, 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 andthe 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 SecurityEvaluation Part 1: Introduction and general model (1998).


Figure 10Parts of the CC framework covered in this document 33

TOE physicalenvironment

TOE purposeAssets requiring

protection

Establishsecurity

environment

Establishsecurity

objectives

Establishsecurity

requirements

Establish TOEsummary

specification

Threats

Securityobjectives

Organisationalsecurity policies

CC requirementscatalogue

Functionalrequirements

Assurancerequirements

TOE summaryspecification

Requirements forthe environment

SecurityEnvironmentmaterial (PP/ST)

SecurityObjectivesmaterial (PP/ST)

SecurityRequirementsmaterial (PP/ST)

SecuritySpecificationmaterial (ST)

Assumptions

33 Source: Common Criteria for Information Technology Security Evaluation Part1: Introduction and general model (1998).


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 reader’sunderstanding 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 atransaction 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 transactioncan 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, theSOF 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 ofassurance 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 takeinto 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


environment and with poor skills, to complywith the security system. User devices areoften used in a hostile environment, whereUsers have no capabilities to protect them.

As a consequence:

• Evaluation in an Administrator contextrequires a reliable process evaluation withthe aim of verifying organisational aspectsof security. Products can also be evaluatedat a lower assurance level, exploiting thehigh trust level of the Administrator’sinfrastructure.

• Evaluation in a User context is mainly basedon product evaluation, aiming to verify thesoundness of devices used in an untrustedenvironment. On account of the low trustlevel of this context, product evaluationrequires higher assurance levels.

• Evaluation in the Operators context refersto a proper combination of the above-mentioned “profiles”.


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


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


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


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


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 money againstcentral bank money at par at the request of the holder of the electronic money. The details ofthis requirement are to be specified.

Requirement 7: Reserve requirements

The possibility must exist for central banks to impose reserve requirements on all issuers ofelectronic money.


F Cross-reference Table for Security Objectives

OT.SEC.MNG.REPLACEMENT

TOE enforces tech & organis. end-of-life procedures: OT.SYS.LIFE.TERMINATION 12

Trusted path between quasi-actors and subsystems: OT.SYS.TRUSTED-PATH 11 Malfunctions: prevents illicit access to secrets : OT.SEC.ACC.SEC

Assets & Data stored in a permanent way: OT.SYS.AVAIL.PERENNIALITY 10 No predictability of secrets generation : OT.SEC.MNG.PREDICABILITY

Standardised protocol and security procedures for Communications: OT.SYS.CRYP.PROTOCOL 9 Tamper-resistant devices to store & transport secrets: OT.SEC.MNG.TAMPER

Strength of Function (SOF) = High: OT.SYS.CRYP.SOF 8 Recording of [generation,revoke, replace] of secrets: OT.SEC.TRAC.AUDIT

Standard cryptographic algorithms: OT.SYS.CRYP.CRYPTO 7 Standard for generaion/distribution of secrets: OT.SEC.MNG.INITIALIZATION

Prevent unauthorised access: OT.SYS.ACC.ASSETS 6 Service continuity for secrets replacement: OT.SEC.AVAIL.AVAILABILTY

Unique ID for actors/quasi-actors, subsystems & transactions. : OT.SYS.ID 5 Means to replace secrets:

Set Max EV in subsystems: OT.SYS.LIM.EVLIMITS 4 Every secrets has a limited life span: OT.SEC.MNG.LIFESPAN

Only transactions can modify EV: OT.SYS.INT.EVTRANSAC 3 TOE preserves secrets confidence: OT.SEC.CONF.SEC

EV integrity inside devices: OT.SYS.INT.EVSTORAGE 2 Service continuity in case of illicit access/use of secrets: OT.SEC.REACTION

TOE preserves integrity of assets: OT.SYS.INT.ASSETS 1 Means to detect illicit access/use,..of secrets: OT.SEC.DETECTION

SPECIFIC THREATS

Disclosure of

parameters/secrets/RD T.Disclosure_*5 6 8 11 14 23 24 25 26 27 28

Illicit modification of param,

attribute, AD,RD,secrets T.Modification_*1 2 3 4 5 6 10 11 14 19 20 21 23 24 25 26 27 28

Usurpation of someone

else's privileges T.Usurpation_*5 24 25 26 27 28

Creation of fake transactions T.Counterfeiting_*1 2 4 5 6 24 25 26 27 28

Replay attack in a transaction T.Replay_*

Late arrival of RD T.TimeLimits_* 4

Illicit repudiation of a transaction T.Repudiation_* 11 14

ORGANISATIONAL SECURITY POLICIES

Detect intentional/accidenta

dysfunctions of the TOE OSP.DetectionSuppress/limit effect of detected

dysfunctions OSP.Reaction 10 12 19

Log of secrets and

parameters modifications OSP.Log 10

Standard crypto-algoritms &

key management OSP.Crypto 6 8

Communications: standard protocol &

security procedures OSP.Protocol 6 9

Functional qualification for HW, SW &

Organisational Procedures OSP.Qualification 18 20 21

Contractual commit. link EV to CP OSP.Commitment

Two parties validation of the transaction OSP.Validation

Transact.: log for "a posteriori" check OSP.VerificationTransactions: first debit, then credit

(except lower trust level) OSP.Sequence

All secrets have a limited life span OSP.SecretLifeSpan

Security update of devices OSP.Maintenance 29

All secrets/devices can be replaced OSP.Evolution 26

End-of-life procedures for EV OSP.EVPresentation 12

Authorised persons for installation OSP.Access 24 25 27 28

Debit from = credit to

& integrity of EV OSP.Equilibrium 21 23

ASSUMPTIONS

Actor/quasi-actor follow

contractual obligations A.Responsability 15 16

Actor/quasi-actor have

sufficient competence A.Competence 15 17

Physcal protections of

Admin/Oper. devices A.Trusted_location 13

RD -> trans.with CP;

AD-> trans. wth EV creaction/exting. A.Data

All relevant events traced A.Log 15

Physical protections of AD/OP. devices: OE.SYS.TRUSTED_LOCATION 13

Trusted path between quasi-actors and subsystems: OE.SYS.TRUSTED_PATH 14

Assessment of EV Issuer and System Supervisor: OE.SYS.ASSESSMENT 15

Actors/quasi-actors follow contractual obligations: OE.SYS.RESP.RESPONSABILITY 16

Sufficient competence of actors/quasi-actors - info+training: OE.SYS.RESP.COMPETENCE 17

Functional Qualifications for HW,SW & Organisational Procedures: OE.SYS.QUAL.QUALIFICATION 18

Business continuity plan to limit dysfunctions: OE.SYS.AVAIL.AVAILABILITY 19

Devices tested before to operate in the e-money system: OE.SYS.QUAL.DEVELTEST 20

Qualifcation procedure to test aggregation/breaking of EV inside devices: OE.SYS.QUAL.RELIABLE 21

Functional testing on operating devices : OE.SYS.QUAL.OPERTEST 22

Shared devices with other applications: separation of processes: OE.SYS.PARTITION 23

AD: Accounting Data State-of-art outsourcing policy, security policy for external personnel (production- distribution): OE.SYS.RESP.PERSONNEL 24

RD: Reporting Data State-of-art Phys. &Log. Protection of production premises where TOE devices are produced: OE.SYS.LIFE.PRODUCTION 25

EV: Electronic Value State-of-art security for packaging/distribution of devices & SW: OE.SYS.LIFE.DISTRIBUTION 26

TOE: Target Of Evaluation State-of-art initialization procedures: OE.SYS.LIFE.INITIALISATION 27

AD/OP: Administrator/Operator Rights on assets only to identified person: OE.SYS.ACC.PRIVILEGES 28

CP: compensation Security update of HW and SW necessary for e-money system: OE.SYS.MAINTENANCE 29

SW: software

HW: hardware

Auth.: Authentication

creat/ext: creation/extinguishing

SSI: System Supervisor Information

E-MONEY SYSTEM

Domain

SECRETS

Domain

OBJ. for TOE

OBJ. for

ENVIRONMENT

Cross reference table for Specific Security Objectives


Restriction of EV circulation in a subsystem: OT.TRANS.LIFE.CIRCULATION 16

RD represent transactions with CP: OT.TRANS.TRAC.TRUE 15

Initial. -> debit->credit-> close: OT.TRANS.ORD.ORDER 14

One occurance of basic operation per transaction: OT.TRANS.ORD.OCCURENCE 13

Debit = Credit (in a transaction) : OT.TRANS.INT.EQUALITY 12

Record/send RD to Superv.: OT.TRANS.TRAC.RECORD 11

Superv. authenticate RD - : OT.TRANS.AUTH.RD 10

RD to Supervisor on time: OT.TRANS.TRAC.TIMELY 9

Trace of subsys. initial. & modify: OT.TRANS.TRAC.AUDIT 8

Proof of partecipation in the transac.: OT.TRANS.AUTH.PROOF 7 EV creation/extinguishing -> close -> AD to Issuer: OT.CREXT.ORD.ORDER 7

Auth. of EV coming from debited subs.: OT.TRANS.AUTH.EV 6 Record of AD communicated to EV Issuer: OT.CREXT.TRAC.RECORD 6

Auth. among subsys: OT.TRANS.AUTH.SUBSYS 5 Recording of init/modify of EV creat/ext parameters: OT.CREXT.TRAC.AUDIT 5 Continuos monitoring: OT.MON.AVAIL.AVAILABILITY 5

Complete or undo transac.: OT.TRANS.ATOMICITY 4 Continuos extinguishing of EV: OT.CREXT.AVAIL.AVAILABILITY 4 Malfunctions: prevent illicit access to SSI: OT.MON.ACC.SSI 4

Reaction to abnormal events: OT.TRANS.REACTION 3 Extinguishing only between authorised subsys: OT.CREXT.EVAP 3 Detect alteration of Superv. Info/RD: OT.MON.REACTION 3

OT.TRANS.REACTION.UNDO 2 Reaction to dysfunctions: OT.CREXT.REACTION 2 Confident. of Superv. Info: OT.MON.CONF.SSI 2

OT.TRANS.DETECTION 1 Detect modification of assets involved in EV creat/ext: OT.CREXT.DETECTION 1 Detect access to Superv. Info/RD: OT.MON.DETECTION 1

TRANSACTIONS

Domain

EV CREATION &

EXTINGUIS.

Domain

MONITOR

Domain

OE.SEC.MNG.SEPARATION 12 Commitment validation before transaction.: OE.TRANS.COMM.COMMITMENT 17 EV creat/ext=EV in transac.: OE.CREXT.INT.EQUALITY 8 RD &Superv.Info: OE.MON.CONF.NEEDTOKNOW 6

OE.SEC.MNG.NEEDTOKNOW 13 Exchanged EV amount = amount in contract: OE.TRANS.COMM.AMOUNT 18 AD represent creat/ext trans.: OE.CREXT.TRAC.TRUE 9 RD & Sup.Info known only by

Two parties validation of the transaction - cognisance of contract: OE.TRANS.COMM.VALIDATION 19 Issuer authent. received AD: OE.CREXT.AUTH.AD 10 those who need to know

Secrets not shared among functions :

Secrets known by who needs them :

Undo for abnormal events:

Detect abnorm. events on trans.:

11

10

9

8

7

6

5

4

3

2 4 6

6

6

1 3 5

1 2 4 5

4

4

10

10

10

1 9

2 3

5

4 8

6

7

3 8

6 9 10

1 5 6 9

1 2 3 10 11 16

6 10 11

1 6 10 11

1 2 3 13

9

7 1 5

1 9 10 11 15

2 3

8

17 18 19

5 7 19

11

14

4 6 12

9 10 11 15

1 8 11 15

2

1

3 7 9 10 11 12 13

9 11

10 11

11

1 8 12

2 5

8

3 4 5 7

7

4

5 6

1 8

electronic money system security objectives, may 2003

Documents