Ensuring Distributed Accountability in the Cloud

University of Pune
A
Project Report
On
”Ensuring Distributed Accountability ”
Submitted by
Mr.Suraj Mehta
Under the Guidance of
Prof.
Department of Computer Engineering
KJ’S Educational Institute’s
Pune - 411048
2013 - 2014

’Ensuring Distributed Accountability’
Cloud Security
Version: 1.0
Designed By:
Suraj Mehta

Guide and Version Details
Guide:
• Internal Guide Name:
• BE Project Co-ordinator:
Presented By:
Date Version Title Authors
07/11/2013 1.0 ”Ensuring Distributed Accountability” Saily Konde
Aakash Takale
Shreyas Tapale
Suraj Mehta

KJ EDUCATIONAL INSTITUTE’S
TRINITY COLLEGE OF ENGINEERING AND RESEARCH
Pune- 411048
CERTIFICATE
This is to certify that , Mr. Suraj Mehta have carried out Preliminary Project
Work on ”Ensuring Distributed Accountibility” under my guidance in partial
fulﬁllment for degree of Bachelor of Engineering in Computer Science of Pune Uni-
versity during the academic year 2013-2014.
They have satisfactorily completed Preliminary Project Work as prescribed by the
University of Pune for the Final Year of Engineering in Information Technology
Department.
Place: Pune
Date:
Prof. Prof.
[Project Guide] [H.O.D.]

ACKNOWLEDGEMENT
We wish to express my sincere gratitude to H.O.D of Computer Department of
Trinity College of Engineering and Research, Pune for providing us an opportunity
to do my project work on Ensuring Distributed Accountability. This project bears
on imprint of many peoples. We sincerely thank to our project guide for guidance
and encouragement in carrying out this project work. We also wish to express
our gratitude to the oﬃcials and other staﬀ members of project coordinator who
rendered their help during the period of our project work. Last but not least we wish
to thank all our teachers and friends for their constructive comments, suggestions
and criticism and all those directly or indirectly helped us in completing this project.
Name of Student : Suraj Mehta

Ensuring Distributed Accountability
Abstract
Ensuring distributed accountability for data sharing in the cloud is in short nothing
but a novel highly decentralized information accountability framework to keep track
of the actual usage of the users’ data in the cloud. Cloud computing enables highly
efficient services that are easily consumed over the internet. One of the important
and foremost feature of the cloud is user’s data can be operated or processed in any
of the unknown machines that user personally do not own. The feasibility which has
occurred due to the new emerging technology user fear of losing the hold on their
personal data lets say financial or health related. And this can become an obstruc-
tion to the wide adoption of services provided by cloud. Our proposed approach is
Object-centered approach which enables enclosing our logging mechanisms together
with user’s data and respective policies. Using the JAR programmable capacities to
both create a dynamic and travelling object and also to trigger the authentication
and automated logging local to the JARs. And to make more secure the user’s
control we will be providing distributed auditing mechanisms.
Scope:
The scope of our system is that we use a private cloud for uploading the Owner’s
data. While doing this the owner is not sure about his data, so we will be encrypt-
ing his data and then respectively storing it on the cloud. The data would be then
wrapped into JAR file along with some access policies. Few algorithms will be used
by us while carrying out this task. And finally the user or say owner can access his
data safely and securely.
Innovativeness and Usefulness:
We proposed innovative approaches for automatically logging any access to the data
in the cloud together with an auditing mechanism. Our approach allows the data
owner to not only audit his content but also enforce strong back-end protection if
needed. Moreover, one of the main features of our work is that it enables the data
owner to audit even those copies of its data that were made without his knowledge.
Department of Computer Engineering I

Ensuring Distributed Accountability CONTENTS
Contents
1 INTRODUCTION 2
1.1 Overview: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Brief Description: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Problem Deﬁnition Project Objectives, Goal: . . . . . . . . . . . . . . 3
1.4 Applying software engineering approach: . . . . . . . . . . . . . . . . 4
2 Literature Survey 6
2.1 Literature Survey: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Feasibility Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Economical Feasibility: . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Legal Feasibility: . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.3 Time Feasibility: . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.4 S/W and H/W Availability: . . . . . . . . . . . . . . . . . . . 8
3 Project Plan 9
3.1 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 SRS 14
4.1 Introduction: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1 Purpose: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3 Product Features . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.4 Use classes and characteristics . . . . . . . . . . . . . . . . . . 18
4.1.5 Operating Environment . . . . . . . . . . . . . . . . . . . . . 19
4.1.6 Design and Implementation constraints . . . . . . . . . . . . . 19
4.1.7 Assumptions and Dependencies . . . . . . . . . . . . . . . . . 19
4.2 System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3 External Interface Requirements . . . . . . . . . . . . . . . . . . . . . 20
4.3.1 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3.3 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 20
Department of Computer Engineering II

