ISO/TS 17574:2004

TECHNICAL ISO/TS
SPECIFICATION 17574
First edition
2004-11-01
Road transport and traffic telematics —
Electronic fee collection (EFC) —
Guidelines for EFC security protection
profiles
Transports routiers et télématique routière — Systèmes de péage
électronique — Lignes directrices concernant les profils de protection
de la sécurité des péages
Reference number
©
ISO 2004
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2004
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2004 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years with a view to deciding whether it should be confirmed for
a further three years, revised to become an International Standard, or withdrawn. In the case of a confirmed
ISO/PAS or ISO/TS, it is reviewed again after six years at which time it has to be either transposed into an
International Standard or withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
Technical Committee ISO/TC 204, Intelligent transport systems, in accordance with the Agreement on
technical cooperation between ISO and CEN (Vienna Agreement).

Contents page
Foreword.v
Introduction .vi
1 Scope .1
2 Normative references.6
3 Terms and definitions .7
4 Abbreviations.10
5 Outlines of Protection Profile.12
Annex A (informative) Procedures of Preparing Documents.14
Annex B (informative) Example of Threat Analysis Evaluation Method .46
Annex C (informative) Abstract from “Definition of threats and security controls for the
Charging Interface in Electronic Fee Collection”.49
Annex D (informative) Common Criteria Recognition Arrangement (CCRA).61
Bibliography .65

iv © ISO 2004 – All rights reserved

Foreword
This document was prepared by Technical Committee CEN/TC 278, “Road Transport and Traffic Telematics” in
collaboration with ISO/TC 204 “Transport information and control systems”.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification : Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and
United Kingdom.
Introduction
Electronic Fee Collection systems are subject to several ways of fraud both by users and operators but also from
people outside the system. These security threats have to be met by different types of security measures including
security requirements specifications. This document provides a guideline for preparation and evaluation of security
requirements specifications, referred to as Protection Profiles (PP) in ISO/IEC 15408 Information technology -
Security techniques - Evaluation criteria for IT security and ISO/IEC PDTR 15446 Guide for the production of
protection profiles and security target. By a Protection Profile (PP) is meant a set of security requirements for a
category of products or systems that meet specific needs. A typical example would be a PP for On-Board
Equipment (OBEs) to be used in an EFC system.
This document should be read in conjunction with the underlying standards ISO/IEC 15408 and ISO/IEC
PDTR 15446. Although a layman can read the first part of the document to have an overview on how to prepare a
Protection Profile for EFC equipment, the Annexes, and more particularly Clauses A.4 and A.5, require that the
reader is familiar with the ISO/IEC 15408.
It is recommended that Electronic Fee Collection (EFC) operators or national organisations, e.g. Highway
authorities or Transport Ministries, use this guideline to prepare their own EFC/PP, as security requirements should
be described from the standpoint of the operators and/or operators organisations.
It should be noted that this standard is of a more informative than normative nature and it can not be used without
also using the ISO/IEC 15408. Most of the content of the standard is an example shown in Annex A on how to
prepare the security requirements for EFC equipment, in this case an OBE with an IC-card loaded with crucial data
needed for the EFC. The example refers to a Japanese national EFC system and should only be regarded and
used as an example. The Clauses 1 to 5 are normative while Annexes A to D are informative.
After an EFC/PP is prepared, it can be internationally registered by the organisation that prepared the EFC/PP so
that other operators or countries that want to develop their EFC system security services, can refer to an already
registered EFC/PPs.
This EFC related standard on security service framework and EFC/PP is based on the ISO/IEC 15408, Evaluation
criteria for information technology (IT) security. ISO/IEC 15408 includes a set of requirements for the security
functions and assurance of IT relevant products and systems. Operators, organisations or authorities defining their
own EFC/PP can use these requirements. This will be similar to the different PPs registered by several financial
institutions, e.g. for payment instruments like IC-cards.
The products and systems, which were developed in accordance with ISO/IEC 15408, can be publicly assured by
the authentication of the government or designated private evaluation agencies.
vi © ISO 2004 – All rights reserved

