ISO/IEC 29192-4:2013

Information technology — Security techniques — Lightweight cryptography — Part 4: Mechanisms using asymmetric techniques

ISO/IEC 29192-4:2013 specifies three lightweight mechanisms using asymmetric techniques: a) a unilateral authentication mechanism based on discrete logarithms on elliptic curves; b) an authenticated lightweight key exchange (ALIKE) mechanism for unilateral authentication and establishment of a session key; c) an identity-based signature mechanism.

Technologies de l'information — Techniques de sécurité — Cryptographie pour environnements contraints — Partie 4: Mécanismes basés sur les techniques asymétriques

General Information

• Status: Published
• Publication Date: 21-May-2013
• ICS: 35.030 - IT Security
• ICS: 35.040 - Information coding
• Technical Committee: ISO/IEC JTC 1/SC 27 - Information security, cybersecurity and privacy protection
• Drafting Committee: ISO/IEC JTC 1/SC 27/WG 2 - Cryptography and security mechanisms
• Current Stage: 9093 - International Standard confirmed
• Start Date: 03-May-2024
• Completion Date: 14-Feb-2026

Relations

• Amended By: ISO/IEC 29192-4:2013/Amd 1:2016 - Information technology — Security techniques — Lightweight cryptography — Part 4: Mechanisms using asymmetric techniques — Amendment 1
• Effective Date: 15-Aug-2020

Overview

ISO/IEC 29192-4:2013 - Information technology - Security techniques - Lightweight cryptography - Part 4: Mechanisms using asymmetric techniques - specifies three lightweight asymmetric cryptographic mechanisms tailored for constrained environments. The document defines:

• a unilateral authentication mechanism based on discrete logarithms on elliptic curves (often referenced as cryptoGPS);
• an authenticated lightweight key exchange (ALIKE) mechanism for unilateral authentication and session-key establishment (based on a variant of RSA);
• an identity-based signature mechanism that simplifies key management by deriving signer keys from identities.

The standard targets low-resource devices (e.g., RFID tags, sensors, embedded IoT nodes) where computation, memory and power are limited.

Key Topics and Requirements

ISO/IEC 29192-4 defines technical requirements and procedures for each mechanism, including:

• Security requirements for the environment - guidance on assumptions and threat models for constrained deployments.
• Key production - processes for generating and distributing asymmetric pairs, master secret keys (for identity-based schemes), and claimant/signer parameters.
• Authentication exchanges and formats - detailed procedures for unilateral authentication, ALIKE exchanges, and sign/verify operations.
• Session-key derivation - how session keys are derived and handled following ALIKE authenticated exchanges.
• Performance-oriented techniques - support for pre-computation (“coupons”), memory-computation trade-offs (Annex B), and numerical examples (Annex C) to aid implementation in tight-resource contexts.
• Object identifiers and interoperability elements (Annex A) for integration into broader systems.

Normative references include ISO/IEC 15946-1 (elliptic-curve cryptography) and ISO/IEC 29192-1 (lightweight cryptography general).

Practical Applications

ISO/IEC 29192-4 is practical for:

• IoT and RFID device authentication - lightweight unilateral authentication (cryptoGPS) enables identification of constrained provers with minimal runtime cost using offline coupons.
• Secure session establishment - ALIKE provides unilateral authentication plus session-key agreement in environments where full asymmetric protocols are too heavy.
• Simplified signing and verification - identity-based signatures reduce certificate and PKI overhead by deriving signing keys from identities, useful for large fleets of constrained devices.

Typical use-cases: asset tracking, sensor networks, access control, device onboarding, and other low-power embedded systems requiring asymmetric security primitives.

Who Should Use This Standard

• Security architects and engineers designing IoT/RFID systems
• Embedded and firmware developers implementing lightweight cryptography
• Product managers and compliance teams evaluating secure options for constrained devices
• Standards and interoperability bodies aligning device authentication and key-management practices

Related standards and notes

• See ISO/IEC 29192-1 (Lightweight cryptography - General) and ISO/IEC 15946-1 (ECC fundamentals).
• Patent notice: the standard may reference patented techniques; holders identified in the document (e.g., France Telecom, Gemalto, A*STAR/Exploit Technologies) have declared licensing terms. Consult ISO and IEC patent databases for current information.

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 29192-4
First edition
2013-06-01
Information technology — Security
techniques — Lightweight cryptography
Part 4:
Mechanisms using asymmetric
techniques
Téchnologies de l'information — Techniques de sécurité —
Cryptographie pour environnements contraints
Partie 4: Mécanismes basés sur les techniques asymétriques

