0360 PDF

TECHNIC AL ISO/TS
SPECIFIC ATION 19299
First edition
2 01 5-1 0-01
Electronic fee collection — Security

framework
Perception de télépéage — Cadre de sécurité
Reference number
ISO/TS 1 92 99: 2 01 5 (E)
I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n

© ISO 2 01 5
ISO/TS 192 99: 2 015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2015, Published in Switzerland

All rights reserved. Unless otherwise speci fied, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii
© ISO 2015 – All rights reserved
ISO/TS 192 99:2 015(E)
Contents Page
Foreword .................................................. ...................................................................................................... ................................................... ............................... v
Introduction .................................................. ................................................... ................................................... ................................................... ..................... vi
1 Scope .................................................. ................................................... ................................................... ......................................................................... 1
2 Normative references .................................................. ................................................... ................................................... .............................. 2
3 Terms and de initions f .................................................. ................................................... ................................................... ............................. 4
4 Symbols and abbreviated terms .................................................. ................................................... ................................................... ... 9
5 Trust model .................................................. ................................................... ................................................... ................................................... .. 10

5 .1 O verview .................................................. ...................................................................................................... ........................................... 1 0
5 .2 Stakeholders trust relations .................................................. ................................................... ................................................ 1 0
5 .3 Technical trust model .................................................. ................................................... ................................................... ............. 1 1
5.3 .1 General .................. ................................. ................... ................................ ................................................... .......................... 1 1
5.3 .2 Trust model for TC and TSP relations .................................................. ................................................... .... 1 1
5.3 .3 Trust model for TSP and service user relations .................................................. ............................... 1 3
5.3.4 Trust model for Interoperability Management relations .................................................. ......... 13
5 .4 I mplementation .................................................. ................................................... ................................................... ........................... 1 3
5 . 4. 1 Setup of trust relations .................................................. ................................................... ...................................... . 1 3
5 . 4. 2 Trust relation renewal and revocation .................................................. ................................................... . 1 4
5.4.3 Issuing and revocation of sub CA and end-entity certi ficates ................................................ 14
5.4.4 Certi ficate and certi ficate revocation list pro file and format ................. ................................ 15
5.4.5 Certi ficate extensions ................. .................................. ................................................... .................................... ..... 15
6 Security requirements .................................................. ................................................... ................................................... ......................... 17

6.1 General .................................................. ................................................... ................................................... ................................................ 1 7
6.2 Information security management system .................................................. ................................................... ............. 18
6.3 Communication interfaces .................................................. ................................................... ................................................... . 1 8
6.4 D ata storage .................................................. ................................................... ................................................... .................................... 1 9
6.5 Toll charger ................................................... ................................................... ................................................... .................................... 1 9
6.6 Toll service provider ................................................... ................................................... ................................................... .............. 2 1
6.7 Interoperability Management .................................................. ................................................... ............................................ 23
6.8 Limitation of requirements .................................................. ................................................... .................................................. 2 3
7 Security measures — countermeasures .................................................. ................................................... .............................. 2 4

7.1 O verview .................................................. ...................................................................................................... ........................................... 2 4
7.2 General security measures ................................................... ................................................... .................................................. 24
7.3 Communication interfaces security measures .................................................. ................................................... .... 25
7. 3 . 1 General .................. ................................. ................... ................................ ................................................... .......................... 2 5
7. 3 . 2 D SRC-E FC interface .................................................. ................................................... ...................................... .......... 2 6
7. 3 . 3 CCC interface ................................................... .................. ................................. ................................................... ........... 2 7
7. 3 . 4 LAC interface .................................................. ................... ................................ ................................................... ............ 2 8
7. 3 . 5 Front E nd to TSP back end interface .................................................. ................................................... ...... 2 8
7. 3 . 6 TC to TSP interface .................................................. ................................................... ...................................... ........... 2 9
7. 3 . 7 I CC interface .................. ................................ .................... ............................... ................................................... .............. 3 0
7.4 End-to-end security measures ................................................... ................................................... ......................................... 30
7.5 Toll service provider security measures .................................................. ................................................... ................... 32
7.5.1 Front end security measures .................................................. ................................................... ......................... 32
7.5.2 Back end security measures ................................................... ................................................... ......................... 33
7.6 Toll charger security measures .................................................. ................................................... ......................................... 34
7.6.1 RSE security measures .................................................. ................................................... ...................................... .. 34
7.6.2 Back end security measures ................................................... ................................................... ......................... 34
7.6.3 Other TC security measures .................................................. ................................................... ........................... 35
8 Security speci ications for interoperable interface implementation

f .................................................. ....... 35
8.1 General .................................................. ................................................... ................................................... ................................................ 3 5
8. 1 . 1 Subj ect................................................... ................................................... ................................................... ........................... 3 5
© I SO 2 0 1 5 – All rights reserved

iii
ISO/TS 192 99: 2 015(E)
8.1 .2 Signature and hash algorithms ......................................................................................................................... 3 5

8.2 Security speci fications for DSRC-EFC ............................................................................................................................... 3 6
8.2 .1 Subj ect.................................................................................................................................................................................... 3 6
8.2 .2 OBE ........................................................................................................................................................................................... 3 6
8.2 .3 RSE ............................................................................................................................................................................................ 3 6
9 Key management ............................................................................................................................................................................................... 3 6

9.1 Overview ................................................................................................................................................................................................... 3 6
9.2 Asymmetric keys ................................................................................................................................................................................ 3 6
9.2.1 Key exchange between stakeholders ........................................................................................................... 3 6
9.2.2 Key generation and certi fication ..................................................................................................................... 3 7
9.2.3 Protection of keys ......................................................................................................................................................... 3 7
9.2 .4 Application ......................................................................................................................................................................... 3 7
9.3 Symmetric keys .................................................................................................................................................................................... 3 8
9.3 .1 General ................................................................................................................................................................................... 3 8
9.3.2 Key exchange between stakeholders ........................................................................................................... 3 8
9.3.3 Key lifecycle ....................................................................................................................................................................... 3 9
9.3.4 Key storage and protection .................................................................................................................................. 40
9.3.5 Session keys ...................................................................................................................................................................... 41
Annex A (normative) Security pro iles f ............................................................................................................................................................ 42
Annex B (normative) Implementation conformance statement (ICS) proforma ................................................ 46
Annex C (informative) Stakeholder objectives and generic requirements ............................................................... 64
Annex D (informative) Threat analysis ........................................................................................................................................................... 68
Annex E (informative) Security policies ..................................................................................................................................................... 12 4
Annex F (informative) Example for an EETS security policy ................................................................................................ 13 1
Annex G (informative) Recommendations for privacy-focused implementation ........................................... 13 3
Annex H (informative) Proposal for end-entity certi icates f .................................................................................................. 13 5
Bibliography ......................................................................................................................................................................................................................... 13 6
iv
© ISO 2 01 5 – All rights reserved
ISO/TS 192 99:2 015(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC , also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1 .
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1 . In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives) .
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identi fied during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) .
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO speci fic terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
ISO/TS 19299 was prepared by European Committee for Standardization (CEN) in collaboration with
ISO/TC 20 4, Intelligent tran sport system s, in accordance with the agreement on technical cooperation
between ISO and CEN (Vienna Agreement) .
This first edition of ISO/TS 19299 cancels and replaces CEN/TS 16439:2013.

v
ISO/TS 192 99: 2 015(E)
Introduction
Reader’s guide
The development process for a security concept and implementation to protect any existing electronic
fee collection (EFC) system normally includes several steps as follows:
— de finition of the security objectives and policy statements in a security policy;
— threat analysis with risk assessment to de fine the security requirements;
— development of the security measures followed by the development of security test speci fications.
Figure 1 — Development path for the security documents
In the second step, each actor in an existing EFC system has to implement the de fined security measures
and supervise the effectiveness. Security measures which do not work or work incorrectly need to be
improved. The development of the EFC security framework follows this approach as closely as possible.
The used methodology needs to consider following limitations:
— No security policy exists: The security policy can only be de fined by the responsible stakeholders
and its freedom is only limited by laws and regulations. Nonetheless, this Technical Speci fication
provides basic examples of possible security policies (in Annex E to Annex F) .
— 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 bene fit of each countermeasure which is only possible for an
implemented system.
— No speci fic system design or con figuration during the development of this Technical Speci fication
was considered to keep it universally applicable. Only the available EFC base standards and the
comments received by the CEN/TS 16439:2013 (i.e. the previous edition of the EFC security
framework) were taken as references. Speci fic technical details of a particular system (e.g.
servers, computer centres, and de-central elements like road side equipment) need to be taken into
consideration during the implementation in addition to the present EFC security framework.
vi
ISO/TS 192 99:2 015(E)
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 several stakeholders systems. Due to the fact that
there is neither an overall valid security policy, nor the possibility to provide a useful risk assessment,
the EFC security framework provides a toolbox of requirements and security measures covering as
many threats as possible without claiming to provide an exhaustive list.
There is one limitation though to be compliant to this Technical Speci fication that is, if a requirement is
selected, the associated security measure(s) have to be implemented.
To understand the content of this Technical Speci fication, 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 speci fic like back office connections. 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 Speci fication is described brie fly in the steps below:
a) De finition of the stakeholder objectives and generic requirements as the basic motivation for the
security requirements (Annex C ). A possible security policy with a set of policy statements is
provided in Annex E , and an example of an European electronic toll service (EETS) security policy
is given in Annex F.
b) Based on the EFC role model and further de finitions from the EFC architecture standard
(ISO 17573), the speci fication de fines an abstract EFC system model as the basis for a threat
analysis, de finition of requirements, and security measures.
c) The threats on the EFC system model and its assets are analysed by two different methods: an attack-
based analysis and an asset-based analysis. 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 identi fied assets (tangible and intangible entities). This approach, although producing some
redundancy, ensures completeness and coverage of a broader range of risks (see Annex D) .
d) The requirements speci fication (see C lause 6 ) is based on the threats identi fied in Annex D. Each
requirement is at least motivated by one threat and at least one requirement covers each threat.
e) The de finition of security measures (see C lause 7 ) provides a high-level description of recommended
possible methods to cover the developed requirements.
f) The security speci fications for interoperable interface implementation (C lause 8) provide detailed
de finitions, e.g. for message authenticators. These speci fications represent an add-on for security
to the corresponding relevant interface standards.
g) Basic key management requirements that support the implementation of the interoperable
interfaces are described in Clause 9 . The toll charging environment uses cryptographic elements
(keys, certi ficates, certi ficate revocation lists, etc.) to support security services like con fidentiality,
integrity, authenticity, and non-repudiation. This section of the speci fication covers the (initial)
setup of key exchange between stakeholders and several operational procedures like key renewal,
certi ficate revocation, etc.
h) A general trust model (see Clause 5 ) is de fined to form the basis for the implementation of
cryptographic procedures to ensure con fidentiality, 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 speci fic details where needed.
A stakeholder of an EFC scheme who wants to use this security framework needs to do the following:
— de fine a security policy for the EFC scheme (may involve more than one stakeholder in an
interoperable EFC scheme). Some examples for a security policy and its elements are provided (in

vii
ISO/TS 192 99: 2 015(E)
Annex E and Annex F ) as an aid for using this Technical Speci fication to build up a secure system for
a concrete interoperability framework (including the European electronic toll service).
— identify the relevant processes, systems and interfaces, and match them to the EFC security framework;
— select the corresponding security requirements according to the security policy;
— implement the security measures associated to the selected requirements;
— provide evidence of compliance of its systems, processes, and interfaces with the requirements set
forth in this Technical Speci fication. Evidence can be provided by a self-declaration, an internal or
external audit, or other certi fications.
EFC role model
This Technical Speci fication complies with the role model de fined in ISO 17573 . 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 fees. The TC is the actor associated with the toll charging role (see Figure 2) .
Figure 2 — The role model underlying this Technical Speci ication

f
Toll service providers (TSP) issue on-board equipment (OBE ) to the users of the tolled infrastructure
or transport service. TSPs are responsible for providing the OBE that will be used for collecting data,
enabling the TC to send a claim to the TSP for the use of the infrastructure or transport service by their
service users (SU). In autonomous systems, each TSP delivers toll declarations to the TC who operates the
autonomous system. Such a TC possibly receives toll declarations from more than one TSP. In dedicated
short-range communication (DSRC)-based systems, the TC receives the main toll declarations from its
own RSE which communicates with the TSP’s OBE and only supplementary charging data, if required,
from the TSP. Interoperability management (IM) in Figure 2 comprises all speci fications and activities
that in common, de fine and maintain a set of rules that govern the overall toll charging environment.
The trust model de fined in this Technical Speci fication 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 toll service provider
compliant to this Technical Speci fication needs to be able to give evidence of security management as
required. Such evidence is the basis of trust relations between the involved entities.
Figure 3 below illustrates the abstract EFC system model used to analyse the threats, de fine the
security requirements and associated security measures for this Technical Speci fication. This Technical
Speci fication 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 (also called in-
vehicle ITS Stations) used to host the EFC application. The OBE may either be connected to a central
viii
ISO/TS 192 99:2 015(E)
account or use a payment medium such as ICC or mobile payment for on-board-account EFC system.
Any financial transactions to the payment medium are out of scope of this Technical Speci fication.
GNSS
Position &
Time
U ser Tol l Servi ce Provi d er
Con tract
I CC con tact(l ess) Service Point

D ri ve r Personnel
Customization,
Eq u i pm en t su ppl i er, servi ce provi d er, etc.

Maintenance
con tact(l ess)
HMI
o pti o n al
Value added
S e rvi ce P ro vi d e r
OB E CN OBE
services
B ack E n d
P ro xy
P o we r,
Tach o ,
DSRC
C AN ,
e tc.
Tol l Ch arg er
To l l C h arg e r
ANPR B ack E n d
Ve h i cl e RSE ,
E n forcem en t
Personnel
Figure 3 — EFC system model of the EFC Security framework
Relation to other security standards
Several generic and speci fic standards and Technical Reports concerning security issues for information
technology already exist. This Technical Speci fication uses these existing standards and expands their
usability for EFC applications. The framework references and tailors the security techniques and
me tho do l o g i e s fro m the s e s ta nd a rd s .
illustrates the context of the EFC security framework to other security standards. It is not an
F i g u re 4
exhaustive description as only the most relevant standards are shown, i.e. the standards that gave most
input to this Technical Speci fication. 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.
© I S O 2 0 1 5 – Al l ri gh ts re s e rve d ix
ISO/TS 192 99: 2 015(E)
ETSI TR 1 02 731
(Essen ti al Cou n ter-
m easu res for Co-operati ve
I TS)
Di g i tal si g n atu res
Eq u i pm en t m an ag em en t
Figure 4 — Relevant security standards in the context of the EFC — Security framework
E ach group of s tandards in Figure 4 provides the fol lowing features:
— Security techniques — Security measures and algorithms : T he group is a collec tion of es sential
security measures and recommended cryptographic algorithms including the guidelines for
accurate use.
— IT — Open system interconnection : T his group of s tandards provides mechanis ms 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 de fines methodologies
and processes for the security evaluation and certi fication for most categories of products used in
the E FC environment. T he arrows ins ide the group indicate the relation between the s tandards in a
bottom-up direc tion.
— IT — Security techniques — Information security management system : This standard family

de fines requirements and guidelines for the implementation of security management systems for
all types of organizations. The standards are well suited for the security solutions of the back end
and other fixed or installed equipment including software of EFC systems.
A corresponding ISO/IEC 27001 certi fication of a toll charger (TC) or toll service provider (TSP)
organization may be used to demonstrate ful filment of this Technical Speci fication provided that
the scope and the Statements of Applicability (SoA) include the EFC business processes speci fied in
ISO 17573 and the selected security requirements and their associated security measures provided by
this Technical Speci fication are applied, e.g. by using them as part of the so-called catalogues containing
the security measures and control objectives. Figure 5 below i llus trates how this appro ach works in
parallel. The first step of both paths is analysing the business processes followed by a threat analysis.
x
ISO/TS 192 99:2 015(E)
A common risk analysis combines the generic and the EFC related analysis and results in the respective
security measures and controls.
I n form ati on Secu ri ty M an ag em en t System s - I SO 27001
Figure 5 — Scope in relation to the Information Security Management System
In addition, the EFC security framework makes use of existing threat analysis methods and also uses
existing threat analysis with relation to EFC or ITS [e.g. ETSI/TR 102 893 (intelligent transport systems;
security; threat, vulnerability and risk analysis)].

xi
TECHNICAL SPECIFICATION ISO/TS 192 99:2 015(E)
Electronic fee collection — Security framework
1 Scope
The overall scope of this Technical Speci fication is an information security framework for all
organizational and technical entities of an EFC scheme and in detail for the interfaces between them,
based on the system architecture de fined in ISO 17573. The security framework describes a set of
requirements and associated security measures for stakeholders to implement and thus ensure a
secure operation of their part of an EFC system as required for a trustworthy environment according to
its security policy.
The scope of this Technical Speci fication comprises the following:
— de finition of a trust model (C lause 5 );
Basic assumptions and principles for establishing trust between the stakeholders.
— security requirements (Clause 6 );

— security measures — countermeasures (Clause 7 );
Security requirements to support actual EFC system implementations.
— security speci fications for interface implementation (Clause 8 );
These speci fications represent an add-on for security to the corresponding standards. Figure 5
above shows the relevant interfaces and the corresponding relevant interface standards, as
illustrated in Figure 6.
— key management (C lause 9 );

Covering the (initial) setup of key exchange between stakeholders and several operational
procedures like key renewal, certi ficate revocation, etc.
— security pro files (Annex A);
— implementation conformance statement (Annex B ) provides a checklist to be used by an equipment
supplier, a system implementation, or an actor of a role declaring his conformity to this Technical
Speci fication;
— general information security objectives of the stakeholders (Annex C ) which provide a basic
motivation for the security requirements;
— threat analysis (Annex D) on the EFC system model and its assets using two different complementary
methods, an attack-based analysis, and an asset-based analysis;
— security policy examples (Annex E and Annex F );
— recommendations for privacy-focused implementation (Annex G );
— proposal for end-entity certi ficates (Annex H ) .

1
ISO/TS 192 99: 2 015(E)
Figure 6 — Scope of EFC security framework for secure communication
The following are outside the scope of this Technical Speci fication:
— 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 are covered in
C E N/ T R 1 6 6 9 0 .
— entities and interfaces of the interoperability management role;

— the technical trust relation between TSP and service user;
— concrete implementation speci fications for implementation of security for EFC system [e.g. European
electronic toll service (EETS)] ;
— detailed speci fications required for privacy-friendly EFC implementations;
— any financial transactions between the payment service provider and the payment medium issued
by the latter (e.g. ICC).
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
I SO 1 2 81 3 : 2 01 5 , Electronic fee collection — Compliance check communication for autonomous systems
ISO 1 2 8 5 5 : 2 01 5 , Electronic fee collection — Information exchange between service provision and toll
charging
2
© I S O 2 0 1 5 – Al l ri gh ts re s e rve d
ISO/TS 192 99:2 015(E)
ISO 13141:2015 , Electronic fee collection — Localization augmentation communication for autonomous
systems
ISO 14906: 2011, Electronic fee collection — Application interface definition for dedicated short-range
communication
EN 15509: 2014, Electronic fee collection — Interoperability application pro file for DSRC
CEN/TS 16702-1: 2014, Electronic fee collection — Secure monitoring for autonomous toll systems — Part
1: Compliance checking
ISO 17575 -1: 2015, Electronic fee collection — Application interface definition for autonomous systems —
Part 1: Charging
ISO/IEC 7816 -3 ,Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical
interface and transmission protocols
ISO/IEC 8825 -1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) — Part 1
ISO/IEC 9594-8: 2014, Information technology — Open Systems Interconnection — The Directory: Public-
key and attribute certificate frameworks — Part 8
ISO/IEC 9797-1: 2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO/IEC 11770 -1: 2010, Information technology — Security techniques — Key management — Part 1:
Framework
ISO/IEC 11770 -3: 2015, Information technology — Security techniques — Key management — Part 3:
Mechanisms using asymmetric techniques
ISO/IEC 18031, Information technology — Security techniques — Random bit generation
ISO/IEC 18033 -2 , Information technology — Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers
ISO/IEC 19790, Information technology — Security techniques — Security requirements for

cryptographic modules
ISO/IEC 27001, Information technology — Security techniques — Information security management

systems — Requirements
ISO/IEC 27002: 2013 , Information technology — Security techniques — Code of practice for information
security controls
ISO/IEC 27005 , Information technology — Security techniques — Information security risk management
IETF Request for Comments (RFC ) 4301: 2005 -12 , Security Architecture for the Internet Protocol
IETF Request for Comments (RFC ) 43 47: 2006-0 4, Datagram Transport Layer Security
IETF Request for Comments (RFC ) 4648: 2006 -10, The Base16, Base32, and Base64 Data Encodings
IETF Request for Comments (RFC ) 5035: 2007-08, Enhanced Security Services (ESS) Update: Adding
CertID Algorithm Agility
IETF Request for Comments (RFC) 5246:2008-08, The Transport Layer Security (TLS) Protocol, Version 1.2
IETF Request for Comments (RFC ) 52 80: 2008-05 , Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Pro file

3
ISO/TS 192 99: 2 015(E)
IETF Request for Comments (RFC ) 5746: 2010 -02 , Transport Layer Security (TLS) Renegotiation
Indication Extension
Federal Information Processing Standards (FIPS) PUB 140 -2 , December 2002 , Security requirements for
cryptographic modules
3 Terms and de initions f
For the purposes of this document, the following terms and de finitions apply.
3 .1
accountability
property that ensures that the actions of an entity may be traced uniquely to the entity
[SOURCE: ISO 7498-2:1989, 3.3.3]
3 .2
activist
especially active, vigorous advocate of a cause, especially a political cause
3.3
asset
anything that has value to a stakeholder
Note 1 to entry: An asset may be tangible or intangible.
3 .4
attack
attempt to destroy, expose, alter, disable, steal, or gain unauthorized access to or make unauthorized
use of an asset (3 . 3)
[SOURCE: ISO/IEC 27000:2014, 2.3]

3 .5
authenticity
property that an entity is what it claims to be
[SOURCE: ISO/IEC 27000:2014, 2.8]
3 .6
availability
property of being accessible and usable upon demand by an authorized entity
[SOURCE: ISO 7498-2:1989, 3.3.11]
3 .7
back end
part of the back office system interfacing to one or more front ends (3 .17 )
3 .8
certi icate revocation list
f
signed list indicating a set of certi ficates that are no longer considered valid by the certi ficate issuer
[SOURCE: ISO/IEC 9594-8:2014, 3.5.12]
3 .9
key certi ication authority f
CA
authority trusted by one or more users to create and assign public-key certi ficates
[SOURCE: ISO 15782-1:2009, 3.15]
4
ISO/TS 192 99:2 015(E)
3 .10
communication provider
provider of communication services used for the transmission of information
3 .11
con fidentiality
prevention of information leakage to non-authenticated individuals, parties, and/or processes
[SOURCE: ISO/TS 17574:2009, 3.7]

3 .12
data protection commissioner
data privacy commissioner
person responsible for the enforcement and monitoring of compliance with the applicable data
protection legislation
3 .13
data subject’s consent
any freely given speci fic and informed written indication of his wishes by which the data subject
signi fies his agreement to personal data (3 . 30) relating to him being processed
3 .14
electronic money
value having its equivalence in real money, electronically stored e.g. on a bank account or an IC-card,
which thus can be used by the user for payments
[SOURCE: ISO/TR 19639:—, 3.5]
3 .15
enforcement
measures or actions performed to achieve compliance with laws, regulations, or rules
Note 1 to entry: In this context, the process of compelling observance of a toll regime (3 .46) .
3 .16
foreign state agency
any agency of any state except the state under whose jurisdiction a particular toll scheme (3 .47) is operated
3 .17
front end
part of a tolling system consisting of OBE and possibly, a proxy where tolling information and usage
data are collected and processed for delivery to the back end (3 .7 )
3 .18
domestic state agency
government or any agency of the state or nation under whose jurisdiction a particular toll schema is
being operated
3 .19
hacker
person who attempts or succeeds to gain unauthorized access to protected resources
3 .20
information asset
knowledge or data that has value to the stakeholder
[SOURCE: ISO/IEC 27032:2012, 4.27, modi fied]

5
ISO/TS 192 99: 2 015(E)
3 .21
information security
preservation of con fidentiality (3 .11) , integrity (3 . 24) , availability (3 .6) , authenticity (3 . 5 ) , accountability
(3 .1) , non-repudiation (3 . 27 ), and reliability of information

3 .22
information security event
identi fied occurrence of a system, service or network state indicating a possible breach of information
security policy or failure of controls, or a previously unknown situation that may be security relevant
[SOURCE: ISO/IEC 27000:2014, 2.35]
3 .23
information security incident
unwanted information security (3 . 21) events that have a signi ficant probability of compromising
business operations and threatening information security
3 .2 4
integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/TS 17574:2009, 3.11, modi fied]
3 .25
interoperability
ability of systems to exchange information and to make mutual use of the information that has
been exchanged
[SOURCE: ISO/IEC/TR 10000-1:1998, 3.2.1, modi fied]

3 .26
message authentication code
MAC
string of bits which is the output of a MAC algorithm
Note 1 to entry: A MAC is sometimes called a cryptographic check value (see, for example, ISO 7498-2).
[SOURCE: ISO/IEC 9797-1:2011, 3.9]
3 .27
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
[SOURCE: ISO/IEC 27000:2014, 2.55]
3 .28
on-board equipment
OBE
equipment located on-board a vehicle including nomadic devices with the function of exchanging
information with external systems
3 .29
payment medium
carrier of payment means, such as paper ticket, IC-card, smart phone or on-board unit (OBU)
6
ISO/TS 192 99:2 015(E)
3 . 30
personal data
information relating to an identi fied or identi fiable natural person
Note 1 to entry: In relation to EFC, an identi fied or identi fiable natural person is equivalent to the role service
user (ISO 17573: 2010) .
3 . 31
policy
overall intention and direction as formally expressed by management
3 . 32
data privacy
rights and obligations of individuals and organizations with respect to the collection, use, retention,
disclosure and disposal of personal information
[SOURCE: ISO/TS 14441:2013, 3.26]

3 . 33
processing of personal data
operation or set of operations which is performed upon personal data (3 . 30 ), whether or not by
automatic means, such as collection, recording, organization, storage, adaptation or alteration,
retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available,
alignment or combination, blocking, erasure, or destruction
3 .3 4
roadside equipment
RSE
equipment located along the road ether fixed or mobile
3 .35
secure application module
SAM
physical module that securely executes cryptographic functions and stores keys
3 .36
security policy
set of rules that regulate how to handle security threats or de fine the appropriate security level
[SOURCE: ISO/TS 17574:2009, 3.23]
3 .37
security service
service provided by communicating systems which ensures adequate security of the systems or of
data transfers
[SOURCE: ISO 7498-2:1989, 3.3.51, modi fied]

3 .38
digital signature
one or more data elements resulting from the digital signature process
3 .39
threat
potential cause of an unwanted information security incident, which may result in harm

7
ISO/TS 192 99: 2 015(E)
3 .40
threat agent
entity that has the intention to act adversely on an asset (3 . 3)
3 .41
threat analysis
systematic detection, identi fication, and evaluation of threats (3 . 39)
3 .42
toll
any charge, tax, or duty levied in relation with using a vehicle in a toll domain (3 .45 )
[SOURCE: CEN/TR 16092:2011, 3.6, modi fied]
3 .43
toll charger
TC
entity which levies toll (3 .42) for the use of vehicles in a toll domain (3 .45 )
[SOURCE: ISO 17573:2010, 3.16, modi fied]

3 .44
toll declaration
statement to declare the usage of a given toll service to a toll charger (3 .43)

3 .45
toll domain
area or a part of a road network where a certain toll regime (3 .46) is applied

3 .46
toll regime
set of rules, including enforcement rules, governing the collection of toll (3 .42) in a toll domain (3 .45 )
[SOURCE: ISO 17573:2010, 3.20]

3 .47
toll scheme
organizational view of a toll regime (3 .46) including the actors and their relationships
[SOURCE: ISO/TS 17575-3:2011, 3.35, modi fied]

3 .48
toll service provider
TSP
entity providing toll services in one or more toll domains (3 .45 )
3 .49
trusted third party
TTP
security authority or its agent trusted by other entities with respect to security-related activities
[SOURCE: ISO/IEC 10181-1:1996, 3.3.30 modi fied]
8
ISO/TS 192 99:2 015(E)
3 .50
service user
SU
generic term used for the customer of a toll service provider (3 .48) , one liable for toll (3 .42) , the owner of
the vehicle, a fleet operator, a driver, etc. depending on the context
3 .51
vulnerability
weakness of an asset (3 . 3 ) or control that can be exploited by an attacker
4 Symbols and abbreviated terms
AC _CR Access Credentials (EN 15509: 2014)
ADU Application Data Unit
CA Certi fication Authority (ISO 15782-1:2009)

CCC Compliance Check Communication (ISO 12 813: 2015 )
CN Cellular Network
CRL Certi ficate Revocation List

DES Data Encryption Standard
DSRC Dedicated Short-Range Communication (ISO 14906:2011)
EETS European Electronic Toll Service
EFC Electronic Fee Collection (ISO 17573: 2010)
GNSS Global Navigation and Satellite System (ISO 17573:2010)

H TTP HyperText Transfer Protocol
H TTPS HTTP over Secure socket layer
ICC Integrated Chip Card (IC card)
ICS Implementation Conformance Statement (ISO/TS 14907-2:2011)
IETF Internet Engineering Task Force
IM Interoperability Management
IPsec Internet Protocol Security
ISMS Information Security management system (ISO/IEC 27000:2014)
LAC Localization Augmentation Communication (ISO 13141: 2015 )
MAC Message Authentication Code

MAC_TC DSRC Message Authentication Code for toll charger
MAC_TSP DSRC Message Authentication Code for toll service provider

9
ISO/TS 192 99: 2 015(E)
OBE On-Board Equipment (ISO 14906: 2011)
OID Object Identi fier

PAN Personal Account Number
PER Packed Encoding Rules (ISO/IEC 8825 -2)
PKI Public Key Infrastructure

RQ Requirement
RSA Rivest, Shamir and Adleman
NOTE RSA is an algorithm for public-key cryptography also referred to as asymmetrical cryptographic
technique.
RSE Roadside Equipment (ISO 14906:2011)
SAM Secure application module
SH A-1 Secure hash algorithm (ISO/IEC 10118-3)
SM Security Measure (countermeasure)

SU Service User
TC Toll Charger (ISO 17573: 2010)
TLS Transport Layer Security

TSP Toll Service Provider
TTP Trusted Third Party

VPN Virtual Private Network
XER XML Encoding Rules (ISO/IEC 8825-4)
5 Trust model
5.1 Overview
The trust model provides the basic trust and functionality for the implementation of authenticated and
secured communication channels between TSP and TC .
The trust model has two different levels, the contractual framework between the stakeholders (TC ,
TSP, and SU ) and the technical trust model between the I T infrastructure of the TC and TSP.
The trust model is based on the assumption that no initial technical trust relation between any of the
stakeholders exists or will be generated by a prede fined third party.
5.2 Stakeholders trust relations
Three kinds of bidirectional contract-based peer-to-peer trust relations are present in the underlying
EFC role model. The following are the peer-to-peer trust relations:
— between toll charger and toll service provider;

— between toll service provider and service user;
10
ISO/TS 192 99:2 015(E)
— between toll charger or toll service provider and interoperability management.

T he re is no d i re c t tr u s t re l ati o n b e t we e n to l l ch a r ge r a n d s e r v ic e u s e r, as i l lu s tr ate d in F i g u re 7. T he
obligation of the service user is to pay for the transport service (e.g. road use) according to laws and
regulations of the respective toll domain by using the OBE issued by the TSP.
Figure 7 — Stakeholder trust relations
The interoperability management can be a single organization or a construct of several entities

performing different tasks. Issuing rules, regulations, and general user information by the
interoperability management (IM) is done using a trust relation outside of the scope of this Technical
Speci fication (dotted arrows in ). Trust relations between IM and TC or TSP inside the scope
F i g u re 7
are among others used for certi fication of organization or equipment and TTP functions in case this is
performed by the IM.
One supported model is an agreement between TC and TSP to use a Trusted Third Party (TTP) (e.g. for
issuing public-key root certi ficates). Such a hierarchical trust relation supported by a TTP can include
the IM relations to TC and TSP. The TTP could either be performed as a part of the IM or external TTP(s)
could be used to issue the root certi ficates. This Technical Speci fication does not require a mandatory
T T P i n a h ie ra rch ic a l tr u s t mo de l , b u t s up p o r ts the u s e o f i t.
Another supported model is an agreement between TC and TSP to directly trust them by exchanging
self-signed root certi ficates. Such a peer-to-peer trust relation can also include the IM relations to
TC and TSP. This Technical Speci fication does not require a mandatory peer-to-peer trust model, but
s up p o r ts the u s e o f i t.
The technical trust relation of any chosen trust model between TSP and service user (SU) as well as the
indirect trust relation between TC and SU are outside the scope of this Technical Speci fication.
5.3 Technical trust model
5.3 .1 General
The technical trust model de fines a solution for the trust relations between the different stakeholders.
T he te c h n ic a l tr u s t mo de l i s de p e nde nt o n the re qu i re me nt s o f the co nc e r ne d s ta ke ho lde r s w i th re s p e c t
to support an interoperable EFC system.

5.3 .2 Trust model for TC and TSP relations
The technical trust model uses the ISO/IEC 9594-8, (X.509) version 3 public-key and attribute certi ficate
fra me wo rks fo r e s tab l i s h i n g s e c u re co m mu n i c ati o n ch a n ne l s . T he s e s e c u re c o m mu n ic ati o n c h a n ne l s
11
ISO/TS 192 99: 2 015(E)
ensure con fidentiality, integrity, authenticity, and non-repudiation (only with proof of origin) of the
me s s a ge s e xch a n ge d b e t we e n T C a nd T S P.
The use of ISO/IEC 9594-8, i.e. using the possibility to import and use in parallel different (self-
signed) root certi ficates in the trust model, enables the support of both a peer-to-peer approach and
a hierarchical approach using a trusted third party. In addition, it also allows a mixed approach with
peer-to-peer relations between TC and TSP on one hand and a TTP certi fication authority (CA) approach
o n the o the r h a n d .
EXAMPLE F i g u re 8 illustrates an example of a trust model approach which is supported by this Technical
Speci fication.
Figure 8 — Example of a mixed trust model environment
F i g u re 8 indicates the possibility of the trust model allowing an entity to participate at the same time
in a m i xe d e nv i ro n me nt w i th b o th ap p ro ac he s . T he do t te d b ox m a rke d as “ h i e ra rch ic a l tr u s t” s ho ws
the trusted third parties in their roles as certi fication authorities (CA1 and CA2) issuing certi ficates
for each entity based on its self-signed root certi ficate imported by the entities. It is also possible that
the TTP CAs directly issue certi ficates for the technical entities communicating with each other. In
this case, no root certi ficate would exist and securing all interfaces would be established by bilaterally
accepting self-signed certi ficates.
A trust relation can also be established across different TTP CAs as indicated by the dotted connections
T C 1 tr u s ts T T P C A1 a nd T S P 3 tr u s t s T T P C A 2 . T T P C A1 a l s o tr u s ts T T P C A 2 a n d v ic e ve r s a . T he re re fo re ,
the re i s a l s o a tr u s t re l atio n b e t we e n T C 1 a n d T S P 3 .
The dotted box “peer-to-peer trust” shows entities generating self-signed root certi ficates for exchange
and import of these certi ficates. Entities in the overlapping part of the boxes (i.e. TC1, TSP2, and TSP3)
import both the certi ficates issued by the TTP CAs and the connected peer-to-peer trust partner (i.e.
TC3, TSP1) self-signed root certi ficates.
The use of the ISO/IEC 9594-8 framework and certi ficates also enables hierarchical CA structures with a
root CA and subordinate level CAs. To limit implementation complexity and to support interoperability,
the set of allowed certi fication levels shall be limited as indicated in 5 .4. 3 .
The used type and structure of the model for the trust relation between the involved stakeholders is
a de c i s io n o f the i r c o ntrac tu a l fra me wo rk a nd de p e n d s o n the i r te c h n ic a l re qu i re me n ts as we l l as the
legal framework. The IM in an interoperable EFC system shall develop and maintain a suitable trust
mo de l . A n e x a mp le fo r E E T S c a n b e fo u nd i n A n ne x F.
12
ISO/TS 192 99:2 015(E)
5.3 .3 Trust model for TSP and service user relations
A s tandardized trus t relation mechanism for the trus t between TSP and service user is not required for
interoperability. The solution for a trusted and secured communication between TSP and service user is a
decision taken by the TSP based on the legal requirements for the contract between TSP and service user.
According to ISO 17573, the operation of the OBE and the provision of toll declarations in a secure way
as required for toll charging is part of the toll service provider role. Requirements for achieving end-to -
end security from the OBE to the toll chargers systems is therefore considered to be an internal interface
of the TSP and then between TSP and TC. If security requirements for end-to-end security are imposed
by the security policy, appropriate measures need to be implemented (e.g. usage of CEN/TS 16702-1 or
C EN/TS 16702-2 ) .
5.3 .4 Trust model for Interoperability Management relations
The interoperability management may issue rules, regulations, and standards for the EFC system via
commonly recognized channels. Communication between IM and TC or TSP (e.g. for certi fication of
organizations or equipment) can be done with legacy methods such as physical mail and face to face
meetings . No technical trus t model is required for either of these communications .
For all other cases where electronic data exchange channels are required, the s ame technical trus t
model as de fined in 5 . 3 . 2 shall be used.
5.4 Implementation
5.4.1 Setup of trust relations
After TC and TSP have agreed on the trust relation to be used and have signed a contract, they shall
setup the technical trus t relation.
The initial step for the setup of the trust relation is the import of a root certi ficate. This can be either
the CA root certi ficate of an agreed TTP acting as a root CA or a (self-signed) root certi ficate of the TC or
TSP respectively as already explained in 5 . 3 . 2 .
If using a TTP, the retrieval of the CA root certi ficate shall be done according to mechanism 3 of
ISO/IEC 11770 -3: 2015 , C lause 1 2 or an equivalent. S everal procedures might be used such as the following:
— downloading the certi ficate from a recognized and secure website;

