ABSTRACT

Public-key digital certificate has been widely used in public-key infrastructure (PKI) to provide user public key authentication. However, the public-key digital certificate itself cannot be used as a security factor to authenticate user. In this paper, we propose the concept of generalized digital certificate (GDC) that can be used to provide user authentication and key agreement. A GDC contains users public information, such as the information of users digital drivers license, the information of a digital birth certificate, etc., and a digital signature of the public information signed by a trusted certificate authority (CA). However, the GDC does not contain any users public key. Since the user does not have any private and public key pair, key management in using GDC is much simpler than using public-key digital certificate. The digital signature of the GDC is used as a secret token of each user that will never be revealed to any verifier. Instead, the owner proves to the verifier that he has the knowledge of the signature by responding to the verifiers challenge. Based on this concept, we propose both discrete logarithm (DL)-based and integer factoring (IF)-based protocols that can achieve user authentication and secret key establishment.

TABLE OF CONTENTS

1. INTRODUCTION 11.2 Existing system................................................................51.3 Proposed System........................................................52. MODULES 101.1 Page count Based co-occurrence measures...21.2 Lexical pattern extraction....................................................51.3 Measuring semantic similarity...............................................51.4 Ranking search results...............................................53. SYSTEM ANALYSIS 103.1 Software and Hardware Requirements....113.2 About the Software...123.3 Feasibility Study..163.4 Functional and Non-functional Requirements184. SYSTEM DESIGN205. SAMPLE CODE306. OUTPUT SCREENS487. SYSTEM TESTING578. CONCLUSION 639. FUTURE ENHANCEMENTS 6510. BIBLIOGRAPHY67

1. INTRODUCTION1.1 Overview:We propose an innovative approach which enables a user to be authenticated and a shared secret session key be established with his communication partner using any general form of digital certificates, such as a digital drivers license, a digital birth certificate or a digital ID, etc. We call this kind of digital certificate as a generalized digital certificate (GDC).

A GDC contains users public information and a digital signature of this public information signed by a trusted CA. However, in GDC, the public information does not contain any users public key. Since user does not have any private and public key pair, this type of digital certificate is much easier to manage than the X.509 public-key digital certificates. The digital signature of the GDC is used as a secret token of each user.

The owner of a GDC never reveals signature of GDC to a verifier in plaintext. Instead, the owner computes a response to the verifiers challenge to prove that he has the knowledge of the digital signature. Thus, owning a GDC can provide user authentication in a digital world. In addition, a secret session key can be established between the verifier and the certificate owner during this interaction. There are three entities in a digital certificate application. They are the following: a) Certificate Authority (CA): CA is the person or organization that digitally signs a statement with its private key. In PKI applications, the X.509 public-key digital certificate contains a statement, including the users public key, and a digital signature of the statement. The difference between the GDC and the existing public-key digital certificate is that in a GDC, the public information does not contain any users public key. b) Owner of a GDC: The owner of the GDC is the person who receives the GDC from a trusted CA over a secure channel. The owner needs to compute a valid answer in response to the verifiers challenged question in order to be authenticated and establish a secret session key. c) Verifier: The verifier is the person who challenges the owner of a GDC and validates the answer using the owners public information and CAs public key.In most paper-world user identification applications, a trusted authority is responsible for issuing identification card with user information, such as user name and a personal photo on the card, to each user. Each user can be successfully identified if the user owns a legitimate paper certificate and matches the photo on the card. The built-in tamper-resistant technology made the identification cards very difficult to be forged. Therefore, owning a paper certificate is the factor in the authentication process. In this paper, our goal is to propose a similar solution in electronic-world applications. We call it the generalized digital certificate (GDC). A GDC contains public information of the user and a digital signature of the public information signed by a trusted certificate authority. The digital signature will never be revealed to the verifier. Therefore, the digital signature of a GDC becomes a security factor that can be used for user authentication.

1.2 Existing System

The well-known digital certificate is the X.509 public-key digital certificate [1]. The statement generally contains the users public key as well as some other information. The signer of the digital signature is normally a trusted certificate authority (CA). The X.509 public-key digital certificate has been widely used in public-key infrastructure (PKI) to provide authentication on the users public key contained in the certificate. The user is authenticated if he is able to prove that he has the knowledge of the private key corresponding to the public key specified in the X.509 public-key digital certificate. However, the public key digital certificate itself cannot be used to authenticate a user since a public-key digital certificate contains only public information and can be easily recorded and played back once it has been revealed to a verifier. A traditional digital signature provides authentication of a given message to the receiver. However, this approach can sometimes violate the signers privacy. A malicious receiver can reveal the senders digital signature to any third-party without the senders consent. Subsequently, anyone can access the signers public key and validate the digital signature. In 1989, Chaum and Antwerpen [5] introduced the notion of an undeniable signature, which enables the signer to have a complete control over his/her signature. The verification of an undeniable signature requires participation of the message signer. However, this arrangement can prevent undesirable verifiers from validating the signature. The real problem of the undeniable signature is that the signer needs to authenticate the verifier before helping the verifier to validate the undeniable signature

DISADVANTAGES IN EXISTING SYSTEM Efficient estimation of semantic similarity between words is critical for various natural language processing tasks such as word sense disambiguation (WSD), textual entailment, and automatic text summarization. Semantic similarity between entities changes over time and across domains.

1.3 Proposed systemOur proposed scheme is closely related to the ID-based cryptography. In an ID-based cryptographic algorithm, each user needs to register at a private key generator (PKG) and identify himself before joining the network. Once a user is accepted, the PKG will generate a private key for the user. The users identity (e.g. users name or email address) becomes the corresponding public key.

In this way, in order to verify a digital signature of a message, the sender sends an encrypted message to a receiver, a user only needs to know the identity of his communication partner and the public key of the PKG, which is extremely useful in cases like wireless communication where pre-distribution of authenticated public keys is infeasible. However, in an ID-based cryptographic algorithm, it is assumed that each user already knows the identity of his communication partner. Based on this assumption, there is no need, nor have feasible ways, to authenticate the identity. This is the main advantage of ID-based cryptography. Due to this assumption, ID-based cryptography is only limited to applications that communication entities know each other prior to communication.While in our proposed GDC scheme, the user does not need to know any information of his/her communication partner. The public information of a GDC, such as users identity, can be transmitted and verified by each communication entity. Furthermore, this information is used to authenticate each other. In other words, our proposed schemes support general PKI applications, such as Internet e-commence, that communication entities do not need to know each other prior to the communication. Our proposed solution is based on the combination of a conventional digital signature scheme and the well-known (generalized) Diffie- Hellman assumption.

SOFTWARE REQUIRMENT SPECIFICATION

Introduction: A Software Requirements Specification (SRS) is a complete description of the behaviour of the system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains non-functional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). Functional Requirements: In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Behavioural requirements describing all the cases where the system uses the functional requirements are captured in use cases. Functional requirements are supported by non-functional requirements (also known as quality requirements), which impose constraints on the design or implementation (such as performance requirements, security, or reliability). How a system implements functional requirements is detailed in the system design. In some cases a requirements analyst generates use cases after gathering and validating a set of functional requirements. Each use case illustrates behavioral scenarios through one or more functional requirements. Often, though, an analyst will begin by eliciting a set of use cases, from which the analyst can derive the functional requirements that must be implemented to allow a user to perform each use case. Non Functional Requirements: In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions In general; functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements," and "non-behavioral requirements.Qualities, that is, non-functional requirements, can be divided into two main categories: 1. Execution qualities, such as security and usability, which are observable at run time. 2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.

SYSTEM ANALYSIS

