ISO/IEC 29167-19:2016

Information technology - Automatic identification and data capture techniques - Part 19: Crypto suite RAMON security services for air interface communications

ISO/IEC 29167-19:2016 defines the Rabin-Montgomery (RAMON) crypto suite 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 may be referred by ISO committees for air interface standards and application standards. ISO/IEC 29167-19:2016 specifies a crypto suite for Rabin-Montgomery (RAMON) for air interface for RFID systems. The crypto suite is defined in alignment with existing air interfaces. ISO/IEC 29167-19:2016 defines various authentication methods and methods of use for the cipher. A Tag and an Interrogator may support one, a subset, or all of the specified options, clearly stating what is supported.

Technologie informative — Identification automatique et technique capturé data — Partie 19: Air interface pour les services de sécurité suite de crypto RAMON

General Information

• Status: Withdrawn
• Publication Date: 17-May-2016
• Withdrawal Date: 17-May-2016
• ICS: 35.040 - Information coding
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 4 - Radio communications
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 26-Jun-2019
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 29167-19:2019 - Information technology - Automatic identification and data capture techniques - Part 19: Crypto suite RAMON security services for air interface communications
• Effective Date: 04-Feb-2017

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29167-19
First edition
2016-05-15
Information technology — Automatic
identification and data capture
techniques —
Part 19:
Crypto suite RAMON security services
for air interface communications
Technologie informative — Identification automatique et technique
capturé data —
Partie 19: Air interface pour les services de sécurité suite de crypto
RAMON
Reference number
©
ISO/IEC 2016
© ISO/IEC 2016, 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2016 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Conformance . 1
2.1 Claiming conformance . 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 . 3
5.1 Symbols . 3
5.2 Abbreviated terms . 3
5.3 Notation . 4
6 Crypto suite introduction . 5
6.1 Overview . 5
6.2 Authentication protocols . 6
6.2.1 Tag Identification . 6
6.2.2 Symmetric mutual authentication . 7
6.3 Send Sequence Counter . 8
6.4 Session key derivation . 9
6.4.1 KDF in counter mode . 9
6.4.2 Key Derivation Scheme .10
6.5 IID, SID, Used Keys and Their Personalisation.11
6.6 Key table .13
7 Parameter definitions .14
8 State diagrams.14
8.1 General .14
8.2 State diagram and transitions for Tag identification .15
8.2.1 Partial Result Mode.15
8.2.2 Complete Result Mode .16
8.3 State diagram and transitions for mutual authentication .17
8.3.1 Partial Result Mode.17
8.3.2 Complete Result Mode .18
8.3.3 Combination of complete and partial result mode . .19
9 Initialization and resetting .20
10 Identification and authentication.20
10.1 Tag identification .20
10.1.1 Partial Result Mode.20
10.1.2 Complete Result Mode .20
10.2 Mutual authentication .21
10.2.1 Partial Result Mode.21
10.2.2 Complete Result Mode .22
10.3 The Authenticate command.23
10.3.1 Message formats for Tag identification .23
10.3.2 Message formats for Mutual Authentication .24
10.4 Authentication response .25
10.4.1 Response formats for Tag identification .25
10.4.2 Response formats for mutual authentication .26
10.4.3 Authentication error response .28
10.5 Determination of Result Modes .29
© ISO/IEC 2016 – All rights reserved iii

11 Secure communication .30
11.1 Secure communication command .30
11.2 Secure Communication response .31
11.2.1 Secure communication error response .31
11.3 Encoding of Read and Write commands for secure communication .31
11.4 Application of secure messaging primitives .32
11.4.1 Secure Communication command messages .32
11.4.2 Secure Communication response messages .34
11.4.3 Explanation of cipher block chaining mode .37
Annex A (normative) State transition tables .39
Annex B (normative) Error codes and error handling.42
Annex C (normative) Cipher description .43
Annex D (informative) Test Vectors .58
Annex E (normative) Protocol specific .61
Annex F (informative) Non-traceable and integrity-protected Tag identification .68
Annex G (informative) Memory Organization for Secure UHF Tags (Proposal) .71
Bibliography .75
iv © ISO/IEC 2016 – 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 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, Subcommittee
SC 31, Automatic identification and data capture.
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 communications
— 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
— Part 20: Crypto suite Algebraic Eraser security services for air interface communications
The following part is under preparation:
— Part 15: Crypto suite XOR security services for air interface communications
© ISO/IEC 2016 – All rights reserved v

Introduction
This part of ISO/IEC 29167 specifies the security services of a Rabin-Montgomery (RAMON) crypto
suite. It is important to know that all security services are optional. The crypto suite provides Tag
authentication security service.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this International
Standard may 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 ensured 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 may be obtained from:
NXP B.V.
411 East Plumeria, San Jose,
CA 95134-1924 USA
The latest information on IP that may be applicable to this part of ISO/IEC 29167 can be found at www.
iso.org/patents.
vi © ISO/IEC 2016 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 29167-19:2016(E)
Information technology — Automatic identification and
data capture techniques —
Part 19:
Crypto suite RAMON security services for air interface
communications
1 Scope
This part of ISO/IEC 29167 defines the Rabin-Montgomery (RAMON) crypto suite 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 may be referred by ISO committees for air
interface standards and application standards.
This part of ISO/IEC 29167 specifies a crypto suite for Rabin-Montgomery (RAMON) 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 may support one, a subset, or all of the specified options, clearly stating what
is supported.
2 Conformance
2.1 Claiming conformance
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 may 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.
To conform to this part of ISO/IEC 29167, a Tag may implement any subset of the optional commands
defined in this part of ISO/IEC 29167.
© ISO/IEC 2016 – All rights reserved 1

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-3, Information technology — Radio frequency identification for item management —
Part 3: Parameters for air interface communications at 13,56 MHz
ISO/IEC 18000-4, Information technology — Radio frequency identification for item management — Part
4: Parameters for air interface communications at 2,45 GHz
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
authentication
service that is used to establish the origin of information
4.2
confidentiality
property whereby information is not disclosed to unauthorized parties
4.3
integrity
property whereby data has not been altered in an unauthorized manner since it was created,
transmitted or stored
4.4
non-traceability
protection ensuring that an unauthorized interrogator is not able to track the Tag location by using the
information sent in the Tag response
4.5
secure communication
communication between the tag and the interrogator by use of the Authenticate command, assuring
authenticity, integrity and confidentiality of exchanged messages
2 © ISO/IEC 2016 – All rights reserved

