ISO/TS 21719-2:2018

TECHNICAL ISO/TS
SPECIFICATION 21719-2
First edition
2018-02
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 2018
© ISO 2018, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2018 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms and symbols . 5
5 Conformance . 6
5.1 General . 6
5.2 Base standards . 6
5.3 Main contents of an EFC Personalization AP . 6
6 Personalization overview . 7
6.1 Process . 7
6.2 System architecture . 7
7 OBE requirements . 7
7.1 General . 7
7.2 DSRC lower layer requirements . 7
7.2.1 Supported DSRC stacks . 7
7.2.2 CEN DSRC stack . 8
7.3 OBE personalization functions . 8
7.3.1 General. 8
7.3.2 Initialization and termination . 9
7.3.3 Retrieving OBE identifier . 9
7.3.4 Writing of data . 9
7.4 Security requirements .11
7.5 Transaction requirements .13
8 Personalization equipment requirements .13
8.1 General .13
8.2 DSRC lower layer requirments .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 .14
8.5 Transaction requirements .14
Annex A (normative) Security calculations .15
Annex B (normative) PICS proforma .20
Annex C (normative) Personalization of ES 200 674-1 compliant OBEs .25
Annex D (informative) Transaction example .30
Annex E (informative) Security computation example .35
Bibliography .39
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 on 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 the following
URL: www .iso .org/ iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 21719 series can be found on the ISO website.
iv © ISO 2018 – All rights reserved

