ISO/IEC 29167-13:2015

INTERNATIONAL ISO/IEC
STANDARD 29167-13
First edition
2015-05-15
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
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. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Conformance . 1
2.1 Claiming conformance . 1
2.2 Interrogator conformance and obligations . 1
2.3 Tag conformance and obligations . 1
3 Normative references . 2
4 Terms and definitions . 2
5 Symbols and abbreviated terms . 2
5.1 Symbols . 2
5.2 Abbreviated terms . 2
6 Cipher introduction . 3
7 Parameter definition . 3
8 State diagram . 4
9 Initialization and resetting . 5
10 Authentication . 5
10.1 General . 5
10.2 Tag Authentication (TA) . 7
10.2.1 General. 7
10.2.2 CryptoAuthCmd(TA.1 Payload for Tag CS) . 7
10.2.3 CryptoAuthResp(TA.1 Payload for Interrogator CS) . 7
10.2.4 Final Interrogator Processing . 7
10.3 Interrogator Authentication (IA). 8
10.3.1 General. 8
10.3.2 CryptoAuthCmd(IA.1 Payload for Tag CS) . 8
10.3.3 CryptoAuthResp(IA.1 Payload for Interrogator CS) . 8
10.3.4 CryptoAuthCmd(IA.2 Payload for Tag CS) . 9
10.3.5 CryptoAuthResp(IA.2 Payload for Interrogator CS) . 9
10.4 Mutual Authentication (MA) . 9
10.4.1 General. 9
10.4.2 CryptoAuthCmd (MA.1 Payload for Tag CS) .10
10.4.3 CryptoAuthResp(MA.1 Payload for Interrogator CS) .10
10.4.4 CryptoAuthCmd(MA.2 Payload for Tag CS) .10
10.4.5 CryptoAuthResp(MA.2 Payload for Interrogator CS) .11
10.4.6 Final Interrogator Processing .11
11 Communication .11
11.1 General .11
11.2 Authenticated Communication .12
11.3 Secure Authenticated Communication .13
12 Key table and key update .14
Annex A (normative) State transition tables .15
Annex B (normative) Error conditions and error handling .19
Annex C (normative) Cipher description .20
Annex D (informative) Test vectors .23
Annex E (normative) Protocol specific .30
© ISO/IEC 2015 – All rights reserved iii

Bibliography .39
iv © ISO/IEC 2015 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. 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, 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: Security services for RFID air interfaces
— Part 10: Crypto suite AES-128 security services for air interface communications
— Part 11: Crypto suite PRESENT-80 security services for air interface communications
— Part 12: Crypto suite ECC-DH security services for air interface communications
— Part 13: Crypto suite Grain-128A security services for air interface communications
— Part 14: Crypto suite AES OFB security services for air interface communications
— Part 16: Crypto suite ECDSA-ECDH security services for air interface communications
— Part 17: Crypto suite cryptoGPS security services for air interface communications
— Part 19: Crypto suite RAMON security services for air interface communications
The following part is under preparation:
— Part 15: Crypto suite XOR security services for air interface communications
© ISO/IEC 2015 – All rights reserved v

Introduction
This part of ISO/IEC 29167 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).
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 www.
iso.org/patents.
vi © ISO/IEC 2015 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29167-13:2015(E)
Information technology — Automatic identification and
data capture techniques —
Part 13:
Crypto suite Grain-128A security services for air interface
communications
1 Scope
This part of ISO/IEC 29167 defines the Crypto Suite for Grain-128A for the ISO/IEC 18000 air interface
standards for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto
suite for security for RFID devices that might be referred by ISO committees for air interface standards
and application standards
This part of ISO/IEC 29167 specifies a crypto suite for Grain-128A for air interface for RFID systems. The
crypto suite is defined in alignment with existing air interfaces.
This part of ISO/IEC 29167 defines various authentication methods and methods of use for the cipher. A
tag and an interrogator might support one, a subset, or all of the specified options, clearly stating what
is supported.
2 Conformance
2.1 Claiming conformance
To claim conformance with this part of ISO/IEC 29167, an Interrogator or 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 commands 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 can
— implement any subset of the optional commands defined in this part of ISO/IEC 29167.
To conform to this part of ISO/IEC 29167, the Interrogator shall not
— implement any command that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom command to meet the requirements of this
part of ISO/IEC 29167.
2.3 Tag conformance and obligations
To conform to this part of ISO/IEC 29167, a Tag shall
— implement the mandatory commands defined in this part of ISO/IEC 29167 for the supported types
and conform to the relevant part of ISO/IEC 18000.
© ISO/IEC 2015 – All rights reserved 1

