ISO/IEC 29167-12:2015

INTERNATIONAL ISO/IEC
STANDARD 29167-12
First edition
2015-05-15
Information technology — Automatic
identification and data capture
techniques —
Part 12:
Crypto suite ECC-DH security services
for air interface communication
Technologies de l’information — Techniques automatiques
d’identification et de capture de donnees —
Partie 12: Services de sécurité par suite cryptographique ECC-DH
pour communications par interface radio
Reference number
©
ISO/IEC 2015
© 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

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 . 2
3 Normative references . 2
4 Terms and definitions . 2
5 Symbols and abbreviated terms . 3
5.1 Symbols . 3
5.2 Abbreviated terms . 4
6 Introduction of the ECC-DH crypto suite . 5
6.1 Core functionality . 5
6.2 Design principles of the crypto suite . 6
7 Parameter definitions . 6
7.1 Elliptic curve parameters . 6
7.2 Parameters of the EPIF Format . 7
7.3 Random number generation . 7
8 Crypto suite state diagram . 7
9 Initialization and resetting . 8
10 Tag Authentication . 8
10.1 Introduction . 8
10.2 Message and Response formatting . 9
10.2.1 Concept . 9
10.2.2 Description of Message and Response concept. 9
10.2.3 Transmission order of the data . 9
10.2.4 Parsing the Message . . 9
10.3 TAM1.0 .10
10.3.1 TAM1.0 Message — write certificate data .10
10.3.2 TAM1.0 Response .
status of write operation .11
10.3.3 Protection of certificate record .11
10.4 TAM1.1 .11
10.4.1 TAM1.1 Message .
request certificate data .11
10.4.2 TAM1.1 Response .
certificate data .11
10.5 TAM1.2 .12
10.5.1 TAM1.2: Message .
send Interrogator challenge .12
10.5.2 TAM1.2 Response .
authentication result .12
10.6 TAM1.3 .13
10.6.1 TAM1.3: Message .
request certificate data and send challenge.13
10.6.2 TAM1.3 Response .
certificate data and authentication result.13
11 Certificate memory .13
11.1 Concept .13
© ISO/IEC 2015 – All rights reserved iii

11.2 Certificate memory structure .14
11.3 Certificate record .15
11.4 Compressed X.509 certificate .15
11.5 X.509 certificate .17
11.6 Custom certificates .17
12 Tag authentication procedure .17
12.1 Processing steps .17
12.2 IChallenge generation and formatting .17
12.3 IChallenge examination .18
12.4 TResponse generation and formatting .18
12.5 TResponse examination .19
13 Communication .19
14 Key table and key update .20
Annex A (normative) Cryptographic suite State transition table .21
Annex B (normative) Error conditions and error handling .22
Annex C (normative) Cipher description .23
Annex D (informative) Examples ECC cryptographic protocol .25
Annex E (normative) Air Interface Protocol specific information .27
Annex F (normative) Reconstruction of X.509 Certificate .30
Bibliography .39
iv © ISO/IEC 2015 – 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 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
© ISO/IEC 2015 – All rights reserved v

Introduction
Elliptic curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic
structure of elliptic curves over finite fields. For elliptic-curve-based protocols, it is assumed that finding
the discrete logarithm of a random elliptic curve element with respect to a publicly-known base point is
computationally infeasible. The size of the elliptic curve determines the difficulty of the problem.
This part of ISO/IEC 29167 specifies the security services for an RFID Tag with an ECC-DH crypto suite
based on the Diffie-Hellman key exchange algorithm. It specifies the details of a protocol and interface
format for application with RFID Tags which provide unilateral authentication capability, based on the
use of ECC. Although such Tags can operate in any frequency band legitimate for such applications, the
main focus of this part of ISO/IEC 29167 is on externally-powered (also called “passive”) Tags designed
for the HF/UHF frequency bands, where the demands on low silicon footprint and power consumption
are most stringent.
This part of ISO/IEC 29167 defines only Tag authentication for the ECC-DH cipher.
The International Organization for Standardization (ISO) and International Electrotechnical Commission
(IEC) draw attention to the fact that it is claimed that compliance with this part of ISO/IEC 29167 may
involve the use of patents concerning radio-frequency identification and cryptographic technologies
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 licenses
under reasonable and non-discriminatory terms and conditions with applicants throughout the world.
In this respect, the statements of the holders of these patent rights are registered with ISO and IEC.
Information on the declared patents may be obtained from:
Impinj, Inc.
701 N 34th Street, Suite 300 Seattle, WA 98103 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

