ETSI TS 102 723-9 V1.1.1 (2021-03)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
OSI cross-layer topics;
Part 9: Interface between security entity and facilities layer

2 ETSI TS 102 723-9 V1.1.1 (2021-03)

Reference
DTS/ITS-00553
Keywords
adaption, addressing, interface, ITS, 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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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 2021.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 723-9 V1.1.1 (2021-03)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 8
2 References . 8
2.1 Normative references . 8
2.2 Informative references . 8
3 Definition of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Architecture . 10
4.1 General . 10
4.1.1 Introduction. 10
4.1.2 Vertical message flow . 10
4.1.3 Horizontal control communication . 11
4.1.4 Protocol work split . 12
4.1.5 Multiple instances . 12
4.1.6 Error handling . 12
4.2 Security services . 12
5 Interfaces between the Security entity and the Facilities layer . 13
5.1 Interface services . 13
5.2 Service primitives and parameters . 14
5.2.1 SF-SIGN . 14
5.2.1.1 Description . 14
5.2.1.2 SF-SIGN.request . 14
5.2.1.3 SF-SIGN.confirm . 15
5.2.2 SF-VERIFY . 15
5.2.2.1 Description . 15
5.2.2.2 SF-VERIFY.request . 15
5.2.2.3 SF-VERIFY.confirm . 15
5.2.3 SF-ENCRYPT . 16
5.2.3.1 Description . 16
5.2.3.2 SF-ENCRYPT.request . 16
5.2.3.3 SF-ENCRYPT.confirm . 17
5.2.4 SF-DECRYPT . 17
5.2.4.1 Description . 17
5.2.4.2 SF-DECRYPT.request . 17
5.2.4.3 SF-DECRYPT.confirm . 17
5.2.5 SF-IDCHANGE-SUBSCRIBE . 17
5.2.5.1 Description . 17
5.2.5.2 SF-IDCHANGE-SUBSCRIBE.request . 18
5.2.5.3 SF-IDCHANGE-SUBSCRIBE.confirm. 18
5.2.6 SF-IDCHANGE-EVENT . 18
5.2.6.1 Description . 18
5.2.6.2 SF-IDCHANGE-EVENT.indication . 18
5.2.6.3 SF-IDCHANGE-EVENT.response . 18
5.2.7 SF-IDCHANGE-UNSUBSCRIBE . 19
5.2.7.1 Description . 19
5.2.7.2 SF-IDCHANGE-UNSUBSCRIBE.request . 19
5.2.7.3 SF-IDCHANGE-UNSUBSCRIBE.confirm . 19
5.2.8 SF-IDCHANGE-TRIGGER . 19
ETSI
4 ETSI TS 102 723-9 V1.1.1 (2021-03)
5.2.8.1 Description . 19
5.2.8.2 SF-IDCHANGE-TRIGGER.request . 19
5.2.8.3 SF-IDCHANGE-TRIGGER.confirm . 19
5.2.9 SF-ID-LOCK . 20
5.2.9.1 Description . 20
5.2.9.2 SF-ID-LOCK.request . 20
5.2.9.3 SF-ID-LOCK.confirm . 20
5.2.10 SF-ID-UNLOCK . 20
5.2.10.1 Description . 20
5.2.10.2 SF-ID-UNLOCK.request . 20
5.2.10.3 SF-ID-UNLOCK.confirm . 20
5.2.11 SF-LOG-SECURITY-EVENT . 21
5.2.11.1 Description . 21
5.2.11.2 SF-LOG-SECURITY-EVENT.request message example . 21
5.2.11.3 SF-LOG-SECURITY-EVENT.confirm message example . 23
5.2.12 SF-ENCAP . 23
5.2.12.1 Description . 23
5.2.12.2 SF-ENCAP.request . 23
5.2.12.3 SF-ENCAP.confirm . 24
5.2.13 SF-DECAP . 24
5.2.13.1 Description . 24
5.2.13.2 SF-DECAP.request . 24
5.2.13.3 SF-DECAP.confirm . 25
6 SF-SAP procedures . 25
6.1 Outbound message handling. 25
6.1.1 Using SF-SIGN, SF-ENCRYPT . 25
6.1.2 Using SF-ENCAP . 26
6.2 Inbound message handling . 26
6.2.1 Using SF-VERIFY and SF-DECRYPT . 26
6.2.2 Using SF-DECAP . 27
6.3 ID Management . 27
6.3.1 IDCHANGE Notifications . 27
6.3.1.1 Introduction . 27
6.3.1.2 Id-change event hook . 28
6.3.1.3 Two phase commit process . 28
6.3.2 Prevent IDCHANGES . 30
6.3.3 Trigger IDCHANGES . 31
6.4 Log security event . 31
Annex A (informative): SF-Command . 32
A.1 Overview . 32
A.2 Description . 32
A.2.1 SF-IDCHANGE-EVENT service: SF-COMMAND.request (see clause 5.2.6.2) . 32
A.2.2 SF-IDCHANGE-EVENT service: SF-COMMAND.confirm (see clause 5.2.6.3) . 33
Annex B (informative): SF-Request . 34
B.1 Overview . 34
B.2 Description . 34
B.2.1 SF-ENCRYPT service: SF-REQUEST.request (see clause 5.2.3.2) . 34
B.2.2 SF-ENCRYPT service: SF-REQUEST.confirm (see clause 5.2.3.3) . 35
Annex C (informative): Example of service primitives description in the framework of
ISO 24102-3 . 36
C.1 Introduction . 36
C.2 Class for SF-SAP Command.request service primitive functions . 36
C.3 Class for SF-SAP Command.confirm service primitive functions . 36
ETSI
5 ETSI TS 102 723-9 V1.1.1 (2021-03)
C.4 Class for SF-SAP Request.request service primitive functions . 37
C.5 Class for SF-SAP Request.confirm service primitive functions . 37
History . 38

