ISO/TS 19299: Electronic fee collection - Security framework

Citation preview

TECHNIC AL SPECIFIC ATION

ISO/TS 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

[email protected] www.iso.org

ii

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 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 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 .4

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

Trust model for Interoperability Management relations

.................................................. .........

13

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 5.4.4 5.4.5

Issuing and revocation of sub CA and end-entity certi ficates Certi ficate and certi ficate revocation list pro file and format Certi ficate extensions

................................................

14

................. ................................

15

................. .................................. ................................................... .................................... .....

15

Security requirements .................................................. ................................................... ................................................... ......................... 17 6.1

General .................................................. ................................................... ................................................... ................................................ 1 7

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.8

Limitation of requirements .................................................. ................................................... .................................................. 2 3

6.2

6.7 7

4

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

5.3.4

6

.................................................. ................................................... ................................................... .............................

Information security management system

Interoperability Management

.................................................. ................................................... .............

.................................................. ................................................... ............................................

18

23

Security measures — countermeasures .................................................. ................................................... .............................. 2 4 7.1

7.2 7.3

7.4 7.5 7.6

O verview .................................................. ...................................................................................................... ........................................... 2 4

General security measures Communication interfaces security measures

................................................... ................................................... ..................................................

24

.................................................. ................................................... ....

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

End-to-end security measures Toll service provider security measures 7.5.1 Front end security measures 7.5.2 Back end security measures Toll charger security measures 7.6.1 RSE security measures 7.6.2 Back end security measures 7.6.3 Other TC security measures

................................................... ................................................... .........................................

30

.................................................. ................................................... ...................

32

.................................................. ................................................... .........................

32

................................................... ................................................... .........................

33

.................................................. ................................................... .........................................

34

.................................................. ................................................... ...................................... ..

34

................................................... ................................................... .........................

34

.................................................. ................................................... ...........................

35

.................................................. .......

35

8 Security speci ications for interoperable interface implementation f

8.1

General .................................................. ................................................... ................................................... ................................................ 3 5 8. 1 . 1

Subj ect................................................... ................................................... ................................................... ........................... 3 5

© I SO 2 0 1 5 – All rights reserved

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

iii

ISO/TS 192 99: 2 015(E)

8.2

9

8.1 .2

Signature and hash algorithms ......................................................................................................................... 3 5

8.2 .1

Subj ect.................................................................................................................................................................................... 3 6

8.2 .2

OBE ........................................................................................................................................................................................... 3 6

8.2 .3

RSE ............................................................................................................................................................................................ 3 6

Security speci fications for DSRC-EFC ............................................................................................................................... 3 6

Key management ............................................................................................................................................................................................... 3 6 9.1

9.2

9.3

Overview ................................................................................................................................................................................................... 3 6

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 .1

General ................................................................................................................................................................................... 3 8

Symmetric keys .................................................................................................................................................................................... 3 8 9.3.2 9.3.3 9.3.4 9.3.5

Annex A (normative)

Key exchange between stakeholders ........................................................................................................... 3 8 Key lifecycle ....................................................................................................................................................................... 3 9 Key storage and protection .................................................................................................................................. 40 Session keys ...................................................................................................................................................................... 41

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

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 – 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.

© ISO 2 01 5 – All rights reserved

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

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

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 – All rights reserved

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 attackbased 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 © ISO 2 01 5 – All rights reserved

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

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

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 – All rights reserved

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

Service Point

con tact(l ess)

D ri ve r

Personnel

Customization, Maintenance

con tact(l ess) HMI

o pti o n al

Value added services

S e rvi ce P ro vi d e r OB E

CN

OBE 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 Ve h i cl e

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

I CC

B ack E n d

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 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. F i g u re 4

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

ix

ISO/TS 192 99: 2 015(E)

ETSI TR 1 02 731 (Essen ti al Cou n term 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

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

© I SO 2 0 1 5 – All rights reserved

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)].

© ISO 2015 – All rights reserved

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

xi

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

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 motivation for the security requirements;

C ) which provide a basic

— 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 ) .

© ISO 2 01 5 – All rights reserved

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

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 ,

ISO

1 2 8 5 5 : 2 01 5 ,

charging

2

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

Electronic fee collection — Compliance check communication for autonomous systems Electronic fee collection — Information exchange between service provision and toll

© 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,

communication

Electronic fee collection — Application interface definition for dedicated short-range

Electronic fee collection — Interoperability application pro file for DSRC

EN 15509: 2014,

CEN/TS 16702-1: 2014,

1: Compliance checking ISO 17575 -1: 2015,

Part 1: Charging

Electronic fee collection — Secure monitoring for autonomous toll systems — Part

Electronic fee collection — Application interface definition for autonomous systems —

Identification cards — Integrated circuit cards — Part 3: Cards with interface and transmission protocols

ISO/IEC 7816 -3 ,

contacts — Electrical

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: Publickey 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,

Framework

Information technology — Security techniques — Key management — Part 1:

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 ,

security controls ISO/IEC 27005 ,

Information technology — Security techniques — Code of practice for information

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,

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 ,

and Certificate Revocation List (CRL) Pro file

© ISO 2 01 5 – All rights reserved

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

Enhanced Security Services (ESS) Update: Adding

Internet X.509 Public Key Infrastructure Certificate

3

ISO/TS 192 99: 2 015(E)

IETF Request for Comments (RFC ) 5746: 2010 -02 ,

Indication Extension

Transport Layer Security (TLS) Renegotiation

Federal Information Processing Standards (FIPS) PUB 140 -2 , December 2002 ,

cryptographic modules

Security requirements for

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

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 – All rights reserved

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]

© ISO 2 01 5 – All rights reserved

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

5

ISO/TS 192 99: 2 015(E)

3 .21 information security

integrity (3 . 24) , availability (3 .6) , authenticity (3 . 5 ) , accountability non-repudiation (3 . 27 ), and reliability of information

preservation of con fidentiality (3 .11) , (3 .1) ,

[SOURCE: ISO/IEC 27000:2014, 2.33, modi fied] 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

information security (3 . 21) events that have a signi ficant probability of compromising business operations and threatening information security unwanted

[SOURCE: ISO/IEC 27000:2014, 2.36, modi fied] 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

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 – All rights reserved

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 [SOURCE: ISO/IEC 27000:2014, 2.60, modi fied] 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 [SOURCE: ISO/IEC 27000:2014, 2.83, modi fied]

© ISO 2 01 5 – All rights reserved

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

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)

[SOURCE: ISO 17573:2010, 3.17, modi fied] 3 .45 toll domain area or a part of a road network where a certain

toll regime (3 .46)

is applied

[SOURCE: ISO 17573:2010, 3.18, modi fied] 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 ) [SOURCE: ISO 17573:2010, 3.23, modi fied] 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

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 – All rights reserved

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 [SOURCE: ISO 17573:2010, 3.29, modi fied] 3 .51 vulnerability weakness of an

asset (3 . 3 )

or control that can be exploited by an attacker

[SOURCE: ISO/IEC 27000:2014, 2.89, modi fied] 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

© ISO 2 01 5 – All rights reserved

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

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

technique.

RSA is an algorithm for public-key cryptography also referred to as asymmetrical cryptographic

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 5.1

Trust model 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

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 – All rights reserved

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 are among others used for certi fication of organization or equipment and TTP functions in case this is performed by the IM. F i g u re

7

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 5.3 .1

Technical trust model 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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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 (selfsigned) 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 Speci fication.

F i g u re

8

illustrates an example of a trust model approach which is supported by this Technical

Figure 8 — Example of a mixed trust model environment

F i g u re 8 in

a

indicates the possibility of the trust model allowing an entity to participate at the same time

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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

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 end-entity certi ficates of this root certi ficate shall be renewed according to the process de fined in

5 . 4 . 1 . A l l i s s ue d 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 signature of the message shall be veri fied with the public key of the originally imported root certi ficate. I S O/ I E C

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 > EndEntity) 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 certi ficate. The digital signature of the message shall be veri fied with the public key of the originally imported root certi ficate. I S O/ I E C

Exchange of certi ficates and CRLs is de fined in

14

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

C l au s e 9 .

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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 ficateusing 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; © ISO 2 0 1 5 – All rights reserved

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

15

ISO/TS 192 99: 2 015(E)

b)

CRL distribution points;

c)

authority information access.

16

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 2015 – All rights reserved

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

5

Key agreement Key certi ficate signing

6

C RL s igning

4

Encipher only Decipher only

7 8

6 6.1

Security requirements 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.

© ISO 2 0 1 5 – All rights reserved

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

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 .

De finition of the requirement or recommendation. Marked with an X if this requirement is relevant for a DSRC system. Marked with an X if this requirement is relevant for an autonomous system.

Requirement DSRC GNSS A n ne x D

6.2

provides a reference to the requirement(s) that is (are) driven by a given threat.

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

RQ.ISMS.1

An Information Security Management System (ISMS) according to

DSRC

GNSS

X

X

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 ,

RQ.ISMS.2 6.3

and continuously improved. Non-EFC speci fic threats shall be covered by a security measure or security control de fined by the ISO/IEC 27002 or equivalent standard.

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 analysis results in unreasonably high implementation costs. lists all requirements identi fied in the threat analysis.

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 Tab le 4

Table 4 — General interface requirements No. RQ. I F. 0 2

RQ. I F. 1 0

RQ. I F. 1 1

18

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

Requirement 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

availability. Data exchange shall guarantee data con fidentiality. Data exchange shall guarantee data integrity.

DSRC

GNSS

X

X

X

X

X

X

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table 4 (continued) No.

Requirement

RQ. IF.1 2 RQ. IF.1 3 RQ. IF.14 RQ. IF. 20

DSRC

GNSS

Data exchange shall guarantee the authenticity of the data originator.

X

X

Data exchange shall guarantee non-repudiation with proof of origin.

X

X

Data exchange shall guarantee non-repudiation with proof of delivery. Data exchange shall only be done between authenticated entities for

X

X

X

X

Data exchange shall allow the detection of resent messages

X

X

Data exchange shall allow the detection of mass rej ection of toll

X

X

X

X

the respective data exchange. RQ. IF. 3 0 RQ. IF. 31

(protection against replay attacks).

declarations (protection agains t interface errors) . RQ. IF. 32

Data exchange shall allow the detection of mass rej ection of billing 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 No.

Requirement

RQ. DS .01 RQ. DS .02 RQ. DS .03 RQ. DS .05 RQ. DS .06 RQ. DS .07

Access to stored data shall only be granted after authorization. Access to stored data shall only be granted via de fined interfaces and de fined procedures. Stored data shall have an independent backup storage.

Data storage shall guarantee data integrity. Access to data storage shall guarantee data con fidentiality. Data s torage shall guarantee non-repudiation with proof of origin for

DSRC

GNSS

X

X

X

X

X

X

X

X

X

X

X

X

X

X

DSRC

GNSS

applicable data. RQ. DS .0 8

Data storage shall guarantee non-repudiation with proof of delivery for

applicable data.

6.5

Toll charger

The following clauses list requirements for protection of the TCs assets.

Table 6 — Toll charger requirements No. RQ.TC .01

Requirement

The TC shall determine if factual road usage is represented by a

X

X

In case the TC performs spot checks, he shall be able to determine the

X

X

In case the TC performs spot checks, he shall be able to determine the

X

X

The TC shall check the integrity and authenticity of the received data as

X

X

The TC shall determine if toll declarations are based on data originating

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 RQ.TC .03

OBE working status (enabled by RQ.TSP.53 for autonomous systems). ICC working status in the OBE .

RQ.TC .0 4

compared to the data sent from the OBE . RQ.TC .05

from a legitimate OBE or TSP back end (enabled by RQ.TSP.55).

© ISO 2 01 5 – All rights reserved

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

19

ISO/TS 192 99: 2 015(E)

Table 6 (continued) No. RQ.TC .06

Requirement

DSRC

The TC shall make sure that any invoices generated in his name and on his behalf are conformant to the invoicing rules of his country (enabled by

GNSS

X

X

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

X

X

X

X

n. a.

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

The TC shall exhaustively test all features of an RSE update before it is

X

X

The TC shall have a rollback scenario ready before an RSE update is

X

X

X

X

X

X

RQ.TC .10

RQ.TC .1 2

(enabled by RQ.TSP.58) to identify the use of OBE versions not certi fied by the TC. The TC shall implement all necessary technical and organizational mechanisms for a correct implementation of a keyset for OBE communication provided by the TSP. The TC shall make sure that his back end system can cope with a sudden

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.

RQ.TC . 20

provided by the TC (this is covered by RQ.TSP.12). The TC shall detect RSE damaging and recover the RSE functionality

NOTE

This requirement is not applicable where the billing details are

within an agreed time frame. RQ.TC . 21 RQ.TC . 2 2

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. The TC shall implement RSE authentication measures for DSRC

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 within an agreed time frame.

RQ.TC . 24 RQ.TC . 25

The RSE shall not allow unauthorized access to software and data.

The TC shall guarantee con fidentiality, integrity, and non-repudiation with 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

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 enforcement case.

RQ.TC . 32 RQ.TC . 50

The TC shall make sure that the enforcement case data are court proof.

A data protection commissioner or delegate shall have the possibility to audit the system for compliance with data privacy regulations. NOTE

RQ.TC . 51

Such audits shall be used to prove the data protection concept.

The TC shall publish his procedures of collecting and processing personal data or regis ter with the responsible data protection authorities.

RQ.TC .70

implemented. RQ.TC .71

implemented. RQ.TC .90

RQ.TC .91

The TCs 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). The TC shall provide non-repudiation with proof of origin for dis tributed toll context data.

20

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table 6 (continued) No.

Requirement

RQ.TC .92

RQ.TC .93

RQ.TC .9 4

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 speci fic OBE (enabled by RQ.TSP.62). The TC shall only accept an OBE after detecting if the ICC in the OBE belongs to a trusted TSP and that the TSP guarantees payment for that speci fic ICC. The TC shall only accept an exception list after veri fication of

DSRC

GNSS

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

DSRC

GNSS

n . a.

X

n . a.

X

X

X

X

X

X

X

X

X

X

X

X

X

n . a.

X

n . a.

X

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 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 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 the TSPs acknowledge for di s tributed tol l context data.

RQ.TC .9 8

The TC shall implement all necessary technical and organizational meas u res to guarantee the di s tribution of corre c t tol l context data to the TSP.

RQ.TC .9 9

6.6

T he TC shal l acknowledge a re ceived excep tion li s t and provide

non-repudiation with proof of delivery to the TSP.

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 No. RQ.TS P. 01

Requirement

The TSP shall determine if factual road usage is represented by a 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 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 from a legitimate OBE or IC C .

RQ.TS P. 0 5

The OBE shall prevent or detect illegal modi fication of parameters through its external i nterfaces .

RQ.TS P. 0 6

The ICC shall prevent or detect illegal modi fication of parameters through its external i nterfaces .

RQ.TS P. 0 7

The OBE shall not allow the service user to modify fixed vehicle parame ters .

RQ.TS P. 0 8

RQ.TS P. 0 9

RQ.TS P.10

T he TS P shal l detec t duplicate or fal s e OBE or IC C identities and blo ck

such OBE or ICC identities by placing them on the exception list. The TSP shall notify the service user if the OBE or ICC is not working correctly. 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 complete ro ad us age data.

RQ.TS P.11

The TSP shall determine if factual road usage is represented by a 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. 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). © I SO 2 0 1 5 – All rights reserved

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

21

ISO/TS 192 99: 2 015(E)

Table 7 (continued) No. RQ.TSP.1 3

Requirement

DSRC

GNSS

X

X

X

X

n. a.

X

X

X

X

X

X

X

X

X

X

X

X

X

The OBE shall only present intended data by the user interface.

X

X

The TSPs implementation of the front end and gathering and processing

X

X

X

X

The TSP shall accept received toll context data only after veri fication of non-repudiation with proof of origin.

RQ.TSP.14

The TSP shall provide exception lists including non-repudiation with proof of origin to the TC .

RQ.TSP.16 RQ.TSP.17 RQ.TSP.18

The OBE shall detect signal input inconsis tencies. The TSP shall acknowledge received toll context data and provide

