ISO/IEC 29167-16:2022

Information technology - Automatic identification and data capture techniques - Part 16: Crypto suite ECDSA-ECDH security services for air interface communications

This document describes a crypto suite based on elliptic curve cryptography (ECC) for the ISO/IEC 18000 series of standards protocol. In particular, this document specifies the use of elliptic curve Diffie-Hellman (ECDH) key agreement in a secure channel establishment and the use of elliptic curve digital signature algorithm (ECDSA) in an authentication mechanism. This document specifies a crypto suite for ECDSA-ECDH for air interface for RFID systems. The crypto suite is defined in alignment with existing air interfaces. This document defines a mutual authentication method and methods of use for the cipher. A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported. Key update is not supported in this document. ECDSA-ECDH cipher is a high-weight security protocol especially for active RFID system, aiming at meeting those scenarios with high level security requirement.

Technologies de l'information — Techniques automatiques d'identification et de capture de données — Partie 16: Services de sécurité de la suite cryptographique ECDSA-ECDH pour les communications d'interfaces aériennes

General Information

• Status: Published
• Publication Date: 28-Nov-2022
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 4 - Radio communications
• Current Stage: 6060 - International Standard published
• Start Date: 29-Nov-2022
• Due Date: 21-Jan-2024
• Completion Date: 29-Nov-2022

Relations

• Revises: ISO/IEC 29167-16:2015 - Information technology - Automatic identification and data capture techniques - Part 16: Crypto suite ECDSA-ECDH security services for air interface communications
• Effective Date: 26-Nov-2021

Overview - ISO/IEC 29167-16:2022 (ECDSA‑ECDH crypto suite for air interface)

ISO/IEC 29167-16:2022 defines a public‑key crypto suite based on elliptic curve cryptography (ECC) for RFID air interfaces in the ISO/IEC 18000 family. The standard specifies use of ECDH (Elliptic Curve Diffie‑Hellman) for secure channel establishment and ECDSA (Elliptic Curve Digital Signature Algorithm) for mutual authentication between a Tag and an Interrogator (reader). It is intended as a high‑weight security protocol, particularly for active RFID systems requiring strong cryptographic protections. This second edition (2022) updates references and aligns the suite with existing air interface parameters.

Key topics and technical requirements

• Crypto primitives: ECDSA for entity authentication and ECDH for key agreement (ECDSA‑ECDH crypto suite).
• Mutual authentication: Protocols and message formats for mutual authenticate messages (MAM), including Authenticate(MAM1.1 / MAM1.2) and associated responses.
• Secure channel establishment: Use of ECDH to derive session keys (SEK, SIK) for confidential and integrity‑protected communication.
• Message and response formats: Mandatory and optional message structures; Tags and Interrogators must clearly declare supported options.
• Conformance rules: Devices claiming conformance must implement mandatory messages and comply with ISO/IEC 18000 air interface requirements; optional parameters may be selectively implemented.
• Operational mechanics included: State diagram, initialization/reset behavior, authentication procedures, fragmentation/defragmentation, and error codes.
• Supporting material: Parameter definitions, certificate format, test vectors, examples of ECC parameters, and guidance on Trusted Third Party (TTP) usage.
• Limitations: Key update is not supported by this document - long‑term key management considerations must be handled externally.
• Security focus: Designed as a high‑weight protocol suited to scenarios with elevated security requirements for RFID air interfaces.

Practical applications and users

Who benefits from ISO/IEC 29167-16:

• RFID system designers implementing secure air interfaces for asset tracking, logistics, supply chain security.
• Tag and Interrogator (reader) manufacturers seeking standardized ECC‑based authentication and secure channel services.
• Security architects and integrators deploying active RFID in sensitive environments (industrial IoT, critical infrastructure).
• Conformance and test laboratories using the document’s test vectors and conformance rules to validate implementations.
• Standards and procurement teams specifying high‑security RFID solutions that align with ISO/IEC 18000 protocols.

Related standards (normative and informative)

• ISO/IEC 18000‑4 (RFID air interface at 2,45 GHz)
• ISO/IEC 29167‑1 (AIDC security services for RFID air interfaces)
• ISO/IEC 11770‑3, 11770‑6 (Key management; key derivation)
• ISO/IEC 9798‑3, 14888‑3 (Entity authentication and digital signatures)
• ISO/IEC 18031, 18033‑3, 9797‑3 (Random generation, encryption, MACs)

