ISO/IEC FDIS 29167-13

ISO/IEC DISFDIS 29167-13:2024(en)
ISO/IEC JTC 1/SC 31
Secretariat: ANSI
Date: 2025-04-1110-30
Information technology — Automatic identification and data capture
techniques — —
Part 13:
Crypto suite Grain-128A security services for air interface
communications
Technologies de l'information — Techniques automatiques d'identification et de capture de donnees — —
Partie 13: Services de sécurité par suite cryptographique Grain-128A pour communications par interface radio
FDIS stage
© ISO/IEC 20242025
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'sISO’s member body in the country of the requester.
ISO Copyright Officecopyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland.
© ISO/IEC 2025 – All rights reserved
ii
ISO/IEC DISFDIS 29167-13:20242025(en)

© ISO/IEC 20242025 – All rights reserved
iii
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
4.1 Symbols . 1
4.2 Abbreviated terms . 1
5 Conformance . 2
5.1 Claiming conformance . 2
5.2 Interrogator conformance and obligations . 2
5.3 Tag conformance and obligations . 2
6 Cipher introduction. 3
7 Parameter description . 3
8 State diagram . 4
9 Initialization and resetting . 6
10 Authentication . 6
10.1 General . 6
10.2 Tag Authentication (TA) . 8
10.3 Interrogator Authentication (IA) . 9
10.4 Mutual Authentication (MA) . 11
11 Communication . 13
11.1 General . 13
11.2 Authenticated Communication . 13
11.3 Secure Authenticated Communication . 14
12 Key table and key update . 15
Annex A (normative) State transition tables . 17
Annex B (normative) Error conditions and error handling . 22
Annex C (normative) Cipher description . 23
Annex D (informative) Test vectors . 26
Annex E (normative) Protocol specific . 34
Bibliography . 44

© ISO/IEC 2025 – All rights reserved
iv
ISO/IEC DISFDIS 29167-13:20242025(en)
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).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO and IEC [had/had not]
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
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-13:2015), which has been
technically revised.
The main changes arechange is as follows:
— Requirements requirements in Annex EAnnex E have been updated to reflect changes to the
corresponding over-the-air protocol.
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.
© ISO/IEC 20242025 – All rights reserved
v
Introduction
This document specifies the security services of a Grain-128A crypto suite that is based on a lightweight
stream cipher. It is important to know that all security services are optional. Every manufacturer has the
liberty to choose which services will be implemented on a Tag (e.g. Tag-only authentication).
© ISO/IEC 2025 – All rights reserved
vi
DRAFT International Standard ISO/IEC DIS 29167-13:2024(en)

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 assured 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 can be obtained from:
Impinj, Inc.
th
701 N 34 Street, Suite 300
Seattle, WA 98103 USA
The latest information on IP that might be applicable to this part of ISO/IEC 29167 can be found at .
© ISO/IEC 2024 – All rights reserved