ETSI
6 ETSI TS 102 723-9 V1.1.1 (2021-03)
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).
The present document is part 9 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.2].
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.
Introduction
The communications architecture standard ETSI EN 302 665 [i.1], clause 4.4 describes the reference architecture of ITS
station, which includes the following internal functional blocks:
• ITS-S Access layer;
• ITS-S Networking & Transport layer;
• ITS-S Facilities layer;
• ITS-S Applications;
• ITS-S Management entity;
• ITS-S Security entity;
and the interfaces between these blocks.
ETSI
7 ETSI TS 102 723-9 V1.1.1 (2021-03)
The present document specifies interfaces between the security entity and facilities layer of ITS-S from a functional
point of view. Access control to the Service Access Point and further definitions of station internal signals are out of
scope of the present document.
The SAP specification is specific to the ITS architecture but generic to the concrete technologies used.
The present document is structured in the following way:
• First, the architecture integration is outlined.
• Secondly, functionalities are collected from related standards and mapped to service primitives.
• Finally, the use of service primitives in procedures is described.
ETSI
8 ETSI TS 102 723-9 V1.1.1 (2021-03)
1 Scope
The present document specifies interfaces between the ITS Security entity and the ITS Facilities layer including
interface services and service primitives which are extensible in order to achieve general applicability. Additionally, it
specifies related procedures and common parameters.
The SF-SAP description in the present document is from a functional point of view according to the ISO model
modified by ETSI EN 302 665 [i.1].
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 TS 102 940: "Intelligent Transport Systems (ITS); Security; ITS communications security
architecture and security management".
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 EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture".
[i.2] ETSI TS 102 723-1: "Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 1:
Architecture and addressing schemes".
[i.3] ISO 24102-3: "Intelligent transport systems -- Communications access for land mobiles (CALM) -
- ITS station management -- Part 3: Service access points".
[i.4] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats".
[i.5] ETSI TS 102 637-1: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set
of Applications; Part 1: Functional Requirements".
[i.6] ETSI TS 101 539-2: "Intelligent Transport Systems (ITS); V2X Applications; Part 2: Intersection
Collision Risk Warning (ICRW) application requirements specification".
[i.7] ETSI TS 101 539-3: "Intelligent Transport Systems (ITS); V2X Applications; Part 3: Longitudinal
Collision Risk Warning (LCRW) application requirements specification".
ETSI
9 ETSI TS 102 723-9 V1.1.1 (2021-03)
[i.8] PRESERVE Deliverable D1.3: "V2X Security Architecture V2", January 2014.
NOTE: Available at https://www.preserve-project.eu/www.preserve-project.eu/sites/preserve-
project.eu/files/PRESERVE-D1.3-V2X_Security_Architecture_V2.pdf.
[i.9] H. Schweppe, B. Weyl, Y. Roudier, M.S. Idrees, T. Gendrullis, M. Wolf: "Securing car2X
applications with effective hardware-software co-design for vehicular on-board networks".
th
In 27 Joint VDI/VW Automotive Security Conference, Berlin, Germany, October 2011.
VDI Berichte 2131.
NOTE: Available at https://evita-project.org/Publications/SGIR11.pdf.
[i.10] ETSI EN 302 663: "Intelligent Transport Systems (ITS); ITS-G5 Access layer specification for
Intelligent Transport Systems operating in the 5 GHz frequency band".
[i.11] ETSI EN 303 613: "Intelligent Transport Systems (ITS); LTE-V2X Access layer specification for
Intelligent Transport Systems operating in the 5 GHz frequency band".
[i.12] ETSI TS 101 539-1: "Intelligent Transport Systems (ITS); V2X Applications; Part 1: Road Hazard
Signalling (RHS) application requirements specification".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI EN 302 665 [i.1], ETSI TS 102 940 [1] and the
following apply:
security association: addressing information and 'security material' for connecting to the 'security management entity'
NOTE: This corresponds to 'enrolment authorities' and 'authorization authorities'.
security entity: functional entity inside an ITS station which offers 'security mechanisms'
security protocol: protocol used to encode and decode 'security material' and messages between ITS Stations
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI EN 302 665 [i.1], ETSI TS 102 940 [1] and
the following apply:
SAP Service Access Point
SF-SAP Security entity - Facilities layer SAP
ETSI
10 ETSI TS 102 723-9 V1.1.1 (2021-03)
4 Architecture
4.1 General
4.1.1 Introduction
Figure 1 shows the ITS station reference architecture, as defined in ETSI EN 302 665 [i.1]. The present document
contains the specification of the Service Access Points (SAP), connecting the security entity and the facilities layer,
i.e. SF-SAP.
Figure 1: ITS station reference architecture
Interaction between the security entity and the layers may follow two principles. First, the vertical message flow
through the layers from top to bottom or vice versa. Secondly, the horizontal control communication from the security
entity towards the corresponding layer. Both are described in clauses 4.1.2 and 4.1.3.
4.1.2 Vertical message flow
Figure 2 extends the ITS station reference architecture by illustrating the overall information flow through the layers,
from originating application on the left hand side, to the receiving application on the right hand side.