Introduction
On-board equipment (OBE) is an in-vehicle device that is able to contain one or more application
instances in order to support different intelligent transportation system (ITS) implementations such
as electronic fee collection (EFC). Examples of EFC applications are road toll collection/road charging,
local augmentation (LAC) or compliance checking (CCC).
To assign the EFC application in the OBE to a certain user and/or vehicle, personalization should be
performed. This means that unique user and vehicle related data, needs to be transferred to the OBE.
The CEN/TR 16152 already assessed many aspects of the personalization process and it also defined
the overall personalization assets as; application data, application keys and vehicle data.
Different communication media may be used for transferring the personalization assets to the OBE but
for all media, common procedures may be applied such as an overall message exchange framework and
necessary security functionality in order 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, will further be
able to outsource parts of, or a complete, personalization to a third party or to another service provider
or personalization agent.
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 RTTT communication profiles 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.
This document may be complemented by a set of standards defining conformity evaluation of the
conformance requirements.
TECHNICAL SPECIFICATION ISO/TS 21719-2:2018(E)
Electronic fee collection — Personalization of on-board
equipment (OBE) —
Part 2:
Using dedicated short-range communication
1 Scope
This document specifies
— 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.
Protcol information conformance statement (PICS) proforma is provided in Annex B, whereas security
computation examples are provided in Annex E.
The scope of the personalization functionality is illustrated in Figure 1 and it is limited to the DSRC
interface between the personalization equipment (PE) and the OBE.
Domain of the entity responsible for personalization
CentralSystem Personalization On Board Equipment (OBE)
DSRC
Equipment (PE)
Scope of this document
Figure 1 — Scope for this document (box delimited by a dotted line)
It is outside the scope of this document to define
— conformance procedures and test specification (this is provided in a separate set of standards),
— setting-up of operating organizations (e.g. toll service provider, personalization agent, trusted third
party, etc.), and
— legal issues.
NOTE Some of these issues are subject to separate standards prepared by CEN/TC 278, ISO/TC 204 or
ETSI ERM.
Figure 2 shows the scope of this document from a DSRC-stack perspective.
RSE OBE
EFC personalization
transaction and DSRC
communication
Application functions Application functions
AP
AP and data and data
security algorithms ADU
security algorithms
Request
Response
DSRC L7
DSRC L7
functions
functions
T-APDU
DSRC L2 LLC DSRC L2 LLC
Downlink Uplink
frames frames
LPDU
DSRC L2 MAC DSRC L2 MAC
DSRC L1 DSRC L1
DSRC L1 DSRC L1
parameters parameters
PPDU
Figure 2 — Relationship between this document and DSRC-stack elements
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 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/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:2014, Electronic Fee Collection — Interoperability application profile for DSRC
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2 © ISO 2018 – All rights reserved
DSRC management
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at www .electropedia .org
— ISO Online browsing platform: available at www .iso .org/ obp
3.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
Note 1 to entry: The access credentials carry information needed to fulfil access conditions in order to perform
the operation on the addressed element in the OBE. The access credentials can carry passwords, as well as
cryptographic based information such as authenticators.
[SOURCE: EN 15509:2014, 3.1]
3.2
attribute
addressable package of data consisting of a single data element (3.10) or structured sequences of data
elements
[SOURCE: ISO 17575-1:2016, 3.2]
3.3
authentication
security mechanism allowing verification of the provided identity
[SOURCE: EN 301 175 V1.1.1:1998, 3]
3.4
authenticator
data, possibly encrypted, that is used for authentication (3.3)
[SOURCE: EN 15509:2014, 3.3]
3.5
base standard
approved International Standard or ITU-T Recommendation
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.1]
3.6
cryptography
principles, means and methods for the transformation of data in order to hide its information content,
prevent its undetected modification or prevent its unauthorized use
[SOURCE: EN 15509:2014, 3.6]
3.7
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO/TS 19299:2015, 3.24, modified — the term “integrity” has been changed to “data
integrity”.]
3.8
data privacy
rights and obligations of individuals and organizations with respect to the collection, use, retention,
disclosure and disposal of personal information
[SOURCE: ISO/TS 19299:2015, 3.32]
3.9
electronic fee collection
EFC
fee collection by electronic means
[SOURCE: ISO 12855:2015, 3.6]
3.10
element
DSRC directory containing application information in the form of attributes (3.2)
[SOURCE: ISO 14906:2011, 3.11, modified — the definition has been revised.]
3.11
international standardized profile
internationally agreed-to, harmonized document which describes one or more profiles (3.16)
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.2]
3.12
on-board equipment
OBE
required equipment on-board a vehicle for performing required electronic fee collection (EFC) (3.9)
functions and communication services
3.13
OBE personalization
process of transferring personalization assets (3.14) to the on-board equipment (OBE) (3.12)
3.14
personalization assets
specific data stored in the on-board equipment (OBE) (3.12) related to the user and the vehicle
3.15
personalization equipment
equipment for transferring personalization assets (3.14) to the on-board equipment (OBE) (3.12)
3.16
profile
set of requirements and selected options from base standards (3.5) or international standardized
profiles used to provide a specific functionality
[SOURCE: ISO/IEC TR 10000-1:1998, 3.1.4 — modified]
3.17
service primitive
elementary communication service provided by the application layer protocol to the application
processes
Note 1 to entry: The invocation of a service primitive by an application process implicitly calls upon and uses
services offered by the lower protocol layers.
[SOURCE: ISO 14906:2011, 3.18, modified — the scope of application has been deleted.]
3.18
toll charger
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16, modified — the definition has been revised.]
4 © ISO 2018 – All rights reserved

