BSI PD CEN/TS 16439:2013

1.1 EFC specific scope

ISO 17573 defines the roles and functions as well as the internal and external entities of the EFC system environment. Based on the system architecture defined in ISO 17573, the security framework describes a set of requirements and security measures for stakeholders to implement and operate their part of an EFC system as required for a trustworthy environment according to its basic information security policy. In general, the overall scope is an information security framework for all organisational and technical entities and in detail for the interfaces between them.

Figure 3 below illustrates the abstract EFC system model used to analyse the threats, define the security requirements and security measures of this Technical Specification. This Technical Specification is based on the assumption of an OBE which is dedicated to EFC purposes only and neither considers value added services based on EFC OBE, nor more generic OBE platforms (called in-vehicle ITS Stations) used to host the EFC application.

The trust model comprises all basic assumptions and principles for establishing trust between the stakeholders. The trust model forms the basis for the implementation of cryptographic procedures to ensure confidentiality, integrity, authenticity and partly non-repudiation of exchanged data.

The scope of this security framework comprises the following:

• general information security objectives of the stakeholders;

• threat analysis;

• definition of a trust model;

• security requirements;

• security measures – countermeasures;

• security specifications for interface implementation;

• key management;

• security policies;

• privacy-enabled implementations.

The following is outside the scope of this Technical Specification:

• a complete risk assessment for an EFC system;

• security issues rising from an EFC application running on an ITS station;

NOTE Security issues associated with an EFC application running on an ITS station will be covered in a CEN Technical Report on “Guidelines for EFC-applications based on in vehicle ITS Stations” that is being developed at the time of publication of this document.

• entities and interfaces of the interoperability management role;

• the technical trust relation of the model between TSP and User;

• a complete specification and description of all necessary security measures to all identified threats;

• concrete implementation specifications for implementation of security for EFC system, e.g. European electronic toll service (EETS);

• detailed specifications required for privacy-friendly EFC implementations.

The detailed scope of the bullet points and the clause with the corresponding content is given below:

• General information security objectives of the stakeholders (informative, Annex C)

  To derive actual security requirements and define implementations, it is crucial to gain a common understanding of the possible different perspectives and objectives of such stakeholders of a toll charging environment.

• Threat analysis (informative, Annex D)

The threat analysis is the basis and motivation for all the security requirements resulting in this framework. The results from two complementary approaches will be combined in one common set of requirements. The first approach considers a number of threat scenarios from the perspective of various attackers. The second approach looks in depth on threats against the various identified assets (tangible and intangible entities).

• Definition of a trust model (normative, Clause 5)

The trust model comprises all basic assumptions and principles for establishing trust between the stakeholders. The trust model forms the basis for the implementation of cryptographic procedures to ensure confidentiality, integrity, authenticity and partly non-repudiation of exchanged data.

• Security requirements (normative, Clause 6)

Based on the threat analysis, security requirements are defined (e.g. for organisational and technical entities, interfaces, information etc) from which a system operator can draw its own applicable set according to the actual security policy. No concrete implementation specifications will be given as they are strongly dependent on the actual context of the toll charging environment and the relations between the stakeholders. A basic risk analysis of the interfaces shown in Figure 4 introduces the minimum set of security requirements for the protection of these interfaces.

• Security measures – countermeasures (normative, Clause 7)

A set of security measures mainly for data protocol layer of interfaces according to Figure 4 based on the requirements is defined to support actual EFC system implementations and as a base for the security specifications for interoperable interface implementation.

• Security specifications for interface implementation (normative, Clause 8)

To support the future implementation of (interoperable) toll charging environments, this specification provides precise implementation specifications for the interfaces, e.g. the detailed definition of message authenticators. These specifications represent an add-on for security to the corresponding standards. Figure 4 shows the relevant interfaces and the corresponding standards which need to be enhanced by proper security provisions.

• Key management (normative, Clause 9)

The toll charging environment uses cryptographic elements (keys, certificates, revocation lists etc) to support security services like confidentiality, authenticity, integrity and non-repudiation. This section of thespecification covers the initial setup of key exchange between stakeholders and several operational procedures like key renewal, certificate revocation etc.

specification covers the initial setup of key exchange between stakeholders and several operational procedures like key renewal, certificate revocation etc.

