11203203 project document

SECURE AND SCALABLE SHARING OF PERSONAL HEALTH RECORDS IN

CLOUD COMPUTING USING ATTRIBUTE BASED ENCRYPTION

A Project Report Submitted in partial fulfillment of the

Requirements for the award of the Degree of

MASTER OF COMPUTER APPLICATIONS

Submitted By

T.HEMALATHA

Regd No: 11203203

Under the Esteemed guidance of

Mr. L. JAGJEEVAN RAO, MCA, M.Tech

Assistant Professor

DEPARTMENT OF MCA

K L University

Estd. U/s 3 of UGC Act 1956, Accredited by NAAC A Grade ISO 9001: 2000

Green Fields, Vaddeswaram, P.O, Guntur Dt-522 502

June 2014

DEPARTMENT OF MASTER OF COMPUTER APPLICATIONS

CERTIFICATE

This is to certify that the project work entitled SECURE AND SCLABLE SHARING

OF PERSONAL HELATH RECORDS IN CLOUD COMPUTING USING ATTRINUTR

BASED ENCRYPTION submitted by T.HEMALATHA (11203203) in partial fulfillment of the

award of degree of Master Of Computer Applications during the academic year 2011-2014,has

been successfully completed.

INTERNAL GUIDE Prof.S.VENKATESWARLU

Mr. L. JAGJEEVAN RAO Head of the Department

Asst. Professor Department Of MCA

Department Of MCA KLUniversity

DECLARATION

I, T.HEMALATHA hereby declare that the work which is being presented in the

dissertation entitled SECURE AND SCALABLE SHARING OF PERSONAL HEALTH

RECORDS IN CLOUD COMPUTING USING ATTRIBUTE BASED ENCRYPTION in

the partial fulfillment of the requirements for the award of degree of Master Of Computer

Applications submitted to the department of Master Of Computer Applications from

KLUniversity, Vaddeswaram is my original work carried out during the period from January

2014 to June 2014.

I have not submitted the matter embodied in this dissertation for the award of any other

degree.

Date:

(T.HEMALATHA)

R.NO:11203203

ACKNOWLEDGEMENT

Apart from the efforts of me, the success of any work depends largely on the

encouragement and guidelines of many others. I take this opportunity to express my gratitude

to the people who have been instrumental in the successful completion of this end semester

report.

Firstly, I would like to thank the President Mr.KoneruSatyanarayana, Chancellor

Mr.G.L.Datta and Vice-chancellor Mr. L.S.S.Reddy, for providing me an opportunity and

facilities to do this project.

I would like to show my greatest appreciation to Dr. A.Anand Kumar, Principal

KLU College of Engineering, for his valuable suggestions and statements.

I am deeply indebted to my internal guide Asst Prof. S. Venkateswarlu, Head Of

Dept, MCA. I cant say thank you enough for his tremendous support and help. I feel

motivated and encouraged every time I attend his meeting. Without his encouragement and

guidance this thesis would not have materialized.

Finally, I owe a lot to the teaching and non-teaching staff of the Dept. of MCA for

their direct or indirect support in doing my Project work.

(T.HEMALATHA)

--------------------------------------------------------------------------------------------------------------------- ----------------

CONTENTS PAGE NO --------------------------------------------------------------------------------------------------------------------- ----------------

ABSTRACT

1. INTRODUCTION------------------------------------------------------------------------------------------------ 1

1.1 ORGANIZATIONPROFILE--------------------------------------------------------------------------------- 2

1.1 PURPOSE OF THE SYSTEM-------------------------------------------------------------------------------- 2

1.2 SCOPE OF THE SYSTEM------------------------------------------------------------------------------------ 3

1.3 EXISTING SYSTEM AND DRAWBACKS---------------------------------------------------------------- 3

1.4 PROPOSED SYSTEM------------------------------------------------------------------------------------------ 4

2. SYSTEM ANALYSIS-------------------------------------------------------------------------------------------- 5

2.1 FUNCTIONAL REQUIREMENTS--------------------------------------------------------------------------- 6

2.2 NON FUNCTIONAL REQUIREMENTS------------------------------------------------------------------- 10

2.3 HARDWARE AND SOFTWARE SPECIFICATIONS---------------------------------------------------- 12

2.4 ANALYSIS---------------------------------------------------------------------------------------------------------- 13

3. SYSTEM DESIGN------------------------------------------------------------------------------------------------- 16

3.1 DESIGN METHODOLOGY---------------------------------------------------------------------------------- 17

3.2. SYSTEM ARCHITECTURE-------------------------------------------------------------------------------- 18

3.3UML DIAGRAMS----------------------------------------------------------------------------------------- ----- 18

3.4 DATA DICTIONARY--------------------------------------------------------------------------------------- - 28

3.5 DESIGN PRINCIPLES-------------------------------------------------------------------------------------- ---- 30

3.6. DATABASE DESIGN----------------------------------------------------------------------------------------- 30

4. SYSTEM IMPLEMENTATION------------------------------------------------------------------------------- 36

4.1 MODULES------------------------------------------------------------------------------------------------------- 37

4.2 CODE FOR THE PROPOSED SYSTEM------------------------------------------------------------------ 39

4.3. OUTPUT SCREENS------------------------------------------------------------------------------------------ 45

5. SYSTEM TESTING--------------------------------------------------------------------------------------------- 59

5.1. TYPES OF TESTING---------------------------------------------------------------------------------------- 60

5.2. TEST CASES-------------------------------------------------------------------------------------------------- 64

6. CONCLUSION--------------------------------------------------------------------------------------------------- 65

7. BIBILOGRAPHY---------------------------------------------------------------------------------------------- 67

SECURE AND SCALABLE SHARING OF PERSONAL HEALTH RECORDS IN CLOUD COMPUTING USING ATTRIBUTE

BASED ENCRYPTION

K L University R.No:11203203

ABSTRACT

Personal health record (PHR) is an emerging patient-centric model of health

information exchange, which is often outsourced to be stored at a third party, such as cloud

providers. However, there have been wide privacy concerns as personal health information could

be exposed to those third party servers and to unauthorized parties. To assure the patients

control over access to their own PHRs, it is a promising method to encrypt the PHRs before

outsourcing. Yet, issues such as risks of privacy exposure, scalability in key management,

flexible access and efficient user revocation, have remained the most important challenges

toward achieving fine-grained, cryptographically enforced data access control. In this paper, we

propose a novel patient-centric framework and a suite of mechanisms for data access control to

PHRs stored in semi-trusted servers. To achieve fine-grained and scalable data access control for

PHRs, we leverage attribute based encryption (ABE) techniques to encrypt each patients PHR

file. Different from previous works in secure data outsourcing, we focus on the multiple data

owner scenario, and divide the users in the PHR system into multiple security domains that

