CEN/TS 16439:2013

SLOVENSKI STANDARD
01-april-2013
Elektronsko pobiranje pristojbin - Varnostni okvir
Electronic fee collection - Security framework
Elektronische Gebührenerhebung - Sicherheitsgrundstruktur
Perception de télépéage - Cadre de sécurité
Ta slovenski standard je istoveten z: CEN/TS 16439:2013
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16439
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
January 2013
ICS 35.240.60
English Version
Electronic fee collection - Security framework
Perception de télépéage - Cadre de sécurité Elektronische Gebührenerhebung -
Sicherheitsgrundstruktur
This Technical Specification (CEN/TS) was approved by CEN on 27 August 2012 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2013 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16439:2013: E
worldwide for CEN national Members.

Contents Page
Foreword . 6
0 Introduction . 7
0.1 Reader's guide . 7
0.2 EFC role model . 8
0.3 Relation to other security standards . 9
1 Scope . 11
1.1 EFC specific scope . 11
1.2 Scope in relation to other security frameworks . 14
2 Normative references . 15
3 Terms and definitions . 16
4 Symbols and abbreviations . 22
5 Trust model . 24
5.1 Introduction . 24
5.2 Stakeholders trust relations . 24
5.3 Technical trust model . 25
5.3.1 General . 25
5.3.2 Trust model for TC and TSP relations . 25
5.3.3 Trust model for TSP and User relations . 27
5.3.4 Trust model for Interoperability Management relations . 27
5.4 Implementation . 27
5.4.1 Setup of trust relations . 27
5.4.2 Trust relation renewing and revocation . 27
5.4.3 Issuing and revocation of sub CA and entity certificates . 28
5.4.4 Certificate and Certificate Revocation List profile and format . 28
5.4.5 Certificate extensions . 28
6 Security requirements. 29
6.1 Introduction . 29
6.2 Information Security Management System . 29
6.3 Communication interfaces . 30
6.3.1 General . 30
6.3.2 Generic interface requirements . 31
6.3.3 DSRC profile . 31
6.3.4 TC to TSP profile . 32
6.3.5 Communication provider profile. 32
6.4 Data storages . 33
6.4.1 General . 33
6.4.2 OBE data storages . 33
6.4.3 RSE data storages. 33
6.4.4 Back End data storage . 34
6.5 Toll Charger . 34
6.6 Toll Service Provider . 35
6.7 User. 37
6.8 Interoperability Management . 38
6.9 Limitation of requirements . 38
7 Security measures - countermeasures . 38
7.1 Introduction . 38
7.2 General security measures . 39
7.3 Communication interfaces security measures . 39
7.3.1 General .3 9
7.3.2 DSRC-EFC interface .3 9
7.3.3 CCC interface . 40
7.3.4 LAC interface .4 0
7.3.5 Front End to TSP Back End interface .4 1
7.3.6 TC to TSP interface .4 1
7.4 End-to-end security measures .4 1
7.5 Toll Service Provider security measures .4 3
7.5.1 Front End security measures.4 3
7.5.2 Back End security measures .4 3
7.6 Toll Charger security measures.4 4
7.6.1 RSE security measures .4 4
7.6.2 Back End security measures .4 4
7.6.3 Other TC security measures .4 4
8 Security specifications for interoperable interface implementation . 45
8.1 General .4 5
8.1.1 Subject .4 5
8.1.2 Signature and hash algorithms .4 5
8.1.3 MAC algorithm .4 5
8.1.4 MAC key derivation .4 6
8.1.5 Key encryption algorithm.4 6
8.1.6 Padding algorithm .4 6
8.2 Security specifications for DSRC-EFC .4 6
8.2.1 Subject .4 6
8.2.2 OBE .4 6
8.2.3 RSE .4 7
8.3 Security specifications for CCC.4 7
8.3.1 Subject .4 7
8.3.2 OBE .4 7
8.3.3 RSE .4 7
8.4 Security specifications for LAC .4 7
8.4.1 Subject .4 7
8.4.2 OBE .4 7
8.4.3 RSE .4 7
8.5 Security specifications for Front End to TSP interface . 48
8.5.1 General .4 8
8.5.2 ChargeReport message authentication .4 8
8.6 Security specifications for TC to TSP interface .4 9
8.6.1 General .4 9
8.6.2 Secure communication channel .4 9
8.6.3 Message authentication .4 9
8.6.4 Proof of message delivery .5 1
8.6.5 TSP ChargeReport authentication . 51
9 Key management .5 2
9.1 Introduction .5 2
9.2 Asymmetric keys .5 2
9.2.1 Key exchange between stakeholders .5 2
9.2.2 Key generation and certification.5 2
9.2.3 Protection of Keys .5 3
9.2.4 Application.5 3
9.3 Symmetric keys .5 3
9.3.1 Introduction .5 3
9.3.2 Key exchange between stakeholders .5 3
9.3.3 Key lifecycle .5 4
9.3.4 Key storage and protection .5 6
9.3.5 Session keys .5 7
Annex A (normative) Data type specification.5 8
Annex B (normative) Implementation Conformance Statement (ICS) proforma . 62
B.1 Guidance for completing the ICS proforma . 62
B.1.1 Purposes and structure . 62
B.1.2 Abbreviations and conventions. 62
B.1.3 Instructions for completing the ICS proforma . 64
B.2 Identification of the implementation . 64
B.2.1 General . 64
B.2.2 Date of the statement . 64
B.2.3 Implementation Under Test (IUT) identification . 64
B.2.4 System Under Test (SUT) identification . 65
B.2.5 Product supplier . 65
B.2.6 Applicant (if different from product supplier) . 66
B.2.7 ICS contact person . 66
B.3 Identification of the standard . 67
B.4 Global statement of conformance . 67
B.5 Roles . 67
B.6 Trust Model functionalities . 67
B.7 Profiles . 68
B.8 Requirements . 68
B.9 Security measures . 71
B.10 Specifications for interoperable interfaces security . 74
Annex C (informative) Stakeholder objectives and generic requirements . 76
C.1 Introduction . 76
C.2 Toll Chargers . 77
C.2.1 Toll chargers and their main interests . 77
C.2.2 Security service requirements for a Toll Charger . 77
C.3 Toll Service Providers . 78
C.3.1 Toll service providers and their main interests . 78
C.3.2 Security service requirements for a Toll Service Provider . 78
C.4 Users . 79
C.4.1 Users and their main interests . 79
C.4.2 Users requirements . 79
C.5 Interoperability Management . 79
C.5.1 Interoperability management and its main interests . 79
C.5.2 Security service requirements for interoperability management . 80
Annex D (informative) Threat analysis . 81
D.1 General introduction . 81
D.2 Attack trees based threat analysis . 81
D.2.1 Introduction . 81
D.2.2 System model . 82
D.2.3 Presentation of attack trees . 83
D.2.4 Attacker class 1: User . 84
D.2.5 Attacker class 2: Toll Service Provider . 86
D.2.6 Attacker class 3: Toll Charger . 89
D.2.7 Attacker class 4: Hacker . 91
D.2.8 Attacker class 5: Activist . 94
D.2.9 Attacker class 6: Communication provider . 95
D.2.10 Attacker class 7: Enterprise . 96
D.2.11 Attacker class 8: Government . 99
D.2.12 Attacker class 9: Foreign power . 101
D.3 Asset based threat analysis . 102
D.3.1 General . 102
D.3.2 Threatened Assets . 102
D.3.3 Compliance matrix . 104
D.3.4 Presentation of threats . 106
D.3.5 Generic threats . 107
D.3.6 Asset: Billing details . 109
D.3.7 Asset: OBE Charge Report . 110
D.3.8 Asset: Customisation information . 111
D.3.9 Asset: User contract information . 111
D.3.10 Asset: Exception List . 112
D.3.11 Asset: "Help, info, complain". 112
D.3.12 Asset: OBE .1 13
D.3.13 Asset: User privacy . 115
D.3.14 Asset: RSE .1 15
D.3.15 Asset: EFC stakeholders image and reputation . 116
D.3.16 Asset: TC and TSP central system . 117
D.3.17 Asset: Transit information . 117
D.3.18 Asset: Trust object . 118
D.3.19 Asset: User identification. 120
D.3.20 Asset: Context Data . 120
D.3.21 Asset: Payment means . 121
D.3.22 Asset: Limited autonomy . 122
D.3.23 Asset: EFC Schema . 122
D.3.24 Asset: Contractual conditions . 123
D.3.25 Asset: Operational rules . 124
D.3.26 Asset: Complaint . 125
D.3.27 Asset: Certification . 127
D.3.28 Asset: Operational report. 128
Annex E (informative) Security Policies . 129
E.1 Introduction .1 29
E.1.1 Scope of the annex . 129
E.1.2 Motivation for the need of security policies . 129
E.2 Example EFC scheme security policy . 129
E.2.1 Motivation for information security . 129
E.2.2 Purpose of the security policy . 130
E.2.3 Scope .1 30
E.2.4 Policy statements . 132
E.3 Development of operators security policies . 134
E.3.1 General .1 34
E.3.2 Interface requirements . 135
E.3.3 Data storage requirements . 135
Annex F (informative) Example for an EETS Security Policy . 136
F.1 Introduction .1 36
F.2 Basic laws and regulations . 136
F.3 Organisation of EETS Information Security . 136
F.3.1 General .1 36
F.3.2 Steering Committee . 136
F.3.3 Trust Model .1 36
Annex G (informative) Requirements on privacy-focused implementation . 138
G.1 Introduction .1 38
G.2 Legal basis .1 38
G.2.1 EU Directive 95/46/EC. 138
G.2.2 European data protection supervisor (EDPS) . 138
G.3 Users’ requirements . 139
Bibliography .1 40

