F. Wei, J. Ma, A. Ge, G. Li, C. Ma
196
undetectable on-line dictionary attacks [19]. In 2005,
Abdalla et al. also proposed an efficient 3PAKE
protocol and proved its security in the random oracle
model [20]. Unfortunately, their protocol still suffers
from the undetectable on-line dictionary attack.
Recently, Farash et al. proposed two 3PAKE protocols
based on Chebyshev chaotic maps [21, 22]. In order
to resist undetectable on-line dictionary attacks, some
researchers designed 3PAKE protocols using server’s
public-keys and symmetric cryptosystems [23-25].
However, the clients need to verify the validity the
server’s public key. This is very inconvenient for the
clients. In this paper, we pay attention to the 3PAKE
protocols that require neither server’s public-keys nor
symmetric cryptosystems.
In 2009, Huang proposed a 3PAKE protocol
without using server’s public-keys and symmetric
cryptosystems [26]. Unfortunately, Yoon et al. found
that Huang’s protocol is insecure against the
undetectable on-line dictionary attack and the off-line
dictionary attack [27]. Meanwhile, Wu et al. also
pointed out that Huang’s protocol is vulnerable to the
key compromise impersonation attack [28]. In 2010,
Lee et al. put forward two novel 3PAKE protocols
without using server’s public-keys [29]. In 2011,
Chang et al. proposed a communication-efficient
3PAKE protocol which requires neither the server’s
public-keys nor symmetric cryptosystems based on
Lee et al.’s protocol [30]. However, Wu et al.
demonstrated that Chang et al.’s protocol is insecure
against partition attacks, by which the adversary can
guess the correct password in an off-line manner [31].
Tso also showed that Chang et al.’s protocol is
vulnerable even to passive attackers [32]. He
presented two improved protocols to remedy the
security flaws of Chang et al.’s protocol. Recently,
Tallapally showed that Huang’s protocol [26] suffers
from the unknown key share attack [33]. To overcome
the shortcomings of Huang’s protocol, Tallapally also
proposed an enhanced 3PAKE protocol. However,
Farash et al. indicated that Tallapally’s protocol [33]
not only is vulnerable to the undetectable on-line
password guessing attack, but also is insecure against
the off-line password guessing attack [34]. They also
put forward an improved 3PAKE protocol to
overcome the security pitfalls of Tallapally’s protocol.
Surprisingly, we found that Farash et al.’s protocol
[34] still suffers from the same attack. In this paper,
we show that Farash et al.’s protocol is insecure
against the partition attack and the off-line dictionary
attack by an insider attacker. Moreover, the
communication cost of Farash et al.’s protocol is
expensive since their protocol needs 5 rounds to work.
To remedy these problems, we propose an improved
3PAKE protocol without using server’s public-keys
and symmetric cryptosystems. The proposed protocol
is provably secure in the random oracle model based
on the GDH assumption. Compared with other related
protocol, our proposed protocol not only achieves
stronger security but also has higher communication
efficiency.
The remainder of this paper is organized as
follows. In Section 2, we briefly review Farash et al.’s
3PAKE protocol. We demonstrate the vulnerabilities
of Farash et al.’s 3PAKE protocol in Section 3. In
Section 4, our improved protocol is described. The
security of our protocol is proven in the random oracle
model in Section 5. We compare the efficiency and
security features of our protocol with related protocols
in Section 6. We conclude our paper in Section 7.
2. Review of Farash et al.’s 3PAKE Protocol
In this section, we will briefly review Farash et
al.’s 3PAKE protocol [34]. For more details, refer to
[34].
2.1. Notations
Some notations used throughout this paper are
summarized in Table 1.
Table 1. Notations
The authentication server
Password shared between A and S
Password shared between B and S
The ring of integers modulo
The non-zero residues modulo
A large prime number with
A multiplicative group of order
A cryptographic hash function
2.2. Protocol description
The detailed steps of Farash et al.’s 3PAKE
protocol, as shown in Fig. 1, are described as follows:
Round 1. The client A chooses
and
computes
. A then sends
to S. Similarly, the client B also selects
and computes
, and
sends
to S.
Round 2. Upon receiving the messages
and
from the client A and B respectively,
S obtains
and
, then chooses a random