Information technology — Automatic identification and data capture
techniques — —
Part 13:
Crypto suite Grain-128A security services for air interface
communications
1 Scope
This document definesspecifies the Crypto Suite for Grain-128A for the ISO/IEC 18000 air interface
standards for radio frequency identification (RFID) devices.
This document definesspecifies various authentication methods 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.
2 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 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabularyVocabulary
ISO/IEC 29167-1, Information technology — Automatic identification and data capture techniques — Part 1:
Security services for RFID air interfaces
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 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/
4 Symbols and abbreviated terms
4.1 Symbols
xxxx binary notation
b
xxxx hexadecimal notation
h
|| concatenation of syntax elements in the order written
4.2 Abbreviated terms
CRC Cyclic Redundancy Check
CS Cryptographic suite
© ISO/IEC 2025 – All rights reserved
CSI Cryptographic suite indicator
IA Interrogator Authentication
IV Initialization Vector
LFSR Linear Feedback Shift Register
LSB Least significant bit
MA Mutual Authentication
MAC Message Authentication Code
MSB Most significant bit
NFSR Nonlinear Feedback Shift Register
RFU Reserved for future use
TA Tag Authentication
5 Conformance
5.1 Claiming conformance
To claim conformance with this part of ISO/IEC 29167, andocument, the Interrogator or Tag shall
complyconform with all relevant clauses of this part of ISO/IEC 29167document, except those marked as
“optional”.
5.2 Interrogator conformance and obligations
To conform to this part of ISO/IEC 29167document, an Interrogator shall
— implement the mandatory commands defineddescribed in this part of
ISO/IEC 29167document and conform to the relevant part of the ISO/IEC 18000 series.
To conform to this part of ISO/IEC 29167document, an Interrogator can
— implement any subset of the optional commands defineddescribed in this part of
ISO/IEC 29167document.
To conform to this part of ISO/IEC 29167document, the Interrogator shall not
— — implement any command that conflicts with this part of ISO/IEC 29167document, or
— — require the use of an optional, proprietary, or custom command to meet the requirements of
this part of ISO/IEC 29167document.
5.3 Tag conformance and obligations
To conform to this part of ISO/IEC 29167document, a Tag shall
— implement the mandatory commands defineddescribed in this part of
ISO/IEC 29167document for the supported types and conform to the relevant part of the ISO/IEC 18000
series.
To conform to this part of ISO/IEC 29167document, a Tag can
© ISO/IEC 2025 – All rights reserved
— implement any subset of the optional commands defineddescribed in this part of
ISO/IEC 29167document.
To conform to this part of ISO/IEC 29167document, a Tag shall not
— — implement any command that conflicts with this part of ISO/IEC 29167document, or
— — require the use of an optional, proprietary, or custom command to meet the requirements of
this part of ISO/IEC 29167document.
6 Cipher introduction
Many stream ciphers have been proposed over the years, and new designs are published as cryptanalysis
[ [1]]
enhances our understanding of how to design safer and more efficient primitives. While the NESSIE 6
project failed to name a stream cipher “winner” after evaluating several new designs in 2000-2003, the
[ [2]]
eSTREAM 7 project finally decided on two portfolios of promising candidates. One of these portfolios was
[ [3]]
aimed at hardware attractive constructions, and Grain 8 is one of three finalists.
Grain is notable for its extremely small hardware representation. During the initial phase of the eSTREAM
[ [4] ]
project, the original version, Grain v0, was strengthened after some observations. 9 . The final version is
known as Grain v1.
Like the other eSTREAM portfolio ciphers, Grain v1 is modern in the sense that it allows for public IVs, yet
they only use 80-bit keys. Recognizing the emerging need for 128-bit keys, Grain-128 supporting 128-bit
[ [5] ]
keys and 96-bit IVs was proposed. 10 . The design is akin to that of 80-bit Grain, but noticeably, the
nonlinear parts of the cipher have smaller degrees than their counterparts in Grain v1.
[ [6] ]
A new version of Grain-128, namely Grain-128A, has been specified. 11 . The new stream cipher has native
support for Message Authentication Code (MAC) generation and is expected to be comparable to the old
version in hardware performance. MAC generation does not affect the keystream generated by Grain-128A.
Grain-128A uses slightly different nonlinear functions in order to strengthen it against the known attacks
and observations on Grain-128. The changes are modest and provide for a high confidence in Grain-128A, as
the cryptanalysis carries over from Grain-128. For the sake of clarity, the stream cipher is fully described in
[9]
Annex CAnnex C though although it is also specified in ISO/IEC 29192-8 .
Error conditions for this cryptographic suite shall be handled in accordance with Annex BAnnex B.
The cryptographic engine in this cryptographic suite shall be in accordance with Annex CAnnex C.
Test vectors for parts of this document are provided in Annex DAnnex D.
Over-the-air protocol commands that use this cryptographic suite shall be in accordance with
Annex EAnnex E.
7 Parameter definitiondescription
The parameters used in this cryptographic suite are provided in Table 1Table 1 — Definition of
Parameters
.
Table 1 — Description of parameters
Parameter Description
AuthMethod[1:0] Authentication method specified by the Interrogator to be used by the Tag
© ISO/IEC 2025 – All rights reserved
Parameter Description
CSFeatures[7:0] Optional features supported by the Tag
IKeystream Interrogator keystream used for authentication
IRandomNumber[47:0] 48-bit Interrogator random number used for crypto engine initialization
IV[95:0] 96-bit Initialization Vector
KeyID[7:0] Specifies the 128-bit crypto key having the ID number = KeyID
MAC32[31:0] 32-bit Message Authentication Code
MAC64[63:0] 64-bit Message Authentication Code
Method[1:0] Authentication method
Options[3:0] Optional features specified by the Interrogator to be used by the Tag
Step[1:0] Step number in the authentication method
TKeystream Tag keystream used for authentication
TRandomNumber[47:0] 48-bit Tag random number used for crypto engine initialization
8 State diagram
Figure 1 — Tag crypto engine The state diagram for the tag cryptographic engine is provided in Figure 1.
The state-transition tables that accompany the state diagram are stated in Annex AAnnex A.
© ISO/IEC 2025 – All rights reserved
Condition 1 Any CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate in this state shall be a Crypto Error
condition (ERROR = TRUE) and cause the state machine to remain in this state.
Condition 2 Initialization of the keystream generator and MAC generator shall be performed as described in
Clause 9.
Condition 3 Any CryptoAuthCmd, CryptoSecCommCmd, or CryptoKeyUpdate in this state shall be a Crypto Error
condition (ERROR = TRUE) and cause the state machine to remain in this state.
Condition 4 Any CryptoAuthCmd other than IA.2, CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate in
this state shall be a Crypto Error condition (ERROR = TRUE) and cause the state machine to remain in this state.
Condition 5 Any CryptoAuthCmd other than MA.2, CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate in
this state shall be a Crypto Error condition (ERROR = TRUE) and cause the state machine to remain in this state.
Condition 6 Any CryptoAuthCmd, CryptoSecCommCmd, or CryptoKeyUpdate in this state shall be a Crypto Error
condition (ERROR = TRUE) and cause the state machine to remain in this state. A CryptoCommCmd shall generate a
MAC and authenticate the CryptoCommCmd.
Condition 7 Any CryptoAuthCmd in this state shall be a Crypto Error condition (ERROR = TRUE) and cause the
state machine to remain in this state. A CryptoCommCmd shall generate a MAC and authenticate the CryptoCommCmd
and shall generate a MAC for use in the CryptoCommResp. A CryptoSecCommCmd shall be decrypted and generate a
© ISO/IEC 2025 – All rights reserved
MAC for authenticating the CryptoSecCommCmd and the CryptoSecCommResp shall be encrypted and generate a MAC
for use in the CryptoSecCommResp.
Figure 1 — Tag crypto engine state diagram
9 Initialization and resetting
The Tag’s air interface protocol logic shall provide an external reset to the Tag crypto engine which shall set
flags and states (in bold) as follows: INIT = FALSE, TA = FALSE, IA = FALSE, and ERROR = FALSE before a
transition to the CS-Reset state.
The CS-Reset state shall process crypto commands from the Tag’s air interface protocol logic only when
ERROR = FALSE. The Tag shall check the crypto command and payload for any error conditions. An error
condition occurs for any CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate command. The Tag
shall check a CryptoAuthCmd payload for any error conditions. An error condition in the payload occurs
when Step ≠ 00 , or the KeyID value is not supported by the Tag, or AuthMethod = 00 and the Tag does not
b b
support Tag authentication, or AuthMethod = 00 and the Options selected are not supported by the Tag
b
CSFeatures, or AuthMethod = 01 and the Tag does not support Interrogator authentication, or AuthMethod
b
= 01 and Options ≠ 0000 , or AuthMethod = 10 and Options ≠ 0000 , or AuthMethod = 11 and the Tag
b b b b b
does not support a vendor defineddescribed authentication.
If an error condition exists, then the Tag crypto engine shall set ERROR = TRUE and remain in the CS-Reset
state.
If no error condition exists, the Tag shall transition to the CS-Init state to start processing the
CryptoAuthCmd and initializes the keystream and MAC generators in the following manner. The key and the
initialization vector (IV) shall be used to initialize the cipher. Denote the bits of the key as k , 0 ≤ i ≤ 127 and
i
the IV bits IV , 0 ≤ i ≤ 95. The IV shall be generated using IRandomNumber and TRandomNumber such that
i
IV[95:0] = TRandomNumber[47:0] || IRandomNumber[47:0]. The 128 NFSR elements are loaded with the
key bits, b = k , 0 ≤ i ≤ 127, and the first 96 LFSR elements are loaded with a one and the IV bits, s = 1 s =
i i 0 i
IV , 1 ≤ i ≤ 95. The last 32 bits of the LFSR are filled with 2 bits for authentication information followed by
i
ones and a zero, s = Tag being authenticated, s = Interrogator being authenticated, s = 1, 98 ≤ i ≤ 126, s
96 97 i 127
= 0. Then, the cipher is clocked 256 times without producing any keystream. Instead the pre-output function
is fed back and XORed with the input, both to the LFSR and to the NFSR. The keystream from the pre-output
function is ready for use and the cipher is now clocked to initialize the MAC generator, either 64 times for a
32-bit MAC generator or 128 times for a 64-bit MAC generator. The Tag crypto engine shall set INIT = TRUE
and the keystream and MAC generators are ready for use to support authentication and communication
security services. While INIT = TRUE, the output streams of the keystream generator and the MAC generator
shall retain state information from one crypto engine operation until the next crypto engine operation.
10 Authentication
10.1 General
A primary use for the Grain-128A CS is to perform authentication of Tags, Interrogators, or both. The
authentication method to be performed shall be specified by the 2-bit value AuthMethod[1:0] which is
defineddescribed in Table 2Table 2. Some of the authentication methods require multiple steps to be
performed in a specific sequence. The current step in the sequence shall be specified by the 2-bit value
Step[1:0] and represents steps 0, 1, 2, and 3 as defineddescribed in Table 3Table 3. All authentication
methods start with step 0 and then the step increments sequentially as needed. Step 0 for all authentication
methods shall be initiated by the Interrogator. During step 0 of an authentication method, the Tag shall
provide an 8-bit value CSFeatures[7:0] which is defineddescribed in Table 5Table 5 and used to indicate
which of the optional Grain-128A CS features are supported by the Tag. During step 0 or 1 of an
© ISO/IEC 2025 – All rights reserved
authentication method, the Interrogator shall provide a 4-bit value Options[3:0] which is defineddescribed
in Table 4Table 4 and used to indicate which optional features should be used by the Tag.
Table 2 — Definition — Description of AuthMethod[1:0]
Value Description
00b Tag authentication
01 Interrogator authentication
b
10 Mutual authentication
b
11b Vendor defined
Table 3 — Definition — Description of Step[1:0]
Value Description
00b Step 0
01 Step 1
b
10 Step 2
b
11b Step 3
Table 4 — Definition — Description of Options[3:0]
Name Description
Options[3] Vendor defined
Options[2] Vendor defined
Options[1] 0 = Disable Secure Authenticated Communication,
1 = Enable Secure Authenticated Communication
Options[0] 0 = Use MAC32,
1 = Use MAC64
Table 5 — Definition — Description of CSFeatures[7:0]
Name Description
CSFeatures[7] Vendor defined
CSFeatures[6] 0 = Encrypted read of hidden memory not supported,
1 = Encrypted read of hidden memory supported
CSFeatures[5] 0 = Key update not supported,
1 = Key update supported
CSFeatures[4] 0 = Secure authenticated communication not supported,
1 = Secure authenticated communication supported
CSFeatures[3] 0 = MAC64 not supported,
1 = MAC64 supported
CSFeatures[2] 0 = MAC32 not supported,
1 = MAC32 supported
CSFeatures[1] 0 = IA not supported,
1 = IA supported
CSFeatures[0] 0 = TA not supported,
© ISO/IEC 2025 – All rights reserved
Name Description
1 = TA supported
10.2 Tag Authentication (TA)
10.2.1 General
The Tag authentication method uses a challenge-response protocol having one pair of message exchange as
shown in Figure 2Figure 2. The Grain-128A CS is initialized using a crypto key specified by the Interrogator
and an IV consisting of a 96-bit random number. The Interrogator and Tag each provide half of the bits used
to generate the IV. Once the Grain-128A CS is initialized, the resulting keystream from the Interrogator and
the Tag are compared to authenticate the Tag. The details of the Tag authentication process are provided in
10.2.2, 10.2.3 and 10.2.4the following sections.