Ensuring Distributed Accountability CONTENTS
4.4 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Safety Requirements . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.3 Software Quality Attributes . . . . . . . . . . . . . . . . . . . 21
4.4.4 Security Requirements . . . . . . . . . . . . . . . . . . . . . . 21
4.5 System Analysis Model . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5.1 Use Case Diagram: . . . . . . . . . . . . . . . . . . . . . . . . 22
4.5.2 Class Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 System Design 24
5.1 System Architecture and Business Logic: . . . . . . . . . . . . . . . . 25
5.2 UML Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Component and Deployment Diagram . . . . . . . . . . . . . . . . . . 28
6 Technical Speciﬁcation 30
6.1 Technology details to be used in the project . . . . . . . . . . . . . . 31
6.2 References to Technology . . . . . . . . . . . . . . . . . . . . . . . . . 31
7 Conclusion 32
8 References 34
9 Appendix A 36
10 Appendix B 40
11 Appendix C 44
Department of Computer Engineering III

Ensuring Distributed Accountability LIST OF FIGURES
List of Figures
4.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1 System Architecture and Business Logic . . . . . . . . . . . . . . . . 25
5.2 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Activity Diagram2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5 Component Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1 System Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1 Agile Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Department of Computer Engineering IV

Ensuring Distributed Accountability LIST OF TABLES
List of Tables
3.1 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 System Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1 Status of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Department of Computer Engineering 1

Ensuring Distributed Accountability INTRODUCTION
1.1 Overview:
The Aim of our system is, in addition to the Ensuring Distributed Accountability
for Data Sharing in the Cloud. we use cloud for uploading data owner’s data. Data
Owner who has uploaded his data on cloud he is not ensure about his data, so we
have to store his data on the cloud by encrypting his data and then that data is
wrapped into jar file along with the access policies and then that jar file is stored at
the cloud.Then user can access the data.
1.2 Brief Description:
Cloud computing enables highly scalable services to be easily consumed over the
Internet on an as-needed basis.A major feature of the cloud services is that user’s
data are usually processed remotely in unknown machines that users do not own or
operate. While enjoying the convenience brought by this new emerging technology,
users’ fears of losing control of their own data (particularly, financial and health
data) can become a significant barrier to the wide adoption of cloud services. To
address this problem, in this paper, we propose a novel highly decentralized in-
formation accountability framework to keep track of the actual usage of the users’
data in the cloud. In particular, we propose an object-centered approach that en-
ables enclosing our logging mechanism together with users’ data and policies. We
leverage the JAR programmable capabilities to both create a dynamic and traveling
object, and to ensure that any access to users’ data will trigger authentication and
automated logging local to the JARs. To strengthen user’s control, we also provide
distributed auditing mechanisms. We provide extensive experimental studies that
demonstrate the efficiency and effectiveness of the proposed approaches.
1.3 Problem Definition Project Objectives, Goal:
Existing System
Internet on an as- needed basis. A major feature of the cloud services is that users’
operate.While enjoying the convenience brought by this new emerging technology,
data) can become a significant barrier to the wide adoption of cloud services.

Proposed System
In this paper, we propose a novel highly decentralized information accountabil-
ity framework to keep track of the actual usage of the users’ data in the cloud.
In particular, we propose an object-centered approach that enables enclosing our
logging mechanism together with users’ data and policies. We leverage the JAR
programmable capabilities to both create a dynamic and traveling object, and to
ensure that any access to users’ data will trigger authentication and automated log-
ging local to the JARs. To strengthen user’s control, we also provide distributed
auditing mechanisms. We provide extensive experimental studies that demonstrate
the efficiency and effectiveness of the proposed approaches.
1.4 Applying software engineering approach:
We follow software engineering ’Waterfall Model’ approach. According that Software
development take place in five step as follow:
1. Communication
The communication take place between we and our project guide. We com-
municate project feasibility, requirements. This take one two week.
2. Planning
In planning we plan Project Estimation. We plan Software Project Estimation,
as Estimating size near 20Gb,Estimating Effort ,Estimating Schedule project
completing upto February and Estimating Cost upto Rs.10,000 as we develop
project on cloud.
3. Modeling
We model project by following Algorithms:
Algorithms
• RSA Algorithm for encryption and decryption of data which we are going
to store in the jar file.
• Algorithm for Openssl authentication.
• Algorithm for Log files Transfer.
• Algorithm to find correct Inner Jar.

4. Construction
Module 1:
GUI design of the project and RSA algorithm implementation for data en-
cryption and decryption.
Module 2:
Extracting the jar ﬁles which have been created when data owner had uploaded
his data and decryption of that data.
Module 3:
Creating the space on cloud and according to user access control policies al-
lowing the user to access uploaded data.
Module 4:
Finalizing all the requirements such as timed access, giving the special access
over the data to the paid user, sending the generated log to the data owner.
5. Deployment
After completing project we deliver after February we take feedback and ac-
cording o feedback we release next version of this application.

