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
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
ISO/IEC 11770-4:2017/Amd.2:2021(E)
© 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
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
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
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
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
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
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
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
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
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
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
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
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, …, n − 2}. D is calculated as follows:
e
— compute y = (x ) mod n;
1 1
— compute W = BS2I(H(I2OS(7)||v ||I2OS(x )));
j 2
— compute Z = ((y − 1) + W) mod (n − 1);
— output Z.
9.3.4.3 Password-entangled key token generation function C
The password-entangled key token generation function C takes, as input, password verification data v ,
j
an integer Z in {1, …, n − 2}, integers y , d, p, q in {1, …, n − 1} respectively, and produces an integer x i n
2 1
{1, …, n − 1} as the output of C(v , Z, y , d, p, q). C is calculated as follows:
j 2
d
— compute x = (y ) mod n;
2 2
— compute W = BS2I(H(I2OS(7)||v || I2OS(x )));
j 2
— compute y = ((Z − W) mod (n − 1)) + 1;
d
— compute x = (y ) mod n;
1 1
— output x .
d [38]
NOTE y mod n can be calculated efficiently using p and q and Garner’s algorithm with ((((x − x )/q) mod
p q
(d mod (p − 1)) (d mod (q − 1))
p)q) + x where x = y mod p and x = y mod q.
q p q
9.3.4.4 Key derivation function K
The key derivation function K is the same as that defined in 6.2.3.6.
9.3.5 Initialization operation
In the initialization operation, A securely transfers the hash value A′′ associated with the pseudo
identity and the password verification element v to B, and B securely transfers the RSA public key
parameters e and n to A. While A has the password π, the pseudo identity A′ and the stored secret
u , B has the corresponding password verification data v , the hash value A′′ and the RSA private key
1 1 1
parameters d, p, q and so on.
NOTE Entity A can update the password-based weak secret by performing the initialization operation.
9.3.6 Key agreement operation
This mechanism (for j ≥ 1) involves A and B performing sequences of steps numbered A1 to A6 and B1 to
B5 (for the steps to be followed by A and B, respectively). Steps A4 and B3 and later are optional.
a) Key token construction (A1)
A performs the following steps:
1) choose two integers x and x randomly from {1, …, n – 1} as its key token factor;
1 2
e
2) compute v = J(π, u ), y = (x ) mod n and Z = D(e, n, x , x , v ) as its key token;
j j 2 2 1 2 j
3) make A′ , Z and y available to B.
j 2
b) Shared secret key derivation (B1)
B performs the following steps:
1) receive A′ , Z and y from A;
j 2
10 © ISO/IEC 2021 – All rights reserved
ISO/IEC 11770-4:2017/Amd.2:2021(E)
2) compute A′′ = H(I2OS(0)|| A′ );
j j
3) look for an entry corresponding to A′′ in the server’s database; if it does not exist, output
j
“invalid” and stop; otherwise, continue;
4) delete other entries for A that do not match with A′′ since they are garbage when communication
j
is cut in the middle of the sequence;
5) choose an L -bit random string r , and then make r available to A;
K 1 1
6) compute x = C(v , Z, y , d, p, q);
1 j 2
7) compute K = H(I2OS(1)||I2OS(x )||A||B||A′ ||r ||I2OS(Z)||v ||I2OS(y ));
s 1 j 1 j 2
8) compute K = K(K , I2OS(11), L ) as a shared secret key for the following communication;
i s K
9) compute K = K(K , I2OS(10), L ) as the MAC key if the key confirmation below completes
m s K
successfully.
c) Shared secret key derivation (A2)
A performs the following steps:
1) compute K = H(I2OS(1)||I2OS(x )||A||B||A′ ||r ||I2OS(Z)||v ||I2OS(y ));
s 1 j 1 j 2
2) compute K = K(K , I2OS(11), L ) as a shared secret key for the following communication;
i s K
3) compute K = K(K , I2OS(10), L ) as the MAC key if the key confirmation steps in d) below
m s K
complete successfully.
d) Key confirmation (B2 and A3) (mandatory)
B performs the following steps (B2):
1) compute o = mac(K , I2OS(2)||K ||I2OS(1));
B m s
2) make o available to A.
B
A performs the following steps (A3):
1) receive o from B;
B
2) compute o ′ = mac(K , I2OS(2)||K ||I2OS(1));
B m s
3) if o ≠ o ′, output “invalid” and stop.
B B
e) Key confirmation (A4 and B3) (optional)
A performs the following steps (A4):
1) compute o = mac(K , I2OS(2)||K ||I2OS(0));
A m s
2) make o available to B.
A
B performs the following steps (B3):
1) receive o from A;
A
2) compute o ′ = mac(K , I2OS(2)||K ||I2OS(0));
A m s
3) if o ≠ o ′, output “invalid” and stop.
A A
f) Storage update (A5, B4, A6 and B5) (optional)
A performs the following steps (A5):
© ISO/IEC 2021 – All rights reserved 11
ISO/IEC 11770-4:2017/Amd.2:2021(E)
1) choose an L -bit random string A′ , and then compute A′′ = H(I2OS(0)||A′ );
K j+1 j+1 j+1
2) make AE(K , A′′ ) available to B where AE(K , *) is a symmetric authenticated encryption
i j+1 i
function using K as the symmetric key.
i
B performs the following steps (B4):
1) receive AE(K , A′′ ) from A, and then extract A′′ from it;
i j+1 j+1
2) compute v = v ⊕ H(I2OS(2)||K );
j+1 j s
3) add {A′′ , v , A} to the server’s database;
j+1 j+1
4) make AE(K , reply1) available to A where reply1 is a reply message.
i
A performs the following steps (A6):
1) receive AE(K , reply1) from B;
i
2) if the result of decrypting AE(K , reply1) is not the same as reply1, output “invalid” and stop;
i
3) compute u = u ⊕ H(I2OS(2)||K );
j+1 j s
4) update {B, A′ , u } to {B, A′ , u };
j j j+1 j+1
5) make AE(K , reply2) available to B where reply2 is a reply message.
i
B performs the following steps (B5):
1) receive AE(K , reply2) from A;
i
2) if the result of decrypting AE(K , reply2) is not the same as reply2, output “invalid” and stop;
i
3) delete all A’s records {*, *, A} except {A′′ , v , A} from the server’s database. The deleted
j+1 j+1
records include old records {A′′ , v , A} and those that might remain as a result of communication
j j
errors between A and B.
Numerical examples can be found in Annex D.2.
NOTE 1 r can be removed if it is acceptable for K to be a function only of inputs from A, and joint key control
1 i
property is not required.
NOTE 2 x can be removed and e can be 3 if n is stored in a location in which adversaries cannot modify it even
if they can copy it.
NOTE 3 A′ can be replaced with A if anonymity of A against eavesdroppers is not required.
NOTE 4 The octet string of A can be the concatenation of an octet string identifying the user and an octet
string identifying the storage or the client terminal.
NOTE 5 After the key agreement, the RSA parameters can be updated by sending a new value of n from B to A
encrypted using AE().
NOTE 6 This mechanism can be extended to provide security against server compromise impersonation
attacks as in Section 6 of Reference [36].
Annex B
Add the following before -- Balanced Key Agreement Mechanism 1 –-:
id-km-ws-lKAM-1 OID ::= { id-km-ws leakageResilientKeyAgreementMechanism-1(9) }
id-km-ws-lKAM-2 OID ::= { id-km-ws leakageResilientKeyAgreementMechanism-2(10) }
12 © ISO/IEC 2021 – All rights reserved
ISO/IEC 11770-4:2017/Amd.2:2021(E)
Annex B
Add the following before END -- KeyManagement-WeakSecrets –-:
-- Leakage-Resilient Key Agreement Mechanism 1 --
verificationElementDerivation-9 OID ::= {
id-km-ws-lKAM-1 verificationElementDerivationFunction(1) }
keyTokenGeneration-9 OID ::= {
id-km-ws-lKAM-1 keyTokenGenerationFunction(2) }
entangledKeyTokenGeneration-9 OID ::= {
id-km-ws-lKAM-1 entangledKeyTokenGenerationFunction(3) }
keyTokenCheck-9 OID ::= {
id-km-ws-lKAM-1 keyTokenCheckFunction(4) }
secretValueDerivation-9 OID ::= {
id-km-ws-lKAM-1 secretValueDerivationFunction(5) }
keyDerivation-9 OID ::= {
id-km-ws-lKAM-1 keyDerivationFunction(6) }
-- Leakage-Resilient Key Agreement Mechanism 2 --
passwordVerificationElementDerivation-10 OID ::= {
id-km-ws-lKAM-2 passwordVerificationElementDerivationFunction(1) }
keyTokenGeneration-10 OID ::= {
id-km-ws-lKAM-2 keyTokenGenerationFunction(2) }
passwordEntangledKeyTokenGeneration-10 OID ::= {
id-km-ws-lKAM-2 passwordEntangledKeyTokenGenerationFunction(3) }
keyDerivation-10 OID ::= {
id-km-ws-lKAM-2 keyDerivationFunction(4) }
Annex C
Add new Clause C.4 as follows:
C.4 Parameters in leakage-resilient key agreement mechanism 2 (LKAM2)
Examples of the parameter e chosen to meet requirements a)-c) of 9.3.3 are as follows for L =112, 128,
K
192, 224 and 256, respectively:
113 90
e=2 +2 +1=020000040000000000000000000001 for L =112,
K
129 127
e=2 +2 +1=0280000000000000000000000000000001 for L =128,
K
193 132
e=2 +2 +1=02000000000000001000000000000000000000000000000001 for L =192,
K
225 182
e=2 +2 +1=0200000000004000000000000000000000000000000000000000000001 for L =224,
K
257 132
e=2 +2 +1=020000000000000000000000000000001000000000000000000000000000000001
for L = 256.
K
Annex D
Add new Annex D as follows:
© ISO/IEC 2021 – All rights reserved 13
ISO/IEC 11770-4:2017/Amd.2:2021(E)
Annex D
(informative)
Numerical examples
D.1 Numerical examples of LKAM1
This clause lists numerical examples of leakage-resilient key agreement mechanism 1 (LKAM1) with
[37]
elliptic curve domain parameters.
secp224r1 (SHA224), L = 112, HMAC
K
A (= l r p a k eu s er1@ a i s t . g o . jp) = 6C7270616B65757365723140616973742E676F2E6A70
B (= l r p a k e s er ver @ a i s t . g o . jp) = 6C7270616B6573657276657240616973742E676F2E6A70
password (= zokang1) = 7A6F6B616E6731
H(π) (= SHA512(I2OS(0)||A||B||password)) = 64C0F6239CCA16866612D8E1115B5ADA038D88B2A1376CC24E
3B54F308DCBF18256A008ED70342EB5F32BAB141717BEB59B46EAE36D8E50EBA514287CFA66DDB
G = 038C9C85F629134BEED14A1665662BBFC7F517BDFE070C1E470D2BD921
b
s = 77A29359EA58A369D5F49519334A91C82E2D04A7BA97D56B4B28F9E5
W = 033440F4772CD2AA5BB8452DEA433A3308CE6CE8448148135F6E44DD1E
x = B7F03B2A8293504BCBE4D10593216B46E0FE3EC3DFA0474E041FE99E
X = 020BBDFA70DD45BC4C547E76CE7FF03B4AB32ADA12A52637F82F910D0C
X′ = 039C4956146DF34530CB82503A0925497761402B7722C71F26C0B0D4FC
y = 915186FF1942FCC764FEA417CD728909F5C29419E59273BFC5EBE02A
Y = 034E5F87BEE7955E0AFF018DA0D77A12FFFB6C4B130E95602821252304
z = 020A386B68808E33B6DE6A5DF9AF8FA29D4765128CCC2D5E76D6C2FBF7
K (= HMAC(A||B||…, P (= 1), L ) = B4989CC5943D6C8A1F8EF04866F43B6B89A70959681DC8A13C0AB494
1 1 K
o = E26DC0043AA90EBDF33CF4C5B1B1860348D56D2226D0383ED62B56C9
B
o = D2F7F179F71D62B9DA5033A5F1096F4EA75E5E24AA6D0A432EE8DD0A
A
s = 05F627B8FA25380326AD512536BA467C8C5B989D4A7B7CE2A163F802
W = 02AF9DFB335866BF68D391FBF0F791D195D2EBE6A0FB07AE514E483298
secp256r1 (SHA256), L = 128, HMAC
K
A (= l r p a k eu s er1@ a i s t . g o . jp) = 6C7270616B65757365723140616973742E676F2E6A70
B (= l r p a k e s er ver @ a i s t . g o . jp) = 6C7270616B6573657276657240616973742E676F2E6A70
H(π) (= SHA512(I2OS(0)||A||B||password)) = 64C0F6239CCA16866612D8E1115B5ADA038D88B2A1376CC24E
3B54F308DCBF18256A008ED70342EB5F32BAB141717BEB59B46EAE36D8E50EBA514287CFA66DDB
G = 03836362FFB02357EFF24F4881D96618B2128F55791A445D67E301A5A67B57146B
b
s = 08B637BA75234719211718326BE28CB3C45EF4EA366DEEBAD2A1738D6A77E327
W = 03EDA13583FB00976FA641B29F1DA37D95EC4E38328A3E645A522637C635F7AFB7
x = 36B80344B46ACC4185A40A740D8008C47BCF6F5C183787DD3E8CFF1CA38A26EC
X = 025460E3BA90D478232E64786C016CDC1CA31B67F9C876CBFF5E59CAD80F417896
X′ = 02CA2646F82997E01610F25B2BA8858557A193FEF31C4360DBE81537C96D4ECA03
14 © ISO/IEC 2021 – All rights reserved
ISO/IEC 11770-4:2017/Amd.2:2021(E)
y = 78574F0E3861B458291DF3D3935624E873FF9AB8FECD7FB731E8E4E28312C53A
Y = 02A509BBD2DCA18C790960A7D6A616A29E9361C5B3E8EDCD5474EDDC03F4FF680A
z = 02903FB52457300DC360EE8E29E35C8E2AF029EE2E552F9AC79C7D7414A09BFDAF
K = 642B8E2BAF69CE15311D89111403F530239D324B597998C2E6468F153545BF68
o = EA9C1114DA052C9946016F3E13E5071F687C0F397FCE48395EB417854F13FA43
B
o = 7E44AC7A41F74B739B4119288C00117C4EF697E38E4B4CF9CCA75AF48A220633
A
s = 8674A52EC629B2DB1CA283E9F3C1BAB79A060CA25F8FCB3EFC940EC3A5A6DEF9
W = 02ECCBC141C0BD5663378F7F71DD846ADDD11DFEE0160DB8863583680A014A21E7
secp384r1 (SHA384), L = 192, HMAC
K
A (= l r p a k eu s er1@ a i s t . g o . jp) = 6C7270616B65757365723140616973742E676F2E6A70
B (= l r p a k e s er ver @ a i s t . g o . jp) = 6C7270616B6573657276657240616973742E676F2E6A70
H(π) (= SHA512(I2OS(0)||A||B||password)) = 64C0F6239CCA16866612D8E1115B5ADA038D88B2A1376CC24E
3B54F308DCBF18256A008ED70342EB5F32BAB141717BEB59B46EAE36D8E50EBA514287CFA66DDB
G = 032795D71E027B79FBD173E29AFEC1FEA012EA8E949261351B1B55A057BA2AEB486DAE7864567E2954551
b
02A36E80FFABC
s = 172728FF24A8DACA76CB35CD452A5B2965566765284188B170432CB308087F694BA5BE9096646BD841A38
CDBF303BA36
W = 0387B53DFD61DBCA7B713EEE1CD97F906BDDDB51545606982047180ED861A334816B9280C680B7D006CE
16A791E6D34052
x = 06E32720C444DB089B0FB133C4B76BCB999AF85BE2F0FEE00828F3D2C8F6F461B6C59DD6C50D221BF62893
DAE34D170E
X = 024F7E422FAF3CE9B6C41D152810F1219275EF2609C2B773FDDA831042547079A81D6422C333176E4BBEA3
3B1177A91A29
X′ = 0245E1A1AEF8670486F0CEB1B64365C6C880EF523B74ADB8FBA8E98E8B7262479342852EACBE59C97A5B4
43DA391F84DBC
y = 04AA9BED6A080FEB1AA1989C879EC789FCE09E0DDF31ACE2AD6AAF9B1B74801E5BF4A47FD5C88FC6D340AA
A4510D3C2A
Y = 02D07170771E78C29960CD8F2C4BF84C680E0E634D626B4354A29E608746AAF6EF0EE8F6F3916D46AEE054
2D0A64945539
z = 02CA358BBFC9048EDEA3F584105E3461F9DE6BE68F8D6FD36A35C206DF9E83AFC9D84D8EEBFC6A9B5AF261
66D5324A2B93
K = F053027E04824E247DCBD91922C523DB14936475839F0B5D03FE9D93A6D60129E5C77DEB2219BFC8404
BE35805487286
o = 786C709D048E9E9CEAB0C2E032596E5E708ECE7AD3BA38CD998DE574DF65C413494922D50D2D869D572A5
B
CF563EA65DB
o = 3E9928F723856EA8A9051C1C1AE5B9DBCBF5B71235874C03AFD9FF8A7119B001A87E45310899F44314426
A
04878D50C2A
s = 37926DC8F0C6DD5C833A9BAC88CBC7B10540C3FD6ED95522C14DF050BFDDE4A55B551D50747EBB03DDFBB
231AD11FA8B
W = 026B99C3D3216E128D04FCACFBE3BD54BA6D60226406EE9789B6040743302C6A916287178C7E0A9CE3AA
1CBCBEF63BF7B7
secp521r1 (SHA512), L = 256, HMAC
K
A (= l r p a k eu s er1@ a i s t . g o . jp) = 6C7270616B65757365723140616973742E676F2E6A70
B (= l r p a k e s er ver @ a i s t . g o . jp) = 6C7270616B6573657276657240616973742E676F2E6A70
H(π) (= SHA512(I2OS(0)||A||B||password)) = 64C0F6239CCA16866612D8E1115B5ADA038D88B2A1376CC24E
3B54F308DCBF18256A008ED70342EB5F32BAB141717BEB59B46EAE36D8E50EBA514287CFA66DDB
© ISO/IEC 2021 – All rights reserved 15
ISO/IEC 11770-4:2017/Amd.2:2021(E)
G = 0301FC7EA5FABE261338268E4D869C85792F696FED0C4E8DF2C5CC2E1A058870AD34F2075F6AA9EB345E5
b
C7E389A1F6DACDC69E7F2E23E2E6F4FE634B7AF04B96C0000
s = 0145C5774E00ECF1B110F2830121B25AF54DC20AB69DCAB9EB178A8503F9BB0149584FAAF65643FEB5D3D
7ADBAB368DCCD7F516D01B1225016EDCE45DD3D35A222A4
W = 02001641396A47DF8E7904722C402F3CF28D0195A9E9F01C9F8587E21DF000EA8FE9F8F5AC190B8433A6
78D977802A06F54773D2D703DC7C70A31F86CFDE98456B7B6F
x = 3415721DBA0048D8FFA0B55AE61A5A26FDFED7ED27338B57CCB727821DAEFF7ADE71FF07696940EDE7C6F0
ECE64CC528CBFA2B1719AA7EC87A7203701BF28974F2
X = 0201789EDE6B436290240CD0560C417E026CFC40189E01E7D
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...