ISO/IEC 29167-10:2026

International
Standard
ISO/IEC 29167-10
Third edition
Information technology —
2026-03
Automatic identification and data
capture techniques —
Part 10:
Crypto suite AES-128 security
services for air interface
communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 10: Services de sécurité par suite cryptographique AES-128
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 .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 .5
3.3 Abbreviated terms .5
4 Conformance . 6
4.1 Air interface protocol specific information .6
4.2 Interrogator conformance and obligations .6
4.3 Tag conformance and obligations .6
5 Overview of the AES-128 crypto suite . 7
6 Parameter description . 7
7 Crypto suite state diagram . 8
8 Initialization and resetting . 9
9 Authentication . 9
9.1 General .9
9.2 Adding custom data to authentication process .10
9.3 Message and response formatting . 12
9.4 Tag authentication (Method “00” = TAM). 12
9.4.1 General . 12
9.4.2 TAM1 Message . 13
9.4.3 TAM1 Response . 13
9.4.4 Final Interrogator processing TAM1 .14
9.4.5 TAM2 Message .14
9.4.6 TAM2 Response .16
9.4.7 Final Interrogator processing TAM2 .19
9.5 Interrogator authentication (Method “01” = IAM) . 20
9.5.1 General . 20
9.5.2 IAM1 Message . 20
9.5.3 IAM1 Response . 20
9.5.4 Final Interrogator processing IAM1 .21
9.5.5 IAM2 Message .21
9.5.6 IAM2 Response . 22
9.5.7 Final Interrogator processing IAM2 . 22
9.5.8 IAM3 Message . 22
9.5.9 IAM3 Response .27
9.5.10 Final Interrogator processing IAM3 .27
9.6 Mutual authentication (Method “10” = MAM) .27
9.6.1 General .27
9.6.2 MAM1 Message .27
9.6.3 MAM1 Response . 28
9.6.4 Final Interrogator processing MAM1 . 28
9.6.5 MAM2 Message . 29
9.6.6 MAM2 Response . 29
9.6.7 Final Interrogator processing MAM2 . 30
10 Communication .30
11 Key Table and KeyUpdate .30

© ISO/IEC 2026 – All rights reserved
iii
Annex A (normative) Crypto suite state transitions .32
Annex B (normative) Error conditions and error handling .33
Annex C (normative) Cipher description .34
Annex D (informative) References for AES test vectors .38
Annex E (normative) Protocol specific information .39
Annex F (informative) Examples of messages and responses for the implementation of the
TAM1, TAM2, MAM1 and MAM2 .46
Bibliography .54

© ISO/IEC 2026 – All rights reserved
iv
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 third edition cancels and replaces the second edition (ISO/IEC 29167-10:2017), which has been
technically revised.
The main change is as follows: requirements in Clause 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 2026 – All rights reserved
v
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 symmetric block cipher AES-128.
A crypto suite only supports the encryption on the Tag and use the encryption for “encrypting” messages
sent from the Tag to the Interrogator and “decrypting” messages received from the Interrogator.

© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 29167-10:2026(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 interface standards for radio
frequency identification (RFID) devices.
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.
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 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 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Vocabulary
ISO/IEC 29167-1, Information technology — Automatic identification and data capture techniques — Part 1:
Security services for RFID air interfaces

© ISO/IEC 2026 – All rights reserved
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
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
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
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
AuthenticationBlock
variable that contains information to verify the authenticity of the Tag or the Interrogator
3.1.5
bit string
ordered sequence of 0s and 1s
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
blocksize
number of bits in an input (or output) block of the block cipher (3.1.6)
3.1.8
CBC _AES (IV, key, data)
ENC
advanced encryption standard in cipher block chaining encryption mode of input data "data", using
[9]
initialization vector (3.1.20) "IV" and 128-bit key (3.1.21) "key", according to NIST/SP 800-38A
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— 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 describes cipher block chaining.

© ISO/IEC 2026 – All rights reserved
3.1.9
CBC _AES (IV, key, data)
DEC INV
advanced encryption standard in cipher block chaining decryption mode of input data "data", using
[9]
initialization vector (3.1.20) "IV" and 128-bit key (3.1.21) "key", according to NIST/SP 800-38A
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-DEC( key, I ) XOR IV, and
1 1
— O = AES-DEC( key, I ) XOR I ).
n n (n-1)
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
— O = AES-DEC( key, I XOR IV ), and
1 1
— O = AES-DEC( key, I XOR O ).
n n (n-1)
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 (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-ENC( key, I ) XOR IV, and
1 1
— O = AES-ENC( key, I ) XOR I )
n n (n-1)
3.1.12
ciphertext
encrypted plaintext (3.1.30)
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.
Note 2 to entry: The computation of the MAC shall conform with the requirements of MAC method 5 in ISO/IEC 9797-1.
3.1.14
command (message)
data that the Interrogator sends to a Tag with "Message" as parameter
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
data block
block
sequence of bits whose length is the block size of the block cipher (3.1.6)

© ISO/IEC 2026 – All rights reserved
3.1.17
ENC_key
variable that contains the key (3.1.21) that is used for cryptographic confidentiality protection
Note 1 to entry: This variable shall be used for cryptographic confidentiality protection.
3.1.18
H
number of bits of the header (3.1.19)
3.1.19
header
H bits composed of BlockSize (3.1.7), Offset, Profile and BlockCount
3.1.20
initialization vector
IV
input block that some modes of operation (3.1.28) require as an additional initial input
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.22
KeyID
numerical designator for a single key (3.1.21)
3.1.23
Key[KeyID].ENC_key
variable that contains the key (3.1.21) that is used for encryption
Note 1 to entry: This variable shall be used for encryption.
3.1.24
Key[KeyID].MAC_key
key (3.1.21) that can be used for cryptographic integrity protection
3.1.25
MAC_key
variable that contains the key (3.1.21) that is used for cryptographic integrity protection
Note 1 to entry: This variable shall be used for cryptographic integrity protection.
3.1.26
memory profile
start pointer within the Tag’s memory for addressing custom data block (3.1.16)
3.1.27
message
part of the command that is defined by the crypto suite
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.29
output block
data that is an output of either the forward cipher function or the inverse cipher function of the block cipher
algorithm
© ISO/IEC 2026 – All rights reserved
3.1.30
plaintext
ordinary readable text before being encrypted into ciphertext (3.1.12) or after being decrypted from
ciphertext
3.1.31
reply
data that the Tag returns to the Interrogator with "Response" as parameter
3.1.32
response
part of the reply (stored or sent) that is defined by the crypto suite
3.1.33
word
bit string (3.1.5) comprised of 16 bits
3.2 Symbols
Field[a:b] selection of bits "a" through to, and including, bit "b" from a string of bits denoted Field where
Field [0] represents the least significant or rightmost bit
EXAMPLE 1 Field [2:0] represents the selection of the three least significant bits of Field.
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.
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)
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 document 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 (e.g. ready).
— Command parameters are underlined. Some flags are also command parameters; a flag used as a command
parameter will be underlined (e.g. Pointer).
— Commands are denoted in italics. Variables are also denoted in italics. Where there can be confusion between
commands and variables, this protocol will make an explicit statement (e.g. Query).
3.3 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
FIPS federal information processing standard