non-repudiation with proof of delivery to the TC. The TSP shall verify the provided non-repudiation with proof of delivery in the TCs acknowledge for a dis tributed exception list.

RQ.TSP.19 RQ.TSP. 20 RQ.TSP. 21

The TSP shall notify the TC about stolen or cloned OBE or ICC. The TSP shall accept reports of stolen OBE or ICC by service users. The TSP shall detect cloned OBE or ICC and block them by placing them on the exception lis t.

RQ.TSP.40

The OBE shall not allow change of internal data through the user interface except the data allowed to be changed.

RQ.TSP.41 RQ.TSP.42

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 systems that manage their personal data.

RQ.TSP. 51

The TSP shall enable the TC to determine if factual road usage is

X

X

RQ.TSP. 53

The TSP shall enable the TC to perform spot checks through CCC (required

X

X

RQ.TSP. 55

The TSP shall enable the TC to determine if toll declarations are based on

X

X

X

X

X

X

X

X

X

X

X

X

X

X

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). to enable RQ.TC.02 for autonomous systems).

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 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 invoice.

RQ.TSP. 5 8

The TSP shall enable the TC to check the model and make of OBE during a 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 data or regis ter with the responsible data protection authorities.

RQ.TSP.60 RQ.TSP.62

The TSP shall only use equipment that passed certi fication by the TC and delivers the agreed quality of service. The TSP shall enable the TC to detect if an OBE belongs to the TSP (required to enable RQ.TC .92) .

RQ.TSP.70

The TSP shall exhaustively test all features of an OBE update before it is implemented (e.g. dis tributed over the air) .

22

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table 7 (continued) No.

Requirement

RQ.TSP.71

The TSP shall have a rollback scenario ready before an OBE update is

DSRC

GNSS

X

X

X

X

X

X

X

X

X

X

X

X

n. a.

X

X

X

X

X

X

X

implemented (e. g. dis tributed over the air) . RQ.TSP. 80

The TSP shall implement all necessary technical and organizational quality control mechanisms for all OBE before they are distributed to the service users .

RQ.TSP. 81

The TSP shall implement all necessary technical and organizational quality control mechanism for the provision of a key set for OBE communication to the TC .

RQ.TSP. 82

The TSP shall implement all necessary technical and organizational quality control mechanism for the maintenance or exchange of OBE with low performance.

RQ.TSP. 89 RQ.TSP.90

The TSP shall take protective measures agains t repudiation of invoices and

its underlying con firmation data by service users. The TSPs systems should be designed in a way that access to stored or processed data is only possible within the legal context of the respective countries (lawful interception) .

RQ.TSP.91

RQ.TSP.92 RQ.TSP.96

The data communication between front end (OBE ) and back end (TSP)

shall be protected against interception in a way that access to stored or processed data is only possible within the legal context of the respective country (lawful interception). Customization of OBE shall be done in a secure way to guarantee data integrity and non-repudiation with proof of origin. The TSP shall guarantee the availability of its POS network according to agreed service levels .

RQ.TSP.97

The TSP shall implement all necessary technical and organizational 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 No.

Requirement

RQ.IM.01

The interoperability management shall issue an EFC security policy. NOTE

DSRC

GNSS

X

X

X

X

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 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.

© ISO 2 01 5 – All rights reserved

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

23

ISO/TS 192 99: 2 015(E)

Table 9 — Denial of service and hardware integrity threats No.

Requirement

Prevent denial of service attack. Prevent message transmission delay.

RQ. X X . 0 1

DSRC

GNSS

X

X

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 .

Prevent manipulating equipment; especially prevent OBE from HW

RQ. X X . 0 2

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 with the applicable security policy. 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

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 Table header No. Security measure DSRC GNSS

Ful illed RQ f

NOTE see

7.2

Meaning

Unique number for every security measure Description of the security measure (countermeasure) Marked with an X if this security measure is relevant for a DSRC system Marked with an X if this security measure is relevant for an autonomous system List of requirements that the security measure ful fils

For a detailed de finition for the implementation of communication interface security measure,

C l au s e

8.

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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 the national data protection commissioner or authority for compliance with national data protection regulations if required by law.

X

X

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 to perform audit(s) of the communication providers systems and procedures

X

X

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 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

shall periodically audit invoices to service users for tolls of his toll domain.

RQ.T S P. 8 2

X

X

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 No.

Requirement

DSRC

GNSS

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.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

RQ. I F. 0 2 RQ.T S P. 6 0

25

ISO/TS 192 99: 2 015(E)

Table 12 (continued) No.

Requirement

DSRC

GNSS

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 and authenticated entity.

X

X

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

SM.207

X

X

RQ.ISMS.1

to I S O/ I E C 2 70 0 1 o r a n e qu i va l e n t.

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

No.

Requirement

DSRC

GNSS

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

shall request the OBE to calculate and provide a DSRC Message Authentication Code for TC (MAC_TC) over at least the ISO 14906 attribute PaymentMeans using a key known only to the TC and the TSP during an EFC transaction. The OBE shall respond accordingly.

X

n. a.

RQ. I F. 1 1 RQ. I F. 1 2 RQ. I F. 1 3 RQ.T C . 0 1 RQ.T S P. 5 5 RQ.T S P. 8 9

26

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table 13 (continued) No.

Requirement

DSRC

GNSS

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

request the OBE to calculate and provide a DSRC Message Authentication Code for TSP (MAC_TSP) over at least the ISO 14906 attribute PaymentMeans using a key known only to the TSP during an EFC transaction. The OBE shall respond accordingly.

X

n. a.

RQ. I F. 1 1 RQ. I F. 1 2 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 authenticity and integrity.

X

n. a.

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 authenticity and integrity.

X

X

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

No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.220

SM.221

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

RSE shall request the OBE to calculate and provide a DSRC Message Authentication Code for TC (MAC_TC) over at least the ISO 14906 attribute PaymentMeans using a key known only to the TC and the TSP during a CCC transaction. The OBE shall respond accordingly. 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

RSE shall request the OBE to calculate and provide a DSRC Message Authentication Code for TSP (MAC_TSP) over at least the PaymentMeans attribute, using a key known only to the TSP during a CCC transaction. The OBE shall respond accordingly.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

n. a.

X

RQ. I F. 1 1 RQ. I F. 1 2 RQ. I F. 1 3 RQ.T S P. 5 3

n. a.

X

RQ. I F. 1 1 RQ. I F. 1 2 RQ. I F. 1 3

27

ISO/TS 192 99: 2 015(E)

Table 14 (continued) No.

Requirement

DSRC

GNSS

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

No.

Requirement

DSRC

GNSS

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

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.

n. a.

X

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

No.

Requirement

DSRC

GNSS

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

guarantees its authenticity and integrity.

n. a.

X

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

7.3 .6

TC to TSP interface Table 17 — TC to TSP interface security measures

No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.250

The bidirectional TC to TSP back office data exchange shall be

X

implemented us ing a s ecure connec tion with authentication.

X 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 the TSP or include the as so ciated event data for thos e tol l declarations

which have been acquired by him.

X

X

RQ.TSP.10 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

against the sent toll declarations to detect modi fications and/or missing or additional tol l declarations not sent to the TC in a GNS S environment.

n. a.

X

RQ.TSP.10 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 con firmed by the TSP in an agreed time frame with an authenticated

X

X 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 and con firmed by the TC in an agreed time frame with an authenticated

X

X 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.

rep orts and/or tol l declarations .

X

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 through his system on demand of the TC (charge report and/or more 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 the TSP to allow him to calcu late the amount given in the bil ling detai ls . NO TE

O ther means than I SO/ TS 17575 -3 could be used, e. g. publication

n. a.

X

RQ.TSP. 51 X

X

RQ.TC .9 8 RQ.TSP.1 2

on a webs ite.

© ISO 2 0 1 5 – All rights reserved

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

29

ISO/TS 192 99: 2 015(E)

Table 17 (continued) No.

Requirement

DSRC

GNSS

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 physical feasibility of trips in the toll domain. SM.260 SM.261 SM.262

RQ.T S P. 1 1 RQ.T S P. 1 2

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

of a key set for OBE communication to the TC.

X

X

RQ.T S P. 8 1

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

detection of duplicate messages as a protection against replay attacks.

The TSP shall provide the TC with the data about all valid OBE issued by

X

X

RQ. I F. 3 0

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 SM.265

The TC shall guarantee the correct manual entry or automatic processing of a keyset for OBE communication provided by the TSP. 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

sent toll declarations to detect modi fications, missing, or additional toll

X

X

RQ.T C . 1 0

n. a.

X

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

No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.270

The OBE shall calculate an authentication code to ICC complying with ISO/IEC 7816-3 command/response using a key known only to the ICC

X

X

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table 19 — End-to-end security measures No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.310

The OBE shall be designed as a clearly distinguished entity with a de fined interface to the TC RSE. The OBE’s functionality shall be tested to guarantee its functionality and it shall be auditable according to suitability for use procedure.

X

n. a.

RQ.TC .01 RQ.TC .07 RQ.TC .1 2 RQ.TSP. 51 RQ.TSP.60 RQ.TSP.70

SM.311

The correct and trustworthy OBE functionality shall be periodically audited by the TSP and optionally by the TC or an independent entity on his behalf. NO TE

An audit process can compare charge data of sample vehicles

equipped with the OBE with known independent trip data.

SM.312

The TC shall perform plausibility and completeness checks on toll declarations acquired by the TSP in a GNSS environment.

X

X

RQ.TC .01 RQ.TC .07 RQ.TSP. 51 RQ.TSP.60 n. a.

X

RQ.TC .01 RQ.TC .1 2

SM.313 SM.314 SM.315 SM.316

The TC shall compare toll declarations acquired by the TSP with his own observations in accordance with privacy regulations. The TC shall verify if toll declaration(s) acquired by the TSP correctly correspond(s) to charge report(s) and/or road usage data.

The TSP shall prepare a fall back scenario before any OBE update and

initiate a rollback of the update when needed.

The TC shall determine if the toll declarations have been produced by a trusted OBE by a message authentication code (MAC) or digital signature.

n. a.

X

RQ.TC .01 n. a.

X

RQ.TC .01 X

X

RQ.TSP.71 X

X 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 over the air to ensure its integrity. The OBE shall check the integrity of the received update before the update is s tarted.

SM.318

If toll declarations are acquired by the TSP, the registration of road usage data shall be based on a minimum set of functions in the OBE trusted by both the TSP and the TC. These functions shall directly or indirectly ensure the integrity of the toll declarations including non-repudiation with proof of origin.

X

X

RQ.TSP.70 n. a.

X

RQ.TC .01 RQ.TC .0 4 RQ.TC .05 RQ.TSP. 51 RQ.TSP. 55 RQ.TSP. 89

SM.319 SM.320 SM.322

The TSP shall provide an undeniable proof of correct regis tration of road

usage data for a de fined location and moment in time or for a de fined range of time and for a speci fied set of OBE(s) on demand to the TC.

The TC shall compare proof of correct regis tration of road usage data

acquired by the TSP with his own observations in accordance with privacy regulations. The OBE shall be designed as a clearly distinguished entity with a de fined interface to the proxy or TSPs back end. The OBE’s functionality shall be tested to guarantee its functionality and it shall be auditable according to a de fined procedure.

n. a.

X

RQ.TSP. 51 n. a.

X

RQ.TC .01 n. a.

X

RQ.TC .07 RQ.TSP.01 RQ.TSP.60 RQ.TSP.70

© ISO 2 01 5 – All rights reserved

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

31

ISO/TS 192 99: 2 015(E)

Table 19 (continued) No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.323

The TSP shall perform plausibility and completeness checks on toll declarations acquired by him. Those checks comprise the veri fication of the physical feasibility of trips in the toll domain compared with the

n. a.

X

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

No.

Requirement

DSRC

GNSS

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 SM.412

The TSP shall test a signi ficant percentage of OBE delivered to him to achieve an accepted quality level according to ISO 2859 or equivalent. 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

DSRC interface, the TSP shall store the value of the MAC_TC, KeyRef, and

X

X

RQ.T S P. 8 0

n. a.

X

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

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.

X

X

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 con fidentiality, integrity, and authenticity.

n. a.

X

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table 20 (continued) No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.417

The OBE shall s witch to a “NO T OK” s tate if it detects signal input

inconsistencies and the TSP shall be informed by the GNSS OBE.

SM.418

The OBE shall not allow the service user to modify any data in the OBE except the data allowed to be changed through the user interface.

n. a.

X

RQ.TSP.16 X

X

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

No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.420 SM.421

The TSP shall verify if toll declaration(s) correctly correspond(s) to charge report(s) and/or road usage data.

The TSP shall determine if the charge report has been produced by a trus ted front end.

n. a.

X

RQ.TSP. 51 n. a.

X

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 or by detecting multiple locations for the same OBE or ICC at the same time.

X

X

RQ.TSP.0 8 RQ.TSP. 21

SM.425

The TSP shall use cryptographic measures to encrypt the sending of customization data to the OBE to guarantee data integrity and

non-repudiation with proof of origin.

SM.426

The TSP shall verify the integrity of the charge report based on the MAC_TSP or digital signature.

X

X

RQ.TSP.92 RQ.TSP.97 n. a.

X

RQ. IF.11 RQ. IF.1 2 RQ. IF.1 3 RQ.TSP.01 RQ.TSP.03 RQ.TSP.0 4

© ISO 2 01 5 – All rights reserved

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

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

No.

Requirement

DSRC

GNSS

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

check the value of the MAC_TC using the key addressed by KeyRef and the

X

n. a.

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

store the value of the authenticated AttributeList, MAC_TSP, KeyRef, and

X

n. a.

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

shall check the value of the MAC_TC using the key addressed by KeyRef

n. a.

X

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 SM.516

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

shall store the value of the authenticated AttributeList, MAC_TC, MAC_TSP, KeyRef, and RndRSE as part of the compliance check record. The RSE’s functionality shall be tested to guarantee its functionality.

n. a.

X

RQ. I F. 1 2 RQ. I F. 1 3

X

X

RQ.T C . 70

7.6.2

Back end security measures Table 23 — TC Back end security measures

No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.520

34

The TC shall perform plausibility and completeness checks on toll declarations acquired by him through the DSRC interface.

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

X

n. a.

RQ.T C . 1 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)

Table 23 (continued) No.

Requirement

DSRC

GNSS

Ful illed RQ f

SM.521

If toll declarations are acquired by the TSP and these are based on LAC data, the TC shall check the value of the MAC_TC using the key addressed by KeyRef and the RndRSE.

n. a.

X

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, data integrity, and non-repudiation with proof of origin of a keyset for

X

X

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

No.

Requirement

DSRC

GNSS

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

compare them with his own observations in accordance with privacy

n. a.

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 8.1.1

General 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 directly related to an application data unit (ADU) speci fication of an interoperable interface. C l au s e

8.1.2

7

wh i ch

a re

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; © I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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 ,

keying material. 9.2 9.2 .1

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 ,

a n d de s tr uc ti o n

of

Asymmetric keys Key exchange between stakeholders

The exchange of root public keys, i.e. CA root certi ficates is de fined in

36

de r i vatio n ,

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

5 . 4 .1 .

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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) .

© ISO 2 0 1 5 – All rights reserved

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

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 9.3 .2 .1

Key exchange between stakeholders 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

9.3 .2 .3

Padding algorithm

in PKCS#1 v2.1 when KDF1 is applied.

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

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 2015 – All rights reserved

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

Identi ied by

DSRC AID

1 1 1 20 20 20 21 21

Applicable standard

f

EFC_ContextMark + KeyRef EFC_ContextMark + KeyRef EFC_ContextMark CCC_ContextMark + KeyRef CCC_ContextMark + KeyRef CCC_ContextMark LAC_ContextMark LAC_ContextMark +

Key usage

ISO 13141:2015

Authentication key1 ... Authentication key4 Authentication key5 ... Authentication key8 Access Key Authentication key1 ... Authentication key4 Authentication key5 ... Authentication key8 Access Key Access Key

ISO 13141:2015

LAC _Authentication-

