SYSTEM REQUIRMENTS SPECIFICATION
A. Aim of the Project:
This aim of the System is to address the problem of data privacy and design a cloud-assisted
privacy preserving mobile health monitoring system to protect the privacy of the involved parties
and their data. Moreover, the outsourcing decryption technique and a newly-proposed key private
proxy re-encryption are adapted to shift the computational complexity of the involved parties to the
cloud without compromising clients’ privacy and service providers ‘intellectual property. Finally,
our security and performance analysis demonstrates the effectiveness of our developed System.
A CAM system will collect authorized medical data about people and store it securely on the
cloud server to help deliver quick and efficient care of Patients.
Problem Statement:
This system will address the important problem of data security and design a cloud-assisted
privacy preserving mobile health monitoring system to protect the privacy of the involved parties
and their data. The intended system will consist of implementation in a mobile based environment.
Integration of cloud server and users’ device to provide efficient storage and accessibility. Providing
complete security of user data in accompany with mobile environment.
Existing System:
In Existing System CAM model is present as a web based project. A website that allows user
login, Trusted Authority login and the company i. e. service provider. Our aim is to provide the
service in an easier and in a mobile way. Users will have this service as a mobile app so the
convenience or the usage is increased. Existing system misses the mobile part which our system
will be implementing.
Disadvantage:
In Existing System privacy protection mechanisms apply by simply re-moving clients’ personal
identity information (such as names or SSN) or by using anonymization technique fails to servers
an effective way in dealing with privacy of health systems due to the increasing amount and
diversity of personal identifiable information . It is worth noting that the collected information from
a mHealth monitoring system could contain clients’ personal physical data such as their heights,
weights, and blood types, or even their ultimate personal identifiableinformation such as their
fingerprints and DNA profiles. Because there may be chances of data misuse from Admin, Trusted
Authority.
B. Proposed System
The proposed models will be a User module, a Trusted Authority module and a Service Provider
module. User module consists of an android app which will allow users to use the application in
mobile environment. It will present before the user a login and through which access to app
showing their requests, also user will be able to query the app for their schedule of medication.
Trusted Authority module will act as an interface between user and service provider. It will
hold the information provided by the users and provide the users with keys. The information is
held by the trusted authority is in encrypted format so no way of information leak.
The System stores its encrypted monitoring data or program in the cloud server. Individual
clients collect their medical data and store them in their mobile devices, which then transform the
data into attribute vectors. The attribute vectors are delivered as inputs to the monitoring program
in the cloud server through a mobile (or smart) device. A semi-trusted authority is responsible for
distributing private keys to the individual clients and collecting the service fee from the clients
according to a certain business model such as pay-as-you-go business model.
C. Description of Project In Short:
We first elaborate our cloud-assisted mHealth monitoring system (CAM). CAM consists of four
parties: the cloud server (simply the cloud), the company who provides the mHealth monitoring
service (i.e. the healthcare service provider), and the individual clients (simply clients), and a semitrusted authority (TA).
The company stores its encrypted monitoring data or program in the cloud server. Individual
clients collect their medical data and store them in their mobile devices, which then transform the
data into attribute vectors. The attribute vectors are delivered as inputs to the monitoring program
in the cloud server through a mobile (or smart) device. A semi-trusted authority is responsible for
Distributing private keys to the individual clients and collecting the service fee from the clients
according to a certain business model such as pay-as-you-go business model. The TA can be
considered as a collaborator or a management agent for a company (or several companies) and
thus shares certain level of mutual interest with the company. However, the company and TA could
collude to obtain private health data from client input vectors. We assume a neutral cloud server,
which means it neither colludes with the company nor a client to attack the other side.
D. Process Summary:
mHelath Service Provider Processes
1. Service Provider will store the data monitoring details in cloud in encrypted form.
2. Service provider can view user details.
3. Service Provider can add medical data details & also view & add comments &
descriptions.
Cloud Server Processes
4. Act’s as a offline storage.
5. All data are stored in encrypted form securely even password of user also.
Cloud Server Processes
6. Client Registration.
7. Trusted Authority activates the user account.
8. Client Login by providing correct Username & Password.
9. Client can raise the query when a query is raise request is automatically send to the
Trusted Authority.
10. Client can view their details.
11. Client can raise query & view query results using the token
Cloud Server Processes
12. STA will generate token for user (Client). STA also not able to view the token even if
token is generated & send by STA.
E. Algorithms:
1. Private Key encryption Algorithm:
This algorithm is performed by TA to generate private key for each user.
2. Token Generation Algorithm:
This algorithm is performed by TA to generate unique & encrypted token
for each client.
3. Decryption Algorithm:
Decryption Algorithm performed at Client side to decrypt the data returned by cloud
server.
F. Experimental Setup:
We require cloud server (Amazon Service Provider) to store large amount of user details
securely in encrypted format.
Hardware Requirements:

Pentium processor at 900 MHz or higher

1 GB RAM or higher

25 GB or more hard disk
Software Requirements:

Operating System

Developing language : - Java (JDK 1.7)

Database
: - MySQL 5.5

Tools
: - Eclipse Helios
: - Windows 7.

Server
: - Apache Tomcat 7.0.
Design and Implementation Constraints
We will deploy this system on Cloud Server so we need to purchase Private Cloud. We need an
android enabled phone with internet facility.
Assumptions and Dependencies
User is using Android Application to give their daily schedule information to obtain
response from Healthcare Provider.
Modules Information
Module1:
1.1. GUI of the Project
GUI of the Project in android accessing cloud & for displaying final result to the user.
1.2. Branching Program:
We formally describe the branching programs, which include binary classification or decision trees
as a special case. We only consider the binary branching program for the ease of exposition since a
private query protocol based on a general decision tree can be easily derived from our scheme.
Module 2: Token Generation
To generate the private key for the attribute vector a client first computes the identity
representation set of each element and delivers all the identity representation sets to TA. Then TA
runs the Anon Extraction each identity in the identity set and delivers all the respective private
keys to the client.
Module 3:
3.1 Query Generation
A client delivers the private key sets obtained from the TokenGenerationalgorithm to the
cloud, which runs the Anon Decryption algorithm on the cipher text generated in the Store
algorithm. Starting the decryption result determines which cipher text should be decrypted next.
Then the decryption result indicates the next node index. The cloud will then use
AnonDecryptionalgorithm to decrypt the subsequent cipher text Continue this process iteratively
until it reaches a leaf node and decrypt the respective attached information.
3.2 Semi Trusted Authority:
A semi-trusted authority is responsible for distributing private keys to the individual clients
and collecting the service fee from the clients according to a certain business model such as pay-asyou-go business model. The TA can be considered as a collaborator or a management agent for a
company (or several companies) and thus shares certain level of mutual interest with the company.
However, the company and TA could collude to obtain private health data from client input vectors.
Module 4: Contribution Work
4.1 Fully Secure Anonymous HIBE
A Hierarchical Identity Based Encryption scheme (henceforth abbreviated in HIBE) over an
alphabet ∑ is a tuple of five efficient and probabilistic algorithms: (Setup, Encrypt, KeyGen,
Decrypt, and Delegate).
An HIBE system is an IBE that allows delegation of the keys in a hierarchical structure. To the
top of the structure there is the central authority that holds the master secret key, then several
sub-authorities (or individual users) that hold delegated keys which can be used to decrypt only
the messages addressed to the organization which the sub-authority belongs.
We will be comparing our existing system with this algorithm.
Project Plan
Modules
Code Delivery date
Code
delivered
(Percentage) %
Module 1
25%
Module 2
50%
Module 3
75%
Module 4
100%
in