A Role-Based Encryption Scheme for Securing Outsourced Cloud Data in a Multi-Organization Context

04/11/2020 ∙ by Nazatul Haque Sultan, et al. ∙ 0

Role-Based Access Control (RBAC) is a popular model which maps roles to access permissions for resources and then roles to the users to provide access control. Role-Based Encryption (RBE) is a cryptographic form of RBAC model that integrates traditional RBAC with the cryptographic encryption method, where RBAC access policies are embedded in encrypted data itself so that any user holding a qualified role can access the data by decrypting it. However, the existing RBE schemes have been focusing on the single-organization cloud storage system, where the stored data can be accessed by users of the same organization. This paper presents a novel RBE scheme with efficient user revocation for the multi-organization cloud storage system, where the data from multiple independent organizations are stored and can be accessed by the authorized users from any other organization. Additionally, an outsourced decryption mechanism is introduced which enables the users to delegate expensive cryptographic operations to the cloud, thereby reducing the overhead on the end-users. Security and performance analyses of the proposed scheme demonstrate that it is provably secure against Chosen Plaintext Attack and can be useful for practical applications due to its low computation overhead.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Public cloud storage have already become popular with end-users such as individuals and organizations. Some popular public cloud storage includes Microsoft Azure Storage Service [1], Amazon S3 [2], and Google Cloud Storage [3]. The public cloud storage provides the data owners111Data owners are the end-users who own data. to reduce their investment costs like building their own storage infrastructures. It also enables ubiquitous data access through the Internet without worrying about management and maintenance of the outsourced data [4].

Although the benefits of public cloud storage are significant, there is some reluctance among the data owners to outsource their data in the storage servers of the public cloud due to their concern for data security and privacy [5, 6]. As the public cloud is formed by one or more cloud storage servers which are often distributed geographically in different locations, data owners do not know for certain where their data are stored. There is a strong perception that end-users lose control over their data once it is uploaded to the cloud storage [7]. There is more reluctance, especially if the data is sensitive. In [8], McAfee reported that of the outsourced data are sensitive or confidential such as health-related data, financial documents, and personal photographs. This concern arises as the service provider might have the ability to access the sensitive information of the data owners for various motivations. For example, if the outsourced data contain data owners’ health records, the service provider has the potential to sell these data to health insurance agencies for financial gain [9]. Hence, it is critical to preserve the confidentiality of outsourced data so that no malicious entity, including the service provider, has the ability to access the data without proper authorization. In order to control access of the data stored in a public cloud, suitable access control policies and mechanisms are required. The access policies must restrict data access to anyone other than those intended by the data owners.

In large scale systems such as enterprise, Role-Based Access Control (RBAC) has been widely used for access control, as it provides flexible security management. For instance, it allows access control to be managed at a level that corresponds closely to the organisation’s policy and structure. Roles in organizations are mapped to access permissions and users are mapped to appropriate roles. In general, users are assigned membership to the roles based on their responsibilities and qualification in the organisation, and permissions are assigned to qualified roles instead of individual users. Moreover, in RBAC, a role can inherit permissions from other roles, therefore there can be a hierarchical structure of roles. This is one of the major advantages of the RBAC system. However, in the traditional RBAC [10, 11], a service provider defines and enforces access policies on behalf of the data owners. The data owners have to, therefore, assume that the service provider is trusted to prevent unauthorised users from accessing their data. However, in an untrusted environment like a cloud environment, the service provider may give access privileges to unauthorized users for its own benefit, which can lead to reduced level of trust on the part of the data owners on the service provider when it comes to defining and enforcing access policy. This, in turn, makes the traditional RBAC mechanism less suitable for public cloud storage system.

Role-Based Encryption (RBE) is a cryptographic data access control method which is designed by combining the traditional RBAC model with the encryption method. It enables data owners to define and enforce RBAC access policy on the encrypted data itself [12, 7]. It thus reduces dependency on the service provider for defining and enforcement of RBAC access policy while giving full control to the data owners. In RBE, roles are organized to form a hierarchy, and each role is associated with a group of users who possess that role. Data are encrypted in such a way that any user who holds the required roles can derive the appropriate keys to decrypt the data. As the RBE is based on the RBAC model, the inheritance properties of RBE makes it more suitable for large organizations with complex hierarchical structures.