Figure 2 — TA Message Exchange
10.2.2 CryptoAuthCmd(TA.1 Payload for Tag CS)
The Interrogator shall generate a 48-bit random number for use as IRandomNumber and save it for
subsequent use. The Interrogator shall issue the challenge to the Tag with the TA.1 Payload for the Tag CS as
defineddescribed in Table 6Table 6 which includes the desired options to be used, the KeyID for the crypto
key to be used, and the Interrogator random number.
Table 6 — TA.1 Payload for Tag CS
AuthMethod Step OptionsOption KeyID IRandomNumber
#Number of bits 2 2 4 8 48
descriptionDescri
00 00 As desired nn Interrogator random number
b b h
ption
10.2.3 CryptoAuthResp(TA.1 Payload for Interrogator CS)
The Tag shall generate a 48-bit random number for use as TRandomNumber. The Tag crypto engine shall be
initialized for Tag authentication as specified in Clause 9Clause 9 using TRandomNumber, IRandomNumber,
and the crypto key specified by KeyID. The crypto engine shall then generate the Tag keystream
TKeystream[63:0]. The Tag shall respond to the challenge from the Interrogator with the TA.1 Payload for
the Interrogator CS as defineddescribed in Table 7Table 7 which includes the CS features of the Tag, the Tag
random number, and the Tag keystream. The Tag shall transition to the TA.1 state after the response to the
Interrogator and shall set TA = TRUE. Tag authentication Step ‘00 ’ is now complete.
b
Table 7 — TA.1 Payload for Interrogator CS
CSFeatures TRandomNumber TKeystream
#Number of bits 8 48 64
CS features of the Tag Tag random number Tag keystream
descriptionDescr
© ISO/IEC 2025 – All rights reserved
CSFeatures TRandomNumber TKeystream
iption
10.2.4 Final Interrogator Processing
The Interrogator crypto engine shall be initialized for Tag authentication as specified in Clause 9Clause 9
using TRandomNumber, the saved IRandomNumber, and the crypto key specified by KeyID. The crypto
engine shall then generate the Interrogator keystream IKeystream[63:0]. The Interrogator shall use
IKeystream and TKeystream to authenticate the Tag and accepts the Tag as valid if TKeystream[63:0] =
IKeystream[63:0].
10.3 Interrogator Authentication (IA)
10.3.1 General
The Interrogator authentication method uses a challenge-response protocol having two pairs of message
exchange as shown in Figure 3Figure 3. The Grain-128A CS is initialized using a crypto key specified by the
Interrogator and an IV consisting of a 96-bit random number. The Interrogator and Tag each provide half of
the bits used to generate the IV. Once the Grain-128A CS is initialized, the resulting keystream from the
Interrogator and the Tag are compared to authenticate the Interrogator. The details of the Interrogator
authentication process are provided in 10.3.2, 10.3.3, 10.3.4 and 10.3.5the following sections.

