ISO/IEC 11770-4:2017/Amd 2:2021
(Amendment)Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets — Amendment 2: Leakage-resilient password-authenticated key agreement with additional stored secrets
Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets — Amendment 2: Leakage-resilient password-authenticated key agreement with additional stored secrets
Technologies de l'information — Techniques de sécurité — Gestion de clés — Partie 4: Mécanismes basés sur des secrets faibles — Amendement 2
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 11770-4
Second edition
2017-11
AMENDMENT 2
2021-02
Information technology — Security
techniques — Key management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 2: Leakage-resilient
password-authenticated key agreement
with additional stored secrets
Technologies de l'information — Techniques de sécurité — Gestion
de clés —
Partie 4: Mécanismes basés sur des secrets faibles
AMENDEMENT 2
Reference number
ISO/IEC 11770-4:2017/Amd.2:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
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) or the IEC
list of patent declarations received (see https:// patents .iec).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, SC 27,
Information security, cybersecurity and privacy protection.
A list of all parts in the ISO/IEC 11770 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
Information technology — Security techniques — Key
management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 2: Leakage-resilient password-authenticated key
agreement with additional stored secrets
Introduction
Insert new list item e) as follows:
e) Leakage-resilient password-authenticated key agreement with additional stored secrets:
Establish one or more shared secret keys between two entities A and B, where A has a weak secret
and a (possibly, insecure) stored secret that might be revealed to or altered by adversaries and B has
verification data derived from A’s weak secret and stored secret. In a leakage-resilient password-
authenticated key agreement with additional stored secrets mechanism, the shared secret keys are
the result of a data exchange between the two entities; the shared secret keys are established if,
and only if, the two entities have used the weak secret, the stored secret and the corresponding
verification data; and A, B and an adversary who has obtained and altered the stored secret are all
unable to predetermine the values of the shared secret keys.
NOTE 4 Here, “leakage-resilience” means security against either compromise of stored secrets held by client
A or compromise of verification data held by server B, but not both. This type of key agreement mechanism is
able to protect A’s weak secret from being discovered by B, as well as preventing an adversary from getting A’s
weak secret from B. Also, this type of key agreement mechanism prevents an adversary from performing online
dictionary attacks unless the adversary obtains A’s stored secret. In other words, an adversary who obtains A’s
stored secret is restricted to performing online dictionary attacks, and the security level in this case is the same
as that of the other mechanisms in this document. A typical application scenario would involve use between a
client (A) and a server (B), where a client user employs a portable device such as a smart phone, USB memory or
smart card to save the user’s stored secret, or where a client terminal shares a network-attached storage device
in an office environment.
Clause 2
Replace Clause 2 with the following:
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 10118 (all parts), Information technology — Security techniques — Hash-functions
ISO/IEC 29192-5, Information technology — Security techniques — Lightweight cryptography — Part 5:
Hash-functions
ISO/IEC 9797 (all parts), Information technology — Security techniques — Message Authentication
Codes (MACs)
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
ISO/IEC 29192-6, IT Security techniques — Lightweight cryptography — Part 6: Message Authentication
Codes (MACs)
ISO/IEC 11770-6, Information technology — Security techniques — Key management — Part 6: Key
derivation
ISO/IEC 18033-2, Information technology — Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers
ISO/IEC 19772, Information technology — Security techniques — Authenticated encryption
Clause 3
Insert new term 3.40 as follows:
3.40
Hamming weight
number of non-zero elements in a bit string
Clause 4
Replace definitions as follows:
H a collision-resistant hash-function taking an octet string as input and giving a bit
string as output. One of the hash-functions specified in ISO/IEC 10118 (all parts) or
ISO/IEC 29192-5 shall be used
h(x, L ) a collision-resistant hash-function taking an octet string x and an integer L as input
K K
and giving a bit string of length L (in bits) as output. One of the hash-functions spec-
K
ified in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5 shall be used
mac(k, m) a message authentication code (MAC) function taking a key k and a variable-length
message m as input and giving a fixed-length output. One of the MAC algorithms
specified in ISO/IEC 9797 (all parts) or ISO/IEC 29192-6 shall be used
G,G ,G points of order r on E over F(q), where the relative discrete logarithms of G,G ,G
a b a b
are unknown
g, g , g , g elements of multiplicative order r in F(q), where the relative discrete logarithms of
1 a b
g, g , g , g are unknown
1 a b
K a function for deriving a key from a secret value and a key derivation parameter. One
of the key derivation functions specified in ISO/IEC 11770-6 shall be used
Add the following definitions:
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
⊕
bit-wise exclusive-or operation on bit-strings of equal length
AE an authenticated encryption, (reversible) transformation of data by a cryptographic
algorithm to produce ciphertext that cannot be altered by an unauthorized entity
without detection, i.e. that provides data confidentiality, data integrity, and data or-
igin authentication. One of the authenticated encryption methods specified in ISO/
IEC 19772 shall be used
Clause 5
Replace the last sentence with the following:
It is also assumed that the entities are aware of a common hash-function H, one of the hash-
functions specified in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5.
Clause 9
Add new Clause 9 as follows:
9 Leakage-resilient password-authenticated key agreement with additional stored secrets
9.1 General
This clause specifies two mechanisms (LKAM1 and LKAM2) for leakage-resilient password-
authenticated key agreement with additional stored secrets. These mechanisms, specified in 9.2 and
9.3, require one of the two entities to possess verification data for a weak secret and a stored secret
known to the other entity.
The two mechanisms share the following initialization and key establishment processes.
Initialization process: The two entities involved agree to use a set of valid domain parameters, a set of
key derivation parameters and a set of functions, all of which may be publicly known. The two entities
also agree to use shared password-based information, i.e. one entity has a password-based weak secret
and a stored secret, and the other entity has the corresponding verification data.
NOTE In the initialization process, the two entities who only share password-based information can
establish a secure channel by performing the key establishment process. In the case of LKAM2, the server first
sends an RSA parameter n. Through the established secure channel, the two entities can register verification
data and stored secrets.
Key establishment process:
a) Generate and exchange key tokens. The two entities involved each randomly choose one or more
key token factors associated with the domain parameters, create the corresponding key tokens,
which may be associated with the password and the stored secret or verification data (a key token
associated with the password and the stored secret or verification data is called an “entangled key
token”), and then make the key tokens available to the other entity.
b) Check validity of key tokens. Depending on the operations for producing key tokens in step a), the two
entities involved each choose an appropriate method to validate the received key tokens based on
the domain parameters. If any validation fails, the entity involved shall output “invalid” and stop.
c) Derive shared secret keys. The two entities involved each apply certain secret value derivation
functions to their own key token factor, the other entity’s key tokens and/or shared verification
data to produce a shared secret value. Each entity further applies a key derivation function to the
shared secret value and the key derivation parameters, to derive one or more shared secret keys.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
d) Check key confirmation and update stored secrets. The two entities involved use the shared secret
keys established using the above steps to confirm their awareness of the keys to each other, and to
update their stored secrets. This step is mandatory.
9.2 Leakage-resilient key agreement mechanism 1 (LKAM1)
9.2.1 General
This mechanism is designed to achieve leakage-resilient password-authenticated key agreement with
additional stored secrets, and establishes one or more shared secret keys between entities A and B.
In the mechanism, A has a password-based octet string π and a stored secret s , and B has verification
i
data W corresponding to π and s . This mechanism provides unilateral explicit key authentication and,
i i
optionally, mutual key authentication.
This mechanism works in both the DL setting and the EC setting.
NOTE 1 In applications using leakage-resilient password-authenticated key agreement with additional stored
secrets, A can play the role of a client and B can play the role of a server.
[35]
NOTE 2 This mechanism is based on the work of Shin, Kobara and Imai .
9.2.2 Prior shared parameters
Key agreement between two entities A and B takes place in an environment consisting of the following
parameters:
— a set of valid domain parameters (either DL domain parameters or EC domain parameters) as
specified in Clause 5;
— a counter which stores the value of i (initially i = 1);
— the length L of a shared secret key K;
K
— a password-based octet string π and a stored secret s , which is an integer of L bits used by A;
i K
— a verification element derivation function J, used by A;
— a verification element W = J(π, s ), used by A and B;
i i
— a key token generation function D, used by A and B;
— an entangled key token generation function C, used by A;
— a key token check function T, used by A and B;
— two secret value derivation functions V and V , one for each entity;
A B
— a key derivation function K, used by A and B;
— one or more key derivation parameter octet strings {P , P , …}, where A and B shall agree to use the
1 2
same values.
9.2.3 Functions
9.2.3.1 Verification element derivation function J
The verification element derivation function J takes a password-based octet string π and a stored secret
s as input and produces an element of F(q), written J(π, s ), as output. Leakage-resilient key agreement
i i
mechanism 1 can be used with either of the following two functions J and J :
DL EC
— J is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including g and
b
q), a password-based octet string π and a stored secret s , J is defined as in Formula (40):
i DL
4 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
BS2I(H()π )+srmod
i
Js(,π )m= gqod (40)
DL ib
— J is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters
(including G ), a password-based octet string π and a stored secret s , J is defined as in Formula (41):
b i EC
J (π, s ) = [BS2I(H(π)) + s mod r] × G (41)
EC i i b
Function BS2I (Bit String to Integer conversion) is described in Annex A.
9.2.3.2 Key token generation function D
The key token generation function D takes an integer x from {1, …, r − 1} as input, and produces an
element written D(x) as output. Leakage-resilient key agreement mechanism 1 can be used with either
of the following two functions D and D :
DL EC
— D is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including g and
q) and an input x from {1, …, r − 1}, D is defined as in Formula (42):
DL
x
D (x) = g mod q (42)
DL
— D is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters
(including G) and an input x from {1, …, r − 1}, D is defined as in Formula (43):
EC
D (x) = [x] × G (43)
EC
9.2.3.3 Entangled key token generation function C
The entangled key token generation function C takes two inputs, an output W of function J and an output
i
X of function D, and produces an element written C(W , X) as output. Leakage-resilient key agreement
i
mechanism 1 can be used with either of the following C functions C and C :
DL EC
— C is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including q) and
two inputs, the output W of function J and the output X of function D, C is defined as follows:
i DL
— compute C (W , X) = W × X mod q;
DL i i
— if C (W , X) is 0, 1 or q − 1, output “invalid” and stop; otherwise, output C (W , X).
DL i DL i
— C is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters and
two inputs, the output W of function J and the output X of function D, C is defined as follows:
i EC
— compute C (W , X) = W + X;
EC i i
n
— if [2 ] × C (W , X) = 0 , output “invalid” and stop; otherwise output C (W , X).
EC i E EC i
9.2.3.4 Key token check function T
The key token check function T is the same as that defined in 6.2.3.3.
9.2.3.5 Secret value derivation functions V and V
A B
a) The secret value derivation function V takes two inputs, an integer x from {1, …, r − 1} and an
A
output Y of function D, and produces an element written V (x, Y) as output.
A
© ISO/IEC 2021 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
b) The secret value derivation function V takes three inputs, an integer y from {1, …, r − 1}, an output X′
B
of function C and an output W of function J, and produces an element written V (y, X′, W ) as output.
i B i
c) V and V satisfy the condition V (x, Y) = V (y, X′, W ).
A B A B i
Leakage-resilient key agreement mechanism 1 can be used with either of the following two functions
V and V , and either of the following two functions V and V :
ADL AEC BDL BEC
a) V is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
ADL
over the multiplicative group of F(q). Given the DL domain parameters (including q), an integer x
from {1, …, r − 1} and an integer Y from {2, …, q − 2}, V is defined in the following steps:
ADL
x
— compute V (x, Y) = Y mod q;
ADL
— output V (x, Y).
ADL
b) V is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
BDL
over the multiplicative group of F(q). Given the DL domain parameters (including q), an integer y
from {1, …, r − 1}, an integer X′ from {2, …, q − 2} and an integer W from {2, …, q − 2}, V is defined
i BDL
in the following steps:
y
— compute V (y, X′, W ) = (X′ / W ) mod q;
BDL i i
— output V (y, X′, W ).
BDL i
c) V is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
AEC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters, an
integer x from {1, …, r − 1} and a point Y(≠ 0 ) on E, V is defined in the following steps:
E AEC
— compute V (x, Y) = [x] × Y;
AEC
— output V (x, Y).
AEC
d) V is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
BEC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters,
an integer y from {1, …, r − 1}, a point X′(≠ 0 ) on E and a point W (≠ 0 ) on E, V is defined in the
E i E BEC
following steps:
— compute V (y, X′, W ) = [y] × (X′ − W );
BEC i i
— output V (y, X′, W ).
BEC i
9.2.3.6 Key derivation function K
The key derivation function K is the same as that defined in 6.2.3.6.
9.2.4 Initialization operation
In the initialization operation, A chooses an integer s randomly from {1, …, r − 1}, computes W = J(π, s ),
1 1 1
and then securely transfers W to B. While A has the password-based weak secret π and the stored secret
1
s (along with the counter i = 1), B has the corresponding verification data W and the counter i = 1.
1 1
NOTE Entity A can update the password-based weak secret by performing the initialization operation.
9.2.5 Key agreement operation
In the i-th (i ≥ 1) key agreement operation, this mechanism involves both A and B performing a
sequence of up to three steps, numbered A1 to A3 and B1 to B3 (for the steps to be followed by A and B,
respectively).
a) Entangled key token construction (A1)
A performs the following steps:
6 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
1) compute W = J(π, s ) as its verification element;
i i
2) choose an integer x randomly from {1, …, r − 1} as its key token factor;
3) compute X = D(x) as its key token, and X′ = C(W , X) as its entangled key token (if the output of
i
function C is “invalid”, go back to the above item to choose a different x value at random and try again);
4) make i and X′ available to B.
b) Key token construction (B1)
B performs the following steps:
1) receive i and X′ from A;
2) check the validity of i: if the received value of i is not the same as the value B has, output “invalid”
and stop; otherwise, continue;
3) check the validity of X′ using T(X′): if T(X′) = 0, output “invalid” and stop; otherwise, continue;
4) choose an integer y uniformly at random from the range {1, …, r − 1} as its key token factor;
5) compute Y = D(y) as its key token;
6) compute z = V (y, X′, W ) as an agreed secret value;
B i
7) compute o = H(I2OS(1)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
B X X X i X
8) make Y and o available to A.
B
c) Key confirmation (mandatory) and shared secret key derivation (A2)
A performs the following steps:
1) receive Y and o from B;
B
2) check the validity of Y using T(Y): if T(Y) = 0, output “invalid” and stop; otherwise, continue;
3) compute z = V (x, Y) as an agreed secret value;
A
4) compute o ′ = H(I2OS(1)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
B X X X i X
5) if o ≠ o ′, output “invalid” and stop; otherwise, continue;
B B
6) compute o = H(I2OS(2)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
A X X X i X
7) compute K = K(A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z), P , L ) as a
j X X X i X j K
shared secret key for each key derivation parameter P ( j = 1, 2, …);
j
8) make o available to B.
A
d) Key confirmation and shared secret key derivation (B2)
B performs the following steps:
1) receive o from A;
A
2) compute o ′ = H(I2OS(2)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
A X X X i X
3) if o ≠ o ′, output “invalid” and stop; otherwise, continue;
A A
4) compute K = K(A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z), P , L ) as a
j X X X i X j K
shared secret key for each key derivation parameter P ( j = 1, 2, …).
j
e) Update of stored secrets (A3 and B3)
© ISO/IEC 2021 – All rights reserved 7
---------------------- Page: 10 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
A performs the following step (A3):
1) compute s = s + BS2I(H(I2OS(3)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )||
(i+1) i X X X i
GE2OS (z))) mod r.
X
B performs the following step (B3):
1) compute u = BS2I(H(I2OS(3)||A||B||I2OS(i)||GE2OS (X′)|| GE2OS (Y)|| GE2OS (W )||
X X X i
GE2OS (z))) mod r;
X
u
2) compute W = W × (g ) mod q in the DL setting;
(i+1) i b
3) compute W = W + [u] × G in the EC setting;
(i+1) i b
4) check the validity of W using T(W ): if T(W ) = 0, output “invalid” and stop.
(i+1) (i+1) (i+1)
Entity A shall verify the entity B’s proof of knowledge of the agreed key before revealing any information
derived from the agreed key. Therefore, A2 shall be done before B2 if the latter is performed.
Functions BS2I (Bit String to Integer conversion), I2OS (Integer to Octet String conversion) and GE2OS
X
(Group Element to Octet String conversion) are described in Annex A where Annex A shall be referenced
for the details of the conversion functions.
Numerical examples can be found in D.1.
NOTE 1 A group element in this mechanism is a point on the curve E in the EC setting, or an integer in the
range {1, …, q – 1} in the DL setting.
NOTE 2 In this mechanism, X and Y can be computed before the key agreement operation.
NOTE 3 This mechanism can be extended to provide synchronization, randomized ID and security against
server compromise impersonation attacks in the same way as in Section 6 of Reference [36].
9.3 Leakage-resilient key agreement mechanism 2 (LKAM2)
9.3.1 General
This mechanism is designed to achieve leakage-resilient authenticated key agreement with password
and untrusted storage using the RSA public key cryptosystem and establishes one or more shared
secret keys between entities A and B with joint key control. In the mechanism, A remembers a password
(denoted by π when rendered as an octet string), and has, in an untrusted storage device that might be
modified or copied by adversaries to impersonate A or B or to reveal the agreed keys, the RSA parameter
n, a stored secret u where subscript j denotes a counter and a random pseudo identity A′ of A. B has
j
password verification data v corresponding to both π and u , a hash value A′′ of A′, and RSA private key
j j
parameters d, p, q and so on. These RSA private and public key parameters shall be generated using
ISO/IEC 18033-2:2006, 11.1, and the additional requirement and recommendations for e to be used in
this mechanism are explained in 9.3.3. This mechanism provides unilateral explicit key authentication,
and optionally mutual key authentication.
NOTE 1 In applications using leakage-resilient authenticated key agreement with password and untrusted
storage, A can play the role of a client and B can play the role of a server.
[36]
NOTE 2 This mechanism is based on the work of Shin, Kobara and Imai .
9.3.2 Prior shared parameters
Key agreement between two entities A and B takes place in an environment consisting of the following
parameters, in which L , e, H, mac, K, {P , P , .} are shared as system parameters among all or a subset
K 1 2
of the users of this mechanism:
— the length of a shared secret key L which must be a multiple of 8;
K
8 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
— a set of RSA public key parameters, namely a prime integer e and a composite number n generated
as specified in ISO/IEC 18033-2:2006, 11.1, where e is specialized for this mechanism as explained
in 9.3.3;
— a cryptographic collision-resistant hash-function H giving a 2L -bit output, that shall be chosen
K
from amongst the functions standardized in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5, being
truncated as necessary;
— a message authentication code generation function mac, that shall be chosen from amongst the
functions standardized in ISO/IEC 9797 (all parts) or ISO/IEC 29192-6;
— a counter which stores the value of j (initially j =1);
— a stored secret u and corresponding v = J(π, u ) where u is an octet string of random L bits and J is a
j j j j K
password verification element derivation function in 9.3.4.1. Both u and v are set in the initialization
j j
operation in 9.3.5, and then used by A and B, respectively;
— a pseudo identity A′ and a corresponding hash value A′′ = H(I2OS(0)||A′) of the entity A, where A′
j j j j
is an octet string of length L /8 whose constituent bits are generated uniformly at random. Both A′
K j
and A′′ are set in the initialization operation in 9.3.5 and used by A and B, respectively;
j
— a key derivation function K, that shall be chosen from amongst the functions standardized in
ISO/IEC 11770-6;
— one or more key derivation parameter octet strings {P , P , .}, where A and B shall agree to use the
1 2
same values.
9.3.3 Additional requirement and recommendations for RSA public key parameter e
The following requirements on the choice of the parameter e, additional to those specified in
ISO/IEC 18033-2:2006, 11.1, apply.
L
K
a) e shall be a prime and e ≥ 2 ;
b) the sum of the Hamming weight of the binary representation of e and the bit-length of e should be
as small as possible, subject to requirement a);
c) e should be as large as possible within b).
[36]
NOTE 1 Requirement a) ensures that the e-residue attack , which applies when an adversary can modify the
parameter n, is not feasible.
NOTE 2 Recommendation b) is intended to help minimize the computational cost for entity A.
NOTE 3 Recommendation c) is intended to make e-residue attacks as difficult as possible for a given
computational cost on A.
NOTE 4 Examples of choices for e satisfying requirement a)-c) are given in C.4.
9.3.4 Functions
9.3.4.1 Password verification element derivation function J
The password verification element derivation function J takes a password-based octet string π and a
random L -bit stored secret u as input, and produces as output an octet string password verification
K j
data v = H(I2OS(4)||π||A||B) ⊕ u .
j j
9.3.4.2 Key token generation function D
© ISO/IEC 2021 – All rights reserved 9
---------------------- Page: 12 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2021(E)
The key token generation function D takes password verification data v , RSA public parameters n, e and
j
integers x , x in {1, …, n − 1} as input, and produces as output Z = D(e, n, x , x , v ), an integer in the range
1 2 1 2 j
{0,
...
INTERNATIONAL ISO/IEC
STANDARD 11770-4
Second edition
2017-11
AMENDMENT 2
Information technology — Security
techniques — Key management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 2: Leakage-resilient
password-authenticated key agreement
with additional stored secrets
PROOF/ÉPREUVE
Reference number
ISO/IEC 11770-4:2017/Amd.2:2020(E)
©
ISO/IEC 2020
---------------------- Page: 1 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO/IEC 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
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) or the IEC
list of patent declarations received (see https:// patents .iec).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology, SC 27,
Information security, cybersecurity and privacy protection.
A list of all parts in the ISO/IEC 11770 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
Information technology — Security techniques — Key
management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 2: Leakage-resilient password-authenticated key
agreement with additional stored secrets
Introduction
Insert new list item e) as follows:
e) Leakage-resilient password-authenticated key agreement with additional stored secrets:
Establish one or more shared secret keys between two entities A and B, where A has a weak secret
and a (possibly, insecure) stored secret that might be revealed to or altered by adversaries and B has
verification data derived from A’s weak secret and stored secret. In a leakage-resilient password-
authenticated key agreement with additional stored secrets mechanism, the shared secret keys are
the result of a data exchange between the two entities; the shared secret keys are established if,
and only if, the two entities have used the weak secret, the stored secret and the corresponding
verification data; and A, B and an adversary who has obtained and altered the stored secret are all
unable to predetermine the values of the shared secret keys.
NOTE 4 Here, "leakage-resilience" means security against either compromise of stored secrets held by client
A or compromise of verification data held by server B, but not both. This type of key agreement mechanism is
able to protect A’s weak secret from being discovered by B, as well as preventing an adversary from getting A’s
weak secret from B. Also, this type of key agreement mechanism prevents an adversary from performing online
dictionary attacks unless the adversary obtains A’s stored secret. In other words, an adversary who obtains A’s
stored secret is restricted to performing online dictionary attacks, and the security level in this case is the same
as that of the other mechanisms in this document. A typical application scenario would involve use between a
client (A) and a server (B), where a client user employs a portable device such as a smart phone, USB memory or
smart card to save the user's stored secret, or where a client terminal shares a network-attached storage device
in an office environment.
Clause 2
Replace Clause 2 with the following:
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 10118 (all parts), Information technology — Security techniques — Hash-functions
ISO/IEC 29192-5, Information technology — Security techniques — Lightweight cryptography — Part 5:
Hash-functions
ISO/IEC 9797 (all parts), Information technology — Security techniques — Message Authentication
Codes (MACs)
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 4 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
ISO/IEC 29192-6, IT Security techniques — Lightweight cryptography — Part 6: Message Authentication
Codes (MACs)
ISO/IEC 11770-6, Information technology — Security techniques — Key management — Part 6: Key
derivation
ISO/IEC 18033-2, Information technology — Security techniques — Encryption algorithms — Part 2:
Asymmetric ciphers
ISO/IEC 19772, Information technology — Security techniques — Authenticated encryption
Clause 3
Insert new term 3.40 as follows:
3.40
Hamming weight
number of non-zero elements in a bit string
Clause 4
Replace definitions as follows:
H a collision-resistant hash-function taking an octet string as input and giving a bit
string as output. One of the hash-functions specified in ISO/IEC 10118 (all parts) or
ISO/IEC 29192-5 shall be used
h(x, L ) a collision-resistant hash-function taking an octet string x and an integer L as input
K K
and giving a bit string of length L (in bits) as output. One of the hash-functions spec-
K
ified in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5 shall be used
mac(k, m) a message authentication code (MAC) function taking a key k and a variable-length
message m as input and giving a fixed-length output. One of the MAC algorithms
specified in ISO/IEC 9797 (all parts) or ISO/IEC 29192-6 shall be used
G,G ,G points of order r on E over F(q), where the relative discrete logarithms of G,G ,G
a b a b
are unknown
g, g , g , g elements of multiplicative order r in F(q), where the relative discrete logarithms of
1 a b
g, g , g , g are unknown
1 a b
K a function for deriving a key from a secret value and a key derivation parameter. One
of the key derivation functions specified in ISO/IEC 11770-6 shall be used
Add the following definitions:
2 PROOF/ÉPREUVE © ISO/IEC 2020 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
⊕
bit-wise exclusive-or operation on bit-strings of equal length
AE an authenticated encryption, (reversible) transformation of data by a cryptographic
algorithm to produce ciphertext that cannot be altered by an unauthorized entity
without detection, i.e. that provides data confidentiality, data integrity, and data or-
igin authentication. One of the authenticated encryption methods specified in ISO/
IEC 19772 shall be used
Clause 5
Replace the last sentence with the following:
It is also assumed that the entities are aware of a common hash-function H, one of the hash-
functions specified in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5.
Clause 9
Add new Clause 9 as follows:
9 Leakage-resilient password-authenticated key agreement with additional stored secrets
9.1 General
This clause specifies two mechanisms (LKAM1 and LKAM2) for leakage-resilient password-
authenticated key agreement with additional stored secrets. These mechanisms, specified in 9.2 and
9.3, require one of the two entities to possess verification data for a weak secret and a stored secret
known to the other entity.
The two mechanisms share the following initialization and key establishment processes.
Initialization process: The two entities involved agree to use a set of valid domain parameters, a set of
key derivation parameters and a set of functions, all of which may be publicly known. The two entities
also agree to use shared password-based information, i.e. one entity has a password-based weak secret
and a stored secret, and the other entity has the corresponding verification data.
NOTE In the initialization process, the two entities who only share password-based information can
establish a secure channel by performing the key establishment process. In the case of LKAM2, the server first
sends an RSA parameter n. Through the established secure channel, the two entities can register verification
data and stored secrets.
Key establishment process:
a) Generate and exchange key tokens. The two entities involved each randomly choose one or more
key token factors associated with the domain parameters, create the corresponding key tokens,
which may be associated with the password and the stored secret or verification data (a key token
associated with the password and the stored secret or verification data is called an “entangled key
token”), and then make the key tokens available to the other entity.
b) Check validity of key tokens. Depending on the operations for producing key tokens in step a), the two
entities involved each choose an appropriate method to validate the received key tokens based on
the domain parameters. If any validation fails, the entity involved shall output “invalid” and stop.
c) Derive shared secret keys. The two entities involved each apply certain secret value derivation
functions to their own key token factor, the other entity's key tokens and/or shared verification
data to produce a shared secret value. Each entity further applies a key derivation function to the
shared secret value and the key derivation parameters, to derive one or more shared secret keys.
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 6 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
d) Check key confirmation and update stored secrets. The two entities involved use the shared secret
keys established using the above steps to confirm their awareness of the keys to each other, and to
update their stored secrets. This step is mandatory.
9.2 Leakage-resilient key agreement mechanism 1 (LKAM1)
9.2.1 General
This mechanism is designed to achieve leakage-resilient password-authenticated key agreement with
additional stored secrets, and establishes one or more shared secret keys between entities A and B.
In the mechanism, A has a password-based octet string π and a stored secret s , and B has verification
i
data W corresponding to π and s . This mechanism provides unilateral explicit key authentication and,
i i
optionally, mutual key authentication.
This mechanism works in both the DL setting and the EC setting.
NOTE 1 In applications using leakage-resilient password-authenticated key agreement with additional stored
secrets, A can play the role of a client and B can play the role of a server.
NOTE 2 This mechanism is based on the work of Shin, Kobara and Imai [35].
9.2.2 Prior shared parameters
Key agreement between two entities A and B takes place in an environment consisting of the following
parameters:
— a set of valid domain parameters (either DL domain parameters or EC domain parameters) as
specified in Clause 5;
— a counter which stores the value of i (initially i = 1);
— the length L of a shared secret key K;
K
— a password-based octet string π and a stored secret s , which is an integer of L bits used by A;
i K
— a verification element derivation function J, used by A;
— a verification element W = J(π, s ), used by A and B;
i i
— a key token generation function D, used by A and B;
— an entangled key token generation function C, used by A;
— a key token check function T, used by A and B;
— two secret value derivation functions V and V , one for each entity;
A B
— a key derivation function K, used by A and B;
— one or more key derivation parameter octet strings {P , P , …}, where A and B shall agree to use the
1 2
same values.
9.2.3 Functions
9.2.3.1 Verification element derivation function J
The verification element derivation function J takes a password-based octet string π and a stored secret
s as input and produces an element of F(q), written J(π, s ), as output. Leakage-resilient key agreement
i i
mechanism 1 can be used with either of the following two functions J and J :
DL EC
— J is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including g and
b
q), a password-based octet string π and a stored secret s , J is defined as in Formula (40):
i DL
4 PROOF/ÉPREUVE © ISO/IEC 2020 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
BS2I(H(π)) + s mod r
J (π, s ) = g mod q (40)
DL i b i
— J is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters
(including G ), a password-based octet string π and a stored secret s , J is defined as in Formula (41):
b i EC
J (π, s ) = [BS2I(H(π)) + s mod r] × G (41)
EC i i b
Function BS2I (Bit String to Integer conversion) is described in Annex A.
9.2.3.2 Key token generation function D
The key token generation function D takes an integer x from {1, …, r − 1} as input, and produces an
element written D(x) as output. Leakage-Resilient Key Agreement Mechanism 1 can be used with either
of the following two functions D and D :
DL EC
— D is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including g and
q) and an input x from {1, …, r − 1}, D is defined as in Formula (42):
DL
x
D (x) = g mod q (42)
DL
— D is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters
(including G) and an input x from {1, …, r − 1}, D is defined as in Formula (43):
EC
D (x) = [x] × G (43)
EC
9.2.3.3 Entangled key token generation function C
The entangled key token generation function C takes two inputs, an output W of function J and an output
i
X of function D, and produces an element written C(W , X) as output. Leakage-Resilient Key Agreement
i
Mechanism 1 can be used with either of the following C functions C and C :
DL EC
— C is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
DL
over the multiplicative group of elements of F(q). Given the DL domain parameters (including q) and
two inputs, the output W of function J and the output X of function D, C is defined as follows:
i DL
— compute C (W , X) = W × X mod q;
DL i i
— if C (W , X) is 0, 1 or q − 1, output “invalid” and stop; otherwise, output C (W , X).
DL i DL i
— C is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
EC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters and
two inputs, the output W of function J and the output X of function D, C is defined as follows:
i EC
— compute C (W , X) = W + X;
EC i i
n
— if [2 ] × C (W , X) = 0 , output “invalid” and stop; otherwise output C (W , X).
EC i E EC i
9.2.3.4 Key token check function T
The key token check function T is the same as that defined in 6.2.3.3.
9.2.3.5 Secret value derivation functions V and V
A B
a) The secret value derivation function V takes two inputs, an integer x from {1, …, r − 1} and an
A
output Y of function D, and produces an element written V (x, Y) as output.
A
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE 5
---------------------- Page: 8 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
b) The secret value derivation function V takes three inputs, an integer y from {1, …, r − 1}, an output X’
B
of function C and an output W of function J, and produces an element written V (y, X’, W ) as output.
i B i
c) V and V satisfy the condition V (x, Y) = V (y, X’, W ).
A B A B i
Leakage-resilient key agreement mechanism 1 can be used with either of the following two functions
V and V , and either of the following two functions V and V :
ADL AEC BDL BEC
a) V is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
ADL
over the multiplicative group of F(q). Given the DL domain parameters (including q), an integer x
from {1, …, r − 1} and an integer Y from {2, …, q − 2}, V is defined in the following steps:
ADL
x
— compute V (x, Y) = Y mod q;
ADL
— output V (x, Y).
ADL
b) V is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
BDL
over the multiplicative group of F(q). Given the DL domain parameters (including q), an integer y
from {1, …, r − 1}, an integer X’ from {2, …, q − 2} and an integer W from {2, …, q − 2}, V is defined
i BDL
in the following steps:
y
— compute V (y, X’, W ) = (X’ / W ) mod q;
BDL i i
— output V (y, X’, W ).
BDL i
c) V is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
AEC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters, an
integer x from {1, …, r − 1} and a point Y(≠ 0 ) on E, V is defined in the following steps:
E AEC
— compute V (x, Y) = [x] × Y;
AEC
— output V (x, Y).
AEC
d) V is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
BEC
over the additive group of elements in an elliptic curve of F(q). Given the EC domain parameters,
an integer y from {1, …, r − 1}, a point X’(≠ 0 ) on E and a point W (≠ 0 ) on E, V is defined in the
E i E BEC
following steps:
— compute V (y, X’, W ) = [y] × (X’ − W );
BEC i i
— output V (y, X’, W ).
BEC i
9.2.3.6 Key derivation function K
The key derivation function K is the same as that defined in 6.2.3.6.
9.2.4 Initialization operation
In the initialization operation, A chooses an integer s randomly from {1, …, r − 1}, computes W = J(π, s ),
1 1 1
and then securely transfers W to B. While A has the password-based weak secret π and the stored secret
1
s (along with the counter i = 1), B has the corresponding verification data W and the counter i = 1.
1 1
NOTE Entity A can update the password-based weak secret by performing the initialization operation.
9.2.5 Key agreement operation
In the i-th (i ≥ 1) key agreement operation, this mechanism involves both A and B performing a
sequence of up to three steps, numbered A1 to A3 and B1 to B3 (for the steps to be followed by A and B,
respectively).
a) Entangled key token construction (A1)
6 PROOF/ÉPREUVE © ISO/IEC 2020 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
A performs the following steps:
1) compute W = J(π, s ) as its verification element;
i i
2) choose an integer x randomly from {1, …, r − 1} as its key token factor;
3) compute X = D(x) as its key token, and X’ = C(W , X) as its entangled key token (if the output of function
i
C is “invalid”, go back to the above item to choose a different x value at random and try again);
4) make i and X’ available to B.
b) Key token construction (B1)
B performs the following steps:
1) receive i and X’ from A;
2) check the validity of i: if the received value of i is not the same as the value B has, output “invalid”
and stop; otherwise, continue;
3) check the validity of X’ using T(X’): if T(X’) = 0, output “invalid” and stop; otherwise, continue;
4) choose an integer y uniformly at random from the range {1, …, r − 1} as its key token factor;
5) compute Y = D(y) as its key token;
6) compute z = V (y, X’, W ) as an agreed secret value;
B i
7) compute o = H(I2OS(1)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
B X X X i X
8) make Y and o available to A.
B
c) Key confirmation (mandatory) and shared secret key derivation (A2)
A performs the following steps:
1) receive Y and o from B;
B
2) check the validity of Y using T(Y): if T(Y) = 0, output “invalid” and stop; otherwise, continue;
3) compute z = V (x, Y) as an agreed secret value;
A
4) compute o ’ = H(I2OS(1)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
B X X X i X
5) if o ≠ o ’, output “invalid” and stop; otherwise, continue;
B B
6) compute o = H(I2OS(2)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
A X X X i X
7) compute K = K(A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z), P , L ) as a shared
j X X X i X j K
secret key for each key derivation parameter P ( j = 1, 2, …);
j
8) make o available to B.
A
d) Key confirmation and shared secret key derivation (B2)
B performs the following steps:
1) receive o from A;
A
2) compute o ’ = H(I2OS(2)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z));
A X X X i X
3) if o ≠ o ’, output “invalid” and stop; otherwise, continue;
A A
4) compute K = K(A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z), P , L ) as a shared
j X X X i X j K
secret key for each key derivation parameter P ( j = 1, 2, …).
j
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE 7
---------------------- Page: 10 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
e) Update of stored secrets (A3 and B3)
A performs the following step (A3):
1) compute s = s + BS2I(H(I2OS(3)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )||
(i+1) i X X X i
GE2OS (z))) mod r.
X
B performs the following step (B3):
1) compute u = BS2I(H(I2OS(3)||A||B||I2OS(i)||GE2OS (X’)|| GE2OS (Y)|| GE2OS (W )|| GE2OS (z)))
X X X i X
mod r;
u
2) compute W = W × (g ) mod q in the DL setting;
(i+1) i b
3) compute W = W + [u] × G in the EC setting;
(i+1) i b
4) check the validity of W using T(W ): if T(W ) = 0, output “invalid” and stop.
(i+1) (i+1) (i+1)
Entity A shall verify the entity B's proof of knowledge of the agreed key before revealing any information
derived from the agreed key. Therefore, A2 shall be done before B2 if the latter is performed.
Functions BS2I (Bit String to Integer conversion), I2OS (Integer to Octet String conversion) and GE2OS
X
(Group Element to Octet String conversion) are described in Annex A where Annex A shall be referenced
for the details of the conversion functions.
Numerical examples can be found in Annex D.1.
NOTE 1 A group element in this mechanism is a point on the curve E in the EC setting, or an integer in the
range {1, …, q – 1} in the DL setting.
NOTE 2 In this mechanism, X and Y can be computed before the key agreement operation.
NOTE 3 This mechanism can be extended to provide synchronization, randomized ID and security against
server compromise impersonation attacks in the same way as in Section 6 of Reference [36].
9.3 Leakage-resilient key agreement mechanism 2 (LKAM2)
9.3.1 General
This mechanism is designed to achieve leakage-resilient authenticated key agreement with password
and untrusted storage using the RSA public key cryptosystem and establishes one or more shared
secret keys between entities A and B with joint key control. In the mechanism, A remembers a password
(denoted byπ when rendered as an octet string), and has, in an untrusted storage device that might be
modified or copied by adversaries to impersonate A or B or to reveal the agreed keys, the RSA parameter
n, a stored secret u where subscript j denotes a counter and a random pseudo identity A' of A. B has
j
password verification data v corresponding to both π and u , a hash value A'' of A', and RSA private key
j j
parameters d, p, q and so on. These RSA private and public key parameters shall be generated using
ISO/IEC 18033-2:2006, 11.1, and the additional requirement and recommendations for e to be used in
this mechanism are explained in 9.3.3. This mechanism provides unilateral explicit key authentication,
and optionally mutual key authentication.
NOTE 1 In applications using leakage-resilient authenticated key agreement with password and untrusted
storage, A can play the role of a client and B can play the role of a server.
NOTE 2 This mechanism is based on the work of Shin, Kobara and Imai [36].
9.3.2 Prior shared parameters
Key agreement between two entities A and B takes place in an environment consisting of the following
parameters, in which L , e, H, mac, K, {P , P , .} are shared as system parameters among all or a subset
K 1 2
of the users of this mechanism:
— the length of a shared secret key L which must be a multiple of 8;
K
8 PROOF/ÉPREUVE © ISO/IEC 2020 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
— a set of RSA public key parameters, namely a prime integer e and a composite number n generated
as specified in ISO/IEC 18033-2:2006, 11.1, where e is specialized for this mechanism as explained
in 9.3.3;
— a cryptographic collision-resistant hash-function H giving a 2L -bit output, that shall be chosen
K
from amongst the functions standardized in ISO/IEC 10118 (all parts) or ISO/IEC 29192-5, being
truncated as necessary;
— a message authentication code generation function mac, that shall be chosen from amongst the
functions standardized in ISO/IEC 9797 (all parts) or ISO/IEC 29192-6;
— a counter which stores the value of j (initially j =1);
— a stored secret u and corresponding v = J(π,u ) where u is an octet string of random L bits and J is a
j j j j K
password verification element derivation function in 9.3.4.1. Both u and v are set in the initialization
j j
operation in 9.3.5, and then used by A and B, respectively;
— a pseudo identity A' and a corresponding hash value A'' = H(I2OS(0)||A' ) of the entity A, where A'
j j j j
is an octet string of length L /8 whose constituent bits are generated uniformly at random. Both A'
K j
and A'' are set in the initialization operation in 9.3.5 and used by A and B, respectively;
j
— a key derivation function K, that shall be chosen from amongst the functions standardized in
ISO/IEC 11770-6;
— one or more key derivation parameter octet strings {P , P , .}, where A and B shall agree to use the
1 2
same values.
9.3.3 Additional requirement and recommendations for RSA public key parameter e
The following requirements on the choice of the parameter e, additional to those specified in
ISO/IEC 18033-2:2006, 11.1, apply.
L
K
a) e shall be a prime and e ≥ 2 ;
b) the sum of the Hamming weight of the binary representation of e and the bitlength of e should be as
small as possible, subject to requirement a);
c) e should be as large as possible within b).
NOTE 1 Requirement a) ensures that the e-residue attack [36], which applies when an adversary can modify
the parameter n, is not feasible.
NOTE 2 Requirement b) is intended to help minimize the computational cost for entity A.
NOTE 3 Requirement c) is intended to make e-residue attacks as difficult as possible for a given computational
cost on A.
NOTE 4 Examples of choices for e satisfying requirement a)-c) are given in C.4.
9.3.4 Functions
9.3.4.1 Password verification element derivation function J
The password verification element derivation function J takes a password-based octet string π and a
random L -bit stored secret u as input, and produces as output an octet string password verification
K j
data v = H(I2OS(4)||π||A||B) ⊕ u .
j j
9.3.4.2 Key token generation function D
© ISO/IEC 2020 – All rights reserved PROOF/ÉPREUVE 9
---------------------- Page: 12 ----------------------
ISO/IEC 11770-4:2017/Amd.2:2020(E)
The key token generation function D takes password verification data v , RSA public parameters n, e and
j
integers x , x in {1, …, n − 1} as input, and produces as output Z = D(e, n, x , x , v ), an integer in the range
1 2 1 2 j
{0, …, n − 2}. D is calculated as follows:
e
—
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.