Reference number
©
ISO/IEC 2013
©  ISO/IEC 2013
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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2013 – All rights reserved

Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 Unilateral authentication mechanism based on discrete logarithms on elliptic curves . 6
5.1 General . 6
5.2 Security requirements for the environment . 6
5.3 Key production . 7
5.4 Unilateral authentication mechanism . 8
6 Unilateral authenticated key exchange mechanism based on encryption . 9
6.1 General . 9
6.2 Security requirements for the environment . 10
6.3 Key production . 10
6.4 Unilateral authentication exchange . 11
6.5 Session-key derivation . 12
7 Identity-based signature mechanism . 12
7.1 General . 12
7.2 Security requirements for the environment . 12
7.3 Key production . 13
7.4 Sign . 13
7.5 Verify . 13
Annex A (normative) Object identifiers . 14
Annex B (normative) Memory-Computation Trade-Off Technique . 15
Annex C (informative) Numerical examples . 16
C.1 cryptoGPS mechanism . 16
C.1.1 Key production . 16
C.1.2 Authentication exchange . 16
C.2 ALIKE mechanism . 18
C.2.1 Key production . 18
C.2.2 Authentication exchange . 18
C.2.3 Session-key derivation . 19
C.3 Identity-based signature mechanism . 19
C.3.1 Key production . 19
C.3.2 Sign . 20
C.3.3 Verify . 21
Annex D (informative) Features . 22
Bibliography . 25

© ISO/IEC 2013 – All rights reserved iii

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
ISO/IEC 29192-4 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, IT Security techniques.
ISO/IEC 29192 consists of the following parts, under the general title Information technology — Security
techniques — Lightweight cryptography:
 Part 1: General
 Part 2: Block ciphers
 Part 3: Stream ciphers
 Part 4: Mechanisms using asymmetric techniques
Further parts may follow.
iv © ISO/IEC 2013 – All rights reserved

Introduction
This part of ISO/IEC 29192 specifies three lightweight mechanisms based on asymmetric cryptography. The
three mechanisms have different functionality, different supporting infrastructures, and different performance
profiles.
 cryptoGPS is a lightweight asymmetric identification scheme; in the cryptographic literature such
schemes are generally described as interactive proofs of knowledge. While there are many types of such
scheme, the computational costs for the prover when using cryptoGPS are relatively low. This is
particularly the case since cryptoGPS is well-suited to an implementation strategy using what is often
referred to as "coupons". These are, essentially, the results given by a modest off-line pre-computation,
with coupons being used by the prover at each invocation of the cryptoGPS scheme. The resultant
scheme, with the role of the prover being taken by a computationally restricted device such as an RFID
tag, offers very useful performance trade-offs.
 ALIKE is an asymmetric mechanism for authentication and key exchange. Based on a variant of RSA,
ALIKE offers a unilateral authentication and an additional functionality, i.e. secure key establishment.
ALIKE offers implementation advantages when compared to conventional asymmetric solutions such as
RSA.
 The third mechanism is an identity-based signature scheme. Hence a trusted third party is involved in the
