ISO 19299:2020
(Main)Electronic fee collection — Security framework
Electronic fee collection — Security framework
This document defines an information security framework for all organizational and technical entities of an EFC scheme and for the related interfaces, based on the system architecture defined in ISO 17573-1. The security framework describes a set of security requirements and associated security measures. Annex D contains a list of potential threats to EFC systems and a possible relation to the defined security requirements. These threats can be used for a threat analysis to identify the relevant security requirements for an EFC system. The relevant security measures to secure EFC systems can then be derived from the identified security requirements.
Perception de télépéage — Cadre de sécurité
Ce document définit un cadre de sécurité de l'information pour toutes les entités organisationnelles et techniques d'un système EFC et pour les interfaces correspondantes, sur la base de l'architecture système définie dans la norme ISO 17573-1. Le cadre de sécurité décrit un ensemble d'exigences de sécurité et de mesures de sécurité associées. L'Annexe D contient une liste des menaces potentielles pour les systèmes EFC et une relation possible avec les exigences de sécurité définies. Ces menaces peuvent être utilisées pour une analyse des menaces afin d'identifier les exigences de sécurité pertinentes pour un système EFC. Les mesures de sécurité pertinentes pour sécuriser les systèmes EFC peuvent ensuite être dérivées des exigences de sécurité identifiées.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19299
First edition
2020-08
Electronic fee collection — Security
framework
Perception de télépéage — Cadre de sécurité
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Trust model . 4
5.1 Overview . 4
5.2 Stakeholders trust relations . 5
5.3 Technical trust model . 6
5.3.1 General. 6
5.3.2 Trust model for TC and TSP relations . 6
5.3.3 Trust model for TSP and service user relations . 7
5.3.4 Trust model for interoperability management relations . 7
5.4 Implementation . 7
5.4.1 Setup of trust relations . 7
5.4.2 Trust relation renewal and revocation . 8
5.4.3 Issuing and revocation of sub CA and end-entity certificates . 8
5.4.4 Certificate and certificate revocation list profile and format . 9
5.4.5 Certificate extensions . 9
6 Security requirements .10
6.1 General .10
6.2 Information security management system .11
6.3 Communication interfaces .12
6.4 Data storage .12
6.5 Toll charger .12
6.6 Toll service provider .14
6.7 Interoperability management .16
6.8 Limitation of requirements .17
7 Security measures — Countermeasures .17
7.1 Overview .17
7.2 General security measures .18
7.3 Communication interfaces security measures .18
7.3.1 General.18
7.3.2 DSRC-EFC interface . .19
7.3.3 CCC interface .20
7.3.4 LAC interface .21
7.3.5 Front End to TSP back end interface .21
7.3.6 TC to TSP interface .22
7.3.7 ICC interface .23
7.4 End-to-end security measures .24
7.5 Toll service provider security measures .25
7.5.1 Front end security measures .25
7.5.2 Back end security measures .26
7.6 Toll charger security measures .27
7.6.1 RSE security measures . .27
7.6.2 Back end security measures .28
7.6.3 Other TC security measures .28
8 Security specifications for interoperable interface implementation .29
8.1 General .29
8.1.1 Subject.29
8.1.2 Signature and hash algorithms .29
8.2 Security specifications for DSRC-EFC .29
8.2.1 Subject.29
8.2.2 OBE .29
8.2.3 RSE .29
9 Key management .30
9.1 Overview .30
9.2 Asymmetric keys .30
9.2.1 Key exchange between stakeholders .30
9.2.2 Key generation and certification .30
9.2.3 Protection of keys .30
9.2.4 Application .31
9.3 Symmetric keys .31
9.3.1 General.31
9.3.2 Key exchange between stakeholders .31
9.3.3 Key lifecycle .32
9.3.4 Key storage and protection .33
9.3.5 Session keys .34
Annex A (normative) Security profiles .35
Annex B (informative) Implementation conformance statement (ICS) proforma .39
Annex C (informative) Stakeholder objectives and generic requirements .57
Annex D (informative) Threat analysis .61
Annex E (informative) Security policies .118
Annex F (informative) Example for an EETS security policy .124
Annex G (informative) Recommendations for privacy-focused implementation .126
Bibliography .128
iv © ISO 2020 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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 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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC
278 Intelligent transport systems, in accordance with the Agreement on technical cooperation between
ISO and CEN (Vienna Agreement).
This first edition cancels and replaces ISO/TS 19299:2015, which has been technically revised.
The main changes compared to the previous edition are as follows:
— added requirements and security measures for the use of common payment media according to
ISO/TS 21193;
— updated data protection considerations in Annex G, in order to take into account the European
Union’s new General Data Protection Regulation (i.e. Directive 2016/679/EC).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
Context of this document
The development process for a security concept and implementation to protect any existing electronic
fee collection (EFC) system normally includes several steps as follows (see Figure 1):
— 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
Each actor in an existing EFC system implements the defined security measures and supervises their
effectiveness. When a security measure is found not working properly, an improvement process is
started. The development of the EFC security framework follows this approach, with the following
limitations:
— No standard security policy exists, nor can it be defined: The security policy can only be defined by
the responsible stakeholders and it is limited by laws and regulations. Nonetheless, this document
provides basic examples of possible security policies (in Annex E to Annex F).
— No standard risk assessment is possible: Risk assessment compares possible losses to stakeholders
with the required resources (e.g. equipment, knowledge, time) to perform an attack. In a real system,
risk assessment is based on the evaluation of the costs and benefits of each countermeasure.
— No specific system design or configuration was deemed as universally applicable. Only the available
EFC base standards were taken as references. Specific technical details of a particular system
(e.g. servers, computer centres, and de-centralised elements like roadside equipment) need to be
additionally taken into consideration when implementing security measures.
vi © ISO 2020 – All rights reserved
Selection of requirements and 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
no overall valid security policy, nor is there the possibility to provide a useful risk assessment, the EFC
security framework provides an extensive (but non-exhaustive) toolbox of requirements and security
measures.
To understand the content of this document, the reader should be aware of the methodological
assumptions used to develop it. 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. An application independent security framework for such system
parts and interfaces, an information security management system (ISMS), can be found, for example, in
the ISO/IEC 27000 series.
The development process of this document 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 a 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-1), 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 several threat
scenarios from the perspective of various attackers. The second approach looks in depth on threats
against the various identified assets (tangible and intangible). This approach, although producing
some redundancy, ensures completeness and coverage of a broad 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 each threat is covered by at least one
requirement.
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, such as 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
(e.g. keys, certificates, certificate revocation lists) to support security services like confidentiality,
integrity, authenticity, and non-repudiation. This section of the document covers the (initial) setup
of key exchange between stakeholders and several operational procedures, such as key renewal,
certificate revocation.
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 should 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 Annex E and
Annex F) as an aid 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
of this document. Evidence can be provided by a self-declaration, an internal or external audit, or
other certifications.
EFC role model
This document complies with the role model defined in ISO 17573-1. According to this role model, the
toll charger (TC) manages the tolled infrastructure or transport service and is the recipient of the road
usage fees. The TC is the actor associated with the toll charging role (see Figure 2).
Figure 2 — Role model underlying this document
Toll service providers (TSPs) act as intermediaries between TC’s and road users, by providing these
latter with contractual relationships and devices (generally on-board equipment — OBE) to interface
the tolled infrastructure or transport service. The OBE 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. 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. The interoperability
management role (IM) in Figure 2 comprises all specifications and activities that define and maintain a
set of rules that govern the overall toll charging environment.
The trust model defined in this document is based on the role model summarized 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 essential. A TC or TSP compliant to this document
should 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 and define the
security requirements and associated security measures for this document. This document assumes
an OBE that is dedicated to EFC purposes only and does not consider value added services based on
EFC OBE, nor does it consider more generic OBE platforms (also called in-vehicle ITS Stations) which
could be used to host the EFC application. The OBE may either be connected to a central account or use
a payment medium such as integrated circuit cards (ICC) or mobile payment for on-board-account EFC
system. Any financial transactions are out of scope of this document.
viii © ISO 2020 – All rights reserved
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 document makes use of existing standards and expands their usability
for EFC applications. This framework references and adapts security techniques and methodologies
from relevant standards.
Figure 4 shows the context of the EFC security framework to the most relevant security standards that
gave input to this document. Standards that are directly used and referenced are highlighted in black.
Figure 4 — Relevant security standards in the context of the EFC — Security framework
Standards shown in Figure 4 are grouped in the following categories, where arrows inside each group
indicate which standard provides input to other standards:
— Security techniques — Security measures and algorithms: collection of essential security
measures and recommended cryptographic algorithms including the guidelines for accurate use.
— IT — Open system interconnection: provides mechanisms for the secure communications
between open systems. These 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): defines methodologies and processes
for the security evaluation and certification for most categories of products used in the EFC
environment.
— IT — Security techniques — Information security management system: defines requirements
and guidelines for the implementation of security management systems for all types of organizations.
The standards in this group are suited for security solutions of back end and other fixed or installed
equipment of EFC systems, including their software.
An ISO/IEC 27001 certification of a TC or TSP organization may be used to demonstrate conformity
with this document, provided that the scope and the Statements of Applicability (SoA) include the
EFC business processes specified in ISO 17573-1 and that security requirements and their associated
security measures provided by this document are applied, for example by using them as part of so-
called catalogues, i.e., sets containing the security measures and control objectives. Figure 5 illustrates
how this approach works in two parallel paths. The first step of both paths is analysing the business
x © ISO 2020 – All rights reserved
processes, which is then followed by a threat analysis. A common risk analysis combines the generic
and the EFC related analysis and results in the respective security measures and controls.
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 uses
existing threat analysis with relation to EFC or ITS, such as ETSI/TR 102 893.
This document contains:
— definition of a trust model (Clause 5): basic assumptions and principles for establishing trust
between the stakeholders;
— security requirements (Clause 6): security requirements to support EFC system implementations;
— security measures — countermeasures (Clause 7);
— security specifications for interface implementation (Clause 8): security add-on to EFC standards,
as shown in Figure 6;
— key management (Clause 9): initial setup of key exchange between stakeholders and several
operational procedures, such as key renewal, certificate revocation;
— security profiles (Annex A);
— implementation conformance statement (Annex B): checklist to be used by an equipment supplier, a
system implementation, or an actor of a role declaring their conformity to this document;
— general information security objectives of the stakeholders (Annex C) which provide a basic
motivation for the security requirements;
— threat analysis (Annex D) on the EFC system model and its assets using two different complementary
methods, an attack-based analysis, and an asset-based analysis;
— security policy examples (Annex E and Annex F);
— recommendations for privacy-focused implementation (Annex G).
Figure 6 — Scope of EFC security framework for secure communication
This document does not encompass:
— 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 CEN/
TR 16690.
— the technical trust relation between TSP and service user;
— specifications for implementation of security for specific EFC services, such as European Electronic
Toll Service (EETS);
— detailed specifications required for privacy-friendly EFC implementations;
— any financial transactions between the payment service provider and the payment medium, for
example ICC issued by it.
xii © ISO 2020 – All rights reserved
INTERNATIONAL STANDARD ISO 19299:2020(E)
Electronic fee collection — Security framework
1 Scope
This document defines an information security framework for all organizational and technical entities
of an EFC scheme and for the related interfaces, based on the system architecture defined in ISO 17573-1.
The security framework describes a set of security requirements and associated security measures.
Annex D contains a list of potential threats to EFC systems and a possible relation to the defined
security requirements. These threats can be used for a threat analysis to identify the relevant security
requirements for an EFC system.
The relevant security measures to secure EFC systems can then be derived from the identified security
requirements.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 2859-1, Sampling procedures for inspection by attributes — Part 1: Sampling schemes indexed by
acceptance quality limit (AQL) for lot-by-lot inspection
ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical
interface and transmission protocols
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) — Part 1:
ISO/IEC 9594-8:2017, Information technology — Open Systems Interconnection — The Directory — Part 8:
Public-key and attribute certificate frameworks
ISO/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO/IEC 11770-1:2010, Information technology — Security techniques — Key management — Part 1:
Framework
ISO/IEC 11770-3:2015, Information technology — Security techniques — Key management — Part 3:
Mechanisms using asymmetric techniques
ISO 12813, Electronic fee collection — Compliance check communication for autonomous systems
ISO 12855, Electronic fee collection — Information exchange between service provision and toll charging
ISO 13141, Electronic fee collection — Localization augmentation communication for autonomous systems
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 17575-1, Electronic fee collection — Application interface definition for autonomous systems — Part 1:
Charging
ISO/TS 17573-2, Electronic fee collection — System architecture for vehicle related tolling— Part 2:
Vocabulary
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
EN 15509:2014, Electronic fee collection — Interoperability application profile for DSRC
CEN/TS 16702-1, Electronic fee collection — Secure monitoring for autonomous toll systems — Part 1:
Compliance checking
IETF RFC 4648:2006-10, The Base16, Base32, and Base64 Data Encodings
IETF RFC 5280:2008-05, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile
Federal Information Processing Standards (FIPS) PUB 140-2, December 2002, Security requirements for
cryptographic modules
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 17573-2 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
asset
anything that has value to a stakeholder
Note 1 to entry: An asset may be tangible or intangible.
[SOURCE: ISO/TS 17573-2:2020, 3.9, modified — Note 1 to entry added.]
3.2
certification authority
CA
entity trusted by one or more entities to assign and revoke public key certificates
[SOURCE: ISO 21188:2018, 3.21]
3.3
data subject's consent
any freely given specific and informed written indication of its wishes by which the data subject
signifies its agreement to personal data relating to it being processed
3.4
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.
[SOURCE: ISO/TS 17573-2:2020, 3.73, modified — Note 1 to entry added.]
2 © ISO 2020 – All rights reserved
3.5
lot
definite amount of items, delivered together
Note 1 to entry: An inspection lot may consist of several batches or parts of batches.
[SOURCE: ISO 2859-1: 1999, 3.1.13, modified.]
3.6
policy
intentions and direction of an organization, as formally expressed by its management
[SOURCE: ISO/IEC 27000:2018, 3.53, modified.]
3.7
sample
set of one or more items taken from a lot and intended to provide information on the lot
[SOURCE: ISO 2859-1: 1999, 3.1.15]
3.8
service user
SU
generic term used for the customer of a toll service provider, one liable for toll, the owner of the vehicle,
a fleet operator, a driver, depending on the context
4 Abbreviated terms
AC_CR access credentials (ISO 14906)
ADU application data unit
CA certification authority (ISO 21188)
CCC compliance check communication (ISO 12813)
CN cellular network
CRL certificate revocation list
DSRC dedicated short-range communication (ISO 14906)
EETS European electronic toll service
EFC electronic fee collection (ISO 17573-1)
GNSS global navigation and satellite system (ISO 17573-1)
HTTP hypertext transfer protocol
HTTPS http over secure socket layer
HW Hardware
ICC integrated circuit(s) card
ICS implementation conformance statement (ISO 14907-2)
NOTE Under preparation. Stage at the time of publication: ISO/DIS 14907-2:2020.
IETF internet engineering task force
IM interoperability management
IPsec internet protocol security
ISMS information security management system (e.g. ISO/IEC 27001)
LAC localization augmentation communication (ISO 13141)
MAC message authentication code
MAC_TC DSRC message authentication code for toll charger
MAC_TSP DSRC message authentication code for toll service provider
OBE on-board equipment (ISO 14906)
OID object identifier
PKI public key infrastructure
RQ requirement
RSA Rivest, Shamir and Adleman
NOTE RSA is an algorithm for public-key cryptography also referred to as asymmetrical
cryptographic technique.
RSE roadside equipment (ISO 14906)
SAM secure application module
SHA-1 secure hash algorithm (ISO/IEC 10118-3)
SM security measure (countermeasure)
SU service user
SW software
TC toll charger (ISO 17573-1)
TLS transport layer security
TSP toll service provider
TTP trusted third party
VPN virtual private network
5 Trust model
5.1 Overview
The trust model provides the basic trust and functionality for the implementation of authenticated
and secured communication channels among toll service provider (TSP), toll charger (TC) and
interoperability management (IM).
The trust model has two different levels, namely, the contractual framework between the stakeholders
[TC, TSP, and service user (SU)], and the technical trust model between the IT infrastructure of the TC
and TSP.
4 © ISO 2020 – All rights reserved
The trust model assumes that no initial technical trust relation between any of the stakeholders exists
or is provided by a predefined 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:
— between TC and TSP;
— between TSP and SU;
— between TC or TSP and IM.
There is no direct trust relation between TC and service user, as illustrated in Figure 7. The 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 set of several entities performing
different tasks. Issuing rules, regulations, and general user information by the interoperability
management (IM) is performed by means of a trusted relation which is outside of the scope of this
document (dotted arrows in Figure 7). Trust relations between IM and TC or TSP are among others used
for certification of organization or equipment and TTP functions in case this is performed by the IM.
One supported model is an agreement between TC and TSP to use a Trusted Third Party (TTP) (e.g. for
issuing public-key root certificates). Such a relation can include the IM relations to TC and TSP. The TTP
may either be performed as a part of the IM, or external TTP(s) may be used to issue the root certificates.
This document does not require a mandatory TTP in a hierarchical trust model but supports the use of it.
Another supported model is based on an agreement between TC and TSP (direct trust), which is
performed by exchanging self-signed root certificates. Such a peer-to-peer trust relation can also
include the IM relations to TC and TSP. This document does not require a mandatory peer-to-peer trust
model but supports the use of it.
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 document.
5.3 Technical trust model
5.3.1 General
The technical trust model defines the trust relations between the different stakeholders.
5.3.2 Trust model for TC and TSP relations
The technical trust model uses the Rec. ITU-T X.509 (10/2016)∣ ISO/IEC 9594-8 version 3 public-key
and attribute certificate frameworks for establishing secure communication channels. These secure
communication channels ensure confidentiality, integrity, authenticity, and non-repudiation (only with
proof of origin) of the messages exchanged between TC and TSP.
The use of ISO/IEC 9594-8, i.e. using the possibility to import and use in parallel different (self-
signed) root certificates 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 the one hand, and a TTP certification authority (CA)
approach on the other hand.
Figure 8 illustrates an example of a trust model approach which is supported by this document.
Figure 8 — Example of a mixed trust model environment
Figure 8 indicates the possibility of a trust model allowing an entity to participate in a mixed
environment that uses both approaches. The dotted box marked as “hierarchical trust” shows the
trusted third parties in their roles as certification authorities (CA1 and CA2), issuing certificates for
each entity based on its self-signed root certificate imported by the entities. It is also possible that the
TTP CAs directly issue certificates for the technical entities communicating with each other. In this
case, no root certificate would exist and securing all interfaces would be established by bilaterally
accepting self-signed certificates.
A trust relation can also be established across different TTP CAs as indicated by the dotted
...
NORME ISO
INTERNATIONALE 19299
Première édition
2020-08
Perception de télépéage — Cadre de
sécurité
Electronic fee collection — Security framework
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Termes abrégés . 3
5 Modèle de confiance . 5
5.1 Vue d’ensemble . 5
5.2 Relations de confiance entre les parties prenantes . 5
5.3 Modèle de confiance technique . 6
5.3.1 Généralités . 6
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) . 6
5.3.3 Modèle de confiance pour les relations entre le prestataire de services de
péage (TSP) et l’utilisateur du service (SU) . 7
5.3.4 Modèle de confiance pour les relations du gestionnaire de
l’interopérabilité (IM) . 8
5.4 Mise en œuvre. 8
5.4.1 Instauration des relations de confiance . 8
5.4.2 Renouvellement et révocation des relations de confiance . 9
5.4.3 Émission et révocation des certificats de l’autorité de certification (CA)
subordonnée et d’entité finale . 9
5.4.4 Profil et format de certificat et de liste de révocation de certificats (CRL) .10
5.4.5 Extensions de certificat .10
6 Exigences relatives à la sécurité .11
6.1 Généralités .11
6.2 Système de management de la sécurité de l’information (ISMS) .12
6.3 Interfaces de communication .13
6.4 Stockage des données .13
6.5 Percepteur de péage .14
6.6 Prestataire de services de péage .16
6.7 Gestionnaire de l’interopérabilité (IM) .18
6.8 Limitation des exigences .19
7 Mesures de sécurité — Contre-mesures .19
7.1 Vue d’ensemble .19
7.2 Mesures de sécurité générales .19
7.3 Mesures de sécurité relatives aux interfaces de communication .20
7.3.1 Généralités .20
7.3.2 Interface DSRC-EFC .21
7.3.3 Interface CCC .22
7.3.4 Interface LAC .23
7.3.5 Interface entre le système frontal et le système dorsal du prestataire de
services de péage (TSP) .23
7.3.6 Interface entre le TC et le TSP .24
7.3.7 Interface ICC.25
7.4 Mesures de sécurité de bout en bout .26
7.5 Mesures de sécurité relatives au prestataire de services de péage (TSP) .28
7.5.1 Mesures de sécurité relatives au système frontal .28
7.5.2 Mesures de sécurité relatives au système dorsal . .28
7.6 Mesures de sécurité relatives au percepteur de péage (TC) .29
7.6.1 Mesures de sécurité relatives à l’équipement au sol (RSE) .29
7.6.2 Mesures de sécurité relatives au système dorsal . .30
7.6.3 Autres mesures de sécurité relatives au percepteur de péage (TC) .31
8 Spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable .31
8.1 Généralités .31
8.1.1 Sujet .31
8.1.2 Signature et algorithmes de hachage .31
8.2 Spécifications de sécurité relatives à l’interface DSRC-EFC .31
8.2.1 Sujet .31
8.2.2 OBE .31
8.2.3 RSE .32
9 Gestion de clés .32
9.1 Vue d’ensemble .32
9.2 Clés asymétriques .32
9.2.1 Échange de clés entre les parties prenantes .32
9.2.2 Génération et certification de clés .32
9.2.3 Protection des clés .33
9.2.4 Application .33
9.3 Clés symétriques .33
9.3.1 Généralités .33
9.3.2 Échange de clés entre les parties prenantes .34
9.3.3 Cycle de vie des clés .34
9.3.4 Stockage et protection de clé .36
9.3.5 Clés de session .36
Annexe A (normative) Profils de sécurité .37
Annexe B (normative) Formulaire de déclaration de conformité de mise en œuvre (ICS) .42
Annexe C (informative) Objectifs des parties prenantes et exigences génériques .61
Annexe D (informative) Analyse des menaces .66
Annexe E (informative) Politiques de sécurité .132
Annexe F (informative) Exemple de politique de sécurité d’un service européen de
télépéage (SET) .139
Annexe G (informative) Recommandations relatives à une mise en œuvre axée sur la vie
privée .141
Bibliographie .143
iv © ISO 2020 – Tous droits réservés
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 attiré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 nature volontaire des normes, 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’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 204, Systèmes de transport intelligents,
en collaboration avec le comité technique CEN/TC 278, Systèmes de transport intelligents, du Comité
européen de normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le
CEN (Accord de Vienne).
Cette première édition annule et remplace la première édition de l’ISO/TS 19299:2015 qui a fait l’objet
d’une révision technique.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— exigences et mesures de sécurité ajoutées pour l’utilisation de moyens de paiement communs selon
l’ISO/TS 21193;
— mise à jour des considérations relatives à la protection des données en Annexe G, afin de prendre
en compte le nouveau règlement général sur la protection des données (Directive 2016/679/CE) de
l’Union européenne.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html.
Introduction
Contexte du présent document
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 (voir Figure 1):
— 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é.
Figure 1 — Plan de développement des documents de sécurité
Chaque acteur d’un système EFC existant mets en œuvre les mesures de sécurité définies et supervise
leur efficacité. Lorsqu'une mesure de sécurité ne fonctionne pas correctement, un processus
d'amélioration est lancé. Le développement du cadre de sécurité EFC s’attache à suivre cette approche
avec les limitations suivantes:
— Il n’existe aucune politique standard de sécurité et elle ne peut pas non plus être définie: la politique
de sécurité peut seulement être définie par les parties prenantes responsables, et son rayon d’action
est limité par la réglementation et les lois applicables. Néanmoins, le présent document propose
quelques exemples simples des politiques de sécurité possibles (de l’Annexe E à l’Annexe F).
— Aucune évaluation standard des risques n’est possible: l’évaluation des risques compare la perte
possible pour la partie prenante avec les ressources nécessaires (par exemple équipement,
connaissances, temps) à la réalisation d’une attaque. Dans un système réel, l’évaluation des risques
repose sur l’évaluation des coûts et des avantages de chaque contre-mesure.
vi © ISO 2020 – Tous droits réservés
— Aucune conception ou configuration de système spécifique n’a été jugée universellement applicable.
Seules les normes EFC de base disponibles ont été prises comme références. 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 des mesures de sécurité.
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.
Étant 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, le cadre de sécurité EFC propose un ensemble complet (mais non exhaustif)
d’exigences et de mesures de sécurité.
Pour comprendre le contenu du présent document, 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é fiable de bout en bout garantit le fonctionnement précis et fiable des
composants d’interaction des environnements de perception du télé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. Un cadre de sécurité indépendant de l’application pour ces
parties et interfaces, un système de management de la sécurité de l’information (ISMS, Information
Security Management System), peut être trouvé, par exemple, dans la série de normes ISO/IEC 27000.
Le processus d’élaboration du présent document 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-1), 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 de menace du point de vue des agresseurs. La seconde
approche étudie de manière approfondie les menaces à l’égard des différents actifs identifiés
(corporels et incorporels). Cette approche, même si elle introduit une certaine redondance, garantit
l’exhaustivité et la couverture d’un vaste éventail de risques (voir Annexe D).
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, tel que 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 télépéage utilise des
éléments cryptographiques (par exemple clés, certificats, liste de révocation de certificats) 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 du document 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.
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é devrait 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 à la conception d’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 le présent document. La preuve peut être une autodéclaration, un audit interne ou externe,
voire d’autres certifications.
Modèle de rôle EFC
Le présent document satisfait au modèle de rôle défini dans l’ISO 17573-1. Selon ce modèle de rôle, le
percepteur de péage (TC, Toll Charger) gère l’infrastructure de péage ou du service de transport et
est le destinataire des redevances du réseau routier. Le TC est l’acteur associé au rôle Perception du
télépéage (voir Figure 2).
Figure 2 — Modèle de rôle sous-tendant le présent document
Les prestataires de services de péage (TSPs, Toll Service Providers) agissent en tant qu'intermédiaire
entre les TC et les usagers de la route, en fournissant à ces derniers des relations contractuelles et des
dispositifs (généralement des équipements embarqués (OBE, On-Board Equipment) pour interfacer le
service d’infrastructure ou de transport à péage. L’OBE 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. 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 les OBE du TSP. Le rôle de gestionnaire de l’interopérabilité (IM, Interoperability
viii © ISO 2020 – Tous droits réservés
Management) représentée à la Figure 2 inclut toutes les spécifications et activités qui définissent et
maintiennent un ensemble de règles gouvernant l’environnement global de perception du télépéage.
Le modèle de confiance défini dans le présent document est basé sur le modèle de rôle résumé 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 sont essentiels. Un
percepteur de péage (TC) ou un prestataire de services de péage (TSP) en conformité avec le présent
document devrait être capable de fournir une preuve du management de la sécurité exigée. 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 utilisé pour l’analyse des menaces,
et décrit les exigences de sécurité et des mesures de sécurité associées pour le présent document.
Ce document suppose qu’un OBE qui est dédié exclusivement à des fins EFC et ne s’intéresse pas aux
services à valeur ajoutée basés sur un OBE EFC, et ne considère pas non plus que les plateformes OBE
plus génériques (également appelées « stations STI embarquées ») pourraient être utilisées pour
héberger l’application EFC. L’OBE peut soit être connecté à un compte central, soit utiliser un moyen
de paiement tel qu’une carte à puce intégrée (ICC, Integrated Chip Card) ou un paiement mobile pour
un système EFC à compte embarqué. Les transactions financières n’entrent pas dans le domaine
d’application du présent document.
Figure 3 — Modèle de système EFC du cadre de sécurité EFC
Relation avec les autres normes de sécurité
Plusieurs normes génériques et spécifiques et Rapports techniques traitent déjà des problèmes de
sécurité relatifs aux technologies de l’information. Le présent document fait usage de normes existantes
et élargit leur usage aux applications EFC. Ce cadre référence et adapte les techniques et méthodologies
de sécurité découlant de normes pertinentes.
La Figure 4 illustre le contexte du cadre de sécurité EFC par rapport aux normes de sécurité les
plus pertinentes qui ont servi à l’élaboration du présent document. Les normes qui sont utilisées et
référencées directement sont en noir.
x © ISO 2020 – Tous droits réservés
Figure 4 — Normes de sécurité pertinentes dans le contexte du cadre de sécurité EFC
Les normes illustrées à la Figure 4 sont regroupées dans les catégories suivantes, les flèches à l’intérieur
de chaque groupe indiquant quelle norme sert à l’élaboration d’autres normes:
— Techniques de sécurité – Mesures de sécurité et algorithmes: mesures de sécurité essentielles
et algorithmes cryptographiques recommandés, y compris les directives relatives à une utilisation
précise.
— Technologies de l’information – Interconnexion de systèmes ouverts (OSI): fournit les
mécanismes utilisés pour établir des communications sécurisées entre des systèmes ouverts. Ces
normes décrivent quelques-unes des exigences de sécurité dans les domaines de l’authentification
et d’autres services de sécurité en proposant un ensemble de cadres.
— Critères d’évaluation de la sécurité informatique (critères communs): définit des méthodologies
et des processus pour l’évaluation de la sécurité et la certification de la majorité des catégories de
produits utilisés dans l’environnement EFC.
— Technologies de l’information — Techniques de sécurité — Système de management de la
sécurité de l’information (ISMS): définit les exigences et les directives relatives à la mise en œuvre
des systèmes de management de la sécurité pour tous les types d’organisations. Les normes de ce
groupe conviennent aux solutions de sécurité du système dorsal et des autres équipements fixes ou
installés des systèmes EFC, y compris leurs logiciels.
Il est permis d’utiliser une certification ISO/IEC 27001 d’un percepteur de péage (TC) ou d’un
prestataire de services de péage (TSP) pour prouver la conformité au présent document, sous réserve
que le domaine d’application et les déclarations d’applicabilité (SoA, Statement of Applicability)
incluent les processus métier EFC spécifiés dans l’ISO 17573-1 et que les exigences de sécurité et leurs
mesures de sécurité associées fournies par le présent document soient appliquées, par exemple en les
utilisant dans ce que l'on appelle des catalogues, c'est-à-dire des ensembles contenant les mesures de
sécurité et les objectifs de contrôle. La Figure 5 ci-après montre comment cette approche fonctionne
dans deux méthodes parallèles. La première partie des deux méthodes consiste à réaliser une analyse
des processus métiers, suivie d’une analyse des menaces. Une analyse des risques commune combine
l’analyse générique et l’analyse spécifique au système EFC (ainsi que les résultats associés) dans les
mesures et les contrôles de sécurité respectifs.
Figure 5 — Domaine d’application par rapport au système de management de la sécurité de
l’information
En outre, le cadre de sécurité EFC utilise les méthodes existantes d’analyse des menaces ainsi que
l’analyse des menaces existante en rapport avec l’EFC ou les STI, comme par exemple ETSI/TR 102 893.
Le présent document inclut:
— la définition d’un modèle de confiance (voir Article 5): principes et hypothèses de base pour
l’établissement de relations de confiance entre les parties prenantes;
— les exigences de sécurité (voir Article 6): exigences de sécurité relatives à la prise en charge des
mises en œuvre du système EFC actuel;
— les mesures de sécurité — contre-mesures (voir Article 7);
— les spécifications de sécurité relatives à la mise en œuvre d’une interface (voir Article 8): extension
de sécurité aux normes EFC, comme illustré à la Figure 6;
— la gestion de clés (voir Article 9): 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;
— les profils de sécurité (voir Annexe A);
— la déclaration de conformité de la mise en œuvre (voir Annexe B): liste de contrôle devant être
utilisée par un fournisseur d’équipement, un chargé de mise en œuvre d’un système ou un acteur
d’un rôle pour déclarer leur conformité au présent document;
— les objectifs généraux de sécurité de l’information des parties prenantes (voir Annexe C) qui
constituent le principal motif des exigences de sécurité;
— l’analyse des menaces (voir Annexe D) 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;
xii © ISO 2020 – Tous droits réservés
— des exemples de politiques de sécurité (voir Annexe E et Annexe F);
— des recommandations pour une mise en œuvre axée sur la confidentialité (voir Annexe G).
Figure 6 — Domaine d’application du cadre de sécurité EFC pour les communications sécurisées
Ce document n'englobe pas:
— une évaluation complète des risques d’un système EFC;
— les problèmes de sécurité découlant d’une application EFC s’exécutant sur une station STI;
NOTE Les problèmes de sécurité associés à une application EFC s’exécutant sur une station STI sont couverts
dans la CEN/TR 16690.
— la relation de confiance technique entre le TSP et l’utilisateur du service;
— les spécifications pour la mise en œuvre de la sécurité des services EFC spécifiques tel que le Service
Européen de Télépéage [SET];
— les spécifications détaillées nécessaires pour les mises en œuvre EFC respectueuses de la vie privée;
— les transactions financières éventuelles entre le prestataire de services de paiement et le moyen de
paiement tel que l'ICC mis à disposition par ce dernier.
NORME INTERNATIONALE ISO 19299:2020(F)
Perception de télépéage — Cadre de sécurité
1 Domaine d’application
Ce document définit un cadre de sécurité de l'information pour toutes les entités organisationnelles
et techniques d'un système EFC et pour les interfaces correspondantes, sur la base de l'architecture
système définie dans la norme ISO 17573-1. Le cadre de sécurité décrit un ensemble d'exigences de
sécurité et de mesures de sécurité associées.
L'Annexe D contient une liste des menaces potentielles pour les systèmes EFC et une relation possible
avec les exigences de sécurité définies. Ces menaces peuvent être utilisées pour une analyse des
menaces afin d'identifier les exigences de sécurité pertinentes pour un système EFC.
Les mesures de sécurité pertinentes pour sécuriser les systèmes EFC peuvent ensuite être dérivées des
exigences de sécurité identifiées.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 2859-1, Règles d'échantillonnage pour les contrôles par attributs — Partie 1: Procédures
d'échantillonnage pour les contrôles lot par lot, indexés d'après le niveau de qualité acceptable (NQA)
ISO/IEC 7816-3, Cartes d'identification — Cartes à circuit intégré — Partie 3: Cartes à contacts — Interface
électrique et protocoles de transmission
ISO/IEC 8825-1, Technologies de l’information — Règles de codage ASN.1: Spécification des règles de
codage de base (BER), des règles de codage canoniques (CER) et des règles de codage distinctives (DER) —
Partie 1 (disponible en anglais seulement)
ISO/IEC 9594-8:2017, Technologies de l’information — Interconnexion de systèmes ouverts (OSI) —
L’annuaire — Partie 8: Cadre général des certificats de clé publique et d’attribut
ISO/IEC 9797-1:2011, Technologies de l’information — Techniques de sécurité — Codes d’authentification
de message (MAC) — Partie 1: Mécanismes utilisant un chiffrement par blocs
ISO/IEC 11770-1:2010, Technologies de l’information — Techniques de sécurité — Gestion de clés — Partie
1: Cadre général
ISO/IEC 11770-3:2015, Technologies de l’information — Techniques de sécurité — Gestion de clés — Partie
3: Mécanismes utilisant des techniques asymétriques
ISO 12813, Perception de télépéage — Communication de contrôle de conformité pour systèmes autonomes
ISO 12855, Perception du télépéage — Échange d’informations entre la prestation de service et la
perception du péage
ISO 13141, Perception de télépéage — Communications d'augmentation de localisations pour systèmes
autonomes
ISO 14906, Perception du télépéage — Définition de l'interface d'application relative aux communications
dédiées à courte portée
ISO 17575-1, Perception du télépéage — Définition de l'interface d'application pour les systèmes
autonomes — Partie 1: Imputation
ISO/TS 17573-2, Perception de télépéage – Architecture de systèmes pour le péage lié aux véhicules —
Partie 2: Vocabulaire
ISO/IEC 18031, Technologies de l'information — Techniques de sécurité — Génération de bits aléatoires
ISO/IEC 18033-2, Technologies de l'information — Techniques de sécurité — Algorithmes de chiffrement —
Partie 2: Chiffres asymétriques
ISO/IEC 19790, Technologies de l'information — Techniques de sécurité — Exigences de sécurité pour les
modules cryptographiques
EN 15509:2014, Perception de télépéage — Profil d’application d’interopérabilité pour DSRC
CEN/TS 16702-1, Perception du télépéage — Surveillance sécurisée pour systèmes autonomes de péage —
Partie 1: Contrôle de conformité
IETF RFC 4648:2006-10, The Base16, Base32, and Base64 Data Encodings (disponible en anglais seulement)
IETF RFC 5280:2008-05, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile (disponible en anglais seulement)
Federal Information Processing Standards (FIPS) PUB 140-2, December 2002, Security requirements for
cryptographic modules (disponible en anglais seulement)
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO/TS 17573-2 ainsi que les
suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse http:// www .electropedia .org/
3.1
actif
élément ayant de la valeur pour une partie prenante
Note 1 à l'article: un actif peut être corporel ou incorporel.
[SOURCE: ISO/TS 17573-2:2020, 3.9, modifiée - Note 1 à l'article ajoutée]
3.2
autorité de certification
CA (Certification Authority)
autorité habilitée par un ou plusieurs utilisateurs à créer et attribuer les certificats de clé publique
[SOURCE: ISO 21188:2018, 3.21]
3.3
consentement de la personne visée
toute indication écrite informée, spécifique et exprimée librement par laquelle la personne visée signifie
son accord pour le traitement des données personnelles qui lui sont afférentes
2 © ISO 2020 – Tous droits réservés
3.4
contrôle sanction
mesures ou actions appliquées pour imposer le respect de lois, de réglementations ou de règles
Note 1 à l'article: Dans ce contexte, le contrôle sanction est le processus consistant à imposer le respect d’un
régime de péage.
[SOURCE: ISO/TS 17573-2:2020, 3.9, modifiée - Note 1 à l'article ajoutée]
3.5
lot
quantité définie d’articles, livrés ensembleNote 1 à l’article: un lot pour inspection peut être constitué
de plusieurs lots ou parties de lots.
[SOURCE: ISO 2859-1: 1999, 3.1.13, modifiée.]
3.6
politique
intentions et orientation générales d’une organisation telles que formalisées par sa direction
[SOURCE: ISO/IEC 27000:2018, 3.53, modifiée]
3.7
échantillon
ensemble d’un ou de plusieurs articles tirés d’un lot et destinés à fournir des informations sur le lot
[SOURCE: ISO 2859-1: 1999, 3.1.15]
3.8
utilisateur du service
SU (Service User)
terme générique désignant, selon le contexte, le client d’un TSP, tout utilisateur tenu de payer le péage,
le propriétaire du véhicule, l’exploitant d’un parc de véhicules, un conducteur.
4 Termes abrégés
AC_CR identifiants d’accès (ISO 14906)
ADU unité de données d’application
CA autorité de certification (ISO 21188)
CCC communication de contrôle de conformité (ISO 12813)
CN réseau cellulaire
CRL liste de révocation de certificats
DSRC communications dédiées à courte portée (ISO 14906)
EETS service européen de télépéage
EFC perception du télépéage (ISO 17573-1)
GNSS système mondial de navigation par satellite (ISO 17573-1)
HTTP protocole de transfert hypertexte
HTTPS http sur la couche SSL (Secure Socket Layer)
HW matériel
ICC carte à puce intégrée (IC card)
ICS déclaration de conformité de mise en œuvre (ISO/TS 14907-2)
IETF groupe de travail d’ingénierie d’Internet
IM gestion de l’interopérabilité
IPsec sécurité de protocole internet
ISMS système de management de la sécurité de l’information (ISO/IEC 27001)
LAC communications d’augmentation de localisations (ISO 13141)
MAC code d’authentification de message
MAC_TC code d’authentification de message DSRC pour le percepteur de péage
MAC_TSP code d’authentification de message DSRC pour le TSP
OBE équipement embarqué (ISO 14906)
OID identificateur d’objet (Object Identifier)
PKI Infrastructure de clé publique
RQ exigence
RSA Rivest, Shamir et Adleman
NOTE RSA est un algorithme de cryptographie à clé publique, également appelé tech-
nique
cryptographique asymétrique.
RSE équipement au sol (ISO 14906)
SAM module d’application sécurisé
SHA-1 algorithme de hachage sécurisé (ISO/IEC 10118-3)
SM mesure de sécurité (contre-mesure)
SU utilisateur du service
SW logiciel
TC percepteur de péage (ISO 17573-
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.