SecRBAC: Secure data in the Clouds

ABSTRACT:

Most current security solutions are based on perimeter security. However, Cloud computing breaks the organization perimeters. When data resides in the Cloud, they reside outside the organizational bounds. This leads users to a loose of control over their data and raises reasonable security concerns that slow down the adoption of Cloud computing. Is the Cloud service provider accessing the data? Is it legitimately applying the access control policy defined by the user? This paper presents a data-centric access control solution with enriched role-based expressiveness in which security is focused on protecting user data regardless the Cloud service provider that holds it. Novel identity-based and proxy re-encryption techniques are used to protect the authorization model. Data is encrypted and authorization rules are cryptographically protected to preserve user data against the service provider access or misbehavior. The authorization model provides high expressiveness with role hierarchy and resource hierarchy support. The solution takes advantage of the logic formalism provided by Semantic Web technologies, which enables advanced rule management like semantic conflict detection. A proof of concept implementation has been developed and a working prototypical deployment of the proposal has been integrated within Google services.

EXISTING SYSTEM:

• Several data-centric approaches, mostly based on Attribute-based Encryption (ABE), have arisen for data protection in the Cloud. In ABE, the encrypted ciphertext is labeled with a set of attributes by the data owner. Users also have a set of attributes defined in their private keys. They would be able to access data (i.e. decrypt it) or not depending on the match between ciphertext and key attributes.
• The set of attributes needed by a user to decrypt the data is defined by an access structure, which is specified as a tree with AND and OR nodes.
• There are two main approaches for ABE depending on where the access structure resides: Key-Policy ABE (KP-ABE) and Ciphertext-Policy ABE (CP-ABE).
• In KP-ABE the access structure or policy is defined within the private keys of users. This allows to encrypt data labeled with attributes and then control the access to such data by delivering the appropriate keys to users. However, in this case the policy is really defined by the key issuer instead of the encryptor of data, i.e. the data owner. So, the data owner should trust the key issuer for this to properly generate an adequate access policy.
• To solve this issue, CP-ABE proposes to include the access structure within the ciperthext, which is under control of the data owner. Then, the key issuer just asserts the attributes of users by including them in private keys. However, either in KP-ABE or CP-ABE, the expressiveness of the access control policy is limited to combinations of AND-ed and OR-ed attributes.

DISADVANTAGES OF EXISTING SYSTEM:

• Encrypting data avoids undesired accesses. However, it entails new issues related to access control management.
• To the best of our knowledge, there is no data-centric approach providing an RBAC model for access control in which data is encrypted and self-protected.
• Existing Hierarchical approach implies that attributes should be managed by the same root domain authority.
• User privileges are completely independent of their private key. Finally, no user-centric approach for authorization rules is provided by current ABE solutions.

PROPOSED SYSTEM:

• This paper presents SecRBAC, a data-centric access control solution for self-protected data that can run in untrusted CSPs and provides extended Role-Based Access Control expressiveness.
• The proposed authorization solution provides a rule-based approach following the RBAC scheme, where roles are used to ease the management of access to the resources.
• The main contributions of the proposed solution are:
• Data-centric solution with data protection for the Cloud Service Provider to be unable to access it.
• Rule-based approach for authorization where rules are under control of the data owner.
• High expressiveness for authorization rules applying the RBAC scheme with role hierarchy and resource hierarchy (Hierarchical RBAC or hRBAC).
• Access control computation delegated to the CSP, but being unable to grant access to unauthorized parties.
• Secure key distribution mechanism and PKI compatibility for using standard X.509 certificates and keys.

ADVANTAGES OF PROPOSED SYSTEM:

• The proposal in this paper supposes a first solution for a data-centric RBAC approach, offering an alternative to the ABAC model.
• This approach can help to control and manage security and to deal with the complexity of managing access control in Cloud computing.
• Role and resource hierarchies are supported by the authorization model, providing more expressiveness to the rules by enabling the definition of simple but powerful rules that apply to several users and resources thanks to privilege propagation through roles and hierarchies.
• Policy rule specifications are based on Semantic Web technologies that enable enriched rule definitions and advanced policy management features like conflict detection.

SYSTEM ARCHITECTURE:

MODULES:

• File Upload
• File Download
• File Update
• New Group User Inclusion
• Departing Group User

MODULE DESCRIPTIONS:

File Upload:

Whenever a need to share data among the group arises, the owner of the file sends the encryption request to the CS. The request is accompanied by the file (F) and a list (L) of users that are to be granted access to the file. L also contains the access rights for each of the users. The users may have READ-only and/or READ–WRITE access to the file. Other parameters can be also set to enforce fine-grained access control over the data. L is used to generate the ACL for the data by the CS. L is sent to the CS only if the data are to be shared with a new proposed group. If the group already exists, the encryption request will not contain L; rather, the group ID of the existing group will be sent. The CS, after receiving the encryption request for the file, generates the ACL from the list and creates a group of the users. The ACL is separately maintained for each file. The ACL contains information regarding the file such as its unique ID, size, owner ID, the list of the user IDs with whom the file is being shared, and other metadata. If the group already existed, only the ACL for the file is created. Next, the CS generates K according to the procedure defined in Section III-B and encrypts the file with an appropriate symmetric block cipher (we have used the AES for encryption purposes). The result is an encrypted file (C). Subsequently, the CS generates Ki and K_ i for every user and deletes K by secure overwriting. Secure overwriting is a concept in which the bits in the memory are constantly flipped to make sure that a memory cell never grips a charge for enough duration for it to be remembered and recovered. The Ki for each user is inserted into the ACL for later use. To protect the integrity of the file, the CS also computes the hash-based message authentication code (HMAC) signature on every encrypted file. A similar procedure for the HMAC key is adopted. However, the HMAC key is kept by the CS only. The encrypted data, the group ID (in the case of a newly generated group), and the K_ i for the owner are sent to the requesting data owner. The group ID and the K_ i for the rest of the group users are directly sent to them over a secure communication channel. The public keys of the group users can be also used to transmit the user portion of the key. We have used the public keys of the users to transmit the key portions. The user, after receiving C, uploads it to the cloud. K is deleted via secure overwriting from the CS after the encryption process. It is noteworthy that the key generation process is executed once when the group is initiated and the first file is submitted for encryption. Moreover, a newly joining member also activates the key generation but only for the new member.

File Download:

The authorized user sends a download request to the CS or downloads the encrypted file (C) from the cloud and sends the decryption request to the CS. The cloud verifies the authorization of the user through a locally maintained ACL. The decryption request is accompanied by the user portion of the key, i.e., K_ i, along with other authentication credentials. The CS computes K by applying XOR operation over K_ i and the corresponding Ki from the ACL. As each of the users correspond to a different pair of Ki and K_ i, none of the users can use other users’ K_ i to masquerade identity. Subsequently, the CS proceeds with the decryption process after verifying the integrity of the file. If the correct K_ i is received by the CS, the result will be a successful decryption process; otherwise, the decryption will fail. After successful decryption, the file is sent to the requesting user through a secure communication channel that could be Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec) channels. K is deleted via secure overwriting from the CS after decryption. The users are authenticated before the request processing according to standard procedures. Similar to the file upload process, the downloading of the file can be also done by the CS on behalf of the user. In the aforesaid case, the decryption request is sent to the CS. The CS, after authenticating the user, sends the download request to the cloud for the specified file. The cloud sends the encrypted file (C) to the CS. The rest of the process for the decryption is the same.

File Update:

Updating the file has a similar procedure to that of uploading the file. The difference is that, while updating, all of the activities related to the creation of the ACL and key generation are not carried out. The user, who has downloaded the file and made any changes, sends an update request to the CS. The request contains the group ID, the file ID, and K_i, along with the file to be encrypted after changes. The CS verifies that the user has the WRITE access to the file from the corresponding ACL. In the case of a valid update request, the CS computes K by XORing Ki and K_ i, encrypts the file, and performs the HMAC calculations. The encrypted file is sent to the user or uploaded to the cloud. K is deleted afterward.

New Group User Inclusion:

If a new user joins the group, the addition of the user is made on the request of the file owner. The request contains the user ID of the joining user, along with the access control parameters to be included in the ACL, and the group ID. The parameters include the IDs of the files for which the user has been granted access rights. It also includes the details indicating the READ and/or WRITE rights granted to the user. Alternatively, the date can be mentioned from which the access rights are valid for the user. This ensures the backward access control for the joining member. The CS, after receiving the joining request, updates the ACLs related to the files for which the access is granted. The key shares are generated, and the user shares are sent to the user along with the corresponding file IDs.

Departing Group User:

The CS is notified about a departing member by the group owner. The CS removes all of the records for the departing user from the ACLs of the related files. As the whole key is not possessed by the group members, the departing member (even being malicious) will be unable to decrypt any of the group data files. Even the presence of encrypted files with a malicious departing member will not affect the privacy of the data. The malicious member will be unable to construct the whole key for decryption. Therefore, the forward access control is also ensured by the SeDaSC methodology. The next section discusses how different security services are achieved by the SeDaSC methodology.

SYSTEM REQUIREMENTS:

HARDWARE REQUIREMENTS:

• System                           :         Pentium Dual Core.

• Hard Disk                      :         120 GB.

• Monitor                         :         15’’ LED

• Input Devices                 :         Keyboard, Mouse

• Ram                               :         1GB.

SOFTWARE REQUIREMENTS:

• Operating system                    :         Windows 7.
• Coding Language           :         JAVA/J2EE
• Tool                               :         Netbeans 7.2.1
• Database                        :         MYSQL

REFERENCE:

Juan M. Mar´ın P´ erez, Gregorio Mart´ınez P´ erez, Antonio F. Skarmeta G´omez, “SecRBAC: Secure data in the Clouds”, IEEE TRANSACTIONS ON SERVICES COMPUTING 2016.