ISO/IEC 29167‑16 is essential for stakeholders implementing ECC‑based authentication and secure channels on RFID air interfaces, providing a prescriptive, interoperable approach to strong RFID security.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29167-16
Second edition
2022-11
Information technology — Automatic
identification and data capture
techniques —
Part 16:
Crypto suite ECDSA-ECDH
security services for air interface
communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 16: Services de sécurité de la suite cryptographique ECDSA-
ECDH pour les communications d'interfaces aériennes
Reference number
© ISO/IEC 2022
© ISO/IEC 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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2022 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms.2
4.1 Symbols . 2
4.2 Abbreviated terms . 2
5 Conformance . 3
5.1 Claiming conformance . 3
5.2 Interrogator conformance and obligations . 4
5.3 Tag conformance and obligations . 4
6 Cipher introduction .4
7 Parameter definitions .4
7.1 Parameter definitions . 4
7.2 Certiticate format . . 5
8 State diagram . 6
9 Initialization and resetting .6
10 Authentication . 7
10.1 General . 7
10.2 Authenticate message . 7
10.2.1 Message in Authenticate command and reply . 7
10.2.2 Authenticate(MAM1.1 Message) . 8
10.2.3 MAM1.1 Response . 9
10.2.4 Authenticate(MAM1.2 Message) . 9
10.2.5 MAM1.2 Response . 10
10.3 Authentication procedure . 11
10.3.1 Protocol requirements . 11
10.3.2 Procedure . 11
11 Communication .13
11.1 Authenticate communication . 13
11.2 Secure communication .13
Annex A (normative) State transition table .15
Annex B (normative) Error codes and error handling .16
Annex C (normative) Cipher description .17
Annex D (informative) Test vectors .18
Annex E (normative) Protocol specific operation .23
Annex F (normative) Protocol message’s fragmentation and defragmentation .27
Annex G (informative) Examples of ECC parameters .28
Annex H (normative) TTP involving.29
Bibliography .31
iii
© ISO/IEC 2022 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
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 document 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 or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC 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) or the IEC
list of patent declarations received (see https://patents.iec.ch).
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. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
This second edition cancels and replaces the first edition (ISO/IEC 29167-16:2015), which has been
technically revised.
The main changes are as follows:
— certain normative references have been updated;
— editor ial and technical rev isions have been made to maint ain confor mance w it h ISO/IEC 18000-4:2018.
A list of all parts in the ISO/IEC 29167 series can be found on the ISO and IEC websites.
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 and
www.iec.ch/national-committees.
iv
© ISO/IEC 2022 – All rights reserved

Introduction
The International Organization for Standardization (ISO) and the International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may
involve the use of a patent.
ISO and IEC take no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO and IEC that he/she is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this
respect, the statement of the holder of this patent right is registered with ISO and IEC. Information may
be obtained from the patent database available at www.iso.org/patents or https://patents.iec.ch.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights other than those in the patent database. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
v
© ISO/IEC 2022 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29167-16:2022(E)
Information technology — Automatic identification and
data capture techniques —
Part 16:
Crypto suite ECDSA-ECDH security services for air interface
communications
1 Scope
This document describes a crypto suite based on elliptic curve cryptography (ECC) for the
ISO/IEC 18000 series of standards protocol. In particular, this document specifies the use of elliptic
curve Diffie-Hellman (ECDH) key agreement in a secure channel establishment and the use of elliptic
curve digital signature algorithm (ECDSA) in an authentication mechanism.
This document specifies a crypto suite for ECDSA-ECDH for air interface for RFID systems. The crypto
suite is defined in alignment with existing air interfaces.
This document defines a mutual authentication method and methods of use for the cipher. A Tag and an
Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.
Key update is not supported in this document.
ECDSA-ECDH cipher is a high-weight security protocol especially for active RFID system, aiming at
meeting those scenarios with high level security requirement.
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 18000-4:2018, Information technology — Radio frequency identification for item management —
Part 4: Parameters for air interface communications at 2,45 GHz
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary
ISO/IEC 29167-1, Information technology — Automatic identification and data capture techniques — Part
1: Security services for RFID air interfaces
ISO/IEC 14888-3, IT Security techniques — Digital signatures with appendix — Part 3: Discrete logarithm
based mechanisms
ISO/IEC 11770-3, Information security — Key management — Part 3: Mechanisms using asymmetric
techniques
ISO/IEC 9797-3, Information technology — Security techniques — Message Authentication Codes (MACs)
— Part 3: Mechanisms using a universal hash-function
ISO/IEC 9798-3, IT Security techniques — Entity authentication — Part 3: Mechanisms using digital
signature techniques
ISO/IEC 18031, Information technology — Security techniques — Random bit generation
© ISO/IEC 2022 – All rights reserved

ISO/IEC 18033-3, Information technology — Security techniques — Encryption algorithms — Part 3: Block
ciphers
ISO/IEC 11770-6, Information technology — Security techniques — Key management — Part 6: Key
derivation
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the following
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
command
message that interrogator sends to tag with "Message" as parameter
3.2
Message
part of the command (3.1) that is defined by the crypto suite
3.3
reply
response that tag returns to the interrogator with "Response" as parameter
3.4
Response
part of the reply (stored or sent) (3.3) that is defined by the crypto suite
4 Symbols and abbreviated terms
4.1 Symbols
xxxx Binary notation
xxxx Hexadecimal notation
h
|| Concatenation of syntax elements, transmitted in the order written
() Refers to that element of an ordered pair which is plotted on the horizontal axis of a two-di-
abscissa
mensional cartesian coordinate system
• Point multiply
4.2 Abbreviated terms
CRC Cyclic redundancy check
CS Crypto suite
CSI Cryptographic suite identifier
DSA Digital signature algorithm
© ISO/IEC 2022 – All rights reserved

EBV Extensible bit vector
ECC Elliptic curve cryptography
ECDH Elliptic curve Diffie-Hellman
ECDHP ECDH parameter
ECDSA Elliptic curve digital signature algorithm
FN Fragmentation number
IAK Integrity authentication key
IID IDentifier of interrogator
MIC Message integrity check code
MAC Message authentication code
MAM Mutual authenticate message
MK Master key
MTU Maximum transmission unit
RFU Reserved for future use
RN Random number
RFID Radio frequency identification
SEK Session encryption key
SIK Session integrity check key
TID IDentifier of tag
TPK Temporary public key
TRAIS Tag and reader air interface security
TRAIS-P Tag and reader air interface security based on public key cryptography
TTP Trusted third party
TTPID IDentifier of TTP
5 Conformance
5.1 Claiming conformance
To claim conformance with this document, an Interrogator or a Tag shall comply with all relevant
clauses of this document except those marked as “optional”.
[1]
Relevant conformance test methods are provided in ISO/IEC 19823-16 .
© ISO/IEC 2022 – All rights reserved

5.2 Interrogator conformance and obligations
To conform to this document, an Interrogator shall implement the mandatory messages and responses
format defined in this document, and conform to the relevant part of the ISO/IEC 18000 series.
To conform to this document, an Interrogator may implement any subset of the optional parameters for
message and response format defined in this document.
To conform to this document, the Interrogator shall not
— implement any messages and responses format that conflicts with this document, or
— require the use of an optional, proprietary, or custom parameters for message and response format
to meet the requirements of this document.
5.3 Tag conformance and obligations
To conform to this document, a Tag shall implement the mandatory message and response formatting
defined in this document for the supported types, and conform to the relevant part of the ISO/IEC 18000
series.
To conform to this document, a Tag may implement any subset of the optional parameters in the
message and response formatting defined in this document.
To conform to this document, a Tag shall not
— implement any message and response formatting that conflicts with this document, or
— require the use of an optional, proprietary, or custom parameter in the message and response
formatting to meet the requirements of this document.
6 Cipher introduction
The ECDSA is a variant of the DSA which uses ECC. ECDSA supports mutual authentication and has been
specified in ISO/IEC 14888-3. The cipher descriptions of Annex C shall apply.
ECDH is an anonymous key agreement protocol that allows two parties, each having an elliptic curve
public-private key pair, to establish a shared secret over an insecure channel. This shared secret shall
be directly used as a key, or better yet, to derive another key which shall then be used to encrypt
subsequent communications using a symmetric key cipher. It is a variant of the Diffie-Hellman protocol
using ECC. ECDH protocol specified in ISO/IEC 11770-3 shall apply.
ECC is an approach to public-key cryptography based on the algebraic structure of elliptic curves over
finite fields. Compared to the RSA algorithm, ECC offers equivalent security with smaller key sizes
which result in savings for power, memory, bandwidth, and computational resources that make ECC
especially attractive for RFID system.
7 Parameter definitions
7.1 Parameter definitions
Table 1 contains the parameters definitions of the crypto suite.
© ISO/IEC 2022 – All rights reserved

Table 1 — Descriptions of parameters
Parameter Description
The number of fragmentations.
FN[7:0]
This shows the authentication type in the authentication procedure. The values are as
following:
— 00: mutual authentication;
— 01: reserved for the use of interrogator authentication;
AuthType[1:0]
— 10: reserved for the tag authentication;
— 11: Other (as defined by the CSI).
This shows the step number in the authentication procedure. The values are as follow-
ing:
— 000: Step 1 of Authenticate command;
AuthStep[2:0]
— 001: Step 2 of Authenticate command;
— 010-111: All other values are RFU.
ECDH parameter, consist of parameter ID, parameter length and parameter content
three parts, where the parameter ID shall be 8 bits; parameter shall be 16 bits in length
and indicates the number of bytes in the parameter content. The values of ECDH pa-
rameter:
ECDHP[255:0]
1) 01h: The field value shall be denoted by OIDs. The Length subfield indicates the
number of octets of OIDs. The values of Content subfield are the content of OIDs.
2) Other: All other values are RFU.
Certx[Variable] The digital certificate of x. x can be tag, interrogator or TTP. See 7.2.
RNt[63:0] 64-bit random number generated by the tag.
X t[391:0] Temporary private key generated by tag and used for ECDH exchange.
Temporary public key generated by tag and used for ECDH exchange, the procedure of
TPKt[391:0] generation is as follows: the tag generates a temporary private key which is used for
ECDH exchange, and temporary public key TPKt=Xt•P.
TTPID[Variable] Specifying whether or not the TTP is to be involved and the identifier of the TTP.
Sigt[383:0] Digital signature generated by the tag.
RNi[63:0] 64-bit random number generated by the interrogator.
Xi[391:0] Temporary private key generated by interrogator and used for ECDH exchange.
Temporary public key generated by interrogator and used for ECDH exchange, the pro-
TPKi[391:0] cedure of generation is as follows: the interrogator generates a temporary private key
which is used for ECDH exchange, the temporary public key TPKi=Xi•P.
MICi[255:0] Message integrity code generated by the interrogator.
Sigi[383:0] Digital signature generated by the interrogator.
MICt[255:0] Message integrity code generated by the tag.
MK[127:0] Master key.
Authentication result generated by the TTP and contains the value of RESt, RESi and
AuthRes[Variable]
Sigttp.
ECC parameters example see Annex G.
7.2 Certiticate format
Figure 1 specifies the encoding of digital certificate Cert in the TLV format.
x
© ISO/IEC 2022 – All rights reserved

