A FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER

Transcription

1 INTERNATIONAL JOURNAL OF INFORMATION AND SYSTEMS SCIENCES Volume 1, Number 2, Pages c 2005 Institute for Scientific Computing and Information A FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER PING LUO, MANQIU ZHONG, XIAONING PENG, AND DAOSHUN WANG Abstract. The X.509 framework protocol uses public-key certificate in authentication and conversation key negotiation. This framework gains convenient user key management, but because of the low speed of asymmetric cryptographic algorithms, the speed of handshake is not satisfactory. In this paper, we will present a fast handshake caching protocol that requires a trusted third part caching center but attempts to minimize its involvement in the execution of the protocol, which can greatly enhance the efficiency of authentication. With this protocol, even if both sides of communication never contact each other before, they can quickly and conveniently authenticate each other and negotiate the secure conversation key of the communication session from the caching context on the trust path if there is a trust path between them. With the handshake caching protocol, the speed of authentication and conversation key negotiation is 3-4 times faster than the X.509 protocol without reducing the security. Furthermore, we will pay particular attention to the process of the conversation key negotiation, analyze its efficiency and security, and discuss some aspects of its formal verification. Key Words. X509. Asymmetric algorithms, authentication, fast handshake. 1. Possibility of enhancing the handshake efficiency Since the low speed of asymmetric authentication framework comes from the low speed of big number calculation, there are two ways to enhance the efficiency. The first is to reduce the times of calculation as much as possible, and the other is to change the protocol, making the calculation work in parallel, which is serial originally. Caching the secure information of handshake is an effective method to avoid calculation. Reusing the conversation key, by which the both sides of communication negotiated last time, can reduce the times of calculation. Currently, many applications based on the X.509 authentication framework perform the caching mechanism. However, in the existing performances, the cached secure information can be only used by the both sides of communication that publish it. When two actors that haven t connected before want to build the secure connection, they have to shake hands fully. To make the calculation work in parallel, the existing authentication protocol needs to be extended. In this paper, we will present a fast handshake caching protocol with caching center, which can greatly enhance the efficiency of authentication. Following this protocol, even if both sides of communication never contact Received by the editors January 1, 2004 and, in revised form, March 22, This research was supported by the National 973 Project (No. 2003CB314805) and the National Natural Science Foundation of China (No ). 137

2 138 P. LUO, M. ZHNG, X. PENG, AND D. WANG each other before, they can conveniently negotiate the secure conversation key of the communication session from the cached context on the trust path if there is a trust path between them. 2. Some conceptions 2.1. User key word. User key word is the user s private information to encrypt his secure information of connection. It can be used in user authentication and secure information of connection s protection. The user key word would never be transferred on the network, so it is quite safe. User can choose his key word independently and privately at any moment. However, since the user key word is the symmetrical key of secure information encryption, if a user changes his key word, the secure information he has published becomes useless, unless the user encrypts and publishes them again Handshake secure information. The discrete logarithm method is based on the value of p which is assumed to be a large prime with g as a primitive element of GF (p) and y = g x modp as the public key, where GF (p) is a finite field and x is a user s secret key. It is very easy to calculate y from x but difficult to calculate x from y which is basis of the discrete logarithm problem. For discussion simplicity, we denote y = g x modp by g x in the following. The handshake secure information contains the conversation key that the both sides of communication negotiate following the handshake process defined in the X.509 framework and will be used in user authentication and negotiation of conversation key in the handshake caching protocol. Here we suppose that the both sides of communication are A and B, and their key words are a and b, k 1 is the conversation key they negotiated. Then the handshake secure information they would present is as follows: (i) If A allows others to negotiate conversation key with him from the trust path B to A, A publishes the big numbers g ak1 k1 and g k1 a ; (ii) If A allows other users to use the path A to B as one part of their trust path, A publishes the big number g a k1 ; (iii) If B allows others to negotiate conversation key with him from the trust path A to B, B publishes the big numbers g bk1 k1 and g k1 b ; (iv) If B allows other users to use the path B to A as one part of their trust path, B publishes the big number g b k Trust path. The performance of handshake caching protocol with caching center is based on trust path. The both sides of communication can negotiate conversation key from the secure information on the trust path rather than from the public-key certificate. The trust path can be defined as follows in two cases (suppose that the both sides of communication are A and B, and there is a third part actor C, which here just describes the trust path from A to B): (a) If A and B have been contacted and cached secure information of the connection from A to B, there is a trust path from A to B; (b) If there exists the trust path from A to C and from C to B, there is a trust path from A to B. Figure 1 describes above two cases. Since the trust path is directive, there may be no trust path from B to A, even if the trust path from A to B exists. In a network, if the trust path is treated as a directed edge and each user is treated as a node, we can get a digraph of the network. So finding the trust path between two users in the network is equivalent to finding the directed path between two nodes in the digraph.

