ISO/IEC FDIS 29167-10

ISO/IEC JTC 1/SC 31
Date: 2025-04-18
ISO/IEC DIS FDIS 29167-10:2024(en)
ISO/IEC JTC 1/SC 31/WG 4
Secretariat: ANSI
Date: 2025-10-30
Information technology — Automatic identification and data
capture techniques — —
Part 10:
Crypto suite AES-128 security services for air interface
communications
Technologies de l’informationl'information — Techniques automatiques
d’identificationd'identification et de capture de données —
Partie 10: Services de sécurité par suite cryptographique AES-128 pour communications par interface
radio
FDIS stage
Error! Reference source not found.
© ISO/IEC 2025
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 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel.Phone: + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
Error! Reference source not found.
ii
ISO/IEC DIS 29167-10:2024(en)
© ISO/IEC 2024 – All rights reserved
iii
Error! Reference source not found.
Contents Page
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Symbols and abbreviated terms . 5
4 Conformance . 6
4.1 Air interface protocol specific information . 6
4.2 Interrogator conformance and obligations . 7
4.3 Tag conformance and obligations . 7
5 Introduction of the AES-128 crypto suite . 7
6 Parameter definitions . 8
7 Crypto suite state diagram . 9
8 Initialization and resetting . 10
9 Authentication . 10
9.1 General . 10
9.2 Adding custom data to authentication process . 11
9.3 Message and response formatting . 13
9.4 Tag authentication (Method “00” = TAM) . 14
9.5 Interrogator authentication (Method “01” = IAM) . 23
9.6 Mutual authentication (Method “10” = MAM) . 32
10 Communication . 35
11 Key Table and KeyUpdate . 35
Annex A (normative) Crypto suite state transition table . 37
Annex B (normative) Error conditions and error handling . 38
Annex C (normative) Cipher description . 39
Annex D (informative) References for AES test vectors . 43
Annex E (normative) Protocol specific information . 45
Annex F (informative) Examples of messages and responses for the implementation of the
TAM1, TAM2, MAM1 and MAM2 . 53
Bibliography . 63