greatly reduces the key management complexity for owners and users. A high degree of patient

privacy is guaranteed simultaneously by exploiting multi-authority ABE. Our scheme also

enables dynamic modification of access policies or file attributes, supports efficient on-demand

user/attribute revocation and break-glass access under emergency scenarios. Extensive analytical

and experimental results are presented which show the security, scalability and efficiency of our

proposed scheme.

SECURE AND SCALABLE SHARING OF PERSONAL HEALTH RECOREDS IN CLOUD COMPUTING USING ATTRIBUTE

BASED ENCRYPTION

K L University 1 R.NO:11203203

INTRODUCTION


BASED ENCRYPTION


1.1 ORGANIZATION PROFILE:

INFOPARK SOFTWARE TECHNOLOGIES is a proprietary firm

incepted in the year 1999.Infopark basic activities is development and training in the fields of

computer science and Information technology.

The core team behind Infopark is a group of engineers with immense experience in various

technologies like Mobile, web and database.Infopark provides software development and

consultancy services to various I.T and non I.T firms. The software development include tailor

made solutions, web development services, and product maintenance services.

Infopark is the only Training Center in Vijayawada with Mac Machines for the Training of iOS

and Final Cut Pro(FCP).The Company is also Providing BPO Services like E-Accounting to the

USA clients, and also Training the Commerce Students on Quick Books (a leading Accounting

Software in U.S and Canada) for BPO jobs.

Infopark was also a consortium member for A.P Govt 1000 schools computer education project,

and success fully implemented and executed the project in 145 schools in Rangareddy, Chittor,

Kadapa and Nellore districts during 2001-2010.

1.2. PURPOSE OF THE PROJECT

The personal health record system needs security against attackers and hackers. Scalable and

Secure sharing includes basic securities to protect the information from unauthorized access and

loss. This paper proposed the new approach for existing PHR system for providing more

security using attribute based encryption which plays an important role because these are

unique and not easily hack able. We are reducing key management problem and also we

enhance privacy guarantee


BASED ENCRYPTION


1.3 . SCOPE OF THE SYSTEM

1. Quickly find out information of patient details.

2. In case of emergency doctor and other emergency department quickly get all the details

all the informative details and start treatment.

3. If in any condition doctors and medical facilities are not available the PHR owner itself

able to take care of his health.

4. To provide easy and faster access information.

5. To provide user friendly environment.

6. To provide data confidentiality and write access control

1.4. EXISTING SYSTEM AND DRAWBACKS

In Existing system a PHR system model, there are multiple owners who may encrypt

according to their own ways, possibly using different sets of cryptographic keys. Letting each

user obtain keys from every owner whos PHR she wants to read would limit the accessibility

since patients are not always online. An alternative is to employ a central authority (CA) to do

the key management on behalf of all PHR owners, but this requires too much trust on a single

authority (i.e., cause the key escrow problem).

Key escrow (also known as a fair cryptosystem) is an arrangement in which the keys

needed to decrypt encrypted data are held in escrow so that, under certain circumstances, an

authorized third party may gain access to those keys. These third parties may include businesses,

who may want access to employees' private communications, or governments, who may wish to

be able to view the contents of encrypted communications.


BASED ENCRYPTION


1.5. PROPOSED SYSTEM

We endeavor to study the patient centric, secure sharing of PHRs stored on semi-trusted

servers, and focus on addressing the complicated and challenging key management issues. In

order to protect the personal health data stored on a semi-trusted server, we adopt attribute-based

encryption (ABE) as the main encryption primitive.

Using ABE, access policies are expressed based on the attributes of users or data, which

enables a patient to selectively share her PHR among a set of users by encrypting the file under a

set of attributes, without the need to know a complete list of users.

The complexities per encryption, key generation and decryption are only linear with the number

of attributes involved.


BASED ENCRYPTION


SYSTEM ANALYSIS


BASED ENCRYPTION


2.1 FUNCTIONAL REQUIREMENTS

1. INPUT DESIGN

The input design is the link between the information system and the user. It

comprises the developing specification and procedures for data preparation and those steps are

necessary to put transaction data in to a usable form for processing can be achieved by inspecting

the computer to read data from a written or printed document or it can occur by having people

keying the data directly into the system. The design of input focuses on controlling the amount of

input required, controlling the errors, avoiding delay, avoiding extra steps and keeping the

process simple. The input is designed in such a way so that it provides security and ease of use

with retaining the privacy. Input Design considered the following things:-

What data should be given as input?

How the data should be arranged or coded?

The dialog to guide the operating personnel in providing input.

Methods for preparing input validations and steps to follow when error occur.

Objectives

1. Input Design is the process of converting a user-oriented description of the input into a

computer-based system. This design is important to avoid errors in the data input process

and show the correct direction to the management for getting correct information from the

computerized system.

2. It is achieved by creating user-friendly screens for the data entry to handle large volume of

data. The goal of designing input is to make data entry easier and to be free from errors.

The data entry screen is designed in such a way that all the data manipulates can be

performed. It also provides record viewing facilities.

3. When the data is entered it will check for its validity. Data can be entered with the help of

screens. Appropriate messages are provided as when needed so that the user will not be in


BASED ENCRYPTION


maize of instant. Thus the objective of input design is to create an input layout that is easy

to follow.

USER INTERFACE DESIGN

It is essential to consult the system users and discuss their needs while designing

the user interface.

CLASSIFICATION OF USER INTERFACE SYSTEMS

User-initiated interfaces

The user is in charge, controlling the progress of the user/computer dialogue. User

initiated interfaces fall into low approximate classes. They are:-

1. Command driven interfaces: - In this type of interface, the user inputs commands or

queries which are interpreted by the computer.

2. Forms oriented interface: - The user calls up an image of the form to his/her screen

and fills in the form. The forms oriented interface is chosen because it is the best

choice.

Computer-initiated interfaces

In the computer-initiated interface, the computer selects the next stage in the

interaction. The computer guides the progress of the user/computer dialogue. Information is

displayed and the user response of the computer takes action or displays further information. The

following computer initiated interfaces were used. They are:-

1. The menu system for the user is presented with a list of alternatives and the user

chooses one out of those alternatives.

2. Question & Answer type dialog system is used where the computer asks question and

takes action based on the users reply.

Right from the start, the system is going to be menu driven and the opening

menu displays the available options. Choosing one option gives another popup menu with


BASED ENCRYPTION


more options. In this way every option leads the users to data entry form where the user can

key in the data.

Error message design

The design of error messages is an important part of the user interface design.

As user is bound to commit some errors or other while designing a system, the system should be

designed to be helpful by providing the user with information regarding the error he/she has

committed.

This application must also be able to produce outputs at different modules for

different inputs.

2. OUTPUT DESIGN