To conform to this part of ISO/IEC 29167, a Tag can
— implement any subset of the optional commands defined in this part of ISO/IEC 29167.
To conform to this part of ISO/IEC 29167, a Tag shall not
— implement any command that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom command 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 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
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 (all parts) apply.
5 Symbols and abbreviated terms
5.1 Symbols
xxxx binary notation
b
xxxx hexadecimal notation
h
|| concatenation of syntax elements in the order written
5.2 Abbreviated terms
CRC Cyclic Redundancy Check
CS Cryptographic Suite
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
2 © ISO/IEC 2015 – All rights reserved

NFSR Nonlinear Feedback Shift Register
RFU Reserved for Future Use
TA Tag Authentication
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
project failed to name a stream cipher “winner” after evaluating several new designs in 2000-2003, the
[2]
eSTREAM project finally decided on two portfolios of promising candidates. One of these portfolios
[3]
was 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
[4]
eSTREAM 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
[5]
128-bit 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.
[6]
A new version of Grain-128, namely Grain-128A, has been specified . 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.
7 Parameter definition
Table 1 — Definition of 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
© ISO/IEC 2015 – All rights reserved 3

8 State diagram
external reset
INIT=FALSE
TA =FALSE
IA =FALSE
ERROR =FALSE
CS-Reset
Note 1
[INIT = FALSE and
TA =FALSE and
IA =FALSE and
ERROR = FALSE and
[CryptoAuthCmd(TA.1) or
CryptoAuthCmd(IA.1) or
CryptoAuthCmd(MA.1)]]
CS-Init
CryptoAuthCmd(TA.1) CryptoAuthCmd(MA.1)
INIT =TRUE
CryptoAuthResp(TA.1)
Note 2 CryptoAuthResp(MA.1)
CryptoAuthCmd(IA.1)
CryptoAuthResp(IA.1)
TA.1
IA.1 MA.1
Step 00 Complete
b
Step 00 Complete Step 00 Complete
b b
TA =TRUE
Note 4 Note 5
Note 3
ERROR = FALSE ERROR= FALSE
If ERROR =FALSE
CryptoAuthCmd(IA.2) CryptoAuthCmd(MA.2)
Generate MAC for CryptoAuthResp(IA.2) CryptoAuthResp(MA.2)
CryptoCommResp
IA.2 MA.2
Step 01 Complete Step 01 Complete
b b
If IA successful, If IA successful,
then IA =TRUE, else then TA =IA= TRUE,
ERROR =TRUE else ERROR = TRUE
Note 6 Note 7
If ERROR =FALSE
Validate MAC for
If ERROR = FALSE
CryptoCommCmd If ERROR = FALSE
Validate MAC for
Decryption of
CryptoCommCmd
CryptoSecCommCmd
CryptoSecCommCmd
Encryption of
Generate MAC for
CryptoSecCommResp
CryptoCommResp
CryptoSecCommResp
Note 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.
Note 2. Initialization of the keystream generator and MAC generator shall be performed as described in Section 9.
Note 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.
Note 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.
Note 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.
Note 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.
Note 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.
Figure 1 — Tag Crypto Engine State Diagram
The state-transition tables are provided in Annex A.
4 © ISO/IEC 2015 – All rights reserved