Foreword
This document (CEN/TS 16439:2013) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
0 Introduction
0.1 Reader's guide
The development process for the security concept and implementation to protect an existing system normally
includes several steps as follows: threat analysis with risk assessment, security policy definition, requirements
and countermeasures definition followed by the implementation of countermeasures and supervising of their
effectiveness. Countermeasures which do not work or work incorrectly need to be improved. The development
of the Electronic Fee Collection (EFC) - Security Framework follows this approach as closely as possible,
although there is no existing system to analyse. The used methodology needs to consider following
limitations:
 No risk assessment possible: The risk assessment compares the possible loss for the stakeholder and
the required resources (e.g. equipment, knowledge, time, etc.) to perform an attack. It is the trade-off
evaluation of the cost and benefit of each countermeasure which is only possible for an existing system.
 No security policy exists. The security policy can only be defined by the responsible stakeholder and its
freedom is only limited by laws and regulations. Nonetheless, basic but incomplete examples of possible
security policies can be provided.
 No specific system design or configuration exists to be based on. Only the available EFC base standards
can be taken as references. Specific technical details of a particular system (e.g. servers, computer
centres, de-central elements like road side equipment) need to be taken into consideration in addition to
the present security framework.
The selection of requirements and the respective security measures for an existing EFC system is based on
the security policy and the risk assessment of the several stakeholders for their system parts. Due to the fact
that there is neither an overall valid security policy, nor that the possibility to provide a useful risk assessment
exists, the EFC security framework provides a toolbox of requirements and security measures covering as
many threats as possible.
To understand the content of this Technical Specification, the reader should be aware of the methodological
assumptions used to develop it. The security of an (interoperable) EFC scheme depends on the correct
implementation and operation of a number of processes, systems and interfaces. Only a reliable end-to-end
security ensures the accurate and trustworthy operation of interacting components of toll charging
environments. Therefore, this security framework also covers systems or interfaces which are not EFC-
specific, like back-office connections. For such parts however, only requirements and recommendations, no
security measures, are provided. The application independent security framework for such system parts and
interfaces, the Information Security Management System (ISMS), is provided in the ISO 2700x family of
standards.
The development process of this Technical Specification is described briefly in the steps below:
a) Definition of the stakeholder objectives as the basic motivation for the security requirements (Annex C).
b) Based on the EFC role model and further definitions from the EFC architecture standard (ISO 17573), the
specification defines an abstract EFC system model as the basis for threat analysis, definition of
requirements and security measures (see Clause 1 and Annex D).
c) The threats on the EFC system model and its assets are analysed by two different methods: an asset-
based analysis and an attack-based analysis. This approach, although producing some redundancy,
ensures completeness and coverage of all relevant factors (Annex D).
d) The requirements specification (Clause 6) is based on the threats identified in Annex D. Each
requirement is at least motivated by one threat. At this stage, the specification does not prescribe any
concrete implementation of a security requirement.
e) The definition of security measures (Clause 7) provides a high level description of recommended possible
methods to achieve and implement the goal(s) of the fulfilled requirements.
f) Detailed security measures are only provided for the implementation of the interoperable interfaces
(Clause 8) based on the requirements and the high level security measures.
g) Basic key management requirements that support the implementation of the interoperable interfaces
security measures are described in Clause 9.
A general trust model (Clause 5) is defined to form the basis for the implementation of cryptographic
procedures to ensure confidentiality, integrity and authenticity of exchanged data. In this context, the security
framework references approved international standards for the implementation of cryptographic procedures,
enhanced by EFC specific details if needed.
A stakeholder of an EFC scheme who wants to use this security framework needs to do the following:
1) Identify the relevant processes, systems and interfaces in the security framework.
2) Extract the corresponding security requirements according to his security policy.
3) Provide evidence of compliance of its systems, processes and interfaces with the requirements of
this specification. Evidence can be provided by a self-declaration, an internal or external audit or
other certifications.
0.2 EFC role model
This Technical Specification complies with the role model defined in ISO 17573, Electronic fee collection 
System architecture for vehicle-related tolling. According to this role model, the Toll Charger (TC) is the
provider of the tolled infrastructure or transport service and, hence, the recipient of the road usage charges.
The Toll Charger is the actor associated with the Toll Charging role; see Figure 1.