5 Symbols and abbreviated terms
5.1 Symbols
xx binary notation
xxh hexadecimal notation
|| concatenation of syntax elements in the order written
5.2 Abbreviated terms
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CH Challenge
CH , CH Interrogator random challenge, 16 bytes
I1 I2
CH Tag random challenge, 16 bytes
T
CG Cryptogram
CMAC Ciphered Message Authentication Code
CRC Cyclic Redundancy Check
CRC–16 16-bit CRC
CS Crypto Suite
CSI Crypto Suite Identifier
DEC(key, data) AES decryption of enciphered “data” with secret “key”
ENC(key, data) AES encryption of plain “data” with secret “key”
EPC™ Electronic Product Code
IID Interrogator Identifier, 8 bytes
IV Initialization Vector for CBC-encryption, 16 bytes
KDF Key Derivation Function
K Public key for encryption stored on Tag
E
K Private decryption key stored on Interrogator
D
K Public signature verification key stored on Interrogator
V
K Private signature generation key stored in the tag issuer facility
S
K Shared secret message encryption key
ENC
K Shared secret message authentication key
MAC
KESel Key select (determines which KE will be used)
© ISO/IEC 2016 – All rights reserved 3

KSel Key select (determines which pair of KENC, KMAC will be used)
MAC(key, data) Calculation of a MAC of (enciphered) “data”’ with secret “key”; internal state of
the tag’s state machine
MAMx,y Mutual Authentication Method x.y
MCV MAC Chaining Value
MIX(CH, RN, SID) RAMON mix function
PRF Pseudorandom Function
R Tag response
RAMON Rabin-Montgomery
RFU Reserved for Future Use
RM_ENC(key, data) RAMON encryption of plain “data” with public “key”
RM_DEC(key, data) RAMON decryption of enciphered “data” with private “key”
RN Random Number
RNT Tag Random Number, 16 bytes
S Message encryption session key
ENC
S Message authentication session key
MAC
SID Secret IDentifier, 8 bytes, identifying the tag
SSC Send Sequence Counter for replay protection, 16 bytes
TAMx,y Tag Authentication Method x.y; internal state of the tag’s state machine
TLV Tag Length Value
UHF Ultra High Frequency
UII Unique Item Identifier
WORM Write once, read many
5.3 Notation
This crypto suite uses the notation of ISO/IEC 18000-63.
The following notation for key derivation corresponds to Reference [7] and Clause 5.
PRF(s,x) A pseudo-random function with seed s and input data x.
K Key derivation key used as input to the KDF to derive keying material. K is used as the block
I I
cipher key, and the other input data are used as the message defined in
Reference [5].
K Keying material output from a key derivation function, a binary string of the required length,
O
which is derived using a key derivation key.
Label A string that identifies the purpose for the derived keying material, which is encoded as a bina-
ry string.
4 © ISO/IEC 2016 – All rights reserved

Context A binary string containing the information related to the derived keying material. It may include
identities of parties who are deriving and/or using the derived keying material and, optionally, a
nonce known by the parties who derive the keys.
L An integer specifying the length (in bits) of the derived keying material K . L is represented as a
O
binary string when it is an input to a key derivation function. The length of the binary string is
specified by the encoding method for the input data.
h An integer that indicates the length (in bits) of the output of the PRF.
i A counter that is input to each iteration of the PRF.
r An integer, smaller or equal to 32, that indicates the length of the binary representation of the
counter i. in bits.
00h An all zero octet. An optional data field used to indicate a separation of different variable length
data fields.
The smallest integer that is larger than or equal to X. The ceiling of X.
 
X
 
 
{X} Indicates that data X is an optional input to the key derivation function.
[T] An integer T represented as a binary string (denoted by the “2”) with a length specified by the
function, an algorithm, or a protocol which uses T as an input.
∅ The empty binary string.
6 Crypto suite introduction
6.1 Overview
The RAMON Crypto Suite permits two levels of implementation. The first level provides secure
identification and tag authentication, while the second level extends the functionality by mutual
authentication to securely communicate between Interrogator and Tag, e.g. for secure reading and
writing non-volatile memory.
Basic RAMON Tags may provide only the first level of implementation, while more sophisticated Tags
also provide the second level. See Figure 1 for the different implementation levels for the RAMON
crypto suite.
© ISO/IEC 2016 – All rights reserved 5

Figure 1 — Overview of the different implementation levels for the RAMON crypto suite
6.2 Authentication protocols
6.2.1 Tag Identification
The Rabin-Montgomery crypto suite provides non-traceable and confidential Tag identification.
Confidentiality and privacy for the Tag’s identifier are provided without requiring the Tag to store a
private key.
[3]
The crypto suite is based on the asymmetric cryptosystem developed by Michael O. Rabin . The
[2]
original algorithm is augmented by a method detected by Peter Montgomery , which avoids the
division of long numbers in modular arithmetic. Combining Rabin encryption with the concept of
Montgomery multiplication advantage is taken of the fact that no “costly” division is required.
The Tag performs only public key operations. The Interrogator performs the “expensive” private
key operation. The steps necessary to carry out RAMON are outlined in Table 1. RAMON encryption
performed by the Tag and decryption performed by the Interrogator are specified in C.3 and C.4. The
cryptographic keys are specified in 6.6.
This specification also includes in C.1 the structure of the clear text record used for authentication of
the Tag, comprising the Tag identity record and random data originating in part from the Tag and from
the Interrogator for the other part.
6 © ISO/IEC 2016 – All rights reserved

