Title of the Project:

Achieving Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing

Objective of the Project:

The objective of the project is to achieve Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing

Introduction:
The use of widely distributed resources on the Internet has strained existing network infrastructures. Until recently, applications and services were targeted to environments spanning few administrative domains supporting a relatively static user community. However, the explosion of new forms of communication has invalidated many of the basic assumptions upon which these systems were built. Thus, the design of these systems, and of their security in particular, has recently come under considerable scrutiny. An approach addressing the requirements of these emerging applications and services is the use of policy. Through policy, a system may address the (sometimes conflicting) needs of all communication participants in real time. Each session occurs within the context of a shared policy defining the acceptable behavior and requirements of its participants. Thus, rather than relying solely on the system designers or network administration to define service behavior, the interests of all parities are considered at the point at which communication occurs. This paper considers a number of principles for the construction of one kind of policy, secure group communication policy. We define a group security policy as a statement of the entirety of security relevant parameters and facilities used to implement the group. This best fits the viewpoint

of policy as defining how security directs group behavior, who are the entities allowed to participate, and which mechanisms will be used to achieve mission critical goals.Note that this definition is not restricted to electronically distributed statements, policy is often the result of system design and configuration. Cloud Computing refers to both the applications delivered as services over the Internet and the hardware and systems in the datacenters that provide those services. The services themselves have long been referred to as Software as a Service (SaaS), so we use that term. The datacenter hardware and software is what we will call a Cloud.When a Cloud is made available in a payas-you-go manner to the public, we call it a Public Cloud; the service being sold is Utility Computing. Current examples of public Utility Computing include AmazonWeb Services, Google AppEngine, and Microsoft Azure. We use the term Private Cloud to refer to internal datacenters of a business or other organization that are not made available to the public. Thus, Cloud Computing is the sum of SaaS and Utility Computing, but does not normally include Private Clouds. Well generally use Cloud Computing, replacing it with one of the other terms only when clarity demands it. .The advantages of SaaS to both end users and service providers are well understood. Service providers enjoy greatly simplified software installation and maintenance and centralized control over versioning; end users can access the service anytime, anywhere, share data and collaborate more easily, and keep their data stored safely in the infrastructure. Cloud Computing does not change these arguments, but it does give more application providers the choice of deploying their product as SaaS without provisioning a datacenter: just as the emergence of semiconductor foundries gave chip companies the opportunity to design and sell chips without owning a fab, Cloud Computing allows

deploying SaaS and scaling on demand without building or provisioning a datacenter. Analogously to how SaaS allows the user to offload some problems to the SaaS provider, the SaaS provider can now offload some of his problems to the Cloud Computing provider. From now on, we will focus on issues related to the potential SaaS Provider (Cloud User) and to the Cloud Providers, which have received less attention. Cloud computing is an emerging computing paradigm in which resources of the computing infrastructure are provided as services over the Internet. As promising as it is,this paradigm also brings forth many new challenges for data security and access control when users outsource sensitive data for sharing on cloud servers, which are not within the same trusted domain as data owners. To keep sensitive user data confidential against untrusted servers, existing solutions usually apply cryptographic methods by disclosing data decryption keys only to authorized users. However, in doing so, these solutions inevitably introduce a heavy computation overhead on the data owner for key distribution and data management when finegrained data access control is desired, and thus do not scale well. The problem of simultaneously achieving fine-grainedness, scalability, and data confidentiality of access control actually still remains unresolved. This paper addresses this challenging open issue by, on one hand, defining and enforcing access policies based on data attributes, and, on the other hand, allowing the data owner to delegate most of the computation tasks involved in finegrained data access control to untrusted cloud servers without disclosing the underlying data contents. We achieve this goal by exploiting and uniquely combining techniques of attribute-based encryption (ABE), proxy re-encryption, and lazy re-encryption.Our proposed scheme also has salient properties of user access privilege confidentiality and user secret key

accountability. Extensive analysis shows that our proposed scheme is highly efficientand provably secure under existing security models.

Literature Survey: Group Security Policy

This section considers the requirements of policy management in secure group communication systems. A set of principles derived from these requirements is developed and illustrated. We begin in the next subsection by stating a definition of secure groups and their policies.

Secure Groups and Policy

Described in Figure 1, we define a secure group as the collection of cooperating entities operating under a shared security policy. Each group contains a group controller from which keying material logically emanates. Groups can be organized into logical subgroups, with distinct entities serving as subgroup-controllers . Group members may join, leave, or become compromised at any time during the session. In particular, we define the participants of a group as follows:

The

policy

is

specified

in

accordance

with

the

expectedcontent

value

and

operatingenvironment. The issuing authority is trusted by all potential groupmembers to state an appropriate policy.

Group Controller (GC):

The GC acts as a key dissemination and access control authority. The GC enforces group access control policy by creating and distributing group keying material to authorized entities, and initiating rekeying and member ejection as events dictate.

Subordinate Group Controller (SGC):

A subordinate controller performs all group controller functions,with the exception of session key creation.

Member (M):
The group member is the consumer of the group keying material. The member verifies the policy as correct, and enforces the authorization policies as defined by the policy specification (i.e., by only accepting appropriately authorized group messages).Throughout, we assume that members and controllers are mutually trusted, i.e., entities receiving a policy accept and enforce (the authenticated) policy as directed by its specification. However, members who become compromised may diverge from the specification arbitrarily.We assert entities external to the group and compromised members may intercept messages, modify messages, or prevent messages from being delivered.

