Strategies for Landing an Oracle DBA Job as a Fresher
KEY AGGREGATE CRYPTOSYSTEM FOR SCALABLE DATA SHARING IN CLOUD
1. B. Tech Project Report
KEY AGGREGATE CRYPTOSYSTEM FOR SCALABLE DATA
SHARING IN CLOUD
Submitted in partial fulfillment for the award of the Degree of
Bachelor of Technology in Computer Science and Engineering
Department of Computer Science and Engineering
MES INSTITUTE OF TECHNOLOGY AND MANAGEMENT
CHATHANNOOR, KOLLAM
KERALA
2. ABSTRACT
Data sharing is an important functionality in cloud storage. In this paper,
we show how to securely, efficiently, and flexibly share data with others in cloud
storage. We describe new public-key cryptosystems which produce constant-size
ciphertexts such that efficient delegation of decryption rights for any set of
ciphertexts are possible. The novelty is that one can aggregate any set of secret keys
and make them as compact as a single key, but encompassing the power of all the
keys being aggregated. In other words, the secret key holder can release a constant-
size aggregate key for flexible choices of ciphertext set in cloud storage, but the
other encrypted files outside the set remain confidential. This compact aggregate key
can be conveniently sent to others or be stored in a smart card with very limited
secure storage. We provide formal security analysis of our schemes in the standard
model. We also describe other application of our schemes. In particular, our
schemes give the first public-key patient-controlled encryption for flexible
hierarchy, which was yet to be known.
3. CONTENTS
CHAPTERNO: TITLE PAGE NO:
List of Abbreviations iii
List of Figures iv
1 INTRODUCTION 01
2 LITERATURE SURVEY 03
2.1 EASiER 03
2.2 MULTI-AUTHORITY 04
ATTRIBUTE BASED
ENCRYPTION
2.3 DISTRIBUTED ACCESS 04
CONTROL IN CLOUDS
2.4 IMPROVING PRIVACY AND 05
SECURITY IN
MULTIAUTHORITY
ATTRIBUTE-BASED
ENCRYPTION
2.5 SCALABLE AND SECURE 06
SHARING OF PERSONAL
HEALTH RECORDS IN CLOUD
COMPUTING USING
ATTRIBUTE-BASED
ENCRYPTION
3 EXISTING SYSTEM 08
4 PROPOSED SYSTEM 09
4.1 PROBLEM STATEMENT 11
5 REQUIREMENT 12
SPECIFICATION
5.1 HARDWARE REQUIREMENTS 12
4. 5.2 SOFTWARE REQUIREMENTS 12
5.2.1 Microsoft Visual Studio 2010 12
5.2.2 Architecture 13
5.2.3 Features 14
6 SYSTEM DESIGN 15
6.1 MODULES 15
6.1.1 Setup Phase 15
6.1.2 Encrypt Phase 15
6.1.3 Key Gen Phase 15
6.1.4 Decrypt Phase 16
6.1.5 User Management 16
6.1.6 Data Management 16
7 IMPLEMENTATION 17
7.1 FRAMEWORK 17
7.2 SHARING ENCRYPTED DATA 18
7.3 PERFORMANCE ANALYSIS 19
7.3.1 Performance of Our Proposed 20
Schemes
7.4 DATAFLOW DIAGRAMS 22
8 ALGORITHMS USED 25
8.1 8.1 AES ALGORITHM 25
8.1.1 The Origins Of Aes 25
8.1.2 Basic Concept Of The Algorithm 25
9 SCREENSHOTS 31
10 ADVANTAGES 36
11 FUTURE SCOPE 37
12 CONCLUSION 38
REFERENCES 39
5. List of Abbreviations
EASiER - Encryption-based Access Control in Social Networks with
Efficient Revocation
ABE - attribute based encryption
KDCs - key distribution centers
DACC - Distributed Access Control in Clouds
PHR - Personal health record
KAC - aggregate cryptosystem KAC
MPF - Managed Package Framework
PK - public key
MK - master key
AES - Advanced Encryption Standard
6. List of Figures
Figure No: Title Page No:
4.1 Alice shares files with identifiers 2, 09
3, 6 and 8 with Bob by sending him
a single aggregate key.
7.1 Using KAC for data sharing in cloud 18
storage
7.2 Admin login 22
7.3 User request and response 23
7.4 Admin Operations 23
7.5 User Upload data 24
8.1 Aes Algorithm Structure 26
8.2 Structure of key and the state 27
8.3 Expanding first column of next 29
round key
9.1 User registration form 31
9.2 User login 31
9.3 User file upload 32
9.4 Admin login 32
9.5 Admin file upload to cloud 33
9.6 user request file 33
9.7 User respond 34
9.8 Decrypt Key In Mail 34
9.9 Owner respond 35
7. a
CHAPTER 1
INTRODUCTION
Cloud storage is gaining popularity recently. In enterprise settings, we see the rise in
demand for data outsourcing, which assists in the strategic management of corporate data. It
is also used as a core technology behind many online services for personal applications.
Nowadays, it is easy to apply for free accounts for email, photo album, file sharing and/or
remote access, with storage size more than 25GB (or a few dollars for more than 1TB).
Together with the current wireless technology, users can access almost all of their files and
emails by a mobile phone in any corner of the world.
Considering data privacy, a traditional way to ensure it is to rely on the server to
enforce the access control after authentication, which means any unexpected privilege
escalation will expose all data. In a shared-tenancy cloud computing environment, things
become even worse. Data from different clients can be hosted on separate virtual machines
(VMs) but reside on a single physical machine. Data in a target VM could be stolen by
instantiating another VM co-resident with the target one. Regarding availability of files,
there are a series of cryptographic schemes which go as far as allowing a third-party auditor
to check the availability of files on behalf of the data owner without leaking anything about
the data, or without compromising the data owners anonymity. Likewise, cloud users
probably will not hold the strong belief that the cloud server is doing a good job in terms of
confidentiality. A cryptographic solution, with proven security re-lied on number-theoretic
assumptions is more desirable, whenever the user is not perfectly happy with trusting the
security of the VM or the honesty of the technical staff. These users are motivated to encrypt
their data with their own keys before uploading them to the server. Data sharing is an
important functionality in cloud storage.
For example, bloggers can let their friends view a subset of their private pictures; an
enterprise may grant her employees access to a portion of sensitive data. The challenging
problem is how to effectively share encrypted data. Of course users can download the
encrypted data from the storage, decrypt them, then send them to
others for sharing, but it loses the value of cloud storage. Users should be able to delegate the
access rights of the sharing data to others so that they can access these data from the server
8. directly. However, finding an efficient and secure way to share partial data in cloud storage
is not trivial.
Assume that Alice puts all her private photos on Dropbox, and she does not want to
expose her photos to everyone. Due to various data leakage possibility Alice cannot feel
relieved by just relying on the privacy protection mechanisms provided by Dropbox, so she
encrypts all the photos using her own keys before uploading. One day, Alice’s friend, Bob,
asks her to share the photos taken over all these years which Bob appeared in. Alice can then
use the share function of Dropbox, but the problem now is how to delegate the decryption
rights for these photos to Bob. A possible option Alice can choose is to securely send Bob
the secret keys involved. Naturally, there are two extreme ways for her under the traditional
encryption paradigm. Encryption keys also come with two flavors — symmetric key or
asymmetric (public) key. Using symmetric encryption, when Alice wants the data to be
originated from a third party, she has to give the encryptor her secret key; obviously, this is
not always desirable. By contrast, the encryption key and decryption key are different in
public-key encryption. The use of public-key encryption gives more flexibility for our
applications. For example, in enterprise settings, every employee can up-load encrypted data
on the cloud storage server without the knowledge of the company’s master-secret key.
9. CHAPTER 2
LITERATURE SURVEY
2.1 EASiER: Encryption-based Access Control in Social Networks with Efficient
Revocation
A promising approach to mitigate the privacy risks in Online Social Networks
(OSNs) is to shift access control enforcement from the OSN provider to the user by means
of encryption. However, this creates the challenge of key management to support complex
policies involved in OSNs and dynamic groups. To address this, we propose EASiER, an
architecture that supports fine-grained access control policies and dynamic group
membership by using attribute-based encryption. A key and novel feature of our
architecture, however, is that it is possible to remove access from a user without issuing new
keys to other users or re-encrypting existing cipher texts. We achieve this by creating a
proxy that participates in the decryption process and enforces revocation constraints. The
proxy is minimally trusted and cannot decrypt cipher texts or provide access to previously
revoked users. We describe EASiER architecture and construction; provide performance
evaluation, and prototype application of our approach on Facebook. We propose EASiER
(Encryption-based Access Control in Social Networks with Efficient Revocation), an
architecture that supports fine-grained access control policies and dynamic group
membership by using attribute-based encryption. Persona is a state-of-the-art design that
proposes the use of attribute-based encryption (ABE) to enable fine-grained access control.
We present some basic mathematical assumptions, and some details of CP-ABE. We present
access control architecture for OSNs, named EASiER that supports efficient revocation in
ABE. We achieve this revocation scheme by introducing a minimally trusted proxy,
leveraging ideas from a group communication scheme, and combining it with ABE. In most
of the existing social network privacy architectures settings access control is performed via
encryption, but none of the schemes focus on the issue of efficient user or attribute
revocation. The existing revocation schemes have their limitations too.
2.2 MULTI-AUTHORITY ATTRIBUTE BASED ENCRYPTION
10. In an identity based encryption scheme, each user is identified by a unique identity
string. An attribute based encryption scheme (ABE), in contrast, is a scheme in which each
user is identified by a set of attributes, and some function of those attributes is used to
determine decryption ability for each cipher text. Sahai and Waters introduced a single
authority attribute encryption scheme and left open the question of whether a scheme could
be constructed in which multiple authorities were allowed to distribute attributes [SW05].
We answer this question in the affirmative. Our scheme allows any polynomial number of
independent authorities to monitor attributes and distribute secret keys. An encrypt or can
choose, for each authority, a number dk and a set of attributes; he can then encrypt a
message such that a user can only decrypt if he has at least dk of the given attributes from
each authority k. Our scheme can tolerate an arbitrary number of corrupt authorities. We
also show how to apply our techniques to achieve a multi-authority version of the large
universe fine grained access control ABE presented by Gopal et al. We also show how to
apply our techniques to achieve a multi-authority version of the large universe fine grained
access control ABE. Thus an adversary which breaks this encryption scheme with advantage
implies an algorithm for breaking the BDH Assumption with no negligible advantage. We
can conclude that this encryption scheme is sid-secure. One major limitation to the SW
scheme. In their scheme, as in every IBE scheme, the user must go to a trusted party and
prove his identity in order to obtain a secret key which will allow him to decrypt messages.
In this case, each user must go to the trusted server, prove that he has a certain set of
attributes, and then receive secret keys corresponding to each of those attributes.
2.3 DISTRIBUTED ACCESS CONTROL IN CLOUDS
We propose a new model for data storage and access in clouds. Our scheme avoids
storing multiple encrypted copies of same data. In our framework for secure data storage,
cloud stores encrypted data (without being able to decrypt them). The
main novelty of our model is addition of key distribution centers (KDCs). We propose DACC
(Distributed Access Control in Clouds) algorithm, where one or more KDCs distribute keys to
data owners and users. KDC may provide access to particular fields in all records. Thus, a single
key replaces separate keys from owners. Owners and users are assigned certain set of attributes.
Owner encrypts the data with the attributes it has and stores them in the cloud. The
11. users with matching set of attributes can retrieve the data from the cloud. We apply attribute-
based encryption based on bilinear pairings on elliptic curves. The scheme is collusion
secure; two users cannot together decode any data that none of them has individual right to
access. DACC also supports revocation of users, without redistributing keys to all the users
of cloud services. We show that our approach results in lower communication, computation
and storage overheads, compared to existing models and schemes. We propose DACC:
Distributed Access Control in Clouds, a new access control mechanism, where
owners decide on attributes that users should have and users receive decryption keys which
enable them to access records which they are authorized to access. We show that it performs
better than other proposed access control schemes for clouds. ABE was proposed by Sahai
and Waters. In ABE, a user has a set of attributes in addition to its unique ID. In DACC, the
cloud is assumed to be honest. If this requirement is not possible to satisfy, then care should
be taken, that the cloud does not modify the data that it contains. The main drawback of that
the size of the secret key is very large. The main drawback of is that the access policies are
restrictive.
2.4 IMPROVING PRIVACY AND SECURITY IN MULTI-AUTHORITY
ATTRIBUTE-BASED ENCRYPTION
Attribute based encryption (ABE) determines decryption ability based on a user’s
attributes. In a multi-authority ABE scheme, multiple attribute-authorities monitor different
sets of attributes and issue corresponding decryption keys to users and encrypts can require
that a user obtain keys for appropriate attributes from each
authority before decrypting a message. Chase gave a multi-authority ABE scheme using the
concepts of a trusted central authority (CA) and global identifiers (GID).
However, the CA in that construction has the power to decrypt every cipher text, which
seems somehow contradictory to the original goal of distributing control over many potentially
untrusted authorities. Moreover, in that construction, the use of a consistent GID allowed the
authorities to combine their information to build a full profile with all of a user’s attributes,
which unnecessarily compromises the privacy of the user. In this paper, we propose a solution
which removes the trusted central authority, and protects the users’ privacy by
12. preventing the authorities from pooling their information on particular users, thus making
ABE more usable in practice. We propose a solution which removes the trusted central
authority, and protects the users’ privacy by preventing the authorities from pooling their
information on particular users, thus making ABE more usable in practice. That approach
also has the advantage that any arbitrary string can be used as an attribute via the use of a
collision resistant hash function. The beauty of a PRF family is that no polynomial-time
adversary can distinguish (with significant advantage) between a randomly chosen function
and a truly random function. The scheme like the scheme we will present here has the
advantage that it does not rely on a central authority.
2.5 SCALABLE AND SECURE SHARING OF PERSONAL HEALTH RECORDS IN
CLOUD COMPUTING USING ATTRIBUTE-BASED ENCRYPTION
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
13. proposed scheme. There have been wide privacy concerns as personal health information
could be exposed to those third party servers and to unauthorized parties. Department of
Veterans Affairs database containing sensitive PHI of 26.5 million military veterans,
including their social security numbers and health problems was stolen by an employee who
took the data home without authorization.
14. CHAPTER 3
EXISTING SYSTEM
There exist several expressive ABE schemes where the decryption algorithm only
requires a constant number of pairing computations. Recently, Green et al. Proposed a
remedy to this problem by introducing the notion of ABE with outsourced decryption, which
largely eliminates the decryption overhead for users. Based on the existing ABE schemes
Green et al. Also presented concrete ABE scheme with outsourced decryption.
In this exisisting system, a user provides an untrusted server, say a proxy operated by a
cloud service provider with a transformation key TK that allows the latter to transfer any
ABE cipher text CT satisfied by that users attributes or access policies into a simple cipher
text CT and it only incurs a small overhead for the user to recover the plain text from
transformed cipher text CT. The security property of the ABE scheme with outsourced
decryption guarantees that an adversary ( including the malicious server) be not able to learn
anything about the encrypted message; however, the scheme provides no guarantee on the
correctness of the transformation done by the cloud server. In the cloud computing setting,
cloud service providers may have strong financial incentives to return incorrect answers, if
such answers requires less work and are unlikely detected by users.
15. CHAPTER 4
PROPOSED SYSTEM
The challenging problem is how to effectively share encrypted data. Of course users can
download the encrypted data from the storage, decrypt them, then send them to others for
sharing, but it loses the value of cloud storage. Users should be able to delegate the access rights
of the sharing data to others so that they can access these data from the server directly.
Fig 4.1: Alice shares files with identifiers 2, 3, 6 and 8 with Bob by sending him
a single aggregate key.
However, finding an efficient and secure way to share partial data in cloud storage is
not trivial. Below we will take Dropbox as an example for illustration. Assume that Alice
puts all her private photos on Dropbox, and she does not want to
16. expose her photos to everyone. Due to various data leakage possibility Alice cannot feel
relieved by just relying on the privacy protection mechanisms provided by Dropbox, so she
encrypts all the photos using her own keys before uploading. One day, Alice’s friend, Bob,
asks her to share the photos taken over all these years which Bob appeared in. Alice can then
use the share function of Dropbox, but the problem now is how to delegate the decryption
rights for these photos to Bob. A possible option Alice can choose is to securely send Bob
the secret keys involved. Naturally, there are two extreme ways for her under the traditional
encryption paradigm: Alice encrypts all files with a single encryption key and gives Bob the
corresponding secret key directly. Alice encrypts files with distinct keys and sends Bob the
corresponding secret keys. Obviously, the first method is inadequate since all unchosen data
may be also leaked to Bob.
For the second method, there are practical concerns on efficiency. The number of
such keys is as many as the number of the shared photos, say, a thousand. Transferring these
secret keys inherently requires a secure channel, and storing these keys requires rather
expensive secure storage. The costs and complexities involved generally increase with the
number of the decryption keys to be shared. In short, it is very heavy and costly to do that.
Encryption keys also come with two flavors symmetric key or asymmetric (public) key.
Using symmetric encryption, when Alice wants the data to be originated from a third party,
she has to give the encryptor her secret key; obviously, this is not always desirable. By
contrast, the encryption key and decryption key are different in public key encryption. The
use of public-key encryption gives more flexibility for our applications. For example, in
enterprise settings, every employee can up- load encrypted data on the cloud storage server
without the knowledge of the company’s master-secret key. Therefore, the best solution for
the above problem is that Alice encrypts files with distinct public-keys, but only sends Bob a
single (constant-size) decryption key. Since the decryption key should be sent via a secure
channel and kept secret, small key size is always desirable.
4.1 PROBLEM STATEMENT
“To design an efficient public-key encryption scheme which supports flexible delegation
in the sense that any subset of the ciphertexts (produced by the encryption scheme) is decryptable
by a constant-size decryption key (generated by the owner of the master-secret
17. key).” We solve this problem by introducing a special type of public-key encryption which
we call key aggregate cryptosystem (KAC). In KAC , users encrypt a message not only
under a public-key, but also under an identifier of ciphertext called class. That means the
ciphertexts are further categorized into different classes. The key owner holds a master-
secret called master-secret key, which can be used to extract secret keys for different classes.
More importantly, the extracted key have can be an aggregate key which is as compact as a
secret key for a single class, but aggregates the power of many such keys, i.e., the decryption
power for any subset of ciphertext classes. With our solution, Alice can simply send Bob a
single aggregate key via a secure e-mail. Bob can download the encrypted photos from
Alice’s Dropbox space and then use this aggregate key to decrypt these encrypted photos.
The sizes of ciphertext, public-key, master-secret key and aggregate key in our KAC
schemes are all of constant size. The public system parameter has size linear in the number
of ciphertext classes, but only a small part of it is needed each time and it can be fetched on
demand from large (but non-confidential) cloud storage. Previous results may achieve a
similar property featuring a constant-size decryption key, but the classes need to conform to
some pre-defined hierarchical relationship. Our work is flexible in the sense that this
constraint is eliminated, that is, no special relation is required between the classes
18. CHAPTER 5
REQUIREMENT SPECIFICATION
5.1 HARDWARE REQUIREMENTS
Processor - Pentium –IV.
Speed - 1.1 GHz.
RAM - 512 MB(min).
Hard Disk - 40 GB.
Key Board - Standard Windows Keyboard.
Mouse - Two or Three Button Mouse.
Monitor - LCD/LED.
5.2 SOFTWARE REQUIREMENTS
Front end : .Net
Back end : SQL Server
Operating System : Windows
IDE : Visual Studio
5.2.1 Microsoft Visual Studio 2010
Microsoft Visual Studio is an integrated development environment (IDE) from
Microsoft. It is used to develop console and graphical user interface applications along with
Windows Forms applications, web sites, web applications, and web services in both native
code together with managed code for all platforms supported by Microsoft Windows,
Windows Mobile, .NET Framework, .NET Compact Framework and Microsoft Silverlight.
Visual Studio includes a code editor supporting IntelliSense as well as code refactoring. The
integrated debugger works both as a source-level debugger and a machine-level debugger.
Other built-in tools include a
19. forms designer for building GUI applications, web designer, class designer, and database
schema designer. It accepts plug-ins that enhance the functionalityat almost every level
including adding support for source-control systems (like Subversion and Visual
SourceSafe) and adding new toolsets like editors and visual designers for domain-specific
languages or toolsets for other aspects of the software development life cycle (like the Team
Foundation Server client: Team Explorer).
Visual Studio supports different programming languages by means of language
services, which allow the code editor and debugger to support (to varying degrees) nearly
any programming language, provided a language-specific service exists. Built-in languages
include C/C++ (via Visual C++), VB.NET (via Visual Basic .NET), C# (via Visual C#), and
F# (as of Visual Studio 2010). Support for other languages such as M, Python, and Ruby
among others is available via language services installed separately. It also supports
XML/XSLT,HTML/XHTML, JavaScript and CSS. Individual language-specific versions of
Visual Studio also exist which provide more limited language services to the user: Microsoft
Visual Basic, Visual J#, Visual C#, and Visual C++. Microsoft provides "Express" editions
of its Visual Studio 2010 components Visual Basic, Visual C#, Visual C++, and Visual Web
Developer at no cost. Visual Studio 2010, 2008 and 2005 Professional Editions, along with
language-specific versions (Visual Basic, C++, C#, J#) of Visual Studio Express 2010 are
available for free to students as downloads via Microsoft's Dream Spark program.
5.2.2 Architecture
Visual Studio does not support any programming language, solution or tool
intrinsically, instead allows the plugging of functionality coded as a VS Package. When
installed, the functionality is available as a Service. The IDE provides three services:
SVsSolution, which provides the ability to enumerate projects and solutions; SVsUIShell,
which provides windowing and UI functionality (including tabs, toolbars and tool windows);
and SVsShell, which deals with registration of VS
Packages. In addition, the IDE is also responsible for coordinating and enabling
communication between services. All editors, designers, project types and other tools
are implemented as VS Packages. Visual Studio uses COM to access the VS Packages. The
Visual Studio SDK also includes the Managed Package Framework (MPF), which is a set of
20. managed wrappers around the COM-interfaces that allow the Packages to be written in any
language. However, MPF does not provide all the functionality exposed by the Visual
Studio COM interfaces. The services can then be consumed for creation of other packages,
which add functionality to the Visual Studio IDE.
5.2.3 Features
Visual Studio, like any other IDE, includes a code editor that supports syntax
highlighting code and using IntelliSense for not only variables, functions and methods but
also language constructs like loops and queries. IntelliSense is supported for the included
languages, as well as for XML and for Cascading Style Sheets and JavaScript when
developing web sites and web applications. Auto complete suggestions are popped up in a
modeless list box, overlaid on top of the code editor. The code editor is used for all
supported languages. The Visual Studio code editor also supports setting bookmarks in code
for quick navigation. Other navigational aids include collapsing code blocks and incremental
search, in addition to normal text search and regex search. The code editor also includes a
multi-item clipboard and a task list. The code editor supports code snippets, which are saved
templates for repetitive code and can be inserted into code and customized for the project
being worked on. A management tool for code snippets is built in as well. These tools are
surfaced as floating windows which can be set to automatically hide when unused or docked
to the side of the screen. Visual Studio features background compilation. As code is being
written, Visual Studio compiles it in the background in order to provide feedback about
syntax and compilation errors, which are flagged with a red wavy underline.
CHAPTER 6
SYSTEM DESIGN
6.1 MODULES
Setup Phase
Encrypt Phase
KeyGen Phase
Decrypt Phase
21. User Management Module
Data Management Module
6.1.1 Setup Phase
The setup algorithm takes no input other than the implicit security parameter. It
outputs the public parameters PK and a master key MK.
6.1.2 Encrypt Phase
Encrypt(PK,M, A). The encryption algorithm takes as input the public parameters
PK, a message M, and an access structure A over the universe of attributes. The algorithm
will encrypt M and produce a ciphertext CT such that only a user that possesses a set of
attributes that satisfies the access structure will be able to decrypt the message. We will
assume that the ciphertext implicitly contains A.
6.1.3 Key Gen Phase
Key Generation(MK,S). The key generation algorithm takes as input the master key
MK and a set of attributes S that describe the key. It outputs a private key SK.
6.1.4 Decrypt Phase
Decrypt(PK, CT, SK). The decryption algorithm takes as input the public parameters
PK, a ciphertext CT, which contains an access policy A, and a private key SK, which is a
private key for a set S of attributes. If the set S of attributes satisfies the access structure A
then the algorithm returns a message M.
6.1.5 User Management
This part of the module mainly deals with the users who are associated with the
proposed system. It is in this part of the module that the username
22. and password are checked before they can log into the system. The user management
module is also used for the management of the registered usere by the administrator. The
user management is the place where the administrator manages the GUI that helps the users
to easily use the system without difficulty. Here we implement the side that is directly in
contact with the users. A user is allowed to enter the system after authentication of that
particular user. The users of the system have to provide user name and password .If a
particular user is not in the login table, then he can’t access the system.
6.1.6 Data Management
The storage cloud is maintained by a third-party cloud provider (e.g., Amazon S3)
and keeps the data on behalf of the data owner. We emphasize that we do not require any
protocol and implementation changes on the storage cloud to support our system. Even a
naive storage service that merely provides file upload/download operations will be suitable.
23. CHAPTER 7
IMPLEMENTATION
7.1 FRAMEWORK
A key-aggregate encryption scheme consists of fivepolynomial-time algorithms as
follows.The data owner establishes the public system parameter via Setup and generates a
public/master-secret3 key pair via KeyGen. Messages can be encrypted via Encryptby
anyone who also decides what ciphertext class isassociated with the plaintext message to be
encrypted.The data owner can use the master-secret to generate an aggregate decryption key
for a set of ciphertext classes via Extract. The generated keys can be passed to delegatees
securely (via secure e-mails or secure devices) Finally, any user with an aggregate key can
decrypt any ciphertext provided that the ciphertext’s class is contained in the aggregate key
via Decrypt.
Setup: executed by the data owner to setup an account on an untrusted server. On input a
security level parameter 1_ and the number of ciphertext classes n (i.e., class index
should be an integer bounded by 1 and n), it outputs the public system parameter param,
which is omitted from the input of the other algorithms for brevity.
KeyGen: executed by the data owner to randomly generate a public/master-secret key
pair (pk; msk).
Encrypt: executed by anyone who wants to encrypt data. On input a public-key pk, an
index I denoting the ciphertext class, and a message m, it outputs a ciphertext C.
Extract: executed by the data owner for delegating the decrypting power for a certain set
of ciphertext classes to a delegatee. On input the mastersecret key msk and a set S of
indices corresponding to different classes, it outputs the aggregate key for set S denoted
by KS.
Decrypt : executed by a delegatee who received an aggregate key KS generated by
Extract. On input KS, the set S, an index i denoting the ciphertext class the ciphertext C
24. belongs to, and C, it outputs the decrypted result m if i €S.
7.2 SHARING ENCRYPTED DATA
A canonical application of KAC is data sharing. The key aggregation property is
especially useful when we expect the delegation to be efficient and flexible. The schemes
enable a content provider to share her data in a confidential and selective way, with a fixed
and small ciphertext expansion, by distributing to each authorized user a single and small
aggregate key.
Fig 7.1: Using KAC for data sharing in cloud storage
Here we describe the main idea of data sharing in cloud storage using KAC, illustrated
in Figure 7.1. Suppose Alice wants to share her data m1,m2,....my on the server. She first
performs Setup to get param and execute KeyGen to get the public/master-secret key
25. pair (pk, msk). The system parameter param and public-key pk can be made public and
master-secret key msk should be kept secret by Alice. Anyone (including Alice herself) can
then encrypt each mi by Ci = Encrypt(pk, i ,mi). The encrypted data are uploaded to the
server. With param and pk, people who cooperate with Alice can update Alice’s data on the
server. Once Alice is willing to share a set S of her data with a friend Bob, she can compute
the aggregate key KS for Bob by performing Extract(msk,S). Since KS is just a constantsize
key, it is easy to be sent to Bob via a secure e-mail. After obtaining the aggregate key, Bob
can download the data he is authorized to access. That is, for each i € S, Bob downloads Ci
(and some needed values in param) from the server. With the aggregate key KS, Bob can
decrypt each Ci by Decrypt for each i € S.
7.3 PERFORMANCE ANALYSIS
7.3.1 Compression Factors
This is used in the Complete Subtree scheme, which is a representative solution to the
broadcast encryption problem following the well-known Subset-Cover framework. It employs a
static logical key hierarchy, which is materialized with a full binary key tree of height h , and
thus can support up to 2h ciphertext classes, a selected part of which is intended for an authorized
delegatee. Therefore, we are interested in na, the number of symmetric-keys to be assigned in this
hierarchical key approach, in an average sense. Obviously, if r = 0, na should also be 0, which
means no access to any of the classes; if r = 100%, na should be as low as 1, which means that
the possession of only the root key in the hierarchy can grant the access to all the 2h classes.
Consequently, one may expect that na may first increase with r, and may decrease later. We set r
= 10%; 20%; ; 90%, and choose the portion in a random
manner to model an arbitrary “delegation pat-tern” for different delegatees. For each
combination of r and h, we randomly generate 104 different combinations of classes to be
delegated, and the output key set size na is the average over random delegations.
For a given h, na increases with the dele-gation ratio r until r reaches 70%. An
amazing fact is that, the ratio of na to N(= 2h+1 1), the total number of keys in the hierarchy
(e.g., N = 15 in Figure 3), appears to be only determined by r but irrelevant of h. This is
26. because when the number of ciphertext classes (2h) is large and the delegation ratio (r) is
fixed, this kind of random delegation achieves roughly the same key assignment ratios
(na=N). Thus, for the same r, na grows exponentially with h. We can easily estimate how
many keys we need to assign when we are given r and h.
We then turn our focus to the compression7 factor F for a certain h, i.e., the average
number of delegated classes that each granted key can decrypt. Specifically, it is the ratio of
the total number of delegated classes (r2h) to the number of granted keys required (na).
Certainly, higher compression factor is preferable because it means each granted key can
decrypt more ciphertexts. Figure 7.2 illustrates the relationship between the compression
factor and the delegation ratio. Somewhat surprisingly, we found that F = 3:2 even for
delegation ratio of r = 0:9, and F < 6 for r = 0:95, which deviates from the intuition that only
a small number of “powerful” keys are needed for delegating most of the classes. We can
only get a high (but still small) compression factor when the delegation ratio is close to 1. In
our experiment, the delegation is randomly chosen. It models the situation that the needs for
delegating to different users may not be predictable as time goes by, even after a careful
initial planning. This gives empirical evidences to support our thesis that hierarchical key
assignment does not save much in all cases.
7.3.2 Performance of Our Proposed Schemes
Our approaches allow the compression factor F (F = n in our schemes) to be a
tunable parameter, at the cost of O(n)-sized system parameter. Encryption can be done
in constant time, while decryption can be done in O(jSj) group multiplications (or point
addition on elliptic curves) with 2 pairing operations, where S is the set of ciphertext classes
decryptable by the granted aggregate key and jSj n. As expected, key extraction requires
O(jSj) group multiplications as well, which seems unavoidable. However, as demonstrated
by the experiment results, we do not need to set a very high n to have better compression
than the tree-based approach. Note that group multiplication is a very fast operation.
Again, we confirm empirically that our analysis is true. We implemented the basic KAC
system in C with the Pairing-Based Cryptography (PBC) Library8 version 0.4.18 for the
underlying elliptic-curve group and pairing operations. Since the granted key can be as small
27. as one G element, and the ciphertext only contains two G and one GT elements, we used
(symmetric) pairings over Type-A (supersingular) curves as defined in the PBC library
which offers the highest efficiency among all types of curves, even though Type-A curves
do not provide the shortest representation for group elements. In our implementation, p is a
160-bit Solinas prime, which offers 1024-bit of discrete-logarithm security. Setup algorithm,
while outputting (2n + 1) elements by doing (2n 2) exponentiations, can be made efficient by
preprocessing function offered by PBC, which saves time for exponentiating the same
element (g) in the long run. This is the only “low-level” optimization trick we have used. All
other operations are implemented in a straightforward manner. In particular, we did not
exploit the fact that e^(g1; gn) will be exponentiated many times across different
encryptions. However, we pre-computed its value in the setup stage, such that the encryption
can be done without computing any pairing.
The ex-ecution times of Setup, KeyGen, Encrypt are independent of the delegation
ratio r. In our experiments, KeyGen takes 3:3 milliseconds and Encrypt takes 6:8
milliseconds. As expected, the running time complexities of Extract and Decrypt increase
linearly with the delegation ratio r (which determines the size of the delegated set S). Our
timing results also conform to what can be seen from the
equation in Extract and Decrypt — two pairing oper-ations take negligible time, the running
time of Decrypt is roughly a double of Extract. Note that our experiments dealt with up to
65536 number of classes (which is also the compression factor), and should be large enough
for fine-grained data sharing in most situations.
Finally, we remark that for applications where the number of ciphertext classes is
large but the non-confidential storage is limited, one should deploy our schemes using the
Type-D pairing bundled with the PBC, which only requires 170-bit to represent an element
in G. For n = 216, the system parameter requires ap-proximately 2:6 megabytes, which is as
large as a lower-quality MP3 file or a higher-resolution JPEG file that a typical cellphone
can store more than a dozen of them. But we saved expensive secure storage without the
hassle of managing a hierarchy of delegation classes.
31. CHAPTER 8
ALGORITHMS USED
8.2 AES ALGORITHM
8.1.1 The Origins Of Aes
The principal drawback of 3DES (which was recommended in 1999, Federal
Information Processing Standard FIPS PUB 46-3 as new standard with 168-bit key) is that
the algorithm is relatively sluggish in software. A secondary drawback is the use of 64-bit
block size. For reasons of both efficiency and security, a larger block size is desirable.In
1997, National Institute of Standards and Technology NIST issued a call for proposals for a
new Advanced Encryption Standard (AES), which should have security strength equal to or
better than 3DES, and significantly improved efficiency. In addition, NIST also specified
that AES must be a symmetric block cipher with a block length of 128 bits and support for
key lengths of 128, 192, and 256 bits.In a first round of evaluation, 15 proposed algorithms
were accepted. A 2nd
round narrowed to 5 algorithms. NIST completed its evaluation
process and published a final standard (FIPS PUB 197) in November, 2001. NIST selected
Rijndael as the proposed AES algorithm. The 2 researches of AES are Dr. Joan Daemon and
Dr. Vincent Rijmen from Belgium.
AES Evaluation
Security – 128 minimal key size provides enough security
Cost – AES should have high computational efficiency
8.1.2 Basic Concept Of The Algorithm
The Advanced Encryption Standard (AES) was announced by the National Institute
of Standards and Technology (NIST) in November 2001. It is the successor
of Data Encryption Standard (DES), which cannot be considered as safe any longer,
because of its short key with a length of only 56 bits. To determine which algorithm
32. would follow DES, NIST called for different algorithm proposals in a sort of competition.
The best of all suggestions would become the new AES. In the final round of this
competition the algorithm Rijndael, named after its Belgian inventors Joan Daemen and
Vincent Rijmen, won because of its security, ease of implementation, and low memory
requirements. There are three different versions of AES. All of them have a block length of
128 bits, whereas the key length is allowed to be 128, 192, or 256 bits. In this application
report, only a key length of 128 bits is discussed.
The AES algorithm consists of ten rounds of encryption, as can be seen in Figure 1.
First the 128-bit key is expanded into eleven so-called round keys, each of them 128 bits in
size. Each round includes a transformation using the corresponding cipher key to ensure the
security of the encryption.
Fig 8.1: Aes Algorithm Structure
33. After an initial round, during which the first round key is XORed to the plain text
(Addroundkey operation), nine equally structured rounds follow. Each round consists of the
following operations:
• Substitute bytes
• Shift rows
• Mix columns
• Add round key
The tenth round is similar to rounds one to nine, but the Mix columns step is
omitted. In the following sections, these four operations are explained.
Structure of Key and Input Data
Both the key and the input data (also referred to as the state) are structured in a 4x4
matrix of bytes. Figure 2 shows how the 128-bit key and input data are distributed into the
byte matrices.
Fig 8.2:Structure of key and the state
Substitute Bytes (Subbytes Operation)
34. The Subbytes operation is a nonlinear substitution. This is a major reason for the
security of the AES. There are different ways of interpreting the Subbytes operation. In this
application report, it is sufficient to consider the Subbytes step as a lookup in a table. With
the help of this lookuptable, the 16 bytes of the state (the input data) are substituted by the
corresponding values found in the table.
Shift Rows (Shiftrows Operation)
As implied by its name, the Shiftrows operation processes different rows. A simple
rotate with a different rotate width is performed. The second row of the 4x4 byte input data
(the state) is shifted one byte position to the left in the matrix, the third row is shifted two
byte positions to the left, and the fourth row is shifted three byte positions to the left. The
first row is not changed.
Mix Columns (Mixcolumns Operation)
Probably the most complex operation from a software implementation perspective is
the Mixcolumns step. Opposed to the Shiftrows operation, which works on rows in the 4x4
state matrix, the Mixcolumns operation processes columns. In principle, only a matrix
multiplication needs to be executed. To make this operation reversible, the usual addition
and multiplication are not used. In AES, Galois field operations are used. This paper does
not go into the mathematical details, it is only important to know that in a Galois field, an
addition corresponds to an XOR and a multiplication to a more complex equivalent. The fact
that there are many instances of 01 in the multiplication matrix of the Mixcolumns operation
makes this step easily computable.
Add Round Key (Addroundkey Operation)
The Addroundkey operation is simple. The corresponding bytes of the input data and the
expanded key are XORed .
35. Key Expansion (Keyexpansion Operation)
As previously mentioned, Keyexpansion refers to the process in which the 128 bits
of the original key are expanded into eleven 128-bit round keys.
To compute round key (n+1) from round key (n) these steps are performed:
1. Compute the new first column of the next round key as shown in Figure 7:
Fig 8.2:Expanding first column of next round key
First all the bytes of the old fourth column have to be substituted using the Subbytes
operation. These four bytes are shifted vertically by one byte position and then XORed to
the old first column. The result of these operations is the new first column.
2. Columns 2 to 4 of the new round key are calculated as shown:
36. • [new second column] = [new first column] XOR [old second column]
• [new third column] = [new second column] XOR [old third column]
• [new fourth column] = [new third column] XOR [old fourth column].
Decrypting
Decryption can be done in a similar way to encryption. First two arrays are defined.
When a decryption needs to be performed, one array contains the key and the other one the
cipher text.
43. CHAPTER 10
ADVANTAGES
How to protect users data privacy is a central question of cloud storage. With more
mathematical tools, cryptographic schemes are getting more versatile and often involve
multiple keys for a single application. In this project, we consider how to “compress” secret
keys in public key cryptosystems which support delegation of secret keys for different
ciphertext classes in cloud storage. No matter which one among the power set of classes, the
delegate can always get an aggregate key of constant size. Our approach is more flexible
than hierarchical key assignment which can only save spaces if all key-holders share a
similar set of privileges.
44. CHAPTER 11
FUTURE SCOPE
To provide a secure environment where a data owner can share data with members
of his group while preventing any outsiders from gaining any data access in case of
malicious activities such as data loss and theft. However, throughout the chapter that
member of the group will not carry out malicious activities on the data owner’s data.
Auditing and Accountability in the Cloud is a potential for future research in the context of
data sharing in the Cloud. Many users, in particular organizations and enterprises, benefit
from data sharing in the Cloud. However, there is always a likely chance that members of
the group can carry out illegal operations on the data such as making illegal copies and
distributing copies to friends, general public in order to profit. A future research direction
would be to find ways for a data owner to hold accountable any member that carries out
malicious activities on their data. Another research direction would be to give the data owner
physical access control over his data. Instead of accountability, the data owner can create a
set of access control rules on his data and send the data along with the access control policy.
In this way, any member with access to the data can only use the data in such a way that
abides by the access control policy. If a member attempts to make illegal copies of the data,
the access control policy should “lock” the data to prevent the member from doing so. Also,
since data stored in the Cloud are usually stored and replicated in different geographical
locations around the world, it is crucial that the legal jurisdictions are honored and followed.
A potential research direction would be to find ways to store and process data in a way that
does not breach the privacy and security laws of the region.
CHAPTER 12
CONCLUSION
45. We introduce the concept of key based cryptosystem for scalable data sharing in
cloud. We proved security of the system in a model that gives the adversary his choice of
public key and messages forge. An efficient client based encryption with the power of single
aggregate key is adopted .Our project ensures strong belief in terms of confidentiality. A
limitation in our work is the predefined bound of the number of maximum ciphertext
classes. In cloud storage, the number of ciphertexts usually grows rapidly. So we have to
reserve enough ciphertext classes for the future extension. Thus data privacy and security is
maintained by designing a public key cryptosystem called as Key Aggregate Cryptosystem
(KAC). This KAC helps user to share their data partially over cloud with constant size key
pair of public-master keys and also receiver can decrypt this data with single constant size
aggregate key. There are some limitation to the existing system like predefined bound of the
number of maximum ciphertext classes and system is prompt to leakage of key. Although
the parameter can be downloaded with ciphertexts, it would be better if its size is
independent ofthe maximum number of ciphertext classes. On the other hand, when one
carries the delegated keys around in a mobile device without using special trusted hardware,
the key is prompt to leakage, designing a leakageresilient cryptosystem yet allows efficient
and flexible key delegation is also an interesting direction.
46. REFERENCE
[1] Key-Aggregate Cryptosystem for Scalable Data Sharing in Cloud Storage
Cheng-Kang Chu, Sherman S. M. Chow, Wen-Guey Tzeng, Jianying Zhou,
and Robert H. Deng, Senior Member, IEEE
[2] C. Wang, S.S.M. Chow, Q. Wang, K. Ren, and W. Lou, “Privacy-Preserving Public Auditing for
Secure Cloud Storage,” IEEE Trans. Computers, vol. 62, no. 2, pp. 362-375, Feb. 2013.
[3] B. Wang, S.S.M. Chow, M. Li, and H. Li, “Storing Shared Data on The Cloud via Security-
Mediator,” Proc. IEEE 33rd Int’l Conf.Distributed Computing Systems (ICDCS), 2013.
[4] S.S.M. Chow, C.-K. Chu, X. Huang, J. Zhou, and R.H. Deng, “Dynamic Secure Cloud
Storage with Provenance,” Cryptography and Security, pp. 442-464, Springer, 2012.
[5] D. Boneh, C. Gentry, B. Lynn, and H. Shacham, “Aggregate and Verifiably Encrypted
Signatures from Bilinear Maps,” Proc. 22nd
Int’l Conf. Theory and Applications of
Cryptographic Techniques (EUROCRYPT ’03), pp. 416-432, 2003.
[6] M.J. Atallah, M. Blanton, N. Fazio, and K.B. Frikken, “Dynamic And Efficient Key
Management for Access Hierarchies,” ACM Trans. Information and System Security, vol.
12, no. 3, pp. 18:1-18:43, 2009.
[7] J. Benaloh, M. Chase, E. Horvitz, and K. Lauter, “Patient Controlled Encryption: Ensuring
Privacy of Electronic Medical Records,” Proc. ACM Workshop Cloud Computing Security
(CCSW ’09), pp. 103-114, 2009.
[8] F. Guo, Y. Mu, Z. Chen, and L. Xu, “Multi-Identity Single-Key Decryption without
Random Oracles,” Proc. Information Security and Cryptology (Inscrypt ’07), vol. 4990, pp.
384-398, 2007.
[9] V. Goyal, O. Pandey, A. Sahai, and B. Waters, “Attribute-Based Encryption for Fine-
Grained Access Control of Encrypted Data,” Proc. 13th ACM Conf. Computer and Comm.
Security (CCS ’06), pp. 89-98, 2006.
