Internet DRAFT - draft-scott-mpinfull
draft-scott-mpinfull
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]
