Share PDF

Search documents:
  Report this document  
    Download as PDF   
      Share on Facebook

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 1

1. INTRODUCTION

A personal health record (PHR) makes it easy to gather and manage medical information in one accessible and secure location. Carrying paper records is a big drawback, rarely the patients have with them when they need. Personal health record systems overcome this problem by making the personal health record accessible anytime via a Web-enabled device, such as computer. Literally, having a personal health record can be a lifesaver. In an emergency patient can quickly give emergency personal vital information about disease, medications and drug allergies. Now a day, personal health record (PHR) has become a patient-centric model of health information exchange. A PHR service allows patients to create, manage and control their personal health data from one place through the web, which has made the storing, retrieving and sharing of the medical information more efficient. Especially, each patient will have full control of their medical records and can share their health data with different users from different domains which include healthcare providers, family members and friends. Due to high cost of building and maintaining separate data centers, many PHR services are outsourced and provided by third party service providers for example, Microsoft Health Vault (UK). The Health Vault Program of Microsoft will allow users including individuals, health centers, hospitals etc. to gain access to the information on health related issues. The user interface will be simple, that would allow anyone to operate the program easily. But on the other hand, many people do not wish to share their private health records and other information universally through the Health Vault. As the sensitive Personal Health Information (PHI) is highly valuable, the third-party storage servers are the targets of various malicious behaviors which may result in exposure of the PHI. Researches on PHR’s using cloud computing is still underway.

The main concern is about whether the patients could actually control the sharing of their sensitive PHR and other information, especially when they are stored on a third-party server which people may not fully trust. To ensure patient-centric privacy control over their own PHRs, encryption of data is necessary prior storage. Basically, the PHR owners themselves should decide how to encrypt their files and to allow which set of users to obtain

Department Of ECE, AMCEC

1

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

access to each file. The PHR and other files are available to only those users who are given the corresponding decryption key and are confidential to other users. Furthermore, the patient will always have the right to not only to grant, but also to revoke access rights when it is necessary.

This scheme endeavors 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. To protect the personal health data stored on a semi-trusted server, Attribute-Based Encryption (ABE) method is used. Using ABE, files are encrypted under a set of attributes. Access policies are expressed based on the attributes of users or data, which enables patients to selectively share their PHR among a set of users. The complexities per encryption, key generation and decryption are only linear with the number of attributes involved. However, to integrate ABE into a large-scale PHR system, important issues such as key management scalability, dynamic policy updates, and efficient on-demand revocation are non-trivial to solve. To this end, the following are the main contributions:

An ABE method is proposed for patient-centric secure sharing of PHRs in cloud computing environments, under the multi-owner settings. To overcome the key management challenges, the users in the system are divided into two categories, namely public domain and personal domain. In particular, large number of professional users is managed by attribute authorities (AA) in the public domain, while each owner only needs to manage the keys of a small number of users in their personal domain.

In the public domain, multi-authority ABE (MA-ABE) is used to improve the security and avoid key management problem. Each attribute authority (AA) in it governs a disjoint subset of user role attributes. Encryption mechanism allows PHR owners to specify role-based access policies during file encryption. In the personal domain, owners directly assign access rights to personal users and encrypt a PHR file under its data attributes.

Department Of ECE, AMCEC

2

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

The main goal of our framework is to provide secure patient-centric PHR access and efficient key management at the same time. The key idea is to divide the system into multiple security domains (namely, public domains (PUDs) and personal domains (PSDs)) according to the different users’ data access requirements. The PUDs consist of users based on their professional roles, such as doctors, nurses and medical researchers. In practice, a PUD can be hospital, government or insurance sector. In case of PSD, its users are personally associated with a data owner (such as family members or close friends), and they access the PHRs based on access rights assigned by the owner.

The use of cloud computing has increased rapidly in many organizations. Cloud computing provides many benefits in terms of low cost and accessibility of data. Cloud is a computing model providing web-based software and computing resources on demand. By deploying technology as a service, it gives users access only to the resources they need for a particular task. This prevents from paying for idle computing resources. Cloud computing can also go beyond cost savings by allowing users to access the latest software and infrastructure offerings to advance business innovation. Some of the advantages of cloud computing are

Cloud is simply a metaphor for the internet.

Users do not have or need knowledge, control and ownership in the computer infrastructure.

Users simply rent or access the software, paying only for what they use.

Department Of ECE, AMCEC

3

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 2

2.LITERATURE SURVEY

2.1Literature Survey

A personal health record (PHR) is simply a collection of information about a person’s health. It is a tool for the excellent management of the health.

J. Benaloh, [7], “Patient Controlled Encryption: Ensuring Privacy of Electronic Medical Records,” has proposed a scheme in which a file can be uploaded without key distribution and it is highly efficient. But it is a single data owner scenario and thus it is not easy to add categories. C. Dong, [9] “Shared and Searchable Encrypted Data for Untrusted Servers,” has explored that the data encryption scheme does not require a trusted data server. The server can perform encrypted searches and updates on encrypted data without knowing the plaintext or the decryption keys. But in this scheme the server knows the access pattern of the users which allows it to infer some information about the queries.

To realize fine grained access control, the traditional public key encryption based schemes [7] and [9] either incur high key management overhead, or require encrypting multiple copies of a file using different users’ keys.

To improve upon the scalability of the above solutions, one-to-many encryption methods such as attribute based encryption (ABE) can be used. In Goyal et. al’s seminar paper, [10] “Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data”, data is encrypted under a set of attributes so that multiple users who possess proper key can decrypt.

Yu et al, [8] “Achieving Secure, Scalable and Fine-Grained Data Access Control in Cloud Computing,” and [14] “Attribute Based Data Sharing With Attribute Revocation,” applied key-policy ABE to secure outsourced data in the cloud. In this scheme, a single data owner can encrypt data and share with multiple authorized users, by distributing keys to them that contain attribute-based access privileges. Since the key update operations can be

Department Of ECE, AMCEC

4

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

aggregated over time, their scheme achieves low amortized overhead. The main disadvantage in the scheme is that the data owner is also a Trusted Authority (TA) at the same time. If this scheme is applied to a PHR system with multiple data owners and users, it would be inefficient because then each user would receive many keys from multiple owners, even if the keys contain the same set of attributes.

A. Boldyreva, V. Goyal, and V. Kumar, [12] “Identity-Based Encryption With Efficient Revocation,” and X. Liang, R, [22] “Ciphertext Policy Attribute Based Encryption With Efficient Revocation,” resolved a well-known challenging problem to revoke users/ attributes efficiently and on-demand in ABE. Traditionally this is often done by the authority broadcasting periodic key updates to unrevoked users frequently but does not achieve complete backward/ forward security and is less efficient.

Recently J. Hur and D. K. Noh in [21] “Attribute-Based Revocation in Data Outsourcing Systems,” and S. Jahid, P. Mittal, and N. Borisov in [22], “Easier: Encryption- Based Access Control in Social Networks With Efficient Revocation,” proposed two CP- ABE schemes with immediate attribute revocation capability, instead of periodical revocation. However, they were not designed for Multi Authority Attribute Based Encryption (MAABE).

S. Ruj, A. Nayak, and I. Stojmenovic in [23], “DACC: Distributed Access Control in Clouds,” proposed an alternative solution for the same problem. The main advantage of the solution is each user can obtain secret keys from any subset of the Trusted Authorities (TAs) in the system. On the downside, the communication overhead of key revocation is still high, as it requires a data owner to transmit an updated ciphertext component to every non-revoked user.

M. Li, S. Yu, N. Cao and W. Lou in [3], “Authorized Private Keyword Search Over Encrypted Personal Health Records in Cloud Computing,” address the problem of authorized private keyword searches over encrypted data in cloud computing, where multiple data owners encrypt their records along with a keyword index to allow searches by multiple users. The main advantage of schemes in this category is they obviate the overhead for users to acquire search capabilities. However, search authorization is intrinsically difficult to

Department Of ECE, AMCEC

5

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

achieve since it is contradictory with user-generated capabilities.

Due to high cost of building and maintaining specialized data centers, many PHR services are outsourced to or provided by third party service providers for example, Microsoft Health Vault. The Health Vault Program of Microsoft will allow people including individuals, health centers, hospitals etc., to gain access to the huge wealth of information on health related issues. The user interface will be simple, that would allow anyone to operate the program easily. But on the other hand, there is still less guarantee to protect one’s privacy statement. Many individuals do not wish to disclose their private health records and other information to be displayed universally through the Health Vault.

Although there exist healthcare regulations such as Health Insurance Portability and Accountability Act (HIPAA) in United States which is recently amended to incorporate business associates. Cloud providers are usually not covered entities. On the other hand, due to the high value of the sensitive personal health information (PHI), the third-party storage servers are often the targets of various malicious behaviors which may lead to exposure of the PHI.