A quality output is one, which meets the requirements of the end user and

presents the information clearly. In any system results of processing are communicated to the

users and to other system through outputs. In output design it is determined how the information

is to be displaced for immediate need and also the hard copy output. It is the most important and

direct source information to the user. Efficient and intelligent output design improves the

systems relationship to help user decision-making.

1. Designing computer output should proceed in an organized, well thought out manner; the

right output must be developed while ensuring that each output element is designed so that

people will find the system can use easily and effectively. When analysis design computer

output, they should Identify the specific output that is needed to meet the requirements.

2. Select methods for presenting information.

3. Create document, report, or other formats that contain information produced by the system.

The output form of an information system should accomplish one or more of the

following objectives.

Convey information about past activities, current status or projections of the

Future.


BASED ENCRYPTION


Signal important events, opportunities, problems, or warnings.

Trigger an action.

Confirm an action.

ERROR AVOIDANCE:

At this stage care is to be taken to ensure that input data remains accurate form the stage

at which it is recorded up to the stage in which the data is accepted by the system. This can be

achieved only by means of careful control each time the data is handled.

ERROR DETECTION:

Even though every effort is make to avoid the occurrence of errors, still a small

proportion of errors are always likely to occur, these types of errors can be discovered by using

validations to check the input data.

DATA VALIDATION:

Procedures are designed to detect errors in data at a lower level of detail. Data

validations have been included in the system in almost every area where there is a possibility for

the user to commit errors. The system will not accept invalid data. Whenever an invalid data is

keyed in, the system immediately prompts the user and the user has to again key in the data and

the system will accept the data only if the data is correct. Validations have been included where

necessary.

The system is designed to be a user friendly one. In other words the system has

been designed to communicate effectively with the user. The system has been designed with

popup menus.

PERFORMANCE REQUIREMENTS:

Performance is measured in terms of the output provided by the application.

Requirement specification plays an important part in the analysis of a system. Only when the

requirement specifications are properly given, it is possible to design a system, which will fit into

required environment. It rests largely in the part of the users of the existing system to give the


BASED ENCRYPTION


requirement specifications because they are the people who finally use the system. This is

because the requirements have to be known during the initial stages so that the system can be

designed according to those requirements.

It is very difficult to change the system once it has been designed and on the other

hand designing a system, which does not cater to the requirements of the user, is of no use. The

requirement specification for any system can be broadly stated as given below:-

The system should be able to interface with the existing system

The system should be accurate

The system should be better than the existing system

The existing system is completely dependent on the user to perform all the duties.

2.2. NON FUNCTIONAL REQUIREMENTS

Describe the existing non-functional (also referred to as Quality of Service by the International

Institute of Business Analysts, Business Analysis Body of Knowledge), technical environment,

systems, functions, and processes. Include an overview of the non-functional requirements

necessary to achieve the projects objectives.

2.2.1. Hardware Requirements

Describe hardware requirements and any related processes. Include a detailed description of

specific hardware requirements and associate them to specific project functionality/deliverables.

Include information such as type of hardware, brand name, specifications, size, security, etc.

Assign a unique ID number to each requirement.

2.2.2. Software Requirements

Describe software requirements and any related processes. Include a detailed description of

specific software requirements and associate them to specific project functionality/deliverables.

Include information such as in-house development or purchasing, security, coding language,

version numbering, functionality, data, interface requirements, brand name, specifications, etc.

Assign a unique ID number to each requirement.


BASED ENCRYPTION


2.2.3. Performance Requirements

Describe performance requirements and any related processes. Include a detailed description of

specific performance requirements and associate them to specific project

functionality/deliverables. Include information such as cycle time, speed per transaction, test

requirements, minimum bug counts, speed, reliability, utilization etc.

2.2.4. Supportability Requirements

Describe all of the technical requirements that affect supportability and maintainability such as

coding standards, naming conventions, maintenance access, required utilities, etc. Assign a

unique ID number to each requirement.

2.2.5. Security Requirements

Describe all of the technical requirements that affect security such as security audits,

cryptography, user data, system identification/authentication, resource utilization, etc. Assign a

unique ID number to each requirement.

2.2.6. Interface Requirements

Describe all of the technical requirements that affect interfaces such as protocol management,

scheduling, directory services, broadcasts, message types, error and buffer management, security,

etc. Assign a unique ID number to each requirement.

2.2.7. Availability Requirements

Describe all of the technical requirements that affect availability such as hours of operation, level

of availability required, down-time impact, support availability, etc. Assign a unique ID number

to each requirement.

2.2.8. Assumptions / Constraints

Describe any technical assumptions / constraints related to any of the projects requirements.


BASED ENCRYPTION


2.3. SYSTEM REQUIREMENT SPECIFICATION:

MINMUM HARDWARE REQUIRED:

System : Pentium IV 1.8 GHz (recommended)

Hard Disk : 40 GB

RAM : 512 MB (recommended)

SOFTWARE REQUIRED

Operating System : Windows XP, or VISTA or 7 or 8

Coding language : ASP.NET with C#

Database : SQL SERVER 2008

Software Tools : Microsoft visual studio 2012


BASED ENCRYPTION


2.4 SYSTEM ANALYSIS

2.4.1 MODULES

1. Registration

2. Upload files

3. ABE for Fine-grained Data Access Control

4. Setup and Key Distribution

5. Break-glass

MODULES DESCRIPTION

1. Registration

In this module normal registration for the multiple users. There are multiple

owners, multiple AAs, and multiple users. The attribute hierarchy of files leaf nodes is atomic

file categories while internal nodes are compound categories. Dark boxes are the categories that

a PSDs data reader has access to.

Two ABE systems are involved: for each PSD the revocable KP-ABE scheme is

adopted for each PUD, our proposed revocable MA-ABE scheme.

PUD - public domains

PSD - personal domains

AA - attribute authority

MA-ABE - multi-authority ABE

KP-ABE - key policy ABE

2. Upload files:

In this module, users upload their files with secure key probabilities. The owners upload

ABE-encrypted PHR files to the server. Each owners PHR file encrypted both under a certain

fine grained model.


BASED ENCRYPTION


3. ABE for Fine-grained Data Access Control

In this module ABE to realize fine-grained access control for outsourced data

especially, there has been an increasing interest in applying ABE to secure electronic healthcare

records (EHRs). An attribute-based infrastructure for EHR systems, where each patients EHR

files are encrypted using a broadcast variant of CP-ABE that allows direct revocation. However,

the cipher text length grows linearly with the number of UN revoked users. In a variant of ABE

that allows delegation of access rights is proposed for encrypted EHRs applied cipher text policy

ABE (CP-ABE) to manage the sharing of PHRs, and introduced the concept of

social/professional domains investigated using ABE to generate self-protecting EMRs, which

