Problem Analysis

Product Definition:
The product definition of our project is to enhance the HTTP layer security using Zero Knowledge Interactive Protocol. The proposed method can be implemented in both client side and server side as an extension to HTTP; it can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server. The proposed method is based on a modified SRP-6 Zero Knowledge Password Proof method (ZKPP).

Feasibility Analysis:

Project Plan:
Users are never going to be safe as long as they are required to manually enter sensitive information into login forms. The current trend of protecting users from attacks is by the use of browser toolbars or enhanced browsers which try to detect a fraudulent website when users navigate to such a site. While these methods are helpful, they still leave the door open for attacks. Currently, most Phishing sites use static cloning of real sites. However, there is nothing to prevent Phishers from creating dynamically cloned sites. Such sites implement a real-time manin-the-middle (MITM) attack vector against web surfers and servers. Even when servers use a secure SSL protocol to communicate with users, they still leave the door open for several MITM modes of attack. That is, unless they enforce a non anonymous mutual authentication using

digital certificates. When a server requires a secure session form a client, a Phisher can start such a secure session with the server on one end and start another session with a user on the other end. All a Phisher has to do is decrypt whatever messages are sent to it and pass them along to the other end. In such a scenario, a user will not even notice that her password has been compromised; even One Time Passwords does not help. Intercepting OTP by a Phisher is not as rewarding as when intercepting a regular password but when a real-time MTIM is active, there is nothing to prevent an attacker from add bots which would take a captured OTP and use it to immediately effect a transaction. Even if such attempts are thwarted by a server requiring constant manual interaction with a human being (which is unlikely), the door is still open for targeted Phishing whereby a Phisher manually intervenes once a session is created. The main purpose of our product is to provide more security in HTTP layer. This proposed new method can implement both on a client side as well as a server side. It does not require any modifications to existing infrastructure, or any changes to databases used by servers to store users credentials. The proposed method can be implemented as an extension to HTTP; it can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server.

Software Requirement Specification

1.Introduction

1.1 Purpose

Zero-knowledge proof or zero-knowledge protocol is an interactive method for one party to prove to another that a (usually mathematical) statement is true, without revealing anything other than the contents of the statement. One of the most fascinating uses of zero-knowledge proofs within cryptographic protocols is to enforce honest behavior while maintaining privacy. Zero Knowledge Interactive Proof techniques are useful in identification of digital signature and in authentication system. The objective of this project is to enhance the HTTP layer security using Zero Knowledge Interactive Protocol. The proposed method can be implemented in both client side and server side as an extension to HTTP; it can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server. The proposed method is based on a modified SRP-6 Zero Knowledge Password Proof method (ZKPP). 1.2 Intended Audience and Reading Suggestions This document can be used by different readers like developers, users, testers, project managers, marketing staff and document writers. After the introduction part, this SRS contains the overall description of the proposed system, the system features, external interface requirements and the functional and non-functional requirements. We can read this document in the order that is followed in the overview sections. 1.3 Project Scope Our project is to implement a browser extension in HTTP layer using zero knowledge interactive protocol. The advantage of using this technique is that we never use any trusted third party like Kerberos. Here when the client login into a web server, browser will invoke the plug-in automatically and authenticate the client and the server before going into the actual server.

The main advantage of this project is that by using this plug-in we can avoid common attacks such as man in the middle attack, phishing etc. Even if there are so many solutions exist to avoid such problems still door is open for attacks. But this plug-in will provide the mutual authentication without sending the actual password to the server. So here we never compromising the password and after getting the confirmation from the server side to the plug in , the actual connection is establishing between the client and the server. Here we dont even use digital signatures 1.3 References

1. Gaurav Gain, Zero-knowledge: A Survey 2. Oren, Y., Properties of Zero-knowledge Proofs.

2 Overall Description

2.1 Product Perspective Users are never going to be safe as long as they are required to manually enter sensitive information into login forms. The current trend of protecting users from attacks is by the use of browser toolbars or enhanced browsers which try to detect a fraudulent website when users navigate to such a site. While these methods are helpful, they still leave the door open for attacks. Currently, most Phishing sites use static cloning of real sites. However, there is nothing to prevent Phishers from creating dynamically cloned sites. Such sites implement a real-time manin-the-middle (MITM) attack vector against web surfers and servers. Even when servers use a secure SSL protocol to communicate with users, they still leave the door open for several MITM modes of attack. That is, unless they enforce a non anonymous mutual authentication using