There have been a few RBE schemes proposed over the recent years such as [12, 7, 13, 14]. All of the schemes are designed for a single-organization public cloud storage system, where the outsourced data are hosted in the public cloud by the data owners of an organization, and the data are accessible to the users of the same organization only. In such a case, a single authority maintains all the roles and role hierarchies of that organization. The authority is responsible for assigning roles and corresponding role-keys to the users according to their access privileges in the role hierarchy. Later, the users can access data using their assigned roles, and role-keys will be used to decrypt the appropriate encrypted data. As a result, a user must hold a role in the organization to access data stored by that organization.

In many practical scenarios such as consortium222Consortium is an association where multiple organizations come together to share data to achieve some common goals., the data owners from multiple organizations outsource their data to the public cloud, and the data are shared with the users of other organizations. It might also happen that two organizations wish to work together on a collaborative project requiring users from these two organizations to share data in a secure manner. This is a more challenging multi-organization public cloud storage scenario. In such scenarios, the existing schemes [7, 13, 14] fail as an authority in one organization will not be able to establish roles for the users in the other organization(s) for the lack of trust among the organizations. One approach to solving this problem is to define a fresh RBE system for the consortium creating separate roles and role hierarchies for the users of the consortium from different organizations. However, this creates a practical challenge as it is difficult to define the authority who can manage this consortium role system, and to which organization should this authority report to.

In this paper, we have developed a novel multi-organization RBE scheme, which addresses the above challenge of sharing outsourced encrypted data between multiple organizations. Our multi-organization RBE scheme will achieve the sharing of encrypted data across multiple organizations in such a way that only users with appropriate roles belonging to different organizations are able to decrypt the data. Hence, the proposed scheme is suitable for secure data sharing among several organizations such as in a consortium or in collaborative projects, where the ability to decrypt and access the data from different organizations is only possible if the appropriate policies specified by those organizations are satisfied. This has been achieved without creating a fresh consortium RBE system as mentioned earlier.

The realization of the proposed multi-organization RBE scheme has been achieved using a hybrid cloud architecture comprising a private cloud and public cloud333In a recent reference [8], McAfee reported that 59% of the organizations are using the hybrid cloud model, and its popularity is growing at an increasing rate among the organizations.. The private cloud is used to store only the sensitive information such as user and organization related secrets, and the public cloud is used to store the actual data in encrypted form. Users who wish to share or access the data only interact with the public cloud; there is no access for public users to access the private cloud, which greatly reduces the attack surface for the private cloud. This architecture not only dispels the organisation’s concerns about risks of leaking sensitive organization’s information, but also takes full advantage of public cloud’s power to securely store large volume of data.

The noteworthy contributions of the scheme proposed in this paper are as follows:

  1. A single-organization role-based encryption scheme referred to as SO-RBE is proposed. SO-RBE achieves access control over encrypted data in a single-organization cloud storage system, where the outsourced (encrypted) data are hosted by an organization. The encrypted data can be decrypted and accessed by the users of same organization who satisfy appropriate policies.

  2. A separate multi-organization role-based encryption scheme referred to as MO-RBE is proposed by extending SO-RBE. MO-RBE enables a user of one organization to access data from another without possessing any role from that organization, provided the user is authorized. That is, the existing roles of the user from his/her own organization are alone sufficient to access data of the other organizations if the user is authorized (satisfies the appropriate access policies needed to decrypt the data).

  3. An efficient user revocation mechanism is introduced, which will work on both SO-RBE and MO-RBE, for revoking users from the system without the need to perform computationally expensive operations.

  4. An outsourced decryption method is also introduced for outsourcing of the computation intensive cryptographic operations to the cloud without disclosing confidential information to the service provider.

  5. A formal security analysis of the proposed scheme is provided which shows that the proposed scheme is provably secure against Chosen Plaintext Attack (CPA) under the standard cryptographic assumptions.

  6. Moreover, performance analysis of the proposed scheme demonstrates that the proposed scheme is efficient to be used in practical applications.

