01-21-2014, 04:24 PM
Scalable and Secure Sharing of Personal Health
Records in Cloud Computing using
Attribute-based Encryption
Abstract
Personal health record (PHR) is an emerging patient-centric model of
health information exchange, which is often outsourced to be stored at a third party, such
as cloud providers. However, there have been wide privacy concerns as personal health
information could be exposed to those third party servers and to unauthorized parties. To
assure the patients’ control over access to their own PHRs, it is a promising method to
encrypt the PHRs before outsourcing. Yet, issues such as risks of privacy exposure,
scalability in key management, flexible access and efficient user revocation, have
remained the most important challenges toward achieving fine-grained, cryptographically
enforced data access control. In this paper, we propose a novel patient-centric framework
and a suite of mechanisms for data access control to PHRs stored in semi-trusted servers.
To achieve fine-grained and scalable data access control for PHRs, we leverage attribute
based encryption (ABE) techniques to encrypt each patient’s PHR file. Different from
previous works in secure data outsourcing, we focus on the multiple data owner scenario,
and divide the users in the PHR system into multiple security domains that greatly
reduces the key management complexity for owners and users. A high degree of patient
privacy is guaranteed simultaneously by exploiting multi-authority ABE. Our scheme
also enables dynamic modification of access policies or file attributes, supports efficient
on-demand user/attribute revocation and break-glass access under emergency scenarios.
Extensive analytical and experimental results are presented which show the security,
scalability and efficiency of our proposed scheme.
Architecture
Existing System
In Existing system a PHR system model, there are multiple owners
who may encrypt according to their own ways, possibly using different sets
of cryptographic keys. Letting each user obtain keys from every owner who’s
PHR she wants to read would limit the accessibility since patients are not
always online. An alternative is to employ a central authority (CA) to do the
key management on behalf of all PHR owners, but this requires too much
trust on a single authority (i.e., cause the key escrow problem).
Key escrow (also known as a “fair” cryptosystem) is an
arrangement in which the keys needed to decrypt encrypted data are held in
escrow so that, under certain circumstances, an authorized third party may
gain access to those keys. These third parties may include businesses, who
may want access to employees' private communications, or governments,
who may wish to be able to view the contents of encrypted communications.
Proposed System
We endeavor to study the patient centric, secure sharing of PHRs stored on
semi-trusted servers, and focus on addressing the complicated and challenging key
management issues. In order to protect the personal health data stored on a semitrusted
server, we adopt attribute-based encryption (ABE) as the main encryption
primitive.
Using ABE, access policies are expressed based on the attributes of users or
data, which enables a patient to selectively share her PHR among a set of users by
encrypting the file under a set of attributes, without the need to know a complete list
of users.
The complexities per encryption, key generation and decryption are only
linear with the number of attributes involved.
Modules
1. Registration
2. Upload files
3. ABE for Fine-grained Data Access Control
4. Setup and Key Distribution
5. Break-glass
Modules Description
Registration
In this module normal registration for the multiple users. There are
multiple owners, multiple AAs, and multiple users. The attribute hierarchy of files
– leaf nodes is atomic file categories while internal nodes are compound
categories. Dark boxes are the categories that a PSD’s data reader has access to.
Two ABE systems are involved: for each PSD the revocable KP-ABE
scheme is adopted for each PUD, our proposed revocable MA-ABE scheme.
_ PUD - public domains
_ PSD - personal domains
_ AA - attribute authority
_ MA-ABE - multi-authority ABE
_ KP-ABE - key policy ABE
Upload files
In this module, users upload their files with secure key probabilities. The
owners upload ABE-encrypted PHR files to the server. Each owner’s PHR file
encrypted both under a certain fine grained model.
ABE for Fine-grained Data Access Control
In this module ABE to realize fine-grained access control for outsourced data
especially, there has been an increasing interest in applying ABE to secure electronic
healthcare records (EHRs). An attribute-based infrastructure for EHR systems, where
each patient’s EHR files are encrypted using a broadcast variant of CP-ABE that
allows direct revocation. However, the cipher text length grows linearly with the
number of un revoked users. In a variant of ABE that allows delegation of access
rights is proposed for encrypted EHRs applied cipher text policy ABE (CP-ABE) to
manage the sharing of PHRs, and introduced the concept of social/professional
domains investigated using ABE to generate self-protecting EMRs, which can either
be stored on cloud servers or cell phones so that EMR could be accessed when the
health provider is offline.
Setup and Key Distribution
In this module the system first defines a common universe of data attributes shared by
every PSD, such as “basic profile”, “medical history”, “allergies”, and “prescriptions”. An
emergency attribute is also defined for break-glass access.
Each PHR owner’s client application generates its corresponding public/master keys.
The public keys can be published via user’s profile in an online healthcare social-network (HSN)
There are two ways for distributing secret keys.
_ First, when first using the PHR service, a PHR owner can specify the access
privilege of a data reader in her PSD, and let her application generate and
distribute corresponding key to the latter, in a way resembling invitations in
GoogleDoc.
_ Second, a reader in PSD could obtain the secret key by sending a request
(indicating which types of files she wants to access) to the PHR owner via HSN,
and the owner will grant her a subset of requested data types. Based on that, the
policy engine of the application automatically derives an access structure, and
runs keygen of KP-ABE to generate the user secret key that embeds her access
structure.
Break-glass module
In this module when an emergency happens, the regular access
policies may no longer be applicable. To handle this situation, break-glass access is
needed to access the victim’s PHR. In our framework, each owner’s PHR’s access
right is also delegated to an emergency department ED to prevent from abuse of
break-glass option, the emergency staff needs to contact the ED to verify her
identity and the emergency situation, and obtain temporary read keys. After the
emergency is over, the patient can revoke the emergent access via the ED.
System Specification
[b]System Requirements:
Hardware Requirements:
•System : Pentium IV 2.4 GHz.
•Hard Disk : 40 GB.
•Floppy Drive : 1.44 Mb.
•Monitor : 15 VGA Colour.
•Mouse : Logitech.
•Ram : 512 Mb.
Software Requirements:
•Operating system : - Windows XP.
•Coding Language : ASP.Net with C#.
•Data Base : SQL Server 2008
[/b]
Records in Cloud Computing using
Attribute-based Encryption
Abstract
Personal health record (PHR) is an emerging patient-centric model of
health information exchange, which is often outsourced to be stored at a third party, such
as cloud providers. However, there have been wide privacy concerns as personal health
information could be exposed to those third party servers and to unauthorized parties. To
assure the patients’ control over access to their own PHRs, it is a promising method to
encrypt the PHRs before outsourcing. Yet, issues such as risks of privacy exposure,
scalability in key management, flexible access and efficient user revocation, have
remained the most important challenges toward achieving fine-grained, cryptographically
enforced data access control. In this paper, we propose a novel patient-centric framework
and a suite of mechanisms for data access control to PHRs stored in semi-trusted servers.
To achieve fine-grained and scalable data access control for PHRs, we leverage attribute
based encryption (ABE) techniques to encrypt each patient’s PHR file. Different from
previous works in secure data outsourcing, we focus on the multiple data owner scenario,
and divide the users in the PHR system into multiple security domains that greatly
reduces the key management complexity for owners and users. A high degree of patient
privacy is guaranteed simultaneously by exploiting multi-authority ABE. Our scheme
also enables dynamic modification of access policies or file attributes, supports efficient
on-demand user/attribute revocation and break-glass access under emergency scenarios.
Extensive analytical and experimental results are presented which show the security,
scalability and efficiency of our proposed scheme.
Architecture
Existing System
In Existing system a PHR system model, there are multiple owners
who may encrypt according to their own ways, possibly using different sets
of cryptographic keys. Letting each user obtain keys from every owner who’s
PHR she wants to read would limit the accessibility since patients are not
always online. An alternative is to employ a central authority (CA) to do the
key management on behalf of all PHR owners, but this requires too much
trust on a single authority (i.e., cause the key escrow problem).
Key escrow (also known as a “fair” cryptosystem) is an
arrangement in which the keys needed to decrypt encrypted data are held in
escrow so that, under certain circumstances, an authorized third party may
gain access to those keys. These third parties may include businesses, who
may want access to employees' private communications, or governments,
who may wish to be able to view the contents of encrypted communications.
Proposed System
We endeavor to study the patient centric, secure sharing of PHRs stored on
semi-trusted servers, and focus on addressing the complicated and challenging key
management issues. In order to protect the personal health data stored on a semitrusted
server, we adopt attribute-based encryption (ABE) as the main encryption
primitive.
Using ABE, access policies are expressed based on the attributes of users or
data, which enables a patient to selectively share her PHR among a set of users by
encrypting the file under a set of attributes, without the need to know a complete list
of users.
The complexities per encryption, key generation and decryption are only
linear with the number of attributes involved.
Modules
1. Registration
2. Upload files
3. ABE for Fine-grained Data Access Control
4. Setup and Key Distribution
5. Break-glass
Modules Description
Registration
In this module normal registration for the multiple users. There are
multiple owners, multiple AAs, and multiple users. The attribute hierarchy of files
– leaf nodes is atomic file categories while internal nodes are compound
categories. Dark boxes are the categories that a PSD’s data reader has access to.
Two ABE systems are involved: for each PSD the revocable KP-ABE
scheme is adopted for each PUD, our proposed revocable MA-ABE scheme.
_ PUD - public domains
_ PSD - personal domains
_ AA - attribute authority
_ MA-ABE - multi-authority ABE
_ KP-ABE - key policy ABE
Upload files
In this module, users upload their files with secure key probabilities. The
owners upload ABE-encrypted PHR files to the server. Each owner’s PHR file
encrypted both under a certain fine grained model.
ABE for Fine-grained Data Access Control
In this module ABE to realize fine-grained access control for outsourced data
especially, there has been an increasing interest in applying ABE to secure electronic
healthcare records (EHRs). An attribute-based infrastructure for EHR systems, where
each patient’s EHR files are encrypted using a broadcast variant of CP-ABE that
allows direct revocation. However, the cipher text length grows linearly with the
number of un revoked users. In a variant of ABE that allows delegation of access
rights is proposed for encrypted EHRs applied cipher text policy ABE (CP-ABE) to
manage the sharing of PHRs, and introduced the concept of social/professional
domains investigated using ABE to generate self-protecting EMRs, which can either
be stored on cloud servers or cell phones so that EMR could be accessed when the
health provider is offline.
Setup and Key Distribution
In this module the system first defines a common universe of data attributes shared by
every PSD, such as “basic profile”, “medical history”, “allergies”, and “prescriptions”. An
emergency attribute is also defined for break-glass access.
Each PHR owner’s client application generates its corresponding public/master keys.
The public keys can be published via user’s profile in an online healthcare social-network (HSN)
There are two ways for distributing secret keys.
_ First, when first using the PHR service, a PHR owner can specify the access
privilege of a data reader in her PSD, and let her application generate and
distribute corresponding key to the latter, in a way resembling invitations in
GoogleDoc.
_ Second, a reader in PSD could obtain the secret key by sending a request
(indicating which types of files she wants to access) to the PHR owner via HSN,
and the owner will grant her a subset of requested data types. Based on that, the
policy engine of the application automatically derives an access structure, and
runs keygen of KP-ABE to generate the user secret key that embeds her access
structure.
Break-glass module
In this module when an emergency happens, the regular access
policies may no longer be applicable. To handle this situation, break-glass access is
needed to access the victim’s PHR. In our framework, each owner’s PHR’s access
right is also delegated to an emergency department ED to prevent from abuse of
break-glass option, the emergency staff needs to contact the ED to verify her
identity and the emergency situation, and obtain temporary read keys. After the
emergency is over, the patient can revoke the emergent access via the ED.
System Specification
[b]System Requirements:
Hardware Requirements:
•System : Pentium IV 2.4 GHz.
•Hard Disk : 40 GB.
•Floppy Drive : 1.44 Mb.
•Monitor : 15 VGA Colour.
•Mouse : Logitech.
•Ram : 512 Mb.
Software Requirements:
•Operating system : - Windows XP.
•Coding Language : ASP.Net with C#.
•Data Base : SQL Server 2008
[/b]