ISO/IEC 29167-10:2017
(Main)Information technology — Automatic identification and data capture techniques — Part 10: Crypto suite AES-128 security services for air interface communications
Information technology — Automatic identification and data capture techniques — Part 10: Crypto suite AES-128 security services for air interface communications
ISO/IEC 29167-10:2017 specifies the crypto suite for AES-128 for the ISO/IEC 18000 air interfaces standards for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto suite for security for RFID devices that might be referred by ISO committees for air interface standards and application standards. ISO/IEC 29167-10:2017 specifies a crypto suite for AES-128 for an air interface for RFID systems. The crypto suite is defined in alignment with existing air interfaces. ISO/IEC 29167-10:2017 specifies various authentication methods and methods of use for the encryption algorithm. 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 10: Services de sécurité par suite cryptographique AES-128 pour communications par interface radio
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29167-10
Second edition
2017-09
Information technology — Automatic
identification and data capture
techniques —
Part 10:
Crypto suite AES-128 security services
for air interface communications
Technologies de l'information — Techniques automatiques
d'identification et de capture de données —
Partie 10: Services de sécurité par suite cryptographique AES-128
pour communications par interface radio
Reference number
©
ISO/IEC 2017
© ISO/IEC 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO/IEC 2017 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms, definitions, symbols and abbreviated terms . 1
4 Conformance . 6
4.1 Air interface protocol specific information . 6
4.2 Interrogator conformance and obligations . 6
4.3 Tag conformance and obligations . 6
5 Introduction of the AES-128 crypto suite . 6
6 Parameter definitions . 7
7 Crypto suite state diagram . 8
8 Initialization and resetting . 9
9 Authentication . 9
9.1 General . 9
9.2 Adding custom data to authentication process .10
9.3 Message and response formatting .12
9.4 Tag authentication (Method “00” = TAM) .13
9.4.1 General.13
9.4.2 TAM1 Message .13
9.4.3 TAM1 Response .14
9.4.4 Final Interrogator processing TAM1 .14
9.4.5 TAM2 Message .14
9.4.6 TAM2 Response .16
9.4.7 Final Interrogator processing TAM2 .20
9.5 Interrogator authentication (Method “01” = IAM).21
9.5.1 General.21
9.5.2 IAM1 Message .21
9.5.3 IAM1 Response .22
9.5.4 Final Interrogator processing IAM1 .22
9.5.5 IAM2 Message .22
9.5.6 IAM2 Response .23
9.5.7 Final Interrogator processing IAM2 .23
9.5.8 IAM3 Message .23
9.5.9 IAM3 Response .28
9.5.10 Final Interrogator processing IAM3 .29
9.6 Mutual authentication (Method “10” = MAM) .29
9.6.1 General.29
9.6.2 MAM1 Message .29
9.6.3 MAM1 Response .30
9.6.4 Final Interrogator processing MAM1 .30
9.6.5 MAM2 Message .30
9.6.6 MAM2 Response .31
9.6.7 Final Interrogator processing MAM2 .31
10 Communication .31
11 Key Table and KeyUpdate .31
Annex A (normative) Crypto suite state transition table .34
Annex B (normative) Error conditions and error handling .35
© ISO/IEC 2017 – All rights reserved iii
Annex C (normative) Cipher description .36
Annex D (informative) Test vectors .40
Annex E (normative) Protocol specific information.41
Annex F (informative) Examples .49
Bibliography .58
iv © ISO/IEC 2017 – All rights reserved
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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on 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 the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by 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-10:2015), which has been
technically revised.
A list of all parts in the ISO/IEC 29167 series can be found on the ISO website.
© ISO/IEC 2017 – All rights reserved v
Introduction
This document specifies the security services of an AES-128 crypto suite. AES has a fixed block size of
128 bits and a key size of 128 bits, 192 bits or 256 bits. This document uses AES with a fixed key size of
128 bits and is referred to as AES-128.
This document specifies procedures for the authentication of a Tag and or an Interrogator using AES-
128 and provides the following features:
— Tag Authentication;
— Tag Authentication allows authenticated and encrypted reading of a part of the Tag’s memory;
— Interrogator Authentication;
— Interrogator Authentication allows authenticated and encrypted writing of a part of the Tag’s memory;
— Mutual Authentication.
Crypto suite only supports encryption on the Tag and uses encryption for “encrypting” messages sent
from the Tag to the Interrogator and “decrypting” messages received from the Interrogator.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this document
might involve the use of patents concerning radio-frequency identification technology given in the
clauses identified below.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licenses
under reasonable and non-discriminatory terms and conditions with applicants throughout the world.
In this respect, the statements of the holders of these patent rights are registered with ISO and IEC.
Information on the declared patents may be obtained from:
Impinj, Inc.
Chris Dorio
Chief Strategy and Technology Officer
The latest information on IP that might be applicable to this document can be found at www.iso.
org/patents.
vi © ISO/IEC 2017 – All rights reserved
INTERNATIONAL STANDARD ISO/IEC 29167-10:2017(E)
Information technology — Automatic identification and
data capture techniques —
Part 10:
Crypto suite AES-128 security services for air interface
communications
1 Scope
This document specifies the crypto suite for AES-128 for the ISO/IEC 18000 air interfaces standards
for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto suite for
security for RFID devices that might be referred by ISO committees for air interface standards and
application standards.
This document specifies a crypto suite for AES-128 for an air interface for RFID systems. The crypto
suite is defined in alignment with existing air interfaces.
This document specifies various authentication methods and methods of use for the encryption
algorithm. 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 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) —
Part 1: Mechanisms using a block cipher
ISO/IEC 18000-63, Information technology — Radio frequency identification for item management —
Part 63: Parameters for air interface communications at 860 MHz to 960 MHz Type C
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Harmonized vocabulary
ISO/IEC 29167-1, Information technology — Automatic identification and data capture techniques —
Part 1: Security services for RFID
3 Terms, definitions, symbols and abbreviated terms
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1 Terms and definitions
© ISO/IEC 2017 – All rights reserved 1
3.1.1
AES-CMAC-96 (key, data)
CMAC generation with input data "data", using initialization vector "IV" and 128-bit key "key",
truncating the result by using only the 96 most significant bits from the 128-bit CMAC code
3.1.2
AES-DEC (key, data)
AES in ECB decryption mode of input data "data" and 128-bit key "key"
3.1.3
AES-ENC (key, data)
AES in ECB encryption mode of input data "data" and 128-bit key "key"
3.1.4
AuthenticationBlock
variable that contains information to verify the authenticity of the Tag or the Interrogator
3.1.5
bit string
ordered sequence of 0s and 1s
3.1.6
block cipher
family of functions and their inverse functions that is parameterized by keys
Note 1 to entry: The functions map bit strings of a fixed length to bit strings of the same length.
3.1.7
blocksize
number of bits in an input (or output) block of the block cipher
3.1.8
CBC _AES (IV, key, data)
ENC
AES in CBC encryption mode of input data "data", using initialization vector "IV" and 128-bit key "key",
according to NIST/SP 800-38A
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-ENC( key, I XOR IV ), and
1 1
— O = AES-ENC( key, I XOR O ).
n n (n−1)
Note 2 to entry: C.2 describes the cipher block chaining.
3.1.9
CBC _AES (IV, key, data)
DEC INV
AES in CBC decryption mode of input data "data", using initialization vector "IV" and 128-bit key "key",
according to NIST/SP 800-38A
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-DEC( key, I ) XOR IV, and
1 1
— O = AES-DEC( key, I ) XOR I ).
n n (n-1)
3.1.10
CBC _AES (IV, key, data)
ENC INV
CBC in encryption mode using initialization vector "IV" and 128-bit key "key"
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-DEC( key, I XOR IV ), and
1 1
2 © ISO/IEC 2017 – All rights reserved
— O = AES-DEC( key, I XOR O ).
n n (n-1)
3.1.11
CBC _AES (IV, key, data)
DEC
CBC in decryption mode using initialization vector "IV" and 128-bit key "key"
Note 1 to entry: Output blocks (O ) are obtained from input blocks (I ) as follows:
i i
— O = AES-ENC( key, I ) XOR IV, and
1 1
— O = AES-ENC( key, I ) XOR I )
n n (n-1)
3.1.12
ciphertext
encrypted plaintext
3.1.13
cipher-based message authentication code
CMAC
algorithm based on a symmetric key block cipher
Note 1 to entry: In this document, data is systematically padded with zero bits before computing the MAC,
resulting in the last block of MAC inputs is always complete. Therefore, K1-MAC is always used. It makes the
computation of K2-MAC useless.
Note 2 to entry: The computation of the MAC shall comply with the requirements of MAC method 5 in
ISO/IEC 9797-1.
3.1.14
Command (Message)
data that the Interrogator sends to a Tag with "Message" as parameter
3.1.15
D
number of 128-bit blocks that can be added to the authentication response as custom data and header
3.1.16
data block
block
sequence of bits whose length is the block size of the block cipher
3.1.17
ENC_key
variable that contains the key that will be used for cryptographic confidentiality protection
Note 1 to entry: This variable shall be used for cryptographic confidentiality protection.
3.1.18
H
number of bits of the header
3.1.19
Header
H bits composed of BlockSize, Offset, Profile and BlockCount
3.1.20
Initialization Vector
IV
input block that some modes of operation require as an additional initial input
© ISO/IEC 2017 – All rights reserved 3
3.1.21
input block
data that is an input to either the forward cipher function or the inverse cipher function of the block
cipher algorithm
3.1.22
Key
string of bits used by a cryptographic algorithm to transform plaintext into ciphertext or vice versa or
to produce a message authentication code
3.1.23
KeyID
numerical designator for a single key
3.1.24
Key[KeyID].ENC_key
variable that contains the key that will be used for encryption
Note 1 to entry: This variable shall be used for encryption.
3.1.25
Key[KeyID].MAC_key
key that can be used for cryptographic integrity protection
3.1.26
MAC_key
variable that contains the key that will be used for cryptographic integrity protection
Note 1 to entry: This variable shall be used for cryptographic integrity protection.
3.1.27
Memory Profile
start pointer within the Tag’s memory for addressing custom data block
3.1.28
Message
part of the command that is defined by the crypto suite
3.1.29
Mode of Operation
Mode
algorithm for the cryptographic transformation of data that features a symmetric key block cipher
algorithm
3.1.30
output block
data that is an output of either the forward cipher function or the inverse cipher function of the block
cipher algorithm
3.1.31
Plaintext
ordinary readable text before being encrypted into ciphertext or after being decrypted from ciphertext
3.1.32
Reply (Response)
data that the Tag returns to the Interrogator with "Response" as parameter
3.1.33
Response
part of the reply (stored or sent) that is defined by the crypto suite
4 © ISO/IEC 2017 – All rights reserved
3.1.34
word
bit string comprised of 16 bits
3.2 Symbols and abbreviated terms
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CMAC Cipher-based Message Authentication Code
DIV integral part of a division
Field[a:b] selection from a string of bits in Field
For a > b, selection of a string of bits from the bit string Field. Selection ranges from bit
number a until and including bit number b from the bits of the string in Field, whereby
Field[0] represents the least significant bit. For selecting one single bit from Field a=b.
For example, Field[2:0] represents the selection of the three least significant bits of Field.
FIPS Federal Information Processing Standard
IV Initialization Vector
LSB Least Significant Byte
MAC Message Authentication Code
MPI Memory Profile Indicator
MSB Most Significant Byte
NIST National Institute of Standards and Technology (United States)
RFU Reserved for Future Use
TID Tag-IDentification or Tag IDentifier (depending on context)
UII Unique Identification ID
xxxx binary notation of term "xxxx", where "x" represents a binary digit
b
xxxx hexadecimal notation of term "xxxx", where "x" represents a hexadecimal digit
h
In this crypto suite, the bytes in the hexadecimal numbers are presented with the most
significant byte at the left and the least significant byte at the right. The bit order per
byte is also presented with the most significant bit at the left and the least significant bit
at the right.
For example, in "ABCDEF" the byte "AB" is the most significant byte and the byte "EF" is
the least significant byte.
|| concatenation of syntax elements, transmitted in the order written (from left to right)
For example, "123456" || "ABCDEF" results in "123456ABCDEF", where the byte "12" is the
most significant byte and the byte "EF" is the least significant byte.
Note 1 to entry This protocol uses the following notational conventions:
— States and flags are denoted in bold. Some command parameters are also flags; a command
parameter used as a flag will be bold. Example: ready.
© ISO/IEC 2017 – All rights reserved 5
— Command parameters are underlined. Some flags are also command parameters; a flag used as
a command parameter will be underlined. Example: Pointer.
— Commands are denoted in italics. Variables are also denoted in italics. Where there might be
confusion between commands and variables, this protocol will make an explicit statement.
Example: Query.
4 Conformance
4.1 Air interface protocol specific information
To claim conformance with this document, an Interrogator or Tag shall comply with all relevant clauses
of this document, except those marked as “optional”.
4.2 Interrogator conformance and obligations
To conform to this document, an Interrogator shall implement the mandatory commands defined in
this document and conform to the relevant part of ISO/IEC 18000.
To conform to this document, an Interrogator can implement any subset of the optional commands
defined in this document.
To conform to 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 obligations
To conform to this document, a Tag shall implement the mandatory commands defined in this document
for the supported types and conform to the relevant part of ISO/IEC 18000.
To conform to this document, a Tag can implement any subset of the optional commands defined in this
document.
To conform to this document, a Tag shall not
— implement any command that conflicts with this document, or
— require the use of an optional, proprietary or custom command to meet the requirements of this
document.
5 Introduction of the AES-128 crypto suite
The Advanced Encryption Standard (AES) is an open, royalty-free, symmetric block cipher based on so-
called substitution-permutation networks. AES is highly suitable for efficient implementation in both
software and hardware, including extremely constrained environments such as RFID Tags. The AES
cipher is standardized as ISO/IEC 18033-3.
AES is approved by the National Institute of Standards and Technology (NIST). It was approved as a
standard in 2001 following a 5-year standardization process that involved a number of competing
encryption algorithms and published as FIPS PUB 197 in November 2001.
6 © ISO/IEC 2017 – All rights reserved
AES was published, along with design criteria and test vectors, in Reference [2].
NOTE AES normally uses encryption to encrypt plaintext and decryption to decrypt ciphertext. This
crypto suite uses encryption both to encrypt plaintext as well as to decrypt ciphertext. This allows the use of an
encryption-only implementation on the Tag.
References for AES test vectors are provided in Annex D.
Annex F provides examples for the implementation of the functionality that is specified in this
document.
6 Parameter definitions
Table 1 describes all the parameters that are used in this document.
Table 1 — Definition of AES-128 crypto suite parameters
Parameter Description
Parameter used in IResponse of IAM3 Message with the parameters:
AES-DEC(Key[KeyID].ENC_key, C_IAM3[11:0] || Purpose_IAM3[3:0] || IRnd_
AuthenticationBlock IAM3[31:0] || TChallenge_IAM1[79:0])
This parameter is only introduced to make the content of the IResponse of
IAM3 Message easier to read.
16-bit predefined constant for MAM1 with the value "DA83 "
h
C_MAM1[15:0]
(for Tag to Interrogator response)
12-bit predefined constant for MAM2 with the value "DA8 "
h
C_MAM2[11:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM1 with the value "96C5 "
h
C_TAM1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C5 "
h
C_TAM2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C0 "
h
C_TAM2_0[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C1 "
h
C_TAM2_1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C2 "
h
C_TAM2_2[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value "96C3 "
h
C_TAM2_3[15:0]
(for Tag to Interrogator response)
12-bit predefined constant for IAM2 with the value "DA8 "
h
C_IAM2[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DA8 "
h
C_IAM3_0[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DA9 "
h
C_IAM3_1[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DAA "
h
C_IAM3_2[11:0]
(for Interrogator to Tag response)
12-bit predefined constant for IAM3 with the value "DAB "
h
C_IAM3_3[11:0]
(for Interrogator to Tag response)
CUSTOMDATA(D*128-H) Part of the Tag’s memory that may be included in the authentication process
HEADER(H) Header of H bits preceding the custom data
IChallenge_MAM1[79:0] 80-bit challenge generated by the Interrogator for use in MAM1
IChallenge_TAM1[79:0] 80-bit challenge generated by the Interrogator for use in TAM1
IChallenge_TAM2[79:0] 80-bit challenge generated by the Interrogator for use in TAM2
© ISO/IEC 2017 – All rights reserved 7
Table 1 (continued)
Parameter Description
IRnd_IAM2[31:0] 32-bit random data generated by the Interrogator for use in IAM2
IRnd_IAM3[31:0] 32-bit random data generated by the Interrogator for use in IAM3
Keyset identified by KeyID, consisting of ENC_key for encryption and
Key[KeyID]
(optional) MAC_key for integrity protection
Variable that shall contain the key that will be used for cryptographic
MAC_key[127:0]
integrity protection
Authentication purpose bits for IAM2
Purpose_IAM2[3:0] If Purpose_IAM2[3:3] = 0 the bits [2:0] are RFU with value 000
b b
If Purpose_IAM2[3:3] = 1 the bits [2:0] are manufacturer defined
b
Authentication purpose bits for IAM3
Purpose_IAM3[3:0] If Purpose_IAM3[3:3] = 0 the bits [2:0] are RFU with value 000
b b
If Purpose_IAM3[3:3] = 1 the bits [2:0] are manufacturer defined
b
Authentication purpose bits for MAM2
Purpose_MAM2[3:0] If Purpose_MAM2[3:3] = 0 the bits [2:0] are RFU with value 000
b b
If Purpose_MAM2[3:3] = 1 the bits [2:0] are manufacturer defined
b
TChallenge_IAM1[79:0] 80-bit challenge that the Tag generates for use in IAM1
TChallenge_MAM1[79:0] 80-bit challenge that the Tag generates for use in MAM1
TRnd_TAM1[31:0] 32-bit random data provided by the Tag for TAM1
TRnd_TAM2[31:0] 32-bit random data provided by the Tag for TAM2
7 Crypto suite state diagram
The transitions between the crypto suite states are specified in Figure 1.
The Tag shall transition from the Start State to the Next State conforming to the requirements specified
in Annex A.
8 © ISO/IEC 2017 – All rights reserved
Key
a
All variable fields will be reset at power-up.
b
All errors result in a transition to Initial state.
Figure 1 — Crypto suite Tag state diagram
The Interrogator is considered authenticated only in the IA-OK state.
8 Initialization and resetting
After power-up and after a reset, the crypto suite shall transition into the Initial state.
After the Tag encounters an error condition, it shall transition into the Initial state.
After the Tag encounters an error condition, it may send an error reply to the Interrogator, but in that
case the Tag shall select one Error Condition from the list that is specified in Annex B.
A transition to Initial state shall also cause a reset of all variables used by the crypto suite.
Implementations of this crypto suite shall assure that all memory used for intermediate results is
cleared after each operation (message-response pair) and after reset.
9 Authentication
9.1 General
This document supports Tag Authentication, Interrogator Authentication and Mutual Authentication.
All functions are implemented using a message-response exchange. This clause describes the details of
the messages and responses that are exchanged between the Interrogator and Tag.
© ISO/IEC 2017 – All rights reserved 9
All message and response exchanges are listed in Table 2.
Table 2 — Message and response functions
Command Function
TAM1 message Send Interrogator challenge and request Tag authentication response
TAM1 response Return Tag authentication response
TAM2 message Send Interrogator challenge and request Tag authentication response with custom data
TAM2 response Return Tag authentication response and custom data
IAM1 message Send Interrogator authentication request
IAM1 response Return Tag challenge
IAM2 message Send Interrogator authentication response
IAM2 response Return Interrogator Authentication result
IAM3 message Send Interrogator authentication response plus custom data
IAM3 response Return Interrogator Authentication result
MAM1 message Send Interrogator challenge and request Tag authentication response and challenge
MAM1 response Return Tag authentication response and challenge
MAM2 message Send Interrogator authentication response
MAM2 response Return Interrogator Authentication result
9.2 Adding custom data to authentication process
This document supports including part of the Tag’s memory as custom data to the authentication
process. The custom data may be protected (protection of integrity and authenticity) and/or encrypted
(confidentiality protection) with the authentication. The authentication message shall include the
reference KeyID to select an encryption key in Table 27 (see Clause 11). If protection of integrity and
authenticity of the data is requested, the selected reference KeyID shall also contain a MAC key.
A Tag that supports including custom data in the authentication process shall define at least one and at
most 16 memory profiles. All supported addresses or pointers for the memory profiles are specified in
Annex E.
The memory profiles may also be linked to a key in Table 27 that shall be used for the encryption
process to protect the data.
Custom data is specified as a number (1 to 16) of consecutive 16-bit or 64-bit blocks in the Tag's memory.
The custom data block shall be defined by the parameters BlockSize, Profile, Offset and BlockCount.
The mode of operation that shall be used for the encryption and/or protection of the custom data is
specified by ProtMode.
BlockSize shall select the size of the custom data block; "0 " specifies custom data in 64-bit blocks, "1 "
b b
specifies custom data as 16-bit blocks.
Profile shall select one of the memory profiles that are supported by the Tag. The memory profiles are
specified in Annex E.
Offset specifies a 12-bit offset (in multiples of 16-bit or 64-bit blocks) that needs to be added to the
address that is specified by Profile. Minimum value "000000000000 " corresponds to a zero offset.
b
Maximum value is 111111111111 (decimal 4095). For 16-bit blocks, the maximum bit pointer offset is
b
16 × 4095 = 65520. For 64-bit blocks, the maximum bit pointer offset is 64 × 4095 = 262080.
BlockCount specifies the 4-bit number of custom data blocks that need to be selected from the offset
position onwards. Minimum value is "0000 ", corresponding to one single block. Maximum binary
b
value is "1111 ", or decimal 15, corresponds to a maximum number of 16 blocks of custom data that
b
shall be included. If the number of included bits of the custom data including header is not a multiple
of 128 then padding with zeroes shall be applied to the least significant bits of the last block that has
10 © ISO/IEC 2017 – All rights reserved
a non-zero block size of less than 128 bits. The Interrogator shall maintain the value of BlockCount for
use as part of the MAC verification process. The Tag manufacturer shall specify the number of custom
data blocks that can be included.
NOTE When combined with the values for BlockSize and BlockCount, as well as requiring that all component
blocks are complete, the padding scheme proposed in this document is unambiguous.
HEADER is composed of the concatenation of the BlockSize, Profile, Offset, BlockCount and extra zeroes
padding.
If BlockSize = “0 ”, HEADER is a 64-bit value defined as:
b
HEADER = BlockSize[0:0] || Profile[3:0] || Offset[11:0] || BlockCount[3:0] || 00000000000 || 00000000
b h
If BlockSize = “1 ”, Header is a 32-bit value defined as:
b
HEADER = BlockSize[0:0] || Profile[3:0] || Offset[11:0] || BlockCount[3:0] || 00000000000
b
H represents the number of bits of HEADER. If BlockSize = “0 ”, then H = 64, else H = 32.
b
D represents the number of 128-bit custom data blocks including the header, when present, and is
defined by BlockCount and BlockSize. The minimum value of D shall be 1. The maximum value of D
supported by the Tag is specified by the Tag manufacturer.
If n represents the decimal value of BlockCount (0 to 15), then D is as follows:
— For TAM2
— If BlockSize = 0 and TAM2_Rev=0, then D: = (n+1) DIV 2 + (n+1) MOD2
b
— If BlockSize = 1 and TAM2_Rev=0, then D: = (n+8) DIV 8
b
— If BlockSize = 0 and TAM2_Rev=1, then D: = (n+2) DIV 2 + (n+2) MOD2
b
— If BlockSize = 1 and TAM2_Rev=1, then D: = (n+10) DIV 8
b
— For IAM3
— If BlockSize = 0 and TAM2_Rev=1, then D: = (n+2) DIV 2 + (n+2) MOD2
b
— If BlockSize = 1 and TAM2_Rev=1, then D: = (n+10) DIV 8
b
CUSTOMDATA(D*128) contains the custom data as a bit string with a length of D*128-H bits (including
padding) for IAM3 and TAM2 command and TAM2_Rev=1.
CUSTOMDATA(D*128) contains the custom data as a bit string with a length of D*128 bits (including
padding) for TAM2 command and TAM2_Rev=0.
NOTE Access rights to custom data can be restricted by the specification of the interface. Annex E describes
protocol-specific implementations for various modes of the ISO/IEC 18000 series.
ProtMode specifies the mode of operation that shall be used for the encryption and/or protection of
the custom data. Table 3 specifies the mode of operation for encryption algorithms and/or message
authentication algorithms for the (optional) protection (authentication and/or encryption) of
custom data.
© ISO/IEC 2017 – All rights reserved 11
Table 3 — Supported modes of operation for ProtMode
a
ProtMode[3:0] Description
Plaintext
b
(no integrity and/or confidentiality protection requested)
0001 CBC (encryption only)
b
0010 CMAC (message authentication only)
b
0011 CBC + CMAC
b
0100 Reserved for future use
b
…. ….
0111 Reserved for future use
b
1000 Manufacturer defined
b
…. ….
1111 Manufacturer defined
b
a
When a ProtMode is selected that specifies data encryption (ProtMode "0001 "
b
and "0011 "), the Tag may assert a privilege that makes all memory accessible for the
b
duration of the execution of the command. See Annex E for details of the air interface
specific implementations.
NOTE This document specifies the use of an encryption-only implementation on the Tag.
9.3 Message and response formatting
The functionality of this document is implemented by means of a Command(Message)/(Response)
exchange (see Figure 2) as described in the air interface specification.
Figure 2 — Command(Message)/Response exchange
The "air interface part" of the Tag passes the Message on to the "crypto suite part" of the Tag and returns
the Response from the "crypto suite part" as a Reply to the Interrogator. The crypto suite shall parse
the Messages and process the data based on the value of AuthMethod, which is the first parameter (first
two bits) of all Messages.
The following subclauses describe the formatting of Message and Response for Tag Authentication,
Interrogator Authentication and Mutual Authentication. The Messages for Tag Authentication,
Interrogator Authentication and Mutual Authentication shall be distinguished by AuthMethod.
If AuthMethod = "00 ", the Tag shall parse the Message for Tag Authentication as described in 9.4.
b
If AuthMethod = "01 ", the Tag shall parse Message for Interrogator Authentication as described in 9.5.
b
If AuthMethod = "10 ", the Tag shall parse Message for Mutual Authentication as described in 9.6.
b
If AuthMethod = "11 ", then the Tag shall return a "Not Supported" error condition.
b
12 © ISO/IEC 2017 – All rights reserved
9.4 Tag authentication (Method “00” = TAM)
9.4.1 General
Tag Authentication allows an Interrogator to authenticate a Tag by verifying the Tag’s secret key
with the TAM1 response. Optionally, the Tag may return part of its memory as custom data, which
may be protected (protection of integrity, authenticity of origin and timeliness) and/or encrypted
(confidentiality protection), with the TAM2 response.
Tag authentication only is implemented in TAM1 and Tag authentication with the addition of custom
data is implemented as TAM2.
The following subclauses describe the formatting of Message and Response for Tag Authentication.
The TAM Messages are distinguished by the value of CustomData, which is the second parameter (third
bit) of both TAM Messages.
If CustomData = "0 ", the Tag shall parse the TAM1 Message for Tag Authentication without custom
b
data as described in 9.4.2.
If CustomData = "1 ", the Tag shall parse the TAM2 Message for Tag Authentication with custom data as
b
described in 9.4.5.
9.4.2 TAM1 Message
For Tag authentication, the Interrogator shall generate an 80-bit random TAM1 Interrogator challenge
and include that in the TAM1 message. The TAM1 message shall also include the reference KeyID to
select an encryption key in Table 27 (see Clause 11).
The TAM1 Message format is specified in Table 4 and has the following parameters:
— AuthMethod: value "00 " specifies the use for TAM;
b
— CustomData: flag with value "0 " to indicate that no custom data is requested (TAM1);
b
— TAM1_RFU: value "00000 " makes the total length of the TAM1 Message a multiple of 8-bits and
b
might be used for future extensions of this document;
— KeyID: 8-bit value that specifies the key that shall be used for TAM1;
— IChallenge_TAM1: 80-bit random challenge that the Interrogator has generated for use in TAM1.
Table 4 — TAM1 Message format
AuthMethod CustomData TAM1_RFU KeyID IChallenge_TAM1
# of bits 2 1 5 8 80
random Interrogator
Description 00 0 00000 [7:0]
b b b
challenge
The Tag shall accept this message in any state. If the value of the parameters of the message are invalid,
then the Tag shall transition to the Initial state, thereby aborting any cryptographic protocol that has
not yet been completed.
If the length of the TAM1 message is <> 96 bits, then the Tag shall return an "Other Error" error
condition.
If TAM1_RFU[4:0] is <> "00000 ", then the Tag shall return a "Not Supported" error condition.
b
If the Tag does not support key[KeyID].ENC_key, then the Tag shall return a "Not Supported" error
condition.
© ISO/IEC 2017 – All rights reserved 13
ISO/IEC 29167-10:201
...
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...