Figure 3 — IA Message Exchange
10.3.2 CryptoAuthCmd(IA.1 Payload for Tag CS)
The Interrogator shall generate a 48-bit random number for use as IRandomNumber and save it for
subsequent use. The Interrogator shall request a challenge from the Tag using the IA.1 Payload for the Tag
CS as defineddescribed in Table 8Table 8 which includes the KeyID for the crypto key to be used and the
Interrogator random number.
Table 8 — IA.1 Payload for Tag CS
Options
AuthMethod Step KeyID IRandomNumber
Option
#Number of bits 2 2 4 8 48
descriptionDescripti
01b 00b 0000b nnh Interrogator random number
on
10.3.3 CryptoAuthResp(IA.1 Payload for Interrogator CS)
The Tag shall generate a 48-bit random number for use as TRandomNumber in the following IA.1 Payload
for the Interrogator CS. The Tag crypto engine shall be initialized for Interrogator authentication as specified
in Clause 9Clause 9 using TRandomNumber, IRandomNumber, and the crypto key specified by KeyID. The
Tag shall respond with the challenge to the Interrogator with the IA.1 Payload for the Interrogator CS as
defineddescribed in Table 9Table 9 which includes the CS features of the Tag and the Tag random number.
© ISO/IEC 2025 – All rights reserved
The Tag shall transition to the IA.1 state after the response to the Interrogator. Interrogator authentication
Step ‘00 ’ is now complete.
b
Table 9 — IA.1 Payload for Interrogator CS
CSFeatures TRandomNumber
#Number of bits 8 48
descriptionDescrip
CS features of the Tag Tag random number
tion
10.3.4 CryptoAuthCmd(IA.2 Payload for Tag CS)
The Interrogator crypto engine shall be initialized for Interrogator authentication as specified in
Clause 9Clause 9 using TRandomNumber, the saved IRandomNumber, and the crypto key specified by
KeyID. The crypto engine shall then generate the Interrogator keystream IKeystream[63:0]. The
Interrogator shall then respond to the challenge from the Tag with the IA.2 Payload for the Tag CS as
defineddescribed in Table 10Table 10 which includes the desired options to be used, the KeyID for the
crypto key to be used, and the Interrogator keystream. The KeyID value shall be the same as used in the IA.1
Payload for the Tag CS.
Table 10 — IA.2 Payload for Tag CS
OptionsOp
AuthMethod Step KeyID IKeystream
tion
#Number of bits 2 2 4 8 64
descriptionDescri Same as used for Interrogator
01b 01b As desired
ption IA.1 Payload keystream
10.3.5 CryptoAuthResp(IA.2 Payload for Interrogator CS)
The IA.1 state shall process crypto commands from the Tag’s air interface protocol logic only when ERROR =
FALSE. The Tag shall check the crypto command and payload for any error conditions. An error condition
occurs for any CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate command. The Tag shall check
a CryptoAuthCmd payload for any error conditions. An error condition in the payload occurs when
AuthMethod ≠ 01 , Step ≠ 01 , or the KeyID value is not the same as used for the IA.1 payload, or the Options
b b
selected are not supported by the Tag CSFeatures.
If an error condition exists then the Tag crypto engine shall set ERROR = TRUE and remain in the IA.1 state.
If no error condition exists, the Tag crypto engine shall generate the Tag keystream TKeystream[63:0]. The
Tag shall then use IKeystream and TKeystream to authenticate the Interrogator and accepts the Interrogator
as valid if TKeystream[63:0] = IKeystream[63:0]. The Tag shall respond to the Interrogator with the IA.2
Payload for the Interrogator CS as defineddescribed in Table 11Table 11 which includes the status
information whether the Interrogator authentication succeeded or failed. If the Interrogator authentication
succeeded, the Tag shall transition to the IA.2 state after the response to the Interrogator and set IA = TRUE.
Otherwise, the Interrogator authentication failed and the Tag shall transition to the IA.2 state after the
response to the Interrogator and set ERROR = TRUE. Interrogator authentication Step ‘01 ’ is now complete.
b
Table 11 — IA.2 Payload for Interrogator CS
IA Status
#Number of bits 1
0 = OK (succeeded),
descriptionDescriptio
© ISO/IEC 2025 – All rights reserved
IA Status
n 1 = KO (failed)
10.4 Mutual Authentication (MA)
10.4.1 General
The mutual authentication method uses a challenge-response protocol having two pairs of message
exchange as shown in Figure 4Figure 4 and is based on Interrogator authentication first. The Grain-128A CS
is initialized using a crypto key specified by the Interrogator and an IV consisting of a 96-bit random
number. The Interrogator and Tag each provide half of the bits used to generate the IV. Once the Grain-128A
CS is initialized, the resulting keystream from the Interrogator and the Tag are compared to authenticate the
Tag and the Interrogator. The details of the mutual authentication process are provided in 10.4.2, 10.4.3,
10.4.4, 10.4.5 and 10.4.6the following sections.