Figure 2: TX (left) and RX (right) information flow through the ITS station
ETSI
11 ETSI TS 102 723-9 V1.1.1 (2021-03)
The present document specifies only the SF-SAP, therefore only a subset of the ITS station reference architecture has to
be taken into account. Figure 3 shows the typical information flow between any sending (TX) and receiving (RX) party,
with regard to the SF-SAP only. The Security entity acts like a layer inside the Facilities layer, i.e. it is called during the
processing of messages traversing the Facilities layer. The security entity will however not act as a layer above or below
the Facilities layer. This means that interactions with Applications and Network & Transport layers are achieved via
other means, i.e. the FA-SAP is used for the interaction between the Facilities and Applications layers, whereas the
NF-SAP is used for the interaction between the Networking & Transport layers and Facilities layers.

Figure 3: SF-SAP centric Information flow
4.1.3 Horizontal control communication
Figure 4 outlines the second communication principle. There is a horizontal control communication between the
security entity and the corresponding communications layer, facilities layer in this case. This is needed for the ID
change functionality introduced later. In general, the security entity will be able to indicate an ID change to the
corresponding layer and some additional ID change related calls.

Figure 4: Horizontal Control Communication
ETSI
12 ETSI TS 102 723-9 V1.1.1 (2021-03)
4.1.4 Protocol work split
The SF-SAP provides a set of primitive Security functions to the Facilities layer.
Figure 5 shows how a protocol entity within the Facilities layer handles the sending and receiving of information but
uses some security extensions to invoke the primitive functions of the Security entity in order to meet the security
requirements of this layer. They are supported by the Identity Management Capabilities, specified in ETSI
TS 102 940 [1], clause 6, necessary to apply the Atomic Security Capabilities.

Figure 5: Protocol work split
4.1.5 Multiple instances
The present document does not discuss architecture. However, the SF-SAP can support different permissions. The
management of different credential sets at the same time can be implemented by using multiple instances of the
Security entity at the same time. Different or same components in the Facilities layer might use multiple instances of the
Security entity using the service primitives described in clause 5. Handling and access control of those is out of scope of
the present document.
4.1.6 Error handling
The present document does not make assumptions on implementation specific error handling for using the described
services. This means that, if a call of any of the described services fails for some reason, the present document does not
specify if this should be handled using exceptions or any other error handling technique.
However, the present document does specify the behaviour of services that can have a positive or negative result. For
instance, a SF-VERIFY can be SUCCESSFUL if the verification was successful or it can be unsuccessful, if the
signature was invalid (FALSE_SIGNATURE). This is considered to be within normal operation conditions, and
therefore not an error.
4.2 Security services
The required ITS security services are identified as the first level security services in ETSI TS 102 940 [1], clause 5.2.
In addition to those, security services used in the research projects PRE-DRIVE C2X and EVITA were adopted and
fitted to the existing services. See PRESERVE Deliverable D1.3 [i.8] and [i.9] for documentation on the research
project services.
Table 1 summarizes the security services to be specified in the present document, clause 5. These security services shall
be invoked directly by applications or other components and layers according to ETSI TS 102 940 [1]. A "security
service group" is introduced to ease the readability of the table.
ETSI
13 ETSI TS 102 723-9 V1.1.1 (2021-03)
Table 1: Security Service to Service Implementation Assignment
Security Service Security Service Name Type/Direction Implemented by (clause 5)
Group
Confidentiality Encrypt Single Message Request SF-ENCRYPT
Decrypt Single Message Request SF-DECRYPT
Authentication and Authorize Single Message Request SF-SIGN
Integrity Validate Authorization on Request SF-VERIFY
Single Message
Identity Management Lock ID Change Request SF-ID-LOCK
Unlock ID Change Request SF-ID-UNLOCK
Subscribe to ID Change Request SF-IDCHANGE-SUBSCRIBE
Notification
Unsubscribe from ID Request SF-IDCHANGE-
Change Notification UNSUBSCRIBE
Change ID Indication send to subscribed SF-IDCHANGE-EVENT
entities
Trigger ID Change Request SF-IDCHANGE-TRIGGER
Extras Log Security Event Request SF-LOG-SECURITY-EVENT
Extract Permissions Request SF-EXTRACT-PERMISSIONS
Encapsulate Message Request SF-ENCAP
Decapsulate Message Request SF-DECAP