Ensuring Distributed Accountability Literature Survey
2.1 Literature Survey:
Paper Name:Ensuring Distributed Accountability for Data Sharing in the Cloud
Author(s): Smitha Sundareswaran, Anna C. Squicciarini, Member, IEEE, and
Dan Lin
Other Details: IEEE Transaction On Dependable And Secure Computing, Vol.
9, No. 4, July/August 2012
Year: - 2012
Abstract:
Ensuring distributed accountability for data sharing in the cloud is in short
nothing but a novel highly decentralized information accountability framework to
keep track of the actual usage of the users’ data in the cloud. Cloud computing
enables highly efficient services that are easily consumed over the internet. One of
the important and foremost feature of the cloud is user’s data can be operated or
processed in any of the unknown machines that user personally do not own. The
feasibility which has occurred due to the new emerging technology user fear of losing
the hold on their personal data lets say financial or health related. And this can
become an obstruction to the wide adoption of services provided by cloud. Our
proposed approach is Object-centered approach which enables enclosing our logging
mechanisms together with user’s data and respective policies. Using the JAR pro-
grammable capacities to both create a dynamic and travelling object and also to
trigger the authentication and automated logging local to the JARs. And to make
more secure the user’s control we will be providing distributed auditing mechanisms.
2.2 Feasibility Study
The feasibility study is major factor which contributes to analysis of system. In
earlier stages of S/W development, it is necessary to check whether system is feasi-
ble or not. There are 4 aspects of checking feasibility. Detail study was carried out
to check workability of proposed system, so the feasibility study is system proposal
regarding to its workability, impact on organization, ability to meet user require-
ments and effective use of resources thus when application progresses, it normally
goes through a feasibility study and risk analysis.
Four key considerations are involved in feasibility analysis :
1. Economic Feasibility
2. Legal Feasibility
3. Time Feasibility

Ensuring Distributed Accountability Literature Survey
4. S/W and H/W Availability
2.2.1 Economical Feasibility:
System has been developed using resource S/W. Cost involved in deploying system,
such that there should be private cloud network is required. Beneﬁt of this product
will deﬁnitely outweigh its cost once system has been setup, we will get the reliability
function.
2.2.2 Legal Feasibility:
We shall be using licensed version of various development tools/software required.
Thus this project is legally feasible.
2.2.3 Time Feasibility:
There is a lot of learning curve to all the components involved in this project. The
project mainly deals with software. The time that will be required to do this project
is decided to be 6 months including the planning (that has already taken place). The
project is timed to be deployable in the last week of March. The total project is
feasible in terms of time.
2.2.4 S/W and H/W Availability:
The project requires Microsoft Windows based operating system and some software
tools that are easily available in the market for sale and it’s possible to request it
from the college as well. We can conclude that the software and hardware are easily
available and can be used as they are required.

Ensuring Distributed Accountability Project Plan
3.1 Plan
Task Description Duration
Literature Research 2012Ensuring Distributed Accountability July
Analysis Critical analysis and comparison of technologies August
studied and results achieved in research.
Design and Planning Divided into Module September
Module1 GUI design of the project and RSA algorithm Nov
implementation for data encryption and decryption.
Module2 Extracting the jar ﬁles which have been Dec
created when data owner had uploaded his data
and decryption of that data.
Module3 Creating the space on cloud and according Jan
to user access control policies allowing the user
to access uploaded data.
Module4 Finalizing all the requirements February
Testing Implement a test the system quality ﬁx errors Feb
if any and improve if needed.
Final Report Prepare and upload Final Report March

Schedule
No. Start Date Due Date Student Name Work Completed and
Pt.dicussed with guide
1 22/7 29/7 Suraj Mehta Project Search
Shreyas Tapale
Aakash Takale
Saily Konde
2 29/7 8/8 Suraj Mehta Requirement analysis and
Shreyas Tapale gathering
Aakash Takale
Saily Konde
3 8/8 16/8 Suraj Mehta Preliminary Documentation
Shreyas Tapale And Seminar
Aakash Takale
Saily Konde
4 24/9 25/10 Suraj Mehta Dessigning
Shreyas Tapale
Aakash Takale
Saily Konde
5 Nov Jan Suraj Mehta Coding
Shreyas Tapale
Aakash Takale
Saily Konde
6 Feb Feb Suraj Mehta Testing
Shreyas Tapale
Aakash Takale
Saily Konde
Table 3.1: Schedule