3.19
toll service provider
entity providing toll services in one or more toll domains
Note 1 to entry: The toll service provider is responsible for the configuration and operation (functioning) of the
OBE with respect to tolling.
[SOURCE: ISO 17573:2010, 3.23, modified — the definition has been revised and Notes 1 and 2 have
been deleted.]
3.20
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO 17575-1:2016, 3.21]
4 Abbreviated terms and symbols
AC_CR access credentials (see ISO 14906)
ADU application data unit (see ISO 14906)
APDU application protocol data unit (see ISO 14906)
AP application process (see ISO 14906)
ASN.1 abstract syntax notation one (see ISO/IEC 8824-1)
BST beacon service table (see ISO 14906)
CCC compliance check communication (see ISO 12813)
DSRC dedicated short-range communication
e [key] (value) encryption of the value using the key
EID element identifier (see ISO 14906)
EFC electronic fee collection (see ISO 17573)
IAP interoperable application profile (see EN 15509)
ICS implementation conformance statement
ISP international standardized profile (see ISO/IEC TR 10000-1)
IUT implementation under test
L1 Layer 1 of DSRC (physical layer)
L2 Layer 2 of DSRC (LLC and MAC layer)
L7 Layer 7 of DSRC (application layer)
LAC localization augmentation communication (see ISO 13141)
LLC logical link control (see EN 12795)
LSDU link service data unit
MAC media access control (see EN 12795)
OBE on-board equipment
PE personalization equipment
PICS protocol implementation conformance statement
T-APDU transfer-application protocol data unit
VST vehicle service table (see ISO 14906)
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 application profile 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 application profile is
illustrated in Figure 3.
ISO 21719-2
EFC
Personalization of
OBE, Using DSRC
ISO 14906
Authentication Modes of EFC application DSRC Stack
authentication Modes of EFC application DSRC Stack
codes operation Interface Standards
codes operation Interface Standards
Deinition
Deinition
ISO 14816
ISO 14816
Encryption
AVEI Numbering
Encryption AVEI Numbering
algorithms and data
and data
algorithms
structures
structures
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.
6 © ISO 2018 – All rights reserved

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.
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 during the personalization process transferred to the OBE 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.
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–1 ETSI/ES 200 674–1 Specification and implementation example
(Clause 11 and (Clauses 7 to 10 and in Annex C
Annex C) Annex C)
Japanese DSRC ARIB STD-T75 ARIB STD-T75
Wave DSRC IEEE1609.11 IEEE802.11p
IEEE1609.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:2014, 6.1.2 which implicitly requires compliance with the
underlying standards as shown in the Figure 4.
ISO 21719-2
EFC
Personalization of
OBE, using DSRC
CEN DSRC Stack
ISO/IEC 9797-1 ISO 14906 EN 12834/ EN 15509
ISO/IEC 10116
Message Modes of EFC application ISO 15628 EFC Interop.
authentication interface DSRC Layer 7 application
operation
codes deƒinition ISO/IEC 10116 proƒile
ISO 14816 EN 12795
ISO 18033-3 EN 13372
AVEI Numbering
DSRC Layer 2
Encryption DSRC proƒile
and data ISO/IEC 9797-1
algorithms
structures
message
EN 12253
DSRC Layer 1
ISO 18033-3
Figure 4 — Relationship and references between standards for the CEN DSRC stack
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;
8 © ISO 2018 – All rights reserved

— 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.
Other DSRC stack implementations of initialization and termination are defined in 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 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 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.
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).
This is performed by using the EFC function SET_SECURE as defined in ISO 14906.
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
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 what optional parameters that are present
in Action Parameter and 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.
KeyRefAuthRes 1 Optional
When present, an Authenticator_Response will be provided in
the response.
NOTE The structure above is equivalent to the following ASN.1 type definition encoded with Unaligned
Packed Encoding Rules (UPER) 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,
10 © ISO 2018 – All rights reserved

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.
RndOBE2 8 Optional
Random number used to calculate the
Authenticator_Response.
Present if an Authenticator_Response is requested
NOTE The structure above is equivalent to the following ASN.1 type definition encoded with Unaligned
Packed Encoding Rules (UPER) to be coded into the OCTET STRING of the Response Parameter.
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
(in octets)
Personalization AccessKey 16 AccessKey used for computation of AccessCredentials that allows for
writing attributes received in the AttributeList into the EFC application.
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.
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;
12 © ISO 2018 – All rights reserved