2.2Disadvantages in Existing System

There is no policy management for file access, so that unauthorized users can also able to access the sensitive data.

There is no encryption and decryption concept so the files stored in the semi-trusted cloud can able to leak the information to others.

There is no structured way to access the file for personal & professional purpose.

2.3Objective

The main aim of the proposed system is to provide secure patient-centric PHR access and efficient key management at the same time. The key idea is to divide the system into multiple security domains (namely, public domains (PUDs) and personal domains (PSDs)) according to the different users’ data access requirements.

Department Of ECE, AMCEC

6

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 3

3.SECURE SHARING OF PHR

3.1Sharing of PHR

The main goal of PHR system is to provide patient-centric PHR access with high security and efficient key management. This is achieved by dividing the system into multiple security domains (namely, public domains (PUDs) and personal domains (PSDs)) according to different users’ data access requirements. The PUDs consist of users based on their professional roles, such as doctors, nurses and medical researchers. In practice, a PUD can be hospital, government or insurance sector. In case of PSD, its users are personally associated with a data owner (such as family members or close friends) and they access the PHRs based on access rights assigned by the owner. In both types of security domains, we utilize ABE to realize cryptographically enforced, patient-centric PHR access. Especially, in a PUD multi- authority ABE is used, in which there are multiple “attribute authorities” (AAs), each governing a disjoint subset of attributes. Role attributes are defined for PUDs that represent the professional role. The PUD users obtain their attribute-based keys from the respective AAs, without the need to interact directly with the owners. To control access from PUD users, owners can specify role-based access policies for their PHR files. Since the PUDs consist of a large number of users, there is a great reduction in the key management overhead for both the owners and users.

The data owners (e.g., patients) are the trusted authorities of their own PSD and provide the secret keys and access rights to the users in their PSD. Since the users are personally known by the PHR owner, to realize patient-centric access, the owner is at the best position to grant user access rights. For PSD, data attributes are defined which refer to the intrinsic properties of the PHR data, such as the category of a PHR file. For the purpose of PSD access, each PHR file is labeled with its data attributes, while the key size is only linear with the number of file categories a user can access. Since the number of users in a PSD is often small, it reduces the burden for the owner. When encrypting the data for PSD, all that the

Department Of ECE, AMCEC

7

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

owner needs to know is the intrinsic data properties. The multi-domain approach provides best models for different user types and access requirements in a PHR system. The use of ABE makes the encrypted PHRs self-protective, i.e., they can be accessed by only authorized users even when storing on a semi-trusted server, and when the owner is not online.

3.2 Module Description

The goal of patient-centric privacy is often in conflict with scalability in a PHR system. The authorized users may either need to access the PHR for personal use or professional purposes. Examples of the former are family member and friends, while the latter can be medical doctors, pharmacists, and researchers, etc. We refer to the two categories of users as personal and professional users, respectively.

Fig 3.1: PHR System Scenario

Department Of ECE, AMCEC

8

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

For the PUDs, the system defines role attributes, and a reader in a PUD obtains secret key from AAs. This is reflected by (1) in Fig.3.1. MA-ABE is used to encrypt the data.

PHR Encryption and Access: The owners upload ABE-encrypted PHR files to the server ((3)). Each owner’s PHR file is encrypted both under a certain fine-grained and role-based access policy for users from the PUD to access, and under a selected set of data attributes that allows access from users in the PSD. Only authorized users can decrypt the PHR files, excluding the server. The data readers download PHR files from the server, and they can decrypt the files only if they have suitable attribute-based keys ((5)).

User Revocation: Here we consider revocation of a data reader or attributes/access privileges. There are several possible cases: 1) revocation of one or more role attributes of a public domain user; 2) Revocation of a personal domain user’s access privileges; 3) revocation of a personal domain user. These can be initiated through the PHR owner’s client application.

Policy Updates: The PHR owners can update their sharing policy for the existing PHR documents by updating the attributes (or access policy). The supported operations include add/delete/change, which can be done by the server on behalf of the user.

Break-glass: 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 victim’s PHR. In this system, each owner’s PHR’s access right is also delegated to an emergency department (ED, (6)). In case of emergency, the emergency staff needs to contact the ED to verify the identity and the emergency situation of the patient, and obtain temporary read keys ((7)). After the emergency is over, the patient can revoke the emergent access via the ED.

This system considers the server to be semi-trusted, i.e., honest but curious. That is the server will try to find out the secret information in the stored PHR files as much as possible, but they will honestly follow the protocol in general. On the other hand, some users will also try to access the files beyond their rights. For example, a pharmacy may try to obtain the prescriptions of patients for marketing and boosting its profits. To do so, they may collude with other users, or even with the server.

In cloud Environment PHR Owners need upload data on cloud in such a manner that confidentiality of data and access rights of the data in highest point. There are various types

Department Of ECE, AMCEC

9

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

of user allowed to access the data based on policy management as given by table (3.1). This system has three types of users Admin, PHR Owner & Data Access Member. Following are the type of files which the PHR owner wishes to share with various types of users. Below which gives the details about the attributes used.

3.2.1 Sample Files used in this system

Personal File

Medical History

Current Medical Examination

Insurance Details

Sensitive Details

3.2.2 Attribute Types in this System

Friends

Hospitals

Insurance

Emergency

Table 3.1: Access Policy Table

 

Files / Attribute

Friends

Hospitals

Insurance

Emergency

 

 

 

 

 

 

 

 

 

Personal

Yes

No

No

Yes

 

 

 

 

 

 

 

 

 

Medical_History

Yes

Yes

No

Yes

 

 

 

 

 

 

 

 

 

Current_Exams

No

Yes

Yes

Yes

 

 

 

 

 

 

 

 

 

Insurance

No

Yes

Yes

Yes

 

 

 

 

 

 

 

 

 

Sensitive

No

No

No

Yes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Department Of ECE, AMCEC

10

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

3.3 Block Diagram of PHR System

Fig 3.2: Block diagram of PHR system

The block diagram of the proposed PHR system is shown n fig (3.2). In this diagram, PHR system is the system in which encryption and decryption of the health records and other files takes place. PHR users or owners upload their files which are encrypted in PHR system and stored in the cloud storage. The PHR user will send the attribute based key to the data access users such as hospitals, friends and insurance company using which they will be authorized to access the files according to policy management. Hence the decrypted file will be downloaded into the data access user’s system using attribute based key. Different users will be given different keys. Admin will be responsible for managing PHR user details, transaction details, policy management etc.

Department Of ECE, AMCEC

11

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

He can change the access policy any time. PHR user details contain PHR ID, name, city, contact number etc. Transaction details contain the user name, transaction type (uploading or downloading of a file), file name and type (text or image), date and time of transaction.

3.3.1 Sample Input and Sample Output

When the PHR Owner is uploading a file from his local machine to web server, it has to be redirected to Attribute Based Encryption Service which is running in cloud server 1 and Cloud server 1 will encrypt the file and the encrypted file has to send to cloud server 2 using web service concept which will store in cloud server 2.

When the Data Access Member is downloading a file from the Cloud server through policy management control, the corresponding file has to fetch from cloud server 2 and it will send to Attribute based decryption service which is running in cloud server 1. Once the file is decrypted it will be downloaded to the user machine.

3.4Sessions & Modules

3.4.1Admin Session

1.Login Module

Using login module, admin will login to his account and he will maintain all the following sessions.

2.Attribute Values

Different users have been given different attribute values. Attributes here used are friend, doctor, insurance and emergency.

3.Policy Management

There is policy management for file access, data access member can able to access the files which they have rights set by the policy.

Department Of ECE, AMCEC

12

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.PHR Owners

There are number of PHR Owners who wish to maintain their health records and other files in cloud. Admin has the right to add or delete PHR owners.

5.Key Generation

Different keys will be generated for different data access members and by using which the users can be able to access the files according to policy management.

6.Transaction Details

All the details such as user name, transaction type, file name and type, date and time of transaction are updated.

7.Change Password

Admin is able to change the password at any time.

3.4.2 PHR Owners Session

1.Login Module

Using login module, PHR owner will login to his account and maintains the following sessions.

2.File Upload

Following are the steps to upload a file

File upload from local system to Server

PHR owner will upload the files from local system to the web server.

Encrypting file content

The files in the server will be encrypted using DES algorithm.

Data Storage in Cloud

Encrypted files will be stored in the cloud server.

3.Attribute based Key Distribution through e-mail

For distribution of keys to different users, following are the steps involved.

Fetching the key from database

The owner will copy the key from the data base

Identifying the attribute value

Different attributes are identified.

Converting the key to attribute based key

Department Of ECE, AMCEC

13

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

The code will generate different keys for different attribute users.

Sending the attribute based key through email

Attribute based keys are sent to various users through email.

4.Transaction Details

