ISO/IEC 19823-21:2019
(Main)Information technology — Conformance test methods for security service crypto suites — Part 21: Crypto suite SIMON
Information technology — Conformance test methods for security service crypto suites — Part 21: Crypto suite SIMON
This document describes methods for determining conformance to the security crypto suite defined in ISO/IEC 29167‑21. This document contains conformance tests for all mandatory functions. The conformance parameters are the following: — parameters that apply directly affecting system functionality and inter-operability, — protocol including commands and replies, — nominal values and tolerances. Unless otherwise specified, the tests in this document are intended to be applied exclusively to RFID tags and interrogators defined in the ISO/IEC 18000 series using ISO/IEC 29167‑21.
Technologies de l'information — Méthodes d'essai de conformité pour les suites cryptographiques des services de sécurité — Partie 21: Suite cryptographique SIMON
General Information
Buy Standard
Standards Content (Sample)
Deleted: PRF
ISO/IEC 19823-21 :2019(E)
Information technology — Conformance test methods for security service crypto
suites — Part 21: Crypto suite SIMON
Technologies de l'information — Méthodes d'essai de conformité pour les suites cryptographiques
des services de sécurité— Partie 21: Suite cryptographique SIMON
---------------------- Page: 1 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
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).
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 http://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.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
A list of all parts in the ISO/IEC 19823 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
ii © ISO/IEC 2019 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
Introduction
The ISO/IEC 29167 series describes security services as applicable for the ISO/IEC 18000 series. The
various parts of ISO/IEC 29167 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. It
is related to the ISO/IEC 18047 series, which describes the radio frequency identification device
conformance test methods, in the same way as ISO/IEC 29167 is related to ISO/IEC 18000.
These relations mean that, for a product that is claimed to be compliant to a pair of 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.
NOTE 1 The conformance test requirements of ISO/IEC 18000‐6, ISO/IEC 18000‐61, ISO/IEC 18000‐62,
ISO/IEC 18000‐63, ISO/IEC 18000‐64 are currently all in ISO/IEC 18047‐6.
This document describes the test methods for the SIMON crypto suite as standardized in
ISO/IEC 29167‐21.
NOTE 2 Test methods for interrogator and tag performance are covered by ISO/IEC 18046 (all parts).
© ISO/IEC 2019 – All rights reserved iii
---------------------- Page: 3 ----------------------
Deleted: PRF
Error! Reference source not found. ISO/IEC 19823-21:2019(E)
Information technology — Conformance test methods for security
service crypto suites — Part 21: Crypto suite SIMON
1 Scope
This document describes methods for determining conformance to the security crypto suite defined in
ISO/IEC 29167‐21.
This document contains conformance tests for all mandatory functions.
The conformance parameters are the following:
— parameters that apply directly affecting system functionality and inter‐operability,
— protocol including commands and replies,
— nominal values and tolerances.
Unless otherwise specified, the tests in this document are intended to be applied exclusively to RFID
tags and interrogators defined in the ISO/IEC 18000 series using ISO/IEC 29167‐21.
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‐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 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 — Harmonized vocabulary
ISO/IEC 29167‐21:2018, Information technology — Automatic identification and data capture
techniques — Part 21: Crypto suite SIMON security services for air interface communications
3 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms, definitions, symbols and abbreviated terms given in
ISO/IEC 19762 and in ISO/IEC 29167‐21 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
© ISO/IEC 2019 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
4 Test methods
4.1 General
This document describes test methods for ISO/IEC 29167‐21. As parts of ISO/IEC 19823 are always
tested in relation to ISO/IEC 18047, duplication of information requirements and specifications is
meant to be avoided.
Clause 5 defines elements that are covered in the respective part of ISO/IEC 18047.
Clause 6 defines elements that are not covered by ISO/IEC 18047 and are therefore addressed in this
document.
4.2 By demonstration
If tests are labelled “by demonstration” then laboratory testing of one or (if required for statistical
reasons) multiple products, processes or services is required to ensure conformance. A test laboratory
that meets the requirements of 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 in this
document. The detailed test plan is left to the discretion of the test laboratory.
4.3 By design
If tests are labelled “by design” then verification of design parameters and/or theoretical analysis is
used to 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 report 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-63 interrogators and tags
The mandatory requirements and applicable optional requirements of ISO/IEC 18047‐6:2017, Clauses 4
and 5 shall be fulfilled.
Before a DUT is tested according to this document, it shall successfully pass ISO/IEC 18047‐6:2017,
Clause 7.
6 Test methods with respect to ISO/IEC 29167-21 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 a template to report the test
results. Furthermore, it is used to refer to the test requirements in 6.2.
2 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
Table 1 — Test map for optional features
To be tested for
Test
# Feature Additional requirement supplied
results
product?
Shall be tested with the Authenticate command of
1 TA
ISO/IEC 18000‐63
Shall be tested with the Authenticate command of
2 IA
ISO/IEC 18000‐63
Shall be tested with the Authenticate command of
3 MA
ISO/IEC 18000‐63
Secure Shall be tested with the SecureComm command
4
Communication of ISO/IEC 18000‐63
6.2 Crypto suite requirements
6.2.1 General
This clause refers to the requirements of ISO/IEC 29167‐21.
6.2.2 Crypto suite requirements of ISO/IEC 29167-21:2018, Clauses 1 to 8 and Annexes A to C
All the requirements of ISO/IEC 29167‐21:2018, Clauses 1 to 8 and Annexes A to C shall be met and
conformance shall be verified by design only.
6.2.3 Crypto suite requirements of ISO/IEC 29167-21:2018, Clauses 9 to 12 and Annex E
The requirements of ISO/IEC 29167‐21:2018, Clauses 9 to 12 and Annex E listed in Table 2 shall be met.
This document shall be read in conjunction with ISO/IEC 29167‐21 to provide a full explanation of the
terms used.
Table 2 — Crypto suite requirements for ISO/IEC 29167-21
Protocol MO
a
Item Requirement Applies to How verified
a b
subclause
The Interrogator shall generate a random
Interrogato
1 9.3.2 Interrogator challenge (IChallenge‐b/k) that is M By design
r
carried in the TAM1 message.
The Tag shall accept the TAM1 message at any
time (unless occupied by internal processing
and not capable of receiving messages), i.e. upon
2 9.3.3 receipt of the message with valid parameters, M Tag By design
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
2
3 9.3.3 value of Step is different, the Tag shall return a M Tag Test_Pattern 2
"Not Supported" error.
The Tag shall check if the RFU is "00". If the
2
4 9.3.3 value of RFU is different, the Tag shall return a M Tag Test_Pattern 2
"Not Supported" error.
The Tag shall check whether the values of
5 9.3.3 M Tag By design
BlockSize and KeySize are supported by the Tag.
© ISO/IEC 2019 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
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
6 9.3.3 M Tag By design
use in Tag authentication. If either or both of
these checks is failed, the Tag shall return a "Not
Supported" error.
The Tag shall check whether the parameter set
PS is supported. If the parameter set PS is not
7 9.3.3 M Tag Test_Pattern 2
supported, the Tag shall return a "Not
Supported" error.
Assuming that the TAM1 message is successfully
8 9.3.3 parsed by the Tag, the Tag shall prepare the M Tag By design
TAM1 response.
The Tag shall generate a random salt TRnd‐b/k
9 9.3.4 of length r bits were r is given for the parameter M Tag By design
set in Table 4.
The Tag shall use Key.KeyID and SIMON
encryption to form a b‐bit string TResponse
such that
10 9.3.4 M Tag Test_Pattern 1
TResponse = SIMON‐b/k‐ENC ( Key.KeyID,
C_TAM‐b/k ‖ TRnd‐b/k ‖ IChallenge‐b/k )
The Tag shall return TResponse to the
11 9.3.4 M Tag By design
Interrogator.
After receiving TAM1 response, the Interrogator
shall use Key.KeyID to compute the b‐bit string S
where:
Interrogato
12 9.3.5 M By design
S = SIMON‐b/k‐DEC ( Key.KeyID, TResponse ). r
The Interrogator shall check that S[t‐1:0] =
IChallenge‐b/k.
The Interrogator shall send an initial message
IAM1 to the Tag prompting the Tag to start a
Interrogato
challenge‐response exchange.
13 9.4.2 O By design
r
The Interrogator shall also indicate the variant
of SIMON to be used.
The Tag shall accept this message at any time
(unless occupied by internal processing and not
capable of receiving messages), i.e. upon receipt
14 9.4.3 of the message with valid parameters, the Tag O Tag By design
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
2
15 9.4.3 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
The Tag shall check if the Step is "00". If the
2
16 9.4.3 value of Step is different, the Tag shall return a O Tag Test_Pattern 3
"Not Supported" error.
4 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
The Tag shall check if the RFU is "00". If the
2
17 9.4.3 value of RFU is different, the Tag shall return a O Tag Test_Pattern 3
"Not Supported" error.
The Tag shall check whether the values of
BlockSize and KeySize are supported by the Tag.
18 9.4.3 O Tag By design
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
19 9.4.3 O Tag By design
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
20 9.4.3 parameter set PS is supported by the Tag. If not, O Tag Test_Pattern 3
the Tag shall return a "Not Supported" error.
If the IAM1 message is successfully parsed by
21 9.4.3 the Tag, the Tag shall calculate the IAM1 O Tag By design
response.
The Tag shall generate a random challenge
TChallenge‐b/k of length t bits, where t is
22 9.4.4 O Tag By design
determined by the parameter set, and shall send
this to the Interrogator.
The Interrogator shall construct the IAM2 Interrogato
23 9.4.5 O By design
message. r
The Interrogator shall form a b‐bit string
IResponse such that
IResponse = SIMON‐b/k‐DEC ( Key.KeyID, Interrogato
24 9.4.6 O Test_Pattern 4
C_IAM‐b/k ‖ IRnd‐b/k ‖ TChallenge‐b/k ). r
The Interrogator shall send IResponse to the
Tag as part of the IAM2 message; see Table 10.
The Tag shall only accept the IAM2 message
25 9.4.7 O Tag By design
when the cryptographic engine is in state PA1.
If Interrogator authentication is not supported
on the Tag, i.e. if "01" is not a valid value for
2
26 9.4.7 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
The Tag shall check if the Step is "01". If the
2
27 9.4.7 value of Step is different, the Tag shall return a O Tag Test_Pattern 5
"Not Supported" error.
The Tag shall check if the RFU is "0000". If the
2
28 9.4.7 value of RFU is different, the Tag shall return a O Tag Test_Pattern 5
"Not Supported" error.
The Tag shall use Key.KeyID to compute the b‐
bit string S where
29 9.4.7 O Tag By design
S = SIMON‐b/k‐ENC ( Key.KeyID, IResponse ).
The Tag shall check that S[t‐1:0] = TChallenge‐
30 9.4.7 O Tag By design
b/k.
31 9.4.7 The Tag shall prepare IAM2 response. O Tag By design
© ISO/IEC 2019 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
The Tag shall return the value of TStatus to the
32 9.4.8 O Tag Test_Pattern 6
Interrogator.
If, under conditions laid out in the over‐the‐air
protocol, there is no response from the Tag or if
Interrogato
33 9.4.9 the returned value of TStatus is 0, then the O By design
2
r
Interrogator shall abandon the cryptographic
protocol.
The Interrogator shall generate a random
Interrogato
34 9.5.2 Interrogator challenge (IChallenge‐b/k) that is O By design
r
carried in the MAM1 message.
The Interrogator shall indicate the variant of Interrogato
35 9.5.2 O By design
SIMON to be used. r
The Tag shall accept MAM1 message at any time
(unless occupied by internal processing and not
capable of receiving messages), i.e. upon receipt
36 9.5.3 of the message with valid parameters, the Tag O Tag By design
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
2
37 9.5.3 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
The Tag shall check if the Step is "00". If the
2
38 9.5.3 value of Step is different, the Tag shall return a O Tag Test_Pattern 7
"Not Supported" error.
The Tag shall check if the RFU is "002". If the
39 9.5.3 value of RFU is different, the Tag shall return a O Tag Test_Pattern 7
"Not Supported" error.
The Tag shall check whether the values of
BlockSize and KeySize are supported by the Tag.
40 9.5.3 O Tag By design
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
41 9.5.3 O Tag By design
use in Interrogator‐Tag mutual authentication. If
at least one of these checks is failed, the Tag
shall return a "Not Supported" error.
The Tag shall check whether the value of
42 9.5.3 parameter set PS is supported by the Tag. If not, O Tag By design
the Tag shall return a "Not Supported" error.
The Tag shall generate a random challenge
43 9.5.3 O Tag By design
TChallenge‐b/k.
The Tag shall construct a b‐bit string by
concatenating C_MAM‐b/k with the (b‐t‐c) most
44 9.5.3 O Tag By design
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
45 9.5.3 O Tag Test_Pattern 8
S = SIMON‐b/k‐ENC ( Key.KeyID, C_MAM‐b/k ‖
6 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
TChallenge‐b/k [t-1:2t-b+c] ‖
IChallenge‐b/k ).
After receiving MAM1 Response, the
Interrogator shall use Key.KeyID to compute the
b‐bit string T where:
Interrogato
46 9.5.5 T = SIMON‐b/k‐DEC ( Key.KeyID, TResponse[b- O By design
r
1:0] ).
1. The Interrogator shall check that T[t‐1:0] =
IChallenge‐b/k.
If the cryptographic protocol has not been
abandoned, the Interrogator shall form a b‐bit
string IResponse depending on the parameter
set PS as follows:
1. If PS = 00 then IResponse is equal to
2
SIMON‐b/k‐DEC ( Key.KeyID, C_MAM‐b/k ‖ T[b‐
t‐c‐1:0] ‖ T[b‐c‐1:t] ‖
TResponse[2t+c‐1:b] ).
Interrogato
47 9.5.6 O By design
r
2. If PS = 012 then IResponse is equal to T[b-c:t].
The Interrogator shall set SecureComm = 00012
if secure communications as described in
Section 10 will be used after mutual
authentication is completed. Otherwise, the
Interrogator shall set SecureComm = 00002.
The Interrogator shall send IResponse and the
value of SecureComm to the Tag as part of the
MAM2 message.
The Tag shall only accept this message when the
48 9.5.7 O Tag By design
cryptographic engine is in the state PA2.
If Mutual authentication is not supported on the
Tag, i.e. if "10" is not a valid value for
2
49 9.5.7 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
The Tag shall check if the Step is "01". If the
2
50 9.5.7 value of Step is different, the Tag shall return a O Tag Test_Pattern 9
"Not Supported" error.
The Tag shall check if the RFU is "0000". If the
2
51 9.5.7 value of RFU is different, the Tag shall return a O Tag Test_Pattern 9
"Not Supported" error.
If PS = 00 then the Tag computes the b‐bit
2
string S = SIMON‐b/k‐ENC ( Key.KeyID,
IResponse ).
SIMON‐b/k‐DEC ( Key.KeyID, C_MAM‐b/k ‖ T[b‐
52 9.5.7 O Tag Test_Pattern 10
t‐c‐1:0] ‖ T[b‐c‐1:t] ‖
TResponse[2t+c‐b‐1:0] ).
The Tag shall check if S[t‐1:0] = TChallenge‐b/k.
If PS = 01, then the Tag shall check whether S =
2
53 9.5.7 O Tag Test_Pattern 10
TChallenge‐b/k.
© ISO/IEC 2019 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
If TStatus = 1 and SecureComm = 1, the Tag
2 h
shall generate a random string NT. The Tag shall
54 9.5.7 further indicate using KeyID which key shall be O Tag Test_Pattern 10
2
used for the subsequent secure communication
session.
If, under conditions laid out in the over‐the‐air
protocol, there is no response from the Tag or if
Interrogato
55 9.5.9 the returned value of TStatus is 0 then the O By design
2
r
Interrogator shall abandon the cryptographic
protocol.
If the response is encapsulated, then it shall be
encapsulated as described in this crypto suite. A
56 10.1 O Tag By design
Tag shall only encapsulate the response to an
encapsulated command.
If a secure communication session is required,
Interrogato
57 10.2 the session shall be launched by the Interrogator O By design
r
after a successful mutual authentication.
SEC shall only be used after mutual
Interrogato
authentication has been established and it
r
58 10.3.1 guarantees the confidentiality and/or O By design
authenticity of the payload P being
Tag
encapsulated.
To send a command as an encapsulated payload
P, the Interrogator shall perform the following
steps:
1. The Interrogator shall verify that TStatus is
1. If not, the Interrogator shall abandon the
2
encapsulation process.
2. The Interrogator shall identify the key
Key.KeyID to be used.
2
3. The Interrogator shall construct the initial
value of the (b-16)‐bit string N as N = N ‖
T
TChallenge.
4. The Interrogator shall choose the length
T_Length for the authentication token T.
5. The Interrogator shall specify if the payload Interrogato
59 10.3.2 O By design
is authenticated or both encrypted and r
authenticated. If authentication without
encryption is required, then the
Interrogator shall set Enc = 0. If both
encryption and authentication are required,
then the Interrogator shall set Enc = 1.
6. The Interrogator shall specify if the payload
parameters should be protected. If
parameter protection is required, then the
Interrogator shall set Protect = 1. If
parameter protection is not required, then
the Interrogator shall set Protect = 0.
7. The Interrogator shall specify whether the
8 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
Tag response is to be in the clear,
authenticated, or encrypted and
authenticated.
8. The Interrogator shall construct a string X
where |X| = 0 or |X| = 8. If Protect = 0 then X
= ∅. If Protect = 1 then X = Response ‖ Enc ‖
Protect ‖ 002.
9. The Interrogator shall compute SEC
(Key.KeyID2, N, param, Enc, X ‖ P). The
output will be denoted Q ‖ T. Depending on
the value of Enc, Q will either be equal to X
‖ P or equal to the encryption of X ‖ P. In
both cases, an authentication tag T will be
included.
10. The Interrogator shall encapsulate the
payload defined in Table 17 and send this
to the Tag using an encapsulating over‐the‐
air command.
11. After a successful invocation of SEC, the
value of N shall be incremented by 1 using
integer addition.
To protect the reply to an encapsulated
command, the Tag shall perform the following
steps:
1. If the Tag is not in the state IA, then the Tag
shall return a “Cryptographic Suite Error”
and abandon the communication session.
2. The Tag shall process the encapsulating
command as described in 10.4.1. Unless an
error has been encountered, this will reveal
the encapsulated command and, optionally,
the values of Response, Enc, and Protect.
3. If Protect = 1, the Interrogator has used
2
parameter protection. Provided the
encapsulated command was processed
without error (10.4.1), the values of
60 10.3.3 Response, Enc, and Protect in Table 17 shall O Tag By design
be recovered from the output of CES in
10.4.1. If Protect = 02, the Interrogator has
not used parameter protection. The values
of Response, Enc, and Protect shall be
recovered from the payload in Table 17.
4. If Response = 0000, the Tag shall respond
2
without encapsulation.
5. Otherwise, the Tag shall execute the
encapsulated command and construct the
reply R.
6. If Response = 1 or 2, the Tag shall
x x
© ISO/IEC 2019 – All rights reserved 9
---------------------- Page: 12 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
compute SEC (Key.KeyID, N, param, Enc, R)
2
with the reply R. The value of Enc will be 0
if Response = 1 and Enc = 1 if Response =
x
2. The output will be denoted Q ‖ T.
x
7. The Tag shall return Q ‖ T to the
Interrogator instead of the unprotected
reply R.
8. After a successful invocation of SEC, the
value of N shall be incremented by 1 using
integer addition.
On receiving an encapsulating command with
payload Q ‖ T, the Tag shall perform the
following steps to process the payload Q ‖ T.
1. If the Tag is not in the state IA, then the
encapsulating command shall be ignored
and the Tag shall return a “Cryptographic
Suite Error” and abandon the
communication session.
2. The Tag shall check whether Key.KeyID is
2
authorized for use with secure
communication. If not, the Tag shall return
a "Not Supported" error.
3. The Tag shall check if param is supported
by the Tag. If not, the Tag shall return a
"Not Supported" error condition.
4. The Tag shall check if the value of Enc is
supported by the Tag. If not, the Tag shall
return a "Not Supported" error condition.
5. The Tag shall check if the RFU is "00". If
2
the value of RFU is different, the Tag shall
61 10.4.2 O Tag By design
return a "Not Supported" error.
6. The Tag shall construct the initial value of N
as N = NT ‖ TChallenge.
7. Assuming that the encapsulating command
is successfully parsed by the Tag, the Tag
shall recover Q ‖ T from the encapsulating
command and compute CES (Key.KeyID, N,
2
param, Enc, Q ‖ T).
8. If the output from CES (Key.KeyID, N,
2
T_Length, Enc, Q ‖ T) is AUTH_ERROR, the Tag
shall return a “Cryptographic Suite Error”
and abandon the communication session.
9. If the output from CES (Key.KeyID2, N,
T_Length, Enc, Q ‖ T) is not AUTH_ERROR, the
Tag shall consider the output to be the
intended encapsulated command.
10 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 13 ----------------------
ISO/IEC 19823-21:2019(E)
Deleted: PRF
10. After a successful invocation of CES, the
value of N shall be incremented by 1 using
integer addition.
To recover the original response from a
cryptographically‐protected Tag response, the
Interrogator shall perform the following steps:
1. The Interrogator shall verify that the Tag
response was received in response to an
encapsulated command issued by the
Interrogator. If not, the Interrogator shall
abandon the secure communication
process.
2. The Interrogator shall recover the
cryptographically‐protected reply Q ‖ T
from the over‐the‐air Tag response.
Interrogato
62 10.4.3 O By design
3. The Interrogator shall compute CES r
(Key.KeyID, N, param, Enc, Q ‖ T). If the
2
output is AUTH_ERROR, the Interrogator shall
abandon the communication session.
Otherwise, the output is the originally
constructed Tag reply R.
4. After a successful invocation of CES, the
value of N shall be incremented by 1 using
integer addition.
However, Key.j shall not be specified when there
63 11 O Tag By design
remain unspecified Key.i with i
If a Tag is unable to act on the key update
64 11 command, the Tag shall return a "Not O Tag By design
Supported" error.
1) The Authenticate command shall be
65 E.4.2 supported. M Tag Test_Pattern 1
2) The Challenge command shall not be
66 E.4.2 supported. M Tag By design
3) The maximum execution time for an
Authenticate Command containing a TAM1
67 E.4.2 M Tag Test_Pattern 1
payload shall be below 20 ms.
4) The Tag shall ignore commands from an
Interrogator during execution of a
68 E.4.2 M Tag By design
cryptographic operation.
5) The Tag shall not support sending the
contents of the ResponseBuffer in the reply
69 E.4.2 M Tag By design
to an ACK command.
6) The Tag shall support sending the contents
of the ResponseBuffer in the reply to a
70 E.4.2
...
INTERNATIONAL ISO/IEC
STANDARD 19823-21
First edition
2019-05
Information technology —
Conformance test methods for
security service crypto suites —
Part 21:
Crypto suite SIMON
Technologies de l'information — Méthodes d'essai de conformité pour
les suites cryptographiques des services de sécurité —
Partie 21: Suite cryptographique SIMON
Reference number
ISO/IEC 19823-21:2019(E)
©
ISO/IEC 2019
---------------------- Page: 1 ----------------------
ISO/IEC 19823-21:2019(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2019
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 19823-21:2019(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
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-63 interrogators and tags .2
6 Test methods with respect to ISO/IEC 29167-21 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-21:2018, Clauses 1 to 8 and
Annexes A to C . . 3
6.2.3 Crypto suite requirements of ISO/IEC 29167-21:2018, Clauses 9 to 12
and Annex E. 3
6.3 Test patterns .13
6.3.1 General.13
6.3.2 Test_Pattern 1 .14
6.3.3 Test_Pattern 2 .14
6.3.4 Test_Pattern 3 .15
6.3.5 Test_Pattern 4 .15
6.3.6 Test_Pattern 5 .16
6.3.7 Test_Pattern 6 .16
6.3.8 Test_Pattern 7 .17
6.3.9 Test_Pattern 8 .17
6.3.10 Test_Pattern 9 .18
6.3.11 Test_Pattern 10 .18
6.3.12 Test_Pattern 11 .19
Bibliography .20
© ISO/IEC 2019 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 19823-21:2019(E)
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).
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 http: //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.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
A list of all parts in the ISO/IEC 19823 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO/IEC 2019 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 19823-21:2019(E)
Introduction
The ISO/IEC 29167 series describes security services as applicable for the ISO/IEC 18000 series. The
various parts of ISO/IEC 29167 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.
It is related to the ISO/IEC 18047 series, which describes the radio frequency identification device
conformance test methods, in the same way as ISO/IEC 29167 is related to ISO/IEC 18000.
These relations mean that, for a product that is claimed to be compliant to a pair of 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.
NOTE 1 The conformance test requirements of ISO/IEC 18000-6, ISO/IEC 18000-61, ISO/IEC 18000-62, ISO/
IEC 18000-63, ISO/IEC 18000-64 are currently all in ISO/IEC 18047-6.
This document describes the test methods for the SIMON crypto suite as standardized in ISO/
IEC 29167-21.
NOTE 2 Test methods for interrogator and tag performance are covered by ISO/IEC 18046 (all parts).
© ISO/IEC 2019 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 19823-21:2019(E)
Information technology — Conformance test methods for
security service crypto suites —
Part 21:
Crypto suite SIMON
1 Scope
This document describes methods for determining conformance to the security crypto suite defined in
ISO/IEC 29167-21.
This document contains conformance tests for all mandatory functions.
The conformance parameters are the following:
— parameters that apply directly affecting system functionality and inter-operability,
— protocol including commands and replies,
— nominal values and tolerances.
Unless otherwise specified, the tests in this document are intended to be applied exclusively to RFID
tags and interrogators defined in the ISO/IEC 18000 series using ISO/IEC 29167-21.
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-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 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 —
Harmonized vocabulary
ISO/IEC 29167-21:2018, Information technology — Automatic identification and data capture
techniques — Part 21: Crypto suite SIMON security services for air interface communications
3 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms, definitions, symbols and abbreviated terms given in ISO/
IEC 19762 and in ISO/IEC 29167-21 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
© ISO/IEC 2019 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 19823-21:2019(E)
4 Test methods
4.1 General
This document describes test methods for ISO/IEC 29167-21. As parts of ISO/IEC 19823 are always
tested in relation to ISO/IEC 18047, duplication of information requirements and specifications is meant
to be avoided.
Clause 5 defines elements that are covered in the respective part of ISO/IEC 18047.
Clause 6 defines elements that are not covered by ISO/IEC 18047 and are therefore addressed in this
document.
4.2 By demonstration
If tests are labelled “by demonstration” then laboratory testing of one or (if required for statistical
reasons) multiple products, processes or services is required to ensure conformance. A test laboratory
that meets the requirements of 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 in this
document. The detailed test plan is left to the discretion of the test laboratory.
4.3 By design
If tests are labelled “by design” then verification of design parameters and/or theoretical analysis is
used to 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 report 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-63 interrogators and tags
The mandatory requirements and applicable optional requirements of ISO/IEC 18047-6:2017, Clauses 4
and 5 shall be fulfilled.
Before a DUT is tested according to this document, it shall successfully pass ISO/IEC 18047-6:2017,
Clause 7.
6 Test methods with respect to ISO/IEC 29167-21 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 a template to report the test
results. Furthermore, it is used to refer to the test requirements in 6.2.
2 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 19823-21:2019(E)
Table 1 — Test map for optional features
To be tested for
Test
# Feature Additional requirement supplied prod-
results
uct?
Shall be tested with the Authenticate command of
1 TA
ISO/IEC 18000-63
Shall be tested with the Authenticate command of
2 IA
ISO/IEC 18000-63
Shall be tested with the Authenticate command of
3 MA
ISO/IEC 18000-63
Secure Communi- Shall be tested with the SecureComm command of
4
cation ISO/IEC 18000-63
6.2 Crypto suite requirements
6.2.1 General
This clause refers to the requirements of ISO/IEC 29167-21.
6.2.2 Crypto suite requirements of ISO/IEC 29167-21:2018, Clauses 1 to 8 and Annexes A to C
All the requirements of ISO/IEC 29167-21:2018, Clauses 1 to 8 and Annexes A to C shall be met and
conformance shall be verified by design only.
6.2.3 Crypto suite requirements of ISO/IEC 29167-21:2018, Clauses 9 to 12 and Annex E
The requirements of ISO/IEC 29167-21:2018, Clauses 9 to 12 and Annex E listed in Table 2 shall be met.
This document shall be read in conjunction with ISO/IEC 29167-21 to provide a full explanation of the
terms used.
Table 2 — Crypto suite requirements for ISO/IEC 29167-21
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
The Interrogator shall generate a random Inter-
1 9.3.2 rogator challenge (IChallenge-b/k) that is carried M Interrogator By design
in the TAM1 message.
The Tag shall accept the TAM1 message at any
time (unless occupied by internal processing
and not capable of receiving messages), i.e. upon
2 9.3.3 receipt of the message with valid parameters, M Tag By design
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
2
3 9.3.3 value of Step is different, the Tag shall return a M Tag Test_Pattern 2
"Not Supported" error.
The Tag shall check if the RFU is "00 ". If the
2
4 9.3.3 value of RFU is different, the Tag shall return a M Tag Test_Pattern 2
"Not Supported" error.
a
All clause, subclause and table references are to ISO/IEC 29167-21.
b
M: mandatory; items marked with "M" are mandatory and shall be tested for all devices.
O: optional; items marked with “O” are optional and shall be tested only for devices that support the feature that is indicated
by the requirement.
© ISO/IEC 2019 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 19823-21:2019(E)
Table 2 (continued)
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
The Tag shall check whether the values of Block-
Size and KeySize are supported by the Tag. If at
5 9.3.3 M Tag By design
least one of these checks is failed, the Tag shall
return a "Not Supported" error.
The Tag shall check whether the values of Block-
Size and KeySize are supported by Key.KeyID and
6 9.3.3 that Key.KeyID is authorized for use in Tag authen- M Tag By design
tication. If either or both of these checks is failed,
the Tag shall return a "Not Supported" error.
The Tag shall check whether the parameter set
PS is supported. If the parameter set PS is not
7 9.3.3 M Tag Test_Pattern 2
supported, the Tag shall return a "Not Support-
ed" error.
Assuming that the TAM1 message is successful-
8 9.3.3 ly parsed by the Tag, the Tag shall prepare the M Tag By design
TAM1 response.
The Tag shall generate a random salt TRnd-b/k of
9 9.3.4 length r bits were r is given for the parameter set M Tag By design
in Table 4.
The Tag shall use Key.KeyID and SIMON encryp-
tion to form a b-bit string TResponse such that
10 9.3.4 M Tag Test_Pattern 1
TResponse = SIMON-b/k-ENC ( Key.KeyID, C_
TAM-b/k ‖ TRnd-b/k ‖ IChallenge-b/k )
The Tag shall return TResponse to the Interro-
11 9.3.4 M Tag By design
gator.
After receiving TAM1 response, the Interrogator
shall use Key.KeyID to compute the b-bit string
S where:
12 9.3.5 M Interrogator By design
S = SIMON-b/k-DEC ( Key.KeyID, TResponse ).
The Interrogator shall check that S[t-1:0] = IChal-
lenge-b/k.
The Interrogator shall send an initial message
IAM1 to the Tag prompting the Tag to start a
challenge-response exchange.
13 9.4.2 O Interrogator By design
The Interrogator shall also indicate the variant
of SIMON to be used.
The Tag shall accept this message at any time
(unless occupied by internal processing and not
capable of receiving messages), i.e. upon receipt
14 9.4.3 of the message with valid parameters, the Tag O Tag By design
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
2
15 9.4.3 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
a
All clause, subclause and table references are to ISO/IEC 29167-21.
b
M: mandatory; items marked with "M" are mandatory and shall be tested for all devices.
O: optional; items marked with “O” are optional and shall be tested only for devices that support the feature that is indicated
by the requirement.
4 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 19823-21:2019(E)
Table 2 (continued)
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
The Tag shall check if the Step is "00 ". If the
2
16 9.4.3 value of Step is different, the Tag shall return a O Tag Test_Pattern 3
"Not Supported" error.
The Tag shall check if the RFU is "00 ". If the
2
17 9.4.3 value of RFU is different, the Tag shall return a O Tag Test_Pattern 3
"Not Supported" error.
The Tag shall check whether the values of Block-
Size and KeySize are supported by the Tag. If at
18 9.4.3 O Tag By design
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
19 9.4.3 O Tag By design
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 param-
20 9.4.3 eter set PS is supported by the Tag. If not, the Tag O Tag Test_Pattern 3
shall return a "Not Supported" error.
If the IAM1 message is successfully parsed by the
21 9.4.3 O Tag By design
Tag, the Tag shall calculate the IAM1 response.
The Tag shall generate a random challenge
TChallenge-b/k of length t bits, where t is deter-
22 9.4.4 O Tag By design
mined by the parameter set, and shall send this
to the Interrogator.
The Interrogator shall construct the IAM2
23 9.4.5 O Interrogator By design
message.
The Interrogator shall form a b-bit string IRe-
sponse such that
IResponse = SIMON-b/k-DEC ( Key.KeyID, C_IAM-
24 9.4.6 O Interrogator Test_Pattern 4
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.
The Tag shall only accept the IAM2 message
25 9.4.7 O Tag By design
when the cryptographic engine is in state PA1.
If Interrogator authentication is not supported
on the Tag, i.e. if "01 " is not a valid value for
2
26 9.4.7 O Tag By design
AuthMethod, then the Tag shall return a "Not
Supported" error condition.
The Tag shall check if the Step is "01 ". If the
2
27 9.4.7 value of Step is different, the Tag shall return a O Tag Test_Pattern 5
"Not Supported" error.
The Tag shall check if the RFU is "0000 ". If the
2
28 9.4.7 value of RFU is different, the Tag shall return a O Tag Test_Pattern 5
"Not Supported" error.
The Tag shall use Key.KeyID to compute the b-bit
string S where
29 9.4.7 O Tag By design
S = SIMON-b/k-ENC ( Key.KeyID, IResponse ).
a
All clause, subclause and table references are to ISO/IEC 29167-21.
b
M: mandatory; items marked with "M" are mandatory and shall be tested for all devices.
O: optional; items marked with “O” are optional and shall be tested only for devices that support the feature that is indicated
by the requirement.
© ISO/IEC 2019 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 19823-21:2019(E)
Table 2 (continued)
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
The Tag shall check that S[t-1:0] = TChal-
30 9.4.7 O Tag By design
lenge-b/k.
31 9.4.7 The Tag shall prepare IAM2 response. O Tag By design
The Tag shall return the value of TStatus to the
32 9.4.8 O Tag Test_Pattern 6
Interrogator.
If, under conditions laid out in the over-the-air
protocol, there is no response from the Tag or
33 9.4.9 if the returned value of TStatus is 0 , then the O Interrogator By design
2
Interrogator shall abandon the cryptographic
protocol.
The Interrogator shall generate a random Inter-
34 9.5.2 rogator challenge (IChallenge-b/k) that is carried O Interrogator By design
in the MAM1 message.
The Interrogator shall indicate the variant of
35 9.5.2 O Interrogator By design
SIMON to be used.
The Tag shall accept MAM1 message at any time
(unless occupied by internal processing and not
capable of receiving messages), i.e. upon receipt
36 9.5.3 of the message with valid parameters, the Tag O Tag By design
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 AuthMeth-
2
37 9.5.3 O Tag By design
od, then the Tag shall return a "Not Supported"
error condition.
The Tag shall check if the Step is "00 ". If the
2
38 9.5.3 value of Step is different, the Tag shall return a O Tag Test_Pattern 7
"Not Supported" error.
The Tag shall check if the RFU is "00 ". If the
2
39 9.5.3 value of RFU is different, the Tag shall return a O Tag Test_Pattern 7
"Not Supported" error.
The Tag shall check whether the values of Block-
Size and KeySize are supported by the Tag. If at
40 9.5.3 O Tag By design
least one of these checks is failed, the Tag shall
return a "Not Supported" error.
The Tag shall check whether the values of Block-
Size and KeySize are supported by Key.KeyID and
that Key.KeyID is authorized for use in Interro-
41 9.5.3 O Tag By design
gator-Tag mutual authentication. If at least one of
these checks is failed, the Tag shall return a "Not
Supported" error.
The Tag shall check whether the value of param-
42 9.5.3 eter set PS is supported by the Tag. If not, the Tag O Tag By design
shall return a "Not Supported" error.
The Tag shall generate a random challenge TCh-
43 9.5.3 O Tag By design
allenge-b/k.
a
All clause, subclause and table references are to ISO/IEC 29167-21.
b
M: mandatory; items marked with "M" are mandatory and shall be tested for all devices.
O: optional; items marked with “O” are optional and shall be tested only for devices that support the feature that is indicated
by the requirement.
6 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 19823-21:2019(E)
Table 2 (continued)
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
The Tag shall construct a b-bit string by concat-
enating C_MAM-b/k with the (b-t-c) most signif-
44 9.5.3 O Tag By design
icant 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
45 9.5.3 S = SIMON-b/k-ENC ( Key.KeyID, C_MAM-b/k ‖ O Tag Test_Pattern 8
TChallenge-b/k [t -1: 2 t -b+c] ‖
IChallenge-b/k ).
After receiving MAM1 Response, the Interro-
gator shall use Key.KeyID to compute the b-bit
string T where:
46 9.5.5 T = SIMON-b/k-DEC ( Key.KeyID, TRespon- O Interrogator By design
se[b-1:0] ).
1. The Interrogator shall check that T[t-1:0] =
IChallenge-b/k.
If the cryptographic protocol has not been aban-
doned, the Interrogator shall form a b-bit string
IResponse depending on the parameter set PS as
follows:
1. If PS = 00 then IResponse is equal to
2
SIMON-b/k-DEC ( Key.KeyID, C_MAM-b/k ‖ T[b-
t-c-1:0] ‖ T[b-c-1:t] ‖
TResponse[2t+c-1:b] ).
47 9.5.6 O Interrogator By design
2. If PS = 01 then IResponse is equal to T[b-c:t].
2
The Interrogator shall set SecureComm = 0001
2
if secure communications as described in Section
10 will be used after mutual authentication is
completed. Otherwise, the Interrogator shall set
SecureComm = 0000 .
2
The Interrogator shall send IResponse and the
value of SecureComm to the Tag as part of the
MAM2 message.
The Tag shall only accept this message when the
48 9.5.7 O Tag By design
cryptographic engine is in the state PA2.
If Mutual authentication is not supported on the
Tag, i.e. if "10 " is not a valid value for AuthMeth-
2
49 9.5.7 O Tag By design
od, then the Tag shall return a "Not Supported"
error condition.
The Tag shall check if the Step is "01 ". If the
2
50 9.5.7 value of Step is different, the Tag shall return a O Tag Test_Pattern 9
"Not Supported" error.
The Tag shall check if the RFU is "0000 ". If the
2
51 9.5.7 value of RFU is different, the Tag shall return a O Tag Test_Pattern 9
"Not Supported" error.
a
All clause, subclause and table references are to ISO/IEC 29167-21.
b
M: mandatory; items marked with "M" are mandatory and shall be tested for all devices.
O: optional; items marked with “O” are optional and shall be tested only for devices that support the feature that is indicated
by the requirement.
© ISO/IEC 2019 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC 19823-21:2019(E)
Table 2 (continued)
Protocol
a b
Item Requirement MO Applies to How verified
a
subclause
If PS = 00 then the Tag computes the b-bit string
2
S = SIMON-b/k-ENC ( Key.KeyID, IResponse ).
SIMON-b/k-DEC ( Key.KeyID, C_MAM-b/k ‖ T[b-
52 9.5.7 O Tag Test_Pattern 10
t-c-1:0] ‖ T[b-c-1:t] ‖
TResponse[2t+c-b-1:0] ).
The Tag shall check if S[t-1:0] =
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.