ISO/IEC 29167-13:2026

International
Standard
ISO/IEC 29167-13
Second edition
Information technology —
2026-03
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
Reference number
© ISO/IEC 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
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 .2
5 Conformance . 2
5.1 Air interface protocol specific information .2
5.2 Interrogator conformance and obligations .2
5.3 Tag conformance and obligations .2
6 Overview of the Grain-128A crypto suite . 3
7 Parameter description . 3
8 Crypto suite state diagram . 4
9 Initialization and resetting . 6
10 Authentication . 7
10.1 General .7
10.2 Tag authentication .8
10.2.1 General .8
10.2.2 CryptoAuthCmd(TA.1 Payload for Tag CS) .8
10.2.3 CryptoAuthResp(TA.1 Payload for Interrogator CS) .9
10.2.4 Final interrogator processing .9
10.3 Interrogator authentication .9
10.3.1 General .9
10.3.2 CryptoAuthCmd(IA.1 Payload for Tag CS) .9
10.3.3 CryptoAuthResp(IA.1 Payload for Interrogator CS) .10
10.3.4 CryptoAuthCmd(IA.2 Payload for Tag CS) .10
10.3.5 CryptoAuthResp(IA.2 Payload for Interrogator CS) .10
10.4 Mutual authentication .11
10.4.1 General .11
10.4.2 CryptoAuthCmd (MA.1 Payload for Tag CS) .11
10.4.3 CryptoAuthResp(MA.1 Payload for Interrogator CS) .11
10.4.4 CryptoAuthCmd(MA.2 Payload for Tag CS) .11
10.4.5 CryptoAuthResp(MA.2 Payload for Interrogator CS) . 12
10.4.6 Final interrogator processing . 12
11 Communication .12
11.1 General . 12
11.2 Authenticated communication . 13
11.3 Secure authenticated communication .14
12 Key table and key update .15
Annex A (normative) State transitions .16
Annex B (normative) Error conditions and error handling .20
Annex C (normative) Cipher description .21
Annex D (informative) Test vectors .24
Annex E (normative) Protocol specific information .31
Bibliography .39

© ISO/IEC 2026 – 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.
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
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 change is as follows: requirements in Annex 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 2026 – All rights reserved
iv
Introduction
This document provides a common crypto suite for security for radio frequency identification (RFID)
devices. The crypto suite is defined in alignment with existing air interfaces and specifies a variety of
security services provided by the lightweight stream cipher Grain-128A.
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 2026 – All rights reserved
v
International Standard ISO/IEC 29167-13:2026(en)
Information technology — Automatic identification and data
capture techniques —
Part 13:
Crypto suite Grain-128A security services for air interface
communications
1 Scope
This document specifies the crypto suite for Grain-128A for the ISO/IEC 18000 air interface standards for
radio frequency identification (RFID) devices.
This document specifies various authentication methods and methods of use for the cipher.
In this document, 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 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 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Vocabulary
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

© ISO/IEC 2026 – All rights reserved
4.2 Abbreviated terms
CRC cyclic redundancy check
CS crypto suite
CSI crypto suite identifier
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 Air interface protocol specific information
The Interrogator or Tag shall conform with all relevant clauses of this document, except those marked as
“optional”.
5.2 Interrogator conformance and obligations
An Interrogator shall implement the mandatory commands described in this document and conform to the
relevant part of the ISO/IEC 18000 series.
An Interrogator can implement any subset of the optional commands described in this document.
The Interrogator shall not:
— implement any command that conflicts with this document; or
— require the use of an optional, proprietary or custom command to meet the requirements of this
document.
5.3 Tag conformance and obligations
A Tag shall implement the mandatory commands described in this document for the supported types and
conform to the relevant part of the ISO/IEC 18000 series.
A Tag can implement any subset of the optional commands described in this document.
A Tag shall not:
— implement any command that conflicts with this document; or

© ISO/IEC 2026 – All rights reserved
— require the use of an optional, proprietary or custom command to meet the requirements of this
document.
6 Overview of the Grain-128A crypto suite
Many stream ciphers have been proposed over the years and new designs are published as cryptanalysis
[6]
enhances our understanding of how to design safer and more efficient primitives. While the NESSIE
project failed to name a stream cipher “winner” after evaluating several new designs in 2000-2003, the
[7]
eSTREAM project finally decided on two portfolios of promising candidates. One of these portfolios was
[8]
aimed at hardware attractive constructions and Grain is one of three finalists.
Grain is notable for its extremely small hardware representation. During the initial phase of the eSTREAM
[9]
project, the original version, Grain v0, was strengthened after some observations. 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
[10]
keys and 96-bit IVs was proposed. 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.
[11]
A new version of Grain-128, namely Grain-128A, has been established. 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
Annex C although it is also specified in ISO/IEC 29192-8.
Error conditions for this crypto suite shall be handled in accordance with Annex B.
The cryptographic engine in this crypto suite shall be in accordance with Annex C.
Test vectors for parts of this document are provided in Annex D.
Over-the-air protocol commands that use this crypto suite shall be in accordance with Annex E.
7 Parameter description
Table 1 describes all the parameters that are used in this document.

© ISO/IEC 2026 – All rights reserved
Table 1 — Grain-128A crypto suite parameters
Parameter Description
AuthMethod[1:0] Authentication method specified by the Interrogator to be used by the Tag
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 Crypto suite state diagram
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 A.

© ISO/IEC 2026 – 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 MAC for authenticating the CryptoSecCommCmd and the CryptoSecCommResp shall be encrypted and generate a
MAC for use in the CryptoSecCommResp.