Figure 1 — Certificate format
The Cert Type subfield specifies the type of the certificate and shall be 4 bits in length. The values are:
a) 0000: Value subfield contains X.509 certificate of Interrogator, Cert ;
i
b) 0001: Value subfield contains X.509 certificate of Tag, Cert ;
t
c) 0010: Value subfield contains X.509 certificate of TTP, Cert ;
ttp
d) Other: All other values are RFU.
The 12-bit Cert Length subfield contains the length in number of octets of the Value subfield, in the
range of 1 to 4095.
8 State diagram
The state diagram for this cryptographic suite consists of four states. The transition between these
states is specified in Figure 2. The state transition table of Annex A shall apply.
Figure 2 — State diagram
9 Initialization and resetting
This document shall implement Ready, Authenticate, AuthComm and SecureComm states.
After power-up and after a reset of the crypto suite the tag moves into the Ready state.
Implementations of this suite shall assure that all memory used for intermediate results is cleared after
each operation (message-response pair) and after reset.
© ISO/IEC 2022 – All rights reserved

10 Authentication
10.1 General
This document describes additions to the ISO/IEC 18000 series of standards protocol to support the
TRAIS-P. Especially, it defines
a) the use of ECC certificates and ECDSA for mutual authentication of an interrogator and a tag,
b) the use of the ECDH key agreement scheme with keys to establish the secure channel, and
c) the encoding in the related commands and the processing of those messages.
Figure 3 shows protocol flows of ECDSA-based mutual authentication procedure with the key agreement
of ECDH.
Figure 3 — Mutual authentication with key agreement
The mechanism is based on the ISO/IEC 9798-3, the interrogator and tag can also involve an on-line
trusted third party for the mutual authentication, Figure 4 shows protocol flows between on-line
trusted third party and an interrogator (for the case of TTP involving, Annex H shall apply).
Figure 4 — Protocol flows between TTP and interrogator
10.2 Authenticate message
10.2.1 Message in Authenticate command and reply
Interrogators and Tags shall implement the Authenticate command, message in Authenticate command
as shown in Table 2. The fast response in reply to an Authenticate command is shown in Table 3. An
Interrogator uses Authenticate commands to perform mutual authentication. The CSI specified in the
message selects a particular cryptographic suite from among those supported by the Tag.
Table 2 — Message in Authenticate command
CSI Length Message
# of bits 8 EBV Variable
length of mes-
description CSI message (depends on CSI)
sage
© ISO/IEC 2022 – All rights reserved