The details such as user name, transaction type, file name and type, date and time of transaction are updated.

5.Change Password

PHR owner can change his login account password if necessary.

3.4.3 Data Access Member Session

1.File Download

Following are the steps for downloading the file

PHR Owner ID Input

First the data access member should enter the PHR owner ID.

Attribute Based Key Input

Input the decryption key which the data access member receives from the owner through the mail

Verifying the PHR ID and Input Key

Verification of the PHR ID and Input Key is done.

Listing the file based on Access Policy

According to the policy management, files are listed to which the data access member has privilege to access.

Encrypted File Download from cloud to web server

From cloud where the encrypted file is stored will get downloaded into the web server.

Decrypting the file in web server

The encrypted file will get decrypted in the web server.

File download to local system

The decrypted file i.e. the original file will be downloaded into the local machine of the data access member.

Department Of ECE, AMCEC

14

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

3.5 Use Case Diagram for Admin session

Fig 3.3: Admin session

Fig (3.3) shows the admin session. Admin is responsible for managing PHR user details, transaction details, policy management, attribute values etc. He can change the access policy any time. He can add, delete or edit the details of PHR users. PHR user details contain PHR ID, name, city, contact etc. Transaction details contain the user name, transaction type (upload or download), file name, file type (text or image), date and time of transaction. He can change the password of his account when it is necessary.

Department Of ECE, AMCEC

15

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

3.6 Use Case Diagram for PHR Owner session

Fig 3.4: PHR Owner session

Fig (3.4) gives PHR owner session. After encryption the PHR owner will upload the files into the clouds server and sends different attribute based keys to different users through mail. Transaction details contain the user name, transaction type (upload or download), file name, file type (text or image), date and time. The owners can change the password of their accounts whenever required.

Department Of ECE, AMCEC

16

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

3.7 Use Case Diagram for data access user

Fig 3.5: Data access user session

Fig (3.5) shows the data access user session. Data access member or user can download the files using the attribute based key sent by the PHR owner. When the user inputs the key along with the PHR owner ID, only those files which the user has right to access get decrypted and downloaded into the local machine.

Department Of ECE, AMCEC

17

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 3.6: Sequence diagram

Fig (3.6) indicates the sequence diagram for the data access user session. A file is accessed by using the following steps.

1.User or data access member input the PHR ID of the owner and attribute-based key.

2.Verification of the key for its validity.

3.If the key is invalid, it gives fail message.

4.If the key is valid, a list of encrypted files according to the access policy will be decrypted.

5.Decrypted files or plain files will be downloaded into the user’s local system.

Department Of ECE, AMCEC

18

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

3.8 Deal with Emergency Access

Sometimes medical staffs need to have temporary access to certain parts of the PHR data when an emergency occurs to a patient, who may be unconscious and unable to modify the access policies beforehand. The medical staffs require a temporary authorization (e.g., emergency key) to decrypt those parts of data. This can be easily achieved in this system by allowing each patient delegate their emergency key to an emergency department (ED). At the beginning, each owner defines an “emergency” attribute and includes it into the Personal domain part of the ciphertext of each PHR document to allow emergency access. The patient then generates an emergency key and delegates it to the ED who stores it in a database of patient directory. During emergency, the medical staff requests and obtains the corresponding patient’s emergency key from the ED and then access the decrypted PHR documents using that key. After recovering from the emergency, the patient can revoke the emergency access by changing the access policy.

Department Of ECE, AMCEC

19

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 4

4.SYSTEM REQUIREMENTS

4.1Hardware Requirement

Following are the hardware required for the proposed system

Processor : Pentium IV with 2.6 GHz

Hard Disk : 120 GB

 

RAM

:

2 GB

 

Monitor

:

Samtron 15 inches

 

Mouse

:

Samsung Scroll Mouse

CD-ROM : Sony 40x Max

Keyboard : 107 keys

4.2Software Requirements

Following are the software required for the proposed system

J2EE – Servlet, JSP

JDK 1.6

Database Server My-SQL Server

TomCat 6.0

Operating System: Windows XP Edition

A detail description of the software used in the system is given below.

4.3 JavaScript

JavaScript is a script-based programming language that was developed by Netscape Communication Corporation. JavaScript was originally called Live Script and renamed as JavaScript to indicate its relationship with Java. JavaScript supports the development of both client and server components of Web-based applications. On the client side, it can be used to

Department Of ECE, AMCEC

20

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

write programs that are executed by a Web browser within the context of a Web page. On the server side, it can be used to write Web server programs that can process information submitted by a Web browser and then update the browser’s display accordingly.

Even though JavaScript supports both client and server Web programming, we prefer JavaScript at Client side programming since most of the browsers supports it. JavaScript is almost as easy to learn as HTML, and JavaScript statements can be included in HTML documents by enclosing the statements between a pair of scripting tags

<Script> ………. </Script>

<Script Language = “JavaScript”>

JavaScript statements

</Script>

4.3.1 Few things we can do with JavaScript

Validate the contents of a form and make calculations.

Add scrolling or changing messages to the Browser’s status line.

Animate images or rotate images that change when we move the mouse over them.

Detect the browser in use and display different content for different browsers.

Detect installed plug-ins and notify the user if a plug-in is required.

We can do much more with JavaScript, including creating entire application.

4.3.2 Difference between JavaScript and Java

JavaScript and Java are entirely different languages. A few of the most glaring differences are

Java applets are generally displayed in a box within the web document; JavaScript can affect any part of the Web document itself.

While JavaScript is best suited to simple applications and adding interactive features to Web pages; Java can be used for incredibly complex applications.

Department Of ECE, AMCEC

21

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.3.3 Advantages of Javascript

There are many other differences but the important thing to remember is that JavaScript and Java are separate languages. They are both useful for different things; in fact they can be used together to combine their advantages.

JavaScript can be used for Sever-side and Client-side scripting.

It is more flexible than VBScript.

JavaScript is the default scripting languages at Client-side since all the browsers supports it.

4.4Java Technology

The primary motivation of java language was the need for a platform-independent (i.e., architecture neutral) language that could be used to create software to be embedded in various consumer electronic devices.

Java is a programmer’s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives the programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

4.4.1 Importance of Java to The Internet

Java has had a profound effect on the Internet. This is because, Java expands the Universe of objects that can move about freely in Cyberspace. In a network, two categories of objects are transmitted between the Server and the Personal computer. They are: Passive information and Dynamic active programs. The Dynamic, Self-executing programs cause serious problems in the areas of Security and probability. But, Java addresses those concerns and by doing so, has opened the door to an exciting new form of program called the Applet.

Department Of ECE, AMCEC

22

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.4.2 Java Can Be Used To Create Two Types of Programs

Applications and Applets: An application is a program that runs on our Computer under the operating system of that computer. It is more or less like one creating using C or C++. Java’s ability to create Applets makes it important. An Applet is an application designed to be transmitted over the Internet and executed by a Java –compatible web browser. An applet is actually a tiny Java program, dynamically downloaded across the network, just like an image. But the difference is, it is an intelligent program, not just a media file. It can react to the user input and dynamically change.

4.4.3 Features of Java Security

Every time while download a normal program lead to risking a viral infection. Prior to java, most users did not download executable programs frequently, and those who did scan them for viruses prior to execution. Most users still worried about the possibility of infecting their systems with a virus. In addition, another type of malicious program exists that must be guarded against. This type of program can gather private information, such as credit card numbers, bank account balances, and passwords. Java answers both these concerns by providing a “firewall” between a network application and computer. When people use a java- compatible web browser, they can safely download java applets without fear of virus infection or malicious intent.

4.4.4 Portability

For programs to be dynamically downloaded to all the various types of platforms connected to the internet, some means of generating portable executable code is needed. The same mechanism that helps ensure security also helps create portability. Indeed, java’s solution to these two problems is both elegant and efficient.

Department Of ECE, AMCEC

23

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.4.5 The Byte Code

The key that allows the Java to solve the security and portability problems is that the output of Java compiler is Byte code. Byte code is a highly optimized set of instructions designed to be executed by the Java run-time system, which is called the Java Virtual Machine (JVM). That is, in its standard form, the JVM is an interpreter for byte code. Translating a Java program into byte code helps makes it much easier to run a program in a wide variety of environments. The reason is, once the run-time package exists for a given system, any Java program can run on it.

4.5 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 onto a machine, it is verified. As part of the loading process, a class loader is invoked and does byte code verification makes sure that the code that’s has been generated by the compiler will not corrupt the machine that it’s 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.

4.5.1 Overall Description

Java Source

Java byte code

Java VM

 

 

Java

.Class

Fig 4.1 Development process of JAVA Program

Java programming uses 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

Department Of ECE, AMCEC

24

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

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.

4.5.2 Java Architecture

