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

ISO/IEC 29167-16:2015 describes a crypto suite based on Elliptic Curve Cryptography (ECC) for the ISO/IEC 18000‑ series of standards protocol. In particular, it 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. ISO/IEC 29167-16:2015 specifies a crypto suite for ECDSA-ECDH for air interface for RFID systems. The crypto suite is defined in alignment with existing air interfaces. ISO/IEC 29167-16:2015 defines a mutual authentication method and methods of use for the cipher. A Tag and an Interrogator may support one, a subset, or all of the specified options, clearly stating what is supported. Key update is not supported in this international standard.

Technologies de l'information — Techniques automatiques d'identification et de capture de données — Partie 16: Services de sécurité par suite cryptographique ECDSA-ECDH pour communications d'interface radio

General Information

• Status: Withdrawn
• Publication Date: 17-Nov-2015
• ICS: 35.040 - Information coding
• 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: 9599 - Withdrawal of International Standard
• Start Date: 29-Nov-2022
• Completion Date: 30-Oct-2025

Relations

• Revised: 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
• Effective Date: 26-Nov-2021

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29167-16
First edition
2015-11-15
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é par suite cryptographique ECDSA-
ECDH pour communications d’interface radio
Reference number
©
ISO/IEC 2015
© ISO/IEC 2015, 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Conformance . 1
2.1 Claiming conformance . 1
2.2 Interrogator conformance and obligations . 1
2.3 Tag conformance and obligations . 2
3 Normative references . 2
4 Terms and definitions . 2
5 Symbols and abbreviated . 3
5.1 Symbols . 3
5.2 Abbreviated terms . 3
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 . 6
10.1 General . 6
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 . 8
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 .12
11.1 Authenticate Communication .12
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 .23
Annex F (normative) Protocol message’s fragmentation and defragmentation .28
Annex G (informative) Examples of ECC parameters .29
Annex H (normative) TTP involving .30
© ISO/IEC 2015 – All rights reserved iii

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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
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).
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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, Subcommittee
SC 31, Automatic identification and data capture techniques.
ISO/IEC 29167 consists of the following parts, under the general title Information technology —
Automatic identification and data capture techniques:
— Part 1: Air Interface for security services and file management for RFID architecture
— Part 10: Air Interface for security services crypto suite AES128
— Part 11: Air Interface for security services crypto suite PRESENT-80
— Part 12: Air Interface for security services crypto suite ECC-DH
— Part 13: Air Interface for security services crypto suite Grain-128A
— Part 14: Air Interface for security services crypto suite AES-OFB
— Part 15: Air Interface for security services crypto suite XOR
— Part 16: Air Interface for security services crypto suite ECDSA-ECDH
— Part 17: Air Interface for security services crypto suite Crypto GPS
— Part 19: Air Interface for security services crypto suite RAMON
iv © ISO/IEC 2015 – All rights reserved