To the best of our knowledge, this is the first RBE scheme that addresses access control over encrypted data for public cloud storage system in a multi-organization context.

Unless stated otherwise, we refer the public cloud storage system as the cloud in the rest of this paper.

The rest of this paper is organized as follows. Related works are presented in Section 2. Section 3 gives a brief overview of role hierarchy, properties of the bilinear map, and complexity assumptions that will be used throughout this paper. The system model, framework, security assumptions and security model are presented in Section 4. Section 5 describes the proposed scheme in detail. The security and performance analysis details are given in Section 6 and finally, Section 7 concludes this paper.

2 Related Works

2.1 Hierarchical Key Management (HKM) Schemes

Access control using hierarchical key management (HKM) method has been studied in the early 1980s. In [15], Akl et al. presented the first cryptographic hierarchical access control technique to solve the hierarchical multi-level security problem. In this scheme, the users are grouped into disjoint sets (or classes) and form a hierarchical structure of classes. Each class is assigned with a unique encryption key and a public parameter in such a way that a higher-level class can derive encryption keys of any lower-level classes using its encryption key and some public parameters. Later several other HKM schemes have been proposed using different techniques, e.g. [16, 17, 18, 19, 20, 21]. Recently, in [19], Tang et al.

presented a HKM scheme based on linear geometry to provide flexible and fine-grained access control in cloud storage systems. In this scheme, any class in the hierarchy can derive encryption key using inner product of its public vector with the private vector of its ancestor class. In

[20], Chen et al. proposed another HKM scheme to support the assignment of dynamic reading and writing privileges. However, the main drawback of the HKM schemes is the high complexity for setting up the encryption keys for a large set of users [7]. Also, user revocation is a challenging task, as all the encryption keys that are known to the revoked users, and their related public parameters need to change per user revocation which may incur a high overhead on the system.

2.2 Hierarchical ID based Encryption Scheme (HIBE)

An alternative approach for the management of keys is Hierarchical ID-based Encryption (HIBE) such as [22, 23]. In these schemes, a user can decrypt an encrypted data using the private key associated with his/her identity if and only if the data is encrypted using any descendant identity of the hierarchy (i.e., tree). That is, the user cannot access any data which are encrypted using the ancestor identities or any other identity of the hierarchy. As such, the HIBE schemes can enforce RBAC access policy in encrypted data by associating the users with leaf nodes and roles with non-leaf nodes in the hierarchy. However, in HIBE schemes, the size of an identity increases with depth of the hierarchy. In addition, the identity of a node must be a subset of its ancestor node so that its ancestor node can derive this node’s private key for decryption. Therefore, this node cannot be assigned as a descendant node of another node in the hierarchy tree unless the identity of the other role is also the super set of this node’s identity.

2.3 Attribute based Encryption (ABE) Schemes

The first attribute-based encryption (ABE) scheme was proposed in [24] based on the work in [25], and some other ABE schemes have been proposed afterwards. In these schemes, data is encrypted using a set of attributes, and users who have the private keys associated with these attributes can decrypt the data. These works have provided an alternative approach to secure the data stored in a distributed environment using a different access control mechanism, such as [26]. In [12], Zhou et al. have shown that an ABE scheme can be used to enforce RBAC policies. However, in that approach, the size of user key is not constant, and the revocation of a user will result in a key update of all the other users of the same role. [13] also investigated the solutions of using ABE scheme in RBAC model. However their solution only maps the attributes to the role level in RBAC, and they assumed that the RBAC system itself would determine the user membership. There have also been other works based on variants of ABE such as [27, 24, 28, 29, 30, 31]. However, all these works [27, 24, 28, 29, 30, 31] cannot address role hierarchy and inheritance properties.

2.4 Role based Encryption (RBE)