digital certificates. When a server requires a secure session form a client, a Phisher can start such a secure session with the server on one end and start another session with a user on the other end. All a Phisher has to do is decrypt whatever messages are sent to it and pass them along to the other end. In such a scenario, a user will not even notice that her password has been compromised, even One Time Passwords does not help. Intercepting OTP by a Phisher is not as rewarding as when intercepting a regular password but when a real-time MTIM is active, there is nothing to prevent an attacker from add bots which would take a captured OTP and use it to immediately effect a transaction. Even if such attempts are thwarted by a server requiring constant manual interaction with a human being (which is unlikely), the door is still open for targeted Phishing whereby a Phisher manually intervenes once a session is created.

The main purpose of our product is to provide more security in HTTP layer. This proposed new method can implement both on a client side as well as a server side. It does not require any modifications to existing infrastructure, or any changes to databases used by servers to store users credentials. The proposed method can be implemented as an extension to HTTP, It can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server. 2.2 Product Features The main feature of our product is to provide a mutual authentication between the client and the server. Whenever a client system is installed this plug-in, it will automatically do the authentication between the client side and the server side. The main advantage of using this plugin is that we never revealing the password anywhere. This is done by Zero Knowledge proof using SHA 6.

2.3 User Classes and Characteristics User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level or experience. The main user class comes under our product is security. It has the highest priority. Through our product, we are giving a new system which will provide extra security while using browsers. Here we never were compromising with passwords. Our plug-in will provide mutual authentication using Zero Knowledge Proofs. 2.4 Operating Environment This software is a browser extension done in Mozilla Firefox. It requires minimum 1GB RAM. The processor used is Pentium III or above. 2.5 Design and Implementation Constraints In order to ensure mutual authentication between the client and the server, we need to install the plug-in in client system. Before connecting in to the actual server, this plug-in will automatically invoked and it will authenticate both the server side and the client side. It will establish a proper connection only after getting a confirmation from the plug-in. The main constraint comes under our product is that it will work only with new accounts which having the capability to process zero knowledge programming functions. Since existing web sites doesnt contains this facility, we can only use our plug-in in new web accounts. 2.6 Assumptions and Dependencies Our product is to ensure mutual authentication between the client and the server, we will install the software in the client system. Once the client needs connection with a web server, it

will send a request to server and client will get a special log in form which contains certain hidden values. It will retrieve by the plug-in and then there will be a communication between plug-in and the server and they will share some variables and values. After sharing those values, both side will calculate certain values and based on these values, plug-in will offer mutual authentication. In order to provide the comparison possible, both sides will use the same functions ie zero knowledge programming functions.

System Features

username uses

log in uses user

uses

password

invoke plug in

plug in

authenticate the client and the server Web server

response

extends

extends user

response ok to client Web server

response error to client

communicate

3.1 Security The main feature provided by our product is security. Since our product is mainly focusing on the authentication between the client and the server ie, mutual authentication, It provides more secure features than the existing system. 3.11 Description and Priority Since our product is mainly focusing on security, it has the highest priority. If our product will successfully provide this secure feature, benefit will also be high. Since this is not an existing system, high risk is there to provide this security feature using a new concept Zero Knowledge Proofs. 3.12 Stimulus/Response Sequences Once client needs to establish a connection with a web server, it will send a request to server and client will get a special log in form which contains certain hidden values. It will retrieve by the plug-in and then plug-in and server will communicate each other and will share some variables and values. After sharing those values, both side will calculate certain values and based on these values, plug-in will offer mutual authentication. 3.13 Functional Requirements In order to get response from server, it should be able to process the zero knowledge programming functions. There are certain calculations done by both sides and finally we need to compare those values. So the functions we are using for the processing by both sides should be same otherwise comparison cannot be possible. The main requirement needed for the mutual authentication is that

1. Client should install the plug-in client system. 2. Server should be capable of processing zero knowledge programming functions.

4 External Interface Requirements

4.1User Interfaces When server gets a request from client, it will send a log in form called special log in form because it contains certain hidden values and these values will be extracted by plug-in which is installed in client system and the result will send to server as hidden fields by using the same log in form. Again it will send second log in form and do some calculations and finally both sides will compare those values. Mutual authentication done by both sides by this process and if the values are same then client can continue with further browsing. 4.2 Software Interfaces We are using one database for storing the passwords from clients so that an authenticated client can access the server. If a client needs to create a new account, he should send his password to server and server will store it in server database. 4.3 Communications Interfaces The objective of project is to enhance the HTTP layer security using Zero Knowledge Interactive Protocol. The proposed method can be implemented in both client side and server side as an extension to HTTP, it can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server.

Software Document Specification

1.INTRODUCTION
1.1 Purpose This software design document describes the architecture and system design of our project Zero Knowledge Interactive Protocol for HTTP. This document gives the software development team an overall guidance of the architecture of the software project. It provides a stable reference document that outlines all part of the software and how they will work. It also describes structures that reside within the software, including attributes and relationships between data objects. This software also deals with the internal and external program interfaces as well as the design of human interface. 1.2 Scope Our project is to implement a browser extension in HTTP using zero knowledge interactive protocol. It will offer more secure features while using web servers. The advantage of using this client software is that we never using any trusted third party like in Kerberos. Here when the client login into a web server, browser will invoke the plug-in automatically and authenticate the client and the server before going into the actual server. The main gain of this project is that by using this client software we can avoid common attacks such as man in the middle attack, phishing etc. Even if there are so many solutions exist to avoid such problems still door is open for attacks. But this plug-in will provide the mutual authentication without sending the actual password in the server side. So here we never

compromising the password and after getting the confirmation from the server side to the plug-in only, the actual connection is establishing between the client and the server. Here we dont even using digital signatures.

2. SYSTEM OVERVIEW
The main purpose of our product is to provide more security in HTTP layer. This proposed new method can implement both on a client side as well as a server side. It does not require any modifications to existing infrastructure, or any changes to databases used by servers to store users credentials. The proposed method can be implemented as an extension to HTTP, it can also be implemented by existing HTTP where HTML forms are used to communicate security parameters between client and server. The main feature of our product is to provide a mutual authentication between the client and the server. Whenever a client is installed this plug-in into the client system, it will automatically do the authentication between the client side and the server side. The main advantage of using this plug-in is that we never revealing the password anywhere. This is done using Zero Knowledge proof using SHA 6 3. SYSTEM ARCHITECTURE

3.1 Architectural Design

Client

Server

Authentication Parameters in a first login form Present to user a login form with user name (U). Create random a. Compute A=G^a. A,U

Determine ZKPP parameters G, N. Send indication to Client of password & session protection methods supported by Server. Attach also data elements required for each supported method.

Retrieve x using U. Create random b. Calculate B=G^b + 3*G^x B in a second login form

Present to user a login form with a password field p. Capture password p. Compute x from p. Compute u=H(A,B) and S=(B-3*G^x)^(a+u*x). Set C=IP address of Server. Compute M1=H(A,B,S,C)

M1, C

Compute u=H(A,B) and S=(A*(G^x)^u)^b Set C=IP address of Server. Compute M1=H(A,B,S,C) Create session if M1=M1

3.2 Decomposition Description

Sequence Diagram

user use 1: log in()

plug-in

mail server server

2: client authentication() 3: server authentication() 4: response() 5: check_response_ok()) 6: request() 7: response()

Collaboration Diagram

5: check_response_ok()

1: log in() user 4: response() plug-in

6: request() 3: server authentication() 7: response() 2: client authentication()

Server

4. COMPONENT DESIGN

Here mainly there are three components. A client program, a plug in and the server program. In client program, it will send a request to the web server and whenever the client send this, plug in which is installed in the client side will invoke automatically and it receives the username and the password, it will convert the password into a hash form and this will send to the server side for the verification. Thus nobody can hack the original password. Thus it can ensure even dictionary attack. For ensuring the mutual authentication we are using a Zero Knowledge Interactive Protocol application called Secure Remote Password Protocol. By applying this protocol we provides the mutual authentication.

5. HUMAN INTERFACE DESIGN

5.1 Overview of User Interface Users are never going to be safe as long as they are required to manually enter sensitive information into login forms. The current trend of protecting users from attacks is by the use of browser toolbars or enhanced browsers which try to detect a fraudulent website when users navigate to such a site. While these methods are helpful, they still leave the door open for attacks. Here the client system will install the plug-in which automatically check whether both the user and the server are authenticated or not. If not it wont allow to continue. The main advantage of using this plug-in is that we never compromising the password. Whenever the password entered into the log-in form, plug-in will convert the password into a hash form which is done in the client software by itself. By doing this we can avoid many attacks such as dictionary attacks, phishing etc.

5.2 Screen Images