Figure 4 — MA Message Exchange
10.4.2 CryptoAuthCmd (MA.1 Payload for Tag CS)
The Interrogator shall generate a 48-bit random number for use as IRandomNumber and save it for
subsequent use. The Interrogator shall request a challenge from the Tag using the MA.1 Payload for the Tag
CS as defineddescribed in Table 12Table 12 which includes the KeyID for the crypto key to be used and the
Interrogator random number.
Table 12 — MA.1 Payload for Tag CS
Option
AuthMethod Step sOptio KeyID IRandomNumber
n
#Number of bits 2 2 4 8 48
descriptionDescr
10b 00b 0000b nnh Interrogator random number
iption
10.4.3 CryptoAuthResp(MA.1 Payload for Interrogator CS)
The Tag shall generate a 48-bit random number for use as TRandomNumber in the following MA.1 Payload
for the Interrogator CS. The Tag crypto engine shall be initialized for mutual authentication as specified in
Clause 9Clause 9 using TRandomNumber, IRandomNumber, and the crypto key specified by KeyID. The Tag
shall respond with the challenge to the Interrogator with the MA.1 Payload for the Interrogator CS as
defineddescribed in Table 13Table 13 which includes the CS features of the Tag and the Tag random
number. The Tag shall transition to the MA.1 state after the response to the Interrogator. The Mutual
authentication Step ‘00 ’ is now complete.
b
Table 13 — MA.1 Payload for Interrogator CS
CSFeatures TRandomNumber
© ISO/IEC 2025 – All rights reserved
CSFeatures TRandomNumber
#Number of bits 8 48
descriptionDesc
CS features of the Tag Tag random number
ription
10.4.4 CryptoAuthCmd(MA.2 Payload for Tag CS)
The Interrogator crypto engine shall be initialized for mutual authentication as specified in Clause 9Clause 9
using TRandomNumber, the saved IRandomNumber, and the crypto key specified by KeyID. The crypto
engine shall then generate the Interrogator keystream IKeystream[63:0]. The Interrogator shall then
respond to the challenge from the Tag with the MA.2 Payload for the Tag CS as defineddescribed in
Table 14Table 14 which includes the desired options to be used, the KeyID for the crypto key to be used, and
the Interrogator keystream. The KeyID value shall be the same as used in the MA.1 Payload for the Tag CS.
Table 14 — MA.2 Payload for Tag CS
Options
AuthMethod Step KeyID IKeystream
Option
#Number of bits 2 2 4 8 64
descriptionDesc As Same as used for Interrogator
10 01
b b
ription desired MA.1 Payload keystream
10.4.5 CryptoAuthResp(MA.2 Payload for Interrogator CS)
The MA.1 state shall process crypto commands from the Tag’s air interface protocol logic only when ERROR
= FALSE. The Tag shall check the crypto command and payload for any error conditions. An error condition
occurs for any CryptoCommCmd, CryptoSecCommCmd, or CryptoKeyUpdate command. The Tag shall check
a CryptoAuthCmd payload for any error conditions. An error condition in the payload occurs when
AuthMethod ≠ 10 , Step ≠ 01 , or the KeyID value is not the same as used for the MA.1 payload, or the
b b
Options selected are not supported by the Tag CSFeatures.
If an error condition exists then the Tag crypto engine shall set ERROR = TRUE and remain in the MA.1
state.
If no error condition exists, the Tag crypto engine shall generate the Tag keystream TKeystream[63:0]. The
Tag shall then use IKeystream and TKeystream to authenticate the Interrogator and accepts the Interrogator
as valid if TKeystream[63:0] = IKeystream[63:0].
If the Interrogator is invalid, the Tag shall respond to the Interrogator with the MA.2 Payload for the
Interrogator CS as defineddescribed in Table 15Table 15 with the status information that the Interrogator
authentication failed and not include a Tag keystream. The Tag shall transition to the MA.2 state after the
response to the Interrogator and set ERROR = TRUE. The Mutual authentication Step ‘01 ’ is now complete.
b
If the Interrogator is valid, the Tag crypto engine shall generate a new value for the Tag keystream
TKeystream[127:64]. The Tag shall respond to the Interrogator with the MA.2 Payload for the Interrogator
CS as defineddescribed in Table 15Table 15 with the status information that the Interrogator authentication
succeeded and include the updated Tag keystream for Tag authentication by the Interrogator. The Tag shall
transition to the MA.2 state after the response to the Interrogator and set TA = IA = TRUE. The Mutual
authentication Step ‘01 ’ is now complete.
b
Table 15 — MA.2 Payload for Interrogator CS
IA Status TKeystream
© ISO/IEC 2025 – All rights reserved
IA Status TKeystream
0 when IA failed,
#Number of bits 1
64 when IA succeeded
0 = OK (succeeded),
descriptionDescr
Tag keystream
iption
1 = KO (failed)
10.4.6 Final Interrogator Processing
The Interrogator shall check the authentication status from the Tag and if it is OK, the Interrogator crypto
engine shall generate a new value for the Interrogator keystream IKeystream[127:64]. The Interrogator
shall use TKeystream and the updated IKeystream to authenticate the Tag and accepts the Tag as valid if
TKeystream[127:64] = IKeystream[127:64].
11 Communication
11.1 General
Authentication integrity shall be maintained for an Interrogator authentication and a Mutual authentication.
It is optional to maintain the authentication integrity of a Tag authentication. Authentication integrity shall
be performed using either authenticated communication and/or secure authenticated communication, or
both. A Message Authentication Code (MAC) shall be used to provide the integrity protection. The
Interrogator selects between using a MAC32 or a MAC64 via the Options parameter during the Tag
authentication process in 10.2.210.2.2,, the Interrogator authentication process in 10.3.410.3.4,, or the
mutual authentication process in 10.4.410.4.4.
11.2 Authenticated Communication
Authenticated communication is used for either an air interface protocol command and/or response, or
both, and includes a Message Authentication Code to maintain the integrity of a prior authentication. If a Tag
is authenticated as a result of Tag authentication, then it is at the discretion of the Interrogator to maintain
the integrity of the authentication during subsequent communications with the singulated Tag. The
Interrogator may use authenticated communication but the Interrogator commands to the Tag cannot
provide integrity protection since the Interrogator has not been authenticated. The TA.1 state shall process
crypto responses from the Tag’s air interface protocol logic only when ERROR = FALSE. The Tag shall check
the crypto responses for error conditions. An error condition occurs for any CryptoAuthResp or
CryptoSecCommResp. If an error condition exists then the Tag crypto engine shall set ERROR = TRUE and
remain in the TA.1 state. If no error condition exists, the Tag shall provide integrity protection for the Tag
response in the CryptoCommResp payload. Integrity of the Tag response is shown in Table 17Table 17 and
shall be performed with the addition of an 8-bit value of 00 followed by a MAC generated by the Tag crypto
h
engine MAC generator. The Tag shall remain in the TA.1 state after the response is sent to the Interrogator.
The Interrogator crypto engine MAC generator shall generate a MAC for the Tag response within the
CryptoCommResp payload to authenticate the Tag response. The Interrogator accepts the Tag response as
valid from the authenticated Tag if the MAC from the Tag equals the MAC from the Interrogator.
If an Interrogator is authenticated as a result of Interrogator authentication, then it shall maintain the
integrity of the authentication during subsequent communications with the singulated Tag. Tag replies to the
authenticated Interrogator cannot provide integrity protection since the Tag has not been authenticated.
Integrity of Interrogator commands is shown in Table 16Table 16 and shall be performed by the addition of
an 8-bit value of 00 followed by a MAC generated by the Interrogator crypto engine MAC generator. The
h
IA.2 state shall process crypto commands and responses from the Tag’s air interface protocol logic only
when ERROR = FALSE. The Tag shall check the crypto commands for error conditions. An error condition
occurs for any CryptoAuthCmd, CryptoSecCommCmd, or CryptoKeyUpdate. If an error condition exists then
the Tag crypto engine shall set ERROR = TRUE and remain in the IA.2 state. If no error condition exists, the
© ISO/IEC 2025 – All rights reserved
Tag crypto engine MAC generator shall generate a MAC for the Interrogator command within the
CryptoCommCmd payload to authenticate the Interrogator command. The Tag accepts the Interrogator
command as valid from the authenticated Interrogator if the MAC from the Interrogator equals the MAC
from the Tag. If they are not equal then the Interrogator command is invalid and the Tag crypto engine shall
set ERROR = TRUE and the Tag shall remain in the IA.2 state.
If a Tag and Interrogator are both authenticated as a result of mutual authentication, then both shall
maintain the in
...