Priority
Quality Parameter Priority Statement of Req. Yes/No
Compatibility 1 Should be executes in expected time Yes
Completeness 1 Expected i/p should get relative and Yes
complete o/p
Correctness 2 Conversion should be eﬃcient Yes
Cost of ownership 1 Should be below1000 Yes
Environmental 1 Should not contribute to excess Yes
use of environmental harming
Extensibility 1 Advancement acceptable Yes
Installation Complexity 1 Easy installable in local machine Yes
Parallel Processing 3 Comcept of multitasking is utilized Yes
Performance 1 90per. of appl. should be converted Yes
Portability 1 Should be installable in various Yes
common platform
Regulatory 1 Supervise proper seq. execution Yes
Reusability 1 Main purpose is reusability Yes
Scalability 1 Should be expandable in features Yes
Security 1 Not excessible to external world so is safe Yes
Time to Market 1 Should be published in Apple store or Yes
android store by completion of this year
Training Complexity 1 Should be easy to learn and maintain Yes
Usability 1 Handy to use and execute Yes
Table 3.2: Priority

TASK START DATE DUE DATE PRIORITY
1) Pre-project discussion
regarding modules to be
developed and concepts 17 July 2013 19 July 2013 High
to be implemented in
planned system.
2) Detailed discussion on
scope of the project and 21July 2013 22July 2013 Medium
feasibility issues
regarding project.
3) Submission of abstract
and finalization of 23 July 2013 23 July 2013 High
topic.
4) Research on previously
developed system based
on same technology and 2 Aug 2013 4 Aug 2013 Medium
collection of research
papers.
5) Seminar. 8 Aug 2013 8 Aug 2013 High
6) Requirement gathering
and to learn the earlier 12 Aug 2013 16 Aug 2013 Medium
implemented technologies.
7) Collection and Analysis
of more research 19 Aug 2013 28 Aug 2013 Medium
papers.
8) Preparation of UML 29 Aug 2013 5 Sep 2013 High
diagrams.
9) Technical research on
different data
encryption methods and 6 Sep 2013 23 Sep 2013 High
working on different
technologies.
10) Preparation of critique
on different research 24 Sep 2013 30 Sep 2013 Low
papers that are being
referred.

Ensuring Distributed Accountability SRS
4.1 Introduction:
4.1.1 Purpose:
Cloud computing is a technology which uses internet and remote servers to store
data and application. In cloud there is no need to install particular hardware, soft-
ware on user machine, so user can get the required infrastructure on his machine in
cheap charges/rates. Cloud computing is an infrastructure which provides useful, on
demand network services to use various resources with less effort. Features of cloud
computing are huge access of data, application, resources and hardware without
installation of any software, user can access the data from any machine or anywhere
in the world, business can get resource in one place, that means cloud computing
provides scalability in on demand services to the business users. To date, there are
a number of notable commercial and individual cloud computing services, includ-
ing Amazon, Google, Microsoft, Yahoo, and Salesforce. Clouds in general provide
services at three different levels (IaaS, PaaS, and Saas) as follows, although some
providers can choose to expose services at more than one level.
Everyone kept their data in cloud, as everyone kept their data in cloud so it
becomes public so security issue increases towards private data. Data usage in cloud
is very large by users and businesses, so data security in cloud is very important
issue to solve. Many users want to do business of his data through cloud, but users
may not know the machines which actually process and host their data. While
enjoying the convenience brought by this new technology, users also start worrying
about losing control of their own data.
Under the Database as a service, this is having four parts which are as per
mentioned below:
• Encryption and Decryption - For security purpose of data stored in cloud,
encryption seems to be perfect security solution.
• Key Management - If encryption is necessary to store data in the cloud, en-
cryption keys can’t be store their, so user requires key management.
• Authentication - For accessing stored data in cloud by authorized users.
• Authorization - Rights given to user as as cloud provider.
To solve the security issues in cloud; other user can’t read the respective user’s data
without having access. Data owner should not bother about his data, and should
not get fear about damage of his data by hacker; there is need of security mechanism
which will track usage of data in the cloud. Accountability is necessary for monitor-
ing data usage, in this all actions of users like sending of file are cryptographically
linked to the server, that performs them and server maintain secured record of all

the actions of past and server can use the past records to know the correctness of ac-
tion. It also provides reliable information about usage of data and it observes all the
records, so it helps in make trust, relationship and reputation. So accountability is
for verification of authentication and authorization. It is powerful tool to check the
authorization policies .Accountability describes authorization requirement for data
usage policies. Accountability mechanisms, which rely on after the fact verification,
are an attractive means to enforce authorization policies.
There are 7 phases of accountability
1. Policy setting with data
2. Use of data by users
3. Logging
4. Merge logs
5. Error correctness in log
6. Auditing
7. Rectify and improvement.
These phases may change as per framework.
First the data owner will set the policies with data and send it to cloud service
provider (CSP), data will be use by users and logs of each record will be created,
then log will be merged and error correction in log has been done and in auditing
logs are checked and in last phase improvement has been done.
4.1.2 Project Scope
In project we need to define the scope of the project , we have divide the whole
project in tow four modules. These are following
Module 1
GUI design of the project and RSA algorithm implementation for data encryption
and decryption.
Module 2
Extracting the jar files which have been created when data owner had uploaded his
data and decryption of that data.

