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.