© ISO/IEC 2026 – All rights reserved
IAM Interrogator authentication
IV initialization 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
RFU reserved for future use
TA Tag authentication
TID Tag-IDentification or Tag IDentifier (depending on context)
UII unique identification ID
4 Conformance
4.1 Air interface protocol specific information
An Interrogator or Tag shall conform 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 E.
4.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.
4.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
— require the use of an optional, proprietary or custom command to meet the requirements of this
document.
© ISO/IEC 2026 – All rights reserved
5 Overview of the AES-128 crypto suite
The 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].
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 C.
References for AES test vectors are provided in Annex D.
The implementation of this crypto suite shall conform to the protocol -specific information provided in
Annex E.
Annex F provides examples for the implementation of the functionality that is specified in this document.
6 Parameter description
Table 1 describes all the parameters that are used in this document.
Table 1 — 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 Mes-
sage easier to read.
16-bit predefined constant for MAM1 with the value "DA83 "
h
C_MAM1[15:0]
(for Tag to Interrogator response)
12-bit predefined constant for MAM2 with the value "DA8 "
h
C_MAM2[11:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM1 with the value "96C5 "
h
C_TAM1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C5 "
h
C_TAM2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C0 "
h
C_TAM2_0[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C1 "
h
C_TAM2_1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C2 "
h
C_TAM2_2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C3 "
h
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)

© ISO/IEC 2026 – All rights reserved
TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
Parameter Description
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
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 (optional) MAC_key
Key[KeyID]
for integrity protection
MAC_key[127:0] Variable that shall contain the key that is used for cryptographic integrity protection
Authentication purpose bits for IAM2
Purpose_IAM2[3:0] If Purpose_IAM2[3:3] = 0 the bits [2:0] are RFU with value 000
b b
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] = 1 the bits [2:0] are manufacturer defined
b
Authentication purpose bits for MAM2
Purpose_MAM2[3:0] If Purpose_MAM2[3:3] = 0 the bits [2:0] are RFU with value 000
b b
If Purpose_MAM2[3:3] = 1 the bits [2:0] are manufacturer defined
b
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 1.
The Tag shall transition from the Start state to the Next state conforming to the requirements specified in
Annex A.
© ISO/IEC 2026 – 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 condition from the list that is specified in Annex 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 2026 – All rights reserved
All message and response exchanges are listed in Table 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) or encrypted (confidentiality
protection), or both, with the authentication. The authentication message shall include the reference KeyID
to select an encryption key in Table 27 (see Clause 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 E.
The memory profiles may also be linked to a key in Table 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 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 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
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

© ISO/IEC 2026 – All rights reserved
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 1 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.
NOTE 2 Access rights to custom data can be restricted by the specification of the interface. Annex 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 or protection of the
custom data, or both. Table 3 specifies the mode of operation for either encryption algorithms or message
authentication algorithms for the (optional) protection (either authentication or encryption, or both) of
custom data, or both.
© ISO/IEC 2026 – All rights reserved
Table 3 — Supported modes of operation for ProtMode
a
ProtMode[3:0] Description
0000 plaintext (either no integrity or confidentiality protection requested, or both)
b
0001 CBC (encryption only)
b
0010 CMAC (message authentication only)
b
0011 CBC + CMAC
b
0100 reserved for future use
b
…. ….
0111 reserved for future use
b
1000 manufacturer defined
b
…. ….
1111 manufacturer defined
b
a
When a ProtMode is selected that specifies data encryption (ProtMode "0001 " and "0011 "), the Tag may assert a privilege
b b
that makes all memory accessible for the duration of the execution of the command. See Annex 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 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.4, 9.5 and 9.6 describe the formatting of Message and Response for Tag authentication,
Interrogator authentication and Mutual authentication. The Messages for Tag 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.4.
b
If AuthMethod = "01 ", the Tag shall parse Message for Interrogator authentication as described in 9.5.
b
If AuthMethod = "10 ", the Tag shall parse Message for Mutual authentication as described in 9.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

© ISO/IEC 2026 – All rights reserved
protected (protection of integrity, authenticity of origin and timeliness) 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.2.
If CustomData = "1 ", the Tag shall parse the TAM2 Message for Tag authentication with custom data as
b
described in 9.4.5.
9.4.2 TAM1 Message
For Tag authentication, the Interrogator sha
...