Module 3
Creating the space on cloud and according to user access control policies allowing
the user to access uploaded data.
Module 4
Finalizing all the requirements such as timed access, giving the special access over
the data to the paid user, sending the generated log to the data owner.
4.1.3 Product Features
1. Jar Creation using RSA key.
2. Making Jar Access.
3. Making Authentication request to the cloud service provider.
4. In the Authentication request cloud service provider will give authentication
response.
5. Then encrypted logging will be done.
6. After that Certificate Revocation List (CRL) verification will be done with
certificate authorities.
7. Then we will send merged log to the user.

4.1.4 Use classes and characteristics
Use case Diagram
Figure 4.1: Use Case Diagram
List of actors and their details
Data Owner- 1st privilege.
Cloud Service Provider- 2nd privilege.
Certificate - 3rd privilege.
User-4th privilege.
Database- Cloud.
Use case description
The purpose of use case diagram is to capture the dynamic aspect of a system. Use
case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. So
when a system is analysed to gather its functionalities use cases are prepared and
actors are identified.
Preconditions
Distributed Accountability having four prioritized accounts, namely Data Owner,Cloud
Service Provider,Certificate,User.
Data Owner as system 1 adds a new data.
Cloud Serivce Provider as system 2 has to provide data storage space to data owner.
Certificate as system 3 has give certificate to data owner and user as he autherizied.

User as system 4 has use data owners data.
System Feature
ID 1
Description Overall System
Actors Data Owner,Cloud Service,Certificate,User,Database
Preconditions Data owner has store and share data with users.
Basic Steps Store data,share data,autherized users,provide security,security alters.
Exceptions If user is not share data,he is not aturized.
Table 4.1: System Features
4.1.5 Operating Environment
• Operating System : -windows XP/Window Vista/Windows 7.
• Development End(Programming Languages):- Java
• Platform: Java.
4.1.6 Design and Implementation constraints
• We are going to use Private cloud in this project.
• Private cloud: Here we are using 3-4 machines to form a cloud. One machine
will be the server and others will be client. Client will send the request and
server will process that request.
4.1.7 Assumptions and Dependencies
Before doing the setup on cloud we have to test our project on server. then after
checking its functionality we will create setup on cloud. Here we are assuming that
one machine will be server and others will be client.
4.2 System Features
The Functional Requirement document (also called Functional Specifications or
Functional Requirement Specifications), document the operations and activities that
a system must be able to perform.

Functional Requirements should include:
• Descriptions of data to be entered into the system
• Descriptions of operations performed by each screen
• Descriptions of work-ﬂows performed by the system
• Descriptions of system reports or other outputs
• Who can enter the data into the system.
• How the system meets applicable regulatory requirements
The functional speciﬁcation is designed to be read by a general audience. Readers
should understand the system, but no particular technical knowledge should be
required to understand the document.
4.3 External Interface Requirements
4.3.1 User Interface
User Interface can be done at the time of implementation, so we need to add here
screen shots of the GUI prepared.
4.3.2 Hardware Interfaces
• Processor : -PIV- 500 MHz to 3.0 GHz.
• RAM : - 1GB/above
• Hard Disk : -20 GB/above
• We will require 3-4 machines for cloud formation.
4.3.3 Software Interfaces
• Operating System : -windows XP/Window Vista/Windows 7.
• Development End(Programming Languages):- Java
• Platform: Java.

4.4 Non Functional Requirements
4.4.1 Performance Requirements
Performance details the way the system will perform for users. Think about:
• What is the response time for reports, queries, and updates?
• What is the total number of user sessions open for the entire application?
• What is the total number of concurrent sessions that can be opened by a single
user?
• What is the total amount of idle time before the user session is forced to
terminate?
4.4.2 Safety Requirements
For these requirements we are using antivirus in our machine to machine crash. Also
we are going to use login registration for the new user.
4.4.3 Software Quality Attributes
Our system will be user friendly, good performance and time consuming.
4.4.4 Security Requirements
We are going to use login registration for the new user.

4.5 System Analysis Model
4.5.1 Use Case Diagram:
Figure 4.2: Use Case Diagram

4.5.2 Class Diagram:
Figure 4.3: Class Diagram

Ensuring Distributed Accountability System Design
5.1 System Architecture and Business Logic:
Figure 5.1: System Architecture and Business Logic

5.2 UML Diagram
1. Sequence Diagram
Figure 5.2: Sequence Diagram

2. Activity Diagram for Data Owner
Figure 5.3: Activity Diagram

Figure 5.4: Activity Diagram2
5.3 Component and Deployment Diagram

Figure 5.5: Component Diagram
Figure 5.6: Deployment Diagram

