ISO/IEC 29167-11:2025
(Main)Information technology — Automatic identification and data capture techniques — Part 11: Crypto suite PRESENT-80 security services for air interface communications
Information technology — Automatic identification and data capture techniques — Part 11: Crypto suite PRESENT-80 security services for air interface communications
This document defines the crypto suite for PRESENT-80 for the ISO/IEC 18000 series of air interfaces standards for radio frequency identification (RFID) devices. This document provides a common crypto suite for security for RFID devices for air interface standards and application standards. The crypto suite is defined in alignment with existing air interfaces. This document specifies basic security services that are use the lightweight block cipher PRESENT-80. The variant of PRESENT that takes 128-bit keys is also considered in this document. This document defines various methods of use for the cipher.
Technologies de l'information — Identification et capture automatique de données — Partie 11: Services de sécurité par suite cryptographique PRESENT-80 pour communications par interface radio
General Information
Relations
Standards Content (Sample)
International
Standard
ISO/IEC 29167-11
Third edition
Information technology —
2025-09
Automatic identification and data
capture techniques —
Part 11:
Crypto suite PRESENT-80
security services for air interface
communications
Technologies de l'information — Identification et capture
automatique de données —
Partie 11: Services de sécurité par suite cryptographique
PRESENT-80 pour communications par interface radio
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
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 requirements .3
4.3 Tag conformance and requirements .3
5 Introduction of the PRESENT-80 cryptographic suite . 4
6 Parameter and variable definitions . 4
7 Crypto suite state diagram . 4
8 Initialization and resetting . 5
9 Authentication . 5
9.1 Introduction .5
9.2 Message and response formatting .5
9.3 Tag authentication: AuthMethod “00” .6
9.3.1 General .6
9.3.2 TAM1 message .6
9.3.3 Intermediate Tag processing .7
9.3.4 TAM1 response .8
9.3.5 Final Interrogator processing . .8
9.4 Interrogator authentication: AuthMethod “01” .8
9.4.1 General .8
9.4.2 IAM1 message .9
9.4.3 Intermediate Tag processing #1 .9
9.4.4 IAM1 response .9
9.4.5 Intermediate Interrogator processing .10
9.4.6 IAM2 message .10
9.4.7 Intermediate Tag processing #2 .10
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 .11
9.5.3 Intermediate Tag processing #1 . 12
9.5.4 MAM1 response. 12
9.5.5 Intermediate Interrogator processing . 12
9.5.6 MAM2 message . 13
9.5.7 Intermediate Tag processing #2 . 13
9.5.8 MAM2 response . 13
9.5.9 Final Interrogator processing . .14
10 Communication . 14
11 Key table and Key update . 14
Annex A (normative) Crypto suite state transition table .15
Annex B (normative) Errors and error handling .16
Annex C (informative) Description of PRESENT. 17
© ISO/IEC 2025 – All rights reserved
iii
Annex D (informative) Test vectors .22
Annex E (normative) Protocol specific information .24
Bibliography .27
© ISO/IEC 2025 – 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-11:2023), 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 2025 – All rights reserved
v
International Standard ISO/IEC 29167-11:2025(en)
Information technology — Automatic identification and data
capture techniques —
Part 11:
Crypto suite PRESENT-80 security services for air interface
communications
1 Scope
This document defines the crypto suite for PRESENT-80 for the ISO/IEC 18000 series of air interfaces
standards for radio frequency identification (RFID) devices. This document provides a common crypto
suite for security for RFID devices for air interface standards and application standards. The crypto suite is
defined in alignment with existing air interfaces.
This document specifies basic security services that are use the lightweight block cipher PRESENT-80. The
variant of PRESENT that takes 128-bit keys is also considered in this document.
This document defines various methods of use for the cipher.
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 (all parts), Information technology — Radio frequency identification for item management
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
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 0’s and 1’s
© ISO/IEC 2025 – All rights reserved
3.1.2
block cipher
family of permutations parameterized by a cryptographic key (3.1.3); permutations map bit strings (3.1.1) of
a fixed length given by the block size to bit strings of the same length
3.1.3
cryptographic key
string of bits of a specified length that is used by the block cipher (3.1.2) to transform a data block (3.1.4)
3.1.4
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.5
PRESENT-k-ENC(key, data)
PRESENT encryption of data, a 64-bit data block (3.1.4), using key, a k-bit cryptographic key (3.1.3)
3.1.6
PRESENT-k-DEC(key, data)
PRESENT decryption of data, a 64-bit data block (3.1.4), using key, a k-bit cryptographic key (3.1.3)
3.1.7
salt
string of bits, typically randomly generated, that is used to diversify a cryptographic computation
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
EXAMPLE 3 |∅| = 0
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]
represents 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 ∅.
Field [∼] Non-empty string constructed from a string of bits denoted Field
Key.KeyID Cryptographic key identified and indexed by the numerical value KeyID
© ISO/IEC 2025 – All rights reserved
3.3 Abbreviated terms
CS Crypto suite
CSI Crypto Suite Indicator
IA Interrogator authentication
IChallenge Interrogator challenge
MA Mutual authentication
RFU Reserved for future use
RFID Radio frequency identification
TA Tag authentication
TID Tag Identification number
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”.
[1]
Relevant conformance test methods are provided in ISO/IEC 19823-11 .
4.2 Interrogator conformance and requirements
The Interrogator shall implement the mandatory commands defined in this document and conform to the
relevant part of the ISO/IEC 18000 series.
The Interrogator can implement any subset of the optional commands defined 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 requirements
The Tag shall implement the mandatory commands defined in this document for the supported types and
conform to the relevant part of the ISO/IEC 18000 series.
The Tag can implement any subset of the optional commands defined in this document.
The 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 2025 – All rights reserved
5 Introduction of the PRESENT-80 cryptographic suite
PRESENT-80 is a block cipher that uses an 80-bit key and is designed to be suitable for extremely constrained
environments such as RFID Tags.
The details of the operation of the PRESENT-80 cipher are provided in Annex C. The background to the
development of PRESENT-80 and its design principles are described in Reference [5].
A variant of PRESENT-80, denoted PRESENT-128, supports keys of length 128 bits.
Guidance on the appropriate variant to use in a given application lies outside the scope of this document.
A thorough security and risk assessment is advised before deployment. Errors and error-handling for this
cryptographic suite shall be in accordance with Annex B.
Test vectors for parts of this document are provided in Annex D.
Over-the-air protocol commands that use this cryptographic suite shall be in accordance with Annex E.
6 Parameter and variable definitions
Table 1 lists the variables and constants that are used in this document.
Table 1 — PRESENT-80 cryptographic suite variables and constants
Parameter Description
IChallenge A random challenge generated by the Interrogator
TChallenge A random challenge generated by the Tag
TRnd A random salt value generated by the Tag
IRnd A random salt value generated by the Interrogator
CTAM A pre-defined constant set to the two-bit value 00
CIAM A pre-defined constant set to the two-bit value 01
CMAM1 A pre-defined constant set to the two-bit value 10
CMAM2 A pre-defined constant set to the two-bit value 11
Purpose bits for Interrogator authentication
PurposeIAM If PurposeIAM[3:3] = 0 , the bits [2:0] are RFU with value 000 .
2 2
If PurposeIAM[3:3] = 1 , the bits [2:0] are manufacturer defined.
Purpose bits for Mutual authentication
PurposeMAM If PurposeMAM[3:3] = 0 , the bits [2:0] are RFU with value 000 .
2 2
If PurposeMAM[3:3] = 1 , the bits [2:0] are manufacturer defined.
A set of up to 16 keys Key.0 through to Key.15
Not all key values need to be specified. However, Key.j shall not be
Key.0 … Key.15
specified when there remains an unspecified Key.i with i
If there is only one key on the Tag, it shall be identified as Key.0.
7 Crypto suite state diagram
After power-up and after a reset, the cryptographic engine transitions into the Initial state. The
cryptographic engine shall follow the state transition in Table A.1. The state progressions defined by the
state transition table in Annex A is illustrated in Figure 1.
© ISO/IEC 2025 – 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 — Cryptographic engine state diagram
8 Initialization and resetting
After power-up and after a reset the cryptographic engine transitions into the Initial state.
Implementations of this suite shall ensure that all memory used for any intermediate results is cleared
a) after the completion of each cryptographic protocol,
b) if some cryptographic protocol is abandoned or incomplete, and
c) after reset.
9 Authentication
9.1 Introduction
This document supports Tag authentication, Interrogator authentication and Tag-Interrogator mutual
authentication.
9.2 Message and response formatting
Messages and responses are part of the security commands described in the air interface specification.
This document describes the formatting of message and response for a Tag authentication method, an
Interrogator authentication method and a Tag-Interrogator mutual authentication method.
© ISO/IEC 2025 – All rights reserved
Different authentication methods are identified using the AuthMethod field. The values for this field are
given in Table 2.
Table 2 — Values and descriptions for AuthMethod[1:0]
Value Description
00 Tag authentication
01 Interrogator authentication
10 Tag-Interrogator authentication
11 Vendor defined
9.3 Tag authentication: AuthMethod “00”
9.3.1 General
Tag authentication uses a challenge-response protocol, which is illustrated in Figure 2.
Figure 2 — Tag authentication via a challenge-response scheme
9.3.2 TAM1 message
The Interrogator shall generate a random IChallenge that is carried in the TAM1 message. The format of the
TAM1 message is given in Table 3.
The Interrogator may choose optional extended functionality for the TAM1 message. The Interrogator may
identify the cryptographic key Key.KeyID that should be used and, for Key.KeyID, whether it is 80 or 128 bits long.
NOTE 1 If a Tag supports anything other than a single 80-bit key, then extended functionality is required.
NOTE 2 Determining Key.KeyID is a matter of key management that lies outside the scope of this document.
NOTE 3 The variant(s) of PRESENT deployed on a device are manufacturer dependent.
NOTE 4 Appropriate mechanisms to generate IChallenge lie outside the scope of this document.
Table 3 — TAM1 message format
Field Payload
Always included In addition, for the case E=1
AuthMethod RFU Extension TID Challenge Key KeyLength E-RFU
Length (bits) 2 2 1 1 42 4 1 3
Value 00 00 E T IChallenge KeyID L 000
2 2 2
The fields shaded in gray are present only if E=1 .
© ISO/IEC 2025 – 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) – 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.
A Tag conforming to this document shall support the case of AuthMethod=00 .
The actions of the Tag when AuthMethod=00 are defined in this subclause. Actions of the Tag for other
values of AuthMethod are defined in 9.4 and 9.5.
If the value of the field RFU is not 00 , the Tag shall set a "Not Supported" crypto suite error.
The Tag shall parse the value of E.
— If E=0 :
— Extended functionality is not requested by the Interrogator.
— An 80-bit key, for which Key.ID=0, shall be used for Tag authentication.
— The TAM1 message payload has length 48 bits.
— If E=1 :
— Extended functionality is requested by the Interrogator.
— The fields Key, KeyLength, and E-RFU (see below) reveal the extended functionality requested by the
Interrogator.
— The TAM1 message payload has length 56 bits.
— A Tag shall support at least one of the options E=0 or E=1 . The Tag shall set a "Not Supported" crypto
2 2
suite error for a value of E that is not supported by the Tag.
The Tag shall parse the value of T.
— If T=0 , the Interrogator is requesting the output from the cryptographic operation. The reply to the
TAM1 message consists of the output from the cryptographic operation.
— If T=1 , the Interrogator is requesting some or all of the TID in addition to the output from the cryptographic
operation.
— If the Tag supports the option T=1 , then the reply to the TAM1 message consists of some or all of
the TID concatenated with the output from the cryptographic operation. There is no restriction on
the number, selection or location of TID bits returned. The choice and specification is manufacturer
defined.
— If the Tag does not support T=1 , then the Tag shall set a "Not Supported" crypto suite error.
— A Tag shall support the option T=0 and may support the option T=1 .
2 2
If present, the Tag parses KeyID, identifying the choice of cryptographic key.
— The Tag shall use Key.KeyID to compute TAM1 response.
— If the Tag does not support Key.KeyID, then the Tag shall set a "Not Supported" crypto suite error.
If present, the Tag parses L, the value of KeyLength.
— If L=0 , then PRESENT-80 shall be used in the computation of TAM1 response. If Key.KeyID does not have
length 80 bits, then the Tag shall set a "Not Supported" crypto suite error.
— If L=1 , then PRESENT-128 shall be used in the computation of TAM1 response. If Key.KeyID does not
have length 128 bits, then the Tag shall set a "Not Supported" crypto suite error.
© ISO/IEC 2025 – All rights reserved
If present, the Tag checks that the value of the field E-RFU=000 . If not, the Tag shall set a "Not Supported"
crypto suite error.
9.3.4 TAM1 response
If the TAM1 message is successfully parsed by the Tag, the Tag shall generate a random salt TRnd of length
20 bits.
The Tag shall use Key.KeyID of length k and PRESENT-k encryption to form a 64-bit string TResponse:
TResponse = PRESENT-k-ENC ( Key.KeyID, CTAM ‖ TRnd ‖ IChallenge ).
NOTE 1 In the case that E=0 , KeyID takes the default value 0 and the only key on the Tag – Key.0 – is an 80-bit key.
NOTE 2 Appropriate mechanisms to generate TRnd lie outside the scope of this document.
NOTE 3 Only one input block of 64 bits is encrypted and so only one invocation of PRESENT is required.
The TAM1 Response to the Interrogator is given in Table 4.
Table 4 — TAM1 Response format
Field Payload
Case T=0 Case T=1
2 2
Response Response
Length (bits) 64 65 to 160 (manufacturer dependent)
Value TResponse TID[∼] || TResponse
9.3.5 Final Interrogator processing
After receiving TAM1 response, the Interrogator shall use Key.KeyID to compute the 64-bit string R:
R = PRE
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...