EN 15509:2014 EN 15509:2014 EN 15509:2014 ISO 12813:2015 ISO 12813:2015 ISO 12813:2015

keyRefMAC_TC_

Key_TC

KeyType

Resulting authentication code

0

MAC_TC

0

MAC_TSP

1

AC _CR

2

MAC_TC

2

MAC_TSP

3

AC _CR

4

AC _CR

n.a.

MAC_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.

© ISO 2015 – All rights reserved

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

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 9.3 .4.1

Key storage and protection 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

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 0 1 5 – All rights reserved

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).

© ISO 2015 – All rights reserved

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

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: Simpli fied risk assessment description.

Risk assessment:

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.

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

Risk assessment:

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

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 – All rights reserved

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. Requirement pro file:

Mandatory:

RQ.IF.02 + RQ.IF.10 + RQ.IF.11 + RQ.IF.13 + RQ.IF.30

Recommended:

RQ.IF.12 + RQ.IF.20

Pro ile B (extended pro ile A) f

Risk assessment:

f

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: © ISO 2015 – All rights reserved

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

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.

Requirement pro file:

Mandatory: RQ.IF.11 + RQ.IF.12 + RQ.IF.13 + RQ.IF.20 + RQ.IF.30 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

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

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

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:

-

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.

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:

-

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:

© ISO 2 01 5 – All rights reserved

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

