CEN ISO/TS 21719-2:2022

SLOVENSKI STANDARD
01-januar-2023
Nadomešča:
SIST-TS CEN ISO/TS 21719-2:2018
Elektronsko pobiranje pristojbin - Personalizacija (prilagajanje) opreme vozil - 2.
del: Uporaba posebne komunikacije kratkega dosega (ISO/TS 21719-2:2022)
Electronic fee collection - Personalization of on-board equipment (OBE) - Part 2: Using
dedicated short-range communication (ISO/TS 21719-2:2022)
Elektronische Gebührenerhebung - Personalisierung von Onboard Einrichtungen - Teil 2:
Verwendung von dedizierter Nahbereichskommunikation (ISO/TS 21719-2:2022)
Perception de télépéage - Personnalisation des équipements embarqués - Partie 2:
Utilisation des communications dédiées à courte portée (ISO/TS 21719-2:2022)
Ta slovenski standard je istoveten z: CEN ISO/TS 21719-2:2022
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN ISO/TS 21719-2
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
November 2022
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 35.240.60 Supersedes CEN ISO/TS 21719-2:2018
English Version
Electronic fee collection - Personalization of on-board
equipment (OBE) - Part 2: Using dedicated short-range
communication (ISO/TS 21719-2:2022)
Perception de télépéage - Personnalisation des Elektronische Gebührenerhebung - Personalisierung
équipements embarqués - Partie 2: Utilisation des von Onboard Einrichtungen - Teil 2: Verwendung von
communications dédiées à courte portée (ISO/TS dedizierter Nahbereichskommunikation (ISO/TS
21719-2:2022) 21719-2:2022)
This Technical Specification (CEN/TS) was approved by CEN on 6 October 2022 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN ISO/TS 21719-2:2022 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (CEN ISO/TS 21719-2:2022) has been prepared by Technical Committee ISO/TC 204
"Intelligent transport systems" in collaboration with Technical Committee CEN/TC 278 “Intelligent
transport systems” the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN ISO/TS 21719-2:2018.
Any feedback and questions on this document should be directed to the users’ national standards
body/national committee. A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Endorsement notice
The text of ISO/TS 21719-2:2022 has been approved by CEN as CEN ISO/TS 21719-2:2022 without any
modification.
TECHNICAL ISO/TS
SPECIFICATION 21719-2
Second edition
2022-10
Electronic fee collection —
Personalization of on-board
equipment (OBE) —
Part 2:
Using dedicated short-range
communication
Perception de télépéage — Personnalisation des équipements
embarqués —
Partie 2: Utilisation des communications dédiées à courte portée
Reference number
ISO/TS 21719-2:2022(E)
ISO/TS 21719-2:2022(E)
© ISO 2022
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/TS 21719-2:2022(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 Conformance . 5
5.1 General . 5
5.2 Base standards . 5
5.3 Main contents of an EFC personalization AP . 5
5.4 Conformance statement . 6
6 Personalization overview .6
6.1 Process . 6
6.2 System architecture . 6
7 OBE requirements .6
7.1 General . 6
7.2 DSRC lower layer requirements . 6
7.2.1 Supported DSRC stacks . 6
7.2.2 CEN DSRC stack . 7
7.3 OBE personalization functions. 8
7.3.1 General . 8
7.3.2 Initialization and termination . 8
7.3.3 Retrieving the OBE identifier . 8
7.3.4 Writing of data . 8
7.4 Security requirements . . 11
7.5 Transaction requirements .12
8 Personalization equipment requirements .13
8.1 General .13
8.2 DSRC lower layer requirements .13
8.2.1 Supported DSRC stacks .13
8.2.2 CEN DSRC stack .13
8.3 PE personalization functions . .13
8.4 Security requirements . . 13
8.5 Transaction requirements .13
Annex A (normative) Security calculations .14
Annex B (normative) PICS proforma . .19
Annex C (normative) Personalization of OBE conforming to ETSI ES 200 674-1 .24
Annex D (informative) Transaction example .29
Annex E (informative) Security computation examples .33
Bibliography .37
iii
ISO/TS 21719-2:2022(E)
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 second edition cancels and replaces the first edition (ISO/TS 21719-2:2018), which has been
technically revised.
The main changes are as follows:
— addition of subclause 5.4 on the Conformance statement;
— minor updating of terms, including a reference to ISO/TS 17573-2 as the primary source.
A list of all parts in the ISO 21719 series can be found on the ISO website.
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.
iv
ISO/TS 21719-2:2022(E)
Introduction
On-board equipment (OBE) is an in-vehicle device that contains one or more application instances to
support different intelligent transport system (ITS) implementations such as electronic fee collection
(EFC).
To assign the EFC application in the OBE to a certain user or/and vehicle, personalization is performed.
This means that unique user- and vehicle-related data needs to be transferred and stored in the OBE.
CEN/TR 16152 assessed many aspects of the personalization process and defined the overall
personalization assets: application data, application keys and vehicle data.
Different communication media may be used for transferring the personalization assets to the OBE. An
overall message exchange framework and required security functionality may be applied for all media
common procedures, to ensure data protection and integrity.
By standardizing the personalization procedure, compatibility of personalization equipment is
supported, and the entity responsible for the personalization [e.g. a toll service provider (TSP)] will
further be able to outsource partial or complete personalization to a third party or to another service
provider or personalization agent.
The scope of the personalization functionality is illustrated in Figure 1 and is limited to the dedicated
short-range communication (DSRC) interface between the personalization equipment (PE) and the OBE.
Figure 1 — Scope for this document (box delimited by a dotted line)
This document defines a complete application profile using the personalization functionality described
in ISO/TS 21719-1, on top of a CEN DSRC stack according to the DSRC communication profiles as
specified in EN 13372 and using the EFC Application Interface according to ISO 14906.
This document further defines in the annexes the use of this application profile on top of other DSRC
communication stacks that are compliant with the application layer interfaces as defined in ISO 14906
and EN 12834.
Figure 2 shows the scope of this document from a DSRC-stack perspective.
v
ISO/TS 21719-2:2022(E)
Key
ADU application data unit
T-APDU transfer-application protocol data unit
LPDU logical link control (LLC) protocol data unit
PPDU physical layer protocol data unit
DSRC L1 DSRC layer 1 (physical layer)
DSRC L2 DSRC layer 2 (data link layer)
DSRC L7 DSRC layer 7 (application layer)
Figure 2 — Relationship between this document and DSRC-stack elements
vi
TECHNICAL SPECIFICATION ISO/TS 21719-2:2022(E)
Electronic fee collection — Personalization of on-board
equipment (OBE) —
Part 2:
Using dedicated short-range communication
1 Scope
This document defines:
— personalization interface: dedicated short-range communication (DSRC),
— physical systems: on-board equipment and the personalization equipment,
— DSRC-link requirements,
— EFC personalization functions according to ISO/TS 21719-1 when defined for the DSRC interface,
and
— security data elements and mechanisms to be used over the DSRC interface.
A protocol information conformance statement (PICS) proforma is provided in Annex B, and security
computation examples are provided in Annex E.
It is outside the scope of this document to define:
— conformance procedures and test specifications,
— setting-up of operating organizations (e.g. toll service provider, personalization agent, trusted third
party), and
— legal issues.
NOTE Some of these issues are subject to separate standards prepared by ISO/TC 204, CEN/TC 278 or ETSI
ERM.
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/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO/IEC 10116:2017, Information technology — Security techniques — Modes of operations for an n-bit
block cipher
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range
communication
ISO 15628, Intelligent transport systems — Dedicated short range communication (DSRC) — DSRC
application layer
ISO/TS 21719-2:2022(E)
ISO/IEC 18033-3:2010, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
EN 12834, Road transport and traffic telematics — Dedicated Short Range Communication (DSRC) —
DSRC application layer
EN 15509:2022, Electronic fee collection — Interoperability application profile for DSRC
ETSI/ES 200 674-1:2013, Intelligent Transport Systems (ITS) — Road Transport and Traffic Telematics
(RTTT) — Dedicated Short Range Communications (DSRC) — Part 1: Technical characteristics and test
methods for High Data Rate (HDR) data transmission equipment operating in the 5,8 GHz Industrial,
Scientific and Medical (ISM) band (V2.4.1, 2013-05)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
[SOURCE: ISO/TS 17573-2:2020, 3.4, modified — admitted term removed (listed in Clause 4).]
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
[SOURCE: ISO/TS 17573-2:2020, 3.13]
3.3
authentication
security mechanism allowing verification of the provided identity
[SOURCE: ISO/TS 17573-2:2020, 3.15]
3.4
authenticator
data, possibly encrypted, that is used for authentication (3.3)
[SOURCE: ISO/TS 17573-2:2020, 3.16]
3.5
base standard
approved International Standard, Technical Specification or ITU-T Recommendation
Note 1 to entry: This includes but is not limited to approved standard deliverables from ISO, ITU, CEN, CENELEC,
ETSI and IEEE.
[SOURCE: ISO/TS 17573-2:2020, 3.23]
3.6
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/TS 17573-2:2020, 3.56]
ISO/TS 21719-2:2022(E)
3.7
electronic fee collection
fee collection by electronic means
[SOURCE: ISO/TS 17573-2:2020, 3.70, modified — admitted term removed (listed in Clause 4).]
3.8
EFC Element
coherent set of data and functionality
Note 1 to entry: The functionality includes, where applicable, the security-related functions and the associated
security keys.
Note 2 to entry: EFC Elements are created by the applications and addressed using Element identifiers.
Note 3 to entry: In a given on-board equipment (OBE) (3.9), the EID is used to address a toll context, identified by
the EFC-ContextMark, in which attributes (3.2) can be addressed unambiguously by AttributeIDs inside an EFC
Element of the OBE.
[SOURCE: ISO/TS 17573-2:2020, 3.71]
3.9
on-board equipment
all required equipment on-board a vehicle for performing required electronic fee collection (EFC) (3.7)
functions and communication services
[SOURCE: ISO/TS 17573-2:2020, 3.126, modified — admitted term removed (listed in Clause 4).]
3.10
OBE personalization
transferring personalization assets (3.11) to the on-board equipment (OBE) (3.9)
[SOURCE: ISO/TS 17573-2:2020, 3.123]
3.11
personalization assets
specific data stored in the on-board equipment (OBE) (3.9) related to the user and the vehicle
[SOURCE: ISO/TS 17573-2:2020, 3.137]
3.12
personalization equipment
equipment for transferring personalization assets (3.11) to the on-board equipment (OBE) (3.9)
[SOURCE: ISO/TS 17573-2:2020, 3.138]
3.13
profile
set of requirements and selected options from base standards (3.5) or international standardized
profiles used to provide a specific functionality
[SOURCE: ISO/TS 17573-2:2020, 3.146]
3.14
toll service provider
entity providing toll services in one or more toll domains
[SOURCE: ISO/TS 17573-2:2020, 3.206, modified — admitted term removed (listed in Clause 4).]
ISO/TS 21719-2:2022(E)
3.15
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO/TS 17573-2:2020, 3.211]
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
Ack acknowledgement
AcK access key
AC_CR access credentials
ADU application data unit
APDU application protocol data unit
AP application profile
ASN.1 abstract syntax notation one
AVEI automatic vehicle and equipment identification
BST beacon service table
CBC cipher block chaining
DSRC dedicated short-range communication
EFC electronic fee collection
EID element identifier
ICS implementation conformance statement
IUT implementation under test
MAC message authentication code
OBE on-board equipment
PE personalization equipment
PICS protocol implementation conformance statement
SAM secure application module
TSP toll service provider
T-APDU transfer-application protocol data unit
VST vehicle service table
ISO/TS 21719-2:2022(E)
5 Conformance
5.1 General
This clause describes in general terms what it means to be conformant with (the profile in) this
document.
5.2 Base standards
This document defines one application profile (AP). The base standards that this AP is based upon are
as follows:
— standards for security functionality;
— standards for EFC application definition as, e.g. ISO 14906;
— standards for the DSRC communication stack definition.
An overview of the relationship and references between base standards and this AP is illustrated in
Figure 3.
Key
AVEI automatic vehicle and equipment identification
Figure 3 — Relationship and references between base standards and this document
All requirements defined in this document are either choices made from these base standards or more
specific and limited requirement based on the general provisions of these standards.
5.3 Main contents of an EFC personalization AP
The conformance requirements of an AP are divided between requirements for the on-board equipment
(OBE) and the personalization equipment (PE). The requirements are listed separately for OBE and PE.
This applies for all parts, requirements, PICS and conformance testing.
ISO/TS 21719-2:2022(E)
The conformance requirements of an AP according to this document shall include the following parts
(divided into separate requirements for OBE and PE):
— DSRC lower layer requirements;
— EFC personalization functions;
— security requirements;
— transaction requirements.
5.4 Conformance statement
A supplier of OBE that claims conformity of their OBE to this document shall provide a statement of
conformance to this document by completing the protocol implementation conformance statement
(PICS) as provided in B.5.
6 Personalization overview
6.1 Process
The overall personalization process is described in ISO/TS 21719-1:2018, 5.1.
Personalization means that an existing EFC application structure in the OBE is populated with
personalization assets such as user or vehicle data.
Creation of the EFC application and entering initial data, such as initial security keys, is performed
before the personalization and is out of scope of this document.
During personalization, the OBE shall be within the communication range of the PE in order for the data
exchange according to this document to take place.
Application data and security keys are transferred to the OBE during the personalization process in an
attribute list using standardized DSRC commands according to the requirements in this document.
6.2 System architecture
The overall system architecture is described in ISO/TS 21719-1:2018, 5.2.
For personalization over a DSRC interface, the OBE and PE shall contain a DSRC stack and the application
services as described in this document.
Security functionality and secure key storage may either be implemented within the PE or the PE may
be connected to a central system where this functionality may reside. This is outside the scope of this
document.
7 OBE requirements
7.1 General
This clause contains the normative conformance requirements on the OBE for profile number 1: EFC-
DSRC-Personalization Profile 1.
7.2 DSRC lower layer requirements
7.2.1 Supported DSRC stacks
This document supports the DSRC stacks as defined in Table 1.
ISO/TS 21719-2:2022(E)
Table 1 — Supported DSRC stacks
DSRC stack Application layer Lower layers Detailed specifications
CEN-DSRC ISO 15628 EN 12795 Specification in 7.2.2
EN 12834 EN 12253
Italian DSRC ETSI/ES 200 674– ETSI/ES 200 674– Specification and implementation example in
1:2013, Clause 11 1:2013, Clauses 7 to Annex C
and Annex C 10 and Annex C
Japanese DSRC ARIB STD-T75 ARIB STD-T75
Wave DSRC IEEE1609.11 IEEE 802.11p
IEEE 1609.3/4
7.2.2 CEN DSRC stack
The following requirements apply for the personalization profile when using the CEN DSRC stack.
The OBE shall comply with EN 15509:2022, 6.1.2 which implicitly requires conformance with the
underlying standards as shown in Figure 4.
Figure 4 — Relationship and references between standards for the CEN DSRC stack
ISO/TS 21719-2:2022(E)
7.3 OBE personalization functions
7.3.1 General
The OBE shall offer the following functions in order to support personalization:
— initialization of communication: used to establish a communication session with the OBE;
— transferring OBE identifier(s) to the PE; (optional);
— writing of data: used to update data in the OBE;
— terminate session: used to terminate the personalization session with the OBE.
7.3.2 Initialization and termination
For CEN-DSRC, the OBE shall provide the following functions:
— INITIALIZATION, and RELEASE application layer services according to ISO 15628 and EN 12834.
DSRC stack implementations of initialization and termination according to ETSI ES 200 674-1 shall be in
accordance with Annex C.
During initialization, the OBE shall transfer the following security parameters to the PE:
— random number from the OBE, RndOBE;
— key diversifier (optional);
— key reference (optional).
7.3.3 Retrieving the OBE identifier
In order for the PE to know the identity of the unit and, if necessary, provide a parameter for key
derivation to the PE, the function GET according to ISO 15628 and EN 12834 may optionally be
implemented.
It is out of the scope of this document to define the exact parameter to be used as the identifier.
7.3.4 Writing of data
The main functionality of personalization is to write or update data to already existing data fields
(attributes) in an EFC application in the OBE.
The writing of data shall be performed by using the EFC function SET_SECURE as defined in ISO 14906.
Application attributes are defined with their container types in the application interface standard
ISO 14906. Security keys are stored in attributes with container type 2 (octet string).
The SET_SECURE.request shall, for personalization, be used as shown in Table 2 where the settings of
optional parameters are defined and shown in bold for the purpose of this document.
Table 2 — SET_SECURE.request
parameter name ASN.1 type Value Remark/constraints
Element identifier EID Dsrc-EID 1–127
ActionType INTEGER(0.127,.) 3
AccessCredentials OCTET STRING PRESENT, Length = 8 octets
ActionParameter OCTET STRING Content; see Table 3
ISO/TS 21719-2:2022(E)
TTabablele 2 2 ((ccoonnttiinnueuedd))
parameter name ASN.1 type Value Remark/constraints
Mode BOOLEAN TRUE Confirmed mode
The ActionParameter shall carry the attributes to be written into the OBE plus any information required
by the algorithm providing the security measures. SET_SECURE.request shall be used in confirmed
mode, and a reply shall always be expected.
The content of the action parameter (OCTET STRING) within the scope of this document is defined in
Table 3.
Table 3 — Action parameter content definition
Parameter Length Definition
(octets)
Option_indicator request 1 Always present
Bit string that defines which optional parameters are present
in Action Parameter; it is defined as follows:
b – AttributeList present
b – AttributeListEncrypted present
b – KeyRefEnc present
b – RndPE present
b – Autenticator_Request present
b – KeyRefAuthReq present
b – KeyRefAuthRes present
b – Not used
Table 4 shows allowed combinations of the Option Indicator.
AttributeList n. Optional
An attributeList according to ISO 14906-
Either the parameter AttributeList or AttributeListEncrypted
shall be present.
AttributeListEncrypted m. Optional
An octet string that contains an AttributeList that has been
padded to even 16 octet blocks and encrypted.
Either the parameter AttributeList or AttributeListEncrypted
shall be present.
KeyRefEnc 1 Optional
Encryption Key reference.
Shall be present if AttributeListEncrypted is present.
RndPE 16 Optional
Random number from the PE.
Shall be present if AttributeListEncrypted is present or if
KeyRefAuthRes is present.
Authenticator_Request 8 Optional
Authenticator to secure the integrity of the AttributeList.
KeyRefAuthReq 1 Optional
Shall be present if Authenticator_Request is present.
ISO/TS 21719-2:2022(E)
TTabablele 3 3 ((ccoonnttiinnueuedd))
Parameter Length Definition
(octets)
KeyRefAuthRes 1 Optional
When present, an Authenticator_Response will be provided in
the response.
NOTE 1 The action parameter structure in Table 3 is equivalent to the following ASN.1 type definition encoded
with unaligned packed encoding rules to be coded into the OCTET STRING of the Action Parameter.
ActionParameterContent:: = SEQUENCE {
fill          BOOLEAN,
attributelist      OCTET STRING       OPTIONAL,
attributelistEncrypted OCTET STRING       OPTIONAL,
keyRefEnc        INTEGER (0.255)     OPTIONAL,
rndPE          OCTET STRING (SIZE(8))  OPTIONAL,
authenticatorReq    OCTET STRING (SIZE(8))  OPTIONAL,
keyRefAuthReq      INTEGER (0.255)     OPTIONAL,
keyRefAuthRes      INTEGER (0.255)     OPTIONAL
}
The content of the allowed combinations of option indicators in request within the scope of this
document is defined in Table 4.
Table 4 — Allowed combinations of option indicators in request
Option set 1 Option set 2 Option set 3 Option set 4
b – AttributeList present X X
b – AttributeListEncrypted present X X
b – KeyRefEnc present X X
b – RndPE present X X X
b – Autenticator_Request present X X X X
b – KeyRefAuthReq present X X X X
b – KeyRefAuthRes present X X
The SET_SECURE.response is used according to ISO 14906 where the response parameter content is
used according to Table 5 and Table 6.
Table 5 — SET_SECURE.response
Parameter name ASN.1 type Value Remark/constraints
ResponseParameter OCTET STRING See Optional use
Table 6
Return Code (Ret) ReturnStatus Optional use
SET_SECURE.response shall carry the ResponseParameter and the confirmation of the corresponding
request.
Table 6 — Response parameter definition
Parameter Length Definition
(octets)
Authenticator_Response 8 Optional
Authenticator to prove proper writing of AttributeList.
Present if an Authenticator_Response is requested.
ISO/TS 21719-2:2022(E)
TTabablele 6 6 ((ccoonnttiinnueuedd))
Parameter Length Definition
(octets)
RndOBE2 8 Optional
Random number used to calculate the
Authenticator_Response.
Present if an Authenticator_Response is requested
NOTE 2 The response parameter structure in Table 6 is equivalent to the following ASN.1 type definition
encoded with unaligned packed encoding rules to be coded into the OCTET STRING of the ResponseParameter.
ResponseParameterContent:: = SEQUENCE {
authenticatorRes    OCTET STRING (SIZE(8))
rndOBE2         OCTET STRING (SIZE(8))
}
7.4 Security requirements
This document defines security features and mechanisms based on the security framework defined in
ISO/TS 19299.
All security functionality is implemented according to the following security primitives:
— AES128 encryption algorithm as defined in ISO/IEC 18033-3:2010, 5.2;
— message Authentication Code (MAC) calculation according to MAC algorithm 5 as defined in
ISO/IEC 9797-1:2011, 7.6;
— cipher Block Chaining (CBC) algorithm according to ISO/IEC 10116:2017, Clause 7;
— padding method 4 according to ISO/IEC 9797-1:2011, 6.3.5.
The security related data elements listed in Table 7 shall be handled by the OBE.
Table 7 — Security related data elements
Name Length Remarks
(octets)
Personalization AccessKey 16 AccessKey used for computation of AccessCredentials that allows for
writing attributes received in the AttributeList into the EFC applica-
tion.
AccessCredentials 8 AccessCredentials that allows for writing attributes received in the
AttributeList into the EFC application.
AC_CR-KeyReference 2 Reference to the key generation and the diversifier for the computa-
tion of PersonalizationAccessKey.
RndOBE 8 Random number received from the OBE in the initialization phase of
the personalization transaction and used for computation of access
credentials. If RndOBE received from the OBE is 4 octets, it shall be
padded to eight octets by using the Padding method 2 according to
ISO/IEC 9797-1.
RndOBE2 8 Random number generated by the OBE and used in the calculation of
the Authenticator_Response.
EncryptionKey 16 Encryption Key used to encrypt/decrypt the AttributeList.
KeyRefEnc 1 Reference to EncryptionKey used to encrypt the AttributeList
The reference corresponds to the Attribute ID where the key is stored.
RndPE 16 Random number, from PE used as Start Vector for encryption of the
AttributeList and for the computation of the Authenticator_Response.
ISO/TS 21719-2:2022(E)
TTabablele 7 7 ((ccoonnttiinnueuedd))
Name Length Remarks
(octets)
AuthenticationReqKey 16 AuthenticationKey used for the computation of
Authenticator_Request calculated over the ApplicationList (or
AttributeListEncrypted) that shall be written.
AuthenticationResKey 16 AuthenticationKey used for the computation of
Authenticator_Response calculated by the OBE over the
ApplicationList when it has been written.
Authenticator_Request 8 Authenticator calculated over the ApplicationList (or
AttributeListEncrypted) that shall be written.
Authenticator_Response 8 Authenticator calculated by the OBE over the ApplicationList when it
has been written.
KeyRefAuthReq 1 Reference to AuthenticationKey used for the computation of
Authenticator_Request calculated over the ApplicationList (or
AttributeListEncrypted) that shall be written.
The reference corresponds to the Attribute ID where the key is stored.
KeyRefAuthRes 1 Reference to AuthenticationKey used for the computation of
Authenticator_Response calculated by the OBE over the
ApplicationList when it has been written.
The reference corresponds to the Attribute ID where the key is stored.
The OBE shall be able to:
— generate a random number RndOBE that shall be transferred to the PE in the initialization phase;
— generate a random number RndOBE2 that shall be transferred to the PE in the response;
— check the received access credentials in order to authenticate the PE. This check uses the RndOBE and
the PersonalizationAccessKey. If erroneous access credentials are received, no further processing
of the received data shall be performed and the ReturnStatus in the SET_SECURE response shall be
set to “Access Denied”;
— decrypt the received AttributeListEncrypted before performing the write operation to the EFC
element. The decryption is performed by using the RndPE and the EncryptionKey defined by the
KeyRefEnc;
— check the received attributes for correct size. If the check is negative, no writing of data shall be
performed and the ReturnStatus shall be set to “Argument Error”;
— check the received Authenticator_Request calculated over the AttributeList, by using the received
RndOBE and the AuthenticationReqKey defined by the KeyRefAuthReq, in order to check the data
integrity, before writing the attribute list data into the EFC element. If the check is negative no
writing of data shall be performed and the ReturnStatus shall be set to “Argument Error”;
— calculate an Authenticator_Response over the ApplicationList, the received RndPE and the RndOBE2,
by using the AuthenticationResKey defined by the KeyRefAuthRes, in order to supply a proof that
data was properly written to the EFC element.
If a Write command carries an AttributeList that includes an update of the security keys, authenticators
shall be calculated or checked by using the already existing keys in the OBE.
Security calculations shall be as defined in Annex A.
7.5 Transaction requirements
An OBE that conforms to this document shall be able to perform a personalization transaction that
includes the functions as defined in Clause 7.
ISO/TS 21719-2:2022(E)
Annex D provides an informative example of a personalization transaction when using CEN DSRC.
8 Personalization equipment requirements
8.1 General
This clause contains the normative conformance requirements on the personalization equipment (PE)
for profile number 1; EFC-DSRC-Personalization Profile 1.
8.2 DSRC lower layer requirements
8.2.1 Supported DSRC stacks
The PE shall be able to support OBEs with corresponding DSRC stack as defined in 7.2.
8.2.2 CEN DSRC stack
The following requirements apply for the personalization profile when using the CEN DSRC stack:
— the PE shall conform to EN 15509:2022, 6.2.2.
8.3 PE personalization functions
The PE shall be able to su
...