Java architecture provides a portable, robust, high performing environment for development. Java provides portability by compiling the byte codes for the Java Virtual Machine, which is then interpreted on each platform by the run-time environment. Java is a dynamic system, able to load code when needed from a machine in the same room or across the planet.

4.5.3 Compilation of code

When you compile the code, the Java compiler creates machine code (called byte code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM is supposed to execute the byte code. The JVM is created for overcoming the issue of portability. The code is written and compiled for one machine and interpreted on all machines. This machine is called Java Virtual Machine.

4.6 Servlets

Servlets provide a Java(TM)-based solution used to address the problems currently associated with doing server-side programming, including inextensible scripting solutions, platform-specific APIs, and incomplete interfaces.

Servlets are modules that extend request/response-oriented servers, such as Java- enabled web servers. For example, a servlet might be responsible for taking data in an HTML order-entry form and applying the business logic used to update a company’s order database.

Department Of ECE, AMCEC

25

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 4.2: Servlet function

Servlets are to servers what applets are to browsers. Unlike applets, h owever, Servlets have no graphical user interface. Servlets can be embedded in many different servers because the servlet API, which you use to write Servlets, assumes nothing ab out the server's environment or protocol. Servlets have become most widely used withi n HTTP servers; many web servers support the Servlet API.

4.6.1 Other Uses of Servlets

Allowing collaboration between people. A Servlet can handle multiple requests concurrently, and ca n synchronize requests. This allows Servlets to support systems such as on-line conferencing.

Forwarding requests. Servlets can forward requests to other servers and Servlets. Thus Servlets can be used to balance load among several servers that mirror the same content, and to partition a single logical service over several servers, according to task type or organizational boundaries.

Department Of ECE, AMCEC

26

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.6.2 The Servlet Interface

The central abstraction in the Servlet API is the Servlet interfa ce. All Servlets implement this interface, either directly or, more commonly, by extend ing a class that implements it such as HttpServlet.

Fig 4.3 Servlet interface

The Servlet interface declares, but does not implement, methods that manage the servlet and its comm unications with clients. Servlet writers provide some or all of these methods when developing a servlet.

4.6.3 Client Interaction

When a servlet accepts a call from a client, it receives two objects:

A ServletRequest, w hich encapsulates the communication from the client to the server.

A ServletResponse, which encapsulates the communication from the servlet back to the client.

ServletRequest and ServletResponse are interfaces defined by the javax.servlet package.

Department Of ECE, AMCEC

27

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.6.3.1 The Servlet Request Interface

The ServletRequest interface allows the servlet access to information such as the names of the parameters passed in by the client, the protocol (scheme) being used by the client and the names of the remote host that made the request and the server that receive the input stream, ServletInputStream. Servlets use the input stream to get data from clients that use application protocols such as the HTTP POST and PUT methods.

Interfaces that extend ServletRequest interface allow the servlet to retrieve more protocol-specific data. For example, the HttpServletRequest interface contains methods for accessing HTTP-specific header information.

4.6.3.2 The Servlet Response Interface

The ServletResponse interface gives the servlet methods for replying to the client.

Allows the servlet to set the content length and MIME type of the reply.

Provides an output stream, ServletOutputStream, and a Writer through which the servlet can send the reply data.

Interfaces that extend the ServletResponse interface give the servlet more protocol- specific capabilities. For example, the HttpServletResponse interface contains methods that allow the servlet to manipulate HTTP-specific header information.

4.6.4 Additional Capabilities of HTTP Servlets

The classes and interfaces described above make up a basic Servlet. HTTP Servlets have some additional objects that provide session-tracking capabilities. The servlet writer can use these APIs to maintain state between the servlet and the client that persists across multiple connections during some time period. HTTP Servlets also have objects that provide cookies. The servlet writer uses the cookie API to save data with the client and to retrieve

Department Of ECE, AMCEC

28

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

this data. The classes mentioned in the Architecture of the Servlet Package section are shown in the example in bold:

SimpleServlet extends the HttpServlet class, which implements the Se rvlet interface.

SimpleServlet overrides the doGet method in the HttpServlet class. The doGet method is called when a client makes a GET request (the default HTTP req uest method) and results in the simple H TML page being returned to the client.

Within the doGet met hod, An HttpServletRequest object represents the user’s request. o An HttpServletResponse object represents the response to the user.

o Because text data is returned to the client, the reply is sent using the Writer object obtained from the HttpServletResponse object.

4.6.5 Servlet Lifecycle

Each servlet has the sa me life cycle

A server loads and initializes the servlet.

The servlet handles zero or more client requests.

The server remove s the servlet.

Fig 4.4 Servlet Lifecycle

Department Of ECE, AMCEC

29

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.6.5.1 Initializing a Servlet

When a server loads a servlet, the server runs the servlet's init method. Initialization completes before client requests are handled and before the servlet is destroyed. Even though most Servlets run in multi-threaded servers, Servlets have no concurrency issues during servlet initialization. The server calls the init method once, when the server loads the servlet, and will not call the init method again unless the server is reloading the servlet. The server cannot reload a servlet until after the server has destroyed the servlet by calling the destroy method.

The init Method:

The init method provided by the HttpServlet class initializes the servlet and logs the initialization. To do initialization specific to your servlet, override the init () method following these rules.

If an initialization error occurs that renders the servlet incapable of handling client requests, throw an Unavailable Exception.

Initialization Parameters:

The second version of the init takes the parameter name as an parameter's value.

method calls the getInitParameter method. This method argument and returns a String representation of the

The specification of initialization parameters is server-specific. In the Java Web Server, the parameters are specified with a servlet is added then configured in the Administration Tool. For an explanation of the Administration screen where this setup is performed, see the Administration Tool: Adding Servlets online help document.

Department Of ECE, AMCEC

30

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.6.5.2 Destroying a Servlet

Servlets run until the server destroys them, for example at the request of a system administrator. When a server destroys a servlet, the server runs the servlet's destroy method. The method run once; the server will not run that servlet again until after the server reloads and reinitializes the servlet.

When the destroy method runs, another thread might be running a service request. The Handling Service Threads at Servlet Termination section shows how to provide a clean shutdown when there could be long-running threads still running service requests.

Using the Destroy Method:

The destroy method provided by the Http Servlet class destroys the servlet and logs the destruction. To destroy any resources specific to servlet, override the destroy method. The destroy method should undo any initialization work and synchronize persistent state with the current in-memory state.

A server calls the destroy method after all service calls have been completed, or a server- specific number of seconds have passed, whichever comes first. If the servlet handles any long-running operations, service methods might still be running when the server calls the destroy method.

The destroy method shown above expects all client interactions to be completed when the destroy method is called, because the servlet has no long-running operations.

4.7Java Server Pages

Java Server Pages technology allows to put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML and XML, and JSP elements, which determine how the page constructs dynamic content.

Department Of ECE, AMCEC

31

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Java Server Pageâ„¢ ( JSP): An extensible Web technology that us es template data, custom elements, scripting la nguages, and server-side Java objects to return dynamic content to a client. Typically the te mplate data is HTML or XML elements, and i n many cases the client is a Web browser.

We can develop the application according to JSP model1 as shown in fig (4.5).

Fig 4.5: JSP Model1

According to above model the presentation logic has to be implemented in JSP page and the business logic has to be implemented as part of Java bean. Thi model helps in separating the presentation and business logic. For large-scale projects instead of using model1 it is better to use mo del2 (MVC).

Java Server Pages (J SP) lets people to separate the dynamic part of the pages from the static HTML. Simply w riting the regular HTML in the normal manner, using whatever Web-page-building tools normally used. Then enclosing the code for the dynamic parts in special tags, most of which start with "<%" and end with "%>". For example, here is a section of a JSP page that results in something like "Thanks for ordering Core Web Programming”.

For URL of

http://host/OrderConfirmation.jsp?title=Core+Web+Programming:

Thanks for ordering

<I><%= request.getParameter("title") %></I>

Department Of ECE, AMCEC

32

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

People normally give their file a .jsp extension, and typically install it in any place they could place a normal Web page. Although what they write often looks more like a regular HTML file than a servlet, behind the scenes, the JSP page just gets converted to a normal servlet, with the static HTML simply being printed to the output stream associated with the servlet's service method. This is normally done the first time the page is requested, and developers can simply request the page themselves when first installing it if they want to be sure that the first real user doesn't get a momentary delay when the JSP page is translated to a servlet and the servlet is compiled and loaded. Note also that many Web servers allows to define aliases so that a URL that appears to reference an HTML file really points to a servlet or JSP page.

4.8J2EE Platform Overview

The J2EE platform is designed to provide server-side and client-side support for developing distributed, multi-tier applications. Such applications are typically configured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and back-end enterprise information systems providing data management.

4.8.1 Multitier Model

The J2EE platform provides a multi-tier distributed application model. This means that the various parts of an application can run on different devices. The J2EE architecture defines a client tier, a middle tier (consisting of one or more sub-tier), and a back-end tier. The client tier supports a variety of client types, both outside and inside of corporate firewalls. The middle tier supports client services through Web containers in the Web tier and supports business logic component services through JavaBeans TM. On the back end, the enterprise information systems in the tier are accessible by way of standard APIs (Application Programming Interfaces).

Department Of ECE, AMCEC

33

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 4.6: Multitier Model of J2EE Platform

4.8.2 Container-Based Component Management

Central to the J2EE component-based development model is the notion of containers. Containers are standardized runtime environments that provide specific services to components. Components can expect these services to be available on any J2EE platform from any vendor. For example, all J2EE Web containers provide runtime support for responding to client requests, performing request-time processing (such as invoking JSP pages or servlet behavior), and returning results to the client. In addition, they provide APIs to support user session management. All Web containers provide automated support for transaction and life cycle management of Web components, as well as bean lookup and other services. Containers also provide standardized access to enterprise information systems; for example, providing access to relational data through the JDBC API. In addition, containers provide a mechanism for selecting application behaviors at assembly or deployment time. Through the use of deployment descriptors (XML files that specify component and container behavior), components can be configured to a specific container’s environment when deployed, rather than in component code. Features that can be configured at deployment time include security checks, transaction control, and other management responsibilities.

Department Of ECE, AMCEC

34

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.8.3 Support for Client Components

The J2EE client tier provides support for a variety of client types, both within the enterprise firewall and outside. Clients can be offered through Web browsers by using plain HTML pages, HTML generated dynamically by Java Server Pages TM.

4.8.4 J2EE Platform Benefits

With features designed to expedite the process of developing distributed applications, the J2EE platform offers several benefits:

Simplified architecture and development

Freedom of choice in servers, tools, and components

Integration with existing information systems

Scalability to meet demand variations

Flexible security model

4.8.4.1 Scales Easily

J2EE containers provide a mechanism that supports simplified scaling of distributed applications, with no application development effort. Because J2EE containers provide components with transaction support, database connections, life cycle management, and other features that influence performance, they can be designed to provide scalability in these areas. For example, containers may pool database connections, providing clients with quick, efficient access to data. Because containers may run on multiple systems, Web containers can automatically balance load in response to fluctuating demand.

Department Of ECE, AMCEC

35

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.8.4.2 Simplified, Unified Security Model

The J2EE security model is designed to support single sign on access to application services. Component developers can specify the security requirements of a component at the method level to ensure that only users with appropriate permissions can access specific data operations. While both Java Beans technology and Java Servlet APIs provide programmatic security control, the basic role-based security mechanism (where groups of users share specific permissions) is specified entirely at application deployment time. This provides both greater flexibility and better security control.

4.8.5 J2EE Application Scenarios

The J2EE specifications encourage architectural diversity. The J2EE specifications and technologies make few assumptions about the details of API implementations. The application-level decisions and choices are ultimately a trade-off between functional richness and complexity. The J2EE programming model is flexible enough for applications that support a variety of client types, with both the Web container and Web container as optional.

4.9 HTML

HTML (Hypertext Markup Language) is the predominant markup language for web pages. It provides a means to describe the structure of text-based information in a document by denoting certain text as headings, paragraphs, lists, and so on and to supplement that text with interactive forms, embedded images, and other objects. HTML is written in the form of labels (known as tags), surrounded by angle brackets. HTML can also describe, to some degree, the appearance and semantics of a document, and can include embedded scripting language code which can affect the behavior of web browsers and other HTML processors.

Hypertext Markup Language (HTML), the languages of the World Wide Web (WWW), allows users to produce Web pages that include text, graphics and pointer to other Web pages (Hyperlinks). HTML is not a programming language but it is an application of

Department Of ECE, AMCEC

36

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

ISO Standard 8879, SGML (Standard Generalized Markup Language), but specialized to hypertext and adapted to the Web. The idea behind Hypertext is that instead of reading text in rigid linear structure, we can easily jump from one point to another point. We can navigate through the information based on our interest and preference. A markup language is simply a series of elements, each delimited with special characters that define how text or other items enclosed within the elements should be displayed. Hyperlinks are underlined or emphasized works that load to other documents or some portions of the same document.

HTML can be used to display any type of document on the host computer, which can be geographically at a different location. It is a versatile language and can be used on any platform or desktop. HTML provides tags (special codes) to make the document look attractive. HTML tags are not case-sensitive. Using graphics, fonts, different sizes, color, etc., can enhance the presentation of the document. Anything that is not a tag is part of the document itself.

4.9.1 Basic HTML Tags

<! -- -->

specifies comments

<A>……….</A>

Creates hypertext links

<B>……….</B>

Formats text as bold

<BIG>……….</BIG>

Formats text in large font.

<BODY>…</BODY>

Contains all tags and text in the HTML document

<DD>…</DD>

Definition of a term

<DL>...</DL>

Creates definition list

<FONT>…</FONT>

Formats text with a particular font

<FORM>...</FORM>

Encloses a fill-out form

<FRAME>...</FRAME>

Defines a particular frame in a set of frames

Department Of ECE, AMCEC

37

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

 

<H#>…</H#>

Creates heading of different levels (1 – 6)

 

<HEAD>...</HEAD>

Contains tags that specify information about a document

<HR>...</HR>

Creates a horizontal rule

 

<HTML>…</HTML>

Contains all other HTML tags

 

<META>...</META>

Provides meta-information about a document

 

<SCRIPT>…</SCRIPT>

Contains client-side or server-side script

 

<TABLE>…</TABLE>

Creates a table

 

<TD>…</TD>

Indicates table data in a table

 

<TR>…</TR>

Designates a table row

 

<TH>…</TH>

Creates a heading in a table

 

4.9.2 Attributes

The attributes of an element are name-value pairs, separated by "=", and written within the start label of an element, after the element's name. The value should be enclosed in single or double quotes, although values consisting of certain characters can be left unquoted in HTML (but not XHTML). Leaving attribute values unquoted is considered unsafe.

Most elements take any of several common attributes: id, class, style and title. Most also take language-related attributes: lang and dir. The id attribute provides a document-wide unique identifier for an element. This can be used by stylesheets to provide presentational properties, by browsers to focus attention on the specific element or by scripts to alter the contents or presentation of an element. The class attribute provides a way of classifying similar elements for presentation purposes. For example, an HTML document (or a set of documents) may use the designation class="notation" to indicate that all elements with this class value are all subordinate to the main text of the document (or documents). Such notation classes of elements might be gathered together and presented as footnotes on a page, rather than appearing in the place where they appear in the source HTML.

Department Of ECE, AMCEC

38

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.9.3 Advantages of HTML

A HTML document is small and hence easy to send over the net.

It is small because it does not include formatted information.

HTML is platform independent.

HTML tags are not case-sensitive.

4.10 MySql

MySql is a relational database management system, which organizes data in the form of tables. MySQL is one of many databases servers based on RDBMS model, which manages a seer of data that attends three specific things-data structures, data integrity and data manipulation. With MySQL cooperative server technology we can realize the benefits of open, relational systems for all the applications. MySQL makes efficient use of all systems resources, on all hardware architecture; to deliver unmatched performance, price performance and scaleability.Any DBMS to be called as RDBMS has to satisfy Dr.E.F.Codd’s rules.

4.10.1 Distinct Features of MySql

PORTABLITY: The MySQL RDBMS is available on wide range of platforms

ranging from PCs to super computers and as a multi user loadable module for Novel NetWare, if one application is developed on a system, the same application can be run on other systems without any modifications.

COMPATIBILITY: MySQL commands can be used for communicating with IBM DB2 mainframe RDBMS that is different from MySQL , that is MySQL compatible with DB2. MySQL RDBMS is a high performance fault tolerant DBMS , which is specially designed for online transaction processing and for handling large database applications.

Department Of ECE, AMCEC

39

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

MULTITHREADED SERVER ARCHITECTURE: MySQL adaptable multithreaded server architecture delivers scalable high performance for very large number of users on all hardware architecture including symmetric multiprocessors (sumps) and loosely coupled multiprocessors. Performance is achieved by eliminating CPU, I/O, memory and operating system bottlenecks and by optimizing the MySQL DBMS server code to eliminate all internal bottlenecks.

4.10.2 FEATURES OF MYSQL

Most popular RDBMS in the market because of its ease of use

Client/server architecture.

Data independence.

Ensuring data integrity and data security.

Managing data concurrency.

Parallel processing support for speed up data entry and online transaction processing used for applications.

DB procedures, functions and packages.

Department Of ECE, AMCEC

40

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 5

5.SOFTWARE IMPLEMENTATION

5.1Implementation of PHR System

The PHR system can be implemented using the hardware and software mentioned in the previous chapters. The system first defines attributes shared by the users in PSD and PUD, such as “personal”, “medical history”, “current exams”, “insurance”, and “sensitive”. An emergency attribute is also defined for emergency access. Each PHR owner’s client application generates its corresponding master keys. When using the PHR service for the first time, a PHR owner can specify the access privilege of a data reader in PSD and then the application generate and distribute corresponding key to the latter through the mail.

For the PUDs, the system defines role attributes, and a user in a PUD obtains secret key from AAs. The secrete key is sent to the hospital authority or other authorities included in the system through mail. Each user in the PUD obtains attributes from the AAs. In practice, there exist multiple AAs each governing a different subset of role attributes. For example, hospital staffs shall have a different AA from pharmacy specialists.

5.2 Algorithm for the PHR system

1.PHR owner will input the files he/she wants to share.

2.Encryption of input files is done using DES algorithm.

3.Encrypted files uploaded into the cloud server and distribution of attribute based key.

4.User or data access member input the attribute-based key.

5.Verification of the key for its validity.

6.If the key is invalid, files will not decrypt.

7.If the key is valid, files will be decrypted.

8.Decrypted files will be downloaded into the user’s local system.

Department Of ECE, AMCEC

41

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Flowchart-for PHR system

Start

Input files

Encryption

No

If encrypted

Yes

s Encrypted files uploaded in cloud server

Input attributed key

No

If key is

valid? Stop

Decryption of files

based on access policy

Yes

Decrypted Files

downloaded

Stop

Fig 5.1: Flow chart of PHR system

The flow chart of the proposed PHR system is shown in figure (5.1) with the algorithm given above..

Department Of ECE, AMCEC

42

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

5.3 File Uploading Process

Fig 5.2: Flow chart for file upload

Flow chart for uploading of file is given in fig (5.2) with the corresponding algorithm in the below subsection.

5.3.1 Algorithm for file upload

1.Get the file to be uploaded into the server.

2.Get the encryption key to be used for encrypting the file.

3.Using the encryption key (EK) the file is encrypted.

4.Now the encrypted file is uploaded into the cloud server.

Department Of ECE, AMCEC

43

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

5.4 Key Distribution Process

Fig 5.3: Flow chart for key distribution

5.4.1 Algorithm for distributing key to users

1.Get the e-mail id of the user to whom the key is to be distributed.

2.Get the attribute type such as friend, hospital, insurance and emergency.

3.Get the attribute values for the corresponding attributes. For example FR for friend and EM for emergency.

Department Of ECE, AMCEC

44

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

4.User key (UK) is generated by performing Exclusive-OR (XOR) operation on dencryption key (DK) and attribute value (AV).

5.The resulting user key is written in a file and sends the file which distributes the e-mail.

5.5 File Downloading Process

Fig 5.4: Flow chart file download

Fig (5.4) is the flow chart for downloading a file and the corresponding algorithm is given in the below section.

Department Of ECE, AMCEC

45

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

5.5.1 Algorithm for file download

1.Get the PHR owner ID, attribute type and user key.

2.Get the attribute value for the corresponding attribute type.

3.Decryption key is generated by performing Exclusive-OR (XOR) operation on user key (UK) and attribute value (AV).

4.If the Decryption key (DK) is valid, then the list of files which the current attribute type has right to access is read.

5.Then the encrypted file (EF) is read from the cloud server.

6.Using the decryption key (DK), encrypted file (EF) is decrypted.

7.The decrypted file is downloaded into the users local machine.

8.If the DK is invalid then the file will not download and the process stops.

Department Of ECE, AMCEC

46

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 6

6.ENCRYPTION AND DECRYPTION

6.1Encryption and Decryption

A message in its original form (plaintext) is converted (encrypted) into an unintelligible form (cipher text) by a set of procedures known as an encryption algorithm (cipher) and a variable, called a key. The ciphertext is transformed (decrypted) back into plaintext using the encryption algorithm and a key. It is a way to enhance the security of a message or file by scrambling the contents so that it can be read only by someone who has the right encryption key to unscramble it.

6.2 Data Encryption Standard (DES)

Using Data Encryption Standard (DES) algorithm data is encrypted and decrypted. DES is the block cipher, an algorithm that takes a fixed-length string of plaintext bits and transforms it through a series of complicated operations into another cipher text bit string. In DES, the block size is 64 bits. DES also uses a key to customize the transformation, so that decryption can supposedly only be performed by those who know the particular key used to encrypt. The key consists of 64 bits; however, only 56 of these are actually used by the algorithm. Eight bits are used solely for checking parity, and are thereafter discarded. Hence the effective key length is 56 bits, and it is always quoted as such. DES uses the two basic techniques of cryptography - confusion and diffusion. At the simplest level, diffusion is achieved through numerous permutations and confusions is achieved through the XOR operation. The mechanism of diffusion seeks to make the relationship between the plaintext and ciphertext as complex as possible in order to avoid attempts to deduce the key. On the other hand, confusion seeks to make the relationship between the statistics of the ciphertext and the value of the encryption key as complex as possible, again to avoid attempts to discover the key. This is achieved by the use of a complex substitution algorithm.

Department Of ECE, AMCEC

47

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 6.1 General description of DES algorithm

Fig (6.1) is the general description of DES algorithm. The basic process in enciphering a 64- bit data block and a 56-bit key using the DES consists of:

An initial permutation (IP)

16 rounds of a complex key dependent calculation f

A final permutation, being the inverse of IP

Fig (6.2) shows the single round of DES algorithm.

 

The overall processing at each iteration:

 

Li = Ri-1

(6.1)

Ri = Li-1 F(Ri-1, Ki)

(6.2)

Where Li is the left half of 64 bit block and Ri is the right half of the same 64 bit block and F(Ri-1, Ki) is the fiestal function of Ri-1 and the 56-bit key Ki. is the XOR operation.

Department Of ECE, AMCEC

48

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 6.2 Single Round of DES algorithm

6.2.1 Initial Permutation (IP)

There is an initial permutation IP of the 64 bits of the message data say M. This rearranges the bits according to the following table, where the entries in the table show the new arrangement of the bits from their initial order. The 58th bit of M becomes the first bit of IP. The 50th bit of M becomes the second bit of IP. The 7th bit of M is the last bit of IP.

 

 

 

IP

 

 

 

 

58

50

42

34

26

18

10

2

60

52

44

36

28

20

12

4

62

54

46

38

30

22

14

6

64

56

48

40

32

24

16

8

57

49

41

33

25

17

9

1

59

51

43

35

27

19

11

3

61

53

45

37

29

21

13

5

63

55

47

39

31

23

15

7

Department Of ECE, AMCEC

49

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Example: Let M be the plain text message M = 0123456789ABCDEF, where M is in hexadecimal (base 16) format. Rewriting M in binary format, we get the 64-bit block of text: M = 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Applying the initial permutation to the block of text M, we get

IP = 1100 1100 0000 0000 1100 1100 1111 1111 1111 0000 1010 1010 1111 0000 1010 1010

Here the 58th bit of M is "1", which becomes the first bit of IP. The 50th bit of M is "1", which becomes the second bit of IP. The 7th bit of M is "0", which becomes the last bit of IP. Next divide the permuted block IP into a left half L0 of 32 bits, and a right half R0 of 32 bits. Example: From IP, we get L0 and R0

L0 = 1100 1100 0000 0000 1100 1100 1111 1111

R0 = 1111 0000 1010 1010 1111 0000 1010 1010

We now proceed through 16 iterations, for 1<=n<=16, using a function f which operates on two blocks, a data block of 32 bits and a key Kn of 48 bits to produce a block of 32 bits. Let + denote XOR addition, (bit-by-bit addition modulo 2). Then for n going from 1 to 16 we calculate equation (3.1) and (3.2).

6.2.2 The Feistel (F) function

Fig 6.3: The Feistel function (F-function)

Department Of ECE, AMCEC

50

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

The F-function, depicted in Fig (6.3), operates on half a block (32 bits) at a time and consists of four stages:

1.Expansion: The 32-bit half-block is expanded to 48 bits using the expansion permutation, denoted E in the diagram, by duplicating half of the bits. The output consists of eight 6-bit (8 * 6 = 48 bits) pieces, each containing a copy of 4 corresponding input bits, plus a copy of the immediately adjacent bit from each of the input pieces to either side.

2.Key mixing: The result is combined with a subkey using an XOR operation. 16 48- bit subkeys, one for each round, are derived from the main key using the key schedule (described below).

3.Substitution: After mixing in the subkey, the block is divided into eight 6-bit pieces before processing by the S-boxes, or substitution boxes. Each of the eight S-boxes replaces its six input bits with four output bits according to a non-linear transformation, provided in the form of a lookup table. The S-boxes provide the core of the security of DES without which the cipher would be linear, and trivially breakable.

4.Permutation: Finally the 32 outputs from the S-boxes are rearranged according to a fixed permutation, the P-box. This is designed so that, after permutation, each S-box's output bits are spread across 6 different S boxes in the next round.

Department Of ECE, AMCEC

51

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

6.2.3 Key schedule

Fig 6.4: The key-schedule

Fig (6.4) illustrates the key schedule for encryption, the algorithm which generates the subkeys. Initially, 56 bits of the key are selected from the initial 64 by Pe rmuted Choice 1 (PC-1) and the remaining ei ght bits are either discarded or used as parity c heck bits. The 56 bits are then divided into t wo 28-bit halves; each half is thereafter treated separately. In successive rounds, both halves are rotated left by one or two bits (specified for each round), and then 48 subkey bits are selected by Permuted Choice 2 (PC-2), 24 bits from the left half, and 24 from the right. The r otations (denoted by "<<<" in the diagram) mea n that a different set of bits is used in each subkey.

 

 

 

PC-1

 

 

 

57

49

41

33

25

17

9

1

58

50

42

34

26

18

10

2

59

51

43

35

27

19

11

3

60

52

44

36

63

55

47

39

31

23

15

7

62

54

46

38

30

22

14

6

61

53

45

37

29

21

13

5

28

20

12

4

Department Of ECE, AMCEC

52

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

 

 

 

 

 

 

PC-2

 

 

 

14

17

11

24

1

5

 

3

28

15

6

21

10

 

23

19

12

4

26

8

 

16

7

27

20

13

2

 

41

52

31

37

47

55

 

30

40

51

45

33

48

 

44

49

39

56

34

53

 

46

42

50

36

29

32

 

The key schedule for decryption is similar but the subkeys are in reverse order compared to encryption. Apart from that change, the process is the same as for encryption. The same 28 bits are passed to all rotation boxes.

6.2.4 Substitution Boxes

There are eight Substitution boxes or S-boxes and each box has six bits input and four bits output. We now calculate the output of these boxes as, S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8)