-

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 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

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 – All rights reserved

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. no answer required (allowed only if the status is n/a directly or after evaluation

N/A, n/a or -

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 > ( ), < name2 > ( ), ..., < nameN > ( )

EXAMPLE 1:

rej ect(1) , accept(2)

length:

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 .

© ISO 2 01 5 – All rights reserved

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

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 T he

Instructions for completing the ICS proforma

s up p l ie r

o f the

o f the

s p ac e s

i mp le me nt atio n

p ro vi de d .

In

or

p a r tic u l a r,

an an

ac to r

t a ki n g a

e x p l ic i t

ro le

a n s we r

shall

shal l

be

c o mp le te e nte re d ,

supported column boxes provided using the notation described previously.

the in

IC S

e ach

p ro fo r m a o f the

in

e ac h

s up p o r t

or

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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: ……………………………………………………………………………………………………………………………………… ……… . . Additional information: ……………………………………………………………………………………………………………………………………… ……… . .

© I SO 2 0 1 5 – All rights reserved

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

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: ……………………………………………………………………………………………………………………………………… ……… . . Additional information: ……………………………………………………………………………………………………………………………………… ……… . . ……………………………………………………………………………………………………………………………………… ……… . . ……………………………………………………………………………………………………………………………………… ……… . .

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. Nonsupported 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

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

© I SO 2 0 1 5 – All rights reserved

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

5.2

o. 2–1

5.2

c. 2–2

5.2

c. 2 –3

5 . 3 .4

c. 2– 4

(using a TTP)

4 5 6

Use of a peer-to-peer trus t model

Root CA is performed by IM Root CA is performed by external

TTP

7

Use of trus t model for all 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 Item

Supported functionality

Reference

Status

Support (Y/N)

1

Importing CA root certi ficate from

5 .4.1

c. 3 –1

- downloading the certi ficate from

5 .4.1

o. 3 –1

3

- retrieving it per courier, if it is

5 .4.1

o. 3 –1

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

5 .4.1

o. 3 –2

5 .4.1

o. 3 –2

a TTP according to method 3 of

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

2

a recognized and secure website

supported by the TTP

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 ISO/IEC 11770 -3: 201 5 , C lause 1 2 or an equivalent

8

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

© ISO 2 01 5 – All rights reserved

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

51

ISO/TS 192 99: 2 015(E)

Table B.3 (continued) Item

Supported functionality

Reference

Status

Support (Y/N)

Key veri fication using a fingerprint based on the algorithms de fined in

9

5 .4.1

c. 3 –3

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. c. 3 -2 : I F Table B . 2/4 TH E N m E LSE n/a. c. 3 -3 : I F Table B . 3/8 TH E N m E LSE n/a.

Table B.4 — Trust relation renewal and revocation Item

Supported functionality

Reference

Status

Support (Y/N)

1

Length of private key of root certi ficate sufficient for duration

5 .4. 2

m

5 .4. 2

m

5 .4. 2

m

5 .4. 2

m

5 .4. 2

m

of us e

2

Validity of root certi ficate accordi ng to the length of the

private key

3

Automatic termi nation of trus t relation after expi ration date of

root certi ficate 4

Replacement of a root certi ficate accordi ng to Table B . 3

5

Replacement of derived s ub - C A

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

7

Automatic termi nation of trus t

5 .4. 2

m

5 .4. 2

m

certi ficates

relation after revo cation of ro ot

certi ficate 8

Use of Certi ficate Revocation List as de fined in ISO/IEC 9594-8

9

Signi ng of revo cation mes s age for

5 .4. 2

m

Veri fication of the signature of

5 .4. 2

m

10

a root certi ficate

revocation mes s age for a ro ot

certi ficate

52

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

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table B.5 — Issuing and revocation of sub-CA and end-entity certi icates f

Item

Supported functionality

Reference

Status

Support (Y/N)

1

2

Private key of root certi ficate only used for signing end-entity or sub CA certi ficates Extended Key Usage extensions

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

5 .4. 3

m

accordi ng to I S O/I E C 959 4 - 8 us ed

3

Certi ficate validation process can handle at least four certi ficate level s

4

End-entity certi ficate for securing communication channel s

5

End-entity certi ficate for message s igni ng

6 7 8 9

End-entity certi ficate for message/key encryption Use of Certi ficate Revocation List as de fined in ISO/IEC 9594-8 Signi ng of revo cation mes s age for

a root certi ficate Veri fication of the signature of 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

Item

f

Supported functionality

f

Reference

Status

Support (Y/N)

1

ISO/IEC 9594-8 certi ficates

5 .4.4

m

5 .4.4

m

5 .4.4

m

5 .4.4

m

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 i s s ued accordi ng to I S O/I E C 9 59 4 - 8 with the up date

3 4 5

speci fied in RFC 6818 All certi ficates DER encoded and Base64 encoded (PEM certi ficate) Al l C RL DE R enco ded and B as e6 4

encoded (PEM CRL) Key veri fication using a fingerprint based on the algorithms de fined in I S O 1 2 85 5 : 2 01 5

© I SO 2 0 1 5 – All rights reserved

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

53

ISO/TS 192 99: 2 015(E)

Table B.7 — Certi icate and certi icate revocation list pro ile and format f

Item

f

f

Supported functionality

Reference

Status

Support (Y/N)

1 2

Agreement on the u se of critical

certi ficate extensions All certi ficate extensions de fined

5 .4. 5

m

5 .4. 5

m

5 .4. 5

m

5 .4. 5

m

either as critical or non- critical

3 4

Rej ec tion of u nrecogn i zed critical

certi ficate extensions Rejection of critical certi ficate 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

5 .4. 5

m

5 .4. 5

m

5 .4. 5

c.7–1

5 .4. 5

c.7–2

5 .4. 5

m

5 .4. 5

m

7

8

9

certi ficate extensions

certi ficate extensions Only use key usage and basic constraints as critical certi ficate extensions in a root certi ficate Only use key usage with allowed values as critical certi ficate extensions in an end-entity certi ficate Only use extended key usage with OI D for the TC to TSP b ack end i nterface

10

Only use Extended Key Usage with OI D for the TS P Front E nd to B ack E nd interface

11

12

Only use allowed non-critical certi ficate extensions in a root certi ficate Only use allowed non-critical 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 2 3

54

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

DSRC pro file TC to TSP pro file A TC to TSP pro file B

A . 2 .1

o

A. 2 . 2

o

A. 2 . 2

o

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table B.8 (continued) Item

Requirement

Reference

Status

Support (Y/N)

4

C ommunication

8

provider pro file ICC interface pro file OBE data storage pro file ICC data storage pro file RSE data storage pro file

9

B ack end data s torage

5 6 7

pro file

A. 2 . 3

o

A . 2 .4

o

A . 3 .1

o

A. 3 . 2

o

A. 3 . 3

o

A . 3 .4

o

B.8 Requirements Table B.9 — Information system security requirements Item

Requirement

Reference

Status

Support (Y/N)

1 2

RQ.ISMS.01 RQ.ISMS.02

6.2

m

6.2

o

Table B.10 — General interface requirements Item

Requirement

Reference

Status

Support (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 .

© I SO 2 0 1 5 – All rights reserved

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

55

ISO/TS 192 99: 2 015(E)

Table B.11 — Data Storage requirements Item

Requirement

Reference

Status

Support (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 Item

Requirement

Reference

Status

Support (Y/N)

56

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

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

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table B.12 (continued) Item

Requirement

Reference

Status

Support (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 Item

Requirement

Reference

Status

Support (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

© I SO 2 0 1 5 – All rights reserved

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

57

ISO/TS 192 99: 2 015(E)

Table B.13 (continued) Item

Requirement

Reference

Status

Support (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 Item

Requirement

Reference

Status

Support (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 Item

Requirement

Reference

Status

Support (Y/N)

58

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

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

© I SO 2 0 1 5 – All rights reserved

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

2

SM201

3

SM202

4

SM203

5

SM204

6

SM205

7

SM207

8

SM208

c.16-1: IF any requirement listed in

Tab le 1 2

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

7. 3 . 1

c . 1 6 –1

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 Item

Measure

Reference

Status

Support (Y/N)

1

SM210

2

SM211

3

SM212

4

SM213

5

SM214

6

SM215

c.17-1: IF any requirement listed in

Tab l e 1 3

7. 3 . 2

c . 1 7–1

7. 3 . 2

c . 1 7–1

7. 3 . 2

c . 1 7–1

7. 3 . 2

c . 1 7–1

7. 3 . 2

c . 1 7–1

7. 3 . 2

c . 1 7–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.18 — CCC interface security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM220

2

SM221

3

SM222

4

SM223

c.18-1: IF any requirement listed in

Tab le 14

7. 3 . 3

c . 1 8 –1

7. 3 . 3

c . 1 8 –1

7. 3 . 3

c . 1 8 –1

7. 3 . 3

c . 1 8 –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.19 — LAC interface security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM230

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

7. 3 . 4

c . 19 –1

59

ISO/TS 192 99: 2 015(E)

Table B.19 (continued) Item

Measure

Reference

Status

Support (Y/N)

2

SM231

7. 3 . 4

c.19-1: IF any requirement listed in

Tab le 1 5

c . 1 9 –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 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 Item

Measure

Reference

Status

Support (Y/N)

1

SM240

2

SM241

c.20-1: IF any requirement listed in

Tab le 1 6

7. 3 . 5

c . 2 0 –1

7. 3 . 5

c . 2 0 –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.21 — TC to TSP interface security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM250

2

SM251

3

SM252

4

SM253

5

SM254

6

SM255

7

SM256

8

SM257

9

SM258

10

SM259

11

SM260

12

SM261

13

SM262

14

SM263

15

SM264

16

SM265

17

SM266

c.21-1: IF any requirement listed in

Tab le 17

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 1 –1

7. 3 . 6

c . 2 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 l e B . 1 3 , o r Tab le B . 14 , T H E N m E L S E n/a .

Table B.22 — End-to-end security measures Item

Measure

Reference

Status

Support (Y/N)

1

60

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

SM310

7. 4

c . 2 2 –1

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table B.22 (continued) Item

Measure

Reference

Status

Support (Y/N)

2

SM311

3

SM312

4

SM313

5

SM314

6

SM315

7

SM316

8

SM317

9

SM318

10

SM319

11

SM320

12

SM322

13

SM323

14

SM324

15

SM330

c.22-1: IF any requirement listed in

Tab le 19

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –1

7. 4

c . 2 2 –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.23 — Front end/OBE interface security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM410

2

SM411

3

SM412

4

SM413

5

SM414

6

SM415

7

SM416

8

SM417

9

SM418

10

SM419

c.23-1: IF any requirement listed in

Tab le 2 0

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

7. 5 . 1

c . 2 3 –1

for this security measure is selected in

Tab le B .9 , Tab l e 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.2 4 — TSP back end security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM420

2

SM421

3

SM422

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

7. 5 . 2

c . 2 4 –1

7. 5 . 2

c . 2 4 –1

7. 5 . 2

c . 2 4 –1

61

ISO/TS 192 99: 2 015(E)

Table B.2 4 (continued) Item

Measure

Reference

Status

Support (Y/N)

4

SM423

5

SM424

6

SM425

7

SM426

c.24-1: IF any requirement listed in

Tab le 2 1

7. 5 . 2

c . 2 4 –1

7. 5 . 2

c . 2 4 –1

7. 5 . 2

c . 2 4 –1

7. 5 . 2

c . 2 4 –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.25 — RSE security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM510

2

SM511

3

SM512

4

SM513

5

SM514

6

SM515

7

SM516

c.25-1: IF any requirement listed in

Tab le 2 2

7. 6 . 1

c . 2 5 –1

7. 6 . 1

c . 2 5 –1

7. 6 . 1

c . 2 5 –1

7. 6 . 1

c . 2 5 –1

7. 6 . 1

c . 2 5 –1

7. 6 . 1

c . 2 5 –1

7. 6 . 2

c . 2 5 –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.26 — TC Back End security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM520

2

SM521

3

SM522

4

SM523

5

SM524

6

SM525

c.26-1: IF any requirement listed in

Tab le 2 3

7. 6 . 2

c . 2 6 –1

7. 6 . 2

c . 2 6 –1

7. 6 . 2

c . 2 6 –1

7. 6 . 2

c . 2 6 –1

7. 6 . 2

c . 2 6 –1

7. 6 . 2

c . 2 6 –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.27 — Other TC security measures Item

Measure

Reference

Status

Support (Y/N)

1

SM530

c.27-1: IF any requirement listed in

7. 6 . 1

Tab le 2 4

c . 2 7–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 l e B . 1 3 , o r Tab le B . 14 , T H E N m E L S E n/a .

62

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

8.2 .3

c. 2 8 –2

8.2 .3

c. 2 8 –2

8.2 .3

c. 2 8 –2

8.2 .3

C . 2 8 –3

for E FC

2

Security level 1 RSE for E FC

4

RSE requests MAC_TC RSE requests MAC_TC

5

Agre ement with

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.

© I SO 2 0 1 5 – All rights reserved

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

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

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 – All rights reserved

ISO/TS 192 99:2 015(E)

EXAMPLE 4 c)

For Europe, see Reference [7 ], Annex III, article 2.1.1.4.

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, © ISO 2 0 1 5 – All rights reserved

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

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

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 0 1 5 – All rights reserved

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

C.4.2

for detailed explanation about user privacy.

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 C.5.1

Interoperability management 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.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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

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 – All rights reserved

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.

© ISO 2 01 5 – All rights reserved

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

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

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 – All rights reserved

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 Table header

Meaning

No.

Unique number for every threat according to the numbering scheme described in D.1 . 2 .

Threat

D escrip tion of the threat.

Marked with an X if this requirement is relevant for a DSRC system. Marked with an X if this requirement is relevant for an autonomous system. Reference to the requirement(s) driven by the threat..

DSRC GNSS

Related RQ

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

© ISO 2 0 1 5 – All rights reserved

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

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 No.

Threat

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

DSRC

GNSS

X

X

Related RQ

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

example, by covering the antenna where this is applicable.

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 .1 2

Muting the OBE

n. a.

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

road usage sensor itself (i.e. autonomous systems only), the communication signal might be temporarily or permanently blocked, thus 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 ”.

X

RQ.T C . 0 1 RQ.T C . 0 2 RQ.T S P. 0 1 RQ.T S P. 51 RQ.T S P. 0 9

T H . S U.101 .1 3

Removing or destroying the OBE

X

One of the simplest, yet most effective attacks is to destroy or remove the

X

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

T H . S U . 1 0 1 . 14

measure is designed, this will render the vehicle “invisible” for the system. Disconnect the OBE power supply temporarily or permanently The simplest attack is to remove the OBE power supply. That can be done permanently or only temporarily, e.g. by inserting a switch in the power supply.

X

X

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 .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

RQ.T C . 0 1

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 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

e.g. with a portable jamming device or an ITS-system

n. a.

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

One of the simplest, yet most effective attacks is to destroy the ICC and 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

RQ.T C . 0 2

X

X

RQ.T C . 0 1

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 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

72

Sub goal: Manipulating the system to register the wrong road usage

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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 No.

Threat

TH . SU.101 . 21

Manipulating the input to the road usage sensors This attack is typically relevant in systems where road usage is continually recorded (such as in GNSS-based systems) and involves spoo fing the signal that goes into the sensor. It does not require any modi fications to the OBE since it is directed at the road usage signal before it enters the OBE .

TH . SU.101 . 2 2

Manipulating the road usage sensors This attack involves modifying the road usage sensors, for example, by replacing them or filtering their output to generate data that results in a lower toll. It is performed in real time and modi fies road usage data as it is

DSRC

GNSS

n. a.

X

Related RQ RQ.TC .01 RQ.TSP.01 RQ.TSP.16 RQ.TSP. 51

n. a.

X

RQ.TC .01 RQ.TSP.01 RQ.TSP. 51

collected. TH . SU.101 . 2 3

Manipulating the road usage data collection software The software calculating the road usage based on the sensor inputs is

TH . SU.101 . 24

altered in such a way that a lower road usage will be recorded, stored, and transmitted to the back end (only possible in autonomous systems). Manipulating the road usage data after collection in the OBE or ICC In the case where several items of road usage data remain under the

control of the service user, before being reported to another party, the service user has the possibility of modifying the road usage data taking the whole data set into account.

n. a.

X

RQ.TC .01 RQ.TSP.01 RQ.TSP. 51 n. a.

X

RQ.TC .01 RQ.TC .0 4 RQ.TSP.01 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 of road usage Use ICC simulation equipment instead of a real ICC .

n. a.

X

RQ.TC .01 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

© ISO 2 01 5 – All rights reserved

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

73

ISO/TS 192 99: 2 015(E)

Table D.4 — SU goal: Avoiding payment of toll — Faking toll parameters DSRC

GNSS

Faking vehicle parameters

X

X

The service user sets vehicle parameters to a value that does not re flect reality, but that lowers the toll.

RQ.TSP.05

No.

Threat

TH . SU.101 . 31

Related RQ RQ.TC .02 RQ.TSP.40 RQ.TSP. 53

TH . SU.101 . 32

Faking identity The service user sets OBE, ICC or user identity parameters to a value that does not re flect reality and that lowers the toll (e.g. reduced tariff for disabled person) or charges the toll to another (or a fake) user.

X

X

RQ.TC .02 RQ.TSP.05 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 No.

Threat

TH . SU.101 .41

Force insufficient OBE data buffer

DSRC

GNSS

n. a.

X

Related RQ

Preventing the OBE from sending data to the back end for as long as

RQ.TC .01

longer being collected or overwriting old road usage not taken in account

RQ.TSP.01

in the back end.

RQ.TSP.09

possible to produce insufficient memory that results in road usage no

RQ.TC .02

RQ.TSP. 51 RQ.TSP. 53 TH . SU.101 .42

TH . SU.101 .43

Bribing TC or TSP employee to manipulate the service user account The service user in fluences (e.g. bribes, as family or friend) an employee to manipulate his account to pay lower toll to avoid a penalty, etc. Denying presence in toll domain

X

RQ.ISMS.2 X

X

The service user denies the presence in a toll domain at a given time and

RQ.TSP. 89

Using an OBE without a valid contract with a TSP

X

thus, denies payment of invoice.

TH . SU.101 .44

X

SU uses an OBE without a valid contract with a TSP to avoid payment to

X

RQ.TC .92

the TSP.

TH . SU.101 .45

Using an ICC without a valid contract with a TSP

X

SU uses an ICC without a valid contract with a TSP to avoid payment to

X

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). — Secondly, if it becomes a wide-spread practice, it undermines the belief that the EFC system is correct and fair.

74

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 – All rights reserved

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

motivated by spite. D.2 .4.4

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

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). — Secondly, if it becomes a wide-spread practice, it undermines the belief that the EFC system is 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

motivated by a concern for the service user’s own privacy. D.2 .5

e c o no m i c i nce n ti ve ,

b ut b e

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 No.

Threat

T H .T S P. 1 0 4 . 0 1

Fa k i n g r o ad u s e

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 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

DSRC

GNSS

X

X

Related RQ RQ.T C . 1 3 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

The TSP could use faulty toll context data to in flate the toll charged to 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

n. a.

X

RQ.T S P. 1 7 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

The TSP charges the service user a higher amount as calculated by himself or by the TC(s) based on the billing details. The TSP changes the

X

X

RQ.T S P. 5 7

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 The TSP modi fies toll declarations acquired and reported by him to i nc r e a s e h i s r e mu n e r ati o n .

n. a.

X

RQ.T C . 1 3 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.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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

No.

Threat

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

DSRC

GNSS

X

X

Related RQ

The TSP collects and compiles service user pro files, based on the collected vehicle position data and/or vehicle mileage, in a way that is

RQ.T S P. 5 9

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) No. T H .T S P. 1 0 6 . 0 1

Resell service user data to third party 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

T H .T S P. 1 0 6 . 0 2

transmitted to an external party without the knowledge of the SU. Allow service user tracking by third parties The collected service user and vehicle position data, maybe more data 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 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

T H .T S P. 1 0 6 . 0 3

D.2 .5.5

DSRC

GNSS

X

X

Related RQ

Threat

service user and vehicle tracking. The attack is either performed by the TSP or by his staff without the knowledge of TSP. Provide speci fic data mining based on road usage data Perform speci fic data mining and statistics on demand and distribute the (even anonymous) results to commercially interested parties.

RQ.T S P. 5 9

X

X

RQ.ISMS.1 RQ.ISMS.2 RQ.T S P. 5 9

X

X

RQ.T S P. 5 9

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table D.9 — TSP goal: Reselling of data about service user(s) No.

Threat

T H .T S P. 1 0 7. 0 1

Modifying road usage data reported from the OBE The TSP could modify the road usage data to be sent to the TC so that the toll is de flated, for example, slightly shifting the time values to put the

DSRC

GNSS

n. a.

X

Related RQ RQ.T C . 0 1 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

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 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.

T H .T S P. 1 0 7. 0 3

Faulty interpretation of road usage data In certain set ups, the TSP will have the ability to interpret the road usage data in a way that in flates the toll that is due to the TC while using the

n. a.

X

RQ.T C . 0 1 RQ.T S P. 5 1

n. a.

X

RQ.T C . 0 1 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

If the TSP is in control of computing the final toll or some data on which the final toll is computed, it could use faulty toll context data to de flate 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

n. a.

X

RQ.T C . 0 1 RQ.T C . 1 7 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 A TSP which has been requested by a TC to enrich determined charging data may manipulate them to reduce the final toll while using the correct

n. a.

X

RQ.T C . 0 1 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

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

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

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

TSP to get paid by the SU without paying the TC. D.2 .5.6

n. a.

X

RQ.T C .9 2

n. a.

X

RQ.T C .9 3

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 No.

Threat

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

The TSP could use equipment that does not ful fil agreed certi fications or that cannot deliver the agreed quality of service.

DSRC

GNSS

X

X

Related RQ RQ.T C . 0 7 RQ.T C . 0 8 RQ.T S P. 5 8 RQ.T S P. 6 0

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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

No.

Threat

TH .TSP.10 9. 01

Using an OBE longer than its guaranteed battery life

DSRC

GNSS

X

X

Related RQ

The TSP could use an OBE longer than its guaranteed battery life which leads to a lower quality of service and additional cost/loss of income to

RQ.TSP. 82

the TC . TH .TSP.10 9. 02

No t exchanging OBE with low p erformance

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

X

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 D.2 .6.1

Attacker class 3 : Toll charger 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 No.

Threat

TH .TC .111 .01

Modify toll declarations acquired by the TC

TH .TC .111 . 02

TH .TC .111 . 03

78

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

DSRC

GNSS

X

n. a.

Related RQ

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

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

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

© ISO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.12 (continued) No.

Threat

TH .TC .111 .0 4

Modify toll declarations reported by the TSP The TC modi fies the toll declarations acquired and reported by the TSP

DSRC

GNSS

n. a.

X

Related RQ 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 The TC inserts fake toll declarations into the lis t of toll declarations

acquired and reported by the TSP and reports them as billing details back

n. a.

X

RQ.TSP.1 2

to the TSP. TH .TC .111 .06

Repudiate the origin of toll context data The TC repudiates the origin (or the update of a new version) of the toll

context data and claims payment for service users according to the old toll context data.

X

X

RQ.TC .91 RQ.TC .97 RQ.TSP.13 RQ.TSP.17

TH .TC .111 .07

Repudiate reception of exception list The TC denies or repudiates the reception of an exception list and claims

payment for service users which were on the denied or repudiated list at the time of acquisition of the toll declaration(s) by him. D.2 .6.3

X

X

RQ.TC .9 4 RQ.TC .9 9 RQ.TSP.14 RQ.TSP.18

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 No.

Threat

TH .TC .106 .01

Resell service user data to third party

TH .TC .106 .02

transmitted to an external party without the knowledge of the SU. Allow service user tracking by third parties The collected service user and vehicle position data, maybe more

The collected service user and vehicle position data are sold and

data than is required for charging purposes, are sold and transmitted “in real time” to third parties without the permission of the service user for

TH .TC .106 .03

D.2 .6.4

service user and vehicle tracking. The attack is either performed by the TC or by his staff without knowledge of the TC. Provide speci fic data mining based on road usage data Perform speci fic data mining and statistics on demand and distribute the (even anonymous) results to commercially interested parties.

DSRC

GNSS

X

X

Related RQ RQ.TC . 51

X

X

RQ.ISMS.1 RQ.ISMS.2 RQ.TC . 51

X

X

RQ.TC . 51

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.

© ISO 2 01 5 – All rights reserved

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

79

ISO/TS 192 99: 2 015(E)

Table D.14 — TC goal: Neglect maintenance of equipment No.

Threat

T H .T C . 1 1 2 . 0 1

Avoiding a regular maintenance of RSE equipment in free flow systems 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

to a lower quality of service and possible claims of low OBE performance

DSRC

GNSS

X

n. a.

Related RQ RQ.T C . 2 0 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 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

low performance prolonging lower quality of service and possible claims

X

n. a.

RQ.T C . 2 0 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

systems

X

n. a.

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

to the use of manual payment instead of handling through the TSP

RQ.T C .9 6

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

DSRC systems

X

n. a.

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

low performance prolonging the use of manual payment instead of the

RQ.T C .9 6

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 No. T H .T C . 1 1 3 . 0 1

DSRC

GNSS

X

X

Related RQ

Threat

Poor quality of toll context data 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

The TC could provide faulty toll context data to in flate the toll charged to

X

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 D.2 .7.1

Attacker class 4: Hacker 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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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 No.

Threat

TH . H A.11 5 . 01

Fake an input s ignal from the vehicle and have it accep ted as valid

In this attack, a signal required for the operation of the system is emulated or modi fied to change its semantics. Typical sources of signals are CAN

DSRC

GNSS

X

X

Related RQ RQ.TSP.16

bus , tachograph, or o dometer. TH . H A.11 5 . 02

Induce noise on power supply lines to cause system misoperation Excessive power supply noise can induce system misoperation and/or system restarts with corresponding loss of data.

X

X

RQ.TC . 01 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 Adjust the OBE so that it is inappropriately set (for example, telling it that it is in a p as senger car rather than a truck) .

X

X

RQ.TSP.0 5 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

For example, to automatically update the class of a vehicle before an audit check event takes place to generate problems for the ser vice users .

X

X

RQ.TC . 01 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.

© ISO 2 0 1 5 – All rights reserved

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

81

ISO/TS 192 99: 2 015(E)

Table D.17 — Hacker goal: Obtain respect amongst their peers No.

Threat

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

T H . H A .116 . 02

DSRC

GNSS

X

X

Related RQ

Allowing the modi fication of the data that is recorded by the secure element (secure storage in OBE, e.g. HSM). Extract private keys from the OBE Allowing the falsi fication of an OBE to act as the OBE for the purpose of

-

X

X

-

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.),

T H . H A .116 . 0 6

T H . H A .116 . 0 7

—

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 .

Act as the maintenance and customization functionality Enabling elevated access to the system for the purpose of modifying its con figuration. 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

-

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

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

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

X

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

-

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

Modify the input signals that are received by the charging application with

X

-

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

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table D.17 (continued) DSRC

GNSS

n. a.

X

Related RQ

No.

Threat

TH . H A.116.14

Access to OBE for manipulation of output state

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 No. TH . H A.117.01

DSRC

GNSS

n. a.

X

Related RQ

Threat Intercept the communication between the OBE (front end) and the TSP 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

OBE . TH . H A.117.0 4

Y

RQ. XX.02

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

Clone an OBE

X

X

Clone an existing OBE and its private key on an original OBE or an

RQ.TSP.0 8

No.

Threat

TH . H A.118 .01

also-cloned hardware.

Related RQ RQ.TSP.10 RQ.TSP.19 RQ.TSP. 21

TH . H A.118 .02

Build a fake OBE

X

Design and build a fake OBE which is not (easily) detectable by RSE and

RQ.TSP.0 8

enforcement equipment.

© ISO 2 01 5 – All rights reserved

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

X

RQ.TSP.10

83

ISO/TS 192 99: 2 015(E)

Table D.19 (continued) DSRC

GNSS

X

X

Related RQ

No.

Threat

T H . H A .11 8 . 0 3

C lo ne a n I C C

Clone an existing ICC and its private key on an original ICC or also, on an

RQ.T S P. 0 8 RQ.T S P. 1 0

a l s o - c l o ne d h a r d wa r e .

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

Design and build a fake ICC which is not (easily) detectable by RSE and

D.2 .8.1

RQ.T S P. 0 8 RQ.T S P. 1 0

e n fo r c e me n t e q u i p m e n t.

D.2 .8

X

Attacker class 5: Activist 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 No.

Threat

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

84

GNSS

n. a.

X

Related RQ

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.

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

DSRC

-

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table D.20 (continued) No.

Threat

TH . AC T.119. 02

Breach of data integrity/non-repudiation Break into the system or into data communication between parts of the system and change the contents of messages and possibly the associated

DSRC

GNSS

X

X

Related RQ -

mes s age authenticators . TH . AC T.119. 03

Manipulating the exception list by, for example, deleting entries or

X

i ns er ti ng new entries

TH . AC T.119. 0 4

Breach of data con fidentiality/privacy 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

X -

X

X -

can b e achieved i n the general publ ic. TH . AC T.119. 0 5

D enial of ser vice

X

The whole or parts of the charging system may be prevented from

-

op eration . TH . AC T.119. 0 6

X

-

Manipulate the status of a large population of OBE Cause OBE malfunction which leads to inability to access the system or unjusti fied enforcement to service users.

X

X -

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. 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.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. 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 .

© I SO 2 0 1 5 – All rights reserved

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

85

ISO/TS 192 99: 2 015(E)

D.2 .9 D.2 .9.1

Attacker class 6: Communication provider 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 No.

Threat

TH .CP.1 23 .01

Data corruption

DSRC

GNSS

X

X

Related RQ

Deliberately, corrupting the data f low leading to retransmission of packets and thus, increased aggregate data flow. D.2 .9.3

RQ. IF.02

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 No.

Threat

TH .CP.1 24.01

Prevent data transfer

DSRC

GNSS

n. a.

X

Related RQ

By preventing data transfer from the OBE for an extended period of time, it is possible to make the OBE data buffer over flow and the data to be lost,

RQ. IF.02

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 No.

Threat

TH .CP.1 25 .01

Data communication interception

DSRC

GNSS

X

X

Related RQ

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

RQ.TC .90

iles.

RQ.TSP.90 RQ.TSP.91

86

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.23 (continued) No.

Threat

TH .CP.1 25 .02

DSRC

GNSS

n. a.

X

Related RQ

Data traffic analysis The attack analyses the data communication traffic, i.e. the connection, location, duration, and frequency of the communications to generate service user tracking pro files.

RQ. IF.10

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 No. TH . EN.1 26.01

Threat

Bribing TSP or TC employee to get data A main attack avenue may 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

DSRC

GNSS

X

X

Related RQ RQ.ISMS.2

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 interface

X

X

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

TH . EN.1 26.0 4

Data communication interception on the TSP to TC interface

X

To intercept all data sent between the TC and the TSP and use it for own

RQ.TC .90

purposes .

RQ.TSP.90

Data communication interception on the air interface (e. g. OBE CN interface)

To intercept all data sent from a speci fic OBE to the TSP over the air

interface and use it for own purposes .

© ISO 2 01 5 – All rights reserved

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

X

n. a.

X

RQ. IF.10 RQ.TSP.90 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

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

No.

Threat

TH . EN.1 27.01

Related RQ

OBE to service users allowing them to avoid paying toll. TH . EN.1 27.02

RQ.TSP.19 RQ.TSP. 21

C loning or faking of ICC and sell it to other service users

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.

X

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 No. TH . EN.1 2 8 .01

TH . EN.1 2 8 .02

Threat

Compromise the system by exploiting weaknesses in the encryption algo rithms for recovery of diversi fied keys. Disable receiving of information

DSRC

GNSS

X

X

Related RQ X

Intercept data communication and replace data, certi ficates, hashes, or other key information to disable data decryption or veri fication of

X -

signatures . TH . EN.1 2 8 .03

Disable correct encryption and/or data signing Exchange receiver certi ficate and/or encryption session key with a fake or

X

X -

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 No.

Threat

TH . EN.1 2 9.01

Steal an OBE (analysing, cloning, or reselling)

DSRC

GNSS

X

X

Related RQ

Steal one or more OBE from service user vehicles or from a TSP stock.

RQ.TSP.19 RQ.TSP. 20

88

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.27 (continued) No.

Threat

TH . EN.1 2 9.02

Steal an ICC (analysing, cloning, or reselling) Steal one or more ICC from service user vehicles or from a TSP s tock.

DSRC

GNSS

X

X

Related RQ RQ.TSP.19 RQ.TSP. 20

TH . EN.1 2 9.03

Steal roadside equipment Steal ins talled roadside equipment or equipment from a TC stock or

X

X

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 No. TH . EN.13 0.01

Threat

Bribing TSP or TC employee to get data A main attack avenue may be to get access to data by bribing an employee to act like a ‘spy’. The bribed employee may install a bypass data

DSRC

GNSS

X

X

Related RQ RQ.ISMS.2

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 interface To intercept all data sent from the communication provider to the TSP and use it for own purposes .

X

X

RQ. IF.10 RQ.TC .90 RQ.TSP.90 RQ.TSP.91

TH . EN.13 0.03

Data communication interception on the TSP to TC interface To intercept all data sent between the TC and the TSP and use it for own purposes .

TH . EN.13 0.0 4

Data communication interception on the air interface (e. g. OBE CN interface)

To intercept all data sent from a speci fic OBE to the TSP over the air interface and use it for own purposes .

X

X

RQ.TC .90 RQ.TSP.90 n. a.

X

RQ. IF.10 RQ.TSP.90 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.

© ISO 2 01 5 – All rights reserved

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

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 No.

Threat

TH .GOV.131 .01

Access targeted information at the TC’s system

DSRC

GNSS

X

X

Related RQ

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

The targeted information is obtained through direct contact with the

RQ.TSP.90

X

(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 No. TH .GOV.132 .01

Data communication interception on the communication provider to TSP interface The same attack as TH .GOV.133 .01 .

DSRC

GNSS

X

X

Related RQ

Threat

RQ. IF.10 RQ.TC .90 RQ.TSP.90 RQ.TSP.91

TH .GOV.132 .02

Data communication interception on the TSP to TC interface The same attack as TH .GOV.133 .02 .

X

X

RQ.TC .90 RQ.TSP.90

90

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.30 (continued) No.

Threat

TH .GOV.1 32 .03

Data communication interception on the air interface (e.g. OBE CN interface) The same attack as TH .GOV.1 33 .03 .

DSRC

GNSS

n. a.

X

Related RQ RQ. IF.10 RQ.TSP.90 RQ.TSP.91

TH .GOV.1 32 .0 4

Identify the vehicle/OBE at relevant locations

X

Use an appropriate installation to obtain an identi fier of the vehicle or

RQ.TSP.90

X

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 No.

Threat

TH .GOV.1 33 .01

Data communication interception on the communication provider to TSP interface

DSRC

GNSS

X

X

Related RQ 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

TH .GOV.1 33 .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

Data communication interception on the air interface (e.g. OBE CN interface)

To intercept all data sent from a speci fic OBE to the TSP over the air interface and use it for own purposes.

n. a.

X

RQ. IF.10 RQ.TSP.90 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.

© ISO 2 01 5 – All rights reserved

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

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 No.

Threat

TH .GOV.13 4.01

Access detailed charge/location data at the TC system

DSRC

GNSS

X

X

Related RQ

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

The targeted charge/location data are obtained through direct contact

RQ.TSP.90

X

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 No.

Threat

TH . FP.119.01

Large-scale disruption of GNSS signal

92

GNSS

n. a.

X

Related RQ

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.

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

DSRC

-

© ISO 2 01 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.33 (continued) No. T H . F P. 1 1 9 . 0 2

Threat

Breach of data integrity/non-repudiation Break into the system or into data communication between parts of the system and change the contents of messages and possibly the associated

DSRC

GNSS

X

X

Related RQ -

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 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

X

X

-

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

The whole or parts of the charging system may be prevented from

X

-

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 OBE will be caused to malfunction which causes inability to access the system or unjusti fied enforcement to service users.

X

X

-

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 No. T H . F P. 1 3 5 . 0 1

Threat

Bribing TSP or TC employee to get data 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

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

DSRC

GNSS

X

X

Related RQ RQ.ISMS.2

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

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

X

X

-

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. © I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

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 No.

Threat

TH . FP.1 3 6 . 01

TH . FP.1 3 6 . 02

Switching off satellite system 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). Jamming the s atel lite s ignal

DSRC

GNSS

n. a.

X

Related RQ -

n. a.

The foreign state agency might threaten to jam the satellite signal used by

X -

the E FC in ques tion on a large scale. TH . FP.1 3 6 . 03

TH . FP.1 3 6 . 0 4

Bribing TSP or TC employee to get data

X

T he s ame attack as TH . FP.1 3 5 .01 .

RQ.ISMS.2

H ire hackers

X

T he s ame attack as TH . FP.1 3 5 .02 .

X

X -

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

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 0 1 5 – All rights reserved

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

6)

DSRC interface

— Asset 213: TC and TSP central system — Asset 219: Limited autonomy — 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

8)