Introduction
This international standard describes a crypto suite based on Elliptic Curve Cryptography (ECC) for the
ISO/IEC 18000- series of standards protocol. In particular, it 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 international standard defines only mutual authentication for the ECDSA-ECDH cipher. An
Interrogator or a Tag authentication is not supported in this international standard.
ECDSA-ECDH cipher is a high-weight security protocol especially for active RFID system, aiming at
meeting those scenarios with high level security requirement.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may
involve the use of patents concerning radio-frequency identification technology given in the clauses
identified below.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have ensured the ISO and IEC that they are willing to negotiate licences
under reasonable and non-discriminatory terms and conditions with applicants throughout the world.
In this respect, the statements of the holders of these patent rights are registered with ISO and IEC.
Information on the declared patents may be obtained from:
NXP B.V.
411 East Plumeria, San José, CA 95134-1924 USA
China IWNCOMM Co., LTD.
nd
A201, QinFeng Ge, Xi’an Software Park, No.68 Keji 2 Road, Xi’an Hi-tech Industrial Development
Zone, Shaanxi, P. R. China 710075
Impinj, Inc.
th
701 N 34 Street, Suite 300, Seattle, WA 98103 USA
The latest information on IP that may be applicable to this part of ISO/IEC 29167 can be found at www.
iso.org/patents.
© ISO/IEC 2015 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 29167-16:2015(E)
Information technology — Automatic identification and
data capture techniques —
Part 16:
Crypto suite ECDSA-ECDH security services for air interface
communications
1 Scope
This international standard describes a crypto suite based on Elliptic Curve Cryptography (ECC) for the
ISO/IEC 18000- series of standards protocol. In particular, it 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 international standard 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 international standard defines a mutual authentication method and methods of use for the cipher.
A Tag and an Interrogator may support one, a subset, or all of the specified options, clearly stating what
is supported. Key update is not supported in this international standard.
2 Conformance
2.1 Claiming conformance
To claim conformance with this part of ISO/IEC 29167, an Interrogator or a Tag shall comply with all
relevant clauses of this part of ISO/IEC 29167, except those marked as “optional”.
2.2 Interrogator conformance and obligations
To conform to this part of ISO/IEC 29167, an Interrogator shall
— implement the mandatory messages and responses format defined in this part of ISO/IEC 29167,
and conform to the relevant part of ISO/IEC 18000
To conform to this part of ISO/IEC 29167, an Interrogator may
— implement any subset of the optional parameters for message and response format defined in this
part of ISO/IEC 29167
To conform to this part of ISO/IEC 29167, the Interrogator shall not
— implement any messages and responses format that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom parameters for message and response format
to meet the requirements of this part of ISO/IEC 29167.
© ISO/IEC 2015 – All rights reserved 1

2.3 Tag conformance and obligations
To conform to this part of ISO/IEC 29167, a Tag shall
— implement the mandatory message and response formatting defined in this part of ISO/IEC 29167
for the supported types, and conform to the relevant part of ISO/IEC 18000
To conform to this part of ISO/IEC 29167, a Tag may
— implement any subset of the optional parameters in the message and response formatting defined
in this part of ISO/IEC 29167
To conform to this part of ISO/IEC 29167, a Tag shall not
— implement any message and response formatting that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom parameter in the message and response
formatting to meet the requirements of this part of ISO/IEC 29167.
3 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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, Information technology — Radio frequency identification for item management —
Part 4: Parameters for air interface communications at 2,45 GHz
ISO/IEC 19762 (all parts), 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:2006, Information technology — Security techniques — Digital signatures with
appendix — Part 3: Discrete logarithm based mechanisms
ISO/IEC 11770-3:2008, Information technology — Security techniques — Key management — Part 3:
Mechanisms using asymmetric techniques
ISO/IEC 9798-3:1998/Amd.1:2010, Information technology — Security techniques — Entity
authentication — Part 3: Mechanisms using digital signature techniques / Amendment 1: .
ISO/IEC 18031:2011, Information technology — Security techniques — Random bit generation
ISO/IEC 11770-6, Information technology — Security techniques – Key management — Part 6: Key derivation
RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 (all parts) and the
following apply.
4.1
command (message)
command that Interrogator sends to Tag with “Message” as parameter
4.2
message
part of the Command that is defined by the CS
2 © ISO/IEC 2015 – All rights reserved

4.3
reply (response)
reply that Tag returns to the Interrogator with “Response” as parameter
4.4
response
part of the Reply (stored or sent) that is defined by the CS
5 Symbols and abbreviated
5.1 Symbols
xxxx Binary notation
xxxx Hexadecimal notation
h
|| Concatenation of syntax elements, transmitted in the order written
()abscissa Refers to that element of an ordered pair which is plotted on the horizontal axis of a two-di-
mensional cartesian coordinate system
• Point multiply
5.2 Abbreviated terms
CRC Cyclic Redundancy Check
CS Crypto Suite
CSI Cryptographic Suite Identifier
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
RFU Reserved for Future Use
RN Random Number
© ISO/IEC 2015 – All rights reserved 3

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
6 Cipher introduction
The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm
(DSA) which uses Elliptic Curve Cryptography (ECC). ECDSA supports mutual authentication and has
been specified in ISO/IEC 14888-3.
Elliptic curve Diffie–Hellman (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 has been specified in ISO/IEC 11770-3.
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.
Table 1 — Definition of parameters
Parameter Description
FN[7:0] The number of fragmentations.
This shows the authentication type in the authentication procedure. The val-
ues are as following:
— 00: mutual authentication
AuthType[1:0]
— 01: reserved for the use of interrogator authentication
— 10: reserved for the tag authentication
— 11: Other (as defined by the CSI)
4 © ISO/IEC 2015 – All rights reserved

Table 1 (continued)
Parameter Description
This shows the step number in the authentication procedure. The values are as
following:
— 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 con-
tent 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 parameter:
ECDHP[255:0]
1) 01 : The field value shall be denoted by OIDs. The Length subfield indicates
h
the number of octets of OIDs. The values of Content subfield are the content of OIDs.
2) Other: All other values are RFU.
Cert [Variable]    The digital certificate of x. x can be tag, interrogator or TTP. See 7.2.
x
RN [63:0] 64-bit random number generated by the tag.
t
X [391:0] Temporary private key generated by tag and used for ECDH exchange.
t
Temporary public key generated by tag and used for ECDH exchange, the procedure
TPK [391:0] of generation is as follows: the tag generates a temporary private key which is used
t
for ECDH exchange, and temporary public key TPK = X •P.
t t
TTPID[Variable] Specifying whether or not the TTP is to be involved and the identifier of the TTP
Sig [383:0] Digital signature generated by the tag.
t
RN [63:0] 64-bit random number generated by the interrogator.
i
X [391:0] Temporary private key generated by interrogator and used for ECDH exchange.
i
Temporary public key generated by interrogator and used for ECDH exchange, the
TPK [391:0] procedure of generation is as follows: the interrogator generates a temporary private
i
key which is used for ECDH exchange, the temporary public key TPK = X •P.
i i
MIC [255:0] Message integrity code generated by the interrogator.
i
Sig [383:0] Digital signature generated by the interrogator.
i
MIC [255:0] Message integrity code generated by the tag.
t
MK[127:0] Master key.
Authentication result generated by the TTP and contains the value of RES , RES
t i
AuthRes[Variable]
and Sig .
ttp
7.2 Certiticate format
Figure 1 specifies the encoding of digital certificate Cert in the TLV format.
x
Figure 1 — Certificate format
1. 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
© ISO/IEC 2015 – All rights reserved 5

d) Other: All other values are RFU.
2. 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. See Annex A.
Figure 2 — State diagram
9 Initialization and resetting
This part of ISO/IEC 29167 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 ensure that all memory used for intermediate results is cleared after
each operation (message-response pair) and after reset.
10 Authentication
10.1 General
This part of the standard describes additions to the ISO/IEC 18000 series of standards protocol to
support the tag and reader air interface security (TRAIS) based on public key cryptography (TRAIS-P).
Especially, it defines
1. the use of ECC certificates and Elliptic Curve Digital Signature Algorithm (ECDSA) for mutual
authentication of an interrogator and a tag, and
2. the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme with keys to establish
the secure channel, and
6 © ISO/IEC 2015 – All rights reserved