5.3 Screen Objects and Actions When a client would like to log in into a web server using its url, client software will automatically invoke and it will send a log in form for the user. User will enter his username and password into that log in form, and it will the data in client system itself. The client software retrieves the url from the client and then it will send a request to the server. Server will send a special log in form for the client software which contains username text field and some hidden fields which contains some values for further calculation. Client software will send back that log in form with suitable values contains username and hidden variables. Then server will send another log in form which contains password field and also some hidden fields to the client software. Client software retrieves this log in form and in the password field, it will enter the hash form of the original password. After getting the hash code and other variables, server will do all

the calculations and compare the values from both the client software and the server. If the final value is same in both side, we can say that the client as well as the server were authenticated. After getting the confirmation from the client software to the client, it can communicate with the actual server. 6. APPENDICES Position Paper: Enhancing browsers & servers with anti spoof data elements

Testing
Software testing provides an objective, independent view of the software to allow the project to appreciate and understand the risks at implementation of the software. Test techniques include, the process of executing a program or application with the intent of finding software bugs. Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been implemented. As such, the methodology of the test is governed by the software development methodology adopted. Testing can never completely identify all the defects within software. Instead, it furnishes a criticism or comparison that compares the state and behavior of the product against oracles principles or mechanisms by which someone might recognize a problem. These may include specifications, contracts, comparable products, past versions of the same product,inferences about intended or expected purpose, user or customer expectations, relevant standards, applicable laws, or other criteria.

A primary purpose for testing is to detect software failures so that defects may be uncovered and corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. Functional Testing Functional testing refers to tests that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of can the user do this or does this particular feature work. It is also known as acceptance testing. In software development, acceptance testing by the system provider is often distinguished from acceptance testing by the customer prior to accepting transfer of ownership. In such environments, acceptance testing performed by the customer is known as user acceptance testing. Users of the system perform these tests, which developers derive from the client's contract or the user requirements specification. Structural Testing Structural testing is white box testing, not black box testing, since black boxes are considered opaque and do not permit visibility into the code. It is also known as clear box testing, also known as glass box testing. It is a way to test software with knowledge of the internal workings of the code being tested. It uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the

software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. Test Cases: A test case normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. It can occasionally be a series of steps but with one expected result or expected outcome. The optional fields are a test case ID, test step, or order of execution number, related requirements, depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results, who generated the results, and what system configuration was used to generate those results. These past results would usually be stored in a separate table. Test Methods and Tools used System testing is a stage of implementation which is aimed at ensuring that the system works accurately and efficiently before live operations commences. Testing is vital to the success of the system. It makes a logical assumption that if all the part of the system are correct, the goal will be successfully achieved. Thus a series of tests where performed for the proposed System before the system was ready for implementation. The various methods for testing the system are

1. Unit Testing

2. Integration Testing Unit Testing: Unit testing is a software verification and validation method in which a programmer tests if individual units of source code are fit for use. A unit is the smallest testable part of an application. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual to being formalized as part of automation. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits. Unit tests find problems early in the development cycle. Unit testing may reduce uncertainty in the units themselves and can be used in a bottomup testing style approach. By testing the parts of a program first and then testing the sum of its parts, integration testing becomes much easier. Integration Testing Integration testing is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing and before system testing. It takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing. The purpose of integration testing is to verify functional, performance, and reliability requirements placed on major design items. Test cases are constructed to test that all components

within assemblages interact correctly, for example across procedure calls or process activations, and this is done after testing individual modules, i.e. unit testing. The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the integration testing of further assemblages. Testing Methods A test method is a definitive procedure that produces a test result. A test can be considered as technical operation that consists of determination of one or more characteristics of a given product, process or service according to a specified procedure. In a software development, it is vital for all interested people to understand and agree upon methods of obtaining data and making measurements. Usually a test method is used to predict or imply suitability for a certain purpose. These may be based on published literature, engineering studies, or formal programs such as quality functional deployment. Validation of the suitability of the test method is often required. Test methods are often scrutinized for their validity and applicability, or their accuracy in a given context. For this reason, it is very important that the scope of the test method be clearly defined, and any aspect included in the scope is shown to be accurate and repeatable through validation. Testing tools Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing tools include features such as: Program monitors, permitting full or partial monitoring of program code. Formatted dump or symbolic debugging, tools allowing inspection of program variables on error at chosen points

Automated functional GUI testing tools are used to repeat system level tests through GUI. Benchmarks, allowing runtime performance comparisons to be made Performance analysis that can help to highlight hot spots and resource usage

