Robust and Simple Authentication Protocol - Semantic Scholar

3 downloads 0 Views 137KB Size Report
[10] launched the replay attack and the denial- of-service attack on the SAS protocol and proposed their. Optimal Strong-Password Authentication (OSPA) ...
c British Computer Society 2003 

Robust and Simple Authentication Protocol H UNG -Y U C HIEN1,2

AND J INN -K E JAN 2

1 Department of Information Management, NanKai College, NanTou, Taiwan, Republic of China 2 Institute of Computer Science, National Chung Hsing University, Taichung, Taiwan,

Republic of China Email: [email protected] Password-based authentication protocols are currently the conventional authentication protocols in many distributed systems. However, the security of these protocols is falling behind the times because more and more attacks can now break them. The security weaknesses of the Simple And Secure (SAS) protocol, the Optimal Strong-Password Authentication (OSPA) protocol, and the revised SAS protocols are examined in this paper. We then propose our RObust and SImple (ROSI) protocol to help raise security levels. The ROSI protocol can be easily implemented and has lower communication costs than most other protocols. Received 17 December 2001; revised 15 July 2002

1. INTRODUCTION Password-based protocols are currently the mainstream authentication protocols in many distributed environments. In these protocols, there are basically two approaches to the generation of passwords: (1) users choose passwords by themselves and (2) users use computer-generated passwords. A password chosen by a user has low entropy, and the user can easily memorize a weak password. A weak password is also called a weak key [1, 2]. In contrast, a computer can randomly generate strong passwords (also called strong keys) with high entropy, but it is difficult for users to memorize these computer-generated passwords (strong keys). Therefore, trusted devices (for example, smart cards) are usually needed to store strong passwords. Weak password protocols are vulnerable to the password guessing attack, also called the dictionary attack [1, 2, 3, 4], because of their low entropy [1, 2, 3, 4]. The password guessing attack is launched by establishing a dictionary of common keys or user-information-related keys and using the dictionary words one by one to make attacks. Due to the low entropy of weak passwords and the availability of attack tools over the Internet, the password-guessing attack is very popular and is powerful against weak-password-based authentication protocols. An attacker can use the dictionary in two major ways [1, 2, 3]. One is the off-line guessing attack, where the attacker records the communication data of legal users’ requests and then goes over the dictionary to launch attacks. The attacker selects one password after another from the dictionary, computes the transmission values with the chosen password and then searches for a match in the recorded data. If a match is found, then the T HE C OMPUTER J OURNAL,

chosen password is the real password. The second dictionary attack is the on-line guessing attack. The attacker selects one password after another from the dictionary and then uses these passwords to masquerade as the legal user to send a service request. If the request fails, the attacker selects another password and tries again. The standard ways of preventing such on-line attacks are to either limit the number of failed runs before the password becomes expired or reduce the rate at which the user is allowed to make requests [1, 2]. Many schemes [1, 2, 3] have used public key algorithms or Diffie–Hellman algorithms to withstand off-line guessing attacks. These schemes place high computational load on the system. Their deployment is therefore limited. Based on only the hashing operation, Sandirigama et al. [5] proposed the Simple And Secure (SAS) authentication protocol. The SAS protocol is aimed to withstand the manin-the-middle attack that can break the previous protocols [6, 7, 8]. Not requiring memory for storing random numbers on the client’s side, the SAS protocol requires no IC card (or smartcard) [9] support. Moreover, it requires no resetting of passwords and has low computation and communication costs. These features make it more attractive than others [6, 7, 8]. However, the protocol is vulnerable to the guessing attack (which will be demonstrated in Section 3), in addition to the weaknesses reported by Lin et al. [10] as well as Kamioka and Shimizu [11]. Lin et al. [10] launched the replay attack and the denialof-service attack on the SAS protocol and proposed their Optimal Strong-Password Authentication (OSPA) protocol. Rather than using public key algorithms, Lin et al. used an IC card to store well-chosen passwords, so-called ‘strong passwords’ or ‘strong keys’, to achieve security against Vol. 46, No. 2, 2003

194

H UNG -Y U C HIEN AND J INN -K E JAN