1 Scope
This document gives guidelines for the preparation and evaluation of security requirements specifications, referred
to as Protection Profiles (PP) in ISO/IEC 15408 Evaluation criteria for IT security and ISO/IEC PDTR 15446 Guide
for the production of protection profiles and security target. By a Protection Profile (PP) is meant a set of security
requirements for a category of products or systems which meet specific needs. A typical example would be a PP
for OBEs to be used in an EFC system and in this case the PP would be an implementation-independent set of
security requirements for the OBEs meeting the operators and users needs for security.
The document uses an OBE with an integrated circuit(s) card (ICC) as an example describing both the structure of
the PP as well as the proposed content.
Figure 1 shows how this document fits in the overall picture of EFC security architecture. The shaded boxes are the
aspects mostly related to the preparation of PPs for EFC systems.

Figure 1 — Overall view of security architecture

The main purpose of a PP is to analyse the security environment of a subject and then to specify the requirements
meeting the threats being the output of the security environment analysis. The subject studied is called the Target
of Evaluation (TOE). In this document, an OBE with an ICC is used as an example of the TOE.
The preparatory work of EFC/PP consists of the steps shown in Figure 2 (items 1 to 6):
Figure 2 — The process of preparing a Protection Profile for EFC equipment

A PP can be registered publicly by the entity preparing the PP in order to make it known and available to other
parties that can use the same PP for their own EFC systems.
By a Security Target (ST) is meant a set of security requirements and specifications to be used as the basis for
evaluation of an identified TOE. While the PP can be looked upon as the EFC operator requirements the ST can be
looked upon as the documentation of a supplier as for the compliance with and fulfilment of the PP for the TOE,
e.g. an OBE.
Figure 3 shows a simplified picture and example of the relationships between the EFC operator, the EFC
equipment supplier and an evaluator. As for international registry organisation, i.e. Common Criteria Recognition
Arrangement (CCRA) and current registered PPs, reference is made to Annex D.
2 © ISO 2004 – All rights reserved

Figure 3 — Relationships between operators, suppliers and evaluators
The ST is similar to the PP, except that it contains additional implementation-specific information detailing how the
security requirements are realised in a particular product or system. Hence, the ST includes the following parts not
found in a PP:
— a TOE summary specification that presents the TOE-specific security functions and assurance measures;
— an optional PP claims portion that explains PPs the ST is claimed to be conformant with (if any);
— finally the rational contains additional evidence establishing that the TOE summary specifications ensures
satisfaction of the implementation-independent requirements, and that claims about PP conformance are
satisfied.
Actual security functions of EFC products will be designed based on this ST, see example in Figure 4.
Figure 4 — Example on design based on a PP
TOE for EFC is limited to EFC specific entities and interfaces such as for Users, Service Providers and
communication link (DSRC or CN) between Users and Service Providers, which are essential to EFC systems and
are shown shadowed in Figure 5. Since the existing financial security standards and criteria are applicable to other
entities and interfaces, they are assumed to be outside the scope of TOE for EFC.
The security evaluation is performed by assessing the security related properties of entities and interfaces defined
in STs, as opposed to assessing complete processes which often are distributed over more entities and interfaces
than those covered by the TOE of this document.
NOTE Assessing security issues for complete processes is a complimentary approach, which may well be beneficial to apply
when evaluating the security of a system.
In Annex A, the guideline for preparing EFC/PP is described by using an OBE as an example of EFC products. The
crucial communication link in this Annex (between the OBE and the RSE) is based on DSRC.
4 © ISO 2004 – All rights reserved

Figure 5 — Scope of TOE for EFC

Figure 6 below shows the entities involved in the charging interface, i.e. the User, the Service Provider, and a
Dishonest Party, the latter trying to gain from tampering segments or communication.

Figure 6 — Entities involved in the Charging Interface of EFC
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO/IEC 15408-1:1999, Information technology - Security techniques - Evaluation criteria for IT security –
Part 1: Introduction and general model
ISO/IEC 15408-2:1999, Information technology - Security techniques - Evaluation criteria for IT security –
Part 2: Security functional requirements
ISO/IEC 15408-3:1999, Information technology - Security techniques - Evaluation criteria for IT security –
Part 3: Security assurance requirements