— retrieving it per courier, if supported by the TTP;
— receiving it through signed e-mail, etc.
In the case of a peer-to-peer trust model, the exchange of the CA root certi ficates between TC and TSP
shall be done using a secure communication channel which ensures the authenticity of the issuer and
sender (proof of origin). The exchange of the root certi ficates shall be done with one of the public key
transport mechanisms 1 or 2 as de fined in ISO/IEC 11770-3:2015, Clause 12 (Public key transport).
— Mechanism 1: This mechanism shall ful fil the requirements and implement the measures of
mechanism 1 of ISO/IEC 11770-3:2015, Clause 12, but using a certi ficate instead of a public key. As
an example, it may be implemented by a physical meeting when both stakeholders (representatives
of the TC and TSP, respectively) exchange valid identi fication tokens (e.g. passport) and documents
proving the relationship with their organization.
ISO/IEC 11770-3 public key transport mechanism 1 may be implemented as a part of the contract
signing process to guarantee the certi ficate and public key authenticity.
— Mechanism 2: This mechanism shall ful fil the requirements and implement the measures of
mechanism 2 of ISO/IEC 11770-3:2015, Clause 12, but using a certi ficate instead of a public key. As
an example, it may be implemented by sending the root certi ficate through signed e-mail (using
© ISO 2 0 1 5 – All rights reserved

13
ISO/TS 192 99: 2 015(E)
another certi ficate, e.g. issued by a TTP) and then checking the fingerprint through telephone, or
sending the certi ficate through courier which authenticates the sender.
The key token veri fication shall be done using fingerprint of the root certi ficate based on the
algorithms de fined in ISO 12855:2015 if ISO/IEC 11770-3 public key transport mechanism 2 is used.
5.4.2 Trust relation renewal and revocation
The root certi ficate shall have a validity and key length recommended for the use during the planned
c o n trac t du rati o n b e t we e n T C a n d T S P.
NOTE For recommended key length and validity periods, see, for example, h t tp s : //w w w.
b s i . b u n d . d e / D E / T h e m e n / w e i t e r eT h e m e n / E l e k t r o n i s c h e S i g n a t u r/ Te c h n i s c h e R e a l i s i e r u n g /
Kryptoalgorithmen/kryptoalgorithmen_node . h tm l (German only).

The trust relation shall automatically end when a root certi ficate is not replaced by the date of expiry.
The replacement of a root certi ficate shall be done in the same way as already de fined in 5 . 4 . 1 . A l l i s s ue d
end-entity certi ficates of this root certi ficate shall be renewed according to the process de fined in 5 .4. 3 .
It shall be possible to revoke a root certi ficate by its issuer before the expiry of the validity for any
reason. The revocation of a root certi ficate shall be done by a procedure similar to the early termination
of the contract and results in a termination of the trust relation. The trust relation shall automatically
end when a root certi ficate is revoked.
The information about revocation of a root certi ficate shall be distributed issuing a Certi ficate Revocation
List (CRL) de fined in 9594-8 signed by the private-key of the root certi ficate. The digital
I S O/ I E C
signature of the message shall be veri fied with the public key of the originally imported root certi ficate.
Further activities that are necessary to handle compromised root certi ficates are beyond the scope of
this Technical Speci fication because they usually require certain organizational measures.
5.4.3 Issuing and revocation of sub CA and end-entity certi icates f
The corresponding private-key of the root certi ficate shall only be used for signing end-entity or sub CA
certi ficates. The purpose and usage of the end-entity certi ficate (e.g. TC to TSP communication) shall be
de fined by using the extended key usage extension in the ISO/IEC 9594-8 certi ficate.
The implementation of the certi ficate veri fication process shall support a certi ficate chain starting from
a root certi ficate and contain at least up to four certi ficate levels (i.e. Root > CA1 > CA2 > CA3 > End-
Entity) signed by a sub CA or end-entity private key.
Each entity shall have at least three different end-entity certi ficates to be used for
— s e c u re co m mu n ic atio n c h a n ne l s ,
— me s s a ge s i g n i n g , a nd
— message or key encryption purposes.

It is recommended that these end-entity certi ficates have a validity period of less than two years.
The information about revocation of an end-entity certi ficate shall be distributed issuing a
Certi ficate Revocation List (CRL) de fined in 9594-8 signed by the private-key of the root
I S O/ I E C
certi ficate. The digital signature of the message shall be veri fied with the public key of the originally
imported root certi ficate.
Exchange of certi ficates and CRLs is de fined in C l au s e 9 .
14
ISO/TS 192 99:2 015(E)
5.4.4 Certi icate and certi icate revocation list pro ile and format
f f f
The issued ISO/IEC 9594-8 certi ficates version 3 and CRL version 2 shall be according to the pro file
defined in IETF RFC 5280 with the update speci fied in RFC 6818. A compliant implementation to this
speci fication to import and use the certi ficates and CRLs shall at least support all possible critical
certi ficate and CRL extensions as defined in IETF RFC 5280 pro file with the update speci fied in RFC 6818.
All root, sub CA, and end-entity certi ficates shall be encoded according to the distinguished encoding
rules (DER) as de fined in ISO/IEC 8825-1 and thereafter, be Base64-encoded as de fined in IETF RFC
4648 and enclosed by „––-BEGIN CERTIFICATE––-“ and „––-END CERTIFICATE––-“, i.e. as de fined in the
PEM (privacy enhanced mail) certi ficate format.
All CRL shall be DER encoded as de fined in ISO/IEC 8825-1 and thereafter, be Base64-encoded (as
de fined in IETF RFC 4648) and enclosed by „––-BEGIN X.509 CRL––-“ and „––-END X.509 CRL––-“, i.e. as
de fined in the PEM CRL format.
All certi ficates and CRL shall have a fingerprint in hexadecimal format based on the algorithms de fined
in I SO 1 2 85 5: 2 01 5 .
5.4.5 Certi icate extensions f
Considering IETF RFC 5280:2008, 4.2 and clari fications in ISO/IEC 9594-8:2014, Clause 7, the processing
of critical extensions is delicate and shall be clearly agreed between the stakeholders (TC and TSP)
to avoid implementation problems when the involved PKI platform technologies do not support the
processing of certi ficates with certain extensions marked as critical.
Each extension used in a certi ficate shall be designated as either critical or non-critical. A certi ficate-
using system shall reject the certi ficate if it encounters a critical certi ficate extension it does not
recognize or a critical certi ficate extension that contains information it cannot process. A non-critical
extension may be ignored if it is not recognized, but shall be processed if it is recognized.
NOTE Any extension that is flagged non-critical can cause inconsistent behaviour between certi ficate-using
systems that will process the extension and certi ficate-using systems that do not recognize the extension and
wi ll ignore it.
A root certi ficate shall only use the certi ficate extensions listed below marked as critical:
a) key usage;
b) bas ic cons traints .
An end-entity certi ficate shall use the certi ficate extensions listed below marked as critical:
a) key usage;
T he values in Table 1 shall be used.
b) Extended key usage with object identi fier (OID) for the following:
— TC to TSP interface certi ficate;
— Front end to TSP back end interfaces certi ficate.
The following extensions may be present in root certi ficates as non-critical:
a) CRL distribution points;
b) authority information access.
The following extensions may be present in end-entity certi ficates as non-critical:
a) basic constraints;

15
ISO/TS 192 99: 2 015(E)
b) CRL distribution points;

c) authority information access.
16
ISO/TS 192 99:2 015(E)
Table 1 — Values for key usage
Value Meaning
0 D igital s ignature
1 C ontent commitment
2 Key encipherment
3 D ata encipherment
4 Key agreement
5 Key certi ficate signing
6 C RL s igning
7 Encipher only
8 Decipher only
6 Security requirements
6.1 General
A security requirement is a functional or non-functional requirement that needs to be satis fied in order
to mitigate the threats to an EFC system or reducing its consequences.
Security requirements can be motivated by different sources. The following list presents some of the
most relevant sources for EFC systems:
— generic information technology security requirements can be found in ISO Information Security
Management System family of standards (e.g. in ISO/IEC 27001);
— security requirements for the protection of payment card data can be found in the Payment Card
Industry Data Security Standard (PCI DSS), [ ] if applicable; 12
— system-speci fic security requirements based on a threat analysis of the EFC system as presented in
this Technical Speci fication in Annex D.
Mainly motivated by the threat analysis in Annex D , the following section speci fies a basic set of
information security requirements to protect the threatened assets in an EFC system.
The security policy for an EFC scheme or for an EFC operators system may consider additional security
requirements driven by the mentioned standards or other relevant sources.
NOTE A general and complete IT security guideline for an information security management system is
provided in the ISO 2700x family of standards (see 1.2 and 6 . 2 ) .
In order to be compliant with this Technical Speci fication, an implementation shall ful fil all
requirements selected in accordance with the applicable security policy. Any security measures from
C lause 7 that are associated to the security requirements listed in this Clause shall be implemented
when the relevant requirement is selected to be ful filled.
If a requirement is not selected, it is also not mandatory to implement the associated security measure.
In addition to the security policy, there are also some security pro files de fined in Annex A to ease the
implementation of a common set of security requirements. If an entity states compliance with one or
more of the de fined security pro files, all mentioned requirements are mandatory and the associated
security measures have to be implemented.
Table 2 explains the notation of the requirements de fined in this clause.

17
ISO/TS 192 99: 2 015(E)
Table 2 — Notation of requirements
Table header Meaning
No. Unique number for every requirement to enable a later matching with the security
me a s u re s .
Requirement De finition of the requirement or recommendation.

DSRC Marked with an X if this requirement is relevant for a DSRC system.
GNSS Marked with an X if this requirement is relevant for an autonomous system.
A n ne x D provides a reference to the requirement(s) that is (are) driven by a given threat.
6.2 Information security management system
This Technical Speci fication provides measures to address potential EFC speci fic risks by de fining
requirements and detailed security measures which take into consideration the speci fic nature of EFC
systems including their interoperable interfaces and speci fic assets. Those security measures have
been designed based on an analysis of possible threats speci fically applicable to EFC systems, without
evaluating the real associated risks, which are system speci fic.
TCs and TSPs shall analyse and evaluate the risks associated with those threats and should also identify
and analyse more generic information and communication technology risks applicable to organizations
operating EFC systems, by performing a comprehensive risk analysis according to ISO/IEC 27005.
In order to effectively ensure information security in a holistic approach, TCs and TSPs shall establish,
implement, operate, monitor, review, maintain, and continuously improve an Information Security
Management System (ISMS) according to ISO/IEC 27001. The ISMS shall consider the EFC business
processes speci fied in ISO 17573 within its scope and consider, among others, the risks identi fied in
this Technical Speci fication. The security measures de fined in this Technical Speciation shall be used
while de fining and implementing the controls for minimizing the impact of the identi fied risks.
The ISMS should also consider the generic companies business processes as part of its scope.
Table 3 — ISMS requirements
No. Requirement DSRC GNSS
RQ.ISMS.1 An Information Security Management System (ISMS) according to X X
I S O/ I E C 2 70 0 1 s h a l l b e e s ta b l i s he d , i m p l e me n te d , o p e r ate d , m a i n ta i n e d ,
and continuously improved.

RQ.ISMS.2 Non-EFC speci fic threats shall be covered by a security measure or X X
security control de fined by the ISO/IEC 27002 or equivalent standard.
6.3 Communication interfaces
Communication interfaces are some of the most threatened links in the security chain of the EFC system
as shown in the threat analysis in A n ne x D . P ro te c ti n g i nte r face s a ga i n s t a l l th re ats w i tho u t a b a s ic r i s k
analysis results in unreasonably high implementation costs. lists all requirements identi fied in Tab le 4
the threat analysis.
Table 4 — General interface requirements
RQ. I F. 0 2 D at a e xc h a n ge s h a l l b e do n e u s i n g tr a n s m i s s i o n c h a n n e l s w i th r e l i ab l e X X
availability.
RQ. I F. 1 0 Data exchange shall guarantee data con fidentiality. X X
RQ. I F. 1 1 Data exchange shall guarantee data integrity. X X
18
ISO/TS 192 99:2 015(E)
Table 4 (continued)
RQ. IF.1 2 Data exchange shall guarantee the authenticity of the data originator. X X
RQ. IF.1 3 Data exchange shall guarantee non-repudiation with proof of origin. X X
RQ. IF.14 Data exchange shall guarantee non-repudiation with proof of delivery. X X
RQ. IF. 20 Data exchange shall only be done between authenticated entities for X X
the respective data exchange.
RQ. IF. 3 0 Data exchange shall allow the detection of resent messages X X
(protection against replay attacks).
RQ. IF. 31 Data exchange shall allow the detection of mass rej ection of toll X X
declarations (protection agains t interface errors) .
RQ. IF. 32 Data exchange shall allow the detection of mass rej ection of billing X X
details (protection against interface errors) .
6.4 Data storage
Data storage shall ful fil the following requirements independently of the state of data processing.
Table 5 — Data storage requirements
RQ. DS .01 Access to stored data shall only be granted after authorization. X X
RQ. DS .02 Access to stored data shall only be granted via de fined interfaces and X X
de fined procedures.
RQ. DS .03 Stored data shall have an independent backup storage. X X
RQ. DS .05 Data storage shall guarantee data integrity. X X
RQ. DS .06 Access to data storage shall guarantee data con fidentiality. X X
RQ. DS .07 Data s torage shall guarantee non-repudiation with proof of origin for X X
applicable data.
RQ. DS .0 8 Data storage shall guarantee non-repudiation with proof of delivery for X X
applicable data.
6.5 Toll charger
The following clauses list requirements for protection of the TCs assets.
Table 6 — Toll charger requirements
RQ.TC .01 The TC shall determine if factual road usage is represented by a X X

corresponding set of correct and complete toll declarations either
acquired directly through the TCs RSE or through a TSP (enabled by
RQ.TSP.51 for autonomous systems).
RQ.TC .02 In case the TC performs spot checks, he shall be able to determine the X X
OBE working status (enabled by RQ.TSP.53 for autonomous systems).
RQ.TC .03 In case the TC performs spot checks, he shall be able to determine the X X
ICC working status in the OBE .
RQ.TC .0 4 The TC shall check the integrity and authenticity of the received data as X X
compared to the data sent from the OBE .
RQ.TC .05 The TC shall determine if toll declarations are based on data originating X X
from a legitimate OBE or TSP back end (enabled by RQ.TSP.55).

19
ISO/TS 192 99: 2 015(E)
Table 6 (continued)
RQ.TC .06 The TC shall make sure that any invoices generated in his name and on his X X
behalf are conformant to the invoicing rules of his country (enabled by
RQ.TSP. 56) .
RQ.TC .07 The TC shall ensure that the TSPs OBE is suitable for use in his toll. X X
RQ.TC .0 8 The TC shall check the model and make of OBE during a vehicle check X X
(enabled by RQ.TSP.58) to identify the use of OBE versions not certi fied
by the TC.
RQ.TC .10 The TC shall implement all necessary technical and organizational X X
mechanisms for a correct implementation of a keyset for OBE
communication provided by the TSP.
RQ.TC .1 2 The TC shall make sure that his back end system can cope with a sudden X X
change of the customization information of an OBE (e. g. change of license
plate over the air) .
RQ.TC .1 3 The TC shall verify the correctness of billing details received from the TSP. n. a. X
NOTE This requirement is not applicable where the billing details are
provided by the TC (this is covered by RQ.TSP.12).
RQ.TC . 20 The TC shall detect RSE damaging and recover the RSE functionality X X
within an agreed time frame.
RQ.TC . 21 The TC shall detect theft of RSE parts and recover the RSE functionality X X
by a replacement of the stolen part within an agreed time frame.
RQ.TC . 2 2 The TC shall implement RSE authentication measures for DSRC X X
communication based upon security level 1 as de fined in EN 15509:2014
or equivalent national s tandards/regulations .
RQ.TC . 2 3 The TC shall detect RSE malfunction or underperformance and correct it X X

within an agreed time frame.
RQ.TC . 24 The RSE shall not allow unauthorized access to software and data. X X
RQ.TC . 25 The TC shall guarantee con fidentiality, integrity, and non-repudiation with X X
proof of origin of a keyset for OBE communication during transfer to the
RSE .
RQ.TC . 3 0 The TC shall implement all necessary technical and organizational X X

measures to avoid an enforcement case when a correct toll declaration
was received.
RQ.TC . 31 The TC shall make sure that the correct service user is charged for an X X
enforcement case.
RQ.TC . 32 The TC shall make sure that the enforcement case data are court proof. X X
RQ.TC . 50 A data protection commissioner or delegate shall have the possibility to X X

audit the system for compliance with data privacy regulations.
NOTE Such audits shall be used to prove the data protection concept.
RQ.TC . 51 The TC shall publish his procedures of collecting and processing personal X X
data or regis ter with the responsible data protection authorities.
RQ.TC .70 The TC shall exhaustively test all features of an RSE update before it is X X
implemented.
RQ.TC .71 The TC shall have a rollback scenario ready before an RSE update is X X
implemented.
RQ.TC .90 The TCs systems shall be designed in a way that access to stored or X X
processed data is only possible within the legal context of the respective
country (e.g. lawful interception).
RQ.TC .91 The TC shall provide non-repudiation with proof of origin for dis tributed X X
toll context data.
20
ISO/TS 192 99:2 015(E)
Table 6 (continued)
RQ.TC .92 The TC shall only accept an OBE after detecting if an OBE belongs to a X X
trusted TSP and that the TSP guarantees payment for that speci fic OBE
(enabled by RQ.TSP.62).
RQ.TC .93 The TC shall only accept an OBE after detecting if the ICC in the OBE X X
belongs to a trusted TSP and that the TSP guarantees payment for that
speci fic ICC.
RQ.TC .9 4 The TC shall only accept an exception list after veri fication of X X
non-repudiation with pro of of origi n .
RQ.TC .95 The TC shall be responsible for the availability of his back office interfaces X X
accordi ng to agre ed s er vice level s .
RQ.TC .9 6 The TC shall be responsible for the availability of his RSE interfaces to an X X
OB E accordi ng to agree d ser vice level s .
RQ.TC .9 7 The TC shall verify the provided non-repudiation with proof of delivery in X X
the TSPs acknowledge for di s tributed tol l context data.
RQ.TC .9 8 The TC shall implement all necessary technical and organizational X X

meas u res to guarantee the di s tribution of corre c t tol l context data to the
TSP.
RQ.TC .9 9 T he TC shal l acknowledge a re ceived excep tion li s t and provide X X

non-repudiation with proof of delivery to the TSP.
6.6 Toll service provider
T he following clauses lis t requirements for the protec tion of the TSPs as s ets .
Table 7 — Toll service provider requirements
RQ.TS P. 01 The TSP shall determine if factual road usage is represented by a n . a. X

corres p ondi ng se t of corre c t and complete tol l de clarations .
RQ.TS P. 03 The TSP shall check the integrity and authenticity of the received road n . a. X
us age data s ent from the OBE .
RQ.TS P. 0 4 T he TS P shal l determi ne i f tol l de clarations are b ased on data origi nati ng X X
from a legitimate OBE or IC C .
RQ.TS P. 0 5 The OBE shall prevent or detect illegal modi fication of parameters through X X
its external i nterfaces .
RQ.TS P. 0 6 The ICC shall prevent or detect illegal modi fication of parameters through X X
its external i nterfaces .
RQ.TS P. 0 7 The OBE shall not allow the service user to modify fixed vehicle parame - X X
ters .
RQ.TS P. 0 8 T he TS P shal l detec t duplicate or fal s e OBE or IC C identities and blo ck X X

such OBE or ICC identities by placing them on the exception list.
RQ.TS P. 0 9 The TSP shall notify the service user if the OBE or ICC is not working X X
correctly.
RQ.TS P.10 T he TS P shal l determi ne i f bi l l i ng de tai l s are b as ed on correc t and n . a. X
complete ro ad us age data.
RQ.TS P.11 The TSP shall determine if factual road usage is represented by a n . a. X
corres p ondi ng se t of bi l l i ng detai l s .
RQ.TS P.1 2 The TSP shall verify the correctness of billing details received from the TC. X X
NO TE T hi s requ i rement i s not applicable where the bi l l i ng de tai l s are

provided by the TSP (this is covered by RQ.TC.13).

21
ISO/TS 192 99: 2 015(E)
Table 7 (continued)
RQ.TSP.1 3 The TSP shall accept received toll context data only after veri fication of X X
non-repudiation with proof of origin.
RQ.TSP.14 The TSP shall provide exception lists including non-repudiation with proof X X
of origin to the TC .
RQ.TSP.16 The OBE shall detect signal input inconsis tencies. n. a. X
RQ.TSP.17 The TSP shall acknowledge received toll context data and provide X X
non-repudiation with proof of delivery to the TC.
RQ.TSP.18 The TSP shall verify the provided non-repudiation with proof of delivery X X
in the TCs acknowledge for a dis tributed exception list.
RQ.TSP.19 The TSP shall notify the TC about stolen or cloned OBE or ICC. X X
RQ.TSP. 20 The TSP shall accept reports of stolen OBE or ICC by service users. X X
RQ.TSP. 21 The TSP shall detect cloned OBE or ICC and block them by placing them on X X
the exception lis t.
RQ.TSP.40 The OBE shall not allow change of internal data through the user X X
interface except the data allowed to be changed.
RQ.TSP.41 The OBE shall only present intended data by the user interface. X X
RQ.TSP.42 The TSPs implementation of the front end and gathering and processing X X
of data should be in compliance with the privacy requirements of the toll
domain.
RQ.TSP. 50 The TSP shall ensure that only authenticated service users have access to X X
systems that manage their personal data.
RQ.TSP. 51 The TSP shall enable the TC to determine if factual road usage is X X
represented by a corresponding set of correct and complete toll
declarations sent either directly from the OBE to the TCs RSE (in a DSRC
system) or through a back office data exchange (required to enable
RQ.TC.01 for autonomous systems).
RQ.TSP. 53 The TSP shall enable the TC to perform spot checks through CCC (required X X
to enable RQ.TC.02 for autonomous systems).
RQ.TSP. 55 The TSP shall enable the TC to determine if toll declarations are based on X X
data originating from a legitimate front end (required to enable RQ.TC .05
for autonomous systems) or OBE (in a DSRC system).
RQ.TSP. 5 6 The TSP shall enable the TC to audit invoices to service users for tolls of X X
his toll domain (required to enable RQ.TC .06) .
RQ.TSP. 57 The TSP shall enable the service user to check the correctness of an X X
invoice.
RQ.TSP. 5 8 The TSP shall enable the TC to check the model and make of OBE during a X X
vehicle check (required to enable RQ.TC .0 8) .
NOTE The data in the relevant fields are set by the manufacturer during
production. The responsibility of the TSP is to provide the TC with the
different possible values for these fields to distinguish between
the different OBE models and makes .
RQ.TSP. 59 The TSP shall publish his procedures of collecting and processing personal X X
data or regis ter with the responsible data protection authorities.
RQ.TSP.60 The TSP shall only use equipment that passed certi fication by the TC and X X
delivers the agreed quality of service.
RQ.TSP.62 The TSP shall enable the TC to detect if an OBE belongs to the TSP X X
(required to enable RQ.TC .92) .
RQ.TSP.70 The TSP shall exhaustively test all features of an OBE update before it is X X
implemented (e.g. dis tributed over the air) .
22
ISO/TS 192 99:2 015(E)
Table 7 (continued)
RQ.TSP.71 The TSP shall have a rollback scenario ready before an OBE update is X X
implemented (e. g. dis tributed over the air) .
RQ.TSP. 80 The TSP shall implement all necessary technical and organizational quality X X
control mechanisms for all OBE before they are distributed to the service
users .
control mechanism for the provision of a key set for OBE communication to
the TC .
control mechanism for the maintenance or exchange of OBE with low
performance.
RQ.TSP. 89 The TSP shall take protective measures agains t repudiation of invoices and X X
its underlying con firmation data by service users.
RQ.TSP.90 The TSPs systems should be designed in a way that access to stored or X X
countries (lawful interception) .
RQ.TSP.91 The data communication between front end (OBE ) and back end (TSP) n. a. X
shall be protected against interception in a way that access to stored or
country (lawful interception).
RQ.TSP.92 Customization of OBE shall be done in a secure way to guarantee data X X
integrity and non-repudiation with proof of origin.
RQ.TSP.96 The TSP shall guarantee the availability of its POS network according to X X
agreed service levels .
RQ.TSP.97 The TSP shall implement all necessary technical and organizational X X
measures that an update of the customization information is correct.
6.7 Interoperability Management
The main security requirement for an interoperability management is to ensure the trust of all
stakeholders in the interoperability scheme.
Table 8 — Interoperability management requirements
RQ.IM.01 The interoperability management shall issue an EFC security policy. X X
NOTE Examples explaining the content of such a security policy are given
in Annex E and Annex F.
RQ.IM.02 The interoperability management shall have or de fine one or more X X

auditing bodies supervising the security implementation of the TSP
and TC involved in the interoperable EFC scheme.
6.8 Limitation of requirements
The following requirements are included to document the limitation of security measures against some
threats. This means that either no required security measure exists to protect against the threat, or the
security measure is not really feasible because it is much too expensive. The requirements in Table 9
are not further treated in this Technical Speci fication.

23
ISO/TS 192 99: 2 015(E)
Table 9 — Denial of service and hardware integrity threats
RQ. X X . 0 1 Prevent denial of service attack. Prevent message transmission delay. X X
T h i s r e qu i r e me n t c o ve r s at t ac k s a g a i n s t a c o m mu n i c a ti o n i n te r fac e o r
against a whole service. A simple and/or cheap security measure does not
e x i s t du e to th e fac t th at l o n g d i s ta n c e c o m mu n i c a ti o n i n te r fac e s c a n n o t b e
p r o te c te d a ga i n s t a l l k i n d s o f i m a g i n ab l e at t ac k s .
RQ. X X . 0 2 Prevent manipulating equipment; especially prevent OBE from HW X X
m a n i p u l ati o n .
Such a requirement can be ful filled by developing a tamperproof OBE,

which is not deemed viable from a cost efficiency perspective.
7 Security measures — countermeasures
7.1 Overview
A security measure describes actions to be taken by the addressed entity to satisfy one or more security
requirements. The actual implementation of the action is up to the entity. A security measure describes
one possible solution to satisfy one or more security requirements.
In order to be compliant with this Technical Speci fication, an implementation shall ful fil all security
measures that are associated to the security requirements in C l au s e 6 wh ic h a re s e l e c te d i n ac c o rd a nc e
with the applicable security policy.

The table below explains the notation and relations of the security measures de fined in this Clause.
Table 10 — Notation and relations of security measures
No. Unique number for every security measure

Security measure Description of the security measure (countermeasure)
DSRC Marked with an X if this security measure is relevant for a DSRC system
GNSS Marked with an X if this security measure is relevant for an autonomous system
Ful illed RQ
f List of requirements that the security measure ful fils
NOTE For a detailed de finition for the implementation of communication interface security measure,
see C l au s e 8.
7.2 General security measures
This Technical Speci fication provides measures to address potential EFC speci fic risks by de fining
requirements and detailed security measures which take into consideration the speci fic nature of EFC
systems including their interoperable interfaces and speci fic assets. Those security measures have
been designed based on an analysis of possible threats speci fically applicable to EFC systems, without
evaluating the real associated risks, which are system speci fic.
24
ISO/TS 192 99:2 015(E)
Table 11 — General security measures
No. Security measure DSRC GNSS
Ful illed RQ
f
SM.101 The TC shall register the data processing application of the EFC system with X X
the national data protection commissioner or authority for compliance with

national data protection regulations if required by law.
RQ.T C . 5 0
RQ.T C . 5 1
RQ.T S P. 42
RQ.T S P. 5 9
RQ.T S P.9 0
RQ.T S P.9 1
SM.102 T he T C a n d th e T S P s h a l l s i g n a P e r s o n a l D a ta A s s i s t a n t A g r e e m e n t to b e X X
c o mp l i a n t to th e n ati o n a l d a ta p r o te c ti o n r e g u l a ti o n s o f th e T C . I n th i s
RQ.T S P. 42
a g r e e me n t, th e du ti e s a n d r i gh ts o f th e T S P a r e s ta te d i n r e ga r d to the d at a
RQ.T S P.9 0
p r o c e s s i n g.
RQ.T S P.9 1
RQ.T C . 0 6
RQ.T S P. 5 6
RQ.T S P. 8 9
SM.103 T he c o n tr ac ti n g p a r ti e s o f c o m mu n i c ati o n p r o v id e r s s h a l l s i g n a P e r s o n a l X X
D at a A s s i s t a n t A g r e e me n t o r e qu i va l e n t to b e c o mp l i a n t to th e n ati o n a l d at a
RQ.T S P. 42
p r o te c ti o n r e g u l a ti o n s o f th e T C . I n th i s a g r e e m e n t, the du ti e s a n d r i g h t s o f
RQ.T S P.9 0
th e c o m mu n i c ati o n p r o v id e r a r e s t ate d i n r e g a r d to th e p r o c e s s i n g o f
RQ.T S P.9 1
p e r s o n a l d a ta .
SM.104 The TC shall have the possibility to perform audit(s) of the TSP systems and X X
p r o c e du r e s to p r o o f th e ad h e r e nc e to the r e g i s te r e d d a ta p r o c e s s i n g
RQ.T S P. 42
ap p l i c a ti o n a n d the P e r s o n a l D at a A s s i s t a n t A g r e e me n t .
RQ.T S P.9 0
RQ.T S P.9 1
SM.105 The contracting parties of communication providers shall have the possibility X X
to perform audit(s) of the communication providers systems and procedures RQ.T S P. 42

to p r o ve th e ad h e r e n c e to th e r e g i s te r e d d a ta p r o c e s s i n g ap p l i c ati o n a n d th e
P e r s o n a l D at a A s s i s ta n t Ag r e e m e n t o r e qu i va l e n t . RQ.T S P.9 0
RQ.T S P.9 1
SM.106 The TSP shall establish a quality control process for the maintenance or X X
e xc h a n ge o f l o w p e r fo r m i n g O B E w i th i n a n a g r e e d ti m e fr a me . T h i s p r o c e s s
may be initiated by the detection of a low performing OBE by the TSP or by a

RQ.T S P. 8 2
report of such an OBE by the TC.

SM.107 T he T S P s h a l l e n a b l e the T C to au d i t i n vo i c e s ge n e r a te d i n h i s n a me . T he T C X X
shall periodically audit invoices to service users for tolls of his toll domain. RQ.T C . 0 6
RQ.T S P. 5 6
RQ.T S P. 8 9
7.3 Communication interfaces security measures
7.3 .1 General
Security measures for the protection of data exchanged between entities using the different interfaces.
Table 12 — General interface security measures
Ful illed RQ
f
SM.200 T he c o n tr ac ti n g p a r ti e s o f c o m mu n i c ati o n p r o v id e r s s h a l l h ave p r o p e r X X
s e r v i c e l e ve l s a g r e e d a n d m o n i to r i n g p r o c e du r e s i n p l ac e th at a r e ab l e to
detect any non-compliant behaviour of the communication provider.

RQ. I F. 0 2
RQ.T S P. 6 0
25
ISO/TS 192 99: 2 015(E)
Table 12 (continued)
Ful illed RQ
f
SM.201 The TC and the TSP shall agree on de fined interfaces and procedures for X X
th e ac c e s s to s to r e d d a ta . T he s e i n te r fac e s s ho u l d b e b a s e d o n E u r o p e a n
RQ. D S . 0 2
o r I n te r n a ti o n a l S t a n d a r d s wh e n e ve r p o s s i b l e .
RQ. D S . 0 6
RQ. I F. 2 0
RQ. I F. 3 1
RQ. I F. 3 2
RQ.T C . 2 4
RQ.T C .9 0
SM.202 The TC and the TSP shall only allow access to stored data for an authorized X X
and authenticated entity. RQ. D S . 0 1
RQ. I F. 2 0
RQ.T C . 2 4
RQ.T C .9 0
RQ.T S P. 5 0
SM.203 Implement the security measure or security control de fined by X X
I S O/ I E C 2 70 0 2 o r e qu i va l e n t .
RQ. D S . 0 3
RQ. D S . 0 5
RQ.ISMS.2
SM.204 The TC and TSP shall agree on a service level agreement de fining quality X X
go a l s a n d r e s p o n s e ti me s .
RQ.T C . 0 7
RQ.T C . 2 0
RQ.T C . 2 1
RQ.T C . 2 3
RQ.T C .9 5
RQ.T C .9 6
RQ.T S P. 6 0
RQ.T S P.9 6
SM.205 Implement an Information Security Management System (ISMS) according X X
to I S O/ I E C 2 70 0 1 o r a n e qu i va l e n t.
RQ.ISMS.1
SM.207 P r o o f o f o r i g i n au the n ti c a to r s s h a l l b e s to r e d to ge the r w i th th e d at a X X
r e c e i ve d .
RQ. D S . 0 7
SM.208 Proof of delivery authenticators shall be stored together with the data X X
de l i ve r e d .
RQ. D S . 0 8
7.3 .2 DSRC-EFC interface
Table 13 — DSRC-EFC interface security measures
Ful illed RQ
f
SM.210 I f to l l de c l a r a tio n s a r e ac qu i r e d th r o u gh th e D S RC i n te r fac e , th e R S E X n. a.
shall request the OBE to calculate and provide a DSRC Message

Authentication Code for TC (MAC_TC) over at least the ISO 14906 RQ. I F. 1 1
attribute PaymentMeans using a key known only to the TC and the TSP RQ. I F. 1 2
during an EFC transaction. The OBE shall respond accordingly. RQ. I F. 1 3
RQ.T C . 0 1
RQ.T S P. 5 5
RQ.T S P. 8 9
26
ISO/TS 192 99:2 015(E)
Ful illed RQ
f
SM.211 I f to l l d e c l a r ati o n s a r e ac q u i r e d th r o u gh the D S RC i n te r fac e , the R S E s h a l l X n. a.
request the OBE to calculate and provide a DSRC Message

Authentication Code for TSP (MAC_TSP) over at least the ISO 14906 RQ. I F. 1 1
attribute PaymentMeans using a key known only to the TSP during an RQ. I F. 1 2
EFC transaction. The OBE shall respond accordingly. RQ. I F. 1 3
RQ.T S P. 0 4
RQ.T S P. 8 9
SM.212 T he O B E s h a l l i mp l e me n t a n ac c e s s c o n tr o l m e c h a n i s m fo r a n E F C X n. a.
c o m m a n d add r e s s i n g i t s E F C d at a a t tr i b u te s . T he R S E s h a l l i m p l e me n t the
RQ. I F. 2 0
c a l c u l a ti o n o f th e c o r r e s p o n d i n g ac c e s s c o d e s .
RQ.T C . 2 2
RQ.T S P. 0 5
RQ.T S P. 0 7
RQ.T S P. 4 0
RQ.T S P. 41
SM.213 T he R S E s h a l l r e ad , i n c r e m e n t, a n d w r i te a tr a n s ac ti o n c o u n te r to th e O B E . X n. a.
T he O B E s h a l l s u p p o r t th i s .
RQ.T S P. 2 1
SM.214 The TSP shall implement a MAC_TSP authenticator in the OBE to prove its X n. a.
authenticity and integrity. RQ. I F. 1 1
RQ. I F. 1 2
RQ. I F. 1 3
RQ.T S P. 0 3
RQ.T S P. 0 4
RQ.T S P. 6 2
SM.215 The TSP shall implement a MAC_TC authenticator in the OBE to prove its X X
authenticity and integrity. RQ. I F. 1 1
RQ. I F. 1 2
RQ. I F. 1 3
RQ.T S P. 6 2
7.3 .3 CCC interface
Table 14 — CCC interface security measures
Ful illed RQ
f
SM.220 I f c o mp l i a n c e c h e c ki n g i s p e r fo r m e d th r o u gh th e D S RC i n te r fac e , th e n. a. X
RSE shall request the OBE to calculate and provide a DSRC Message
Authentication Code for TC (MAC_TC) over at least the ISO 14906 RQ. I F. 1 1
attribute PaymentMeans using a key known only to the TC and the TSP RQ. I F. 1 2
during a CCC transaction. The OBE shall respond accordingly. RQ. I F. 1 3
RQ.T S P. 5 3
SM.221 I f c o m p l i a n c e c h e c k i n g i s p e r fo r m e d th r o u gh th e D S RC i n te r fac e , th e n. a. X
RSE shall request the OBE to calculate and provide a DSRC Message
Authentication Code for TSP (MAC_TSP) over at least the PaymentMeans RQ. I F. 1 1
attribute, using a key known only to the TSP during a CCC transaction. RQ. I F. 1 2
The OBE shall respond accordingly. RQ. I F. 1 3
27
ISO/TS 192 99: 2 015(E)
Ful illed RQ
f
SM.222 T h e O B E s h a l l i mp l e m e n t a n ac c e s s c o n tr o l me c h a n i s m fo r a n E F C n. a. X
c o m m a n d add r e s s i n g i t s C C C d at a at tr i b u te s . T he R S E s h a l l i m p l e m e n t
RQ. I F. 2 0
th e c a l c u l ati o n o f the c o r r e s p o n d i n g ac c e s s c o de s .
RQ.T C . 2 2
RQ.T S P. 0 5
RQ.T S P. 0 7
RQ.T S P. 4 0
RQ.T S P. 41
RQ.T S P. 5 3
SM.223 If toll declarations are acquired by the TSP, the OBE shall provide an n. a. X
u n de n i ab l e p r o o f o f c o r r e c t r e g i s tr ati o n o f r o a d u s a ge d a ta fo r th e g i ve n
RQ.T C . 0 1
l o c ati o n a n d m o m e n t i n ti me o f the C C C tr a n s ac ti o n .
RQ.T S P. 5 1
RQ.T S P. 5 3
RQ.T S P. 8 9
7.3 .4 LAC interface
Table 15 — LAC interface security measures
Ful illed RQ
f
SM.230 I f l o c a l i z ati o n au g m e n ta ti o n c o m mu n i c a ti o n i s p e r fo r m e d th r o u gh th e n. a. X
DSRC interface, the RSE shall provide a MAC_TC over the LAC data sent to
the OBE calculated with a key known only to the TC and the lacTime. RQ. I F. 1 1
RQ. I F. 1 2
RQ. I F. 1 3
SM.231 T h e O B E s h a l l i mp l e m e n t a n ac c e s s c o n tr o l me c h a n i s m fo r a n E F C n. a. X
c o m m a n d add r e s s i n g th e L AC d a t a a t tr i b u te s . T h e R S E s h a l l i m p l e me n t
RQ. I F. 2 0
th e c a l c u l ati o n o f the c o r r e s p o n d i n g ac c e s s c o de s .
RQ.T C . 2 2
RQ.T S P. 0 5
RQ.T S P. 0 7
RQ.T S P. 4 0
RQ.T S P. 41
7.3 .5 Front End to TSP back end interface
Table 16 — Front end to TSP back end interface security measures
Ful illed RQ
f
SM.240 T h e T S P s h a l l i mp l e me n t a n au the n ti c ato r i n th e c h a r ge r e p o r t wh i c h n. a. X
guarantees its authenticity and integrity. RQ.T C . 0 4
RQ.T S P. 0 3
SM.241 T h e b i d i r e c ti o n a l F r o n t E n d to T S P b ac k e n d c o m mu n i c ati o n s h a l l b e n. a. X
i m p l e me n te d u s i n g a s e c u r e c o n n e c ti o n .
RQ. I F. 1 0
RQ. I F. 1 1
28
ISO/TS 192 99:2 015(E)
7.3 .6 TC to TSP interface
Table 17 — TC to TSP interface security measures
Ful illed RQ
f
SM.250 The bidirectional TC to TSP back office data exchange shall be X X

