SIST-TP CEN/TR 16968:2016

SLOVENSKI STANDARD
01-september-2016
Elektronsko pobiranje pristojbin - Ocena varnostnih ukrepov za aplikacije z
uporabo posebne komunikacije kratkega dosega
Electronic Fee Collection - Assessment of security measures for applications using
Dedicated Short-Range Communication
Elektronische Gebührenerhebung - Beurteilung von Sicherheitsmaßnehmen für
Anwendungen mit dedizierter Nahbereichskommunikation
Perception de télépéage - Évaluation des mesures de sécurité pour les applications
utilisant les communications dédiées à courte portée
Ta slovenski standard je istoveten z: CEN/TR 16968:2016
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 16968
TECHNICAL REPORT
RAPPORT TECHNIQUE
May 2016
TECHNISCHER BERICHT
ICS 35.240.60
English Version
Electronic Fee Collection - Assessment of security
measures for applications using Dedicated Short-Range
Communication
Elektronische Gebührenerhebung - Beurteilung von
Sicherheitsmaßnahmen für Anwendungen mit
dedizierter Nahbereichskommunikation

This Technical Report was approved by CEN on 11 April 2016. It has been drawn up by the Technical Committee CEN/TC 278.

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

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Terms and definitions . 6
3 Abbreviations . 9
4 Method . 10
5 Security Objectives and Functional Requirements . 13
5.1 Target of evaluation . 13
5.2 Security objectives . 14
5.2.1 Introduction . 14
5.2.2 Confidentiality . 14
5.2.3 Availability . 14
5.2.4 Accountability . 14
5.2.5 Data integrity . 14
5.3 Functional security requirements . 15
5.3.1 Introduction . 15
5.3.2 Confidentiality . 15
5.3.3 Availability . 17
5.3.4 Accountability . 18
5.3.5 Data integrity . 20
5.4 Inventory of assets . 21
5.4.1 Functional Assets . 21
5.4.2 Data Assets. 22
6 Threat analysis . 22
7 Qualitative risk analysis . 24
7.1 Introduction . 24
7.1.1 General . 24
7.1.2 Likelihood of a threat . 24
7.1.3 Impact of a threat . 25
7.1.4 Classification of Risk . 26
7.2 Risk determination . 26
7.2.1 Definition of high and low risk context . 26
7.2.2 Threat T1: Access Credentials keys can be obtained . 27
7.2.3 Threat T2: Authentication keys can be obtained . 27
7.2.4 Threat T3: OBU can be cloned . 28
7.2.5 Threat T4: OBU can be faked. 28
7.2.6 Threat T5: Authentication of OBU data can be repudiated . 29
7.2.7 Threat T6: Application data can be modified after the transaction . 29
7.2.8 Threat T7: Data in the VST is not secure . 30
7.2.9 Threat T8: DSRC Communication can be eavesdropped . 30
7.2.10 Threat T9: Correctness of application data are repudiated . 31
7.2.11 Threat T10: Master keys may be obtained from RSE . 31
7.3 Summary . 31
8 Proposals for new security measures . 32
8.1 Introduction. 32
8.2 Security measures to counter risks related to key recovery . 32
8.3 Recommended countermeasures . 34
8.4 Qualitative cost benefit analysis . 35
9 Impact of proposed countermeasures . 35
9.1 Current situation and level of fraud in existing EFC systems using CEN DSRC link . 35
9.2 EETS legislation . 36
9.3 Analysis of effects on existing EFC systems . 36
9.3.1 Affected roles . 36
9.3.2 The CEN DSRC equipment Manufacturers . 36
9.3.3 The Toll Service Providers . 37
9.3.4 The Toll Chargers . 37
10 Recommendations . 38
10.1 Add security levels and procedures to EN ISO 14906 . 38
10.2 Recommendation for other EFC standards . 39
10.3 New standards . 39
Annex A (informative) Current status of the DEA cryptographic algorithm . 40
A.1 Overview . 40
A.2 ISO/IEC 9797-1 (MAC Algorithm 1) . 40
A.3 FIPS 46 (DEA Specification – DES) . 40
A.4 ENISA recommendations . 41
Annex B (informative) Security considerations regarding DSRC in EFC Standards . 42
B.1 Security vulnerabilities in EN 15509 and EN ISO 14906 . 42
B.2 Security vulnerabilities in EN ISO 12813 (CCC) . 42
B.3 Security vulnerabilities in EN ISO 13141 (LAC) . 43
B.4 Security vulnerabilities in CEN/TS 16702-1 (SM-CC) . 43
Bibliography . 44

European foreword
This document (CEN/TR 16968:2016) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
Introduction
Security for dedicated short-range communication (DSRC) applications in the context of electronic fee
collection (EFC) has a long history in standardization. Currently the area is covered by several
standards and technical specifications, successively developed over time:
— EN ISO 14906 (Electronic fee collection - Application interface definition for dedicated short-range
communication) provides a toolbox of functions and security measures which can be used for DSRC
application.
— CEN ISO/TS 19299 (Electronic fee collection - Security framework) analyzes the threats to an EFC
system as a whole, and not specifically for the DSRC technology.
— EN ISO 12813 (Electronic fee collection - Compliance check communication for autonomous
systems) and EN ISO 13141 (Electronic fee collection - Localisation augmentation communication
for autonomous systems) mirrors the best-practice security measures of EN 15509.
— CEN/TS 16702-1 (Electronic fee collection - Secure monitoring for autonomous toll systems - Part
1: Compliance checking) provides an EFC enforcement concept, partially dependent on a DSRC
application.
— EN 15509 (Electronic fee collection - Interoperability application profile for DSRC) defines an
interoperable application profile which comprises a selection of such measures with a definition of
security algorithms associated to it. It is based on the experience of many EU projects related to
DSRC-EFC.
As the security domain has evolved, it is now necessary to analyze again the threats, vulnerabilities and
risks of using the CEN DSRC technology in all DSRC-based applications related to EFC. Technological
advances and proliferation of cryptographic tools and knowledge has made an attack on the security
procedures of DSRC more likely.
This technical report (TR) identifies context dependent risks on the DSRC link and proposes security
measures to counter them and the points out what new standard deliverables that are needed.
1 Scope
This Technical Report includes a threat analysis, based on CEN ISO/TS 19299 (EFC - Security
Framework), of the CEN DSRC link as used in EFC applications according to the following Standards and
Technical Specification
— EN 15509:2014,
— EN ISO 12813:2015,
— EN ISO 13141:2015,
— CEN/TS 16702-1:2014.
This Technical Report contains:
— a qualitative risk analysis in relation to the context (local tolling system, interoperable tolling
environment, EETS);
— an assessment of the current recommended or defined security algorithms and measures to
identify existing and possible future security leaks;
— an outline of potential security measures which might be added to those already defined for DSRC;
— an analysis of effects on existing EFC systems and interoperability clusters;
— a set of recommendations on how to revise the current standards, or proposal for new work items,
with already made implementations taken into account.
The security analysis in this Technical Report applies only to Security level 1, with Access Credentials
and Message authentication code, as defined in EN 15509:2014.
It is outside the scope of this Technical Report to examine Non DSRC (wired or wireless) interfaces to
the OBE and RSE.
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
[SOURCE: EN 15509:2014, 3.1]
2.2
accountability
property that ensures that the actions of an entity may be traced uniquely to that entity
[SOURCE: ISO 7498-2:1989, 3.3.3, modified]
2.3
asset
anything that has value to a stakeholder
[SOURCE: CEN ISO/TS 19299:2015, 3.3]
2.4
attack
attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use
of an asset
[SOURCE: CEN ISO/TS 19299:2015, 3.4]
2.5
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
[SOURCE: EN ISO 17575-1:2016, 3.2]
2.6
authentication
security mechanism allowing verification of the provided identity
[SOURCE: EN 301 175]
2.7
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
2.8
confidentiality
prevention of information leakage to non-authenticated individuals, parties and/or processes
[SOURCE: CEN ISO/TS 19299:2015, 3.11]
2.9
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: CEN ISO/TS 19299:2015, 3.28]
2.10
hacker
person who attempts or succeeds to gain unauthorized access to protected resources
[SOURCE: CEN ISO/TS 19299:2015, 3.19]
2.11
key management
generation, distribution, storage, application and revocation of encryption keys
[SOURCE: CEN ISO/TS 17574:2009, 3.13 modified]
2.12
message authentication code
MAC
string of bits which is the output of a MAC algorithm
[SOURCE: ISO/IEC 9797-1:2011, 3.9]
2.13
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
[SOURCE: CEN ISO/TS 19299:2015, 3.27]
2.14
on-board equipment
OBE
all required equipment on-board a vehicle for performing required EFC functions and communication
services
2.15
on-board unit
OBU
single electronic unit on-board a vehicle for performing specific EFC functions and for communication
with external systems
Note 1 to entry: An OBU always includes, in this context, at least the support of the DSRC interface
2.16
reliability
ability of a device or a system to perform its intended function under given conditions of use for a
specified period of time or number of cycles
[SOURCE: CEN ISO/TS 14907-1:2015, 3.17]
2.17
roadside equipment
RSE
equipment located along the road, either fixed or mobile
[SOURCE: CEN ISO/TS 14907-1:2015, 3.17]
2.18
security target
set of security requirements and specifications to be used as the basis for evaluation of an identified
TOE
[SOURCE: CEN ISO/TS 17574:2009, 3.25]
2.19
target of evaluation
TOE
set of software, firmware and/or hardware possibly accompanied by guidance
[SOURCE: ISO/IEC 15408-1:2009, 3.1.70]
2.20
threat
potential cause of an unwanted information security incident, which may result in harm
[SOURCE: CEN ISO/TS 19299:2015, 3.39]
2.21
threat agent
entity that has the intention to act adversely on an asset
[SOURCE: CEN ISO/TS 19299:2015, 3.40]
2.22
threat analysis
systematic detection, identification, and evaluation of threats
[SOURCE: CEN ISO/TS 19299:2015, 3.41]
2.23
toll charger
TC
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16 modified]
2.24
toll service provider
TSP
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010, 3.23 modified]
2.25
transaction counter
data value in the on-board unit that is incremented by the roadside equipment at each transaction
[SOURCE: EN 15509:2014, 3.23]
2.26
vulnerability
weakness of an asset or control that can be exploited by an attacker
[SOURCE: CEN ISO/TS 19299:2015, 3.51]
3 Abbreviations
For the purposes of this document, the following symbols and abbreviations apply.
AES Advanced Encryption Standard
CCC Compliance check communication (EN ISO 12813)
COTS Commercial Off-the-Shelf
DEA Data Encryption Algorithm
DES Data Encryption Standard
DSRC Dedicated Short-Range Communication (EN ISO 14906)
EETS European Electronic Toll Service
IAP Interoperable Application Profile
LAC Localisation augmentation communication (EN ISO 13141)
MAC Message authentication code
NIST National Institute of Standards and Technology
OBE On-board Equipment
OBU On-board Unit
RSE Roadside Equipment
SM-CC Secure Monitoring Compliance Check (CEN/TS 16702–1:2014)
TOE Target Of Evaluation
TVRA Threat, Vulnerability and Risk Analysis
VST Vehicle Service Table
4 Method
The method in this technical report is based on the method of ETSI/TS 102 165-1 which defines a 10
step method which in turn is based on ISO/IEC 15408 and is especially adapted to communication
interfaces. This approach is also used in ETSI/TR 102 893. The 10 steps are listed below:
1) Identification of the Target of Evaluation (TOE) resulting in a high-level description of the main
assets of the TOE and the TOE environment and a specification of the goal, purpose and scope of the
Threat, Vulnerability and Risk Analysis (TVRA). See 5.1.
2) Identification of the objectives resulting in a high-level statement of the security aims and issues to
be resolved. See 5.2.
3) Identification of the functional security requirements, derived from the objectives from step 2.
See 5.3.
4) Inventory of the assets as refinements of the high-level asset descriptions from step 1 and
additional assets as a result of steps 2 and 3. See 5.4.
5) Identification and classification of the vulnerabilities in the system, the threats that can exploit
them, and the unwanted incidents that may result. See Clause 6.
6) Quantifying the occurrence likelihood and impact of the threats. See 7.1.
7) Establishment of the risks. See 7.2.
8) Identification of countermeasures framework (conceptual) resulting in a list of alternative security
services and capabilities needed to reduce the risk. See 8.2.
9) Countermeasure cost-benefit analysis (including security requirements cost-benefit analysis
depending on the scope and purpose of the TVRA) to identify the best fit security services and
capabilities amongst alternatives from step 8. See Clause 9.
10) Specification of detailed requirements for the security services and capabilities from step 9.
See Clause 10.
Steps 6-10 will be adapted to the generic case of DSRC communication addressed by this technical
report. Furthermore, the analysis under step 5 and step 8 specifically takes CEN ISO/TS 19299 into
account. The adapted methodology used in this report is illustrated in Figure 1.
Figure 1 — Adapted TVRA methodology used in this report
5 Security Objectives and Functional Requirements
5.1 Target of evaluation
There are two potential Targets of Evaluation (TOE) for security analysis purposes:
— The OBU
— The RSE
Per definition, a TOE can only be attacked through its exposed interfaces and the presence of a threat
agent is necessary to launch an attack. The scope of this analysis is the communication link over 5.8 GHz
CEN DSRC, see Figure 2. Communication over the other interfaces identified in Figure 2 is out of scope
for this TR.
Figure 2 — TOE
NOTE Figure 2 is copied from Figure 1 in EN 15509.
The CEN DSRC link is the communication link between the RSE and OBU according to EN 15509:2014
(DSRC-EFC), EN ISO 12813:2015 (CCC), EN ISO 13141:2015 (LAC) and CEN/TS 16702-1:2014 (SM-CC).
For the sake of this Technical Report analysis it is assumed that a valid OBU is issued by and is in the
domain of the Toll Service Provider (TSP) and likewise that the road side equipment (RSE) is in the
domain of the Toll Charger (TC) managing a given toll domain. However, most of the analysis will hold
true even in the case of a different assignement of responsibilities.
The analysis only applies to EN 15509 Security Level 1 with Access Credentials and Message
authentication code. Security level 0 is not considered.
5.2 Security objectives
5.2.1 Introduction
In accordance with NIST Special Publication 800-33 the security objectives considered are: availability,
integrity, confidentiality and accountability.
The fifth NIST security objective “assurance”, which is the basis for confidence that the security
measures, both technical and operational, work as intended, is not considered here, as this TR does not
cover implementation aspects.
NOTE Authentication, authorization and access control are security services that focus on preventing a
security breach and are used to fulfil the objectives.
5.2.2 Confidentiality
The following security objectives relative to the confidentiality of stored and transmitted information
are specified:
— Co1 Information relating to the identity of a Service User should not be revealed to any
unauthorized 3rd party
— Co2 Information held within the OBU and RSE should be protected from unauthorized access.
— Co3 Information sent from an OBU to an authorized RSE should not reveal the vehicle's travel
history to any party not authorized to receive the information.
— Co4 Data exchange guarantees data confidentiality
5.2.3 Availability
The following security objective relative to the availability of services is specified:
— Av1 Access to and the operation of DSRC-EFC/CCC/LAC/SM-CC services should not be prevented by
malicious activity performed on the TOE.
5.2.4 Accountability
The following security objective relative to the accountability of services is specified:
— Ac1 The data exchanged should provide authentication and non-repudiation for the respective
service.
5.2.5 Data integrity
The following security objectives relative to the integrity of data in the TOE:
— In1 Information stored within an OBU or RSE should be protected from unauthorized
modification and deletion.
— In2 Information sent to or from an OBU or RSE should be protected against unauthorized or
malicious modification or manipulation during transmission.
5.3 Functional security requirements
5.3.1 Introduction
The following clauses present a number of functional security requirements that covers the security
objectives listed in 5.2.
As far as possible this has been done by selecting appropriate requirements from CEN
ISO/TS 19299:2015. Those have been given identifiers according to the template RQ.TC/TSP.XX with
the corresponding requirement description copied from CEN ISO/TS 19299:2015.
NOTE It was considered to only reference to the requirements in CEN ISO/TS 19299:2015, and not to repeat
these in this Technical Report. However, this approach was discarded as it would significantly have hampered the
readability of this Technical Report. As a consequence of the adopted approach, to reference the requirements
identifiers and to cite the associated requirements, is that this Technical Report contains “shall” statements in 5.3.
For those objectives not fully covered by CEN ISO/TS 19299:2015 functional security requirements
original to this technical report have been defined. They are given identifiers according to the template
DSRC-SEC.RQ.TC/TSP.XX.
5.3.2 Confidentiality
Table 1 — Toll charger confidentiality requirements
Obj. Objective Req. Id. Requirement
Id.
Co3 Information sent from an OBU RQ.TC.01 DSRC-EFC, CCC, LAC and SM-CC applications
to an authorized RSE should not shall either not request information about the
reveal the vehicle's travel vehicle's travel history or protect its
history to any party not confidentiality in transfer.
authorized to receive the
information.
Co2 Information held within the RQ.TC.24 The RSE shall not allow unauthorized access
OBU and RSE should be to software and data.
protected from unauthorized
RQ.TC.90 The TCs systems shall be designed in a way
access.
that access to stored or processed data are
only possible within the legal context of the
respective country (e.g. lawful interception).
Table 2 — OBU confidentiality requirements
Obj. Objective Req. Id. Requirement
Id.
Co3 Information sent from an OBU  DSRC-EFC, CCC, LAC and SM-CC applications
to an authorized RSE should not shall either not provide information about the
reveal the vehicle's travel vehicle's travel history or protect its
history to any party not confidentiality in transfer.
authorized to receive the
information.
Co2 Information held within the Derived The TSP shall implement RSE authentication
OBU and RSE should be from measures for DSRC communication based upon
protected from unauthorized RQ.TC.22 security level 1 as defined in EN 15509:2014 or
access. equivalent national standards/regulations.
The OBU shall not allow unauthorized access to
software and data.
RQ.TSP.90 The TSP systems shall be designed in a way that
access to stored or processed data is only
possible within the legal context of the
respective country (e.g. lawful interception).
Co1 Information relating to the  The OBU's VST shall not contain data identifying
identity of a Service User should a Service User
not be revealed to any
DSRC-EFC, CCC, LAC and SM-CC applications
unauthorized 3rd party.
shall either not provide information identifying
a Service User or protect its confidentiality in
transfer.
Co4 Data exchange guarantees data RQ.IF.10 DSRC-EFC, CCC and SM-CC applications shall
confidentiality protect its confidentiality in transfer.
5.3.3 Availability
Table 3 — Toll charger availability requirements
Obj. Objective Req. Id. Requirement
Id.
Av1 Access to and the operation of RQ.TC.08 The TC shall check the model and make of
DSRC-EFC/CCC/LAC/SM-CC OBE during a vehicle check (enabled by
services should not be RQ.TSP.58) to identify the use of OBE
prevented by malicious activity versions not certified by the TC.
performed on the TOE.
RQ.TC.20 The TC shall detect RSE damaging and
recover the RSE functionality within an
agreed time frame.
RQ.TC.21 The TC shall detect theft of RSE parts and
recover the RSE functionality by a
replacement of the stolen part within an
agreed time frame.
RQ.TC.23 The TC shall detect RSE malfunction or
underperformance and correct it within an
agreed time frame.
RQ.TC.24 The RSE shall not allow unauthorized access
to software and data.
RQ.TC.96 The TC shall be responsible for the
availability of his RSE interfaces to an OBE
according to agreed service levels.
Table 4 — Toll service provider availability requirements
Obj. Objective Req. Id. Requirement
Id.
Av1 Access to and the operation of RQ.TSP.09 The TSP shall notify the service user if the
DSRC-EFC/CCC/LAC/SM-CC OBE or ICC is not working correctly.
services should not be
RQ.TSP.05 The OBE shall prevent or detect illegal
prevented by malicious activity
modification of parameters through its
performed on the TOE.
external interfaces.
5.3.4 Accountability
Table 5 — Toll charger accountability requirements
Obj. Objective Req. Id. Requirement
Id.
Ac1 The following security objective RQ.TC.01 The TC shall determine if factual road usage is
relative to the accountability of represented by a corresponding set of correct
services is specified: and complete toll declarations either acquired
directly through the TCs RSE or through a TSP
The data exchanged should
(enabled by RQ.TSP.51 for autonomous
provide authentication and non-
systems).
repudiation for the respective
service
RQ.TC.04 The TC shall check the integrity and
authenticity of the received data as compared
to the data sent from the OBE.
RQ.TC.32 The TC shall make sure that the enforcement
case data is court proof.
RQ.TC.92 The TC shall only accept an OBE after
detecting if an OBE belongs to a trusted TSP
and that the TSP guarantees payment for that
specific OBE (enabled by RQ.TSP.62).
Table 6 — Toll service provider accountability requirements
Obj. Objective Req. Id. Requirement
Id.
Ac1 The following security objective RQ.TC.01 The TC shall determine if factual road usage is
relative to the accountability of represented by a corresponding set of correct
services is specified: and complete toll declarations either acquired
directly through the TCs RSE or through a TSP
The data exchanged should
(enabled by RQ.TSP.51 for autonomous
provide authentication and non-
systems).
repudiation for the respective
service
RQ.TSP.04 The TSP shall determine if toll declarations
are based on data originating from a
legitimate OBE or ICC.
RQ.TSP.08 The TSP shall detect duplicate or false OBE or
ICC identities and block such OBE or ICC
identities by placing them on the exception
list.
RQ.TSP.19 The TSP shall notify the TC about stolen or
cloned OBE or ICC.
RQ.TSP.21 The TSP shall detect cloned OBE or ICC and
block them by placing them on the exception
list.
RQ.TSP.51 The TSP shall enable the TC to determine if
factual road usage is 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 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 data originating
from a legitimate Front End (required to
enable RQ.TC.05 for autonomous systems) or
OBE (in a DSRC system).
5.3.5 Data integrity
Table 7 — Toll charger integrity requirements
Obj. Objective Req. Id. Requirement
Id.
In1 Information stored within an RQ.TC.24 The RSE shall not allow unauthorized access to
OBU or RSE should be protected software and data.
from unauthorized modification
and deletion.
In2 Information sent to or from an  The TC shall implement OBU Data Integrity
OBU or RSE should be protected verification for DSRC communication based
against unauthorized or upon security level 1 as defined in
malicious modification or EN 15509:2014 or equivalent national
manipulation during standards/regulations.
transmission.
The TC shall implement application data
integrity verification as defined in SM-CC
The TC shall provide application data integrity
measures as defined in LAC (LACData MAC1
and MAC2)
The TC shall provide application data integrity
measures for EFC-DSRC (ReceiptData
Authenticator)
The TC shall implement application data
integrity verification for EFC-DSRC
(ReceiptData Authenticator)
RQ.TC.04 The TC shall check the integrity and
authenticity of the received data as compared
to the data sent from the OBE.
RQ.TC.05 The TC shall determine if toll declarations are
based on data originating from a legitimate
OBE or TSP Back End (enabled by RQ.TSP.55).
Table 8 — Toll service provider integrity requirements
Obj. Objective Req. Id. Requirement
Id.
In1 Information stored within an  The TSP shall provide OBU authentication
OBU or RSE should be protected measures for DSRC communication based upon
from unauthorized modification security level 1 as defined in EN 15509:2014 or
and deletion. equivalent national standards/regulations.
The TSP shall not allow unauthorized access to
software and data.
In2 Information sent to or from an  The TSP shall provide OBU data integrity
OBU or RSE should be protected measures for DSRC communication based upon
against unauthorized or security level 1 as defined in EN 15509:2014 or
malicious modification or equivalent national standards/regulations.
manipulation during
The TSP shall provide application data
transmission.
integrity measures as defined in SM-CC
The TSP shall implement application data
integrity verification as defined in LAC
RQ.IF.11 Data exchange shall guarantee data integrity.
RQ.IF.12 Data exchange shall guarantee the authenticity
of the data originator.
RQ.IF.13 Data exchange shall guarantee non-repudiation
with proof of origin.
RQ.IF.20 Data exchange shall only be done between
authenticated entities for the respective data
exchange.
5.4 Inventory of assets
5.4.1 Functional Assets
The functional assets in the OBU and RSE that concern the TOE can be classified as follows:
— The implementation of the communication protocol stack, incl. the parameters defining its
behaviour;
— The DSRC-EFC/CCC/LAC/SM-CC application
The functional assets from the security point of view for OBU and RSE are:
— The OBU key derivation algorithm for authentication and AC key
— The MAC generation algorithms based on DEA
— The AC calculation algorithm based on DEA
5.4.2 Data Assets
5.4.2.1 OBU
The data assets in the OBU are discussed in CEN/TR 16152:2011, Clause 5.2. The assets that concern
the TOE can be classified as follows:
— Communication initialization data provided in the VST
— Application data that can be transferred to or from the OBU over the DSRC interface as DSRC
attributes
— Cryptographic key material for DSRC Security, i.e. OBU DEA authentication, non-repudiation and
access control keys. These assets are described in EN 15509:2014, Clauses 6.1.5.2, 6.1.5.3 and
Table A.4. Notice that the OBU only carries diversified keys.
— Parameters for DSRC behaviour
5.4.2.2 RSE
The data assets in the RSE that concern the TOE can be classified as follows:
— Application data communicated (written) over the DSRC interface as part of DSRC attributes
— Cryptographic key material for DSRC Security, i.e. RSE authentication and access control master
keys. These assets are described in EN 15509:2014, Clauses 6.1.5.2, 6.1.5.3 and Table A.4. Notice
that the RSE carries master keys, but only derived keys are used for the authentication and access
control procedures.
— Parameters for DSRC behaviour
6 Threat analysis
Within a TOE, vulnerability is considered to be a combination of an identified system weakness with
one or more threats that are able to exploit that weakness. The weaknesses have been identified by
analysis of requirements and assets.
A threat agent may exploit a weakness and recover keys in some of the threats. Notice that one
successful attack only relates to one DSRC application and one EfcContextMark at a time. It is assumed
that different applications co-existing inside one OBU are fully isolated from each other.
The consequences refer to functional security requirements (5.3) that are potentially violated by this
threat.
The analysis does not fully analyze what entity that will lose income, it may be the Toll Charger or the
Toll Service Provider or other entities.
The analysis is done on EN 15509 security level 1. In EFC system using security level 0 (without the use
of access control), some threats do not apply.
Table 9 — Vulnerabilities, weaknesses and threats
Weaknesses in Threat  Consequence
standards' system
design
DEA key(s) is T1: Access Credentials Attacker in Confidentiality and integrity:
subject to brute key can be obtained possession of an Attributes on all OBUs with
force attack. from an RSE by OBU communication the same AC_CR-
obtaining an AC simulator KeyReference can be read
response and executing out and written according to
a brute force attack access conditions in
standards.
T2: Proof of concept Attacker with access Accountability:
published: to outcome of T1and Authentication keys can be
The authentication key possession of a RSE obtained from valid OBUs.
can be obtained from communication
an OBU by obtaining simulator
several MAC responses
and executing a brute
force attack.
T3: Single OBUs can be Attacker with access Accountability: Toll is levied
1)
to outcome of T2 and on incorrect service user
cloned .
can build OBU
hardware
T4: OBUs can be Attacker with access Accountability and Integrity.
2)
to outcome of T2 and
faked .
can build OBU
hardware
T5: Authentication of Service Provider not Accountability: OBU cannot
OBU data can be willing to pay. be used for payment
repudiated on the basis effectively. Toll Charger
User repudiating the
that DES is not secure. loses income.
tolls
T6: Application data Toll Charger willing Integrity: A higher fee is
can be modified after to obtain more proposed / debited to the
the transaction took payment from user.
place service provider
Users loose trust in the
/user
system
Initialization phase T7: Data in the VST is Service Provider Accountability: model and
is not secured not secure. using not certified make of OBU is not
OBUs authentic.
1) Cloning refers to copying the entire set of attributes and related cryptographic key material from a valid OBU.
The resulting OBU will be indistinguishable from the original OBU.
2) Faking refers to copying some information from the original OBU, and changing some.
Weaknesses in Threat  Consequence
standards' system
design
DSRC T8: DSRC Attacker with DSRC- Confidentiality: User can be
Communication is Communication can be sniffer within DSRC tracked at the RSE and
in plaintext eavesdropped. communication private information be
range exploited by unauthorized
parties
Application data are T9: Correctness of Service Provider not Integrity: OBU cannot be
not protected application data are willing to pay used for payment effectively.
against integrity repudiated. Toll Charger loses income.
User repudiating the
attacks
tolls
Master key is T10: Master keys may Attacker with access Accountability, integrity and
subject to brute be o
...