Table 1 — Protocol steps for Tag identification
Interrogator Tag
(K , K ) (SID, K )
D V E
Generate random challenge CH and send it to (CH )
I1 I1
the Tag. → Generate random number RN .
T
Generate response cryptogram:
(R) R = RM_ENC(K , MIX(CH , RN , TLV record)).
E I1 T
Decrypt Tag response and apply the inverse of ←
the MIX function to get the plaintext P:
−1
P = MIX (RM_DEC (K , R)).
D
Obtain CH , RN and SID from plaintext P.
I1 T
Compare previously generated Interrogator
challenge with the value received from Tag. If
successful, Tag is identified.
If a signature is provided along with the SID,
use K to validate the signature. If successful,
V
Tag is authenticated.
6.2.2 Symmetric mutual authentication
This crypto suite allows combining the Rabin-Montgomery scheme for Tag identification with
symmetric mutual authentication. The mutual authentication specified by this crypto suite is based
on AES, according to Reference [8]. The CBC mode for encryption is specified in Reference [4]. For MAC
generation CMAC according to Reference [5] is used. For derivation of secure messaging keys, the KDF
in counter mode specified in 5.1 of Reference [7] is used.
The protocol steps for mutual authentication are outlined in Table 2.
Table 2 — Protocol steps for mutual authentication
Interrogator Tag
Phase
(IID, Database, K , K ) (SID, K , K , K )
D V E ENC MAC
(1)  Tag Generate random challenge CH and send it (CH ) Generate random number RN .
I1 I1 T
Identification to the Tag. → Generate response:
(R) R = RM_ENC(K , MIX(CH , RN ,
E I1 T
Decrypt Tag response and apply the ← TLV record, ‘00’ byte)).
inverse of the MIX function to get the plain-
text P:
−1
P = MIX [RM_DEC (K , R)].
D
Obtain CH , RN and SID from plaintext P.
I1 T
Compare previously generated Interrogator
challenge with the value received from Tag.
If successful, Tag is identified.
If a signature is provided along with the SID,
use K to validate the signature. If success-
V
ful, Tag is authenticated.
Set CH = RN .
T T
The Interrogator has successfully identified (and authenticated) the Tag.
In the following phase, CH and SID are used in the mutual authentication.
T
© ISO/IEC 2016 – All rights reserved 7

Table 2 (continued)
Interrogator Tag
Phase
(IID, Database, K , K ) (SID, K , K , K )
D V E ENC MAC
(2)  Mutual Generate CH .
I2
Authentication
Generate cryptogram:
S = CH || IID || CH || SID;
I2 T
C = ENC (K , S);
ENC
M = MAC (K , C);
MAC
CG = C || M. (CG ) Decrypt and verify the cryptogram:
I I
→ MAC (K , C);
MAC
DEC (K , C).
ENC
Verify CH and SID. If equal, gener-
T
ate Session Keys S , S .
ENC MAC
Initialize SSC.
Generate Tag cryptogram:
S = CH || SID || CH || IID;
T I2
C = ENC (K , S);
ENC
M = MAC (K , C);
MAC
CG = C || M
T
Verify the cryptogram: (CG )
T
MAC (K , C); ←
MAC
DEC (K , C).
ENC
Verify CH , CH , SID and IID.
I2 T
If equal, generate session keys: S , S .
ENC MAC
Initialize SSC.
Mutual authentication is now complete and a secure channel is established.
The Interrogator has access to a list of SIDs (Secret identifiers) with the associated K and K for
ENC MAC
each Tag. This is represented by the “Database” on Interrogator’s site.
After having successfully identified the Tag in Phase 1, the Interrogator is able to find secret keys K
ENC
and K that it shares with the Tag. K is used in CBC mode. The IV for encryption is set to all zeroes
MAC ENC
00h.00h. As the size of S is on both sides a multiple of the AES block size, no padding is applied. K is
MAC
used to calculate a 16-byte MAC.
CH and CH are used as challenges in the challenge-response protocol for mutual authentication and
T I2
for generation of the starting value of the SSC. See 6.3 for details.
The session encryption key, S , is used for confidentiality of data in transit. AES encryption, including
ENC
an SSC, is illustrated in Figure 18; decryption is illustrated in Figure 19. The session MAC key, S , is
MAC
used for data and protocol integrity. This crypto suite derives session keys as specified in 6.4.
If the Tag cannot verify the interrogator’s MAC, it reports a Crypto Suite error (see Annex B for
information) and assumes state Init. If the interrogator cannot verify the tag’s MAC, the tag is not
authenticated.
6.3 Send Sequence Counter
The send sequence counter (SSC) ensures that the Initial Values (IVs) are different for every encryption
and the MAC chaining values (MCVs) are different for every MAC generation. To this end, the SSC is
incremented (+1) each time before a Secure Communication command or response is processed.
After mutual authentication, the initial value of the send sequence counter SSC is generated as follows:
SSC = CH ( least significant bytes) ||
T
8 © ISO/IEC 2016 – All rights reserved

CH ( least significant bytes)
I2
After receiving a secure command, the Tag increments SSC, then checks the MAC and then decrypts the
command. In turn, before sending a secure response the Tag increments SSC, encrypts the response
and generates the MAC. Each particular step is under control of the security flags. Thus, if SSC has the
value x at idle time, x+1 is used for processing the next secure command, and x+2 is used for processing
the response. SSC may overflow to 0h during the increment without particular action.
6.4 Session key derivation
The derivation of the session keys, S and S , is based on the KDF in counter mode specified in 5.1
ENC MAC
of Reference [7]. This method uses CMAC as the PRF with AES as underlying block cipher with full 16
bytes output length. The input to the PRF for this cipher suite is as specified in 6.4.2.
6.4.1 KDF in counter mode
The key derivation function iterates a pseudorandom function n times and concatenates the output
 
until L bits of keying material are generated, where n: = Lh/ . In each iteration, the fixed input data is
 
 
the string Label || 00h || Context || [L] . The counter [i] is the iteration variable and is represented as a
2 2
binary string of r bits.
Figure 2 illustrates the process.
The input to the PRF [see step d) of Process] is explained in 6.4.2.
For the derivation of session encryption key S , K is set to K . For the derivation of session MAC
ENC I ENC
key S , K is set to K .
MAC I MAC
Fixed values
— h – The length of the output of the PRF in bits;
— r – The length of the binary representation of the counter i. in bits.
Input: K , Label, Context, and L.
I
Process
 
a) n: = Lh/ .
 
 
r
b) If n > 2 -1, then indicate a crypto suite error and stop.
c) result(0) := ∅.
d) For i = 1 to n, do
— K(i) := PRF (K , [i] || Label || 00h || Context || [L] );
I 2 2
— result(i) := result(i-1) || K(i).
e) Return: K := the leftmost L bits of result (n).
O
Output: K .
O
© ISO/IEC 2016 – All rights reserved 9

