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. 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 11: Interface radio pour services sécurité – Suite cryptographique PRESENT-80 security services for air interface communications

General Information

Status
Published
Publication Date
19-Feb-2023
Current Stage
9599 - Withdrawal of International Standard
Start Date
25-Sep-2025
Completion Date
30-Oct-2025

Relations

Effective Date
03-Feb-2024
Effective Date
26-Nov-2021

Overview

ISO/IEC 29167-11:2023 specifies a crypto suite based on the lightweight block cipher PRESENT-80 for securing air‑interface communications in the ISO/IEC 18000 series of RFID standards. The standard defines a common set of security services for RFID air interfaces and application layers, aligned with existing air‑interface protocols. It covers both the original PRESENT variant using an 80‑bit key and the 128‑bit key variant, and provides message formats, state diagrams and conformance rules for Tags and Interrogators.

Key topics and requirements

  • Crypto suite definition: Uses the PRESENT block cipher for block encryption/decryption of 64‑bit data blocks and supports both 80‑bit and 128‑bit key options.
  • Authentication methods: Specifies Tag authentication (TA), Interrogator authentication (IA) and Mutual authentication (MA) message flows and formatting, with AuthMethod identifiers (e.g., “00”, “01”, “10”) for interoperability.
  • Protocol elements: Includes parameter and variable definitions, initialization/reset procedures, state machine/state transition diagrams, and communication handling for air interface exchanges.
  • Key management: Defines key tables and key update mechanisms so Tags and Interrogators can support one or several keyed options and explicitly declare supported methods.
  • Interoperability & conformance: Details conformance rules for both Tag and Interrogator roles and protocol‑specific implementation notes (annexes include normative protocol info).
  • Verification tools: Contains normative test vectors and error‑handling provisions to aid implementation testing.
  • Standards governance: Notes potential patent claims and aligns with ISO/IEC editorial and patent disclosure practices.

Practical applications

  • Securing low‑power, resource‑constrained RFID deployments where lightweight cryptography is required (e.g., supply chain tags, asset tracking, IoT sensors).
  • Enabling mutual authentication between RFID Tags and Interrogators to prevent cloning, unauthorized reads, replay attacks and to improve privacy.
  • Providing a standardized security layer for manufacturers and system integrators to achieve interoperability across different ISO/IEC 18000 air interfaces.
  • Useful for developers building firmware for Tags, middleware for readers, and security assessments for the RFID ecosystem.

Who should use this standard

  • RFID product designers and firmware engineers
  • System integrators and solution architects for supply chain, logistics, retail and IoT
  • Security engineers evaluating lightweight cryptographic options for constrained devices
  • Standards bodies and test laboratories validating RFID interoperability and conformance

Related standards

  • ISO/IEC 18000 (RFID air interfaces)
  • ISO/IEC 29167‑1 (Security services for RFID air interfaces)
  • ISO/IEC 19762 (Harmonized AIDC vocabulary)

Keywords: ISO/IEC 29167-11:2023, PRESENT-80, RFID security, lightweight block cipher, air interface, Tag authentication, Interrogator authentication, mutual authentication, ISO/IEC 18000.

Standard

ISO/IEC 29167-11:2023 - Information technology — Automatic identification and data capture techniques — Part 11: Crypto suite PRESENT-80 security services for air interface communications Released:20. 02. 2023

English language
27 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEC 29167-11:2023 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Automatic identification and data capture techniques - Part 11: Crypto suite PRESENT-80 security services for air interface communications". This standard covers: 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. A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.

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. A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.

ISO/IEC 29167-11:2023 is classified under the following ICS (International Classification for Standards) categories: 35.040.50 - Automatic identification and data capture techniques. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEC 29167-11:2023 has the following relationships with other standards: It is inter standard links to ISO/IEC 29167-11:2025, ISO/IEC 29167-11:2014. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO/IEC 29167-11:2023 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO/IEC
STANDARD 29167-11
Second edition
2023-02
Information technology — Automatic
identification and data capture
techniques —
Part 11:
Crypto suite PRESENT-80
security services for air interface
communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 11: Interface radio pour services sécurité – Suite
cryptographique PRESENT-80 security services for air interface
communications
Reference number
© ISO/IEC 2023
© ISO/IEC 2023
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
ii
© ISO/IEC 2023 – 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 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” . 9
9.4.1 General . 9
9.4.2 IAM1 message . 9
9.4.3 Intermediate Tag processing #1 . 9
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 . 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 .12
9.5.3 Intermediate Tag processing #1 .12
9.5.4 MAM1 response.12
9.5.5 Intermediate Interrogator processing . 13
9.5.6 MAM2 message . 13
9.5.7 Intermediate Tag processing #2 . 13
9.5.8 MAM2 response . 14
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
iii
© ISO/IEC 2023 – All rights reserved

Annex C (informative) Description of PRESENT .17
Annex D (informative) Test vectors .22
Annex E (normative) Protocol specific information .24
Bibliography .27
iv
© ISO/IEC 2023 – All rights reserved

Foreword
SO (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).
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) or the IEC
list of patent declarations received (see https://patents.iec.ch).
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-11:2014), which has been
technically revised.
The main changes are as follows:
— the Interrogator authentication and Tag-Interrogator mutual authentication has been added;
— the variant of PRESENT that uses a 128-bit key has been added.
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.
v
© ISO/IEC 2023 – All rights reserved

Introduction
The International Organization for Standardization (ISO) and the International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may
involve the use of a patent.
ISO and IEC take no position concerning the evidence, validity and scope of this patent right.
The holder of this patent right has assured ISO and IEC that he/she is willing to negotiate licences under
reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this
respect, the statement of the holder of this patent right is registered with ISO and IEC. Information may
be obtained from the patent database available at www.iso.org/patents or https://patents.iec.ch.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights other than those in the patent database. ISO and IEC shall not be held responsible for
identifying any or all such patent rights.
vi
© ISO/IEC 2023 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29167-11:2023(E)
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.
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 (all parts), Information technology — Radio frequency identification for item management
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized 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 2023 – All rights reserved

3.1.2
block cipher
family of permutations parameterized by a cryptographic key (3.1.3); permutations map bit strings 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 2023 – 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 comply 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 2023 – 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 [3].
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 2023 – All rights reserved

Figure 1 — Cryptographic engine state diagram
NOTE 1 For all of TAM1, IAM1, MAM1, IAM2, MAM2 and errors return to Initial State without action.
NOTE 2 For all of TAM1, IAM1, MAM1, MAM2 and errors return to Initial State without action.
NOTE 3 For all of TAM1, IAM1, MAM1, IAM2 and errors return to Initial State without action.
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.
The following subclauses of this document describe the formatting of message and response for a
© ISO/IEC 2023 – All rights reserved

Tag authentication method, an Interrogator authentication method and a Tag-Interrogator mutual
authentication method.
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. This 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.
© ISO/IEC 2023 – All rights reserved

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
2.
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.
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"
2 2
crypto 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
© ISO/IEC 2023 – All rights reserved

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.
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 invoca
...

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...