where Si(Bi) refers to the output of the i-th S box. To repeat, each of the functions S1, S2,..., S8, takes a 6-bit block as input and yields a 4-bit block as output. The table to determine S1 is shown and explained below:

 

 

 

 

 

S1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Column Number

 

 

 

 

 

 

 

 

 

 

Row

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No.

0

1

2

3

4

5

6

7

8

9

10 11

12 13

14 15

0

14

4

13

1

2 15

11

8

 

3

 

10

6 12

5

9

0

7

1

0 15

7

4

14

2

13

 

1

10

 

 

6

12 11

9

5

3

8

2

4

1

14

8

13

6

2 11

15

12

9

7

 

3

10

5

0

3

15 12

8

2

4

9

1

 

7

5 11

3 14

 

10

 

0

6 13

Department Of ECE, AMCEC

53

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

If S1 is the function defined in this table and B is a block of 6 bits, then S1(B) is determined as follows: The first and last bits of B represent in base 2 a number in the decimal range 0 to 3 (or binary 00 to 11). Let that number be i. The middle 4 bits of B represent in base 2 a number in the decimal range 0 to 15 (binary 0000 to 1111). Let that number be j. Look up in the table the number in the i-th row and j-th column. It is a number in the range 0 to 15 and is uniquely represented by a 4 bit block. That block is the output S1(B) of S1 for the input B. For example, for input block B = 011011 the first bit is "0" and the last bit "1" giving 01 as the row. This is row 1. The middle four bits are "1101". This is the binary equivalent of decimal 13, so the column is column number 13. In row 1, column 13 appears 5. This determines the output; 5 is binary 0101, so that the output is 0101. Hence S1(011011) = 0101.