implemented us ing a s ecure connec tion with authentication.
RQ. I F.10
RQ. I F.11
RQ. I F. 31
RQ. I F. 3 2
SM.251 The TC shall link the billing details to a set of toll declarations provided by X X
the TSP or include the as so ciated event data for thos e tol l declarations
RQ.TSP.10
which have been acquired by him.
RQ.TSP.11
RQ.TSP.1 2
SM.252 I f the TSP receives bi l ling details from the TC , he shall comp are them n. a. X
against the sent toll declarations to detect modi fications and/or missing
RQ.TSP.10
or additional tol l declarations not sent to the TC in a GNS S environment.
RQ.TSP.11
RQ.TSP.1 2
RQ.TSP. 8 9
SM.253 Distribution of toll context data shall be undeniably signed by the TC and X X
con firmed by the TSP in an agreed time frame with an authenticated
RQ. I F.1 2
res p onse.
RQ. I F.1 3
RQ. I F.14
RQ.TC .91
RQ.TC .97
RQ.TSP.1 3
RQ.TSP.17
SM.254 Distribution of the exception list shall be undeniably signed by the TSP X X
and con firmed by the TC in an agreed time frame with an authenticated
RQ. I F.1 2
res p onse.
RQ. I F.1 3
RQ. I F.14
RQ.TC .9 4
RQ.TC .9 9
RQ.TSP.14
RQ.TSP.18
SM.255 The front end and/or the TSP back end shall undeniably sign charge n. a. X
rep orts and/or tol l declarations .
RQ. I F.1 2
RQ. I F.1 3
RQ.TSP. 5 5
RQ.TSP. 8 9
SM.256 The originator of a trust object shall undeniably sign it. X X
RQ. I F.1 2
RQ. I F.1 3
RQ.TC . 2 5
RQ.TSP. 81
SM.257 The TSP shall provide data underlying a speci fic toll declaration acquired n. a. X
through his system on demand of the TC (charge report and/or more
RQ.TSP. 51
detai led ro ad us age data) .
SM.258 T he TC shal l provide the tariff table and all the relevant toll context data to X X
the TSP to allow him to calcu late the amount given in the bil ling detai ls .
RQ.TC .9 8
NO TE O ther means than I SO/ TS 17575 -3 could be used, e. g. publication RQ.TSP.1 2
on a webs ite.

29
ISO/TS 192 99: 2 015(E)
Ful illed RQ
f
SM.259 The TSP shall be able to perform plausibility and completeness checks on X X
r e c e i ve d b i l l i n g de ta i l s .
RQ.T S P. 1 0
NOTE Those checks could be performed by the veri fication of the RQ.T S P. 1 1
physical feasibility of trips in the toll domain. RQ.T S P. 1 2
SM.260 T h e T S P s h a l l e s ta b l i s h a c o n tr o l m e c h a n i s m to e n s u r e a c o r r e c t p r o v i s i o n X X
of a key set for OBE communication to the TC. RQ.T S P. 8 1
SM.261 T h e T C a n d th e T S P s h a l l e s t ab l i s h a d at a tr a n s fe r p r o to c o l th a t a l l o ws th e X X
detection of duplicate messages as a protection against replay attacks. RQ. I F. 3 0
SM.262 The TSP shall provide the TC with the data about all valid OBE issued by X X
him.
RQ.T S P. 5 5
RQ.T S P. 5 8
RQ.T S P. 6 2
SM.263 The TC shall verify that an OBE is listed as valid by the TSP who issued it. X X
RQ.T C . 0 8
RQ.T C .9 2
SM.264 The TC shall guarantee the correct manual entry or automatic processing X X
of a keyset for OBE communication provided by the TSP. RQ.T C . 1 0
SM.265 T h e T C s h a l l c o m p a r e th e b i l l i n g d e t a i l s r e c e i ve d fr o m the T S P a g a i n s t the n. a. X
sent toll declarations to detect modi fications, missing, or additional toll RQ.T C . 1 3
d e c l a r ati o n s no t s e n t to the T C i n a G N S S e n v i r o n m e n t.
RQ.T S P. 8 9
SM.266 The TC shall always acquire the correct and current service user details X X
b e fo r e s t a r ti n g a n e n fo r c e me n t p r o c e du r e .
RQ.T C . 3 1
7.3 .7 ICC interface
Table 18 — ICC interface security measures
Ful illed RQ
f
SM.270 The OBE shall calculate an authentication code to ICC complying with X X
ISO/IEC 7816-3 command/response using a key known only to the ICC RQ. I F. 1 1
i s s u e r.
RQ. I F. 1 2
7.4 End-to-end security measures
End-to-end security means front end to TSP to TC security measures.
30
ISO/TS 192 99:2 015(E)
Table 19 — End-to-end security measures
Ful illed RQ
f
SM.310 The OBE shall be designed as a clearly distinguished entity with a de fined X n. a.
interface to the TC RSE. The OBE’s functionality shall be tested to RQ.TC .01
guarantee its functionality and it shall be auditable according to RQ.TC .07
suitability for use procedure. RQ.TC .1 2
RQ.TSP. 51
RQ.TSP.60
RQ.TSP.70
SM.311 The correct and trustworthy OBE functionality shall be periodically X X

audited by the TSP and optionally by the TC or an independent entity on RQ.TC .01
his behalf.
RQ.TC .07
NO TE An audit process can compare charge data of sample vehicles RQ.TSP. 51
equipped with the OBE with known independent trip data. RQ.TSP.60
SM.312 The TC shall perform plausibility and completeness checks on toll n. a. X

declarations acquired by the TSP in a GNSS environment. RQ.TC .01
RQ.TC .1 2
SM.313 The TC shall compare toll declarations acquired by the TSP with his own n. a. X
observations in accordance with privacy regulations. RQ.TC .01
SM.314 The TC shall verify if toll declaration(s) acquired by the TSP correctly n. a. X
correspond(s) to charge report(s) and/or road usage data.
RQ.TC .01
SM.315 The TSP shall prepare a fall back scenario before any OBE update and X X
initiate a rollback of the update when needed.
RQ.TSP.71
SM.316 The TC shall determine if the toll declarations have been produced by a X X
trusted OBE by a message authentication code (MAC) or digital signature. RQ. IF.1 2
RQ. IF.1 3
RQ.TC .01
RQ.TC .0 4
RQ.TC .05
SM.317 The TSP shall undeniably sign any update package before it is distributed X X
over the air to ensure its integrity. The OBE shall check the integrity of RQ.TSP.70
the received update before the update is s tarted.
SM.318 If toll declarations are acquired by the TSP, the registration of road usage n. a. X
data shall be based on a minimum set of functions in the OBE trusted by RQ.TC .01
both the TSP and the TC. These functions shall directly or indirectly RQ.TC .0 4
ensure the integrity of the toll declarations including non-repudiation RQ.TC .05
with proof of origin.
RQ.TSP. 51
RQ.TSP. 55
RQ.TSP. 89
SM.319 The TSP shall provide an undeniable proof of correct regis tration of road n. a. X
usage data for a de fined location and moment in time or for a de fined RQ.TSP. 51
range of time and for a speci fied set of OBE(s) on demand to the TC.
SM.320 The TC shall compare proof of correct regis tration of road usage data n. a. X
acquired by the TSP with his own observations in accordance with RQ.TC .01
privacy regulations.
SM.322 The OBE shall be designed as a clearly distinguished entity with a de fined n. a. X
interface to the proxy or TSPs back end. The OBE’s functionality shall be RQ.TC .07
tested to guarantee its functionality and it shall be auditable according to RQ.TSP.01
a de fined procedure. RQ.TSP.60
RQ.TSP.70

31
ISO/TS 192 99: 2 015(E)
Ful illed RQ
f
SM.323 The TSP shall perform plausibility and completeness checks on toll n. a. X
declarations acquired by him. Those checks comprise the veri fication of

the physical feasibility of trips in the toll domain compared with the RQ.T S P. 0 1
RQ.T S P. 5 1
ac t u a l to l l de c l a r ati o n s .
SM.324 The TC shall prepare a fall back scenario before any RSE update and X X
i n i ti ate a r o l l b ac k o f th e u p d ate whe n n e e de d .

RQ.T C . 71
SM.330 T he T S P s h a l l p r o v i d e the s e r v i c e u s e r w i th the de t a i l e d tr a n s ac tio n d a ta X X
up o n r e qu e s t.
RQ.T S P. 5 7
RQ.T S P. 8 9
7.5 Toll service provider security measures
7.5.1 Front end security measures
Table 20 — Front end/OBE interface security measures
Ful illed RQ
f
SM.410 I f c o m p l i a n c e c h e c k i n g i s p e r fo r me d th r o u g h th e D S RC i n te r fac e , th e O B E n. a. X
s h a l l s u p p o r t a C o mp l i a n c e C he c k i n g C o m mu n i c ati o n tr a n s ac ti o n o ve r a n
interface with security as de fined in ISO 12813:2015 when it passes RQ.T C . 0 1
RQ.T C . 0 2
s u c h a R S E o r u s e s e c u r e m o n i to r i n g- c o mp l i a nc e c he c ki n g.
RQ.T S P. 51
RQ.T S P. 5 3
SM.411 The TSP shall test a signi ficant percentage of OBE delivered to him to X X
achieve an accepted quality level according to ISO 2859 or equivalent. RQ.T S P. 8 0
SM.412 I f l o c a l i z ati o n au g m e n ta ti o n c o m mu n i c a tio n i s p e r fo r m e d th r o u gh th e n. a. X
DSRC interface, the TSP shall store the value of the MAC_TC, KeyRef, and RQ. I F. 1 2
l acT i me a s p a r t o f the c h a r ge d a ta a n d p r o v i de the m a s p a r t o f th e c h a r ge
RQ. I F. 1 3
rep or t.
RQ.T S P. 51
SM.413 T h e O B E s h a l l i mp l e m e n t a r o l e b a s e d ac c e s s c o n tr o l m e c h a n i s m fo r i t s X X
DRSC interface. Any commands reserved to the TSP (i.e. other than those
for DSRC-EFC, CCC, and LAC) shall be usable only by the TSP. RQ. I F. 2 0
RQ.T C . 2 2
RQ.T S P. 0 5
RQ.T S P. 0 7
RQ.T S P. 4 0
RQ.T S P. 41
SM.414 The service user shall be noti fied about the OBE or ICC working status. X X
RQ.T C . 0 2
RQ.T C . 0 3
RQ.T S P. 0 9
SM.415 The communication between OBE and proxy shall guarantee n. a. X
con fidentiality, integrity, and authenticity. RQ. I F. 1 0
RQ. I F. 1 1
SM.416 The OBE shall prevent any illegal modi fication of parameters through its X X
e x te r n a l i n te r fac e s o r s w i tc h to a “N O T O K” s t ate i f i t de te c ts i t.
RQ.T S P. 0 5
RQ.T S P. 0 7
32
ISO/TS 192 99:2 015(E)
Ful illed RQ
f
SM.417 The OBE shall s witch to a “NO T OK” s tate if it detects signal input n. a. X
inconsistencies and the TSP shall be informed by the GNSS OBE. RQ.TSP.16
SM.418 The OBE shall not allow the service user to modify any data in the OBE X X
except the data allowed to be changed through the user interface.
RQ.TSP.05
RQ.TSP.07
RQ.TSP.40
SM.419 The ICC shall not allow the service user to modify any data in the ICC. X X
RQ.TSP.06
7.5.2 Back end security measures
Table 21 — TSP back end security measures
Ful illed RQ
f
SM.420 The TSP shall verify if toll declaration(s) correctly correspond(s) to charge n. a. X
report(s) and/or road usage data.
RQ.TSP. 51
SM.421 The TSP shall determine if the charge report has been produced by a n. a. X
trus ted front end.
RQ.TSP.01
RQ.TSP.0 4
RQ.TSP.0 8
SM.422 The TSP shall verify the integrity of the charge report. n. a. X
RQ.TSP.01
SM.423 The TSP shall include stolen or cloned OBE or ICC in an exception list. X X
RQ.TSP.0 8
RQ.TSP.19
RQ.TSP. 20
RQ.TSP. 21
SM.424 The TSP shall detect a cloned OBE or ICC by using the transaction counter X X
or by detecting multiple locations for the same OBE or ICC at the same time. RQ.TSP.0 8
RQ.TSP. 21
SM.425 The TSP shall use cryptographic measures to encrypt the sending of X X
customization data to the OBE to guarantee data integrity and RQ.TSP.92
non-repudiation with proof of origin.
RQ.TSP.97
SM.426 The TSP shall verify the integrity of the charge report based on the n. a. X
MAC_TSP or digital signature. RQ. IF.11
RQ. IF.1 2
RQ. IF.1 3
RQ.TSP.01
RQ.TSP.03
RQ.TSP.0 4

33
ISO/TS 192 99: 2 015(E)
7.6 Toll charger security measures
7.6.1 RSE security measures
Table 22 — RSE security measures
Ful illed RQ
f
SM.510 I f to l l de c l a r a tio n s a r e ac qu i r e d th r o u gh th e D S RC i n te r fac e , th e T C s h a l l X n. a.
check the value of the MAC_TC using the key addressed by KeyRef and the RQ. I F. 1 1
Rnd RS E .
RQ. I F. 1 2
RQ. I F. 1 3
RQ.T C . 0 1
RQ.T C . 0 4
RQ.T C . 0 5
SM.511 I f to l l d e c l a r a ti o n s a r e ac q u i r e d th r o u gh th e D S RC i n te r fac e , the T C s h a l l X n. a.
s to r e th e va l ue o f th e tr a n s ac ti o n c o u n te r r e ad- o u t o f the O B E a s p a r t o f
RQ.T S P. 2 1
th e b i l l i n g d e ta i l s .
SM.512 I f to l l d e c l a r ati o n s a r e ac qu i r e d th r o u g h the D S RC i n te r fac e , the T C s h a l l X n. a.
store the value of the authenticated AttributeList, MAC_TSP, KeyRef, and RQ. I F. 1 2
R n d R S E a s p a r t o f the b i l l i n g d e t a i l s .
RQ. I F. 1 3
RQ.T S P. 2 1
SM.513 If toll declarations are acquired by the TSP, the dedicated compliance n. a. X
c h e c ki n g R S E o f th e T C s h a l l p e r fo r m a C o mp l i a nc e C h e c k i n g
Communication transaction over an interface with security as de fined in RQ.T C . 0 1
RQ.T C . 0 2
I S O 1 2 8 1 3 : 2 0 1 5 wh e n a n O B E p a s s e s i t o r u s e s e c u r e
RQ.T C . 0 5
m o n i to r i n g- c o mp l i a nc e c he c ki n g.
RQ.T S P. 5 3
SM.514 I f c o mp l i a nc e c he c ki n g i s p e r fo r m e d th r o u g h the D S RC i n te r fac e , the T C n. a. X
shall check the value of the MAC_TC using the key addressed by KeyRef RQ. I F. 1 1
a n d th e R n d R S E .
RQ. I F. 1 2
RQ. I F. 1 3
RQ.T C . 0 1
RQ.T C . 0 4
SM.515 I f c o mp l i a nc e c he c ki n g i s p e r fo r m e d th r o u g h the D S RC i n te r fac e , the T C n. a. X
shall store the value of the authenticated AttributeList, MAC_TC, MAC_TSP,

KeyRef, and RndRSE as part of the compliance check record. RQ. I F. 1 2
RQ. I F. 1 3
SM.516 The RSE’s functionality shall be tested to guarantee its functionality. X X
RQ.T C . 70
7.6.2 Back end security measures
Table 23 — TC Back end security measures
Ful illed RQ
f
SM.520 The TC shall perform plausibility and completeness checks on toll X n. a.
declarations acquired by him through the DSRC interface. RQ.T C . 1 2
34
ISO/TS 192 99:2 015(E)
Ful illed RQ
f
SM.521 If toll declarations are acquired by the TSP and these are based on LAC n. a. X
data, the TC shall check the value of the MAC_TC using the key addressed
by KeyRef and the RndRSE. RQ. I F. 1 1
RQ. I F. 1 2
RQ. I F. 1 3
RQ.T C . 0 4
RQ.T C . 0 5
SM.522 The TC shall check the exception list to ensure a valid payment guarantee X X
o f the T S P fo r th e e x i s ti n g s e r v i c e u s e r.
RQ.T C .9 2
RQ.T C .9 3
SM.523 The TC shall use cryptographic measures to guarantee con fidentiality, X X
data integrity, and non-repudiation with proof of origin of a keyset for RQ.T C . 2 5
O B U c o m mu n i c ati o n du r i n g tr a n s fe r to th e R S E .
SM.524 T h e T C s h a l l m a ke s u r e th a t a l l r e l e va n t to l l d e c l a r a ti o n s a r e c o n s i de r e d X X
b e fo r e i n i ti a ti n g e n fo r c e m e n t p r o c e du r e s a g a i n s t a s e r v i c e u s e r.
RQ.T C . 3 0
SM.525 The TC shall use cryptographic measures to guarantee data integrity and X X
n o n- r e p ud i ati o n w i th p r o o f o f o r i g i n fo r a l l r e c o r de d d a ta r e ga r d i n g a n
RQ.T C . 3 2
e n fo r c e me n t c a s e .
7.6.3 Other TC security measures
Table 2 4 — Other TC security measures
Ful illed RQ
f
SM.530 I f to l l d e c l a r ati o n s a r e ac q u i r e d th r o u gh the D S RC i n te r fac e , the T C s h a l l X n. a.
compare them with his own observations in accordance with privacy RQ.T C . 0 1
r e g u l a tio n s .
8 Security speci ications for interoperable interface implementation

f
8.1 General
8.1.1 Subj ect
This subclause de fines the detailed Technical Speci fications supplementing the de finitions in other
standards that shall be implemented to ful fil the security measures de fined in C l au s e 7 wh i ch a re
directly related to an application data unit (ADU) speci fication of an interoperable interface.
8.1.2 Signature and hash algorithms
The signature and hash algorithms for proof of message authenticity, integrity, and non-repudiation are
de fined in the following standards:
— security speci fications for TC to TSP back office interface: ISO 12855:2015;
— security speci fications for front end to TSP interface: ISO 17575-1:2015;
— non-DSRC MAC algorithm: CEN/TS 16702-1:2014;
— security speci fications for CCC: ISO 12813:2015;
35
ISO/TS 192 99: 2 015(E)
— security speci fications for LAC: ISO 13141:2015.
8.2 Security speci ications for DSRC-EFC f
8.2 .1 Subj ect
This subclause provides the implementation of security measures SM.210, SM.211, SM.212, SM.214, and
SM215.
8.2 .2 OBE
The OBE shall comply with the security measures of EN 15509:2014 security level 1 or equivalent
n atio n a l s ta nd a rd s/re g u l atio n s E u ro p e .
8.2 .3 RSE
The RSE shall comply with the security measures of EN 15509:2014 security level 1 or equivalent
national standards/regulations outside Europe. The RSE may additionally support OBE complying with
EN 15509:2014 security level 0 or equivalent national standards/regulations.
NOTE Security level 0 will provide compatibility with legacy OBE not supporting this Technical Speci fication.
The RSE shall request MAC_TC and MAC_TSP by addressing at least the PaymentMeans attribute. The
RSE shall use one of the values of KeyRef corresponding to AuthenticationKey 1 to 4 to obtain the
MAC_TC. The RSE shall use one of the values of KeyRef corresponding to AuthenticationKey 5 to 8 to
obtain the MAC_TSP.
The exact values of KeyRef to be used shall be subject of agreement between toll charger and toll
s e r v i c e p ro v i de r.
9 Key management
9.1 Overview
Keys are a critical part of any security system that relies on cryptographic techniques. The appropriate
protection of keys depends on a number of factors such as the type of application for which the keys
are used, the threats they face, the different states the keys may assume, etc. Primarily, depending
upon the cryptographic technique, they have to be protected against disclosure, modi fication,
destruction and replay.
NOTE ISO/IEC 11770-1:2010, Annex A provides a list of threats to key management.
The objective of key management is the secure administration and use of key management services and
therefore, the protection of keys is extremely important. Key management procedures depend on the
underlying cryptographic mechanisms, the intended use of the key, and the security policy in use. Key
management also includes those functions that are executed in cryptographic devices.
Key management is the administration and use of the services of generation, registration, certi fication,
de re g i s tratio n , d i s tr ib u tio n , i n s t a l l atio n , s to ra ge , a rch i v i n g , re vo c atio n , de r i vatio n , a n d de s tr uc ti o n of
keying material.
9.2 Asymmetric keys
9.2 .1 Key exchange between stakeholders
The exchange of root public keys, i.e. CA root certi ficates is de fined in 5 . 4 .1 .
36
ISO/TS 192 99:2 015(E)
The exchange of entity public keys, i.e. end-entity certi ficates, shall be according to the public key
transport mechanism 3 de fined in ISO/IEC 11770-3.
In case of public key transport mechanism 3, the certi ficate veri fication procedure shall include the
check of the certi ficate attribute “Extended Key Usage” with OID for the following:
— TC to TSP interface certi ficate;
— Front End to TSP Back End interfaces certi ficate.
9.2.2 Key generation and certi ication f
Key generation and certi fication including certi ficate life cycle management (including, among others,
key generation and certi fication processes) shall be performed at least according to Annex D of
I SO/I EC 11770 -1 : 2 010 .
Random bit generators (e.g. for the generation of session keys) shall comply with the requirements
de fined in ISO/IEC 18031.
NOTE Additional information and guidance for asymmetric key management and PKIs is provided for
example in Reference [16 ].
9.2 .3 Protection of keys
Private keys for ADU authentication and/or decryption shall be stored in a cryptographic module
designed according to one of the following example security standards and protection pro files:
— ISO/IEC 19790 (minimum level 3);
— FIPS PUB 140-2 (minimum security level 3);
— common criteria protection pro file BSI-PP-0002 (minimum EAL4).
9.2 .4 Application
Each TSP shall have at least the following certi ficates for different uses:
— an ADU message signing certi ficate for ISO 12855:2015 messages;
— a certi ficate used for establishing secure communication channels (an IPsec/TLS certi ficate securing
ISO 12855:2015 communication);
— if applicable a certi ficate used for establishing secure communication between front end to TSP
back end in an autonomous system.
In case of charge report authentication by a signature according to SM.240, each OBE should have its
own certi ficate.
Each TC shall have at least the following certi ficates for different uses:
— an ADU message signing certi ficate for ISO 12855:2015 messages;
— a key encryption certi ficate for message and/or key encryption purposes from the TSP;
— a certi ficate used for establishing secure communication channels (an IPsec/TLS certi ficate securing
I SO 1 2 85 5: 2 01 5 communication) .

37
ISO/TS 192 99: 2 015(E)
9.3 Symmetric keys
9.3 .1 General
The following are three different applications for symmetric keys in an EFC system:
— the DSRC communication keys with two different characteristics, the DSRC master key, and the
derived OBE DSRC key;
— the MAC keys with two different characteristics, the MAC master key and the derived OBE MAC key;
— the communication session keys to encrypt data of a communication channel between two entities.
9.3 .2 Key exchange between stakeholders
9.3 .2 .1 General
Symmetric keys shall be exchanged by using the secured and authenticated channel. Such a channel is,
for example, a VPN connection or a transfer using a courier, registered mail, etc. where the key message
is stored on a memory device. The keys inside the message shall be additionally encrypted unless a
cryptographic module with active key access authentication for the exchange is used.
The key encryption algorithm (including padding/encoding method) for the data element key below
shall be performed according the following de finitions.
9.3 .2 .2 Key encryption algorithm
The RSA algorithm with the RSA encoding method (REM1) according to ISO/IEC 18033-2 shall be used
for key encryption.
RSA-2048 as de fined in ISO/IEC 18033-2 shall be used for key encryption.
NOTE The required key encryption algorithm (REM1) according to ISO/IEC 18033-2 is equal to RSAES-OAEP
in PKCS#1 v2.1 when KDF1 is applied.
9.3 .2 .3 Padding algorithm
If not otherwise de fined, the padding algorithm used in this Technical Speci fication shall be the padding
method 2 de fined in ISO/IEC 9797-1:2011, 6.3.3.
For non-DSRC messages authenticated by a signature or MAC, the padding algorithm de fined in this
Clause shall be used, but the padding shall not be added to the message for transmission.
NOTE 1 Adding these padding bits to an ASN.1, encoded message is not supported by the ASN.1 compiler.
NOTE 2 The padding method 2 for hashes de fined in ISO 10118-1:2000, A.2 is technically the same method.
9.3 .2 .4 Key transfer
The keys shall be signed by its originator and sent in the TrustObjectADU if an ISO 12855:2015
compatible back office data exchange is used.
The speci fic ASN.1 module TrustObjectCode has been de fined in ISO 12855:2015 to verify the decryption
of sent encrypted data (e.g. the DSRC master keys).
38
ISO/TS 192 99:2 015(E)
9.3 .3 Key lifecycle
9.3 .3 .1 General
Random bit generators for the generation of symmetric keys shall comply with the requirements
de fined in ISO/IEC 18031.
Destroying of a key shall be done by overwriting the original key and any copy of the key in the memory
and other backup data storages.
9.3 .3 .2 DSRC keys
DSRC master keys for DSRC-EFC, CCC, and LAC are generated and stored by the TSP at start-up and
any time it is deemed necessary by the TSP or the interoperability management. DSRC master keys are
associated to one or more values of the EFC-Context Mark, CCC-Context Mark, or LAC-Context Mark
respectively as speci fied in Table 25.
Table 25 — Overview of DSRC keys
Resulting
DSRC
AID
Identi ied by
f
Applicable
standard
Key usage KeyType authentication
code
1 EFC_ContextMark EN 15509:2014 Authentication key1 ... 0 MAC_TC

+ KeyRef Authentication key4
1 EFC_ContextMark EN 15509:2014 Authentication key5 ... 0 MAC_TSP
1 EFC_ContextMark EN 15509:2014 Access Key 1 AC _CR
20 CCC_ContextMark ISO 12813:2015 Authentication key1 ... 2 MAC_TC
20 CCC_ContextMark ISO 12813:2015 Authentication key5 ... 2 MAC_TSP
20 CCC_ContextMark ISO 12813:2015 Access Key 3 AC _CR
21 LAC_ContextMark ISO 13141:2015 Access Key 4 AC _CR
21 LAC_ContextMark ISO 13141:2015 LAC _Authentication- n.a. MAC_TC
+ Key_TC
keyRefMAC_TC_
LAC
The derived DSRC keys shall be transmitted to and stored in the OBE.
The OBE may store additional DSRC keys for purposes beyond the mentioned DSRC applications:
— for writing of the EFC or CCC attributes which are marked as read-only. This is often referred to as
personalization;
— for other DSRC applications hosted by the OBE like ERI/AVI.
Only the DSRC master keys are required to check the value of MAC_TC and the master keys to calculate
the AC_CR are needed by the TC. Such master keys for DSRC EFC, CCC, and LAC shall be transmitted to
the TC in accordance with 9.3.2 .1.
DSRC master keys can be archived only if there is no OBE with a corresponding context mark active in
the EFC system anymore.
DSRC master keys can only be destroyed if all data related to OBE with a corresponding context mark
have been deleted.

39
ISO/TS 192 99: 2 015(E)
9.3 .3 .3 MAC keys
MAC master keys are generated and stored by the TSP. Derived MAC keys are transmitted to and
s tored in the OBE .
MAC master keys shall be transmitted to the TC in accordance with 9. 3 . 2 .1 .

In case the MAC of a ChargeReport should provide the same evidence compared to a signature based
on a PKI (e.g. may be required by the secure monitoring concept), other requirements for MAC master
key management will apply. For example, in such case, a MAC master key should be provided in a
cryptographic module with limited functions (MAC veri fication with OK/NOK output only, no access to
the key itself) to the TC.
9.3 .4 Key storage and protection
9.3 .4.1 Master keys
DSRC master keys and MAC master keys stored and used in the TC and TSP back end and in RSE shall be
protected agains t unauthorized access .
DSRC master keys and MAC master keys, when stored for non-operative purposes (e.g. back-up or offline
storage) or transferred internally in the system, shall be encrypted with an algorithm considered
strong enough. The corresponding encryption key shall be stored in the same manner as described for
the DSRC master keys and access to it shall be protected at least by a passphrase.
When stored in the clear and used for cryptographic operations, DSRC master keys and MAC master
keys shall be kept in a secure environment and implemented by either of the following:
— a dedicated cryptographic HW module (e.g. a SAM);
— de fined procedures, hardware provisions, and software security functions to address the threats in
the speci fic environment as evaluated by the toll charger with reasonable measures.
Either solution shall ful fil the following security requirements and objectives:
a) manage secure key distribution, i.e. reception of encrypted keys and subsequent decryption for
operational storage;
b) protect the cryptographic functions from unauthorized operation or use, including physical
protection against unauthorized operation and/or deactivation to prevent unauthorized operation;
c) prevent unauthorized disclosure of the keys, including physical protection against disclosure
and/or deletion to prevent disclosure (e.g. storage in volatile memory);
d) prevent use of keys with prohibited algorithms (e.g. prevent that encryption keys are used for
authentication);
e) prevent unauthorized modi fication of the cryptographic algorithms, including unauthorized
modi fication, substitution, insertion, and deletion of keys
f) provide indications about the operational state of the environment;
g) ensure that the implemented module solution performs properly when operating in an approved
mode of operation;
h) detect errors in the operation of the implemented module solution and to prevent the compromise
of keys resulting from these errors.
A certi fied cryptographic hardware module for storage of DSRC master keys and execution of key
functions is recommended.
40
ISO/TS 192 99:2 015(E)
9.3 .4.2 OBE keys
The OBE shall only store derived keys.
9.3 .5 Session keys
Session keys used in the TC and TSP back end and in RSE shall be protected against unauthorized access
during their lifetime. Session keys that are no more used shall be destroyed securely (e.g. overwriting
of any copy of the key in memory and other data storages).

41
ISO/TS 192 99: 2 015(E)
Annex A
(normative)
Security pro iles f
A.1 General
The pro file de finition uses the following pattern:

Risk assessment: Simpli fied risk assessment description.
Requirement pro file: De fines the mandatory and recommended requirements to be ful filled for
pro file compliance.
In order to claim conformance with a pro file, all listed mandatory requirements shall be ful filled.
A.2 Communication interface pro iles f
A.2.1 DSRC pro ile f
The DSRC pro file includes the requirements for the charging (EFC), the compliance check (CCC), and the
localization (L AC ) transactions.
Risk assessment: OBE charging transaction data received by the RSE contains all relevant
information for the payment claim. Read out of OBE data by a fake RSE is
possible without service user notice. This requires the authentication of the
OBE access by the RSE.
Manipulation of such data and/or replay by a fake OBE is in principle
simple even if technically difficult. This requires authentication
mechanisms for OBE and RSE. Proof of message integrity is also required.
A service user may deny a certain road use (charging or CCC event).
A faked LAC event can be used to prove, deny, or claim a cheaper road use.
Faking or denying unprotected data is simple. Non-repudiation with proof
of origin is required.
Communication eavesdropping is technically difficult and requires either

access or a close location to the OBE or RSE and does not provide an
attacker with substantial new data of the service user, vehicle, or RSE .
Con fidentiality is not required.
Requirement pro file: Mandatory: RQ.IF.11 + RQ.IF.12 + RQ.IF.13 + RQ.IF.20 + RQ.IF.30
Recommended: -
A.2.2 TC to TSP pro iles f
The pro file covers the not-secured communication between TC and TSP for back office data exchange
according to ISO 12 855: 2015 .
42
ISO/TS 192 99:2 015(E)
Pro ile A f
Risk assessment: Communication eavesdropping and interception by third parties

on a non-protected communication channel is easy and most likely.
Modi fication of information as man in the middle and sending fake
messages are also serious threats. Protection of sensitive service user data
is also an issue. Message con fidentiality, integrity, and authenticity shall be
ensured.
The TSP or its service user may deny a toll declaration or billing detail.
Therefore, non-repudiation with proof of origin is required.
The back office interface shall be protected against replay attacks.

Recommended: RQ.IF.12 + RQ.IF.20
Pro ile B (extended pro ile A)
f f
Risk assessment: For a TSP, it is crucial that a TC receives

exception lists. For a TC, it is crucial that a TSP uses valid and up-to-date toll
context data. Therefore, this communication channel shall provide
non-repudiation with proof of delivery.
Requirement pro file: Mandatory: RQ.IF.02 + RQ.IF.10 + RQ.IF.11 + RQ.IF.13 + RQ.IF.14 + RQ.IF.30
Recommended: RQ.IF.12 + RQ.IF.20
A.2.3 Communication provider pro ile f
This pro file covers TC or TSP system internal interfaces using communication services of a third party.
This includes, but is not limited to, the use of a telecommunication provider for the following:
— RSE to TC back end communication;
— OBE to proxy/TSP back end communication;
— TC or TSP internal back end communication.
Communication protection according to this pro file can be used as proof for trustworthy data handling
by a TSP or TC.
Risk assessment: Standard communication channels offered by communication providers

can have some security mechanisms providing con fidentiality, integrity,
and authenticity against third party attacks. These possible security
measures do not protect against communication eavesdropping and
interception by insiders, e.g. personnel of the communication provider.
Communication eavesdropping and interception by third parties is possible,
but in most cases less likely. Protection of sensitive service user data is also
an issue.
The risk is high enough to require additional from the communication

provider independent, con fidentiality, integrity, and authenticity measures
for exchanged messages.
Requirement pro file: Mandatory: RQ.IF.02 + RQ.IF.10 + RQ.IF.11

Recommended: -

43
ISO/TS 192 99: 2 015(E)
A.2.4 ICC interface pro ile f
The ICC interface pro file includes the requirements for the reading account data and charging.
Risk as ses s ment: ICC reading account data and ICC charging transaction data received by
RSE through OBE contains all relevant information for the payment
claim. Read out of ICC data by a fake RSE and/or OBE is possible without
ser vice user notice. T his requires authentication of the RSE and/or OBE .
T his requires authentication mechanis ms for ICC and RSE and/or OBE .
Proof of message integrity is also required.

A user may deny a certain road use (charging). A faked ICC may be used
to deny road use or claim a cheaper road use. Faking or denying
unprotec ted data is s imple. Non-repudiation with pro of of origin i s
required.
Communication eavesdropping is technically difficult and requires either

acces s or a clos e lo cation to the ICC or OBE and does not provide an
attacker with substantial new data of the service user. Con fidentiality is
not required.

Recommended: -
A.3 Data storage pro iles f
A.3.1 OBE data storages pro ile f
This pro file considers an OBE in the service user environment, i.e. a personalized OBE mounted in a
vehicle.
Risk as ses s ment: An illegal manipulation of data stored in the OBE may result in lower
charge for the ser vice user and los s of income for TC and TSP or even an
interruption in the regis tration of ro ad us age. An unauthori zed read out
of data stored in the OBE can result in a privacy violation of the service user.
Requirement pro file: Mandatory: RQ.DS.01 + RQ.DS.02 + RQ.DS.05 + RQ.DS.07 + RQ.DS.06
if applicable (e.g. for keys)
Recommended: -
EXAMPLE 1 For an OBE mounted Inside of a vehicle, RQ.DS.02 is ful filled for the HMI. An existing CN or DSRC
interface requires additional access credentials covered by RQ.DS.01.
EXAMPLE 2 RQ.DS.02 + RQ.DS.05 + RQ.DS.06 + RQ.DS.07 can be guaranteed by a tamper evident OBE.
A.3.2 ICC data storage pro ile f
This pro file considers an ICC in the service user environment, i.e. an issued ICC inserted into an OBE.
Risk as ses s ment: Not allowed manipulation of data s tored in the ICC can res ult in lower
charge for the ser vice user and los s of income for TC or in an increase of
stored values without paying. Not authorized read out of data stored in the
ICC can result in a privacy violation to the service user.
44
ISO/TS 192 99:2 015(E)

Recommended: -
A.3.3 RSE data storage pro ile f
The pro file covers RSE at a publicly available location without any additional external protection
measure (e.g. surveillance camera) .
Risk assessment: An illegal manipulation of data stored in the RSE (before transmitted to
the TSPs back end) may result in loss of income for TC and TSP. An
unauthorized read out of data stored in the RSE (e.g. enforcement data)
can result in a privacy violation to the service user and/or loss of
reputation of the TC. Changing of the data originator identity (i.e. OBE
identity) can result in charging a wrong service user. Access to the
communication keys can allow the faking of OBE or the personalization
of OBE without a TSP contract.

Recommended: -
A.3.4 Back end data storage pro ile f
This pro file is given for completeness only. A detailed method for the evaluation of security requirements
can be found in ISO/IEC 27001. The requirement pro file below does not apply to all kind of data stored
in a back end, but each requirement will apply to a certain kinds of data.
Requirement pro file: Mandatory: RQ.DS.01 + RQ.DS.02 + RQ.DS.03 + RQ.DS.05 + RQ.DS.07 +
RQ.DS.08 + RQ.DS.06 if applicable (e.g. for keys)
Recommended: -

