ISO/IEC 29167-22:2026

International
Standard
ISO/IEC 29167-22
Second edition
Information technology —
2026-03
Automatic identification and data
capture techniques —
Part 22:
Crypto suite SPECK security services
for air interface communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 22: Services de sécurité par suite cryptographique SPECK
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 . 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 Overview of the SPECK crypto suite . 4
6 Parameter and variable descriptions. 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 .7
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 . .11
9.5 Mutual authentication (AuthMethod “10”) .11
9.5.1 General .11
9.5.2 MAM1 message . 12
9.5.3 Intermediate Tag processing #1 . 13
9.5.4 MAM1 response. 13
9.5.5 Intermediate Interrogator processing .14
9.5.6 MAM2 message .14
9.5.7 Intermediate Tag processing #2 .14
9.5.8 MAM2 response . 15
9.5.9 Final Interrogator processing . . 15
10 Communication .16
10.1 General .16
10.2 Message and response formatting .16
10.3 Transforming a payload prior to encapsulation .17
10.3.1 General .17
10.3.2 Encapsulating an Interrogator command .18

© ISO/IEC 2026 – All rights reserved
iii
10.3.3 Cryptographically protecting a Tag reply .19
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 transitions .23
Annex B (normative) Errors and error handling .24
Annex C (normative) Description of SPECK and SILC v3 .25
Annex D (informative) Test vectors .29
Annex E (normative) Protocol specific information .40
Bibliography .43

© 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 second edition cancels and replaces the first edition (ISO/IEC 29167-22:2018), which has been
technically revised.
The main change is as follows: Annex E has been updated to reflect changes to the 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 lightweight block cipher SPECK.

© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 29167-22:2026(en)
Information technology — Automatic identification and data
capture techniques —
Part 22:
Crypto suite SPECK security services for air interface
communications
1 Scope
This document specifies the crypto suite for SPECK for the ISO/IEC 18000 air interface standards for radio
frequency identification (RFID) devices.
SPECK is a symmetric block cipher that is parameterized in both its block length and key length. The block/
key length options supported in this crypto suite (in bits) are 64/96, 96/96, 64/128, 128/128 and 128/256.
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-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 —
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 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.1
bit string
ordered sequence of 0s and 1s
3.1.2
block cipher
family of permutations that is parameterized by a cryptographic key and, optionally, the block size (3.1.3)

© ISO/IEC 2026 – All rights reserved
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
blocks (3.1.6)
3.1.5
command
data that the Interrogator sends to the Tag with Message as the 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
SPECK-b/k-ENC(key, data)
SPECK encryption of a b-bit data block (3.1.6) using a k-bit cryptographic key (3.1.4)
3.1.11
SPECK-b/k-DEC(key, data)
SPECK 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 within the crypto suite
3.2 Symbols
XXXX binary notation
XXXX hexadecimal notation
h
‖ concatenation of syntax elements, transmitted in the order written
∅ empty string, typically used to indicate a deliberately empty input or omitted field
|A| bit-wise length of the string A expressed as an integer
EXAMPLE 1 |0000 | = 4.
EXAMPLE 2 |0000 | = 16.
h
© ISO/IEC 2026 – All rights reserved
EXAMPLE 3 |∅| = 0.
fix1(A) string obtained by fixing the first (leftmost) bit to 1
EXAMPLE 4 fix1(0000 ) = 1000 .
2 2
EXAMPLE 5 fix1(0000 ) = 8000 .
h h
EXAMPLE 6 fix1(∅) = ∅.
msb (A) n-bit binary string obtained by taking the first (leftmost) n bits of the binary representation of A
n
EXAMPLE 7 msb (1010 ) = 101 .
3 2 2
EXAMPLE 8 msb (ABCD ) = 1010101 .
7 h 2
EXAMPLE 9 msb (∅) = ∅.
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 10 Field [2:0] represents the selection of the three least significant bits of Field.
EXAMPLE 11 Field, without a specified range, indicates the entirety of Field.
EXAMPLE 12 Field [-1:0] is an alternative representation of the empty string ∅.
Key.KeyID cryptographic key identified and indexed by the numerical value KeyID
3.3 Abbreviated terms
CS crypto suite
CSI crypto suite identifier
IA Interrogator authentication
MA Mutual authentication
RFU reserved for future use
TA Tag authentication
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”.
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 may implement any subset of the optional commands described in this document.
The Interrogator shall not:
— implement any command that conflicts with this document; or

© ISO/IEC 2026 – All rights reserved
— require the use of an optional, proprietary or custom command to meet the requirements of this
document.
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 may 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.
5 Overview of the SPECK crypto suite
SPECK is a lightweight Feistel block cipher that is suitable for extremely constrained environments such as
RFID Tags. The details of the operation of the SPECK cipher are described in Annex C.
The background for the development of SPECK and its design principles are described in Reference [3].
SPECK is parameterized in terms of the data block size, denoted b, and the key size denoted k. A particular
variant of SPECK is denoted SPECK-b/k throughout this document. While Reference [3] offers many different
choices to the block and key size, this crypto suite only supports the five parameter combinations given in
Table 1.
Table 1 — Variants of SPECK-b/k supported in this document
SPECK-64/96 SPECK-64/128 SPECK-96/96 SPECK-128/128 SPECK-128/256
Block size (b bits) 64 64 96 128 128
Key size (k bits) 96 128 96 128 256
It is possible that not all variants of SPECK 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 parts of this document are provided in Annex D.
Over-the-air protocol commands that use this crypto suite shall be in accordance with Annex E.
6 Parameter and variable descriptions
Table 2 describes all the variables and constants that are used in this document.

© ISO/IEC 2026 – All rights reserved
Table 2 — SPECK crypto suite variables and constants
Parameter Description
A challenge generated at random by the Interrogator. The length of IChallenge-b/k depends on
IChallenge-b/k
the values of b and k.
A challenge generated at random by the Tag. The length of TChallenge-b/k depends on the
TChallenge-b/k
values of b and k.
A salt value generated at random by the Tag. The length of TRnd-b/k depends on the values of b
TRnd-b/k
and k.
A salt value generated at random by the Interrogator. The length of IRnd-b/k depends on the
IRnd-b/k
values of b and k.
C_TAM-b/k A pre-defined constant. The length and value of C_TAM-b/k depends on the values of b and k.
C_IAM-b/k A pre-defined constant. The length and value of C_IAM-b/k depends on the values of b and k.
C_MAM-b/k A pre-defined constant. The length and value of C_MAM-b/k depends on 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 crypto suite shall transition into the Initial state, state transitions
shall be as described by Annex A and error handling shall be as described by Annex B. The state diagram is
shown in Figure 1.
© ISO/IEC 2026 – All rights reserved
Condition 1 For all of TAM1, IAM1, MAM1, IAM2, MAM2 and errors, return to Initial state without action.
Condition 2 For all of TAM1, IAM1, MAM1, MAM2 and errors, return to Initial state without action.
Condition 3 For all of TAM1, IAM1, MAM1, IAM2 and errors, return to Initial state without action.
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.

© ISO/IEC 2026 – All rights reserved
9.2 Message and response formatting
Messages and responses are part of the security commands described in the air interface specification.
Subclauses 9.3, 9.4 and 9.5 describe the formatting of message and response for a 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 the challenge-response protocol shown in Figure 2.
Figure 2 — Tag authentication via a challenge-response scheme
The parameter set PS described 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
ISO/IEC 29167-10. This provides some drop-in compatibility between SPECK-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 shown in Table 5. The Interrogator shall also indicate the variant of SPECK to be used.
NOTE 1 The variant(s) of SPECK 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 2026 – All rights reserved
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 (are) 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 where r is given for the parameter set in
Table 3.
The Tag shall use Key.KeyID and SPECK encryption to form a b-bit string TResponse such that:
TResponse = SPECK-b/k-ENC ( Key.KeyID, C_TAM-b/k ‖ TRnd-b/k ‖ IChallenge-b/k ).
The Tags shall return TResponse to the Interrogator, as shown in Table 6.
NOTE 1 Only one input block of b bits is encrypted and so only one invocation of SPECK-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 = SPECK-b/k-DEC ( Key.KeyID, TResponse ).
a) The Interrogator shall check that S[t-1:0] = IChallenge-b/k.
b) 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 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.

© ISO/IEC 2026 – All rights reserved
9.4 Interrogator authentication (AuthMethod “01”)
9.4.1 General
Interrogator authentication uses a challenge-response protocol as shown in 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
ISO/IEC 29167-10. This provides some drop-in compatibility between SPECK-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, as shown in Table 8, to the Tag prompting the Tag to
start a challenge-response exchange.
The Interrogator shall also indicate the variant of SPECK to be used.
NOTE The variant(s) of SPECK deployed on a device is (are) manufacturer dependent.
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
© ISO/IEC 2026 – All rights reserved
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 as shown in Table 9.
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:
IResponse = SPECK-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
© ISO/IEC 2026 – All rights reserved
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 = SPECK-b/k-ENC ( Key.KeyID, IResponse ).
The Tag checks the validity of the string S.
a) The Tag shall check that S[t-1:0] = TChallenge-b/k.
b) 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 as shown in Table 11. If TStatus = 1 , then the
cryptographic state machine moves to state Interrogator authentication (IA) (see Clause 7).
Table 11 — IAM2 response format
Payload
Field
Status
Length (bits) 1
Value TStatus
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 as shown in
Figure 4.
© ISO/IEC 2026 – All rights reserved
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
ISO/IEC 29167-10. This provides some drop-in compatibility between SPECK-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
b/k 64/96 64/128 96/96 128/128 128/256
t = │ TChallenge-b/k │ 42 42 56 80 80
Parameter set PS = 00 t = │ IChallenge-b/k │ 42 42 56 80 80
c = │ C_MAM-b/k │ 2 2 8 16 16
t = │ TChallenge-b/k │ 30 30 46 60 60
Parameter set PS = 01 t = │ IChallenge-b/k │ 30 30 46 60 60
c = │ C_MAM-b/k │ 4 4 4 8 8
9.5.2 MAM1 message
The Interrogator shall generate a random Interrogator challenge (IChallenge-b/k) that is carried in the
MAM1 message shown in Table 13. The length of IChallenge-b/k is denoted t and specified in Table 12.
The Interrogator shall also indicate the variant of SPECK to be used.
NOTE The variant(s) of SPECK deployed on a device is (are) manufacturer dependent.
Table 13 — MAM1 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 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
© ISO/IEC 2026 – All rights reserved
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 fails, 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 = SPECK-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.
NOTE 1 Only one input block of b bits is encrypted and so only one invocation of SPECK-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 as shown in Table 14.
Table 14 — MAM1 response format
Payload
Field
Tag Response
Length (bits) 2t + c
Value TResponse
© ISO/IEC 2026 – All rights reserved
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 = SPECK-b/k-DEC ( Key.KeyID, TResponse[b-1:0]).
The Interrogator checks the validity of the string T.
a) The Interrogator shall check that T[t-1:0] = IChallenge-b/k.
b) 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:
a) If PS = 00 , then IResponse is equal to:
SPECK-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] ).
b) 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
Pa
...