ISO/IEC 29167-10:2015
(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:2015 defines 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 part of ISO/IEC 29167 specifies a crypto suite for AES 128 for air interface for RFID systems. The crypto suite is defined in alignment with existing air interfaces. This part of ISO/IEC 29167 defines various authentication methods and methods of use for the cipher. A Tag and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.
Technologies de l'information — Techniques automatiques d'identification et de capture de données — Partie 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
First edition
2015-05-15
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 29167-10:2015(E)
©
ISO/IEC 2015
---------------------- Page: 1 ----------------------
ISO/IEC 29167-10:2015(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2015, 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 2015 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 29167-10:2015(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Conformance . 1
2.1 Air interface protocol specific information . 1
2.2 Interrogator conformance and obligations . 1
2.3 Tag conformance and obligations . 1
3 Normative references . 2
4 Terms and definitions . 2
5 Symbols and abbreviated terms . 4
5.1 Symbols . 4
5.2 Abbreviated terms . 4
6 Introduction of the AES-128 crypto suite . 5
7 Parameter definitions . 5
8 Crypto suite state diagram . 6
9 Initialization and resetting . 6
10 Authentication . 6
10.1 Introduction . 6
10.2 Message and Response formatting . 7
10.3 Tag authentication (Method “00” = TAM) . 7
10.3.1 TAM1 and TAM2 . 7
10.3.2 TAM1 Message . 7
10.3.3 TAM1 Response . 8
10.3.4 Final Interrogator processing TAM1 . 8
10.3.5 TAM2 Message . 8
10.3.6 TAM2 Response .11
10.3.7 Final Interrogator processing TAM2 .13
11 Communication .13
12 Key Table .13
Annex A (normative) Crypto Suite State transition tables .15
Annex B (normative) Error conditions and error handling .16
Annex C (normative) Cipher description .17
Annex D (informative) Test vectors .18
Annex E (normative) Protocol specific information.19
Annex F (informative) Examples .23
Bibliography .26
© ISO/IEC 2015 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 29167-10:2015(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. 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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT), see the following URL: Foreword — Supplementary information.
The committee responsible for this document is ISO/IEC JTC 1, Information technology, SC 31, Automatic
identification and data capture techniques.
ISO/IEC 29167 consists of the following parts, under the general title Information technology —
Automatic identification and data capture techniques:
— Part 1: Security services for RFID air interfaces
— Part 10: Crypto suite AES-128 security services for air interface communications
— Part 11: Crypto suite PRESENT-80 security services for air interface communications
— Part 12: Crypto suite ECC-DH security services for air interface communication
— Part 13: Crypto suite Grain-128A security services for air interface communications
— Part 14: Crypto suite AES OFB security services for air interface communications
— Part 16: Crypto suite ECDSA-ECDH security services for air interface communications
— Part 17: Crypto suite cryptoGPS security services for air interface communications
— Part 19: Crypto suite RAMON security services for air interface communications
The following parts are under preparation:
— Part 15: Crypto suite XOR security services for air interface communications
iv © ISO/IEC 2015 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 29167-10:2015(E)
Introduction
This part of ISO/IEC 29167 specifies the security services of an AES-128 crypto suite for Tag authentication.
AES has a fixed block size of 128 bits and a key size of 128 bits, 192 bits, or 256 bits. The version specified
in this crypto suite uses AES with a fixed key size of 128 bits and is referred to as AES-128.
This part of ISO/IEC 29167 defines procedures for Tag Authentication using AES-128 and provides the
following functionality:
— Tag Authentication;
— Tag Authentication allows authenticated reading of a part of the Tag’s memory;
— Authenticated reading might be in plain text, MAC protected, Encrypted, or Encrypted and MAC
protected;
— Crypto suite uses encryption for enciphering of plain text, as well as deciphering of encrypted text.
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 the ISO and IEC that they are willing to negotiate licences
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 can be obtained from:
Impinj, Inc.
th
701 N 34 Street, Suite 300
Seattle, WA 98103 USA
The latest information on IP that might be applicable to this part of ISO/IEC 29167 can be found at www.
iso.org/patents.
© ISO/IEC 2015 – All rights reserved v
---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO/IEC 29167-10:2015(E)
Information technology — Automatic identification and
data capture techniques —
Part 10:
Crypto suite AES-128 security services for air interface
communications
1 Scope
This part of ISO/IEC 29167 defines 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 part of ISO/IEC 29167 specifies a crypto suite for AES 128 for air interface for RFID systems. The
crypto suite is defined in alignment with existing air interfaces.
This part of ISO/IEC 29167 defines various authentication methods and methods of use for the cipher. A Tag
and an Interrogator can support one, a subset, or all of the specified options, clearly stating what is supported.
2 Conformance
2.1 Air interface protocol specific information
To claim conformance with this part of ISO/IEC 29167, an Interrogator or Tag shall comply with all
relevant clauses of this part of ISO/IEC 29167, except those marked as “optional”.
2.2 Interrogator conformance and obligations
To conform to this part of ISO/IEC 29167, an Interrogator shall
— implement the mandatory commands defined in this part of ISO/IEC 29167 and conform to the
relevant part of ISO/IEC 18000.
To conform to this part of ISO/IEC 29167, an Interrogator can
— implement any subset of the optional commands defined in this part of ISO/IEC 29167.
To conform to this part of ISO/IEC 29167, the Interrogator shall not
— implement any command that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom command to meet the requirements of this
part of ISO/IEC 29167.
2.3 Tag conformance and obligations
To conform to this part of ISO/IEC 29167, a Tag shall
— implement the mandatory commands defined in this part of ISO/IEC 29167 for the supported types
and conform to the relevant part of ISO/IEC 18000.
© ISO/IEC 2015 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC 29167-10:2015(E)
To conform to this part of ISO/IEC 29167, a Tag can
— implement any subset of the optional commands defined in this part of ISO/IEC 29167.
To conform to this part of ISO/IEC 29167, a Tag shall not
— implement any command that conflicts with this part of ISO/IEC 29167, or
— require the use of an optional, proprietary, or custom command to meet the requirements of this
part of ISO/IEC 29167.
3 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies
ISO/IEC 18000-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 (all parts), Information technology — Automatic identification and data capture (AIDC)
techniques — Harmonized vocabulary
ISO/IEC 29167-1, Information technology — Automatic identification and data capture techniques —
Part 1: Security services for RFID air interfaces
4 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 (all parts) and the
following apply.
4.1
AES-CBC-ENC(IV, key, data)
AES data encryption (forward operation) in CBC mode of input data “data”, using initialization vector IV
and 128 bit cryptographic key “key”
4.2
AES-ECB-ENC(key, data)
AES data encryption (forward operation) in ECB mode of input data “data”, using 128 bit cryptographic
key “key”
4.3
AES-CMAC-96(key, data)
CMAC generation using AES in forward operation with 128 bit cryptographic key “key” of input data
“data”, truncating the result by using only the 96 most significant bits from the 128-bit CMAC code
4.4
bit string
ordered sequence of 0’s and 1’s
4.5
block cipher
family of functions and their inverse functions that is parameterized by cryptographic keys; the
functions map bit strings of a fixed length to bit strings of the same length
4.6
block size
number of bits in an input (or output) block of the block cipher
2 © ISO/IEC 2015 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 29167-10:2015(E)
4.7
cryptographic key
string of bits used by a cryptographic algorithm to transform plain text into cipher text or vice versa or
to produce a message authentication code
4.8
CMAC
cipher-based MAC algorithm based on a symmetric key block cipher
Note 1 to entry: See MAC method 5 in Reference [1] for a normative reference.
4.9
Command (Message)
data that Interrogator sends to Tag with “Message” as parameter
4.10
D
number of additional 128-bit blocks with custom data that may be added to the Tag authentication response
4.11
Data Block (Block)
sequence of bits whose length is the block size of the block cipher
4.12
initialization vector
data block that some modes of operation require as an additional initial input
4.13
input block
data that is an input to either the forward cipher function or the inverse cipher function of the block
cipher algorithm
4.14
Key
string of bits used by a cryptographic algorithm to transform plain text into cipher text or vice versa or
to produce a message authentication code
4.15
KeyID
numerical designator for a single key
4.16
Key[KeyID].ENC_key
key that shall be used for encryption
4.17
Key[KeyID].MAC_key
key that may be used for cryptographic integrity protection
4.18
MAC_key
Variable that shall contain the key that will be used for cryptographic integrity protection
4.19
Memory Profile
start pointer within the Tag’s memory for addressing custom data block
4.20
Message
part of the Command that is defined by the crypto suite
© ISO/IEC 2015 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC 29167-10:2015(E)
4.21
Mode of Operation (Mode)
algorithm for the cryptographic transformation of data that features a symmetric key block cipher algorithm
4.22
output block
data that is an output of either the forward cipher function or the inverse cipher function of the block
cipher algorithm
4.23
Plaintext
usable data that is formatted as input to a mode
4.24
Reply (Response)
data that Tag returns to the Interrogator with “Response” as parameter
4.25
Response
part of the Reply (stored or sent) that is defined by the crypto suite
4.26
word
bit string comprised of 16 bits
5 Symbols and abbreviated terms
5.1 Symbols
xxxxb binary notation of term “xxxx”, where “x” represents a binary digit.
xxxxh hexadecimal notation of term “xxxx”, where “x” represents a hexadecimal digit.
In this crypto suite the bytes in the hexadecimal numbers are presented with the most signif-
icant 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.
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] repre-
sents the least significant bit.
For example Field[2:0] represents the selection of the three least significant bits of Field.
5.2 Abbreviated terms
AES Advanced Encryption Standard
CBC Cipher-Block Chaining
CMAC Cipher-based MAC
ECB Electronic Code Book
FIPS Federal Information Processing Standard
4 © ISO/IEC 2015 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 29167-10:2015(E)
IV Initialization Vector
LSB Least Significant Byte
MAC Message Authentication Code
MPI Memory Profile Indicator
MSB Most Significant Byte
NIST (United States) National Institute of Standards and Technology
RFU Reserved for Future Use
TID Tag-IDentification or Tag IDentifier, depending on context
UII Unique Identification ID
6 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
[2]
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 five-year standardization process that involved a number of competing
encryption algorithms and published as FIPS PUB 197 in November 2001.
AES was originally published, along with design criteria and test vectors, in reference document [5] in
the Bibliography.
NOTE AES normally uses encryption for the enciphering of plain text and decryption for the deciphering of
encrypted text. This crypto suite uses encryption for enciphering of plain text as well as deciphering of encrypted
text. This allows the use of an encryption-only implementation on the Tag.
7 Parameter definitions
Table 1 describes all the parameters that are used in this part of ISO/IEC 29167.
Table 1 — Definition of AES-128 crypto suite parameters
Parameter Description
16-bit predefined constant for TAM1 with the value “96C5h”
C_TAM1[15:0]
(for Tag to Interrogator response)
16-bit predefined constant for TAM2 with the value “96C5h”
C_TAM2[15:0]
(for Tag to Interrogator response)
Ciphertext[n] Temporary storage for encryption result
Part of the Tag’s memory that may be returned with the Tag authentication
CUSTOMDATA(D*128)
response
IChallenge_TAM1[79:0] 80-bit challenge that the Interrogator generates for use in TAM1
IChallenge_TAM2[79:0] 80-bit challenge that the Interrogator generates for use in TAM2
Keyset identified by KeyID, consisting of ENC_key for encryption and (optional)
Key[KeyID]
MAC_key for integrity protection
Variable that shall contain the key that will be used for cryptographic integrity
MAC_key[127:0]
protection
© ISO/IEC 2015 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC 29167-10:2015(E)
Table 1 (continued)
Parameter Description
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
8 Crypto suite state diagram
After power-up or reset the crypto suite transitions to its Initial state.
A transition to Initial state shall also cause a reset of all variables used by the crypto suite.
1
Power-up
CMD: Authenticate[TAM1] CMD: Authenticate[TAM2]
Reply: TAM1 Response Reply: TAM2 Response
Initial
Note 1. Allvariablefieldswillberesetatpower-up
Figure 1 — Crypto suite Tag state diagram
9 Initialization and resetting
After power-up and after a reset the crypto suite transitions into the Initial state.
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.
10 Authentication
10.1 Introduction
This part of ISO/IEC 29167 supports only Tag Authentication. All functions are implemented using a
message-response exchange. This section describes the details of the messages and responses that are
exchanged between the Interrogator and Tag.
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 plus custom data
TAM2 response Return Tag authentication response and custom data
6 © ISO/IEC 2015 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 29167-10:2015(E)
10.2 Message and Response formatting
Message and Response are part of the security commands that are described in the air interface
specification. 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” 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
of all Messages.
The following sections of this document describe the formatting of Message and Response for Tag
Authentication. AuthMethod shall be “00 ” for Tag Authentication.
b
If AuthMethod = “00 ” the Tag shall parse Message as described in 10.3
b
If AuthMethod = “01 ”, “10 ” or “11 ” then the Tag shall return a “Not Supported” error condition and
b b b
shall transition to the Initial state.
10.3 Tag authentication (Method “00” = TAM)
10.3.1 TAM1 and TAM2
Tag Authentication allows an Interrogator to authenticate a Tag by verifying the Tag’s secret key (TAM1).
Optionally the Tag may return part of its memory as custom data, that may be protected (protection of
integrity, authenticity of origin, and timeliness) and/or encrypted (confidentiality protection), with the
Tag authentication TAM2 response.
The functionality shall be implemented by means of a challenge-response exchange. Tag authentication
only shall be implemented in TAM1 and Tag authentication with the addition of custom data shall be
implemented as TAM2 (see Figure 2).
Authenticate(TAM1/TAM2 Message)
(TAM1/TAM2 Response)
Figure 2 — Tag authentication
The following sections of this document describe the formatting of Message and Response for Tag
Authentication.
The crypto suite shall parse the TAM Messages and process the data based on the value of CustomData,
which is the second parameter of both TAM Messages. The Messages for Tag Authentication without and
with custom data shall be distinguished by CustomData. CustomData shall be “0 ” for Tag Authentication
b
without custom data and “1 ” for Tag Authentication with custom data.
b
If CustomData = “0 ” the Tag shall parse the TAM1 Message as described in 10.3.2
b
If CustomData = “1 ” the Tag shall parse the TAM2 Message as described in 10.3.5
b
10.3.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 the Key Management Table (see Clause 12).
© ISO/IEC 2015 – All rights reserved 7
Interrogator
Tag
---------------------- Page: 12 ----------------------
ISO/IEC 29167-10:2015(E)
The TAM1 Message format has the following fields:
— AuthMethod: value “00 ” defines the use for TAM
b
— CustomData: flag to indicate that custom data is requested, “0 ” defines no custom data
b
requested (TAM1)
— TAM1_RFU: makes the total length of the TAM1 Message a multiple of 8-bits and will be used for
future extensions of this part of ISO/IEC 29167
— KeyID: defines the key that shall be used for TAM1
— IChallenge_TAM1: random challenge that the Interrogator has generated for use in TAM1
Table 3 — TAM1 Message format
AuthMethod CustomData TAM1_RFU KeyID IChallenge_TAM1
# of bits 2 1 5 8 80
description 00 0 00000 [7:0] random Interrogator challenge
b b b
The Tag shall accept this message in any state. If the parameters of the message are valid, 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 <> 96 bits then the Tag shall return an “Other Error” error condition
and shall transition to the Initial state.
If TAM1_RFU <> “00000 ” then the Tag shall return a “Not Supported” error condition and shall transition
b
to the Initial state.
If the Tag does not support key[KeyID].ENC_key then it shall return a “Not Supported” error condition
and shall transition to the Initial state.
10.3.3 TAM1 Response
If all verifications are s
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.