Throughout, we assume that members and controllers are mutually trusted, i.e., entities receiving a policy accept and enforce (the authenticated) policy as directed by its specification. However, members who become compromised may diverge from the specification arbitrarily members We assert entities external to the group and compromised may intercept messages, modify messages, or prevent messages from being delivered.We note many other, more complicated, models of group exist. For example, groups can converge on a singlepolicy through negotiation or assume members are untrusted . For brevity, we defer discussion of these groups. However, many of the principles identified in the following section are applicable to these groups.Each policy is initially stated as sets of conditional statements defining the possible authorizations and mechanisms used to implement a group. The conditional statements indicate environment-specific constraints and requirements of potential sessions. The group owner creates the initial policy. An instantiation of the policy1 results from the leader evaluation of the conditional policy statements. The instantiation defines the security relevant properties of the group. However, some aspects of the group policy are implicitly defined; decisions about how the group security is implemented can be the result of system design and configuration. Whether explicitly or implicitly defined, we assert that any group must specify the following:

Identification

Each participant and group must be unambiguously identified. Failure to correctly identify the group policies, messages, and participants can lead to incorrect and insecure operation.

Authorization
A group policy must identify the entities allowed to perform protected actions. Group authorization partially determines the trust embodied by the group.

Access Control
Allowable access to group action must be stated by policy. An access control policy defines a mapping between the authorized parties and secure actions in the group, and indirectly, the permissions for group information.

Mechanism
Each policy must state how the security requirements of the group are to be addressed.This includes the identification of the approaches used to achieve security guarantees and the parameters of their operation. Thus, a mechanism policy defines the provisioning of group software and often the operation of its component protocols.

Verification
Each policy must present evidence of its validity. The means by which the origin, integrity, and freshness of the policy is asserted (for example, via digital signature) must be known by each group member prior to its acquisition.

Design Goals
Our main design goal is to help the data owner achieve fine-grained access control on files stored by Cloud Servers. Specifically, we want to enable the data owner to enforce a unique access structure on each user, which precisely designates the set of files that the user is allowed to access. We also want to prevent Cloud Servers from being able to learn both the data file

contents and user access privilege information. In addition, the proposed scheme should be able to achieve security goals like user accountability and support basic operations such as user grant/revocation as a general one-to-many communication system would require. All these design goals should be achieved efficiently in the sense that the system is scalable.

Key Policy Attribute-Based Encryption (KP-ABE)

KP-ABE is a public key cryptography primitive for one-to-many communications. In KPABE, data are associated with attributes for each of which a public key component is defined. The encryptor associates the set of attributes to the message by encrypting it with the corresponding public key components. Each user is assigned an access structure which is usually defined as an access tree over data attributes, i.e., interior nodes of the access tree are threshold gates and leaf nodes are associated with attributes. User secret key is defined to reflect the access structure so that the user is able to decrypt a ciphertext if and only if the data attributes satisfy his access structure.

Existing Systems:
In the existing system the problem with data security and access control when users outsource sensitive data for sharing on cloud servers, which are not within the same trusted domain as data owners.the system was a failure To keep sensitive user data confidential against untrusted servers, existing solutions usually apply cryptographic methods by disclosing data decryption keys only to authorized users.

Drawbacks

The main drawback of the existing system is that the system is not secure and scalable.The sytem was failure in case of data security and access control.It coulnot aceive the fine grained data access control.

Proposed System:
we address this open issue and propose a secure and scalable fine-grained data access control scheme for cloud computing. Our proposed scheme is partially based on our observation that, in practical application scenarios each data file can be associated with a set of attributes which are meaningful in the context of interest. The access structure of each user can thus be defined as a unique logical expression over these attributes to reflect the scope of data files that the user is allowed to access. As the logical expression can represent any desired data file set, fine-grainedness of data access control is achieved. To enforce these access structures, we define a public key component for each attribute. Data files are encrypted using public key components corresponding to their attributes.

Advantage over existing systems:

The proposed system could achieve Secure, Scalable, and Fine-grained Data Access Control in Cloud Computing. Also The problem of simultaneously achieving fine-grainedness, scalability, and data confidentiality of access control actually still remains unresolved.

CONCLUSION
This paper aims at fine-grained data access control in cloud computing. One challenge in this context is to achieve finegrainedness finegrainedness, data confidentiality, and scalability simultaneously, which is not provided by current work. In this paper we propose a scheme to achieve this goal by exploiting KPABE and uniquely combining it with techniques of proxy re-encryption and lazy re-encryption. Moreover, our proposed scheme can enable the data owner to delegate most of computation overhead to powerful cloud servers. Confidentiality of user access privilege and user secret key accountability can be achieved. Formal security proofs show that our proposed scheme is secure under standard cryptographic models.

REFERENCES
[1] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia,Above the clouds: A berkeley view of cloud computing, University of California, Berkeley, Tech. Rep. USB-EECS-2009-28, Feb 2009. [2] Amazon Web Services (AWS), Online at http://aws. amazon.com. [3] Google App Engine, Online at http://code.google.com/appengine/. [4] Microsoft Azure, http://www.microsoft.com/azure/. [5] 104th United States Congress, Health Insurance Portability and Accountability Act of 1996 (HIPPA), Online at http://aspe.hhs.gov/ admnsimp/pl104191.htm, 1996. [6] H. Harney, A. Colgrove, and P. D. McDaniel, Principles of policy in secure groups, in Proc. of NDSS01, 2001. [7] P. D. McDaniel and A. Prakash, Methods and limitations of security policy reconciliation, in Proc. of SP02, 2002.

[8] T. Yu and M. Winslett, A unified scheme for resource protection in automated trust negotiation, in Proc. of SP03, 2003. [9] J. Li, N. Li, and W. H. Winsborough, Automated trust negotiation using cryptographic credentials, in Proc. of CCS05, 2005. [10] J. Anderson, Computer Security Technology Planning Study, AirForce Electronic Systems Division, Report ESD-TR-73-51, 1972, http: