ISO/IEC 29167-21:2018

Information technology - Automatic identification and data capture techniques - Part 21: Crypto suite SIMON security services for air interface communications

This document defines the crypto suite for SIMON for the ISO/IEC 18000 air interfaces standards for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto suite for security for RFID devices that can be referred by ISO committees for air interface standards and application standards. The crypto suite is defined in alignment with existing air interfaces. SIMON is a symmetric block cipher that is parameterized in both its block length and key length. In this standard, a variety of block/key length options are supported. This document defines various methods of use for the cipher. A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.

Technologies de l'information — Techniques automatiques d'identification et de capture de données — Partie 21: Services de sécurité par suite cryptographique SIMON pour communications par interface radio

General Information

• Status: Published
• Publication Date: 17-Oct-2018
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 4 - Radio communications
• Current Stage: 9092 - International Standard to be revised
• Start Date: 14-May-2024
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 29167-21 - Information technology - Automatic identification and data capture techniques - Part 21: Crypto suite SIMON security services for air interface communications
• Effective Date: 18-May-2024

Overview

ISO/IEC 29167-21:2018 specifies a crypto suite based on the lightweight block cipher SIMON for air‑interface communications of RFID devices. It defines how SIMON is applied within the ISO/IEC 18000 family of air interface standards to provide common, interoperable security services for Tags (RFID transponders) and Interrogators (readers). The standard supports multiple SIMON block/key size variants and defines message formats, authentication methods, communication encapsulation, key management and conformance rules.

Key topics and technical requirements

• SIMON cipher variants: The suite supports several block/key size options (notably 64/96, 96/96, 64/128, 128/128 and 128/256 bits). Implementations must state which options they support.
• Authentication methods: Procedures for Tag authentication, Interrogator authentication and Mutual authentication are defined, including message/response formatting and state transitions.
• Communication protection: Methods to encapsulate commands and cryptographically protect Tag responses (integrity and confidentiality modes) are specified for air interface messages.
• Initialization and state machine: State diagrams, initialization/reset rules and a crypto suite state transition table govern secure session behavior.
• Key management: Key table structures and key update mechanisms for managing SIMON keys on Tags and Interrogators.
• Error handling and conformance: Normative rules for conformance, error reporting and protocol‑specific obligations for Tags and Interrogators.
• Supporting material: Annexes include a description of SIMON and SILC v3, test vectors, protocol‑specific information and normative tables for implementers.
• IP notice: The document draws attention to possible patent claims related to the technology (some patent contact information is provided).

Applications and practical value

• Provides a standardized, lightweight cryptographic option for securing RFID air interfaces used in:
  • Supply chain and inventory management
  • Asset tracking and logistics
  • Access control and secure identification
  • IoT devices where constrained resources require lightweight ciphers
• Enables interoperable security between different vendors’ Tags and Interrogators by specifying common message formats, authentication flows and key management.

Who should use this standard

• RFID device manufacturers and firmware developers implementing SIMON‑based security
• System integrators deploying secure RFID solutions for logistics, retail or access control
• Standards committees and application designers referencing a crypto suite for ISO/IEC 18000 air interfaces
• Security architects and compliance teams evaluating lightweight cryptographic options for constrained devices

Related standards

• ISO/IEC 18000 (air interface parameters for RFID)
• ISO/IEC 19762 (AIDC harmonized vocabulary)