can either be stored on cloud servers or cell phones so that EMR could be accessed when the

health provider is offline.

4. Setup and Key Distribution

In this module the system first defines a common universe of data

attributes shared by every PSD, such as basic profile, medical history, allergies, and

prescriptions. An emergency attribute is also defined for break-glass access. Each PHR

owners client application generates its corresponding public/master keys. The public keys can

be published via users profile in an online healthcare social-network (HSN)

There are two ways for distributing secret keys.

First, when first using the PHR service, a PHR owner can specify the access

privilege of a data reader in her PSD, and let her application generate and

distribute corresponding key to the latter, in a way resembling invitations in

GoogleDoc.

Second, a reader in PSD could obtain the secret key by sending a request

(indicating which types of files she wants to access) to the PHR owner via HSN,

and the owner will grant her a subset of requested data types. Based on that, the

policy engine of the application automatically derives an access structure, and

runs keygen of KP-ABE to generate the user secret key that embeds her access

structure.


BASED ENCRYPTION


5. Break-glass module

In this module when an emergency happens, the regular access policies may no

longer be applicable. To handle this situation, break-glass access is needed to access the victims

PHR. In our framework, each owners PHRs access right is also delegated to an emergency

department ED to prevent from abuse of break-glass option, the emergency staff needs to contact

the ED to verify her identity and the emergency situation, and obtain temporary read keys. After

the emergency is over, the patient can revoke the emergent access via the ED.


BASED ENCRYPTION


SYSTEM DESIGN


BASED ENCRYPTION


3.1. DESIGN METHODOLOGY:

Software design sits at the technical kernel of the software engineering process and is

applied regardless of the development paradigm and area of application. Design is the first step

in the development phase for any engineered product or system. The designers goal is to

produce a model or representation of an entity that will later be built. Beginning, once system

requirement have been specified and analyzed, system design is the first of the three technical

activities -design, code and test that is required to build and verify software.

The importance can be stated with a single word Quality. Design is the place

where quality is fostered in software development. Design provides us with representations of

software that can assess for quality. Design is the only way that we can accurately translate a

customers view into a finished software product or system. Software design serves as a

foundation for all the software engineering steps that follow. Without a strong design we risk

building an unstable system one that will be difficult to test, one whose quality cannot be

assessed until the last stage.

During design, progressive refinement of data structure, program structure, and

procedural details are developed reviewed and documented. System design can be viewed from

either technical or project management perspective. From the technical point of view, design is

comprised of four activities architectural design, data structure design, interface design and

procedural design.


BASED ENCRYPTION


3.2. SYSTEM ARCHITECTURE

Figure 1: Architecture of system.

3.3. UML DIAGRAMS:

3.3.1. UML (Unified Modeling Language):

It is a language to specifying, visualizing and constructing the artifacts of software

system as well as for business models. GRADY BOOCH, IVAR JACCOBSON and JAMES

RUMBUGH found it. The UML notation is useful for graphically depicting Object Oriented

Analysis and Object Oriented Design (OOA and OOD) modules.

The unified modeling language is a standard language for specifying,

Visualizing, Constructing and documenting the software system and its components. It is a

graphical language that provides a vocabulary and set of semantics and rules. The UML focuses

on the Conceptual and physical representation of the system. It captures the decisions and


BASED ENCRYPTION


understandings about systems that must be constructed. It is used to understand, design,

configure, maintain and control information about the systems.

Visualizing:

Through UML I see or visualize an existing system and ultimately I visualize how the

system is going to be after implementation. Unless I think I cannot implement.

Specifying:

Specifying means building models that are precise, unambiguous and complete UML

addresses the specification of all the important Analysis Design, Implementation decisions that

must be made in developing and deploying a software system.

Constructing:

UMLs models can be directly connected to a variety of programming language through

mapping a model from UML to a programming language like Java or C++ or VB. Forward

Engineering and Reverse Engineering is possible through UML.

Documenting:

The deliverables of a project apart from coding are some artifacts which are critical in

controlling, measuring and communicating about a system during its development viz.

Requirements, Architecture, Design, Source code, Project plans, Tests, Prototypes, Releases etc.

Diagrams in UML:

Diagrams are graphical presentation of set of elements. Diagrams project a system, or

visualize a system from different angles and perspectives.

The UML has nine diagrams these diagrams can be classified into the following groups.


BASED ENCRYPTION


Static:--

a. Class diagrams.

b. Object diagrams.

c. Component diagrams.

d. Deployment diagrams

Dynamic:

a. Use case diagram.

b. Sequence diagram.

c. Collaboration diagram.

d. State chart diagram.

e. Activity diagram.

3.3.1. STRUCTURAL DIAGRAMS:

Class diagram

This shows a set of classes, interfaces, collaborations and their relationships. There are

the most common diagrams in modeling the object oriented systems and are used to give the

static view of a system.

Object diagram

Shows a set of objects and their relationships and are used to show the data structures,

the static snapshots of instances of the elements in a class diagram. Like class diagram, the object

diagrams also address the static design view or process view of a system.

Component diagram

Shows a set of components and their relationships and are used to illustrate the static

implementation view of a system. They are related to class diagrams where in components map

to one or more classes, interfaces of collaborations.


BASED ENCRYPTION


Deployment diagram

Shows a set of nodes and their relationships. They are used to show the static deployment

view of the architecture of a system. They are related to the component diagrams where a node

encloses one or more components.

3.3.1. BEHAVIOURAL DIAGRAMS:

Use Case diagram

Shows a set of use cases and actors and their relationships. These diagrams illustrate the

static use case view of a system and are important in organizing and modeling of a system.

Sequence diagram & collaboration diagram

These two diagrams are semantically same i.e. the dynamics of a system can be modeled

using one diagram and transform it to the other kind of diagram without loss of information.

Both form the, Interaction diagram.

Sequence diagram

Sequence diagram is an interaction diagram which focuses on the time ordering of

messages it shows a set of objects and messages exchange between these objects. This diagram

illustrates the dynamic view of a system.

Collaboration diagram

This diagram is an interaction diagram that stresses or emphasizes the structural

organization of the objects that send and receive messages. It shows a set of objects, links

between objects and messages send and received by those objects. There are used to illustrate the

dynamic vies of a system.


BASED ENCRYPTION


UML DIAGRAMS

Class Diagram:

A class diagram is a type of static structure diagram that describes the structure of a

system by showing the systems classes, their attributes, operations and relationships among the

classes.

Figure 1: class diagram


BASED ENCRYPTION


Use Case Diagram:

A usecase diagram is a representation of users interaction with the system and depecting the

specifications of a usecase.

Upload Files

Generate Secret Keys

Data_Owner

Maintain Secret key

Register

Login

Search Files

Display's Required Datas