OBE cellular network interface

— Asset 205: Customization information

— Asset 213: TC and TSP central system — Asset 216: Service user identi fication — Asset 201: Information assets — Asset 202: Infras tructure assets — Asset 20 4: OBE C harge report

— Asset 205: Customization information — Asset 20 9: OBE

— Asset 213: TC and TSP central system — Asset 214: Road usage data

— Asset 217: Toll context data

9) OBE proxy to toll service provider interface (optional)

— Asset 201: Information assets — Asset 202: Infras tructure assets — Asset 20 4: OBE C harge report — Asset 205: Customization information — Asset 20 9: OBE

— Asset 213: TC and TSP central system — Asset 214: Road usage data

— Asset 217: Toll context data

— Asset 219: Limited autonomy

© ISO 2 01 5 – All rights reserved

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

95

ISO/TS 192 99: 2 015(E)

Table D. 36 (continued) Interface 10)

Covered in

Toll service provider to toll charger back end

connection

— Asset 201: Information assets — Asset 203: Billing Details — Asset 207: E xception list

— Asset 213: TC and TSP central system — Asset 215: Trus t Obj ects

— Asset 217: Toll context data — Asset 221: Contractual conditions — Asset 22 2: Operational rules 11)

RSE interface to toll charger back end

— Asset 207: E xception list

— Asset 213: TC and TSP central system — Asset 214: Road usage data

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

14) TSP personnel HMI and access to equipment

— Asset 213: TC and TSP central system — Asset 213: TC and TSP central system

15 )

OBE dis tribution to TSP back end

communication 16)

Delivering of equipment (e. g. OBE ) and

service provision (e.g. communication services) by suppliers and subcontractors. This is not a real

— Asset 22 6: Enforcement data

— Asset 20 9: OBE

— Asset 213: TC and TSP central system

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

parameters from the vehicle and for invoicing used to customize the OBE .

— Asset 206: Service user contract information — Asset 20 8: Customer service

— Asset 210: Service user privacy — Asset 213: TC and TSP central system — Asset 22 3: Complaints

18) Physical or contactless interface between

— Asset 22 8: ICC

19) Physical or contactless interface for the loading of

— Out of scope of this Technical Speci fication

OBE and IC card

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 Table header No. Threat

Meaning

Unique number for every threat according to the numbering scheme described in D.1 . 2 . 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.

DSRC GNSS

Related RQ

96

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

Marked with an X if this requirement is relevant for a DSRC system. Marked with an X if this requirement is relevant for an autonomous system. Reference to the requirement(s) driven by the threat.

© ISO 2 01 5 – All rights reserved

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 No.

Threat

TH . DT. 201 .01

Modify the data during transmission.

TH .OU T. 201 .01 TH . SU. 201 .01

Possible damage:

TH .OU T. 201 .02

— violation of data integrity (loss of income). Modify the data stored in any equipment or Back End including a central

TH . SU. 201 .02

clus ter equipment.

TH .TC . 201 .02 TH .TSP. 201 .02 TH .OU T. 201 .03 TH . SU. 201 .03

Possible damage:

— violation of data integrity (loss of income). Deleting a message during transmission. Possible damage:

— no availability of data (loss of income). TH .OU T. 201 .03 TH . SU. 201 .03

Prevent data communication (denial of service attack) . Possible damage:

TH . DT. 201 .05

— no availability of data (loss of income). Loss of data caused by accident, environmental incident, or equipment

TH . I T. 201 .05

failure.

DSRC

GNSS

X

X

Related RQ RQ. IF.11

X

X

RQ. DS .01 RQ. DS .02 RQ. DS .05 X

X

RQ. XX.01

X

X

RQ. XX.01

X

X

RQ. XX.01

Possible damage: TH .OU T. 2 01 .06 TH . SU. 201 .06

TH .OU T. 201 .07 TH . SU. 201 .07

TH .OU T. 201 .0 8 TH .TC . 201 .0 8 TH .TSP. 201 .0 8

— no availability of data (loss of income). Modify the identi fication of the data originator Possible damage:

— violation of authenticity (loss of income). The originator of the data is a not an authorized person or entity. Possible damage:

— violation of authenticity (loss of income). Replaying of a data communication message. Possible damage:

— violation of authenticity (loss of income).

TH .OU T. 201 .09

Eavesdropping of data communication.

TH .OU T. 201 .10

— breach of con fidentiality (disclosure of information to unauthorized individuals or systems, violation of service user privacy). Read access to data stored in any equipment or back end.

Possible damage:

TH . SU. 201 .10 TH .TC . 201 .10 TH .TSP. 201 .10

Possible damage:

— breach of con fidentiality (disclosure of information to unauthorized individuals or systems, violation of service user privacy).

© ISO 2 01 5 – All rights reserved

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

X

X

RQ. DS .07 RQ. IF.1 2 X

X

RQ. DS .07 RQ. IF. 20 X

X

RQ. IF. 3 0

X

X

RQ. IF.10

X

X

RQ. DS .01

RQ.IM.01 RQ.IM.02

97

ISO/TS 192 99: 2 015(E)

Table D.38 (continued) No.

Threat

TH .OUT. 201 .11

Intercept a communication with fake recipient identi fication.

DSRC

GNSS

X

X

Related RQ RQ. IF. 20

Data are sent to an unauthorized recipient. Possible damage:

TH . SU. 201 .1 2 TH .TC . 2 01 .1 2 TH .TSP. 201 .1 2 TH . SU. 201 .13 TH .TC . 2 01 .13 TH .TSP. 201 .13

— 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). Deny being the originator of an information or message.

X

RQ. IF.1 3

Possible damage: — loss of non-repudiation (loss of income) .

Deny having received an information or message.

X

X

RQ. IF.14

Possible damage: — loss of non-repudiation (loss of income) .

TH.IM.201.14

Missing global security rules

TH .TC . 2 01 .14

The TCs and TSPs do not have a globally valid set of security rules (possibly de fined by an interoperability management). This leads to unaligned security implementations with different levels of security at the various TCs and TSPs and possible security holes.

TH .TSP. 201 .14

X

X

X

RQ.IM.01 RQ.IM.02

Possible damage:

— undermine trust in the toll charging environment; — no or incorrect tolling; — loss of income; — breach of con fidentiality (disclosure of information to unauthorized individuals or systems, violation of service user privacy) — violation of data integrity (loss of income); — violation of authenticity (loss of income); — no availability of data (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 No.

Threat

TH . DT. 2 02 .01

Environmental incident.

TH . I T. 2 02 .01

Possible damage:

— damage of the equipment; — data processing failure; — loss of data (no availability of data, loss of income). TH .OUT. 202 .02 TH . SU. 202 .02

Vandalism. Possible damage:

— damage of the equipment; — data processing failure; — loss of data (no availability of data, loss of income).

98

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

DSRC

GNSS

X

X

Related RQ RQ.TC . 20 RQ.TC . 2 3

X

X

RQ.TC . 20 RQ.TC . 2 3 RQ.TSP.0 9

© ISO 2 01 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.39 (continued) No.

Threat

TH .OU T. 2 02 . 03 TH . S U. 2 02 . 03

Traffic accidents (only OBE and RSE). In GNSS only relevant for CCC and LAC. Pos s ible damage:

TH .OU T. 2 02 . 0 4 TH . S U. 2 02 . 0 4

TH .OU T. 2 02 . 0 5 TH . S U. 2 02 . 0 5

DSRC

GNSS

X

X

Related RQ RQ.TC . 2 0 RQ.TC . 2 3

— damage of the equipment; — data processing failure; — loss of data (no availability of data, loss of income).

RQ.TS P. 0 9

T heft of equ ipment.

X

Pos s ible damage:

— loss of equipment; — loss of data (no availability of data, loss of income) and possibly; —breach of con fidentiality (disclosure of information to unauthorized individuals or systems, violation of service user privacy). Software modi fication. Pos s ible damage:

— violation of data integrity (loss of income); — loss of data (no availability of data, loss of income) and possibly; — breach of con fidentiality (disclosure of information to unauthorized individuals or systems, violation of service user privacy). TH . OU T. 2 02 . 0 6

D en ial of ser vice attack again s t data communication i nterfaces or

TH . S U. 2 02 . 0 6

i nternal software pro ces ses or s er vices .

X

RQ.TC . 2 1 RQ.TS P. 2 0

X

X

RQ.TC . 2 4 RQ.TSP. 0 5 RQ.TS P.40

X

X

RQ. X X. 01

Pos s ible damage:

— loss of data (no availability of data, loss of income). 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 No. TH . D T. 2 03 . 01

Threat 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 b ack end.

DSRC

GNSS

X

X

Related RQ 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

—

wrong data cou ld le ad to wrong i nvoices and TC clai ms .

making a proper claim from the TC to the TSP;

TH . I T. 2 03 . 02 TH .OU T. 2 03 . 02 TH .TS P. 2 03 . 02

Billing details could be transmitted to an unauthorized party. Pos s ible damage:

— undermine trust in the toll charging environment; — violation of service users privacy; —

TH . I T. 2 03 . 03 TH .OU T. 2 03 . 03

Pos s ible damage:

— undermine trust in the toll charging environment;

RQ. I F. 2 0

X

X

RQ. I F. 2 0

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

© I SO 2 0 1 5 – All rights reserved

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

X

los s of B i l li ng detai l s for fur ther pro ces s i ng and bi l li ng.

Billing details could be sent from an unauthorized party. —

X

99

ISO/TS 192 99: 2 015(E)

Table D.40 (continued) No.

Threat

TH . I T. 2 03 . 0 4

The content of Billing details could be revealed to an unauthorized party.

TH . OU T. 2 03 . 0 4 TH .TC . 2 03 . 0 4 TH .TS P. 2 03 . 0 4

TH . D T. 2 03 . 0 5 TH . I T. 2 03 . 0 5 TH . OU T. 2 03 . 0 5 TH .TS P. 2 03 . 0 5

Pos s ible damage:

DSRC

GNSS

X

X

Related RQ RQ.ISMS.2

— undermine trust in the toll charging environment; — violation of service users privacy. The transmission of billing details could be disturbed and delayed.

X

Pos s ible damage:

RQ.ISMS.2

— undermine trust in the toll charging environment; — denial of service; — negatively affect billing processes; —

RQ.TC .9 0

X

RQ.TC .95

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

TH .TS P. 2 03 . 0 6

i s repudiated .

X

X

RQ. I F.1 3

Pos s ible damage:

— no end-to-end security and therefore no acceptance of the billing

RQ. I F.14

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

No. TH . D T. 2 0 4. 01

DSRC

GNSS

n . a.

X

Related RQ

Threat A charge rep or t cou ld b e change d duri ng tran s mi s s ion b e tween front 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; — TH . I T. 2 0 4. 02 TH . OU T. 2 0 4. 02 TH . S U. 2 0 4. 02

A charge report could be transmitted to an unauthorized party.

TH . OU T. 2 0 4. 03

n . a.

— undermine trust in the toll charging environment; — 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.

A charge report could be sent from an unauthorized party.

n . a.

— undermine trust in the toll charging environment; TH . I T. 2 0 4. 0 4 TH . OU T. 2 0 4. 0 4 TH . S U. 2 0 4. 0 4

TH . D T. 2 0 4. 0 5 TH . I T. 2 0 4. 0 5 TH . OU T. 2 0 4. 0 5 TH . S U. 2 0 4. 0 5

100

chargi ng the ser vice us er for non- exi s ting us age of the tol l domai n .

T he content of a charge rep or t cou ld b e revealed to an unauthori ze d

party during transmission.

n . a.

X

RQ. I F.10

Pos s ible damage:

— undermine trust in the toll charging environment; — violation of service users privacy The transmission of charge reports could be disturbed and delayed. Pos s ible damage:

— undermine trust in the toll charging environment; — denial of service; — negatively affect billing processes; —

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

X

RQ. I F. 2 0

Pos s ible damage:

—

X

RQ. I F. 2 0

Pos s ible damage:

— TH . I T. 2 0 4. 03

wrong data cou ld lead to wrong i nvoices and TC clai ms .

n . a.

X

RQ.TSP. 01

violate ser vice levels agre ed with the TC .

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.41 (continued) No.

Threat

TH .OU T. 2 0 4.06

The authenticity of sent charge reports cannot be proven and/or its

TH . SU. 20 4.06

origin is repudiated. Possible damage:

— no end-to-end security and therefore no acceptance of the charge

DSRC

GNSS

n. a.

X

Related RQ RQ. IF.13 RQ. IF.14

report for further processing and billing.

D.3 .8

Asset 2 05: Customization information Table D.42 — Threats to customization information

No.

Threat

TH . DT. 205 .01

C hanging all or parts of the customization information (e. g. service

TH . SU. 205 .01

user contract, tariff classes, etc.) during transmission to the OBE . Possible damage:

— wrong or no service user is invoiced for the road usage;

DSRC

GNSS

X

X

Related RQ RQ. IF.10 RQ. IF.11 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

TH . SU. 205 .02

in the OBE . Possible damage:

TH . DT. 205 .03

— violation of data integrity (loss of income). Changing all or parts of the customization information sent by the OBE.

TH . I T. 205 .03

Prevent OBE from updating cus tomization information.

RQ. DS .05 X

X

X

X

RQ. XX.01

TH . SU. 205 .0 4 TH .TC . 205 .05

RQ. DS .01 RQ. DS .02

RQ. IF.11

TH . I T. 205 .0 4 TH .TSP. 205 .05

X

RQ. IF.10

TH . SU. 205 .03 TH . DT. 205 .0 4

X

Change of fee relevant cus tomization information over the air.

X

X

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

© ISO 2 01 5 – All rights reserved

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

101

ISO/TS 192 99: 2 015(E)

Table D.43 — Threats to service user contract information No. TH . DT. 2 06.02

Change of contract information during transmission (contract agent

TH . I T. 2 06.02

to the TSP) or storage in TSP back end.

TH .OUT. 206.02 TH . SU. 206 .02

TH . DT. 2 06.03 TH .OUT. 206.03

Possible damage:

Possible damage:

— TSP loses income and may be no longer able to operate its

GNSS

X

X

RQ. DS .01

— wrong or no service user is invoiced for the road usage; — 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. Loss of contract information during s torage in TSP back end.

DSRC

Related RQ

Threat

RQ. DS .02 RQ. DS .05 RQ. DS .07 RQ. IF.10 RQ. IF.11 X

X

RQ. DS .03 RQ. DS .05

service

TH . DT. 2 06.0 4 TH . I T. 2 06.0 4 TH .TSP. 206.0 4

Contract details are revealed to unauthorized third parties. Possible damage:

— infringement of service user privacy; — service user loses money by non-genuine and unauthorized

debiting based on his contractual account information.

X

X

RQ. DS .01 RQ. DS .02 RQ. DS .06 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 —

102

economical loss for the operators.

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.44 — Threats to exception list No.

Threat

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 .

DSRC

GNSS

X

X

Related RQ

T H . I T. 2 0 7. 0 1 P o s s i b l e d a m a ge : T H .T S P. 2 0 7. 0 1 T H .T C . 2 0 7. 0 1

— requested locking does not take effect; — wrong OBE gets locked; —

T H . D T. 2 0 7. 0 2

co ntrac tu a l co n s e que nce s .

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 .

RQ. D S . 0 7 RQ. I F. 1 1 RQ. I F. 14 RQ.T C .9 9

X

X

T H . I T. 2 0 7. 0 2 P o s s i b l e d a m a ge : T H . O U T. 2 0 7. 0 2 T H .T C . 2 0 7. 0 2

—

T H . O U T. 2 0 7. 0 3

RQ. I F. 1 1

— requested locking does not take effect; — wrong OBE gets locked;

RQ. I F. 14

co ntrac tu a l co n s e que nce s .

Transmission of exception list to unauthorized party.

X

X

T H .T S P. 2 0 7. 0 3 P o s s i b l e d a m a ge :

RQ. D S . 0 8

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 P o s s i b l e d a m a ge :

RQ. I F. 2 0

T H .T C . 2 0 7. 0 4 —

T H . D T. 2 0 7. 0 5

w r o n g O B E ge t s l o c ke d .

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 : T H .T S P. 2 0 7. 0 5 T H .T C . 2 0 7. 0 5

— delay in requested locking; —

co ntrac tu a l co n s e que nce s .

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

RQ.T C .9 9 RQ.T S P. 1 8 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 No.

Threat

TH . OU T. 2 0 8 . 01

The service user can be impersonated by a fraudulent person getting acces s to the ser vice us ers p ersonal data.

DSRC

GNSS

X

X

Related RQ 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 i nformation or complai nts .

X

X

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 No. TH . I T. 2 0 9. 01 TH . OU T. 2 0 9. 01 TH . S U. 2 0 9. 01

Threat

Manipulation of stored data. Due to manipulation, the correct functionality of the OBE is no longer

DSRC

GNSS

X

X

Related RQ RQ. D S . 01 RQ. D S . 02

guarantee d.

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

—

undermi ne tru s t i n the tol l chargi ng envi ron ment.

pay less toll; — instability of the OBE due to bogus data; TH .TS P. 2 0 9. 02

Violation of data privacy requirements.

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; —

104

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

X

undermi ne tru s t i n the tol l chargi ng envi ron ment.

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.46 (continued) No.

Threat

TH . DT. 209.03

Eavesdropping of OBE communication connection (CN or DSRC ) .

TH . I T. 20 9.03 TH .OU T. 20 9.03 TH . SU. 20 9.03

Possible damage:

— reveal con fidential data to unauthorized parties; — gain knowledge of internal data transmission;

DSRC

GNSS

X

X

Related RQ RQ. IF.10 RQ. IF.11

— undermine trus t in the toll charging environment. TH . DT. 209.0 4 TH .OU T. 20 9.0 4 TH . SU. 20 9.0 4

Prevention of communication. An attacker tries to prevent the working of communication channels

(CN, DSRC), e.g. by covering the antennas. Possible damage:

TH .OU T. 20 9.05 TH . SU. 20 9.05 TH .TC . 209.05

— prevention of correct toll event detection; — less stability of the OBE operations. Change of con figuration data. An attacker tries to manipulate any con figuration data on the OBE (e.g. communication end points, retry limits, etc.).

X

X

RQ.TC .01 RQ.TC .02 RQ.TSP.01 RQ.TSP.0 9 RQ.TSP. 51 X

X

RQ.TSP.40

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;

— undermine trus t in the toll charging environment.

TH .OU T. 2 09.06 TH . SU. 20 9.06 TH .TC . 209.06

Inspection of con figuration data. An attacker can gain an advantage from inspecting con figuration data on

X

X

RQ.TSP.41

the OBE .

Possible damage:

— undermine trust in the toll charging environment; — prepare efficient attacks on the system using this speci fic knowledge. TH .OU T. 20 9.07 TH . SU. 20 9.07

An attacker tries to change the compliance check attributes inside the

OBE to a proper value for an enforcement authority.

n. a.

X

RQ.TSP.40

Possible damage:

— undermine trust in the toll charging environment;

— creation of incorrect charging and enforcement records in order to

pay less toll. TH .OU T. 20 9.0 8 TH . SU. 20 9.08

Internal knowledge on the OBE design.

X

An attacker tries, using technical and organizational measures (such as

RQ.ISMS.2

social engineering), to get internal or con fidential knowledge about the

X

OBE .

Possible damage:

— instability of the OBE; — prevention of correct toll event detection;

— creation of incorrect charging and enforcement records in order

to pay less toll;

— undermine trus t in the toll charging environment.

TH .OU T. 20 9.09 TH . SU. 20 9.0 9

An attacker tries to manipulate or exchange hardware components to

pay lower toll.

X

X

RQ. XX.02

Possible damage: — prevention of correct toll event detection.

© ISO 2 01 5 – All rights reserved

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

105

ISO/TS 192 99: 2 015(E)

Table D.46 (continued) No. T H . D T. 2 0 9 . 1 1 T H . I T. 2 0 9 . 1 1 T H .T S P. 2 0 9 . 1 1

Mass failure of OBE after update over the air. Mass failure of a signi ficant number of OBE after an update over the air. This could be caused by — 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.

DSRC

GNSS

X

X

Related RQ

Threat

RQ.T S P. 70 RQ.T S P. 71

P o s s i b l e d a m a ge :

T H . D T. 2 0 9 . 1 2

— undermine trust in the toll charging environment; — no or incorrect tolling; — loss of income; — additional cost to the TC by providing local OBE. 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 T H .T S P. 2 0 9 . 1 2

type. This could affect a pure DSRC OBE or the DSRC part of a GNSS OBE

RQ.T S P. 8 0

wh i l e c o m mu n i c ati n g w i th the R S E .

This could be caused by — 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. P o s s i b l e d a m a ge :

— — — —

106

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

undermine trust in the toll charging environment; no or incorrect tolling; loss of income; additional cost to the TC by providing local OBE.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

X

X

Related RQ

No.

Threat

TH .TSP. 2 10 . 01

C ollec tion of p ersonal data.

TH .TC . 2 10 . 01

This could be caused by — not necessary for toll collection, —

use of data for other purp os e,

—

provides data to third p arties .

— other data than consented to by the service user (data subject), or

RQ.TC . 5 0 RQ.TC . 51 RQ.TSP. 59

Pos s ible damage:

— violation of privacy; —

undermine trus t in the toll charging environment.

TH .TSP. 2 10 . 02

C ollec ted p ers onal data not handled according to data protec tion laws

TH .TC . 2 10 . 02

and regulations .

This could be caused by —

change, lo s s , or to o long s torage of data,

—

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.

X

X

RQ.TC . 5 0 RQ.TC . 51 RQ.TSP. 59

Pos s ible damage:

— violation of privacy; — TH .TC . 2 10 . 03

undermine trus t in the toll charging environment.

An organization identi fies the service user in cases where there is no violation of the EFC system. Pos s ible damage:

— violation of privacy.

X

X

RQ.TSP. 59 RQ.TC . 5 0 RQ.TC . 51 RQ.TSP. 59

TH .TSP. 2 10 . 0 4 TH .TC . 2 10 . 0 4

A ser vice us er is s ubj ec t to enforcement due to lack of crucial data

availability or improper data processing (e.g. no updated exception list in a charging p oint) .

X

X

RQ.TC . 51 RQ.TSP. 59

Pos s ible damage: —

undermine trus t in the toll charging environment.

D.3 .14 Asset 2 11: RSE Table D.48 — Threats to RSE No. TH .OU T. 2 11 .01

Threat Vandalis m on the RSE , e. g. sho oting with guns on antennas , us ing explo s ives on RSE cabinets or cutting cables .

DSRC

GNSS

X

X

Related RQ RQ.TC . 2 0

Pos s ible damage:

— no or incorrect tolling; — instability of the RSE; — TH . S U. 2 11 . 02

prevention of correc t tol l event detec tion.

Traffic accidents damaging charging points. Pos s ible damage: —

X

RQ.TC . 2 0

los s of income.

© ISO 2 0 1 5 – All rights reserved

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

X

107

ISO/TS 192 99: 2 015(E)

Table D.48 (continued) No.

Threat

TH .OUT. 211 .03

Theft of RSE .

GNSS

X

X

Related RQ RQ.TC . 21

Possible damage:

— no tolling; —disclosure of sensitive information like security keys. TH .OUT. 211 .0 4

DSRC

Faking an RSE .

X

X

RQ.TC . 2 2

Possible damage: — 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

An attacker tries to prevent the working of communication channels,

e.g. by covering the antennas or by jamming the DSRC link.

X

RQ.TC . 2 3

Possible damage: — no or incorrect tolling. TH .OUT. 211 .06

Modi fication or alteration of RSE software.

X

X

RQ.TC . 24

Possible damage: — incorrect tolling. TH .OUT. 211 .07

Internal knowledge on the RSE design.

X

An attacker tries, using technical and organizational measures (such as

RQ.ISMS.2

social engineering) to get internal or con fidential knowledge about RSE.

X

Possible damage: — undermine trust in the toll charging environment. TH . DT. 211 .0 8 TH . I T. 211 .0 8 TH .OUT. 211 .0 8

X

Enforcement interface at RSE unavailable. An OBE is not able to communicate with the enforcement equipment of

X

RQ.TC .96

the TC .

This could be caused by — broken antenna, — misdirected antenna,

— no power supply to RSE, or — I T failure in RSE station. Possible damage:

— undermine trust in the toll charging environment;

— 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

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.49 — Threats to EFC stakeholder image and reputation No.

Threat

TH .TSP. 21 2 .01 TH .TC . 21 2 .01

An organization does not provide the required measures for ensuring

con fidentiality, integrity and accessibility of personal data. Possible damage:

— loss of service users trust (violation of privacy); — loss of credibility and reputation of the organization;

DSRC

GNSS

X

X

Related RQ RQ.TC . 5 0 RQ.TC . 51 RQ.TSP. 59

— undermine trus t in the toll charging environment.

TH .TSP. 21 2 .02 TH .TC . 21 2 .02

An organization provides a third party with the collected personal data

or results of the management of the data collected in those cases where personal data are part of such management.

X

X

RQ.TC . 20

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 No. TH .OU T. 21 3 .01 TH . SU. 213 .01

Threat

Knowledge about the internal toll charging process of the central system of the TSP or TC is used to reduce the toll to be paid by a service user. Possible damage:

— attacker could gain an advantage in optimizing its other attacks;

DSRC

GNSS

X

X

Related RQ RQ.ISMS.2 RQ.TC . 5 0

— disclosure of business knowledge. TH .TSP. 213 .02 TH .TC . 213 .02

Data misuse. Service user and road usage data are not being handled according to

privacy regulations. Possible damage:

TH .OU T. 21 3 .03 TH . SU. 213 .03

— reduce trust in the system; — violation of laws, contracts, and service user privacy. Unauthorized physical access to central system data centre or communication components.

X

X

RQ.TC . 5 0 RQ.TC . 51 RQ.TSP. 59

X

X

RQ.ISMS.2

Possible damage:

TH .OU T. 21 3 .0 4 TH . SU. 213 .0 4

— physical damage; — theft of components; — data manipulation, misuse, or deletion; — violation of service user privacy. Unauthorized logical access to central system or communication interfaces.

X

X

RQ.ISMS.2

Possible damage:

— software manipulation or installation; — data manipulation, misuse, or deletion; — violation of service user privacy.

© ISO 2 01 5 – All rights reserved

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

109

ISO/TS 192 99: 2 015(E)

Table D.50 (continued) No.

Threat

TH . I T. 21 3 .05

Mass rejection of toll declarations or billing details.

DSRC

GNSS

X

X

Related RQ

The toll declarations or billing details transferred between a TC and TSP

get massively rejected.

RQ. IF. 31 RQ. IF. 32

This could be caused by — 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:

— undermine trust in the toll charging environment; — no or incorrect tolling; — loss of income; — additional cost to TC and TSP for error handling procedures . TH . I T. 21 3 .06

Customer service system unavailable.

X

The access to the customer service system is unavailable for service users and/or TSP employees.

X

RQ.ISMS.2

This could be caused by — network unavailable, — S W error, or — server unavailable. Possible damage:

TH . DT. 21 3 .07

— undermine trust in the toll charging environment; — additional cost to the TSP for handling service users manually. TC central system or central cluster equipment is not able to send/receive

TH . I T. 21 3 .07

data to/from the TSPs .

Independent of sending either directly to the TSP or via a central TC

X

X

RQ.TC .95

cluster equipment.

This could be caused by — IT failure in the TCs central system, or — failure in the TCs data transmission equipment. Possible damage:

— undermine trust in the toll charging environment; — 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

Speci fic OBE are not serviced at the POS network due to a problem with

RQ.TSP.96

n. a.

this kind of OBE .

This could be caused by — wrong implementation of the personalization interface in the OBE ,

— wrong keyset in the POS, or — S W error in the POS . Possible damage:

— — — —

110

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

undermine trust in the toll charging environment; no or incorrect tolling; loss of income; additional cost to the TC by providing local OBE.

© ISO 2 01 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.50 (continued) No. TH . DT. 213 .09 TH . I T. 213 .09

Threat

PoS service globally unavailable. No OBE get serviced at the POS network due to a global unavailability of

DSRC

GNSS

X

n. a.

Related RQ RQ.ISMS.2

the POS network.

This could be caused by

— wrong implementation of the personalization interface in OBE ,

— wrong keyset in the POS, — S W error in the POS , or — network unavailable. Possible damage:

— undermine trust in the toll charging environment; — no or incorrect tolling; — loss of income.

TH . DT. 213 .11 TH . I T. 213 .11 TH .TC . 213 .11

Mass failure of RSE after update of SW. Mass failure of a signi ficant number of OBE after an update of an RSE. This could be caused by — insufficient tests by the TC,

X

X

RQ.TC .70 RQ.TC .71

— malfunction due to I T problems, or

— change of S W during transmission to RSE . Possible damage:

— — — —

undermine trust in the toll charging environment; no or incorrect tolling; 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 No. TH . DT. 214.01 TH . I T. 214.01 TH .OU T. 214.01 TH . SU. 214.01

Threat

Alteration of data stored in the tolling station in a DSRC based system or

during transmission to the back end. Possible damage:

— loss of income;

DSRC

GNSS

X

n. a.

Related RQ RQ. DS .01 RQ. DS .02 RQ. DS .05

— wrong service user enforcement.

TH . DT. 214.02 TH . I T. 214.02 TH .OU T. 214.02 TH . SU. 214.02 TH . DT. 214.03 TH . I T. 214.03 TH .TSP. 214.03 TH . SU. 214.03

Alteration of charge reports in an autonomous system.

n. a.

X

Possible damage:

RQ. DS .01

— loss of income.

RQ. DS .02 RQ. IF.11

Incorrect position indication in an autonomous system caused by

alteration of basic data (e. g. map data) . Possible damage:

— loss of income or overcharging;

n. a.

X

RQ. DS .01 RQ. DS .02 RQ. IF.11

— wrong service user enforcement.

© ISO 2 01 5 – All rights reserved

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

111

ISO/TS 192 99: 2 015(E)

Table D.51 (continued) No. T H . D T. 2 14 . 0 4

DSRC

GNSS

n. a.

X

Related RQ

Threat

Data transfer corruption in an autonomous system.

T H . O U T. 2 14 . 0 4 RQ. I F. 1 1

P o s s i b l e d a m a ge :

— loss of income or overcharging; —

T H . D T. 2 14 . 0 5

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.

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 RQ. I F. 1 1

P o s s i b l e d a m a ge : 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

X

X

Related RQ

No.

Threat

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.

T H . O U T. 2 1 5 . 0 1 RQ. I F. 1 1

P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — unscheduled change of cryptographic keys and its connected operational cost; —

T H . I T. 2 1 5 . 0 2

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. A Trust object could be transmitted to an unauthorized party

X

X

T H . O U T. 2 1 5 . 0 2 RQ. I F. 2 0

P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — unscheduled change of cryptographic keys and its connected operational cost; —

T H . I T. 2 1 5 . 0 3

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. A trust object could be sent from an unauthorized party

X

X

T H . O U T. 2 1 5 . 0 3 RQ. I F. 2 0

P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — unscheduled change of cryptographic keys and its connected operational cost; —

T H . I T. 2 1 5 . 0 4 T H . O U T. 2 1 5 . 0 4

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. The content of a trust object could be revealed to an unauthorized party

X

X

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 RQ. D S . 0 2

P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — unscheduled change of cryptographic keys and its connected operational cost; —

T H . D T. 2 1 5 . 0 5

RQ. D S . 0 6 RQ. I F. 1 0 RQ. I F. 1 1

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. 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 : T H . O U T. 2 1 5 . 0 5

— undermine trust in the toll charging environment; —

112

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

RQ. X X . 0 1

den i a l o f s er vice .

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table D.52 (continued) No.

DSRC

GNSS

X

X

Related RQ

Threat

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

T H .T S P. 2 1 5 . 0 6

e n v i r o n m e n t.

RQ.ISMS.2

T H .T C . 2 1 5 . 0 6 P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — unscheduled change of cryptographic keys and its connected operational cost; —

T H . I T. 2 1 5 . 0 7 T H .T S P. 2 1 5 . 0 7 T H .T C . 2 1 5 . 0 7

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

which cannot be used for payment claims. Wrong update of key set for OBE communication. Wrong handling of key information. This could be caused by — wrong generation of key information by TSP, — wrong manual entry of key information by TC, or — wrong processing of key information.

X

n. a.

RQ.T C . 1 0 RQ.T C . 2 5 RQ.T S P. 8 1

P o s s i b l e d a m a ge :

— — — —

no or incorrect tolling; loss of income; no end-to-end security; additional cost to the TC by providing local OBE.

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

No. T H . D T. 2 1 6 . 0 1 T H . I T. 2 1 6 . 0 1

Threat

A user identi fication could be changed during transmission between OBE

DSRC

GNSS

X

X

Related RQ

a nd RS E . RQ. I F. 1 1

T H . O U T. 2 1 6 . 0 1 P o s s i b l e d a m a ge :

— no or incorrect tolling; —

T H . I T. 2 1 6 . 0 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.

A user identi fication could be transmitted to an unauthorized party.

X

X

T H . O U T. 2 1 6 . 0 2 P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — violation of privacy; — prepare efficient attacks on the system using this speci fic knowledge; —

T H . O U T. 2 1 6 . 0 3

RQ. I F. 2 0

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. A user identi fication could be sent from an unauthorized party, e.g. an attacker faking OBE and sending false user identi fications to an RSE.

X

X

RQ. I F. 1 2

P o s s i b l e d a m a ge : —

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.

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

113

ISO/TS 192 99: 2 015(E)

Table D.53 (continued) Threat

TH . I T. 216 .0 4

The content of a user identi fication could be revealed to an unauthorized party (eavesdropping).

TH .OUT. 216.0 4

DSRC

GNSS

X

X

Related RQ

No.

RQ. IF.10

Possible damage:

— undermine trust in the toll charging environment; — violation of privacy; — prepare efficient attacks on the system using this speci fic knowledge. TH . DT. 216 .05 TH . I T. 216 .05 TH .OUT. 216.05

The transmission of user identi fication could be disturbed, e.g. jamming of DSRC link, or delayed.

X

X

RQ. XX.01

Possible damage:

— undermine trust in the toll charging environment; — no or incorrect tolling; — incorrect enforcement. TH .TSP. 216 .06 TH .TC . 216 .06

Change of user identi fication over the air.

X

X

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 No.

Threat

TH . DT. 217.01

Toll context data could be changed during transmission. Possible damage:

— toll context data no longer usable for toll event detection;

DSRC

GNSS

X

X

Related RQ RQ. IF.11

— wrong data could lead to wrong invoices and TC claims . TH . I T. 217.02 TH .OUT. 217.02 TH .TSP. 217.02

Toll context data could be transmitted to an unauthorized party.

X

X

Possible damage:

RQ. DS .0 8

— loss of toll context data for further processing and billing.

RQ.TC .97

— undermine trust in the toll charging environment;

RQ. IF. 20 RQ.TSP.17

TH . I T. 217.03 TH .OUT. 217.03

Toll context data could be sent from an unauthorized party.

X

X

Possible damage:

RQ. DS .07

— charging the user for non-existing usage of the toll domain.

RQ.TC .91

— undermine trust in the toll charging environment;

RQ. IF. 20 RQ.TSP.13

114

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.54 (continued) No.

Threat

TH . DT. 217.0 4

The transmission of toll context data could be disturbed and delayed.

TH . I T. 217.0 4 TH .OU T. 217.0 4 TH .TSP. 217.0 4

Possible damage:

— undermine trust in the toll charging environment; — denial of service; — negatively affect billing processes;

DSRC

GNSS

X

X

Related RQ RQ. IF.02

— violate service levels agreed with the TC .

TH .OU T. 217.05 TH .TSP. 217.05

The authenticity of sent toll context data cannot be proven and/or its

origin is repudiated.

X

X

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. The TC provides wrong or incomplete data (e. g. VAT ID, address data,

contact information, toll domain layout, pricing information, etc.) to the TSP.

X

X

RQ. DS .07 RQ. DS .07 RQ.TC .98

Possible damage:

— undermine trust in the toll charging environment; — 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 No. TH . DT. 218 .02 TH . I T. 218 .02 TH .OU T. 218 .02

TH . I T. 218 .03 TH .OUT. 218 .03 TH .TSP. 218 .03 TH .TC . 218 .03

TH .OUT. 218 .05 TH .TSP. 218 .05 TH . SU. 218 .05

Threat

Payment means validation process could be intercepted by an unauthorized party. Possible damage:

— loss of income; — wrong service user pays. The content of payment means stored/during transmission could be revealed to an unauthorized party. Possible damage:

— undermine trust in the toll charging environment; — wrong service user pays. Payment means stored/during transmission could be forged by an unauthorized party. Possible damage:

— undermine trust in the toll charging environment; — loss of income; — wrong service user pays.

DSRC

GNSS

X

X

Related RQ RQ. IF.11 RQ. IF.1 2 RQ. IF.1 3 RQ. IF.14 X

X

RQ. DS .01 RQ. DS .02 RQ. DS .06 RQ. IF.10 X

X

RQ. DS .01 RQ. DS .02 RQ. DS .05 RQ. IF.10 RQ. IF.11 RQ. IF.1 2 RQ. IF.13 RQ. IF.14

© ISO 2 01 5 – All rights reserved

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

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 Threat

TH . DT. 219.01

Wrong amount written to OBE during customization.

TH . I T. 219.01 TH .OUT. 219.01 TH .TSP. 219.01 TH .OUT. 219.02

Unauthorized change of amount s tored in OBE .

TH .TC . 219.02

GNSS

n. a.

X

RQ.TSP.92

Possible damage:

— amount used autonomously too high;

TH . SU. 219.02

DSRC

Related RQ

No.

— malfunction of OBE .

X

X

RQ. DS .05

Possible damage:

— 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 No. TH . DT. 2 20.01 TH .OUT. 2 20.01

DSRC

GNSS

X

X

Related RQ

Threat An EFC schema could be changed during transmission between

interoperability management and TSP.

RQ. IF.11

Possible damage:

— misalignment between TSP and TC;

— undermine trust in the toll charging environment. TH .OUT. 2 20.02

An EFC schema could be sent from an unauthorized party to either TSP

or TC , or both.

X

X

RQ. IF. 20

Possible damage:

— undermine trust in the toll charging environment;

— wrong data could lead to wrong invoices and TC claims .

TH . DT. 2 20.03 TH . I T. 2 20.03 TH .OUT. 2 20.03

TH .OUT. 2 20.0 4

The transmission of EFC schema could be disturbed, so causing a delay

in acceptance between TSP and TC .

X

X

RQ. IF.02

Possible damage:

— undermine trust in the toll charging environment; — deny correct billing processing. The authenticity of the sent EFC schema cannot be proven and/or the

origin is repudiated.

X

X

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

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.58 — Threats to contractual conditions No.

Threat

TH . DT. 221 .01

The contractual conditions could be changed during transmission to a

TH . I T. 221 .01

TSP.

TH .OU T. 2 21 .01

DSRC

GNSS

X

X

Related RQ RQ. IF.11

Possible damage:

— TSP might base its business on wrong contractual conditions; — undermine trus t in the toll charging environment. TH . DT. 221 .02

The contractual conditions could be changed during transmission to a

TH . I T. 221 .02

(potential) service user.

TH .OU T. 2 21 .02

X

X

RQ. IF.11

Possible damage:

— SU might base its business on wrong contractual conditions; — undermine trus t in the toll charging environment. TH .OU T. 2 21 .03

The contractual conditions could be sent from an unauthorized party. Possible damage:

— TSP or SU might base their business on wrong contractual conditions;

X

X

RQ. IF. 20

— undermine trus t in the toll charging environment. TH . DT. 221 .0 4

The (published) contractual conditions are not available for a TSP or a

TH . I T. 221 .0 4

service user upon demand (denial of service) .

TH .OU T. 2 21 .0 4 TH .TC . 221 .0 4

X

X

RQ. XX.01

Possible damage:

— loss of business because SU might choose another TSP; — undermine trus t in the toll charging environment.

TH . DT. 221 .05 TH . I T. 221 .05 TH .OU T. 2 21 .05

The transmission of the contractual conditions could be disturbed or

delayed (denial of service).

X

X

RQ. XX.01

Possible damage:

— loss of business because SU might choose another TSP; — undermine trus t in the toll charging environment. TH .TSP. 221 .06 TH .TC . 221 .06

The TSP or service user could not determine a liable originator of the

contractual conditions beyond doubt.

X

X

RQ. IF.13

Possible damage:

— TSP or SU cannot hold someone responsible for any damage caused by receiving wrong contractual conditions; — undermine trus t in the toll charging environment. TH .TSP. 221 .07 TH .TC . 221 .07

The TSP or service user could not determine validity period for the contractual conditions beyond doubt.

X

X

RQ. IF.11

Possible damage:

— TSP or SU cannot hold the originator responsible for any damage caused by using invalid contractual conditions; — undermine trus t in the toll charging environment.

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).

© ISO 2 01 5 – All rights reserved

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

117

ISO/TS 192 99: 2 015(E)

Table D.59 — Threats to operational rules Threat

TH . DT. 222 .01

The operational rules could be changed during transmission to a TC .

TH . I T. 222 .01 TH .OUT. 22 2 .01

DSRC

GNSS

X

X

Related RQ

No.

RQ. IF.11

Possible damage:

— TC might base its business on wrong operational rules; — undermine trust in the toll charging environment.

TH . DT. 222 .02 TH . I T. 222 .02 TH .OUT. 22 2 .02

The operational rules could be changed during transmission to a TSP.

X

X

RQ. IF.11

Possible damage:

— TSP might base its business on wrong operational rules; — undermine trust in the toll charging environment.

TH .OUT. 22 2 .03

The operational rules could be sent from an unauthorized party.

X

Possible damage:

— TC or TSP might base its business on wrong operational rules;

X

RQ. IF. 20

— undermine trust in the toll charging environment. TH . DT. 222 .0 4 TH . I T. 222 .0 4 TH .OUT. 22 2 .0 4

The transmission of the operational rules could be disturbed or delayed

(denial of service) .

X

X

RQ. XX.01

Possible damage: — loss of business because a TC or TSP might not be able to operate

according to the rules in due time;