6 © ISO 2004 – All rights reserved

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
assurance requirement
security requirements to assure confidence in the implementation of functional requirements
3.2
audit
recognising errors such as illicit systems and/or illicit access. In addition, recording and analysing information
related to security relevant activities and events in order to attain proper security control in accordance with security
policy
3.3
availability
dependability with respect to readiness for usage. A measure of correct service delivery based on the alternation of
correct and incorrect service
3.4
Central Communication Unit
part of the Central Equipment serving as a mobile communication interface to the OBU
3.5
Central Equipment
system components at fixed centralised locations
NOTE Central equipment is not the same as Central system. Central equipment is used in the GNSS/CN based EFC system.
3.6
certification
action by a third party, demonstrating that adequate confidence is provided that a duly identified product, process
or service is in conformity with a specific standard or other normative document
3.7
Clearing Operator
the entity that collects and possibly aggregates transactions from one or more Transport Service Providers for
delivery to the Issuer(s). The Clearing Operator can also handle the Apportionment between the Transport Service
Providers. In the financial world this operator is equivalent to an Acquirer
3.8
Collection Agent
the entity responsible for selling, reloading or delivering the Payment Means to the User and collecting the payment
from the User on behalf of the Issuer. The Collection Agent can also collect user related application specific data
from the User. The Collection Agent is also referred to as Retailer
3.9
confidentiality
prevention of information leakage to non-authenticated individuals, parties and/or processes
3.10
Evaluation Assurance Level (EAL)
assurance levels to evaluate securities for products and systems
3.11
functional requirement
security requirements to determine the security functions, which are required for systems and/or products
3.12
issuer
the entity responsible for the payment system and responsible for issuing the Payment Means to the User
3.13
integrity
the property that information (data) has not been altered or destroyed in an unauthorised manner
3.14
Key Management (Encryption Key Control)
the generation, distribution, storage, application and deletion of encryption keys
3.15
On-Board Equipment (OBE)
equipment located within the vehicle and supporting the information exchange with the Road Side Unit or the
Central Communication Unit. It is composed of the On-Board Unit and other sub-units whose presence have to be
considered optional for the exception of a Transaction
3.16
On-Board Unit (OBU)
minimum component of an On-Board Equipment, whose functionality always includes at least the support of the
DSRC interface or/and the Central Communication Unit and the protection of the data stored in the OBU
3.17
operator
generic term for the entities: Issuer, Clearing Operator, Collection Agent and Service Provider
3.18
Personalisation card (Set-up card)
an IC card to transcribe individual data such as vehicle information into an On-Board unit
3.19
privacy
the right of individuals to control or influence what information related to them can be collected and stored and by
whom and to whom that information may be disclosed
3.20
protection
the act of protecting, or the state of being protected; preservation from loss, theft, damage or unauthorised access
3.21
rationale (verification)
a process determining that a product of each phase of the system life cycle development process fulfils all the
requirements specified in the previous phase
3.22
reliability
An attribute of any system that consistently produces the same results, preferably meeting or exceeding its
specifications
3.23
responsibility
the state of being responsible, accountable, or answerable, as for an entity, function, system, security service or
obligation
3.24
Road Side Equipment (RSE)
equipment located at a fixed position along the road transport network, for the purpose of communication and data
exchanges with the On-Board Equipment of passing vehicles
8 © ISO 2004 – All rights reserved

3.25
Secure Application Module (SAM)
a module intended to contain algorithm(s), related keys, security procedures and information to protect an
application in such a way that unauthorised access is not possible. This can be achieved through physically,
electrically and logically protection of the module
3.26
Security Policy
a set of rules that regulate how to cope with security threats or what degree of security levels should be kept
3.27
Security Threat
a potential action or manner to violate security systems
3.28
Security Target (ST)
a set of security requirements and specifications to be used as the basis for evaluation of an identified TOE
3.29
Service Provider
the person, company, authority or abstract entity offering a transport service to the User for which the user has to
pay a fee (the fee will in some cases be zero, e.g. emergency vehicles)
3.30
Target Of Evaluation (TOE)
information security product or system for the subject of security evaluation
3.31
User
the entity that uses services provided by the Service Provider according to the terms of the Contract expressed by
the Payment Means. The User receives and reloads the electronic Payment Means through the Collection Agent
3.32
validity
the quality or state of being valid; having legal force
4 Abbreviations
4.1
CC
Common Criteria
4.2
CCRA
Common Criteria Recognition Arrangement
4.3
CN
Cellular Networks
4.4
DSRC
Dedicated Short Range Communication
4.5
EAL
Evaluation Assurance Level
4.6
EFC
Electronic Fee Collection
4.7
GNSS
Global Navigation Satellite Systems
4.8
HMI
Human Machine Interface
4.9
I/F
Interface
4.10
ICC
Integrated Circuit(s) Card
4.11
IT
Information Technology
4.12
OBE
On-Board Equipment
4.13
OBU
On-Board Unit
4.14
PP
Protection Profile
10 © ISO 2004 – All rights reserved