3 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 139 Figure Handshake caching protocol with caching center 3.1. One example. When users need to shake hands by following the handshake caching protocol, they first need to get the trust path between them, after calculating the secure information on the trust path. They will get a same safe conversation key if they have the right user key word and the trust path is authoritative. In order to describe the particular process of negotiating conversation key from the caching secure information, we show an example in Figure 2. Figure 2. In this example, we suppose that there are five users, A, B, C, D and E, and their key words are a, b, c, d and e, respectively. A and B, B and C, C and D, D and E have shaken hands each other by following the X.509 protocol and negotiated the conversation keys k 1 k 4. From the above Figure we can see that A and E allow other negotiate conversation key with them using B to A and D to E as one part of their trust path, B, C and D allow others trust path to pass them bi-directional.

4 140 P. LUO, M. ZHNG, X. PENG, AND D. WANG Now user A and E want to authenticate each other and negotiate the conversation key using the trust path A B C D E. On the trust path, obviously user A can get the big numbers g ek4 k4, g k4 d, g d k3, g k3 c, g c k2, g k2 b, g b k1. User A will do following calculation: g ek4 k4 g k4 d g d k3... g b k1 = g ek4 k1. And then A can work out g ek4 k1 g k1 = g ek4. Hence A can obtain (g ek4 ) ak1, i.e., user A gets g aek4k1. Similarly, E can also get g aek4k1. We call g aek4k1 the compound conversation key of A and E. The process of A and E shaking hands with the trust path is shown in Figure 3. g ek4 k4 g k4 d... g k1 = g ek4, g ak1 k1 g k1 b... g k4 = g ak1, (g ek4 ) ak1 = g aek1k4, (g ak1 ) ek4 = g aek1k4. Figure 3. In the process of handshake in Figure 3, users A and E not only can get the compound conversation key, but also can authenticate each other (see session 3.3). Furthermore, the calculations of A and E to get compound conversation key can work in parallel, which costs much less time. Hence, the efficiency of authentication and negotiating conversation key between users A and E is greatly improved. However, the model in Figure 3 is not practicable. When A and E want to shake hands, they must first connect with B, C and D to get the secure information on the trust path. When the trust path gets longer, we have to cost much more time in calculating compound conversation key. Therefore, this is not acceptable. In performance, we add a handshake caching center (HC) in the above model, which takes charge of caching the secure information of the trust paths. So, we get the model 2 described in Figure 4. Having the handshake caching center, all of the secure information of trust paths can be stored in HC. When A and E want to shake hands, they just need to connect with HC rather than with B, C and D. HC can calculate the secure information of the trust path for any both users in the network, such as g ek4 k1 for A and g ak1 k4 for E. When A and E connect with HC, we can apply the trust path information between each other, HC will not cost much time on calculation. This also can avoid costing much more time when the trust path getting longer. The process of A and E shaking hands with HC is decribed in Figure 5 as follows:

5 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 141 Figure 4. Figure 5. For the purpose of authentication, the secure information of the trust path, which sends the information from HC to users, must be signed by HC. However, since