9 Initialization and resetting
The Tag’s air interface protocol logic shall provide an external reset to the Tag crypto engine which shall
set 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
b b
does not support Tag authentication, or AuthMethod = 00 and the Options selected are not supported
b
by the Tag CSFeatures, or AuthMethod = 01 and the Tag does not support Interrogator authentication,
b
or AuthMethod = 01 and Options ≠ 0000 , or AuthMethod = 10 and Options ≠ 0000 , or AuthMethod =
b b b b
11 and the Tag does not support a vendor defined 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 ≤
i
127 and the IV bits IV , 0 ≤ i ≤ 95. The IV shall be generated using IRandomNumber and TRandomNumber
i
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 are loaded with a one and the IV bits,
i i
s = 1 s = IV , 1 ≤ i ≤ 95. The last 32 bits of the LFSR are filled with 2 bits for authentication information
0 i i
followed by ones and a zero, s = Tag being authenticated, s = Interrogator being authenticated, s =
96 97 i
1, 98 ≤ i ≤ 126, s = 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 defined 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 defined 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 defined 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 defined in Table 4 and used to indicate which optional
features should be used by the Tag.
© ISO/IEC 2015 – All rights reserved 5

Table 2 — Definition of AuthMethod[1:0]
Value Description
00 Tag authentication
b
01 Interrogator authentication
b
10 Mutual authentication
b
11 Vendor defined
b
Table 3 — Definition of Step[1:0]
Value Description
00 Step 0
b
01 Step 1
b
10 Step 2
b
11 Step 3
b
Table 4 — Definition 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 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
6 © ISO/IEC 2015 – All rights reserved

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 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 the following sections.
CryptoAuthCmd(TA.1 Payload for Tag CS)
CryptoAuthResp (TA.1 Payload for Interrogator CS )
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 defined 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 Options KeyID IRandomNumber
# of bits 2 2 4 8 48
description 00 00 As desired nn Interrogator random number
b b h
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 defined 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
# 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
© ISO/IEC 2015 – All rights reserved 7
Interrogator
Tag
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 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 the following sections.
CryptoAuthCmd(IA.1 Payload for Tag CS)
CryptoAuthResp (IA.1 Payload for Interrogator CS)
CryptoAuthCmd(IA.2 Payload for Tag CS)
CryptoAuthResp (IA.2 Payload for Interrogator CS)
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 defined 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 Options KeyID IRandomNumber
# of bits 2 2 4 8 48
description 01 00 0000 nn Interrogator random number
b b b h
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 defined 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
# of bits 8 48
description CS features of the Tag Tag random number
8 © ISO/IEC 2015 – All rights reserved
Interrogator
Tag
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 defined 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 Options KeyID IKeystream
# of bits 2 2 4 8 64
Same as
used for
description 01 01 As desired Interrogator keystream
b b
IA.1 Pay-
load
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
b b
payload, or the 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 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 defined 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
b
now complete.
Table 11 — IA.2 Payload for Interrogator CS
IA Status
# of bits 1
0 = OK (succeeded),
description
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 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
© ISO/IEC 2015 – All rights reserved 9

authenticate the Tag and the Interrogator. The details of the mutual authentication process are provided
in the following sections.
CryptoAuthCmd(MA.1 Payload for Tag CS)
CryptoAuthResp (MA.1 Payload for Interrogator CS)
CryptoAuthCmd(MA.2 Payload for Tag CS)
CryptoAuthResp (MA.2 Payload for Interrogator CS)
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 defined 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 Options KeyID IRandomNumber
# 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 defined 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. Mutual authentication Step
‘00 ’ is now complete.
b
Table 13 — MA.1 Payload for Interrogator CS
CSFeatures TRandomNumber
# 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 defined in Table 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
10 © ISO/IEC 2015 – All rights reserved
Interrogator
Tag
Table 14 — MA.2 Payload for Tag CS
AuthMethod Step Options KeyID IKeystream
# of bits 2 2 4 8 64
Same as used
description 10 01 As desired for MA.1 Pay- Interrogator keystream
b b
load
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
b b
payload, or the 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 defined 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. 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 defined 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. Mutual
authentication Step ‘01 ’ is now complete.
b
Table 15 — MA.2 Payload for Interrogator CS
IA Status TKeystream
0 when IA failed,
# of bits 1
64 when IA succeeded
0 = OK (succeeded),
description Tag keystream
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.
© ISO/IEC 2015 – All rights reserved 11

Authentication integrity shall be performed using authenticated communication and/or secure
authenticated communication. 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.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 an air interface protocol command and/or response 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 Ta
...