NOTE SOURCE: Reference [7].
Figure 2 — KDF in Counter Mode
6.4.2 Key Derivation Scheme
The following derivation data are used to generate session keys according to the KDF in counter mode
as specified in Reference [7].
The one byte counter, i, may take the values 01h or 02h. The value 01h is used when L takes the
value 0080h for derivation of AES-128 keys, which is currently the only case relevant for this part of
ISO/IEC 29167 (see NOTE below).
The iteration variable, i, is concatenated with the fixed input data. The fixed input data is a concatenation
of a Label, a separation indicator 00h, the Context, and [L] as follows:
— Label: consists of 11 zeroes (00h) bytes followed by a one byte derivation constant as defined in
Table 3;
— One byte separation indicator 00h;
— Context: CH || CH ;
I2 T
— [L] : the length in bits of the derived data. For derivation of AES-128 keys which is currently the only
case relevant for this part of ISO/IEC 29167, L takes the value 0080h (see NOTE below).
In each iteration, the fixed input data is the string Label || 0x00 || Context || [L] .
NOTE Currently, this part of ISO/IEC 29167 only supports AES-128 keys. In the future, this part of
ISO/IEC 29167 may be changed to additional key length.
10 © ISO/IEC 2016 – All rights reserved

Table 3 — Encoding of the one byte derivation constant
b8 b7 b6 b5 b4 b3 b2 b1 Description
0 0 0 0 0 0 1 x Key derivation
0 0 0 0 0 0 x 0 Derivation of session encryption key S with K set to K
ENC I ENC
0 0 0 0 0 0 x 1 Derivation of session MAC key S with K set to K
MAC I MAC
NOTE   Any other value is RFU.
A Tag or an Interrogator using a derivation constant marked as RFU is not compliant to this part of
ISO/IEC 29167.
6.5 IID, SID, Used Keys and Their Personalisation
This crypto suite assumes the following keys and information to be available on the Tag:
— the SID, optionally signed with the signature key K before it was stored on the Tag;
S
— the RAMON encryption key K ;
E
and, if mutual authentication is provided:
— the shared secret keys K and K .
ENC MAC
On the Interrogator:
— the RAMON decryption key K ;
D
— optionally, the signature verification key K ;
V
— a list of valid SIDs; each SID might have a signature attached to it;
and, if mutual authentication is provided:
— the shared secret keys K and K .
ENC MAC
The IID is an 8-byte value, which identifies the interrogator to the Tag. The IID can be chosen freely, but
must remain constant during a session.
The SID is a unique 8-byte value, which identifies the Tag to the interrogator. It is set during
personalization and remains constant throughout the lifetime of the Tag.
The SID used by this crypto suite is used by the application to securely identify the tag and therefore
has nothing in common with any unique identifier defined by an air interface standard. The SID and the
optional signature are secret information and should never be readable for an unauthorized reader. The
SID used by this crypto suite shall never be sent in plaintext. The SID can be signed to preserve integrity
and to provide authenticity. The party that generates the signature, possesses the key pair consisting
of the private and the public key (K , K ) for signature generation and verification. It may forward the
S V
public key K to another party to enable it to verify the signature. F.3 contains the specification of the
V
signature over the SID. Annex F shows the usage of the SID in combination with the non-tractability
feature of this crypto suite.
The Tag does not perform signature generation or verification, nor does it store the corresponding
keys. It only stores the SID along with its signature (which is optional) and the public key K for Tag
E
authentication. If mutual authentication is supported, the Tag also stores the shared secret keys K
ENC
and K .
MAC
The memory locations storing the SID and the secret keys K , K and K shall not be readable for
E ENC MAC
any Interrogator after having written these values once during production of the Tag. For that purpose
a Tag may have a memory area used for storing the SID and the key K configured as WORM or as a
E
fuse. However, production is out of scope of this part of ISO/IEC 29167; this functionality has to be
implemented in a proprietary way.
© ISO/IEC 2016 – All rights reserved 11

The Interrogator application performing RAMON, shall have access to the private decryption key K in
D
order to be able to decrypt the authentication message sent by the Tag. In order to be able to perform
mutual authentication, the Interrogator shall have access to the keys K and K associated with a
ENC MAC
specific SID.
EXAMPLE Figure 3 shows an example system flow with the involved components and keys. System Integrator
and Tag Issuer can work in parallel. The steps performed by these parties can be executed independently of the
other party. Generation of the signature key pair and signing of SIDs is an optional security function provided by
the operational environment.
Figure 3 — System flow of an RFID System using the RAMON crypto suite
12 © ISO/IEC 2016 – All rights reserved

6.6 Key table
The keys used by this crypto suite are listed in Table 4 and Table 5.
Table 4 — Keys of this cipher suite used for Tag identification
Key Usage Length in bits
K Public key for encryption stored on Tag 1024
E
K Private decryption key stored on Interrogator 1024
D
Public signature verification key stored on Interrogator.
K 160
V
This is an ECDSA key (see F.3).
Table 5 — Keys of this cipher suite used for mutual authentication and secure communication
Key Usage Length in bits
K Shared secret encryption key 128
ENC
K Shared secret message authentication key 128
MAC
S Session encryption key 128
ENC
S Session message authentication key 128
MAC
K and K shall be different and shall be available to both the Interrogator and the Tag. The
ENC MAC
establishment/derivation of these keys is not in the scope of this specification.
Session keys shall be destroyed immediately when they are no longer used.
For the Rabin-Montgomery scheme, the public key, K , is an integer which indicates the modulus for the
E
long number arithmetic used for the encryption. The private key, K , comprises two prime numbers, p
D
and q, with pqºº3(mod4), where the following relation holds:
Kp=⋅q
E
The security of the Rabin-Montgomery scheme is given by the fact that a factorization of K is
E
computationally hard.
All keys must be stored by the Tag and the Interrogator, such that unauthorized access and modification
is prohibited.
The performance of the RAMON encryption can be improved by a factor of about 3/2, if prime numbers
p and q are chosen that satisfy the following (optional) additional condition:
k/2
Kp=⋅q=12()mod
E
where k is the bit length of K .
E
The security of the Rabin-Montgomery scheme is given by the fact that a factorization of K is
E
computationally hard.
All keys must be stored by the Tag and the Interrogator, such that unauthorized access and modification
is prohibited.
© ISO/IEC 2016 – All rights reserved 13

7 Parameter definitions
The parameter definitions of the crypto suite are specified in Table 6.
Table 6 — Definition of Parameters
Parameter Description
command code This is a protocol-specific code which indicates that this command belongs to a cipher suite.
KESel [7:0] Key select, determines which key will be used for RAMON encryption.
KSel [7:0] Key select, determines which pair of K , K will be used for mutual authentication.
ENC MAC
CH [127:0] Interrogator random challenge, 16 bytes.
I1
CH [127:0]
I2
CH [127:0] Tag random challenge, 16 bytes.
T
RN [127:0] Tag random number, 16 bytes
T
SID Unique identifier of the Tag, 8 bytes. See Table C.2, for additional information.
IID [63:0] Interrogator identifier, 8 bytes.
IV [127:0] Initialization vector for CBC-encryption, 16 bytes.
SSC [127:0] Sequence counter for replay protection, 16 bytes.
8 State diagrams
8.1 General
This crypto suite allows carrying out Tag identification without mutual authentication and secure
communication. Mutual authentication may be performed after successful Tag identification and secure
communication may be used after successful mutual authentication. Mutual authentication corresponds
to
...