Keywords: ISO/IEC 29167-21, SIMON crypto suite, RFID security, air interface, lightweight block cipher, RFID authentication, key management, ISO/IEC 18000.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29167-21
First edition
2018-10
Information technology — Automatic
identification and data capture
techniques —
Part 21:
Crypto suite SIMON security services
for air interface communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 21: Services de sécurité par suite cryptographique SIMON pour
communications par interface radio
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
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: [phone]
Fax: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
3.1 Terms and definitions . 1
3.2 Symbols . 2
3.3 Abbreviated terms . 3
4 Conformance . 3
4.1 Air interface protocol specific information . 3
4.2 Interrogator conformance and obligations . 3
4.3 Tag conformance and obligations . 4
5 Introducing the SIMON cryptographic suite . 4
6 Parameter and variable definitions . 4
7 Crypto suite state diagram . 5
8 Initialization and resetting . 6
9 Authentication . 6
9.1 General . 6
9.2 Message and response formatting . 6
9.3 Tag authentication (AuthMethod “00”) . 7
9.3.1 General. 7
9.3.2 TAM1 message . 7
9.3.3 Intermediate Tag processing . 8
9.3.4 TAM1 response . 8
9.3.5 Final Interrogator processing . 8
9.4 Interrogator authentication (AuthMethod “01”) . 9
9.4.1 General. 9
9.4.2 IAM1 message . 9
9.4.3 Intermediate Tag processing #1 .10
9.4.4 IAM1 response .10
9.4.5 Intermediate Interrogator processing .10
9.4.6 IAM2 message .10
9.4.7 Intermediate Tag processing #2 .11
9.4.8 IAM2 response .11
9.4.9 Final Interrogator processing .12
9.5 Mutual authentication (AuthMethod “10”) .12
9.5.1 General.12
9.5.2 MAM1 message .13
9.5.3 Intermediate Tag processing #1 .13
9.5.4 MAM1 response .14
9.5.5 Intermediate Interrogator processing .14
9.5.6 MAM2 message .14
9.5.7 Intermediate Tag processing #2 .15
9.5.8 MAM2 response .15
9.5.9 Final Interrogator processing .16
10 Communication .16
10.1 General .16
10.2 Message and response formatting .17
10.3 Transforming a payload prior to encapsulation .17
10.3.1 General.17
© ISO/IEC 2018 – All rights reserved iii

10.3.2 Encapsulating an Interrogator command .19
10.3.3 Cryptographically protecting a Tag reply .20
10.4 Processing an encapsulated or cryptographically-protected reply .20
10.4.1 General.20
10.4.2 Recovering an encapsulated Interrogator command .21
10.4.3 Recovering a cryptographically-protected Tag response.22
11 Key table and key update .22
Annex A (normative) Crypto suite state transition table .24
Annex B (normative) Errors and error handling .25
Annex C (normative) Description of SIMON and SILC v3 .26
Annex D (informative) Test vectors .31
Annex E (normative) Protocol specific information.43
Bibliography .46
iv © ISO/IEC 2018 – 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 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 the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee, SC 31 Automatic identification and data capture techniques
A list of all the parts in the ISO/IEC 29167 series can be found on the ISO website.
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.
© ISO/IEC 2018 – All rights reserved v

Introduction
This document specifies a variety of security services provided by the lightweight block cipher SIMON.
While SIMON supports various key and block sizes, the cipher versions that are supported in this
cryptographic suite take the following block/key sizes in bits: 64/96, 96/96, 64/128, 128/128, and
128/256.
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 may be obtained from:
Contact details
Impinj, Inc.
400 Fairview Ave N, # 1200
Seattle, WA 98109 USA
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights other than those identified above. ISO and IEC shall not be held responsible for identifying
any or all such patent rights.
The latest information on IP that may be applicable to this document can be found at www .iso
.org/patents.
vi © ISO/IEC 2018 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29167-21:2018(E)
Information technology — Automatic identification and
data capture techniques —
Part 21:
Crypto suite SIMON security services for air interface
communications
1 Scope
This document defines the crypto suite for SIMON for the ISO/IEC 18000 air interfaces standards
for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto suite
for security for RFID devices that can be referred by ISO committees for air interface standards and
application standards. The crypto suite is defined in alignment with existing air interfaces.
SIMON is a symmetric block cipher that is parameterized in both its block length and key length. In this
standard, a variety of block/key length options are supported.
This document defines various methods of use for the cipher.
A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what
is supported.
2 Normative references
The following documents 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-63, Information technology — Radio frequency identification for item management —
Part 63: Parameters for air interface communications at 860 MHz to 960 MHz Type C
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1.1
bit string
ordered sequence of 0s and 1s
© ISO/IEC 2018 – All rights reserved 1

3.1.2
block cipher
family of permutations that is parameterized by a cryptographic key (3.1.4) and, optionally, the block
size (3.1.3)
3.1.3
block size
number of bits in a data block (3.1.6) that is an input (or output) of the block cipher (3.1.2)
3.1.4
cryptographic key
string of bits of length given by key size (3.1.7) that is used by the block cipher (3.1.2) to transform some
data block (3.1.6)
3.1.5
command
data that the Interrogator sends to the Tag with "Message" as parameter
3.1.6
data block
string of bits whose length is given by the block size (3.1.3) of the block cipher (3.1.2)
3.1.7
key size
length in bits of the cryptographic key (3.1.4) that is used by the block cipher (3.1.2)
3.1.8
message
part of the command (3.1.5) that is defined by the crypto suite
3.1.9
nonce
data block (3.1.6) that, within the parameters of typical use, can be assumed to be non-repeating
3.1.10
SIMON-b/k-ENC(key, data)
SIMON encryption of a b-bit data block (3.1.6) using a k-bit cryptographic key (3.1.4)
3.1.11
SIMON-b/k-DEC(key, data)
SIMON decryption of a b-bit data block (3.1.6) using a k-bit cryptographic key (3.1.4)
3.1.12
Reply
data that the Tag returns to the Interrogator with "Response" (3.1.13) as parameter
3.1.13
Response
part of the “Reply” (3.1.12) (stored or sent) that is defined within the crypto suite
3.2 Symbols
XXXX Binary notation
XXXX Hexadecimal notation
h
‖ Concatenation of syntax elements, transmitted in the order written
∅ The empty string, typically used to indicate a deliberately empty input or omitted field
2 © ISO/IEC 2018 – All rights reserved

|A| The bit-wise length of the string A expressed as an integer
Example 1: |0000 | = 4.
Example 2: |0000 | = 16.
h
Example 3: |∅| = 0.
fix1(A) The string obtained by fixing the first (leftmost) bit to 1
Example 1: fix1(0000 ) = 1000 .
2 2
Example 2: fix1(0000 ) = 8000 .
h h
Example 3: fix1(∅) = ∅.
msb (A) The n-bit binary string obtained by taking the first (leftmost) n bits of the binary repre-
n
sentation of A
Example 1: msb (1010 ) = 101 .
3 2 2
Example 2: msb (ABCD ) = 1010101 .
7 h 2
Example 3: msb (∅) = ∅.
Field [a:b] Selection of bits from a string of bits denoted Field
The selection ranges from bit "a" through to, and including, bit "b" where Field [0] rep-
resents the least significant or rightmost bit.
Example 1: Field [2:0] represents the selection of the three least significant bits of Field.
Example 2: Field, without a specified range, indicates the entirety of Field.
Example 3: Field [-1:0] is an alternative representation of the empty string ∅.
Key.KeyID The cryptographic key identified and indexed by the numerical value KeyID.
3.3 Abbreviated terms
CS Crypto Suite
CSI Crypto Suite Indicator
RFU Reserved for future use
4 Conformance
4.1 Air interface protocol specific information
An Interrogator or Tag shall comply with all relevant clauses of this document, except those marked as
“optional”.
4.2 Interrogator conformance and obligations
An Interrogator shall implement the mandatory commands defined in this document and conform to
the relevant part of ISO/IEC 18000.
An Interrogator may implement any subset of the optional commands defined in this document.
© ISO/IEC 2018 – All rights reserved 3

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 defined in this document for the supported types and
conform to the relevant part of ISO/IEC 18000.
A Tag may implement any subset of the optional commands defined 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.
5 Introducing the SIMON cryptographic suite
SIMON is a lightweight Feistel block cipher that is suitable for extremely constrained environments
such as RFID Tags. The details of the operation of the SIMON cipher are described in Annex C.
The background for the development of SIMON and its design principles are described in Reference [3].
SIMON is parameterized in terms of the block size, denoted b, and the key size, denoted k. A particular
variant of SIMON will be denoted SIMON-b/k throughout this document. While Reference [3] offers
many different choices to the block and key size, this cryptographic suite only supports the five
parameter combinations given in Table 1:
Table 1 — Variants of SIMON-b/k supported in this document
SIMON-64/96 SIMON-64/128 SIMON-96/96 SIMON-128/128 SIMON-128/256
Block size (b
64 64 96 128 128
bits)
Key size
96 128 96 128 256
(k bits)
It is possible that not all variants of SIMON will be cryptographically suited to all applications. Guidance
on the appropriate variant for a given application lies outside the scope of this document and a thorough
security and risk assessment is advised before deployment.
Test vectors for the components of this document are provided in Annex D.
6 Parameter and variable definitions
Table 2 lists the variables and constants that are used in this document.
4 © ISO/IEC 2018 – All rights reserved