4.15
RSE
Road Side Equipment
4.16
SAM
Secure Application Module
4.17
SFP
Security Function Policy
4.18
SOF
Strength of Function
4.19
ST
Security Target
4.20
TOE
Target of Evaluation
4.21
TSF
TOE Security Functions
5 Outlines of Protection Profile
5.1 Structure
The content of a Protection Profile for a part or interface of an EFC system is shown in Figure 7.

Figure 7 — Content of a Protection Profile

5.2 Context
Guidelines for preparing PP are shown as follows:
a) Introduction (see Clause A.1)
b) Target of Evaluation (TOE, see Clause A.2)
The scope of the TOE shall be specified.
c) Security Environments (see Clause A.3)
Development, operation and control methods of TOE is described to clarify the working/operation
requirements. Regarding these requirements, IT assets, which TOE protects and security threats, to which
TOE is exposed, are specified.
d) Security Objectives (see Clause A.4)
Security policies for threats to TOE are determined. The policies are divided into technical policy and
operational/control policy.
Security objectives should be consistent with the operational aim or product purpose of the TOE.
Operational/control policy is defined as personnel and physical objectives in the status that TOE is used or
operated. The operational/control policy includes control and operational rules for operators.
12 © ISO 2004 – All rights reserved

e) Security Requirements (see Clause A.5)
In accordance with the security objectives defined in Clause A.4, concrete security requirements for security
threats stated in Clause A.3 are specified. The security requirements consist of functional requirements
(technical requirements) and assurance requirements for security quality.
Functional requirements are provided selecting necessary requirements from ISO/IEC 15408-2 and
determining parameters.
Regarding assurance requirements, assurance requirements designated in ISO/IEC 15408-3 are adopted by
determining evaluation levels (EAL) for assurance requirements, which are provided in ISO/IEC 15408.
f) Rationale of justification/effectiveness (see Clause A.6)
The contents of PP are checked when necessary and cover security requirements for TOE. The checked
items are shown as follows:
1) All security environments needed are covered;
2) Security objectives should completely meet the security environments;
3) Security requirements should implement security objectives.
Annex A
(informative)
Procedures of Preparing Documents
A.1 Introduction
A.1.1 General
General outline of the document for Protection Profile (PP) is described.
It should be noted that this chapter is informative nature. Most of the content is an example on how to prepare the
security requirements for EFC equipment; in this case an OBE with a smart card loaded with crucial data needed
for the Electronic Fee Collection.
NOTE The examples should only be regarded and used as an example.
A.1.2 Identification Information
Identification Information for the document is as follow:
a) Document title;
b) Version/Release number;
c) Preparation date;
d) Prepared by.
EXAMPLE Identification information
a) Document title: EFC On-Board Unit Security Protection Profile
b) Reference / Version number: 1.0
c) Preparation date 2002-10-20
d) Prepared by: ABC Association.

A.1.3 Target Of Evaluation (TOE) Description
TOE is identified as follows:
a) Product;
b) Version/Release number;
c) Developer.
EXAMPLE TOE description
a) Product EFC On-Board unit
b) Version/Release number 1.0
c) Developer ABC Co., Ltd.
14 © ISO 2004 – All rights reserved

A.1.4 Accordance with ISO/IEC 15408
The prepared “Protection Profile” in accordance with ISO/IEC 15408 is stated explicitly.
The version and preparation data of referenced ISO/IEC15408 are stated as well.
EXAMPLE
ISO/IEC 15408 conformance statement according to:
 ISO/IEC 15408-1:1999;
 ISO/IEC 15408-2:1999;
 ISO/IEC 15408-3:1999.