FINAL
INTERNATIONAL ISO/IEC
DRAFT
STANDARD FDIS
29167-19
ISO/IEC JTC 1/SC 31
Information technology — Automatic
Secretariat: ANSI
identification and data capture
Voting begins on:
2015-10-07 techniques —
Voting terminates on:
Part 19:
2015-12-07
Crypto suite RAMON security services
for air interface communications
Technologie informative — Identification automatique et technique
capturé data —
Partie 19: Air interface pour les services de sécurité suite de crypto
RAMON
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/IEC FDIS 29167-19:2015(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN-
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO/IEC 2015

ISO/IEC FDIS 29167-19:2015(E)
© 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. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Conformance . 1
2.1 Claiming conformance . 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 . 3
5.1 Symbols . 3
5.2 Abbreviated terms . 3
5.3 Notation . 4
6 Crypto suite introduction . 5
6.1 Overview . 5
6.2 Authentication protocols . 6
6.2.1 Tag Identification . 6
6.2.2 Symmetric mutual authentication . 7
6.3 Send Sequence Counter . 8
6.4 Session key derivation . 9
6.4.1 KDF in counter mode . 9
6.4.2 Key Derivation Scheme .10
6.5 IID, SID, Used Keys and Their Personalisation.11
6.6 Key table .12
7 Parameter definitions .13
8 State diagrams.14
8.1 General .14
8.2 State diagram and transitions for Tag identification .15
8.2.1 Partial Result Mode.15
8.2.2 Complete Result Mode .16
8.3 State diagram and transitions for mutual authentication .16
8.3.1 Partial Result Mode.17
8.3.2 Complete Result Mode .18
8.3.3 Combination of complete and partial result mode . .19
9 Initialization and resetting .20
10 Identification and authentication.20
10.1 Tag identification .20
10.1.1 Partial Result Mode.20
10.1.2 Complete Result Mode .20
10.2 Mutual authentication .21
10.2.1 Partial Result Mode.21
10.2.2 Complete Result Mode .22
10.3 The Authenticate command.23
10.3.1 Message formats for Tag identification .23
10.3.2 Message formats for Mutual Authentication .24
10.4 Authentication response .25
10.4.1 Response formats for Tag identification .25
10.4.2 Response formats for mutual authentication .26
10.4.3 Authentication error response .28
10.5 Determination of Result Modes .29
© ISO/IEC 2015 – All rights reserved iii

ISO/IEC FDIS 29167-19:2015(E)
11 Secure communication .30
11.1 Secure communication command .30
11.2 Secure Communication response .31
11.2.1 Secure communication error response .31
11.3 Encoding of Read and Write commands for secure communication .31
11.4 Application of secure messaging primitives .32
11.4.1 Secure Communication command messages .32
11.4.2 Secure Communication response messages .34
11.4.3 Explanation of cipher block chaining mode .37
Annex A (normative) State transition tables .39
Annex B (normative) Error codes and error handling.42
Annex C (normative) Cipher description .43
Annex D (informative) Test Vectors .59
Annex E (normative) Protocol specific .62
Annex F (informative) Non-traceable and integrity-protected Tag identification .69
Annex G (informative) Memory Organization for Secure UHF Tags (Proposal) .72
Bibliography .76
iv © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19: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, Subcommittee
SC 31, Automatic identification and data capture.
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 communications
— 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
— Part 20: Crypto suite Algebraic Eraser security services for air interface communications
The following part is under preparation:
— Part 15: Crypto suite XOR security services for air interface communications
© ISO/IEC 2015 – All rights reserved v

ISO/IEC FDIS 29167-19:2015(E)
Introduction
This part of ISO/IEC 29167 specifies the security services of a Rabin-Montgomery (RAMON) crypto
suite. It is important to know that all security services are optional. The crypto suite provides Tag
authentication security service.
The International Organization for Standardization (ISO) and International Electrotechnical
Commission (IEC) draw attention to the fact that it is claimed that compliance with this International
Standard may 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 ensured 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 may be obtained from:
NXP B.V.
411 East Plumeria, San Jose,
CA 95134-1924 USA
The latest information on IP that may be applicable to this part of ISO/IEC 29167 can be found at www.
iso.org/patents.
vi © ISO/IEC 2015 – All rights reserved

FINAL DRAFT INTERNATIONAL STANDARD ISO/IEC FDIS 29167-19:2015(E)
Information technology — Automatic identification and
data capture techniques —
Part 19:
Crypto suite RAMON security services for air interface
communications
1 Scope
This part of ISO/IEC 29167 defines the Rabin-Montgomery (RAMON) crypto suite 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 may be referred by ISO committees for air
interface standards and application standards.
This part of ISO/IEC 29167 specifies a crypto suite for Rabin-Montgomery (RAMON) 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 may support one, a subset, or all of the specified options, clearly stating what
is supported.
2 Conformance
2.1 Claiming conformance
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 may 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.
To conform to this part of ISO/IEC 29167, a Tag may implement any subset of the optional commands
defined in this part of ISO/IEC 29167.
© ISO/IEC 2015 – All rights reserved 1

ISO/IEC FDIS 29167-19:2015(E)
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-3, Information technology — Radio frequency identification for item management —
Part 3: Parameters for air interface communications at 13,56 MHz
ISO/IEC 18000-4, Information technology — Radio frequency identification for item management — Part
4: Parameters for air interface communications at 2,45 GHz
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
authentication
service that is used to establish the origin of information
4.2
confidentiality
property whereby information is not disclosed to unauthorized parties
4.3
integrity
property whereby data has not been altered in an unauthorized manner since it was created,
transmitted or stored
4.4
non-traceability
protection ensuring that an unauthorized interrogator is not able to track the Tag location by using the
information sent in the Tag response
4.5
secure communication
communication between the tag and the interrogator by use of the Authenticate command, assuring
authenticity, integrity and confidentiality of exchanged messages
2 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
5 Symbols and abbreviated terms
5.1 Symbols
xx binary notation
xxh hexadecimal notation
|| concatenation of syntax elements in the order written
5.2 Abbreviated terms
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CH Challenge
CH , CH Interrogator random challenge, 16 bytes
I1 I2
CH Tag random challenge, 16 bytes
T
CG Cryptogram
CMAC Ciphered Message Authentication Code
CRC Cyclic Redundancy Check
CRC–16 16-bit CRC
CS Crypto Suite
CSI Crypto Suite Identifier
DEC(key, data) AES decryption of enciphered “data” with secret “key”
ENC(key, data) AES encryption of plain “data” with secret “key”
EPC™ Electronic Product Code
IID Interrogator Identifier, 8 bytes
IV Initialization Vector for CBC-encryption, 16 bytes
KDF Key Derivation Function
K Public key for encryption stored on Tag
E
K Private decryption key stored on Interrogator
D
K Public signature verification key stored on Interrogator
V
K Private signature generation key stored in the tag issuer facility
S
K Shared secret message encryption key
ENC
K Shared secret message authentication key
MAC
KESel Key select (determines which KE will be used)
KSel Key select (determines which pair of KENC, KMAC will be used)
© ISO/IEC 2015 – All rights reserved 3

ISO/IEC FDIS 29167-19:2015(E)
MAC(key, data) Calculation of a MAC of (enciphered) “data”’ with secret “key”; internal state of
the tag’s state machine
MAMx,y Mutual Authentication Method x.y
MCV MAC Chaining Value
MIX(CH, RN, SID) RAMON mix function
PRF Pseudorandom Function
R Tag response
RAMON Rabin-Montgomery
RFU Reserved for Future Use
RM_ENC(key, data) RAMON encryption of plain “data” with public “key”
RM_DEC(key, data) RAMON decryption of enciphered “data” with private “key”
RN Random Number
RNT Tag Random Number, 16 bytes
S Message encryption session key
ENC
S Message authentication session key
MAC
SID Secret IDentifier, 8 bytes, identifying the tag
SSC Send Sequence Counter for replay protection, 16 bytes
TAMx,y Tag Authentication Method x.y; internal state of the tag’s state machine
TLV Tag Length Value
UHF Ultra High Frequency
UII Unique Item Identifier
WORM Write once, read many
5.3 Notation
This crypto suite uses the notation of ISO/IEC 18000-63.
The following notation for key derivation corresponds to Reference [7] and Clause 5.
PRF(s,x) A pseudo-random function with seed s and input data x.
K Key derivation key used as input to the KDF to derive keying material. K is used as the
I I
block cipher key, and the other input data are used as the message defined in
Reference [5].
K Keying material output from a key derivation function, a binary string of the required
O
length, which is derived using a key derivation key.
Label A string that identifies the purpose for the derived keying material, which is encoded as a
binary string.
4 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
Context A binary string containing the information related to the derived keying material. It may
include identities of parties who are deriving and/or using the derived keying material
and, optionally, a nonce known by the parties who derive the keys.
L An integer specifying the length (in bits) of the derived keying material K . L is repre-
O
sented as a binary string when it is an input to a key derivation function. The length of
the binary string is specified by the encoding method for the input data.
h An integer that indicates the length (in bits) of the output of the PRF.
i A counter that is input to each iteration of the PRF.
r An integer, smaller or equal to 32, that indicates the length of the binary representation
of the counter i. in bits.
00h An all zero octet. An optional data field used to indicate a separation of different variable
length data fields.
The smallest integer that is larger than or equal to X. The ceiling of X.
 
X
 
 
{X} Indicates that data X is an optional input to the key derivation function.
[T] An integer T represented as a binary string (denoted by the “2”) with a length specified
by the function, an algorithm, or a protocol which uses T as an input.
∅ The empty binary string.
6 Crypto suite introduction
6.1 Overview
The RAMON Crypto Suite permits two levels of implementation. The first level provides secure
identification and tag authentication, while the second level extends the functionality by mutual
authentication to securely communicate between Interrogator and Tag, e.g. for secure reading and
writing non-volatile memory.
Basic RAMON Tags may provide only the first level of implementation, while more sophisticated Tags
also provide the second level. See Figure 1 for the different implementation levels for the RAMON
crypto suite.
© ISO/IEC 2015 – All rights reserved 5

ISO/IEC FDIS 29167-19:2015(E)
Figure 1 — Overview of the different implementation levels for the RAMON crypto suite
6.2 Authentication protocols
6.2.1 Tag Identification
The Rabin-Montgomery crypto suite provides non-traceable and confidential Tag identification.
Confidentiality and privacy for the Tag’s identifier are provided without requiring the Tag to store
a private key.
[3]
The crypto suite is based on the asymmetric cryptosystem developed by Michael O. Rabin . The
[2]
original algorithm is augmented by a method detected by Peter Montgomery , which avoids the
division of long numbers in modular arithmetic. Combining Rabin encryption with the concept of
Montgomery multiplication advantage is taken of the fact that no “costly” division is required.
The Tag performs only public key operations. The Interrogator performs the “expensive” private
key operation. The steps necessary to carry out RAMON are outlined in Table 1. RAMON encryption
performed by the Tag and decryption performed by the Interrogator are specified in C.3 and C.4. The
cryptographic keys are specified in 6.6.
This specification also includes in C.1 the structure of the clear text record used for authentication of
the Tag, comprising the Tag identity record and random data originating in part from the Tag and from
the Interrogator for the other part.
6 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
Table 1 — Protocol steps for Tag identification
Interrogator Tag
(K , K ) (SID, K )
D V E
a)  Generate random challenge CH and send (CH ) a)  Generate random number RN .
I1 I1 T
it to the Tag.
→ b)  Generate response cryptogram:
b)  Decrypt Tag response and apply the    R = RM_ENC[K , MIX(CH , RN , TLV record)].
E I1 T
(R)
inverse of the MIX function to get the plaintext
P:
←
−1
P = MIX [RM_DEC (K , R)].
D
c)  Obtain CH , RN and SID from plaintext P.
I1 T
d)  Compare previously generated Interroga-
tor challenge with the value received from Tag.
If successful, Tag is identified.
e)  If a signature is provided along with the
SID, use K to validate the signature. If suc-
V
cessful, Tag is authenticated.
6.2.2 Symmetric mutual authentication
This crypto suite allows combining the Rabin-Montgomery scheme for Tag identification with
symmetric mutual authentication. The mutual authentication specified by this crypto suite is based
on AES, according to Reference [8]. The CBC mode for encryption is specified in Reference [4]. For MAC
generation CMAC according to Reference [5] is used. For derivation of secure messaging keys, the KDF
in counter mode specified in 5.1 of Reference [7] is used.
The protocol steps for mutual authentication are outlined in Table 2.
Table 2 — Protocol steps for mutual authentication
Interrogator Tag
Phase
(IID, Database, K , K ) (SID, K , K , K )
D V E ENC MAC
a)  Tag a)  Generate random challenge CH and (CH ) a)  Generate random number RN .
I1 I1 T
Identification send it to the Tag.
→ b)  Generate response:
b)  Decrypt Tag response and apply the    R = RM_ENC[K , MIX(CH , RN ,
E I1 T
(R)
inverse of the MIX function to get the plain- TLV record, ‘00’ byte)].
text P: ←
−1
P = MIX [RM_DEC (K , R)].
D
c)  Obtain CH , RN and SID from plaintext
I1 T
P.
d)  Compare previously generated Inter-
rogator challenge with the value received
from Tag. If successful, Tag is identified.
e)  If a signature is provided along with
the SID, use K to validate the signature. If
V
successful, Tag is authenticated.
f)  Set CH = RN .
T T
The Interrogator has successfully identified (and authenticated) the Tag.
In the following phase, CHT and SID are used in the mutual authentication.
© ISO/IEC 2015 – All rights reserved 7

