ISO/IEC 19823-13

FINAL DRAFT
International
Standard
ISO/IEC
FDIS
19823-13
ISO/IEC JTC 1/SC 31
Information technology —
Secretariat: ANSI
Conformance test methods for
Voting begins on:
security service crypto suites —
2025-10-17
Part 13:
Voting terminates on:
2025-12-12
Cryptographic Suite Grain-128A
Technologies de l’information — Conformance test methods for
security service crypto suites —
Partie 13: Suite cryptographique Grain-128A
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/IEC FDIS 19823­13:2025(en) © ISO/IEC 2025

FINAL DRAFT
ISO/IEC FDIS 19823-13:2025(en)
International
Standard
ISO/IEC
FDIS
19823-13
ISO/IEC JTC 1/SC 31
Information technology —
Secretariat: ANSI
Conformance test methods for
Voting begins on:
security service crypto suites —
Part 13:
Voting terminates on:
Cryptographic Suite Grain-128A
Technologies de l’information — Conformance test methods for
security service crypto suites —
Partie 13: Suite cryptographique Grain-128A
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO/IEC 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
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 Reference number
ISO/IEC FDIS 19823­13:2025(en) © ISO/IEC 2025

© ISO/IEC 2025 – All rights reserved
ii
ISO/IEC FDIS 19823-13:2025(en)
Contents Page
Foreword .iv
Introduction .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 and abbreviated terms .2
4 Test methods . 2
4.1 General .2
4.2 By demonstration .2
4.3 By design .2
5 Test requirements for ISO/IEC 18000-62 interrogators and tags . 2
6 Test methods related to the ISO/IEC 29167-13 interrogators and tags . 2
6.1 Test map for optional features .2
6.2 Crypto suite requirements .3
6.2.1 General .3
6.2.2 Crypto suite requirements of ISO/IEC 29167-13:2025, Clauses 5 to 8 and
Annexes A to C .3
6.2.3 Crypto suite requirements of ISO/IEC 29167-13:2025, Clauses 9 to 12 and
Annex E .3
6.3 Test patterns . .14
6.3.1 General .14
6.3.2 Test pattern 1 .14
6.3.3 Test pattern 2 .14
6.3.4 Test pattern 3 .14
6.3.5 Test pattern 4 . 15
6.3.6 Test pattern 5 . 15
6.3.7 Test pattern 6 . 15
6.3.8 Test pattern 7 . 15
6.3.9 Test pattern 8 .16
6.3.10 Test pattern 9 .16
6.3.11 Test pattern 10 .16
6.3.12 Test pattern 11 .16
6.3.13 Test pattern 12 .17
6.3.14 Test pattern 13 .17
6.3.15 Test pattern 14 .17
6.3.16 Test pattern 15 .17
6.3.17 Test pattern 16 .18
6.3.18 Test pattern 17 .18
6.3.19 Test pattern 18 .18
6.3.20 Test pattern 19 .18
6.3.21 Test pattern 20 .19
6.3.22 Test pattern 21 .19
6.3.23 Test pattern 22 .19
6.3.24 Test pattern 23 .19
6.3.25 Test pattern 24 . 20
6.3.26 Test pattern 25 . 20
Bibliography .21

© ISO/IEC 2025 – All rights reserved
iii
ISO/IEC FDIS 19823-13:2025(en)
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 not
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 19823-13:2018), which has been
technically revised.
The main change is as follows: test items have been updated to reflect changes to the over-the-air protocol.
A list of all parts in the ISO/IEC 19823 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
iv
ISO/IEC FDIS 19823-13:2025(en)
Introduction
The ISO/IEC 29167 series describes security services that are applicable for the ISO/IEC 18000 series.
The various parts of the ISO/IEC 29167 series describe crypto suites that are optional extensions to the
ISO/IEC 18000 air interfaces.
The ISO/IEC 19823 series describes the conformance test methods for security service crypto suites.
The ISO/IEC 19823 series is related to the ISO/IEC 18047 series of standards, which describes the radio
frequency identification device conformance test methods, in the same way as the ISO/IEC 29167 series is
related to the ISO/IEC 18000 series. These relations mean that, for a product that is claimed to conform
to a pair ISO/IEC 18000-n and ISO/IEC 29167-m, the test methods of ISO/IEC 18047-n and ISO/IEC 19823-
m apply. If a product supports more than one part of ISO/IEC 18000 or ISO/IEC 29167, all related parts of
ISO/IEC 18047 and ISO/IEC 19823 apply.
The conformance parameters are the following:
— parameters that apply directly affecting system functionality and inter-operability;
— protocol including commands and replies; and
— nominal values and tolerances.
NOTE 1 ISO/IEC 18047-6 provides the conformance test requirements of ISO/IEC 18000-6, ISO/IEC 18000-61,
ISO/IEC 18000-62, ISO/IEC 18000-63 and ISO/IEC 18000-64.
NOTE 2 Test methods for interrogator and tag performance are covered by the multiple parts of the
ISO/IEC 18046 series.
© ISO/IEC 2025 – All rights reserved
v
FINAL DRAFT International Standard ISO/IEC FDIS 19823-13:2025(en)
Information technology — Conformance test methods for
security service crypto suites —
Part 13:
Cryptographic Suite Grain-128A
1 Scope
This document describes the test methods for determining the conformance of security crypto suites with
the specifications given in ISO/IEC 29167-13.
This document contains conformance tests for all mandatory and optional functions.
Unless otherwise specified, the tests in this document are only applicable to radio frequency identification
(RFID) tags and interrogators defined in the ISO/IEC 18000 series using ISO/IEC 29167-13.
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 17025, General requirements for the competence of testing and calibration laboratories
ISO/IEC 18000-62, Information technology — Radio frequency identification for item management — Part 62:
Parameters for air interface communications at 860 MHz to 960 MHz Type B
ISO/IEC 18047-6:2017, Information technology — Radio frequency identification device conformance test
methods — Part 6: Test methods for air interface communications at 860 MHz to 960 MHz
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Vocabulary
ISO/IEC 29167-13:2025, Information technology — Automatic identification and data capture techniques —
1)
Part 13: Crypto suite Grain-128A security services for air interface communications
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 ISO/IEC 29167-13 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/
1) Under preparation. Stage at the time of publication: ISO/IEC FDIS 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
3.2 Symbols and abbreviated terms
For the purposes of this document, the symbols and abbreviated terms given in ISO/IEC 19762 apply.
4 Test methods
4.1 General
This clause describes the general test methods for ISO/IEC 29167-13. As the parts of the ISO/IEC 19823
series are always tested in relation with ISO/IEC 18047, a duplication of information requirements and
specifications should be avoided.
Clause 5 describes elements that are covered in the respective parts of the ISO/IEC 18047 series and
therefore are not addressed in any part of the ISO/IEC 19823 series.
Clause 6 describes elements that are not covered by the ISO/IEC 18047 series which are also addressed in
the respective parts of the ISO/IEC 19823 series.
4.2 By demonstration
"By demonstration" means that laboratory testing of one or (if required for statistical reasons) multiple
products, processes or services to ensure conformance. A test laboratory that meets ISO/IEC 17025 shall
perform the indicated testing to ensure conformance of the component or system.
For Protocol requirements that are verified by demonstration, the test conditions are specified by this
document. The detailed test plan is at the discretion of the test laboratory.
4.3 By design
"By design" means that either design parameters or theoretical analysis, or both, that ensure conformance.
A vendor submitting a component or system for conformance testing shall provide the necessary technical
information, in the form of a technical memorandum or similar. A test laboratory shall issue a test certificate
indicating whether the technical analysis was sufficient to ensure conformance of the component or system.
For protocol requirements that are verified by design, the method of technical analysis is at the discretion
of the submitting vendor and is not specified by this document. In general, the technical analysis shall have
sufficient rigor and technical depth to convince a test engineer knowledgeable of the Protocol that the
particular requirement has been met.
5 Test requirements for ISO/IEC 18000-62 interrogators and tags
The requirements and recommendations of ISO/IEC 18047-6:2017, Clauses 4 and 5 on default conditions
applicable to the test methods and on setup of test equipment, respectively, shall be fulfilled.
Before a device under test (DUT) is tested according to this document, it shall successfully pass
ISO/IEC 18047-6:2017, Clause 7 on conformance tests for ISO/IEC 18000-62.
6 Test methods related to the ISO/IEC 29167-13 interrogators and tags
6.1 Test map for optional features
Table 1 lists all optional features of this crypto suite and shall be used as template to report the test results.
Furthermore, it is used to refer to the test requirements in 6.2.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
Table 1 — Test map for optional features
Item no. Feature Additional requirement Mark items to be Test
tested for supplied results
product
Tag Authentication Shall be tested with the authenticate command
(TA) of the declared ISO/IEC 18000 part.
Interrogator Shall be tested with the authenticate command
Authentication (IA) of the declared ISO/IEC 18000 part.
Secure authenticated Shall be tested with the SecureComm command
communication of the declared ISO/IEC 18000 part.
Shall be tested with the SecureComm command
4 Key update
of the declared ISO/IEC 18000 part.
Number of keys
supported
Table 2 lists all the crypto suite requirements that shall be tested in dependence of the features of Table 1 as
supported by the DUT. Items marked with M are mandatory and shall be tested for each DUT.
6.2 Crypto suite requirements
6.2.1 General
Subclause 6.2 refers to the requirements of ISO/IEC 29167-13.
6.2.2 Crypto suite requirements of ISO/IEC 29167-13:2025, Clauses 5 to 8 and Annexes A to C
All the requirements of ISO/IEC 29167-13:2025, Clauses 5 to 8 and Annexes A to C shall apply, inherently by
design only.
6.2.3 Crypto suite requirements of ISO/IEC 29167-13:2025, Clauses 9 to 12 and Annex E
Table 2 contains all the requirements of ISO/IEC 29167-13:2025, Clauses 9 to 12 and Annex E.
Table 2 — Crypto suite requirements of ISO/IEC 29167-13:2025, Clauses 9 to 12 and Annex E
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
1 9 The Tag’s air interface protocol logic shall M Tag By design
provide an external reset to the Tag crypto
engine which shall set INIT=FALSE, TA=FALSE,
IA=FALSE and ERROR=FALSE before transition
to the CS-Reset state.
2 9 The CS-Reset state shall process crypto com- M Tag By design
mands from the Tag’s air interface protocol logic
only when ERROR=FALSE. If an error condition
exists then the Tag crypto engine shall set ER-
ROR=TRUE and remain in the CS-Reset state.
3 9 If an error condition exists then the Tag crypto M Tag By design
engine shall set ERROR=TRUE and remain in the
CS-Reset state.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
4 9 The Tag shall report an error condition if it M Tag By design
receives a CryptoCommCmd,
CryptoSecCommCmd or CryptoKeyUpdate
command in the CS-Reset state.
5 9 The Tag shall check a CryptoAuthCmd payload M Tag By design
for any error conditions.
6 9 The Tag shall report an error condition if Step ≠ M Tag By demonstration
00 in the CS-Reset state. using test pattern 3
b
7 9 The Tag shall report an error condition if the M Tag By demonstration
KeyID value is not supported by the Tag. using test pattern 2
(only if TA is
supported), test
pattern 10 (only if
IA is supported) and
test pattern 16
8 9 The Tag shall report an error condition if M Tag By design
AuthMethod=00 and the Tag does not support
b
Tag authentication.
9 9 The Tag shall report an error condition if O Tag By design
AuthMethod=00 and the Options selected are
b
not supported by the Tag CSFeatures.
10 9 The Tag shall report an error condition if M Tag By design
AuthMethod=01 and the Tag does not support
b
Interrogator authentication.
11 9 The Tag shall report an error condition if O Tag By demonstration
AuthMethod=01 and Options ≠ 0000 using test pattern 9
b b.
12 9 The Tag shall report an error condition if M Tag By demonstration
AuthMethod=10 and Options ≠ 0000 using test pattern 15
b b.
13 9 The Tag shall report an error condition if M Tag By design
AuthMethod=11 and the Tag does not support
b
a vendor defined authentication.
14 9 If no error condition exists, the Tag shall M Tag By design
transition to the CS-Init state.
15 10.1 The authentication method to be performed M Tag, By design
shall be specified by the 2-bit value AuthMethod Interrogator
which is defined in Table 2.
16 10.1 If AuthMethod="00b", the Tag shall parse the O Tag By demonstration
Message for Tag Authentication as described in using test pattern 1
10.2.
17 10.1 If AuthMethod="01b" the Tag shall parse the O Tag By demonstration
Message Interrogator Authentication as using test pattern 8
described in 10.3
18 10.1 If AuthMethod="10b" the Tag shall parse the M Tag By demonstration
Message for Mutual Authentication as described using test pattern 14
in 10.4
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
19 10.1 Some of the authentication methods require M Tag, By design
multiple steps to be performed in a specific Interrogator
sequence. The current step in the sequence shall
be specified by the 2-bit value Step as defined in
Table 3.
20 10.1 During step 0 of an authentication method, the M Tag By design
Tag shall provide an 8-bit value CSFeatures
which is used to indicate which of the optional
Grain-128A CS features are supported by the Tag.
21 10.1 During step 0 and 1 of an authentication method, M Interrogator By design
the Interrogator shall provide a 4-bit value
Options
22 10.2.1 The Tag authentication method uses a challenge- O Interrogator, By design
response protocol having one pair of message Tag
exchange (see Figure 2).
23 10.2.2 For Tag authentication the Interrogator shall O Interrogator By design
generate a 48-bit random number for use as
IRandomNumber and issue the challenge to the
Tag with the TA.1 Payload as specified in Table 6.
24 10.2.3 The Tag shall generate a 48-bit random number O Tag By design
for use as TRandomNumber. The Tag crypto
engine shall be initialized for Tag authentication
using TRandomNumber, IRandomNumber and
the crypto key specified by KeyID. The crypto
engine then shall generate the Tag keystream.
25 10.2.3 The Tag shall respond to the challenge from the O Tag By design
Interrogator with the TA.1 Payload as specified
in Table 7.
26 10.2.3 The Tag shall transition to the TA.1 state after O Tag By design
the response to the Interrogator and shall set
TA=TRUE.
27 10.2.4 The Interrogator shall be initialized for Tag O Interrogator By design
authentication using TRandomNumber,
IRandomNumber and the crypto key specified by
KeyID. The crypto engine shall then generate the
Interrogator keystream.
28 10.2.4 The Interrogator shall compare the Tag key- O Interrogator By design
stream with the Interrogator keystream to
authenticate the Tag and accepts it as valid if
they are equal.
29 10.3.1 The Interrogator authentication method uses a O Interrogator, By design
challenge-response protocol having two pairs of Tag
message exchange as shown in (see Figure 3).
30 10.3.2 O Interrogator By design
In the first step of the Interrogator authentication
process, the Interrogator shall generate a 48-bit
random number for use as IRandomNumber and
request a challenge from the Tag using the IA.1
Payload, as specified in Table 8.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
31 10.3.3 The Tag shall generate a 48-bit random number O Tag By design
for use as TRandomNumber. The Tag crypto
engine shall be initialized for Interrogator au-
thentication using TRandomNumber, IRandom-
Number and the crypto key specified by KeyID.
32 10.3.3 The Tag shall respond with the challenge to the O Tag By design
Interrogator with the IA.1 Payload as specified
in Table 9.
33 10.3.3 The Tag shall transition to the IA.1 state after O Tag By design
the response to the Interrogator.
34 10.3.4 In the second step, the Interrogator crypto engine O Interrogator By design
shall be initialized for Interrogator authentication
using TRandomNumber, IRandomNumber and
the crypto key specified by KeyID. The crypto
engine shall then generate the Interrogator
keystream.
35 10.3.4 The Interrogator shall respond to the challenge O Interrogator By design
from the Tag with the IA.2 Payload as specified
in Table 10.
36 10.3.5 The Tag shall check the crypto command and O Tag By design
payload for any error conditions. If an error
condition exists then the Tag crypto engine shall
set ERROR=True and remain in the IA.1 state.
37 10.3.5 The Tag shall report an error condition if it re- O Tag By design
ceives a CryptoCommCmd, CryptoSecCommCmd
or CryptoKeyUpdate command in the IA.1 state.
38 10.3.5 The Tag shall report an error condition if O Tag By design
AuthMethod ≠ 01 in the IA.2 payload.
b
39 10.3.5 The Tag shall report an error condition if Step ≠ O Tag By design
01 in the IA.2 payload.
b
40 10.3.5 The Tag shall report an error condition if the O Tag By design
KeyID value is not the same as used for the IA.1
payload.
41 10.3.5 The Tag shall report an error condition if the O Tag By design
selected Options are not supported by the Tag
CSFeatures.
42 10.3.5 If no error condition exists, the Tag crypto O Tag By demonstration
engine shall generate the Tag keystream and using test pattern 8
compare it with the Interrogator keystream. and test pattern 11
It shall accept the Interrogator as valid if the
parameters are equal.
43 10.3.5 The Tag shall respond with the IA.2 Payload as O Tag By design
specified in Table 11.
44 10.3.5 If the Interrogator authentication succeeded, the O Tag By design
Tag shall transition to the IA.2 state after the
response to the Interrogator and set IA=TRUE.
45 10.3.5 If the Interrogator authentication failed, the Tag O Tag By design
shall transition to the IA.2 state after the re-
sponse to the Interrogator and set ERROR=True.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
46 10.4.1 The mutual authentication method uses a M Interrogator, By design
challenge-response protocol having two pairs of Tag
message exchange (see Figure 4).
47 10.4.2 In the first step of the mutual authentication M Interrogator By design
process, the Interrogator shall generate a 48-bit
random number for use as IRandomNumber and
request a challenge from the Tag using the MA.1
Payload, as specified in Table 12.
48 10.4.3 The Tag shall generate a 48-bit random number M Tag By design
for use as TRandomNumber. The Tag crypto
engine shall be initialized for mutual
authentication using the crypto key specified in
KeyID, TRandomNumber and IRandomNumber.
49 10.4.3 The Tag shall respond with the challenge to the M Tag By design
Interrogator with the MA.1 Payload as specified
in Table 13.
50 10.4.3 The Tag shall transition to the MA.1 state after M Tag By design
the response to the Interrogator.
51 10.4.4 In the second step, the Interrogator shall be M Interrogator By design
initialized for mutual authentication using
TRandomNumber, IRandomNumber and the
crypto key specified by KeyID. The crypto engine
shall then generate the Interrogator keystream.
52 10.4.4 The Interrogator shall respond to the challenge M Interrogator By design
from the Tag with the MA.2 Payload as specified
in Table 14.
53 10.4.5 The Tag shall check the crypto command and M Tag By design
payload for any error conditions. If an error
condition exists then the Tag crypto engine shall
set ERROR=True and remain in the MA.1 state.
54 10.4.5 The Tag shall report an error condition if it M Tag By design
receives a CryptoCommCmd,
CryptoSecCommCmd or CryptoKeyUpdate
command in the MA.1 state.
55 10.4.5 The Tag shall report an error condition if Auth- M Tag By design
Method ≠ 10 in the MA.2 payload.
b
56 10.4.5 The Tag shall report an error condition if Step ≠ M Tag By design
01 in the MA.2 payload.
b
57 10.3.5 The Tag shall report an error condition if the M Tag By design
KeyID value is not the same as used for the MA.1
payload.
58 10.3.5 The Tag shall report an error condition if the M Tag By design
selected Options are not supported by the Tag
CSFeatures.
59 10.4.5 If no error condition exists, the Tag crypto M Tag By demonstration
engine shall generate the Tag keystream and using test pattern 14
compare it with the Interrogator keystream. and test pattern 17
It shall accept the Interrogator as valid if the
parameters are equal.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
60 10.4.5 If the Interrogator is invalid, the Tag shall M Tag By design
transition to the MA.2 state after the response to
the Interrogator and set ERROR=True.
61 10.4.5 If the Interrogator is valid, the Tag crypto engine M Tag By design
shall generate a new value for the Tag key-
stream.
62 10.4.5 The Tag shall transition to the MA.2 state M Tag By design
after the response to the Interrogator and set
TA=IA=TRUE.
63 10.4.5 The Tag shall respond with the MA.2 Payload as M Tag By design
specified in Table 15.
64 10.4.6 The Interrogator shall check the authentication M Interrogator By design
status from the Tag and if it is OK, the
Interrogator crypto engine shall generate a new
value for the Interrogator keystream.
65 10.4.6 The Interrogator shall use the updated key- M Interrogator By design
streams to authenticate the Tag. The Tag is
accepted as valid the Tag keystream and the
Interrogator keystream are equal.
66 11.1 Authentication integrity shall be maintained M Interrogator, By design
for an Interrogator authentication and a mutual Tag
authentication, it is optional to maintain the
authentication integrity of a Tag authentication.
67 11.1 Authentication integrity shall be performed M Interrogator, By design
using either authenticated communication or Tag
secure authenticated communication, or both.
68 11.1 A Message Authentication Code (MAC) shall be M Interrogator, By design
used to provide the integrity protection. Tag
69 11.1 The Interrogator shall select between using a M Interrogator By design
MAC32 or a MAC64 via the Options parameter
during the authentication process.
70 11.2 If a Tag is authenticated as a result of Tag O Interrogator By demonstration
authentication, the Interrogator may use using test pattern 4
authenticated communication.
71 11.2 The TA.1 state shall process crypto responses O Tag By design
from the Tag’s air interface protocol logic only
when ERROR=FALSE.
72 11.2 The Tag shall check the crypto responses for O Tag By design
any error conditions. If an error condition
exists then the Tag crypto engine shall set
ERROR=True and remain in the TA.1 state.
73 11.2 An error condition shall occur for any O Tag By design
CryptoSecCommResp or CryptoAuthResp in
the TA.1 state.
74 11.2 If no error condition exists, the Tag shall provide O Tag By design
integrity protection for the Tag response in the
CryptoCommResp payload (see Table 17).
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
75 11.2 Integrity of the Tag response shall be performed O Tag By design
with the addition of an 8-bit value of 00
h
followed by a MAC.
76 11.2 The Tag shall remain in the TA.1 state after the O Tag By design
response is sent to the Interrogator.
77 11.2 The Interrogator shall generate a MAC for the O Interrogator By design
Tag response within the CryptoCommResp
payload to authenticate the Tag response.
78 11.2 The Interrogator shall accept the response as O Interrogator By design
valid if the MAC from the Tag equals the MAC
from the Interrogator.
79 11.2 If an Interrogator is authenticated as a result of O Interrogator By demonstration
Interrogator authentication, then it shall using test pattern 12
maintain the integrity of the authentication and test pattern 13
during subsequent communications with the
singulated Tag.
80 11.2 The Interrogator shall provide integrity O Interrogator By design
protection for the command in the
CryptoCommCmd payload (see Table 16).
81 11.2 Integrity of the Interrogator command shall be O Interrogator By design
performed with the addition of an 8-bit value of
00 followed by a MAC.
h
82 11.2 The IA.2 state shall process crypto commands O Tag By design
from the Tag’s air interface protocol logic only
when ERROR=FALSE.
83 11.2 The Tag shall check the crypto commands O Tag By design
for any error conditions. If an error condition
exists then the Tag crypto engine shall set
ERROR=True and remain in the IA.2 state.
84 11.2 An error condition shall occur for any O Tag By design
CryptoAuthCmd, CryptoKeyUpdate or
CryptoSecCommCmd in the IA.2 state.
85 11.2 If no error condition exists, the Tag shall O Tag By design
generate a MAC for the Interrogator command
within the CryptoCommCmd payload to
authenticate the Interrogator command.
86 11.2 The Tag shall accept the Interrogator command O Tag By design
as valid if the MAC from the Interrogator equals
the MAC from the Tag.
87 11.2 If the Interrogator command is invalid, the Tag O Tag By design
crypto engine shall set ERROR=TRUE and the
Tag shall remain in the IA.2 state.
88 11.2 If a Tag and Interrogator are both authenticated M Interrogator, By demonstration
as a result of mutual authentication, then both Tag using test pattern 14
shall maintain the integrity of the authentication and test pattern 19
during subsequent communications with the
singulated Tag.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items are optional and shall be tested only for devices that support the feature that is indicated by the requirement
a
All clauses, subclauses and tables referenced are from ISO/IEC 29167-13:2025.