the guessing attack. Lin et al. claimed that the protocol could withstand all the above attacks. However, in this paper, we will show that the OSPA protocol actually suffers from the stolen-verifier problem. In many authentication protocols, the server stores the verifiers of user passwords (for example, the hashed passwords). There is one verifier corresponding to each registered user, and these verifiers are stored in disk and in memory. This gives an attacker the chance to steal the verifiers. An attacker who steals a password verifier from the server can use the verifier to launch an impersonation attack or a denial-of-service attack. This is called the stolen verifier problem [3, 10, 12, 13]. Recently, Kamioka and Shimizu [11] have proposed their revised SAS protocols to enhance security. There are two versions of the revised SAS protocol. One version requires the support of an IC card, but the other does not. However, the revised SAS protocols will be proved in this paper to suffer from the stolen-verifier problem and one of them cannot even resist the password guessing attack. In several authentication protocols [4, 10, 13, 14], the timestamp is used to withstand the replay attack. This approach requires clock synchronization among distributed systems. However, some protocols [15] use techniques based on nonce to withstand the replay attack. In the OSPA protocol, a changeable stored verifier is used to withstand the replay attack. In distributed environments, many masqueraded user attacks and an increasing number of masqueraded server attacks have been reported in recent years [4, 16]. The attackers set up a fake server to cheat the users into submitting their sensitive data. Therefore, a secure protocol should support mutual authentication rather than merely unilateral authentication. A mutual authentication protocol allows both the client and the server to authenticate each other, but a unilateral authentication protocol only authenticates the client. The SAS protocol, the revised SAS protocols and the OSPA protocol, unfortunately, only support unilateral authentication. This paper shows the effectiveness of the guessing attack on the SAS protocol, the stolen-verifier problem with the OSPA protocol and the security weaknesses of the revised SAS protocols. We then propose our RObust and SImple (ROSI) authentication protocol to overcome those problems. The ROSI protocol has the following characteristics: (1) it is a smart-card-based protocol; (2) it requires only two message interaction sessions to achieve mutual authentication; (3) it requires only a hashing operation and an exclusive OR operation; (4) it requires little storage space; and (5) it withstands all the previously mentioned attacks. The rest of this paper is organized as follows. Section 2 reviews the SAS protocol, the OSPA protocol and the revised SAS protocols. Section 3 then presents the security weaknesses of the SAS protocol, the revised SAS protocols and the OSPA protocol. After that, in Section 4, we introduce our ROSI protocol, followed by the security examination and performance evaluation which is presented in Section 5. Finally, in Section 6 we draw our conclusions. T HE C OMPUTER J OURNAL,

2. REVIEW OF THE SAS, OSPA AND REVISED SAS PROTOCOLS Before reviewing the protocols, we first introduce the notation. Throughout this paper, h() denotes a secure oneway hash function such as MD5 or SHA. Thus, h(x) implies that x is hashed once and h2 (x) means that x is hashed twice. The symbol S denotes the password and Ni denotes the ith nonce. The symbol  denotes concatenation and ⊕ denotes the bit-wise XOR operation. 2.1. The SAS protocol The SAS protocol consists of two phases—registration and authentication. The registration phase is executed only once and the authentication phase is executed whenever a user wants to login. In the registration phase, the user provides her/his identity UID , h2 (S  N1 ), and the initial nonce N1 through a secure channel. The server stores UID , h2 (S  N1 ) and N1 in the database. After the registration, the user can enter the authentication phase to log in. The following steps describe the ith authentication session, during which the server stores h2 (S  Ni ) and Ni for the client. 1.

2. 3. 4.

User → Server: Service request (the service request contains the necessary information, such as the user’s identity UID ). Server → User: Ni . User → Server: h(S  Ni ) ⊕ h2 (S  Ni ), h2 (S  Ni+1 ) ⊕ h2 (S  Ni ), Ni+1 . Server: Upon receiving the data in Step 3, the server extracts h(S  Ni ) by XORing h(S  Ni ) ⊕ h2 (S  Ni ) with the stored h2 (S  Ni ). The server again applies the hash operation to the derived h(S  Ni ) to check whether h(h(S  Ni )) equals the stored h2 (S  Ni ). If so, it accepts this authentication request and derives h2 (S  Ni+1 ) by XORing h2 (S  Ni+1 ) ⊕ h2 (S  Ni ) and h2 (S  Ni ). Finally, the server stores h2 (S  Ni+1 ) and Ni+1 for the next authentication session.

2.2. The OSPA protocol The OSPA protocol uses a smart card to store a wellchosen strong password that can resist the guessing attack. The protocol consists of two phases—registration and authentication. In the registration phase, the user provides her/his identity UID and h2 (S ⊕ 1) through a secure channel. The server stores UID and h2 (S ⊕ 1), and then it sets n =1 in the database. After registration, the user may enter the authentication phase to login. The nth authentication session is described as follows (see Figure 1). 1.

2. 3. 4.

User → Server: Service request (the service request contains the necessary information, such as the user’s identity UID ). Server → User: n. User → Server: c1 = h(S ⊕ n) ⊕ h2 (S ⊕ n), c2 = h2 (S ⊕ (n + 1)) ⊕ h(S ⊕ n), c3 = h3 (S ⊕ (n + 1)). Server: Upon receiving the data in Step 3, the server first checks whether c1 = c2 . If so, the server extracts