INTERNATIONAL STANDARD ISO/IEC 29167-12:2015(E)
Information technology — Automatic identification and
data capture techniques —
Part 12:
Crypto suite ECC-DH security services for air interface
communication
1 Scope
This part of ISO/IEC 29167 defines the crypto suite for ECC-DH for the ISO/IEC 18000 air interfaces
standards for radio frequency identification (RFID) devices. Its purpose is to provide a common crypto
suite with Diffie-Hellmann-based authentication using ECC (elliptic curve cryptography) over binary
fields 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 ECC-DH 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.
© ISO/IEC 2015 – All rights reserved 1

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.
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
1)
FIPS PUB 186-4, Digital Signature Standard (DSS)
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
Command (Message)
command that Interrogator sends to Tag with “Message” as parameter
4.2
Certificate
digitally signed statement binding a Public Key to an Identity
Note 1 to entry: The term “Certificate” is also known as “Public Key Certificate”.
4.3
double-word
bit string comprised of 32 bits
4.4
entropy
randomness collected by an operating system or application for use in cryptography or other uses that
require random data
1) http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
2 © ISO/IEC 2015 – All rights reserved

4.5
isomorphism
one-to-one correspondence between the elements of two sets such that the result of an operation on
elements of one set corresponds to the result of the analogous operation on their images in the other set
4.6
Message
part of the Command that is defined by the crypto suite
4.7
Reply (Response)
reply that Tag returns to the Interrogator with “Response” as parameter
4.8
weight
number of non-zero coefficients in the polynomial
4.9
Response
part of the Reply (stored or sent) that is defined by the crypto suite
4.10
X.509
ITU-T standard that defines what information should go into a certificate and describes the format
5 Symbols and abbreviated terms
5.1 Symbols
xxxx binary notation of term “xxxx”, where “x” represents a binary digit
b
xxxx hexadecimal notation of term “xxxx”, where “x” represents a hexadecimal digit
h
In this part of ISO/IEC 29167 the bytes in the hexadecimal numbers are presented with
the MSB at the left and the LSB at the right. The bit order per byte is also presented
with the MSB at the left and the LSB at the right
For example in “ABCDEF ” the byte “AB” is the MSB and the byte “EF” is the LSB
h
|| Concatenation of syntax elements
For example “123456 ” || “ABCDEF ” results in “123456ABCDEF ”, where the byte “12”
h h h
is the MSB and the byte “EF” is the LSB.
() x-coordinate of an elliptic curve point
x
−1
() the modular inverse of the polynomial defined within the braces, where the modulus
is as indicated in the expression context
b(t) polynomial basis representation of the curve parameter b (FIPS186-4)
cert(Q) certificate of the public key Q
c(t) check polynomial used in the EPIF Format
2 163
s(t) such that s (t) mod p(t) = b(t) i.e. the square root of b(t) in the field GF(2 )
E elliptic curve
© ISO/IEC 2015 – All rights reserved 3