ISO/IEC FDIS 29167-19:2015(E)
Table 2 (continued)
Interrogator Tag
Phase
(IID, Database, K , K ) (SID, K , K , K )
D V E ENC MAC
b)  Mutual a)  Generate CH . (CG ) a)  Decrypt and verify the crypto-
I2 I
Authentication gram:
b)  Generate cryptogram: →
MAC (K , C);
MAC
S = CH || IID || CH || SID;
I2 T
(CG )    DEC (K , C).
ENC
T
C = ENC (K , S);
ENC
M = MAC (K , C); b)  Verify CH and SID. If equal,
←
MAC T
CG = C || M. generate Session Keys S , S .
I ENC MAC
c)  Verify the cryptogram: c)  Initialize SSC.
MAC (K , C);
MAC
d)  Generate Tag cryptogram:
DEC (K , C).
ENC
S = CH || SID || CH || IID;
T I2
d)  Verify CH , CH , SID and IID.    C = ENC (K , S);
I2 T ENC
M = MAC (K , C);
MAC
e)  If equal, generate session keys: S ,
ENC
CG = C || M
T
S .
MAC
f)  Initialize SSC.
Mutual authentication is now complete and a secure channel is established.
The Interrogator has access to a list of SIDs (Secret identifiers) with the associated K and K for
ENC MAC
each Tag. This is represented by the “Database” on Interrogator’s site.
After having successfully identified the Tag in Phase 1, the Interrogator is able to find secret keys K
ENC
and K that it shares with the Tag. K is used in CBC mode. The IV for encryption is set to all zeroes
MAC ENC
00h.00h. As the size of S is on both sides a multiple of the AES block size, no padding is applied. K is
MAC
used to calculate a 16-byte MAC.
CH and CH are used as challenges in the challenge-response protocol for mutual authentication and
T I2
for generation of the starting value of the SSC. See 6.3 for details.
The session encryption key, S , is used for confidentiality of data in transit. AES encryption, including
ENC
an SSC, is illustrated in Figure 18; decryption is illustrated in Figure 19. The session MAC key, S , is
MAC
used for data and protocol integrity. This crypto suite derives session keys as specified in 6.4.
If the Tag cannot verify the interrogator’s MAC, it reports a Crypto Suite error (see Annex B for
information) and assumes state Init. If the interrogator cannot verify the tag’s MAC, the tag is not
authenticated.
6.3 Send Sequence Counter
The send sequence counter (SSC) ensures that the Initial Values (IVs) are different for every encryption
and the MAC chaining values (MCVs) are different for every MAC generation. To this end, the SSC is
incremented (+1) each time before a Secure Communication command or response is processed.
After mutual authentication, the initial value of the send sequence counter SSC is generated as follows:
SSC = CH ( least significant bytes) ||
T
CH ( least significant bytes)
I2
After receiving a secure command, the Tag increments SSC, then checks the MAC and then decrypts the
command. In turn, before sending a secure response the Tag increments SSC, encrypts the response
and generates the MAC. Each particular step is under control of the security flags. Thus, if SSC has the
value x at idle time, x+1 is used for processing the next secure command, and x+2 is used for processing
the response. SSC may overflow to 0h during the increment without particular action.
8 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
6.4 Session key derivation
The derivation of the session keys, S and S , is based on the KDF in counter mode specified in 5.1
ENC MAC
of Reference [7]. This method uses CMAC as the PRF with AES as underlying block cipher with full 16
bytes output length. The input to the PRF for this cipher suite is as specified in 6.4.2.
6.4.1 KDF in counter mode
The key derivation function iterates a pseudorandom function n times and concatenates the output
until L bits of keying material are generated, where n: = [L/h]. In each iteration, the fixed input data is
the string Label || 00h || Context || [L] . The counter [i] is the iteration variable and is represented as a
2 2
binary string of r bits.
Figure 2 illustrates the process.
The input to the PRF [see step d) of Process] is explained in 6.4.2.
For the derivation of session encryption key S , K is set to K . For the derivation of session MAC
ENC I ENC
key S , K is set to K .
MAC I MAC
Fixed values
— h – The length of the output of the PRF in bits;
— r – The length of the binary representation of the counter i. in bits.
Input: K , Label, Context, and L.
I
Process
a) n: = [L/h].
r
b) If n > 2 -1, then indicate a crypto suite error and stop.
c) result(0): = ∅.
d) For i = 1 to n, do
— K(i): = PRF (K , [i] || Label || 00h || Context || [L] );
I 2 2
— result(i): = result(i-1) || K(i).
e) Return: K : = the leftmost L bits of result (n).
O
Output: K .
O
© ISO/IEC 2015 – All rights reserved 9

