zero knowledge password proof
Post on 26-Oct-2014
32 Views
Preview:
TRANSCRIPT
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
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.
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
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.
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
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 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
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 = (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.
top related