Error! Reference source not found.
iv
ISO/IEC DIS 29167-10:2024(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 thirdsecond edition cancels and replaces the secondfirst edition (ISO/IEC 29167-10:20175), which
has been technically revised.
The main changes arechange is as follows:
— Requirements requirements in Clause E.4Annex E.4 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 2024 – All rights reserved
v
Error! Reference source not found.
Introduction
Crypto suite only supports encryption on the Tag and uses encryption for “encrypting” messages sent
from the Tag to the Interrogator and “decrypting” messages received from the Interrogator.
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 might
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 ISO and IEC that they are willing to negotiate licenses
under reasonable and non-discriminatory terms and conditions with applicants throughout the world.
In this respect, the statements of the holders of these patent rights are registered with ISO and IEC.
Information on the declared patents may be obtained from:
Impinj, Inc.
Chris Dorio
Chief Strategy and Technology Officer
The latest information on IP that might be applicable to this document can be found at .
Error! Reference source not found.
vi
ISO/IEC DISFDIS 29167-10:20242025(en)
Information technologies — Automatic Identification and data capture — Part 10:
© ISO/IEC 20242025 – All rights reserved
vii
DRAFT International Standard ISO/IEC DIS 29167-10:2024(en)

Information technology — Automatic identification and data capture
techniques —
Part 10:
Crypto suite AES-128 security services for air interface
communications
1 Scope
This document specifies the crypto suite for AES-128 for the ISO/IEC 18000 air interfaces standards for
radio frequency identification (RFID) devices. Its purpose is to provideThis document provides a common
crypto suite for security for RFID devices that might be referred by ISO committees for air interface
standards and application standards.
This document specifies the security services of an AES-128 crypto suite. AES has a fixed block size of
128 bits and a key size of 128 bits, 192 bits or 256 bits. This document uses AES with a fixed key size of
128 bits and is referred to as AES-128.
This document specifies procedures for the authentication of a Tag and or an Interrogator using AES-128
and provides the following features:
— — Tag authentication;
— — Tag authentication allowing authenticated and encrypted reading of part of the Tag’s
memory;
— — Interrogator authentication;
— — Interrogator authentication allowing authenticated and encrypted writing of part of the Tag’s
memory;
— — Mutual authentication.
AIn 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 18000--3:2010, Information technology — Radio frequency identification for item management —
Part 3: Parameters for air interface communications at 13,56 MHz
ISO/IEC 18000-63, Information technology — Radio frequency identification for item management — Part 63:
Parameters for air interface communications at 860 MHz to 930 MHz Type C
© ISO/IEC 2024 – All rights reserved

ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary — Vocabulary
ISO/IEC 29167--1, Information technology — Automatic identification and data capture techniques — Part 1:
Security services for RFID air interfaces
3 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
3.1 Terms and definitions
3.1.1 3.1.1
AES-CMAC-96 (key, data)
cipher-based message authentication code (CMAC) (3.1.13) generation with input data "data", using
initialization vector (3.1.20) "IV" and 128-bit key (3.1.21) "key", truncating the result by using only the 96
most significant bits from the 128-bit CMAC code
3.1.2 3.1.2
AES-DEC (key, data)
advanced encryption standard in Electronic Codebook decryption mode of input data "data" and 128-bit key
(3.1.21) "key"
3.1.3 3.1.3
AES-ENC (key, data)
advanced encryption standard in Electronic Codebook encryption mode of input data "data" and 128-bit key
(3.1.21) "key"
3.1.4 3.1.4
AuthenticationBlock
variable that contains information to verify the authenticity of the Tag or the Interrogator
3.1.5 3.1.5
bit string
ordered sequence of 0s and 1s
3.1.6 3.1.6
block cipher
family of functions and their inverse functions that is parameterized by keys (3.1.21)
Note 1 to entry: The functions map bit strings of a fixed length to bit strings of the same length.
3.1.7 3.1.7
blocksize
number of bits in an input (or output) block of the block cipher (3.1.6)
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
3.1.8 3.1.8
CBC _AES (IV, key, data)
ENC
advanced encryption standard in cipher block chaining encryption mode of input data "data", using
[ ]
initialization vector (3.1.20) "IV" and 128-bit key (3.1.21) "key", according to NIST/SP 800-38A 9
Note 1 to entry: Output blocks (Oi) are obtained from input blocks (Ii) as follows:
— — O = AES-ENC( key, I XOR IV ), and
1 1
— — O = AES-ENC( key, I XOR O ).
n n (n−1)
Note 2 to entry: Clause C.2 Clause C.2 describes the cipher block chaining.
3.1.9 3.1.9
CBC _AES (IV, key, data)
DEC INV
advanced encryption standard in cipher block chaining decryption mode of input data "data", using
[ ]
initialization vector (3.1.20) "IV" and 128-bit key (3.1.21) "key", according to NIST/SP 800-38A 9
Note 1 to entry: Output blocks (Oi) are obtained from input blocks (Ii) as follows:
— — O1 = AES-DEC( key, I1) XOR IV, and
— — O = AES-DEC( key, I ) XOR I ).
n n (n-1)
3.1.10 3.1.10
CBC _AES (IV, key, data)
ENC INV
cipher block chaining in encryption mode using initialization vector (3.1.20) "IV" and 128-bit key (3.1.21)
"key"
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— — O1 = AES-DEC( key, I1 XOR IV ), and
— — On = AES-DEC( key, In XOR O(n-1) ).
3.1.11 3.1.11
CBC _AES (IV, key, data)
DEC
cipher block chaining in decryption mode using initialization vector (3.1.20) "IV" and 128-bit key (3.1.21)
"key"
Note 1 to entry: Output blocks (Oi) are obtained from input blocks (Ii) as follows:
— — O = AES-ENC( key, I ) XOR IV, and
1 1
— — On = AES-ENC( key, In) XOR I(n-1) )
3.1.12 3.1.12
ciphertext
encrypted plaintext (3.1.30)
3.1.13 3.1.13
cipher-based message authentication code
CMAC
algorithm based on a symmetric key (3.1.21)block cipher (3.1.6)
Note 1 to entry: In this document, data is systematically padded with zero bits before computing the MAC, resulting in
the last block of MAC inputs is always complete. Therefore, K1-MAC is always used. It makes the computation of K2-
MAC useless.
© ISO/IEC 20242025 – All rights reserved
Note 2 to entry: The computation of the MAC shall complyconform with the requirements of MAC method 5 in
ISO/IEC 9797-1.
3.1.14 3.1.14
command (message)
data that the Interrogator sends to a Tag with "Message" as parameter
3.1.15 3.1.15
D
number of 128-bit blocks that can be added to the authentication response (3.1.32) as custom data and
header (3.1.19)
3.1.16 3.1.16
data block
block
sequence of bits whose length is the block size of the block cipher (3.1.6)
3.1.17 3.1.17
ENC_key
variable that contains the key (3.1.21) that will beis used for cryptographic confidentiality protection
Note 1 to entry: This variable shall be used for cryptographic confidentiality protection.
3.1.18 3.1.18
H
number of bits of the header (3.1.19)
3.1.19 3.1.19
header
H bits composed of BlockSize (3.1.7,), Offset, Profile and BlockCount
3.1.20
Initialization Vector
3.1.20
initialization vector
IV
input block that some modes of operation (3.1.28) require as an additional initial input
3.1.223.1.21 3.1.21
key
string of bits used by a cryptographic algorithm to transform plaintext (3.1.30) into ciphertext (3.1.12) or
vice versa or to produce a message (3.1.21) authentication code
3.1.233.1.22 3.1.22
KeyID
numerical designator for a single key (3.1.21)
3.1.243.1.23 3.1.23
Key[KeyID].ENC_key
variable that contains the key (3.1.21) that will beis used for encryption
Note 1 to entry: This variable shall be used for encryption.
3.1.253.1.24 3.1.24
Key[KeyID].MAC_key
) that can be used for cryptographic integrity protection
key (3.1.21
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
3.1.263.1.25 3.1.25
MAC_key
variable that contains the key (3.1.21) that will beis used for cryptographic integrity protection
Note 1 to entry: This variable shall be used for cryptographic integrity protection.
3.1.273.1.26 3.1.26
memory profile
start pointer within the Tag’s memory for addressing custom data block (3.1.16)
3.1.283.1.27 3.1.27
message
part of the command that is defined by the crypto suite
3.1.293.1.28 3.1.28
mode of operation
mode
algorithm for the cryptographic transformation of data that features a symmetric key (3.1.21) block cipher
algorithm
3.1.303.1.29 3.1.29
output block
data that is an output of either the forward cipher function or the inverse cipher function of the block cipher
algorithm
3.1.313.1.30 3.1.30
plaintext
ordinary readable text before being encrypted into ciphertext (3.1.12) or after being decrypted from
ciphertext
3.1.323.1.31 3.1.31
reply (response)
data that the Tag returns to the Interrogator with "Response" as parameter
3.1.333.1.32 3.1.32
response
part of the reply (stored or sent) that is defined by the crypto suite
3.1.343.1.33 3.1.33
word
bit string (3.1.5) comprised of 16 bits
3.2 Symbols and abbreviated terms
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CMAC Cipher-based Message Authentication Code
CSI crypto suite identifier
DIV integral part of a division
Field[a:b] selection from a string of bits in Field
NOTE 1 For a > b, selection of a string of bits from the bit string Field. Selection ranges
from bit number a until and including bit number b from the bits of the string in Field, whereby
Field[0] represents the least significant bit. For selecting one single bit from Field a=b.
© ISO/IEC 20242025 – All rights reserved
For example, EXAMPLE 1 Field[2:0] represents the selection of the three least significant
bits of Field.
FIPS Federal Information Processing Standard
IAM Interrogator authentication
IV Initialization Vectorinitialization vector
LSB least significant byte
MAC Message Authentication Code
MAM Mutual Authentication
MPI memory profile indicator
MSB most significant byte
NIST National Institute of Standards and Technology (United States)
RFU reserved for future use
TA Tag authentication
TID Tag-IDentification or Tag IDentifier (depending on context)
UII Unique Identification ID
xxxx binary notation of term "xxxx", where "x" represents a binary digit
b
xxxx hexadecimal notation of term "xxxx", where "x" represents a hexadecimal digit
h
NOTE 2 In this crypto suite, the bytes in the hexadecimal numbers are presented with the
most significant byte at the left and the least significant byte at the right. The bit order per byte
is also presented with the most significant bit at the left and the least significant bit at the right.
For example,EXAMPLE 2 in "ABCDEF" the byte "AB" is the most significant byte and the
byte "EF" is the least significant byte.
|| concatenation of syntax elements, transmitted in the order written (from left to right)
For example, EXAMPLE 3 "123456" || "ABCDEF" results in "123456ABCDEF", where the
byte "12" is the most significant byte and the byte "EF" is the least significant byte.
NOTE 3 This protocol uses the following notational conventions:
— — States and flags are denoted in bold. Some command parameters are also flags; a command parameter
used as a flag will be formatted in bold. Example: (e.g. ready.).
— — Command parameters are underlined. Some flags are also command parameters; a flag used as a
command parameter will be underlined. Example: (e.g. Pointer.).
— — Commands are denoted in italics. Variables are also denoted in italics. Where there mightcan be
confusion between commands and variables, this protocol will make an explicit statement. Example: (e.g. Query.).
4 Conformance
4.1 Air interface protocol specific information
To claim conformance with this document, an Interrogator or Tag shall complyconform with all relevant
clauses of this document, except those marked as “optional”.
The implementation of this crypto suite shall conform to the protocol specific information provided in
Annex EAnnex E. .
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
4.2 Interrogator conformance and obligations
To conform to this document, an Interrogator shall implement the mandatory commands defined in this
document and conform to the relevant part of the ISO/IEC 18000 series.
To conform to this document, an Interrogator can implement any subset of the optional commands defined
in this document.
To conform to 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.
4.3 Tag conformance and obligations
To conform to this document, a Tag shall implement the mandatory commands defined in this document for
the supported types and conform to the relevant part of the ISO/IEC 18000 series.
To conform to this document, a Tag can implement any subset of the optional commands defined in this
document.
To conform to this document, a Tag 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 Introduction of the AES-128 crypto suite
The Advanced Encryption Standard (AES) is an open, royalty-free, symmetric block cipher based on so-
called substitution-permutation networks. AES is highly suitable for efficient implementation in both
software and hardware, including extremely constrained environments such as RFID Tags. The AES cipher is
standardized as ISO/IEC 18033-3.
AES is approved by the National Institute of Standards and Technology (NIST). It was approved as a
standard in 2001 following a 5-year standardization process that involved a number of competing
encryption algorithms and published as FIPS PUB 197 in November 2001.
AES was published, along with design criteria and test vectors, in Reference [8 [2].].
NOTE AES normally uses encryption to encrypt plaintext and decryption to decrypt ciphertext. This crypto suite
uses encryption both to encrypt plaintext as well as to decrypt ciphertext. This allows the use of an encryption-only
implementation on the Tag.
The implementation of this crypto suite shall conform to the algorithm-specific information provided in
Annex CAnnex C. .
References for AES test vectors are provided in Annex DAnnex D.
The implementation of this crypto suite shall conform to the protocol -specific information provided in
Annex EAnnex E. .
© ISO/IEC 20242025 – All rights reserved
Annex FAnnex F provides examples for the implementation of the functionality that is specified in this
document.
6 Parameter definitions
Table 1Table 1 describes all the parameters that are used in this document.
Table 1 — Definition of AES-128 crypto suite parameters
Parameter Description
Parameter used in IResponse of IAM3 Message with the parameters:
AES-DEC(Key[KeyID].ENC_key, C_IAM3[11:0] || Purpose_IAM3[3:0] || IRnd_IAM3[31:0] ||
AuthenticationBlock TChallenge_IAM1[79:0])
This parameter is only introduced to make the content of the IResponse of IAM3 Message
easier to read.
16-bit predefined constant for MAM1 with the value "DA83h"
C_MAM1[15:0]
(for Tag to Interrogator response)
12-bit predefined constant for MAM2 with the value "DA8h"
C_MAM2[11:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM1 with the value "96C5h"
C_TAM1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C5h"
C_TAM2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C0h"
C_TAM2_0[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C1h"
C_TAM2_1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C2h"
C_TAM2_2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C3h"
C_TAM2_3[15:0]
(for Tag to Interrogator response)
12-bit predefined constant for IAM2 with the value "DA8 "
h
C_IAM2[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DA8 "
h
C_IAM3_0[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DA9 "
h
C_IAM3_1[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DAA "
h
C_IAM3_2[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DAB "
h
C_IAM3_3[11:0]
(for Interrogator to Tag response)
CUSTOMDATA(D*128-H) Part of the Tag’s memory that may be included in the authentication process
HEADER(H) Header of H bits preceding the custom data
IChallenge_MAM1[79:0] 80-bit challenge generated by the Interrogator for use in MAM1
IChallenge_TAM1[79:0] 80-bit challenge generated by the Interrogator for use in TAM1
IChallenge_TAM2[79:0] 80-bit challenge generated by the Interrogator for use in TAM2
IRnd_IAM2[31:0] 32-bit random data generated by the Interrogator for use in IAM2
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
Parameter Description
IRnd_IAM3[31:0] 32-bit random data generated by the Interrogator for use in IAM3
Keyset identified by KeyID, consisting of ENC_key for encryption and
Key[KeyID]
(optional) MAC_key for integrity protection
Variable that shall contain the key that will beis used for cryptographic
MAC_key[127:0]
integrity protection
Authentication purpose bits for IAM2
Purpose_IAM2[3:0] If Purpose_IAM2[3:3] = 0b the bits [2:0] are RFU with value 000b
If Purpose_IAM2[3:3] = 1 the bits [2:0] are manufacturer defined
b
Authentication purpose bits for IAM3
Purpose_IAM3[3:0] If Purpose_IAM3[3:3] = 0 the bits [2:0] are RFU with value 000
b b
If Purpose_IAM3[3:3] = 1b the bits [2:0] are manufacturer defined
Authentication purpose bits for MAM2
Purpose_MAM2[3:0] If Purpose_MAM2[3:3] = 0b the bits [2:0] are RFU with value 000b
If Purpose_MAM2[3:3] = 1b the bits [2:0] are manufacturer defined
TChallenge_IAM1[79:0] 80-bit challenge that the Tag generates for use in IAM1
TChallenge_MAM1[79:0] 80-bit challenge that the Tag generates for use in MAM1
TRnd_TAM1[31:0] 32-bit random data provided by the Tag for TAM1
TRnd_TAM2[31:0] 32-bit random data provided by the Tag for TAM2
7 Crypto suite state diagram
The transitions between the crypto suite states are specified in Figure 1Figure 1.
The Tag shall transition from the Start State to the Next State conforming to the requirements specified in
Annex AAnnex A.
a
All variable fields will be reset at power-up.
b
All errors result in a transition to Initial state.
© ISO/IEC 20242025 – All rights reserved
a
All variable fields will be reset at power-up.
b
All errors result in a transition to Initial state.
Figure 1 — Crypto suite Tag state diagram
The Interrogator is considered authenticated only in the IA-OK state.
8 Initialization and resetting
After power-up and after a reset, the crypto suite shall transition into the Initial state.
After the Tag encounters an error condition, it shall transition into the Initial state.
After the Tag encounters an error condition, it may send an error reply to the Interrogator, but in that case
the Tag shall select one Error Conditionerror condition from the list that is specified in Annex BAnnex B.
A transition to Initial state shall also cause a reset of all variables used by the crypto suite.
Implementations of this crypto suite shall assure that all memory used for intermediate results is cleared
after each operation (message-response pair) and after reset.
9 Authentication
9.1 General
This document supports Tag Authentication, Interrogator Authentication and Mutual Authentication. All
functions are implemented using a message-response exchange. This clause describes the details of the
messages and responses that are exchanged between the Interrogator and Tag.
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
All message and response exchanges are listed in Table 2Table 2.
Table 2 — Message and response functions
Command Function
TAM1 message Send Interrogator challenge and request Tag authentication response
TAM1 response Return Tag authentication response
TAM2 message Send Interrogator challenge and request Tag authentication response with custom data
TAM2 response Return Tag authentication response and custom data
IAM1 message Send Interrogator authentication request
IAM1 response Return Tag challenge
IAM2 message Send Interrogator authentication response
IAM2 response Return Interrogator Authentication result
IAM3 message Send Interrogator authentication response plus custom data
IAM3 response Return Interrogator Authentication result
MAM1 message Send Interrogator challenge and request Tag authentication response and challenge
MAM1 response Return Tag authentication response and challenge
MAM2 message Send Interrogator authentication response
MAM2 response Return Interrogator Authentication result
9.2 Adding custom data to authentication process
This document supports including part of the Tag’s memory as custom data to the authentication process.
The custom data may be either protected (protection of integrity and authenticity) and/or encrypted
(confidentiality protection)), or both, with the authentication. The authentication message shall include the
reference KeyID to select an encryption key in Table 27Table 27 (see Clause 11Clause 11).). If protection of
integrity and authenticity of the data is requested, the selected reference KeyID shall also contain a MAC key.
A Tag that supports including custom data in the authentication process shall define at least one and at most
16 memory profiles. All supported addresses or pointers for the memory profiles are specified in
Annex EAnnex E.
The memory profiles may also be linked to a key in Table 27Table 27 that shall be used for the encryption
process to protect the data.
Custom data is specified as a number (1 to 16) of consecutive 16-bit or 64-bit blocks in the Tag's memory.
The custom data block shall be defined by the parameters BlockSize, Profile, Offset and BlockCount. The
mode of operation that shall be used for either the encryption and/or protection of the custom data, or both,
is specified by ProtMode.
BlockSize shall select the size of the custom data block; "0 " specifies custom data in 64-bit blocks, "1 "
b b
specifies custom data as 16-bit blocks.
Profile shall select one of the memory profiles that are supported by the Tag. The memory profiles are
specified in Annex EAnnex E.
Offset specifies a 12-bit offset (in multiples of 16-bit or 64-bit blocks) that needs to be added to the address
that is specified by Profile. Minimum value "000000000000 " corresponds to a zero offset. Maximum value
b
© ISO/IEC 20242025 – All rights reserved
is 111111111111 (decimal 4095). For 16-bit blocks, the maximum bit pointer offset is 16 × 4095 = 65520.
b
For 64-bit blocks, the maximum bit pointer offset is 64 × 4095 = 262080.
BlockCount specifies the 4-bit number of custom data blocks that need to be selected from the offset position
onwards. Minimum value is "0000 ", corresponding to one single block. Maximum binary value is "1111 ",
b b
or decimal 15, corresponds to a maximum number of 16 blocks of custom data that shall be included. If the
number of included bits of the custom data including header is not a multiple of 128 then padding with
zeroes shall be applied to the least significant bits of the last block that has a non-zero block size of less than
128 bits. The Interrogator shall maintain the value of BlockCount for use as part of the MAC verification
process. The Tag manufacturer shall specify the number of custom data blocks that can be included.
NOTE When combined with the values for BlockSize and BlockCount, as well as requiring that all component
blocks are complete, the padding scheme proposed in this document is unambiguous.
HEADER is composed of the concatenation of the BlockSize, Profile, Offset, BlockCount and extra zeroes
padding.
If BlockSize = “0 ”, HEADER is a 64-bit value defined as:
b
HEADER = BlockSize[0:0] || Profile[3:0] || Offset[11:0] || BlockCount[3:0] || 00000000000 || 00000000
b h
If BlockSize = “1 ”, Header is a 32-bit value defined as:
b
HEADER = BlockSize[0:0] || Profile[3:0] || Offset[11:0] || BlockCount[3:0] || 00000000000
b
H represents the number of bits of HEADER. If BlockSize = “0 ”, then H = 64, else H = 32.
b
D represents the number of 128-bit custom data blocks including the header, when present, and is defined
by BlockCount and BlockSize. The minimum value of D shall be 1. The maximum value of D supported by the
Tag is specified by the Tag manufacturer.
If n represents the decimal value of BlockCount (0 to 15), then D is as follows:
— — For TAM2:
— — If BlockSize = 0 and TAM2_Rev=0, then D: = (n+1) DIV 2 + (n+1) MOD2;
b
— — If BlockSize = 1 and TAM2_Rev=0, then D: = (n+8) DIV 8;
b
— — If BlockSize = 0 and TAM2_Rev=1, then D: = (n+2) DIV 2 + (n+2) MOD2;
b
— — If BlockSize = 1 and TAM2_Rev=1, then D: = (n+10) DIV 8;
b
— — For IAM3:
— — If BlockSize = 0 and TAM2_Rev=1, then D: = (n+2) DIV 2 + (n+2) MOD2;
b
— — If BlockSize = 1 and TAM2_Rev=1, then D: = (n+10) DIV 8.
b
CUSTOMDATA(D*128) contains the custom data as a bit string with a length of D*128-H bits (including
padding) for IAM3 and TAM2 command and TAM2_Rev=1.
CUSTOMDATA(D*128) contains the custom data as a bit string with a length of D*128 bits (including
padding) for TAM2 command and TAM2_Rev=0.
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
NOTE Access rights to custom data can be restricted by the specification of the interface. Annex EAnnex E
describes protocol-specific implementations for various modes of the ISO/IEC 18000 series.
ProtMode specifies the mode of operation that shall be used for either the encryption and/or protection of
the custom data. Table 3, or both. Table 3 specifies the mode of operation for either encryption algorithms
and/or message authentication algorithms for the (optional) protection (either authentication and/or
encryption, or both) of custom data, or both.
Table 3 — Supported modes of operation for ProtMode
a
ProtMode[3:0] Description
Plaintext
0000 ((either no integrity and/or confidentiality protection
b
requested, or both)
0001 CBC (encryption only)
b
0010b CMAC (message authentication only)
0011b CBC + CMAC
0100 Reserved for future use
b
…. ….
0111 Reserved for future use
b
1000b Manufacturer defined
…. ….
1111 Manufacturer defined
b
a When a ProtMode is selected that specifies data encryption (ProtMode "0001 " and "0011 "),
b b
the Tag may assert a privilege that makes all memory accessible for the duration of the
execution of the command. See Annex EAnnex E for details of the air interface specific
implementations.
NOTE This document specifies the use of an encryption-only implementation on the Tag.
9.3 Message and response formatting
The functionality of this document is implemented by means of a Command(Message)/(Response) exchange
(see Figure 2Figure 2)) as described in the air interface specification.

Figure 2 — Command(Message)/Response exchange
The "air interface part" of the Tag passes the Message on to the "crypto suite part" of the Tag and returns the
Response from the "crypto suite part" as a Reply to the Interrogator. The crypto suite shall parse the
Messages and process the data based on the value of AuthMethod, which is the first parameter (first two
bits) of all Messages.
Subclauses 9.4Subclauses 9.4, 9.5,, 9.5 and 9.69.6 describe the formatting of Message and Response for Tag
Authentication, Interrogator Authentication and Mutual Authentication. The Messages for Tag
© ISO/IEC 20242025 – All rights reserved
Authentication, Interrogator Authentication and Mutual Authentication shall be distinguished by
AuthMethod.
If AuthMethod = "00 ", the Tag shall parse the Message for Tag Authentication as described in 9.49.4.
b
If AuthMethod = "01 ", the Tag shall parse Message for Interrogator Authentication as described in 9.59.5.
b
If AuthMethod = "10 ", the Tag shall parse Message for Mutual Authentication as described in 9.69.6.
b
If AuthMethod = "11 ", then the Tag shall return a "Not Supported" error condition.
b
9.4 Tag authentication (Method “00” = TAM)
9.4.1 General
Tag Authentication allows an Interrogator to authenticate a Tag by verifying the Tag’s secret key with the
TAM1 response. Optionally, the Tag may return part of its memory as custom data, which may be either
protected (protection of integrity, authenticity of origin and timeliness) and/or encrypted (confidentiality
protection), or both, with the TAM2 response.
Tag authentication only is implemented in TAM1 and Tag authentication with the addition of custom data is
implemented as TAM2.
The TAM Messages are distinguished by the value of CustomData, which is the second parameter (third bit)
of both TAM Messages.
If CustomData = "0 ", the Tag shall parse the TAM1 Message for Tag Authentication without custom data as
b
described in 9.4.29.4.2.
If CustomData = "1 ", the Tag shall parse the TAM2 Message for Tag Authentication with custom data as
b
described in 9.4.59.4.5.
9.4.2 TAM1 Message
For Tag authentication, the Interrogator shall generate an 80-bit random TAM1 Interrogator challenge and
include that in the TAM1 message. The TAM1 message shall also include the reference KeyID to select an
encryption key in Table 27Table 27 (see Clause 11Clause 11).).
The TAM1 Message format is specified in Table 4Table 4 and has the following parameters:
— — AuthMethod: value "00 " specifies the use for TAM;
b
— — CustomData: flag with value "0 " to indicate that no custom data is requested (TAM1);
b
— — TAM1_RFU: value "00000 " makes the total length of the TAM1 Message a multiple of 8-bits
b
and mightcan be used for future extensions of this document;
— — KeyID: 8-bit value that specifies the key that shall be used for TAM1;
— — IChallenge_TAM1: 80-bit random challenge that the Interrogator has generated for use in
TAM1.
Table 4 — TAM1 Message format
AuthMethod CustomData TAM1_RFU KeyID IChallenge_TAM1
© ISO/IEC 2025 – All rights reserved
ISO/IEC DISFDIS 29167-10:20242025(en)
AuthMethod CustomData TAM1_RFU KeyID IChallenge_TAM1
#Number of
2 1 5 8 80
bits
random Interrogator
Description 00b 0b 00000b [7:0]
challenge
The Tag shall accept this message in any state. If the value of the parameters of the message are invalid, then
the Tag shall transition to the Initial state, thereby aborting any cryptographic protocol that has not yet
been completed.
If the length of the TAM1 message is <> 96 bits, then the Tag shall return an "Other Error" error condition.
If TAM1_RFU[4:0] is <> "00000 ", then the Tag shall return a "Not Supported" error condition.
b
If the Tag does not support key[KeyID].ENC_key, then the Tag shall return a "Not Supported" error condition.
9.4.3 TAM1 Response
If all parameters have been successful verified, then the Tag shall generate a response as specified in
Table 5Table 5. The Tag shall generate the random data TRnd_TAM1[31:0] and encrypt the concatenation of
the constant C_TAM1[15:0], the random data TRnd_TAM1[31:0] and the challenge IChallenge_TAM1[79:0]
using Key[KeyID].ENC_key.
Table 5 — TAM1 Response
TResponse
#Number of
bits
AES-ENC( Key[KeyID].ENC_key, C_TAM1[15:0] ||
Description
TRnd_TAM1[31:0] || IChallenge_TAM1[79:0] )
After returning the TAM1 Response (TResponse), the Tag shall remain in the Initial state.
9.4.4 Final Interrogator processing TAM1
The Interrogator (or the external application controlling the Interrogator) decrypts the TAM1 Response
(TResponse) and shall verify whether C_TAM1 and IChallenge_TAM1 have the correct value. If the values are
correct, then the Tag can be considered as authentic.
9.4.5 TAM2 Message
TAM2 is used for Tag Authentication if the Tag needs to return part of its memory as custom data. The
custom data is specified in 9.29.2 and may be either protected (protection of integrity and authenticity of
origin) and/or decrypted (confidentiality protection).), or both.
The Interrogator shall generate an 80-bit random number for use as TAM2 Interrogator challenge.
The TAM2 Message format is specified in Table 6Table 6 and has the following parameters:
— — AuthMethod[1:0]: value "00 " specifies the use for TAM;
b
— — CustomData[0:0
...