• Implementation conformance statement (ICS) proforma (Annex B)

Annex B defines the implementation conformance statement proforma to be used by an equipment supplier, a system implementation or an actor of a role declaring his conformity to this Technical Specification.

• Security policies (informative, Annex E and Annex F)

As an aid for using this Technical Specification to build up a secure system, some examples are provided of what security policies could look like for a concrete interoperability framework (including European electronic toll service).

• Privacy-enabled implementations (informative, Annex G)

Respecting privacy is crucial for the implementation of every toll charging environment. However, different Toll Chargers may have different requirements on the level of privacy. This Technical Specification supports implementations with respect to privacy, but does not mandate one specific implementation. Therefore, it summarises the general requirements and conditions in relation to data privacy.

1.2 Scope in relation to other security frameworks

In general the overall scope is an information security framework for all organisational and technical entities of an EFC environment and in detail for the interfaces between them. This Technical Specification covers only the EFC specific aspects and not general IT security aspects. A general and complete IT security guideline, the Information Security Management System, is provided in the ISO 2700x family of standards.

A corresponding ISO/IEC 27001 certification of a TC or Toll Service Provider (TSP) organisation may be used to demonstrate fulfilment of this Technical Specification provided that the scope and the Statements of Applicability (SoA) include the EFC business processes specified in ISO 17573 and the security measures provided by this Technical Specification are applied, e.g. by using them as part of the so-called catalogues containing the security measures and control objectives.

PDF Catalog

