ISO/TS 19299:2015
(Main)Electronic fee collection — Security framework
Electronic fee collection — Security framework
The overall scope of ISO/TS 19299:2015 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 defined 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 ISO/TS 19299:2015 comprises the following: definition of a trust model; Basic assumptions and principles for establishing trust between the stakeholders. security requirements; security measures - countermeasures; Security requirements to support actual EFC system implementations. security specifications for interface implementation; These specifications represent an add-on for security to the corresponding standards. key management; Covering the (initial) setup of key exchange between stakeholders and several operational procedures like key renewal, certificate revocation, etc. security profiles; implementation conformance statement provides a checklist to be used by an equipment supplier, a system implementation, or an actor of a role declaring his conformity to ISO/TS 19299:2015; general information security objectives of the stakeholders which provide a basic motivation for the security requirements; threat analysis 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; recommendations for privacy-focused implementation; proposal for end-entity certificates.
Perception de télépéage — Cadre de sécurité
Le domaine d'application général de l'ISO/TS 19299:2015 consiste à fournir un cadre de sécurité de l'information pour l'ensemble des entités organisationnelles et techniques d'un plan de perception du télépéage (EFC), et plus particulièrement pour les interfaces entre elles, sur la base de l'architecture système définie dans l'ISO 17573. Le cadre de sécurité décrit un ensemble d'exigences et de mesures de sécurité associées destinées à être mises en ?uvre par les parties prenantes, garantissant ainsi un fonctionnement sécurisé de leur partie d'un système EFC, tel que l'exige la politique de sécurité d'un environnement de confiance. Le domaine d'application de l'ISO/TS 19299:2015 inclut: la définition d'un modèle de confiance; Principes et hypothèses de base pour l'établissement de relations de confiance entre les parties prenantes. les exigences de sécurité; les mesures de sécurité ? contre-mesures; Exigences de sécurité relatives à la prise en charge des mises en ?uvre du système EFC actuel. les spécifications de sécurité relatives à la mise en ?uvre de l'interface; Ces spécifications offrent une extension de sécurité aux normes correspondantes. la gestion des clés; Couvre l'instauration (initiale) de l'échange de clés entre les parties prenantes et plusieurs procédures opérationnelles telles que le renouvellement de clés, la révocation de certificats, etc. les profils de sécurité; la déclaration de conformité de la mise en ?uvre propose une liste de contrôle devant être utilisée par un fournisseur d'équipement, un chargé de mise en ?uvre d'un système ou l'acteur d'un rôle pour déclarer sa conformité à l'ISO/TS 19299:2015; les objectifs généraux de sécurité de l'information des parties prenantes qui constituent le principal motif des exigences de sécurité; l'analyse des menaces inhérentes au modèle de système EFC et à ses actifs en utilisant deux méthodes complémentaires distinctes, une analyse basée sur les attaques et une analyse basée sur les actifs; des exemples de politiques de sécurité; les recommandations relatives à une mise en ?uvre axée sur la protection de la vie privée; une proposition relative aux certificats d'entité finale.
General Information
Relations
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 19299
First edition
2015-10-01
Electronic fee collection — Security
framework
Perception de télépéage — Cadre de sécurité
Reference number
ISO/TS 19299:2015(E)
©
ISO 2015
---------------------- Page: 1 ----------------------
ISO/TS 19299:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TS 19299:2015(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 4
4 Symbols and abbreviated terms . 9
5 Trust model .10
5.1 Overview .10
5.2 Stakeholders trust relations .10
5.3 Technical trust model .11
5.3.1 General.11
5.3.2 Trust model for TC and TSP relations .11
5.3.3 Trust model for TSP and service user relations .13
5.3.4 Trust model for Interoperability Management relations .13
5.4 Implementation .13
5.4.1 Setup of trust relations .13
5.4.2 Trust relation renewal and revocation .14
5.4.3 Issuing and revocation of sub CA and end-entity certificates .14
5.4.4 Certificate and certificate revocation list profile and format .15
5.4.5 Certificate extensions .15
6 Security requirements .17
6.1 General .17
6.2 Information security management system .18
6.3 Communication interfaces .18
6.4 Data storage .19
6.5 Toll charger .19
6.6 Toll service provider .21
6.7 Interoperability Management .23
6.8 Limitation of requirements .23
7 Security measures — countermeasures .24
7.1 Overview .24
7.2 General security measures .24
7.3 Communication interfaces security measures .25
7.3.1 General.25
7.3.2 DSRC-EFC interface . .26
7.3.3 CCC interface .27
7.3.4 LAC interface .28
7.3.5 Front End to TSP back end interface .28
7.3.6 TC to TSP interface .29
7.3.7 ICC interface .30
7.4 End-to-end security measures .30
7.5 Toll service provider security measures .32
7.5.1 Front end security measures .32
7.5.2 Back end security measures .33
7.6 Toll charger security measures .34
7.6.1 RSE security measures . .34
7.6.2 Back end security measures .34
7.6.3 Other TC security measures .35
8 Security specifications for interoperable interface implementation .35
8.1 General .35
8.1.1 Subject.35
© ISO 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TS 19299:2015(E)
8.1.2 Signature and hash algorithms .35
8.2 Security specifications for DSRC-EFC .36
8.2.1 Subject.36
8.2.2 OBE .36
8.2.3 RSE .36
9 Key management .36
9.1 Overview .36
9.2 Asymmetric keys .36
9.2.1 Key exchange between stakeholders .36
9.2.2 Key generation and certification .37
9.2.3 Protection of keys .37
9.2.4 Application .37
9.3 Symmetric keys .38
9.3.1 General.38
9.3.2 Key exchange between stakeholders .38
9.3.3 Key lifecycle .39
9.3.4 Key storage and protection .40
9.3.5 Session keys .41
Annex A (normative) Security profiles .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 .124
Annex F (informative) Example for an EETS security policy .131
Annex G (informative) Recommendations for privacy-focused implementation .133
Annex H (informative) Proposal for end-entity certificates.135
Bibliography .136
iv © ISO 2015 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TS 19299:2015(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 identified 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 specific 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 204, Intelligent transport systems, 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 2015 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TS 19299:2015(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:
— definition of the security objectives and policy statements in a security policy;
— threat analysis with risk assessment to define the security requirements;
— development of the security measures followed by the development of security test specifications.
Figure 1 — Development path for the security documents
In the second step, each actor in an existing EFC system has to implement the defined 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 defined by the responsible stakeholders
and its freedom is only limited by laws and regulations. Nonetheless, this Technical Specification
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 benefit of each countermeasure which is only possible for an
implemented system.
— No specific system design or configuration during the development of this Technical Specification
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. Specific technical details of a particular system (e.g.
servers, computer centres, and de-central elements like road side equipment) need to be taken into
consideration during the implementation in addition to the present EFC security framework.
vi © ISO 2015 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/TS 19299:2015(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 Specification that is, if a requirement is
selected, the associated security measure(s) have to be implemented.
To understand the content of this Technical Specification, the reader should be aware of the
methodological assumptions used to develop it. The security of an (interoperable) EFC scheme depends
on the correct implementation and operation of a number of processes, systems, and interfaces.
Only a reliable end-to-end security ensures the accurate and trustworthy operation of interacting
components of toll charging environments. Therefore, this security framework also covers systems or
interfaces which are not EFC specific like back office connections. The application independent security
framework for such system parts and interfaces, the Information Security Management System (ISMS),
is provided in the ISO 2700x family of standards.
The development process of this Technical Specification is described briefly in the steps below:
a) Definition of the stakeholder objectives 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 definitions from the EFC architecture standard
(ISO 17573), the specification defines an abstract EFC system model as the basis for a threat
analysis, definition of requirements, and security measures.
c) The threats on the EFC system model and its assets are analysed by two different methods: an attack-
based analysis and an asset-based analysis. The first approach considers a number of threat scenarios
from the perspective of various attackers. The second approach looks in depth on threats against the
various identified 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 specification (see Clause 6) is based on the threats identified in Annex D. Each
requirement is at least motivated by one threat and at least one requirement covers each threat.
e) The definition of security measures (see Clause 7) provides a high-level description of recommended
possible methods to cover the developed requirements.
f) The security specifications for interoperable interface implementation (Clause 8) provide detailed
definitions, e.g. for message authenticators. These specifications 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, certificates, certificate revocation lists, etc.) to support security services like confidentiality,
integrity, authenticity, and non-repudiation. This section of the specification covers the (initial)
setup of key exchange between stakeholders and several operational procedures like key renewal,
certificate revocation, etc.
h) A general trust model (see Clause 5) is defined to form the basis for the implementation of
cryptographic procedures to ensure confidentiality, integrity, and authenticity of exchanged
data. In this context, the security framework references approved international standards for the
implementation of cryptographic procedures enhanced by EFC specific details where needed.
A stakeholder of an EFC scheme who wants to use this security framework needs to do the following:
— define 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 2015 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO/TS 19299:2015(E)
Annex E and Annex F) as an aid for using this Technical Specification 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 Specification. Evidence can be provided by a self-declaration, an internal or
external audit, or other certifications.
EFC role model
This Technical Specification complies with the role model defined 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 Specification
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 specifications and activities
that in common, define and maintain a set of rules that govern the overall toll charging environment.
The trust model defined in this Technical Specification is based on the role model above and it is also
the technical base for the protection of the data communication between the entities of the role model.
Besides this communication security, trust in the secure implementation and management of the back
end and other equipment for the EFC framework is required. A toll charger or toll service provider
compliant to this Technical Specification 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, define the
security requirements and associated security measures for this Technical Specification. This Technical
Specification is based on the assumption of an OBE which is dedicated to EFC purposes only and neither
considers value added services based on EFC OBE, nor more generic OBE platforms (also called in-
vehicle ITS Stations) used to host the EFC application. The OBE may either be connected to a central
viii © ISO 2015 – All rights reserved
---------------------- Page: 8 ----------------------
ANPR
ISO/TS 19299:2015(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 Specification.
GNSS
Position&
Time
User
TollServiceProvider
Contract
contact(less) ServicePoint
ICC
Driver Personnel
Customization,
Maintenance
contact(less)
HMI
optional
Service Provider
OBE CN OBE
Valueadded
BackEnd
Proxy
services
Power,
Tacho,
DSRC
CAN,
etc.
TollCharger
Toll Charger
BackEnd
Vehicle RSE,
Enforcement
Personnel
Figure 3 — EFC system model of the EFC Security framework
Relation to other security standards
Several generic and specific standards and Technical Reports concerning security issues for information
technology already exist. This Technical Specification uses these existing standards and expands their
usability for EFC applications. The framework references and tailors the security techniques and
methodologies from these standards.
Figure 4 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 Specification. Standards that are directly used and referenced are highlighted in
black (as opposed to grey). Other standards that may provide other security related input are given for
information and completeness only, but are not further used.
© ISO 2015 – All rights reserved ix
Equipmentsupplier,serviceprovider,etc.
---------------------- Page: 9 ----------------------
ISO/TS 19299:2015(E)
ETSI TR 102 731
(Essential Counter-
measures for Co-operative
ITS)
Digital signatures
Equipment management
Figure 4 — Relevant security standards in the context of the EFC — Security framework
Each group of standards in Figure 4 provides the following features:
— Security techniques — Security measures and algorithms: The group is a collection of essential
security measures and recommended cryptographic algorithms including the guidelines for
accurate use.
— IT — Open system interconnection: This group of standards provides mechanisms for the secure
communications between open systems. The standards address some of the security requirements in
the areas of authentication and othe
...
SPÉCIFICATION ISO/TS
TECHNIQUE 19299
Première édition
2015-10-01
Perception de télépéage — Cadre de
sécurité
Electronic fee collection — Security framework
Numéro de référence
ISO/TS 19299:2015(F)
©
ISO 2015
---------------------- Page: 1 ----------------------
ISO/TS 19299:2015(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO/TS 19299:2015(F)
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 3
3 Termes et définitions . 4
4 Symboles et abréviations .10
5 Modèle de confiance .11
5.1 Vue d’ensemble .11
5.2 Relations de confiance entre les parties prenantes .11
5.3 Modèle de confiance technique .13
5.3.1 Généralités .13
5.3.2 Modèle de confiance pour les relations entre le percepteur de péage (TC)
et le prestataire de services de péage (TSP) .13
5.3.3 Modèle de confiance pour les relations entre le prestataire de services de
péage (TSP) et l’utilisateur de service (SU) .14
5.3.4 Modèle de confiance pour les relations du gestionnaire de
l’interopérabilité (IM) .14
5.4 Mise en œuvre.14
5.4.1 Instauration des relations de confiance .14
5.4.2 Renouvellement et révocation des relations de confiance .15
5.4.3 Emission et révocation des certificats de l’autorité de certification (CA)
subordonnée et d’entité finale .16
5.4.4 Profil et format de certificat et de liste de révocation de certificats (CRL) .16
5.4.5 Extensions de certificat .16
6 Exigences relatives à la sécurité .18
6.1 Généralités .18
6.2 Système de management de la sécurité de l’information (ISMS) .19
6.3 Interfaces de communication .19
6.4 Stockage de données .20
6.5 Percepteur de péage .20
6.6 Prestataire de services de péage (TSP) .22
6.7 Gestionnaire de l’interopérabilité (IM) .24
6.8 Limitation des exigences .24
7 Mesures de sécurité — Contre-mesures .25
7.1 Vue d’ensemble .25
7.2 Mesures de sécurité générales .25
7.3 Mesures de sécurité relatives aux interfaces de communication .26
7.3.1 Généralités .26
7.3.2 Interface DSRC-EFC .27
7.3.3 Interface CCC .28
7.3.4 Interface LAC .29
7.3.5 Interface entre le système frontal et le système dorsal du prestataire de
services de péage (TSP) .29
7.3.6 Interface entre le percepteur de péage (TC) et le prestataire de services
de péage (TSP) .30
7.3.7 Interface ICC.31
7.4 Mesures de sécurité de bout en bout .31
7.5 Mesures de sécurité relatives au prestataire de services de péage (TSP) .33
7.5.1 Mesures de sécurité relatives au système frontal .33
7.5.2 Mesures de sécurité relatives au système dorsal . .34
7.6 Mesures de sécurité relatives au percepteur de péage (TC) .34
7.6.1 Mesures de sécurité relatives à l’équipement au sol (RSE) .34
© ISO 2015 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO/TS 19299:2015(F)
7.6.2 Mesures de sécurité relatives au système dorsal . .35
7.6.3 Autres mesures de sécurité relatives au percepteur de péage (TC) .36
8 Spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable .36
8.1 Généralités .36
8.1.1 Sujet .36
8.1.2 Signature et algorithmes de hachage .36
8.2 Spécifications de sécurité relatives au télépéage DSRC .36
8.2.1 Sujet .36
8.2.2 OBE (On-Board Equipment) .37
8.2.3 Equipement routier .37
9 Gestion de clés .37
9.1 Vue d’ensemble .37
9.2 Clés asymétriques .37
9.2.1 Echange de clés entre les parties prenantes .37
9.2.2 Génération et certification de clés .38
9.2.3 Protection des clés .38
9.2.4 Application .38
9.3 Clés symétriques .38
9.3.1 Généralités .38
9.3.2 Echange de clés entre les parties prenantes .39
9.3.3 Cycle de vie des clés .39
9.3.4 Stockage et protection de clé .41
9.3.5 Clés de session .42
Annexe A (normative) Profils de sécurité .43
Annexe B (normative) Formulaire ICS .48
Annexe C (informative) Objectifs des parties prenantes et exigences génériques .67
Annexe D (informative) Analyse des menaces .72
Annexe E (informative) Politiques de sécurité .134
Annexe F (informative) Exemple de politique de sécurité d’un service européen de
télépéage (SET) .141
Annexe G (informative) Recommandations relatives à une mise en œuvre axée sur la
vie privée .143
Annexe H (informative) Proposition relative aux certificats d’entité finale .145
Bibliographie .146
iv © ISO 2015 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO/TS 19299:2015(F)
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer
un engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à
l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes
de l’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos —
Informations supplémentaires.
L’ISO/TS 19299 a été élaborée par le comité européen de normalisation (CEN), en collaboration
avec le comité technique CEN/TC 204, Systèmes intelligents de transport, conformément à l’accord de
coopération technique entre l’ISO et le CEN (Accord de Vienne).
Cette première édition de l’ISO/TS 19299 annule et remplace la CEN/TS 16439:2013.
© ISO 2015 – Tous droits réservés v
---------------------- Page: 5 ----------------------
ISO/TS 19299:2015(F)
Introduction
Note explicative
Le processus de développement d’un concept de sécurité et de sa mise en œuvre visant à protéger
un système existant de perception du télépéage (EFC, Electronic Fee Collection) inclut normalement
plusieurs étapes, notamment:
— la définition des objectifs de sécurité ainsi que des déclarations de politique dans le cadre d’une
politique de sécurité;
— une analyse des menaces, associée à une évaluation des risques afin de définir les exigences de sécurité;
— le développement des mesures de sécurité suivies par le développement des spécifications
d’essai de sécurité.
Anglais Français
POLICIES POLITIQUES
Security objectives Objectifs de sécurité
Policy statements Déclarations de politique
REQUIREMENTS EXIGENCES
Threat analysis Analyse des menaces
Security requirements Exigences de sécurité
SPECIFICATIONS SPECIFICATIONS
Security measures Mesures de sécurité
Specifications of security measures Spécifications de mesures de sécurité
TEST PROCEDURES PROCEDURES D’ESSAI
Test specifications Spécifications d’essai
Figure 1 — Plan de développement des documents de sécurité
vi © ISO 2015 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO/TS 19299:2015(F)
Pour la deuxième étape, chaque acteur d’un système EFC existant doit mettre en œuvre les mesures
de sécurité définies et superviser leur efficacité. Les mesures de sécurité ne fonctionnant pas ou
fonctionnant de manière incorrecte doivent être améliorées. Le développement du cadre de sécurité EFC
s’attache à suivre cette approche autant que possible. La méthodologie utilisée doit tenir compte des
limitations suivantes:
— Il n’existe aucune politique de sécurité: la politique de sécurité peut seulement être définie par les
parties prenantes responsables, et son rayon d’action est uniquement limité par la réglementation
et les lois applicables. Néanmoins, la présente Spécification technique propose quelques exemples
simples des politiques de sécurité possibles (de l’Annexe E à l’Annexe F).
— Aucune évaluation des risques n’est possible: l’évaluation des risques compare la perte possible pour
la partie prenante et les ressources nécessaires (par exemple équipement, connaissances, temps,
etc.) à la réalisation d’une attaque. Il s’agit d’une évaluation comparative des coûts et bénéfices de
chaque contre-mesure, ce qui n’est possible que dans le cas d’un système mis en œuvre.
— Pendant le développement de la présente Spécification technique, aucune conception ou configuration
système spécifique n’a été envisagée à des fins d’applicabilité à l’échelle universelle. Seules les
normes EFC de base disponibles et les commentaires reçus vis-à-vis de la CEN/TS 16439:2013
(l’édition précédente du cadre de sécurité EFC) ont été pris comme références. Outre le cadre de
sécurité EFC présent, les détails techniques spécifiques d’un système particulier (par exemple
serveurs, centres informatiques et éléments décentralisés comme les équipements au sol) doivent
être pris en considération lors de la mise en œuvre.
La sélection des exigences et des mesures de sécurité respectives pour un système EFC existant dépend
de la politique de sécurité et de l’évaluation des risques des systèmes des différentes parties prenantes.
Etant donné qu’il n’existe pas de politique de sécurité générale valide et qu’aucune évaluation des
risques ne peut être fournie, la cadre de sécurité EFC propose un ensemble d’exigences et de mesures de
sécurité couvrant le plus de menaces possibles, sans prétendre à l’exhaustivité.
Cependant, il existe une condition de conformité à la présente Spécification technique: si une exigence
est sélectionnée, la ou les mesures de sécurité associées doivent être mises en œuvre.
Pour comprendre le contenu de la présente Spécification technique, il convient que le lecteur ait
connaissance des hypothèses méthodologiques utilisées pour son élaboration. La sécurité d’un plan EFC
(interopérable) dépend de la réussite de la mise en œuvre et du bon fonctionnement de plusieurs
processus, systèmes et interfaces. Seule une sécurité de bout en bout fiable garantit le fonctionnement
précis et fiable des composants d’interaction des environnements de perception du péage. C’est
pourquoi ce cadre de sécurité couvre également les systèmes ou interfaces qui ne sont pas spécifiques
au concept EFC (notamment les connexions de back-office). Le cadre de sécurité indépendant de
l’application pour ces parties et interfaces, le système de management de la sécurité de l’information
(ISMS, Information Security Management System), est fourni dans la collection de normes ISO 2700x.
Le processus d’élaboration de la présente Spécification technique est décrit de manière succincte ci-après:
a) Définition des objectifs des parties prenantes et des exigences génériques qui constituent le
principal motif des exigences de sécurité (voir Annexe C). Une politique de sécurité possible
supportée par un ensemble de déclarations de politique est fournie à l’Annexe E, et un exemple de
politique de sécurité SET (Service Européen de Télépéage) est donné à l’Annexe F.
b) En fonction du modèle de rôle EFC et des définitions supplémentaires de la norme d’architecture EFC
(ISO 17573), la spécification définit un modèle de système EFC abstrait comme base pour une
analyse des menaces, la définition des exigences et les mesures de sécurité.
c) Les menaces inhérentes au modèle de système EFC et à ses actifs sont analysées par deux méthodes
distinctes: une analyse basée sur les attaques et une analyse basée sur les actifs. La première
approche envisage plusieurs scénarios du point de vue des agresseurs. La seconde approche étudie
de manière approfondie les menaces à l’égard des différents actifs identifiés (entités corporelles
et incorporelles). Cette approche, même si elle introduit une certaine redondance, garantit
l’exhaustivité et la couverture d’une gamme plus vaste de risques (voir Annexe D).
© ISO 2015 – Tous droits réservés vii
---------------------- Page: 7 ----------------------
ISO/TS 19299:2015(F)
d) La spécification des exigences (voir Article 6) est basée sur les menaces identifiées à l’Annexe D.
Chaque exigence est au minimum motivée par une menace et au moins une exigence couvre
chaque menace.
e) La définition des mesures de sécurité (voir Article 7) propose une description générale des
méthodes recommandées possibles pour couvrir les exigences élaborées.
f) Les spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable (voir
Article 8) fournissent des définitions détaillées, par exemple pour les authentificateurs de
messages. Ces spécifications offrent une extension de sécurité aux normes d’interface applicables
correspondantes.
g) Les exigences fondamentales de gestion de clés prenant en charge la mise en œuvre des interfaces
interopérables sont décrites à l’Article 9. L’environnement de perception du péage utilise
des éléments cryptographiques (clés, certificats, liste de révocation de certificats, etc.) pour
prendre en charge les services de sécurité tels que la confidentialité, l’intégrité, l’authenticité et
la non-répudiation. Le présent paragraphe de la spécification couvre l’instauration (initiale) de
l’échange de clés entre les parties prenantes et plusieurs procédures opérationnelles telles que le
renouvellement de clés, la révocation de certificats, etc.
h) Un modèle de confiance général (voir Article 5) est défini pour former la base de la mise en œuvre
de procédures cryptographiques afin de garantir la confidentialité, l’intégrité et l’authenticité des
données échangées. Dans ce contexte, le cadre de sécurité référence les normes internationales
approuvées pour la mise en œuvre de procédures cryptographiques améliorées par des détails EFC
spécifiques lorsque cela s’avère nécessaire.
Une partie prenante d’un plan EFC souhaitant utiliser ce cadre de sécurité doit notamment:
— définir une politique de sécurité pour le plan EFC (pouvant impliquer plus d’une partie prenante
dans un plan EFC interopérable). Quelques exemples de la politique de sécurité et de ses éléments
sont fournis (à l’Annexe E et à l’Annexe F) à titre d’aide à l’utilisation de la présente Spécification
technique pour concevoir un système sécurisé pour un cadre d’interopérabilité concret (y compris
le service européen de télépéage [SET]);
— identifier les processus, systèmes et interfaces applicables, puis les associer au cadre de sécurité EFC;
— sélectionner les exigences de sécurité correspondantes en fonction de la politique de sécurité;
— mettre en œuvre les mesures de sécurité associées aux exigences sélectionnées;
— fournir une preuve de la conformité de ses systèmes, processus et interfaces aux exigences définies
dans la présente Spécification technique. La preuve peut être une autodéclaration, un audit interne
ou externe, voire d’autres certifications.
Modèle de rôle EFC
La présente Spécification technique satisfait au modèle de rôle défini dans l’ISO 17573. Selon ce modèle
de rôle, le percepteur de péage (TC, Toll Charger) est le fournisseur de l’infrastructure de péage ou du
service de transport et ainsi le destinataire des redevances du réseau routier. Le TC est l’acteur associé
au rôle Perception du péage (voir Figure 2).
viii © ISO 2015 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO/TS 19299:2015(F)
Anglais Français
Interoperability management Gestion de l’interopérabilité
Service provision Fourniture du service
Toll charging Perception du télépéage
Service usage Utilisation du service
Figure 2 — Modèle de rôle sous-jacent de la présente Spécification technique
Les prestataires de services de péage (TSP, Toll Service Provider) fournissent un équipement embarqué
(OBE, On-Board Equipment) aux utilisateurs du service d’infrastructure ou de transport à péage.
Les TSP sont chargés de fournir l’OBE qui sera utilisé pour la collecte des données, ce qui permet
au TC d’envoyer une demande au TSP en ce qui concerne l’utilisation de l’infrastructure ou du service
de transport par leurs utilisateurs de services (SU, Service User). Dans les systèmes autonomes,
chaque TSP fournit les déclarations de péage au TC qui exploite le système autonome. Il se peut qu’un
tel TC reçoive les déclarations de péage de plus d’un TSP. Dans les systèmes de communications
dédiées à courte portée (DSRC, Dedicated Short-Range Communication), le TC reçoit les déclarations de
péage principales de son propre équipement au sol (RSE, Road-Side Equipment) qui communique avec
l’OBE du TSP ainsi que les données de perception supplémentaires, si nécessaires, du TSP. La gestion
de l’interopérabilité (IM, Interoperability Management) représentée à la Figure 2 inclut toutes les
spécifications et activités qui permettent de définir et de maintenir un ensemble de règles gouvernant
l’environnement global de perception du péage.
Le modèle de confiance défini dans la présente Spécification technique est basé sur le modèle de rôle
ci-dessus et constitue également la base technique pour la protection de la communication des données
entre les entités du modèle de rôle. Outre la sécurité des communications, la mise en œuvre et la gestion
sécurisées du système dorsal et des autres équipements de l’infrastructure EFC doivent être fiables. Un
percepteur de péage (TC) ou un prestataire de services de péage (TSP) en conformité avec la présente
Spécification technique doit être capable de fournir une preuve du management de la sécurité exigé.
Une telle preuve constitue la base de relations de confiance entre les entités impliquées.
La Figure 3 ci-après représente le modèle de système EFC abstrait utili
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.