A.1.5 Outline of TOE
The following is provided as TOE in this document.
A.1.5.1 Classification of TOE
EXAMPLE
A.1.5.1 Classification of TOE
EFC on-board units
A.1.5.2 TOE functional outline
For users of security “Protection Profile”, types of devises described in “Protection Profile” are described explicitly
to help them determine the application.
EXAMPLE
A.1.5.2 TOE functional outline (OBU for EFC system)
The functional outline is as follows:
a) EFC function:
1) Mutual authentication with IC card;
2) Transcription(caching) of IC card data to OBU(On board unit);
3) Encryption of radio communication with RSE;
4) Assurance of message integrity;
5) Mutual authentication with RSE;
6) Storage of secured information (encryption key) used in OBU during EFC transaction;
b) Set-up function:
1) Authentication of set-up card;
2) Caching of vehicle information from IC card to OBU;
c) HMI function:
1) Report of EFC billing results to users;
2) Guidance of EFC lane.
A.1.5.3 Evaluation assurance level (EAL)
Evaluation assurance levels (EAL) for objectives are selected. Each EAL defines a package consisting of
assurance components and determines the degree of assurance requirements on security systems. The
justification for the selected EAL is stated.
EXAMPLE
A.1.5.3 EFC OBU (EAL is 5)
OBU functions as equipment for e-Commerce in EFC transactions. The security systems of EFC OBU are vulnerable to attack
under the control of individual users. Therefore, a high assurance level (EAL) will be required for EFC OBU.
A.2 Target of Evaluation (TOE)
A.2.1 TOE objectives and methodology
A.2.1.1 TOE use objectives
The following indicates objectives for TOE use and the type of environment in which it is used.
EXAMPLE EFC members (users) use the EFC system at tollgates by inserting the IC card with EFC member contract
information for settlement. Vehicle information such as automobile inspection certification is stored in OBU beforehand. For
storing vehicle information, a Personalisation card for initialisation is used. The OBU (TOE), which read/write data to IC cards for
set-ups/settlement and transmit/receive data to roadside equipment for toll collection transactions, protects interface and internal
data from external threats.
A.2.1.2 TOE use methodology
a) User preparations
Steps to be taken by users before use of TOE
b) Operators preparation
Necessary hardware/software and control systems are described when operators operate TOE
c) Operational procedures
Procedures for operation and maintenance are described.
d) Use procedures
Procedures for users are described.
e) Limitations of use
Limitations of use such as time zones and geographical zones are described.

EXAMPLE
a) User preparations
Users request an operator to install an OBU and set-up vehicle information such as automobile inspection certification to
OBU. In addition, users receive the ICC with EFC member contract information.
b) Operator preparations
Operators issue set-up information in response to user’s requests.
c) Operation procedures
When users are passing through tollgates, the tolls are billed to the IC cards for settlement with EFC member contract
information, which is inserted in the installed on-board units with vehicle information. When a legitimate IC card for
settlement is inserted in the OBU with correct vehicle information, the toll fee is calculated in the communication zone of
RSE at tollgates.
For a change or update of EFC member contract information such as vehicle information, set-up cards and ICC are
updated (reissued/reregistered).
d) Use procedures
Users use EFC system inserting IC cards with EFC member contract information at tollgates according to EFC member
contract or OBU manuals.
16 © ISO 2004 – All rights reserved

e) Limitations of use
In general, 24 h use is available, as long as EFC lanes are open at tollgates.
A.2.2 TOE functions
A.2.2.1 Functions provided by TOE
Functions, which are provided by TOE, are described. All functions for data transactions, which are protected, are
listed.
EXAMPLE
a) EFC transactions:
1) EFC communication control function;
2) Non-secure data record function;
3) HMI input/output control function;
4) IC card insert status detect function;
5) On-board unit self-check function;
b) Security module:
1) Data storage or protection function;
2) User access control function;
3) Authentication function(DSRC, ICC);
4) Encryption / Decryption function;
5) ICC interface function;
6) EFC transaction interface function;
7) Set-up card read function.
A.2.2.2 Functions not provided by TOE
When the TOE function is a part of functions of an entire system, the scope of the TOE in the whole system should
be shown as in Figure A.1 which shows an example where the OBU is the scope of the TOE.
EXAMPLE
Figure A.1 — An example where the TOE is shown in its context
A.2.2.3 Missing functions
When functions, which usually should be provided by the TOE in this section, are not included in the TOE, the
function contents and reasoning for exclusion should be described.
A.2.3 TOE structure
A.2.3.1 Hardware structure
The structure with related hardware units on TOE operation is described. The scope of TOE in the structure should
be shown as in Figure A.2.
EXAMPLE
Figure A.2 — An example on TOE hardware structure
18 © ISO 2004 – All rights reserved