Table 2 — SIMON cryptographic suite variables and constants
Parameter Description
A challenge generated at random by the Interrogator. The length of
IChallenge-b/k
IChallenge-b/k depends on the values of b and k.
A challenge generated at random by the Tag. The length of TChallenge-b/k
TChallenge-b/k
depends on the values of b and k.
A salt value generated at random by the Tag. The length of TRnd-b/k de-
TRnd-b/k
pends on the values of b and k.
A salt value generated at random by the Interrogator. The length of IRnd-
IRnd-b/k
b/k depends on the values of b and k.
A pre-defined constant. The length and value of C_TAM-b/k depends on the
C_TAM-b/k
values of b and k.
A pre-defined constant. The length and value of C_IAM-b/k depends on the
C_IAM-b/k
values of b and k.
A pre-defined constant. The length and value of C_MAM-b/k depends on
C_MAM-b/k
the values of b and k.
A set of up to 256 keys Key.0 through to Key.255.
Key.0 … Key.255
Not all key values need to be specified. However Key.j shall not be specified
when there remain unspecified Key.i with i Table 3 gives the values of C_TAM-b/k, C_IAM-b/k, and C_MAM-b/k, that are used in this document. For
a given choice of operational parameters, the length of these constants depends on the block size b.
Table 3 — Values of C_TAM-b/k, C_IAM-b/k, and C_MAM-b/k for different values of b and k and
different parameter sets PS
b/k 64/96 64/128 96/96 128/128 128/256
C_TAM-b/k 11 11 FF FFFF FFFF
2 2 h h h
C_IAM-b/k 10 10 FE FFFE FFFE
2 2 h h h
C_MAM-b/k for PS=00 01 01 FD FFFD FFFD
2 2 2 h h h
C_MAM-b/k for PS=01 1 1 D FD FD
2 h h h h h
7 Crypto suite state diagram
After power-up and after a reset, the Cryptographic Suite shall transition into the Initial state, state
transitions shall be defined by Annex A, and error handling shall be defined by Annex B. See Figure 1.
© ISO/IEC 2018 – All rights reserved 5

Figure 1 — Crypto suite state diagram
8 Initialization and resetting
After power-up and after a reset, the cryptographic state machine transitions into the Initial state.
Implementations of this suite shall ensure that all memory used for any intermediate results is cleared:
— after the completion of each cryptographic protocol,
— if some cryptographic protocol is abandoned or incomplete, and
— after reset.
9 Authentication
9.1 General
This document supports Tag authentication, Interrogator authentication and Mutual authentication.
This clause describes the details of the messages and responses that are exchanged between the
Interrogator and Tag for each of the authentication methods.
9.2 Message and response formatting
Messages and responses are part of the security commands described in the air interface specification.
The following subclauses of this document describe the formatting of message and response for a
6 © ISO/IEC 2018 – All rights reserved