Vol. 46, No. 2, 2003

ROBUST AND S IMPLE AUTHENTICATION P ROTOCOL

User

195

Server Store UID, h2(S

UID, Service request n

#n) #h (S#n) c =h (S#(n+1))#h(S#n) c =h (S#(n+1))

c1=h(S

#n), n=i

2

2

2

3

3

c2 Extract h (S#(n+1)),h(S#n) If h(h(S#n))=stored h (S#n), and h(h (S#(n+1)))=c3, the user is Check c1

2

2

2

authenticated. Update h2(S

#(n+1)), set n=n+1

FIGURE 1. The nth authentication phase of OSPA.

User

Server UID, h( S || N i ) ⊕ h 3 ( S || N i +1 ) , h 2 ( S || N i +1 ) ⊕ h 2 ( S || N i )

and h 3 ( S || N i +1 ) 2. Compute h( S || N i ) =( h( S || N i ) ⊕ h 3 ( S || N i +1 ) )

1. Derive h 2 ( S || N i +1 ) ⊕ h 3 ( S || N i +1 )

3. Verify whether h(h( S || N i )) equals h 2 ( S || N i )

FIGURE 2. The ith authentication phase of the revised SAS-1.

h(S ⊕ n) by XORing c1 with the stored h2 (S ⊕ n) and then derives h2 (S ⊕ (n + 1)) by XORing c2 with h(S ⊕ n). Finally, the server applies the hashing operation to the derived h2 (S ⊕ (n + 1)) and checks whether h(h2 (S ⊕ (n + 1))) equals c3 . If so, the server accepts this request and then updates h2 (S ⊕ (n + 1)) and sets n = n + 1 for the next authentication session.

2.3.1. Revised SAS-1 The revised SAS-1 uses an IC card to generate and store the random number Ni . In the ith authentication session (see Figure 2), the smart card generates and sends the message {user’s identity, h(S  Ni ) ⊕ h3 (S  Ni+1 ), h2 (S  Ni+1 ) ⊕ h2 (S  Ni )} to the server. Upon receiving the message, the server first uses the stored value h2 (S  Ni ) and the received data to derive h2 (S  Ni+1 ), and then it computes

2.3. The revised SAS protocols In 2001, Kamioka and Shimizu proposed two revised SAS protocols to enhance security. One requires the support of an IC card and the other does not. The first one is called the revised SAS-1 here in this paper and the second one the revised SAS-2. Both of the protocols consist of two phases—registration and authentication. The registration phases of the two revised protocols are the same as that of the SAS protocol. The authentication phases of the revised SAS-1 and the revised SAS-2 are introduced here. T HE C OMPUTER J OURNAL,

h3 (S  Ni+1 ) = h(h2 (S  Ni+1 )). The server then computes h(S  Ni ) = (h(S  Ni ) ⊕ h3 (S  Ni+1 )) ⊕ h3 (S  Ni+1 ). Finally, the server verifies whether h(h(S  Ni )) equals the stored h2 (S  Ni ). If so, it accepts this request and updates the value h2 (S  Ni+1 ) for the next authentication. Vol. 46, No. 2, 2003

196

H UNG -Y U C HIEN AND J INN -K E JAN

User

Server

User’s identity, request

Store counter=n, h 2 ( S || n )

counter=n UID, h( S || n) ⊕ h 3 ( S || n + 1) , h 2 ( S || n + 1) ⊕ h 2 (S || n)

1. Derive h 2 ( S || n + 1)

and

h 3 ( S || n + 1)

2. Compute h( S || n) =( h(S || n) ⊕ h3 (S || n + 1) ) ⊕ h 3 ( S || n + 1)

3. Verify whether h(h( S || n)) equals h 2 ( S || n)

FIGURE 3. The nth authentication session of the revised SAS-2.

2.3.2. Revised SAS-2 In the revised SAS-2, the server takes down the number of authentication sessions each user has been through by using a counter, so therefore the user does not require the support of an IC card. The protocol is similar to the revised SAS-1, except that the random nonce Ni is replaced with the counter n (see Figure 3). 3. THE SECURITY WEAKNESSES OF THE SAS PROTOCOL, THE OSPA PROTOCOL AND THE REVISED SAS PROTOCOLS Lin et al. [10] demonstrated that the replay attack and the denial-of-service attack could smash the SAS protocol. However, a far more serious weakness should also be considered. The guessing attack is a powerful attack on the weak-password-based authentication protocol. Nowadays, even a computer novice can easily obtain attack tools on the Internet. The SAS protocol is vulnerable to the guessing attack. On the other hand, the OSPA protocol is claimed to be resistant to the stolen-verifier problem. However, this paper will show that a thief can masquerade as a legal user and launch the denial-of-service attack once she/he has stolen the stored verifier. Kamioka and Shimizu enhanced the SAS protocol and proposed the revised SAS protocols. However, the revised protocols are still affected by the stolen-verifier problem and, what is worse, the revised SAS2 protocol cannot even resist the guessing attack. 3.1. Guessing attack on the SAS protocol An authentication protocol is vulnerable to the off-line guessing attack if (1) users are allowed to choose weak passwords and (2) the attacker can verify her/his guessed passwords via the recorded communication data. The strength of the hash function does not hinder the guessing attack, since the function is public and the attacker does not need to compute the seed x from a hashed value h(x) T HE C OMPUTER J OURNAL,

[1, 2, 13]. Now, let us take the off-line guessing attack on the SAS protocol. First, the attacker eavesdrops the communication data of some legal users and records the sets {Ni , h(S  Ni ) ⊕ h2 (S  Ni )}. Then the attacker picks out one candidate password S  after another from the dictionary—many tools are available on the Internet to build up a dictionary—and computes h(S   Ni ) ⊕ h2 (S   Ni ) by using the chosen candidate password S  and the nonce Ni (which is sent clearly). Then the attacker searches the recorded data to see whether a match exists. If a match is found, then the chosen password is the real password. 3.2. Stolen-verifier problem with the OSPA protocol The stolen-verifier problem with the OSPA protocol can occur like this. Once the attacker has stolen the verifier, she/he can intercept the legal user’s transmitted data, modify the data by using the stolen verifier and then send the modified data to the server. The server will accept the modified request as a valid one. Assume that the attacker has stolen the verifier h2 (S ⊕ n) from the server. Now, if the attacker intercepts the user’s transmitted data c1 = h(S ⊕ n) ⊕ h2 (S ⊕ n), c2 = h2 (S ⊕ (n + 1)) ⊕ h(S ⊕ n) and c3 = h3 (S ⊕ (n + 1)), she/he then extracts h(S ⊕ n) by XORing c1 with the stolen verifier h2 (S ⊕ n). Then she/he chooses a random number X and computes c2 = h(X) ⊕ h(S ⊕ n) and c3 = h2 (X). Finally, she/he sends (c1 , c2 , c3 ) to the server. The modified data can easily pass the server’s verification. The server accepts this false request, updates the verifier as h(X) and sets n = n+1. From now on, the attacker can masquerade as the legal user. For example, the attacker can send c1 = X ⊕ h(X), c2 = h(Y ) ⊕ X and c3 = h2 (Y ) for the next session, where Y is a randomly selected number and Y = X. The server will accept this request, update the verifier as h(Y ) and set n = n + 1. The attack also results in the denial-of-service problem. After the server has updated the verifier as h(X), the Vol. 46, No. 2, 2003

ROBUST AND S IMPLE AUTHENTICATION P ROTOCOL

User

 û »æ á ) û»æ á ¼

UID, c1=h(h(x||UID) h2(S||Ni)) c2=h3(S||áü¾Ä



Å



ü¾Ä

197

Server

¼,

Store UID, h2(S||Ni)

ü

Compute h(x||UID),



c’1=h(h(x||UID) h2(S||Ni)),



Extract h2(S||Ni+1)=c1 c’1,

h(h (S||N

h(S||Ni)=c2

2

i+1))

Check whether h(h(S||Ni))=stored h2(S||Ni),

h3(S||áü¾Ä) Verify the received h3(S||áü¾Ä)

h (S||N ) 2

i

If so, the user is authenticated. Update h2(S||Ni+1).

h (S||N ) 2

i

Replace the stored h(S||Ni) with h(S||Ni+1) FIGURE 4. The ith authentication phase of ROSI.

legal user cannot login any more. After a few trials, the server will reject the legal user’s request. Although the user may become suspicious and report the situation to the authority, the attacker has illegally accessed the resource in the meantime.

S  after another from the dictionary, computes c1 = h(S   n) ⊕ h3 (S   n + 1) and c2 = h2 (S   n + 1) ⊕ h2 (S   n), and searches the recorded data to find a match. If a match is found, then the chosen password, namely S  , is the real password.

3.3. Security weaknesses of the revised SAS protocols

4. THE RObust AND SImple (ROSI) PROTOCOL

The stolen-verifier problem and the denial-of-service problem with the revised SAS protocols and the off-line guessing attack on the revised SAS-2 are considered here.

In this section, we present the new RObust and SImple (ROSI) authentication protocol that assumes the use of an IC card. The ROSI protocol allows a user to freely choose her/his easily memorized password and store a strong secret key in her/his IC card. Such an arrangement has at least two merits as follows: (1) a user can easily memorize her/his password and (2) the protocol can resist the guessing attack without using a computationally intensive public key algorithm. The ROSI protocol is also composed of two phases— registration and authentication. In the registration phase, the user provides her/his identity, UID , his password, S, and the nonce, N1 , to the server through a secure channel. The server stores UID and h2 (S  N1 ) in its database. The server also writes the data R = h(x  UID ) ⊕ S and h(S  N1 ) into the user’s tamper-resistant smart card, where x is the server’s strong secret key, which is a computer-generated secret key that has a long bit length and high entropy. Note that, in verifier-using methods, there is one password verifier for each registered user and these verifiers should be stored in disk and in memory. This gives the attacker a chance to steal the verifiers. Any attacker who steals the password verifier from the server can use the verifier to launch an impersonation attack or a denial-of-service attack. In contrast, the x in our method is the server secret key that may be stored in ROM or EPROM with stronger protection, which means much better robustness than the

3.3.1. Stolen-verifier problem and denial-of-service problem with the revised SAS-1 and SAS-2 protocols Assume an attacker has stolen the verifier h2 (S  Ni ) in the revised SAS-1. Now she/he intercepts the ith authentication data {h(S  Ni ) ⊕ h3 (S  Ni+1 ), h2 (S  Ni+1 ) ⊕ h2 (S  Ni )}. Using the data and the verifier, she/he can derive h2 (S  Ni+1 ), h3 (S  Ni+1 ) and h(S  Ni ). The attacker randomly chooses a number X and prepares a forged request message as {user’s identity, h(S  Ni ) ⊕ h3 (X), h2 (X) ⊕ h2 (S  Ni )}. The server can be easily cheated and accepts this request and then updates the verifier as h2 (X). From now on, the attacker can masquerade as the user, since she/he knows the seed X of the verifier h2 (X). This impersonation attack also results in the denial-of-service problem because the user no longer knows the new seed of the verifier, namely h2 (X). The same attack can also be plotted against the revised SAS-2. 3.3.2. Off-line guessing attack on the revised SAS-2 After eavesdropping on a set of communication data {user’s identity, n, h(S  n) ⊕ h3 (S  n + 1), h2 (S  n+1)⊕h2 (S  n)}, the attacker tries one potential password T HE C OMPUTER J OURNAL,

Vol. 46, No. 2, 2003

198

H UNG -Y U C HIEN AND J INN -K E JAN

management of those verifiers [13, 17]. Finally, the server issues the card to the user. After the registration phase, the user executes the authentication procedure to login to the server. The following steps are those to be taken in the ith authentication session (see Figure 4), during which the server stores h2 (S  Ni ) in the database and the card stores h(S  Ni ) and R = h(x  UID ) ⊕ S in its memory. 1.

2.

3.

4.

User → Server: The user inputs UID and her/his password S into her/his smart card. The card extracts h(x  UID ) by XORing R with S, selects a new random number Ni+1 and computes c1 = h(h(x  UID ) ⊕ h2 (S  Ni )) ⊕ h2 (S  Ni+1 ) and c2 = h3 (S  Ni+1 ) ⊕ h(S  Ni ) by using Ni+1 , S and h(S  Ni ). The card then sends the login request that contains (UID , c1 , c2 ) to the server. Server: Upon receiving the data from Step 1, the server computes h(x  UID ) by using the server’s secret key x and the user identity, UID , and then it computes c1 = h(h(x  UID ) ⊕ h2 (S  Ni )), where h2 (S  Ni ) is the stored verifier for the user. The server extracts h2 (S  Ni+1 ) by XORing c1 and c1 and then it extracts h(S  Ni ) by XORing c2 with h(h2 (S  Ni+1 )). The server then applies the hash operation to the derived h(S  Ni ) to check whether h(h(S  Ni )) equals the stored h2 (S  Ni ). If so, it accepts this authentication request and stores h2 (S  Ni+1 ) for the next authentication session. Server → User: If Step 2 is successful, the server prepares and sends h2 (S  Ni ) ⊕ h3 (S  Ni+1 ) to the user. User: The user (the card) verifies the received data h2 (S  Ni ) ⊕ h3 (S  Ni+1 ). If the verification succeeds, the user authenticates the server and replaces the stored h(S  Ni ) with h(S  Ni+1 ).

5. SECURITY ANALYSIS AND PERFORMANCE EVALUATION 5.1. Security analysis As illustrated in the previous section, the ROSI protocol achieves mutual authentication in two message interactions, while the SAS protocol achieves unilateral authentication in three interactions. A secure unilateral authentication protocol can be extended to a mutual authentication protocol, but the extension should be carefully examined to prevent the occurrence of any security weakness. The security of the ROSI protocol against various attacks is examined below. 5.1.1. Replay attack The attacker plots a replay attack by recording the transmission data of legal users and then resends the messages later [10]. Even though the ROSI protocol does not use a timestamp, it can still withstand the replay attack. In the ROSI protocol, each new session request should be synchronized with the server’s currently stored verifier, T HE C OMPUTER J OURNAL,

h2 (S  Ni ); therefore, a simple replayed message will not pass the server’s verification. 5.1.2. Impersonation attack The attacker launches an impersonation attack by masquerading as a legal user and generates a request message for the user [4, 10, 12, 14, 15]. Generating a valid login request in the ROSI protocol requires the knowledge of both h(x  UID ) and h(S  Ni ); however, these values are stored in a tamper-resistant device and only the legal user who inputs the right password, S, can trigger the card to correctly yield the values. Therefore, the impersonation attack fails. 5.1.3. Modification attack (or man-in-the-middle attack) The attacker plots a modification attack by modifying the transmitted data when she/he has intercepted a legal user’s request message or has eavesdropped on an old transmission message [4, 10, 12, 14, 15]. The man-in-the-middle attack [10, 12] takes place when the attacker, who sits between the client and the server, tries to cheat either side by eavesdropping on the transmission data, modifying the message and then relaying the modified message. Both the modification attack and the man-in-the-middle attack on the ROSI protocol fail. Modifying c1 of Step 1 will cause the server to fail on recovering the correct h(S  Ni ) from c2 , and modifying c2 of Step 1 also causes the server to fail on recovering the correct h(S  Ni ). The server will reject the request when it cannot recover the correct h(S  Ni ) to check whether h(h(S  Ni )) equals the stored value h2 (S  Ni ). The attacker must know both h(x  UID ) and h(S  Ni ) before she/he can modify both c1 and c2 simultaneously while maintaining the validity of the modified data, which is infeasible because only the right user who inputs the correct password into the tamper-resistant device can derive both of the secret values. 5.1.4. Stolen-verifier problem An attacker who steals the user’s verifier may use the stolen verifier to launch an impersonation attack, a modification attack or a denial-of-service attack [3, 12, 13]. The revised SAS protocols and the OSPA protocol suffer from the stolen-verifier problem because any entity (the server or the attacker) that has the verifier can verify the request data and forge some extra valid requests from the eavesdropped data in these protocols. However, this attack cannot be successfully launched on the ROSI protocols for the following reasons. (1) The value h(x  UID ) and the verifier h2 (S  Ni ) must be known before the attacker can verify a request in the ROSI protocol, which is not likely to happen. (2) The values h(x  UID ), h2 (S  Ni ) and h(S  Ni ) must be known simultaneously to generate a valid request, which is, again, infeasible for the attacker. (3) The attacker who has stolen the verifier h2 (S  Ni ) cannot derive any further value from the user’s request data during the unilateral authentication phase. She/he can only derive the value h3 (S  Ni+1 ) from the Vol. 46, No. 2, 2003

ROBUST AND S IMPLE AUTHENTICATION P ROTOCOL server’s response (in the mutual authentication phase) and then derive the value h(S  Ni ) from the user’s request data by using this value h3 (S  Ni+1 ). However, the attacker cannot launch any successful attack because she/he has no access to the value h(x  UID ). Since the attacker cannot make up any valid message, she/he cannot launch the denial-of-service attack. Even if the attacker has miraculously stolen two consecutive verifiers h2 (S  Ni ) and h2 (S  Ni+1 ), she/he still cannot launch any attack since she/he cannot acquire h(x  UID ). 5.1.5. Guessing attack An authentication protocol may be vulnerable to the guessing attack if the user is allowed to use a weak password (weak key) [1, 2, 3]. An attacker would be able to verify her/his guessed password S  by using the eavesdropped data. Verifying the guessed password in the ROSI protocol requires that the attacker has obtained the server’s secret key x, the random numbers Ni and Ni+1 , and the password S  , where the random numbers Ni and Ni+1 as well as the secret key x have high entropy and are well protected by the secure one-way function h( ). Obtaining the key x and the random numbers is infeasible; therefore, the off-line guessing attack is bound to fail. The standard means of preventing the online guessing attack can be applied in our scheme and so the on-line guessing attack will also fail. 5.1.6. Masquerading as the server The ROSI protocol aims to achieve mutual authentication. Let us consider the masqueraded server attack here. The attacker must prepare the data h2 (S  Ni ) ⊕ h3 (S  Ni+1 ) in Step 4 to masquerade as the server, which requires the knowledge of the values h2 (S  Ni ) and h3 (S  Ni+1 ). However, only the legal server who knows the secret value h(x  UID ) can derive h3 (S  Ni+1 ) from c2 in Step 2. Therefore, the masqueraded server attack fails. 5.2. Performance evaluation This section examines the robustness of our ROSI protocol as well as the referenced protocols and evaluates their performance. First of all, let us examine the security. The SAS protocol and the revised SAS-2 protocol require no IC card support. In contrast, the OSPA protocol and the ROSI protocol adopt the IC card. Unfortunately, the SAS protocol and the revised SAS-2 protocol are vulnerable to the guessing attack, in addition to the weaknesses reported by Lin et al. [10] and Kamioka and Shimizu [11]. The revised SAS-2 protocol and the OSPA protocol are also vulnerable to the stolenverifier problem in which an attacker can successfully launch the denial-of-service attack and the impersonation attack. As more and more server masquerading incidents have been reported [4, 16], mutual authentication is becoming more and more indispensable. Only the ROSI protocol can withstand all the mentioned attacks and provide mutual authentication. T HE C OMPUTER J OURNAL,

199

Next, we compare the number of interactions. The ROSI protocol provides mutual authentication in two interactions and demands only one interaction when unilateral authentication is required. In contrast, the SAS protocol and the OSPA protocol provide only unilateral authentication and they take three interactions. The revised SAS-1 achieves unilateral authentication in one message interaction and the revised SAS-2 requires three message interactions. In terms of the number of interactions, the ROSI protocol outperforms the SAS protocol, the OSPA protocol and the revised SAS-2. The storage on the client side is also one thing to be considered. The clients of either the SAS protocol or the revised SAS-2 do not need to memorize any random value, while each of the clients of the revised SAS-1 has to memorize the random value Ni . Each of the clients of the OSPA protocol has to memorize a well-chosen strong password and a client of the ROSI protocol has to memorize the values h(S  Ni ) and R = h(x  UID ) ⊕ S. Next, let us consider the storage requirement on the server. For each client, both the SAS protocol and the revised SAS2 must store the user’s identity, the verifier and the nonce (or the counter) on the server side. The OSPA protocol stores the user’s identity, the session number and the verifier on the server. On the other hand, both the ROSI protocol and the revised SAS-1 store the user’s identity and the verifier on the server. Now, this paragraph is about the length of the transmission message. Only the quantity of protocol-specific data is considered in the comparison, since almost all the other data (such as protocol version number, checksum and others) are the same for each protocol and depend on implementation environments. The SAS protocol transmits the user’s identity, the nonce and two computed values. The OSPA protocol transmits the user’s identity, the session number and three computed values. The ROSI protocol transmits the user’s identity and two computed values in the case of unilateral authentication and the server will send back another computed value for mutual authentication. The revised SAS-1 transmits three messages and the revised SAS-2 transmits five messages. Now we examine only the computational load the authentication phase puts on the protocols, since the registration phase is executed only once for each protocol. All of the three protocols involve only the hashing operation, string concatenation and the bit-wise exclusive OR operation, where the computational load caused by the latter two operations is negligible. The SAS protocol requires four hashing operations on the client side and one on the server side. The OSPA protocol requires five hashing operations on the client side and two on the server side. The ROSI protocol demands five hashing operations on the client side and four on the server side. The four hashing operations performed by the server can be checked as follows. One is for computing h(x  UID ), the second one for computing h(h(x  UID ) ⊕ h2 (S  Ni )), the third one for h(h2 (S  Ni+1 )), and the fourth one for computing h(h(S  Ni )). The data sent in Step 3 can be computed Vol. 46, No. 2, 2003

200

H UNG -Y U C HIEN AND J INN -K E JAN TABLE 1. Summary of evaluation. SAS

SAS-1

SAS-2

OSPA

ROSI

No 0

Yes 1

No 0

Yes 1

Yes 2

3

2

3

3

2

Unilateral

Unilateral

Unilateral

Unilateral

Mutual

3

1

3

3

Number of transmitted data items

5

3

5

5

Number of hashing operations by the client Number of hashing operations by the server Replay attack Guessing attack Stolen-verifier problem resulting in impersonation attack and denial-of-service attack

4

5

5

5

1 for unilateral authentication (2 for mutual authentication) 3 for unilateral authentication (4 for mutual authentication) 5

1

2

2

2

4

Yes Yes Yes

No No Yes

No Yes Yes

No No Yes

No No No

IC card support Number of random values on the client side Number of stored values for each client on the server side Unilateral or mutual authentication Number of interactions

by using the temporary values in Step 2, without a further hashing operation. Finally, both the SAS-1 and the SAS-2 require five hashing operations on the client side and two on the server side. We now summarize the evaluation listed in Table 1. All the protocols listed are efficient and simple to implement, since they require only a few simple hashing operations and little storage space on the client side. One major difference is that only the ROSI protocol achieves robust security and mutual authentication. The revised SAS protocols and the OSPA protocol are vulnerable to the stolenverifier problem, in which an attacker can successfully launch an impersonation attack and the denial-of-service attack. The revised SAS-2 protocol is even vulnerable to the guessing attack. In contrast, the ROSI protocol can withstand all the attacks. Furthermore, the ROSI protocol has the least transmission cost among all the listed protocols (one interaction with three transmitted data for unilateral authentication and two interactions with four transmitted data for mutual authentication). It achieves optimal performance in terms of the number of interactions. Altogether, these features make it a very attractive solution. 6. CONCLUSION This paper has demonstrated the weaknesses of the SAS protocol, the revised SAS-1, the revised SAS-2 and the T HE C OMPUTER J OURNAL,

OSPA protocol. To strengthen the security, we have proposed the RObust and SImple (ROSI) authentication protocol. In our performance evaluation, the ROSI protocol has been proven to achieve robust security with lower transmission cost than its predecessors. ACKNOWLEDGEMENTS We would like to thank the anonymous reviewers for their helpful comments. This research was partially supported by the National Science Council with project number NSC912626-E-252-002 and NSC91-2213-E005-013. REFERENCES [1] Ding, Y. and Horster, P. (1995) Undetectable on-line password guessing attacks. ACM Operating Syst. Rev., 29, 77–86. [2] Halevi, S. and Krawczyk, H. (1998) Public-key cryptography and password protocols. In Proc. 5th ACM Conf. on Computer and Communications Security, San Francisco, CA, November 3–5, 1998, pp. 122–131. ACM Press, New York. [3] Bellovin, S.-M. and Merritt, M. (1993) Augmented encrypted key exchange: a password-based protocol secure against dictionary attacks and password file compromise. In Proc. First ACM Conf. on Computer and Communications Security, Fairfax, VA, November 3–5, 1993, pp. 244–250. ACM Press, New York.

Vol. 46, No. 2, 2003

ROBUST AND S IMPLE AUTHENTICATION P ROTOCOL [4] Chien, H.-Y., Chen, Y.-H., Jan, J.-K. and Tseng, Y.-M. (2001) Cryptanalysis on dynamic authentication protocol for personal communication system. IEE Electron. Lett., 37, 895–896. [5] Sandirigama, M., Shimizu, A. and Noda, M. T. (2000) Simple and Secure password authentication protocol (SAS). IEICE Trans. Commun., E83-B, 1363–1365. [6] Shimizu, A. (1990) A dynamic password authentication method by one-way function. IEICE Trans., J73-D-I, 630– 636. [7] Shimizu, A. (1991) A dynamic password authentication method by one-way function. Syst. Comput. Japan, 22, 97– 101. [8] Simizu, A., Horioka, T. and Inagaki, H. (1998) A password authentication method for contents communication on the internet. IEICE Trans. Commun., E81-B, 1666–1673. [9] Gemplus, M. L. (1997) Smart-Cards: a cost-effective solution against electronic fraud. European Conference on Security and Detection, April 28–30. Conference publication No. 437, pp. 81–85. IEE. [10] Lin, C.-L., Sun, H.-M. and Hwang, T. (2001) Attacks and solutions on strong-password authentication. IEICE Trans. Commun., E84-B, 2622–2627.

T HE C OMPUTER J OURNAL,

201

[11] Kamioka, T. and Shimizu, A. (2001) The Examination of the Security of SAS One-time Password Authentication. IEICE Technical Report OFS2001-48, no. 435, The Institute of Electronics, Information and Communication Engineers, Tokyo, Japan. [12] Chien, H.-Y., Jan, J.-K. and Tseng, Y.-M. (2000) Impersonation attack on Tan-Zhu’s remote login scheme. IEE Electron. Lett., 36, 1202–1203. [13] Chien, H.-Y., Jan, J.-K. and Tseng, Y. M. (2002) An efficient and practical solution to remote authentication: smart card. Comput. Security, 21, 372–375. [14] Chien, H.-Y., Jan, J.-K. and Tseng, Y.-M. (2001) A modified remote login authentication scheme based on geometric approach. J. Syst. Software, 55, 287–290. [15] Chien, H.-Y., Jan, J.-K. and Tseng, Y.-M. (2001) Cryptanalysis of Chang–Wu’s group-oriented authentication and key exchange protocols. Inform. Process. Lett., 80, 113–117. [16] Asokan, N., Debar, H., Steiner, M. and Waidner, M. (1999) Authenticating public terminals. Comput. Networks, 31, 861– 970. [17] Sun, H.-M. (2000) An efficient remote user authentication scheme using smart cards. IEEE Trans. Consumer Electron., 46, 958–961.

Vol. 46, No. 2, 2003