Chapter 6
Technical Speciﬁcation

Ensuring Distributed Accountability Technical Specification
6.1 Technology details to be used in the project
CLOUD computing presents a new way to supplement the current consumption and
delivery model for IT services based on the Internet, by providing for dynamically
scalable and often virtualized resources as a service over the Internet.
We propose a novel automatic and enforceable logging mechanism in the cloud.
To our knowledge, this is the first time a systematic approach to data accountability
through the novel usage of JAR files is proposed.
. Our proposed architecture is platform independent and highly decentralized,
in that it does not require any dedicated authentication or storage system in place.
. We go beyond traditional access control in that we provide a certain degree of
usage control for the protected data after these are delivered to the receiver.
. We conduct experiments on a real cloud testbed. The results demonstrate the
efficiency, scalability, and granularity of our approach. We also provide a detailed
security analysis and discuss the reliability and strength of our architecture.
6.2 References to Technology
• Cloud service provider (CSP).
• Cloud Information Accountability (CIA).
• Java Running Environment (JRE).
• Identity-Based Encryption (IBE).
• Proof-Carrying authentication (PCA).

Ensuring Distributed Accountability Conclusion
Conclusion
We proposed innovative approaches for automatically logging any access to the
data in the cloud together with an auditing mechanism. Our approach allows the
data owner to not only audit his content but also enforce strong back-end protection
if needed. Moreover, one of the main features of our work is that it enables the data
owner to audit even those copies of its data that were made without his knowledge.
In the future, we plan to reﬁne our approach to verify the integrity of the JRE and
the authentication of JARs . For example, wewill investigate whether it is possible
to leverage the notion of a secure JVM being developed by IBM. This research is
aimed at providing software tamper resistance to Java applications. In the long
term, we plan to design a comprehensive and more generic object-oriented approach
to facilitate autonomous protection of traveling content. We would like to support
a variety of security policies, like indexing policies for text ﬁles, usage control for
executables, and generic accountability and provenance controls.

Ensuring Distributed Accountability References
Ensuring Distributed Accountability for Data Sharing in the Cloud.
1. P. Ammann and S. Jajodia, ”Distributed Timestamp Generation in Planar
Lattice Networks,” ACM Trans. Computer Systems, vol. 11, pp. 205-225,
Aug. 1993.
2. G. Ateniese, R. Burns, R. Curtmola, J. Herring, L. Kissner, Z. Peterson, and
D. Song, ”Provable Data Possession at Untrusted Stores,” Proc. ACM Conf.
Computer and Comm. Security, pp. 598-609, 2007.
3. E. Barka and A. Lakas, ”Integrating Usage Control with SIP-Based Commu-
nications,” J. Computer Systems, Networks, and Comm., vol. 2008, pp. 1-8,
2008.
4. D. Boneh and M.K. Franklin, ”Identity-Based Encryption from the Weil Pair-
ing,” Proc. Int’l Cryptology Conf. Advances in Cryptology, pp. 213-229,
2001.
5. R. Bose and J. Frew, ”Lineage Retrieval for Scientiﬁc Data Processing: A
Survey,” ACM Computing Surveys, vol. 37, pp. 1- 28, Mar. 2005.
6. P. Buneman, A. Chapman, and J. Cheney, ”Provenance Manage- ment in
Curated Databases,” Proc. ACM SIGMOD Int’l Conf. Management of Data
(SIGMOD ’06), pp. 539-550, 2006.
7. B. Chun and A.C. Bavier, ”Decentralized Trust Management and Account-
ability in Federated Systems,” Proc. Ann. Hawaii Int’l Conf. System Sciences
(HICSS), 2004.
8. OASIS Security Services Technical Committee, ”Security Assertion Markup
Language (saml) 2.0,” http://www.oasis-open.org/ committees/tc home.php?wg
abbrev=security, 2012.
9. R. Corin, S. Etalle, J.I. den Hartog, G. Lenzini, and I. Staicu, ”A Logic for
Auditing Accountability in Decentralized Systems,” Proc. IFIP TC1WG1.7
Workshop Formal Aspects in Security and Trust, pp. 187-201, 2005.
10. B. Crispo and G. Ruﬀo, ”Reasoning about Accountability within Delegation,”
Proc. Third Int’l Conf. Information and Comm. Security (ICICS), pp. 251-
260, 2001.