6 142 P. LUO, M. ZHNG, X. PENG, AND D. WANG the secure information on HC is open, the request of the user for the trust path can be plain text and needn t be signed The particular process of the protocol. The handshake caching protocol with caching center can be divided into two independent courses: the course of publishing the secure information of handshake and the course of authenticating and negotiating conversation key with the trust path. For simplicity, we suppose that the users A and E have finished a conversation and have negotiated a conversation key k following the X.509 framework. Then the course of publishing the secure information of handshake is as follows (E is the sponsor): (1) User E sends A the messages {E, ASKH, sgndat A}, where E is the user E, s identification, ASKH is a request of caching secure information of handshake (the particular format of ASKH can be defined in performance), and the sgndat A is the user E, s signature of the message. (2) After receiving the message of the step 1 and verifying the signature of E, user A sends the refusal message if he don t want to cache the secure information of this handshake. Otherwise A sends E the messages {A, ACKH, sgndat A} to perform the course of caching, where A is the user A, s identification, ACKH is the response to caching the secure information of handshake, and sgndat A is the user A, s signature of the message. (3) E sends HC the messages {E, HCInfo E, sgndat A} if A agree to perform the caching course, where HCInfo E is user E, s secure information of handshake defined in section 2.2, and sgndat A is the signature of E. Similarly, user A sends the same type message to HC, too. (4) After receiving these messages, HC verifies the signatures of users and merges the secure information of handshake into its database. The course of authentication and conversation key negotiation with the trust path is as follows. Suppose that E wants to contact with A. (a) User E sends its identity {E, r e } to A, and asks A whether the handshake caching protocol could be performance, where r e is a random number generated by E; (b) If the protocol can t be performed, A sends back the refusing message, and then the both sides of communication shake hands with the default protocol defined by the X.509 framework. Otherwise, A generates a random number r a and calculates r = H(r e, r a ), where H(, ) is a hash function, and r is treated as the serial number of this handshake. Then A sends the message {A, r a }; (c) Receiving the message sent by A, E calculates the serial number of this handshake r = H(r e, r a ); (d) A sends the message EA to HC, where EA is the trust path of the user E to A. At the same time, E sends the message AE to HC, where AE is the trust path of the user A to E; (e) Receiving the request of user A, HC searches the local secure information of handshake, trying to find the trust path of EA. If not found, HC returns the error message; otherwise, sends the result {P I EA, sgndat A} to A, where P I EA is the calculated result of the secure information on the trust path E to A, i.e., g ek4 k1 in Figure 5, sgndat A is the signature of HC to this message. HC also sends the same kinds of messages to E after receiving user E, s request. (f) If either side s trust path does not exist, the handshake caching protocol is terminated. And the both sides of communication should shake hands with the default handshake protocol. Otherwise, the protocol will go on.

7 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 143 (g) Receiving the message returned from HC, A verifies the signature of HC, and works out the compound conversation key with P I EA. And E does the same work; (h) Users A and E send the plain text and cryptograph of serial number {r, F k (r)} each other, where F is the symmetrical encrypt function, F k (r) means to encrypt r with the key k, and k is the compound conversation key. If verified, the handshake is successful The dependability of authentication. In the above handshake caching protocol with caching center, the authentication and negotiation of conversation key will be done in one step. Whether the compound conversation key could be worked out or not shows whether the authentication is successful or not. If the both sides of communication work out the same compound conversation key, the identities of the both sides can be confirmed. The dependability of authentication in this protocol can be ensured in two ways: the user key word and the secure information of handshake. The user key word can point out if the user is what he claimed, since the imitator would never know the right user key word. Of course, the imitator would never know the secure information of handshake, either, and could not work out the compound conversation key (g ek4 ) ak1 with g ek4 (here suppose that the imitator is A). Now we can ensure that there is not imitator in the protocol, but the user is not imitated, which doesn t mean that the user is believable. User A never connects with user E, then even if E claims he owns his user key word e, A can t judge E, s believability, since the user key word can be selected independently. In the protocol this article is presented, and the believability of the user can be ensured with the trust path. If the trust path exists, the user is believable. For example, in Figure 2, user A can believe in user E because E and D shake hand by the X.509 authentication protocol, and there is a trust path from D to A. In the same way, A can prove the believability of users D and C. User B shakes hands with A by the X.509 authentication protocol, so B is believable. Therefore, E is believable to A The security of the compound conversation key. The security of the compound conversation key can be ensured by the user key word. For example, in Figure 2, the compound conversation key of A and E can be expressed in the form of g aek1k4. Anybody can get g ek4 k1 and g ak1 k4, but does not know k 1 and k 4 except B and D, and the imitator can t work out g ek4 and g ak1. User D knows k 4, so he can work out g ak1, but D doesn t know E, s user key word, and thus he can t work out the compound conversation key g aek4k1. Similarly, user B can t work out the key either Efficiency analysis. First, the X.509 framework s primary steps are as follows (suppose that the both sides of communication are A and B): (i) A signs a message, encrypts it with B, s public key, and then sends the message to B; (ii) B decrypts the message with his private key, and verifies A, s signature; (iii) B signs the replying message, encrypts it with A, s public key, and then sends the message to A; (iv) A decrypts the message with his private key, and verifies B, s signature; (v) The both sides begin conversation. In the discussion above, we know that the efficiency can be improved by reducing the times of big number calculation as much as possible, and changing the protocol

