ISO/IEC 11770-4:2017/Amd 1:2019
(Amendment)Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets — Amendment 1: Unbalanced Password-Authenticated Key Agreement with Identity-Based Cryptosystems (UPAKA-IBC)
Information technology — Security techniques — Key management — Part 4: Mechanisms based on weak secrets — Amendment 1: Unbalanced Password-Authenticated Key Agreement with Identity-Based Cryptosystems (UPAKA-IBC)
Technologies de l'information — Techniques de sécurité — Gestion de clés — Partie 4: Mécanismes basés sur des secrets faibles — Amendement 1: Accord dissymétrique de clé authentifié par mot de passe utilisant un mécanisme de chiffrement basé sur l'identité
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 11770-4
Second edition
2017-11-15
AMENDMENT 1
2019-09
Information technology — Security
techniques — Key management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 1: Unbalanced Password-
Authenticated Key Agreement with
Identity-Based Cryptosystems (UPAKA-
IBC)
Technologies de l'information — Techniques de sécurité — Gestion
de clés —
Partie 4: Mécanismes basés sur des secrets faibles
AMENDEMENT 1: Accord dissymétrique de clé authentifié par mot de
passe utilisant un mécanisme de chiffrement basé sur l'identité
Reference number
ISO/IEC 11770-4:2017/Amd.1:2019(E)
©
ISO/IEC 2019
---------------------- Page: 1 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2019
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(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 http: //patents .iec .ch).
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,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
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 2019 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
Information technology — Security techniques — Key
management —
Part 4:
Mechanisms based on weak secrets
AMENDMENT 1: Unbalanced Password-Authenticated Key
Agreement with Identity-Based Cryptosystems (UPAKA-IBC)
Introduction
Insert the following paragraph after Note 2:
d) Unbalanced password-authenticated key agreement with identity-based cryptosystems:
Establish one or more secret keys for an entity, A, associated with another entity, B, where:
1) A and B share a weak secret and B has a strong secret; or
2) A has a weak secret and B has verification data derived from A's weak secret with a one-way
function along with a strong secret.
An example of a strong secret could be a long random key. This strong secret is independent of the
weak secret and has been generated for an identity-based cryptosystem.
In an unbalanced password-authenticated key agreement mechanism with an identity-based
cryptosystem, 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, A has used the weak secret and B has a strong
secret corresponding to its identity and neither of the two entities can predetermine the values of
the shared secret keys.
NOTE 3 This type of key agreement mechanism runs between entities with unbalanced security
requirements such as in the client-server model. It is suitable for the case where a client (A) conducts
authentication based on both a human-memorable password and a server (B)'s identity while enhancing
server authentication (thus avoiding an attack on a cryptographic protocol in which an unauthorized party
masquerades as a legitimate server, which is often called "a server impersonation attack").
Clause 3
Insert the following terminological entry at the end of the clause:
3.39
master-secret key
secret value used by the private key generator to compute private keys for an identity-based encryption
(IBE) or identity-based signature (IBS) scheme
© ISO/IEC 2019 – All rights reserved 1
---------------------- Page: 4 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
Clause 4
Insert the following abbreviated terms:
CT ciphertext, an octet string
G point of order r on E over F(q), in the same subgroup as G
1
IBE identity-based encryption
IBS identity-based signature
ID distinguished identifier that is uniquely assigned to an identity, which is an octet string
κ security parameter
Msg plaintext, an octet string
msk master-secret key of IBE or IBS
parms domain parameters of IBE or IBS
σ signature, an octet string
sk private key corresponding to an entity with distinguished (octet) identifier ID for an IBE or
ID
IBS scheme
Clause 5
Replace the definition of G by the definition of G and G as follows:
1
— G, G curve points of order r (G and G are called the generators of a subgroup of r points on E). It is
1 1
assumed that the logarithm of G to the base G is unknown;
1
Clause 5
Add the following paragraph at the end:
Annex B defines the object identifiers which shall be used to identify the mechanisms specified in this
document.
Clause 8
Add new Clause 8 as follows:
8 Unbalanced password-authenticated key agreement with identity-based
cryptosystems
8.1 General
This clause specifies two unbalanced password-authenticated key agreement mechanisms using
identity-based cryptosystems. In these mechanisms, one entity has a weak secret derived from
a password, and the other entity has the password verification data and a strong secret, i.e., a long
random key which is used with an identity-based cryptosystem. An identity-based cryptosystem is an
2 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
asymmetric cryptographic technique that allows a public key to be defined as a string, such as an IP
address or e-mail address, that represents an entity. The corresponding private key is calculated from
an identity, a set of domain parameters, and a domain-wide secret value called a master-secret key. A
user public key is calculated by anyone who has the necessary domain parameters, while the master
secret key is needed to calculate a user private key, and the calculation can only be performed by a
(trusted) private key generator that has this secret.
The two unbalanced password-authenticated key agreement mechanisms with identity-based
cryptosystems have the following initialization process and key establishment process.
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 can be publicly known.
The two entities also agree to use either a shared weak secret derived from a password or shared
password-based information, i.e. one entity has a password-based weak secret and the other entity has
the corresponding password verification element.
Key establishment process
a) Generate and exchange key tokens. Each of the two entities involved randomly chooses one or
more key token factors associated with the domain parameters, creates the corresponding key
tokens, which may be associated with the password or password verification element (a key token
associated with the password or password verification element is called a “password-entangled
key token”), and then makes 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), each of
the two entities involved chooses an appropriate method to validate the received key tokens based
on the domain parameters. If any validation fails, output “invalid” and stop.
c) Derive shared secret keys. Each of the two entities involved applies certain secret value derivation
functions to their own key token factor, the other entity’s key tokens and/or shared password or
password verification element 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.
d) Check key confirmation. The two entities involved use the shared secret keys established using the
above steps to confirm their awareness of the keys to each other. This step is optional in Unbalanced
Key Agreement Mechanisms with Password and Identity-based Encryption and in Unbalanced Key
Agreement Mechanisms with Password and Identity-based Signature.
For convenience, an unbalanced key agreement mechanism with password and identity-based
encryption and an unbalanced key agreement mechanism with password and identity-based signature
are denoted by UKAM-PiE and UKAM-PiS, respectively.
Because of the use of weak secrets, countermeasures against online guessing attacks shall be taken
into account. For example, counters that indicate the number of failed connections can be introduced:
— a counter that tracks the total number of unsuccessful authentication trials in a row;
— a counter that tracks the total number of unsuccessful authentication events during the period of
use of a specific password;
— a counter that tracks the total number of authentication events (successful and unsuccessful) during
the period of use of the specific password.
NOTE In applications using a UKAM-PiE or UKAM-PiS, A can play the role of a client and B can play the role of
a server.
© ISO/IEC 2019 – All rights reserved 3
---------------------- Page: 6 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
8.2 Unbalanced Key Agreement Mechanism with Password and Identity-based
Encryption (UKAM-PiE)
8.2.1 General
This mechanism is designed to achieve authenticated key agreement using a password and an identity-
based encryption scheme, and it establishes one or more shared secret keys between entities A and B.
In the mechanism, A and B share a password-based octet string π. B additionally has a strong secret,
i.e., a decryption key which is used for an identity-based encryption scheme. This mechanism provides
unilateral explicit key authentication and optionally mutual key authentication.
An identity-based encryption scheme consists of the following four algorithms.
— IBE.Setup(κ). Given a security parameter κ, generate a tuple , where parms denotes IBE
domain parameters, msk denotes a master-secret key.
— IBE.Extract(parms, msk, ID). Given parms, msk, and ID, generate a private key sk for ID.
ID
— IBE.Enc(parms, ID, Msg). Given parms, ID, and a plaintext Msg, perform the encryption and output
the ciphertext of Msg, CT, for ID. Note that Msg and CT are octet strings.
— IBE.Dec(parms, ID, sk , CT). Given parms, ID, and sk , decrypt a ciphertext CT and output a plaintext
ID ID
or "error".
In general, the setup, key extraction and encryption algorithms are probabilistic, while the decryption
algorithm is deterministic. It is recommended that applications establish a methodology for
authenticating access to private keys by using the string ID as an identity in a trusted authentication
[33]
system (see ISO/IEC 18033-5 for further guidance on identity-based ciphers).
This mechanism works in both the DL and EC settings.
As noted in ISO/IEC 18033-5, a general purpose IBE scheme should satisfy the appropriate security
level, namely semantic security against an adaptive chosen ciphertext attack.
NOTE UKAM-PiE is based on Bibliographic reference [29].
8.2.2 Prior shared parameters
Key agreement between two entities A and B takes place in a shared context consisting of the following
parameters:
— a set of valid domain parameters (either DL domain parameters or EC domain parameters) specified
in Clause 5;
— a password-based octet string, π, used by A and B;
— a key token generation function, D;
— a private key, sk , used by B;
B
— an encrypted key token generation function, EK, used by A;
— a key token decryption function, KD, used by B;
— a password verification function, S, used by B;
— a key token check function, T;
— a secret value derivation function, V ;
S
— a key derivation function, K;
4 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
— one or more key derivation parameter octet strings {P , P , .}, where A and B shall agree to use the
1 2
same values;
— the length of a shared secret key, L .
K
8.2.3 Functions
8.2.3.1 Key token generation function, D
The key token generation function, D, is as defined in 6.5.3.2.
8.2.3.2 Encrypted key token generation function, EK
The encrypted key token generation function, EK, takes the IBE domain parameters parms, an ID, a
password-based octet string π, and an output w (or W) of the function D, and produces an encrypted key
token CT as output, i.e. CT = EK(parms, ID, π, w (or W)). UKAM-PiE is used with the following function EK:
— Given the IBE domain parameters parms and three inputs, an octet string ID, an octet string π, and
the output w (or W) of the function D, EK is defined as follows:
— compute d = I2OS(BS2I(H(π)));
— compute e = GE2OS (w (or W));
X
— compute CT = IBE.Enc(parms, ID, d||e);
— output CT.
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.
8.2.3.3 Key token decryption function, KD
The key token decryption, KD, takes the IBE domain parameters parms, an ID, a private key sk for ID,
ID
an output CT of the function EK, and produces an ordered pair made up of an octet string d and a group
element w (or W) as output. UKAM-PiE is used with either KD or KD as the function KD:
DL EC
— KD 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 defined over F(q). Given the DL domain parameters
(including g and q), the IBE domain parameters parms, an octet string ID, a group element sk , and
ID
the output CT of the function EK, KD is defined as follows:
DL
— compute IBE.Dec(parms, ID, sk , CT);
ID
— if the output of IBE.Dec is "error", then output "error";
— else, the output of IBE.Dec is d||e and compute w = I2FE(OS2I(e));
— output (d, w).
— KD 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 defined over F(q). Given the EC domain
parameters (including G), the IBE domain parameters parms, an octet string ID, a group element
sk , and the output CT of the function EK, KD is defined as follows:
ID EC
— compute IBE.Dec(parms, ID, sk , CT);
ID
— if the output of IBE.Dec is "error", then output "error";
— else, the output of IBE.Dec is d||e and compute W = I2FE(OS2I(e));
© ISO/IEC 2019 – All rights reserved 5
---------------------- Page: 8 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
— output (d, W).
Functions OS2I (Octet String to Integer conversion) and I2FE (Integer to Field Element conversion) are
described in Annex A.
8.2.3.4 Password verification function, S
The password verification function, S, takes an octet string d output by the function KD, and a password-
based octet string π, and produces a Boolean value written S(d, π) as output. UKAM-PiE is used with the
following function S:
Given an octet string d output by the function KD and an octet string π, S is defined as follows:
— if d = I2OS(BS2I(H(π))), S(d, π) = 1;
— else, S(d, π) = 0.
Functions BS2I (Bit String to Integer conversion) and I2OS (Integer to Octet String conversion) are
described in Annex A.
8.2.3.5 Key token check function, T
The key token check function, T, is as defined in 6.2.3.3.
8.2.3.6 Secret value derivation function, V
S
The secret value derivation function, V , takes an integer x and a selected group element y (or Y) as
S
input and produces another group element written V (x, y (or Y)) as output. UKAM-PiE is used with
S
either V or V as the function V :
SDL SEC S
— V is suitable for use when the mechanism is used with the DL domain parameters, i.e. it operates
SDL
over the multiplicative group of elements defined over F(q). Given the DL domain parameters
(including r and q), and two inputs, x from {1, …, r − 1} and y from {2, …, q − 2}, V is defined as in
SDL
Formula (35):
x
Vx,myy= od q (35)
()
SDL
— V is suitable for use when the mechanism is used with the EC domain parameters, i.e. it operates
SEC
over the additive group of elements in an elliptic curve defined over F(q). Given the EC domain
parameters (including r), and two inputs, x from {1, …, r − 1} and a point Y (≠0 ) on E, V is defined
E SEC
as in Formula (36):
Vx,Yx= ×Y (36)
()
SEC
8.2.3.7 Key derivation function, K
The key derivation function, K, is as defined in 6.2.3.6.
8.2.4 Key agreement operation
This mechanism involves both A and B performing a sequence of up to four steps, numbered A1-A4 and
B1-B4 (for the steps to be followed by A and B, respectively). Steps A3, A4, B3, and B4 are optional.
Encrypted key token construction (A1)
A performs the following steps:
— choose an integer s randomly from {1, …, r – 1} as its key token factor;
A
6 © ISO/IEC 2019 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC 11770-4:2017/Amd.1:2019(E)
— compute w = D(s ) as its key token;
A A
— compute CT = EK(parms, ID , π, w ) as its encrypted key token;
B A
— make CT available to B (by sending (ID , CT) from A to B).
A
Key token construction (B1)
B performs the following steps:
— receive CT from A;
— compute (d, w ) = KD(parms, ID , sk , CT);
A B B
— if the output of KD is “error”, then output “invalid” and stop; otherwise, continue;
— check validity of w using T(w ): if T(w ) = 0, output “invalid” and stop; otherwise, continue;
A A A
— check validity of d using S(d, π): if S(d, π) = 0, output “invalid” and stop; otherwise, continue;
— choose an integer s randomly from {1, …, r – 1} as its key token factor;
B
— compute w = D(s ) as its key token;
B B
— make w available to A (by sending (ID , w ) from B to A).
B B B
Shared secret key derivation (A2)
A performs the following steps:
— receive w from B;
B
— check validity of w
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.