User.

Emergency Break Glass

Figure 2: UseCase diagram


BASED ENCRYPTION


Sequence Diagram:

A sequence diagram shows object interactions arranged in time sequence.

Figure 3: Sequence diagram


BASED ENCRYPTION


Collaboration Diagram:

This diagram is an interaction diagram that stresses or emphasizes the structural

organization of the objects that send and receive messages. It shows a set of objects, links

between objects and messages send and received by those objects. There are used to illustrate the

dynamic vies of a system.

: DataOwner : User

Cloud

Server

1: Upload the Files

2: Create Account3: Maintain Details

4: Generate keys

5: Search for Files

6: Ask Secret Key

7: Send Secret key

8: Send Required Files

9: Send Duplicate Data

10: Break glass

11: Send Temporary secret key

12: Download files

Figure 4: Collaboration diagram


BASED ENCRYPTION


Flow chart Diagram:

Figure 5: flow chart diagram


BASED ENCRYPTION


Activity Diagram:

The activity Diagram describes the dynamic aspects of the system and is basically a flow

chart to represent the flow from one activity to another activity where the activity can be

described as an operation of a system.

Figure 6: Activity diagram


BASED ENCRYPTION


3.4. DATA DICTIONARY

In database management systems, a file that defines the basic organization of a database. A data

dictionary contains a list of all files in the database, the number of records in each file and the

names and types of each field.

Data dictionary do not contain any actual data from the database, only bookkeeping information

for managing it. Without a data dictionary, however a database management system cannot

access data from the database.

3.4.1. Data Dictionary for the Project


BASED ENCRYPTION



BASED ENCRYPTION


3.5. DESIGN PRINCIPLES

1. David [DAV95] suggests a set of principles for software design:

- The design process should not suffer from tunnel vision.

- The design should be traceable to the analysis model.

- The design should not reinvent the wheel.

2. - The design should minimize the intellectual distance between the software and the

problem in the real world.

- The design should exhibit uniformity and integration.

- The design should be structured to accommodate change.

- The design should be structured to degrade gently.

- Design is not coding.

- The design should be assessed for quality.

- The design should reviewed to minimize conceptual errors.

3. External quality factors: observed by users.

4. Internal quality factors: important to engineers

3.6. DATABASE DESIGN

SQL SERVER -2008

A database management, or DBMS, gives the user access to their data and helps

them transform the data into information. Such database management systems include dBase,

paradox, IMS, SQL Server and SQL Server. These systems allow users to create, update and

extract information from their database.

A database is a structured collection of data. Data refers to the characteristics of

people, things and events. SQL Server stores each data item in its own fields. In SQL Server,

the fields relating to a particular person, thing or event are bundled together to form a single

complete unit of data, called a record (it can also be referred to as raw or an occurrence). Each

record is made up of a number of fields. No two fields in a record can have the same field name.


BASED ENCRYPTION


SQL SERVER TABLES

SQL Server stores records relating to each other in a table. Different tables are

created for the various groups of information. Related tables are grouped together to form a

database.

PRIMARY KEY

Every table in SQL Server has a field or a combination of fields that uniquely

identifies each record in the table. The Unique identifier is called the Primary Key, or simply the

Key. The primary key provides the means to distinguish one record from all other in a table. It

allows the user and the database system to identify, locate and refer to one particular record in

the database.

RELATIONAL DATABASE

Sometimes all the information of interest to a business operation can be stored in

one table. SQL Server makes it very easy to link the data in multiple tables. Matching an

employee to the department in which they work is one example. This is what makes SQL Server

a relational database management system, or RDBMS. It stores data in two or more tables and

enables you to define relationships between the tables and enables you to define relationships

between the tables.

FOREIGN KEY

When a field is one table matches the primary key of another field is referred to as

a foreign key. A foreign key is a field or a group of fields in one table whose values match those

of the primary key of another table.

REFERENTIAL INTEGRITY

Not only does SQL Server allow you to link multiple tables, it also maintains

consistency between them. Ensuring that the data among related tables is correctly matched is

referred to as maintaining referential integrity.


BASED ENCRYPTION


DATA ABSTRACTION

A major purpose of a database system is to provide users with an abstract view of

the data. This system hides certain details of how the data is stored and maintained. Data

abstraction is divided into three levels.

Physical level: This is the lowest level of abstraction at which one describes how the data are

actually stored.

Conceptual Level: At this level of database abstraction all the attributed and what data are

actually stored is described and entries and relationship among them.

View level: This is the highest level of abstraction at which one describes only part of the

database.

ADVANTAGES OF RDBMS

Redundancy can be avoided

Inconsistency can be eliminated

Data can be Shared

Standards can be enforced

Security restrictions can be applied

Integrity can be maintained

Conflicting requirements can be balanced

Data independence can be achieved.

DISADVANTAGES OF DBMS

A significant disadvantage of the DBMS system is cost. In addition to the cost of

purchasing of developing the software, the hardware has to be upgraded to allow for the

extensive programs and the workspace required for their execution and storage. While

centralization reduces duplication, the lack of duplication requires that the database be

adequately backed up so that in case of failure the data can be recovered.


BASED ENCRYPTION


FEATURES OF SQL SERVER (RDBMS)

SQL SERVER is one of the leading database management systems (DBMS)

because it is the only Database that meets the uncompromising requirements of todays most

demanding information systems. From complex decision support systems (DSS) to the most

rigorous online transaction processing (OLTP) application, even application that require

simultaneous DSS and OLTP access to the same critical data, SQL Server leads the industry in

both performance and capability.

SQL SERVER is a truly portable, distributed, and open DBMS that delivers unmatched

performance, continuous operation and support for every database.

SQL SERVER RDBMS is high performance fault tolerant DBMS which is specially

designed for online transactions processing and for handling large database application.

SQL SERVER with transactions processing option offers two features which contribute

to very high level of transaction processing throughput.

ENTERPRISE WIDE DATA SHARING

The unrivaled portability and connectivity of the SQL SERVER DBMS enables

all the systems in the organization to be linked into a singular, integrated computing resource.

PORTABILITY

SQL SERVER is fully portable to more than 80 distinct hardware and operating

systems platforms, including UNIX, MSDOS, OS/2, Macintosh and dozens of proprietary

platforms. This portability gives complete freedom to choose the database server platform that

meets the system requirements.

OPEN SYSTEMS

SQL SERVER offers a leading implementation of industry standard SQL. SQL

Servers open architecture integrates SQL SERVER and non SQL SERVER DBMS with

industrys most comprehensive collection of tools, application, and third party software products


BASED ENCRYPTION


SQL Servers Open architecture provides transparent access to data from other relational

database and even non-relational database.

DISTRIBUTED DATA SHARING

SQL Servers networking and distributed database capabilities to access data