3. 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. According to ISO/IEC 9798-3:1998/Amd.1:2010, the
interrogator and tag can also involve an online trusted third party for the mutual authentication,
Figure 4 shows protocol flows between online trusted third party and an interrogator (See Annex H for
the case of TTP involving).
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
description CSI length of message message (depends on CSI)
Table 3 — Fast response in reply to an Authenticate command
Length Response
# of bits EBV Variable
description length of response response (depends on CSI)
© ISO/IEC 2015 – All rights reserved 7

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
FN IID AuthType AuthStep TTPID Cert ECDHP
i
# of bits 8 64 2 3 Variable Variable 256
Digital
Interroga- TTP in-
fragmenta- certificate ECDH param-
description tor identi- 00 000 volved or
tion number of interro- eter
fier 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 (See Annex E).
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 is to 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 (See Annex H for the case of TTP involving). 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.
2) Other: All other values are RFU.
10.2.3 MAM1.1 Response
The response of MAM1.1 is as shown in Table 5.
8 © ISO/IEC 2015 – All rights reserved

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
descrip- fragmenta- Tag iden- TTP Digital random tem- ECDH Pa- tag
tion tion number tifier involved certifi- number porary rameter ECDSA
or not cate of generated public key signa-
tag by tag generat- ture
ed by tag
and used
for ECDH
exchange
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 (See Annex E).
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. See Annex H for
the case of TTP involving.
: This filed specifies the digital certificate of tag. See 7.2.
d) Cert
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 has been specified in ISO/IEC 18031:2011.
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 describes ECC-192. The use of other ECC curves may require an update of the length of
command parameters.
10.2.4 Authenticate(MAM1.2 Message)
The message of Authenticate command of MAM1.2 is as shown in Table 6.
© ISO/IEC 2015 – All rights reserved 9

Table 6 — MAM1.2 Message
Message
Auth
FN Auth Type RN RN TPK Sig MIC AuthRes
t i i i i
Step
# of
8 2 3 64 64 392 384 256 Variable
bits
temporary
random public key message
random inter-
number generated Integrity
de- fragmen- number rogator results of
gener- by Inter- code gen-
scrip- tation 00 001 gener- ECDSA TTP authen-
ated by rogator erated by
tion number ated by signa- tication
interro- and used Interro-
tag ture
gator for ECDH gator
exchange
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 (See Annex E).
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 meaning:
— 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. The
t
value is the same as the one in the MAM1.1 Response. The random number generation method has
been specified in ISO/IEC 18031:2011.
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. See Annex H for the case of TTP involving.
10.2.5 MAM1.2 Response
The response of MAM1.2 is as shown in Table 7.
10 © ISO/IEC 2015 – All rights reserved

Table 7 — MAM1.2 Response format
Response
FN RN MIC
i t
# of bits 8 64 256
description fragmentation random number generated by
message Integrity code
number interrogator
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 (See Annex E).
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
t
the 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:1998, 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. 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 )absciss, where (X •TPK ) indecates X coordinate of X •TPK , and
i t i t abscissa i t
X •TPK shall not be infinite point. The interrogator computes KD-HMAC-SHA256((X •TPK )
i t i t
abscissa,RN ||RN ) to generate a random value that is used as Master Key (MK), 128 bits. Go to
t i
step 3). The KD-HMAC-SHA256 function is specified in ISO/IEC 11770-6.
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
© ISO/IEC 2015 – All rights reserved 11

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-
t i i i i
SHA256(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 )abscissa,RN ||RN ) to generate a
t i 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, where
t i
the frist part is used as integrity authentication key IAK, the second part is used as session
integrity check key SIK, the third part is used as 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, ignores 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
g) 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 ),
i t i
and bit-wise compares the received MIC in the response against the computed MIC, if they differ
in any bit position, ignores the response, the authentication procedure is failed. Otherwise, the
authentication process is successful.
NOTE 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 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.
NOTE The FN, AuthType, AuthStep, IID and TID in the received messages also shall be checked by both the
tag and interrogator in order to against some security attack such as man-in-the-middle attack.
11 Communication
11.1 Authenticate Communication
Figure 5 shows a representative procedure for an interrogator sending or receiving data using
authenticate communications.
12 © ISO/IEC 2015 – All rights reserved

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 message
authenticate code of message in AuthComm. The response in reply to an AuthComm command is shown
in Table 9, the MAC in response is message authenticate code of Length and Response.
Table 8 — Message in AuthComm command
CSI Length Message MAC
# of bits 8 EBV Variable 128
description CSI length of Message message message authentication 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. Secure Communication uses symmetric encryption algorithms.
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 message authenticate code of reponse in
SecureComm. The resp
...