6.2.5 Permutation

The final stage in the calculation of f is to do a permutation P of the S-box output to obtain the final value of f:

f = P(S1(B1)S2(B2)...S8(B8))

The permutation P is defined in the following table. P yields a 32-bit output from a 32-bit input by permuting the bits of the input block.

 

P

 

16

7

 

20

21

29

12

 

28

17

1

15

23

26

5

18

 

31

10

2

8

 

24

14

32

27

 

3

11

19

13

30

6

22

11

 

4

25

Department Of ECE, AMCEC

54

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Example: If the output of the eight S boxes:

S1(B1)S2(B2)S3(B3)S4(B4)S5(B5)S6(B6)S7(B7)S8(B8) = 0101 1100 1000 0010 1011 0101 1001

0111

 

we get, f = 0010 0011 0100 1010 1010 1001 1011 1011

 

using equation (6.2) and substituting i=1 we get,

 

R1 = L0 + f(R0 , K1 )

(6.3)

= 1100 1100 0000 0000 1100 1100 1111 1111

 

+ 0010 0011 0100 1010 1010 1001 1011 1011

 

= 1110 1111 0100 1010 0110 0101 0100 0100

 

In the next round, we will have L2 = R1, which is the block we just calculated, and then we must calculate R2 =L1 + f(R1, K2), and so on for 16 rounds. At the end of the sixteenth round we have the blocks L16 and R16. We then reverse the order of the two blocks into the 64-bit block and apply a final permutation IP-1 as defined by the following table:

 

 

 

