ISO/IEC 11770-2:2018
(Main)IT Security techniques — Key management — Part 2: Mechanisms using symmetric techniques
IT Security techniques — Key management — Part 2: Mechanisms using symmetric techniques
This document defines key establishment mechanisms using symmetric cryptographic techniques. This document addresses three environments for the establishment of keys: Point-to-Point, Key Distribution Centre (KDC), and Key Translation Centre (KTC). It describes the required content of messages which carry keying material or are necessary to set up the conditions under which the keying material can be established. This document does not indicate other information which can be contained in the messages or specify other messages such as error messages. The explicit format of messages is not within the scope of this document. This document does not specify the means to be used to establish initial secret keys; that is, all the mechanisms specified in this document require an entity to share a secret key with at least one other entity (e.g. a TTP). For general guidance on the key lifecycle, see ISO/IEC 11770-1. This document does not explicitly address the issue of inter-domain key management. This document also does not define the implementation of key management mechanisms; products complying with this document are not necessarily compatible.
Techniques de sécurité IT — Gestion de clés — Partie 2: Mécanismes utilisant des techniques symétriques
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 11770-2
Third edition
2018-10
IT Security techniques — Key
management —
Part 2:
Mechanisms using symmetric
techniques
Techniques de sécurité IT — Gestion de clés —
Partie 2: Mécanismes utilisant des techniques symétriques
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
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 2018 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 3
5 Requirements . 4
6 Point-to-point key establishment . 6
6.1 General . 6
6.2 Key establishment mechanism 1 . 6
6.3 Key establishment mechanism 2 . 7
6.4 Key establishment mechanism 3 . 7
6.5 Key establishment mechanism 4 . 8
6.6 Key establishment mechanism 5 . 8
6.7 Key establishment mechanism 6 .10
7 Mechanisms using a Key Distribution Centre .11
7.1 General .11
7.2 Key establishment mechanism 7 .11
7.3 Key establishment mechanism 8 .12
7.4 Key establishment mechanism 9 .14
7.5 Key establishment mechanism 10.15
8 Mechanisms using a Key Translation Centre .17
8.1 General .17
8.2 Key establishment mechanism 11.17
8.3 Key establishment mechanism 12.18
8.4 Key establishment mechanism 13.20
Annex A (normative) Object identifiers .22
Annex B (informative) Properties of key establishment mechanisms .24
Annex C (informative) Auxiliary techniques .26
Bibliography .28
© ISO/IEC 2018 – All rights reserved iii
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. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
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).
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 Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Security techniques.
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.
This third edition cancels and replaces the second edition (ISO/IEC 11770-2:2008), which has been
technically revised. It also incorporates ISO/IEC 11770-2:2008/Cor 1:2009.
The main changes compared to the previous edition are as follows:
— the list of requirements in Clause 5 has been updated;
— an optional message and mechanism identifier to the encrypted strings sent within each of the
mechanisms has been added;
— the set of inputs for calculation of the key in Mechanism 5 has been expanded;
— minor changes have been made to the fourth message in Mechanism 8 and the second message in
Mechanism 10.
A list of all parts in the ISO/IEC 11770 series can be found on the ISO website.
iv © ISO/IEC 2018 – All rights reserved
Introduction
The purpose of key management is to provide procedures for handling cryptographic keying material to
be used in symmetric or asymmetric cryptographic algorithms according to the security policy in force.
Key establishment mechanisms using symmetric cryptographic techniques can be derived from
the entity authentication mechanisms of ISO/IEC 9798-2 and ISO/IEC 9798-4 by specifying the use
of text fields available in those mechanisms. Other key establishment mechanisms exist for specific
environments. Besides key establishment, the goals of such a mechanism can include unilateral
or mutual authentication of the communicating entities. Further goals can be the verification of the
integrity of the established key, or key confirmation.
© ISO/IEC 2018 – All rights reserved v
INTERNATIONAL STANDARD ISO/IEC 11770-2:2018(E)
IT Security techniques — Key management —
Part 2:
Mechanisms using symmetric techniques
1 Scope
This document defines key establishment mechanisms using symmetric cryptographic techniques.
This document addresses three environments for the establishment of keys: Point-to-Point, Key
Distribution Centre (KDC), and Key Translation Centre (KTC). It describes the required content of
messages which carry keying material or are necessary to set up the conditions under which the keying
material can be established.
This document does not indicate other information which can be contained in the messages or specify
other messages such as error messages. The explicit format of messages is not within the scope of this
document.
This document does not specify the means to be used to establish initial secret keys; that is, all the
mechanisms specified in this document require an entity to share a secret key with at least one other
entity (e.g. a TTP). For general guidance on the key lifecycle, see ISO/IEC 11770-1. This document does
not explicitly address the issue of inter-domain key management. This document also does not define
the implementation of key management mechanisms; products complying with this document are not
necessarily compatible.
2 Normative references
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 11770-1, Information technology — Security techniques — Key management — Part 1: Framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 11770-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
distinguishing identifier
information which unambiguously distinguishes an entity
3.2
entity authentication
corroboration that an entity is the one claimed
[SOURCE: ISO/IEC 9798-1:2010]
© ISO/IEC 2018 – All rights reserved 1
3.3
explicit key authentication from A to B
assurance for entity B that entity A (and possibly additional identified trusted parties) is the only other
entity that is in possession of the correct key
Note 1 to entry: Implicit key authentication from A to B is assurance for entity B that entity A (and possibly
additional identified trusted parties) is the only other entity that can possibly be in possession of the correct key.
Note 2 to entry: Implicit key authentication from A to B and key confirmation from A to B together imply explicit
key authentication from A to B.
Note 3 to entry: Where a mechanism is claimed to provide explicit key authentication, this assumes that the
mechanism has completed successfully, i.e. both parties send and receive all messages correctly and succeed in
processing them correctly. In any protocol, it is not possible from within the protocol itself for the sender of the
final message to know whether this message has been received correctly by the intended recipient. If assurance
is required that this has occurred, then this can typically be obtained from the context of use of the mechanism,
e.g. if a message is received from the recipient making use of an established key.
[SOURCE: ISO/IEC 11770-3:2015]
3.4
key confirmation
key confirmation from A to B
assurance for entity B that entity A is in possession of the correct key
Note 1 to entry: Where a mechanism is claimed to provide key confirmation, this assumes that the mechanism
has completed successfully, i.e. both parties send and receive all messages correctly and succeed in processing
them correctly. In any protocol, it is not possible from within the protocol itself for the sender of the final message
to know whether this message has been received correctly by the intended recipient. If assurance is required
that this has occurred, then this can typically be obtained from the context of use of the mechanism, e.g. if a
message is received from the recipient making use of an established key.
[SOURCE: ISO/IEC 11770-3:2015]
3.5
key control
ability to choose the key, or the parameters used in the key computation
3.6
key derivation function
KDF
function which takes as input a number of parameters, at least one of which is secret, and which gives
as output keys appropriate for the intended algorithm(s) and applications
Note 1 to entry: In ISO/IEC 11770-2:2008, such a function was referred to as a key generating function.
[SOURCE: ISO/IEC 11770-6:2016, 3.3 — modified, Note 1 to entry has been changed and Note 2 to entry
has been removed.]
3.7
point-to-point key establishment
direct establishment of keys between entities, without involving a third party
3.8
random number
time variant parameter (3.11) whose value is unpredictable
3.9
redundancy
information that is known and can be checked
2 © ISO/IEC 2018 – All rights reserved
3.10
sequence number
time variant parameter (3.11) whose value is taken from a specified sequence which is non-repeating
within a certain time period
3.11
time variant parameter
data item used to verify that a message is not a replay, such as a random number (3.8), sequence number
(3.10), or a time stamp
3.12
unknown key share attack
attack in which all the entities involved in the mechanism complete the mechanism successfully to
establish a shared secret key K, but do not agree on the identity of the entity with which they share
the key.
4 Symbols and abbreviated terms
A, B entities between which a key is established
e (Z) result of encrypting data Z with a symmetric encryption algorithm using the secret key K
K
f key derivation function
F keying material
F keying material originated by entity X
X
I the distinguishing identifier of entity X
X
K secret key that is established between entities A and B as a result of the use of one of the
mechanisms specified in this document; K can be part of F or computed from F using a
key derivation function
NOTE K is not to be confused with K , the long-term secret key shared by A and B.
AB
KDC Key Distribution Centre
KTC Key Translation Centre
K secret key associated with entities X and Y
XY
MAC Message Authentication Code
MAC (Z) result of applying a MAC function to data Z using the secret key K
K
P Key Distribution Centre or Key Translation Centre
R random number
R random number issued by entity X
X
i
SID constant uniquely identifying the mechanism (m) and the instance of encryption (i)
m
within the mechanism
T/N time stamp or sequence number
© ISO/IEC 2018 – All rights reserved 3
Text , Text , fields that can contain optional data for use in applications outside the scope of this
1 2
…, document (they can be empty). Their relationship and contents depend upon the specific
application. One such possible application is message authentication (see Annex C for
an example). Likewise, optional plaintext text fields may be included as a prefix, or ap-
pended, to any of the messages. They have no security implications and are not explicitly
included in the mechanisms specified in this document.
TVP Time Variant Parameter
TVP Time Variant Parameter issued by entity X
X
T /N time stamp or sequence number issued by entity X
X X
X||Y The result of the concatenation of data items X and Y in the order specified. In cases
where the result of concatenating two or more data items is encrypted as part of one of
the mechanisms specified in this document, this result shall be composed so that it can
be uniquely resolved into its constituent data strings, i.e. so that there is no possibility
of ambiguity in interpretation. This latter property can be achieved in a variety of dif-
ferent ways, depending on the application. For example, it can be achieved by (a) fixing
the length of each of the strings throughout the domain of use of the mechanism, or (b)
encoding the sequence of concatenated strings using a method that guarantees unique
[1]
decoding, e.g. using the distinguished encoding rules defined in ISO/IEC 8825-1 .
[…] Data items that are optional in the mechanisms are shown in square brackets, [thus].
5 Requirements
The key establishment mechanisms specified in this document make use of symmetric cryptographic
techniques, more specifically, symmetric encryption algorithms, MACs, and/or key derivation functions.
The cryptographic algorithms and their key life-times shall be chosen such that it is computationally
infeasible for a key to be deduced during its lifetime. If the following additional requirements are not
met, the key establishment process can be compromised.
a) For those mechanisms making use of a symmetric encryption algorithm, either assumption 1) or
assumption 2) is required.
1) The encryption algorithm, its mode of operation, and the redundancy in the plaintext shall
provide the recipient with the means to detect forged or manipulated data.
2) The integrity of the encrypted data shall be ensured by a MAC.
In order to achieve 1) or 2), it is recommended that choices for encryption and integrity algorithms
be in accordance with the following.
i) Assumption 1) above is guaranteed if an authenticated encryption technique is used; use
[10]
of one of the techniques standardized in ISO/IEC 19772 is recommended.
ii) The choice for a symmetric encryption algorithm should be chosen from amongst those
standardized in ISO/IEC 18033-3, ISO/IEC 18033-4, ISO/IEC 29192-2 and ISO/IEC 29192-3.
iii) If a block cipher encryption algorithm is used, then the mode of operation employed should
[4]
be one of those standardized in ISO/IEC 10116 .
iv) If a MAC is used, then the techniques should be chosen from amongst those standardized
[2]
in ISO/IEC 9797 (all parts) and ISO/IEC 29192-6.
NOTE 1 When a KDC or KTC is involved, assumptions 1) and 2) are not always equivalent in terms of
the ability to unambiguously detect on which link an active attack is being performed. See Annex C for
examples.
4 © ISO/IEC 2018 – All rights reserved
b) In each exchange specified in the mechanisms of 6, 7 and 8, the recipient of a message shall know
the claimed identity of the originator. If this is not the case, i.e. if the context of use of the mechanism
does not establish the claimed identity, then this can, for example, be achieved by the inclusion of
identifiers in additional plaintext text fields of one or more of the messages.
The specifications of many of the mechanisms in this document require the correctness of an
identifier included in a message to be checked. This should be done by comparing the received
identifier with the expected identifier (as specified in the mechanism concerned). If the identifier
in question is that of the originator of the message, then the recipient should know the value of the
expected identifier because of requirement b).
c) Keying material can be established using either secure or insecure communication channels. When
using only symmetric cryptographic techniques, at least the long-term key(s) K (and K , K ,
AB AP BP
where relevant) shall be exchanged between two entities using a secure channel in order to allow
secure communications.
d) The key establishment mechanisms in this document require the use of time variant parameters,
such as time stamps, sequence numbers, or random numbers. In this context, the use of the term
random number also includes unpredictable pseudo-random numbers. The properties of these
parameters, in particular that they are non-repeating, are important for the security of these
mechanisms. For additional information on time variant parameters, see ISO/IEC 9798-1:2010,
[3] [8]
Annex B . For means of generating random numbers, see ISO/IEC 18031 .
e) The secret key(s) used in implementations of any of the mechanisms specified in this document
shall be distinct from keys used for any other purposes.
f) The data strings encrypted at various points in a key establishment mechanism shall not be
composed so that they can be interchanged.
NOTE 2 This can be enforced by including the following elements in each encrypted data string, e.g.
within a text field.
— The object identifier as specified in Annex A, in particular identifying the ISO/IEC standard
number (11770), the part number (2), and the authentication mechanism.
— A constant that uniquely identifies the encrypted string within the mechanism. This constant
may be omitted in the mechanisms that involve only one encrypted string. A specific proposal for including
[3]
this information in the form of a special identifier is provided in ISO/IEC 9798-2 , and is included as an
optional element in the mechanism specifications in this document.
If any additional element is included in an encrypted string, then its presence shall be checked by
the recipient after decryption, and the mechanism shall fail if any such check fails.
g) In the mechanisms involving a KDC or a KTC, the holder of a key K (or K ) shall always use it in
AP BP
the same way, i.e. acting either as the KDC or KTC P or the entity A (or B). That is, no entity shall
act as the KDC or KTC in one instance of a mechanism and act as A or B in another instance of the
mechanism, and use the same key in both cases. That is, if a single entity uses a mechanism acting
as P in one instance and as A (or B) in the other, then the keys it uses in the two instances shall be
distinct.
The mechanisms specified in this document are believed to offer protection against unknown key share
attacks. However, additional protection against such attacks can be provided if a key K established
using one of the mechanisms specified in this document is subject to further processing before use
[7]
by applying one of the key derivation functions (KDFs) specified in ISO/IEC 11770-6 . The inputs to
the KDF, which should be agreed in advance by the relevant parties, should include the key K and the
identifiers of the parties who will share the secret key. The output of the KDF can then be used as an
operational key.
Annex A defines object identifiers that shall be used to identify the mechanisms specified in this
document.
© ISO/IEC 2018 – All rights reserved 5
6 Point-to-point key establishment
6.1 General
Underlying every key management scheme is a point-to-point key establishment procedure, the use of
which requires that the entities already share a key so that further keys can be established directly
between the two entities. In Clause 6, six point-to-point key establishment mechanisms are specified.
For the implementation of the mechanisms specified in Clause 6, it is required that:
a) a long-term secret key K is shared by entities A and B. This key is assumed to be bilateral, i.e. it
AB
is capable of being used for encrypting and decrypting data strings (or as input to a key derivation
function in the case of Mechanism 1) by both A and B;
b) at least one of A and B is able to generate, acquire or contribute to a secret key, K, as described in the
individual mechanism;
c) the security requirements for the mechanism include the confidentiality of the established secret
key, K, and the detection of modification or replay of keys and messages.
The mechanisms specified in Clause 6 should not be used to update the long-term secret key, K .
AB
6.2 Key establishment mechanism 1
In key establishment mechanism 1, the key, K, is derived from a time variant parameter TVP, i.e.
a random number, R, a time stamp, T, or a sequence number, N, using a key derivation function. Key
establishment mechanism 1 does not provide authentication of the key, K, established by the mechanism.
The mechanism requires that A is able to generate a TVP.
Figure 1 — Mechanism 1
The mechanism involves the following steps (see Figure 1).
1) A generates a time variant parameter, TVP , which can be a random number, R , a time stamp,
A A
T , or a sequence number, N , and transfers it to B. Both A and B then derive the key, K, by using a
A A
key derivation function, f, which takes as inputs the shared secret key, K , and the time variant
AB
parameter, TVP :
A
K = f(K , TVP )
AB A
The function, f, should be one of the one-step key derivation functions specified in ISO/IEC 11770-
6:2016, Clause 6; in the notation of ISO/IEC 11770-6:2016, s = K , should be used as the secret input
AB
and t = TVP as the salt.
A
NOTE 1 A poor choice for the key derivation function, f, can result in an insecure key establishment process.
Implementors of this mechanism are very strongly advised to use a KDF specified in ISO/IEC 11770-6:2016,
Clause 6. Use of an ISO/IEC 11770-6 KDF for f has not been made mandatory in order to allow implementations
complying with a previous edition of this document to also be compliant with this document.
6 © ISO/IEC 2018 – All rights reserved
NOTE 2 In order to also provide entity authentication, key establishment mechanism 1 can be combined with
an authentication mechanism as specified in ISO/IEC 9798-2 or ISO/IEC 9798-4. See Annex C for an example.
6.3 Key establishment mechanism 2
In key establishment mechanism 2 the key, K, is supplied by entity A. The mechanism does not provide
authentication of the key, K, established by the mechanism, nor does it provide entity authentication.
Figure 2 — Mechanism 2
The mechanism involves the following steps (see Figure 2).
1) A sends B the keying material, F (made up of a key, K, together with optional data), encrypted using
the key, K . On receipt of the message, B deciphers the encrypted part, and thus obtains the key, K.
AB
6.4 Key establishment mechanism 3
Key establishment mechanism 3 is derived from the one-pass unilateral authentication mechanism
specified in ISO/IEC 9798-2. In this mechanism, the key, K, is supplied by entity A.
Key establishment mechanism 3 provides unilateral authentication, i.e. the mechanism enables entity
B to authenticate entity A. It also provides key confirmation and explicit key authentication from A to B.
Uniqueness/timeliness is controlled by time stamps or sequence numbers. The mechanism requires
that both A and B are able to maintain mechanisms for generating or verifying the validity of time
stamps, T , or sequence numbers, N , respectively.
A A
Figure 3 — Mechanism 3
The mechanism involves the following steps (see Figure 3).
1) A sends B a time stamp, T or sequence number, N , the distinguishing identifier, I , and the keying
A A B
material, F (made up of a key, K, together with optional data). The inclusion of the distinguishing
identifier, I , is optional. The data fields are encrypted using the key, K . On receipt of the message,
B AB
B deciphers the encrypted part, checks the correctness of its distinguishing identifier, if present,
checks the time stamp or sequence number, and obtains the key, K.
© ISO/IEC 2018 – All rights reserved 7
NOTE Distinguishing identifier I is included in step 1) to prevent a substitution attack, i.e. the re-use of
B
this message by an adversary masquerading as B to A (see Annex B). In environments where such attacks cannot
occur, the identifier can be omitted.
6.5 Key establishment mechanism 4
Key establishment mechanism 4 is derived from the two-pass unilateral authentication mechanism
specified in ISO/IEC 9798-2. In this mechanism, the key, K, is supplied by entity A.
Key establishment mechanism 4 provides unilateral authentication, i.e. the mechanism enables entity
B to authenticate entity A. It also provides key confirmation and explicit key authentication from A to B.
Uniqueness/timeliness is controlled by a random number, R . The mechanism requires that B is able to
B
generate random numbers.
Figure 4 — Mechanism 4
The mechanism involves the following steps (see Figure 4).
1) B sends A a random number, R .
B
2) A sends B the received number, R , the distinguishing identifier, I , and the keying material, F
B B
(made up of a key, K, together with optional data). The inclusion of the distinguishing identifier, I ,
B
is optional. The data fields are encrypted using the key, K . On receipt of message 2, B deciphers
AB
the encrypted part, checks the correctness of its distinguishing identifier, if present, checks that the
random number, R , sent to A in step 1, was used in constructing message 2, and obtains the key, K.
B
NOTE Distinguishing identifier I is included in step 2 to prevent a substitution attack, i.e. the re-use of this
B
message by an adversary masquerading as B to A (see Annex B). In environments where such attacks cannot
occur, the identifier can be omitted.
6.6 Key establishment mechanism 5
Key establishment mechanism 5 is derived from the two-pass mutual authentication mechanism specified
in ISO/IEC 9798-2. This mechanism enables both A and B to contribute part of the established key, K.
Key establishment mechanism 5 provides mutual authentication between A and B. It also provides key
confirmation and explicit key authentication from B to A.
Uniqueness/timeliness is controlled by time stamps or sequence numbers. The mechanism requires
that both A and B are able to maintain mechanisms for generating and verifying the validity of time
stamps, T, or sequence numbers, N.
8 © ISO/IEC 2018 – All rights reserved
Figure 5 — Mechanism 5
The mechanism involves the following steps (see Figure 5).
1) A sends B a time stamp, T , or sequence number, N , the distinguishing identifier, I , and the keying
A A B
material, F . The inclusion of the distinguishing identifier, I , is optional. The data fields are encrypted
A B
using the key, K . On receipt of message 1, B deciphers the encrypted part, checks the correctness of
AB
its distinguishing identifier, if present, and checks the time stamp or sequence number.
2) B sends A the time stamp, T , or sequence number, N , it received from A, its own time stamp, T , or
A A B
sequence number, N , the distinguishing identifier, I , and the keying material, F . The inclusion of
B A B
the distinguishing identifier, I , is optional. The data fields are encrypted using the key, K .
A AB
i) On receipt of message 2, A deciphers the encrypted part, checks the correctness of its
distinguishing identifier, if present, checks that the sequence number, T , or sequence number,
A
N , equal the value it sent in message 1, and checks the time stamp, T , or sequence number, N ,
A B B
provided by B.
ii) Both A and B derive the key, K, using a key derivation function, f, taking as input the secret
keying material fields, F and F , and (at least) the time stamps or sequence numbers, T or N
A B A A
and T or N :
B B
K = f(F , F , T /N , T /N , [I ], [I ], [Text1], [Text2], [SID ]).
A B A A B B A B
In steps 1 and 2, either of the two keying material fields, F and F , may be empty, but not both.
A B
The function, f, should be one of the two-step key derivation functions specified in ISO/IEC 11770-
6:2016, Clause 7; in the notation of ISO/IEC 11770-6:2016, s = F || F should be used as the secret input
A B
to the key extraction function and t = T /N || T /N [|| I ] [|| I ] [|| Text ] [|| Text ] [||SID ] as the salt
A A B B A B 1 2
input to the key expansion function.
NOTE 1 A poor choice for the key derivation function, f, can result in an insecure key establishment process.
Implementors of this mechanism are very strongly advised to use a KDF specified in ISO/IEC 11770-6:2016,
Clause 7. Use of an ISO/IEC 11770-6 KDF for f has not been made mandatory in order to allow implementations
complying with a previous edition of this document to also be compliant with this document.
NOTE 2 If either of the keying material fields, F and F , is empty, the key is computed using the key derivation
A B
function, f, as described above, but with the relevant one of the two inputs equal to either the empty string or a
fixed string (depending on the nature of the function f ).
NOTE 3 Distinguishing identifier, I , is included in step 1 to prevent a substitution attack, i.e. the re-use of this
B
message by an adversary masquerading as B to A (see Annex B). For similar reasons, distinguishing identifier,
I , is present in step 2. In environments where such attacks cannot occur, one or both of the identifiers can be
A
omitted.
© ISO/IEC 2018 – All rights reserved 9
6.7 Key establishment mechanism 6
Key establishment mechanism 6 is derived from the three-pass mutual authentication mechanism
specified in ISO/IEC 9798-2. This mechanism enables both A and B to contribute part of the
established key K.
Key establishment mechanism 6 provides mutual authentication between A and B. It also provides key
confirmation and explicit key authentication from B to A.
Uniqueness/timeliness is controlled by random numbers. The mechanism requires that both A and B
are able to generate random numbers.
Figure 6 — Mechanism 6
The mechanism involves the following steps (see Figure 6).
1) B sends A a random number, R , in message 1.
B
2) A sends B a random number, R , the received number, R , the distinguishing identifier, I , and the
A B B
keying material, F , in message 2. The inclusion of the distinguishing identifier, I , is optional. The
A B
data fields are encrypted using the key, K . On receipt of message 2, B deciphers the encrypted
AB
part, checks the correctness of its distinguishing identifier, if present, and checks that the random
number, R , sent to A in step 1, was used in constructing message 2.
B
3) B sends A the random numbers, R and R , and the keying material, F , in message 3. The data
B A B
fields are encrypted using the key, K .
AB
i) On receipt of message 3, A deciphers the encrypted part and checks that the random numbers,
R and R , sent in messages 1 and 2, respectively, were used in constructing message 3.
B A
ii) Both A and B derive the key, K, using a key derivation function, f, taking as input the secret
keying material fields, F and F , and (at least) the random numbers, R and R :
A B A B
K = f(F , F , R , R , [I ], [Text ], [Text ], [SID ])).
A B A B B 1 2
In steps 2 and 3, either of the two keying material fields, F and F , may be empty, but not both.
A B
The function f should be one of the two-step key derivation functions specified in ISO/IEC 11770-
6:2016, Clause 7; in the notation of ISO/IEC 11770-6:2016, s = F || F should be used as the secret input
A B
to the key extraction function and t = R || R [|| I ] [|| Text ] [|| Text ] [||SID ] as the salt input to the
A B B 1 2
key expansion function.
NOTE 1 A poor choice for the key derivation function, f, can result in an insecure key establishment process.
Implementors of this mechanism are very strongly advised to use a KDF specified in ISO/IEC 11770-6:2016,
Clause 7. Use of an ISO/IEC 11770-6 KDF for f has not been made mandatory in order to allow implementations
complying with a previous edition of this document to also be compliant with this document.
NOTE 2 Distinguishing identifier, I , is included in step 2 to prevent reflection attacks (see Annex B). In
B
environments where such attacks cannot occur, the identifier can be omitted.
10 © ISO/IEC 2018 – All rights reserved
NOTE 3 A variant of key establishment mechanism 6 can be constructed from two parallel instances of key
establishment mechanism 4, one started by entity A and the other by entity B. In this case, the key would be
computed as in step 3 above, i.e. as K = f(F , F , R , R , [I ], [I ], [Text ], [Text ]).
A B A B A B 1 2
7 Mechanisms using a Key Distribution Centre
7.1 General
The purpose of a Key Distribution Centre (KDC) is to first generate or acquire and then distribute a key
to a pair of entities that both share a key with the KDC.
In Clause 7, four key establishment mechanisms using a KDC are specified.
— In the first three mechanisms, one of the two entities requests a key, K, from the KDC for later
distribution to the other entity. The KDC generates or acquires the key, K, and sends a message to
the requesting entity protected by a key shared with this entity. This message contains a second
message protected by a key shared between the KDC and the second entity, which can then be
forwarded by the requesting entity to the ultimate recipient.
— In the fourth mechanism the KDC generates or acquires the key, K, and sends it directly to both
communicating entities. The two messages are protected using the key that the KDC shares with
the corresponding entities.
For all of these mechanisms, only the KDC is required to have the ability to generate or otherwise
acquire keys. Following the distribution of a key by the KDC, the two entities can use this key to support
the use of a point-to-point key establishment mechanism.
For the implementation of the mechanisms specified in Clause 7 it is required that:
a) entities A and B share secret keys, K and K , respectively, with a trusted third party, P, that acts
AP BP
as a KDC; the KDC shall be able to generate or otherwise acquire a key, K;
b) the KDC shall have a means of communication with the entity requesting a key;
c) the security requirements for the mechanism include the confidentiality of K, and the detection of
modification, substitution or replay of keys and messages.
7.2 Key establishment mechanism 7
Key establishment mechanism 7 does not provide authentication of the key, K, established by the
mechanism.
© ISO/IEC 2018 – All rights reserved 11
Figure 7 — Mechanism 7
The mechanism involves the following steps (see Figure 7).
1) A requests keying material from the KDC by sending message 1 to the KDC containing the
distinguishing identifier, I , of the second entity B.
B
2) The KDC sends message 2 to A containing the keying material, F (made up of a key, K, together with
optional data). This message consists of two main parts:
— eS([ ID ]|||FI|||)Text ;
KB7 1
AP
— eS([ ID ]|||FI|||)Text .
KA7 2
BP
On receipt of message 2, A deciphers the first part, checks the correctness of the distinguishing
identifier, I , and obtains the key, K.
B
3) A forwards the second part of message 2 to B in message 3. On receipt of message 3, B deciphers the
encrypted part, checks the correctness of the distinguishing identifier, I , and obtains the key, K.
A
7.3 Key establishment mechanism 8
Key establishment mechanism 8 is derived from the four-pass mutual authentication mechanism
specified in ISO/IEC 9798-2.
Key establishment mechanism 8 optionally provides mutual authentication between A and B. It also
provides key confirmation and explicit key authentication from A to B, and, optionally, from B to A.
Uniqueness/timeliness is controlled by time stamps or sequence numbers. The mechanism requires
that A, B and the KDC are able to maintain mechanisms for generating and verifying the validity of time
stamps, T, or sequence numbers, N.
12 © ISO/IEC 2018 – All rights reserved
Figure 8 — Mechanism 8
The mechanism involves the following steps (see Figure 8).
1) A requests keying material from the KDC by sending message 1 to the KDC containing a time
variant parameter, TVP (which can be a random number, a time stamp, or a sequence number),
A
and the distinguishing identifier, I , of the second entity B.
B
2) The KDC sends message 2 to A containing the keying material, F, (made up of a key, K, together with
optional data). This message consists of two main parts:
— eS([ ID ]|||TVPF||||IT|)ext ;
KA8 B 1
AP
— eS([ ID ]||/TN ||FI|| ||Text ) .
KP8 PA 2
BP
On receipt of message 2, A deciphers the first part, checks that the time variant parameter,
TVP , sent to the KDC in step 1, was used in constructing the first part of message 2, checks the
A
correctness of the distinguishing identifier I , and obtains the key K.
B
3) A forwards the second part of message 2 to B in message 3. Message 3 optionally also contains a
second part, a data field:
eS([ ID ]||/TN ||IT|| ext )
KA8 AB 3
which enables B to check the integrity of the key, K, retrieved from, F.
NOTE 1 The timestamp, T , or sequence number, N , included in message 3 is unrelated to the time
A A
variant parameter, TVP , included in message 1.
A
i) On receipt of message 3, B deciphers the first part, checks the correctness of the time stamp
or sequence number, checks the correctness of the distinguishing identifier, I , and obtains
A
the key, K.
© ISO/IEC 2018 – All rights reserved 13
ii) B deciphers the second part of message 3, if present, and checks the correctness of the time
stamp or sequence number and of the distinguishing identifier, I .
B
The fourth step given below is optional; it can be omitted if either no entity authentication or only
unilateral authenti
...








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