ISO/IEC FDIS 29167-19:2015(E)
NOTE SOURCE: Reference [7].
Figure 2 — KDF in Counter Mode
6.4.2 Key Derivation Scheme
The following derivation data are used to generate session keys according to the KDF in counter mode
as specified in Reference [7].
The one byte counter, i, may take the values 01h or 02h. The value 01h is used when L takes the
value 0080h for derivation of AES-128 keys, which is currently the only case relevant for this part of
ISO/IEC 29167 (see NOTE below).
The iteration variable, i, is concatenated with the fixed input data. The fixed input data is a concatenation
of a Label, a separation indicator 00h, the Context, and [L] as follows:
— Label: consists of 11 zeroes (00h) bytes followed by a one byte derivation constant as defined in Table 3;
— One byte separation indicator 00h;
— Context: CH || CH ;
I2 T
— [L] : the length in bits of the derived data. For derivation of AES-128 keys which is currently the only
case relevant for this part of ISO/IEC 29167, L takes the value 0080h (see NOTE below).
In each iteration, the fixed input data is the string Label || 0x00 || Context || [L] .
NOTE Currently, this part of ISO/IEC 29167 only supports AES-128 keys. In the future, this part of
ISO/IEC 29167 may be changed to additional key length.
10 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
Table 3 — Encoding of the one byte derivation constant
b8 b7 b6 b5 b4 b3 b2 b1 Description
0 0 0 0 0 0 1 x Key derivation
Derivation of session encryption key S with K set to
ENC I
0 0 0 0 0 0 x 0
K
ENC
0 0 0 0 0 0 x 1 Derivation of session MAC key S with K set to K
MAC I MAC
NOTE   Any other value is RFU.
A Tag or an Interrogator using a derivation constant marked as RFU is not compliant to this part of
ISO/IEC 29167.
6.5 IID, SID, Used Keys and Their Personalisation
This crypto suite assumes the following keys and information to be available on the Tag:
— the SID, optionally signed with the signature key K before it was stored on the Tag;
S
— the RAMON encryption key K ;
E
and, if mutual authentication is provided:
— the shared secret keys K and K .
ENC MAC
On the Interrogator:
— the RAMON decryption key K ;
D
— optionally, the signature verification key K ;
V
— a list of valid SIDs; each SID might have a signature attached to it;
and, if mutual authentication is provided:
— the shared secret keys K and K .
ENC MAC
The IID is an 8-byte value, which identifies the interrogator to the Tag. The IID can be chosen freely, but
must remain constant during a session.
The SID is a unique 8-byte value, which identifies the Tag to the interrogator. It is set during
personalization and remains constant throughout the lifetime of the Tag.
The SID used by this crypto suite is used by the application to securely identify the tag and therefore
has nothing in common with any unique identifier defined by an air interface standard. The SID and the
optional signature are secret information and should never be readable for an unauthorized reader. The
SID used by this crypto suite shall never be sent in plaintext. The SID can be signed to preserve integrity
and to provide authenticity. The party that generates the signature, possesses the key pair consisting
of the private and the public key (K , K ) for signature generation and verification. It may forward the
S V
public key K to another party to enable it to verify the signature. F.3 contains the specification of the
V
signature over the SID. Annex F shows the usage of the SID in combination with the non-tractability
feature of this crypto suite.
The Tag does not perform signature generation or verification, nor does it store the corresponding keys. It
only stores the SID along with its signature (which is optional) and the public key K for Tag authentication.
E
If mutual authentication is supported, the Tag also stores the shared secret keys K and K .
ENC MAC
The memory locations storing the SID and the secret keys K , K and K shall not be readable for
E ENC MAC
any Interrogator after having written these values once during production of the Tag. For that purpose
a Tag may have a memory area used for storing the SID and the key K configured as WORM or as a
E
fuse. However, production is out of scope of this part of ISO/IEC 29167; this functionality has to be
implemented in a proprietary way.
© ISO/IEC 2015 – All rights reserved 11