Introduction: To be used efficiently, all computer software needs certain hardware components or other software resources to be present on a computer. These pre-requisites are known as (computer) system requirements and are often used as a guideline as opposed to an absolute rule. Most software defines two sets of system requirements: minimum and recommended. With increasing demand for higher processing power and resources in newer versions of software, system requirements tend to increase over time. Industry analysts suggest that this trend plays a bigger part in driving upgrades to existing computer systems than technological advancements. Hardware Requirements: The most common set of requirements defined by any operating system or software application is the physical computer resources, also known as hardware, a hardware requirements list is often accompanied by a hardware compatibility list (HCL), especially in case of operating systems. An HCL lists tested, compatible, and sometimes incompatible hardware devices for a particular operating system or application. The following sub-sections discuss the various aspects of hardware requirements. Hardware Requirements for Present Project: 1. Input Devices: Keyboard and Mouse 2. RAM: 512 MB 3. Processor: P4 or above 4. Storage: Less than 100 MB of HDD space. Software Requirements: Software Requirements deal with defining software resource requirements and pre-requisites that need to be installed on a computer to provide optimal functioning of an application. These requirements or pre-requisites are generally not included in the software installation package and need to be installed separately before the software is installed. Software Requirements for Present Project: 1. Operating System: Windows XP SP2 or above 2. Run-Time: Java Virtual Machine 3. Apache tomcat server 4. Oracle Database 5. MS-Access Database

SYSTEM ANALYSIS

ABOUT THE SOFTWAREJAVA TECHNOLOGY:Initially the language was called as oak but it was renamed as java in 1995. The primary motivation of this language was the need for a platform-independent (i.e., architecture neutral) language that could be used to create software to be embedded to various consumer electronic devices.1. Java is a programmers language.1. Java is cohesive and consistent.1. Except for those constraints imposed by the Internet environment, Java gives the programmer, full control.1. Finally, Java is to Internet programming where C was to system programming.

JAVA VIRTUAL MACHINE (JVM):Beyond the language, there is the Java Virtual Machine. The Java Virtual Machine is an important element of the Java technology. The virtual machine can be embedded within a web browser or an operating system. Once a piece of java code is loaded on to a machine, it is verified. As part of loading process, a class loader is invoked and does byte code verification makes sure that the code thats has been generated by the compiler will not corrupt the machine that its loaded on. Byte code verification takes place at the end of the compilation process to make sure that is all accurate and correct. So byte code verification is integral to the compiling and executing of java code.

DEVELOPMENT PROCESS OF JAVA PROGRAM:Java programming uses JVM to produce byte codes and executes them. The first box indicates that the Java source code is located in a Java file that is processed with a Java compiler called Javac. The Java compiler produces a file called a .class file, which contains the byte code. The class file is then loaded across the network or loaded locally on your machine into the execution environment is the Java Virtual Machine, which interprets and executes the byte code.

SWINGS

Swing is a large set of components ranging from the very simple, such as labels, to the very complex, such as tables, trees, and styled text documents. Almost all Swing components are derived from a single parent called JComponent which extends the AWT Container class.For this reason, Swing is best described as a layer on top of AWT rather than a replacement for it. Following figure shows a partial JComponent hierarchy. If you compare this with the AWT Component hierarchy of figure 1.1, you will notice that each AWT component has a Swing equivalent that begins with the prefix J. The only exception to this is the AWT Canvas class, for which JComponent, JLabel, or JPanel can be used as a replacement. You will also notice many Swing classes that dont have AWT counterparts.Following Figure represents only a small fraction of the Swing library, but this fraction contains the classes you will be dealing with the most. The rest of Swing exists to provide extensive sup-port and customization capabilities for the components these classes define.

SOME OF THE PACKAGES USED IN SYSTEM ARE:

javax.swingContains the most basic Swing components, default component models and inter-faces. (Most of the classes shown in figure 1.2 are contained in this package.)

javax.swing.borderContains the classes and interfaces used to define specific border styles. Note that borders can be shared by any number of Swing components, as they are not components themselves.

javax.swing.colorchooserContains classes and interfaces that support the JColorChooser component, which is used for color selection. (This package also contains some interesting undocu-mented private classes.)