— undermine trust in the toll charging environment. TH . DT. 222 .05

The (published) operational rules are not available for a TC or TSP upon

TH . I T. 222 .05

demand (denial of service) .

TH.IM.222.05

TH .OUT. 22 2 .05 TH .TC . 2 22 .05

X

X

RQ. XX.01

Possible damage: — TC or TSP might not be able to operate according to this rules in due

time;

— undermine trust in the toll charging environment. TH .TSP. 2 22 .06 TH .TC . 2 22 .06

The TC or TSP could not determine a liable originator of the operational

rules beyond doubt.

X

X

RQ. IF.1 3

Possible damage:

— TC or TSP cannot hold someone responsible for any damage because of receiving wrong operational rules; — undermine trust in the toll charging environment.

TH .TSP. 2 22 .07 TH .TC . 2 22 .07

The TSP or service user could not determine validity period for the operational rules beyond doubt.

X

X

RQ. IF.11

Possible damage:

— TSP or SU cannot hold the originator responsible for any damage because of wrong operational rules; — undermine trust in the toll charging environment.

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

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 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.60 — Threats to complaints Threat

TH . DT. 223 .01

The complaint could be changed during transmission to the

TH.IM.223.01

TH .OU T. 2 23 .01

DSRC

GNSS

X

X

Related RQ

No.

interoperability management, TC or to TSP or to a service user.

RQ. IF.11

Possible damage:

— IM, TC or TSP suffers loss for processing/correcting a wrong complaint; — undermine trus t in the toll charging environment.

TH .OU T. 2 23 .02

The complaint could be sent from an unauthorized party. Possible damage:

— receiver suffers loss for processing/correcting a wrong complaint;

X

X

RQ. IF. 20

— undermine trus t in the toll charging environment. TH . I T. 223 .03 TH .TSP. 223 .03 TH . SU. 22 3 .03 TH .TC . 223 .03

The complaint could be sent to an unauthorized party. Possible damage:

— infringement of business con fidentiality; — loss for resending it to the correct party and because of the delay;

X

X

RQ. IF. 20

— undermine trus t in the toll charging environment.

TH . DT. 223 .0 4 TH . I T. 223 .0 4 TH .OU T. 2 23 .0 4

The transmission of the complaint could be disturbed or delayed

(denial of service) .

X

X

RQ. XX.01

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; — undermine trus t in the toll charging environment.

TH . DT. 223 .05 TH . I T. 223 .05 TH .OU T. 2 23 .05 TH .TSP. 223 .05

The content of a complaint could be revealed to an unauthorized party.

X

X

RQ. DS .01

Possible damage:

— 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

No. TH . DT. 224.01 TH . I T. 224.01 TH .OU T. 2 24.01

Threat

Application for certi fication (TC, TSP) could be changed during transmission to the certi fication authority. Possible damage:

— certi fication authority suffers loss for processing/correcting a wrong application;

DSRC

GNSS

X

X

Related RQ RQ. IF.11 RQ. IF.1 2

— undermine trus t in the toll charging environment.

TH . DT. 224.02 TH . I T. 224.02 TH .OU T. 2 24.02

Granted certi fication could be changed during transmission to the applicant (TC , TSP) . Possible damage:

— applicant (TC,TSP) and certi fication authority suffers loss for timing and correcting a wrong certi fication;

X

X

RQ. IF.11 RQ. IF.1 2

— undermine trus t in the toll charging environment.

© ISO 2 01 5 – All rights reserved

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

119

ISO/TS 192 99: 2 015(E)

Table D.61 (continued) No.

Threat

TH . OU T. 2 2 4. 03

The application could be sent from an unauthorized party. — certi fication authority suffers loss for processing an unauthorized application;

TH . OU T. 2 2 4. 0 4 TH .TS P. 2 2 4. 0 4 TH .TC . 2 2 4. 0 4

TH . OU T. 2 2 4. 0 5

Candidate applicant (TC, TSP) can falsify certi ficate.

RQ. I F. 2 0

X

Pos s ible damage:

RQ. I F.11

—

RQ. I F.1 2

u ndermi ne tru s t i n the tol l chargi ng envi ronment.

Certi ficate can be generated and issued by a non-certi fied authority.

—

TH .TC . 2 2 4. 0 6

X

X

X

X

RQ. I F.1 2

— unfair and unjusti fied pro fits; — inadmissibility;

TH .TS P. 2 2 4. 0 6

X

u ndermi ne tru s t i n the tol l chargi ng envi ronment.

Pos s ible damage:

TH.IM.224.06

GNSS

Related RQ

Pos s ible damage:

—

DSRC

u ndermi ne tru s t i n the tol l chargi ng envi ronment.

The valid time period of the certi ficate could have elapsed or could not be determined beyond any doubt.

X

X

RQ. I F.11

Pos s ible damage:

— unfair and unjusti fied pro fits; — TH .TS P. 2 2 4. 07 TH .TC . 2 2 4. 07

u ndermi ne tru s t i n the tol l chargi ng envi ronment.

TC or TSP could use uncerti fied equipment.

X -

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

—

u ndermi ne tru s t i n the tol l chargi ng envi ronment.

X

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

T hre ats as describ e d in as set 2 01 .

X

X

Pos s ible damage:

RQ.ISMS.2

No.

Threat

TH .TS P. 2 2 5 . 01 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

agreements b etwe en the TS Ps and TC s .

Related RQ RQ.TC . 2 2 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

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

© I SO 2 0 1 5 – All rights reserved

ISO/TS 192 99:2 015(E)

Table D.63 — Threats to enforcement data Threat

TH . DT. 226 .01

Enforcement procedure s tarted although the OBE declared the presence

TH . I T. 226 .01

DSRC

GNSS

X

X

Related RQ

No.

in a toll domain correctly.

Enforcement is directed agains t a service user although his OBE declared

the presence in a toll domain correctly and a toll declaration was pro -

RQ.TC .01 RQ.TC . 3 0 RQ.TSP. 51

duced.

Possible damage:

— undermine trust in the toll charging environment; — wrong enforcement of service user(s)

— additional cost to the TSP for customer service TH . I T. 226 .02 TH .TSP. 226 .02 TH .TC . 226 .02

Wrong service user is enforced. Enforcement is directed agains t the wrong service user.

X

X

RQ.TC . 31

This could be caused by — 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:

— undermine trust in the toll charging environment; — wrong enforcement of service user(s); — additional cost to the TSP for customer service. TH . DT. 226 .03 TH . I T. 226 .03 TH .TC . 226 .03

Evidence data not court proof.

Cryptographic information is compromised during recording,

X

X

RQ.TC . 32

transmission or s toring of evidence data. Possible damage:

— undermine trust in the toll charging environment; — 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 No. TH .TC . 227.01 TH .TSP. 227.01

DSRC

GNSS

The invoice is not made out according to the invoicing rules of the

X

X

Possible damage:

RQ.TSP. 5 6

Threat

country of the TC.

— loss of VAT reclaim for service user; — excessive claims by service users;

Related RQ RQ.TC .06

— undermine trus t in the toll charging environment.

TH .TSP. 227.02

The invoice is not made out according to the invoicing rules of the coun-

try

of the TSP.

X

X

RQ.TC .06 RQ.TSP. 5 6

Possible damage:

— loss of VAT reclaim for service user; — excessive claims by service users;

— undermine trus t in the toll charging environment.

© ISO 2 01 5 – All rights reserved

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

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 No. T H . I T. 2 2 8 . 0 1 T H . O U T. 2 2 8 . 0 1 T H . S U. 2 2 8 . 01

Threat

Manipulation of stored data. Due to manipulation, the correct functionality of the ICC/OBE is no longer

DSRC

GNSS

X

X

Related RQ RQ. D S . 0 1 RQ. D S . 0 2

g u a r a n te e d .

RQ. D S . 0 5 P o s s i b l e d a m a ge :

— creation of wrong charging records with the goal to pay less toll; — instability of the ICC/OBE due to bogus data; —

T H .T S P. 2 2 8 . 0 2

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 .

Violation of data privacy requirements.

X

RQ.T S P. 42

P o s s i b l e d a m a ge :

— 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 T H . I T. 2 2 8 . 0 3 T H . O U T. 2 2 8 . 0 3

X

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 .

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

Such a connection can either be physical or contactless.

X

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 T H . O U T. 2 2 8 . 0 4 T H . S U. 2 2 8 . 0 4

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 .

P r e ve n ti o n o f c o m mu n i c ati o n .

X

An attacker tries to prevent the working of physical or contactless

X

RQ.T C . 0 1 RQ.T C . 0 2

c o m mu n i c a ti o n c h a n n e l s .

RQ.T S P. 0 1 P o s s i b l e d a m a ge :

T H . O U T. 2 2 8 . 0 5 T H . S U. 2 2 8 . 0 5 T H .T C . 2 2 8 . 0 5

— prevention of correct toll event detection; — less stability of the ICC/OBE operations. Change of con figuration data. An attacker tries to manipulate any con figuration data on the ICC (e.g. communication end points, retry limits, etc.).

RQ.T S P. 0 9 RQ.T S P. 5 1

X

X

RQ.T S P. 4 0

P o s s i b l e d a m a ge :

— less stability of the ICC/OBE operations; — creation of wrong charging records with the goal to pay less toll

T H . O U T. 2 2 8 . 0 6 T H . S U. 2 2 8 . 0 6 T H .T C . 2 2 8 . 0 6

—

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

—

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 .

Inspection of con figuration data. An attacker can gain an advantage from inspecting con figuration data

X

X

RQ.T S P. 41

o n th e I C C .

P o s s i b l e d a m a ge :

— undermine trust in the toll charging environment; — prepare efficient attacks on the system using this speci fic knowledge.

12 2

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

ISO/TS 192 99:2 015(E)

Table D.65 (continued) DSRC

GNSS

Internal knowledge on the OBE design.

X

X

An attacker tries, using technical and organizational measures (such as

RQ.ISMS.2

No.

Threat

TH .OU T. 2 2 8 .0 8 TH . SU. 22 8 .0 8

social engineering) to get internal or con fidential knowledge about the

Related RQ

ICC . Possible damage:

— less stability of the ICC/OBE operations; — prevention of correct toll event detection; — creation of incorrect charging records in order to pay less toll — undermine trus t in the toll charging environment.

© ISO 2 01 5 – All rights reserved

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

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. 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

The XY1)

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

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 – All rights reserved

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.

© ISO 2 01 5 – All rights reserved

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

12 5

ISO/TS 192 99: 2 015(E)

Interoperability

Steering Committee

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 ,

between the physical assets, user manuals, procedures, etc.;

— interfaces between the physical assets shown as interfaces in

12 6

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

i n fo r m ati o n

e xch a n ge d

on

i n te r face s

F i g u re E . 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)

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

© ISO 2 0 1 5 – All rights reserved

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

12 7

ISO/TS 192 99: 2 015(E)

3)

b)

including the particular set of principles , obj ectives, and business requirements for information

processing in XY EFC system.

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

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 0 1 5 – All rights reserved

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 ,

signi ficant changes to the threat situation.

risk

e va lu atio n s

shall

be

ca rrie d

out

whe n

the re

a re

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 T he

General

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 of this Technical Speci fication shall be used as a starting point for the risk de s c r ib e d

in

A n ne x

D

a s s e s s me nt p ro c e s s .

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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

12 9

ISO/TS 192 99: 2 015(E)

E.3 .2

Interface requirements

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.

6.3

E.3 .3

Data storage requirements

of this Technical Speci fication provides a simpli fied risk assessment for the data storages in the OBE, 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. 6 .4

13 0

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

© I S O 2 0 1 5 – Al l ri gh ts re s e rve d

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 F.3 .1

Organization of EETS Information Security 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.

© ISO 2 01 5 – All rights reserved

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

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

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 2015 – All rights reserved

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 © ISO 2 01 5 – All rights reserved

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

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

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 – All rights reserved

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

EETS - ADU authentication

EIPSec establishment

EETS - DSRC Key Encryption

digital signature of ISO 12855:2015 messages.

Used for establishing VPN connection with TSPs

Used for encrypting TSP DSRC Keysets from

f

v3

v3

v3

f signature algorithm

PKCS#1 v2.1 (recommended)

PKCS#1 v1.5

PKCS#1 v2.1 (recommended)

Hash algorithm

SHA256 (recommended) Signature, non-repudiation Computer (machine) 2 048

SHA1

SHA256 (recommended)

Signature and encryption

keyEncipherment

Computer (machine) 2048

Computer (machine) 2048

Obj ectives

and proof of delivery

Used for verifying the Description

Certi icate version Certi icate Key usage Subj ect type Key length 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:

Extensions

digitalSignature, non-repudiation basicConstraints: not CA cRLDistributionPoints: CDP_URL cRLDistributionPoints: CDP_URL

© ISO 2015 – All rights reserved

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

(! ) keyUsage:

digitalSignature,

(! ) keyUsage: keyEncipherment

basicConstraints: not CA cRLDistributionPoints: CDP_URL cRLDistributionPoints: CDP_URL

basicConstraints: not CA cRLDistributionPoints: CDP_URL cRLDistributionPoints: CDP_URL

keyEncipherment

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

[3]

ISO/IEC 8825 -4,

[4]

ISO/IEC 9646-7:1995, Information technology — Open Systems Interconnection — Conformance

[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

[8]

Rules (PER) — Part 2

Information technology — ASN.1 encoding rules: XML Encoding Rules (XER) — Part 4

testing methodology and framework — Part 7: Implementation Conformance Statements

Electronic Toll Service and its technical elements (OJ L 268/11 13 .10. 2009)

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] [12] [13] [14]

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)

Data S ecurity S tandard P.C.I. Requirements and Security Assessment Procedures (www. pcisecuritystandards.org) ISO/IEC 27000:2014, Information technology — Security techniques — Information security

management systems — Overview and vocabulary

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]

13 6

ISO/IEC 14888-1:2008, Information technology — Security techniques — Digital signatures with

appendix — Part 1: General

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 – All rights reserved

ISO/TS 192 99:2 015(E)

[19]

ISO/IEC 14888-2:2008, Information technology — Security techniques — Digital signatures with

[20]

ISO/IEC 14888-3:2006, Information technology — Security techniques — Digital signatures with

[21]

appendix — Part 2: Integer factorization based mechanisms appendix — Part 3: Discrete logarithm based mechanisms

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

[24]

ISO/TS 14907-2:2011, Electronic fee collection — Test procedures for user and fixed equipment —

[25]

Public-Key Cryptography Standards (PKCS) #1 v2.1: RSA Cryptography Standard, RSA

[26]

frameworks for open systems: Overview — Part 1

Part 2: Conformance test for the onboard unit application interface Laboratories, June 14, 20 02

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

[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

[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

[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

autonomous systems -- Part 3: Context data

ITS stations

Analysis (TVRA, V1.1.1)

for High Data Rate (HDR) data transmission equipment operating in the 5,8 GHz Industrial,

Scienti fic and Medical (ISM) band

© ISO 2 01 5 – All rights reserved

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

13 7

ISO/TS 192 99: 2 015(E)

ICS 35.240.60; 03.220.20 Price based on 137 pages

© ISO 2015 – All rights reserved

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