Ensuring Distributed Accountability Appendix A
Mathematical Models and Identified Functional decomposition
A.1 Mathematical Model (Venn Diagram, Set representation of the
scope, any mathematical formula)
Ensuring Distributed Data Accountablity for Data Sharing in cloud
1.Problem Statement:
Internet on an as-needed basis. A major feature of the cloud services is that users’
operate. While enjoying the convenience brought by this new emerging technology,
data) can become a significant barrier to the wide adoption of cloud services.
2.Mathematical Module:
Let S be the proposed System S={Logger, IJ, OJ, LF, encrypted data, class files,
LR, Log Harmonizer, pull(LR), push(LR), access log, pure log, master Index}
1. Logger = {IJ, OJ, LF }
IJ is the Inner-JAR
OJ is Outer-JAR
LF are the corresponding log files
2. IJ=encrypted data, ICF1, ICF2, ICF3, LF, public key
ICF1 is a class file for writing the log records
ICF2 is another class file which corresponds with the log harmonizer
ICF3 is a third class file for displaying or downloading the data public key of
the IBE key pair for encrypting the log records
3. OJ =IJ, OCF1, OCF2, OCF3, OCF4
OCF1 is a class file for authenticating the servers or the users
OCF2 is another class file finding the correct inner JAR,
OCF3 is a third class file which checks the JVM’s validity,
OCF4 is a class file is used for managing the GUI
4. Log Record
LR=(r1,..,rk) Where ri = (ID, Act, T, Loc, h((ID, Act, T, Loc) —ri - 1
——r1),sig) Here, ri indicates that an entity identified by I D has performed
an action Act on the user’s data at time T at location Loc. The component

h((ID, Act, T, Loc) —ri - 1 ——r1) corresponds to the checksum of the records
preceding the newly inserted one, concatenated with the main content of the
record itself. The component sig denotes the signature of the record created
by the server.
5. Log harmonizer = CFs, error correction information, user’s IBE decryption
key CFs are class files for both a server and a client processes to allow it to
communicate with its logger components
6. push(LR) - The logs are periodically pushed to the data owner (or auditor)
by the harmonizer.
7. pull(LR) - It allows auditors to retrieve the logs anytime when they want to
check the recent access to their own data.
8. Pure Log- record every access to the data
9. Access Log - It has two main tasks logging actions and enforcing access
control.
10. master Index - It is the master file, which is created for performing indexing on
the JAR files. The master file will contain an every JAR file which is present
on the cloud.
The structure of master file will be as follows
master Index = { name of file, type of data, name of OuterJAR, name of
InnerJAR}
3. NP hard or NP complete:
Our project comes into the NP complete. Our project comes into NP complete
because in particular time it will give the result. For the decision problem, so that
it will give the solution for the problem within polynomial time. The set of all
decision problems whose solution can be provided into polynomial time by using the
given algorithm.
A.2 Functional Decomposition of the system ( list the functional
decomposition of the system, and support it with the diagram)
For this project Before doing the setup on cloud we have to test our project on
server. then after checking its functionality we will create setup on cloud. we are
assuming that one machine will be server and others will be client.
Input: Data Which data owner have to upload
Output: Displaying data to the user which data owner has uploaded
Success: Successful formation of outer jar and extraction of that jar
Failure: User Unable to see the data

System Flow Diagram :
Figure 9.1: System Flow Diagram

Ensuring Distributed Accountability Appendix B
Testing / Reliability of Design
B.1 Test Plan for Desgin
System Testing
The purpose of testing is to discover errors. Testing is the process of trying to
discover every conceivable fault or weakness in a work product. It provides a way to
check the functionality of components, sub assemblies, assemblies and/or a finished
product It is the process of exercising software with the intent of ensuring that the
Software system meets its requirements and user expectations and does not fail in
an unacceptable manner. There are various types of test. Each test type addresses
a specific testing requirement.
Types Of Tests
Unit Testing
Unit testing involves the design of test cases that validate that the internal program
logic is functioning properly, and that program inputs produce valid outputs. All
decision branches and internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the completion of an
individual unit before integration. This is a structural testing, that relies on knowl-
edge of its construction and is invasive. Unit tests perform basic tests at component
level and test a specific business process, application, and/or system configuration.
Unit tests ensure that each unique path of a business process performs accurately
to the documented specifications and contains clearly defined inputs and expected
results.
Integration Testing
Integration tests are designed to test integrated software components to determine
if they actually run as one program. Testing is event driven and is more concerned
with the basic outcome of screens or fields. Integration tests demonstrate that al-
though the components were individually satisfaction, as shown by successfully unit
testing, the combination of components is correct and consistent. Integration testing
is specifically aimed at exposing the problems that arise from the combination of
components.
Functional Test
Functional tests provide systematic demonstrations that functions tested are avail-
able as specified by the business and technical requirements, system documentation,
and user manuals.
Functional testing is centered on the following items:
Valid Input identified classes of valid input must be accepted.

Invalid Input identified classes of invalid input must be rejected.
Functions identified functions must be exercised.
Output identified classes of application outputs must be exercised.
Systems Procedures interfacing systems or procedures must be invoked.
Organization and preparation of functional tests is focused on requirements, key
functions, or special test cases. In addition, systematic coverage pertaining to iden-
tify Business process flows; data fields, predefined processes, and successive processes
must be considered for testing. Before functional testing is complete, additional tests
are identified and the effective value of current tests is determined.
System Test
System testing ensures that the entire integrated software system meets require-
ments. It tests a configuration to ensure known and predictable results. An exam-
ple of system testing is the configuration oriented system integration test. System
testing is based on process descriptions and flows, emphasizing pre-driven process
links and integration points.
White Box Testing
White Box Testing is a testing in which in which the software tester has knowledge
of the inner workings, structure and language of the software, or at least its purpose.
It is purpose. It is used to test areas that cannot be reached from a black box level.
Black Box Testing
Black Box Testing is testing the software without any knowledge of the inner work-
ings, structure or language of the module being tested. Black box tests, as most
other kinds of tests, must be written from a definitive source document, such as
specification or requirements document, such as specification or requirements doc-
ument. It is a testing in which the software under test is treated, as a black box
.you cannot ”see” into it. The test provides inputs and responds to outputs without
considering how the software works.
B.2 Details of Design Testing
Unit Testing:
Unit testing is usually conducted as part of a combined code and unit test phase of
the software lifecycle, although it is not uncommon for coding and unit testing to
be conducted as two distinct phases.
Test Strategy and approach
Field testing will be performed manually and functional tests will be written in
detail.

Test Objectives
• All field entries must work properly.
• Pages must be activated from the identified link.
• The entry screen, messages and responses must not be delayed.
Features to be tested
• Verify that the entries are of the correct format
• No duplicate entries should be allowed
• All links should take the user to the correct page.
Integration Testing
Software integration testing is the incremental integration testing of two or more
integrated software components on a single platform to produce failures caused by
interface defects. The task of the integration test is to check that components or
software applications, e.g. components in a software system or - one step up - soft-
ware applications at the company level - interact without error.
Test Results: All the test cases mentioned above passed successfully. No de-
fects encountered.
Acceptance Testing
User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

Ensuring Distributed Accountability Appendix C
Testing / Reliability of Design
C.1 Project Management Approach (Roles and Responsibilities)
Software Development Life cycle.
There are various software development approaches deﬁned and designed which are
used/employed during development process of software, these approaches are also
referred as ”Software Development Process Models” (e.g. Waterfall model, model,
iterative model, Agile development etc.). Each process model follows a particular
life cycle in order to ensure success in process of software development. Software
life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase
in the life cycle. Requirements are translated into design. Code is produced accord-
ing to the design which is called development phase. After coding and development
the testing veriﬁes the deliverable of the implementation phase against requirements.
Agile Development:
There are following six phases in every Software development life cycle model in
Agile Methodology.:
Figure 11.1: Agile Development
1. Requirement gathering and analysis
2. Design
3. Implementation or coding

4. Testing
5. Deployment
6. Maintenance
Requirement gathering and analysis:
Business requirements are gathered in this phase. This phase is the main focus of
the project managers and stake holders. Meetings with managers, stake holders and
users are held in order to determine the requirements like; Who is going to use the
system? How will they use the system? What data should be input into the system?
What data should be output by the system? These are general questions that get
answered during a requirements gathering phase. After requirement gathering these
requirements are analyzed for their validity and the possibility of incorporating the
requirements in the system to be development is also studied. Finally, a Require-
ment Specification document is created which serves the purpose of guideline for the
next phase of the model.
Design:
In this phase the system and software design is prepared from the requirement spec-
ifications which were studied in the first phase. System Design helps in specifying
hardware and system requirements and also helps in defining overall system architec-
ture. The system design specifications serve as input for the next phase of the model.
Implementation and Coding:
On receiving system design documents, the work is divided in modules/units and
actual coding is started. Since, in this phase the code is produced so it is the main
focus for the developer. This is the longest phase of the software development life
cycle.
Testing:
After the code is developed it is tested against the requirements to make sure that
the product is actually solving the needs addressed and gathered during the require-
ments phase. During this phase unit testing, integration testing, system testing,
acceptance testing are done.
Deployment:
After successful testing the product is delivered / deployed to the customer for their
use.

Maintenance:
Once when the customers starts using the developed system then the actual prob-
lems comes up and needs to be solved from time to time. This process where the
care is taken for the developed product is known as maintenance.
C.2 Status of Project Work done
WORK DONE STATUS
1)Requirement gathering Done
2)On ﬁeld survey Done
3)Literature survey Done
4)Technical research Done
5)Designing of block diagram Done
6)Designing of UML architecture Done
7)Study of Quality Parameter Done
Table 11.1: Status of Project

Ensuring Distributed Accountability in the Cloud

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (8)

Destacado

Destacado (20)

Similar a Ensuring Distributed Accountability in the Cloud

Similar a Ensuring Distributed Accountability in the Cloud (20)

Último

Último (20)

Ensuring Distributed Accountability in the Cloud