Table 3 — Fast response in reply to an Authenticate command
Length Response
# of bits EBV Variable
description length of response response (depends on CSI)
10.2.2 Authenticate(MAM1.1 Message)
The message of Authenticate command of MAM1.1 is as shown in Table 4.
Table 4 — MAM1.1 Message
Message
Auth Auth
FN IID TTPID Cert ECDHP
i
Type Step
# of bits 8 64 2 3 Variable Variable 256
TTP in- digital certifi-
fragmentation interrogator ECDH param-
description 00 000 volved or cate of interro-
number identifier eter
not gator
The fields of MAM1.1 Message shall have the following meaning:
a) FN: This field shall be 8 bits in length and specifies the number of fragmentations (protocol specific
of Annex E shall apply).
b) IID: This field shall be 64 bits in length and specifies the Interrogator identifier.
c) AuthType: This field shall be 2 bits in length and the values of the AuthType field are as follows:
— 00: mutual authentication;
— 01: reserved for the use of interrogator authentication;
— 10: reserved for the tag authentication;
— 11: RFU.
d) AuthStep: This field shall be 3 bits in length and specifies the step number in the procedure. Each
authentication procedure requires a pre-determined number of steps. In MAM1.1 Message, the
value is 000.
e) TTPID: Bit [7:0] of this field specifies whether or not the TTP shall be involved by the interrogator
in the mutual authentication. The optional bit [71:8] is only present and shall be the identifier value
of the TTP while bit [7:0] is set to 0000 0001 (for the case of TTP involving, Annex H shall apply).
The values of bit [7:0] of the TTP field are as follows:
— 0000 0000: TTP not to be involved;
— 0000 0001: TTP to be involved;
— other: All other values are RFU.
f) Cert : This field specifies the digital certificate of interrogator. See 7.2.
i
g) ECDHP: This field shall be 256 bits in length and specifies the ECDH parameter, consisting of
parameter ID, parameter length and parameter content. Where the parameter ID shall be 8 bits;
parameter length shall be 16 bits in length and indicates the number of bytes in the parameter
content. The values of ECDH Parameter:
1) 01h: The field value shall be denoted by OIDs. The Length subfield indicates the number of
octets of OIDs. The values of Content subfield are the content of OIDs.
© ISO/IEC 2022 – All rights reserved