Field[a:b] Selection from a string of bits in Field. Selection ranges from bit a till and including
bit b from the bits of the string in Field, whereby Field[0] represents the least signifi-
cant bit. For example Field[2:0] represents the selection of the three least significant
bits of Field
G base point on the elliptic curve B-163 defined in FIPS 186-4
n
GF(2)[t]/p(t) GF(2 ) represented as the field of polynomials modulo a polynomial p(t) of degree n
m(t) the defining polynomial of the ring GF(2)[t]/m(t) used by the EPIF Format
N degree of the polynomial p(t)
ɸ order of the base point on the chosen curve; the bit length of ɸ is considered to be
the key size (FIPS186-4 Notation: n)
p(t) the field polynomial (FIPS186-4)
p’(t) the defining polynomial of the isomorphic field GF(2)[t]/p’(t) used by the EPIF For-
mat
Polstr() binary transmission of the polynomial defined within the braces, highest possible
degree bit first i.e. including leading zeros; hence if the maximum possible degree of
a polynomial is 170, then 171 bits are transmitted i.e. coefficients of terms of degree
170 down to degree 0
Q private key value of the Tag, a scalar in the range 2.ɸ-2
Q public key of the Tag is the elliptic curve point; Q = qG
R random value chosen by the Interrogator in the range 2.ɸ-2 (FIPS186-4)
Ρ isomorphism from GF(2)[t]/p(t) to GF(2)[t]/p’(t)
Σ mapping from GF(2)[t]/p’(t) to GF(2)[t]/m(t)
n 2
Trace() function which is a mapping from GF(2 ) to GF(2); the quadratic equation y + y + α
n
= 0 has a solution in GF(2 ) when Trace(α) = 0
5.2 Abbreviated terms
ECC Elliptic Curve Cryptography
EPIF Error-Protected Isomorphic Field
FIPS Federal Information Processing Standard
GF(x) Galois Field (with x elements)
HF High Frequency (i.e. the frequency band 3MHz to 30 MHz)
NIST (United States) National Institute of Standards and Technology
toEPIF function which describes the transformation to the EPIF format
4 © ISO/IEC 2015 – All rights reserved

6 Introduction of the ECC-DH crypto suite
6.1 Core functionality
Elliptic curve cryptography has been the basis for many cryptographic protocols for authentication and
key agreement. The oldest of these protocols is due to Diffie and Hellmann, and was originally described
in Reference [1] as a method of key agreement between two parties performing computations in the
multiplicative group of GF(p). This method and its analogous implementation using operations in a
group of points on an elliptic curve defined over a finite field, are well known since the inception of
public key cryptography, and are not described further here. Instead, attention is drawn to the specific
idea of using this protocol for entity authentication, in which:
— One party (the proving entity or “prover”) has a static public/private key-pair and a public key
certificate which uses a digital signature to bind the public key with the name of the organization
that produced the key-pair. In a real life application the certificate (with the digital signature) should
be generated by a certification authority.
— The other party (the “verifier”), presents an ephemeral public key to the prover. The prover is
required to perform an operation with the private key using this ephemeral public key as an input,
and to return the result to the verifier.
— The verifier compares this result with that obtained from his own private key operation, using the
ephemeral private key (effectively just a random number) and the prover’s public key as an input.
The private key operation corresponds to multiplication of a point by the private key (a scalar). The
public key corresponds to the multiplication of the private key (scalar) by a predetermined point on the
curve, chosen as a domain parameter of the system. This protocol is illustrated by Figure 1 depicting an
RFID system executing (an authentication protocol using) operations on a group of elliptic curve points.
Tag
Interrogator
1. WriteCertificate
cert(Q)
(optional)
Memory
G: system basepoint
2. Verify Result
Result r: random scalar
(optional)
q: tagprivate key(scalar)
q
Q: tagpublickey point
3. RequestCertificate
Q(=qG)
Cert(Q): certificateofQ
requestCertificate
(optional)
Cert(Q)
4. Verify cert(Q)
cert(Q)
(optional)
5. Generate ChallengerG
[and optional
rG [req.Cert.]
ECCcore
RequestCertificate]
7. Verify cert(Q)
cert(Q), q(rG)
6. Calculate
r
Figure 1 — Elliptic Curve static Diffie-Hellman authentication
In this protocol, the verifier (the Interrogator) first requests the public key certificate from the Tag
and verifies if the certificate is valid. Then the Interrogator generates a ephemeral public key r and
multiplies the system base point G by this number, and sends the resulting point rG to the prover (in
this case the “Tag”). The Tag performs a multiplication of this point by its private key q and returns the
result q(rG) to the Interrogator. The Interrogator then verifies that the private key q was really used by
© ISO/IEC 2015 – All rights reserved 5