stored on remote server with the same ease as if the information was stored on a single local

computer. A single SQL statement can access data at multiple sites. You can store data where

system requirements such as performance, security or availability dictate.

UNMATCHED PERFORMANCE

The most advanced architecture in the industry allows the SQL SERVER DBMS

to deliver unmatched performance.

SOPHISTICATED CONCURRENCY CONTROL

Real World applications demand access to critical data. With most database

Systems application becomes contention bound which performance is limited not by the

CPU power or by disk I/O, but user waiting on one another for data access. SQL Server employs

full, unrestricted row-level locking and contention free queries to minimize and in many cases

entirely eliminates contention wait times.

NO I/O BOTTLENECKS

SQL Servers fast commit groups commit and deferred write technologies

dramatically reduce disk I/O bottlenecks. While some database write whole data block to disk at

commit time, SQL Server commits transactions with at most sequential log file on disk at

commit time, On high throughput systems, one sequential writes typically group commit

multiple transactions. Data read by the transaction remains as shared memory so that other

transactions may access that data without reading it again from disk. Since fast commits write

all data necessary to the recovery to the log file, modified blocks are written back to the database

independently of the transaction commit, when written from memory to disk.


BASED ENCRYPTION


TYPES OF OBJECTS IN SQL SERVER

SQL-SERVER database consist of six types of objects. They are,

1. TABLE

2. QUERY

3. FORM

4. REPORT

5. MACRO


BASED ENCRYPTION


SYSTEM IMPLEMENTATION


BASED ENCRYPTION


INTRODUCTION:

Implementation is the stage of the project when the theoretical design is turned out into a

working system. Thus it can be considered to be the most critical stage in achieving a successful

new system and in giving the user, confidence that the new system will work and be effective.

The implementation stage involves careful planning, investigation of the existing system

and its constraints on implementation, designing of methods to achieve changeover and

evaluation of changeover methods.

4.1. MODULES

4.1.1. REGISTRATION:

In this module normal registration for the multiple users. There are multiple

owners, multiple AAs, and multiple users. The attribute hierarchy of files leaf nodes is atomic

file categories while internal nodes are compound categories. Dark boxes are the categories that

a PSDs data reader has access to. Two ABE systems are involved: for each PSD the revocable

KP-ABE scheme is adopted for each PUD, our proposed revocable MA-ABE scheme.

PUD - public domains

PSD - personal domains

AA - attribute authority

MA-ABE - multi-authority ABE

KP-ABE - key policy ABE

4.1.2. UPLOAD FILES:

In this module, users upload their files with secure key probabilities. The owners

upload ABE-encrypted PHR files to the server. Each owners PHR file encrypted both under a

certain fine grained model.


BASED ENCRYPTION


4.1.3. ABE FOR FINE GAINED DATA ACCESS CONTROL:

In this module ABE to realize fine-grained access control for outsourced data

especially, there has been an increasing interest in applying ABE to secure electronic healthcare

records (EHRs). An attribute-based infrastructure for EHR systems, where each patients EHR

files are encrypted using a broadcast variant of CP-ABE that allows direct revocation. However,

the cipher text length grows linearly with the number of UN revoked users. In a variant of ABE

that allows delegation of access rights is proposed for encrypted EHRs applied cipher text policy

ABE (CP-ABE) to manage the sharing of PHRs, and introduced the concept of

social/professional domains investigated using ABE to generate self-protecting EMRs, which

can either be stored on cloud servers or cell phones so that EMR could be accessed when the

health provider is offline

4.1.4. SETUP AND KEY DISTRIBUTION:

In this module the system first defines a common universe of data attributes shared by

every PSD, such as basic profile, medical history, allergies, and prescriptions. An

emergency attribute is also defined for break-glass access. Each PHR owners client application

generates its corresponding public/master keys. The public keys can be published via users

profile in an online healthcare social-network (HSN)

There are two ways for distributing secret keys.

First, when first using the PHR service, a PHR owner can specify the access privilege

of a data reader in her PSD, and let her application generate and distribute

corresponding key to the latter, in a way resembling invitations in GoogleDoc.

Second, a reader in PSD could obtain the secret key by sending a request (indicating

which types of files she wants to access) to the PHR owner via HSN, and the owner

will grant her a subset of requested data types. Based on that, the policy engine of the

application automatically derives an access structure, and runs keygen of KP-ABE to

generate the user secret key that embeds her access structure.


BASED ENCRYPTION


4.1.5. BREAK GLASS/EMERGENCY MODULE:

In this module when an emergency happens, the regular access policies may no

longer be applicable. To handle this situation, break-glass access is needed to access the victims

PHR. In our framework, each owners PHRs access right is also delegated to an emergency

department ED to prevent from abuse of break-glass option, the emergency staff needs to contact

the ED to verify her identity and the emergency situation, and obtain temporary read keys. After

the emergency is over, the patient can revoke the emergent access via the ED.

4.2 SAMPLE CODE:

Encryption.cs

Using System;

Using System. Data;

Using System. Configuration;

Using System.Linq;

Using System. Web;

using System.Web.Security;

using System.Web.UI;

using System.Web.UI.HtmlControls;

using System.Web.UI.WebControls;

using System.Web.UI.WebControls.WebParts;

using System.Xml.Linq;

using System.Configuration;

using System.Data.SqlClient;

using System.Text;

using System.Security.Cryptography;

///

/// Summary description for encryption

///

public class encryption