IP-1

 

 

 

40

8

48

16

56

24

64

32

39

7

47

15

55

23

63

31

38

6

46

14

54

22

62

30

37

5

45

13

53

21

61

29

36

4

44

12

52

20

60

28

35

3

43

11

51

19

59

27

34

2

42

10

50

18

58

26

33

1

41

9

49

17

57

25

Department Of ECE, AMCEC

55

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

That is, the output of the algorithm has bit 40 of the pre-output block as its first bit, bit 8 as its second bit, and so on, until bit 25 of the pre-output block is the last bit of the output.

Example: If we process all 16 blocks using the method defined previously, we get, on the 16th round,

L16 = 0100 0011 0100 0010 0011 0010 0011 0100

R16 = 0000 1010 0100 1100 1101 1001 1001 0101

We reverse the order of these two blocks and apply the final permutation to

R16L16 = 00001010 01001100 11011001 10010101 01000011 01000010 00110010 00110100

IP-1 = 10000101 11101000 00010011 01010100 00001111 00001010 10110100 00000101

which in hexadecimal format is

85E813540F0AB405.

This is the encrypted form of M = 0123456789ABCDEF: namely, C = 85E813540F0AB405.

Decryption is simply the inverse of encryption, following the same steps as above, but reversing the order in which the subkeys are applied.

Department Of ECE, AMCEC

56

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

6.3 DES Algorithm

Fig 6.5: DES encryption algorithm

Fig (6.5) gives the simplified version of DES algorithm. The plain text is encrypted by the following steps in DES algorithm.

1. The plaintext is divided into 64-bit blocks. Each block is worked independently through 16 iterations of the algorithm.

Department Of ECE, AMCEC

57

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

2.At the same time, the 56-bit key is divided in half. In each iteration, the bits in each half are shifted to the left to change the key values.

3.A 64-bit block is divided in half and the right half is combined with the two key halves created in step 2.

4.The results of step 3 are converted again using permutation, then the results are combined with the left half of the 64-bit block.

5.The results of the above steps become the new right half. Now the next iteration for the same 64-bit block is ready to start. The right half from the previous iteration is brought down to become the new left half. Also, the left and right halves of the key are bit-shifted left and combined to create a new key.

6.The process repeats again using the new left half and new right half for 15 more iterations. This produces the first 64-bit block of cipher text.

The next 64-bit block is processed using the same procedure. There are 16 identical stages of processing, termed rounds. Before the main rounds, the block is divided into two 32-bit halves and processed alternately; this crisscrossing is known as the Feistel scheme. The Feistel structure ensures that decryption and encryption are very similar processes — the only difference is that the sub-keys are applied in the reverse order when decrypting. The rest of the algorithm is identical. This greatly simplifies implementation, particularly in hardware, as there is no need for separate encryption and decryption algorithms. The F-function scrambles half a block together with some of the key. The output from the F-function is then combined with the other half of the block, and the halves are swapped before the next round. After the final round, the halves are swapped; this is a feature of the Feistel structure which makes encryption and decryption similar processes.

Department Of ECE, AMCEC

58

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 7

7.ADVANTAGES AND APPLICATIONS

7.1Advantages

There is policy management for file access, data access member can able to access the files which they have rights set by the policy.

Files stored in the semi-trusted cloud are in encrypted form and there is no chance of others to view the file content.

There is a structured way to access the file for personal & professional purpose through attribute policies and attribute based encryption and decryption.

7.2 Applications

Online personal health record (PHR) enables patients to manage their own medical records in a centralized way, which greatly facilitates the storage, access and sharing of personal health data.

Easy ways for health providers, insurance companies, hospitals and patients to all access the information.