45
ISO/TS 192 99: 2 015(E)
Annex B
(normative)
Implementation conformance statement (ICS) proforma
B.1 Guidance for completing the ICS proforma
B.1.1 Purposes and structure
The purpose of this ICS proforma is to provide a mechanism whereby a supplier of an implementation or
an actor taking a role according to the requirements de fined in this Technical Speci fication can provide
information about the implementation in a standardized manner.
The ICS proforma is subdivided into subclauses for the following categories of information:
— guidance for completing the ICS proforma;

— identi fication of the implementation;
— global statement of conformance;
— ICS proforma tables.
B.1.2 Abbreviations and conventions
The ICS proforma contained in this Annex comprises information in tabular form in accordance with
the guidelines presented in ISO/IEC 9646-7.
— Item column: The item column contains a number which identi fies the item in the table.
— Item description column: The item description column describes in free text each respective
item (e.g. parameters, timers, etc.). It implicitly means “is <item description> supported by the
implementation? ”.
— Status column: The following notations de fined in ISO/IEC 9646-7 are used for the status column.
m mandatory - The capability is required to be supported.

o optional - The capability may be supported or not.
n/a not applicable - In the given context, it is impossible to use the capability.
x prohibited (excluded) - There is a requirement not to use this capability in the
given context.
o.i quali fied optional - For mutually exclusive or selectable options from a set. “i” is an
integer which identi fies a unique group of related optional items and the logic of
their selection which is de fined immediately following the table.
c.i conditional - The requirement on the capability (“m”, “o”, “x” or “n/a”) depends on
the support of other optional or conditional items. “i” is an integer identifying a
unique conditional status expression which is de fined immediately following the
table.
46
ISO/TS 192 99:2 015(E)
— Reference column: The reference column makes reference to this Technical Speci ficaton except
where explicitly stated otherwise.
— Support column: The support column shall be filled in by the supplier of the implementation. The
following common notations de fined in ISO/IEC 9646-7 are used for the support column:
Y or y supported by the implementation.
N or n not supported by the implementation.
N/A, n/a or - no answer required (allowed only if the status is n/a directly or after evaluation
of a conditional status) .
NOTE As stated in ISO/IEC 9646-7, support for a received PDU requires the ability to parse all valid
parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is non-conformant.
Support for a parameter on a PDU means that the semantics of that parameter are supported.
— Values allowed column: The values allowed column contains the type, the list, the range, or the
length of values allowed. The following notations are used.
range of values: < min value > .. < max value >
EXAMPLE 1: 5 . . 20
list of values: < value1 > , < value2 > , ..., < valueN >
EXAMPLE 1: 2 , 4, 6, 8, 9
EXAMPLE 2: ‘1101’B, ‘1011’B, ‘1111’B
EXAMPLE 3: ‘0A’H, ‘3 4’H, ‘2 F’H
list of named values: < name1 > (<val1 > ), < name2 > (<val2 > ), ..., < nameN > (<valN > )
EXAMPLE 1: rej ect(1) , accept(2)
length: size (<min size > .. < max size > )

EXAMPLE 1: size (1 . . 8)
— Values supported column: The values supported column shall be filled in by the supplier of the
implementation. In this column, the values or the ranges of values supported by the implementation
shall be indicated.
— References to items: For each possible item answer (answer in the support column) within the ICS
proforma, a unique reference exists used, for example, in the conditional expressions. It is de fined as
the table identi fier followed by a solidus character “/” and followed by the item number in the table.
If there is more than one support column in a table, the columns are discriminated by letters (a, b,
etc.), respectively.
EXAMPLE 1 B.5/4 is the reference to the answer of item 4 in Table B . 5 .
EXAMPLE 2 B.6/3b is the reference to the second answer (i.e. in the second support column) of item 3 in
Table B .6 .

47
ISO/TS 192 99: 2 015(E)
— P re re qu i s i te l i ne .
A prerequisite line takes the form Prerequisite: < predicate > .

A p re re qu i s i te l i ne a fte r a C l au s e o r tab le ti tle i nd i c ate s th at the who l e cl au s e o r the who le t ab le i s
no t re qu i re d to b e co mp le te d i f the p re d i c ate i s FA L S E .
B.1.3 Instructions for completing the ICS proforma
T he s up p l ie r o f the i mp le me nt atio n or an ac to r t a ki n g a ro le shall c o mp le te the IC S p ro fo r m a in e ac h
o f the s p ac e s p ro vi de d . In p a r tic u l a r, an e x p l ic i t a n s we r shal l be e nte re d , in e ach o f the s up p o r t or
supported column boxes provided using the notation described previously.

Additional comments may be provided in the space at the bottom of the tables or separately, if necessary.
B.2 Identi ication of the implementation f
B.2 .1 General
Identi fication of the Implementation Under Test (IUT) and the system in which it resides [the System
Under Test (SUT)] shall be filled in so as to provide as much detail as possible regarding version
numbers and con figuration options.
The supplier information and actor information shall both be filled in if they are different.
A p ers on who can a n s we r que r ie s re ga rd i n g i n fo r m ati o n s up p l i e d in the IC S shall be n a me d as the
co n tac t p e r s o n .
B.2 .2 Date of the statement
……………………………………………………………………………………………………………………………………… ……… . .
B.2.3 Implementation Under Test (IUT) identi ication f
I U T n a me :
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
I U T ve r s io n :
……………………………………………………………………………………………………………………………………… ……… . .
B.2.4 System Under Test (SUT) identi ication f
S U T n a me :
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
Hardware con figuration:

……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
Operating system:
48
ISO/TS 192 99:2 015(E)
……………………………………………………………………………………………………………………………………… ……… . .
B.2 .5 Supplier
Name:
……………………………………………………………………………………………………………………………………… ……… . .
Addres s:
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
Telephone number:
……………………………………………………………………………………………………………………………………… ……… . .
Facs imi le number:
……………………………………………………………………………………………………………………………………… ……… . .
E-mail addres s:
……………………………………………………………………………………………………………………………………… ……… . .
Additional information:
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
B.2 .6 Actor (if different from supplier)
Name:
……………………………………………………………………………………………………………………………………… ……… . .
Addres s:
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
Telephone number:
……………………………………………………………………………………………………………………………………… ……… . .
Facs imi le number:
……………………………………………………………………………………………………………………………………… ……… . .
E-mail addres s:
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .

49
ISO/TS 192 99: 2 015(E)
……………………………………………………………………………………………………………………………………… ……… . .
B.2 .7 ICS contact person
(A person to contact if there are any queries concerning the content of the ICS)
Name:
……………………………………………………………………………………………………………………………………… ……… . .
Telephone numb er:
……………………………………………………………………………………………………………………………………… ……… . .
Facs imi le number:
……………………………………………………………………………………………………………………………………… ……… . .
E-mai l addres s:
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
……………………………………………………………………………………………………………………………………… ……… . .
B.3 Identi ication of the standard f
This ICS proforma applies to the following Technical Speci fication:

— I SO/TS 192 9 9 Electronic fee collection — Security framework.
B.4 Global statement of conformance
Are all mandatory capabilities implemented? (Yes/No) ……………

Answering “No” to this question indicates non-conformance to this Technical Speci fication. Non-
supported mandatory capabilities are to be identi fied in the ICS, with an explanation of why the
implementation is non- conforming on p ages attached to the IC S proforma.
B.5 Roles
Table B.1 — Roles
Item Implemented role Reference Status Support
(Y/N)
1 Tol l charger 5.2 o.1–1
2 Tol l ser vice provider 5.2 o.1–1
3 Interoperability management 5.2 o.1–1
o.1-1: It is mandatory to support at least one of these options.
B.6 Trust model
50
ISO/TS 192 99:2 015(E)
Table B.2 — Trust model basics
Item Supported functionality Reference Status Support
(Y/N)
1 Support for a trust model 5 .4.1 m
2 Use of ISO/IEC 9594-8 certi ficates 5.3.2 c. 2–1
3 Use of a hierarchical trust model 5.2 o. 2–1

(using a TTP)
4 Use of a peer-to-peer trus t model 5.2 o. 2–1
5 Root CA is performed by IM 5.2 c. 2–2
6 Root CA is performed by external 5.2 c. 2 –3

TTP
7 Use of trus t model for all 5 . 3 .4 c. 2– 4

electronic data exchange
channels between IM and TC/TSP
o.2-1: It is mandatory to support at least one of these options.
c. 2-1: IF Table B . 2/1 THEN m ELSE n/a.
c. 2-2: IF Table B .1/3 and Table B. 2/3 THEN o ELSE n/a.
c.2-3: IF (Table B .1/1 or Table B.1/2) and Table B . 2/3 and not Table B . 2/4 THEN m ELSE n/a.
c.2-4: IF Table B .1/3 THEN m ELSE n/a.
Table B. 3 — Trust relation setup
(Y/N)
1 Importing CA root certi ficate from 5 .4.1 c. 3 –1

a TTP according to method 3 of
ISO/IEC 11770 -3: 201 5 , C lause 1 2 or
an equivalent
2 - downloading the certi ficate from 5 .4.1 o. 3 –1

a recognized and secure website
3 - retrieving it per courier, if it is 5 .4.1 o. 3 –1

supported by the TTP
4 - receiving it via signed e-mail 5 .4.1 o. 3 –1
5 - other method, please describe 5 .4.1 o. 3 –1
6 Exchanging root certi ficates 5 .4.1 c. 3 –2

according to method 1 or 2 of
ISO/IEC 11770 -3: 201 5 , C lause 1 2 or
an
equivalent
7 - using mechanism 1 of 5 .4.1 o. 3 –2

ISO/IEC 11770 -3: 201 5 , C lause 1 2 or
an
equivalent
8 - using mechanism 2 of 5 .4.1 o. 3 –2

ISO/IEC 11770 -3: 201 5 , C lause 1 2 or
an
equivalent

51
ISO/TS 192 99: 2 015(E)
Table B.3 (continued)
(Y/N)
9 Key veri fication using a fingerprint 5 .4.1 c. 3 –3

based on the algorithms de fined in
I S O 1 2 8 5 5 : 2 01 5
o. 3 -1 : I F Table B . 2 /3 THEN it is mandatory to support at least one of these options.

o. 3 -2 : I F Table B . 2 /4 THEN it is mandatory to support at least one of these options.
c. 3 -1 : I F Table B . 2/3 TH E N m E LSE n/a.
Table B.4 — Trust relation renewal and revocation
(Y/N)
1 Length of private key of root 5 .4. 2 m

certi ficate sufficient for duration
of us e
2 Validity of root certi ficate 5 .4. 2 m

accordi ng to the length of the
private key
3 Automatic termi nation of trus t 5 .4. 2 m
relation after expi ration date of
root certi ficate
4 Replacement of a root certi ficate 5 .4. 2 m
accordi ng to Table B . 3
5 Replacement of derived s ub - C A 5 .4. 2 m

or end-entity certi ficates
accordi ng to Table B . 5
6 Supp or t for revo cation of ro ot 5 .4. 2 m

certi ficates
7 Automatic termi nation of trus t 5 .4. 2 m
relation after revo cation of ro ot
certi ficate
8 Use of Certi ficate Revocation List 5 .4. 2 m
as de fined in ISO/IEC 9594-8
9 Signi ng of revo cation mes s age for 5 .4. 2 m
a root certi ficate
10 Veri fication of the signature of 5 .4. 2 m
revocation mes s age for a ro ot
certi ficate
52
ISO/TS 192 99:2 015(E)
Table B.5 — Issuing and revocation of sub-CA and end-entity certi icates f
(Y/N)
1 Private key of root certi ficate 5 .4. 3 m

only used for signing end-entity
or sub CA certi ficates
2 Extended Key Usage extensions 5 .4. 3 m
accordi ng to I S O/I E C 959 4 - 8 us ed
3 Certi ficate validation process can 5 .4. 3 m

handle at least four certi ficate
level s
4 End-entity certi ficate for securing 5 .4. 3 m

communication channel s
5 End-entity certi ficate for message 5 .4. 3 m

s igni ng
6 End-entity certi ficate for 5 .4. 3 m

message/key encryption
7 Use of Certi ficate Revocation List 5 .4. 3 m
as de fined in ISO/IEC 9594-8
8 Signi ng of revo cation mes s age for 5 .4. 3 m
a root certi ficate
9 Veri fication of the signature of 5 .4. 3 m
revo cation mes s age for a ro ot
certi ficate
Table B.6 — Certi icate and certi icate revocation list pro ile and format
f f f
(Y/N)
1 ISO/IEC 9594-8 certi ficates 5 .4.4 m

vers ion 3 i s s ued according to
I S O/I E C 9 59 4 - 8 with the up date
speci fied in RFC 6818
2 I S O/I E C 9 59 4 - 8 C RL vers ion 2 5 .4.4 m
i s s ued accordi ng to
I S O/I E C 9 59 4 - 8 with the up date
speci fied in RFC 6818
3 All certi ficates DER encoded and 5 .4.4 m
Base64 encoded (PEM certi ficate)
4 Al l C RL DE R enco ded and B as e6 4 5 .4.4 m
encoded (PEM CRL)
5 Key veri fication using a 5 .4.4 m
fingerprint based on the
algorithms de fined in
I S O 1 2 85 5 : 2 01 5

53
ISO/TS 192 99: 2 015(E)
Table B.7 — Certi icate and certi icate revocation list pro ile and format
f f f
(Y/N)
1 Agreement on the u se of critical 5 .4. 5 m

certi ficate extensions
2 All certi ficate extensions de fined 5 .4. 5 m
either as critical or non- critical
3 Rej ec tion of u nrecogn i zed critical 5 .4. 5 m

4 Rejection of critical certi ficate 5 .4. 5 m
extens ions with i n formation
u nable to pro ces s
5 I gnori ng u nrecogni zed non- critical 5 .4. 5 m

6 P ro ces s re cogni zed non- critical 5 .4. 5 m
7 Only use key usage and basic 5 .4. 5 m
constraints as critical certi ficate
extensions in a root certi ficate
8 Only use key usage with allowed 5 .4. 5 m
values as critical certi ficate
extensions in an end-entity
certi ficate
9 Only use extended key usage with 5 .4. 5 c.7–1
OI D for the TC to TSP b ack end
i nterface
10 Only use Extended Key Usage 5 .4. 5 c.7–2

with OI D for the TS P Front E nd
to B ack E nd interface
11 Only use allowed non-critical 5 .4. 5 m

certi ficate extensions in a root
certi ficate
12 Only use allowed non-critical 5 .4. 5 m
certi ficate extensions in an
end-entity certi ficate
c.7.1 : I F Table Table B .1/1 or Table B .1/2 TH E N m E LSE n. a.
c.7.1 : I F Table B .1/2 TH E N m E LSE n. a.
B.7 Pro iles f
Table B.8 — Pro iles f
Item Requirement Reference Status Support
(Y/N)
1 DSRC pro file A . 2 .1 o
2 TC to TSP pro file A A. 2 . 2 o
3 TC to TSP pro file B A. 2 . 2 o
54
ISO/TS 192 99:2 015(E)
(Y/N)
4 C ommunication A. 2 . 3 o
provider pro file
5 ICC interface pro file A . 2 .4 o
6 OBE data storage pro file A . 3 .1 o
7 ICC data storage pro file A. 3 . 2 o
8 RSE data storage pro file A. 3 . 3 o
9 B ack end data s torage A . 3 .4 o

pro file
B.8 Requirements
Table B.9 — Information system security requirements
(Y/N)
1 RQ.ISMS.01 6.2 m
2 RQ.ISMS.02 6.2 o
Table B.10 — General interface requirements
(Y/N)
1 RQ. I F. 02 6.3 c.10 –1
2 RQ. I F.10 6.3 c.10 –1
3 RQ. I F.11 6.3 c.10 –2
4 RQ. I F.1 2 6.3 c.10 –3
5 RQ. I F.1 3 6.3 c.10 – 4
6 RQ. I F.14 6.3 c.10 –5
7 RQ. I F. 2 0 6.3 c.10 –3
8 RQ. I F. 3 0 6.3 c.10 – 4
9 RQ. I F. 3 1 6.3 o
10 RQ. I F. 3 2 6.3 o
c.10 -1 : I F Table B . 8/2 or Table B . 8/3 or Table B . 8/4 TH E N m E LSE o .
c.10 -2 : I F Table B . 8/1 or Table B . 8/2 or Table B . 8/3 or Table B . 8/4 TH E N m E LSE o.
c.10 -3 : I F Table B . 8/1 TH E N m E LSE o .
c.10 - 4: I F Table B . 8/2 or Table B . 8/3 TH E N m E LSE o .
c.10 -5 : I F Table B . 8/3 TH E N m E LSE o .

55
ISO/TS 192 99: 2 015(E)
Table B.11 — Data Storage requirements
(Y/N)
1 RQ. D S . 01 6 .4 c.11–1
2 RQ. D S . 02 6 .4 c.11–1
3 RQ. D S . 03 6 .4 c.11–3
4 RQ. D S . 0 5 6 .4 c.11–1
5 RQ. D S . 0 6 6 .4 c.11–2
6 RQ. D S . 07 6 .4 c.11–1
7 RQ. D S . 0 8 6 .4 c.11–3
c.11-1 : I F Table B . 8/5 or Table B . 8/6 or Table B . 8/7 TH E N m E LSE o .
c.11-2 : I F Table B . 8/5 or Table B . 8/6 TH E N m E LSE o .
c.11-3 : Table B . 8/7 TH E N m E LSE o.
Table B.12 — Toll charger requirements
(Y/N)
1 RQ.TC . 01 6.5 c.1 2 –1
2 RQ.TC . 02 6.5 c.1 2 –1
3 RQ.TC . 03 6.5 c.1 2 –1
4 RQ.TC . 0 4 6.5 c.1 2 –1
5 RQ.TC . 0 5 6.5 c.1 2 –1
6 RQ.TC . 0 6 6.5 c.1 2 –1
7 RQ.TC . 07 6.5 c.1 2 –1
8 RQ.TC . 0 8 6.5 c.1 2 –1
9 RQ.TC .10 6.5 c.1 2 –1
10 RQ.TC .1 2 6.5 c.1 2 –1
11 RQ.TC .1 3 6.5 c.1 2 –1
12 RQ.TC . 2 0 6.5 c.1 2 –1
13 RQ.TC . 2 1 6.5 c.1 2 –1
14 RQ.TC . 2 2 6.5 c.1 2 –1
15 RQ.TC . 2 3 6.5 c.1 2 –1
16 RQ.TC . 2 4 6.5 c.1 2 –1
17 RQ.TC . 2 5 6.5 c.1 2 –1
18 RQ.TC . 3 0 6.5 c.1 2 –1
19 RQ.TC . 3 1 6.5 c.1 2 –1
20 RQ.TC . 3 2 6.5 c.1 2 –1
21 RQ.TC . 5 0 6.5 c.1 2 –1
22 RQ.TC . 51 6.5 c.1 2 –1
23 RQ.TC .70 6.5 c.1 2 –1
24 RQ.TC .71 6.5 c.1 2 –1
25 RQ.TC .9 0 6.5 c.1 2 –1
56
ISO/TS 192 99:2 015(E)
(Y/N)
26 RQ.TC .91 6.5 c.1 2 –1
27 RQ.TC .9 2 6.5 c.1 2 –1
28 RQ.TC .93 6.5 c.1 2 –1
29 RQ.TC .9 4 6.5 c.1 2 –1
30 RQ.TC .9 5 6.5 c.1 2 –1
31 RQ.TC .9 6 6.5 c.1 2 –1
32 RQ.TC .9 7 6.5 c.1 2 –1
33 RQ.TC .9 8 6.5 c.1 2 –1
34 RQ.TC .9 9 6.5 c.1 2 –1
c.1 2 -1 : I F Table B .1/1 TH E N o E LSE n/a.
Table B.13 — Toll service provider requirements
(Y/N)
1 RQ.TS P. 01 6.6 c.1 3 –1
2 RQ.TS P. 03 6.6 c.1 3 –1
3 RQ.TS P. 0 4 6.6 c.1 3 –1
4 RQ.TS P. 0 5 6.6 c.1 3 –1
5 RQ.TS P. 0 6 6.6 c.1 3 –1
6 RQ.TS P. 07 6.6 c.1 3 –1
7 RQ.TS P. 0 8 6.6 c.1 3 –1
8 RQ.TS P. 0 9 6.6 c.1 3 –1
9 RQ.TS P.10 6.6 c.1 3 –1
10 RQ.TS P.11 6.6 c.1 3 –1
11 RQ.TS P.1 2 6.6 c.1 3 –1
12 RQ.TS P.1 3 6.6 c.1 3 –1
13 RQ.TS P.14 6.6 c.1 3 –1
14 RQ.TS P.16 6.6 c.1 3 –1
15 RQ.TS P.17 6.6 c.1 3 –1
16 RQ.TS P.18 6.6 c.1 3 –1
17 RQ.TS P.19 6.6 c.1 3 –1
18 RQ.TS P. 2 0 6.6 c.1 3 –1
19 RQ.TS P. 2 1 6.6 c.1 3 –1
20 RQ.TS P.40 6.6 c.1 3 –1
21 RQ.TS P.41 6.6 c.1 3 –1
22 RQ.TS P.42 6.6 c.1 3 –1
23 RQ.TS P. 5 0 6.6 c.1 3 –1
24 RQ.TS P. 51 6.6 c.1 3 –1
25 RQ.TS P. 5 3 6.6 c.1 3 –1

57
ISO/TS 192 99: 2 015(E)
(Y/N)
26 RQ.TSP. 5 5 6.6 c.1 3 –1
27 RQ.TSP. 5 6 6.6 c.1 3 –1
28 RQ.TS P. 5 7 6.6 c.1 3 –1
29 RQ.TSP. 5 8 6.6 c.1 3 –1
30 RQ.TSP. 59 6.6 c.1 3 –1
31 RQ.TSP. 60 6.6 c.1 3 –1
32 RQ.TS P. 62 6.6 c.1 3 –1
33 RQ.TSP.70 6.6 c.1 3 –1
34 RQ.TSP.71 6.6 c.1 3 –1
35 RQ.TSP. 8 0 6.6 c.1 3 –1
36 RQ.TSP. 81 6.6 c.1 3 –1
37 RQ.TSP. 82 6.6 c.1 3 –1
38 RQ.TSP. 8 9 6.6 c.1 3 –1
39 RQ.TSP.9 0 6.6 c.1 3 –1
40 RQ.TSP.91 6.6 c.1 3 –1
41 RQ.TS P.92 6.6 c.1 3 –1
42 RQ.TS P.9 6 6.6 c.1 3 –1
43 RQ.TSP.9 7 6.6 c.1 3 –1
c.1 3 -1 : I F Table B .1/2 TH E N o E LSE n/a.
Table B.14 — Interoperability Management requirements
(Y/N)
1 RQ. I M . 01 6.8 c.14 –1
2 RQ. I M . 0 2 6.8 c.14 –1
c.14 -1 : I F Table B .1/3 TH E N o E LSE n/a.
B.9 Security measures
Table B.15 — General security measures
(Y/N)
1 S M .101 7. 2 c.1 5 –1
2 S M .10 2 7. 2 c.1 5 –1
3 S M .10 3 7. 2 c.1 5 –1
4 S M .10 4 7. 2 c.1 5 –1
5 S M .10 5 7. 2 c.1 5 –1
6 S M .10 6 7. 2 c.1 5 –1
7 S M .10 7 7. 2 c.1 5 –1
58
ISO/TS 192 99:2 015(E)
c.15-1: IF any requirement listed in Tab le 1 1 for this security measure is selected in Tab le B .9 , Tab le B . 1 0 ,
Tab le B . 1 1 , Tab le B .1 2 , Tab le B .1 3 , o r Tab le B .14 , T H E N m E L S E n/a .
Table B.16 — General interface security measures
Item Measure Reference Status Support
(Y/N)
1 SM200 7. 3 . 1 c . 1 6 –1
2 SM201 7. 3 . 1 c . 1 6 –1
3 SM202 7. 3 . 1 c . 1 6 –1
4 SM203 7. 3 . 1 c . 1 6 –1
5 SM204 7. 3 . 1 c . 1 6 –1
6 SM205 7. 3 . 1 c . 1 6 –1
7 SM207 7. 3 . 1 c . 1 6 –1
8 SM208 7. 3 . 1 c . 1 6 –1
c.16-1: IF any requirement listed in Tab le 1 2 for this security measure is selected in Tab le B .9 , Tab le B .1 0 ,
Tab l e B . 1 1 , Tab l e B . 1 2 , Tab l e B . 1 3 , o r Tab le B . 14 , T H E N m E L S E n/a .
Table B.17 — DSRC-EFC interface security measures
(Y/N)
1 SM210 7. 3 . 2 c . 1 7–1
2 SM211 7. 3 . 2 c . 1 7–1
3 SM212 7. 3 . 2 c . 1 7–1
4 SM213 7. 3 . 2 c . 1 7–1
5 SM214 7. 3 . 2 c . 1 7–1
6 SM215 7. 3 . 2 c . 1 7–1
c.17-1: IF any requirement listed in Tab l e 1 3 for this security measure is selected in Tab le B .9 , Tab le B . 1 0 ,
Tab le B .1 1 , Tab le B .1 2 , Tab le B .1 3 , o r Tab le B .14 , T H E N m E L S E n/a .
Table B.18 — CCC interface security measures
(Y/N)
1 SM220 7. 3 . 3 c . 1 8 –1
2 SM221 7. 3 . 3 c . 1 8 –1
3 SM222 7. 3 . 3 c . 1 8 –1
4 SM223 7. 3 . 3 c . 1 8 –1
c.18-1: IF any requirement listed in Tab le 14 for this security measure is selected in Tab le B .9 , Tab le B . 1 0 ,
Table B.19 — LAC interface security measures
(Y/N)
1 SM230 7. 3 . 4 c . 19 –1
59
ISO/TS 192 99: 2 015(E)
(Y/N)
2 SM231 7. 3 . 4 c . 1 9 –1
Tab le B . 1 1 , Tab le B . 1 2 , Tab l e B . 1 3 , o r Tab le B . 14 , T H E N m E L S E n/a .
Table B.20 — Front end to TSP back end interface
(Y/N)
1 SM240 7. 3 . 5 c . 2 0 –1
2 SM241 7. 3 . 5 c . 2 0 –1
c.20-1: IF any requirement listed in Tab le 1 6 for this security measure is selected in Tab le B .9, Tab le B .1 0 ,
Tab le B . 1 1 , Tab le B . 1 2 , Tab le B .1 3 , o r Tab le B . 14 , T H E N m E L S E n/a .
Table B.21 — TC to TSP interface security measures
(Y/N)
1 SM250 7. 3 . 6 c . 2 1 –1
2 SM251 7. 3 . 6 c . 2 1 –1
3 SM252 7. 3 . 6 c . 2 1 –1
4 SM253 7. 3 . 6 c . 2 1 –1
5 SM254 7. 3 . 6 c . 2 1 –1
6 SM255 7. 3 . 6 c . 2 1 –1
7 SM256 7. 3 . 6 c . 2 1 –1
8 SM257 7. 3 . 6 c . 2 1 –1
9 SM258 7. 3 . 6 c . 2 1 –1
10 SM259 7. 3 . 6 c . 2 1 –1
11 SM260 7. 3 . 6 c . 2 1 –1
12 SM261 7. 3 . 6 c . 2 1 –1
13 SM262 7. 3 . 6 c . 2 1 –1
14 SM263 7. 3 . 6 c . 2 1 –1
15 SM264 7. 3 . 6 c . 2 1 –1
16 SM265 7. 3 . 6 c . 2 1 –1
17 SM266 7. 3 . 6 c . 2 1 –1
c.21-1: IF any requirement listed in Tab le 17 for this security measure is selected in Tab le B .9 , Tab le B .1 0 ,
Table B.22 — End-to-end security measures
(Y/N)
1 SM310 7. 4 c . 2 2 –1
60
ISO/TS 192 99:2 015(E)
(Y/N)
2 SM311 7. 4 c . 2 2 –1
3 SM312 7. 4 c . 2 2 –1
4 SM313 7. 4 c . 2 2 –1
5 SM314 7. 4 c . 2 2 –1
6 SM315 7. 4 c . 2 2 –1
7 SM316 7. 4 c . 2 2 –1
8 SM317 7. 4 c . 2 2 –1
9 SM318 7. 4 c . 2 2 –1
10 SM319 7. 4 c . 2 2 –1
11 SM320 7. 4 c . 2 2 –1
12 SM322 7. 4 c . 2 2 –1
13 SM323 7. 4 c . 2 2 –1
14 SM324 7. 4 c . 2 2 –1
15 SM330 7. 4 c . 2 2 –1
c.22-1: IF any requirement listed in Tab le 19 for this security measure is selected in Tab le B .9, Tab le B . 1 0 ,
Table B.23 — Front end/OBE interface security measures
(Y/N)
1 SM410 7. 5 . 1 c . 2 3 –1
2 SM411 7. 5 . 1 c . 2 3 –1
3 SM412 7. 5 . 1 c . 2 3 –1
4 SM413 7. 5 . 1 c . 2 3 –1
5 SM414 7. 5 . 1 c . 2 3 –1
6 SM415 7. 5 . 1 c . 2 3 –1
7 SM416 7. 5 . 1 c . 2 3 –1
8 SM417 7. 5 . 1 c . 2 3 –1
9 SM418 7. 5 . 1 c . 2 3 –1
10 SM419 7. 5 . 1 c . 2 3 –1
c.23-1: IF any requirement listed in Tab le 2 0 for this security measure is selected in Tab le B .9 , Tab l e B . 1 0 ,
Table B.2 4 — TSP back end security measures
(Y/N)
1 SM420 7. 5 . 2 c . 2 4 –1
2 SM421 7. 5 . 2 c . 2 4 –1
3 SM422 7. 5 . 2 c . 2 4 –1
61
ISO/TS 192 99: 2 015(E)
Table B.2 4 (continued)
(Y/N)
4 SM423 7. 5 . 2 c . 2 4 –1
5 SM424 7. 5 . 2 c . 2 4 –1
6 SM425 7. 5 . 2 c . 2 4 –1
7 SM426 7. 5 . 2 c . 2 4 –1
Table B.25 — RSE security measures
(Y/N)
1 SM510 7. 6 . 1 c . 2 5 –1
2 SM511 7. 6 . 1 c . 2 5 –1
3 SM512 7. 6 . 1 c . 2 5 –1
4 SM513 7. 6 . 1 c . 2 5 –1
5 SM514 7. 6 . 1 c . 2 5 –1
6 SM515 7. 6 . 1 c . 2 5 –1
7 SM516 7. 6 . 2 c . 2 5 –1
Table B.26 — TC Back End security measures
(Y/N)
1 SM520 7. 6 . 2 c . 2 6 –1
2 SM521 7. 6 . 2 c . 2 6 –1
3 SM522 7. 6 . 2 c . 2 6 –1
4 SM523 7. 6 . 2 c . 2 6 –1
5 SM524 7. 6 . 2 c . 2 6 –1
6 SM525 7. 6 . 2 c . 2 6 –1
Table B.27 — Other TC security measures
(Y/N)
1 SM530 7. 6 . 1 c . 2 7–1
62
ISO/TS 192 99:2 015(E)
B.10 Speci ications for interoperable interfaces security

f
Table B.28 — Security speci ications for DSRC-EFC

f
Item Speci ication

f Reference Status Support
(Y/N)
1 Security level 1 OBE 8.2 .2 c. 2 8 –1

for E FC
2 Security level 1 RSE 8.2 .3 c. 2 8 –2

for E FC
3 RSE requests MAC_TC 8.2 .3 c. 2 8 –2
4 RSE requests MAC_TC 8.2 .3 c. 2 8 –2
5 Agre ement with 8.2 .3 C . 2 8 –3

TC/TSP on KeyRef
c. 2 8 -1 : I F Table B .1/2 TH E N m E LSE n/a.
c. 2 8 -2 : I F Table B .1/1 TH E N m E LSE n/a.
c. 2 8 -3 : I F Table B .1/1 or Table B .1/2 TH E N m E LSE n/a.

63
ISO/TS 192 99: 2 015(E)
Annex C
(informative)
Stakeholder objectives and generic requirements
C.1 General
For the motivation of this Technical Speci fication and for proper identi fication of the assets to be
protected and possible threats, it is necessary to identify the various security objectives and generic
requirements of the different stakeholders in an interoperability scheme.
Stakeholders are:
— toll chargers;
— toll service providers;
— service users;
— interoperability management entities like EETS member states or other third parties.
NOTE Either party may use subcontractors and/or delegate parts of their task/responsibility to third
parties. However, with regard to the relation with the other party, the full responsibility and liability is assumed
to remain completely with the subcontracting party. More speci fically, this Technical Speci fication assumes, in
this respect, for both a toll service provider and a toll charger that
1) subcontracting/delegation by one party shall have no consequences for the security measures required for
another party, and
2) nevertheless, a (subcontracting/delegating) party may require that another party will use dedicated
addresses and/or keys for speci fic purposes (messages).
EXAMPLE 1 A toll service provider may use a subcontractor for all his tasks up to issuing the declarations to
the toll chargers. In such a case, the toll service provider may require a toll charger to use different addresses and
keys for declaration related communication and charging (invoice) related communication.
EXAMPLE 2 A toll charger may (have to) entrust enforcement/compliance checking to a third party. In such a
case, the toll charger may require a toll service provider to deal with dedicated addresses and dedicated keys for
any communication related with these parties.
Security might not only be required by the stakeholder, but also imposed by regulations. This Clause
presents the security requirements imposed by legislation and regulation in one or more toll charging
environments.
The security framework speci fied in this Technical Speci fication is suitable to adhere to the following
legal requirements in a toll charging environment:
a) the toll service shall provide security features relative to the protection of data stored, handled,
and transferred between stakeholders in the toll service environment. The security features shall
protect the interests of toll service stakeholders from harm or damage caused by lack of availability,
con fidentiality, integrity, authentication, non-repudiation, and access protection of sensitive user
data appropriate to a multi-user toll service environment;
EXAMPLE 3 For Europe, see Reference [ 7 ], Annex III, Article 1.5.2.
b) the toll service shall provide means for toll chargers to easily and unambiguously detect whether
a vehicle circulating on their toll domain and allegedly using the toll service is actually equipped
with a validated and properly functioning OBE providing truthful information;
64
ISO/TS 192 99:2 015(E)
EXAMPLE 4 For Europe, see Reference [7 ], Annex III, article 2.1.1.4.

c) the toll service shall provide means to protect toll chargers, toll service providers , and toll service
users against fraud/abuse;
EXAMPLE 5 For Europe, see Reference [7 ], Annex III, article 1.5.1.
d) the toll service shall ful fil the requirements of legislation on the protection of individuals with
regard to the process ing of personal data and on the free movement of s uch data.
EXAMPLE 6 For Europe, see Reference [6 ] , article 2.7 and in Reference [ 7 ] , Annex III, article 2.2, and
Reference [9 ].
This list of regulatory requirements for the EETS may be supplemented, if applicable, with additional
regulatory requirements for other toll charging environments. Nevertheless, this security framework
is also s uitable for countries with less s tringent legal requirements .
C.2 Toll chargers
C.2 .1 Toll chargers and their main interests
A toll charger is a legal entity that charges toll for vehicles in a toll domain.
See I SO 17573 for details .
The main as set for a toll charger to be protected is its income.
The main security requirements for a toll charger to protect its assets are the following:
— prevention of loss of income due to incorrect toll declarations , high collection cos ts , and/or
irrecoverable debts;
— con fidentiality of commercial details;
— adherence to the regulatory security requirements in the toll charging environments he is
op erating i n .
A toll charger can operate in more than one toll charging environment. For Scandinavia, one may think,
e.g. on a local system, EasyGo, and the EETS.
C.2 .2 Security service requirements for a toll charger
Security requirements for a toll charger can be ful filled with the following security services:
a) non-repudiation services for data received from external entities particularly from toll service
providers (including acknowledgements);
NO TE T hese ser vices are needed in order to prevent los s es due to the denial of having sent charging
related data.
EXAMPLE Toll declarations, compliance checking data, blacklists, etc.

b) accountability of toll declarations (for autonomous toll charging environments).
In an autonomous toll charging environment, a toll charger shall have the possibility to check for
any vehicle observed in the toll charger domain,
1) whether or not the vehicle is equipped with a valid OBE ,
2) the identity of the toll service provider responsible for this OBE, and
3) whether or not the vehicle’s OBE behaves correctly,

65
ISO/TS 192 99: 2 015(E)
4) whether or not the presence of this vehicle is correctly accounted for in the toll service
provider’s toll declaration.
C.3 Toll service providers
C.3 .1 Toll service providers and their main interests
A toll service provider is a legal entity providing to his service users toll service(s) on one or more toll
domains for one or more classes of vehicles .
See I SO 17573 for details .
The main asset for a toll service provider to protect is his business as an intermediary between his
service users and the toll chargers .
The main security requirements for a toll service provider to protect its assets are the following:
— provide a secure toll service and trustworthy toll declarations for his service users;
NOTE 1 It is in the interest of the toll service provider that a service user can easily check the correctness
of the toll declarations is s ued on his behal f.
— provide the toll chargers with trustworthy toll declarations;

NOTE 2 It is in the interest of the toll service provider that a toll charger can easily check the correctness
of the toll declarations issued by a toll service provider.
— con fidentiality of commercial details;
— adherence to the regulatory security requirements in the toll charging environments the devices
provided by the toll service provider are operating;
— being able to check the correctness of the tolling operations and the behaviour of the toll service
provider devices involved therein and to provide evidence of that to the other stakeholders;
— being able to protect his business from fraud and unjusti fied claims.
C.3 .2 Security service requirements for a toll service provider
Security requirements for a toll service provider can be ful filled with the following security services:
a) non-repudiation services for data received from external entities, particularly from toll chargers
(including acknowledgements);
NO TE T hes e ser vices are needed in order to prevent lo s s es due to the denial of having sent charging
related data.
b) accountability for toll declarations (for autonomous toll charging environments) towards his
service users. A service user shall be given the possibility to check any toll declaration that has
been sent for his vehicle by the toll service provider to a toll charger;
c) con fidentiality services for
1) communications between the toll service provider’s central equipment and the toll charger’s
central equipment, and
2) communications between the toll service provider’s central equipment and the service user’s
central equipment.
66
ISO/TS 192 99:2 015(E)
C.4 Service users
C.4.1 Service users and their main interests
T he m a i n i nte re s ts o f a s e r v ic e u s e r a re
— p ro te c ti o n a ga i n s t u n fa i r ch a rg i n g , a n d
— all involved entities ensuring the protection of user privacy.

S e e A n ne x G for detailed explanation about user privacy.
C.4.2 Service users requirements
The main objectives and security related requirements of a service user are the following:
a) possibility to check and control that the toll service provider is charging fairly;
EXAMPLE For Europe, see Reference [ ], article 4.8.
3
b) ensuring that nobody (neither TC, nor TSP) collects data that is not absolutely necessary (data not
required for tolling and not required by law);
c) protection of user data held by toll chargers and toll service providers against misuse;
d) protection of user privacy by toll chargers and toll service providers;
e) easy ful filment of the obligation to pay the usage of road network.
C.5 Interoperability management
C.5.1 Interoperability management and its main interests
Interoperability management includes all actors responsible for ensuring interoperability, particularly for
the interoperability requirements of the equipment to be used by toll chargers and toll service providers.
The main security requirements for an interoperability management actor to protect its assets are
— to ensure the trust of all stakeholders in the interoperability scheme, and
EXAMPLE To ensure that fraud or breach of any security measure have minimum impact on the whole schema.
— to avoid disputes between stakeholders and ensure interoperability.
C.5.2 Security service requirements for interoperability management
No speci fic security services are identi fied for the exchange of information with interoperability
m a n a ge me n t ac to r s .
Communication with an interoperability actor could be based on conventional information interchange

such as registered letters, recorded letters signed for, recorded letters with proof of delivery signed by
the addressee, and/or bailiff’s noti fications and so on.
67
ISO/TS 192 99: 2 015(E)
Annex D
(informative)
Threat analysis
D.1 General
D.1.1 General approach
This informative part of the Technical Speci fication is the basic motivation for the security requirements
which are normative.
The threat analysis is carried out using two different approaches. The first approach is based on the
attack tree methodology (see D.2 ) where the attack driver is the intention and bene fit of the attacker.
This threat analysis has one weakness: that unintended threats by user and equipment which caused
accidents or which had natural causes (e.g. climatic phenomenon) are not covered. Therefore, the
second approach, an asset based threat analysis (see D. 2 , D. 3) in parallel is required. A parallel threat
analysis will also result in a more complete list of existing threats.
D.1.2 Naming conventions
The threat numbering scheme is based on the format TH.XXX.MG.NU where

— TH describes that the number is referring to a threat;
— XXX is the attacker class or the event causative entity or object class. The class enables the attack
tree threats and asset based threats to have the same numbering scheme. The coding covers the
following de finitions:
— SU – Service user;
— TSP – Toll service provider;
— TC – Toll charger;
— HA – Hacker;
— ACT – Activist;
— CP – Communication provider;
— EN – Enterprise;
— GOV – Government;
— FSA – Foreign state agency;
— IM – Interoperability management;
— OUT – Outsider;
— DT – Data Transmission equipment;
— IT – IT equipment;
— MG is the numeric equivalent of the main goal of the attacker or the asset at risk, e.g. avoid to pay
toll, pro file service users (attack tree goals being numbered 1xx), and billing details, service user
68
ISO/TS 192 99:2 015(E)
contract information, and OBE (assets at risk being numbered 2 xx) . The total sum of attacker goals
and assets at risk are supposed to be less than 999 each. Each attacker class or asset at risk could
then have allocated a number series enabling each attacker class or asset at risk to have up to 9 99
different goals or events;
— NU is the threat number within each main goal of the attacker or asset at risk.
D.1.3 Statement of completeness
The list of threats contained in this Annex is not a comprehensive all-encompassing list of all possible
threats to an EFC system. Such a list can never be complete as there will always be threats to a
speci fic implementation not included here and will always contain threats not applicable to a speci fic
implementation. This list should just cover the most common threats to an EFC system. It will be the
responsibility of the implementer of this Technical Speci fication to select the threats applicable to his
speci fic implementation.
D.2 Attack trees based threat analysis
D.2 .1 Overview
These attack trees are based on the approach proposed on the attack tree methodology introduced by
Bruce Schneier (for detailed information, see Reference [26 ]). Attack trees provide a formal, methodical
way of describing the security of systems based on varying attacks. Essentially, attacks are represented
against a system in a tree structure with the goal as the root node and different ways of achieving that
goal as leaf nodes.
A threat exists only if an attacker has a bene fit from the attack. Threats without any bene fit for an
attacker are not considered threats in the current approach. It is possible that attacks are executed only
for fun, but then the fun is the attacker’s bene fit. The main driver of a threat analysis is the bene fit of
the attack. A strong relationship between the threat, the attacker, and the goal of the attack exists. If
there is no bene fit, no attack will be performed and no threat exists which requires security measures.
The concept of an attack tree is that it is rooted in the class of user attempting the attack. The attacker
is characterized by a primary motivation which de fines the types of attack they perform and the
exploitations of the outcomes of those attacks.
It is fully expected that the attacks that different classes of attackers will perform will overlap and a
single attack can be attempted by several classes of attackers with differing motivations. The purpose of
the attack tree is simply to maximize the coverage of the attack space by means of a structured approach,
not to constrain or mandate speci fic solutions to these attacks based on the originating community.
D.2 .2 System model
The system model shown below is used for the attack tree based threat analysis and the asset based
threat analysis.

69
ISO/TS 192 99: 2 015(E)
Figure D.1 — Attack trees — Assumed system model
The arrangement of components in the system is largely irrelevant to the attack tree approach since it
is focused on the external elements of an attack. It does, however, provide a common terminology for
the components within the system and also an enumeration of the externally visible attack surfaces
(some of which are visible to certain attackers and not to others) .
The interfaces and therefore, the most likely attack points are the following:
1) OBE user interface;
2) OBE data interface(s) for value added services (out of scope for this Technical Speci fication);
3) OBE vehicle interface: Connections to the vehicle, e.g. power supply, CAN bus, tachograph signal, etc.;
4) GNSS interface;
5) OBE tampering;
6) DSRC interface;
7) OBE customization and maintenance interface;
8) OBE cellular network interface;
9) OBE proxy to toll service provider interface (optional);
10) Toll service provider to toll charger Back End connection;
11) RSE interface to toll charger back end;
70
ISO/TS 192 99:2 015(E)
12) RSE compliance check interface for license/number plate recognition (ANPR);
13) TC personnel HMI and access to equipment;
14) TSP personnel HMI and access to equipment;
15) OBE distribution to TSP Back End communication;
16) delivering of equipment (e.g. OBE) and service provision (e.g. communication services) by
s uppliers and s ubcontractors . T his is not a real interface, but attacks to be cons idered cou ld be
p erformed during equipment development, equipment manu fac turing, ser vice implementation, or
service operation;
17 ) the service user declares all contractual parameters from the vehicle and for invoicing, used to
customize the OBE;
18) physical or contactless interface from the OBE to the IC card;
19) physical or contactless interface for the loading of the IC card (out of scope for this Technical
Speci fication).
D.2 .3 Presentation of attack trees
The table below explains the template used for the attack tree based threat analysis.
Table D.1 — Notation and relations of threats
No. Unique number for every threat according to the numbering scheme described in D.1 . 2 .
Threat D escrip tion of the threat.

Related RQ Reference to the requirement(s) driven by the threat..
D.2 .4 Attacker class 1: Service user
D.2 .4.1 General
The service user is de fined as the person who is liable to pay the toll in the EFC-system and as such, can
be a physical person, a company, or another legal entity. The service user class also includes the driver
even when someone else pays the toll. Publicity is not an objective of the service user (this is dealt with
under the activis t attacker) .
D.2 .4.2 Goal 101: Avoiding payment of toll
The primary goal from a service user is his intention to avoid paying the toll. The effect of the
attack i s two -fo ld .
— Firstly, it represents a loss of income for the entity collecting the toll (i.e. toll charger).
— Secondly, if it becomes a wide-spread practice, it undermines the belief that the EFC system is
correct and fair.
D.2 .4.2 .1 Sub goal: Manipulating the system to not register road usage

71
ISO/TS 192 99: 2 015(E)
Table D.2 — SU goal: Avoiding payment of toll — Manipulating the system to not register road
usage
DSRC GNSS
No. Threat
Related RQ
T H . S U.101 .11 B l i n d i n g th e r o ad u s a ge s e n s o r X X
T h e r o ad u s a ge s e n s o r i n a G N S S o r a D S RC O B E c o u l d b e b l i n de d , fo r RQ.T C . 0 1
example, by covering the antenna where this is applicable. RQ.T C . 0 2
RQ.T S P. 0 1
RQ.T S P. 0 9
RQ.T S P. 51
T H . S U.101 .1 2 Muting the OBE n. a. X
I n the c a s e whe r e th e O B E c o m mu n i c a ti o n c h a n n e l i s s e p a r a te fr o m the RQ.T C . 0 1
road usage sensor itself (i.e. autonomous systems only), the RQ.T C . 0 2
communication signal might be temporarily or permanently blocked, thus RQ.T S P. 0 1
avo i d i n g th e r e p o r ti n g o f r o ad u s a ge d at a r e n d e r i n g the O B E “mu te ”. RQ.T S P. 51
RQ.T S P. 0 9
T H . S U.101 .1 3 Removing or destroying the OBE X X
One of the simplest, yet most effective attacks is to destroy or remove the RQ.T C . 0 2
O B E . Re m o va l c o u l d b e p e r m a n e n t o r te mp o r a l . U n l e s s s o m e c o u n te r
measure is designed, this will render the vehicle “invisible” for the system.
T H . S U . 1 0 1 . 14 Disconnect the OBE power supply temporarily or permanently X X
The simplest attack is to remove the OBE power supply. That can be done RQ.T C . 0 1
permanently or only temporarily, e.g. by inserting a switch in the power RQ.T C . 0 2
supply. RQ.T S P. 0 1
RQ.T S P. 0 9
RQ.T S P. 51
T H . S U.101 .1 5 J a m m i n g th e G N S S r o ad u s a ge s e n s o r n. a. X
e . g. w i th a p o r ta b l e j a m m i n g d e v i c e RQ.T C . 0 1
RQ.T C . 0 2
RQ.T S P. 0 1
RQ.T S P. 0 9
RQ.T S P. 51
T H . S U.101 .16 J a m m i n g th e D S RC r o ad u s a ge s e n s o r X n. a.
e.g. with a portable jamming device or an ITS-system RQ.T C . 0 1
RQ.T C . 0 2
RQ.T S P. 0 1
RQ.T S P. 0 9
RQ.T S P. 51
T H . S U.101 .17 Destroying the ICC X X
One of the simplest, yet most effective attacks is to destroy the ICC and RQ.T C . 0 2
deny responsibility for the malfunction.

T H . S U.101 .1 8 J a m m i n g th e I C C i n te r fac e X X
e . g. w i th a p o r ta b l e j a m m i n g d e v i c e RQ.T C . 0 1
RQ.T C . 0 2
J a m m i n g th e I C C i n te r fac e du r i n g c h a r g i n g tr a n s ac ti o n s wo u l d l o o k l i ke a
RQ.T S P. 0 1
m a l fu n c ti o n .
RQ.T S P. 0 9
RQ.T S P. 51
D.2 .4.2 .2 Sub goal: Manipulating the system to register the wrong road usage
72
ISO/TS 192 99:2 015(E)
Table D. 3 — SU goal: Avoiding payment of toll — Manipulating the system to register the
wrong road usage
DSRC GNSS
No. Threat
Related RQ
TH . SU.101 . 21 Manipulating the input to the road usage sensors n. a. X
This attack is typically relevant in systems where road usage is continually RQ.TC .01
recorded (such as in GNSS-based systems) and involves spoo fing the signal RQ.TSP.01
that goes into the sensor. It does not require any modi fications to the OBE RQ.TSP.16
since it is directed at the road usage signal before it enters the OBE . RQ.TSP. 51
TH . SU.101 . 2 2 Manipulating the road usage sensors n. a. X
This attack involves modifying the road usage sensors, for example, by RQ.TC .01
replacing them or filtering their output to generate data that results in a RQ.TSP.01
lower toll. It is performed in real time and modi fies road usage data as it is RQ.TSP. 51
collected.
TH . SU.101 . 2 3 Manipulating the road usage data collection software n. a. X
The software calculating the road usage based on the sensor inputs is RQ.TC .01
altered in such a way that a lower road usage will be recorded, stored, and RQ.TSP.01
transmitted to the back end (only possible in autonomous systems). RQ.TSP. 51
TH . SU.101 . 24 Manipulating the road usage data after collection in the OBE or ICC n. a. X
In the case where several items of road usage data remain under the RQ.TC .01
control of the service user, before being reported to another party, the RQ.TC .0 4
service user has the possibility of modifying the road usage data taking the RQ.TSP.01
whole data set into account. RQ.TSP.03
RQ.TSP.07
RQ.TSP.40
RQ.TSP. 51
TH . SU.101 . 25 Manipulating the road usage data in transit from the OBE or ICC n. a. X
Road usage data can be manipulated as it is communicated from the OBE RQ.TC .01
or ICC . RQ.TC .0 4
RQ.TSP.01
RQ.TSP.03
RQ.TSP. 51
TH . SU.101 . 26 Use an OBE simulator to produce the required road usage “toll declaration” n. a. X
Prevent the OBE from sending the road usage to the back end and produce RQ.TC .01
a fake data set with OBE simulation equipment that is sent ins tead. RQ.TC .05
RQ.TSP.01
RQ.TSP.0 4
RQ.TSP. 51
RQ.TSP. 55
TH . SU.101 . 27 Change user input according to sensed or known external audit-checks X X
Update the tariff relevant settings of an OBE before known audit-check RQ.TC .02
event (CCC or camera equipment) takes place. RQ.TSP.05
RQ.TSP.40
RQ.TSP. 53
TH . SU.101 . 2 8 Use an ICC simulator to produce the required data for an OBE at the time n. a. X
of road usage
RQ.TC .01
Use ICC simulation equipment instead of a real ICC . RQ.TC .05
RQ.TSP.01
RQ.TSP.0 4
RQ.TSP. 51
RQ.TSP. 55
D.2 .4.2 .3 Sub goal: Faking toll parameters

73
ISO/TS 192 99: 2 015(E)
Table D.4 — SU goal: Avoiding payment of toll — Faking toll parameters
DSRC GNSS
No. Threat
Related RQ
TH . SU.101 . 31 Faking vehicle parameters X X
The service user sets vehicle parameters to a value that does not re flect RQ.TC .02
reality, but that lowers the toll. RQ.TSP.05
RQ.TSP.40
RQ.TSP. 53
TH . SU.101 . 32 Faking identity X X
The service user sets OBE, ICC or user identity parameters to a value that RQ.TC .02
does not re flect reality and that lowers the toll (e.g. reduced tariff for RQ.TSP.05
disabled person) or charges the toll to another (or a fake) user. RQ.TSP.06
RQ.TSP.0 8
RQ.TSP.40
RQ.TSP. 53
D.2 .4.2 .4 Sub goal: Manipulating the system to loose road usage data
Table D.5 — SU goal: Avoiding payment of toll — Manipulating the system to loose road usage data
DSRC GNSS
No. Threat
Related RQ
TH . SU.101 .41 Force insufficient OBE data buffer n. a. X
Preventing the OBE from sending data to the back end for as long as RQ.TC .01
possible to produce insufficient memory that results in road usage no RQ.TC .02
longer being collected or overwriting old road usage not taken in account RQ.TSP.01
in the back end. RQ.TSP.09
RQ.TSP. 51
RQ.TSP. 53
TH . SU.101 .42 Bribing TC or TSP employee to manipulate the service user account X X
The service user in fluences (e.g. bribes, as family or friend) an employee RQ.ISMS.2
to manipulate his account to pay lower toll to avoid a penalty, etc.
TH . SU.101 .43 Denying presence in toll domain X X
The service user denies the presence in a toll domain at a given time and RQ.TSP. 89
thus, denies payment of invoice.
TH . SU.101 .44 Using an OBE without a valid contract with a TSP X X
SU uses an OBE without a valid contract with a TSP to avoid payment to RQ.TC .92
the TSP.
TH . SU.101 .45 Using an ICC without a valid contract with a TSP X X
SU uses an ICC without a valid contract with a TSP to avoid payment to RQ.TC .93
the TSP.
D.2 .4.3 Goal 102 : Undermining the system
A secondary goal is to undermine the system out of discontent with its design or plain existence.
This secondary threat might cause the service user to perform attacks that due to their costs are not
justi fiable from an economic perspective. The effect of the attack is two-fold:
— Firstly, it represents a loss of income for the entity that is collecting the toll (i.e. toll charger).
correct and fair.
74
ISO/TS 192 99:2 015(E)
A l l the at tacks de s c r i b e d i n G o a l 1 0 2 m i ght a l s o be p e r fo r me d w i tho u t the e co no m i c i nce n ti ve , b ut b e
motivated by spite.
D.2 .4.4 Goal 103 : Protecting the service users own privacy
A service user might be discontent with the privacy protection features of a mandatory EFC system
causing her/him not to disclose data that is crucial for the functioning of the system. The effect of the
at tack i s t wo - fo ld .
— Firstly, it represents a loss of income for the entity that is collecting the toll (i.e. toll charger).
c o r re c t a nd fa i r.
A l l the at tacks de s c r ib e d i n G o a l 1 0 3 m i gh t a l s o be p e r fo r me d w i tho u t the e c o no m i c i nce n ti ve , b ut b e
motivated by a concern for the service user’s own privacy.

D.2 .5 Attacker class 2 : Toll service provider
D.2 .5.1 General
The toll service provider is the legal entity providing toll services to his service users in one or more
to l l do m a i n s fo r o ne o r mo re c l a s s e s o f ve h ic le s .
D.2 .5.2 Goal 104: Increase revenue from service user/overcharge service user
In order for this to be considered an attack, the way to increase revenue from the user shall involve
overcharging, that is, charging a toll that is larger than what is motivated by the actual road usage. The
motivation is short-term financial gain.
Table D.6 — TSP goal: Increase revenue from service user/overcharge service user
DSRC GNSS
No. Threat
Related RQ
T H .T S P. 1 0 4 . 0 1 Fa k i n g r o ad u s e X X
T he T S P c o u l d c h a r ge a s e r v i c e u s e r fo r r o ad u s a ge th a t h a s ne ve r ta ke n RQ.T C . 1 3
p l ac e . H e c a l c u l a te s th e fa ke c h a r ge b a s e d o n th e to l l c o n te x t d at a a n d RQ.T S P. 5 7
t a r i ffs o f a T C w i tho u t i n vo l v i n g th e m .
T H .T S P. 1 0 4 . 0 2 U s i n g i nc o r r e c t to l l c o n te x t d at a n. a. X
The TSP could use faulty toll context data to in flate the toll charged to RQ.T S P. 1 7
th e s e r v i c e u s e r wh i l e a l s o u s i n g the c o r r e c t d at a th a t r e s u l ts i n a l o we r RQ.T S P. 5 7
to l l d e c l a r e d to the T C a n d thu s , b e ab l e to ke e p th e d i ffe r e n c e .
T H .T S P. 1 0 4 . 0 3 O ve r c h a r g i n g the s e r v i c e u s e r X X
The TSP charges the service user a higher amount as calculated by RQ.T S P. 5 7
himself or by the TC(s) based on the billing details. The TSP changes the
i n vo i c e d at a r e c e i ve d fr o m th e T C to i n c r e a s e the c h a r ge .
T H .T S P. 1 0 4 . 0 4 Modify toll declarations n. a. X
The TSP modi fies toll declarations acquired and reported by him to RQ.T C . 1 3
i nc r e a s e h i s r e mu n e r ati o n . RQ.T S P. 1 2
D.2.5.3 Goal 105: Pro iling of service user(s) f
The toll service provider could perform pro filing for its own gain or could be pressurized by a third party
(e.g. a repressive government or a criminal organization) to collect and provide service user pro files.
75
ISO/TS 192 99: 2 015(E)
T he at tac k co u ld be d i re c te d to wa rd s the who le s e r v ice u s er co l le c ti ve or an i nd i vi du a l s e r vi ce u s e r.
When the whole collective is pro filed, it could be used to target commercial offerings [own or others;
in the second case, probably in combination with reselling of data about tolled service users (see Goal
106)] to a suitable service user. Yet, political or criminal motives are also possible.
If a single service user is pro filed, the motivations could, in addition, also be of a personal nature,
s ta l ki n g o f ce le b r i tie s , j e a lo u s s p o u s e s , e tc .
Table D.7 — TSP goal: Pro iling of service user(s)

f
DSRC GNSS
No. Threat
Related RQ
T H .T S P. 1 0 5 . 0 1 Ac c e s s i n g a n d c o mp i l i n g i n fo r m ati o n o n th e s e r v i c e u s e r s X X
The TSP collects and compiles service user pro files, based on the RQ.T S P. 5 9
collected vehicle position data and/or vehicle mileage, in a way that is

no t a l l o we d ac c o r d i n g to l aw o r c o n tr ac t .
D.2 .5.4 Goal 106: Reselling of data about service user(s)
The toll service provider could gain financially from reselling con fidential and sensitive data about the
service user(s) to other commercial parties operating data mining systems, for example, to an insurance
company, advertising industry, or governmental agencies which are active in anti-terrorism, etc.
Table D.8 — TSP goal: TSP’s reselling of data about service user(s)
DSRC GNSS
No. Threat
Related RQ
T H .T S P. 1 0 6 . 0 1 Resell service user data to third party X X
T h e c o l l e c te d s e r v i c e u s e r a n d ve h i c l e p o s i ti o n d at a a r e s o l d a n d RQ.T S P. 5 9
transmitted to an external party without the knowledge of the SU.

T H .T S P. 1 0 6 . 0 2 Allow service user tracking by third parties X X
The collected service user and vehicle position data, maybe more data RQ.ISMS.1
th a n i s r e qu i r e d fo r c h a r g i n g p u r p o s e s , i s s o l d a n d tr a n s m i t te d “ i n r e a l RQ.ISMS.2
ti m e ” to th i r d p a r ti e s w i th o u t the p e r m i s s i o n o f th e s e r v i c e u s e r fo r RQ.T S P. 5 9
service user and vehicle tracking. The attack is either performed by the
TSP or by his staff without the knowledge of TSP.
T H .T S P. 1 0 6 . 0 3 Provide speci fic data mining based on road usage data X X
Perform speci fic data mining and statistics on demand and distribute RQ.T S P. 5 9
the (even anonymous) results to commercially interested parties.
D.2 .5.5 Goal 107: Reduction of payments to toll charger
The intention is to pay the toll charger less than it is entitled to due to the road usage of the service user.
The motivation is short-term financial gain.
76
ISO/TS 192 99:2 015(E)
Table D.9 — TSP goal: Reselling of data about service user(s)
DSRC GNSS
No. Threat
Related RQ
T H .T S P. 1 0 7. 0 1 Modifying road usage data reported from the OBE n. a. X
The TSP could modify the road usage data to be sent to the TC so that the RQ.T C . 0 1
toll is de flated, for example, slightly shifting the time values to put the RQ.T S P. 5 1
tr ip
i n a no th e r, c he ap e r, ti m e c l a s s , wh i l e u s i n g the c o r r e c t d at a to c h a r ge the
s e r v i c e u s e r.
T H .T S P. 1 0 7. 0 2 S u p p r e s s i n g r e p o r ti n g o f r o ad u s e n. a. X
T he T S P c o u l d r e fr a i n fr o m r e p o r ti n g r o ad u s a ge to th e T C wh i l e u s i n g RQ.T C . 0 1
the c o r r e c t d at a to c h a r ge th e s e r v i c e u s e r. RQ.T S P. 5 1
T H .T S P. 1 0 7. 0 3 Faulty interpretation of road usage data n. a. X
In certain set ups, the TSP will have the ability to interpret the road usage RQ.T C . 0 1
data in a way that in flates the toll that is due to the TC while using the RQ.T S P. 5 1
c o r r e c t d at a to c h a r ge th e u s e . A n e x a m p l e c o u l d b e i f m ap m a tc h i n g i s
under the control of the TSP and road usage sensor data are intentionally
misinterpreted to mean a faulty, less expensive, route.
T H .T S P. 1 0 7. 0 4 U s i n g i n c o r r e c t to l l c o n te x t d a ta n. a. X
If the TSP is in control of computing the final toll or some data on which RQ.T C . 0 1
the final toll is computed, it could use faulty toll context data to de flate RQ.T C . 1 7
the to l l to b e p a i d to the T C wh i l e u s i n g th e c o r r e c t d at a th a t r e s u l ts i n a RQ.T S P. 51
h i g he r to l l r e q u e s te d fr o m the s e r v i c e u s e r a n d thu s , b e a b l e to ke e p the
d i ffe r e n c e .
T H .T S P. 1 0 7. 0 5 Manipulate charging data during enrichment n. a. X
A TSP which has been requested by a TC to enrich determined charging RQ.T C . 0 1
data may manipulate them to reduce the final toll while using the correct RQ.T S P. 51
d a t a to c h a r ge th e s e r v i c e u s e r.
T H .T S P. 1 0 7. 0 6 I s s u i n g O B E w i tho u t a va l i d c o n tr ac t n. a. X
A T S P i s s u e s a n O B E to the S U w i th o u t a va l i d c o n tr ac t b e t we e n T C a n d RQ.T C .9 2
TSP to get paid by the SU without paying the TC.

T H .T S P. 1 0 7. 0 7 I s s u i n g I C C w i th o u t a va l i d c o n tr ac t n. a. X
A T S P i s s u e s a n I C C to the S U w i th o u t a va l i d c o n tr ac t b e t we e n T C a n d RQ.T C .9 3
TSP to get paid by the SU without paying the TC.
D.2 .5.6 Goal 108: Use of cheaper (substandard) equipment
The toll service provider may have an advantage if it can lower its investment costs for equipment
(primarily OBE).
Table D.10 — TSP goal: Use of cheaper (substandard) equipment
DSRC GNSS
No. Threat
Related RQ
T H .T S P. 1 0 8 . 0 1 U s i n g s u b s t a n d a r d e qu i p me n t X X
The TSP could use equipment that does not ful fil agreed certi fications or RQ.T C . 0 7
that cannot deliver the agreed quality of service. RQ.T C . 0 8
RQ.T S P. 5 8
RQ.T S P. 6 0
77
ISO/TS 192 99: 2 015(E)
D.2 .5.7 Goal 109: Neglect maintenance of equipment
The toll service provider may have an advantage if it can lower its operational costs by neglecting the
maintenance of equipment (primarily OBE).
NOTE For example, using an OBE longer than its intended battery life or not replacing poorly performing OBE.
Table D.11 — TSP goal: Neglect maintenance of equipment
DSRC GNSS
No. Threat
Related RQ
TH .TSP.10 9. 01 Using an OBE longer than its guaranteed battery life X X
The TSP could use an OBE longer than its guaranteed battery life which RQ.TSP. 82
leads to a lower quality of service and additional cost/loss of income to
the TC .
TH .TSP.10 9. 02 No t exchanging OBE with low p erformance X X
T he TSP avoids the exchange of OBE even if he has knowledge of its low RQ.TSP. 82
performance prolonging a lower quality of service and additional
cos t/ los s of income to the TC .
D.2 .5.8 Goal 110: Delaying payment to TC
The toll service provider can have an advantage if it can delay its payment to the TC. Especially when a
TSP goes bankrupt, this can lead to damage to the TC if the unpaid amount is higher than the payment
security provided.
D.2 .6 Attacker class 3 : Toll charger
D.2 .6.1 General
The toll charger is a legal entity charging toll for vehicles in a toll domain. The motivation of the toll
charger can be to reduce the complexity of his operations or to make charges against a toll service
provider or service user which are not appropriate and thus , to increase his revenue. He can also attempt
to resell or otherwise, pro fit from the data collected from toll service providers or service users.
D.2 .6.2 Goal 111: Increase revenue
The malicious intention of a toll charger to increase the revenue received from toll ser vice providers
and/or service users for the us age of the toll domain.
Table D.12 — TC goal: Increase revenue
DSRC GNSS
No. Threat
Related RQ
TH .TC .111 .01 Modify toll declarations acquired by the TC X n. a.
The TC modi fies the toll declarations he has acquired himself (e.g. with its RQ.TSP.10
ro ad s ide equipment) and rep orts it as bi lling detai ls . RQ.TSP.11
TH .TC .111 . 02 Insert toll declarations acquired by the TC X n. a.
T he TC adds fake toll declarations to the genuine tol l declarations he has RQ.TSP.10
acquired hims el f and rep orts them as bi lling detai ls . RQ.TSP.11
TH .TC .111 . 03 Replay toll declarations X n. a.
The TC replays genuine toll declarations he has acquired himself and RQ.TSP.10
rep orts them again as bil ling detai ls . RQ.TSP.11
78
ISO/TS 192 99:2 015(E)
Table D.12 (continued)
DSRC GNSS
No. Threat
Related RQ
TH .TC .111 .0 4 Modify toll declarations reported by the TSP n. a. X
The TC modi fies the toll declarations acquired and reported by the TSP RQ.TSP.1 2
and reports them as billing details back to the TSP.
TH .TC .111 .05 Insert toll declarations reported by the TSP n. a. X
The TC inserts fake toll declarations into the lis t of toll declarations RQ.TSP.1 2
acquired and reported by the TSP and reports them as billing details back
to the TSP.
TH .TC .111 .06 Repudiate the origin of toll context data X X
The TC repudiates the origin (or the update of a new version) of the toll RQ.TC .91
context data and claims payment for service users according to the old toll RQ.TC .97
context data. RQ.TSP.13
RQ.TSP.17
TH .TC .111 .07 Repudiate reception of exception list X X
The TC denies or repudiates the reception of an exception list and claims RQ.TC .9 4
payment for service users which were on the denied or repudiated list at RQ.TC .9 9
the time of acquisition of the toll declaration(s) by him. RQ.TSP.14
RQ.TSP.18
D.2 .6.3 Goal 106: Reselling of data about service users
The toll charger could gain financially from reselling con fidential and sensitive data about the service
users to other commercial parties operating data mining systems, for example, to an insurance
company, advertising industry, or governmental agencies which are active in anti-terrorism, etc.
Table D.13 — TC goal: TC’s reselling of data about service users
DSRC GNSS
No. Threat
Related RQ
TH .TC .106 .01 Resell service user data to third party X X
The collected service user and vehicle position data are sold and RQ.TC . 51
transmitted to an external party without the knowledge of the SU.
TH .TC .106 .02 Allow service user tracking by third parties X X
The collected service user and vehicle position data, maybe more RQ.ISMS.1
data than is required for charging purposes, are sold and transmitted “in RQ.ISMS.2
real time” to third parties without the permission of the service user for RQ.TC . 51
service user and vehicle tracking. The attack is either performed by the TC
or by his staff without knowledge of the TC.
TH .TC .106 .03 Provide speci fic data mining based on road usage data X X
Perform speci fic data mining and statistics on demand and distribute the RQ.TC . 51
(even anonymous) results to commercially interested parties.
D.2 .6.4 Goal 112 : Neglect maintenance of equipment
The toll charger can have an advantage if it can lower its operational costs by neglecting the maintenance
of equipment (primarily RSE).
NOTE For example, using RSE longer than its intended life span does not replace poorly performing RSE.

79
ISO/TS 192 99: 2 015(E)
Table D.14 — TC goal: Neglect maintenance of equipment
DSRC GNSS
No. Threat
Related RQ
T H .T C . 1 1 2 . 0 1 Avoiding a regular maintenance of RSE equipment in free flow systems X n. a.
T h e T C c o u l d avo i d a r e g u l a r m a i n te n a nc e o f R S E e qu i p me n t wh i c h l e ad s RQ.T C . 2 0
to a lower quality of service and possible claims of low OBE performance RQ.T C .9 6
to the T S P.
T H .T C . 1 1 2 . 0 2 Not exchanging DSRC beacons with low performance in free flow systems X n. a.
T h e T C do e s n o t e xc h a n ge D S RC b e ac o n s e ve n i f h e h a s kn o wl e d ge o f th e i r RQ.T C . 2 0
low performance prolonging lower quality of service and possible claims RQ.T C .9 6
o f l o w O B E p e r fo r m a n c e to th e T S P.
T H .T C . 1 1 2 . 0 3 Avo i d i n g a r e g u l a r m a i n te n a n c e o f R S E e qu i p me n t i n b a r r i e r b a s e d D S RC X n. a.
systems RQ.T C . 2 0
T h e T C c o u l d avo i d a r e g u l a r m a i n te n a nc e o f R S E e qu i p me n t wh i c h l e ad s RQ.T C .9 6
to the use of manual payment instead of handling through the TSP

h a r m i n g th e b u s i n e s s c a s e o f the T S P.
T H .T C . 1 1 2 . 0 4 N o t e xc h a n g i n g D S RC b e ac o n s w i th l o w p e r fo r m a n c e i n b a r r i e r b a s e d X n. a.
DSRC systems RQ.T C . 2 0
T h e T C do e s n o t e xc h a n ge D S RC b e ac o n s e ve n i f h e h a s kn o wl e d ge o f th e i r RQ.T C .9 6
low performance prolonging the use of manual payment instead of the

h a n d l i n g th r o u gh th e T S P h a r m i n g th e b u s i n e s s c a s e o f th e T S P.
D.2 .6.5 Goal 113 : Poor management of toll context data
The toll charger can have an advantage if it can lower its operational costs by neglecting the management
o f to l l co n te x t d ata .
NO TE Fo r e x a mp l e , u s i n g w ro n g n a me s i n to l l s tatio n de s c r ip tio n s a nd u s i n g w ro n g p r ice s fo r ch a rg i n g p o i nts .
Table D.15 — TC goal: Poor management of toll context data
DSRC GNSS
No. Threat
Related RQ
T H .T C . 1 1 3 . 0 1 Poor quality of toll context data X X
The TC could provide toll context data with a poor quality causing RQ.T C .9 8
a dd i ti o n a l c o s ts to the T S P fo r s e r v i c e u s e r c o mp l a i n t h a n d l i n g.
T H .T C . 1 1 3 . 0 2 U s i n g i n c o r r e c t to l l c o n te x t d at a X X
The TC could provide faulty toll context data to in flate the toll charged to RQ.T C .9 8
th e s e r v ic e u s e r.
D.2 .6.6 Goal 114: Delaying payment of TSP remuneration
The toll charger can have an advantage if it can delay its payment to the TSP.
NOTE This is considered to be out of scope and only kept to document the boundaries of the current EFC
security framework.
D.2 .7 Attacker class 4: Hacker
D.2 .7.1 General
A hacker is de fined as an attacker who is attempting to penetrate the system without direct financial
motivation. A hacker is characterized by capable intellect, high tenacity, and a desire to demonstrate
80
ISO/TS 192 99:2 015(E)
relatively publicly the results of his efforts. This class of attacker can find the results of their actions
exploited for commercial or criminal bene fit by attackers in other classes. Their effects cannot
be considered benign, but are likely to be technically sophisticated and can be time consuming in
implementation.
D.2 .7.2 Goal 115: Demonstrate system vulnerability
This class of attacks shows that the system is vulnerable, but does not necessarily achieve a perceivable
bene fit for the attacker.
Table D.16 — Hacker goal: Demonstrate system vulnerability
DSRC GNSS
No. Threat
Related RQ
TH . H A.11 5 . 01 Fake an input s ignal from the vehicle and have it accep ted as valid X X
In this attack, a signal required for the operation of the system is emulated RQ.TSP.16
or modi fied to change its semantics. Typical sources of signals are CAN
bus , tachograph, or o dometer.
TH . H A.11 5 . 02 Induce noise on power supply lines to cause system misoperation X X
Excessive power supply noise can induce system misoperation and/or RQ.TC . 01
system restarts with corresponding loss of data. RQ.TC . 02
RQ.TSP. 01
RQ.TSP. 5 3
TH . H A.11 5 . 0 4 Fake input s ignal from GNS S n. a. X
C reate a ‘fake’ GNS S s ignal which overrules the ‘real’ one and gives a RQ.TC . 01
di fferent p os ition for the OBE . RQ.TC . 02
RQ.TSP. 01
RQ.TSP.16
RQ.TSP. 5 3
TH . H A.11 5 . 0 5 Provide false con figuration data to the OBE/proxy X X
Adjust the OBE so that it is inappropriately set (for example, telling it that RQ.TSP.0 5
it is in a p as senger car rather than a truck) . RQ.TSP. 07
RQ.TSP.9 7
TH . H A.11 5 . 0 6 Fake us er input according to sens ed or known external audit checks X X
For example, to automatically update the class of a vehicle before an RQ.TC . 01

audit check event takes place to generate problems for the ser vice users . RQ.TSP. 01
RQ.TSP.0 5
RQ.TSP. 07
D.2 .7.3 Goal 116: Obtain respect amongst their peers
This class of attack is characterized by innate “cleverness” or complexity. Again, it does not necessarily
have a malevolent intent or result, but can be exploited by others for commercial gain.
NOTE No protection requirements are de fined for these threats as there is no possible damage to the
system, except for perhaps, “loss of repudiation”. These threats are considered to be out of scope and only kept to
document the boundaries of the current EFC security framework.

81
ISO/TS 192 99: 2 015(E)
Table D.17 — Hacker goal: Obtain respect amongst their peers
DSRC GNSS
No. Threat
Related RQ
T H . H A .116 . 01 Re p l ac e th e s e c u r e e l e me n t w i th a fa ke s e c u r e e l e m e n t X X
Allowing the modi fication of the data that is recorded by the secure -
element (secure storage in OBE, e.g. HSM).

T H . H A .116 . 02 Extract private keys from the OBE X X
Allowing the falsi fication of an OBE to act as the OBE for the purpose of -
c h a r ge m a n i p u l a tio n .
T H . H A .116 . 0 3 Extract secret keys from the RSE X n. a.
A l l o w i n g a fa ke R S E to ac t a s th e R S E fo r th e p u r p o s e o f c h a r ge -
m a n i p u l ati o n .
T H . H A .116 . 0 4 Ac t a s a n O B E c o m mu n i c a ti o n p e e r to e x tr ac t i n fo r m a ti o n fr o m i t n. a. X
T H . H A .116 . 0 5 P r o v i d i n g a n ad d i tio n a l s e r v i c e wh ic h i n te r fe r e s w i th the to l l i n g X X
ap p l i c a tio n
-
A n add i ti o n a l ap p l i c ati o n c o u l d b e i n s t a l l e d o n a n O B E wh i c h s u p p o r t s
secondary applications to prevent the OBE from operating correctly by

— using system resources (memory, CPU, etc.),
— co mp ro m i s i n g i np u t s i g n a l s , a nd
— c o m p r o m i s i n g o u tp u t s t ate r e g i s tr ati o n .
T H . H A .116 . 0 6 Act as the maintenance and customization functionality X X
Enabling elevated access to the system for the purpose of modifying its -
con figuration.
T H . H A .116 . 0 7 O p e n the O B E a n d o b s e r ve c o m mu n i c a ti o n b e t we e n t wo c o m p o n e n ts o n X X
p r i n te d c i r c u i t b o a r d
-
To ga i n kn o wl e d ge a b o u t th e c o m mu n i c a ti o n a n d b e i n g ab l e to m a n ip u l a te
i t.
T H . H A .116 . 0 8 Re p l ac e c o m p o n e n t o n th e p r i n te d c i r c u i t b o a r d X X
Removal of a component (ROM, FPGA, etc.) and replacement with a similar -
component which offers new/different functionality.

T H . H A .116 . 0 9 I n va l i d ate/i n c ap ac i t ate a c o m p o n e n t o n th e p r i n te d c i r c u i t b o a r d X X
For example, by using a JTAG interface to switch a component into test -
mode or destroying the antenna without interfering with the rest of the
functionality.
T H . H A .116 .10 Ac t a s a R S E fo r th e p u r p o s e o f e x tr ac ti n g d at a fr o m th e O B E X n. a.
T H . H A .116 .11 Get access to central system of a TC or TSP X X
A l l o w i n g th e b i g s c a l e m a n i p u l a ti o n o f s e r v i c e u s e r d a t a a n d r o ad u s a ge -
d a ta .
T H . H A .116 .1 2 Ac c e s s to O B E th r o u gh b ac k do o r X X
G a i n i n g ac c e s s to th e O B E d at a fo r th e p u r p o s e o f m a n i p u l a ti o n , d a ta -
c o l l e c ti o n , a n d/o r fu r the r i n ve s ti gati o n .
T H . H A .116 .1 3 Ac c e s s to O B E fo r m a n i p u l ati o n o f s e n s o r d at a X X
Modify the input signals that are received by the charging application with -
a n i n te n ti o n o f ge t ti n g i t to m i s c a l c u l ate th e r e s u l t.
82
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . H A.116.14 Access to OBE for manipulation of output state n. a. X
Modifying the information that is recorded in the OBE as a charge event -

(trail) .
D.2 .7.4 Goal 117: Improve understanding of the system or to research its operation
This class of attack leads to information leakage from the system or an increased level of knowledge
outside of the implementer community which was never intended.
Table D.18 — Hacker goal: Improve understanding of the system or to research its operation
DSRC GNSS
No. Threat
Related RQ
TH . H A.117.01 Intercept the communication between the OBE (front end) and the TSP n. a. X
back end.
RQ. IF.10
RQ. IF.11
RQ.TSP.90
RQ.TSP.91
TH . H A.117.02 Intercept internal communications between the OBE and Proxy. n. a. X
RQ. IF.10
RQ. IF.11
RQ.TSP.90
TH . H A.117.03 Intercept internal communications between any two elements within the X Y
OBE .
RQ. XX.02
TH . H A.117.0 4 Intercept communications between the OBE and RSE . X n. a.
RQ. IF.10
RQ. IF.11
RQ.TC .90
D.2 .7.5 Goal 118: Provide fake OBE or ICC
This class of attack demonstrates the cleverness and engineering capabilities of the hacker and can also
lead to financial pro fit by selling faked OBE or ICC or the knowledge of how to fake them.
Table D.19 — Hacker goal: Fake an OBE or ICC
DSRC GNSS
No. Threat
Related RQ
TH . H A.118 .01 Clone an OBE X X
Clone an existing OBE and its private key on an original OBE or an RQ.TSP.0 8
also-cloned hardware. RQ.TSP.10
RQ.TSP.19
RQ.TSP. 21
TH . H A.118 .02 Build a fake OBE X X
Design and build a fake OBE which is not (easily) detectable by RSE and RQ.TSP.0 8
enforcement equipment. RQ.TSP.10

83
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
T H . H A .11 8 . 0 3 C lo ne a n I C C X X
Clone an existing ICC and its private key on an original ICC or also, on an RQ.T S P. 0 8
a l s o - c l o ne d h a r d wa r e . RQ.T S P. 1 0
RQ.T S P. 19
RQ.T S P. 2 1
T H . H A .11 8 . 0 4 B u i l d a fa ke I C C X X
Design and build a fake ICC which is not (easily) detectable by RSE and RQ.T S P. 0 8
e n fo r c e me n t e q u i p m e n t. RQ.T S P. 1 0
D.2 .8 Attacker class 5: Activist
D.2 .8.1 General
An activist is de fined as an especially active, vigorous advocate of a cause, especially a political cause
which may use violence, civil disobedience, or criminal activities to achieve his goals. Terrorists are
included in this attacker class. An activist may be interested in abusing or manipulating the system in
order to highlight or realize his political objective even though that objective might not have any relation
to the system as such. To an activist, publicity is one of the main goals; therefore, he is interested in
large scale disruptions of the systems that cannot be easily reconciled or hidden by the authorities. The
activist might not be interested in hiding his identity.
NOTE Most of the threats are covered by other requirements and security measures. An activist has
possibly more resources than the other attackers and can break the security measures de fined by the EFC
security framework. Yet, such speci fic threats and the respective intention of an activist (e.g. terrorist, etc.) are
out of scope of the EFC security framework. This subclause is kept to document the boundaries of the current EFC
security framework.
D.2 .8.2 Goal 119: Societal destabilization
Manipulation of tolling systems might have destabilizing effects on society as a whole. This can be the
intention of activists motivated by anger or resentment against the political regime or the way of living
in one or more countries. Manipulation of tolling systems could have the following effects:
— reducing the trust of service users in the correct functioning of tolling systems and, by extension, of
any high-tech system;
— re duc i n g tr u s t o f s e r vi ce u s e r s i n to l l ch a r ge r s , to l l s e r v ic e p ro v ide r s o r to l l c h a r g i n g e nv i ro n me nt
management, and, by extension, in any authority;

— endangering the financial stability of toll chargers or local or national governments by reducing
revenues from tolling operations;
— d i s r up ti n g the m a i nte n a nc e o f i n fra s tr uc tu re due to l ac k o f fu nd s .
Table D.20 — Activist goal: Societal destabilization
DSRC GNSS
No. Threat
Related RQ
T H . AC T. 1 1 9 . 0 1 L a r ge - s c a l e d i s r up ti o n o f G N S S s i g n a l n. a. X
By jamming or otherwise, disrupting the GNSS signal in large areas, the -
OBE of a large number of service users of autonomous EFC systems will

stop functioning correctly.
84
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . AC T.119. 02 Breach of data integrity/non-repudiation X X
Break into the system or into data communication between parts of the -
system and change the contents of messages and possibly the associated
mes s age authenticators .
TH . AC T.119. 03 Manipulating the exception list by, for example, deleting entries or X X
i ns er ti ng new entries
-
TH . AC T.119. 0 4 Breach of data con fidentiality/privacy X X
Break into the system and get access to personal data of service users. -
By publishing the attack and the data, a major loss of trust in the system
can b e achieved i n the general publ ic.
TH . AC T.119. 0 5 D enial of ser vice X X
The whole or parts of the charging system may be prevented from -
op eration .
-
TH . AC T.119. 0 6 Manipulate the status of a large population of OBE X X
Cause OBE malfunction which leads to inability to access the -
system or unjusti fied enforcement to service users.
D.2.8.3 Goal 120: Raise in pro ile of the activists cause f
Activists may try to manipulate the system for the sole purpose of drawing the attention of the public
at large to the activists cause. This will often be achieved by claiming responsibility for a successful
attack after wards .
In general, there will not be very much difference in the attack methods employed compared with the
attacks describ ed in D. 2 . 8 . 2 .
D.2 .8.4 Goal 12 1: Direct furthering of activists cause
Activists may try to manipulate the system in order to directly further their cause. This might, for
example, be a reduction in the number of total driven kilometres in the case of an activist motivated by
green issues. A key factor here is to in fluence the behaviour of any party in the system, but especially
that of the service users. One of the ways to achieve this is to reduce the trust of service users in the
system, so that they will be less inclined to use it.
D.2 .8.5 Goal 12 2 : Reduction in credibility of the system
The activists cause may be the toll charging environment itself, for example, if he is opposed to the idea
of tolling as such. By trying to discredit the system in the eyes of users or politicians, he might try to
end the use of existing tolling systems or to prevent the establishing of new ones.

85
ISO/TS 192 99: 2 015(E)
D.2 .9 Attacker class 6: Communication provider
D.2 .9.1 General
The communication provider is the entity providing the communications infrastructure for the
operation of the EFC system. The different communication services of the system are provided by
several providers, for example, CN services, internet, etc. Using one speci fic service can involve several
toll service providers at the same time (e.g. internet) .
D.2 .9.2 Goal 12 3 : Increase network utilization
The communication provider is trying to optimize network utilization for the purpose of achieving
higher remuneration from toll service providers or toll chargers.
Table D.21 — Communication provider goal: Increase network utilization
DSRC GNSS
No. Threat
Related RQ
TH .CP.1 23 .01 Data corruption X X
Deliberately, corrupting the data f low leading to retransmission of packets RQ. IF.02
and thus, increased aggregate data flow.
D.2 .9.3 Goal 12 4: Decrease network utilization
The communication provider is trying to reduce the use of the network by flat rate communication user
(it is assumed that EFC systems have flat rate contracts for all OBE) to increase income from time or
volume metered communication users.
Table D.22 — Communication provider goal: Decrease network utilization
DSRC GNSS
No. Threat
Related RQ
TH .CP.1 24.01 Prevent data transfer n. a. X
By preventing data transfer from the OBE for an extended period of time, it RQ. IF.02
is possible to make the OBE data buffer over flow and the data to be lost,
thus, not being transferred over the network with a resulting decrease in
network utilization.
D.2 .9.4 Goal 12 5: Collecting travel behaviour
The communication provider establishes individual user tracking pro files and sells them to interested
third parties.
Table D.23 — Communication provider goal: Collecting travel behaviour
DSRC GNSS
No. Threat
Related RQ
TH .CP.1 25 .01 Data communication interception X X
The attack collects the usage data (e.g. vehicle position and mileage) by RQ. IF.02
data communication interception to generate service user tracking pro- RQ. IF.10
f iles. RQ.TC .90
RQ.TSP.90
RQ.TSP.91
86
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .CP.1 25 .02 Data traffic analysis n. a. X
The attack analyses the data communication traffic, i.e. the connection, RQ. IF.10
location, duration, and frequency of the communications to generate
service user tracking pro files.
D.2 .10 Attacker class 7: Enterprise
D.2 .10.1 General
The attacker class enterprise contains all kind of organizations with certain financial, technical,
and personnel resources. This class includes general organized commercial enterprises of either a
legitimate or illegitimate nature using their resources to make pro fit performing the attack against the
tolling system.
D.2 .10.2 Goal 12 6: Movement tracking
The aim of movement tracking is to know where a vehicle at a certain time is or what trips a vehicle
make over a certain time. This might have several reasons, for example:
— knowing the position of a vehicle or its freight of special value (e.g. steal the vehicle);
— tracking an individual (the driver);
— tracking the vehicle to discover business behaviour of a competitor.
Table D.2 4 — Enterprise goal: Movement tracking
DSRC GNSS
No. Threat
Related RQ
TH . EN.1 26.01 Bribing TSP or TC employee to get data X X
A main attack avenue may be to get access to data by bribing an employee RQ.ISMS.2
to act like a ‘spy’. The bribed employee may install a bypass data
connection to allow online access for the (criminal) enterprise or manually
download data from the system. In principle, all kinds of data can be
collected such as the movement and mileage data of targeted vehicles and
service user personal data.
TH . EN.1 26.02 Data communication interception on the communication provider to TSP X X

interface
RQ. IF.10
To intercept all data sent from the communication provider to the TSP and RQ.TC .90
use it for own purposes . RQ.TSP.90
RQ.TSP.91
TH . EN.1 26.03 Data communication interception on the TSP to TC interface X X
To intercept all data sent between the TC and the TSP and use it for own RQ.TC .90
purposes . RQ.TSP.90
TH . EN.1 26.0 4 Data communication interception on the air interface (e. g. OBE CN inter- n. a. X
face)
RQ. IF.10
To intercept all data sent from a speci fic OBE to the TSP over the air RQ.TSP.90
interface and use it for own purposes . RQ.TSP.91

87
ISO/TS 192 99: 2 015(E)
D.2 .10.3 Goal 12 7: Creation and distribution of cloned equipment
A (criminal) enterprise clones OBE or ICC and sells them to service users.
Table D.25 — Enterprise goal: Creation and distribution of cloned equipment
DSRC GNSS
No. Threat
Related RQ
TH . EN.1 27.01 C loning or faking of OBE and sell it to other service users X X
C loning or faking an existing OBE and its credentials or accounts (trusted RQ.TSP.0 8
obj ects) , on original OBE or on an also-cloned hardware, and selling the RQ.TSP.10
OBE to service users allowing them to avoid paying toll. RQ.TSP.19
RQ.TSP. 21
TH . EN.1 27.02 C loning or faking of ICC and sell it to other service users X X
C loning or faking an existing ICC and its credentials or accounts (trusted RQ.TSP.0 8
obj ects) , on original ICC or on an also-cloned hardware, and selling the RQ.TSP.10
ICC to service users allowing them to avoid paying toll. RQ.TSP.19
RQ.TSP. 21
D.2 .10.4 Goal 12 8: Disable/compromise system encryption
An enterprise demonstrates the vulnerability of the system encryption to discredit a competitor’s

implementation.
NOTE An enterprise has possibly more resources than other attackers and can break the cryptographic
algorithms. Yet, this is out of scope of the EFC security framework. This subclause is kept to document the
boundaries of the current EFC security framework.
Table D.26 — Enterprise goal: Disable/compromise system encryption
DSRC GNSS
No. Threat
Related RQ
TH . EN.1 2 8 .01 Compromise the system by exploiting weaknesses in the encryption algo - X X
rithms for recovery of diversi fied keys. -
TH . EN.1 2 8 .02 Disable receiving of information X X
Intercept data communication and replace data, certi ficates, hashes, or -

other key information to disable data decryption or veri fication of
signatures .
TH . EN.1 2 8 .03 Disable correct encryption and/or data signing X X
Exchange receiver certi ficate and/or encryption session key with a fake or -
a wrong (not from the appointed receiver) one.
D.2 .10.5 Goal 12 9: Steal equipment
A (criminal) enterprise steals OBE, road side, or other equipment either for analysing and cloning or for
reselling the equipment.
Table D.27 — Enterprise goal: Steal equipment
DSRC GNSS
No. Threat
Related RQ
TH . EN.1 2 9.01 Steal an OBE (analysing, cloning, or reselling) X X
Steal one or more OBE from service user vehicles or from a TSP stock. RQ.TSP.19
RQ.TSP. 20
88
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . EN.1 2 9.02 Steal an ICC (analysing, cloning, or reselling) X X
Steal one or more ICC from service user vehicles or from a TSP s tock. RQ.TSP.19
RQ.TSP. 20
TH . EN.1 2 9.03 Steal roadside equipment X X
Steal ins talled roadside equipment or equipment from a TC stock or RQ.TC . 21

premise.
D.2 .10.6 Goal 13 0: Extortion
A (criminal) enterprise could try to break into several parts of an EFC system to obtain sensitive data. It
can use this data either to extort money from targeted individuals, or to extort money from the involved
toll service provider or toll charger by threatening to disclose this information about their clients.
Table D.28 — Enterprise goal: Extortion
DSRC GNSS
No. Threat
Related RQ
TH . EN.13 0.01 Bribing TSP or TC employee to get data X X
A main attack avenue may be to get access to data by bribing an employee RQ.ISMS.2
to act like a ‘spy’. The bribed employee may install a bypass data
connection to allow online access for the (criminal) enterprise or
manually download data from the system. In principle, all kinds of data
can be collected such as the movement and mileage data of targeted
vehicles and service user personal data.
TH . EN.13 0.02 Data communication interception on the communication provider to TSP X X

interface
RQ. IF.10
To intercept all data sent from the communication provider to the TSP and
RQ.TC .90
use it for own purposes .
RQ.TSP.90
RQ.TSP.91
TH . EN.13 0.03 Data communication interception on the TSP to TC interface X X
purposes .
RQ.TSP.90
TH . EN.13 0.0 4 Data communication interception on the air interface (e. g. OBE CN inter- n. a. X
face)
RQ. IF.10
interface and use it for own purposes .
RQ.TSP.91
D.2 .11 Attacker class 8: Government
D.2 .11.1 General
The sovereign entity within whose domain the toll charger operates. That includes all government
departments and governmental organizations, for example, police and military forces, intelligence
services, etc. The government is characterized by signi ficant resources and signi ficant technical and
financial capability.

89
ISO/TS 192 99: 2 015(E)
D.2 .11.2 Goal 13 1: In theatre commercial advantage
This class of attack gives a commercial advantage to companies of the tolling scheme (e.g. toll service
providers and OBE manufactures) or other business in the domain of the government. The main target
is to collect information outside the legal framework that provides an advantage to the local companies.
If this is done within the legal framework, it is not a threat.
E xamples are the following:
— collecting information about using an OBE may be interesting for OBE manufacturers and toll
service providers
— tracking commercial vehicles to discover business behaviour and relationships that may give local
service users an advantage
— tracking private vehicles to discover their commercial behaviour and whereabouts which may give
local companies an advantage
NOTE Attacks not related to data collected and exchanged in the EFC system are out of scope of the current
threat analysis.
Table D.29 — Government goal: In theatre commercial advantage
DSRC GNSS
No. Threat
Related RQ
TH .GOV.131 .01 Access targeted information at the TC’s system X X
The targeted information is obtained through direct contact with the RQ.TC .90
(s tate-owned) TC which provides the data on request of the Government
after appropriate data mining.
TH .GOV.131 .02 Access detailed charge/location data at the TSP system X X
The targeted information is obtained through direct contact with the RQ.TSP.90
(s tate-owned) TSP which provides the data on request of the
Government after appropriate data mining.
D.2 .11.3 Goal 13 2 : Political targeting of individuals and organizations
Governmental organizations are able to control movements and/or discrediting individuals or

organizations based on their travelling behaviour. This will be done by collecting travelling data of
visited locations or travelled distance of individuals or members of organizations outside of the legal
framework by collecting travelling data of their vehicles. If this is done within the legal framework, it is
not a threat.
Table D. 30 — Government goal: Political targeting of individuals and organizations
DSRC GNSS
No. Threat
Related RQ
TH .GOV.132 .01 Data communication interception on the communication provider to TSP X X
interface
RQ. IF.10
The same attack as TH .GOV.133 .01 . RQ.TC .90
RQ.TSP.90
RQ.TSP.91
TH .GOV.132 .02 Data communication interception on the TSP to TC interface X X
The same attack as TH .GOV.133 .02 . RQ.TC .90

RQ.TSP.90
90
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .GOV.1 32 .03 Data communication interception on the air interface n. a. X
(e.g. OBE CN interface)
RQ. IF.10
The same attack as TH .GOV.1 33 .03 . RQ.TSP.90
RQ.TSP.91
TH .GOV.1 32 .0 4 Identify the vehicle/OBE at relevant locations X X
Use an appropriate installation to obtain an identi fier of the vehicle or RQ.TSP.90

OBE ’s.
D.2 .11.4 Goal 13 3 : Tracking of Individuals by interception of data communication
This class of attacks allows the Government the tracking of individuals by interception of data
communication outside the legal framework for several reasons.
NOTE For example, to catch criminals, supervise suspicious individuals, collecting traffic information, etc.
The tracking of users and vehicles is realized by data collected by data communication interception. If
this is done within the legal framework, it is not a threat.
Table D. 31 — Government goal: Tracking of individuals by interception of data communication
DSRC GNSS
No. Threat
Related RQ
TH .GOV.1 33 .01 Data communication interception on the communication provider to TSP X X
interface
RQ. IF.10
To intercept all data sent from the communication provider to the TSP RQ.TC .90
and use it for own purposes . RQ.TSP.90
RQ.TSP.91
TH .GOV.1 33 .02 Data communication interception on the TSP to TC interface X X
purposes . RQ.TSP.90
TH .GOV.1 33 .03 Data communication interception on the air interface (e.g. OBE CN n. a. X
interface)
RQ. IF.10
interface and use it for own purposes. RQ.TSP.91
D.2 .11.5 Goal 13 4: Tracking of individuals by direct access to data through power of authority
This class of attacks allows the Government the tracking of individuals by direct access to data through
power of authority outside the legal framework for several reasons.
NOTE For example, to catch criminals, supervise suspicious individuals, collecting traffic information, etc.
If this is done within the legal framework, it is not a threat.

91
ISO/TS 192 99: 2 015(E)
Table D. 32 — Government goal: Tracking of individuals by direct access to data through

power of authority
DSRC GNSS
No. Threat
Related RQ
TH .GOV.13 4.01 Access detailed charge/location data at the TC system X X
The targeted charge/location data are obtained through direct contact RQ.TC .90
with the (s tate-owned) TC which provides the data on request of the
government.
TH .GOV.13 4.02 Access detailed charge/location data at the TSP system X X
The targeted charge/location data are obtained through direct contact RQ.TSP.90
with the (s tate-owned) TSP which provides the data on reques t of the
government.
D.2 .12 Attacker class 9: Foreign state agency
D.2 .12 .1 General
A foreign state agency is de fined as any agency of any state except the state under whose jurisdiction
a particular toll scheme is operated. The foreign state agency is characterized by signi ficant resources
both technical and financial.
NOTE Most of the threats are covered by other requirements and security measures. A foreign state agency
has possibly more resources than the other attackers and can break the security measures de fined by the EFC
security framework. Yet, such speci fic threats and the respective intention of a foreign state agency (e.g. terrorist,
etc.) are out of scope of the EFC security framework. This subclause is kept to document the boundaries of the
current EFC security framework.
D.2 .12 .2 Goal 119: Societal destabilization
Manipulation of tolling systems might have destabilizing effects on society as a whole. This may be the
intention of activists motivated by anger or resentment against the political regime or the way of living
in one or more countries. Manipulation of tolling systems could have the following effects:
— reducing the trust of service users in the correct functioning of tolling systems and, by extension, of
any high-tech system;
— reducing trust of service users in toll chargers, toll service providers or toll charging environment
management, and, by extension, in any authority;
— endangering the financial stability of toll chargers or local or national governments by reducing
revenues from tolling operations;
— disrupting the maintenance of infrastructure due to lack of funds.
Table D. 33 — Hacker goal: Societal destabilization
DSRC GNSS
No. Threat
Related RQ
TH . FP.119.01 Large-scale disruption of GNSS signal n. a. X
By jamming or otherwise disrupting the GNSS signal in large areas, the -

OBE of a large number of service users of autonomous EFC systems will
stop functioning correctly.
92
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
T H . F P. 1 1 9 . 0 2 Breach of data integrity/non-repudiation X X
Break into the system or into data communication between parts of the -
system and change the contents of messages and possibly the associated
me s s a ge au th e n ti c a to r s .
T H . F P. 1 1 9 . 0 3 Manipulating the exception list by, e.g. deleting entries or inserting new X X
e n tr i e s .
-
T H . F P. 1 1 9 . 0 4 Breach of data con fidentiality/privacy X X
Break into the system and get access to personal data of service users. By -
publishing the attack and the data, a major loss of trust in the system can
b e ac h i e ve d i n th e ge n e r a l p u b l i c .
T H . F P. 1 1 9 . 0 5 D e n i a l o f s e r v ic e X X
The whole or parts of the charging system may be prevented from -
o p e r a ti o n .
T H . F P. 1 1 9 . 0 6 Manipulate the status of a large population of OBE X X
OBE will be caused to malfunction which causes inability to access the -
system or unjusti fied enforcement to service users.
D.2 .12 .3 Goal 13 5: Movement tracking
The foreign state agency may be interested in tracking certain persons (e.g. political activists or
government officials) in the toll domain.
Table D. 3 4 — Hacker goal: Movement tracking
DSRC GNSS
No. Threat
Related RQ
T H . F P. 1 3 5 . 0 1 Bribing TSP or TC employee to get data X X
T he s a me a t tac k s a s T H . E N . 1 2 6 . 0 1 . A m a i n at t ac k a ve nu e fo r fo r e i g n s t ate RQ.ISMS.2

agencies could be to get access to data by bribing an employee
to act like a “spy”. The bribed employee may install a bypass data
connection to allow online access for the (criminal) enterprise or manually
download data from the system. In principle, all kinds of data can be
c o l l e c te d , s u c h a s th e mo ve m e n t a n d m i l e a ge d a ta o f t a r ge te d ve h i c l e s a n d
s er vice u s er p ers o n a l data .
A major reason why a foreign state agency can use this attack (where, e.g.
activists cannot) is that it potentially has large sums of money at its
d i s c r e ti o n .
T H . F P. 1 3 5 . 0 2 H i r e h ac ke r s X X
Another way of attacking the system to obtain the desired data is by -
hiring hackers using the money in the possession of a foreign state

agency. Although these hackers then cease to be “ethical” hackers, many
, especially those related to the interception
o f the at t ac k s l i s te d i n D . 2 . 6
o f c o m mu n ic ati o n , w i l l s ti l l b e u s ab l e .
D.2 .12 .4 Goal 13 6: Extortion
A foreign state agency could try to break into several parts of an EFC system to obtain sensitive data or
to gain control over the system. It could use this data either to extort targeted individuals or to extort
the involved government by threatening to disclose information about their citizens on a large scale.
This is very close to the intention of movement tracking described above.
93
ISO/TS 192 99: 2 015(E)
Alternatively, the foreign state agency could extort the government, toll service providers, or toll
chargers by showing its control over (some part of) the EFC system and threatening to use this power
in a way disadvantageous to the party involved. In contrast to extortion by a (criminal) enterprise, its
object will usually not be money, but some form of collaboration with the foreign state agency’s goal.
This does, however, not change the methods used by the foreign state agency.
Table D.35 — Hacker goal: Extortion
DSRC GNSS
No. Threat
Related RQ
TH . FP.1 3 6 . 01 Switching off satellite system n. a. X
If the foreign state agency in question is in control of the satellite system -

used by the EFC system in question, it might threaten to disable the use of
the system for that particular EFC system (if possible).
TH . FP.1 3 6 . 02 Jamming the s atel lite s ignal n. a. X
The foreign state agency might threaten to jam the satellite signal used by -
the E FC in ques tion on a large scale.
TH . FP.1 3 6 . 03 Bribing TSP or TC employee to get data X X
T he s ame attack as TH . FP.1 3 5 .01 . RQ.ISMS.2

TH . FP.1 3 6 . 0 4 H ire hackers X X
T he s ame attack as TH . FP.1 3 5 .02 . -
D.2 .12 .5 Goal 13 7: International prestige
A foreign state agency could seek to enhance its own internal prestige by showing it is able to disrupt
large-scale EFC systems operation by other governments. Alternatively, it could seek to diminish the
prestige of other governments by disrupting their EFC systems. In this respect, the foreign state agency
comes very close to the motives of a hacker described in goals 115 to 118 (see D. 2 .7. 2 to D. 2 .7. 5 ) .
D.3 Asset based threat analysis
D.3 .1 General
For every identi fied asset, the possible threats will be listed with a description on possible damages.
The threat analysis does not assume any existing security measure. Therefore, an attack can exploit
any imaginable vulnerability.
One of the main targets is the identi fication of realistic threats without a bene fit for the threat
agent, especially if the threat agent is not a person or organization. Nevertheless, the current threat
analysis does not include threats by hardware, software, or other implementation faults. This includes
malfunction of equipment caused by inconsistent data received through an interface.
D.3 .2 Threatened Assets
This section identi fies objects subject to attacks in an EFC system called ‘threatened assets’. Threatened
assets require protection by certain security measures. The main types of threatened assets in the
current analysis are the following:
— important information objects such as described in ISO 17573;
— software such as OBE, ICC, and computer software;
— physical entities, e.g. OBE, ICC, RSE, and back end equipment;
— privacy of service users;
94
ISO/TS 192 99:2 015(E)
— intangibles such as toll chargers and toll service providers reputation and image.
Not all of the information obj ects as described in ISO 17573 are in the scope of the current Technical
Speci fication, i.e. the information objects in the EFC rules class are out of scope.
While this security architecture covers all information objects and interfaces, it has to be mentioned
that not all interfaces fully rely on technical implementations. Furthermore, technical standards are
not available for every interface.
D.3 .3 Compliance matrix
Most of the interface-related assets have been derived from the EFC architecture standard which
describes information objects. The following matrix matches the interfaces and assets from the system
model (see Figure D.1 ) to the analysed assets in the asset-based threat analysis.
Table D.36 — Compliance matrix of the asset based threat analysis
Interface Covered in
1) OBE user interface — Asset 20 9: OBE
2) OBE data interface(s) for value added services — Out of scope of this Technical Speci fication
3) OBE vehicle interface: Connections to the — Asset 20 9: OBE
vehicle, e.g. power supply, CAN bus, tachograph
signal, etc.
4) GNSS interface — Asset 20 9: OBE
5) OBE tampering — Asset 20 9: OBE

— Asset 213: TC and TSP central system
— Asset 219: Limited autonomy
6) DSRC interface — Asset 201: Information assets
— Asset 202: Infras tructure assets
— Asset 205: Customization information
— Asset 20 9: OBE
— Asset 211: RSE
— Asset 214: Road usage data
— Asset 216: Service user identi fication
7) OBE cus tomization and maintenance interface — Asset 205: Customization information
— Asset 216: Service user identi fication
8) OBE cellular network interface — Asset 201: Information assets
— Asset 202: Infras tructure assets
— Asset 20 4: OBE C harge report
— Asset 20 9: OBE
— Asset 217: Toll context data
9) OBE proxy to toll service provider interface — Asset 201: Information assets
(optional) — Asset 202: Infras tructure assets
— Asset 20 4: OBE C harge report
— Asset 20 9: OBE
— Asset 219: Limited autonomy

95
ISO/TS 192 99: 2 015(E)
Table D. 36 (continued)
Interface Covered in
10) Toll service provider to toll charger back end — Asset 201: Information assets
connection — Asset 203: Billing Details
— Asset 207: E xception list
— Asset 215: Trus t Obj ects
— Asset 221: Contractual conditions
— Asset 22 2: Operational rules
11) RSE interface to toll charger back end — Asset 207: E xception list
1 2) RSE compliance check interface for — Asset 211: RSE

license/number plate recognition (ANPR) — Asset 22 6: Enforcement data
13) TC personnel HMI and access to equipment — Asset 213: TC and TSP central system
— Asset 22 6: Enforcement data
14) TSP personnel HMI and access to equipment — Asset 213: TC and TSP central system
15 ) OBE dis tribution to TSP back end — Asset 213: TC and TSP central system
communication
16) Delivering of equipment (e. g. OBE ) and — Asset 20 9: OBE

service provision (e.g. communication services) by — Asset 213: TC and TSP central system
suppliers and subcontractors. This is not a real
interface, but attacks to be considered may be
performed during equipment development,
equipment manufacturing, service implementation,
or service operation.
17 ) The service user declares all contractual — Asset 206: Service user contract
parameters from the vehicle and for invoicing used information
to customize the OBE . — Asset 20 8: Customer service
— Asset 210: Service user privacy
— Asset 22 3: Complaints
18) Physical or contactless interface between — Asset 22 8: ICC

OBE and IC card
19) Physical or contactless interface for the loading of — Out of scope of this Technical Speci fication
the IC card
D.3 .4 Presentation of threats
The table below explains the template used for the asset based threat analysis.
Table D. 37 — Notation and relations of threats
No. Unique number for every threat according to the numbering scheme described in D.1 . 2 .
Threat A description of the actual threat (without having a concrete vulnerability in mind)
Description of the possible cause and damage of execution of the threat.

Related RQ Reference to the requirement(s) driven by the threat.
96
ISO/TS 192 99:2 015(E)
D.3 .5 Generic threats
D.3 .5.1 Asset 2 01: Information assets
Information assets are, in general, information objects representing some value (possibly representing
money) for an organization or person. These information objects have a generating process stored in
and exchanged between equipment (e.g. OBE , RSE , and back end) . The table below contains the generic
threats for these information assets.
Table D.38 — Generic threats to information assets
DSRC GNSS
No. Threat
Related RQ
TH . DT. 201 .01 Modify the data during transmission. X X
TH .OU T. 201 .01
Possible damage: RQ. IF.11
TH . SU. 201 .01
— violation of data integrity (loss of income).
TH .OU T. 201 .02 Modify the data stored in any equipment or Back End including a central X X
TH . SU. 201 .02 clus ter equipment.
RQ. DS .01
TH .TC . 201 .02
Possible damage: RQ. DS .02
TH .TSP. 201 .02
— violation of data integrity (loss of income). RQ. DS .05
TH .OU T. 201 .03 Deleting a message during transmission. X X

TH . SU. 201 .03
Possible damage: RQ. XX.01
— no availability of data (loss of income).
TH .OU T. 201 .03 Prevent data communication (denial of service attack) . X X
TH . SU. 201 .03
Possible damage: RQ. XX.01
TH . DT. 201 .05 Loss of data caused by accident, environmental incident, or equipment X X
TH . I T. 201 .05 failure.
RQ. XX.01
Possible damage:
TH .OU T. 2 01 .06 Modify the identi fication of the data originator X X
TH . SU. 201 .06
— violation of authenticity (loss of income). RQ. IF.1 2
TH .OU T. 201 .07 The originator of the data is a not an authorized person or entity. X X
TH . SU. 201 .07
— violation of authenticity (loss of income). RQ. IF. 20
TH .OU T. 201 .0 8 Replaying of a data communication message. X X

TH .TC . 201 .0 8
Possible damage: RQ. IF. 3 0
TH .TSP. 201 .0 8
— violation of authenticity (loss of income).
TH .OU T. 201 .09 Eavesdropping of data communication. X X

— breach of con fidentiality (disclosure of information to
unauthorized individuals or systems, violation of service user privacy).
TH .OU T. 201 .10 Read access to data stored in any equipment or back end. X X
TH . SU. 201 .10
TH .TC . 201 .10
TH .TSP. 201 .10
— breach of con fidentiality (disclosure of information to RQ.IM.01
unauthorized individuals or systems, violation of service user privacy). RQ.IM.02

97
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .OUT. 201 .11 Intercept a communication with fake recipient identi fication. X X
Data are sent to an unauthorized recipient. RQ. IF. 20
Possible damage:
— violation of authenticity;
— no availability of data (loss of income);
— breach of con fidentiality (disclosure of information to unauthorized
individuals or systems, violation of service user privacy).
TH . SU. 201 .1 2 Deny being the originator of an information or message. X X
TH .TC . 2 01 .1 2
Possible damage: RQ. IF.1 3
TH .TSP. 201 .1 2
— loss of non-repudiation (loss of income) .
TH . SU. 201 .13 Deny having received an information or message. X X

TH .TC . 2 01 .13
TH .TSP. 201 .13
— loss of non-repudiation (loss of income) .
TH.IM.201.14 Missing global security rules X X

TH .TC . 2 01 .14
The TCs and TSPs do not have a globally valid set of security rules RQ.IM.01
TH .TSP. 201 .14
(possibly de fined by an interoperability management). This leads to RQ.IM.02
unaligned security implementations with different levels of security at
the various TCs and TSPs and possible security holes.
Possible damage:
— undermine trust in the toll charging environment;
— no or incorrect tolling;
— loss of income;
individuals or systems, violation of service user privacy)
— violation of data integrity (loss of income);
— violation of authenticity (loss of income);
D.3 .5.2 Asset 2 02 : Infrastructure assets
Infrastructure assets are any kind of equipment used for the EFC system (e.g. OBE, RSE, or back end
equipment) not covered as a speci fic asset. This class of asset consists of two parts namely the physical
hardware and the software of the equipment. The table below contains the generic threats for these
infrastructure assets.
Table D. 39 — Generic threats to infrastructure assets
DSRC GNSS
No. Threat
Related RQ
TH . DT. 2 02 .01 Environmental incident. X X
TH . I T. 2 02 .01
Possible damage: RQ.TC . 20
— damage of the equipment; RQ.TC . 2 3
— data processing failure;
— loss of data (no availability of data, loss of income).
TH .OUT. 202 .02 Vandalism. X X
TH . SU. 202 .02
— damage of the equipment; RQ.TC . 2 3
— data processing failure; RQ.TSP.0 9
98
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .OU T. 2 02 . 03 Traffic accidents (only OBE and RSE). X X
TH . S U. 2 02 . 03
In GNSS only relevant for CCC and LAC. RQ.TC . 2 0
RQ.TC . 2 3
Pos s ible damage:
— damage of the equipment; RQ.TS P. 0 9
— data processing failure;

TH .OU T. 2 02 . 0 4 T heft of equ ipment. X X
TH . S U. 2 02 . 0 4
Pos s ible damage: RQ.TC . 2 1
— loss of equipment; RQ.TS P. 2 0
— loss of data (no availability of data, loss of income) and possibly;

—breach of con fidentiality (disclosure of information to unauthorized
TH .OU T. 2 02 . 0 5 Software modi fication. X X
TH . S U. 2 02 . 0 5
— violation of data integrity (loss of income); RQ.TSP. 0 5
— loss of data (no availability of data, loss of income) and possibly; RQ.TS P.40

TH . OU T. 2 02 . 0 6 D en ial of ser vice attack again s t data communication i nterfaces or X X
TH . S U. 2 02 . 0 6 i nternal software pro ces ses or s er vices .
RQ. X X. 01
Pos s ible damage:

D.3 .6 Asset 2 03 : Billing details
Re fined charge report of the OBE up to the level of details requested in the user bill including the
payment claim.
Table D.40 — Threats to billing details
DSRC GNSS
No. Threat
Related RQ
TH . D T. 2 03 . 01 B i l l i ng detai l s cou ld b e changed duri ng trans mi s s ion b etwe en TS P and TC X X
b ack end.
RQ. I F.11
Pos s ible damage:

— bi l l ing detai l data no longer u s able for bi l li ng the s er vice u ser or for
making a proper claim from the TC to the TSP;
— wrong data cou ld le ad to wrong i nvoices and TC clai ms .
TH . I T. 2 03 . 02 Billing details could be transmitted to an unauthorized party. X X

TH .OU T. 2 03 . 02
Pos s ible damage: RQ. I F. 2 0
TH .TS P. 2 03 . 02
— violation of service users privacy;
— los s of B i l li ng detai l s for fur ther pro ces s i ng and bi l li ng.
TH . I T. 2 03 . 03 Billing details could be sent from an unauthorized party. X X

TH .OU T. 2 03 . 03

— chargi ng the ser vice u ser for non- exi s ti ng u s age of the tol l domain .

99
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . I T. 2 03 . 0 4 The content of Billing details could be revealed to an unauthorized party. X X
TH . OU T. 2 03 . 0 4
Pos s ible damage: RQ.ISMS.2
TH .TC . 2 03 . 0 4
— undermine trust in the toll charging environment; RQ.TC .9 0
TH .TS P. 2 03 . 0 4
— violation of service users privacy.
TH . D T. 2 03 . 0 5 The transmission of billing details could be disturbed and delayed. X X
TH . I T. 2 03 . 0 5
TH . OU T. 2 03 . 0 5
— undermine trust in the toll charging environment; RQ.TC .95
TH .TS P. 2 03 . 0 5
— denial of service;
— negatively affect billing processes;
— violate ser vice levels agre ed with the TC .
TH . OU T. 2 03 . 0 6 The authenticity of sent billing details cannot be proven and/or its origin X X
TH .TS P. 2 03 . 0 6 i s repudiated .
RQ. I F.1 3
Pos s ible damage: RQ. I F.14
— no end-to-end security and therefore no acceptance of the billing

detai ls for fur ther pro ces s i ng and bi l li ng.
D.3 .7 Asset 2 04: OBE Charge Report
Table D.41 — Threats to OBE charge report
DSRC GNSS
No. Threat
Related RQ
TH . D T. 2 0 4. 01 A charge rep or t cou ld b e change d duri ng tran s mi s s ion b e tween front n . a. X
end and TS P b ack end.
RQ. I F.11
Pos s ible damage:

— charge report data no longer usable for billing the service user;
— wrong data cou ld lead to wrong i nvoices and TC clai ms .
TH . I T. 2 0 4. 02 A charge report could be transmitted to an unauthorized party. n . a. X

TH . OU T. 2 0 4. 02
TH . S U. 2 0 4. 02
— violation of service users privacy;
— lo s s of charge rep or t for fur ther pro ces s i ng and bi l li ng.
TH . I T. 2 0 4. 03 A charge report could be sent from an unauthorized party. n . a. X

TH . OU T. 2 0 4. 03

— chargi ng the ser vice us er for non- exi s ting us age of the tol l domai n .
TH . I T. 2 0 4. 0 4 T he content of a charge rep or t cou ld b e revealed to an unauthori ze d n . a. X

TH . OU T. 2 0 4. 0 4 party during transmission. RQ. I F.10
TH . S U. 2 0 4. 0 4
Pos s ible damage:
— violation of service users privacy
TH . D T. 2 0 4. 0 5 The transmission of charge reports could be disturbed and delayed. n . a. X
TH . I T. 2 0 4. 0 5
Pos s ible damage: RQ.TSP. 01
TH . OU T. 2 0 4. 0 5
TH . S U. 2 0 4. 0 5
— violate ser vice levels agre ed with the TC .
100
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .OU T. 2 0 4.06 The authenticity of sent charge reports cannot be proven and/or its n. a. X
TH . SU. 20 4.06 origin is repudiated.
RQ. IF.13
— no end-to-end security and therefore no acceptance of the charge
report for further processing and billing.
D.3 .8 Asset 2 05: Customization information
Table D.42 — Threats to customization information
DSRC GNSS
No. Threat
Related RQ
TH . DT. 205 .01 C hanging all or parts of the customization information (e. g. service X X
TH . SU. 205 .01 user contract, tariff classes, etc.) during transmission to the OBE .
RQ. IF.10
— wrong or no service user is invoiced for the road usage; RQ.TSP.92
— loss of income for TSP because no service user can be invoiced
(payment guarantee to TC until user/OBE is on exception list);
— loss of income caused by wrong tariff class.
TH . I T. 205 .02 Changing or deleting all or parts of the customization information s tored X X
TH . SU. 205 .02 in the OBE .
RQ. DS .01
— violation of data integrity (loss of income). RQ. DS .05
TH . DT. 205 .03 Changing all or parts of the customization information sent by the OBE. X X
TH . I T. 205 .03
RQ. IF.10
TH . SU. 205 .03
RQ. IF.11
TH . DT. 205 .0 4 Prevent OBE from updating cus tomization information. X X

TH . I T. 205 .0 4
RQ. XX.01
TH . SU. 205 .0 4
TH .TSP. 205 .05 Change of fee relevant cus tomization information over the air. X X
TH .TC . 205 .05
The personalization data in a GNSS OBE can be changed over the air RQ.TC .1 2
causing a sudden change of data transmitted to the RSE from one RQ.TSP.97
charging point to the next.
Possible damage:
— this could lead to negative effects in normal operation (e. g.
enforcement, fraud detection, etc.) if not properly agreed and tested
between TSP and TC (e. g. sudden change of vehicle group or Euro
emission category settings);
— in a failure condition, this could j eopardize tolling if the TSP
transmits wrong data to the OBE(s) .
D.3 .9 Asset 2 06: Service user contract information

101
ISO/TS 192 99: 2 015(E)
Table D.43 — Threats to service user contract information
DSRC GNSS
No. Threat
Related RQ
TH . DT. 2 06.02 Change of contract information during transmission (contract agent X X
TH . I T. 2 06.02 to the TSP) or storage in TSP back end.
RQ. DS .01
TH .OUT. 206.02
TH . SU. 206 .02
— wrong or no service user is invoiced for the road usage; RQ. DS .05
— loss of income for TSP because no service user can be; RQ. DS .07
invoiced (payment guarantee to TC until user/OBE is on exception list); RQ. IF.10
— loss of income caused by wrong tariff class. RQ. IF.11
TH . DT. 2 06.03 Loss of contract information during s torage in TSP back end. X X
TH .OUT. 206.03
— TSP loses income and may be no longer able to operate its RQ. DS .05
service
TH . DT. 2 06.0 4 Contract details are revealed to unauthorized third parties. X X

TH . I T. 2 06.0 4
TH .TSP. 206.0 4
— infringement of service user privacy; RQ. DS .02
— service user loses money by non-genuine and unauthorized RQ. DS .06
debiting based on his contractual account information. RQ. IF.10
RQ. IF.11
D.3 .10 Asset 2 07: Exception list
Any problems regarding the exchange of exception lists has direct effects on the shift of risk between
TC and TSP and can thus have signi ficant economic consequences.
The following threats can cause different types of damage to the different stakeholders in an EFC
system. These damages could be grouped into four main groups, namely,
— loss of reputation and personal integrity for the user,
— economical loss for the service user,
— loss of reputation and credibility for the operators, and

— economical loss for the operators.
102
ISO/TS 192 99:2 015(E)
Table D.44 — Threats to exception list
DSRC GNSS
No. Threat
Related RQ
T H . D T. 2 0 7. 0 1 L o s s/c h a n ge o f e xc e p t i o n l i s t du r i n g tr a n s m i s s i o n fr o m T S P to T C . X X
T H . I T. 2 0 7. 0 1
P o s s i b l e d a m a ge : RQ. D S . 0 7
— requested locking does not take effect;

T H .T S P. 2 0 7. 0 1
RQ. I F. 1 1
— wrong OBE gets locked;

T H .T C . 2 0 7. 0 1
RQ. I F. 14
— co ntrac tu a l co n s e que nce s . RQ.T C .9 9
T H . D T. 2 0 7. 0 2 L o s s/c h a n ge o f e xc e p t i o n l i s t du r i n g tr a n s m i s s i o n fr o m T C C S to R S E . X X
T H . I T. 2 0 7. 0 2
P o s s i b l e d a m a ge : RQ. I F. 1 1
— requested locking does not take effect;

T H . O U T. 2 0 7. 0 2
RQ. I F. 14
— wrong OBE gets locked;

T H .T C . 2 0 7. 0 2
— co ntrac tu a l co n s e que nce s .
T H . O U T. 2 0 7. 0 3 Transmission of exception list to unauthorized party. X X
T H .T S P. 2 0 7. 0 3
T H .T C . 2 0 7. 0 3
— loss of privacy.
RQ. I F. 2 0
RQ.T C .9 9
RQ.T S P. 1 8
T H . O U T. 2 0 7. 0 4 Placement of OBE on exception list by unauthorized party. X X
T H .T S P. 2 0 7. 0 4
T H .T C . 2 0 7. 0 4
— w r o n g O B E ge t s l o c ke d .
T H . D T. 2 0 7. 0 5 Delay of exception list transmission. X X
T H . I T. 2 0 7. 5
P o s s i b l e d a m a ge : RQ.T C .9 9
— delay in requested locking;

T H .T S P. 2 0 7. 0 5
RQ.T S P. 1 8
T H .T C . 2 0 7. 0 5
— co ntrac tu a l co n s e que nce s . RQ. X X . 0 1
103
ISO/TS 192 99: 2 015(E)
D.3 .11 Asset 2 08: Customer service
Cus tomer ser vice data can be information about the S Us p ersonal data or information ab out the OBE
used by the SU which can be contract, payment, and vehicle or usage data. The information is exchanged
between the S U and TSP.
Table D.45 — Threats to customer service
DSRC GNSS
No. Threat
Related RQ
TH . OU T. 2 0 8 . 01 The service user can be impersonated by a fraudulent person getting X X
acces s to the ser vice us ers p ersonal data.
RQ.TS P. 5 0
Pos s ible damage:

— violation of privacy;
— undermi ne tru s t i n the TS P op eration of the tol l chargi ng envi ron-
ment.
EXAMPLE An attacker can give the impression that he is the service user
and requires a printout of all stored user information, e.g. payment
me ans and tol l trans ac tions .
TH . OU T. 2 0 8 . 02 The service user can be impersonated by a fraudulent person giving false X X

i nformation or complai nts .
RQ.TS P. 5 0
Pos s ible damage:

— violation of privacy, e.g. incorrect enforcement;
— undermi ne tru s t i n the TS P op eration of the tol l chargi ng envi ron-
ment.
EXAMPLE An attacker can give the impression that he is the service user
and rep or ts an OB E s tolen asking for it to b e blo cked .
D.3 .12 Asset 2 09: OBE
Table D.46 — Threats to OBE
DSRC GNSS
No. Threat
Related RQ
TH . I T. 2 0 9. 01 Manipulation of stored data. X X
TH . OU T. 2 0 9. 01
TH . S U. 2 0 9. 01
Due to manipulation, the correct functionality of the OBE is no longer RQ. D S . 01
guarantee d. RQ. D S . 02
RQ. D S . 0 5
Pos s ible damage:
— cre ation of wrong chargi ng or en forcement re cords with the go al to
pay less toll;
— instability of the OBE due to bogus data;
— undermi ne tru s t i n the tol l chargi ng envi ron ment.
TH .TS P. 2 0 9. 02 Violation of data privacy requirements. X X
Pos s ible damage: RQ.TS P.42
— violation of privacy laws;

— collect and store more data than needed;
— violation of the service users privacy;
— undermi ne tru s t i n the tol l chargi ng envi ron ment.
104
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . DT. 209.03 Eavesdropping of OBE communication connection (CN or DSRC ) . X X
TH . I T. 20 9.03
TH .OU T. 20 9.03
TH . SU. 20 9.03
— reveal con fidential data to unauthorized parties; RQ. IF.11
— gain knowledge of internal data transmission;
— undermine trus t in the toll charging environment.
TH . DT. 209.0 4 Prevention of communication. X X

TH .OU T. 20 9.0 4
An attacker tries to prevent the working of communication channels RQ.TC .01
TH . SU. 20 9.0 4
(CN, DSRC), e.g. by covering the antennas. RQ.TC .02
RQ.TSP.01
Possible damage:
RQ.TSP.0 9
— prevention of correct toll event detection; RQ.TSP. 51
— less stability of the OBE operations.
TH .OU T. 20 9.05 Change of con figuration data. X X
TH . SU. 20 9.05
TH .TC . 209.05
An attacker tries to manipulate any con figuration data on the OBE RQ.TSP.40
(e.g. communication end points, retry limits, etc.).
Possible damage:
— less stability of the OBE operations;
— creation of wrong charging or enforcement records with the goal to
pay less toll;
— prevention of correct toll event detection;
TH .OU T. 2 09.06 Inspection of con figuration data. X X

TH . SU. 20 9.06
TH .TC . 209.06
An attacker can gain an advantage from inspecting con figuration data on RQ.TSP.41
the OBE .
Possible damage:
— prepare efficient attacks on the system using this speci fic knowledge.
TH .OU T. 20 9.07 An attacker tries to change the compliance check attributes inside the n. a. X
TH . SU. 20 9.07 OBE to a proper value for an enforcement authority. RQ.TSP.40
Possible damage:
— creation of incorrect charging and enforcement records in order to
pay less toll.
TH .OU T. 20 9.0 8 Internal knowledge on the OBE design. X X
TH . SU. 20 9.08
An attacker tries, using technical and organizational measures (such as RQ.ISMS.2
social engineering), to get internal or con fidential knowledge about the
OBE .
Possible damage:
— instability of the OBE;
— creation of incorrect charging and enforcement records in order
to pay less toll;
TH .OU T. 20 9.09 An attacker tries to manipulate or exchange hardware components to X X

TH . SU. 20 9.0 9 pay lower toll. RQ. XX.02
Possible damage:
— prevention of correct toll event detection.

105
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
T H . D T. 2 0 9 . 1 1 Mass failure of OBE after update over the air. X X
Mass failure of a signi ficant number of OBE after an update over the air.
T H . I T. 2 0 9 . 1 1
RQ.T S P. 70
T H .T S P. 2 0 9 . 1 1
This could be caused by

RQ.T S P. 71
— insufficient tests by the TSP,

— m a l fu n c ti o n du e to I T p r o b l e m s , o r
— c h a n ge o f S W du r i n g tr a n s m i s s i o n to O B E o ve r th e a i r.
P o s s i b l e d a m a ge :

— loss of income;
— additional cost to the TC by providing local OBE.
T H . D T. 2 0 9 . 1 2 Bad performance of a whole production charge or OBE type. X X
T H . I T. 2 0 9 . 1 2
B a d c o m mu n i c a ti o n p e r fo r m a nc e o f a wh o l e p r o du c ti o n c h a r ge o r O B E RQ.T S P. 8 0
type. This could affect a pure DSRC OBE or the DSRC part of a GNSS OBE
T H .T S P. 2 0 9 . 1 2
wh i l e c o m mu n i c ati n g w i th the R S E .

— insufficient charge testing by TSP,
— s ho r t l i ve d c o m p o n e n t s i n O B E , o r
— bad quality of internal antenna.


— loss of income;
106
ISO/TS 192 99:2 015(E)
D.3 .13 Asset 2 10: Service user privacy
Table D.47 — Threats to service user privacy
DSRC GNSS
No. Threat
Related RQ
TH .TSP. 2 10 . 01 C ollec tion of p ersonal data. X X
TH .TC . 2 10 . 01
This could be caused by RQ.TC . 5 0
— not necessary for toll collection, RQ.TC . 51
— use of data for other purp os e, RQ.TSP. 59
— other data than consented to by the service user (data subject), or
— provides data to third p arties .
Pos s ible damage:

TH .TSP. 2 10 . 02 C ollec ted p ers onal data not handled according to data protec tion laws X X
TH .TC . 2 10 . 02 and regulations .
RQ.TC . 5 0
This could be caused by RQ.TC . 51
— change, lo s s , or to o long s torage of data, RQ.TSP. 59
— providing no acces s to col lec ted s er vice user data, or
— no agreements between data controller and data pro ces sor/as s is tant.
Pos s ible damage:

TH .TC . 2 10 . 03 An organization identi fies the service user in cases where there is no X X
violation of the EFC system. RQ.TSP. 59
— violation of privacy. RQ.TC . 51
RQ.TSP. 59
TH .TSP. 2 10 . 0 4 A ser vice us er is s ubj ec t to enforcement due to lack of crucial data X X

TH .TC . 2 10 . 0 4 availability or improper data processing (e.g. no updated exception list in RQ.TC . 51
a charging p oint) .
RQ.TSP. 59
Pos s ible damage:
D.3 .14 Asset 2 11: RSE
Table D.48 — Threats to RSE
DSRC GNSS
No. Threat
Related RQ
TH .OU T. 2 11 .01 Vandalis m on the RSE , e. g. sho oting with guns on antennas , us ing X X
explo s ives on RSE cabinets or cutting cables .
RQ.TC . 2 0
Pos s ible damage:
— instability of the RSE;
— prevention of correc t tol l event detec tion.
TH . S U. 2 11 . 02 Traffic accidents damaging charging points. X X

— los s of income.

107
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .OUT. 211 .03 Theft of RSE . X X

— no tolling;
—disclosure of sensitive information like security keys.
TH .OUT. 211 .0 4 Faking an RSE . X X
Possible damage: RQ.TC . 2 2

— reading of data from all OBE passing the fake RSE for later use,
e.g. OBE impersonation or violation of privacy;
— undermine trust in the toll charging environment.
TH .OUT. 211 .05 Prevention of communication. X X
An attacker tries to prevent the working of communication channels, RQ.TC . 2 3

e.g. by covering the antennas or by jamming the DSRC link.
Possible damage:
— no or incorrect tolling.
TH .OUT. 211 .06 Modi fication or alteration of RSE software. X X

— incorrect tolling.
TH .OUT. 211 .07 Internal knowledge on the RSE design. X X

social engineering) to get internal or con fidential knowledge about RSE.
Possible damage:
TH . DT. 211 .0 8 Enforcement interface at RSE unavailable. X X

TH . I T. 211 .0 8
An OBE is not able to communicate with the enforcement equipment of RQ.TC .96
TH .OUT. 211 .0 8
the TC .

— broken antenna,
— misdirected antenna,
— no power supply to RSE, or

— I T failure in RSE station.
Possible damage:
— no or wrong enforcement of service user(s)
— loss of income
— additional cost to the TSP for customer service.
D.3 .15 Asset 2 12 : EFC stakeholder image and reputation
108
ISO/TS 192 99:2 015(E)
Table D.49 — Threats to EFC stakeholder image and reputation
DSRC GNSS
No. Threat
Related RQ
TH .TSP. 21 2 .01 An organization does not provide the required measures for ensuring X X
TH .TC . 21 2 .01 con fidentiality, integrity and accessibility of personal data. RQ.TC . 5 0
— loss of service users trust (violation of privacy); RQ.TSP. 59
— loss of credibility and reputation of the organization;
TH .TSP. 21 2 .02 An organization provides a third party with the collected personal data X X
TH .TC . 21 2 .02 or results of the management of the data collected in those cases where
RQ.TC . 20
personal data are part of such management.
Possible damage:
— loss of credibility and reputation of the organization;
— undermine trus t in the toll charging environment
— violation of service users privacy.
D.3 .16 Asset 2 13 : TC and TSP central system
NOTE If a group of TCs cooperate, they can use a central TC cluster equipment (e.g. EasyGo). The TC central
clus ter equipment functions as a central point of contact (i.e. data exchange H UB) for the cooperating TCs
towards the TSPs. This is considered to be a part of the TCs central system responsibility.
Table D.50 — Threats to TC and TSP central system
DSRC GNSS
No. Threat
Related RQ
TH .OU T. 21 3 .01 Knowledge about the internal toll charging process of the central system X X
TH . SU. 213 .01 of the TSP or TC is used to reduce the toll to be paid by a service user. RQ.ISMS.2
Possible damage: RQ.TC . 5 0
— attacker could gain an advantage in optimizing its other attacks;
— disclosure of business knowledge.
TH .TSP. 213 .02 Data misuse. X X

TH .TC . 213 .02
Service user and road usage data are not being handled according to RQ.TC . 5 0
privacy regulations. RQ.TC . 51
RQ.TSP. 59
Possible damage:
— reduce trust in the system;
— violation of laws, contracts, and service user privacy.
TH .OU T. 21 3 .03 Unauthorized physical access to central system data centre or X X
TH . SU. 213 .03 communication components.
RQ.ISMS.2
Possible damage:
— physical damage;
— theft of components;
— data manipulation, misuse, or deletion;
— violation of service user privacy.
TH .OU T. 21 3 .0 4 Unauthorized logical access to central system or communication inter- X X
TH . SU. 213 .0 4 faces.
RQ.ISMS.2
Possible damage:
— software manipulation or installation;
— data manipulation, misuse, or deletion;
— violation of service user privacy.

109
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . I T. 21 3 .05 Mass rejection of toll declarations or billing details. X X
The toll declarations or billing details transferred between a TC and TSP RQ. IF. 31
get massively rejected. RQ. IF. 32

— wrong data sent due to error in TC central system,
— data rejected due to error in TSP central system, or
— data compromised during transmission,
Possible damage:
— loss of income;
— additional cost to TC and TSP for error handling procedures .
TH . I T. 21 3 .06 Customer service system unavailable. X X
The access to the customer service system is unavailable for service users RQ.ISMS.2
and/or TSP employees.
— network unavailable,
— S W error, or
— server unavailable.
Possible damage:
— additional cost to the TSP for handling service users manually.
TH . DT. 21 3 .07 TC central system or central cluster equipment is not able to send/receive X X
TH . I T. 21 3 .07 data to/from the TSPs .
RQ.TC .95
Independent of sending either directly to the TSP or via a central TC
cluster equipment.

— IT failure in the TCs central system, or
— failure in the TCs data transmission equipment.
Possible damage:
— loss of income;
— no or wrong enforcement of service user(s) .
TH . I T. 21 3 .0 8 PoS service unavailable for speci fic OBE. X n. a.
Speci fic OBE are not serviced at the POS network due to a problem with RQ.TSP.96
this kind of OBE .

— wrong implementation of the personalization interface in the OBE ,
— wrong keyset in the POS, or
— S W error in the POS .
Possible damage:
— loss of income;
110
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . DT. 213 .09 PoS service globally unavailable. X n. a.
TH . I T. 213 .09
No OBE get serviced at the POS network due to a global unavailability of RQ.ISMS.2
the POS network.

— wrong implementation of the personalization interface in OBE ,
— wrong keyset in the POS,
— S W error in the POS , or
— network unavailable.
Possible damage:
— loss of income.
TH . DT. 213 .11 Mass failure of RSE after update of SW. X X

TH . I T. 213 .11
TH .TC . 213 .11
Mass failure of a signi ficant number of OBE after an update of an RSE. RQ.TC .70
RQ.TC .71
— insufficient tests by the TC,
— malfunction due to I T problems, or
— change of S W during transmission to RSE .
Possible damage:
— loss of income;
— additional cost to the TSP by more support to the SU.
D.3 .17 Asset 2 14: Road usage data
Road usage data are generated in the OBE by either externally collected information, as in the case of
autonomous systems, or a DRSC transaction, as in the case of DSRC systems.
Table D.51 — Threats to road usage data
DSRC GNSS
No. Threat
Related RQ
TH . DT. 214.01 Alteration of data stored in the tolling station in a DSRC based system or X n. a.
TH . I T. 214.01 during transmission to the back end.
RQ. DS .01
TH .OU T. 214.01
TH . SU. 214.01
— loss of income; RQ. DS .05
— wrong service user enforcement.
TH . DT. 214.02 Alteration of charge reports in an autonomous system. n. a. X

TH . I T. 214.02
TH .OU T. 214.02
— loss of income. RQ. DS .02
TH . SU. 214.02
RQ. IF.11
TH . DT. 214.03 Incorrect position indication in an autonomous system caused by n. a. X

TH . I T. 214.03 alteration of basic data (e. g. map data) .
RQ. DS .01
TH .TSP. 214.03
TH . SU. 214.03
— loss of income or overcharging; RQ. IF.11
— wrong service user enforcement.

111
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
T H . D T. 2 14 . 0 4 Data transfer corruption in an autonomous system. n. a. X
T H . O U T. 2 14 . 0 4
— loss of income or overcharging;

— w r o n g s e r v i c e u s e r e n fo r c e m e n t.
T H . D T. 2 14 . 0 5 A l te r ati o n o f d at a du r i n g a D S RC c o m mu n i c a ti o n . X n. a.
T H . O U T. 2 14 . 0 5
T H . S U . 2 14 . 0 5
— l o s s o f i n c o me .
D.3 .18 Asset 2 15: Trust objects
Trust objects can be cryptographic keys, certi ficates, revocation lists, and access points for
cryptographic services. They are exchanged between the TSP and TC.
Table D.52 — Threats to trust objects
DSRC GNSS
No. Threat
Related RQ
T H . D T. 2 1 5 . 0 1 A tr u s t o b j e c t c o u l d b e c h a n ge d du r i n g tr a n s m i s s i o n b e t we e n T C a n d T S P. X X
T H . O U T. 2 1 5 . 0 1

— unscheduled change of cryptographic keys and its connected
operational cost;
— p r o du c ti o n o f d a ta wh i c h c a n n o t b e r e p r o du c e d c o u r t- p r o o f o r
which cannot be used for payment claims.

T H . I T. 2 1 5 . 0 2 A Trust object could be transmitted to an unauthorized party X X
T H . O U T. 2 1 5 . 0 2

operational cost;

T H . I T. 2 1 5 . 0 3 A trust object could be sent from an unauthorized party X X
T H . O U T. 2 1 5 . 0 3

operational cost;
— p r o du c ti o n o f d a ta wh i c h c a n n o t b e r e p r o du c e d , c o u r t- p r o o f, o r

T H . I T. 2 1 5 . 0 4 The content of a trust object could be revealed to an unauthorized party X X
T H . O U T. 2 1 5 . 0 4 e i th e r du r i n g tr a n s m i s s i o n o r fr o m d at a s to r a ge .
RQ. D S . 0 1
— undermine trust in the toll charging environment; RQ. D S . 0 6
— unscheduled change of cryptographic keys and its connected RQ. I F. 1 0
operational cost; RQ. I F. 1 1

T H . D T. 2 1 5 . 0 5 The transmission of Trust Objects could be disturbed and delayed. X X
T H . I T. 2 1 5 . 0 5
P o s s i b l e d a m a ge : RQ. X X . 0 1
T H . O U T. 2 1 5 . 0 5
— den i a l o f s er vice .
112
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
T H . I T. 2 1 5 . 0 6 T he c r e ati o n o f tr u s t o b j e c t s i s n o t c a r r i e d o u t i n a tr u s te d a n d s e c u r e X X
T H .T S P. 2 1 5 . 0 6
T H .T C . 2 1 5 . 0 6
e n v i r o n m e n t.
RQ.ISMS.2

operational cost;
— p r o du c ti o n o f d a t a wh i c h c a n no t b e r e p r o du c e d c o u r t- p r o o f o r

T H . I T. 2 1 5 . 0 7 Wrong update of key set for OBE communication. X n. a.
T H .T S P. 2 1 5 . 0 7
T H .T C . 2 1 5 . 0 7
Wrong handling of key information. RQ.T C . 1 0
This could be caused by RQ.T C . 2 5
— wrong generation of key information by TSP, RQ.T S P. 8 1
— wrong manual entry of key information by TC, or

— wrong processing of key information.
— loss of income;
— no end-to-end security;
D.3.19 Asset 216: Service user identi ication f
Service user identi fication can be payment means, vehicle license plate number, vehicle attributes, and
authenticators, or OBE ID, receipt details, and authenticators. They are exchanged between the TSP
(OBE) and TC (RSE), i.e. from OBE -> RSE.
Table D.53 — Threats to service user identi ication f
DSRC GNSS
No. Threat
Related RQ
T H . D T. 2 1 6 . 0 1 A user identi fication could be changed during transmission between OBE X X
T H . I T. 2 1 6 . 0 1 a nd RS E .
RQ. I F. 1 1
T H . O U T. 2 1 6 . 0 1
— u n de r m i n e tr u s t i n the to l l c h a r g i n g e n v i r o n m e n t.
T H . I T. 2 1 6 . 0 2 A user identi fication could be transmitted to an unauthorized party. X X
T H . O U T. 2 1 6 . 0 2

— prepare efficient attacks on the system using this speci fic
knowledge;
— r e ad i n g o f d at a fr o m a l l O B E p a s s i n g th e fa ke R S E fo r l a te r u s e ,
e.g. OBE impersonation or violation of privacy.

T H . O U T. 2 1 6 . 0 3 A user identi fication could be sent from an unauthorized party, e.g. an X X
attacker faking OBE and sending false user identi fications to an RSE. RQ. I F. 1 2
— u n de r m i n e tr u s t i n the to l l c h a r g i n g e n v i r o n m e n t.
113
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . I T. 216 .0 4 The content of a user identi fication could be revealed to an unauthorized X X
TH .OUT. 216.0 4 party (eavesdropping).
RQ. IF.10
Possible damage:
TH . DT. 216 .05 The transmission of user identi fication could be disturbed, e.g. jamming X X
TH . I T. 216 .05 of DSRC link, or delayed.
RQ. XX.01
TH .OUT. 216.05
Possible damage:
— incorrect enforcement.
TH .TSP. 216 .06 Change of user identi fication over the air. X X
TH .TC . 216 .06
The user information in a GNSS OBE can be changed over the air, causing RQ.TC .1 2
a sudden change of data transmitted to the RSE from one charging point RQ.TSP.97
to the next.
Possible damage:
— this could lead to negative effects in normal operation (e. g.
enforcement, fraud detection, etc.) if not properly agreed and tested
between TSP and TC (e.g. sudden change of license plate or Nationality);
— in a failure condition this could j eopardize tolling, if the TSP
transmits wrong data to the OBE(s) .
D.3 .2 0 Asset 2 17: Toll context data
Toll context data are being provided by the toll charger to the toll service provider.
Table D.5 4 — Threats to toll context data
DSRC GNSS
No. Threat
Related RQ
TH . DT. 217.01 Toll context data could be changed during transmission. X X

— toll context data no longer usable for toll event detection;
— wrong data could lead to wrong invoices and TC claims .
TH . I T. 217.02 Toll context data could be transmitted to an unauthorized party. X X

TH .OUT. 217.02
Possible damage: RQ. DS .0 8
TH .TSP. 217.02
— undermine trust in the toll charging environment; RQ. IF. 20
— loss of toll context data for further processing and billing. RQ.TC .97
RQ.TSP.17
TH . I T. 217.03 Toll context data could be sent from an unauthorized party. X X

TH .OUT. 217.03
— undermine trust in the toll charging environment; RQ. IF. 20
— charging the user for non-existing usage of the toll domain. RQ.TC .91
RQ.TSP.13
114
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . DT. 217.0 4 The transmission of toll context data could be disturbed and delayed. X X
TH . I T. 217.0 4
TH .OU T. 217.0 4
TH .TSP. 217.0 4
— violate service levels agreed with the TC .
TH .OU T. 217.05 The authenticity of sent toll context data cannot be proven and/or its X X
TH .TSP. 217.05 origin is repudiated.
RQ. IF.13
Possible damage:
— no end-to-end security and therefore no acceptance of the toll
context data for further processing.
TH .TC . 217.06 TC provides wrong or incomplete toll context data. X X
The TC provides wrong or incomplete data (e. g. VAT ID, address data, RQ. DS .07
contact information, toll domain layout, pricing information, etc.) to the RQ. DS .07
TSP. RQ.TC .98
Possible damage:
— loss of income or overcharging;
— wrong invoicing of service user(s);
— additional cost to the TSP for cus tomer service.
D.3 .2 1 Asset 2 18: Payment means
The payment means is part of the contract information of the service user. Nonetheless, some special
threats arise for payment means.
Table D.55 — Threats to payment means
DSRC GNSS
No. Threat
Related RQ
TH . DT. 218 .02 Payment means validation process could be intercepted by an unauthor- X X
TH . I T. 218 .02 ized party. RQ. IF.11
TH .OU T. 218 .02
— loss of income; RQ. IF.1 3
— wrong service user pays. RQ. IF.14
TH . I T. 218 .03 The content of payment means stored/during transmission could be X X

TH .OUT. 218 .03 revealed to an unauthorized party. RQ. DS .01
TH .TSP. 218 .03
TH .TC . 218 .03
— undermine trust in the toll charging environment; RQ. DS .06
TH .OUT. 218 .05 Payment means stored/during transmission could be forged by an X X

TH .TSP. 218 .05 unauthorized party. RQ. DS .01
TH . SU. 218 .05
— undermine trust in the toll charging environment; RQ. DS .05
— loss of income; RQ. IF.10
RQ. IF.1 2
RQ. IF.13
RQ. IF.14

115
ISO/TS 192 99: 2 015(E)
D.3 .2 2 Asset 2 19: Limited autonomy
Amount of money the OBE is allowed to use autonomously before connecting to the proxy or the TSPs
back end system.
Table D.56 — Threats to limited autonomy
DSRC GNSS
No. Threat
Related RQ
TH . DT. 219.01 Wrong amount written to OBE during customization. n. a. X
TH . I T. 219.01
Possible damage: RQ.TSP.92
TH .OUT. 219.01
TH .TSP. 219.01
— amount used autonomously too high;
— malfunction of OBE .
TH .OUT. 219.02 Unauthorized change of amount s tored in OBE . X X

TH . SU. 219.02
TH .TC . 219.02
— amount used autonomously too high; RQ.TSP.40
— break-up of limitation.
D.3 .2 3 Asset 2 2 0: EFC schema
New or amended EFC schema (toll domain statement) .
Table D.57 — Threats to the EFC schema
DSRC GNSS
No. Threat
Related RQ
TH . DT. 2 20.01 An EFC schema could be changed during transmission between X X
TH .OUT. 2 20.01 interoperability management and TSP. RQ. IF.11
Possible damage:
— misalignment between TSP and TC;
TH .OUT. 2 20.02 An EFC schema could be sent from an unauthorized party to either TSP X X
or TC , or both.
RQ. IF. 20
Possible damage:
— wrong data could lead to wrong invoices and TC claims .
TH . DT. 2 20.03 The transmission of EFC schema could be disturbed, so causing a delay X X
TH . I T. 2 20.03 in acceptance between TSP and TC .
RQ. IF.02
TH .OUT. 2 20.03
Possible damage:
— deny correct billing processing.
TH .OUT. 2 20.0 4 The authenticity of the sent EFC schema cannot be proven and/or the X X
origin is repudiated.
RQ. IF.1 3
Possible damage:
— no end-to-end security and no acceptance of the EFC schema for
further processing and billing;
— possible misalignment between TSP and TC .
D.3 .2 4 Asset 2 2 1: Contractual conditions
Contractual conditions can be imposed by a toll charger on the toll service providers or can be imposed
by a toll service provider on its service users.
116
ISO/TS 192 99:2 015(E)
Table D.58 — Threats to contractual conditions
DSRC GNSS
No. Threat
Related RQ
TH . DT. 221 .01 The contractual conditions could be changed during transmission to a X X
TH . I T. 221 .01 TSP.
RQ. IF.11
TH .OU T. 2 21 .01
Possible damage:
— TSP might base its business on wrong contractual conditions;
TH . DT. 221 .02 The contractual conditions could be changed during transmission to a X X
TH . I T. 221 .02 (potential) service user.
RQ. IF.11
TH .OU T. 2 21 .02
Possible damage:
— SU might base its business on wrong contractual conditions;
TH .OU T. 2 21 .03 The contractual conditions could be sent from an unauthorized party. X X
Possible damage: RQ. IF. 20

— TSP or SU might base their business on wrong contractual conditions;
TH . DT. 221 .0 4 The (published) contractual conditions are not available for a TSP or a X X
TH . I T. 221 .0 4 service user upon demand (denial of service) .
RQ. XX.01
TH .OU T. 2 21 .0 4
Possible damage:
TH .TC . 221 .0 4
— loss of business because SU might choose another TSP;
TH . DT. 221 .05 The transmission of the contractual conditions could be disturbed or X X
TH . I T. 221 .05 delayed (denial of service).
RQ. XX.01
TH .OU T. 2 21 .05
Possible damage:
— loss of business because SU might choose another TSP;
TH .TSP. 221 .06 The TSP or service user could not determine a liable originator of the X X
TH .TC . 221 .06 contractual conditions beyond doubt.
RQ. IF.13
Possible damage:
— TSP or SU cannot hold someone responsible for any damage caused
by receiving wrong contractual conditions;
TH .TSP. 221 .07 The TSP or service user could not determine validity period for the X X
TH .TC . 221 .07 contractual conditions beyond doubt.
RQ. IF.11
Possible damage:
— TSP or SU cannot hold the originator responsible for any damage
caused by using invalid contractual conditions;
D.3 .2 5 Asset 2 2 2 : Operational rules
Operational rules can be imposed by the interoperability management on the TCs and TSPs or can be
imposed by a TC to TSPs (e.g. EETS decision).

117
ISO/TS 192 99: 2 015(E)
Table D.59 — Threats to operational rules
DSRC GNSS
No. Threat
Related RQ
TH . DT. 222 .01 The operational rules could be changed during transmission to a TC . X X
TH . I T. 222 .01
TH .OUT. 22 2 .01
— TC might base its business on wrong operational rules;
TH . DT. 222 .02 The operational rules could be changed during transmission to a TSP. X X
TH . I T. 222 .02
TH .OUT. 22 2 .02
— TSP might base its business on wrong operational rules;
TH .OUT. 22 2 .03 The operational rules could be sent from an unauthorized party. X X

— TC or TSP might base its business on wrong operational rules;
TH . DT. 222 .0 4 The transmission of the operational rules could be disturbed or delayed X X
TH . I T. 222 .0 4 (denial of service) .
RQ. XX.01
TH .OUT. 22 2 .0 4
Possible damage:
— loss of business because a TC or TSP might not be able to operate
according to the rules in due time;
TH . DT. 222 .05 The (published) operational rules are not available for a TC or TSP upon X X
TH . I T. 222 .05 demand (denial of service) .
RQ. XX.01
TH.IM.222.05 Possible damage:
TH .OUT. 22 2 .05
— TC or TSP might not be able to operate according to this rules in due
TH .TC . 2 22 .05
time;
TH .TSP. 2 22 .06 The TC or TSP could not determine a liable originator of the operational X X
TH .TC . 2 22 .06 rules beyond doubt. RQ. IF.1 3
Possible damage:
— TC or TSP cannot hold someone responsible for any damage because
of receiving wrong operational rules;
TH .TSP. 2 22 .07 The TSP or service user could not determine validity period for the X X
TH .TC . 2 22 .07 operational rules beyond doubt. RQ. IF.11
Possible damage:
— TSP or SU cannot hold the originator responsible for any damage
because of wrong operational rules;
D.3 .2 6 Asset 2 2 3 : Complaints
A complaint can be sent from a TC or a TSP to the interoperability management from TSP to a TC, from
a TC to a TSP, or from a SU to a TC or TSP.
118
ISO/TS 192 99:2 015(E)
Table D.60 — Threats to complaints
DSRC GNSS
No. Threat
Related RQ
TH . DT. 223 .01 The complaint could be changed during transmission to the X X
TH.IM.223.01 interoperability management, TC or to TSP or to a service user. RQ. IF.11
TH .OU T. 2 23 .01
Possible damage:
— IM, TC or TSP suffers loss for processing/correcting a wrong
complaint;
TH .OU T. 2 23 .02 The complaint could be sent from an unauthorized party. X X