Figure 1 — The role model underlying this standard
Service Providers issue on-board equipment (OBE) to the users of the tolled infrastructure or transport
service. Service Providers are responsible for providing the OBE that will be used for collecting data, enabling
the Toll Charger to send a claim to the Service Provider for the usage of the infrastructure or transport service.
In autonomous systems, each Service Provider delivers toll declarations to several Toll Chargers, as well as
each Toll Charger receives toll declarations from more than one Service Provider. In dedicated short-range
communication (DSRC) systems, the Toll Charger receives the main toll declarations from its own RSE and
only supplementary charging data, if required from the Service Providers. Interoperability Management (IM) in
Figure 1 comprises all specifications and activities that in common define and maintain a set of rules that
govern the overall toll charging environment.
The trust model defined in this Technical Specification is based on the role model above and it is also the
technical base for the protection of the data communication between the entities of the role model. Besides
this communication security, trust in the secure implementation and management of the Back End and other
equipment for the EFC framework is required. A Toll Charger or Service Provider compliant to this Technical
Specification needs to be able to give evidence of security management as required. Such evidence is the
basement of trust relations between the involved entities.
0.3 Relation to other security standards
Several generic and specific standards and Technical Reports concerning security issues for information
technology already exist. This Technical Specification uses these existing standards and expands the usability
of them for EFC applications. The framework will reference and tailor the security techniques and
methodologies from these standards.
Figure 2 illustrates the context of the EFC Security Framework to other security standards. It is not exhaustive
description; only the most relevant standards are shown, i.e. the standards that gave most input to this
Technical Specification. Standards that are directly used and referenced are highlighted in black (as opposed
to grey). Other standards that may provide other security related input are given for information and
completeness only but are not further used.
Each group of standards in Figure 2 provides the following features:
 Security techniques - Security measures and algorithms – The group is a collection of essential
security measures and recommended cryptographic algorithms, including the guidelines for the accurate
use of them.
 IT - Security techniques - Information security management system – This standard family defines
requirements and guidelines for the implementation of security management systems for all types of
organisations. The standards are well suited for the security solutions of the Back End and other fixed or
installed equipment including software of EFC systems.
 IT - Open system interconnection – This group of standards provide mechanisms for the secure
communications between open systems. The standards address some of the security requirements in the
areas of authentication and other security services through the provision of a set of frameworks.
 Evaluation criteria for IT security (Common Criteria) – This standard group defines methodologies
and processes for the security evaluation and certification for most categories of products used in the
EFC environment. The arrows inside the group indicate the relation between the standards in a bottom up
direction.
In addition, the EFC Security Framework makes use of existing threat analysis methods and also uses
existing threat analysis with relations to EFC or ITS, e.g. ETSI TR 102 893 (Intelligent Transport Systems;
Security; Threat, Vulnerability and Risk Analysis).
...