{

SqlConnection cn = new SqlConnection(ConfigurationManager.AppSettings["phr "]);

SqlCommand com,cmd1;

string logid, len2, prky,prky1,len1;

string id;

int fid;

public encryption()

{


BASED ENCRYPTION


//

// TODO: Add constructor logic here

//

}

public static string Encrypt(string toEncrypt, bool useHashing)

{

byte[] keyArray;

byte[] toEncryptArray = UTF8Encoding.UTF8.GetBytes(toEncrypt);

System.Configuration.AppSettingsReader settingsReader = new AppSettingsReader();

string key = (string)settingsReader.GetValue("search", typeof(string));

if (useHashing)

{

MD5CryptoServiceProvider hashmd5 = new MD5CryptoServiceProvider();

keyArray = hashmd5.ComputeHash(UTF8Encoding.UTF8.GetBytes(key));

hashmd5.Clear();

}

else

keyArray = UTF8Encoding.UTF8.GetBytes(key);

TripleDESCryptoServiceProvider tdes = new TripleDESCryptoServiceProvider();

tdes.Key = keyArray;

tdes.Mode = CipherMode.ECB;

tdes.Padding = PaddingMode.PKCS7;

ICryptoTransform cTransform = tdes.CreateEncryptor();

byte[] resultArray = cTransform.TransformFinalBlock(toEncryptArray, 0,

toEncryptArray.Length);

tdes.Clear();

return Convert.ToBase64String(resultArray, 0, resultArray.Length);

}

public static string Decrypt(string cipherString, bool useHashing)

{

byte[] keyArray;

byte[] toEncryptArray = Convert.FromBase64String(cipherString);

System.Configuration.AppSettingsReader settingsReader = new AppSettingsReader();

string key = (string)settingsReader.GetValue("search", typeof(String));

if (useHashing)

{

MD5CryptoServiceProvider hashmd5 = new MD5CryptoServiceProvider();

keyArray = hashmd5.ComputeHash(UTF8Encoding.UTF8.GetBytes(key));

hashmd5.Clear();

}

else

keyArray = UTF8Encoding.UTF8.GetBytes(key);


BASED ENCRYPTION


TripleDESCryptoServiceProvider tdes = new TripleDESCryptoServiceProvider();

tdes.Key = keyArray;

tdes.Mode = CipherMode.ECB;

tdes.Padding = PaddingMode.PKCS7;

ICryptoTransform cTransform = tdes.CreateDecryptor();

byte[] resultArray = cTransform.TransformFinalBlock(toEncryptArray, 0,

toEncryptArray.Length);

tdes.Clear();

return UTF8Encoding.UTF8.GetString(resultArray);

}

public int idd()

{

cn.Open();

cmd1 = new SqlCommand("select max(id) from user_reg", cn);

id = Convert.ToString(cmd1.ExecuteScalar());

if (id == "")

{

fid = 1;

}

else

{

fid = Convert.ToInt16(id);

fid = fid + 1;

}

cn.Close();

return fid;

}

public int reid()

{

cn.Open();

cmd1 = new SqlCommand("select max(reqid) from reqtobroker", cn);


if (id == "")

{

fid = 1;

}

else

{


fid = fid + 1;

}


BASED ENCRYPTION


cn.Close();

return fid;

}

public int docid()

{

cn.Open();

cmd1 = new SqlCommand("select max(id) from Docreg", cn);


if (id == "")

{

fid = 1;

}

else

{


fid = fid + 1;

}

cn.Close();

return fid;

}

public int patid()

{

cn.Open();

cmd1 = new SqlCommand("select max(id) from Patreg", cn);


if (id == "")

{

fid = 1;

}

else

{


fid = fid + 1;

}

cn.Close();

return fid;

}

public string createloginid(string n1, string n2, string n3)

{

len1 = Convert.ToString(n2.Length);

logid = Convert.ToString(n2 + n1 + len1 + n3);


BASED ENCRYPTION


return logid;

}

public string createprivacykey(string s1, string s2, string s3)

{

len2 = Convert.ToString(s2.Length);

prky = Convert.ToString(s2 + s1 + len2 + s3);

return prky;

}

public string secretkey(string r2, string r3)

{

//len3 = Convert.ToString(r2.Length);

prky1 = Convert.ToString(r2 + r3);

return prky1;

}

public void register(string id, string unam, string ps, string num, string em, string city, string

fnm, string dat)

{

//cn.Open();

//SqlCommand cmd = new SqlCommand("Insert into registration values('" + id + "','" +

unam + "','" + ps + "','" + num + "','" + em + "','" + city + "','" + fnm + "','" + dat + "')", cn);

//cmd.ExecuteNonQuery();

try

{

cn.Open();

com = new SqlCommand();

com.Connection = cn;

com.CommandType = CommandType.StoredProcedure;

com.CommandText = "register";

com.Parameters.Add("@userid", SqlDbType.Int, 0);

com.Parameters["@userid"].Value = id;

com.Parameters.Add("@username", SqlDbType.VarChar, 50);

com.Parameters["@username"].Value = unam;

com.Parameters.Add("@password", SqlDbType.VarChar, 50);

com.Parameters["@password"].Value = ps;

com.Parameters.Add("@contactno", SqlDbType.VarChar, 50);

com.Parameters["@contactno"].Value = num;

com.Parameters.Add("@email", SqlDbType.VarChar, 50);

com.Parameters["@email"].Value = em;

com.Parameters.Add("@city", SqlDbType.VarChar, 50);

com.Parameters["@city"].Value = city;

com.Parameters.Add("@filename", SqlDbType.VarChar, 50);

com.Parameters["@filename"].Value = fnm;

com.Parameters.Add("@date", SqlDbType.DateTime);


BASED ENCRYPTION


com.Parameters["@date"].Value = dat;

com.ExecuteNonQuery();

cn.Close();

}

catch (Exception e)

{

MsgBox.Show(e.Message);

}

//cn.Close();

}

public DataSet checkuser(string usr,string psw)

{

cn.Open();

SqlDataAdapter adt = new SqlDataAdapter("select username,password from registration

where username='" + usr + "' and password='" + psw + "'", cn);

DataSet da = new DataSet();

adt.Fill(da);

cn.Close();

return da;

}

}


BASED ENCRYPTION


4.3 OUTPUT SCREENS:

Figure: 1.HomeScreen Page

Figure: 2.User Registration Page


BASED ENCRYPTION


Figure: 3.User Registration Page

Figure: 4.Keys Generation Page


BASED ENCRYPTION


Figure: 5.Phr Registration Page

Figure: 6.Phr Login Page


BASED ENCRYPTION


Figure: 7.Phr after Login

Figure: 8.file uploading Page


BASED ENCRYPTION


Figure: 9.Uploading Files Page

Figure: 10.File uploaded successfully


BASED ENCRYPTION


Figure: 11.User Login Page

Figure: 12.Search Page


BASED ENCRYPTION


Figure: 13.Key Enter Page

Figure: 14.Enter Key Page


BASED ENCRYPTION


Figure: 15.Wrong Key Page

Figure: 16.Emergency Services Page


BASED ENCRYPTION


Figure: 17.Request for emergency services

Figure: 18.Key sending to mail


BASED ENCRYPTION


Figure: 19.Public Login Page

Figure: 20.Public after login Page


BASED ENCRYPTION


Figure: 21.Emergency Clients Page

Figure: 22.Sending Secret key Page


BASED ENCRYPTION


Figure: 23.Message Sending Page

Figure: 24.Gmail message


BASED ENCRYPTION


Figure: 25.Files Searching Page

Figure: 26.Enter Secret key Page


BASED ENCRYPTION


Figure: 27.File Download Page

Figure: 28.User Blocking Page


BASED ENCRYPTION


SYSTEM TESTING


BASED ENCRYPTION


INTRODUCTION

The software testing process commences once the program is created and the

documentation and related data structures are designed. Software testing is essential for

correcting errors. Otherwise the program or the project is not said to be complete.

The purpose of testing is to discover errors. Testing is the process of trying to discover

every conceivable fault or weakness in a work product. It provides a way to check the