2) Other: All other values are RFU.
10.2.3 MAM1.1 Response
The response of MAM1.1 is as shown in Table 5.
Table 5 — MAM1.1 Response format
Response
FN TID TTPID Cert RN TPK ECDHP Sig

t t t t
# of bits 8 64 Variable Variable 64 392 256 384
fragme-nta- TTP in- digital random temporary ECDSA
tag identi- ECDH pa-
description tion num- volved or certificate number of public key signature
fier rameter
ber not of tag tag for ECDH of tag
The fields of MAM1.1 Response shall have the following meaning:
a) FN: This field shall be 8 bits in length and specifies the number of fragmentations (the protocol
specific of Annex E shall apply).
b) TID: This field shall be 64 bits in length and specifies the Tag identifier.
c) TTPID: This field specifies whether or not the TTP is to be involved by the interrogator in the
mutual authentication. The value is the same as the one in the MAM1.1 Message. For the case of TTP
involving, Annex H shall apply.
d) Cert : This filed specifies the digital certificate of tag. See 7.2.
t
e) RN : This field shall be 64 bits in length and specifies the random number generated by the tag. The
t
random number generation method specified in ISO/IEC 18031 shall apply.
f) TPK : This field shall be 392 bits in length and specifies the temporary public key generated by the
t
tag and used for ECDH exchange. A tag generates a temporary private key X which is used for ECDH
t
exchange, then computes the temporary public key TPK =X •P.
t t
g) ECDHP: This field shall be 256 bits in length and specifies the ECDH parameter, consisting of
parameter ID, parameter length and parameter content. Where the parameter ID shall be 8 bits;
parameter length shall be 16 bits in length and indicates the number of bytes in the parameter
content. The values of ECDH Parameter:
1) 01 : the field value shall be denoted by OIDs. The Length subfield indicates the number of
h
octets of OIDs. The values of Content subfield are the content of OIDs;
2) Other: all other values are RFU.
h) Sig : This field shall be 384 bits in length and specifies the digital signature generated by the tag.
t
The value is computed by Sig =ECDSA (S ,TID||IID||Cert ||TTPID||RN ||TPK ||ECDHP).
t t t t t
NOTE This document only describes ECC-192. An update of the length of command parameters are required
when use of other ECC curves.
10.2.4 Authenticate(MAM1.2 Message)
The message of Authenticate command of MAM1.2 is as shown in Table 6.
© ISO/IEC 2022 – All rights reserved