8 144 P. LUO, M. ZHNG, X. PENG, AND D. WANG to make the serial calculation for which courses work in parallel. Since the calculations in Figure 5 have full parallelism, in the following efficiency analysis, the two parts of calculation time of the both sides will be treated as one. The handshake caching protocol s primary steps and their time complexity are as follows (suppose that the both sides of communication are A and B): (a) A sends the request and his identity to B. There is no big number calculation in this step; (b) The both sides connect with HC and send the request of trust path. The message can be plain text, so there is no big number calculation in this step; (c) HC searches local trust path list, and returns the result, which need not be encrypted but must be signed by HC. In performance, HC can build the trust path and sign it beforehand, so this step doesn t cost any time of big number calculation; (d) The both sides of communication verify the signature of HC, and work out the compound conversation key. This step has twice big number calculations; (e) The both sides begin conversation. Now we can see that there are only twice big number calculations in above handshake caching protocol, much less than original asymmetric handshake protocol in X.509, which are 8 times at least. It will be 3-4 times faster in the speed of handshaking. 4. Realizing different trust models by different rules of trust path construction The trust model provides how the both sides of communication judge each other s reliablity. There are two kinds of trust models, distributed trust models and centralized trust models. The trust model of the X.509 framework protocol and the Kerberos protocol is centralized. In centralized trust model protocol, user s trust in others is based on his trust in some central institutions (CA in X.509 and AS, TGS in Kerberos). In distributed trust model protocol, trust can be transferred. If A trusts B and B trusts C, A trusts C. The Pretty Good Privacy (PGP) protocol s trust model is distributed. What we discussed above in Figure 5 is a distributed trust model. To realize the centralized trust model, we can change the rule of trust path construction. Let the HC be a special user of the network. Every user shakes hands with it by the X.509 framework, and caches the secure information of the handshake on it. Then when any two users want to shank hands, the process is as follows. In Figure 6, the trust path is A HC B. The trust path has and only has one mid node, HC. The trust between A and B is based on the trust of HC. 5. The verification of security The security of the handshake caching protocol is based on the complexity of discrete logarithm. Since the security of discrete logarithm has been discussed in many articles, we don t put much attention on it. Here we will primarily pay attention to attack from the hacker or monitor. First, the messages needed to transfer in the handshake caching protocol are open. Those in the caching center are open, too. So all these information would not meet with attack and needn t encrypt, either (some of them need to sign). The cached secure information will not reduce the secure level of user key word and conversation key. In the discussion above, we can see that the cached secure information has three forms: g ak1 k1, g a k1 and g k1 a. Hereinto a is user A, s user key word. Attacker could never work out a or k 1 from this secure information, since

9 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 145 Figure 6. this is a discrete logarithm problem. Next, we will discuss some special kinds of attack. For convenience, we discuss (1) HC is imitated. In the handshake caching protocol, HC takes charge of caching handshake secure information and constructing the trust path. The imitation of HC is very terrible in this protocol. However, the asymmetric signature mechanism can protect HC from being imitated. Unless the attacker can imitate the signature of HC, HC would never be imitated. (2) One or more users are imitated. Obviously, the imitator would never succeed, unless he knows the user s key word. Just as the discussion above, working out the user key word from the handshake secure information is a discrete logarithm problem. (3) The replay attack imitating HC. The secure information on HC has time limit since the user would cancel the secure information he had published before. This makes the replay attack imitating HC possible. However, a time stamp s taking part in will perfectly solve this problem. 6. The speed test of the handshake caching protocol The performance of speed test has two parts, the test of handshake speed and the test of system resources engaging rate. Handshake speed test will draw the conclusion on the absolute speed of the handshake in the handshake caching protocol with caching center. The test of system resources engaging rate will show us how much system resources are engaged for handshake in this protocol. The hardware environment is as follows: CPU: INTEL PIII800SE. MEM: HY 256MB-133MHz. HD: SEAGATE 40GB 5400RPS. OS: Window 2000 ProVisual C