checking that r(qG) = = q(rG) where (qG) = Q, the public key point of the Tag. The Interrogator must also
verify that this public key is that of a valid Tag, and accordingly the Tag is also required (somewhere
within the overall protocol) to present a certificate cert(Q), which is signed by a trusted authority who
ensures the authenticity of the public key).
The mathematics of this protocol permits the elliptic curve computations to be performed using only
the x-coordinates of points on the chosen curve (i.e. omitting the computations which involve the
y-coordinate); this results in a lower requirement for computation, and is a well-known property of
Diffie-Hellman protocols, identified in the early days of elliptic curve cryptography.
6.2 Design principles of the crypto suite
The design of the crypto suite is based on the following principles:
— The data exchanges between Tag and Interrogator are designed to minimize the processing and
computation requirements on the Tag (for example, by using formats which avoid the need to
perform modular inversion on the Tag). The exchange of elliptic curve points between Tag and
Interrogator use x-coordinates only to reduce communication overhead and ease computation.
— The data exchanges between the Tag and the Interrogator facilitate simplest possible checking on
the Tag that the x-coordinate of the point supplied to the Tag lies on the intended curve (and not
on its twist), by sending the pair of values (x, (√b)/x) from the Interrogator to the Tag instead of
sending the x and y coordinates of rG; the required check shall then be performed using only two
Trace() computations and a single modular multiplication.
— The data exchanges between the Tag and the Interrogator include an integral integrity mechanism
intended to facilitate integrity checking of cryptographic computations by both parties. In particular,
protection of the computation which is supported. The integrity mechanism is specified in 7.2.
7 Parameter definitions
7.1 Elliptic curve parameters
This part of ISO/IEC 29167 uses Elliptic Curve Cryptography, more particularly it uses elliptic curves E
n
defined over a binary extension field GF(2 ) where E is given by:
23 2
E: y +=xy x ++ ax b
The variables x and y in the above equation are the coordinates of an elliptic curve point and the
coefficients a and b are elliptic curve parameters. The set of points fulfilling the equation together with
a neutral point – the point at infinity – form a group under elliptic curve point addition. Elliptic Curve
Cryptography uses a subgroup of this group generated by a generator G of order ɸ.
NOTE In this part of ISO/IEC 29167 the variable “a” has the constant value 1.
The binary extension field is usually represented as GF(2)[t]/p(t) where p(t) is a primitive polynomial
of degree n; i.e. the elements of the field are represented as polynomials of degree less than n and
operations are performed modulo p(t). For ease of notation the suffix (t) should be dropped when it is
n
clear from the context that an element belongs to GF(2 ).
The authentication protocol defined in this part of ISO/IEC 29167 shall use the Elliptic Curve NIST B-163
whose parameters shall be used as defined in NIST FIPS 186-4.
NOTE please note that NIST FIPS 186–4 uses the variable n to denote the order of the base point (ɸ) and 2^m
to denote the size of the binary field (2^n).
6 © ISO/IEC 2015 – All rights reserved

7.2 Parameters of the EPIF Format
This part of ISO/IEC 29167 shall use the EPIF representation for points and parameters of the elliptic
curve. The EPIF representation is designed on the principle that data exchanges between Tag and
Interrogator should minimize processing time and computational requirements on the Tag; yet allow
robust implementation.
The EPIF format represents the points and parameters of the elliptic curve as elements of the ring GF(2)
[t]/m(t) where m(t) is defined as the product of two irreducible polynomials c(t) and p’(t). The polynomial
m(t) is chosen such that it has minimal weight allowing operations modulo m(t) to be implemented very
efficiently and the polynomial p’(t) is chosen such that GF(2)[t]/p’(t) is isomorphic to GF(2)[t]/p(t). The
polynomials c(t) and p’(t) shall be as defined in normative Annex C.
The transformation to EPIF representation consists of a mapping from GF(2)[t]/p(t) to GF(2)[t]/m(t).
This mapping consist of an isomorphism ρ from GF(2)[t]/p(t) to GF(2)[t]/p’(t) followed by a mapping σ
from GF(2)[t]/p’(t) to GF(2)[t]/m(t) where the mapping σ is such that the following relations shall hold
at all times:
σ :(GF 22)[tp]/ '(tG)(a Ft)[ ]/mt():
∀∈eGFt()2 []/'pt():
σ()ee≡ modppt'( )
σ()ec≡1 mod(t)
This property is used in the protocol to check the elements for errors.
Given the isomorphism ρ, defined as:
ρ :(GF 22)[tp]/ ()tGa Ft()[]/'pt()
The transformation to EPIF format shall be defined as:
toEPIF :(GF 22)[tp]/ ()tGa Ft()[]/(mt):
∀∈vGFt()2 []/(pt):st= oEPIIF()v :
sG∈ Ft()2 []/(mt)
sv≡ρ() mod'pt()
sc≡1 mod(t)
Full details on how to compute the toEPIF() transformation are provided in normative Annex C.
7.3 Random number generation
This part of ISO/IEC 29167 requires the Interrogator to generate a random point. This point should
contain sufficient entropy to meet the requirements of the application.
8 Crypto suite state diagram
The state diagram for this crypto suite consists of one state only; i.e. Initial State.
After power-up the crypto suite transitions to Initial State. The crypto suite shall remain in Initial State
at all times.
© ISO/IEC 2015 – All rights reserved 7

Power-up
CMD: TAM1.0
Action:Write data to certificaterecord
CMD: TAM1.1
Initial
Action:Readdatafromcertificate record
CMD: TAM1.2
State
Action:Execute ECCalgorithm
CMD: TAM1.3
Action:Readdatafromcertificate record
andexecute ECCalgorithm
Note 1: Allvariablefieldswillberesetatpower-up
Figure 2 — Cryptographic suite state diagram
9 Initialization and resetting
This crypto suite only has one state and does not require initialization. The behaviour on reset is to stay
within that state.
Implementations of this part of ISO/IEC 29167 shall ensure that all memory used for intermediate
results is cleared after each operation (message-response pair) and after reset.
The crypto suite shall be reset at power-on.
10 Tag Authentication
10.1 Introduction
This part of ISO/IEC 29167 only supports Tag Authentication. In addition this part of ISO/IEC 29167
also supports writing data of a certificate record to the Tag and requesting data of a certificate record
from the Tag as additional modes of operation. 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 1.
8 © ISO/IEC 2015 – All rights reserved