© ISO/IEC 2026 – All rights reserved
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 ,
b
— the KeyID value is not supported by the Tag,
— AuthMethod = 00 and the Tag does not support Tag authentication,
b
— AuthMethod = 00 and the Options selected are not supported by the Tag CSFeatures,
b
— AuthMethod = 01 and the Tag does not support Interrogator authentication,
b
— AuthMethod = 01 and Options ≠ 0000 , or AuthMethod = 10 and Options ≠ 0000 , or
b b b b
— AuthMethod = 11 and the Tag does not support a vendor described authentication.
b
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 the IV bits IV , 0 ≤ i ≤ 95.
i i
— The IV shall be generated using IRandomNumber and TRandomNumber such that 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
i i
are loaded with a one and the IV bits, s = 1 s = IV , 1 ≤ i ≤ 95. The last 32 bits of the LFSR are filled with
0 i i
2 bits for authentication information followed by ones and a zero, s = Tag being authenticated, s =
96 97
Interrogator being authenticated, s = 1, 98 ≤ i ≤ 126, s = 0.
i 127
— Then, the cipher is clocked 256 times without producing any keystream.
— 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.

© ISO/IEC 2026 – All rights reserved
10 Authentication
10.1 General
A primary use for the Grain-128A CS is to perform authentication of Tags or Interrogators, or both. The
authentication method to be performed shall be specified by the 2-bit value AuthMethod[1:0] which
is described in Table 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 described in Table 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 described in Table 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 authentication method, the Interrogator shall provide a 4-bit
value Options[3:0] which is described in Table 4 and used to indicate which optional features should be used
by the Tag.
Table 2 — Description of AuthMethod[1:0]
Value Description
00 Tag authentication
b
01 Interrogator authentication
b
10 Mutual authentication
b
11 Vendor defined
b
Table 3 — Description of Step[1:0]
Value Description
00 Step 0
b
01 Step 1
b
10 Step 2
b
11 Step 3
b
Table 4 — 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
© ISO/IEC 2026 – All rights reserved
Table 5 — 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,
1 = TA supported
10.2 Tag authentication
10.2.1 General
The Tag authentication method uses a challenge-response protocol having one pair of message exchange
as shown in Figure 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.4.
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
described in Table 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 Option KeyID IRandomNumber
Number of bits 2 2 4 8 48
Description 00 00 As desired nn Interrogator random number
b b h
© ISO/IEC 2026 – All rights reserved
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 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 described in Table 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
Description CS features of the Tag Tag random number Tag keystream
10.2.4 Final interrogator processing
The Interrogator crypto engine shall be initialized for Tag authentication as specified in Clause 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
10.3.1 General
The Interrogator authentication method uses a challenge-response protocol having two pairs of message
exchange as shown in Figure 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.5.
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 described in Table 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
AuthMethod Step Option KeyID IRandomNumber
Number of bits 2 2 4 8 48
Description 01 00 0000 nn Interrogator random number
b b b h
© ISO/IEC 2026 – All rights reserved
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 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 described in
Table 9 which includes the CS features of the Tag and the Tag random number. 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
Description CS features of the Tag Tag random number
10.3.4 CryptoAuthCmd(IA.2 Payload for Tag CS)
The Interrogator crypto engine shall be initialized for Interrogator authentication as specified in Clause 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 described in Table 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
AuthMethod Step Option KeyID IKeystream
Number of bits 2 2 4 8 64
Description 01 01 As desired Same as used for IA.1 Payload Interrogator keystream
b b
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 , 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, 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 described in Table 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
Description 0 = OK (succeeded), 1 = KO (failed)

© ISO/IEC 2026 – All rights reserved
10.4 Mutual authentication
10.4.1 General
The Mutual authentication method uses a challenge-response protocol having two pairs of message
exchange as shown in Figure 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.6.
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 described in Table 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
AuthMethod Step Option KeyID IRandomNumber
Number of bits 2 2 4 8 48
Description 10 00 0000 nn Interrogator random number
b b b h
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 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 described
in Table 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
Number of bits 8 48
Description CS features of the Tag Tag random number
10.4.4 CryptoAuthCmd(MA.2 Payload for Tag CS)
The Interrogator crypto engine shall be initialized for Mutual authentication as specified in Clause 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 described in Table 14 which includes

© ISO/IEC 2026 – All rights reserved
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
AuthMethod Step Option KeyID IKeystream
Number of bits 2 2 4 8 64
Description 10 01 As desired Same as used for MA.1 Payload Interrogator keystream
b b
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 , the KeyID value is not the same as the one used for the MA.1 payload or the
b b
Options selected are not supported by the Tag CSFeatures.
If an error condition exists, 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 described in Table 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 described in Table 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
Number of bits 1 0 when IA failed, 64 when IA succeeded
Description 0 = OK (succeeded), 1 = KO (failed) Tag keystream
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 or secure authenticated communication, or both.
A MAC shall be used to provide the integrity protection. The Interrogator selects between using a MAC32

© ISO/IEC 2026 – All rights reserved
or a MAC64 via the Options parameter during the Tag authentication process in 10.2.2, the Interrogator
authentication process in 10.3.4 or the Mutual authentication process in 10.4.4.
11.2 Authenticated communication
Authenticated communication is used for either an air interface protocol command 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 17 and shall be performed with
the addition of an 8-bit value of 00 followed by a MAC generated by the Tag crypto engine MAC generator.
h
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 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 IA.2 state
h
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
...