Table 6 — MAM1.2 Message
Message
Auth Auth
FN RN RN TPK Sig MIC AuthRes
t i i i i
Type Step
# of bits 8 2 3 64 64 392 384 256 Variable
random
fragme-nta- random temporary Interro-gator message results of
number of
description tion 00 001 number of public key for ECDSA signa- integrity TTP authen-
inter-
number tag ECDH ture code ti-cation
ro-gator
The fields of MAM1.2 Message shall have the following meaning:
a) FN: This field shall be 8 bits in length and specifies the number of fragmentations (the protocol
specific of Annex E shall apply).
b) AuthType: This field shall be 2 bits in length and the value of the AuthType field shall be the same as
the one in the MAM1.1 Message. The descriptions of the values are:
— 00: mutual authentication;
— 01: reserved for the use of interrogator authentication;
— 10: reserved for the tag authentication;
— 11: other (as defined by the CSI).
c) AuthStep: This field shall be 3 bits in length and specifies the step number in the procedure. Each
authentication procedure requires a pre-determined number of steps. In MAM1.2 Message, the
value is 001.
d) RN : This field shall be 64 bits in length and specifies the random number generated by the tag.
t
The value is the same as the one in the MAM1.1 Response. The random number generation method
specified in ISO/IEC 18031 shall apply.
e) RN : This field shall be 64 bits in length and specifies the random number generated by the
i
interrogator.
f) TPK : This field shall be 392 bits in length and specifies the temporary public key generated by the
i
interrogator and used for ECDH exchange. An interrogator generates a temporary private key X
i
which is used for ECDH exchange, then computes the temporary public key TPK =X •P.
i i
g) Sig : This field shall be 384 bits in length and specifies the digital signature generated by the
i
interrogator. The value is computed by Sig =ECDSA(S ,TID||IID||TTPID||RN ||RN ||TPK ).
i i t i i
h) MIC : This field shall be 256 bits in length and specifies the message integrity code
i
generated by the interrogator. The value is computed by MIC =HMAC-SHA256(IAK,
i
TID||IID||TTPID||RN ||RN ||TPK ||Sig ).
t i i i
i) AuthRes: This field is optional and shall be present while bit [7:0] of the TTPID field is 0000 0001,
otherwise, this field is not present. For the case of TTP involving, Annex H shall apply.
10.2.5 MAM1.2 Response
The response of MAM1.2 is as shown in Table 7.
© ISO/IEC 2022 – All rights reserved