Tag authentication method, an Interrogator authentication method and a Tag-Interrogator mutual
authentication method.
9.3 Tag authentication (AuthMethod “00”)
9.3.1 General
Tag authentication uses a challenge-response protocol. See Figure 2.
Figure 2 — Tag authentication via a challenge-response scheme
The parameter set PS defined in Table 4 gives the lengths of different fields for different block and
key sizes.
NOTE The parameter set PS=00 closely matches other parts of the ISO/IEC 29167 series, most notably
29167-10. This provides some drop-in compatibility between SIMON-128/128 and AES-128.
Table 4 — Parameter set PS = 00 for Tag authentication
Parameter set PS= 00
b/k 64/96 64/128 96/96 128/128 128/256
t = │ IChallenge-b/k │ 42 42 56 80 80
r = │ TRnd-b/k │ 20 20 32 32 32
c = │ C_TAM-b/k │ 2 2 8 16 16
9.3.2 TAM1 message
The Interrogator shall generate a random Interrogator challenge (IChallenge-b/k) that is carried in the
TAM1 message. The Interrogator shall also indicate the variant of SIMON to be used.
NOTE 1 The variant(s) of SIMON deployed on a device is (are) manufacturer dependent.
NOTE 2 Mechanisms to generate the random Interrogator challenge lie outside the scope of this document.
Table 5 — TAM1 message format
Payload
Field AuthMethod Step RFU BlockSize KeySize KeyID PS Challenge
Length (bits) 2 2 2 2 2 8 2 t
00 : b=64 00 : k=96
2 2
01 : b=96 01 : k=128
2 2
Value 00 00 00 variable 00 IChallenge-b/k
2 2 2 2
10 : b=128 10 : k=256
2 2
11 : RFU 11 : RFU
2 2
© ISO/IEC 2018 – All rights reserved 7

9.3.3 Intermediate Tag processing
The Tag shall accept the TAM1 message at any time (unless occupied by internal processing and not
capable of receiving messages); i.e. upon receipt of the message with valid parameters, the Tag shall
abort any cryptographic protocol that has not yet been completed and shall remain in the Initial state.
The Tag shall check if the Step is "00 ". If the value of Step is different, the Tag shall return a "Not
Supported" error.
The Tag shall check if the RFU is "00 ". If the value of RFU is different, the Tag shall return a "Not
Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by the Tag. If at least
one of these checks is failed, the Tag shall return a "Not Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by Key.KeyID and that
Key.KeyID is authorized for use in Tag authentication. If either or both of these checks is failed, the Tag
shall return a "Not Supported" error.
The Tag shall check whether the parameter set PS is supported. If the parameter set PS is not supported,
the Tag shall return a "Not Supported" error.
Assuming that the TAM1 message is successfully parsed by the Tag, the Tag shall prepare the TAM1
response.
9.3.4 TAM1 response
The Tag shall generate a random salt TRnd-b/k of length r bits were r is given for the parameter set in
Table 3.
The Tag shall use Key.KeyID and SIMON encryption to form a b-bit string TResponse such that:
TResponse = SIMON-b/k-ENC ( Key.KeyID, C_TAM-b/k ‖ TRnd-b/k ‖ IChallenge-b/k ).
The Tag shall return TResponse to the Interrogator.
NOTE 1 Only one input block of b bits is encrypted and so only one invocation of SIMON-b/k is required.
NOTE 2 Appropriate mechanisms to generate TRnd-b/k lie outside the scope of this document.
Table 6 — TAM1 response format
Payload
Field Tag Response
Length (bits) b
Value TResponse
9.3.5 Final Interrogator processing
After receiving TAM1 response, the Interrogator shall use Key.KeyID to compute the b-bit string S where:
S = SIMON-b/k-DEC ( Key.KeyID, TResponse ).
1. The Interrogator shall check that S[t-1:0] = IChallenge-b/k.
2. The Interrogator may check that S[b -1:b -c] = C_TAM-b/k.
If these verification steps are successfully completed, the Interrogator may conclude that the Tag
and Interrogator possess matching values of Key.KeyID. When combined with an appropriate key
8 © ISO/IEC 2018 – All rights reserved