A.2.3.2 Software structure
The structure with related software in the operation of TOE is described. In the structure, the scope of TOE in the
structure should be stated. Especially, when the operation of TOE depends on OS and data control programs, the
distribution of functions should be described.
A.2.3.3 Rationale
It should be verified that the described items are consistent.
a) Absence of inconsistent provision items;
b) Absence of undefined or unclear provisions of provided contents in this Clause.
A.3 Security Environment
A.3.1 Operation/operational environment of TOE
Security requirements to determine security objectives for TOE operation are provided.
A.3.1.1 Operational environments
The methodology of the use of TOE such as the operational environment, operational time, operational site, use
procedure and location of use is described. The described contents of “A.2.1.2 TOE use methodology” are
described in detail from the aspect of functionality.
a) Operational procedures
Regarding the operational procedures of TOE, the operation of an integrated EFC system including the related
vehicles and ICC for payment are described.
b) Operational time
The operational time zone of TOE is described.
EXAMPLE: The optional time is any time that EFC vehicles use on EFC toll roads
c) Operational sites
Operational sites of TOE are described.
d) Use procedures
The procedures from the purchase (obtain) to the disposal of TOE by users are described including installation
of TOE, set-up of TOE and operation at toll roads.
EXAMPLE
1) Users purchase EFC OBU at OBU dealers (car dealers, car shops). An OBU is installed in a vehicle. In addition, the
on-board information needed for the EFC operation such as vehicle information is stored as on-board information.
2) After EFC member contract, users get an ICC, which is issued by credit card companies.
3) Users will be able to use EFC system by inserting ICC in an OBU installed in a vehicle. The vehicles, which are
capable of using EFC systems, are called EFC vehicles.
4) Users use toll roads with ICC inserted in an OBU in an EFC vehicle and pass through the tollgates without stopping.
Users can dispose of unnecessary OBU voluntarily.
e) Use sites
Sites, where users are able to use TOE, are described.
EXAMPLE Toll roads, along which EFC RSE are installed
f) Limits and requirements in use such as available numbers of TOE are described.
EXAMPLE
1) The number of OBU installed per vehicle is limited to one.
2) OBU are fixed (built-in) in a vehicle.
3) OBU can be used 24 h a day as long as EFC lanes are open for Operation.
A.3.1.2 Physical control
Physical control related to the operation of TOE is described.
a) Installation sites and control
Installation sites and physical control of TOE are described.
EXAMPLE OBU is fixed (built-in) in a vehicle.
b) User unit
For use of TOE, the physical control requirements of ICC for payments, which users possess is described.
EXAMPLE Users are responsible for their ICC
20 © ISO 2004 – All rights reserved

A.3.1.3 Personnel requirements
The personnel requirements for the responsibility and confidence of TOE operation are described. In addition, the
requirements for potential uses, motivations, methods and expertise of attacks are provided.
a) TOE related agents
The following items regarding the manufactures, operators and users of TOE are stated.
1) Type;
2) Role;
3) Authorisation;
4) Reliance;
5) Risk of illicit use;
6) Expertise;
7) Trail;
EXAMPLE Personal requirements
1) Type:  Manufacturer of On-Board unit
2) Role:  Manufacturing and shipping based on standard specification of EFC OBU
3) Authorisation:  None
4) Reliance: No responsibility for security control
5) Risk of illicit use: There are risks of illicit use since the responsibility for security control is absent.
6) Expertise: No need of expertise for security
7) Trail:  Negative list check is implemented while EFC vehicles are passing through tollgates
.
b) Attackers
The following items are described for illicit user requirements against which countermeasure are taken by TOE
1) Type
2) Purpose of illicit use
3) Motivation
4) Means
5) Expertise
EXAMPLE Attackers
1) Type: Illicit third party among EFC users
2) Purpose of illicit use: OBU data forgery, manipulation, obtaining of personal information. Forgery and illicit
modification of OBU medium
3) Motivation: To reduce toll fees or avoid toll fee claims by illicit use of information. Sale of forged OBU.
4) Means: Forgery of vehicle information on On-Board units. Forgery of I/F data between OBU and ICC
to counterfeit someone’s card. Forgery of EFC OBU by analysing OBU internally.
5) Expertise: Comprehend the internal transaction by analysing EFC On-Board units internally.
A.3.1.4 Connectivity/operational environments
The environment for TOE connectivity and operation is provided. Only the structure, which is provided in this
section, shall be TOE.
a) Connectivity
Transactions for RSE at tollgates and ICC needed for the operation of TOE are described.
EXAMPLE
— OBU exchange information via radio communication (5.8 GHZ) with RSE at tollgates.
— OBU read IC card data (card number, ETC member contract information) before vehicles pass through tollgates.
When vehicles pass through tollgates, OBU send applicable IC card internal data to RSE to transmit billing and
transaction record data.
b) Operational requirements
Hardware/ software requirements needed for operation of TOE are described.
(CPU implementation speed, required memory, input/output devices)
A.3.1.5 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items;
b) Absence of undefined or unclear items of provided contents in this Clause.
A.3.2 Security Threats
Security Threats for TOE are as follows:
A.3.2.1 Determination of target resources for protection
a) Selection of target resources for protection