javax.swing.eventContains all Swing-specific event types and listeners. Swing components also sup-port events and listeners defined in java.awt.event and java.beans.

FEASIBILITY STUDYPreliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation:1. Technical Feasibility1. Operational Feasibility1. Economical Feasibility

TECHNICAL FEASIBILITY:The technical issue usually raised during the feasibility stage of the investigation includes the following:1. Does the necessary technology exist to do what is suggested?1. Do the proposed equipments have the technical capacity to hold the data required to use the new system?1. Will the proposed system provide adequate response to inquiries, regardless of the number or location of users?1. Can the system be upgraded if developed?1. Are there technical guarantees of accuracy, reliability, ease of access and data security?

OPERATIONAL FEASIBILITY:Proposed projects are beneficial only if they can be turned out into information system. That will meet the organizations operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: -1. Is there sufficient support for the management from the users?1. Will the system be used and work properly if it is being developed and implemented?1. Will there be any resistance from the user that will undermine the possible application benefits?This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits.The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status.

ECONOMICAL FEASIBILITY:A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs.

SYSTEM DESIGN

UNIFIED MODELING LANGUAGE DIAGRAMS:The unified modelling language allows the software engineer to express an analysis model using the modelling notation that is governed by a set of syntactic semantic and pragmatic rules.A UML system is represented using five different views that describe the system from distinctly different perspective. Each view is defined by a set of diagram, which is as follows.

User Model View This view represents the system from the users perspective. The analysis representation describes a usage scenario from the end-users perspective.Structural Model View1. In this model the data and functionality are arrived from inside the system.1. This model view models the static structures.Behavioural Model View1. It represents the dynamic of behavioural as parts of the system, depicting the interactions of collection between various structural elements described in the user model and structural model view

.Implementation Model View1. In this the structural and behavioural as parts of the system are represented as they are to be built.Environmental Model View1. In this the structural and behavioural aspects of the environment in which the system is to be implemented are representedUse Case DiagramA use case is a generalization of scenario that is a use case specifies all possible scenarios for a given piece of functionality. An actor initiates a use case. A use case represents the complete flow of events through the system in the sense that it describes a series of related interactions that result from its initiation.The use case defines the scope of the system; they also help in identifying the boundary condition of the system. They help in clarifying the roles of the actor in his interaction with the system.

Sequence Diagram: A sequence diagram in Unified Modelling Language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner.Activity Diagram: Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency.[1] In the Unified Modelling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control. Activity diagrams are constructed from a limited repertoire of shapes, connected with arrows. The most important shape types: * rounded rectangles represent activities; * diamonds represent decisions; * bars represent the start (split) or end (join) of concurrent activities; * a black circle represents the start (initial state) of the workflow; * an encircled black circle represents the end (final state).

State Chart Diagram:A state diagram is a type of diagram used in computer science and related fields to describe the behaviour of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction.

Class Diagram: In software engineering, a class diagram in the Unified Modelling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The class diagram is the main building block in object oriented modelling.They are being used both for general conceptual modelling of the systematic of the application, and for detailed modelling translating the models into programming code. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: A class with three sections: 1. The upper part holds the name of the class1. The middle part contains the attributes of the class 1. The bottom part gives the methods or operations the class can take or undertake

SAMPLE CODE

TestingOverview:

The process of executing a system with the intent of finding errors Testing is defined as the process in which defects are identified, isolated, subjected for rectification and ensured that product is defect free in order to produce the quality product and hence customer satisfaction. Quality is defined as justification of the requirements Defect is nothing but deviation from the requirements. Defect is nothing but bug. Testing----the presence of bugs Testing can demonstrate the presence of bugs, but not their absence Debugging and Testing are not the same thing! Testing is systematic attempt to break a program or the AUT Debugging is the art or method of uncovering why the script/program did not execute properly.

Testing Methodologies:

Black box Testing: is the testing process in which tester can perform testing on an application without having any internal structural knowledge of application.Usually Test Engineers are involved in the black box testing. White box Testing: is the testing process in which tester can perform testing on an application with having internal structural knowledge.Usually the Developers are involved in white box testing. Gray box Testing: is the process in which the combination of black box and white box tonics are used.Types of TestingUnit testing Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors These type of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected.Integration testing Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be localised more quickly and fixed. System testing System testing tests a completely integrated system to verify that it meets its requirements System integration testing System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements.[citation needed] Regression testing Regression testing focuses on finding defects after a major code change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur whenever software functionality that was previously working correctly stops working as intended.Acceptance testing Acceptance testing can mean one of two things: 1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression. 2. Acceptance testing performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development.[citation needed]

Alpha testing Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. van Veenendaal, Erik. "Standard glossary of terms used in Software Testing". Beta testing Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.[citation needed] Non-functional testing Special methods exist to test non-functional aspects of software. In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements).Non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing.

TestCases:

Test No.Test CaseExpected OutputActual OutputResult

1.

Invalid Log In Test:By providing invalidUser name andPasswordA dialog Box to be displayed saying Invalid Login, Access Denied

A dialog Box is displayed saying Invalid Login, Access Denied

Passed

2Valid Log In Test: By providing Valid User name and Password

The Text Screen for accepting the text to be shown

The Text Screen for accepting the text is shown

Passed

3Invalid input text : By providing invalid format of data

It will not generate cipher text

It will show error passed

4Valid inputs text: By providing valid format of data(.txt file only)

It will calculate cipher text

It will show cipher text and convert into plain text

Passed

5. Invalid port number: By providing invalid port in server and client it will not connect each other.

It will show error It will show error passed

Conclusion

In this paper, we have proposed a novel design in using a GDC for user authentication and key establishment. In our design, a GDC does not contain the users public key. Since the user does not have any private and public key pair, this type of digital certificate is much easier to manage than the X.509 public-key digital certificates. Our approach can be applied to both DL-based and IF-based public-key cryptosystems.

Future Scope

Bibliography

[1] Network Working Group, Internet X.509 public key infrastructure certificate and crl profile, RFC: 2459," Jan. 1999. [2] C. Tang and D. Wu, An efficient mobile authentication scheme for wireless networks," IEEE Trans. Wireless Commun., vol. 7, pp. 1408- 1416, Apr. 2008. [3] G. Yang, Q. Huang, D. Wong, and X. Deng, An efficient mobile authentication scheme for wireless networks," IEEE Trans. Wireless Commun., vol. 9, pp. 168-174, Jan. 2010. [4] J. Chun, J. Hwang, and D. Lee, A note on leakage-resilient authenticated key exchange," IEEE Trans. Wireless Commun., vol. 8, pp. 2274- 2279, May 2009. [5] D. Chaum and H. van Antwerpen, Undeniable signatures," Advances in Cryptology - Crypto89, Lecture Notes in Computer Science, vol. 435, pp. 212-217, 1989. [6] M. Bohj and M. Kjeldsen, Cryptography report: undeniable signature schemes," Tech. Rep., Dec. 15, 2006. [7] X. Huang, Y. Mu, W. Susilo, and W. Wu, Provably secure pairing-based convertible undeniable signature with short signature length," Pairing-Based Cryptography -C Pairing 2007, vol. 4575/2007 of Lecture Notes in Computer Science, pp. 367-391, Springer Berlin / Heidelberg, 2007. [8] M. Jakobsson, K. Sako, and R. Impagliazzo, Designated verifier proofs and their applications," Advances in Cryptology - EUROCRYPT, pp. 143-154, 1996. LNCS Vol 1070. [9] D. Chaum, Private signature and proof systems," 1996. [10] R. Rivest, A. Shamir, and Y. Tauman, How to leak a secret," Advances in Cryptology-ASIACRYPT, Lecture Notes in Computer Science, vol. 2248/2001, Springer Berlin / Heidelberg, 2001.