ISO/IEC FDIS 29167-19:2015(E)
The Interrogator application performing RAMON, shall have access to the private decryption key K in
D
order to be able to decrypt the authentication message sent by the Tag. In order to be able to perform
mutual authentication, the Interrogator shall have access to the keys K and K associated with a
ENC MAC
specific SID.
EXAMPLE Figure 3 shows an example system flow with the involved components and keys. System Integrator
and Tag Issuer can work in parallel. The steps performed by these parties can be executed independently of the
other party. Generation of the signature key pair and signing of SIDs is an optional security function provided by
the operational environment.
Figure 3 — System flow of an RFID System using the RAMON crypto suite
6.6 Key table
The keys used by this crypto suite are listed in Table 4 and Table 5.
12 © ISO/IEC 2015 – All rights reserved

ISO/IEC FDIS 29167-19:2015(E)
Table 4 — Keys of this cipher suite used for Tag identification
Key Usage Length in bits
K Public key for encryption stored on Tag 1 024
E
K Private decryption key stored on Interrogator 1 024
D
Public signature verification key stored on Interrogator. This is an ECDSA
K 160
V
key (see F.3).
Table 5 — Keys of this cipher suite used for mutual authentication and secure communication
Key Usage Length in bits
K Shared secret encryption key 128
ENC
K Shared secret message authentication key 128
MAC
S Session encryption key 128
ENC
S Session message authentication key 128
MAC
K and K shall be different and shall be available to both the Interrogator and the Tag. The
ENC MAC
establishment/derivation of these keys is not in the scope of this specification.
Session keys shall be destroyed immediately when they are no longer used.
For the Rabin-Montgomery scheme, the public key, K , is an integer which indicates the modulus for the
E
long number arithmetic used for the encryption. The private key, K , comprises two prime numbers, p
D
and q, with pq≡≡3(mod4) , where the following relation holds:
Kp=⋅q
E
The security of the Rabin-Montgomery scheme is given by the fact that a factorization of K is
E
computationally hard.
All keys must be stored by the Tag and the Interrogator, such that unauthorized access and modification
is prohibited.
The performance of the RAMON encryption can be improved by a factor of about 3/2, if prime numbers
p and q are chosen that satisfy the following (optional) additional condition:
k/2
Kp=⋅q =12()mod
E
where k is the bit length of K .
E
The security of the Rabin-Montgomery scheme is given by the fact that a factorization of K is
E
computationally hard.
All keys must be stored by the Tag and the Interrogator, such that unauthorized access and modification
is prohibited.
7 Parameter definitions
The parameter definitions of the crypto suite are specified in Table 6.
© ISO/IEC 2015 – All rights reserved 13

ISO/IEC FDIS 29167-19:2015(E)
Table 6 — Definition of Parameters
Parameter Description
command code This is a protocol-specific code which indicates that this command belongs to a cipher
suite.
KESel [7:0] Key select, determines
...