5 Interfaces between the Security entity and the
Facilities layer
5.1 Interface services
The following services for the SF-SAP are defined in the present document:
• SF-SIGN
Create authentication information for outgoing ITS messages
• SF-VERIFY
Validate authentication information from incoming ITS messages
• SF-ENCRYPT
Encrypt outgoing ITS single messages
• SF-DECRYPT
Decrypt incoming ITS single messages
• SF-IDCHANGE-SUBSCRIBE
Subscribe for notifications on SF-IDCHANGE-EVENT, used for concurrent identifiers exchange across the
ITS-S
• SF-IDCHANGE-EVENT
The indication sent to subscribers on IDCHANGE
• SF-IDCHANGE-UNSUBSCRIBE
Unsubscribe for IDCHANGE notifications, cf. SF-IDCHANGE-EVENT
• SF-IDCHANGE-TRIGGER
Ask security entity to trigger IDCHANGE procedure
• SF-ID-LOCK
Ask security entity to avoid IDCHANGEs
• SF-ID-UNLOCK
Release SF-ID-LOCK
ETSI
14 ETSI TS 102 723-9 V1.1.1 (2021-03)
• SF-LOG-SECURITY-EVENT
Insert external security events
• SF-ENCAP
Encapsulate outbound messages in a security envelope. This is an alternative way of calling the same
functionality that SF-SIGN and/or SF-ENCRYPT offer, where the security parameter selection is done via a
security profile parameter or security entity pre-sets
• SF-DECAP
Decapsulate inbound messages from a security envelope. This is an alternative way of calling the same
functionality that SF-VERIFY and/or SF-DECRYPT offer, and should be used together with SF-ENCAP
5.2 Service primitives and parameters
5.2.1 SF-SIGN
5.2.1.1 Description
The service adds authentication information to the message. Key and identity management is internal to the security
entity. Format of the created security header is dependent on the selected security protocol. The key to use is expected
to be selected by the key and identity management of the security entity. Nevertheless, it is optionally possible to
indicate the key to use via the key_handle parameter.
5.2.1.2 SF-SIGN.request
SF-SIGN.request is sent from the Facilities layer to the Security entity for executing the SIGN service. The parameters
shall be as described in Table 2.
Table 2: SF-SIGN.request
Name Type Valid range Description Status
tbs_message_length INTEGER Length of the message Mandatory
0 to 2 - 1
to be signed
tbs_message OCTET STRING tbs_message_length Octet string containing Mandatory
octets the message to be
signed
its_aid INTEGER ANY ITS-AID of the Mandatory
application payload or
Facilities management
packet to determine the
security profile to apply
permissions_length INTEGER Length of the Mandatory
0 to 2 - 1
permissions
Permissions OCTET STRING Maximum length of Specify the sender's Mandatory
31 octets permissions for the
security entity to decide
which key to use. For
example, when using
ETSI TS 103 097 [i.4]
security protocol, the
permissions contain the
SSP associated with
ITS-AID
context_information OCTET STRING ANY Context information Optional
which could be used in
selecting properties of
the underlying security
protocol for various
purposes
key_handle INTEGER An indicator for the Optional
0 to 2 - 1
security entity to decide
which key to use
ETSI
15 ETSI TS 102 723-9 V1.1.1 (2021-03)
5.2.1.3 SF-SIGN.confirm
SF-SIGN.confirm is sent from the Security entity to the Facilities layer as a corresponding reply to SF-SIGN.request.
The parameters shall be as described in Table 3.
Table 3: SF-SIGN.confirm
Name Type Valid range Description Status
sec_message_length INTEGER Length of the signed Mandatory
0 to 2 - 1
message
sec_message OCTET STRING sec_message_length Octet string of the Mandatory
octets signed message
5.2.2 SF-VERIFY
5.2.2.1 Description
The service verifies the validity of the digital signature and meta information contained in the security header. Its
format, specification, and features are dependent on the selected security protocol.
5.2.2.2 SF-VERIFY.request
SF-VERIFY.request is sent from the Facilities layer to the Security entity for executing the VERIFY service. The
parameters shall be as described in Table 4.
Table 4: SF-VERIFY.request
Name Type Valid range Description Status
sec_header_length INTEGER Length of the security Mandatory
0 to 2 - 1
header
sec_header OCTET STRING sec_header_length octets Octet string containing the Mandatory
security header
message_length INTEGER Length of the message to Mandatory
0 to 2 - 1
be verified
message OCTET STRING message_length octets Octet string containing the Mandatory
message to be verified
5.2.2.3 SF-VERIFY.confirm
SF-VERIFY.confirm is sent from the Security entity to the Facilities layer as a corresponding reply to SF-
VERIFY.request. The parameters shall be as described in Table 5.
ETSI
16 ETSI TS 102 723-9 V1.1.1 (2021-03)
Table 5: SF-VERIFY.confirm
Name Type Valid range Description Status
report INTEGER VERIFY return code: Mandatory
0 to 2 - 1
SUCCESS
FALSE_SIGNATURE
INVALID_CERTIFICATE
REVOKED_CERTIFICATE
INCONSISTENT_CHAIN
INVALID_TIMESTAMP
DUPLICATE_MESSAGE
INVALID_MOBILITY_DATA
UNSIGNED_MESSAGE
SIGNER_CERTIFICATE_NOT_FOUND
UNSUPPORTED_SIGNER_IDENTIFIER_TYPE
INCOMPATIBLE_PROTOCOL
certificate_id OCTET 8 octets Identification of the source certificate, e.g. by the Optional
STRING certificate hash
its_aid_length INTEGER Length of the its_aid field Mandatory
0 to 2 - 1
its_aid INTEGER ANY ITS-AID of the application payload or Facilities Mandatory
management packet to determine the security
profile to apply
permissions OCTET Maximum In case the used security protocol is capable of Mandatory
STRING length of attaching senders permissions, verify may report
31 octets those back to the caller. The definition is
dependent on the applied security protocol.
For example, when using ETSI TS 103 097 [i.4]
security protocol, the permissions contain the
SSP associated with ITS-AID
5.2.3 SF-ENCRYPT
5.2.3.1 Description
This service encrypts message for specific recipients. The designated recipient has to be known to the security entity.
Therefore, an identifier is required to indicate the recipient. An internal mapping of target_id to certificate_id shall be
possible, to select the proper target key.
5.2.3.2 SF-ENCRYPT.request
SF-ENCRYPT.request is sent from the Facilities layer to the Security entity for executing the ENCRYPT service. The
parameters shall be as described in Table 6.
Table 6: SF-ENCRYPT.request
Name Type Valid range Description Status
tbe_payload_length INTEGER Length of the payload to be Mandatory
0 to 2 - 1
encrypted
tbe_payload OCTET STRING tbe_payload_length Octet string of the Payload Mandatory
octets to be encrypted
target_id_list_length INTEGER Length of the target_id_list Mandatory
0 to 2 - 1
target_id_list SET OF OCTET target_id_list_length Unordered collection of Mandatory
STRING elements each of target IDs, for specifying
8 octets multiple recipients
context_information OCTET STRING ANY Context information which Optional
could be used in selecting
properties of the underlying
security protocol for
various purposes
ETSI
17 ETSI TS 102 723-9 V1.1.1 (2021-03)
5.2.3.3 SF-ENCRYPT.confirm
SF-ENCRYPT.confirm is sent from the Security entity to the Facilities layer as a corresponding reply to SF-
ENCRYPT.request. The parameters shall be as described in Table 7.
Table 7: SF-ENCRYPT.confirm
Name Type Valid range Description Status
encrypted_message_length INTEGER Length of the Mandatory
0 to 2 - 1
encrypted_message
encrypted_message OCTET STRING encrypted_message_length Octet string of the Mandatory
octets encrypted_message
5.2.4 SF-DECRYPT
5.2.4.1 Description
This services decrypts messages, which were encrypted using the ENCRYPT service.
5.2.4.2 SF-DECRYPT.request
SF-DECRYPT.request is sent from the Facilities layer to the Security entity for executing the DECRYPT service. The
parameters shall be as described in Table 8.
Table 8: SF-DECRYPT.request
Name Type Valid range Description Status
encrypted_message_length INTEGER Length of the Mandatory
0 to 2 - 1
encrypted_message
encrypted_message OCTET STRING encrypted_message_length Octet string of the Mandatory
octets encrypted_message
5.2.4.3 SF-DECRYPT.confirm
SF-DECRYPT.confirm is sent from the Security entity to the Facilities layer as a corresponding reply to SF-
DECRYPT.request. The parameters shall be as described in Table 9.
Table 9: SF-DECRYPT.confirm
Name Type Valid range Description Status
plaintext_message_length INTEGER Length of the decrypted Mandatory
0 to 2 - 1
message
plaintext_message OCTET plaintext_message_length Octet string containing the Mandatory
STRING octets decrypted message
report INTEGER Decrypt return code: Mandatory
0 to 2 - 1
SUCCESS
UNENCRYPTED_MESSAGE
DECRYPTION_ERROR
INCOMPATIBLE_PROTOCOL
5.2.5 SF-IDCHANGE-SUBSCRIBE
5.2.5.1 Description
Subscription for notifications on IDCHANGE, used for concurrent identifiers exchange across the ITS-S.
ETSI
18 ETSI TS 102 723-9 V1.1.1 (2021-03)
5.2.5.2 SF-IDCHANGE-SUBSCRIBE.request
SF-IDCHANGE-SUBSCRIBE.request is sent from the Facilties layer to the Security entity for executing the
IDCHANGE-SUBSCRIBE service. The parameters shall be as described in Table 10.
Table 10: SF-IDCHANGE-SUBSCRIBE.request
Name Type Valid range Description Status
idchange_event_hook Not applicable in ASN.1 Not applicable in Callback function, which is Mandatory
ASN.1 called when an ID-change
event occurs. The signature
of the hook function is
specified in clause 5.2.6
subscriber_data OCTET STRING ANY Additional parameter for Optional
callback function internal
use. This will be passed to
the hook function on every
call
5.2.5.3 SF-IDCHANGE-SUBSCRIBE.confirm
SF-IDCHANGE-SUBSCRIBE.confirm is sent from the Security entity to the Facilities layer as a corresponding reply to
SF-IDCHANGE-SUBSCRIBE.request. The parameters shall be as described in Table 11.
Table 11: SF-IDCHANGE-SUBSCRIBE.confirm
Name Type Valid range Description Status
subscription INTEGER Subscription handle for Mandatory
0 to 2 – 1
unsubscribe
5.2.6 SF-IDCHANGE-EVENT
5.2.6.1 Description
Indication for notifications on IDCHANGE, see SF-IDCHANGE-SUBSCRIBE specified in clause 5.2.5.
5.2.6.2 SF-IDCHANGE-EVENT.indication
SF-IDCHANGE-EVENT.indication is sent from the Security entity to the Facilities layer for executing the
IDCHANGE-EVENT service. The parameters shall be as described in Table 12.
Table 12: SF-IDCHA
...