ISO/IEC 9798-5:1999

Information technology — Security techniques — Entity authentication — Part 5: Mechanisms using zero knowledge techniques

Technologies de l'information — Techniques de sécurité — Authentification d'entité — Partie 5: Mécanismes utilisant les techniques de connaissance du zéro

General Information

• Status: Withdrawn
• Publication Date: 24-Mar-1999
• Withdrawal Date: 24-Mar-1999
• 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: 9599 - Withdrawal of International Standard
• Start Date: 06-Dec-2004
• Completion Date: 12-Feb-2026

Relations

• Revised: ISO/IEC 9798-5:2004 - Information technology — Security techniques — Entity authentication — Part 5: Mechanisms using zero-knowledge techniques
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL
ISOAEC
STANDARD
9798-5
First edition
1999-03- 15
Information technology - Security
techniques - Entity authentication -
Part 5:
Mechanisms using Zero knowledge techniques
Technologies de I’information - Techniques de skcurite - Authentification
d ’entitk -
Partie 5: Mkcanismes utilisant les techniques de connaissance du z&o

ISO/IEC !mw--5 : Mm(E)
Page
Contents
v
Foreword .
Scope .
..................................... 1
2 Normative references
.............................................. 1
3 Definitions
....................................
4 Symbols and notation
............................. 3
Mechanism based on identities
5.1 .
Specific requirements
5.2 Parameter selection .
......................................
5.3 Identity selection
................................. 4
5.4 Accreditation generation
................................. 5
5.5 Authentication exchange
........ 6
6 Certificate-based mechanism using discrete logarithms
................................... 6
6.1 Specific requirements
......................................... 6
6.2 Key selection
................................. 6
6.3 Authentication exchange
‘7 Certificate-based mechanism using an asymmetric encipherment
System .
................................... 7
7.1 Specific requirements
.................................
7.2 Authentication exchange
.................... 9
A Principles of zero knowledge mechanisms
..........................................
A.l Introduction
.................... 9
A.2 The need for Zero-knowledge mechanisms
........................................
A.3 The definition.
..........................................
A.4 An example
..................................
A.5 Basic design principles
.............................
B Guidance on Parameter choice
............. 12
B.l Parameter choice for the identity-based mechanism
@ ISO/IEC 1999
All rights reserved. Unless otherwise specified, no part of this publication may
be reproduced or utilized in any form or by any means, electronie or mechanical,
including photocopying and microfilm, without Permission in writing from the pub-
lisher.
ISO/IEC Copyright Office l Case Postale 56 l CH-1211 Geneve 20 a Switzerland
Printed in Switzerland
ii
@ISO/IEC ISO/IEC 9798-5 : 1999(E)
IB.2 Parameter choice for the certificate-based mechanism using discrete
logarithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C Examples . 13
C.l Mechanism based on identities . 13
C.1.1 Example with public exponent 2 . 13
C.l.l.l Parameter selection 13
........................
C.1.1.2 Identity selection 13
..........................
C.1.1.3 Accreditation generation . 13
C.1.1.4 Authentication exchange .
Cl.2 Example with public exponent 3 . 15
C.l.2.1 Parameter selection . 15
C.1.2.2 Identity selection . 15
C.1.2.3 Accreditation generation .
C. 1.2.4 Authentication exchange .
C.1.3 Example with public exponent 216 + 1 . 18
C.1.3.1 Parameter selection . 18
C.1.3.2 Identity selection . 18
C.1.3.3 Accreditation generation . 18
C.1.3.4 Authentication exchange . 18
C.2 Mechanism based on discrete logarithms . 20
C.2.1 Example using 768-bit p, 128-bit 4 and RIPEMD-128. . 20
C.2.1.1 Parameter selection . 20
C.2.1.2 Key selection . 20
C.2.1.3 Authentication exchange . 20
C.2.2 Example using ION-bit p, 160-bit Q and SHA-1 . 20
C.2.2.1 Parameter selection .
C.2.2.2 Key selection . 21
C.2.2.3 Authentication exchange . 21
C.3 Mechanism based on a trusted public transformation . 22
C.3.1 Example using 767-bit RSA and RIPEMD-160 . 22
C.3.1.1 Parameter selection . 22
C.3.1.2 Authentication exchange . 22
C.3.2 Example using 1024-bit RSA and SHA-1 22
...............
C.3.2.1 Parameter selection . 22
C.3.2.2 Authentication exchange .
D Comparison of the mechanisms . 24
D.l LMeasures for comparing the mechanisms . 24
D.2 Mechanism based on identities 24
............................
D.2.1 The case where v is large (e.g. the Guillou-Quisquater scheme) 24
D.2.1.1 Computational complexity .
D.2.1.2 Gommunication complexi ty . 25
14.2.1.3 Size of the claimant ’s accreditations . 25
D.2.1.4 Degree of security . 25
D.2.2 Fiat-Shamir scheme . 25
D.2.2.1 Computational complexity . 25
D.2 2.2 Gommunication complexi ty . 25
D.2.2.3 Size of the claimant ’s accreditations . 25
D.2.2.4 Degree of security . 25
D.3 Certificate-based mechanism using discrete logarithms . 26
D.3.1 Computational complexity . 26
D.3.2 Gommunication complexity 26
.........................
D.3.3 Size of the claimant ’s accreditations 26
...................
D.3.4 Degree of security . 26
D.4 Certificate-based mechanism using an asymmetric encipherment sys-
tem . 26
D.4.1 Computational complexity . 26
D.4.2 Gommunication complexity . 26
D.4.3 Size of the claimant ’s accreditations . 26
D.4.4 Degree of security . 26
D.5 Comparison of the mechanisms 26
............................
. . .
@ISO/IEC
ISO/IEC 9798-5 : 1999(E)
................................ 28
E Information about Patents
F Bibliography .
iv
@ISO/IEC ISO, ‘IEC 9798-5 : 1999(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the Interna-
tional 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 techni-
cal committee, ISO/IEC JTCI. 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.
International Standard ISO/IEC 9798-5 was prepared by Joint Technical Commit-
tee ISO/IEC JTC 1, Information technology, Sub-Committee SC27, IT Security
techniques.
ISO/IEC 9798 consists of the following Parts, under the general title Information
technology - Security techniques - Entity authentication:
- Part 1: General
~ Part 2: Mechanisms using symmetric encipherment algorithms
- Part 3: Mechanisms using digital signature techniques
- Part 4: Mechanisms using a cryptographic check function
- Part 5: Mechanisms using xero knowledge techniques
Annexes A, B, C, D, E, and F of this part of ISO/IEC 9798 are for information
only.
ISO and IEC draw attention to the fact that it is claimed that compliance with
this part of ISO/IEC 9798 may involve the use of Patents as given in Annex E.
ISO and IEC take no Position regarding the evidente, validity and scope of these
patent rights.
The holders of these patent rights have assured 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 hold-
ers of these patent rights are registered with ISO and IEC. Information may be
obtained from the addresses given in Annex E.
V
ISO/IEC 9798-5 : 1999(E) @ISO/IEC
Attention is drawn to the possibility that some of the elements of this part of
ISO/IEC 9798 may be the subject of patent rights other than those identified in
Annex E. ISO and IEC shall not be held responsible for identifying any or all such
patent rights.
vi
INTERNATIONAL STANDARD @ISO/IEC
ISO/IEC 9798-5 : 1999(E)
Information technology ~ Security techniques - Entity
aut hent icat ion - Part 5: Mechanisms using Zero knowledge
techniques
1 Scope ISO/IEC 9798-1, Information technology ~ Security tech-
niques ~ Entity authentication mechanisms - Part I: Gen-
eral.
This part of ISO/IEC 9798 specifies three entity authen-
tication mechanisms using zero knowledge techniques. All
ISO/IEC 10118 (all Parts), Information technology - Se-
the mechanisms specified in this part of ISO/IEC 9798 pro-
curity techniques - Ha.6functions,
vide unilateral authentication. These mechanisms are con-
structed using the principles of zero knowledge, but they
will not be zero knowledge according to the stritt definition
sketched in Annex A for all choices of Parameters.
3 Definitions
The first mechanism is said to be based on identities. A
For the purposes of this part of ISO/IEC 9798, the following
trusted accreditation authority provides each claimant with
defini tions apply.
private accreditation information, computed as a function
of the claimant ’s identification data and the accreditation
The following terms are defined in ISO/IEC 9798-1.
authority ’s private key.
3.1 asymmetric cryptographic technique:
The second mechanism is said to be certificate-based using
discrete logarithms. Every claimant possesses a public key,
private key pair for use in this mechanism. Every verifier
3.2 asymmetric encipherment System:
of a claimant ’s identity must possess a trusted copy of the
claimant ’s public verification key; the means by which this
is achieved is beyond the scope of this Standard, but it may
3.3 asymmetric key pair:
be achieved through the distribution of certificates signed by
a Trusted Third Party.
3.4 challenge:
The third mechanism is said to be certificate-based using an
asymmetric encipherment System. Every claimant possesses
3.5 claimant:
a public key, private key pair for an asymmetric cryptosys-
tem. Every verifier of a claimant ’s identity must possess
a trusted copy of the claimant ’s public key; the means by
3.6 decipherment:
which this is achieved is beyond the scope of this st,andard,
but it may be achieved through the distribution of certifi-
cates signed by a Trusted Third Party.
3.7
distinguishing identifier:
3.8 encipherment:
2 Normative references
The following normative documents contain provisions
3.9
entity authentication:
which, through reference in this text, constitute provisions
of this part of lSO/IEC 9798. For dated references, subse-
quent amendments to, or revisions of, any of these publica- 3.10 private key:
However, Parties to agreements based
tions do not apply.
on this International Standard are encouraged to investigate
3.11 public key:
the possibility of applying the most recent editions of the
normative documents indicated below. For undated refer-
ences, the latest edition of the normative document referred
3.12 public verification key:
Members of ISO and IEC maintain registers of
to applies.
currently valid International Standards.
3.13 random number:
ISO/IEC 9796: 1991, I n f ormation technology - Security
techniques -
Digital signature scheme giuing message re-
couery. 3.14
token:
@ISO/IEC
ISO/IEC 9798-5 : 1999(E)
3.25 private decipherment transformation: deci-
3.15 trusted third Party:
pherment transformation determined by an asymmetric en-
cipherment System and the private key of an asymmetric key
3.16 unilateral authentication: pair.
3.26 public accreditation verification exponent:
3.17 verifier:
value agreed by all members of a group of entities, and which,
in conjunction with the modulus, determines the value of the
private accredi tation exponent .
The following term is defined in ISO/IEC 10118-1.
3.27 public encipherment transformation:
enci-
3.18 hash-function: function which maps strings of bits
pherment transformation determined by an asymmetric en-
to fixed-length strings of bits, satisfying the following two
cipherment System and the public key of an asymmetric key
properties:
pair.
-_
it is computationally infeasible to find for a given out-
put an input which maps to this output;
3.28 redundant identity: sequence of data items ob-
tained from an entity ’s identification data by adding redun-
-
it is computationally infeasible to find for a given input dancy using techniques specified in ISO/IEC 97%.
a second input which maps to the same output.
3.29 response: data item sent by the claimant to the
verifier, and which the verifier tan process to help check the
In addition the following definitions are used.
identity of the claimant.
3.19 accreditation authority: entity trusted by all
3.30 witness: data item which provides evidente of the
members of a group of entities for the purposes of the gen-
claimant ’s identity to the verifier.
eration of private accreditation information.
4 Symbols and notation
3.20 accreditation multiplicity Parameter: positive
integer equal to the number of items of secret accreditation
For the purposes of this part of ISO/IEC 9798 the following
information provided to an entity by the accreditation au-
Symbols and notation described in ISO/IEC 9798-1 apply.
thority.
11 d ~ The distinguishing identifier of entity A.
3.21 exchange multiplicity Parameter: positive inte-
B - The distinguishing identifier of entity B.
ger used to determine how many times the exchange of entity
authentication messages shall be performed in one instance
The result of the concatenation of the data items
Y -
of the authentication mechanism.
IZ
Y and 2 in that Order.
3.22 identification data: sequence of data items, in- The following general Symbols and notation are used.
cluding the distinguishing identifier for an entity, assigned
to an entity and used to identify it. d - A challenge.
NOTE - Examples of data items which may be included in the
D -- A response.
identification data include: an account number, expiry date, serial
number, etc.
h -- A hash-function.
r-- A random number.
3.23 private accreditation exponent: value known
only to the accreditation authority, and which is used in the
x - The larges t integer which is not greater than the
1 1
production of claimants’ private accreditation information.
value x.
This value shall be kept secret. This value is related to the
public accreditation verification exponent.
mod - If i is an integer and n is a positive integer, then
i mod n denotes the unique integer j which satisfies
3.24 private accreditation information: private in-
a) O formation provided to a claimant by an accreditation author-
ity, and of which a claimant subsequently proves knowledge,
i - j is an integer mult,iple of n.
b)
thereby establishing the claimant ’s id.entity.