PDF Pages	PDF Title
3	CEN/TC 278 CEN/TS 16439:2012 CEN/TC 278 Electronic fee collection — Security framework ICS:
9	0 Introduction 0.1 Reader’s guide
10	0.2 EFC role model
11	0.3 Relation to other security standards
13	1 Scope 1.1 EFC specific scope
16	1.2 Scope in relation to other security frameworks
17	2 Normative references
18	3 Terms and definitions
24	4 Symbols and abbreviations
26	5 Trust model 5.1 Introduction 5.2 Stakeholders trust relations
27	5.3 Technical trust model 5.3.1 General 5.3.2 Trust model for TC and TSP relations
29	5.3.3 Trust model for TSP and User relations 5.3.4 Trust model for Interoperability Management relations 5.4 Implementation 5.4.1 Setup of trust relations 5.4.2 Trust relation renewing and revocation
30	5.4.3 Issuing and revocation of sub CA and entity certificates 5.4.4 Certificate and Certificate Revocation List profile and format 5.4.5 Certificate extensions
31	6 Security requirements 6.1 Introduction 6.2 Information Security Management System
32	6.3 Communication interfaces 6.3.1 General
33	6.3.2 Generic interface requirements 6.3.3 DSRC profile
34	6.3.4 TC to TSP profile 6.3.5 Communication provider profile
35	6.4 Data storages 6.4.1 General 6.4.2 OBE data storages 6.4.3 RSE data storages
36	6.4.4 Back End data storage 6.5 Toll Charger
37	6.6 Toll Service Provider
39	6.7 User
40	6.8 Interoperability Management 6.9 Limitation of requirements 7 Security measures – countermeasures 7.1 Introduction
41	7.2 General security measures 7.3 Communication interfaces security measures 7.3.1 General 7.3.2 DSRC-EFC interface
42	7.3.3 CCC interface 7.3.4 LAC interface
43	7.3.5 Front End to TSP Back End interface 7.3.6 TC to TSP interface 7.4 End-to-end security measures
45	7.5 Toll Service Provider security measures 7.5.1 Front End security measures 7.5.2 Back End security measures
46	7.6 Toll Charger security measures 7.6.1 RSE security measures 7.6.2 Back End security measures 7.6.3 Other TC security measures
47	8 Security specifications for interoperable interface implementation 8.1 General 8.1.1 Subject 8.1.2 Signature and hash algorithms 8.1.3 MAC algorithm
48	8.1.4 MAC key derivation 8.1.5 Key encryption algorithm 8.1.6 Padding algorithm 8.2 Security specifications for DSRC-EFC 8.2.1 Subject 8.2.2 OBE
49	8.2.3 RSE 8.3 Security specifications for CCC 8.3.1 Subject 8.3.2 OBE 8.3.3 RSE 8.4 Security specifications for LAC 8.4.1 Subject 8.4.2 OBE 8.4.3 RSE
50	8.5 Security specifications for Front End to TSP interface 8.5.1 General 8.5.2 ChargeReport message authentication
51	8.6 Security specifications for TC to TSP interface 8.6.1 General 8.6.2 Secure communication channel 8.6.3 Message authentication
53	8.6.4 Proof of message delivery 8.6.5 TSP ChargeReport authentication
54	9 Key management 9.1 Introduction 9.2 Asymmetric keys 9.2.1 Key exchange between stakeholders 9.2.2 Key generation and certification
55	9.2.3 Protection of Keys 9.2.4 Application 9.3 Symmetric keys 9.3.1 Introduction 9.3.2 Key exchange between stakeholders
56	9.3.3 Key lifecycle 9.3.3.1 General 9.3.3.2 DSRC keys
57	9.3.3.3 MAC keys
58	9.3.4 Key storage and protection 9.3.4.1 Master keys 9.3.4.2 OBE keys
59	9.3.5 Session keys
60	Annex A (normative) Data type specification
64	Annex B (normative) Implementation Conformance Statement (ICS) proforma B.1 Guidance for completing the ICS proforma B.1.1 Purposes and structure B.1.2 Abbreviations and conventions
66	B.1.3 Instructions for completing the ICS proforma B.2 Identification of the implementation B.2.1 General B.2.2 Date of the statement B.2.3 Implementation Under Test (IUT) identification
67	B.2.4 System Under Test (SUT) identification B.2.5 Product supplier
68	B.2.6 Applicant (if different from product supplier) B.2.7 ICS contact person
69	B.3 Identification of the standard B.4 Global statement of conformance B.5 Roles B.6 Trust Model functionalities
70	B.7 Profiles B.8 Requirements
73	B.9 Security measures
76	B.10 Specifications for interoperable interfaces security
78	Annex C (informative) Stakeholder objectives and generic requirements C.1 Introduction
79	C.2 Toll Chargers C.2.1 Toll chargers and their main interests C.2.2 Security service requirements for a Toll Charger
80	C.3 Toll Service Providers C.3.1 Toll service providers and their main interests C.3.2 Security service requirements for a Toll Service Provider
81	C.4 Users C.4.1 Users and their main interests C.4.2 Users requirements C.5 Interoperability Management C.5.1 Interoperability management and its main interests
82	C.5.2 Security service requirements for interoperability management
83	Annex D (informative) Threat analysis D.1 General introduction D.2 Attack trees based threat analysis D.2.1 Introduction
84	D.2.2 System model
85	D.2.3 Presentation of attack trees
86	D.2.4 Attacker class 1: User D.2.4.1 General D.2.4.2 Intention: Avoiding payment of toll
88	D.2.4.3 Intention: Foiling the system D.2.4.4 Intention: Protecting the Users own privacy D.2.5 Attacker class 2: Toll Service Provider D.2.5.1 General
89	D.2.5.2 Intention: Increase revenue from customer / overcharge customer D.2.5.3 Intention: Profiling of customer D.2.5.4 Intention: Resale of data about customers
90	D.2.5.5 Intention: Reduction in payments to Toll Charger
91	D.2.5.6 Intention: To allow the use of cheaper (substandard) equipment D.2.6 Attacker class 3: Toll Charger D.2.6.1 General D.2.6.2 Intention: To increase revenue
92	D.2.6.3 Intention: To resell user data for revenue
93	D.2.7 Attacker class 4: Hacker D.2.7.1 General D.2.7.2 Intention: To demonstrate a system vulnerability
94	D.2.7.3 Intention: To obtain respect amongst their peers
95	D.2.7.4 Intention: To Improve understanding of the system or to research its operation D.2.7.5 Intention: Provide fake OBE
96	D.2.8 Attacker class 5: Activist D.2.8.1 General D.2.8.2 Intention: Societal destabilisation through manipulation of the tolling system
97	D.2.8.3 Intention: Raise in profile of the activists cause D.2.8.4 Intention: Direct furthering of activists cause D.2.8.5 Intention: Reduction in credibility of the system D.2.9 Attacker class 6: Communication provider D.2.9.1 General D.2.9.2 Intention: Increase network utilisation
98	D.2.9.3 Intention: Decrease network utilisation D.2.9.4 Intention: Collecting travel behaviour D.2.10 Attacker class 7: Enterprise D.2.10.1 General
99	D.2.10.2 Intention: Movement tracking D.2.10.3 Intention: Creation and distribution of cloned equipment D.2.10.4 Intention: Disable/compromise system encryption
100	D.2.10.5 Intention: Steal equipment D.2.10.6 Intention: Extortion
101	D.2.11 Attacker class 8: Government D.2.11.1 General D.2.11.2 Intention: In theatre commercial advantage D.2.11.3 Intention: Political targeting of individuals and organisations
102	D.2.11.4 Intention: Tracking of Individuals
103	D.2.12 Attacker class 9: Foreign power D.2.12.1 General D.2.12.2 Intention: Societal destabilisation D.2.12.3 Intention: Movement tracking D.2.12.4 Intention: Extortion
104	D.2.12.5 Intention: International prestige D.3 Asset based threat analysis D.3.1 General D.3.2 Threatened Assets
106	D.3.3 Compliance matrix
108	D.3.4 Presentation of threats
109	D.3.5 Generic threats D.3.5.1 Information assets
110	D.3.5.2 Infrastructure assets
111	D.3.6 Asset: Billing details
112	D.3.7 Asset: OBE Charge Report
113	D.3.8 Asset: Customisation information D.3.9 Asset: User contract information
114	D.3.10 Asset: Exception List D.3.11 Asset: “Help, info, complain”
115	D.3.12 Asset: OBE
117	D.3.13 Asset: User privacy D.3.14 Asset: RSE
118	D.3.15 Asset: EFC stakeholders image and reputation
119	D.3.16 Asset: TC and TSP central system D.3.17 Asset: Transit information
120	D.3.18 Asset: Trust object
122	D.3.19 Asset: User identification D.3.20 Asset: Context Data
123	D.3.21 Asset: Payment means
124	D.3.22 Asset: Limited autonomy D.3.23 Asset: EFC Schema
125	D.3.24 Asset: Contractual conditions
126	D.3.25 Asset: Operational rules
127	D.3.26 Asset: Complaint
129	D.3.27 Asset: Certification
130	D.3.28 Asset: Operational report
131	Annex E (informative) Security Policies E.1 Introduction E.1.1 Scope of the annex E.1.2 Motivation for the need of security policies E.2 Example EFC scheme security policy E.2.1 Motivation for information security
132	E.2.2 Purpose of the security policy E.2.3 Scope
134	E.2.4 Policy statements E.2.4.1 General E.2.4.2 General policy statements
135	E.2.4.3 Organisation of information security E.2.4.4 Asset management
136	E.2.4.5 Violations and sanctions E.2.4.6 Review and evaluation E.2.4.7 Audits E.3 Development of operators security policies E.3.1 General
137	E.3.2 Interface requirements E.3.3 Data storage requirements
138	Annex F (informative) Example for an EETS Security Policy F.1 Introduction F.2 Basic laws and regulations F.3 Organisation of EETS Information Security F.3.1 General F.3.2 Steering Committee F.3.3 Trust Model
140	Annex G (informative) Requirements on privacy-focused implementation G.1 Introduction G.2 Legal basis G.2.1 EU Directive 95/46/EC G.2.2 European data protection supervisor (EDPS)
141	G.3 Users’ requirements
142	Bibliography

Status	Withdrawn
Title	Electronic fee collection. Security framework
Publisher	BSI
Committee	EPL/278
Pages	146
Publication Date	2013-02-28
Withdrawn Date	2015-10-31
Replaced By	PD CEN ISO/TS 19299:2015
ISBN	978 0 580 78694 5
Standard Number	PD CEN/TS 16439:2013
Identical National Standard Of	CEN/TS 16439:2013
Descriptors	Electronic equipment and components, Information exchange, Application layer (OSI), Interfaces (data processing), Toll systems, Traffic, Syntax, Data transmission, Data processing, Data handling, Addresses (data processing), Traffic control, Character strings, Road transport, Messages, Computer applications, Transportation, Data transmission methods
ICS Codes	35.240.60 - IT applications in transport