| Network Working Group | A. Kato |
| Internet-Draft | NTT Software Corporation |
| Intended status: Informational | T. Hardjono |
| Expires: October 27, 2016 | MIT |
| T. Kobayashi | |
| T. Saito | |
| K. Suzuki | |
| NTT | |
| April 25, 2016 |
FSU Key Exchange
draft-kato-fsu-key-exchange-01
This draft proposes an identity-based authenticated key exchange protocol following the extended Canetti-Krawczyk (id-eCK) model. The protocol is currently the most efficient among the id-eCK protocols.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 27, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Authenticated key exchange (AKE) is a core security function within many deployed systems today. It is a foundational function that allows end-users and systems alike to be authenticated prior to access to resource and services. Over the past two decades key exchange schemes have been proposed, based on symmetric and asymmetric key cryptography.
A more recent approach to AKE protocol has been the introduction of identity binding to the exchange [7] [8], obviating the need to rely on a public key infrastructure in which digital certificates need to be exchanged by users or end-points that wish to communicate signed and/or encrypted messages.
Identity-based AKE (ID-AKE) schemes rely on the use of the trusted intermediary referred to as the Key Generation Center (KGC). The role of the KGC, among others, is to generate a pair of master public and secret keys based on the user's identity and to extract a user's secret key corresponding to his or her identity.
In a 2-pass ID-AKE scheme, an "initiator" entity wishing to share a key with a second entity (referred to as the "responder") sends ephemeral public information to the responder. In its turn, the responder sends another ephemeral public information to the initiator entity. Following this, each entity would then generate a session from a number of parameters, notably their respective secret keys (given by the KGC), their own secret values of the ephemeral information, the identity of the peer they're communicating with, and the ephemeral information they received from that peer.
We propose a provably secure ID-AKE scheme called "FSU" [4] [5] [6] based on the previous model of [9] and which builds on the previous efforts in [10] [11] . The model underlying the FSU was chosen due to the merit of provable security based on an adversarial model in which the adversary has the freedom to choose keys reveal.
In order to establish secure communications, the encryption is used, and a key exchange protocol is necessary to use the encryption. If the key exchange protocol has vulnerability, an attacker can intercept all messages, so encrypted session becomes meaningless. In practice, man in the middle attack and a forward security of key exchange protocol are serious issues.
In recent years, IoT technology gathers many attentions. It is expected that 26-30 billion devices will be wirelessly connected by 2020. And to set up a huge number of devices with certificates or passwords for key exchange and to maintain the certificates or passwords require many costs. Furthermore, the leakage of a secret key for key exchange and a session key for encryption likely to occur because of resource restriction of device and installation environment of device.
To resolve above problems, we propose an ID-based authenticated key exchange protocol FSU. In usual PKI based cryptography, a device must set up password or generate own secret key. On the other hand, in the FSU protocol the trusted third party generate the secret key for a huge number of IoT devices, so the manufacture and users of the devices can maintain secret key for the devices unitarily. The FSU Protocol use existing ID, which can be any string, e.g., e-mail address and serial number, as public key instead of certificate or password. Thus, the authentication server is not required to manage the certificates and the passwords of device any more. Finally, the FSU protocol provides the highest security against leakages of secret keys. Thus, security of a session key is preserved even if some secret keys are leaked because of resource restriction and installation environment of devices.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [1].
This section shows notation used in this memo.
Let F_q be a finite field with q = p^n elements for a prime p and an integer n and let E(F_q) be an elliptic curve with an order r and an embedding degree k defined over F_q. An embedding degree k is defined as a minimum integer k such that r is a divisor of q^k - 1.
Let G_1 (resp. G_2) be an additive group with an order r generated by E(F_q) (resp. E'(F_q)). Let G_T be multiplicative groups with the same order r. Let P_1, P_2 be generators of G_1, G_2 respectively. We say that (G_1, G_2, G_T) are bilinear map groups if there exists a pairing e: (G_1, G_2) -> G_T satisfying the following properties:
This pairing is described in specification of optimal ate pairing specification[3]. It is defined by Pairing-Parm-ID following way.
Pairing-Param-ID = {
G1-Curve-ID,
G2-Curve-ID
GT-Field-ID
}
G1-Curve-ID and G2-Curve-ID is an identifiers of elliptic curve. And GT-Field-ID is an identifier of the G_T range of finite field. G1-Curve-ID , G2-Curve-ID and GT-Field-ID are described in [2] the following way.
G1-Curve-ID = {
p_b : A prime specifying base field F_p.
A, B : The coefficients of the equation y^2 = x^3 A * x + B
defining E.
G = (x, y) : The base point, i.e., a point with x and y
being its x- and y-coordinates in E, respectively.
r : The prime order of the group generated by G.
h : The cofactor of G in E.
}
G2-Curve-ID = {
p_b : A prime specifying base field F_p.
e2 : The constant of an irreducible polynomial specifying
extension field F_{p^2} = Fp[u] / (u^2 - e2).
A', B' : The coefficients of the equation y^2 = x^3 A' * x +
B' defining E'.
G' = (x', y') : The base point, i.e., a point with x' and y'
being its x- and y-coordinates in E', respectively.
r' : The prime order of the group generated by G'.
h' : The cofactor of G' in E'.
}
GT-Filed-ID = {
p_b : A prime specifying base field.
r : The prime order of the subgroup of F_{p^12}.
e2 : The constant of the irreducible polynomial of F_{p^2} =
F_p [u] / (u^2 - e2).
e6 : The constant of the irreducible polynomial of F_{p^6} =
F_{p^2}[v] / (v^3 - e6).
e12 : The constant of the irreducible polynomial of F_{p^12}
= F_{p^6}[w] / (w^2 - e12).
h'' : The cofactor of G_T
}
In addition, this memo uses the following functions.
floor(x) : The function returning an integer such that max{x' in Z | x' <= x}.
ceil(x) : The function returning an integer such that min{x' in Z | x' >= x}.
O_E : The point at infinity over elliptic curve E.
This section describes data type and its conversion used in this memo.
This memo uses conversion from bit strings to octet strings. Informally, the idea is to pad the bit string with 0's on the left to make its length a multiple of 8, then chop the result up into octets. Formally, the conversion routine, BS2OSP(B), is specified in Appendix A.1
This memo uses conversion from octet strings to bit strings. Informally, the idea is simply to view the octet string as a bit string. Formally, the conversion routine, OS2BSP(M), is specified in Appendix A.2
This memo uses conversion from field elements to integers. An finite field element should be represented as a polynomial with subfield coefficients, which can be represented as a sequence of the coefficients. Informally, the idea is simply to view the sequence of the coefficients as the radix-p^m representation of the base field elements, where p^m is the number of the subfield elements. Formally, the conversion routine, FE2IP(a), is specified in Appendix A.3
This memo uses conversion from integers to field elements. A field element should be represented as a polynomial with subfield coefficients, and it can be represented as a sequence of the coefficients. Informally, the idea is to represent the integer with radix-p^m positional number system where p^m is the number of the subfield element, and then convert the each digit to the each coefficient of the polynomial. Formally, the conversion routine, I2FEP(x), is specified in Appendix A.4:
This memo uses conversion from field elements to octet strings. This conversion is constructed by using FE2IP and I2SOP conversions. Formally, the conversion routine, FE2OSP(a), is specified in Appendix A.5.
This memo uses conversion from octet strings to field elements. This conversion is constructed by using OS2IP and I2FEP conversions. Formally, the conversion routine, OS2FEP(M), is specified in Appendix A.6.
This memo uses conversion from elliptic curve points to octet strings. Informally the idea is that, if point compression is being used, the compressed y-coordinate is placed in the leftmost octet of the octet string along with an indication that point compression is on, and the x-coordinate is placed in the remainder of the octet string; otherwise if point compression is off, the leftmost octet indicates that point compression is off, and remainder of the octet string contains the x-coordinate followed by the y-coordinate. Formally, the conversion routine, ECP2OSP(P,R), is specified in Appendix A.7.
This memo uses conversion from octet strings to elliptic curve points. Informally, the idea is that, if the octet string represents a compressed point, the compressed y-coordinate is recovered from the leftmost octet, the x-coordinate is recovered from the remainder of the octet string, and then the point compression process is reversed; otherwise the leftmost octet of the octet string is removed, the x-coordinate is recovered from the left half of the remaining octet string, and the y-coordinate is recovered from the right half of the remaining octet string. Formally, the conversion routine, OS2ECPP(M), is specified in Appendix A.8.
This section describes building block for constructing FSU Key Exchange.
MGF1 is a mask generation function, parameterized by a hash function. MGF1(M,n) is defined as follows:
System parameters:
Input:
Output:
Method:
Hashed value should be converted to elliptic curve point as described in this section. Formally, the conversion routine, HASHINGTOPOINT(Curve-ID, Hash, M), is specified as follows:
Input:
Output:
Method:
Bit string should be converted to hashed non-negative integer less than an assigned integer as described in this section. Formally, the conversion routine, IHF1(s,n,Hash) is defined as follows:
Input:
Output:
Method:
Octet string should be converted to hashed finite field element as described in this section. Formally, the conversion routine, OS2FQE(s,Hash,F_{p^m}) is defined as follows:
Input:
Output:
Method:
GROUPMEMBERSHIPTEST(Curve-ID, P) is a test function that an elliptic curve point is on the correct curve and group. GROUPMEMBERSHIPTEST is defined as follows:
Input:
Output:
Method:
This section provides the specification of ID-based authenticated key exchange protocol FSU [4] that is an extension of FSU (Fujioka-Suzuki-Ustaoglu) protocol standardized in ISO/IEC11770-3 [5] [6].
Key Generation Center (KGC) defines the following system parameters in FSU:
KGC generates the master secret key MSK and master public key MPK from system parameters as following.
Hash function H_v are defined as H_v(M) = HASHINGTOPOINT(Gv-Curve-ID, Hash, "FSU"||ECP2OSP(Z_1, R)||ECP2OSP(Z_2, R)||M) for v in {1, 2}. Hash function H is defined as H(M) = MGF1("FSU"||ECP2OSP(Z_1, R)||ECP2OSP(Z_2, R)||M, n).
This subsection explains operations of key distribution by KGC. There are two types of static secret key in FSU Key Exchange, respectively static secret key based on cyclic groups in G_1 and in G_2. FSU Key Exchange requires that an initiator and a responder use static secret key with different types, respectively. Hence, KCG needs to define a rule for key distribution for users. For example, clients use static secret keys in G_1 and servers use them in G_2.
KGC generates static secret key D_{i, v} for an identifier ID_i for i in {A, B} of user in G_v as following.
This subsection describes FSU Key Exchange Protocol in an initiator U_A with an identifier ID_A and static secret key D_{A,1} and a responder U_B with an identifier ID_B and static secret key D_{B,2}.
Computation of ephemeral public key by U_A
Computation of ephemeral public key by U_B
Computation of session key by U_B
Computation of session key by U_A
This memo specifies identity-based authenticated key exchange protocol FSU [4] [6] [5] which is secure in the id-eCK(id-based extended Canetti-Krawczyk) security model under the GBDH(gap bilinear DH) assumption [4].
id-eCK security model is the most strong security model in the meaning of that it ensures the safety of session key if any non-trivial combinations of master key, static key, and ephemeral key are leaked.
And id-eCK security model guarantees following 4 security notions:
TBD
TBD
NOTE TO RFC EDITOR: Please remove this section in before final RFC publication.
TBD
| [1] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. |
| [2] | Kasamatsu, K., Kanno, S., Kato, A., Scott, M., Kobayashi, T. and Y. Kawahara, "Barreto-Naehrig Curves", Internet-Draft draft-kasamatsu-bncurves-02, 2015. |
| [3] | Kato, A., Scott, M., Kobayashi, T. and Y. Kawahara, "Barreto-Naehrig Curves", Internet-Draft draft-kato-optimal-ate-pairings-01, 2015. |
Concrete construction of BS2OSP(B) is specified as follows:
Input:
Output:
Method:
Concrete construction of OS2BSP(M) is specified as follows:
Input:
Output:
Method:
Concrete construction of FE2IP(a) is specified as follows:
System parameters:
Input:
Output:
Method:
Concrete construction of I2FEP(x) is specified as follows:
System parameters:
Input:
Output:
Method:
System parameter:
Input:
Output:
Method:
System parameter:
Input:
Output:
Method:
Concrete construction of ECP2OSP(P,R), is specified as follows:
System parameters:
Input:
Output:
Method:
Concrete construction of OS2ECPP(M), is specified as follows:
System parameters
Input:
Output:
Method: