Zero Knowledge Password Proof

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 man-

in-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 user’s 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 don’t 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





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 man-

in-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.




to store user’s credentials. The proposed method can be implemented as an extension to HTTP, It



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 plug-

in 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 doesn’t 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.

3 System Features

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 don’t even

using digital signatures.

2. SYSTEM OVERVIEW




to store user’s credentials. The proposed method can be implemented as an extension to HTTP, it



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

3.2 Decomposition Description

Sequence Diagram

useruser plug-inplug-in mail server server

1: log in()

2: client authentication()

7: response()

3: server authentication()

4: response()

5: check_response_ok())

6: request()

Collaboration Diagram

Server

user plug-in

1: log in()

2: client authentication()

3: server authentication()

4: response()

5: check_response_ok()

6: request()

7: response()

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





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 won’t 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 bottom-

up 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


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 = (N-1)/2 are prime numbers G = Generator of the multiplicative group modulo N U = username x = value derived from user’s password H() = hash function a, b = random variables

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 user’s 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.

Zero Knowledge Password Proof

Documents

secure ssl

knowledge

knowledge

anonymous

phisher manually

store users

offer mutual

ensure mutual