ETSI TS 102 940 V1.3.1 (2018-04)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Security;
ITS communications security architecture and
security management
2 ETSI TS 102 940 V1.3.1 (2018-04)

Reference
RTS/ITS-00541
Keywords
interoperability, ITS, management, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 940 V1.3.1 (2018-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions, abbreviations and notation . 7
3.1 Definitions . 7
3.2 Abbreviations . 8
3.3 Notation . 8
4 ITS reference architecture . 9
4.1 Background . 9
4.2 ITS applications groups . 10
4.2.1 ITS applications groups and their communication characteristics . 10
4.2.2 Cooperative awareness . 14
4.2.3 Static local hazard warning . 14
4.2.4 Interactive local hazard warning . 15
4.2.5 Area hazard warning . 15
4.2.6 Advertised services . 16
4.2.7 Local high-speed unicast service . 16
4.2.8 Local multicast service . 17
4.2.9 Low-speed unicast service . 17
4.2.10 Distributed (networked) service . 18
4.2.11 Multiple Applications . 18
4.3 Security requirements of ITS application groups . 18
4.3.1 Security requirements of cooperative awareness . 18
4.3.1.1 Authentication and Authorization . 18
4.3.1.2 Confidentiality . 19
4.3.1.3 Privacy . 19
4.3.2 Security requirements of static local hazard warnings . 19
4.3.2.1 Authentication and Authorization . 19
4.3.2.2 Confidentiality and Privacy . 19
4.3.3 Security requirements of interactive local hazard warnings . 19
4.3.3.1 Authentication and Authorization . 19
4.3.3.2 Confidentiality and Privacy . 19
4.3.4 Security requirements of area hazard warnings . 20
4.3.4.1 Authentication and Authorization . 20
4.3.4.2 Confidentiality and Privacy . 20
4.3.5 Security requirements of advertised services . 20
4.3.5.1 Authentication and Authorization . 20
4.3.5.2 Confidentiality and Privacy . 20
4.3.6 Security requirements of other services . 20
4.3.7 Security requirements of multiple applications. 20
4.3.7.1 Authentication and Authorization . 20
4.3.7.2 Confidentiality and Privacy . 20
5 ITS communications security architecture . 21
5.1 ITS station communications security architecture . 21
5.2 Security services . 22
5.3 ITS security functional model . 24
6 ITS station security management . 28
6.1 Basic principles . 28
6.2 Guidelines for establishing enrolment trust requirements . 29
ETSI
4 ETSI TS 102 940 V1.3.1 (2018-04)
6.3 Trust and privacy management . 30
6.4 Access control . 31
6.5 Identity management . 31
6.6 Confidentiality . 32
7 ITS Security management system . 33
7.0 General . 33
7.1 Certificate Trust List/multiple Root CAs . 34
7.2 Root CA . 38
7.3 Enrolment Authority. 39
7.4 Authorization Authority . 39
7.5 Trust List Manager . 40
Annex A (informative): Change history . 41
History . 42

ETSI
5 ETSI TS 102 940 V1.3.1 (2018-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
6 ETSI TS 102 940 V1.3.1 (2018-04)
1 Scope
The present document specifies a security architecture for Intelligent Transport System (ITS) communications. Based
upon the security services defined in ETSI TS 102 731 [4], it identifies the functional entities required to support
security in an ITS environment and the relationships that exist between the entities themselves and the elements of the
ITS reference architecture defined in ETSI EN 302 665 [1].
The present document also identifies the roles and locations of a range of security services for the protection of
transmitted information and the management of essential security parameters. These include identifier and certificate
management, PKI processes and interfaces as well as basic policies and guidelines for trust establishment.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture".
[2] ETSI EN 302 637-2: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set
of Applications; Part 2: Specification of Cooperative Awareness Basic Service".
[3] ETSI EN 302 637-3: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set
of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic
Service".
[4] ETSI TS 102 731: "Intelligent Transport Systems (ITS); Security; Security Services and
Architecture".
[5] ETSI TS 102 941: "Intelligent Transport Systems (ITS); Security; Trust and Privacy
Management".
[6] ETSI TS 102 942: "Intelligent Transport Systems (ITS); Security; Access Control".
[7] ETSI TS 102 943: "Intelligent Transport Systems (ITS); Security; Confidentiality services".
[8] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats".
[9] ETSI TS 103 301: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Facilities layer protocols and communication requirements for infrastructure
services".
[10] ETSI EN 302 636-4-1: "Intelligent Transport Systems (ITS); Vehicular communications;
GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-
multipoint communications; Sub-part 1: Media-Independent Functionality".
ETSI
7 ETSI TS 102 940 V1.3.1 (2018-04)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Definitions".
[i.2] ETSI TR 102 863: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Local Dynamic Map (LDM); Rationale for and guidance on standardization".
[i.3] IEEE 1609.3™ 2010: "Wireless Access in Vehicular Environments (WAVE) - Networking
Services".
[i.4] CEN/TS 16439: "Electronic fee collection - Security framework".
[i.5] ETSI TS 102 890-2: "Intelligent Transport Systems (ITS); Facilities layer function; Part 2:
Position and time facility specification".
[i.6] IETF RFC 4949: "Internet Security Glossary", Version 2, August 2007.
[i.7] ETSI TS 102 723-8: "Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 8: Interface
between security entity and network and transport layer".
[i.8] C-ITS Platform WG5: "Security & Certification Final Report ANNEX 1: Trust models for
Cooperative - Intelligent Transport System (C-ITS)".
[i.9] Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport
Systems (C-ITS), Release 1, June 2017.
NOTE: Available at https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf.
3 Definitions, abbreviations and notation
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI TS 102 731 [4], IETF RFC 4949 [i.6]
and the following apply:
certificate revocation list (CRL): signed list indicating a set of certificates that are no longer considered valid by the
certificate issuer
certificate revocation list for authorities (CRL CA): certificate revocation list issued by a Root CA which contains
only revoked certificates of the subordinate CAs within the hierarchical trust domain managed by the Root CA
certificate trust list: signed list indicating a set of trusted services of a PKI hierarchy controlled by a Root CA or a set
of trusted Root CAs within the C-ITS Trust Domain controlled by a top-level authority (Trust List Manager)
identifier: attribute or a set of attributes of an entity which uniquely identifies the entity within a certain context
security management: operations that support acquiring or establishing the validity of certificates for cooperative ITS
communications
ETSI
8 ETSI TS 102 940 V1.3.1 (2018-04)
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 302 665 [1], ETSI TS 103 301 [9] and
the following apply:
AA Authorization Authority
CA Co-operative Awareness
CAM Co-operative Awareness Message
C-ITS Cooperative Intelligent Transport System
CN Co-operative Navigation
CPOC C-ITS Point Of Contact
CRL Certificate Revocation List
CS Communities Services
CSM Co-operative Speed Management
CCMS Cooperative-ITS security Certificate Management System
DENM Decentralized Environment Notification Message
EA Enrolment Authority
GN GeoNetworking
HSM Hardware Security Module
ID Identity
IP Internet Protocol
IPv6 Internet Protocol version 6
ITS Intelligent Transport System
ITS-S ITS Station
LBS Location Based Services
LCM Life Cycle Management
MAC Medium Access Control
MBD MisBehaviour Detection
OSI Open System Interconnect
PDA Personal Data Appliance
PKI Public Key Infrastructure
RHW Road Hazard Warning
RSU Road Side Unit
SAP Service Access Point
TLM Trust List Manager
UML Unified Modeling Language
WAVE Wireless Access in Vehicular Environments
WSA WAVE Service Announcement
3.3 Notation
The requirements identified in the present document include:
a) mandatory requirements strictly to be followed in order to conform to the present document. Such
requirements are indicated by clauses without any additional marking;
b) requirements strictly to be followed if applicable to the type of ITS Station concerned.
Such requirements are indicated by clauses marked by "[CONDITIONAL]"; and where relevant are marked by an
identifier of the type of ITS-S for which the clauses are applicable as follows:
• [Itss_WithPrivacy] is used to denote requirements applicable to ITS-S for which pseudonymity has to be
assured and re-identification by the AA is not allowed. This includes for instance personal user vehicle ITS-S
or personal ITS-S Portable.
• [Itss_NoPrivacy] is used to denote requirements applicable to ITS-S for which pseudonymity does not have to
be assured and are allowed to be re-identified by the AA. This may be for instance fixed or mobile RSUs or
special vehicles.
ETSI
9 ETSI TS 102 940 V1.3.1 (2018-04)
4 ITS reference architecture
4.1 Background
ETSI EN 302 665 [1] describes an ITS station architecture based upon four processing layers identified as follows:
• Access Layer;
• Networking & Transport Layer;
• Facilities Layer; and
• Applications Layer.
These horizontal layers are bounded on each side by a vertical Management entity and a Security entity (Figure 1).

Figure 1: ITS station architecture (from ETSI EN 302 665 [1])
The layers in this architecture do not represent directly the Open System Interconnect (OSI) protocol modelling layers
but the functionality expected in each can be mapped to OSI model quite simply. Having mapped the OSI protocol
layers to the ITS station architecture, this can be extended into an ITS communications architecture in which the
protocol layers communicate on a peer-to-peer basis as shown in Figure 2.
ETSI
10 ETSI TS 102 940 V1.3.1 (2018-04)

Figure 2: ITS communications architecture
4.2 ITS applications groups
4.2.1 ITS applications groups and their communication characteristics
ETSI TR 102 638 [i.1] defines the basic set of ITS applications which it divides into groups according to the
functionality provided. Based on this a further analysis in ETSI TR 102 863 [i.2] takes into account some additional
sources. The resulting list of functional groupings from this analysis is shown in Table 1. A more detailed description
can be found in ETSI TR 102 863 [i.2], clause A.1.
ETSI
11 ETSI TS 102 940 V1.3.1 (2018-04)
Table 1: ITS application classes
Applications Class Application Use case
Active road safety Driving assistance - Co-operative Awareness (CA) Emergency vehicle warning
Slow vehicle indication
Across traffic turn collision risk warning
Merging Traffic Turn Collision Risk
Warning
Co-operative merging assistance
Intersection collision warning
Co-operative forward collision warning
Lane Change Manoeuvre
Driving assistance - Road Hazard Warning (RHW) Emergency electronic brake lights
Wrong way driving warning
(infrastructure based)
Stationary vehicle - accident
Stationary vehicle - vehicle problem
Traffic condition warning
Signal violation warning
Roadwork warning
Decentralized floating car data -
Hazardous location
Decentralized floating car data -
Precipitations
Decentralized floating car data - Road
adhesion
Decentralized floating car data -
Visibility
Decentralized floating car data - Wind
Vulnerable road user Warning
Pre-crash sensing warning
Co-operative glare reduction
Cooperative traffic Co-operative Speed Management (CSM) Regulatory/contextual speed limits
efficiency notification
Curve Warning
Traffic light optimal speed advisory
Co-operative Navigation (CN) Traffic information and recommended
itinerary
Public transport information
In-vehicle signage
Co-operative local Location Based Services (LBS) Point of Interest notification
services
Automatic access control and parking
management
ITS local electronic commerce
Media downloading
Global internet Communities Services (CS) Insurance and financial services
services
Fleet management
Loading zone management
Theft related services/After theft vehicle
recovery
ITS station Life Cycle Management (LCM) Vehicle software/data provisioning and
update
Vehicle and RSU data calibration
Transport related electronic financial
transactions [i.4]
ETSI
12 ETSI TS 102 940 V1.3.1 (2018-04)
In order to define security classes the communication patterns of the different applications also need to be considered. Table 2 summarizes the communication behaviour of each
application.
Table 2: ITS applications communication behaviour
Use case Addressing Hops Frequency Direction Session
Emergency vehicle warning Broadcast Single High V2V/V2I No
Slow vehicle indication Broadcast Single High V2V No
Across traffic turn collision risk warning Broadcast Single High V2V No
Merging Traffic Turn Collision Risk Warning Broadcast Single High V2V/I2V No
Co-operative merging assistance Broadcast Single High V2V/I2V No
Intersection collision warning Broadcast Single High V2V/I2V No
Co-operative forward collision warning Broadcast Single High V2V No
Lane Change Manoeuvre Broadcast Single High V2V No
Emergency electronic brake lights Broadcast Multi Low V2V No
Wrong way driving warning (infrastructure based) Broadcast Single Low I2V No
Stationary vehicle - accident Broadcast Multi Low V2V/V2I No
Stationary vehicle - vehicle problem Broadcast Multi Low V2V/V2I No
Traffic condition warning Broadcast Multi Low V2V/I2V No
Signal violation warning Broadcast Single High I2V No
Roadwork warning Broadcast Multi Low I2V No
Decentralized floating car data - Hazardous location Broadcast Multi Low V2V/I2V No
Decentralized floating car data - Precipitations Broadcast Multi Low V2V No
Decentralized floating car data - Road adhesion Broadcast Multi Low V2V No
Decentralized floating car data - Visibility Broadcast Multi Low V2V No
Decentralized floating car data - Wind Broadcast Multi Low V2V No
Vulnerable road user Warning Broadcast Single Low V2V/I2V No
Pre-crash sensing warning Indication Broadcast Single High V2V No
Data exchange Unicast Single High V2V Yes
Co-operative glare reduction Broadcast Single Low V2V/I2V No
Regulatory/contextual speed limits notification Broadcast Single Low I2V No
Curve Warning Broadcast Single Medium I2V No
Traffic light optimal speed advisory Broadcast Multi Medium I2V No
Traffic information and Advertisement Broadcast Single Low I2V No
recommended itinerary Service Unicast/Multicast Multi Medium I2V Yes
Advertisement Broadcast Single Low I2V No
Public transport information
Service Multicast Multi Medium I2V Yes
In-vehicle signage Broadcast Single Medium I2V No
Advertisement Broadcast Single Low I2V No
Point of Interest notification
Service Multicast Single Low I2V Yes
ETSI
13 ETSI TS 102 940 V1.3.1 (2018-04)
Use case Addressing Hops Frequency Direction Session
Automatic access control and Advertisement Broadcast Single Low I2V No
parking management
Service Unicast Single Low I2V/V2I Yes
ITS local electronic commerce Unicast Single Low I2V/V2I Yes
Media downloading Unicast Single Low I2V/V2I Yes
Insurance and financial services Unicast Single Low I2V/V2I Yes
Fleet management Unicast Single Low I2V/V2I Yes
Loading zone management Unicast/Multicast Single Low I2V/V2I Yes
Theft related services/After theft vehicle recovery Unicast Multi Low I2V/V2I Yes
Vehicle software/data provisioning and update Unicast Single Low I2V/V2I Yes
Vehicle and RSU data calibration Unicast Single Low I2V/V2I Yes

