Internet-Draft M. Scott, B. Spector, S. Mihaylov Intended Status: Informational MIRACL Ltd Expires: July 29, 2016 January 26, 2016 M-PIN FULL : Zero Knowledge two-Factor Authentication and Key Exchange draft-scott-mpinfull-00 Abstract In this document, the M-PIN FULL protocol for two factor authentication and key exchange is described. This protocol mutually identifies a Client to a Server and the Server to the Client, and agrees between them a cryptographic strong encryption key for subsequent communication. M-PIN FULL requires an external Trusted Authority to issue secrets to participating Clients and Servers. Status of This Memo 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 July 29th, 2016. Copyright Notice 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 Scott Expires July 29, 2016 [Page 1] Internet-Draft M-PIN FULL January 26, 2016 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.0 The M-PIN FULL protocol . . . . . . . . . . . . . . . . . . 4 3.1 System setup and Client registration . . . . . . . . . . . . 4 3.2 Two-Factor Authenticated Key Exchange . . . . . . . . . . . 5 3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Client-Server Authenticated Key Exchange is a cryptographic protocol whereby a Client securely identifies itself to a Server, and visa versa. Traditionally this has been achieved using a protocol like SSL [RFC6101] to authenticate the Server to the Client and to establish a mutual cryptographic key between them. Client authentication to the Server is typically achieved using a Username/Password combination, with the passwords stored in encrypted form on the Server. Typically the Server is itself responsible for enrollment and registration of Clients. This widespread method of Client authentication has serious shortcomings. Often in the event of a security breach at the Server, the encrypted password file might be captured and from this, using standard techniques, the majority of passwords can be recovered. The only defense seems to be the use of increasingly complex passwords, which are difficult to remember. Furthermore the SSL protocol itself has come in for increasing scrutiny, and successful attacks against it have been reported. It is generally agreed that a form of two-factor authentication provides a superior method for Client authentication. The idea is that the Client experience should become very similar to that of extracting money from an Automated Teller Machine (ATM). This is a Scott Expires July 29, 2016 [Page 2] Internet-Draft M-PIN FULL January 26, 2016 familiar experience for many people. The two factors required for authentication are some form of Token, and an easily memorized PIN number, perhaps just 4 decimal digits in length. It is also important that in the event of a Server breach the negative consequences for the Clients should be minimized. For this reason our solution proposes the introduction of a Trusted Authority to handle enrollment and registration of Clients, and to relieve the Server of this burden and responsibility. The Server itself is only in possession of a single small secret issued to it by the Trusted Authority. Previously there was no known protocol which allowed for this type of two-factor authentication which was not open to so-called insider attacks, or off-line dictionary attacks. This has necessitated the issuance of the Token in the potentially expensive form-factor of an autonomous hardware device. The protocol proposed here can be implemented entirely in software. The token is typically just 512 bits of data. Note that this proposal is derived from [MPIN], a simpler protocol which performs only client-side authentication, without key exchange. 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.1 Definitions Two-Factor Authentication: Two-factor Authentication is a technology which allows a Client to authenticate itself via an identity string to a Server using two independent sources of data. These MUST be such that knowledge of one factor does not reveal the other factor. Any third party who obtains by whatever means one factor for a certain identity MUST NOT be able to authenticate themselves to the Server in that identity. Digital Identity: Digital Identity is the data that uniquely describes a person or a thing, and typically contains some information about that entity's relationships. 2.2 Abbreviations Scott Expires July 29, 2016 [Page 3] Internet-Draft M-PIN FULL January 26, 2016 AKE Authenticated Key Exchange TA Trusted Authority AES Advanced Encryption Standard 2.3 Conventions o E is an ordinary pairing-friendly elliptic curve over a finite field F, defined by a fixed prime modulus p. o e: G1 X G2 -> GT is a computable bi-linear map on E. G1 is defined as a group of points on E. G2 is defined as a group of points on a twist of E. Both groups are of prime order q. GT is a finite extension field of F, also of order q. o s is a large positive integer less than q, the master secret belonging to the TA and associated with a particular Server. o H1 is a well known hash function that takes the data associated with Alice's digital identity and assigns it to a point in G1, e.g. H1("Alice@example.com") = A, a point on E in G1. o Hg is a well known hash function which serializes its concatenated inputs, and hashes them to a 256-bit number. For example Hg(A|B) serializes objects A and B into bit strings, concatenates them, and hashes them to a unique 256-bit value. o D=sA is the private key computed by the TA for Alice, and delivered only to Alice. In a similar fashion private keys are issued to all other Clients of the same Server. o S=sQ is the private key computed by the TA for this Server, where Q is a public point on G2. o TOKID is the Token belonging to identity ID, and PINID is the PIN chosen by identity ID. 3.0 The M-PIN FULL protocol 3.1 System setup and Client registration The TA chooses a suitable elliptic curve and defines the groups G1, G2 and GT. To be concrete the TA chooses a BN curve [BN] with parameter x=-0x4080000000000001. This generates a curve with overall security equivalent to AES at the 128-bit level [AES], and which is quite efficient for computation. The TA chooses and makes public a point Q in G2. Scott Expires July 29, 2016 [Page 4] Internet-Draft M-PIN FULL January 26, 2016 The TA generates a master secret s, which is reserved for use with a particular Server. The Server is issued with the secret S=sQ. This is a point multiplication in the group G2. Note that knowledge of S and Q does not reveal s, as it is protected by a known hard problem, the discrete logarithm problem. Clients such as Alice approach the TA and are issued with a secret D=sA, where A is Alice's digital identity hashed to a point in G1. Alice then chooses a PIN number PINA and calculates her token as TOKA=D-PINA.A. In effect her PIN number is subtracted from her secret. The Client is also issued with the pre-calculated values g1=e(sA,Q) and g2=e(A,Q), and the Client modifies g1=g1/g2^PINA=e((s- PINA)A,Q). Both g1 and g2 are stored by the Client. Alice is now ready to identify herself to, and exchange a key with, the Server. 3.2 Two-Factor Authenticated Key Exchange Initially the Client hashes her digital identity "Alice@example.com" to a point A using the hash function H1, and selects random x and r. The Client MUST use fresh, random values of x and r for each run of the protocol. The Server selects random y and w. The Server MUST use fresh, random values of y and w for each run of the protocol. Client --------> Server "Alice@example.com", U=xA Server ---------> Client y, W=wA Client ---------> Server V=-(x+y)(TOKA+PINA.A), R=rA The Server itself calculates A by applying the hash function H1 to the claimed digital identity. Then the Server SHALL check that e(V,Q).e(U+yA,sQ) = 1. If it is not the connection is terminated by the Server, and the attempted Client connection is rejected. The Client will now calculate K=Hg((g1.g2^PINA)^r|xW). If the protocol has been entered into correctly by both parties the Server will calculate the same value as K=Hg(e(R,sQ)|wU). The Client and Server will then calculate the same AES key as the first 128 bits of K. As an alternative flow the Client MAY itself calculate A by applying the hash function H1 to its own digital identity, and instead Scott Expires July 29, 2016 [Page 5] Internet-Draft M-PIN FULL January 26, 2016 transmit A in the first step of the protocol. If the protocol terminates successfully Alice can transmit her actual digital identity under the protection of the agreed key. The Server should then apply the hash function H1 to this identity, and check that the result is the same as the A value transmitted in the first step. This avoids the necessity of the digital identity being transmitted in the clear. 3.3 Discussion o Clients authenticate to a Server using the M-PIN protocol [MPIN}. The Server authenticates to the client by successfully deriving the same key. This is dependent on the Client having been issued with a secret D=sA (reconstructed when the Token and the PIN are recombined), and on the Server possessing a multiple of the same s in G2, the value of sQ. o The TA with its knowledge of the master secret s represents a potential single-point-of-failure for the scheme. However, without going into further detail, we point out here that the TA function can be distributed in a multiplicity of ways using a standard secret sharing scheme. In its simplest manifestation there might be 2 TAs, each one of which issues a part-secret (so s=s1+s2), and both of which would have to be compromised to determine the master secret. o Implementation considerations: An implementation of M-PIN FULL is particularly lightweight on the Client side. Only four point multiplications in G1 are required and an exponentiation in GT. Of particular note is that the Client is not required to calculate an expensive pairing. This will be reasonably fast on the Client side even if carried out within a browser. On the Server side the product of two pairings can be calculated much more efficiently than two single pairings. o It is assumed that the Server will be implementing some kind of mechanism to prevent someone who does not know the PIN from attempting to guess it by making a multiplicity of authentication attempts. Such a mechanism and its implementation are outside of the scope of this draft. o The key exchange supports the desirable feature known as full forward secrecy. This means that in the event that all system secrets are revealed at some time in the future, recorded key exchanges are still secure. 4. Security Considerations Scott Expires July 29, 2016 [Page 6] Internet-Draft M-PIN FULL January 26, 2016 Two-Factor authentication methods can be vulnerable to off-line dictionary attacks. Here an attacker might capture one authentication factor from their victim, typically the token, and then try to use this along with other information, perhaps gleaned from previously recorded protocol runs or other information, to determine their PIN. One manifestation of such an attack might be an "insider" attack whereby another Client Bob with his own secret might capture the token of Alice and by some efficient computation arrive at her PIN number. Another powerful attacker might be an entity which successfully breaches the security of the Server and comes away with its secret sQ. It should not be possible for such an entity to determine a Client's secret, or to authenticate to the Server in the name of a Client. However the server secret sQ is in the group G2, and therefore cannot be used to authenticate to the genuine server, as it expects to receive from a Client only elements of G1. Here we achieve immunity from such attacks by the expedient of implementing the protocol on an ordinary pairing friendly elliptic curve, such that G1 and G2 are distinct groups, albeit of the same order. This idea was first suggested in [Scott]. The XDH assumption [Scott], [BGMM] is that in the context of a pairing, that the Decisional Diffie-Hellman problem is hard in the group G1. 5. IANA Considerations At this time there are no IANA considerations 6. References 6.1 Normative References [RFC6101] Freier A., Karlton P., Kocher P., "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011 [RFC2119] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 6.2 Informative References [AES] National Institute of Standards and Technology, "Specification Scott Expires July 29, 2016 [Page 7] Internet-Draft M-PIN FULL January 26, 2016 for the Advanced Encryption Standard (AES)", FIPS 197, November 2001. [BGMM] Ballard, L., Green, M., de Medeiros B., and Monrose, F., "Correlation-Resistant Storage via Keyword-Searchable Encryption", Cryptology ePrint Archive, Report 2005/417 [BN] Barreto, P., Naehrig, M., "Pairing-Friendly elliptic curves of prime order", SAC 2005, LNCS 3897, Springer-Verlag (2006), pp. 319- 331. [MPIN] Scott, M., Spector, B., Yamamoto, G., "Zero-Knowledge two- factor authentication for digital identity", https://tools.ietf.org/html/draft-scott-mpin-00 [Scott] Scott, M., "Authenticated ID-based Key Exchange and remote log-in with simple token and PIN number", Cryptology ePrint Archive, Report 2002/164 Authors' Addresses Michael Scott 4 Foster Place North Ballybough Dublin 3 Ireland Email: mike.scott@miracl.com Brian Spector 81 Rivington Street London EC2A 3AY England Email: brian.spector@miracl.com Stanislav Mihaylov 63 Kazbek str. Sofia, 1680 Bulgaria Email: stanislav.mihaylov@miracl.com Scott Expires July 29, 2016 [Page 8]