computation of distinct signature keys. This scheme offers implementation advantages over many other
schemes in the cryptographic literature.
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC)
draw attention to the fact that it is claimed that compliance with this document may involve the use of patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights.
The holders of these patent rights have assured ISO and the IEC that they are willing to negotiate licences
either free of charge or 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 may be obtained from:
France Telecom
38-40, rue du Général Leclerc, F-92794 Issy Les Moulineaux CEDEX 9, France
Gemalto SA
6, rue de La Verrerie, 92917 Meudon CEDEX, France
Agency for Science, Technology and Research
Agency for Science, Technology and Research c/o Exploit Technologies Pte Ltd,
30 Biopolis Street, #09-02 Matrix, Singapore 138671
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights other than those identified above. ISO and IEC shall not be held responsible for identifying any or all
such patent rights.
ISO (www.iso.org/patents) and IEC (http://patents.iec.ch) maintain on-line databases of patents relevant to
their standards. Users are encouraged to consult the databases for the most up to date information
concerning patents.
© ISO/IEC 2013 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 29192-4:2013(E)

Information technology — Security techniques — Lightweight
cryptography
Part 4:
Mechanisms using asymmetric techniques
1 Scope
This part of ISO/IEC 29192 specifies three lightweight mechanisms using asymmetric techniques:
 a unilateral authentication mechanism based on discrete logarithms on elliptic curves;
 an authenticated lightweight key exchange (ALIKE) mechanism for unilateral authentication and
establishment of a session key;
 an identity-based signature mechanism.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 15946-1, Information technology — Security techniques — Cryptographic techniques based on
elliptic curves — Part 1: General
ISO/IEC 29192-1, Information technology — Security techniques — Lightweight cryptography — Part 1:
General
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29192-1 and the following apply.
3.1
asymmetric cryptographic technique
cryptographic technique that uses two related operations: a public operation defined by a public data item, and
a private operation defined by a private data item
Note 1 to entry: The two operations have the property that, given the public operation, it is computationally infeasible
to derive the private operation.
[SOURCE: ISO/IEC 9798-5:2009, definition 2.3]
3.2
asymmetric pair
two related data items where the private data item defines a private operation and the public data item defines
a public operation
© ISO/IEC 2013 – All rights reserved 1

[SOURCE: ISO/IEC 9798-5:2009, definition 2.5]
3.3
challenge
procedure parameter used in conjunction with secret parameters to produce a response
[SOURCE: ISO/IEC 9798-5:2009, definition 2.6]
3.4
claimant
entity whose identity can be authenticated, including the functions and the private data necessary to engage in
authentication exchanges on behalf of a principal
[SOURCE: ISO/IEC 9798-5:2009, definition 2.7]
3.5
claimant parameter
public data item, number or bit string, specific to a given claimant within the domain
[SOURCE: ISO/IEC 9798-5:2009, definition 2.9]
3.6
collision-resistant hash-function
hash-function satisfying the following property: it is computationally infeasible to find any two distinct inputs
which map to the same output
Note 1 to entry: computational feasibility depends on the specific security requirements and environment.
[SOURCE: ISO/IEC 10118-1:2000, definition 3.2]
3.7
coupon
pair of pre-computed numbers to be used only once
Note 1 to entry: One of the numbers shall be kept secret, and the other shall remain secret until the time of use.
[SOURCE: ISO/IEC 9798-5:2009, definition 2.8, modified]
3.8
domain
collection of entities operating under a single security policy
Note 1 to entry: For instance, public key certificates created either by a single certification authority, or by a collection
of certification authorities using the same security policy.
[SOURCE: ISO/IEC 9798-5:2009, definition 2.11]
3.9
domain parameter
public key, or function, agreed and used by all entities within the domain
[SOURCE: ISO/IEC 9798-5:2009, definition 2.12]
3.10
entity authentication
corroboration that an entity is the one claimed
[SOURCE: ISO/IEC 9798-1:2010, definition 3.14]
2 © ISO/IEC 2013 – All rights reserved

3.11
exchange multiplicity parameter
number of exchanges of information involved in one instance of an authentication mechanism
[SOURCE: ISO/IEC 9798-5:2009, definition 2.15]
3.12
hash-function
function which maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
 it is computationally infeasible to find for a given output, an input which maps to this output;
 it is computationally infeasible to find for a given input, a second input which maps to the same output
Note 1 to entry: Computational feasibility depends on the specific security requirements and environment.
[SOURCE: ISO/IEC 10118-1:2000, definition 3.5]
3.13
master secret key
secret data item
Note 1 to entry: Master secret key should only be used by the trusted server in accordance with the process of
generation of signer private data.
3.14
private key
private data item of an asymmetric pair
Note 1 to entry: Private key shall be kept secret and should only be used by a claimant in accordance with an
appropriate response formula, thereby establishing its identity.
[SOURCE: ISO/IEC 9798-5:2009, definition 2.21]
3.15
procedure parameter
transient public data item used in an instance of an authentication mechanism, e.g. a witness, challenge or
response
[SOURCE: ISO/IEC 9798-5:2009, definition 2.22]
3.16
public key
public data item of an asymmetric pair, that can be made public and shall be used by every verifier for
establishing the claimant's identity
[SOURCE: ISO/IEC 9798-5:2009, definition 2.23]
3.17
random number
time variant parameter whose value is unpredictable
[SOURCE: ISO/IEC 9798-1:2010, definition 3.29]
3.18
response
procedure parameter produced by the claimant, and processed by the verifier for checking the identity of the
claimant
[SOURCE: ISO/IEC 9798-5:2009, definition 2.25]
© ISO/IEC 2013 – All rights reserved 3

3.19
secret parameter
number or bit string that does not appear in the public domain and is only used by a claimant
Note 1 to entry: For instance, a private key.
[SOURCE: ISO/IEC 9798-5:2009, definition 2.26]
3.20
sign
signature generation process that takes a message and a signing key of a signer to produce a signature
3.21
signer
entity with a unique bit string as an identity, including the functions and the private data necessary to engage
in generation of a signature
3.22
signing key
secret data item given by the trusted server
Note 1 to entry: Signing key should only be used by a signer in accordance with the process of generation of a
signature.
3.23
token
message consisting of data fields relevant to a particular communication and which contains information that
has been produced using a cryptographic technique
[SOURCE: ISO/IEC 9798-5:2009, definition 2.27]
3.24
unilateral authentication
entity authentication which provides one entity with assurance of the other's identity but not vice versa
[SOURCE: ISO/IEC 9798-1:2010, definition 3.39]
3.25
verifier
entity including the functions necessary for engaging in authentication exchanges on behalf of an entity
requiring an entity authentication or for engaging in verifying a signature of a given message and signer
[SOURCE: ISO/IEC 9798-5:2009, modified ─ Added the signature verification case]
3.26
verify
verification process that takes a message, a signature and an identity of a signer to output accept meaning
the given signature is generated by the signer with the corresponding signing key, or reject otherwise
3.27
witness
procedure parameter that provides evidence of the claimant's identity to the verifier
[SOURCE: ISO/IEC 9798-5:2009, definition 2.31]
4 Symbols and abbreviated terms
For the purposes of this part of ISO/IEC 29192, the following symbols and abbreviated terms apply.
4 © ISO/IEC 2013 – All rights reserved

A bit size of the number A if A is a non-negative integer (i.e. the unique integer i so that
i–1 i 16
2  A < 2 if A > 0, or 0 if A = 0, e.g. 65 537 = 2 + 1 = 17), or bit length of the bit string A
if A is a bit string
NOTE To represent a number A as a string of  bits with  >A,  –A bits set to 0 are appended to the left of the
A bits.
A the greatest integer that is less than or equal to the real number A
th
A[i] the i -bit of the number A, where A[1] is the right-most bit and A[A] is the left-most bit
B || C bit string resulting from the concatenation of data items B and C in the order specified. In cases
where the result of concatenating two or more data items is input to a cryptographic algorithm as
part of an authentication mechanism, this result shall be composed so that it can be uniquely
resolved into its constituent data strings, i.e. so that there is no possibility of ambiguity in
interpretation. This latter property could be achieved in a variety of different ways, depending on
the application. For example, it could be guaranteed by
(a) fixing the length of each of the substrings throughout the domain of use of the mechanism,
or
(b) encoding the sequence of concatenated strings using a method that guarantees unique
[18]
decoding, e.g. using the distinguished encoding rules defined in ISO/IEC 8825-1
D response (procedure parameter)
d challenge (procedure parameter)
E elliptic curve (domain parameter)
E block cipher encryption function with key K
K
e public exponent (domain parameter)
* *
f (u, x) f (u, x) = 0 || x || … || 0 || x || 0 || x where x represents the most significant bits of x (potentially
0 0
*
no bits) required so that the length of 0 || x || … || 0 || x || 0 || x is equal to u
* *
f (u, x) f (u, x) = 1 || x || … || 1 || x || 1 || x where x represents the most significant bits of x (potentially
1 1
*
no bits) required so that the length of 1 || x || … || 1 || x || 1 || x is equal to u
h hash-function
h bit length of the hash-code produced by the hash-function h
HE padding function based on the block cipher E (domain parameter)
K
ID binary string that represents the identity or identification information
L bit length of the padding-code produced by the function HE (domain parameter)
m message
N composite modulus (domain parameter)
n order of the base point P (domain parameter)
[n]P multiplication operation that takes a positive integer n and a point P on the curve E as input and
produces as output another point Q on the curve E, where Q = [n]P = P + P + … + P is the sum
of n occurrences of P. The operation satisfies [0]P = 0 (the point at infinity), and [–n]P = [n](–P)
E
© ISO/IEC 2013 – All rights reserved 5

P base point over the elliptic curve E (domain parameter)
p , p … prime factors of the modulus in ascending order, i.e. p < p < … (secret parameters)
1 2 1 2
Q, Q private key (secret parameter)
i
q field size (domain parameter)
r fresh random number or fresh string of random bits (secret parameter)
T public point (domain parameter)
t master secret key (secret parameter)
u bit length of the key K in the block cipher encryption function E (domain parameter)
K
v bit length of a block-message in the block cipher encryption E (domain parameter)
K
W witness (procedure parameter)
w security parameter (domain parameter)
'X X …' number whose hexadecimal representation is X X …, where each X is equal to one of 0-9 and
1 2 1 2 i
A-F
–1
 
 modulus size in bits, i.e. 2  modulus < 2 , also denoted modulus (domain parameter)
 length of fresh strings of random bits for representing challenges (domain parameter)
 length of fresh strings of random bits for representing random numbers (domain parameter)
{a, b, c, …} set containing the elements a, b, c, …
5 Unilateral authentication mechanism based on discrete logarithms on elliptic
curves
5.1 General
This mechanism, cryptoGPS – also called GPS in the earlier cryptographic literature –, is due to Girault,
[6]
Poupard, and Stern . The revised name is now used so as to avoid confusion with the physical location
service GPS. cryptoGPS is a zero-knowledge identification scheme that provides unilateral entity
[21]
authentication. Several variants of cryptoGPS are specified in ISO/IEC 9798-5 and the version most
suitable to constrained devices, along with some optimisations, is presented below.
5.2 Security requirements for the environment
The cryptoGPS mechanism enables a verifier to check that a claimant knows the elliptic curve discrete
logarithm of a claimed public point with respect to a base point. A general framework for cryptographic
techniques based on elliptic curves is given in ISO/IEC 15946-1.
[5] [6]
NOTE 1 This mechanism implements the elliptic curve variant of the cryptoGPS scheme due to Girault, Poupard
[4]
and Stern. It allows use of the so-called LHW (Low Hamming Weight) variant particularly suitable for environments
where the resources of the claimant are very low.
Within a given domain, the following requirements shall be satisfied.
6 © ISO/IEC 2013 – All rights reserved

a) Domain parameters that govern the operation of the mechanism shall be selected. The selected
parameters shall be made available in a reliable manner to all entities within the domain.
b) Every claimant shall be equipped with the same elliptic curve E and a set of parameters, namely the field
size q, a base point P over E, and n the order of point P. The curve and the set of parameters are either
domain parameters or claimant parameters.
c) Each point P used as the base for elliptic curve discrete logarithms shall be such that, for any arbitrary
point J of the curve, finding an integer k in [0, n – 1] (if one exists) such that J = [k]P is computationally
infeasible, where feasibility is defined by the context of use of the mechanism.
d) Every claimant shall be equipped with a private key.
e) Every verifier shall obtain an authentic copy of the public key corresponding to the claimant's private key.
NOTE 2 The exact means by which the verifier obtains a trusted copy of the public point specific to the claimant is
beyond the scope of this part of ISO/IEC 29192. This may, for example, be achieved by the use of public-key certificates
or by some other environment-dependent means.
f) Every verifier shall have the means to produce fresh strings of random bits. When coupons are not used,
every claimant shall also have the means to produce fresh strings of random bits.
g) If the mechanism makes use of a hash-function, then all entities within the domain shall agree on a hash-
[23]
function, e.g. one of the functions specified in ISO/IEC 10118-3 .
5.3 Key production
For claimant A, a fresh string shall be uniformly selected at random from the set {2, 3, …, n – 2}. The string
represents the private key, denoted Q.
The number σ =n gives the number of bits to be used to represent private keys.
Denoted G(A), the public point for claimant A is set equal to either
a) The inverse of the multiplication of the base point P by the number Q.
G(A) = (x , y ) = – [Q]P
G G
NOTE 1 This version is the most suitable for constrained devices.
b) Or the multiplication of the base point P by the number Q.
G(A) = (x , y ) = [Q]P
G G
δ – 1 δ
The challenges are selected from a set of integers S of cardinality ∆, where 2 < ∆ ≤ 2 . The length in bits of
the greatest possible challenge is denoted by β. A value of δ from 8 to 40 is appropriate for most applications.
Unless otherwise specified, the value of δ is set equal to 40. It is a domain parameter.
NOTE 2 The total number of possible challenges should be limited to 2 . If this recommendation is not followed, then
special care should be taken to prevent the verifier using the claimant as a signing oracle.
NOTE 3 When the set of challenges is the interval [0, ∆ – 1], then β = δ.
NOTE 4 A challenge is said to be LHW (Low Hamming Weight) if there are at least σ – 1 zero bits between any two
consecutive one bits in its binary representation.
[21]
NOTE 5 The definition of the public point G(A) differs slightly from that defined in ISO/IEC 9798-5 . This change
allows more compact and efficient implementations of the resultant on-tag computation because the response formula is
now an addition which is easier and more compact to implement than an integer subtraction.
© ISO/IEC 2013 – All rights reserved 7