Table 7 — MAM1.2 Response format
Response
FN RN MIC
i t
# of bits 8 64 256
description fragmentation number random number of interrogator message Integrity code
The fields of MAM1.2 Response shall have the following meaning:
a) FN: This field shall be 8 bits in length and specifies the number of fragmentations (the protocol
specific of Annex E shall apply).
b) RN : This field shall be 64 bits in length and specifies the random number generated by the
i
interrogator. The value is the same as the one in the MAM1.2 Message.
c) MIC : This field shall be 256 bits in length and specifies the message integrity code generated by the
t
Tag. The value is computed by MIC =SHA256(IAK, TID||IID||RN ).
t i
10.3 Authentication procedure
10.3.1 Protocol requirements
Based on the ISO/IEC 9798-3, the authentication protocol requires the tag should have ECC-based
private key S and the related certificate Cert . The interrogator shall have ECC-based private key S and
t t i
the related certificate Cert .
i
10.3.2 Procedure
Authentication protocol flows of ECDSA-based mutual authentication procedure with the key agreement
of ECDH are as follows:
a) The interrogator transmits Authenticate(MAM1.1 Message) to the tag. Where, the TTPID, Cert and
i
ECDHP are included.
b) After receiving Authenticate (MAM1.1 Message), the tag confirms whether or not to involve the
TTP based on the value of TTPID field, if the TTP policy does not match, ignore the message and
the authentication procedure is failed. Otherwise, transmit MAM1.1 Response to the interrogator,
including the TTPID, certificate Cert , random number RN generated by the tag, temporary public key
i t
TPK and ECDHP used for ECDH exchange and generated by the tag, and digital signature Sig generated
t t
by the tag by using its own private key to compute TID||IID||Cert ||TTPID||RN ||TPK ||ECDHP,
t t t
Sig =ECDSA (S ,TID||IID||Cert ||TTPID||RN ||TPK ||ECDHP).
t t t t t
c) After the interrogator has received MAM1.1 Response, the operation is as follows:
1) Confirm whether the values of TTPID and ECDHP in MAM1.1 Response are equal to the values of
TTPID and ECDHP in Authenticate(MAM1.1 Message), respectively, if not, ignore the response,
the authentication procedure is failed. Otherwise, use the tag’s public key Q extracted from
t
certificate Cert to verify the tag’s signature Sig . If the signature verification is failed, ignore
t t
the response, the authentication procedure is failed. The error code type of Annex B shall apply.
Otherwise, go to step 2).
2) The interrogator generates temporary private key X and temporary public key TPK , where
i i
TPK =X •P. and uses X and TPK to perform the ECDH computation, and gets the primary
i i i t
key seed (X •TPK ) , where (X •TPK ) indicates X coordinate of X •TPK , and
i t abscissa i t abscissa i t
X •TPK shall not be infinite point. The interrogator computes KD-HMAC-SHA256((X •TPK )
i t i t
,RN ||RN ) to generate a random value that is used as Master Key (MK), 128 bits. Go to
abscissa t i
step 3). The KD-HMAC-SHA256 function specified in ISO/IEC 11770-6 shall apply.
© ISO/IEC 2022 – All rights reserved

3) The interrogator computes KD-HMAC-SHA256 (MK, TID||IID||RN ||RN ) to generate a random
t i
value, where the first part is used as integrity authentication key IAK, 128 bits, the second part
is used as session integrity check key SIK, 128 bits, the third part is used as session encryption
key SEK,128 bits.
d) The interrogator transmits Authenticate (MAM1.2 Message) to the tag. The command includes
the random number RN generated by the tag, random number RN generated by the interrogator,
t i
temporary public key used for ECDH and generated by the interrogator, digital signature Sig
i
generated by the interrogator to use its own private key to compute TID||IID||TTPID||RN ||RN ||TPK ,
t i i
Sig =ECDSA(S ,TID||IID||TTPID||RN ||RN ||TPK ), and message integrity check code (MIC) generated
i i t i i
by the interrogator to use its IAK to compute TID||IID ||TTPID||RN ||RN ||TPK ||Sig , MIC =HMAC-SH
t i i i i
A256(IAK,TID||IID||TTPID||RN ||RN ||TPK ||Sig ).
t i i i
e) After receiving Authenticate (MAM1.2 Message), the tag should operate as follows:
1) Confirm whether the value of random number RN in Authenticate (MAM1.2 Message) is equal
t
to the value of random number RN in MAM1.1 Response, if not, ignore the command, the
t
authentication procedure is failed; Otherwise, use the interrogator’s public key Q extracted
i
from the certificate Cert to verify the digital signature Sig . If the signature verification is
i i
failed, ignore the response, the authentication procedure is failed. Otherwise, go to step 2).
2) The tag performs the ECDH computation on X and TPK , to get the primary key seed (X •TPK )
t r t i
, where (X •TPK ) indicates X coordinate of X •TPK , and X •TPK shall not be
abscissa t i abscissa t i t i
infinite point. The tag computes KD-HMAC-SHA256((X •TPK ) ,RN ||RN ) to generate a
t i abscissa t i
random value that is used as the MK, 128 bits. Go to step 3).
3) The tag computes KD-HMAC-SHA256(MK, TID||IID||RN ||RN ) to generate a random value,
t i
where the first part is used as an integrity authentication key IAK, the second part is used as
session integrity check key SIK, the third part is used as a session encryption key SEK. Go to
step 4).
4) The tag computes TID||IID||TTPID||RN ||RN ||TPK ||Sig to get the message integrity check code
t i i i
MIC using its IAK, MIC =HMAC-SHA256(IAK, TID||IID||TTPID||RN ||RN ||TPK ||Sig ), and bit-
i t i i i
wise compares the received MIC in the Authenticate command against the computed MIC. If
they differ in any bit position, then ignore the command; the authentication procedure is failed.
Otherwise, the tag authentication process to the interrogator is successful. Go to step 5).
5) The tag transmits MAM1.2 Response to the interrogator, including the random number RN
i
generated by the interrogator, and message integrity check code MIC generated by the tag to
use its IAK to compute TID||IID||RN , MIC =HMAC-SHA256(IAK, TID||IID||RN ).
i t i
f) After receiving MAM1.2 Response, the interrogator first confirms whether the value of random
number RN in the response is equal to the value of random number RN in the Authenticate
i i
(MAM1.2 Message), if not, ignores the response, the authentication procedure is failed. Otherwise,
computes TID||IID||RN to get the MIC using its IAK, MIC =HMAC-SHA256(IAK, TID||IID||RN ), and
i t i
bit-wise compares the received MIC in the response against the computed MIC, if they differ in
any bit position, then ignore the response; the authentication procedure is failed. Otherwise, the
authentication process is successful.
Annex D provides an example of test vectors of the authentication protocol.
When the message shall partition into smaller fragments, the methods of message’s fragmentation and
defragmentation of Annex F shall apply.
The certificate status verification shall be performed by both the tag and interrogator after they
received the certificate from each other and include verification of the certificate’s authenticity and
[2]
expiration status. See RFC 3280 for more information. The validation of certificate revocation status
is optional and may be performed by checking against a certificate revocation list or by contacting an
OCSP responder.
© ISO/IEC 2022 – All rights reserved