management scheme — the definition of which falls outside the scope of this document — the
Interrogator may conclude that the Tag is authentic.
NOTE Determining Key.KeyID is a matter of key management and falls outside of the scope of this document.
9.4 Interrogator authentication (AuthMethod “01”)
9.4.1 General
Interrogator authentication uses a challenge-response protocol. See Figure 3.
Figure 3 — Interrogator authentication via a challenge-response scheme
The parameter set in Table 7 gives the lengths of specific data fields for different choices of block and
key size.
NOTE The parameter set PS=00 closely matches other parts of the ISO/IEC 29167 series, most notably
29167-10. This provides some drop-in compatibility between SIMON-128/128 and AES-128.
Table 7 — Parameter set PS = 00 for Interrogator authentication
Parameter set PS= 00
b/k 64/96 64/128 96/96 128/128 128/256
t = │ TChallenge-b/k │ 42 42 56 80 80
r = │ IRnd-b/k │ 20 20 32 32 32
c = │ I_MAM-b/k │ 2 2 8 16 16
9.4.2 IAM1 message
The Interrogator shall send an initial message IAM1 to the Tag prompting the Tag to start a challenge-
response exchange.
The Interrogator shall also indicate the variant of SIMON to be used.
NOTE The variant(s) of SIMON deployed on a device is (are) manufacturer dependent.
© ISO/IEC 2018 – All rights reserved 9

Table 8 — IAM1 message format
Payload
Field AuthMethod Step RFU BlockSize KeySize KeyID PS
Length (bits) 2 2 2 2 2 8 2
00 : b=64 00 : k=96
2 2
01 : b=96 01 : k=128
2 2
Value 01 00 00 variable 00
2 2 2 2
10 : b=128 10 : k=256
2 2
11 : RFU 11 : RFU
2 2
9.4.3 Intermediate Tag processing #1
The Tag shall accept this message at any time (unless occupied by internal processing and not capable
of receiving messages); i.e. upon receipt of the message with valid parameters, the Tag shall abort any
cryptographic protocol that has not yet been completed and shall remain in the Initial state.
If Interrogator authentication is not supported on the Tag, i.e. if "01 " is not a valid value for AuthMethod,
then the Tag shall return a "Not Supported" error condition.
The Tag shall check if the Step is "00 ". If the value of Step is different, the Tag shall return a "Not
Supported" error.
The Tag shall check if the RFU is "00 ". If the value of RFU is different, the Tag shall return a "Not
Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by the Tag. If at least
one of these checks is failed, the Tag shall return a "Not Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by Key.KeyID and that
Key.KeyID is authorized for use in Interrogator authentication. If at least one of these checks is failed,
the Tag shall return a "Not Supported" error.
The Tag shall check whether the value of parameter set PS is supported by the Tag. If not the Tag shall
return a "Not Supported" error.
If the IAM1 message is successfully parsed by the Tag, the Tag shall calculate the IAM1 response.
9.4.4 IAM1 response
The Tag shall generate a random challenge TChallenge-b/k of length t bits, where t is determined by the
parameter set, and shall send this to the Interrogator.
Table 9 — IAM1 response format.
Payload
Field Challenge
Length (bits) t
Value TChallenge-b/k
9.4.5 Intermediate Interrogator processing
The Interrogator shall construct the IAM2 message.
9.4.6 IAM2 message
The Interrogator shall form a b-bit string IResponse such that
10 © ISO/IEC 2018 – All rights reserved

IResponse = SIMON-b/k-DEC ( Key.KeyID, C_IAM-b/k ‖ IRnd-b/k ‖ TChallenge-b/k ).
The Interrogator shall send IResponse to the Tag as part of the IAM2 message, see Table 10.
NOTE Determining Key.KeyID is a matter of key management and falls outside of the scope of this document.
Table 10 — IAM2 message format
Payload
Field AuthMethod Step RFU InterrogatorResponse
Length (bits) 2 2 4 b
Value 01 01 0000 IResponse
2 2 2
9.4.7 Intermediate Tag processing #2
The Tag shall only accept the IAM2 message when the cryptographic engine is in state PA1 (see
Clause 7).
If Interrogator authentication is not supported on the Tag, i.e. if "01 " is not a valid value for AuthMethod,
then the Tag shall return a "Not Supported" error condition.
The Tag shall check if the Step is "01 ". If the value of Step is different, the Tag shall return a "Not
Supported" error.
The Tag shall check if the RFU is "0000 ". If the value of RFU is different, the Tag shall return a "Not
Supported" error.
If the IAM2 Message is successfully parsed by the Tag, the Tag shall check the returned value of
IResponse in the following manner.
The Tag shall use Key.KeyID to compute the b-bit string S where:
S = SIMON-b/k-ENC ( Key.KeyID, IResponse ).
1. The Tag shall check that S[t-1:0] = TChallenge-b/k.
2. The Tag may check that S[b -1:b -c] = C_IAM-b/k.
If the checks performed by the Tag are successful then the Tag may conclude that the Tag and Interrogator
possess matching values of Key.KeyID. When combined with an appropriate key management scheme
— the definition of which falls outside the scope of this document — the Tag may conclude that the
Interrogator is authentic and TStatus is set to 1 . Otherwise TStatus is set to 0 .
2 2
The Tag shall prepare IAM2 response.
9.4.8 IAM2 response
The Tag shall return the value of TStatus to the Interrogator. If TStatus = 1 , then the cryptographic
state machine moves to state IA (see Clause 7).
Table 11 — IAM2 response format.
Payload
Field Status
Length (bits) 1
Value TStatus
© ISO/IEC 2018 – All rights reserved 11