© ISO/IEC 2025 – All rights reserved
ISO/IEC FDIS 19823-13:2025(en)
TTaabbllee 22 ((ccoonnttiinnueuedd))
Item Protocol
Requirement M/O Applies to Verification method
a
no. subclause
89 11.2 The Interrogator shall provide integrity M Interrogator By design
protection for the command in the
CryptoCommCmd payload (see Table 16).
90 11.2 Integrity of the Interrogator command shall be M Interrogator By design
performed with the addition of an 8-bit value of
00 followed by a MAC.
h
91 11.2 The MA.2 state shall process crypto commands M Tag By design
from the Tag’s air interface protocol logic only
when ERROR=FALSE.
92 11.2 The Tag shall check the crypto command for M Tag By design
any error conditions. If an error condition
exists then the Tag crypto engine shall set
ERROR=True and remain in the MA.2 state.
93 11.2 If secure authenticated communication is not M Tag By design
enabled, an error condition shall occur for any
CryptoAuthCmd, CryptoKeyUpdate or
CryptoSecCommCmd in the MA.2 state.
94 11.2 If no error condition exists, the Tag shall M Tag By design
generate a MAC for the Interrogator command
within the CryptoCommCmd payload to
authenticate the Interrogator command.
95 11.2 The Tag accepts the Interrogator command as M Tag By design
valid if the MAC from the Interrogator equals the
MAC from the Tag.
96 11.2 If the Interrogator command is invalid, the Tag M Tag By design
crypto engine shall set ERROR=TRUE and the
Tag shall remain in the MA.2 state.
97 11.2 The MA.2 state shall also process crypto M Tag By design
responses from the Tag’s air interface
protocol logic only when ERROR=FALSE.
98 11.2 The Tag shall check the crypto command for M Tag By design
any error conditions. If an error condition
exists then the Tag crypto engine shall set
ERROR=True and remain in the MA.2 state.
99 11.2 If the Tag responds to CryptoCommCmd, an M Tag By design
error condition shall occur for any
CryptoSecCommResp or CryptoAuthResp in
the MA.2 state.
100 11.2 If the no error condition exists, the Tag shall M Tag By design
provide integrity protection for the Tag response
in the CryptoCommResp payload (see Table 17).
101 11.2 Integrity of the Tag response shall be performed M Tag By design
with the addition of an 8-bit value of 00
h
followed by a MAC.
102 11.2 The Tag shall remain in the MA.2 state after the O Tag By design
response is sent to the Interrogator.
103 11.2 The Interrogator shall generate a MAC for the O Interrogator By design
Tag response within the CryptoCommResp
payload to authenticate the Tag response.
Key
M mandatory; items are mandatory and shall be tested for all devices
O optional; items ar
...