@ISO/IEC ISO/IEC 9798-5 : 1999(E)
In t,he identity-based me chanism 5, The Jacobi Symbol tan be computed
context of the of clause efficiently without
(44
knowledge of the pri me fac torisation of 72, see
the fol and notation are used. [6] and [8].
lowing Symbols
Entity A ’s private accreditation In the contex t of the d .iscrete logarithm based mechanism of
CAl,CA2,.,CArn ~
information. clause 6, the follo wmg Symbols and not ation are used.
gcd ~ The greatest common divisor of two integers, i.e. g - A positive integer which is the base of the discrete
gcd(a, b) represents the largest positive integer that is a logarithms.
divisor of both a and b.
A Prime number used as a modulus.
P-
The identification data of entity A.
IAl, IA2,. . . , IArn ~
IAz is the ith part of the identification data of entity A. A Prime number which is a factor of p - 1.
Q-
JA1 7 JAS, . . . > JAS -- The redundant identity of entity The public verification key for entity X.
Yx -
A. JAS is the ith part of the redundant identity of en-
tity A. The private authentication key for entity X.
xx -
k, - An integer determined by the modulus n, and In the context of the trusted public transformation based
mechanism of clause 7, the following Symbols and notation
which determines the maximum bit-length of the Parts
of an entity ’s redundant identity. are used.
lcm - The least common multiple of two integers, i.e. PX -- The public encipherment transformation for en-
lcm(a, b) represents the smallest positive integer that is a tity X.
rnultiple of both a and b.
The private decipherment transformation for en-
7-n -- The accredi .tation multiplicity Parameter.
n - A modulus equal to the product of the Prime num-
bers p and q.
5 Mechanism based on identities
A Prime number used to calculate the modulus.
P--
In this clause an entity authentication mechanism is
specified
which is based on the
use of identities.
A Prime number used to calculate the modulus.
eter.
t -- The exchange multiplici ty param
5.1 Specific requirements
su --- The accreditation authority ’s private accreditation
In Order to use the mechanism
within a group of entities, the
exponent.
fol lowing Steps
shall be taken.
The public accreditation verification exponent.
Every entity wishing to act as either a claimant or a
a>
verifier must have the means to generate ran .dom num bers.
W - A witness.
b) An accreditation authority shall be appointed for the
mod* ~ If i is an integer and n is a positive integer, then
group of entities. This accreditation authority shall be
i mod* n denotes the non-negative integer j equal to the
trusted by all members of the group for the purposes of
smaller of the two values: i mod n and n - i mod n. If
guaranteeing identities.
i and j are two integers and n is a positive integer then
i E j (rnod*n) if and only if i mod* n = j mod* n.
A number of Parameters shall be selected, which will
govern the Operation of the entity authentication mecha-
The Jacobi Symbol of the positive integer a with
(44 -
nism. The selected Parameters shall be made known in a
respect to the odd positive integer YL
reliable manner to all members of the group of entities.
NOTE - Let p be an odd Prime and let a be a positive integer.
The Legendre Symbol of a with respect to p, written (u]~), is
d) Every entity wishing to act as a claimant in the au-
defined by
thentication mechanism must be provided with identifica-
(P-1)/2 mod p
.
(alp) = 0,
tion data by some means.
In this context identification
When a is not a multiple of p, (alp) is either +l or -1, depending data is a string of bits of length limited by one of the
on whether or not a is equal to the Square of an integer modulo
Parameters selected in step (c), and which uniquely and
p. The Legendre Symbol of multiples of p with respect to a Prime
meaningfully identifies the entity according to an agreed
p 1s Zero.
convention.
Let n be an odd positive integer satisfying n = pq, where p and q
Every entity wishing to act as a claimant in the au-
e>
are primes, and let a be a positive integer. The Jacobi Symbol of
thentication mechanism shall be issued with private ac-
a with respect to n, written (aln), is defined by
creditation information by the selected accreditation au-
thority.
(44 = (4P>bld~
ISO/IEC 9798-5 : 1999(E) grso/IIX
5.3 Identity selection
f) If the version of the mechanism using a hash-function
is selected, all entities within the group must agree on
the use of a specific hash-function (for example one of the Esch entity wishing to act as a claimant in this mechanism
functions specified in ISO/IEC 10118). must be assigned identification data consisting of a sequence
of %? Parts: IAi, 1142,. . . , [Am. Esch part of the identification
data shall contain at most 8[(k, + 3)/16] bits.
5.2 Parameter selection
The entity authentication mechanism will provide assurance
The Parameters to be selected are as follows.
to the verifier that the claimant is the entity which has been
assigned this identification data.
a) The public accreditation verification exponent v. Cer-
tain values, such as 2, 3 and 216 + 1 = 65537, have some
NOTE 1 - This sequence of identification data Parts could, for
practical advantages.
example, be constructed by assigning an entity a Single identi-
fying string of bits, and appending the binary representations of
b) The modulus n. This positive integer shall be selected
the numbers 1,2,. . . , m in turn to this string to obtain the values
by the appointed accreditation authority. The value of
In such an approach, the binary representa-
~Alr1A2,~-,1Am~
n shall be equal to the product of two Prime numbers
tions of the numbers 1,2,. . . , ‘~2 could conveniently all be made of
p and q. The values of p and q shall be kept secret by the Same length, by prefixing with Zeros as necessary.
the accreditation authority. The Prime numbers p and
NOTE 2 ~ If the Parts of an entity ’s identification data are
q shall be Chosen in such a way that knowledge of their
longer than the maximum permissible length, then this tan be
product n shall not feasibly enable any entity to deduce
dealt with by applying a hash-function to the identification data
them, where feasibility is defined by the context of use of
Parts to obtain the values IAI,~A~, . . . , 1~~. Examples of hash-
the authentication mechanism.
functions tan be found in ISO/IEC 10118.
The values of p and q shall satisfy the following constraints:
NOTE 3 ~ Expiry of an entity ’s identification data tan be en-
forced by the inclusion of an expiry date in the identification data.
- if v is odd, then gcd(p - 1, v) = gcd(q - 1, v) = 1,
Revocation of an entity ’s identification data tan be sirnplified by
and
the inclusion of a serial number in the identification data.
- if v is even, then gcd((p - 1)/2, v) = gcd((q -
1, and p - q shall not be a multiple of 8.
1>/27 v) =
5.4 Accreditation generation
The choice of n determines the value of a further param-
To generate the private accreditation information for an en-
eter, which is denoted by Ic,, in the following way:
tity A, the accreditation authority shall compute a sequence
of m digital signatures CAl, CA2, . . . , (2~~. More specifically,
h = [log, (n>J .
for every i (1 < i < m), CA; shall be computed using the
- -
In other words, a binary representation of n shall contain
following procedure.
Jcs + 1 bits.
a) &2, the ith part of the ‘redundant identity’ for A,
The choice of n also determines the value of the accredi-
shall bae computed from IA;, the ith part of the iden-
tation authority ’s private accreditation exponent, denoted
tification data of A, by subjecting IAz to the first four
The value u shall be set to the
u, in the following way.
Steps of the signature process specified in ISO/IEC 9796,
least positive integer such that UV + 1 is a multiple of
( ‘Padding ’, ‘Extension ’, ‘Redundancy’ and ‘Truncation
and forcing ’), using the specified value of Ic,. The value
lcm(p- l,q- 1) if v is odd,
obtained from this process, denoted IR, shall then be used
lcm(p - 1, q - 1)/2 if v is even.
to derive JAi in the following way.
- If v is odd then JA; = IR.
c) The accreditation multiplicity Parameter m. This
positive integer shall be Chosen in conjunction with the
- If v is even and if (IRln) = +1 then JA; = IR.
public accreditation verification exponent v and the ex-
Change multiplicity t, and affects the level of security of
If v is even and if (IRln) = -1 then ,JA1 = IR/2.
~
the scheme.
The exchange multiplicity Parameter t.
This posi- b) CA~ shall be computed from JAi using the following
tive integer shall be Chosen in conjunction with the public
formula:
accreditation verification exponent v and the accredita-
CA; = (JAi)U mod*n.
tion multiplicity m, and affects the level of security of the
scheme.
The private accreditation information supplied to entity A
NOTE 1 - Guidance on the choice of Parameters for this mech- is equal to the computed signatures CA~, CA2,. . . , CAm.
anism is given in Annex B.
Observe that
NOTE 2 - When v = 2 the mechanism becomes the Fiat-Shamir
(CAi)VJAi E 1 (mod*n)
scheme, [3]. When v > 2, m = 1, and v is a Prime the mechanism
becomes the Guillou-Quisquater scheme, [5]. for every i (1 5 i < m).
@ISO/IEC ISO/IEC 9798-5 : 1999(E)
(2) A sends TokenA& to B. TokenA& shall be equal
5.5 Authentication exchange
to either W or h(WIIText).
This unilateral authentication mechanism involves the fol-
(3) Having received TokenABl, B shall choose at ran-
lowing exchanges of information between a claimant A and
dom a sequence of integers di, &, . . . , d,, where each value
a verifier B, and enables B to check the identity of A. It
d, shall lie in the range 0 to v - 1. This sequence of integers
is necessary for correct Operation of the mechanism that B
is ehe challenge.
is provided with the claimed identification data of A, either
appended to one of t,he information exchanges in the mech-
(4) B sends the challenge dl, dz,. . . ,d, to A.
anism or by some other means.
(5) On receipt of the challenge dl, dz,. . . , d,, A shall
One iteration of the authentication procedure is illustrated
compute the response D from the (secret) value r and
in figure 1. The bracketed numbers in the figure correspond
the private accreditation information CAl, (7~2,. . . , CAm
to the Steps of the exchange described in detail below.
as follows:
(2) TokenA&
D = rfi(C ’~i)~’ mod*n.
2= 1
A
(6) A sends TokenA& = D to B.
(7) On receipt of the response D, B shall perform the
(1)7 (5)
following computations.
(a) B Checks that 0 < D < n/2. If not then B shall
Figure 1 ~ Identity-based mechanism
reject A.
calculates
(b) B
The form of the first token (TokenA&), sent by the claimant
JA&AZ,. . . r JA-, the redundant identity of A, from
to the verifier is either:
the identification data 1~1, 1~2,. . . , IAm of A, using the
same process as specified in clause 5.4, step (a).
TokenA& = W
(c) B now computes the value W’ using the following
or
formula:
TokenA& = h(WIIText)
W’ = D” fi(J~;)~’ mod*n.
where W is the witness, h is a hash-function, and Text, is
an optional text field. This text field is available for use i=l
in applications outside the scope of this part of ISO/IEC
9798 (it may be empty). See annex A of ISO/IEC 9798-1
(d) If W was sent in the first exchange of the pro-
for information on the use of text fields. If this text field is
cedure then B Checks that the computed value W’ is
non-empty then B must have the means to recover the value
equal to the value of W sent in the first exchange of the
of the text field; this may require A to send all or part of the
procedure. Alternatively, if h( WI IText) was sent in the
text field with TokenABl (see also Note 1 below).
first exchange of the procedure then B first computes
h(W ’IIText) and th en Checks that h(W ’IIText) is equal
The form of the second token (TokenABs), sent by the
to the value of h( WI IText) sent in the first exchange of
claimant to the verifier is:
the procedure. If the check succeeds then this iteration
of the mechanism is successful. Otherwise B rejects A.
TokenA& = D
NOTE 1 - 0th er information may be sent with any of the ex-
U 1s ,he response.
where
changes of any of the iterations of the authentication procedure.
In particular note that information included within the identifica-
For each application of this mechanism the following authen- tion data of A may be sent with TokenABl in the first exchange
tication procedure shall be performed t times (where t is the of the first of the t iterations of the authentication procedure (Step
(2)). Such information might be used by B to help compute A ’s
exchange multiplicity Parameter). The verifier B shall only
redundant identity and/or the value of the optional Text field.
accept the claimant A as valid if all t iterations of the pro-
cedure complete successfully.
NOTE 2 ~ It is important that A chooses the random value r by
a process which guarantees that selected values are independent
(1) Entity A, who is equipped with private accreditation
within the lifetime of the accreditation information. If, for exam-
Information CA~, CA~, . . . , CAm, chooses a random num-
ple, the same value r is used twice, then a third Party may be able
ber r, subject to the restriction that r shall be an integer
to deduce part or all of the private accreditation information of
1. This integer is kept secret by A.
satisfying 1 < r < n -
- - A, and hence be able to impersonate A successfully.
,4 now computes the witness W as
NOTE 3 - The redundant identity JAS, JA2, . . . , JAS for A tan
be computed at any Stage by B, i.e. B need not wait until the
W = r’ mod*n.
ISO/IEC 9798-5 : 1999(E) @ISO/IEC
Every entity wishing to act as a verifier must be
receipt of the response D before computing JAS, JAS, . . . , JAS. Tf
e>
B verifies A frequently using this mechanism, then B may Cache equipped with a means to obta$in trusted copies of the
the values JAI, JAS, . . . , JAm.
public verification keys for the entities whose identities it
is to verify.
NOTE 4 - The t iterations of the procedure tan be performed
in parallel, i.e. in the first step A may choose t random numbers
NOTE - The exact means by which entities are provided with
rt, compute t witnesses Wl, Wz,. . . , M/t, send them si-
7-1,f2,.,
trusted copies of public verification keys is beyond the scope of
multaneously to B, and so on. If this ‘parallel implementation’ is
this Standard. This may, for example, be achieved by the use of
adopted, the total number of message exchanges will be equal to
public key certificates or by some other environment-dependent
three, regardless of the value of t.
means.
NOTE 5 - The use of h(WIIText) instead of W’ in the first
exchange of the procedure tan achieve efficiency gains by reducing
6.2 Key selection
the number of bits in TokenABl.
NOTE 6 - It is recommended that the private accreditation
Esch entity X wishing to act as a claimant in this mechanism
information used in this mechanism be used only for the purposes
must be equipped with an asymrnetric key pair (yx, zx),
of authentication, and should not be used for any other appiication
where xx (the private key) shall be an integer Chosen to
(e.g. generation of digital signatures). If this recommendation
satisfy 0 < xx < q. The corresponding public verification
is not followed then special care should be taken to prevent the
key yx shall be set equal to gzX mod p.
verifier using the claimant as a ‘signing oracle ’; this could, for
example, be achieved by requiring the challenge to be of a specially
NOTE _ Guidance on the choice of Parameters for this mecha-
Chosen form.
nism is given in Annex B.
6 Certificate-based mechanism using dis-
6.3 Authentication exchange
trete logarit hms
This unilateral authentication mechanism involves the fol-
In this clause an entity authentication mechanism is specified
lowing exchanges of information between a claimant A and
which uses discrete logarithms.
a verifier B, and enables B to check the identity of A.
NOTE - This mechanism is known as the Schnorr scheme, [lO].
The authentication mechanism is illustrated in fgure 2. The
bracketed numbers in the figure correspond to the Steps of
6.1 Specific requirements the exchange described in detail below.
In Order to use the mechanism within a group of entities, the
(2) TokenA BI
following Steps shall be taken.
Every entity wishing to act as either a claimant or a
a>
verifier must have the means to generate random numbers.
b) All entities within the group must agree on three pos-
The integer p must be Chosen
itive integers p, Q and g.
to be a Prime number. Further q must be Chosen to be a
Prime number which is also a factor of p - 1. Finally g
Figure 2 - Discrete logarithm based mechanism
must be Chosen to be an element of Order q modulo p, that
is g must satisfy:
The form of the first token (TokenABl ), sent by the claimant
(i) gq mod p = 1, and
to the verifier is either:
(ii) g # 1.
TokenABl = W
The values p and g should be Chosen so that, given an
arbitrary integer i (1 < i < q), finding an integer j (if one
or
exists) such that g3 mod p = i shall be computationally
TokenABl = h(WlIText)
infeasible.
where W is the witness, h is a hash-function, and Text is
an optional text field. This text field is available for use
c) All entities within the group must agree on the use of
a hash-function (for example one of the functions specified in applications outside the scope of this part of ISO/IEC
in ISO/IEC 10118). 9798 (it may be empty). See annex A of ISO/IEC 9798-1
for information on the use of text fields. If this Text field is
d) Every entity wishing to act as a claimant must be non-empty then B must have the means to recover the value
equipped with an asymmetric key pair, selected as de- of Text; this may require A to send all or part of the Text
scribed below. field with TokenABl (see also Note 1 below).
@ISO/IEC ISO/IEC 9798-5 : 1999(E)
care should be taken to prevent the verifier using the claimant as a
The form of the second token (TokenAB$ sent by the
‘signing oracle ’; this could, for example, be achieved by requiring
claimant to the verifier is:
the challenge to be of a specially Chosen form.
TokenAB2 = D
NOTE 4 - The use of h(WIIText) instead of W in the first
exchange of the procedure tan achieve efficiency gains by reducing
where D is the response.
the number of bits in TokenABl.
(1) Entity A c h ooses a random number T, subject to the
restriction that r shall be an integer satisfying I < r < q.
7 Certificate-based mechanism using an
This integer is kept secret by A. A now computes the
asymmetric encipherment System
witness W as
W = g’ mod p.
In this clause an entity authentication mechanism is specified
which uses an asymmetric encipherment System.
(2) A sends TokenABi to B. TokenABl shall be equal
to either W or h(WIIText).
NOTE - This mechanism is derived from the Brandt-Damgard-
Landrock-Pedersen scheme, [1,8].
(3) Having received TokenABi , B shall choose at ran-
dom an integer d (the ‘challenge ’), where d shall satisfy
7.1 Specific requirement s
O -
In Order to use the mechanism within a group of entities, the
B sends the challenge d to A.
(4)
following Steps shall be taken.
(5) On receipt of the challenge d, A shall compute the
Every entity wishing to act as a verifier must have the
response D from the (secret) vaiue r and A ’s private key (2)
means to generate random numbers.
ZA by:
D = r - dzA mod q.
b) All entities within the group must agree on the use
of two cryptographic functions: an asymmetric encip her-
(6) A sends TokenAB2 = D to B.
ment System, and a hash-function (for example one of the
functions specified in ISO/IEC 10118).
(7) On receipt of the response D, B shall perform the
following computations. Every entity wishing to act as a claimant must be
equipped with an asymmetric key pair for use with the
(a) B Checks that 0 < D < q. If not then B shall asymmetric encipherment System.
reject A.
d) Every entity wishing to act as a verifier must be
(b) B computes the value W’ using the following for- equipped with a means to obtain trusted copies of the
mula: public keys for the entities whose identities it is to verify.
T/T/’ = (yA)dgD mod p.
NOTE - The exact means by which entities are provided with
trusted copies of public keys is beyond the scope of this stan-
(c) If W was sent in the first exchange of the pro- dard. This may, for example, be achieved by the use of public key
certificates or by some other environment-dependent means.
cedure then B Checks that the computed value W’ is
equal to the value of W sent in the first exchange of
the procedure. Alternatively, if h( W 1 IText) was sent in
7.2 Authentication exchange
the first exchange of the procedure, then B computes
h(W ’IIText) and then Checks it is equal to the value of
This unilateral authentication mechanism involves the fol-
h( Wl IText) sent in the first exchange of the procedure.
lowing exchanges of information between a claimant A and
If h(WIIText) # h(W ’IIText) then the mechanism has
a verifier B, and enables B to check the identity of A.
failed and A shall be rejected. Otherwise B accepts A.
The authentication mechanism is illustrated in figure 3. The
NOTE 1 -- Other information may be sent with any of the ex-
bracketed numbers in the figure correspond to the Steps of
changes of any of the iterations of the authentication procedure.
the exchange described in detail below.
NOTE 2 - It is important that A chooses the random value r
The form of the token (TokenBA) sent by the verifier to the
by a process which guarantees that selected values are indepen-
dent within the lifetime of the accreditation information. If, for claimant is:
example, the same value r is used twice, then a third Party may
TokenBA = d
be able to deduce the private accreditation information of A, and
where d is the challenge. The form of the token (TokenAB)
hence be able to impersonate A successfully.
sent by the claimant to the verifier is:
NOTE 3 - It is recommended that the key pair used in this mech-
TokenAB = D
anisrn be used only for the purposes of authentication, and should
not be used for any other application (e.g. generation of digital
where D is the response.
signat ures) . lf this recommendation is not followed then special
ISO/IEC 9798-5 : 1999(E)
(2) TokenBA
A B
(4) TokenAB
*
(3) PL (5)
Figure 3 ~ Trusted public transformation based
mechanism
(1) Entit,y B c h ooses a random number r. This number
is kept secret by B. B next computes h(r). The random
number r shall be Chosen in such a way that fl Ih( r) lies
within the domain of P A, the public encipherment trans-
formation of A. B now computes the challenge d as
d = p& “llh(r)).
(2) B sends TokenBA = d to A.
(3) Having received TokenBA, A performs the following
computational Steps.
(a) A recovers the value r by calculating
#+) = SA(d),
where SA is the private decipherment transformation of
A.
(b) A recomputes h(r) from the recovered value of r,
and if this value is not equal to the value received from
TokenBA then A aborts the mechanism. If the com-
puted value of h( r ) is the same as the value recovered
from TokenBA then A sets D = r.
(4) A sends TokenA B = D to B.
(5) On receipt of TokenA B, B compares D with r. If
r # D then the mechanism has failed and A is rejected. If
r = D then B accepts A.
NOTE 1 - Other information may be sent with either of the
exchanges of this mechanism.
NOTE 2 - It is important that B chooses the random number
r by a process which guarantees that the probability of the same
number r being Chosen twice within the lifetime of the asymmetric
key pair of A is vanishingly small. If the same number r is used
twice, then a third Party who intercepts the response D on the
first occasion that it is sent, will be able to impersonate A to B by
replaying D as a response to B after B has sent the number r the
second time. However, re-use of a previously valid value of r will
only invalidate one particular instance of use of the mechanism.
NOTE 3 - It is recommended that the key pair used in this
mechanism be used only for the purposes of authentication, and
should not be used for any other application (e.g. encryption of
If this recommendation is not followed then special
messages).
care should be taken to prevent the verifier using the claimant
as a ‘decrypting oracle ’; this could, for example, be achieved by
requiring the hash-value h(r) to be of a special form.
@ISO/IEC ISO/IEC 9798-5 : 1999(E)
Annex A
(informative)
Principles of Zero knowledge mechanisms
I u
It is natura1 to ask: tan one design protocols for use of pri-
A.1 Introduction
vate information which communicate exactly the information
they are meant to communicate, and nothing more? Infor-
In the context of the use of asymmetric cryptographic tech-
mally, this is precisely the property that a Zero-knowledge
niques, a potential weakness of an authentication exchange
mechanism has. Consider for example a Situation where user
is that the verifier may abuse the mechanism to compro-
A is assigned a key pair for a asymmetric cryptographic sys-
mise the claimant ’s private key. When asymmetric cryptog-
tem (PA, SA), such that PA is public while SA is private
raphy is being used, the claimant uses the private key of his
to A. Then using a Zero-knowledge mechanism, A tan con-
asymmetric key pair to compute the response to a verifier ’s
vince B that A possesses the private key corresponding to
challenge. The verifier may then, by choosing the Cl-lallenge
PA, without revealing anything other than this fact. Since
wisely, gain information about the private key of the claimant
A is characterized as the only user with access to SA, this
that could not have been obtained just from knowledge of the
protocol tan be used for authentication. In this case, the
public key of the claimant.
Zero-knowledge property guarantees that B will learn noth-
ing that could help him to later falsely impersonate A.
This type of abuse of an exchange of cryptographic messages
is known as using the claimant as an ‘oracle ’, in that the
The Zero-knowledge property is achieved by designing a di-
claimant provides information about his private key at the
alogue which tan be simulated by the verifier alone. This
behest of the verifier. The idea behind a Zero-knowledge
intuitively proves that the verifier will learn nothing from
autlhentication mechanism is simply to remove this particular
the claimant in terms of properties of the claimant ’s private
potential threat by careful design of the messages. This is
key, which the verifier could not have obtained himself from
done by ensuring that the verifier cannot use the claimant
the corresponding public key. It also means that an observer
as an oracle.
to the exchange of messages making up the mechanism will
be unable to decide if the claimant really was involved, or
the exchange was simulated by the verifier.
A.2 The need for Zero-knowledge mechanisms
Zero-knowledge mechanisms by nature require the use of
asymmetric cryptographic techniques. Given the stritt defi-
In applications involving modern Computer networks, the
nition of a Zero-knowledge mechanism, it is actually not pos-
need for security Services such as user authentication, non-
sible to implement one. In fact, a much better description
repudiation, etc. is widely recognized and steadily growing.
of the mechanisms in this part of ISO/IEC 9798 would be:
In Order to be able to use such Services, it is necessary for
a user to have access to private information, specific to that ‘Secrecy-protecting mechanisms ’. However, the concept of
User. Examples are passwords, private keys to a digital sig- Zero-knowledge mechan
...