9.4.9 Final Interrogator processing
The Interrogator receives IAM2 Response.
If the value of TStatus is 1 then the Interrogator may assume that the Tag is in the state IA (see
Clause 7).
If, under conditions laid out in the over-the-air protocol, there is no response from the Tag or if the
returned value of TStatus is 0 then the Interrogator shall abandon the cryptographic protocol.
9.5 Mutual authentication (AuthMethod “10”)
9.5.1 General
Mutual Interrogator-Tag authentication uses an interleaved challenge-response protocol.
Figure 4 — Interrogator-Tag mutual authentication via an interleaved challenge-response scheme
The parameter set in Table 12 gives the lengths of specific data fields for different choices of block and
key size.
NOTE 1 The parameter set PS=00 closely matches other parts of the ISO/IEC 29167 series, most notably
29167-10. This provides some drop-in compatibility between SIMON-128/128 and AES-128.
NOTE 2 The parameter set PS=01 allows a more efficient mutual authentication protocol than PS=00 . In
2 2
particular, the length of the Tag and Interrogator challenges are chosen so that both can fit within a single
b-bit block.
Table 12 — Parameter sets for mutual Tag-Interrogator authentication
Parameter set PS= 00
b/k 64/96 64/128 96/96 128/128 128/256
t = │ TChallenge-b/k │ 42 42 56 80 80
t = │ IChallenge-b/k │ 42 42 56 80 80
c = │ C_MAM-b/k │ 2 2 8 16 16
Parameter set PS= 01
b/k 64/96 64/128 96/96 128/128 128/256
t = │ TChallenge-b/k │ 30 30 46 60 60
t = │ IChallenge-b/k │ 30 30 46 60 60
c = │ C_MAM-b/k │ 4 4 4 8 8
12 © ISO/IEC 2018 – All rights reserved