— 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 integrity
of the data, 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 are defined in Annex A.
7.5 Transaction requirements
An OBE compliant with this document shall be able to perform a personalization transaction that
includes the functions as defined in Clause 7.
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 requirments
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 comply with EN 15509:2014, 6.2.2
8.3 PE personalization functions
The PE shall be able to support OBEs as defined in 7.3.
8.4 Security requirements
Since the security functionality may reside partly or fully within a central system of the entity
responsible for the personalization, the requirements defined for the PE in this subclause shall be seen
as requirements on the combination of the PE and a possible central system.
The PE shall support the security data elements as defined in the Table 7.
The PE shall be able to:
— generate access credentials using the received RndOBE and the PersonalizationAccessKey in order
to authenticate itself towards the OBE;
— generate a random number RndPE;
— encrypt the AttributeList before sending it to the OBE. The encryption is performed using the RndPE
and an EncryptionKey defined by the KeyRefEnc;
— calculate an Authenticator_Request calculated over the AttributeList and the RndOBE and send this
authenticator to the OBE in order to secure the integrity of the data. The calculation is performed
using an AuthenticationReqKey defined by the KeyRefAuthReq;
— check the Authenticator_Response that is received from the OBE and calculated on the AttributeList,
the RndPE and the received RndOBE2, in order to assess that data was properly written. The check
is performed by using the AuthenticationResKey defined by the KeyRefAuthRes.
8.5 Transaction requirements
A PE compliant with this document shall be able to perform a personalization transaction that includes
the functions as defined in Clause 8.
Annex D provides an informative example of a personalization transaction when using CEN DSRC.
14 © ISO 2018 – All rights reserved

Annex A
(normative)
Security calculations
A.1 General
This annex contains detailed definitions of required security features and calculations.
A.2 Access credentials
A.2.1 General
Access credentials are used to protect against non-authorized access to data in the OBE, and they are a
way for the OBE to verify that it is being accessed by an authentic PE.
A.2.2 Principle of access credentials
The principle of access control to change the OBU information is shown below.
In the initialization phase between an OBE and the PE, the OBE sends an Application List that displays
available EFC Applications in the OBE. For each application, the list contains an EFC Context mark, an
Access Credential Key Reference (AC_CR-KeyReference) and a random number (RndOBE).
The AC_CR-Key reference is used as key diversifier for the PE to derive the Personalization Access Key
from the Master Personalization Access Key. The calculations for this are described in A.3.
Knowing the Personalization Access Key, the PE now is able to calculate correct access credentials (AC_
CR) over the RndOBE. The AC_CR is provided in messages to the OBE during the session.
The OBE compares the received access credentials with its own calculation. In case they are equal, the
OBE accepts the PE as a genuine PE and is accepting the command from the PE.
A.2.3 Calculation of access credentials
The calculation of access credentials in the OBE and PE uses the following standardized security
primitives:
— Message Authentication Code calculation in Chained Block Cipher mode according to ISO/IEC 9797-
1:2011, 7.6; MAC Algorithm 5 (CMAC) with Padding Method 4;
— Encryption algorithm AES-128 according to ISO/IEC 18033-3:2010, 5.2.
As input data string to the MAC algorithm, the 8 octet RndOBE shall be used. It shall be padded to
16 octets using Padding Method 4. The 16 octets output from the MAC algorithm shall be truncated and
the 8 leftmost octets are used as AC-CR.
The encryption key for the encryption algorithm shall be the Personalization Access Key. This key is
already present in the OBE but the PE derived it from the Master Personalization Access Key by using
the AC-CR-Key reference parameter.
A.3 Key derivation for the personalization access key
A.3.1 General
In order to avoid that the Master Personalization Key is stored in all OBEs, different diversified
Personalization Keys are used. The Master Personalization Key therefore only has to be available at
time of personalization and can reside in a Secure Application Module (SAM) to which the PE has access.
A.3.2 Calculation of the personalization access key
The Personalization Access Key of a Key Generation k shall have a length of 16 octets and shall be
derived from the 32 octet Personalization Master Access Key using the AES-256 single block encryption
as specified in ISO/IEC 18033-3:2010, 5.2 according to the description below and using the AC_CR_
KeyRef as described below:
a) let the Personalization Master Access Key for a given generation k be: MPAcK(k);
b) let the derived Personalization Access Key be: PAcK(k);
c) make the concatenation of a multiple of AC_CR-KeyReference to obtain a 16 octets value, VAL:
VAL = ‘AC_CR_KeyReference || AC_CR-KeyReference || AC_CR-KeyReference || AC_CR-KeyReference
|| AC_CR-KeyReference || AC_CR-KeyReference || AC_CR-KeyReference || AC_CR-KeyReference’;
d) Compute the PAcK(k) as follows:
PAcK(k) = e[MPAcK (k)] (VAL).
The generation of the Personalization Access Key is defined at the moment of personalization and
should be associated to the OBU
...