— receiver suffers loss for processing/correcting a wrong complaint;
TH . I T. 223 .03 The complaint could be sent to an unauthorized party. X X

TH .TSP. 223 .03
TH . SU. 22 3 .03
TH .TC . 223 .03
— infringement of business con fidentiality;
— loss for resending it to the correct party and because of the delay;
TH . DT. 223 .0 4 The transmission of the complaint could be disturbed or delayed X X

TH . I T. 223 .0 4 (denial of service) .
RQ. XX.01
TH .OU T. 2 23 .0 4
Possible damage:
— inadmissibility of the complaint because a deadline was not met;
— loss because of the need for a correction and the delay in processing
the complaint;
TH . DT. 223 .05 The content of a complaint could be revealed to an unauthorized party. X X
TH . I T. 223 .05
TH .OU T. 2 23 .05
TH .TSP. 223 .05
— infringement of business con fidentiality; RQ. DS .02
— undermine trus t in the toll charging environment. RQ. DS .06
RQ. IF.10
D.3.27 Asset 224: Certi ication f
The responsibilities of certi fication authority include certifying EFC constituents as well as de fining the
certi fication requirements for the actors involved and equipment used in the EFC system. The role of
the certi fication bodies is to certify the objects (roles and equipment) in a toll charging environment.
Table D.61 — Threats to certi ication

f
DSRC GNSS
No. Threat
Related RQ
TH . DT. 224.01 Application for certi fication (TC, TSP) could be changed during X X
TH . I T. 224.01 transmission to the certi fication authority. RQ. IF.11
TH .OU T. 2 24.01
— certi fication authority suffers loss for processing/correcting a wrong
application;
TH . DT. 224.02 Granted certi fication could be changed during transmission to the X X
TH . I T. 224.02 applicant (TC , TSP) .
RQ. IF.11
TH .OU T. 2 24.02
— applicant (TC,TSP) and certi fication authority suffers loss for timing
and correcting a wrong certi fication;

119
ISO/TS 192 99: 2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH . OU T. 2 2 4. 03 The application could be sent from an unauthorized party. X X
— certi fication authority suffers loss for processing an unauthorized

application;
— u ndermi ne tru s t i n the tol l chargi ng envi ronment.
TH . OU T. 2 2 4. 0 4 Candidate applicant (TC, TSP) can falsify certi ficate. X X

TH .TS P. 2 2 4. 0 4
Pos s ible damage: RQ. I F.11
TH .TC . 2 2 4. 0 4
— u ndermi ne tru s t i n the tol l chargi ng envi ronment. RQ. I F.1 2
TH . OU T. 2 2 4. 0 5 Certi ficate can be generated and issued by a non-certi fied authority. X X
Pos s ible damage: RQ. I F.1 2
— unfair and unjusti fied pro fits;

— inadmissibility;
TH.IM.224.06 The valid time period of the certi ficate could have elapsed or could not X X
TH .TS P. 2 2 4. 0 6 be determined beyond any doubt.
RQ. I F.11
TH .TC . 2 2 4. 0 6
Pos s ible damage:
— unfair and unjusti fied pro fits;
TH .TS P. 2 2 4. 07 TC or TSP could use uncerti fied equipment. X X

TH .TC . 2 2 4. 07
Pos s ible damage: -
— unfair and unjusti fied pro fits

— lo s s of bus ines s to other p ar ties due to p os s ible wrong event
detection and compliance checking;
D.3.28 Asset 225: Quality assurance parameter reporting

The KPI quality assurance parameter reporting describes the performance of agreed parameters
between the TSP and TC .
Table D.62 — Threats to quality assurance parameter reporting
DSRC GNSS
No. Threat
Related RQ
TH .TS P. 2 2 5 . 01 T hre ats as describ e d in as set 2 01 . X X
TH .TC . 2 2 5 . 01
— wrong or mi s s i ng i n formation for che cki ng the s er vice level RQ.TC . 2 2
agreements b etwe en the TS Ps and TC s . RQ.TC .95

RQ.TC .9 6
RQ.TS P.9 6
D.3 .2 9 Asset 2 2 6: Enforcement data
Enforcement is based on assets of the RSE and the TCs central system.
The handling of the enforcement process is covered by this asset.
12 0
ISO/TS 192 99:2 015(E)
Table D.63 — Threats to enforcement data
DSRC GNSS
No. Threat
Related RQ
TH . DT. 226 .01 Enforcement procedure s tarted although the OBE declared the presence X X
TH . I T. 226 .01 in a toll domain correctly. RQ.TC .01
Enforcement is directed agains t a service user although his OBE declared RQ.TC . 3 0
the presence in a toll domain correctly and a toll declaration was pro - RQ.TSP. 51
duced.
Possible damage:
— wrong enforcement of service user(s)
— additional cost to the TSP for customer service
TH . I T. 226 .02 Wrong service user is enforced. X X

TH .TSP. 226 .02
Enforcement is directed agains t the wrong service user. RQ.TC . 31
TH .TC . 226 .02
— error in LPR by TC,
— error in matching evidence data to SU data in IT system, or
— wrong delivery of SU data by TSP.
Possible damage:
— wrong enforcement of service user(s);
— additional cost to the TSP for customer service.
TH . DT. 226 .03 Evidence data not court proof. X X

TH . I T. 226 .03
TH .TC . 226 .03
Cryptographic information is compromised during recording, RQ.TC . 32
transmission or s toring of evidence data.
Possible damage:
— production of data which cannot be reproduced court-proof;
— loss of income.
D.3 .3 0 Asset 2 2 7: Invoice
An invoice issued by the TSP has always to be correct in the legal framework of the TC or the TSP
depending on the nature of the toll (fee, tax, custom, etc.) and the entity the invoice is made out for
(either TC or TSP) .
Table D.64 — Threats to invoices
DSRC GNSS
No. Threat
Related RQ
TH .TC . 227.01 The invoice is not made out according to the invoicing rules of the X X
TH .TSP. 227.01 country of the TC. RQ.TC .06
Possible damage: RQ.TSP. 5 6
— loss of VAT reclaim for service user;
— excessive claims by service users;
TH .TSP. 227.02 The invoice is not made out according to the invoicing rules of the coun- X X
try RQ.TC .06
of the TSP.
RQ.TSP. 5 6
Possible damage:
— loss of VAT reclaim for service user;
— excessive claims by service users;

12 1
ISO/TS 192 99: 2 015(E)
D.3 .3 1 Asset 2 2 8: ICC
An ICC is issued by the TSP or one of his subroles (e.g. a PSP). The threats to the ICC are somewhat
s i m i l a r to the th re ats to a n O B E .
Table D.65 — Threats to ICC
DSRC GNSS
No. Threat
Related RQ
T H . I T. 2 2 8 . 0 1 Manipulation of stored data. X X
T H . O U T. 2 2 8 . 0 1
T H . S U. 2 2 8 . 01
Due to manipulation, the correct functionality of the ICC/OBE is no longer RQ. D S . 0 1
g u a r a n te e d . RQ. D S . 0 2
RQ. D S . 0 5
— creation of wrong charging records with the goal to pay less toll;
— instability of the ICC/OBE due to bogus data;
— u n d e r m i n e tr u s t i n th e to l l c h a r g i n g e nv i r o n me n t .
T H .T S P. 2 2 8 . 0 2 Violation of data privacy requirements. X X
P o s s i b l e d a m a ge : RQ.T S P. 42
— violation of privacy laws;

— collect and store more data than needed;
— violation of the service users privacy;
T H . D T. 2 2 8 . 0 3 E ave s d r o p p i n g o f O B E to I C C c o m mu n i c ati o n c o n n e c ti o n . X X
T H . I T. 2 2 8 . 0 3
T H . O U T. 2 2 8 . 0 3
Such a connection can either be physical or contactless. RQ. I F. 1 0
RQ. I F. 1 1
T H . S U. 2 2 8 . 0 3 P o s s i b l e d a m a ge :
— reveal con fidential data to unauthorized parties;

— gain knowledge of internal data transmission;
T H . D T. 2 2 8 . 0 4 P r e ve n ti o n o f c o m mu n i c ati o n . X X
T H . O U T. 2 2 8 . 0 4
T H . S U. 2 2 8 . 0 4
An attacker tries to prevent the working of physical or contactless RQ.T C . 0 1
c o m mu n i c a ti o n c h a n n e l s . RQ.T C . 0 2
RQ.T S P. 0 1
— prevention of correct toll event detection; RQ.T S P. 0 9
— less stability of the ICC/OBE operations. RQ.T S P. 5 1
T H . O U T. 2 2 8 . 0 5 Change of con figuration data. X X
T H . S U. 2 2 8 . 0 5
An attacker tries to manipulate any con figuration data on the ICC RQ.T S P. 4 0
T H .T C . 2 2 8 . 0 5
(e.g. communication end points, retry limits, etc.).
— less stability of the ICC/OBE operations;

— creation of wrong charging records with the goal to pay less toll
— p r e ve n ti o n o f c o r r e c t to l l e ve n t de te c ti o n
T H . O U T. 2 2 8 . 0 6 Inspection of con figuration data. X X
T H . S U. 2 2 8 . 0 6
T H .T C . 2 2 8 . 0 6
An attacker can gain an advantage from inspecting con figuration data RQ.T S P. 41
o n th e I C C .

12 2
ISO/TS 192 99:2 015(E)
DSRC GNSS
No. Threat
Related RQ
TH .OU T. 2 2 8 .0 8 Internal knowledge on the OBE design. X X
TH . SU. 22 8 .0 8
social engineering) to get internal or con fidential knowledge about the
ICC .
Possible damage:
— less stability of the ICC/OBE operations;
— creation of incorrect charging records in order to pay less toll

12 3
ISO/TS 192 99: 2 015(E)
Annex E
(informative)
Security policies
E.1 General
E.1.1 Overview of this Annex
The scope of this Annex is to provide an example of a security policy for an interoperable cluster of EFC
systems. This Annex also explains the hierarchical structure based on this top level security policy
supplemented by the second level security policies of each entity involved in this EFC cluster.
E.1.2 Motivation for the need of security policies
Based on ISO/IEC 27002:2013, Clause 5, the objective of a security policy is to provide management (of
the stakeholder, i.e. TC, TSP, and IM) direction and support for information security in accordance with
business requirements and relevant laws and regulations.
Management should set a clear policy direction in line with business objectives and demonstrate
support for, and commitment to, information security through the issue and maintenance of an
information security policy across the organization.
The overall information security policy of an EFC scheme shall be issued by the owner of the scheme
(e.g. the government sponsoring a country wide interoperable scheme) or if there is no owner by the
Interoperability Management (e.g. represented by a steering committee set-up by the involved operators).
The EFC scheme security policy de fines the boundaries as a guideline for the security policies of the
operators (e.g. TC and TSP). The EFC scheme security policy contains no risk analysis because neither
the system owner nor the IM does not know the detailed vulnerabilities of the system or the costs of the
required security measures.
Every TC and TSP shall have its own security policy (driven by the EFC scheme policy) which describes
the general approach to security including the security management system, basic documents, the
assets to be protected, and a risk analysis. This forms the basis for any security implementation.
E.2 Example EFC scheme security policy
E.2 .1 Motivation for information security
Information and the supporting processes, systems, and networks are very important business assets
in EFC systems. The whole business model is based on collecting information, handling the information
collected, and then collecting the payment from service users based on the processed collected
information. Information security is essential for the accuracy, the trustworthiness, and the reliability
and availability of the EFC system.
The XY1) EFC system is growing a network of several previously independent EFC systems and it is
evident that the security threats to the whole integrated and interoperable XY EFC system is increasing
each time a new system is added. The threats can both be internal (inside the XY organization) and
external. E xamples of such threats are computer-assisted fraud, sabotage, vandalism, and service
denial (e.g. “I was not there”) enabled by unauthorized access, computer hacking, and malicious code.
1) XY is the placeholder for the name of a real EFC system.

12 4
ISO/TS 192 99:2 015(E)
Fires and floods are also examples of threats that could cause severe damage and loss for the operators
and service users of the system.
The threats can cause different types of damage to the different stakeholders in XY EFC system. These
damages could be grouped into the following four main groups (listed in preferred order) :
— loss of reputation and personal integrity for the user;

— economical loss for the service user;
— loss of reputation and credibility for the operators;
— economical loss for the operators.
E.2 .2 Purpose of the security policy
This information security policy expresses the XY EFC system Steering Committee’s (SC) commitment
to the implementation, maintenance, and improvement of its information security management system.
The policy contains statements for how SC intends to protect information. Each statement requires
more detailed procedures and practices to be implemented which, in turn, will contribute to the overall
reduction in risk as a whole. The policy is a way of assuring the con fidentiality, integrity, and availability
of assets in the XY EFC system organizations and its information and communication architecture and
infrastructure for the bene fit of the XY EFC system service users, TSP, and TC.
The security policy shall also contribute to the XY EFC system organizations goals and strategies and shall
support and protect the organization’s operations, competitiveness, general con fidence, and reputation.
E.2 .3 Scope of the security policy
This policy applies to all employees including permanent and temporary staff and any other persons
who require access to information and/or manage information as part of the XY EFC system service
provision playing the whole or parts of any of the XY EFC system roles shown in Figure E .1 . It also
applies to any facilities management resource which performs a service on behalf of XY EFC system.
Furthermore, this Technical Speci fication de fines the approaches that will be taken in order to ensure
that the level of security implemented in the XY EFC service is in accordance with the associated risks.

12 5
ISO/TS 192 99: 2 015(E)
Steering
Committee
Interoperability
Figure E .1 — Security policy scope — Personnel of roles covered
The policy also applies to the XY EFC system information and communication infrastructure including
the fo l lo w i n g:
— physical assets such as OBE, RSE, computer equipment, etc. shown as entities in F i g u re E . 2 ;
— software assets stored and used by the physical assets;
— i n fo r m atio n a s s e ts s uch as i n fo r m atio n s to re d in d at ab a s e s , i n fo r m ati o n e xch a n ge d on i n te r face s
between the physical assets, user manuals, procedures, etc.;

— interfaces between the physical assets shown as interfaces in F i g u re E . 2 .
12 6
ISO/TS 192 99:2 015(E)
Figure E .2 — Assets and interfaces covered by XY EFC security policy
E.2 .4 Policy statements
E.2 .4.1 General
The policy statements de fine the overall security principles to be followed by each organization and
operator of the XY EFC system.
E.2 .4.2 General policy statements
EFC-PS-1: Information security is the protection of information stored, exchanged on interfaces, and
handled by the personnel and assets involved in the provision of the XY EFC services.
EFC-PS-2: The objective of the information security is to
— ensure con fidentiality, integrity, and availability of all information in the XY EFC service operation
and management according to the selected security requirements,
— contribute to the XY EFC system organization’s goals and strategies and support and protect the
organization’s operations, competitiveness, general con fidence, and reputation,
— prevent and limit the consequences of unwanted or unexpected information security incidents, and
— build the required trust and con fidence between the operators.
EFC-PS-3: The approach taken for information security management shall be based on the following
as pects:
a) establishing security requirements by;

1) asses sing risks to the organization,
2) including the legal, statutory, regulatory, and contractual requirements that the XY EFC service
have to ful fil, and

12 7
ISO/TS 192 99: 2 015(E)
3) including the particular set of principles , obj ectives, and business requirements for information
processing in XY EFC system.
b) selecting and implementing controls to ensure that risks are reduced to an acceptable level.
EFC-PS-4: The interoperability management/steering committee supervise, coordinate, and support

the implementation, maintenance, and improvement of all information security management systems
covering the XY EFC service and provide the resources required for this commitment.
EFC-PS-5: The XY EFC system will use international and European security standards and European
and national legislation for personal integrity.
E.2 .4.3 Organization of information security
EFC-PS-6: The interoperability management/steering committee shall approve all information security
policies and assign security roles across the XY EFC system organizations.
EFC-PS-7: Each XY EFC system operator shall have their own information security policy approved by
the interoperability management/steering committee.
EFC-PS-8: Common basic information security requirements for XY EFC system on the basis of the EFC
security framework and ISO/IEC 27001 will be established and maintained for all entities.
EFC-PS-9: There shall be requirements for con fidentiality or non-disclosure agreements re flecting the
organization’s need for the protection of information.
EFC-PS-10: The information security management shall be subject to reviews with planned intervals or
when signi ficant changes related to information security occurs.
EFC-PS-11: T here shall be an approval and authorization proces ses for new information processing
facilities .
EFC-PS-12: Security measures for new or altered systems shall be chosen based on a risk and vulnerability
evaluation. The choice of measures shall be based on the system’s requirement of protection.
EFC-PS-13: The security of the organization’s information and information facilities as well as the
processing and communication of information shall not be reduced by the introduction of external
products or services .
EFC-PS-14: Anyone granted access to one of the XY EFC system information processing facilities shall
follow the internal guidelines for secure use.
EFC-PS-15: Sensitive personal data shall be protected by reasonable security safeguards against such
risks as loss or unauthorized access, destruction, use, modi fication, or disclosure of data.
EFC-PS-16: T here shall be proces ses for counteracting interruptions to bus ines s activities and loss of
information in those cases where an information security incident has a major impact on the daily
operation of the XY EFC service.
E.2 .4.4 Asset management
EFC-PS-17: All XY EFC system assets shall be accounted for and shall have a nominated owner.
EFC-PS-18: All users of XY EFC system assets shall be authorized to access the appropriate systems,
their resources , and their information.
EFC-PS-19: Systematic security measures shall be carried out to prevent, detect, track, and handle
undesirable events .
EFC-PS-20: All information shall be classi fied to indicate the need, priorities, and expected degree of
protection when handling the information.
12 8
ISO/TS 192 99:2 015(E)
EFC-PS-21: C r i tic a l o r s e n s i ti ve i n fo r m atio n p ro ce s s i n g fac i l i ti e s s h a l l b e ho u s e d i n s e c u re a re a s a nd , i f
considered necessary, protected by entry/access controls.

EFC-PS-22: S o ft wa re s h a l l b e p ro te c te d a ga i n s t m a l ic io u s c o de .
EFC-PS-23: Full traceability shall be a ruling principle.
E.2 .4.5 Violations and sanctions
EFC-PS-24: Any employee covered by the scope of this security policy is obliged to report any information
security incident or violation.
EFC-PS-25: The consequences for employees who cause a breach of security regulations will be evaluated
individually. Deliberate breach of security regulations will be evaluated as a neglect of duty.
E.2 .4.6 Review and evaluation
EFC-PS-26: Regular risk evaluations shall be carried out as a revision of XY EFC system security
me a s u re s a nd o p e r ati ve p r ac ti ce . In add i tio n , risk e va lu atio n s shall be ca rrie d out whe n the re a re
signi ficant changes to the threat situation.

EFC-PS-27: In the event of non-conformances or breach of security related to events, security revisions
and other internal inspections or when changes to the level of threat requires it, a systematic
i mp ro ve me n t a nd le a r n i n g p ro c e s s s h a l l b e c a r r i e d o u t i n o rde r to m i n i m i z e the r i s k o f s i m i l a r e ve nt s
a n d no n- c o n fo r m a nc e s .
E.2 .4.7 Audits
EFC-PS-28: Technical audits will be undertaken as determined by the management. Such audits may
include penetration testing. Any technical audit work shall be carried out under the supervision of a
technically competent, authorized individual.
EFC-PS-29: Any auditing of the operational system shall be carefully planned to minimize disruption
to the running of the system. All auditing work will require approval from the system management.
Auditing checks shall be limited to read only checks of live data. Any other type of checks shall be done
on copies of the data which shall be destroyed once no longer required.
E.3 Development of operators security policies
E.3 .1 General
T he E F C - P S -7 s tate me nt re qu i re s th at e ach o p e r ato r, i.e. TC a nd T S P, shall h ave i ts own i n fo r m atio n
security policy based on the EFC scheme security policy approved by the SC. This security policy shall
contain the additional details to the scheme policy statements in respect of the operators internal risk
analysis resulting requirements and security measures.
On the top level, the operator’s security policy will be very similar to the EFC scheme security policy.
Fo r the mo re de t a i le d p a r t, I S O/ I E C 2 70 0 3 p ro v ide s g u i d a nce fo r o p e r ato r s to
— de fine the ISMS scope, boundaries, and develop the security policy,
— analyse the information security requirements, and
— undertake the risk assessment and plan the risk treatment, i.e. the security measures.
ISO/IEC 27005 describes in more detail the information security risk management. The threats
de s c r ib e d of this Technical Speci fication shall be used as a starting point for the risk
in A n ne x D
a s s e s s me nt p ro c e s s .
12 9
ISO/TS 192 99: 2 015(E)
E.3 .2 Interface requirements
6.3 of this Technical Speci fication provides a simpli fied risk assessment for the three communication
interface types typically used in an EFC system. The resulting requirements and security measures
should be a mandatory minimum speci fication in the security policy for the communication interface
protection of every operator of an EFC scheme.
E.3 .3 Data storage requirements
of this Technical Speci fication provides a simpli fied risk assessment for the data storages in the OBE,
6 .4
RSE, and in the TC or TSP back end. The resulting set of requirements should be a mandatory minimum
speci fication in the security policy for data storage protection of every operator of an EFC scheme.
13 0
ISO/TS 192 99:2 015(E)
Annex F
(informative)
Example for an EETS security policy
F.1 General
As mentioned in the Introduction of this Technical Speci fication, the provided security solution should also
apply to EETS. The overall EETS security policy can, in principle, be based on the example EFC security
policy in E .2 . The EETS security policy has to be extended by the parts defined in the Clauses below.
F.2 Basic laws and regulations
The basis for the EETS security police are the European laws and regulations. The EETS system shall
comply with the following:
— EETS-PS-1: EU Directive 2004/52/EC;
— EETS-PS-2: EU Commission Decision 2009/750/CE;
— EETS-PS-3: EU Directive 95/46/EC .
The following enhancement of the applicable European law in this EETS policy is valid for providers of
publicly available electronic telecommunication services.
— EETS-PS-4: EU Directive 2006/24/EC
— EETS-PS-5: EU Commission Decision 200 8/597/EC
F.3 Organization of EETS Information Security
F.3 .1 General
The organization of information de fined in E .2 .4. 3 shall be updated for EETS with the policy statements
de fined in the subclauses below.
F.3 .2 Steering committee
EETS-PS-6: The Steering Committee (SC) which issues and maintains the EETS security policy shall
be formed by interested stakeholders of the EETS system. At least interested member states and toll
chargers (or toll charger associations) should have delegates in the SC (e.g. like interested member
states are participating at the work of the Stockholm Group, existing toll chargers, etc.) .
F.3 .3 Trust model
EETS-PS-7: The trust model shall be according to Clause 5 based on a peer-to-peer model based on
individual certi fication authorities of toll chargers and toll service providers. The use of a single top
level certi fication authority for all TSP and TC in the EETS context is not recommended. The risks and
liabilities connected with providing such a central TTP service are considered to be too high to be
managed by a single entity. Certain toll service providers and toll chargers may trust the same trusted
third party issuing their root certi ficates though. The use of a peer-to-peer trust model distributes the
risk evenly between all stakeholders.

13 1
ISO/TS 192 99: 2 015(E)
EETS-PS-8: The TTP shall issue the Certi ficate Revocation List (CRL) of the EETS system for its issued
certi ficates. Each member states CA shall issue a CRL for its issued certi ficates.
EETS-PS-9: The TTP shall develop and approve its EETS speci fic security policy in the same manner as
the European Root Policy for the digital tachograph system (see Reference [11]).
13 2
ISO/TS 192 99:2 015(E)
Annex G
(informative)
Recommendations for privacy-focused implementation
G.1 General
Privacy is a crucial issue when setting up an EFC system. This Annex provides a number of
implementation recommendations which support privacy-focused solutions which rely on revealing a
minimum of data.
EFC systems are intrinsically linked with the movement and exchange of data. While the evolution and
development of technology provides many opportunities for the provision of ever-more sophisticated
ITS services mostly designed for the bene fit of users, it is imperative that, as part of fundamental design
of the system or standard, the legal and moral requirements for the privacy and protection of personal
data are taken into account at an early system design stage. This is not only desirable from a moral
point of view, but is fundamentally required in order that a system or standard is legally compliant.
This means taking consideration not only of the potential use but also the protection against misuse of
data in a system.
Speci fic data privacy protection legislation is generally achieved by national legislation and for a variety
of social, cultural, economic, and legal backgrounds which vary from country to country. However, the
general principles are geographically common in many cases. While there may be speci fic national
aspects to data privacy and data protection, there are common aspects that are global. Protecting
privacy is important from a user acceptance point of view as well as for ful filling the legal requirements
expressed in various data privacy and personal data protection laws and directives. Processing of
personal data for other purposes (e.g. pay as you drive insurance or behavioural-based marketing)
should only be possible with clear and unambiguous consent from the data subject’s consent (user).
G.2 Legal basis
G.2 .1 European data protection directive (EU Directive 95/46/EC)
All data relating to an identi fied or directly or indirectly identi fiable natural person need to be treated
as personal data.
Protection of users’ personal data shall be according to the EU Directive 95/46/EC and based on the
following principles:
— position data of the users gathered by an EFC system shall not be used for any other purpose than
the calculation and the collection of the toll (“purpose principle”);
— any data which are irrelevant for the calculation and collection of the toll shall not be gathered, and
if they have been gathered, nevertheless, they shall be discarded as soon as their irrelevance has
become evident (“proportionality principle”);
— as soon as personal data are no longer required for the calculation and collection of the toll, they
shall be discarded (“conservation principle” ) .
G.2 .2 European data protection supervisor (EDPS)
European Data Protection Supervisor (EDPS) recommends that a “privacy by design” approach is
adopted at an early stage of the design of ITS to de fine the architecture, operation, and management
of the applications and systems. EDPS furthermore strongly advises that privacy and data protection

13 3
ISO/TS 192 99: 2 015(E)
impact assessments be conducted in relation to particular sectors and/or purposes of use for the
de finition of appropriate security measures and that best available techniques for privacy, data
protection, and security be developed.
G.3 Service users’ requirements
In an EFC system, there are three parties (toll charger, toll service provider, and service user) interested
in reliability, security, integrity, authenticity, availability, con fidentiality, non-repudiation, and privacy
(at least for personal cars) of EFC related data. Therefore, the following users’ requirements with
regards to security and privacy are recommended.
— A “privacy by design” approach should be adopted at an early stage of the design and ‘best available
techniques’ for privacy, data protection, and security should be implemented.
— The anonymity of the service users should be preserved by favourably using such solutions that
gather vehicle road usage data for the EFC only and use the data for that purpose only.
— A system should be designed with a full possibility to check correctness of operations by the service
user including storing of the raw data in case of disputes in court.
— A system should be designed so that the detailed trip data are fully and permanently deleted from
the system after the charges have been settled.
— In order to protect service users against infringement of their privacy, the entity responsible
for interrogation and control should avoid keeping vehicle road usage records of the checked
transactions when no indication of non-compliance is detected. The identity of the service user shall
not be ascertained unless there is evidence that the used vehicle has committed something which is
de fined as a violation of the road pricing system.
— Processing of vehicle road usage data for other purposes (e.g. pay as you drive insurance or
behavioural-based marketing) should only be possible with clear and unambiguous consent from
the service user.
13 4
ISO/TS 192 99:2 015(E)
Annex H
(informative)
Proposal for end-entity certi icates f
H.1 General
The following table lists the likely attributes to be used for end-entity certi ficates. This is a
recommendation for the implementation of interoperable use of end-entity certi ficates.
Table H.1 — Likely attributes to be used for end-entity certi icates

f
Obj ectives
EETS - ADU authentication EIPSec establishment EETS - DSRC Key
and proof of delivery Encryption
Used for verifying the
Description
digital signature of Used for establishing VPN Used for encrypting
ISO 12855:2015 connection with TSPs TSP DSRC Keysets from
messages.
Certi icate f
v3 v3 v3
version
Certi icate
f
PKCS#1 v2.1 PKCS#1 v2.1
signature
(recommended) PKCS#1 v1.5 (recommended)
algorithm
Hash algorithm SHA256 (recommended) SHA1 SHA256 (recommended)

Key usage Signature, non-repudiation Signature and encryption keyEncipherment
Subj ect type Computer (machine) Computer (machine) Computer (machine)
Key length 2 048 2048 2048
Validity period
(years)
2 2 2
Allow key to be
exported
NO NO NO
Subj ect name
(SN)
Supplied in the CSR Supplied in the CSR Supplied in the CSR
(! ) keyUsage: (! ) keyUsage:
(! ) keyUsage:
digitalSignature, digitalSignature, keyEncipherment
non-repudiation keyEncipherment
basicConstraints: not CA basicConstraints: not CA basicConstraints: not CA
Extensions
cRLDistributionPoints: cRLDistributionPoints: cRLDistributionPoints:
CDP_URL CDP_URL CDP_URL
cRLDistributionPoints: cRLDistributionPoints: cRLDistributionPoints:
CDP_URL CDP_URL CDP_URL

13 5
ISO/TS 192 99: 2 015(E)
Bibliography
[1] ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic
Reference Model — Part 2: Security Architecture
[2] ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding
Rules (PER) — Part 2
[3] ISO/IEC 8825 -4, Information technology — ASN.1 encoding rules: XML Encoding Rules (XER) — Part 4
[4] ISO/IEC 9646-7:1995, Information technology — Open Systems Interconnection — Conformance
testing methodology and framework — Part 7: Implementation Conformance Statements
[5] ISO 17573:2010, Electronic fee collection — Systems architecture for vehicle-related tolling
[6] Directive 2004/52/EC of the European Parliament and of the Council of 29 April 2004 on the
interoperability of electronic road toll systems in the Community (OJ L 166, 30.4.2004)
[7] C(2009) 7547, Commission Decision of 6 October 2009 on the de finition of the European
Electronic Toll Service and its technical elements (OJ L 268/11 13 .10. 2009)
[8] Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on
the protection of individuals with regard to the processing of personal data and on the free
movement of such data (OJ L281, 23.11.1995, p. 31) as amended by Regulation (EC) No 1882/2003
(OJ L2 8 4, 31 .10. 2003 , p. 1)
[9] Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the
retention of data generated or processed in connection with the provision of publicly available
electronic communications services or of public communications networks and amending
Directive 2002/58/EC (OJ L 105, 13 .4. 2006 p. 5 4 - 63)
[10] Commission Decision 2008/597/EC of 3 June 2008 adopting implementing rules concerning
the Data Protection Officer pursuant to Article 24(8) of Regulation (EC) No 45/2001 on the
protection of individuals with regard to the processing of personal data by the Community
institutions and bodies and on the free movement of such data (OJ L193 2 2 .7. 2008, p.7 )
[11] Digital Tachograph System European Root Policy. Version 2.0, Administrative Agreement 17398-
00 -12 (DG-TREN ) (http://dtc.j rc.ec.europa.eu/erca_of_doc/SPI0 4131 .pdf)
[12] Data S ecurity S tandard P.C.I. Requirements and Security Assessment Procedures (www.
pcisecuritystandards.org)
[13] ISO/IEC 27000:2014, Information technology — Security techniques — Information security
management systems — Overview and vocabulary
[14] ISO/IEC 27003:2010, Information technology — Security techniques — Information security

management system implementation guidance
[15] IETF Request for Comments (RFC) 2634, Enhanced Security Services for S/MIME
[16] H ousley R. Tim Polk, Planning for PKI: Best Practices Guide for Deploying Public Key
Infrastructure. Wiley, 2001
[17] NIST Special Publication 800-131A, Transitions: Recommendation for Transitioning the Use of
Cryptographic Algorithms and Key Lengths, National Institute of Standards and Technology,
U.S. Department of Commerce, January 2011
[18] ISO/IEC 14888-1:2008, Information technology — Security techniques — Digital signatures with
appendix — Part 1: General
13 6
ISO/TS 192 99:2 015(E)
appendix — Part 2: Integer factorization based mechanisms
appendix — Part 3: Discrete logarithm based mechanisms
[21] ISO/IEC 18033-3:2010, Information technology — Security techniques — Encryption algorithms —
Part 3: Block ciphers
[22] ISO/IEC 10118-3, Information technology — Security techniques — Hash-functions — Part 3:
Dedicated hash-functions
[23] ISO/IEC 10181-1:1996, Information technology — Open Systems Interconnection — Security
frameworks for open systems: Overview — Part 1
[24] ISO/TS 14907-2:2011, Electronic fee collection — Test procedures for user and fixed equipment —
Part 2: Conformance test for the onboard unit application interface
[25] Public-Key Cryptography Standards (PKCS) #1 v2.1: RSA Cryptography Standard, RSA
Laboratories, June 14, 20 02
[26] S chneier B . Attack trees, Dr. Dobb’s Journal, Dec 1999 (https://www. schneier.com/paper-
attacktrees-ddj -ft.html)
[27] ISO 15782-1:2009, Certi ficate management for financial services — Part 1: Public key certi ficates
[28] ISO/TS 17575-3:2011+Cor1:2013, Electronic fee collection -- Application interface definition for
autonomous systems -- Part 3: Context data
[29] CEN/TS 16702-2:2014, Electronic fee collection — Secure monitoring for autonomous toll
systems — Part 2: Trusted recorder
[30] CEN/TR 16690:2014, Electronic fee collection - Guidelines for EFC applications based on in-vehicle
ITS stations
[31] CEN/TR 16092:2011, Electronic fee collection - Requirements for pre-payment systems
[32] ETSI/TR 102 893:2010, Intelligent Transport Systems; Security - Threat, Vulnerability and Risk
Analysis (TVRA, V1.1.1)
[33] ETSI ES 674 200-1, Electromagnetic compatibility and Radio spectrum Matters (ERM); Road
Transport and Traffic Telematics (RTTT); Part 1: Technical characteristics and test methods
for High Data Rate (HDR) data transmission equipment operating in the 5,8 GHz Industrial,
Scienti fic and Medical (ISM) band

13 7
ISO/TS 192 99: 2 015(E)
ICS 35.240.60; 03.220.20
Price based on 137 pages


0360 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

0360 PDF

Uploaded by

Copyright:

Available Formats

TECHNIC AL ISO/TS

SPECIFIC ATION 19299

Electronic fee collection — Security

I n tern ati o n al Org an i z ati o n fo r S tan d ard i z ati o n

COPYRIGHT PROTECTED DOCUMENT

© ISO 2015, Published in Switzerland

Foreword .................................................. ...................................................................................................... ................................................... ............................... v

Introduction .................................................. ................................................... ................................................... ................................................... ..................... vi

1 Scope .................................................. ................................................... ................................................... ......................................................................... 1

2 Normative references .................................................. ................................................... ................................................... .............................. 2

3 Terms and de initions f .................................................. ................................................... ................................................... ............................. 4

4 Symbols and abbreviated terms .................................................. ................................................... ................................................... ... 9

5 Trust model .................................................. ................................................... ................................................... ................................................... .. 10

6 Security requirements .................................................. ................................................... ................................................... ......................... 17

7 Security measures — countermeasures .................................................. ................................................... .............................. 2 4

8 Security speci ications for interoperable interface implementation

© I SO 2 0 1 5 – All rights reserved

8.1 .2 Signature and hash algorithms ......................................................................................................................... 3 5

9 Key management ............................................................................................................................................................................................... 3 6

Annex B (normative) Implementation conformance statement (ICS) proforma ................................................ 46

Annex C (informative) Stakeholder objectives and generic requirements ............................................................... 64

Annex D (informative) Threat analysis ........................................................................................................................................................... 68

Annex E (informative) Security policies ..................................................................................................................................................... 12 4

Annex F (informative) Example for an EETS security policy ................................................................................................ 13 1

Annex G (informative) Recommendations for privacy-focused implementation ........................................... 13 3

Annex H (informative) Proposal for end-entity certi icates f .................................................................................................. 13 5

© ISO 2 01 5 – All rights reserved

Figure 1 — Development path for the security documents

© ISO 2 01 5 – All rights reserved

Figure 2 — The role model underlying this Technical Speci ication

I CC con tact(l ess) Service Point

Eq u i pm en t su ppl i er, servi ce provi d er, etc.

Figure 3 — EFC system model of the EFC Security framework

Relation to other security standards

(Essen ti al Cou n ter-

m easu res for Co-operati ve

Di g i tal si g n atu res

E ach group of s tandards in Figure 4 provides the fol lowing features:

— IT — Security techniques — Information security management system : This standard family

I n form ati on Secu ri ty M an ag em en t System s - I SO 27001

Figure 5 — Scope in relation to the Information Security Management System

© ISO 2015 – All rights reserved

Electronic fee collection — Security framework

— security requirements (Clause 6 );

— key management (C lause 9 );

© ISO 2 01 5 – All rights reserved

Figure 6 — Scope of EFC security framework for secure communication

— entities and interfaces of the interoperability management role;

ISO/IEC 19790, Information technology — Security techniques — Security requirements for

ISO/IEC 27001, Information technology — Security techniques — Information security management

© ISO 2 01 5 – All rights reserved

3 Terms and de initions f

[SOURCE: ISO/IEC 27000:2014, 2.3]

[SOURCE: ISO/TS 17574:2009, 3.7]

[SOURCE: ISO/IEC 27032:2012, 4.27, modi fied]

© ISO 2 01 5 – All rights reserved

[SOURCE: ISO/IEC 27000:2014, 2.33, modi fied]

[SOURCE: ISO/IEC/TR 10000-1:1998, 3.2.1, modi fied]

[SOURCE: ISO/TS 14441:2013, 3.26]

[SOURCE: ISO 7498-2:1989, 3.3.51, modi fied]

© ISO 2 01 5 – All rights reserved

[SOURCE: ISO 17573:2010, 3.16, modi fied]

[SOURCE: ISO 17573:2010, 3.17, modi fied]