Table 1 — Tag authentication messages and responses
Command Function
TAM1.0 message Write certificate data to the Tag
TAM1.0 response Return status of writing data
TAM1.1 message Request certificate data from the Tag
TAM1.1 response Receive certificate data
TAM1.2 message Send Interrogator Challenge
TAM1.2 response Receive cryptographic response
TAM1.3 message Request certificate record and send Interrogator Challenge
TAM1.3 response Receive certificate record and cryptographic response
10.2 Message and Response formatting
10.2.1 Concept
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.
10.2.2 Description of Message and Response concept
In TAM1.0 the Interrogator may write a public-key certificate in blocks to the Tag. In TAM1.1 the
Interrogator may request a public key certificate in blocks from the Tag. In TAM1.2 the Interrogator
sends a challenge to the Tag and the Tag replies with the response that the Interrogator shall verify
using a public key. In TAM1.3 the Interrogator request the Tag to send a certificate record and sends
a challenge to the Tag. The Tag replies with the content of the requested certificate record and the
cryptographic response that the Interrogator shall verify using a public key.
NOTE All message and response pairs may be exchanged in random sequence.
Authenticate(TAM1.1/TAM1.2/TAM1.3/TAM1.4 Message)
(TAM1.1/TAM1.2/TAM1.3/TAM1.4 Response)
Figure 3 — Message and Response exchange
10.2.3 Transmission order of the data
The transmission order of the data for all Messages and Responses shall be most significant bit first.
Within each Message or Response the most significant word shall be transmitted first.
Within each word the most significant bit shall be transmitted first.
10.2.4 Parsing the Message
For reasons of efficiency the coding for the authentication method and the mode of operation are
combined into one field; AuthParam, as defined in Table 2.
© ISO/IEC 2015 – All rights reserved 9
Interrogator
Tag
Table 2 — Definition of AuthParam flags
Name Value Description
AuthParam[1:0] 00 Write data for Tag certificate
b
AuthParam[1:0] 01 Request data from Tag certificate
b
AuthParam[1:0] 10 Authenticate Tag
b
AuthParam[1:0] 11 Request certificate record from Tag and authenticate Tag——
b
The crypto suite shall parse the Messages and process the data based on the value of AuthParam, which
is the first parameter of all Messages.
The following sections of this document describe the formatting of Message and Response for Tag
Authentication. The Messages shall be distinguished by AuthParam.
If AuthParam = “00 ” the Tag shall parse Message as described in 10.3
b
If AuthParam = “01 ” the Tag shall parse Message as described in 10.4
b
If AuthParam = “10 ” then the Tag shall parse Message as described in 10.5.
b
If AuthParam = “11 ” then the Tag shall parse Message as described in 10.6.
b
If AuthParam[7:2] ≠ “000000 ” then the Tag shall return a “Not Supported” error condition and shall
b
transition to the Initial state.
10.3 TAM1.0
10.3.1 TAM1.0 Message — write certificate data
An Interrogator may use the TAM1.0 Message to write certificate data in blocks (double words) to the
Tag. The certificate data may be stored at any appropriate location in the Tag but it shall be accessible
through the TAM1.1 Message. The layout of the certificate memory shall be as described in Clause 11.
An Interrogator may request the Tag to store certificate data at any time during the protocol.
To write a block of certificate data to the Tag the Interrogator shall format a TAM1.0 message according
to the format described in Table 3.
The fields of the TAM1.0 message shall have the following meaning:
— AuthParam: The authentication parameter as described in 10.2.4. It shall be set to 00
h
— CertNum: The number of the certificate record.
NOTE The manufacturer may limit the size of each certificate and the number of supported certificates.
— WordPtr: A 16-bit pointer indicating the position of a double word within the certificate record.
— Data: A 32-bit value to be written to the certificate record.
Table 3 — TAM1.0 Message format
AuthParam CertNum WordPtr Data
# of bits 8 8 16 32
number of starting data to
Description 00
h
certificate record address pointer be written
10 © ISO/IEC 2015 – All rights reserved

10.3.2 TAM1.0 Response – status of write operation
In case of a write error the Tag shall report a “Memory Write Error” error condition.
In case of other errors the Tag shall report an “Other Error” error condition.
A Tag shall respond to a TAM1.0 Message with a TAM1.0 Response. The TAM1.0 Response shall be empty
(zero bits).
10.3.3 Protection of certificate record
A certificate record may be protected by using of the “properties” field of the certificate header, as
described in 11.3. After a certificate header is written to the Tag’s memory with the “properties” field
set to “1 ”, the contents of the certificate record shall not be changed.
b
NOTE The certificate header should be written as the last double word of the certificate record.
10.4 TAM1.1
10.4.1 TAM1.1 Message – request certificate data
An Interrogator may use the TAM1.1 Message to request the Tag to send certificate data in blocks. The
certificate data may be stored at any appropriate location in the Tag but it shall be accessible through
the TAM1.1 Message.
An Interrogator may request the Tag to send certificate data at any time during the protocol.
To request certificate data from the Tag the Interrogator shall format a TAM1.1 message according to
the format described in Table 4.
The fields of the TAM1.1 message shall have the following meaning:
— AuthParam: The authentication parameter as described in 10.2.4. It shall be set to 01
h
— CertNum: The number of the certificate record.
— WordPtr: A 16-bit pointer indicating the position of a double-word within the certificate record.
— WordCount: A 16-bit value indicating the number of double words to be read from the certificate
record starting from the position indicated by WordPtr. The value of 0000 shall be used to indicate
h
the full contents of the certificate record st
...