Comprehensive solutions for parents who are managing their children’s records.

Eliminate communication barriers and allows documentation flow between patients and clinicians in a timely fashion can save time consumed by face-to-face meetings and telephone communication.

In the case of an emergency a PHR can quickly provide critical information to proper diagnosis or treatment.

Cloud providers offer a computing platform to its clients where they can deploy applications of its own, program languages of its own, all without having to maintain or control the cloud equipment.

Department Of ECE, AMCEC

59

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 8

8. RESULTS

Following are the results of the proposed PHR system.

Fig 8.1: PHR home page

Fig (8.1) is the PHR system home page that is visible whenever the user logs in.

Fig 8.2: Admin profile

Fig (8.2) shows the profile of the admin which includes the name, email id, contact number and address of the admin.

Department Of ECE, AMCEC

60

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.3: Attribute Values

Fig (8.3) gives the attribute values such as friend, hospital, insurance and emergency.

Fig 8.4: Policy Management

Fig (8.4) gives the policy management table details according which the user will get access privilege to selected files.

Department Of ECE, AMCEC

61

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.5: PHR Owner details

Fig (8.5) shows different PHR owner details which includes name, id, address, contact number and email id.

Fig 8.6: Key generation

Fig (8.6) shows the key generation for different PHR owners.

Department Of ECE, AMCEC

62

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Encryption and decryption keys are generated using the following formulas.

Encryption: C = EK(P)

Decryption: P = EK-1(C)

EK is chosen from a family of transformations known as a cryptographic system. The parameter that selects the individual transformation is called the key K, selected from a keyspace K.

Fig 8.7: Transaction details

Fig (8.7) shows the transaction details which includes the user name, transaction type (file upload or download), file type (text or image), time and date of transaction.

Department Of ECE, AMCEC

63

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.8: PHR Owner Details

Fig (8.8) shows the PHR owner profile, it consists of PHR owner id, name, email id etc.

Fig 8.9: File upload

Fig (8.9) shows the uploading of a file by the PHR owner.

Department Of ECE, AMCEC

64

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.10: File upload Confirmation message

Fig (8.10) is the File upload Confirmation message when a file uploaded into the server.

Fig 8.11: Key distribution

Fig (8.11) shows the key distribution to friend. The attribute based key is distributed to respective users through e-mail.

Department Of ECE, AMCEC

65

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.12: Data Access Member login

The data access member will login by entering the PHR Owner ID and the attribute based key distributed by the owner.

Fig 8.13: Data Access Member home page

Fig (8.13) is the Data Access Member home page. It contains two options (1)Download Files. (2) Download Support Files.

Department Of ECE, AMCEC

66

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

Fig 8.14: Downloading of a file

Fig (8.14) shows that the file downloading process is in progress.

Fig 8.15: File Download Success Message

Fig (8.15) gives the file downloading success message when it is downloaded into the user’s local machine.

Department Of ECE, AMCEC

67

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

CHAPTER 9

9.CONCLUSION AND FUTURE SCOPE

9.1Conclusion

In the proposed scheme, it is possible to achieve secure sharing of personal health records and other files in cloud computing. Patients can have complete control of their own privacy through encrypting their Personal Health Record (PHR) and other data to allow access to selective users. The unique challenge introduced by multiple PHR owners and users such as security and key management complexities are greatly reduced by using DES encryption algorithm that has a key size of 56-bits. An Attribute Based Encryption (ABE) is used to encrypt the PHR data, so that patients can allow access not only to personal users, but also to various users from public domains with different professional roles. On-demand user revocation with security is also achieved. Through implementation and simulation, we show that our solution is scalable.

9.2 Future Scope

This project work is on simulation, while the extension of this work is that it can be deployed in real time applications for the secure sharing of files. More security can be achieved through other complicated algorithms with a larger key size.

The records can be shared with users other than the attributes included in this work.

Department Of ECE, AMCEC

68

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

REFERENCES

[1]M. Li, S. Yu, K. Ren and W. Lou, “Securing Personal Health Records In Cloud Computing: Patient-Centric and fine-Grained Data Access Control in Multi-Owner Settings”, SecureComm’10, Sept. 2010, pp. 89–106.

[2]H. Lo¨ hr, A.-R. Sadeghi and M. Winandy, “Securing the E-Health Cloud”, Proceedings of the 1st ACM International Health Informatics Symposium, ser. IHI ’10, 2010, pp. 220– 229.

[3]M. Li, S. Yu, N. Cao, and W. Lou, “Authorized Private Keyword Search Over Encrypted Personal Health Records In Cloud Computing”, ICDCS ’11, Jun. 2011.

[4]“The Health Insurance Portability And Accountability Act”[Online]. Available: http://www.cms.hhs.gov/HIPAAGenInfo/01 Overview.asp

[5]Ming Li, Shucheng Yu, Yao Zheng, Kui Ren, “Scalable and Secure Sharing of Personal

Health Records in Cloud Computing using Attribute-based Encryption” in IEEE 2012 Transactions on Parallel and Distributed Systems, Volume: PP , Issue:99

[6] K. D.

Mandl,

P. Szolovits and I. S. Kohane, “Public Standards And Patients’ Control:

How

to Keep

Electronic Medical Records Accessible but Private”, BMJ, vol. 322, no.

7281, pp. 283, Feb. 2001.

[7]J. Benaloh, M. Chase, E. Horvitz and K. Lauter, “Patient Controlled Encryption: Ensuring Privacy of Electronic Medical Records”, CCSW ’09, 2009, pp. 103–114.

[8]S. Yu, C. Wang, K. Ren, and W. Lou, “Achieving Secure, Scalable and Fine-Grained Data Access Control In Cloud Computing”, IEEE INFOCOM’10, 2010.

Department Of ECE, AMCEC

69

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

[9] C. Dong, G. Russello and N. Dulay, “Shared and Searchable Encrypted Data for Untrusted Servers”, Journal of Computer Security, 2010.

[10]V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-Based Encryption For Fine- Grained Access Control of Encrypted Data”, CCS ’06, 2006, pp. 89–98.

[11]M. Li, W. Lou, and K. Ren, “Data Security and Privacy in Wireless Body Area Networks”, IEEE Wireless Communications Magazine, Feb.2010.

[12]A. Boldyreva, V. Goyal, and V. Kumar, “Identity-Based Encryption with Efficient Revocation”, ACM CCS, ser. CCS ’08, 2008, pp.417–426.

[13]L. Ibraimi, M. Petkovic, S. Nikova, P. Hartel and W. Jonker, “Ciphertext-Policy Attribute-Based Threshold Decryption With Flexible Delegation and Revocation of User Attributes”, 2009.

[14]S. Yu, C. Wang, K. Ren, and W. Lou, “Attribute Based Data Sharing With Attribute Revocation”, ASIACCS’10, 2010.

[15]X. Liang, R. Lu, X. Lin, and X. S. Shen, “Patient Self-Controllable Access Policy on PHI in Ehealthcare Systems”, AHIC 2010, 2010.

[16]L. Ibraimi, M. Asim, and M. Petkovic, “Secure Management Of Personal Health Records by Applying Attribute-Based Encryption”, Technical Report, University of Twente, 2009.

[17]J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-Policy Attribute-Based Encryption”, IEEE S& P ’07, 2007, pp. 321–334.

Department Of ECE, AMCEC

70

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

[18]J. A. Akinyele, C. U. Lehmann, M. D. Green, M. W. Pagano, Z. N. J. Peterson, and A. D. Rubin, “Self-Protecting Electronic Medical Records Using Attribute-Based Encryption”,

Cryptology ePrint Archive, Report 2010/565, 2010, http://eprint.iacr.org/.

[19]M. Chase and S. S. Chow, “Improving Privacy And Security In Multi-Authority Attribute-Based Encryption”, CCS ’09, 2009, pp. 121–130.

[20]X. Liang, R. Lu, X. Lin, and X. S. Shen, “Ciphertext Policy Attribute Based Encryption With Efficient Revocation”, Technical Report, University of Waterloo, 2010.

[21]J. Hur and D. K. Noh, “Attribute-Based Revocation in Data Outsourcing Systems”, IEEE Transactions on Parallel and Distributed Systems, vol. 99, no. PrePrints, 2010.

[22]S. Jahid, P. Mittal and N. Borisov, “Easier: Encryption-Based Access Control in Social Networks With Efficient Revocation” ASIACCS, Hong Kong, March 2011.

[23]S. Ruj, A. Nayak and I. Stojmenovic, “DACC: Distributed Access Control in Clouds”,

10th IEEE TrustCom, 2011.

Department Of ECE, AMCEC

71

Secure Sharing Of Personal Health Records in Cloud Computing Using Encryption

2012-2013

 

 

APPENDIX

PUBLICATIONS

Department Of ECE, AMCEC

72