5.4 Unilateral authentication mechanism
The bracketed letters in Figure 1 correspond to the steps of the mechanism, including the exchanges of
information, described in detail below. The claimant is denoted by A. The verifier is denoted by B.
(b) TokenAB
A B
(d) Challenge
(a), (e) (c), (g)
(f) TokenAB
Figure 1 — Mechanism using a discrete logarithm with respect to elliptic curves
The claimant shall store a number δ, a base P, and a private key Q (as a string of σ bits). Unless otherwise
specified, δ = 40.
In the case of coupon use, in addition to a number δ and a private key Q, the claimant need only store a set of
coupons and is not required to have a means to produce fresh strings of random bits. To be used only once,
each coupon consists of a ρ-bit string (that need not be stored if it can be reproduced by a pseudo-random
[25]
function, e.g. one of the functions specified in ISO/IEC 18031 ) and a witness.
In addition to a number δ and a number σ, the verifier shall be provided with a trusted copy of a public point
G(A) and a trusted copy of the curve E, the base point P and the parameters q and n.
For each application of the mechanism, the following procedure shall be performed. The verifier B shall only
accept the claimant A as valid if the procedure completes successfully.
a) For each authentication,
1) either a coupon (r, W) is used.
2) or a fresh string of ρ bits shall be uniformly selected at random. It shall be kept secret.
ρ = σ + β + 80
NOTE 1 If the fresh string of ρ bits is selected at random, then the probability that the leftmost 80 bits are all equal is
negligible.
Denoted r, the number represented by the fresh string shall be converted into a witness, denoted W.
Witness formula:  W = EC2OSP ([r]P, fmt)
E
with EC2OSP the function to convert a point on elliptic curve E to octet strings defined in
E
ISO/IEC 15946-1 and fmt a format specifier, which is one of the symbolic values compressed,
uncompressed, or hybrid.
NOTE 2 Under certain implementation circumstances some might prefer to use the witness formula
W = EC2OSP ([r mod n]P, fmt).
E
b) A sends TokenAB to B. TokenAB can be either witness W or a hash-code of W and Text, one of the
1 1
following four hash variants.
The four hash variants are h(W || Text), h(W || h(Text)), h(h(W) || Text), and h(h(W) || h(Text)), where h is a
hash-function and Text is an optional text field (it may be empty). If the text field is non-empty, then B shall
have the means to recover the value of Text; this may require that A sends all or part of the text field with the
token. How the text field is made available for use in applications is outside the scope of this part of ISO/IEC
[20]
gives information on the use of text fields. The hash variant is a domain
29192. Annex A of ISO/IEC 9798-1
parameter.
8 © ISO/IEC 2013 – All rights reserved

c) On receipt of TokenAB , a fresh string shall be uniformly selected at random from the set S.
d) B sends the fresh string as a challenge to A. The fresh string represents a number denoted d.
NOTE 3 If an LHW challenge is used, it can be transmitted in a compressed form to A who must have the means to
retrieve the original challenge before step e)1).
e) On receipt of the challenge, the following computational steps are perfor
...