Unbalanced Password-Authenticated Key Agreement with Identity-Based Cryptosystems (UPAKA-IBC)

Accord dissymétrique de clé authentifié par mot de passe utilisant un mécanisme de chiffrement basé sur l'identité

General Information

Status
Published
Publication Date
05-Sep-2019
Current Stage
6060 - International Standard published
Start Date
02-Aug-2019
Completion Date
06-Sep-2019
Ref Project

RELATIONS

Buy Standard

Standard
ISO/IEC 11770-4:2017/Amd 1:2019 - Unbalanced Password-Authenticated Key Agreement with Identity-Based Cryptosystems (UPAKA-IBC)
English language
15 pages
sale 15% off
Preview
sale 15% off
Preview

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
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

IBS scheme
Clause 5
Replace the definition of G by the definition of G and G as follows:

— 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;
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.

— 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;
— 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 ;
— 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 .
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));
— 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

(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,

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

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

the output CT of the function EK, KD is defined as follows:
— compute IBE.Dec(parms, ID, sk , CT);
— 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

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);
— 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

The secret value derivation function, V , takes an integer x and a selected group element y (or Y) as

input and produces another group element written V (x, y (or Y)) as output. UKAM-PiE is used with

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):
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;
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).
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;
— 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;
— 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.