ETSI
14 ETSI TS 102 940 V1.3.1 (2018-04)
The information in table 2 makes it possible to define a number of ITS application categories, thus:
• cooperative awareness;
• static local hazard warnings;
• interactive local hazard warnings;
• area hazard warnings;
• advertised services;
• local high-speed unicast services;
• local multicast services;
• low-speed unicast services; and
• distributed (networked) services.
These ITS application categories are further defined in clause 4.2.2 to clause 4.2.11.
4.2.2 Cooperative awareness
The purpose of cooperative awareness messages is to allow ITS users to provide other users with information regarding
their status and environment in order to improve road safety. They can be categorized as follows:
• broadcast;
• single-hop;
• time-critical;
• having low data content;
• transmitted frequently;
• vehicle-to-vehicle;
• requiring no established communications session; and
• single message with no explicit coordination.
EXAMPLES: Emergency vehicle warning,
Slow vehicle indication,
Across traffic turn collision risk warning,
Merging traffic turn collision risk warning,
Co-operative merging assistance,
Intersection collision warning,
Co-operative forward collision warning,
Lane change manoeuvre.
4.2.3 Static local hazard warning
Static local hazard warning messages are broadcast by fixed roadside ITS stations usually to provide continuous
information regarding a specific static condition which is relevant to road users. They can be categorized as follows:
• broadcast only from a roadside ITS-S;
• single-hop;
• time-critical;
• having low data content;
ETSI
15 ETSI TS 102 940 V1.3.1 (2018-04)
• transmitted frequently;
• requiring no established communications session; and
• single message with no explicit coordination.
EXAMPLES: Merging traffic turn collision risk warning (if infrastructure-based),
Merging assistance (if infrastructure-based),
Intersection collision warning (if infrastructure-based),
Wrong way driving warning,
Signal violation warning.
Static local hazard warnings differ from cooperative awareness messages only in that they are transmitted by roadside
ITS stations rather than vehicle-based stations. Consequently, they have different requirements for privacy preservation
although all other security requirements are identical.
4.2.4 Interactive local hazard warning
Interactive local hazard warning messages are broadcast followed by a unicast session to provide direct cooperation in
specific hazardous situations. The basic model for these applications is that station A receives a cooperative awareness
message from station B and then returns a message to station B requesting that it takes a particular action. Based on this
there may be additional data exchanges. These exchanges may contain more personal information than is included in
cooperative awareness messages. They can be categorized as follows:
• broadcast followed by unicast;
• single-hop;
• time-critical;
• having low data content;
• transmitted frequently, but only if hazard exists;
• establish unicast communication session; and
• single message followed by coordinated session.
EXAMPLE: Pre-crash sensing warning.
4.2.5 Area hazard warning
Area hazard warning messages are broadcast and then forwarded by the receiving stations to form a geocast. They are
sent event-driven to inform about a specific event or a specific condition to improve road safety. They can be
categorized as follows:
• broadcast;
• multi-hop with geocasting;
• time-critical;
• low data content;
• transmitted frequently, but only when hazard exists;
• requires no established communication session.
EXAMPLES: Emergency electronic brake lights,
Stationary vehicle - accident,
Stationary vehicle - vehicle problem,
Traffic condition warning,
Roadwork warning,
Decentralized floating car data - hazardous location, precipitations, road adhesion, visibility, wind.
ETSI
16 ETSI TS 102 940 V1.3.1 (2018-04)
This category is also known as Decentralized Environmental Notification Messages (DENM) within ETSI.
Area hazard warnings are not sent regularly but only when a special situation or event occurred and are not always
linked to a specific ITS-S as a point of origin. Thus, they cannot usually be used for tracking. Security mechanisms need
to take into account the forwarding of the messages.
4.2.6 Advertised services
Advertised services refer to services where a provider unit sends out a message of a particular type advertising that the
service is being offered and an ITS-S with the corresponding user application connects to the service. This description is
based on WAVE Service Announcements (WSAs) as described in IEEE 1609.3 [i.3] but does not preclude any
alternative method of providing Service Announcements including ETSI Facilities service announcement ETSI
TS 102 890-2 [i.5].
Advertisements are not application messages themselves, though they may contain information allowing the user
application to decide whether to connect. For example, a service advertisement for entertainment services might contain
an identifier for the media provider.
They are broadcast as unencrypted messages and usually sent multiple times a second. They can be categorized as
follows:
• broadcast by a service provider;
• single-hop;
• not time-critical;
• low data content;
• sent regularly to announce service;
• may be responded to in order to start a unicast session or enter a multicast session.
EXAMPLES: Public transport information (advertisement),
Traffic information and recommended itinerary (advertisement),
Point of interest notification (advertisement),
Automatic access control and parking management,
Media downloading (advertisement).
In many cases, the responding ITS-S will be associated with an end-user vehicle with a strong expectation of privacy.
4.2.7 Local high-speed unicast service
Local high-speed unicast services are provided directly to vehicles that may be moving at a high speed. They can be
categorized as:
• unicast;
• single-hop;
• time critical;
• medium data content;
• frequently advertised then used as needed;
• local sessions.
EXAMPLE: Traffic information and recommended itinerary (service).
ETSI
17 ETSI TS 102 940 V1.3.1 (2018-04)
4.2.8 Local multicast service
Local multicast services are similar to local unicast service but using multicast communication. They can therefore be
categorized as:
• multicast;
• single-hop;
• time critical;
• medium data content;
• frequently advertised then used as needed;
• local sessions.
EXAMPLES: Traffic information and recommended itinerary (service),
Public transport information (service),
Point of interest notification (service).
The distinguishing features of this type of service are that:
a) information is broadcast to the subscribers - it is in general non-interactive;
b) the service provider may want to provide the service to some but not all of the vehicles in a particular RSU's
communication zone or in a particular larger region.
4.2.9 Low-speed unicast service
Low-speed unicast services are non time-critical services consumed at low (vehicle) speeds. They can be categorized as:
• unicast;
• single-hop;
• low time-criticality;
• medium to large data content;
• low frequency;
• restricted local or remote session.
EXAMPLES: ITS local electronic commerce,
Media downloading,
Insurance and financial services,
Fleet management,
Loading zone management,
Vehicle software/data provisioning and update,
Vehicle and RSU data calibration.
These services differ from high-speed unicast services in that the off-vehicle end of the communications session may be
remote over the network. The application cannot rely on rapid exchange of large amounts of information and will have
higher latency than the high-speed unicast service.
In general, these services will use an IP connection and so the use of existing IP security mechanisms may be
appropriate.
NOTE: In general for ITS IP connections IPv6 will be used although the present document does not disallow any
other variant of IP.
ETSI
18 ETSI TS 102 940 V1.3.1 (2018-04)
4.2.10 Distributed (networked) service
Distributed services are non-time critical subscription services that are intended to be consumed by the user over long
periods such as the duration of a journey or even the lifetime of a vehicle. They can be categorized as:
• unicast;
• single-hop;
• low time-criticality;
• medium to large data content;
• low frequency;
• persistent remote session.
EXAMPLE: Real-time traffic information.
This service is similar to the low-speed unicast service in that it involves connecting with a service provider across a
network. However, the difference is that the logical communication session needs to persist across multiple connections
between the ITS-S and the roadside infrastructure. The persistence may be provided at the application level, the
transport layer, or the internet layer.
4.2.11 Multiple Applications
An ITS-S may run multiple applications. Each application will have its own security requirements as described above.
However, the combination of applications may introduce additional threats to the communications security, such as:
• Privacy - the combination of applications that an ITS-S runs may act as an identifier.
• Availability - one application may consume resources needed by another application.
These issues are mainly handled by mechanisms in the ITS-S before messages are transmitted (see clause 6).
4.3 Security requirements of ITS application groups
4.3.1 Security requirements of cooperative awareness
4.3.1.1 Authentication and Authorization
Cooperative awareness applications are used to enhance traffic safety. In addition to authenticity and integrity,
authorization is required in order to restrict access to legitimate users. Different levels of authentication may be needed
depending on the application and the requirements for participation. Consequently, authorization may depend on status
(e.g. vehicle priority), properties (e.g. sensor equipment, implementation, vehicle type) or subscription to a chargeable
service (e.g. personalized route guidance).
In general, authentication is required for applications that intend to send messages over the network. Thus, for CAM
this may be a central service (on the ITS-S) that may be called by the single applications.
There are several classes of CAM authorization:
• Basic CAM authorization:
- linked to basic data such as length, width, speed, heading, acceleration and brake status;
- granted to all enrolled ITS stations to enable participation in the basic ITS.
• Advanced CAM authorization:
- contains additional information such as that required for across traffic turning, merging assistance and
collision warning;
ETSI
19 ETSI TS 102 940 V1.3.1 (2018-04)
- depends on the abilities of the sending station such as the cryptographic algorithms implemented, its
sensors and its perceived trustworthiness.
• Authorization to claim priority rights for emergency vehicles:
- granted only to specially authorized emergency vehicles or public transport vehicles according to
national legislation. Multiple layers of priority may be defined, for example priority for emergency
vehicles and on a lower level authorization to use a special lane reserved for public transportation;
- granted by a governmental organization or its authorized proxy agency;
- priority rights asserted by the user during operation, not during authorization.
• Authorization to state regulatory orders such as speed limits and road closures:
- granted only to specially authorized ITS stations such as RSUs and police vehicles;
- granted by a governmental organization or its authorized proxy agency.
4.3.1.2 Confidentiality
As CAMs are broadcasts to any possible receiver there are no confidentiality requirements.
4.3.1.3 Privacy
CAMs are sent periodically up to several times a second by every ITS-S. They contain substantial status information
(e.g. location) relating to the sending ITS-S. Consequently, it is necessary to ensure that the data cannot be linked to any
individual so that no personally identifying information is leaked by the CAM service. Details to security mechanisms
and policies provided to protect privacy are given in ETSI TS 102 941 [5].
4.3.2 Security requirements of static local hazard warnings
4.3.2.1 Authentication and Authorization
Static local hazard warnings have very similar properties than the CAM service with the exemption that they are sent by
RSUs. For Authentication and Authorization similar requirements as for CAM apply with the addition, that
authorization should be limited to the specific purpose, functionality, and location of the respective RSU.
4.3.2.2 Confidentiality and Privacy
As the nature of the service is broadcast and the sender is a static RSU, no confidentiality or privacy requirements
apply.
4.3.3 Security requirements of interactive local hazard warnings
4.3.3.1 Authentication and Authorization
In general the requirements for Authorization and Authentication are similar to CAM. In the subsequent unicast session
the local policies of the participating partners may require additional authorization and/or authentication. These
additional requirements are out of the scope of the present document.
4.3.3.2 Confidentiality and Privacy
The requirements for Confidentiality and Privacy depend heavily on the specific application and the information to be
exchanged. The unicast session may contain more privacy related and personally identifying information so that
confidentiality may be an issue but this is likely to be solved within the application or bilaterally between involved
parties. These requirements are, thus, out of scope of the present document.
ETSI
20 ETSI TS 102 940 V1.3.1 (2018-04)
4.3.4 Security requirements of area hazard warnings
4.3.4.1 Authentication and Authorization
Authorization for area hazard warnings (Decentralized Environment Notification Message, DENM) could be granted on
several levels depending on sensor equipment, sensor quality and
...