9.5.2 MAM1 message
The Interrogator shall generate a random Interrogator challenge (IChallenge-b/k) that is carried in the
MAM1 message. The length of IChallenge-b/k is denoted t and specified in Table 12.
The Interrogator shall also indicate the variant of SIMON to be used.
NOTE The variant(s) of SIMON deployed on a device is (are) manufacturer dependent.
Table 13 — MAM1 message format
Payload
Fields AuthMethod Step RFU BlockSize KeySize KeyID PS Challenge
Length (bits) 2 2 2 2 2 8 2 t
00 : b=64 00 : k=96
2 2
01 : b=96 01 : k=128
2 2
Value 10 00 00 variable variable IChallenge-b/k
2 2 2
10 : b=128 10 : k=256
2 2
11 : RFU 11 : RFU
2 2
9.5.3 Intermediate Tag processing #1
The Tag shall accept MAM1 message at any time (unless occupied by internal processing and not capable
of receiving messages); i.e. upon receipt of the message with valid parameters, the Tag shall abort any
cryptographic protocol that has not yet been completed and shall remain in the Initial state.
If Mutual authentication is not supported on the Tag, i.e. if "10 " is not a valid value for AuthMethod,
then the Tag shall return a "Not Supported" error condition.
The Tag shall check if the Step is "00 ". If the value of Step is different, the Tag shall return a "Not
Supported" error.
The Tag shall check if the RFU is "00 ". If the value of RFU is different, the Tag shall return a "Not
Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by the Tag. If at least
one of these checks is failed, the Tag shall return a "Not Supported" error.
The Tag shall check whether the values of BlockSize and KeySize are supported by Key.KeyID and that
Key.KeyID is authorized for use in Interrogator-Tag mutual authentication. If at least one of these checks
is failed, the Tag shall return a "Not Supported" error.
The Tag shall check whether the value of parameter set PS is supported by the Tag. If not the Tag shall
return a "Not Supported" error.
Assuming the MAM1 message is successfully parsed by the Tag, the Tag shall calculate its response
accordingly.
The Tag shall generate a random challenge TChallenge-b/k of length t bits.
The Tag shall construct a b-bit string by concatenating C_MAM-b/k with the (b-t-c) most significant bits
of TChallenge-b/k and the entirety of IChallenge-b/k.
The Tag shall use Key.KeyID to compute the b-bit string S where
S = SIMON-b/k-ENC ( Key.KeyID, C_MAM-b/k ‖ TChallenge-b/k [t -1: 2t -b+c] ‖ IChallenge-b/k ).
TResponse is a string that consists of S concatenated with the remainder (if any) of TChallenge-b/k
TResponse = TChallenge-b/k [2t-b+c-1:0] ‖ S.
© ISO/IEC 2018 – All rights reserved 13

NOTE 1 Only one input block of b bits is encrypted and so only one invocation of SIMON-b/k is required.
NOTE 2 Parameter set PS=01 is constructed so that TResponse is exactly b bits long; i.e. TResponse = S.
9.5.4 MAM1 response
The Tag returns the value of TResponse to the Interrogator.
Table 14 — MAM1 response format
Payload
Field Tag Response
Length (bits) 2t + c
Value TResponse
9.5.5 Intermediate Interrogator processing
After receiving MAM1 Response, the Interrogator shall use Key.KeyID to compute the b-bit string T where:
T = SIMON-b/k-DEC ( Key.KeyID, TResponse[b-1:0] ).
1. The Interrogator shall check that T[t-1:0] = IChallenge-b/k.
2. The Interrogator may check that T[b -1:b -c] = C_TAM-b/k.
If these verification steps are not successful, the Interrogator shall abandon the cryptographic protocol.
Otherwise, the Interrogator may conclude that the Tag and Interrogator possess matching values of
Key.KeyID. When combined with an appropriate key management scheme — the definition of which
falls outside the scope of this document — the Interrogator may conclude that the Tag is authentic.
NOTE Determining Key.KeyID is a matter of key management and falls outside of the scope of this document.
9.5.6 MAM2 message
If the cryptographic protocol has not been abandoned, the Interrogator shall form a b-bit string
IResponse depending on the parameter set PS as follows:
1. If PS = 00 then IResponse is equal to:
SIMON-b/k-DEC ( Key.KeyID, C_MAM-b/k ‖ T[b-t-c-1:0] ‖ T[b-c-1:t] ‖ TResponse[2t+c-1:b] ).
2. If PS = 01 then IResponse is equal to T[b-c:t].
The Interrogator shall set SecureComm = 0001 if secure communications as described in Clause 10
will be used after mutual authentication is completed. Otherwise the Interrogator shall set
SecureComm = 0000 .
The Interrogator shall send IResponse and the value of SecureComm to the Tag as part of the MAM2
message; see Table 15.
Table 15 — MAM2 message format
Payload
Field AuthMethod Step RFU SecureComm Interrogator Response
Length (bits) 2 2 4 4 variable
Value 10 01 0000 variable IResponse
2 2 2
14 © ISO/IEC 2018 – All rights reserved

9.5.7 Intermediate Tag processing #2
The Tag shall only accept this message when the cryptographic engine is in the state PA2; see Clause 7.
If Mutual authentication is not supported on the Tag, i.e. if "10 " is not a valid value for AuthMethod,
then the Tag shall return a "Not Supported" error c
...