Target resources for protection, to be protected by TOE are determined. Resources, which negatively impact
services of TOE by falsification, alteration and loss, are targeted for protection. Regarding determined
individual targeted resources for protection, the lifecycle such as generation, transaction, storage and disposal
are clearly described. If there are indirect resources for a TOE transaction, the indirect resources are
determined as well.
EXAMPLE
a) Target protection resources to be protected by TOE
— ETC member contract information: ICC internal data (i.e. IC card number)
— Vehicle information: OBU internal data such as vehicle classification codes
— Toll gate information: Exit/enter information, barrier information, and transaction record information
— The information stated above is transmitted by radio communication through OBU between roadside units at
tollgates and ICC.
— Toll information: Storage in ICC such as billing information
b) Target resources for protection such as lifecycle
— OBU installation in a vehicle
— Transcription of vehicle information into OBU
22 © ISO 2004 – All rights reserved

— OBU operation at toll roads
— OBU disposal
b) Evaluation of target resources for protection

The values of determined target resources for protection are evaluated. The evaluation is divided into three
levels as follows:
 Level 1: Security problems impact on entire system for TOE. For instance, the system might be
malfunctioning or down.
 Level 2: Security problems drastically compromise the value of system for TOE. For instance, the social
responsibility for the systems impaired. However, restoration of systems is attainable.
 Level 3: Security problems hinder the operation of TOE. For instance, operation of the systems is
temporally interrupted resulting in serious impact on the users.
EXAMPLE
Evaluation of target resource for protection
Level 1: Non (No target resource for protection, which impacts systems such as destroying ETC systems
Level 2: ETC member contract information
Level 3: Vehicle information, tollgate information, toll information
A.3.2.2 Identification of security threats
Potential threats are identified by level of determined target resources for protection. Concrete analysis of target
resource for protection is implemented in terms of who (what), where, when, how (counterfeiting, tapping,
destruction), means (available resources, interface, expertise), threats (falsification, exposure, service interruption)
and reasons.
a) Who (What):
Who (what) generating threats is stated;
b) Target resource:
Target resource for threats (billing data, personal information) is stated;
c) Contents of threats:
Major threats are as follows:
1) Lack of confidentiality;
2) Lack of protection;
3) Lack of availability;
4) Lack of responsibility;
5) Lack of integrity;
6) Lack of reliability;
d) Means:
Means generating attacks are stated;
e) Methodology:
Methodology of attacks is stated;
f) Motivation:
Motivation of attacks is stated;
g) Opportunity:
Opportunity of attacks is stated;
h) Weak points:
Security weaknesses are stated.
Threat analysis, e.g. for lifecycle of target data for protection is shown in Table A.1.
24 © ISO 2004 – All rights reserved

Table A.1 — Example for threat analysis in lifecycle of ETC on-board unit data for protection
0. Manufacturing 1. OBU is installed 2. Vehicle information is 3. OBU is operated at toll 4. OBU is disposed

in a vehicle transcribed into OBU roads

Lifecycle: Threat analysis for “3. OBU operation at toll roads”
Information for protection Threat
Who Where When Methodology, means Threats Why
ETC member contract Illicit third party OBU While inserting ICC Forge ICC or I/F data to Forgery and altering of Avoid toll fee claim
information falsify someone’s card ICC internal data
Vehicle information OBU Anytime / While passing Forgery of vehicle codes Forgery and Reduce toll fee
tollgates of OBU manipulation of OBU
internal data
Tollgate information Tollgate lanes Communication (billing) Eavesdropping of radio Tapping of radio Obtain personal
communication. communication data. information.
Toll fee information
Replay the Communication data Reduce or avoid toll fee.
eavesdropped data. manipulation.
Replay attack.
A.3.2.3 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items;
b) Absence of undefined or unclear items of provided contents in this Clause.
A.3.3 Securit
...