functionality of components, sub assemblies, assemblies and/or a finished product It is the

process of exercising software with the intent of ensuring that the

Software system meets its requirements and user expectations and does not fail in an

unacceptable manner. There are various types of test. Each test type addresses a specific testing

requirement

5.1. TYPES OF TESTING

The following are the types of testing

a. Unit testing

b. Integration testing

c. Functional testing

d. System testing

e. White Box testing

f. Black Box testing

g. Acceptance testing

5.1.1. UNIT TESTING:

Unit testing involves the design of test cases that validate that the internal program logic

is functioning properly, and that program inputs produce valid outputs. All decision branches and

internal code flow should be validated. It is the testing of individual software units of the

application .it is done after the completion of an individual unit before integration. This is a

structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform


BASED ENCRYPTION


basic tests at component level and test a specific business process, application, and/or system

configuration. Unit tests ensure that each unique path of a business process performs accurately

to the documented specifications and contains clearly defined inputs and expected results.

Unit testing is usually conducted as part of a combined code and unit test phase of the

software lifecycle, although it is not uncommon for coding and unit testing to be conducted as

two distinct phases.

5.1.1. TEST STRATEGY AND APPROACH:

Field testing will be performed manually and functional tests will be written in detail.

5.1.1. TEST OBJECTIVES:

a. All field entries must work properly.

b. Pages must be activated from the identified link.

c. The entry screen, messages and responses must not be delayed.

5.1.1. FEATURES TO BE USED:

a. Verify that the entries are of the correct format.

b. No duplicate entries should be allowed.

All links should take the user to the correct page.

5.1.2. INTEGRATION TESTING:

Integration tests are designed to test integrated software components to determine if they

actually run as one program. Testing is event driven and is more concerned with the basic

outcome of screens or fields. Integration tests demonstrate that although the components were

individually satisfaction, as shown by successfully unit testing, the combination of components is

correct and consistent. Integration testing is specifically aimed at exposing the problems that

arise from the combination of components.


BASED ENCRYPTION


Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by interface

defects.

The task of the integration test is to check that components or software applications, e.g.

components in a software system or one step up software applications at the company level

interact without error.

5.1.3. FUNCTIONAL TESTING:

Functional tests provide systematic demonstrations that functions tested are available as

specified by the business and technical requirements, system documentation, and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures : interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to identify Business

process flows; data fields, predefined processes, and successive processes must be considered for

testing. Before functional testing is complete, additional tests are identified and the effective

value of current tests is determined.


BASED ENCRYPTION


5.1.4. SYSTEM TESTING:

System testing ensures that the entire integrated software system meets requirements. It

tests a configuration to ensure known and predictable results. An example of system testing is the

configuration oriented system integration test.

5.1.5. WHITEBOX TESTING:

White Box Testing is a testing in which in which the software tester has knowledge of the

inner workings, structure and language of the software, or at least its purpose. It is purpose. It is

used to test areas that cannot be reached from a black box level.

5.1.6. BLACKBOX TESTING:

Black Box Testing is testing the software without any knowledge of the inner workings,

structure or language of the module being tested. Black box tests, as most other kinds of tests,

must be written from a definitive source document, such as specification or requirements

document, such as specification or requirements document. It is a testing in which the software

under test is treated, as a black box .you cannot see into it. The test provides inputs and

responds to outputs without considering how the software works.

5.1.7. ACCEPTENCE TESTING:

User Acceptance Testing is a critical phase of any project and requires significant

participation by the end user. It also ensures that the system meets the functional requirements.

All the test cases mentioned below passed successfully. No defects encountered


BASED ENCRYPTION


5.2. TEST CASES

Test

no

Module

name

Test name Date Tester Expected output Result

1 Creating

id.cs

Checking

using studio

tool

18/4/2014 Should execute

successfully

Pass

2 Encryption Checking

using studio

tool

20/4/2014 Hema Should encrypt

the given data

Pass

3 Mail.cs Checking

whether mail

is working or

not

25/4/2014 hema Mail should be

send to particular

recipient

Pass

4 Show.cs Placing all

images in

one place

4/5/2014 hema Slide show of

images

Pass

5 Sql Server

setup

Used for

creating

database

14/5/2014 hema Database created

successfully

Pass

6 Connection Connecting

project with

database

20/5/2014 hema Connected

successfully

Pass

7 registration Phr owner

and user

registration

25/5/2014 hema Should display

"details are

saved"

Pass

8 Uploading

files

Should

upload files

28/5/2014 Hema Uploading

successfully

Pass

9 Mail

sending

Sending mail

to requested

user

2/6/2014 hema Mail send Pass


BASED ENCRYPTION


CONCLUSION


BASED ENCRYPTION


In this paper, we have proposed a novel framework of secure sharing of personal health

records in cloud computing. Considering partially trustworthy cloud servers, we argue that

to fully realize the patient-centric concept, patients shall have complete control of their

own privacy through encrypting their PHR files to allow fine-grained access. The

framework addresses the unique challenges brought by multiple PHR owners and users, in

that we greatly reduce the complexity of key management while enhance the privacy

guarantees compared with previous works. We utilize ABE to encrypt the PHR data, so

that patients can allow access not only by personal users, but also various users from

public domains with different professional roles, qualifications and affiliations.

Furthermore, we enhance an existing MA-ABE scheme to handle efficient and on-demand

user revocation, and prove its security. Through implementation and simulation, we show

that our solution is both scalable and efficient.


BASED ENCRYPTION


BIBLIOGRAPHY


BASED ENCRYPTION


1. User Interfaces in C#: Windows Forms and Custom Controls by Matthew MacDonald.

2. Applied Microsoft .NET Framework Programming (Pro-Developer) by Jeffrey

Richter.

3. Practical .Net2 and C#2: Harness the Platform, the Language, and the Framework by

Patrick Smacchia.

4. Data Communications and Networking, by Behrouz A Forouzan.

5. Computer Networking: A Top-Down Approach, by James F. Kurose.

6. Operating System Concepts, by Abraham Silberschatz.

7. M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D.

A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, Above the clouds: A berkeley

view of cloud computing, University of California, Berkeley, Tech. Rep. USB-

EECS-2009-28, Feb 2009.

8. The apache cassandra project, http://cassandra.apache.org/.

9. L. Lamport, The part-time parliament, ACM Transactions

a. on Computer Systems, vol. 16, pp. 133169, 1998.

10. N. Bonvin, T. G. Papaioannou, and K. Aberer, Cost-efficient

a. and differentiated data availability guarantees in data clouds,in Proc. of the

ICDE, Long Beach, CA, USA, 2010.

11203203 project document

Documents

department of master

degree of master

project work

award of degree

cloud computing

partial fulfillment

project report

hemalatha regd