Implementation Software implementation is a phase in the software life cycle where the actual software is implemented. The result of this phase consists of source code, together with documentation to make the code more readable. Implementation is the action that must follow any preliminary thinking in order for something to actually happen. It encompasses all the processes involved in getting new software or hardware operating properly in its environment, including installation, configuration and running, testing, and making necessary changes. The complexity of implementing product software differs on several issues. Examples are: the number of end users that will use the product software, the effects that the implementation has on changes of tasks and responsibilities for the end user, the culture and the integrity of the organization where the software is going to be used and the budget available for acquiring product software. Implementation methods can on the one hand be used as a guiding principle, indicating that the method serves as a global idea about how the implementation phase of any project should run. This choice leaves more room for situational factors that are not taken into account in the chosen method, but will result in ambiguity when questions arise in the execution of the implementation process. Post-Implementation and Software Maintenance

A post-implementation review is an assessment and review of the completed working solution. It will be performed after a period of live running, sometime after the project is completed. The main purposes for a Post Implementation review are to ascertain the degree of success from the project, to examine the efficacy of all elements of the working business solution to see if further improvements can be made to optimize the benefit delivered, to learn lessons from the project, lessons which can be used by the team members and by organization to improve future project work and solutions. Maintenance can only happen efficiently if the earlier phases are done properly. There are four major problems that can slow down the maintenance process: unstructured code, maintenance programmers having insufficient knowledge of the system, documentation being absent, out of date or at best insufficient, and software maintenance having a bad image. The success of the maintenance phase relies on these problems being fixed earlier in the life cycle. Maintenance consists of four parts. Corrective maintenance deals with fixing bugs in the code. Adaptive maintenance deals with adapting the software to new environments. Perfective maintenance deals with updating the software according to changes in user requirements. Finally, preventive maintenance deals with updating documentation and making the software more maintainable. All changes to the system can be characterized by these four types of maintenance. Corrective maintenance is traditional maintenance while the other types are considered as software evolution.

Project Legacy

Current status of the project

Our product is to ensure mutual authentication between the client and the server, we will install the software in the client system. Once the client needs connection with a web server, it will send a request to server and client will get a special log in form which contains certain hidden values. It will retrieve by the plug-in and then there will be a communication between plug-in and the server and they will share some variables and values. After sharing those values, both side will calculate certain values and based on these values, plug-in will offer mutual authentication. In order to provide the comparison possible, both sides will use the same functions ie zero knowledge programming functions.

Remaining Areas of concern Technical and Managerial lessons learnt User Manual The main purpose of our product is to provide more security in HTTP layer. This proposed new method is simple and can implement both on a client side as well as a server side. This method can be implemented as an extension to HTTP where HTML forms are used to transmit security parameters between client and server. The proposed method is based on a modified SRP-6 a Zero Knowledge Interactive Protocol method (ZKIP). The following is one
description of a process for authenticating a client to server, but it can be easily extended to mutual authentication.

N, q G U x H()

= = = = = =

(N-1)/2 are prime numbers Generator of the multiplicative group modulo N username value derived from users password hash function random variables

a, b

In the proposed method server sends the first login form containing the username field and other fields that provide certain parameters to the client software for calculating ZKPP functions. The client software detects the special login form and save the ZKPP parameters. Then it calculate the value of A=G^a. It enters the value of A in the hidden field provided by the login form and send back to the server along with the username. After receiving the value of U and A the server will calculate the value of B= G^b + 3*G^x. Then the sever sends the value of B as hidden field in the second login form which contains the field for users password. The client software then calculates the value of x from the captured password. Computing x depends on the method that x was calculated by the server. I.e., client software needs to learn from a server what function and what parameters were used for such a calculation. This information can be conveyed to the client software in one of the login forms as a set of hidden fields. After calculating the value of x the client software will calculate the following parameters.

u =H(A,B) S = (B-3*G^x)^(a+u*x). C = IP address of Server. M1=H(A,B,S,C) Where C is the anti spoof element containing a string which is the IP address of the server resolved by the client software. After computing the values above, the client software enters them into the second login form. If the form had a password field, then M1 replaces that value. Otherwise, it can be entered into a predestinated hidden field. The value C is also entered into a hidden field in that form.

Upon receiving the second login form, the server verifies the value of C whether it matches at least anyone of the IP address used by the server. Then it computes the following. u=H(A,B) S=(A*(G^x)^u)^b C= C M1=H(A,B,S,C )

If M1=M1 we have authentication. In addition we also have a proof that the IP address to which the client is connected is that of the server and not a MITM attacker. Thus, server can safely continue the session it has with the client software knowing that there is no MITM involved.