A role based encryption (RBE) scheme integrates the RBAC access control model with cryptographic encryption techniques to enforce RBAC access policies on encrypted data. This enables the data to be encrypted to specific roles. Any user who holds the required role(s) and satisfies the associated RBAC access policies can access the data by decrypting it. It thus provides a secure solution for outsourcing data to the cloud storage servers while giving access to authorized users by defining and enforcing role based access policy on the encrypted data itself.

In [12], Zhou et al. proposed the first RBE scheme for data sharing in an untrusted hybrid cloud environment. In this scheme, the ciphertexts and secret keys of the users are of constant size. This scheme also offers efficient user revocation capability. A complete design and implementation of the proposed scheme with a real world application has been described in [7]. In [13], Zhu et al. proposed another RBE scheme that increases ciphertext size linearly with the number of roles. In the scheme [13], user revocation is performed during encryption process by the data owner that embeds revoke user information on the encrypted data itself. Hence data owner must know all the revoked users’ information prior to the data encryption phase. In [14], Perez et al. proposed a data-centric access control mechanism for cloud storage systems using the concept of proxy re-encryption technique. In [14], the data owner outsources data before encrypting it using the identity-based encryption technique proposed in [32]. To share data with the authorized users, the data owner generates re-encryption keys based on the RBAC access policies and keeps the re-encryption keys with the ciphertexts. When an authorized user accesses the ciphertext, the service provider re-encrypts the ciphertext using the re-encryption keys based on a RBAC access policy. However, none of these schemes [12, 7, 13, 14] support data access control in multi-organization cloud storage systems.

In this paper, we have used the RBE scheme described in [12, 7] as the basis for developing our RBE mechanism for multi-organization cloud environment, which has significant advantages compared to the ABE. It has the natural ability to enforce RBAC policies on encrypted data stored in the cloud with an efficient user revocation. A distinct advantage is that RBE is able to deal with role hierarchies, whereby roles inherit permissions from other roles. This is particularly significant as role based systems has been widely used in many large scale commercial systems providing flexible access control management corresponding closely to the organisation’s policy and structure.

Similarly in a multi-authority context, a multi-organization scheme based on ABE is not able to deal with the hierarchical structure of the organization in an efficient manner. On the other hand, a multi-organization scheme based on RBE such as the one proposed in this paper naturally fits with the organizational structure and is able to capture effectively the role hierarchies and inheritance properties. Furthermore, several of the multi-authority ABE schemes such as [28, 29, 33] and [34] require a trusted centralized/global authority to manage the set of attribute authorities. In this sense, these schemes represent a single-organization cloud environment. However, there are a few multi-authority ABE schemes such as [35, 36, 37] can provide role hierarchy and inheritance property. These schemes use a hierarchical key generation method, where one top-level domain authority can generate keys for the lower-level domain authorities or users. But, [35, 36, 37] assume that same root domain authority manages all the attributes of the system [14]. As such, these schemes also represent a single-organization cloud environment.

Fig. 1: Sample Role Hierarchy
Fig. 2: Proposed System Model

3 Preliminaries

This section introduces the concept of role hierarchy, properties of bilinear mapping as well as standard complexity assumptions.

3.1 Role Hierarchy

In the proposed scheme roles are organized into a hierarchy where ancestor roles can inherit access privileges of its descendant roles. Figure 1 shows a sample role hierarchy. The following notations are used to define a role hierarchy:

  • : set of all roles in the role hierarchy. For example,

  • : ancestor set of the role . For example, and .

  • : descendant set of the role . For example, , , and .

  • : set of roles not in , i.e., . For example, , and .

  • : set of roles not in , i.e., . For example, , and .

3.2 Bilinear Map

Let and be two cyclic multiplicative groups. Let, be a generator of . The bilinear map has the following properties:

  • Bilinear: and

  • Non-degenerate:

  • Computable: There exists an efficiently computable algorithm for computing for all

3.3 Complexity Assumptions

  1. Decisional Bilinear Diffie-Hellman (DBDH) Assumption: Let be an efficiently computable bilinear map. The DBDH assumption states that no probabilistic polynomial-time algorithm is able to distinguish the tuples and with non-negligible advantage, where and .

  2. Decisional Modified Bilinear Diffie-Hellman (MDBDH) Assumption [25]: Let be an efficiently computable bilinear map. The MDBDH assumption states that no probabilistic polynomial-time algorithm is able to distinguish the tuples and with non-negligible advantage, where and .

Notation Description
a large prime number
two cyclic multiplicative groups of order
hash function
set of organization in the system
total number of organizations in the system
set of roles managed by organization
system administrator
a role-manager of organization which manages role
role which is managed by organization
unique identity of the user registered with organization
role-key of the role issued to the user

4 Proposed Model

In this section, system model of the proposed scheme is presented along with framework, security assumptions and security model.

4.1 System Model

Figure 2 shows the proposed system model. It consists of six entities, namely system administrator, role-manager, private cloud, public cloud, data owners, and users which are described next. The notations used in this paper are shown in Table I.

  • System Administrator (SA): It is a certified authority of an organization. It is responsible for managing role hierarchy of an organization. It generates system parameters including master secret and system public parameter. It is responsible for issuing a pair of private and public keys for each registered users. System administrator also issues role secret for each role in the organization to the respective role-manager. It also manages private cloud of an organization. System administrator keeps a part of the master secret and user secrets in the private cloud. Further, it revokes users when required. Moreover, each system administrator shares its long term secret with the other system administrators in the cloud system so that its users can access data from the other organizations.

  • Private Clouds: It is formed by the internal cloud storage servers of an organization which is managed by the system administrator. The responsibility of the private cloud is to keep confidential information of the organization. Private cloud mainly stores a part of the master secrets of the system administrator and user secrets. It uses the known master secrets while assisting the public cloud during outsourced decryption process, and it uses user secrets while assisting the role-manager for generating role-keys in the key generation process. Private cloud provides interfaces to the public cloud and to the role-managers only.

  • Role-Manager: It is an entity which is responsible for managing roles. Each role-manager in an organization manages each of its corresponding role(s) and the associated users in that role(s). The role-manager assigns roles to each registered users and issues role-keys related with the assigned roles for them. During the role-key generation process, the role-manager interacts with the private cloud to compute role-keys for the users.

  • Public Cloud: It is formed by one or more cloud storage servers which are managed by a third-party service provider known as cloud service provider. The main responsibility of the public cloud is to store data owners’ outsourced (encrypted) data in its cloud storage servers. The other responsibility is to perform outsourced decryption.

  • Data Owner: It is an entity who owns the data. A data owner encrypts data using RBAC access policy before outsourcing to the public cloud.

  • User: It is an entity who uses the outsourced data. Each user needs to register with a system administrator. For each registered user, the role managers assign roles in form of the role-keys based on their profiles and responsibilities. The registered users also receive private keys from the system administrator.

4.2 Framework

The proposed scheme consists of the following phases and algorithms.

  1. System Initialization: This phase initializes the system, and it is initiated by a system administrator. It consists of the following algorithm.

    • Init : It takes security parameter as input. It outputs master secret , public parameter and another secret .

  2. Manage Role: This phase is initiated by a system administrator to generate secret role parameter, role public keys and role secrets. It comprises the following algorithm.

    • RoleParaGen : It takes system public parameter and a role key hierarchy as input. It outputs secret role parameter and role public key , role secret of each role .

  3. Key Generation: In this phase, system administrator issues a pair of private, public keys, and user secrets for each registered users. In this phase, the role-manager also issues role-keys to each registered user according to the roles they hold. It comprises the following two algorithms.

    • PrivKeyGen : It takes system public parameter , master secret and unique identity of a user as input. It outputs private key , public key and user secret .

    • RoleKeyGen : It takes system public parameter , role secret , , user secret and role as input. It outputs a role-key of the role for the user .

  4. Encryption: This phase is initiated by the data owners to encrypt data using role public keys according to RBAC access policy. It consists of Enc algorithm.

    • Enc : It takes system public parameter , a message where is the message space, and role public key of a role as input and outputs a ciphertext .

  5. Decryption: In this phase, a user of an organization accesses encrypted data hosted by the same organization by decrypting it using his/her role-keys and private key. It comprises Dec algorithm.

    • Dec : It takes role-key , private key of a user and ciphertext as input and outputs a message if and only if .

  6. User Revocation: In this phase, system administrator revokes users from the system. It consists of URevoke algorithm.

    • URevoke (): It takes public key of a revoked user as input. After invalidating the public key of the user , it outputs .

  7. Role Public Key Update: In this phase, joint role public key is generated when an organization wants to share data with some other organizations. This phase is initiated by the system administrator of an organization. It consists of RolePubKeyUpdate algorithm.

    • RolePubKeyUpdate : It takes role public key of the role which is maintained by the system administrator of the organization, another role public key of the role which is maintained by the system administrator of the organization and system public parameter as input. It outputs a joint role public key of the roles and .

  8. Multi-Organization Encryption: This phase encrypts the data using the joint role public key according to a RBAC access policy. It comprises MultiEnc algorithm.

    • MultiEnc : It takes public parameter of , joint role public key and the data (or message) as input. It outputs a ciphertext .

  9. System Administrator Agreement: In this phase, an organization (i.e., system administrator) shares a secret key, termed as long term secret, with other organizations. It consists of LongKeyShare algorithm.

    • LongKeyShare : It takes master secret of the organization, public parameter and another master secret of the organization as input. It outputs a long term secret key and a proxy re-encryption key .

  10. Multi-Organization Decryption: In this phase, a user of an organization accesses the encrypted data from other organizations by decrypting it using his/her role-key and private key. It consists of MultiDec algorithm.

    • MultiDec : It takes a ciphertext , proxy re-encryption key , secrets and , role-key and private key as input. It outputs plaintext data if and only if .

Fig. 3: Sample Role Key Hierarchy

4.3 Security Assumptions

In the proposed scheme, the following security assumptions are made.

  1. Each system administrator and role-manager are fully trusted entities.

  2. Public and private clouds are honest-but-curious entities. They honestly perform assigned tasks, but they may try to gain all the possible knowledge about the outsourced data.

  3. Users are not honest. They may try to gain unauthorized access to the outsourced data by colluding with other users.

  4. As the public cloud is honest, we do not consider any active attacks from it by colluding with the revoked users as in [38, 39, 40], etc.

  5. All entities use secure channels while communicating with one another. The secure channels can be established using Secure Sockets Layer (SSL).

  6. There is an authentication mechanism which is used by role-managers and the public cloud to authenticate the users.

4.4 Security Model

The security model of the proposed scheme is defined on Chosen Plaintext Attack (CPA) security under selective ID Model444In the Selective-ID security model, the adversary must submit a challenged role and role hierarchy before the start of the security game. This is essential in our security proof to set up the role public key (please refer Section 6.1 for more details). [25]. The CPA security can be illustrated using the following security game between a challenger and an adversary .

  • Initialization Adversary sends arbitrary role hierarchies for each uncorrupted system authorities. It also sends two challenged roles and of any two uncorrupted participating organizations/system authorities555Note that, the adversary can send more than two roles associated with any organization to the challenger. For simplicity, we consider two roles associated with two different organizations. to the challenger .

  • Setup Challenger runs Init to generate system public parameters for each uncorrupted system authority . It also generates role public key for the role of all the uncorrupted system authorities. It also generate re-encryption keys for each pair of uncorrupted system authorities. The challenger sends the public parameters, i.e., , role public key and the re-encryption keys to adversary .

  • Phase 1 Adversary submits two roles and so that (i.e., ) and (i.e., ). It also sends an identity to the challenger . Here the challenged identity can be associated with any of the uncorrupted system authorities. The challenger initiates PrivKeyGen and RoleKeyGen algorithms to generate private key, public key and role key and sends them to the adversary . The adversary sends queries for the secret keys to the challenger by polynomially many times.

  • Challenge When the adversary decides that Phase 1 is completed, he/she submits two equal length messages and . The challenger flips a random coin and encrypts the message by initiating MultiENC algorithm.

  • Phase 2 Same as Phase 1.

  • Guess Adversary outputs a guess of . The advantage of the adversary to win this game is .

Definition 4.1.

The proposed scheme is secure against chosen plaintext attack if is negligible for any polynomial time adversary .

Remark 1.

Note that, the challenger sends re-encryption keys to the adversary in the Setup phase. As such, the adversary can re-encrypt the ciphertexts by itself. In addition, we do not consider the Enc oracle, as the adversary can get the same response for the queries from the MultiEnc oracle.

5 Proposed Scheme

In this section, an overview of the proposed scheme is presented followed by its main constructions. In the construction, the Single-Organization Role-Based Encryption (SO-RBE) mechanism is presented first, followed by the Multi-Organization Role-Based Encryption (MO-RBE) mechanism.

5.1 Overview

Although the existing RBE schemes [7, 13] provide access control over encrypted data by enforcing RBAC access policy, these schemes cannot be applied in multi-organization cloud storage systems. Our main challenge is to construct a RBE scheme for both single and multi-organization cloud storage systems that support efficient decryption and user revocation.

In the proposed model, the system administrator of an organization maintains a Role Key Hierarchy (RKH) associated with a role hierarchy. In a RKH, each role is associated with a role public key and a group of users who hold that role. For each user in the group, a role-manager, who maintains that group, issues a unique role-key. The role-key is computed in such a way that it can decrypt any encrypted data computed using role public keys of any descendant roles. That is, if a user holds a role-key associated with the role , the user can decrypt any ciphertext computed using role public key associated with the role if and only if belongs to the ancestor set of (i.e., ). For better illustration, Figure 3 shows a sample RKH of seven roles. Suppose, a data owner encrypts a message using the role public key then any user holding roles can decrypt it using their role-keys, as . Similarly, if the data owner encrypts another message using role public key then the ciphertext can be decrypted only by the users who hold roles and , as .

In order to share data with the users of other organizations, a joint role public key is computed by combining the role public keys of the participated organizations. The joint role public key is then used to encrypt data. The encrypted data is further re-encrypted in such a way that any user who holds a qualified role of a participated organization can decrypt. That is, the role held by the user should belong to an ancestor set of a role associated with the joint role public key. This implies that the same piece of information can be shared with the authorized users irrespective of which organization they belong to.

The outsourced decryption is achieved by enabling the public cloud to perform computationally expensive operations during decryption process. To achieve this, the users delegate their role-keys to the public cloud in such a way that the public cloud partially decrypts requested ciphertexts using the delegated role-keys without knowing the actual content of ciphertexts.

5.2 Single-Organization RBE (SO-RBE)

In this subsection, the proposed SO-RBE mechanism is presented. It consists of the following six phases.

5.2.1 System Initialization

In this phase, a system administrator, say , generates system public parameter and master secret . The system public parameter is kept in a public bulletin board while the master secret is kept secret. It consists of Init algorithm which is explained next.

  • Init : chooses two multiplicative cyclic groups of a large prime order , a generator , a collision resistant hash function and a bilinear map . It also chooses random numbers . It then computes and . The system public parameter is , where and the master secret is , where . keeps and in its private cloud. also sends to each role-manager of the organization.

5.2.2 Manage Role

In this phase, a system administrator, say , generates secret role parameter . also generates role public key and role secret for each role in the organization. keeps the role public keys in its public bulletin board and keeps secret role parameter in a secure place. It also sends role secrets to the respective role-manager. This phase comprises RoleParaGen algorithm which is described next.

  • RoleParaGen : chooses random numbers . For each role in , it computes role public keys and role secret , where

    The secret role parameter is , where .

Remark 2.

With this scheme, it is assumed that the root role in the role hierarchy has more than two children roles to ensure that the role secrets are not disclosed to any other role manager (as with only two children roles each role-manager will know the other’s secret role parameter).

5.2.3 Key Generation

In this phase, a system administrator issues a pair of private, public keys and user secrets for each registered users. The role-manager also issues role-keys to the registered user. The issued private and role-keys are sent to the user using secure-channels while the public key is kept in the public bulletin board. On the other hand, system administrator keeps the user secrets in its private cloud so that the role-manager can access the stored user secrets from the private cloud during role-key generation process. This phase consists of two algorithms, namely PrivKeyGen and RoleKeyGen which are given next.

  • PrivKeyGen : Suppose a user, say , joins the system for the first time. System administrator, say , chooses a random number as a private key and computes the public key and user secret , where

  • RoleKeyGen : When a role-manager assigns a role to a user, this algorithm is initiated. Let a user holds a role . The role-manager first authenticate the user and gets his/her user secret from the private cloud. It then issues a role-key , where

    It is to be noted that and are known to the role-manager .

5.2.4 Encryption

In this phase, a data owner encrypts data before outsourcing it to the public cloud. The data owner first encrypts a random secret key using a RBAC access policy and then encrypts the actual data using the secret key. For the secret key encryption part, Enc algorithm is used, which is defined next. While, for the actual data encryption part, any secure symmetric key encryption algorithm, like Advanced Encryption Standards (AES), can be used. Finally, the data owner combines both the encrypted files and outsources it to the public cloud.

  • Enc : Let a data owner wants to encrypt message , where is the message space, using role . First, the message is encrypted using a random secret key, say , and generates a ciphertext . Afterwards, the secret key is encrypted using the role public key of the role . The encryption procedure is explained below.

    • data owner chooses a random number and computes and , where

    • finally, the data owner generates a ciphertext , where

5.2.5 Decryption

In this phase, a user accesses encrypted data by decrypting it using his/her private and role-keys. To take advantage of the outsourced decryption, the user first sends a transformed role-key to the public cloud, and the public cloud partially decrypts the requested ciphertexts using the transformed role-key and the public key of the user. Afterwards, the user decrypts the partially decrypted ciphertexts using his/her private key. This phase comprises DEC algorithm, which is described next.

  • Dec : Suppose a user , who holds a role , wants to decrypt a ciphertext , where . The user sends a data access request to the public cloud along with a transformed role-key and . The user chooses a random number and computes , where

    Afterwards, the user keeps the random number in a secure database for future use.

    The public cloud initiates outsourced decryption process once it received the transformed role-key from the user . In the outsourced decryption process, public cloud generates two ciphertext components, namely and . Let and denotes . Public cloud computes and as follows:

    Later on, public cloud sends the newly computed ciphertext components , , and to the user. The user gets using his/her private key and random secret as follows:

    Afterwards, the user decrypts using and gets the actual message . Finally, the user deletes the random secret from his/her database.

5.2.6 User Revocation

System administrator revokes users in this phase. It consists of URevoke algorithm which is described below.

  • URevoke (): Suppose, wants to revoke a user, say . simply removes the public key of the user from its public bulletin board so that public cloud can no longer use it for the outsourced decryption process. This, in turn, prevents the revoked user from accessing data.

5.3 Extension to Multi-Organization RBE (MO-RBE)

The SO-RBE mechanism can only be used to achieve access control over encrypted data in a single-organization cloud storage system. In this subsection, our MO-RBE mechanism is presented to achieve access control over encrypted data in the multi-organization cloud storage system. The MO-RBE is an extension of the SO-RBE mechanism which requires the following additional phases.

5.3.1 Role Public Key Update

In this phase, the system administrator of an organization computes joint role public key when it wants to share data with the users of other organizations. This phase comprises RolePubKeyUpdate algorithm which is described next.

  • RolePubKeyUpdate (): Suppose organization wants to share data with the users of organization. Let the system administrator wants to share data with its users who hold access privilege for the role and also with the users of holding access privilege for the role . The system administrator computes a joint role public key for the roles and , where