In order to resist some security attack such as man-in-the-middle attack, the FN, AuthType, AuthStep,
IID and TID in the received messages also shall be checked by both the tag and interrogator.
11 Communication
11.1 Authenticate communication
Figure 5 shows a representative procedure for an interrogator sending or receiving data using
authenticate communications.
Figure 5 — Authenticate communication
After a tag has cryptographically authenticated an interrogator, it may accept subsequent commands
encapsulated in the AuthComm command. The message in an AuthComm shown in Table 8, it includes
CSI field, Length field, Message field and MAC field. The Message field shall encapsulate a tag-supported
command. Before encapsulating a command, an Interrogator shall remove the preamble, handle and
CRC from the command. An interrogator includes a MAC in the AuthComm, the MAC is the message
authentication code of the message in AuthComm. The MAC mechanism specified in ISO/IEC 9797-3
shall apply. The response in reply to an AuthComm command is shown in Table 9, the MAC in the
response is the message authentication code of Length and Response. The error code type of Annex B
shall apply.
Table 8 — Message in AuthComm command
CSI Length Message MAC
# of bits 8 EBV Variable 128
length of message authentication
description CSI message
Message code
Table 9 — Response in reply to an AuthComm command
Length Response MAC
# of bits EBV Variable 128
description length of Response response message authentication code
11.2 Secure communication
Figure 6 shows a representative procedure for an interrogator sending or receiving data using
secure communications. For secure communication, the symmetric encryption algorithm specified in
ISO/IEC 18033-3 shall apply.
© ISO/IEC 2022 – All rights reserved

Figure 6 — Secure communication
After a tag has cryptographically authenticated an interrogator, it shall accept subsequent commands
encapsulated in the SecureComm command. The message in a SecureComm shown in Table 10, it
includes CSI field, Length field, Message field and an optional MAC field. The Message field shall
encapsulate an encrypted tag-supported command. Before encapsulating a command an Interrogator
shall remove the preamble, handle, and CRC from the command. An interrogator encrypts the message
and/or shall include a MAC in the SecureComm, the MAC is the message authentication code of response
in SecureComm. The response in reply to a SecureComm command is shown in Table 11. The error code
type of Annex B shall apply. The MAC in SecureComm and the related response commands is optional
and shall be present while Bit [7:0] of the TTPID field is 0000 0001.
Table 10 — Message in Secure
...