10 146 P. LUO, M. ZHNG, X. PENG, AND D. WANG For the comparison, we will also have a speed test on the SSLV3 handshake protocol that is in performance on the unilateral authentication protocol of X Test of handshake speed. Here, we will compare the absolute handshake speed of the handshake caching protocol and SSLV3 protocol. In the test, we will do a number of handshakes in one thread and calculate the average time. 50, 100, 200, 400 times of handshake will be performed in the test and the result will be compared with the SSLV3 protocol. Figure 7. In the sheet, T is the times the handshake is done, C is the average time cost per handshake, and P is protocol. Also, we will get the charts as follows: Figure 8. Average time cost of SSLV3 protocol In the charts above, X coordinate is the times that handshake is done, and Y coordinate is the average time cost of one handshake with the unit millisecond. Obviously, we have the conclusion from the charts that the speed of handshake caching protocol is about one time faster than the SSLV3 protocol in the same times of handshakes.

11 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 147 Figure 9. Average time cost of handshake caching protocol Figure 10. Average time cost of SSLV3 protocol Figure 11. Average time cost of handshake caching protocol

12 148 P. LUO, M. ZHNG, X. PENG, AND D. WANG 6.2. Test of system resources engaging rate. In the test, we will do 200 times of handshake in 1, 2, 3, 4, 5 threads. Comparison will be done between the two handshake protocols. The result is as follows: In the charts above, X coordinate is the thread count, and Y coordinate is the average time cost of one handshake with the unit millisecond. From the chart we can see that the handshake caching protocol has the better concurrency. 7. Conclusion The handshake caching protocol with caching center is a secure third part authentication protocol based on the asymmetric authentication system. With this protocol, the speed of authentication and negotiation of conversation key will be accelerated greatly. This protocol also reduces the workload on clients and doesn t cause any new secure problem. The protocol presented in this paper is a third part authentication protocol. Its addition would never influence original communication protocol. Client and server can terminate it at any time. These will give much convenience to the user of networks. References [1] R. Atkinson, Security Architecture for the Internet Protocol, RFC1825, [2] A. Aziz, Simple Key-Management for Internet Protocol (SKIP), Internet Draft draft-ietfipsecaziz-skip-20.txt, [3] M. Bellare and P. Rogaway, Distributing keys with perfect forward secrecy, manuscript, [4] S. Bruce, Applied Cryptography Second Edition: Protocols, Algorithms, and Source Code in C, [5] J. Dierks, R. Certicom, C. Allen, The TLS Protocol Version 1.0, [6] W. Diffie, P. C. van Oorshot, and M. J. Wiener, Authentication and Authenticated Key Exchanges, Designs, Codes and Cryptography, V.2, Kluwer Academic Publishers, , [7] Diffie, W., Hellman, M., New directions in cryptography, IEEE Transactions on Information Theory, IT-22(6): ,1976. [8] T. ELGAMAL, A public key cryptosystem and a signature scheme based on discrete logarithms, IEEE Trans. on Info. Theory, IT-31 (1985), [9] IEEE c, Interoperable LAN/MAN Security C Clause 3: Key Management Protocol, Draft, [10] A. Juels and J. Guajardo, RSA key generation with verifiable randomness, Public Key Cryptography: in Lecture Notes in Computer Science, Paris, France, Springer-Verlag, , [11] P. Zimmermann, PGP User s Guide, Boulder, Colo, Dr. Ping Luo, received his B. S and M. S from Xiangtan University in 1983 and 1986, respectively, and Ph. D from the Institute of Mathematics of Chinese Academy Sciences in 1998, specializing in computational mathematics. He is now a an associate professor in the Department of Computer Sciences at Tsinghua University. His current research interests include cryptography and security of network information. He has been working on a number of theoretical problems and different applicationoriented projects. I have studied the elliptic curves cryptosystems, fast public-key cryptosystem, secure E-commerce, computer arithmetic,multibody contact problems,variational inequalities, and domain decomposition methods.

13 FAST HANDSHAKE CACHING PROTOCOL WITH CACHING CENTER 149 Department of Computer Sciences and Technology, University of Tsinghua,Beijing,100084, China URL: Department of Computer Sciences and Technology, University of Tsinghua, Beijing, , China Department of Computer Sciences, Huaihua College, Huaihua , China Department of Computer Sciences and Technology, University of Tsinghua,Beijing,100084, China URL: