Intrusion Detection in Zero Knowledge System Using Model Checking Approach Teslin Jacob, Mithun Raman and Sanjay Singh∗ March 8, 2013
Abstract The number of services provided to the modern users of todays’ generation is countless and ever increasing. However, most of these services require the user to login with a username and a password. These sensitive information has to be sent across the network, which is highly insecure, and can be tapped by any unauthorized individual without much difficulty. The Zero Knowledge protocol provides authentication without the need to send any private and confidential information across the network. Only mathematical computations on these confidential information have to be sent across. In this paper, we have modeled the general working of the Zero Knowledge system by considering the various states that a prover (sender) and a verifier (receiver) will be in during the execution of the protocol, and have proved that the authentication of the prover is possible. Zero Knowledge system is usually considered to be unintrudeable, but that does not stop hackers from attempting to intrude this protocol. So in this paper, we have also considered the various states that an intruder will be in while intruding, and have shown that it is possible for the user to detect if somebody is trying to intrude the Zero Knowledge system. The tool used to model the system is NuSMV.
1
Introduction
Todays generation is exposed to a wide range of services and facilities over the Internet. Most of these services require the user to first register himself; or if he is already registered, then he needs to login, which involves sending of his login credentials over the Internet to the verifier. There are many vulnerabilities and attack vectors for web-based application. This includes both web-specific (i.e. Cross-Site Scripting [1] ), as well as generic (i.e. Password Sniffing [2] ), all of which leave the user susceptible to being victims of identity theft. The first ∗ Sanjay Singh is with the Department of Information and Communication Technology, Manipal Institute of Technology, Manipal University, Manipal-576104, INDIA, E-mail:
[email protected]
1
technique introduced was the password-based authentication, wherein a user and a host share a password which is essentially a long-term but rather smallsize symmetric key. Since in this protocol the password was sent in the open, and the stored password file at the receivers’ end was kept in the open which was easily readable by an attacker. To overcome this problem Needham’s password protocol [3] was introduced, wherein the receiver uses a one-way function to encode the passwords, which is extremely difficult to invert. But again, the password from the sender to the receiver was sent in the open. So then came the one-time password scheme, and the Encrypted Key Exchange(EKE) protocol [4] which involves adding your own salt. In all these protocols, there is a common feature, which is sending the user’s password over the Internet, either in plaintext format or in an encrypted format. In order to avoid this, the Zero Knowledge system was introduced, which eliminated the need to send confidential information over the Internet [5] . There are still no known attacks on this system. However, hackers can still attempt to attack and break this system. Packets sent across the network can be captured by the intruder to perform cryptanalysis. The best way to test the different reachable combinations of states of a system is to model it using an appropriate model checking tool. Model checking is one approach where we can test a particular system by representing it in the form of state transition diagrams. The different states of a system and the transitions between them are identified. These can then be modeled as Finite State Machine (FSM). Once this is done, the constraints on the system can be written in the form of logic specifications which should hold true throughout the system’s execution in all its states. If it is found that a particular specification is false, then it will return a trace leading to the false condition. Using this trace, it is possible to trace the systems properties and what operations it performs under what conditions. Therefore, using this method, any flaw in the system can be detected, and changes to the model of the system can be made to overcome it. The model checking tool we used in this work is NuSMV ( New Symbolic Model Verifier) [6]. In this paper,we have modeled the behavior of the Zero Knowledge system by representing it in terms of the various states that a prover and a verifier will be in, and have checked using Computation Tree Logic (CTL) specifications if authentication is possible. We have also modeled the behavior of an intruder who is trying to capture the packets being sent between the sender and the receiver, and show that it is possible to detect the presence of an intruder. The remainder of the paper is organized as follows. Section 2 discusses about the theoretical background of the Zero Knowledge system. Section 3 describes about the modeling of the Zero Knowledge System in NuSMV. Section 4 discusses the simulation results obtained through NuSMV. Finally conclusion has been drawn in section 5.
2
2 2.1
Theoretical Background Current Web Application Login process
Figure 1: Traditional Authentication System The most common login system used in web application currently is through the use of a form submission of a username and password enabled with SSL communication. In more secure systems, the password is hashed using a Java script-based hashing algorithm before sending it. Figure 1 shows a simple traditional authentication system which shows that an encrypted version of the password needs to be sent across the network.
2.2
Zero Knowledge Proof
Zero Knowledge proofs were first conceived in 1985 in a draft of ”The Knowledge Complexity of Interactive Proof-Systems” [7] . While this landmark paper did not invent interactive proof systems, it did invent the IP hierarchy of interactive proof systems and conceived the concept of knowledge complexity, a measurement of the amount of knowledge about the proof transferred from the prover to the verifier. Zero-Knowledge proof is a much popular concept utilized in many cryptography systems. In this concept, two parties are involved, the prover A and the verifier B. Using this technique, it allows prover A to show that he has a credential (for example, a credit card number), without having to give B the exact number. The reason for the use of a Zero-Knowledge Proof in this situation for an authentication system is because it has the following properties [8]: 3
(i) Completeness: if the statement is true, the honest verifier (that is, one following the protocol properly) will be able to prove that the statement is true to an honest verifier every time. (ii) Soundness: if the statement is false, it is not possible (with a very small chance) to fake the result to the verifier that the statement is true. (iii) Zero-knowledge: if the statement is true, the verifier will not know anything other than that the statement is true. Information about the details of the statement will not be revealed. The step-by-step procedure of the Zero Knowledge password based authentication protocol [8] is given below. (i) Initialization: • Given group G. Let g0 , g1 be primitive roots in G. • Let the public key be zpk = (G, g0 ). (ii) Registration Process: • User inputs username and password. • The user hashes the password with Hash function, H and calculates x = H(password). • The user then computes Y = g0x . • The user sends (username, Y) to the server. • The server stores (username, Y) into the database. (iii) Authentication Process: • The server generates a random one-time token ”a” and stores it and sends it to the user. • User inputs username and password. • The user hashes the password with Hash function, H and calculates x = H(password). • The user then computes Y = g0x . • The user chooses random rx ∈ G and calculates T1 = g0rx . • The user then calculates c = H(Y, T1 , a) and zx = rx − cx . • The user sends (c, zx ) to the server. • The server calculates T1 = Y c g0zx and verifies that c = H(Y, T1 , a). • If successful, user is authenticated.
4
The above algorithm is based on a non-interactive sigma protocol [9], which is a technique commonly used to prove the knowledge of a variable, which in this case, is the password. The user who is logging in is the prover, and the server verifying the login is the verifier. Here are some of the explanation of the components in the algorithm: • G: This is a cyclic group. This group contains a set of numbers which is based on a formula. This is a public group which will be available to both prover (user) and verifier (server). • g0 : A generator of the group G. It is an element of the group G. This is a public variable which will be available to both prover (user) and verifier (server). • x: The hash of the password that the user inputs. • Y: The pseudonym of the user. This is used for the verifier in the calculation of the proof of knowledge. • a: The random token generated for each login attempt. • T1 , rx , zx , c: Other miscellaneous variables which are used in the calculation.
2.3
Introduction to NuSMV
For modeling and verification of properties of Zero Knowledge system we have used NuSMV. NuSMV is a reimplementation and extension of SMV symbolic model checker, the first model checking tool based on Binary Decision Diagrams (BDDs). The tool has been designed as an open architecture for model checking. It is aimed at reliable verification of industrial sized designs, for use as a back end for other verification tools and as a research tool for formal verification techniques [10]. NuSMV supports the analysis of specifications expressed in temporal logic. User interaction is performed with a textual interface, as well as in batch mode. The system is represented in terms of a set of variables, predicates and transitions. Once this is done the constraints on the system can be represented in the form of Computation Tree Logic (CTL) or Linear-time Temporal Logic (LTL) [11] specifications which should hold true throughout the systemss execution in all its states. Whenever a specification is false, the system returns a counterexample to the user indicating the sequence of steps that led to the counterexample. Using these counterexamples, it is possible to trace the systems properties and what operations it performs under what conditions. Accordingly, any flaw in the system can be detected and changes to the model of the system can be made to overcome it.
5
3
Modeling Zero Knowledge Protocol in NuSMV
As stated in section 2, the Zero Knowledge protocol revolves around two major entities, the Prover (sender), and the verifier (receiver). The prover tries to prove a fact to the verifier without actually handing over the fact across the network to the receiver. Here we have modeled the various states of the prover and the verifier while executing the Zero Knowledge protocol. Figure 2 shows the various states that a prover undergoes through, while requesting for authentication from the verifier.
Figure 2: Various States of a Prover
Figure 3 shows the various states that a verifier goes through on an authentication request from the prover.
Figure 3: Various States of a Verifier Using NuSMV, we have modeled the FSM shown in Figure 2 and Figure 3 respectively, and have considered the following cases (specifications) to verify 6
the functionality of Zero Knowledge systems: Case I: When the verifier verifies that the prover is authentic, the prover will move into a state where he is authenticated. Case II: If the prover is not authentic, and the verifier detects that the prover is not authentic, the prover moves into a state where he is declared that he is not authenticated. Case III: If the verifier declares him to be non-authentic, then the prover cannot move into an authenticated state. Case IV: If the verifier declares him to be authentic, then the prover cannot move into a non-authenticated state. So far we have explained the working of a Zero Knowledge system as an authentication protocol between two users, prover and verifier. Now we take into consideration the presence of an intruder in the system. The above FSMs are not equipped with special states that can be used to detect an intruder. Therefore, we present the following two modified FSMs in Figure 4 and Figure 5 that show the states in the presence of an intruder.
Figure 4: Various States of a Prover in the Presence of an Intruder
Figure 6 shows the FSM of an intruder who is responsible for launching an attack on the protocol. The additional state (pIntruder ) helps to detect intrusion. After the prover or the verifier have sent some message across the network, their respective counters will start ticking until they receive a response from the opposite party. If this tick count value exceeds some threshold, the parties can conclude that either an intruder has captured the messages, or the messages are lost due to transmission error. If such a case arises, the parties will move into the pIntruder state and finally enter the tSession state where the session is terminated. These results are shown in section 4.
7
Figure 5: Various States of a Verifier in the Presence of an Intruder
Figure 6: Various States of an Intruder
8
4
Simulation Results and Discussion
We first present the results for the modeling of the classical Zero Knowledge system. The first case (i.e specification) of section 3 can be represented in NuSMV using the following specification: AG (((v.authenticated = 1 & v.state = sendR) & p.state = recR) → AX p.state = auth). The result obtained was TRUE which is indeed correct. The second case in section 3 can be represented in NuSMV using the following specification: AG (((v.authenticated = 0 & v.state = sendR) & p.state = recR) → AX p.state = Nauth). The result obtained was TRUE which is correct because the prover should go into a non-authenticated state when the verifier declares that he is unauthentic. The third case in section 3 can be represented in NuSMV using the following specification: AG (((v.authenticated = 0 & v.state = sendR) & p.state = recR) → AX p.state = auth). The result obtained was FALSE which is correct because the prover cannot go into an authenticated state when the verifier declares that he is unauthentic. The trace obtained is shown in Figure 7 which shows the sequence of steps which proves that the specification is wrong. The forth case in section 3 can be represented in NuSMV using the following specification: AG (((v.authenticated = 1 & v.state = sendR) & p.state = recR) → AX p.state = Nauth). The result obtained was FALSE which is correct because the prover should go into an authenticated state when the verifier declares that he is authentic. The trace obtained is shown in Figure 8 which shows the sequence of steps which proves that the specification is wrong. Next we present the results for the modeling of the intrusion detection states. If the prover is in the sending state, and the intruder has attacked, and the verifier is waiting for prover’s message, then the verifier should go into the pIntruder state. This is represented by the following specification: AG (((i.attack = 1 & p.state = sendCZ) & v.state = waiting) → AF v.state = pIntruder). The result obtained was TRUE which is correct. If the prover has sent a message, and the intruder has captured the message, then the prover should move into the pIntruder state. This is represented by the following specification: AG ((i.attack = 1 & p.state = sendCZ) → AF p.state = pIntruder). 9
Figure 7: Trace of Case III
Figure 8: Trace of Case IV
10
The result obtained was TRUE which is correct. Now if the prover has sent a message which was not captured by the intruder, and the verifier is waiting for the message, then the verifier cannot go into the pIntruder state. The following specification shows this: AG (((i.attack = 0 & p.state = sendCZ) & v.state = waiting) → AF v.state = pIntruder). The result returned was indeed FALSE, with Figure 9 showing its trace.
Figure 9: Trace Showing First Specification for Intruder
If the prover has sent a message which was not captured by the intruder, then the prover cannot go into the pIntruder state. The following specification shows this: AG ((i.attack = 0 & p.state = sendCZ) → AF p.state = pIntruder). The result returned was indeed FALSE, with Figure 10 showing its trace.
5
Conclusion
In this paper through model checking approach we have shown that while using Zero Knowledge System, it is possible for a prover to be authenticated if the verifier is convinced so. We have also shown that it is possible for both the prover and the verifier to detect if an intruder is listening to their conversation,
11
Figure 10: Trace Showing Second Specification for Intruder
and so can terminate their session to prevent further harm from the intruder. Other aspects of the protocol can be modeled by taking into consideration other possible kinds of attacks, and by step-by-step tracing of the execution path, any other flaws and improvements can be detected, and solutions can be suggested using model checking. Hence, model checking provides a very essential tool to verify all kinds of systems that can be represented as state transition diagrams, especially for verifying the various security protocols for their strengths and weaknesses, and suggest improvements which can lead to better system designs and improved security and quality.
References [1] G. Wassernann and C. Davis, “Static detection of cross-site scripting vulnerabilities,” in Software Engineering, 2008. ICSE ’08 ACM/IEEE 30th International Conference, 2008, pp. 171–180. [2] Z. Trabelsi, H. Rahmani, and M. Frikha, “Malicious sniffing systems detection platform,” in Applications and the Internet, 2004. Proceedings. 2004 International Symposium, 2004, pp. 171–180. [3] S. Sultana, M. Jabiullah, and M. Rahman, “Improved needham-schroeder protocol for secured and efficient key distributions,” in Computers and In-
12
formation Technology, 2009. ICCIT ’09. 12th Inteernational Conference, 2009, pp. 564–569. [4] A. Barmawi, S. Takada, and N. Doi, “Augmented encrypted key exchange using rsa encryption,” in Personal, Indoor and Mobile Radio Communications, 1997. ’Waves of the Year 2000’. PIMRC ’97., The 8th IEEE International Symposium, 1997, pp. 490–494. [5] C. Guilou, Louis and T. A. Berson, “How to explain zero-knowlege protocols to your children,” in Advances in Cryptology - CRYPTO ’89, 1990, pp. 628–631. [6] FBK-IRST, “Nusmv,” [Available http://nusmv.fbk.eu/NuSMV/index.html, 2012.
Online]
[7] S. Goldwasser, S. Micali, and C. Rackoff, “The knowledge complexity of interactive proof systems,” SIAM Journal on Computing, pp. 186–208, 1989. [8] L. J. Jun and Brandon, “Implementing zero-knowledge authentication with zero knowledge,” in The Python Papers Monograph 2:9 Proceedings of PyCon Asia-Pacific, 2010. [9] B. Barak, “Zero knowledge, identification protocols,” [Available Online] www.cs.princeton.edu/courses/archive/spr10/cos433/lec18new, 2010. [10] R. Cavada, A. Cimatti, C. A. Jochim, G. Keighren, E. Olivetti, M. Pistore, M. Roveri, and A. Tchaltsev, “Nusmv 2.5 user manual,” [Available Online] http://nusmv.fbk.eu/NuSMV/userman/index-v2.html, 2010. [11] M. Huth and M. Ryan, Logic in Computer Science: Modelling and Reasoning about Systems. New York, NY, USA: Cambridge University Press, 2004.
13
