# Securing organization's data: A role-based authorized keyword search scheme with efficient decryption

Nazatul Haque Sultan, Maryline Laurent, Vijay Varadharajan

► To cite this version:

Nazatul Haque Sultan, Maryline Laurent, Vijay Varadharajan. Securing organization's data: A role-based authorized keyword search scheme with efficient decryption. IEEE Transactions on Cloud Computing, 2023, 11 (1), pp.25-43. 10.1109/TCC.2021.3071304. hal-04331375

HAL Id: hal-04331375

https://hal.science/hal-04331375v1

Submitted on 8 Dec 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Securing Organization's Data: A Role-Based Authorized Keyword Search Scheme with Efficient Decryption

Nazatul Haque Sultan, *Student Member, IEEE*, Maryline Laurent, *Member, IEEE*, and Vijay Varadharajan, *Senior Member, IEEE*

**Abstract**—For better data availability and accessibility while ensuring data secrecy, organizations often tend to outsource their encrypted data to the cloud storage servers, thus bringing the challenge of keyword search over encrypted data. In this paper, we propose a novel authorized keyword search scheme using Role-Based Encryption (RBE) technique in a cloud environment. The contributions of this paper are multi-fold. First, it presents a keyword search scheme which enables only the authorized users, having proper assigned roles, to delegate keyword-based data search capabilities over encrypted data to the cloud providers without disclosing any sensitive information. Second, it supports a multi-organization cloud environment, where the users can be associated with more than one organization. Third, the proposed scheme provides efficient decryption, conjunctive keyword search and revocation mechanisms. Fourth, the proposed scheme outsources expensive cryptographic operations in decryption to the cloud in a secure manner. Fifth, we have provided a formal security analysis to prove that the proposed scheme is semantically secure against Chosen Plaintext and Chosen Keyword Attacks. Finally, our performance analysis shows that the proposed scheme is suitable for practical applications.

**Index Terms**—Role-based encryption, role-based access control, searchable encryption, keyword search, outsourced decryption, provable security, cloud data privacy.

## I. INTRODUCTION

With the ever-increasing amount of digital information, individuals and organizations are now storing/outsourcing their data in the cloud to make use of features such as better accessibility, high availability, reduction of maintenance and initial investment costs [1]. However, with sensitive data stored in the cloud (e.g. see McAfee report [2]) and legal concerns (such as compliance to the European General Data Protection Regulation - GDPR<fnref n="1" />), security and privacy have become major issues in cloud data storage<fnref n="2" />. To preserve privacy and confidentiality of outsourced data in the cloud, a preferred

technique that is often used is encryption-before-outsourcing. The encryption-before-outsourcing technique enables the data owners (i.e. entities owning the data) to outsource their sensitive data in the cloud in an encrypted form. As such, no entity including the cloud service provider can access the sensitive plaintext data without having access to proper decryption key. This, however, restricts data retrieval/search over encrypted data [4]. A trivial solution is to download the whole encrypted database, and then perform the search operation locally after decryption. It is clear that this is not practical. An alternative approach is to allow the service provider to decrypt all the encrypted data so that it can perform search operation over the plaintext data. However, this violates data privacy.

Searchable Encryption (SE) has gained a considerable amount of interest from the research community to address the issue of searching over encrypted data [5]. In SE, users delegate data search capabilities for some keywords over the encrypted data to a service provider without disclosing any useful information about the searched keywords and the actual content of the encrypted data. This process is also referred to as keyword search. Typically, in keyword search, data owners outsource their data in an encrypted form along with an encrypted index of keywords. Whenever a user wants to access data, the user sends the desired keywords in the form of trapdoors to the service provider. In return, the service provider uses the trapdoors to perform search over the encrypted indexes and sends the associated encrypted data, if there is a match between the keywords associated with the trapdoor and encrypted indexes.

Many works have been done in the area of keyword search, achieving search authorization in a coarse-grained way. That is, the users can search all the keywords using their secret keys [6]. However, this kind of authorization may disclose sensitive information. For example, Organization A outsources its data files to the cloud so that its employees can easily access them. Assume Organization A is a participant in a consortium with another Organization B and other organizations. Suppose, some files are associated with the keywords "Organization B" and "Project X" which are only allowed to be accessed by the Managers in the Organization A. In this case, if an adversary can search for the keywords "Organization B" and "Project X" and gets all the encrypted files associated with these two keywords. This will eventually reveal, without knowing the actual content, that Organization A and Organization B are collaborating on Project X, which may not be desirable.

N. H. Sultan and M. Laurent are with the RST Department, Télécom SudParis, Institut Polytechnique de Paris, France.

E-mail: nazatulhaque.sultan@gmail.com; maryline.laurent@telecom-sudparis.eu

V. Varadharajan is with the Faculty of Engineering and Built Environment, Global Innovation Chair Professor at The University of Newcastle, Callaghan, Australia.

E-mail: Vijay.Varadharajan@newcastle.edu.au

<footnote n="1">¹https://ec.europa.eu/commission/priorities/justice-and-fundamental-rights/data-protection/</footnote>

<footnote n="2">²In this paper, cloud represents the public cloud that provides storage facilities to the general public (i.e., individuals and organizations). In general, the public cloud is maintained by a third-party entity referred to as *Cloud Service Provider* [3].</footnote>
To address this problem, several authorized keyword search schemes have been proposed for multi-user settings using different cryptographic techniques, e.g. Pairing-Based Encryption [7], Predicate Encryption [8] and Attribute-Based Encryption [6], [9], where multiple users are able to perform keyword search operations based on some access policies. However, none of these techniques efficiently support hierarchies in an organization, where higher level authorities can inherit access rights of their subordinates. As such, all these schemes [6]–[9] are not able to reflect efficiently organization’s policies and structures<fnref n="3" /> [11].

Role-Based Encryption (RBE) [10], [12], [13] is an emerging cryptographic technique, which combines both properties of the traditional Role-Based Access Control (RBAC) [14] and cryptographic encryption methods, to achieve data access control over encrypted data. In RBE, the data owner encrypts data using a RBAC access policy defined over some roles<fnref n="4" />, and any user having proper roles can derive the secret keys for decryption. Unlike the traditional RBAC method, RBE enables the data owners to define and enforce RBAC access policies on the encrypted data itself. This, in turn, reduces the dependency of the data owners on untrusted service provider for defining and enforcing access policies while sharing data with other authorized users. Moreover, similar to the RBAC, in RBE, roles can inherit access permissions from other roles [10]. Hence, the roles can be organized in a hierarchical structure. This is one of the main advantages of RBE over other encryption mechanisms such as Attribute-Based Encryption [15], [16], as it can reflect closely a real-world organisation's policies and structure. The inheritance property of the RBE makes it more suitable for large scale organizations such as enterprises with a complex hierarchical structures [10]. Therefore, RBE is a more suitable cryptographic technique for designing a keyword search mechanism compared with other cryptographic techniques such as the ABE.

RBE has been used to provide data access control in cloud environments over encrypted data [10], [11], [13]. However, they mainly focus on a single organization cloud environment scenario, where users can have roles only in a single organization and hence can access data associated with only that organization. In many practical scenarios in a cloud environment, a data owner may want to share his/her data with users in several organizations having different roles. For example, a user may work as a researcher and doctor in a clinical research laboratory and hospital respectively. As such, the same user will hold roles in the clinical research laboratory and the hospital. The data owner can specify a RBAC access policy in such a way that only the users having the access privileges for the roles “Researcher” and “Doctor” can gain access to the actual content corresponding to the encrypted data.

This paper further investigates the aforementioned research gaps and proposes a novel keyword search scheme using the RBE technique where organizations outsource their data

to a public cloud. The proposed scheme supports a multi-organization environment, where users can possess roles from more than one organization. It also enables the data owners to define and enforce RBAC access policies on encrypted data, thereby allowing any user having authorized roles to perform a keyword search along with the ability to decrypt. The salient features of the proposed scheme are as follows:

1) An authorized keyword search mechanism is proposed using RBE technique so that only the users possessing authorized roles can delegate keyword search capabilities over encrypted data to the public cloud.

2) The proposed scheme supports multi-organization cloud environment, where a user can be associated with more than one organization, having one or more roles in different organizations.

3) Conjunctive keyword search<fnref n="5" /> functionality is supported without any significant overhead in the system.

4) A user revocation mechanism has been introduced to revoke unintended users.

5) An outsourced decryption mechanism is combined with the proposed scheme enabling the users to delegate most of the computationally expensive cryptographic operations to the public cloud, thereby reducing the overhead on the user-side.

6) A formal security analysis of the proposed scheme has been given demonstrating that the scheme is secure against the Chosen Plaintext Attacks and the Chosen Keyword Attacks.

7) A performance analysis of the proposed scheme has been provided which shows that the proposed scheme is sufficiently efficient to be used in practical applications.

The organization of this paper is as follows: Section II presents a brief overview of some existing works related to the proposed scheme. Section III outlines the problem statement, where the system model, threat model, design and security goals, frameworks and security model of the proposed scheme are presented. Section IV gives a brief overview of the role hierarchy, bilinear pairing properties, a group key distribution technique, and some mathematical assumptions, which will be used throughout this paper. Section V details the proposed scheme including an overview followed by its main construction. Section VI presents a detailed security and performance analyses of the proposed scheme, and finally Section VII concludes this paper.

## II. RELATED WORKS

This section presents a brief overview of some notable works in the keyword search area, including some cryptographic RBAC based data access control schemes.

### A. Keyword Search over Encrypted Data

Data search over encrypted data has been extensively studied since the past decade. Song et al. presented the first practical symmetric key cryptography based searchable encryption scheme that can search full text over encrypted data

<footnote n="3">³In an organization, typically employees are organized in a hierarchical way based on their responsibilities and qualification [10].</footnote>

<footnote n="4">⁴In an organization, roles are typically created based on job functions.</footnote>

<footnote n="5">⁵In conjunctive keyword search, a user can search for multiple keywords in a single request [1].</footnote>
[17]. Leter, several searchable encryption schemes have been proposed, for various functionalities and security requirements, based on either symmetric key cryptography (SKC) [18]–[22] or public-key cryptography (PKC) [6], [9], [23]–[26].

In [18], Curtmola et al. proposed a SKC based keyword search scheme for multi-user settings<fnref n="6" />, which can perform single keyword search. In [19], Kamara et al. proposed a dynamic version of the scheme [18] that can add and delete files at any time efficiently. However, the scheme [19] leaks significant information while performing update operation [21]. In [20], Li et al. proposed a SKC based forward search privacy scheme, which prevents any leakage of information about the past queries. Later on, in [22], Liu et al. proposed a keyword search scheme which enables the users to verify the search results against the dishonest servers. Although the SKC based keyword search schemes provides better efficiency in terms computation cost, PKC based keyword search schemes provide more flexible and expressive search queries [9].

Recently, many PKC based authorized keyword search schemes have been proposed based on Attribute-Based Encryption (ABE) [6], [9], [25]–[27], where any user having a qualified set of attributes that satisfy an access policy can perform search operation using some keywords. That is, these schemes provide authorized keyword search, which allows only intended users to do the search in multi-user settings. In [9], [27], Sun et al. and Sultan et al. proposed keyword search schemes using ABE technique. The schemes provide both single and conjunctive keyword search without introducing any additional overhead in the system. In [6], Hu et al. proposed another ABE based keyword search scheme for dynamic policy update, where the data owners can securely update the access policies using proxy re-encryption and secret sharing techniques. In [25], Miao et al. proposed an ABE based keyword search scheme for hierarchical data, which also supports conjunctive keyword search. In [26], Chaudhari et al. proposed an authorized keyword search scheme using ABE, which hides the access policy from all the intended entities including the public cloud. However, all the aforementioned schemes do not support role hierarchy property and inheritance property.

## B. Cryptographic RBAC based Data Access Control

A cryptographic RBAC based data access control mechanism integrates the traditional RBAC model with cryptographic encryption method to enforce RBAC access policy on encrypted data. It enables the data to be encrypted using RBAC access policy defined over some role(s). Any user, possessing the required role(s) satisfying the associated RBAC access policy is allowed to decrypt the data. Some notable works in this area are [10], [11], [13], [28]–[32], where [28]–[32] are based on Hierarchical Key Assignment (HKA) method and [10], [11], [13] are based on RBE method.

Access control using HKA method has been studied in the early 1980s. In [28], Akl et al. presented the first cryptographic

<figure><img src="image_2.png" /><figcaption>Fig. 1: Proposed System Model</figcaption></figure>

hierarchical access control technique to solve the hierarchical multi-level security problem, where authorized users are allowed to possess different access privileges. 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 own encryption key and some public parameters. Later on, several other hierarchical access control schemes have been proposed using different techniques, e.g. [29]–[32]. However, the main drawback of the HKA schemes is the high complexity in setting up the encryption keys for a large set of users [10]. Also, the 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 update per user revocation which may incur a high overhead on the system.

In [10], Zhou et al. proposed the first RBE scheme for data sharing in an untrusted hybrid cloud environment. In [10], the ciphertexts and secret keys of the users are constant in size. This scheme also offers user revocation capability. In [13], Zhu et al. proposed another RBE scheme. In this scheme, the ciphertext size linearly increases with the number of roles. In [11], Perez et al. proposed a data-centric RBAC based data access control mechanism for cloud storage systems using the concept of proxy re-encryption and identity-based encryption techniques. To share data with the authorized users, the data owner generates proxy re-encryption keys based on some RBAC access policies and keeps the re-encryption keys along with the ciphertexts in the cloud storage servers. When an authorized user accesses the ciphertext, the service provider re-encrypts the ciphertext using the proxy re-encryption keys based on a RBAC access policy. However, none of [10], [11], [13] support multi-organization cloud storage systems, where the same user can possess roles from more than one independent organizations. Moreover, [10], [11], [13] do not address keyword search functionality.

<footnote n="6">⁶Multi-user settings enable the data owners to authorize any number of users to perform keyword search operations.</footnote>
# III. PROBLEM STATEMENT

This section presents the System Model, Threat Model, Design and Security Goals, Framework, and Security Models of the proposed scheme.

## A. System Model

Figure 1 shows the proposed system model, where the dotted and dark lines represent public channel and secure-channel such as SSL (Secure Sockets Layer) respectively. It comprises five entities, namely, System Authorities, Role-Managers, Data Owners, Users, and Public Cloud having the following responsibilities:

* **System Authority (SA):** Each organization has one SA, which maintains the role hierarchy of that organization. It generates system public parameters and master secrets for the organization. SA also maintains all the role-managers that are associated with the organization, and it issues secret keys for each role-manager. In addition, SA issues private and public keys for all the registered users. Further, it issues private, public and proxy re-encryption keys to the public cloud. Moreover, SA is responsible for revoking users from the system when needed.

* **Role-Manager (RM):** It is an entity of an organization which manages the role(s). Note that, the roles are assigned by the SA. In addition, it also issues and manages role-keys for the users.

* **Data Owners (owners):** It is an entity who owns the data and wants to outsource his/her data to the public cloud. An owner first encrypts data using a RBAC access policy before outsourcing to the public cloud. The owner first encrypts a plaintext data using a random secret key by following any secure symmetric key encryption algorithm, e.g., Advanced Encryption Standard (AES). Afterward, the owner chooses a set of keywords associated with the plaintext data and encrypts those keywords along with the random key using the chosen RBAC access policy. The owner then combines all the ciphertexts into one archive and outsources it to the cloud storage servers.

* **Users:** It is an entity who wants to access the outsourced data. Each user must register with SA(s) to receive private and public keys associated with the organization(s) from which he/she wants to access data. Also, a user receives a unique role-key for each role he/she possesses from the respective role-manager. When a user wants to access data, the user computes a trapdoor using his/her private keys, role-keys, the desired keyword(s) and sends it to the public cloud.

* **Public Cloud:** It is a third-party entity which manages the cloud storage servers. The main responsibility of the public cloud is to store owners' encrypted data. Moreover, it is also responsible for performing keyword search operation over the encrypted data. It is assumed that the public cloud correctly performs search operations using the received trapdoors if and only if the requested user has proper roles. It is also assumed that it partially decrypts all the ciphertexts that have a matching keyword(s) with the trapdoors.

## B. Threat Model

Public cloud is considered as an honest-but-curious entity. That is, public cloud honestly performs all the assigned tasks, but it may try to gain additional privacy information from the data available to it. The users may be malicious, and they may try to collude among themselves to gain access to the data beyond their access privileges. The users, having insufficient access rights, may also try to collude with the public cloud for gaining access to the data beyond their access rights. It is assumed that all the SAs and RMs are fully trusted entities. The threat model is supplemented by a Security Model in Section III-E.

## C. Design and Security Goals

The proposed scheme aims to achieve the following functionality and security goals.

**Functionality Goals:** The proposed scheme should provide the following functionalities.

1) **Authorized Keyword Search:** Only the users, having proper roles according to the defined RBAC access policy, are authorized to perform keyword search operations over the encrypted data. That is, any unintended users should not get access to the encrypted (outsourced) data.

2) **Role-Based Data Sharing:** Only the users, possessing the proper roles according to the defined RBAC access policy, can have access to the plaintext data through the decryption operation.

3) **Role Management by Multiple organizations:** The roles assigned to users can be managed by more than one organization and can be simultaneously used for data sharing and keyword search operations.

4) **Conjunctive Keyword Search:** Users can search for multiple keywords using a single search request.

5) **Outsourced Decryption:** Users can delegate most of the computationally expensive operation to the public cloud without disclosing any sensitive information.

6) **Prior Authentication:** The public cloud can authenticate a user before performing the costly keyword search and outsourced decryption operations for the user.

7) **Revocation:** Revocation is supported in two following ways:

* **Complete user revocation:** SA can prevent unintended users from accessing its data.

* **Role-level user revocation:** SA can revoke one or more roles of a user. The idea is that the revoked user can no longer use the revoked roles for accessing data, while the same user should be able to access data using his/her non-revoked roles if they are qualified enough according to the RBAC access policy.

**Security Goals:** The proposed scheme should fulfil the following security requirements:

1) **Data Confidentiality:** Any entity, including the public cloud should not be able to access the plaintext data unless they have proper roles satisfying the defined RBAC access policy. This security notion can be captured by
<table><caption>TABLE I: NOTATIONS</caption><thead><tr><th>Notation</th><th>Description</th></tr></thead><tbody><tr><td>q</td><td>a large prime number</td></tr><tr><td>G<sub>1</sub>, G<sub>T</sub></td><td>two cyclic multiplicative groups of order q</td></tr><tr><td>H<sub>1</sub>(.), H<sub>2</sub>(.)</td><td>hash functions H<sub>1</sub>: {0, 1}<sup>*</sup> → Z<sub>q</sub><sup>*</sup> and H<sub>2</sub>: G<sub>1</sub> → Z<sub>q</sub><sup>*</sup></td></tr><tr><td>Φ</td><td>set of system authorities in the system</td></tr><tr><td>m</td><td>total number of system authorities in the system</td></tr><tr><td>Ψ<sub>k</sub></td><td>set of roles associated with a role hierarchy of the k<sup>th</sup> system authority</td></tr><tr><td>Γ</td><td>set of all roles associated with a ciphertext</td></tr><tr><td>Γ<sub>Φ</sub></td><td>system authorities associated with a ciphertext</td></tr><tr><td>S<sub>ID<sub>u</sub></sub></td><td>set of roles associated with the user ID<sub>u</sub></td></tr><tr><td>r<sub>k,i</sub></td><td>i<sup>th</sup> role managed by k<sup>th</sup> system authority</td></tr><tr><td>R<sub>k,i</sub></td><td>the set of ancestor roles of r<sub>k,i</sub></td></tr><tr><td>ID<sub>u</sub></td><td>unique identity of the u<sup>th</sup> user</td></tr><tr><td>ID<sub>c</sub></td><td>unique identity of the public cloud</td></tr><tr><td>RM<sub>r<sub>k</sub></sub></td><td>role-manager which manages role r<sub>k</sub></td></tr><tr><td>ts</td><td>current timestamp</td></tr></tbody></table>

*Semantic Security.* This security notion is also referred to as *Indistinguishability against Chosen Plaintext Attack (IND-CPA).*

2) **Keyword Secrecy:** Using unqualified search requests or trapdoors, any entity including the public cloud should not be able to learn any useful information about the plaintext keywords associated with the encrypted data. Similarly, any outsider (neither the requesting user nor the public cloud) should be able to learn any useful information about the keywords from the trapdoors. These two security notions can be captured by *Keyword Semantic Security.* This security notion is also referred to as *Indistinguishability against Chosen Keyword Attack (IND-CKA).*

3) **Forward and Backward Secrecy:** Forward secrecy represents that any new user having qualified roles should be able to decrypt the ciphertexts which are encrypted before he/she joined the system. Backward secrecy represents that a revoked user should not be able to decrypt the ciphertexts which are published after his/her revocation using the revoked roles.

4) **Resistance against Replay Attacks:** If one or more valid trapdoor is exposed to an adversary, the adversary should not be able to launch replay attacks. Many recent keyword search schemes, e.g., [6], [9] are susceptible to replay attacks if the trapdoors are exposed, as the adversary can re-use the exposed trapdoors using a fresh random number each time she/he wants to perform a keyword search.

## D. Framework

Broadly the proposed scheme is divided into nine main phases, namely, *System Setup*, *Management of Roles*, *Public Cloud Key Generation*, *New User Enrolment*, *Role Assignment*, *Data Encryption*, *Trapdoor Generation*, *Data Search*, and *Decryption*. SAs initiate the *System Setup* phase to generate mutually agreed public parameters and master secret through the *SYSTEM SETUP* algorithm. SA performs the *Manage of Role* phase to initialize its role hierarchy and generates role related parameters (both public and secret parameters). It also generates proxy re-encryption keys for the public cloud.

It consists of the MANAGEROLE algorithm. SA generates private and public keys for the public cloud in the *Public Cloud Key Generation* phase using the *PUBCLOUDKEYGEN* algorithm. In the *New User Enrolment* phase, SA mainly issues private and public keys for each registered users through the USERPRIVKEYGEN algorithm. Role-managers perform *Role Assignment* phase, where they assign roles in the form of role-keys to the users based on their responsibilities and profile in the organization. It consists of the USERROLEKEYGEN algorithm. In the *Data Encryption* phase, the owner encrypts data and associated keywords using a RBAC access policy. It consists of the ENC algorithm. To perform keyword search as well as outsourced decryption, the users generate trap-doors in the *Trapdoor Generation* phase using the TRAP-GEN algorithm. The public cloud performs the *Data Search* phase, which consists of AUTHENTICATION, KEYSEARCH, and PARTIALDEC algorithms. In the AUTHENTICATION, the public cloud authenticates the requesting user and checks freshness of the keyword search request (i.e., trapdoor) to prevent any replay attacks. In the KEYSEARCH, the public cloud performs keyword search operation on the encrypted data using the received trapdoor. In the PARTIALDEC, the public cloud performs outsourced decryption operations. In this algorithm, the public cloud partially decrypts the ciphertexts which are returned by the KEYSEARCH algorithm. Finally, the user performs *Decryption* phase to decrypt all the partially decrypted ciphertexts received from the public cloud. This phase comprises DEC algorithm. A brief overview of the different algorithms of these phases are explained next. The notations used in this paper are shown in Table I.

* SYSTEMSETUP ((PP, {MS<sub>k</sub>}<sub>v∈F</sub>) ← 1<sup>Λ</sup>): It takes a security parameter Λ as input. It outputs public parameter PP and master secret MS<sub>k</sub> for each SA in the system.

* MANAGEROLE ((RP<sub>k</sub>, {PK<sub>r<sub>k</sub></sub>}<sub>v∀r<sub>k</sub>∈Ψ<sub>k</sub></sub>, {RS<sub>r<sub>k</sub></sub>}<sub>v∀r<sub>k</sub>∈Ψ<sub>k</sub></sub>, {PKey<sub>r<sub>k</sub></sub><sup>r<sub>v</sub></sup>}<sub>v∀r<sub>k</sub>∈R<sub>i</sub><sup>r<sub>k</sub></sup>\{r<sub>i</sub><sup>r<sub>k</sub></sup></sub></sub>) ← (H, PP)): It takes a role hierarchy H and public parameter PP as input. It outputs role secret parameter RP<sub>k</sub>, and for each role r<sub>i</sub><sup>r<sub>k</sub></sup>∈ Ψ<sub>k</sub>, it outputs the role public key PK<sub>r<sub>k</sub></sub>, role secret RS<sub>r<sub>k</sub></sub> and proxy re-encryption keys PKey<sub>r<sub>k</sub></sub><sup>r<sub>v</sub></sup>.

* PUBCLOUDKEYGEN ((Priv<sub>c</sub><sup>k</sup>, Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) ← (PP, MS<sub>k</sub>, ID<sub>c</sub>): It takes public parameter PP, master secret MS<sub>k</sub> and identity ID<sub>c</sub> of the public cloud as input. It outputs a private key Priv<sub>c</sub><sup>k</sup> and two public keys (Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) for the public cloud.

* USERPRIVKEYGEN ((SK<sub>ID<sub>u</sub></sub><sup>k</sup>, Pub<sub>ID<sub>u</sub></sub><sup>k</sup>, US<sub>ID<sub>u</sub></sub>) ← (MS<sub>k</sub>, PP, ID<sub>u</sub>): It takes master secret MS<sub>k</sub>, public parameter PP, and unique identity of a user ID<sub>u</sub> as input. It outputs a secret key SK<sub>ID<sub>u</sub></sub><sup>k</sup>, a public key Pub<sub>ID<sub>u</sub></sub><sup>k</sup> and a user secret US<sub>ID<sub>u</sub></sub> for the user ID<sub>u</sub>.

* USERROLEKEYGEN ((RK<sub>r<sub>x</sub></sub><sup>1,u</sup>, RK<sub>r<sub>x</sub></sub><sup>2,u</sup>) ← (PP, US<sub>ID<sub>u</sub></sub>, RS<sub>r<sub>x</sub></sub><sup>r<sub>x</sub></sup>, t<sub>r<sub>x</sub></sub><sup>r<sub>x</sub></sup>): It takes public parameter PP, user secret US<sub>ID<sub>u</sub></sub>, and role secret RS<sub>r<sub>x</sub></sub><sup>r<sub>x</sub></sup>, role related secret t<sub>r<sub>x</sub></sub><sup>r<sub>x</sub></sup> ∈ Z<sub>q</sub><sup>*</sup> of r<sub>x</sub><sup>r<sub>x</sub></sup> as input. It outputs two role-keys (RK<sub>r<sub>x</sub></sub><sup>1,u</sup>, RK<sub>r<sub>x</sub></sub><sup>2,u</sup>) associated with the role r<sub>x</sub><sup>r<sub>x</sub></sup> for the user ID<sub>u</sub>.
• **ENC** (CT $\leftarrow$ (PP, $\text{Pub}_c^{1k}$, $\text{Pub}_c^{2k}$, M, W, $\Gamma$, $\Gamma_\Phi$)): It takes public parameter PP, both the public keys ($\text{Pub}_c^{1k}$, $\text{Pub}_c^{2k}$) of the public cloud, actual plaintext message M, keyword set W (associated with the actual plaintext message M), a RBAC access policy $\Gamma$, and a set $\Gamma_\Phi$ of SAs which are associated with $\Gamma$ as input. It outputs a ciphertext CT.

• **TRAPGEN** ((Trap, v) $\leftarrow$ ({RK$_{x}^{1,u}$, RK$_{x}^{2,u}$}$_{v \in r_k^* \in S_{\text{ID}_u}}$, SK$_{\text{ID}_u}^{k}$, S$_{\text{ID}_u}$, w)): It takes both the role-keys (RK$_{x}^{1,u}$, RK$_{x}^{2,u}$), secret key SK$_{\text{ID}_u}^{k}$, user role set S$_{\text{ID}_u}$ of a user ID$_u$, and keyword w as input. It outputs a trapdoor Trap and a random number v $\in \mathbb{Z}_q^*$.

• **AUTHENTICATION** $((V_3^1 / \perp) \leftarrow (\{\text{Priv}_c^k\}_{v_k \in \Gamma_\Phi}, \text{Trap}, \text{Pub}_{\text{ID}_u}^k, \text{ID}_u, \text{ts}'))$: It takes private keys of the public cloud $\text{Priv}_c^k$ issues by all the system authorities in the set $\Gamma_\Phi$, trapdoor Trap, public key $\text{Pub}_{\text{ID}_u}^k$ of a user ID$_u$, identity ID$_u$ of the user, and current timestamp ts' as input. If the user ID$_u$ is legitimate and the trapdoor was not previously issued, it outputs $V_3^1$ for a successful authentication. Otherwise, it outputs $\perp$ which represents either an unsuccessful authentication or an invalid trapdoor.

• **KEYSEARCH** ((CT/ $\perp$) $\leftarrow$ (CT, Trap, $V_1^3$)): It takes trapdoor Trap, $V_1^3$ and a ciphertext CT as input. It outputs the ciphertext CT if and only if for all $r_i^k \in \Gamma$ there is $r_x^k \in S_{\text{ID}_u}$ such that $r_x^k \in \mathbb{R}_{r_i^k}$ and the keyword w associated with the trapdoor has a match with a keyword associated with the ciphertext CT. Otherwise, it outputs $\perp$, which represents an unsuccessful search operation.

• **PARTIALDEC** ($\text{CT}' \leftarrow$ (CT, Trap, {$\text{Priv}_c^k$}$_{v_k \in \Gamma_\Phi}$, S$_{\text{ID}_u}$)): It takes the ciphertext CT, trapdoor Trap, private keys $\text{Priv}_c^k$ of the public cloud associated with the system authorities in $\Gamma_\Phi$, and user role set S$_{\text{ID}_u}$ as input. It outputs a partially decrypted ciphertext CT'.

• **FULLDEC**($M \leftarrow$ (CT', $\text{Priv}_{\text{ID}_u}$, v)): It takes the partially decrypted ciphertext CT', user private key $\text{Priv}_{\text{ID}_u}$, and v as input and outputs the actual plaintext message M.

## E. Security Model

The two games, namely, *Semantic Security against Chosen Plaintext Attack* (IND-CPA) and *Semantic Security against Chosen Keyword Attack* (IND-CKA) are used to define the security model of the proposed scheme. These two games are defined next.

1) *Semantic Security against Chosen Plaintext Attack:* The semantic security of the proposed scheme defined on *Chosen Plaintext Attack* (CPA) security under *Selective-ID Model*<fnref n="7" />. The CPA security can be illustrated using the following security game IND-CPA between a challenger *C* and an adversary *A*₁.

**INIT** Adversary $\mathcal{A}_1$ sends a challenged role set $\Gamma^*$, a keyword w and two identities $\text{ID}_u^*$, $\text{ID}_c^*$ to the challenger *C*.

**SETUP** Challenger runs the SYSTEMSETUP algorithm to generate public parameters and master secrets. Challenger *C* generates role public keys, role secrets and proxy re-encryption keys using the MANAGEROLE algorithm. It also generates public and private keys using the PUBCLOUDKEYGEN and USERPRIVKEYGEN algorithms. Challenger *C* sends the public parameter, role public keys, proxy re-encryption keys, public and private keys to the adversary $\mathcal{A}_1$. It keeps the master secret and role secrets in a secure place.

**PHASE 1** Adversary $\mathcal{A}_1$ submits a role set $S^*$ to the challenger *C* for role-keys so that there exists at least one role $r_x^k \in S^*$ such that $r_x^k \notin \mathbb{R}_{r_i^k}$, where $r_i^k \in \Gamma^*$. Challenger *C* runs the USERROLEKEYGEN algorithm to generate role-keys for the adversary $\mathcal{A}_1$. Adversary $\mathcal{A}_1$ can send queries for the role-keys to the challenger *C* by polynomially many times.

**CHALLENGE** When adversary $\mathcal{A}_1$ decides that PHASE 1 is over, it submits two equal length messages $K_0$ and $K_1$, which were not challenged before, to the challenger *C*. Challenger *C* flips a random binary coin $\omega$ and encrypts message $K_\omega$ using the ENC algorithm for the challenged role set $\Gamma^*$. Challenger *C* sends the encrypted message of $K_\omega$ to adversary $\mathcal{A}_1$.

**PHASE 2** Same as PHASE 1.

**GUESS** Adversary $\mathcal{A}_1$ outputs a guess $\omega'$ of $\omega$. The advantage of winning this game for adversary $\mathcal{A}_1$ is $Adv_{\mathcal{A}_1}^{\text{IND-CPA}} = |\text{Pr}[\omega' = \omega] - \frac{1}{2}|$.

**Definition III.1.** The proposed scheme is secure against chosen plaintext attack if $Adv_{\mathcal{A}_1}^{\text{IND-CPA}}$ is negligible for any polynomial time adversary $\mathcal{A}_1$.

2) *Semantic Security against Chosen Keyword Attack:* The semantic security of the proposed keyword search scheme defined on Chosen Keyword Attack (CKA) security under the same *Selective ID Model* as described in Section III-E1. The CKA security can be demonstrated using the following security game IND-CKA between a challenger *C* and an adversary $\mathcal{A}_2$.

**INIT** Adversary $\mathcal{A}_2$ sends a set of challenged roles $\Gamma^*$ and two identities $\text{ID}_u^*$, $\text{ID}_c^*$ to the challenger *C*.

**SETUP** Challenger runs the SYSTEMSETUP algorithm to generate public parameters and master secrets. Challenger *C* generates role public keys, role secrets and proxy re-encryption keys using the MANAGEROLE algorithm. It also generates public and private keys using PUBCLOUDKEYGEN algorithm and a public key using USERPRIVKEYGEN algorithm. Challenger *C* sends the public parameter, role public keys, proxy re-encryption keys, public and private keys to the adversary $\mathcal{A}_2$. It keeps the master secret and role secrets in a secure place.

**PHASE 1** Adversary $\mathcal{A}_2$ submits a set of roles $S^*$ and a keyword w to the challenger *C* so that there exists at least one role $r_x^k \in S^*$ such that $r_x^k \notin \mathbb{R}_{r_i^k}$, where $r_i^k \in \Gamma^*$. Challenger initiates the TRAPGEN algorithm to generate a trapdoor for the adversary $\mathcal{A}_2$. Finally, challenger *C* sends the generated trapdoor to the adversary $\mathcal{A}_2$. Afterwards, adversary $\mathcal{A}_2$ can send queries for the trapdoor to the challenger *C* by polynomially many times.

**CHALLENGE** When adversary $\mathcal{A}_2$ decides that PHASE 1 is completed, it submits two equal length keywords $w_0$ and

<footnote n="7">⁷In the Selective-ID security model, the adversary must submit a set of challenged roles before starting the security game. This is essential in our security proof to set up the role public key (please refer Section VI-A for more details).</footnote>
<figure><img src="image_3.png" /><figcaption>Fig. 2: Sample Role Hierarchy (RH)</figcaption></figure>

$w_1$, which were not challenged before, to the challenger $C$. Challenger $C$ flips a binary coin $\omega$ and encrypts keyword $w_\omega$ using the ENC algorithm for the challenged role set $\Gamma^*$. Challenger $C$ sends the encrypted ciphertext of $w_\omega$ to the adversary $\mathcal{A}_2$.

**PHASE 2 Same as PHASE 1.**

**GUESS** Adversary $\mathcal{A}_2$ outputs a guess $\omega'$ of $\omega$. The advantage of winning this game for adversary $\mathcal{A}_2$ is
$$Adv_{\mathcal{A}_2}^{IND-CKA} = |\Pr[\omega' = \omega] - \frac{1}{2}|.$$

**Definition III.2.** The proposed scheme is secure against the chosen keyword attack if $Adv_{\mathcal{A}_2}^{IND-CKA}$ is negligible for any polynomial time adversary $\mathcal{A}_2$.

# IV. PRELIMINARIES

This section presents an overview of a role hierarchy and bilinear pairing. It also presents an overview of a group key distribution mechanism and a mathematical assumption which is used in this paper.

## A. Role Hierarchy notations

In the proposed scheme, roles are organized in a hierarchy where ancestor roles can inherit access privileges of its descendant roles. Figure 2 shows two sample role hierarchies, namely Role Hierarchy 1 (Figure 2a) and Role Hierarchy 2 (Figure 2b). We consider Role Hierarchy 1 (Figure 2a) as an example to define the following notations of a role hierarchy.

* $r_r^k$: root role of a role hierarchy. We assume that in any role hierarchy there can be only one root role.

* $\Psi_k$: set of all roles in the role hierarchy. For example, $\Psi_k = \{r_r^k, r_1^k, r_2^k, r_3^k, r_4^k, r_5^k, r_6^k, r_7^k, r_8^k\}$

* $\mathbb{R}_{r^k}$: ancestor set of the role $r_r^k$. For example, $\mathbb{R}_{r^k} = \{r_r^k, r_1^k, r_2^k, r_4^k, r_5^k, r_6^k, r_7^k, r_8^k\}$, $\mathbb{R}_{r^k} = \{r_r^k, r_1^k, r_2^k, r_4^k, r_6^k\}$ and $\mathbb{R}_{r^k} = \{r_r^k, r_1^k, r_2^k, r_4^k, r_6^k\}$.

## B. Bilinear Pairing

Let $\mathbb{G}_1$ and $\mathbb{G}_T$ be two cyclic multiplicative groups of order $q$. Let $g$ be a generator of $\mathbb{G}_1$. The bilinear map $\hat{e} : \mathbb{G}_1 \times \mathbb{G}_1 \to \mathbb{G}_T$ has the following properties:

* Bilinear: $\hat{e}(g^a, g^b) = \hat{e}(g, g)^{ab}$, $\forall g \in \mathbb{G}_1$ and $\forall (a, b) \in \mathbb{Z}_q^*$

* Non-degenerate: $\hat{e}(g, g) \neq 1$

* Computable: $\hat{e}(g, g)$ is efficiently computable for all $g \in \mathbb{G}_1$

## C. Group Key Distribution

In [33], Burmester et al. proposed a two round group key distribution scheme using the concept of Diffie-Hellman assumption. Their scheme works as follows:

Let $\mathcal{U} = \{\text{ID}_1, \text{ID}_2, \dots, \text{ID}_n\}$ be the group of $n$ users. Suppose the users are arranged into a cycle. To compute a group key among the users, each user $\text{ID}_i \in \mathcal{U}$ selects a random secret number $a_i \in \mathbb{Z}_q^*$ and broadcasts $x_i = g^{a_i}$ where $g$ is a generator of group $\mathbb{G}_1$. Afterward, it publishes $X_i = (\frac{x_{i+1}}{x_{i-1}})^{a_i}$. Finally, each user $\text{ID}_i$ in the group computes a common key $\text{CK} = g^{a_1 \cdot a_2 + a_2 \cdot a_3 + \dots + a_n \cdot a_1}$ without knowing others' secrets and without disclosing the common key to any other unintended entities.

## D. Decisional Bilinear Diffie-Hellman (DBDH)

Let $\mathbb{G}_1$ and $\mathbb{G}_T$ be two cyclic multiplicative groups of order $q$. Let $g$ be a generator of $\mathbb{G}_1$ and $\hat{e} : \mathbb{G}_1 \times \mathbb{G}_1 \to \mathbb{G}_T$ be an efficiently computable non-degenerate bilinear map. The Decisional Bilinear Diffie-Hellman (DBDH) Assumption is defined as follows: No probabilistic polynomial time adversary is able to distinguish the tuples $\langle g, g^a, g^b, g^c, Z = \hat{e}(g, g)^{abc} \rangle$ and $\langle g, g^a, g^b, g^c, Z = \hat{e}(g, g)^z \rangle$ with non-negligible advantage, where $(a, b, c, z) \in \mathbb{Z}_q^*$ are randomly chosen.

# V. PROPOSED SCHEME

This section presents the proposed scheme in details. First, a brief overview of the proposed scheme is presented, followed by its main construction.

## A. Overview

The main goal of the proposed scheme is to enable the owners to enforce RBAC access policies on the encrypted data so that only the users with the authorized roles can perform the keyword search along with efficient data decryption. To achieve this, the proposed scheme devises a novel RBE technique that enables only the users having authorized roles satisfying the specified RBAC access policy to delegate the keyword search capability to the public cloud without disclosing any sensitive information. To reduce decryption cost at the user side, the devised RBE technique also enables the authorized users to delegate computationally expensive cryptographic operations to the public cloud.

In the proposed scheme, each organization is allowed to maintain its own role hierarchy, and each role hierarchy is associated with a Role-Key Hierarchy (RKH). In Figure 3, a sample RKH is shown. Each node in a RKH represents a role, and each role, say $r_i^k$, is associated with a role public key, say $\text{PK}_{r_i^k}$. In addition, each role is associated with a set of users who have
<figure><img src="image_4.png" /><figcaption>Fig. 3: Sample Role Key Hierarchy (RKH)</figcaption></figure>

In the proposed scheme, each organization is allowed to maintain its own role hierarchy, and each role hierarchy is associated with a Role-Key Hierarchy (RKH). In Figure 3, a sample RKH is shown. Each node in a RKH represents a role, and each role (except the root role), say $r_i^k$, is associated with a role public key, say $PK_{r_i^k}$. In addition, each role (except the root role) is associated with a set of users who have that role, and the users are assigned with a unique pair of role-keys for each role they possess<fnref n="8" />. The role-keys are generated in such a way that the user can use them to compute trapdoors to perform a keyword search over the ciphertexts, which are encrypted using a role public key of any descendent role. The same trapdoor can also be used to perform the outsourced decryption operation. This in turn enables the users to gain access to the actual plaintext data. This process is illustrated as follows. Let us assume that the owner wants to authorize all the users having access privileges for the role $r_5^k$ to have access to data. The owner encrypts the data and the associated keywords using the role public key $PK_{r_5^k}$. Any user who possesses any one of the roles in $\mathbb{R}_{r_5^k} = \{r_1^k, r_2^k, r_3^k, r_4^k\}$ can search and decrypt the encrypted data using their respective role-keys. That is, the user possesses a qualified role for accessing the ciphertext. Similarly, if the owner encrypts data and associated keywords using the role public keys $PK_{r_1^k}$ and $PK_{r_4^k}$, then any user who possesses roles in $\mathbb{R}_{r_1^k} = \{r_1^k, r_2^k\}$ and $\mathbb{R}_{r_4^k} = \{r_3^k, r_4^k\}$ respectively can perform keyword search and data decryption using their respective role-keys.

To support multi-organization data sharing, the proposed scheme takes advantage of an existing group key distribution

protocol to generate a common master secret for all the participating organizations. This master secret is used for generating the system parameters, including public parameters and master secrets of each organizations. This allows a user to possess more than one role from different organizations. More details are given in the following subsection.

## B. Construction

A detailed description of all the phases of the proposed scheme is presented as follows.

1) **System Setup:** In this phase, the system authority of each organization mutually publishes the system public parameter, and they generate their own master secrets. This phase consists of the SYSTEM SETUP algorithm which is defined next.

a) **SYSTEM SETUP** ((PP, {$MS_k$}$_{∀k \in \Phi}$) ← $1^\Lambda$): It chooses two cyclic multiplicative bilinear groups $G_1$ and $G_T$ of order $q$, where $q$ is a large prime number. It also chooses a generator $g \in G_1$, random numbers {$\eta_k, \mu_k, x_k$}$_{∀k \in \Phi} \in \mathbb{Z}_q^*$ and two hash functions $H_1: \{0, 1\}^* \to \mathbb{Z}_q^*$, $H_2: G_1 \to \mathbb{Z}_q^*$. Afterward, all the system authorities follow a group key generation protocol, as described in Section IV-C, to compute a shared secret $g^y$, where $y = y_1 \cdot y_2 + y_3 \cdot y_4 + \dots + y_m \cdot y_1$ and $m$ is the total number of system authorities. Afterward, it computes $Y = \hat{e}(g, g)^y$ and $h_1^k = g^{\eta_k}$, and then publishes the system public parameter PP = $\langle G_1, G_T, g, \hat{e}, H_1, H_2, Y, \{h_1^k\}_{\forall k \in \Phi} \rangle$. Each system authority, say $k^{th}$ system authority $SA_k$, keeps master secret $MS_k = \langle g^y, \eta_k, \mu_k, x_k \rangle$ in a secure place.

**Remark 1.** All the system authorities can check validity of $Y$ by comparing $\hat{e}(g^y, g) \stackrel{?}{=} Y$. Also, any number of new system authorities can be added in the system at any time by sharing the existing group secret key, i.e., $g^y$.

<footnote n="8">⁸In our proposed scheme, the root role ($r_i^k$) is not assigned to any users and is internally managed by the SA. As such, we do not consider any user set with the root role in Figure 3. More details are given in the following sections.</footnote>
2) Management of Roles: In this phase, a system authority generates the role related parameters. Suppose the system authority SA<sub>k</sub> wants to initialize a role hierarchy H. The system authority SA<sub>k</sub> generates role secrets RS<sub>r<sub>i</sub><sup>k</sup></sub> and role public keys PK<sub>r<sub>i</sub><sup>k</sup></sub> for each role r<sub>i</sub><sup>k</sup> associated with H. It also computes proxy re-encryption keys {PKey<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>r<sub>i</sub><sup>k</sup>∈R<sub>r<sub>i</sub><sup>k</sup></sub>\{r<sub>i</sub><sup>k</sup>}</sub> for each role r<sub>i</sub><sup>k</sup> (except the root role) associated with the role hierarchy H. It stores the role public keys in its public bulletin board and keeps the role secrets in a secure place. It also shares each role secret to its corresponding role-manager. That is, the role secret associated with r<sub>i</sub><sup>k</sup>, i.e., RS<sub>r<sub>i</sub><sup>k</sup></sub> is shared with the role-manager which manages r<sub>i</sub><sup>k</sup>, i.e., RM<sub>r<sub>i</sub><sup>k</sup></sub>. Moreover, the proxy re-encryption keys are sent to the proxy-server (i.e., public cloud) using secure-channels. This phase consists of the MANAGEROLE algorithm which is defined next.

a) MANAGEROLE ((RP<sub>k</sub>, {PK<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈Ψ<sub>k</sub></sub>, {RS<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈Ψ<sub>k</sub></sub>, {PKey<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈R<sub>r<sub>i</sub><sup>k</sup></sub>\{r<sub>i</sub><sup>k</sup>}</sub> ) ← (H, PP)): It selects random numbers {t<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈Ψ<sub>k</sub></sub> ∈ Z<sub>q</sub><sup>*</sup>. It computes role secrets RS<sub>r<sub>i</sub><sup>k</sup></sub>, role public key PK<sub>r<sub>i</sub><sup>k</sup></sub> = ⟨PK<sub>r<sub>i</sub><sup>k</sup></sub>, r<sub>i</sub><sup>k</sup>, R<sub>r<sub>i</sub><sup>k</sup></sub>⟩ and proxy re-encryption key {PKey<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈R<sub>r<sub>i</sub><sup>k</sup></sub>\{r<sub>i</sub><sup>k</sup>}</sub> for each role r<sub>i</sub><sup>k</sup> ∈ (Ψ<sub>k</sub> \ {r<sub>i</sub><sup>k</sup>}), where

$$
\begin{align}
\mathrm{RS}_{r_i^k} &= \prod_{\forall r_j^k \in \mathbb{R}_{r_j^k}} t_{r_j^k} \\
\mathrm{PK}_{r_i^k} &= g \prod_{\forall r_j^k \in \mathbb{R}_{r_j^k}} t_{r_j^k} \\
\mathrm{PKey}_{r_i^k}^{r_j^k} &= \prod_{\forall r_j^k \in \mathbb{R}_{r_j^k}} t_{r_j^k} \tag{1}
\end{align}
$$

R<sub>r<sub>i</sub><sup>k</sup></sub> is the set of ancestor roles of r<sub>i</sub><sup>k</sup> and role secret parameter RP<sub>k</sub> = ⟨{t<sub>r<sub>i</sub><sup>k</sup></sub>}<sub>∀r<sub>i</sub><sup>k</sup>∈Ψ<sub>k</sub></sub>⟩. The system authority sends each secret role parameter and role secret associated with a role to the role-manager which is responsible of its management. For example, secret role parameter t<sub>r<sub>i</sub><sup>k</sup></sub> and role secret RS<sub>r<sub>i</sub><sup>k</sup></sub> are shared with the role-manager RM<sub>r<sub>i</sub><sup>k</sup></sub>. Note that the root role is internally managed by the system authority. As such, no proxy re-encryption key, role secret key, role public key are generated for the root role.

3) Public Cloud Key Generation: In this phase, a system authority generates keys for the public cloud. Let the system authority SA<sub>k</sub> wants to issue keys for the public cloud. It computes a private key Priv<sub>c</sub><sup>k</sup>, two public keys (Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) and sends the private key Priv<sub>c</sub><sup>k</sup> to the public cloud using a secure-channel. It stores both the public keys (Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) in its public bulletin board. This phase consists of the PUB-CLOUDKEYGEN algorithm which is defined next.

a) PUBCLOUDKEYGEN ((Priv<sub>c</sub><sup>k</sup>, Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) ← (PP, MS<sub>k</sub>, ID<sub>c</sub>)): It computes a private key Priv<sub>c</sub><sup>k</sup> and two

public keys (Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>) for the public cloud as follows:

$$
\begin{align}
\text{Priv}_c^k &= H_2\left(\left(g^y\right)^{\frac{H_1(\text{ID}_c)}{x_k}}\right) = H_2\left(g^{\frac{y \cdot H_1(\text{ID}_c)}{x_k}}\right) \nonumber \\
\text{Pub}_c^{1k} &= g^{\mu_k \cdot \text{Priv}_c^k} \nonumber \\
\text{Pub}_c^{2k} &= g^{x_k \cdot \text{Priv}_c^k} \tag{2}
\end{align}
$$

4) New User Enrolment: A system authority initiates this phase when a new legitimate user, say ID<sub>u</sub>, wants to join an organization, say k<sup>th</sup> organization. The system authority SA<sub>k</sub> generates a secret key SK<sub>ID<sub>u</sub></sub><sup>k</sup> and public key Pub<sub>ID<sub>u</sub></sub><sup>k</sup> for the user ID<sub>u</sub>. It also generates a user secret US<sub>ID<sub>u</sub></sub> which is shared with all the role-managers under its control. SA<sub>k</sub> sends the secret key SK<sub>ID<sub>u</sub></sub><sup>k</sup> to the user ID<sub>u</sub> using a secure-channel and keeps the public key Pub<sub>ID<sub>u</sub></sub><sup>k</sup> in its public bulletin board. This phase comprises the USERPRIVKEYGEN algorithm which is defined next.

a) USERPRIVKEYGEN ((SK<sub>ID<sub>u</sub></sub><sup>k</sup>, Pub<sub>ID<sub>u</sub></sub><sup>k</sup>, US<sub>ID<sub>u</sub></sub>) ← (MS<sub>k</sub>, PP, ID<sub>u</sub>): It issues a pair of secret key SK<sub>ID<sub>u</sub></sub><sup>k</sup> = ⟨Priv<sub>ID<sub>u</sub></sub>, Priv<sub>ID<sub>u</sub></sub><sup>k</sup⟩, public key Pub<sub>ID<sub>u</sub></sub><sup>k</sup>, and a user secret US<sub>ID<sub>u</sub></sub> as follows:

$$
\begin{align}
\text{Priv}_{\text{ID}_u} &= H_2\left( (g^y)^{H_1(\text{ID}_u)} \right) = H_2\left( g^{y \cdot H_1(\text{ID}_u)} \right) \nonumber \\
\text{Priv}_{\text{ID}_u}^k &= (g^y)^{\frac{\text{Priv}_{\text{ID}_u}}{\eta_k}} \cdot g^{\frac{x_k}{\eta_k}} = g^{\frac{y \cdot \text{Priv}_{\text{ID}_u} + x_k}{\eta_k}} \nonumber \\
\text{Pub}_{\text{ID}_u}^k &= g^{\frac{H_2(\text{Priv}_{\text{ID}_u})}{\text{Priv}_{\text{ID}_u}}} \nonumber \\
\text{US}_{\text{ID}_u} &= (g^y)^{\text{Priv}_{\text{ID}_u}} \cdot g^{\mu_k} = g^{y \cdot \text{Priv}_{\text{ID}_u} + \mu_k} \tag{3}
\end{align}
$$

Note that all the system authorities compute the same private key Priv<sub>ID<sub>u</sub></sub> for the user ID<sub>u</sub>. Hence, the user ID<sub>u</sub> needs to keep only one copy of it.

5) Role Assignment: In this phase, a role-manager assigns roles to a legitimate user. Suppose the role-manager RM<sub>r<sub>x</sub><sup>k</sup></sub> wants to assign a role r<sub>x</sub><sup>k</sup> to the user ID<sub>u</sub>. To do so, RM<sub>r<sub>x</sub><sup>k</sup></sub> computes two role-keys (RK<sub>r<sub>x</sub><sup>1,u</sup></sub>, RK<sub>r<sub>x</sub><sup>2,u</sup></sub>) for the user ID<sub>u</sub> and sends the role- keys to the user ID<sub>u</sub> using a secure-channel. This phase com- prises the USERROLEKEYGEN algorithm which is described next.

a) USERROLEKEYGEN ((RK<sub>r<sub>x</sub><sup>1,u</sup></sub>, RK<sub>r<sub>x</sub><sup>2,u</sup></sub>) ← (PP, US<sub>ID<sub>u</sub></sub>, RS<sub>r<sub>x</sub><sup>k</sup></sub>, t<sub>r<sub>x</sub><sup>k</sup></sub>): Let's say, user ID<sub>u</sub> is assigned with the role r<sub>x</sub><sup>k</sup>. RM<sub>r<sub>x</sub><sup>k</sup></sub> computes the role-keys RK<sub>r<sub>x</sub><sup>1,u</sup></sub> and RK<sub>r<sub>x</sub><sup>2,u</sup></sub> as follows:

$$
\begin{align}
\mathrm{RK}_{r_x^k}^{1,u} &= (\mathrm{US}_{\mathrm{ID}_u})^{\frac{1}{\mathrm{RS}_{r_x^k}}} = g^{\frac{\eta \cdot \mathrm{Priv}_{\mathrm{ID}_u} + \mu_k}{\prod_{r_j^k \in \mathrm{R}_{r_x^k}} t_{r_j^k}}} \nonumber \\
\mathrm{RK}_{r_x^k}^{2,u} &= (\mathrm{US}_{\mathrm{ID}_u})^{\frac{1}{t_{r_x^k}}} = g^{\frac{\eta \cdot \mathrm{Priv}_{\mathrm{ID}_u} + \mu_k}{t_{r_x^k}}} \tag{4}
\end{align}
$$

6) Data Encryption: In this phase, the owner encrypts the plaintext data and then outsources the encrypted data to the cloud storage servers. The owner first encrypts the plaintext data using a random symmetric key by following a secure symmetric key encryption algorithm (e.g., Advanced Encryption Standards). The owner then chooses a set of keywords associated with the actual plaintext data and encrypts the chosen keywords along with the symmetric key using our proposed ENC algorithm. Finally, the owner combines both ciphertexts (i.e., symmetric key and actual plaintext data
components) into one archive and outsources the archive file to the public cloud. The ENC algorithm is defined as follows:

a) **ENC** (CT ← (PP, Pub<sub>c</sub><sup>1k</sup>, Pub<sub>c</sub><sup>2k</sup>, M, W, Γ, Γ<sub>Φ</sub>)): Let an owner of the $k^{th}$ organization wants to share a plaintext message M with the users who possess access rights for the roles in Γ. Let w be a keyword from the keyword space W. First, the owner chooses a random number K ∈ G<sub>T</sub> and encrypts the plaintext message M using K by following a symmetric key encryption algorithm. Afterward, the owner encrypts the random number K along with the keyword w using the role public parameters of the roles in Γ.

The owner chooses random numbers ($\{d_{r_i^k}, d'_{r_i^k}\}_{\forall r_i^k \in \Gamma}\in \mathbb{Z}_q^*$, where $d_i = \sum_{r_i^k \in \Gamma} d_{r_i^k}$, $d_j = \sum_{r_j^k \in \Gamma} d'_{r_j^k}$ and $d = d_i + d_j$. The owner also computes $\{d_k = \sum_{\forall r_k^k \in (\Gamma \cap \Psi_k)} d_{r_k^k}\}_{\forall k \in \Gamma_{\Phi}}$ and $\{d'_k = \sum_{\forall r_k^k \in (\Gamma \cap \Psi_k)} d'_{r_k^k}\}_{\forall k \in \Gamma_{\Phi}}$. Finally, the owner generates a ciphertext CT = $\langle \text{Enc}_K(M), C_1, C_2, C_3, \{C_{4k}, C'_{4k}\}_{\forall k \in \Gamma_{\Phi}}, \{C_{r_i^k}, C'_{r_i^k}\}_{\forall r_i^k \in \Gamma}, \Gamma, \Gamma_{\Phi} \rangle$ for the plaintext message M, where:

$$
\begin{align*}
C_1 &= K \cdot Y^d = K \cdot \hat{e}(g, g)^{y \cdot d} \\
C_2 &= (h_1^k)^{d_j} = g^{\eta_k \cdot d_j} \\
C_3 &= (\text{Pub}_c^{2k})^{d_j} = g^{\mathbf{x}_k \cdot \text{Priv}_c^k \cdot d_j} \\
C_{4k} &= (\text{Pub}_c^{1k})^{d_k} = g^{\mu_k \cdot \text{Priv}_c^k \cdot d_k} \\
C'_{4k} &= (\text{Pub}_c^{1k})^{d'_k} = g^{\mu_k \cdot \text{Priv}_c^k \cdot d'_k} \\
C_{r_i^k} &= (\text{PK}_{\text{r}_i^k})^{d_{r_i^k} \cdot H_1(w)} = g^{H_1(w) \cdot d_{r_i^k} \prod_{j \in \mathbb{R}_{r_i^k}} t_{r_j^k}} \\
C'_{r_i^k} &= (\text{PK}_{\text{r}_i^k})^{d'_{r_i^k} \cdot H_1(w)} = g^{H_1(w) \cdot d'_{r_i^k} \prod_{j \in \mathbb{R}_{r_i^k}} t_{r_j^k}} \tag{5}
\end{align*}
$$

Note that the data owner embeds the hashed value of the keyword, i.e, $H_1(w)$ for some roles in $\Gamma$ only (this fixed position can be seen as part of the public parameter).

7) **Trapdoor Generation**: In this phase, a user generates trapdoor Trap using his/her secret keys and the keywords of his/her choice for delegating keyword search capabilities to the public cloud. The user sends the trapdoor Trap along with the associated roles to the public cloud using a secure-channel. This phase comprises the TRAPGEN algorithm which is described next.

a) **TRAPGEN** ((Trap, v)) ←
({RK<sub>r<sub>i</sub><sup>1,k</sup></sub><sup>u</sup>, RK<sub>r<sub>i</sub><sup>2,k</sup></sub><sup>u</sup>}_{∀r<sub>i</sub><sup>k</sup> ∈ S<sub>ID<sub>u</sub></sub>}, SK<sub>ID<sub>u</sub></sub><sup>k</sup>, S<sub>ID<sub>u</sub></sub>, w)): Suppose the user ID<sub>u</sub> who possesses roles S<sub>ID<sub>u</sub></sub> wants to access the ciphertexts associated with the keyword w of the k<sup>th</sup> organization. User ID<sub>u</sub> chooses a random secret v ∈ Z<sub>q</sub><sup>*</sup>, current timestamp ts, and then he computes a trapdoor
$$ \text{Trap} = \langle tr_1, tr_2, tr_3, tr_4, \{tr_{r_i^k}^1, tr_{r_i^k}^2\}_{\forall r_i^k \in S_{ID_u}}, S_{ID_u}, ts \rangle, $$

where:

$$
\begin{align*}
tr_1 &= \left[ \frac{\text{Priv}_{\text{ID}_u} + ts}{H_2(\text{Priv}_{\text{ID}_u}^k)} \right] v = \frac{[\text{Priv}_{\text{ID}_u} + ts] v}{H_2(\text{Priv}_{\text{ID}_u}^k)} \\
tr_2 &= (\text{Priv}_{\text{ID}_u}^k)^v = g^{\frac{[y \cdot \text{Priv}_{\text{ID}_u} + \mu_k]v}{\eta_k}} \\
tr_3 &= g^{\frac{v}{\text{Priv}_{\text{ID}_u}}} \\
tr_4 &= g^v
\end{align*}
$$

$$
\begin{align}
tr_{r_x^k}^1 &= (\mathrm{RK}_{r_x^k}^{1,u})^{\frac{v}{H_1(w)}} = g^{\frac{[y \cdot \mathrm{Priv}_{\mathrm{ID}_u} + \mu_k]v}{H_1(w) \cdot \prod_{j \in \mathrm{RK}_{r_x^k}} t_{r_j^k}}} \nonumber \\
tr_{r_x^k}^2 &= (\mathrm{RK}_{r_x^k}^{2,u})^{\frac{v}{H_1(w)}} = g^{\frac{[y \cdot \mathrm{Priv}_{\mathrm{ID}_u} + \mu_k]v}{H_1(w) \cdot t_{r_x^k}}} \tag{6}
\end{align}
$$

The user ID<sub>u</sub> keeps the random secret v in a secure place for decryption of the ciphertexts in Section V-B9.

8) **Data Search**: In this phase, the public cloud performs a keyword search operation on the ciphertexts using the trapdoor received from the requested user ID<sub>u</sub>. This phase consists of the AUTHENTICATION, KEYSEARCH and PARTIALDEC algorithms. In the AUTHENTICATION algorithm, the public cloud authenticates the user and checks freshness of the keyword search request. In the KEYSEARCH algorithm, the public cloud performs all the search related operation for finding the ciphertexts which have a matching keyword with the trapdoor received from the user ID<sub>u</sub>. This will be done if and only if the user is legitimate and the keyword search request is valid. In the PARTIALDEC algorithm, the public cloud partially decrypts the ciphertexts and finally sends the partially decrypted ciphertexts to the user ID<sub>u</sub>. The details of these algorithms are given next.

a) **AUTHENTICATION** $((V_3^1 / \perp) \leftarrow (\{\text{Priv}_c^k\}_{\forall k \in \Gamma_\Phi}, \text{Trap}, \text{Pub}_{\text{ID}_u}^k, \text{ID}_u, \text{ts}'))$: Before performing computationally expensive operations, the public cloud first authenticates the requesting user. During the authentication process, the public cloud also checks the freshness of search request by comparing the timestamp ts associated with the trapdoor to its own current timestamp ts' for preventing replay attacks. If the authentication fails or if the timestamp associated with the trapdoor represents a past time, the public cloud aborts the connection, i.e., returns $\perp$. Otherwise, it performs keyword search operations defined in the KEYSEARCH algorithm. To authenticate the user and check the freshness of the request, the public cloud computes $U', V_1^1, V_1^2$ and $V_1^3$, based on its known $\{\text{Priv}_c^k\}_{\forall k \in \Gamma_\Phi}$ keys, where:

$$
\begin{align}
U' &= \prod_{\forall k \in \Gamma_{\Phi}} (C'_{4k})^{\frac{1}{\text{Priv}_c^k}} \nonumber \\
&= \prod_{\forall k \in \Gamma_{\Phi}} (g^{\mu_k \cdot \text{Priv}_c^k \cdot d'_k})^{\frac{1}{\text{Priv}_c^k}} \nonumber \\
&= g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \tag{7}
\end{align}
$$
$$
\begin{align}
V_1^1 &= \hat{e} \left( (\text{Pub}_{\text{ID}_u}^k)^{tr_1}, U' \right) \nonumber \\
&= \hat{e} \left( \left( g^{\frac{H_2(\text{Pub}_{\text{ID}_u}^k)}{H_2(\text{Pub}_{\text{ID}_u}^k)}} \right)^{\frac{[\text{Pub}_{\text{ID}_u}+ts]_v}{H_2(\text{Pub}_{\text{ID}_u}^k)}}, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \right) \nonumber \\
&= \hat{e} \left( g^v, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \right) \cdot \hat{e} \left( g^{\frac{v \cdot ts}{\text{Priv}_{\text{ID}_u}}}, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \right) \nonumber \\
&= \hat{e} (g, g)^{v \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \cdot \hat{e} (g, g)^{\frac{v \cdot ts \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k}{\text{Priv}_{\text{ID}_u}}} \tag{8}
\end{align}
$$

$$
\begin{align}
V_1^2 &= \hat{e}((tr_3)^{ts}, U') \nonumber \\
&= \hat{e} \left( g^{\frac{v \cdot ts}{\text{Priv}_{\text{ID}_u}}}, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \right) \nonumber \\
&= \hat{e} (g, g)^{\frac{v \cdot ts \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k}{\text{Priv}_{\text{ID}_u}}} \tag{9}
\end{align}
$$

$$
\begin{align}
V_1^3 &= \hat{e}(tr_4, U') \nonumber \\
&= \hat{e} \left( g^v, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \right) \nonumber \\
&= \hat{e} (g, g)^{v \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \tag{10}
\end{align}
$$

Now, the public cloud checks whether $V_1^1 \stackrel{?}{=} V_1^2 \cdot V_1^3$. If the equation holds, the public cloud performs the operations defined in the KEYSEARCH algorithm. Otherwise, it aborts the connection.

Proof of consistency:

$$
\begin{align}
V_1^1 &= \hat{e}(g,g)^{v \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k} \cdot \hat{e}(g,g)^{\frac{v \cdot ts \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d'_k}{\text{Priv}_{\text{ID}_u}}} \nonumber \\
&= V_1^3 \cdot V_1^2 \tag{11}
\end{align}
$$

b) KEYSEARCH ((CT/⊥) ← (CT, Trap, $V_1^3$)): Suppose the user ID_u possesses a role set $S_{\text{ID}_u}$ and wants to access the $k^{th}$ organization's data. Suppose CT = $\langle \text{Enc}_K(M), C_1, C_2, C_3, \{C_{4k}, C'_{4k}\}_{\forall k \in \Gamma_{\Phi}}, \{C_{r_k^k}, C'_{r_k^k}\}_{\forall r_k^k \in \Gamma}, \Gamma, \Gamma_{\Phi} \rangle$ is the ciphertext of the $k^{th}$ organization on which the public cloud wants to perform the keyword search operation, where for all $r_k^k \in \Gamma$, there is at least one $r_x^k \in S_{\text{ID}_u}$ such that $r_x^k \in \mathbb{R}_{r_k^k}$.

The public cloud computes $V_{r_x^k}^1$ and $V_2$. While computing $V_{r_x^k}^1$, two cases are considered which are as follows:

Case 1: if $r_x^k == r_i^k$, then

$$
\begin{align}
V_{r_x^k}^1 &= \hat{e} (tr_{r_x^k}^1, C_{r_x^k}^') \nonumber \\
&= \hat{e} \left( g^{\frac{[y \cdot \text{Priv}_{\text{ID}_u} + \mu_k]v}{H_1(w) \cdot \prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}}, g^{\frac{H_1(w) \cdot d'_i}{\prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}} \prod_{j \in \mathbb{R}_{r_x^k}} t_{r_j^k} \right) \nonumber \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u} + \mu_k] \cdot v \cdot d'_i}, \quad (\text{as } \mathbb{R}_{r_x^k} = \mathbb{R}_{r_x^k}) \nonumber \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] \cdot v \cdot d'_i} \cdot \hat{e} (g, g)^{\mu_k \cdot v \cdot d'_i} \tag{12}
\end{align}
$$

Otherwise, Case 2: if $r_x^k \in (\mathbb{R}_{r_x^k} \setminus \{r_i^k\})$ (let $\gamma = [y \cdot \text{Priv}_{\text{ID}_u} + \mu_k]$

$$
\begin{align*}
V_{r_x^k}^1 &= \hat{e} \left( (tr_{r_x^k}^2)^{\text{PKey}_{r_x^k}^k}, C_{r_x^k}' \right) \\
&= \hat{e} \left( g^{\frac{\gamma \cdot v}{H_1(w) \cdot t_{r_x^k}}} \cdot \prod_{j \in \mathbb{R}_{r_x^k}} \frac{1}{\{r_x^k\}^t_{r_x^k}}, g^{\frac{H_1(w) \cdot d'_i}{\prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}} \prod_{j \in \mathbb{R}_{r_x^k}} t_{r_j^k} \right) \\
&= \hat{e} \left( g^{\frac{\gamma \cdot v}{\prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}} \cdot d'_i \prod_{j \in \mathbb{R}_{r_x^k}} t_{r_j^k} \right) \\
&= \hat{e} (g, g)^{\gamma \cdot v \cdot d'_i} \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u} + \mu_k] \cdot v \cdot d'_i} \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] \cdot v \cdot d'_i} \cdot \hat{e} (g, g)^{\mu_k \cdot v \cdot d'_i} \tag{13}
\end{align*}
$$

$$
\begin{align}
V_2 &= \prod V_{r_x^k}^1 \nonumber \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot \sum d'_i} \cdot \hat{e} (g, g)^{v \sum \mu_k \cdot d'_i} \nonumber \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot d_j} \cdot \hat{e} (g, g)^{v \sum \mu_k \cdot d'_i} \tag{14}
\end{align}
$$

Now, the public cloud computes $V_3$, where

$$
\begin{align}
V_3 &= \frac{V_2}{V_1^3} = \frac{\hat{e}(g,g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot d_j} \cdot \hat{e}(g,g)^{v \sum \mu_k \cdot d'_i}}{\hat{e}(g,g)^{v \sum \mu_k \cdot d'_k}} \nonumber \\
&= \hat{e}(g,g)^{v \cdot \text{Priv}_{\text{ID}_u} \cdot d_j \cdot v} \tag{15}
\end{align}
$$

Note that $\hat{e}(g,g)^{v \sum \mu_k \cdot d'_i} = \hat{e}(g,g)^{v \sum \mu_k \cdot d'_k}$ (Please refer Section V-B6).

Afterward, the public cloud computes $V_4$, $V_5$ and $V_6$, where

$$
\begin{align}
V_4 &= \hat{e}(tr_2, C_2) \nonumber \\
&= \hat{e} \left( g^{\frac{[y \cdot \text{Priv}_{\text{ID}_u} + x_k] \cdot v}{\eta_k}}, g^{\eta_k \cdot d_j} \right) \nonumber \\
&= \hat{e}(g,g)^{[y \cdot \text{Priv}_{\text{ID}_u} + x_k] \cdot v \cdot d_j} \nonumber \\
&= \hat{e}(g,g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot v \cdot d_j} \cdot \hat{e}(g,g)^{x_k \cdot v \cdot d_j} \tag{16}
\end{align}
$$

$$
\begin{align}
V_5 &= \hat{e}((tr_4)^{\frac{1}{\text{Priv}_c^k}}, C_3) \nonumber \\
&= \hat{e}\left(g^{\frac{v}{\text{Priv}_c^k}}, g^{x_k \cdot \text{Priv}_c^k \cdot d_j}\right) \nonumber \\
&= \hat{e}(g,g)^{x_k \cdot v \cdot d_j} \tag{17}
\end{align}
$$

$$
\begin{align}
V_6 &= \frac{V_1}{V_2} \nonumber \\
&= \frac{\hat{e}(g,g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot v \cdot d_j} \cdot \hat{e}(g,g)^{x_k \cdot v \cdot d_j}}{\hat{e}(g,g)^{x_k \cdot v \cdot d_j}} \nonumber \\
&= \hat{e}(g,g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot d_j \cdot v} \tag{18}
\end{align}
$$

Finally, the public cloud compares the equations (15) and (18). If both are equal then it performs the operations defined in the PARTIALDEC algorithm (described in Section V-B8c). Otherwise, it aborts all the operations and outputs $\perp$, which means that the ciphertext does not have the desired keyword.
c) PARTIALDEC (CT' ← (CT, Trap, {Priv<sub>c</sub><sup>k</sup>}<sub>∀k∈Γ<sub>Φ</sub></sub>, S<sub>ID<sub>u</sub></sub>))Now, the public cloud computes V<sub>9</sub>, where:

In this algorithm, the public cloud partially decrypts all the ciphertexts returned by the KEYSEARCH algorithm. Suppose ciphertext CT = ⟨Enc<sub>K</sub>(M), C<sub>1</sub>, C<sub>2</sub>, C<sub>3</sub>, {C<sub>4k</sub>, C'<sub>4k</sub>}<sub>∀k∈Γ<sub>Φ</sub></sub>, {C<sub>r<sub>k</sub></sub>, C'<sub>r<sub>k</sub></sub>}<sub>∀r<sub>k</sub>∈Γ, Γ, Γ<sub>Φ</sub></sub>⟩ has a matching keyword with the trapdoor Trap. To partially decrypt the ciphertext CT, the public cloud first computes V<sub>r<sub>k</sub></sub><sup>7</sup> and V<sub>7</sub>. Similar to V<sub>r<sub>k</sub></sub><sup>1</sup>, the computation procedure considers the two following cases to compute V<sub>r<sub>k</sub></sub><sup>7</sup>:

Case 1: if $r_x^k == r_i^k$, then

$$
\begin{align*}
V_{r_x}^7 &= \hat{e} \left( \operatorname{tr}_{r_x}^1 C_{r_i^k} \right) \\
&= \hat{e} \left( g^{\frac{[y \cdot \operatorname{Priv}_{ID_u} + \mu_k]v}{H_1(w) \cdot \prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}} \cdot H_1(w) \cdot d_{r_i^k} \prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k} \right) \\
&= \hat{e} (g, g)^{[y \cdot \operatorname{Priv}_{ID_u} + \mu_k] \cdot v \cdot d_{r_i^k}} \quad (\text{as } \mathbb{R}_{r_x^k} = \mathbb{R}_{r_i^k}) \\
&= \hat{e} (g, g)^{[y \cdot \operatorname{Priv}_{ID_u}] v \cdot d_{r_i^k}} \cdot \hat{e} (g, g)^{\mu_k \cdot v \cdot d_{r_i^k}} \tag{19}
\end{align*}
$$

Otherwise, Case 2: if $r_x^k \in (\mathbb{R}_{r_i^k} \setminus \{r_i^k\})$ (let $\gamma = [y \cdot \text{Priv}_{\text{ID}_u} + \mu_k]$

$$
\begin{align*}
V_{r_x}^7 &= \hat{e} \left( \left( \operatorname{tr}_{r_x}^2 \right)^{\mathbf{P}\text{Key}_{r_x}^k} C_{r_i^k} \right) \\
&= \hat{e} \left( g^{\frac{\gamma \cdot v}{H_1(w) \cdot t_{r_x^k}}} \cdot \frac{1}{\prod_{\forall r_j^k \in \mathbb{R}_{r_x^k} \setminus \{r_j^k\}} t_{r_j^k}}, g^{H_1(w) \cdot d_{r_i^k} \prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}} \right) \\
&= \hat{e} \left( g^{\frac{\gamma \cdot v}{\prod_{\forall r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}}}, g^{d_{r_i^k} \prod_{r_j^k \in \mathbb{R}_{r_x^k}} t_{r_j^k}} \right) \\
&= \hat{e} (g, g)^{\gamma \cdot v \cdot d_{r_i^k}} \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u} + \mu_k] v \cdot d_{r_i^k}} \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot d_{r_i^k}} \cdot \hat{e} (g, g)^{\mu_k \cdot v \cdot d_{r_i^k}} \tag{20}
\end{align*}
$$

$$
\begin{align*}
V_7 &= \prod_{r_x^k} V_{r_x}^7 \\
&= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot \sum d_{r_i^k} \cdot \hat{e} (g, g)^{v \sum \mu_k \cdot d_{r_i^k}}}
\end{align*}
\begin{equation}
= \hat{e} (g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot d_i} \cdot \hat{e} (g, g)^{v \sum \mu_k \cdot d_{r_i^k}} \tag{21}
\end{equation}
$$

The public cloud knowing its private key {Priv<sub>c</sub><sup>k</sup>}<sub>∀k∈Γ<sub>Φ</sub></sub> computes U and V<sub>8</sub>, as follows:

$$
\begin{align*}
U &= \prod_{\forall k \in \Gamma_{\Phi}} (C_{4k})^{\frac{1}{\text{Priv}_{\text{c}}^{k}}} \\
&= \prod_{\forall k \in \Gamma_{\Phi}} \left( g^{\mu_k \cdot \text{Priv}_{\text{c}}^k \cdot d_k} \right)^{\frac{1}{\text{Priv}_{\text{c}}^k}} \\
&= g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d_k} \\
V_8 &= \hat{e} (\text{tr}_4, U) \\
&= \hat{e} (g^v, g^{\sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d_k}) \\
&= \hat{e} (g, g)^{v \sum_{\forall k \in \Gamma_{\Phi}} \mu_k \cdot d_k} \tag{22}
\end{align*}
$$

$$
\begin{align}
V_9 &= \frac{V_7}{V_8} = \frac{\hat{e}(g, g)^{[y \cdot \text{Priv}_{\text{ID}_u}] v \cdot d_i} \cdot \hat{e}(g, g)^{v \sum \mu_k \cdot d_{r_i^k}}}{\hat{e}(g, g)^{v \sum \mu_k \cdot d_k}} \nonumber \\
&= \hat{e}(g, g)^{v \sum \mu_k \cdot d_{r_i^k}} \tag{23}
\end{align}
$$

Note that $\hat{e}(g, g)^{v \sum \mu_k \cdot d_{r_i^k}} = \hat{e}(g, g)^{v \sum \mu_k \cdot d_k}$ (Please refer Section V-B6).

The public cloud computes V<sub>9</sub>, where:

$$
\begin{align*}
V_{10} &= V_6 \cdot V_9 \\
&= \hat{e}(g, g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot d_j \cdot v} \cdot \hat{e}(g, g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot d_i \cdot v} \\
&= \hat{e}(g, g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot v [d_j + d_i]} \\
&= \hat{e}(g, g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot v \cdot d} \tag{24}
\end{align*}
$$

Finally, the public cloud sends the partially decrypted ciphertext CT' = ⟨Enc<sub>K</sub>(M), C<sub>1</sub>, V<sub>10</sub>⟩ to the user ID<sub>u</sub>.

9) Decryption: In this phase, the user ID<sub>u</sub> decrypts the received partially decrypted ciphertext CT' using his/her private key Priv<sub>ID<sub>u</sub></sub> and random secret v. This phase comprises the FULLDEC algorithm which is described next.

a) FULLDEC(M ← (CT', Priv<sub>ID<sub>u</sub></sub>, v)): It computes K from the ciphertext CT' using his/her secret keys, priv<sub>ID<sub>u</sub></sub> and v.

$$
\begin{align*}
K &= \frac{C_1}{(V_{10})^{\frac{1}{\text{Priv}_{\text{ID}_u} \cdot v}}} \\
&= \frac{K \cdot \hat{e}(g, g)^{y \cdot d}}{(\hat{e}(g, g)^{y \cdot \text{Priv}_{\text{ID}_u} \cdot v \cdot d})^{\frac{1}{\text{Priv}_{\text{ID}_u} \cdot v}}} \\
&= \frac{K \cdot \hat{e}(g, g)^{y \cdot d}}{\hat{e}(g, g)^{y \cdot d}} \tag{25}
\end{align*}
$$

Finally, user ID<sub>u</sub> gets the actual plaintext data by decrypting Enc<sub>K</sub>(M) using K and removes the random secret v from his/her database.

C. Conjunctive Keyword Search

Many times a user wants to perform multiple keyword search using a single search request instead of sending multiple single keyword search requests. This property is called the Conjunctive Keyword Search. The proposed scheme can provide conjunctive keyword search with the following modifications. The owner computes modified ciphertext components $C_{r_i^k} = (\text{PK}_{r_i^k})^{d_{r_i^k} \cdot \prod H_1(w_i)} = g^{d_{r_i^k} \prod H_1(w_i) \cdot \prod_{r_j^k \in \mathbb{R}_{r_i^k}} t_{r_j^k}}$ and $C'_{r_i^k} = (\text{PK}_{r_i^k})^{d'_{r_i^k} \cdot \prod H_1(w_i)} = g^{d'_{r_i^k} \prod H_1(w_i) \cdot \prod_{r_j^k \in \mathbb{R}_{r_i^k}} t_{r_j^k}}$. Similarly, a user computes trapdoor components $\text{tr}_{r_x}^1 = (\text{RK}_{r_x^k}^{1,u})^{\frac{v}{\prod H_1(w_i)}}$ and $\text{tr}_{r_x}^2 = (\text{RK}_{r_x^k}^{2,u})^{\frac{v}{\prod H_1(w_i)}}$. It can be observed that, our conjunctive keyword search mechanism does not introduce any additional overhead in the system.

D. Revocation

In the proposed scheme, a SA can revoke a user in two ways, namely complete user revocation and role-level revocation.
The former revocation method means that the user can no longer access any data belonging to that organization. The later revocation method represents that if one or more roles of a user is revoked, the user can still access data with his/her non-revoked roles if they are qualified enough according to the RBAC access policy.

The complete user revocation is achieved by revoking the public key Pub<sup>k</sup><sub>ID<sub>u</sub></sub> of the user, so that the public cloud do not use it during the authentication process in the AUTHEN- TICATION algorithm defined in Section V-B8a. To do that, SA removes the public key Pub<sup>k</sup><sub>ID<sub>u</sub></sub> of the revoked user ID<sub>u</sub> from its public bulletin board, which can be done easily.

For the role-level revocation, the SA updates all the param-
eters related with the revoked role. Suppose the SA wants
to revoke a role r<sup>k</sup><sub>i</sub> from one or more users. To do that,
the SA first chooses a fresh random number t'<sub>r<sub>i</sub>k</sub> ∈ Z<sup>*</sup><sub>q</sub> and
updates all the parameters related with the revoked role r<sup>k</sup><sub>i</sub>.

The SA computes updated public keys ($PK_{r_j^k}$) $\frac{t'_{r_j^k}}{t_{r_j^k}}$, role secrets ($RS_{r_j^k} \cdot \frac{t'_{r_j^k}}{t_{r_j^k}}$) and proxy re-encryption keys ($PKey_{r_j^k}^{r_u^k} \cdot \frac{t'_{r_j^k}}{t_{r_j^k}}$) related with the revoked role $r_i^k$ (i.e., for all $r_j^k$ such that $r_i^k \in \mathbb{R}_{r_j^k}$), where $t_{r_j^k}$ is the previously chosen random number associated with $r_i^k$. The SA then sends the $\frac{t'_{r_j^k}}{t_{r_j^k}}$ to the public cloud for re-encryption of the stored ciphertexts associated with the revoked role $r_i^k$. It also sends $\frac{t'_{r_j^k}}{t_{r_j^k}}$ to the corresponding role-managers for updating the role-keys associated with the revoked role $r_i^k$.

The public cloud re-encrypts the ciphertext components
($C_{r_j^k} \frac{t'_{r_j^k}}{t_{r_j^k}}$ and ($C'_{r_j^k} \frac{t'_{r_j^k}}{t_{r_j^k}}$) for all $r_j^k$ such that $r_i^k \in \mathbb{R}_{r_j^k}$. This
is essential to prevent the revoked users from accessing the
data using the revoked role (i.e., Backward Secrecy).

Moreover, to enable the other non-revoked users for access-
ing the re-encrypted ciphertexts, the concerned role-managers
need to send updated role-keys to the non-revoked users (i.e.,
Forward Secrecy). The updated role-keys are computed as

follows: i) ($RK_{r_i^k}^{1,u}$) $\frac{t'_{r_i^k}}{t_{r_i^k}}$ for all the non-revoked users who possess $r_i^k$ and ii) ($RK_{r_j^k}^{2,u}$) $\frac{t'_{r_j^k}}{t_{r_j^k}}$ for all the non-revoked users who possess $r_j^k$, such that $r_i^k \in \mathbb{R}_{r_j^k}$.

VI. ANALYSIS

This section first presents security analysis of the proposed
scheme, followed by its performance analysis. In the secu-
rity analysis, we demonstrate that the proposed scheme is
secure against chosen plaintext and chosen keyword attacks.
In the performance analysis, we present a comprehensive
performance analysis of the proposed scheme along with its
experimental results.

A. Security Analysis

1) Security against Chosen Plaintext Attack: CPA security of the proposed scheme can be defined by the following theorem and proof.

**Theorem 2.** If a probabilistic-polynomial time (PPT) adversary $\mathcal{A}_1$ wins the CPA security game as defined in Section III-E1 with a non-negligible advantage $\epsilon$, then a PPT simulator $\mathcal{B}$ can be constructed to break the DBDH assumption with non-negligible advantage $\frac{\epsilon}{2}$.

Proof. In this proof, we show that a simulator $\mathcal{B}$ can be constructed to help an adversary $\mathcal{A}_1$ to gain advantage $\frac{\epsilon}{2}$ against our proposed scheme.

The DBDH challenger $\mathcal{C}$ chooses random numbers $(a, b, c, z) \in \mathbb{Z}_q^*$ and flips a binary random coin $l$. It sets $Z = \hat{e}(g, g)^{abc}$ if $l=0$ and $Z = \hat{e}(g, g)^z$ otherwise. Afterwards, challenger $\mathcal{C}$ sends $A = g^a, B = g^b, C = g^c$ and $Z$ to the simulator $\mathcal{B}$, and it asks the simulator $\mathcal{B}$ to output $l$. Now simulator $\mathcal{B}$ acts as a challenger in the rest of the security game.

In the following game, simulator $\mathcal{B}$ interacts with the adversary $\mathcal{A}_1$ as follows:

INIT Adversary $\mathcal{A}_1$ sends a challenged role set $\Gamma^*$, a keyword $w$ and two identities $(\mathrm{ID}_u^*, \mathrm{ID}_c^*)$ to the simulator $\mathcal{B}$.

**SETUP** Simulator $\mathcal{B}$ chooses random numbers $\{\zeta_k, \vartheta_k, \varrho_k\}_{\forall k \in \Phi} \in \mathbb{Z}_q^*$. It also chooses random numbers $\{\alpha_{r_i^k}\}_{\forall i \in \Psi_k, \forall k \in \Phi} \in \mathbb{Z}_q^*$. Simulator $\mathcal{B}$ computes $Y = \hat{e}(g, g)^{ab} = \hat{e}(A, B), \{h_1^k = g^{b \cdot \zeta_k} = B^{\zeta_k}\}_{\forall k \in \Phi}$. Simulator $\mathcal{B}$ also computes $PK_{r_i^k} = g^{b \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}} = B^{\prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}}$ for all $r_i^k \in \Psi_k$, where $1 \le k \le m$. Moreover, simulator $\mathcal{B}$ computes

$$
\left\{ \left\{ \text{PKey}_{r_i^k}^{r_u^k} = \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \{r_w^k\} \alpha_{r_j^k} \right\}_{\forall r_w^k \in \mathbb{R}_{r_i^k}} \right\}_{\forall r_i^k \in \Psi_k}
$$
$$
\text{where } 1 \le k \le m.
$$

Simulator $\mathcal{B}$ also chooses a random number $s_{ID_u^*} \in \mathbb{Z}_q^*$ and computes $h_{id^*} = H_1(ID_u^*)$. It then computes $\{\text{Priv}_c^k, \text{Pub}_c^{1k}, \text{Pub}_c^{2k}, \text{Priv}_{ID_u}, \text{Pub}_{ID_u}^k\}_{\forall k \in \Phi}$ and $\text{Priv}_{ID_u}$, where

$$
\begin{align*}
\text{Priv}_c^k &= H_2\left(g^{\frac{\alpha \cdot b \cdot h_{id_c^*}}{b \cdot \varrho_k}}\right) = H_2\left(A^{\frac{h_{id_c^*}}{\varrho_k}}\right) \\
\text{Pub}_c^{1k} &= g^{b \cdot \vartheta_k \cdot \text{Priv}_c^k} = B^{\vartheta_k \cdot H_2\left(A^{\frac{h_{id_c^*}}{\varrho_k}}\right)} \\
\text{Pub}_c^{2k} &= g^{b \cdot \varrho_k \cdot \text{Priv}_c^k} = B^{\varrho_k \cdot H_2\left(A^{\frac{h_{id_c^*}}{\varrho_k}}\right)} \\
\text{Priv}_{ID_u}^k &= g^{\frac{\alpha \cdot b \cdot s_{ID_u^*} + b \cdot \varrho_k}{b \cdot \zeta_k}} = A^{\frac{s_{ID_u^*}}{\zeta_k}} \cdot g^{\frac{\varrho_k}{\zeta_k}} \\
\text{Pub}_{ID_u}^k &= g^{\frac{H_2(\text{Priv}_{ID_u}^k)}{s_{ID_u^*}}} = g^{\frac{H_2\left(A^{\frac{s_{ID_u^*}}{\zeta_k}} \cdot g^{\frac{\varrho_k}{\zeta_k}}\right)}{s_{ID_u^*}}} \\
\text{Priv}_{ID_u} &= s_{ID_u^*} \tag{26}
\end{align*}
$$

Finally, simulator $\mathcal{B}$ sends the following parameters to the adversary $\mathcal{A}_1$: $\langle g, G_1, G_T, \hat{e}, H_1, H_2, Y, \{h_1^k\}_{\forall k \in \Phi}, \{\{PK_{r_i^k}\}_{\forall r_j^k \in \Psi_k}\}_{\forall k \in \Phi}, \{\{PKey_{r_i^k}\}_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \setminus \{r_i^k\}\}_{\forall r_j^k \in \Psi_k, \forall k \in \Phi}\rangle$. Simulator $\mathcal{B}$ also
sends $\{\text{Priv}_c^k, \text{Pub}_c^{1k}, \text{Pub}_c^{2k}, \text{Priv}_{\text{ID}_u}^k, \text{Pub}_{\text{ID}_u}^k\}_{\forall k \in \Phi}$ and $\text{Priv}_{\text{ID}_u}$ to the adversary $\mathcal{A}$. Note that simulator $\mathcal{B}$ sends a random number $s_{\text{ID}_u^*}$ as $\text{Priv}_{\text{ID}_u}$ to the adversary $\mathcal{A}$. As the simulator $\mathcal{B}$ chooses $s_{\text{ID}_u^*}$ in the SETUP and sends it to the adversary $\mathcal{A}$, the simulated game remains the same as the original scheme.

**PHASE 1** Adversary sends a challenged role set $\mathbb{S}^*$ to the simulator $\mathcal{B}$ for role-keys. Simulator $\mathcal{B}$ computes $\{\text{RK}_{\text{r}^k_x}^{1,u}, \text{RK}_{\text{r}^k_x}^{2,u}\}_{\forall \text{r}^k_x \in \mathbb{S}^*}$ as follows:

For all $\text{r}^k_x \in \mathbb{S}^*$, simulator $\mathcal{B}$ computes

$$ 
\begin{aligned}
\text{RK}_{\text{r}^k_x}^{1,u} &= g^{\frac{a \cdot b \cdot \text{Priv}_{\text{ID}_u} + b \cdot \vartheta_k}{b \prod_{\nabla_r^k} \alpha_{r^k_j}}} = A^{\frac{H_2(A^{\frac{h_{\text{ID}_u^*}}}{\vartheta_k})}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \cdot g^{\frac{\vartheta_k}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \\
\text{RK}_{\text{r}^k_x}^{2,u} &= g^{\frac{a \cdot b \cdot \text{Priv}_{\text{ID}_u} + b \cdot \vartheta_k}{b \alpha_{r^k_x}}} = A^{\frac{H_2(A^{\frac{h_{\text{ID}_u^*}}}{\vartheta_k})}{\alpha_{r^k_x}}} \cdot g^{\frac{\vartheta_k}{\alpha_{r^k_x}}}
\end{aligned} 
\quad (27) $$

Finally, simulator $\mathcal{B}$ sends $\{\text{RK}_{\text{r}^k_x}^{1,u}, \text{RK}_{\text{r}^k_x}^{2,u}\}_{\forall \text{r}^k_x \in \mathbb{S}^*}$ to the adversary $\mathcal{A}_1$. Note that distribution of the role-keys for $\mathbb{S}^*$ is identical to the original scheme.

**CHALLENGE** When adversary $\mathcal{A}_1$ decides that **PHASE 1** is over, it submits two equal length messages $K_0$ and $K_1$ to the simulator $\mathcal{B}$. Simulator $\mathcal{B}$ flips a random binary coin $\omega$ and encrypts $K_\omega$ with the challenged role set $\Gamma^*$.

Simulator $\mathcal{B}$ first computes $h_w = H_1(w)$ and chooses five polynomials $q_1(x), q_2(x), q_3(x), q_4(x)$ and $q_5(x)$ of degree $2, |\Gamma^*_\Phi|, |\Gamma^*_\Phi|, |\Gamma^*| \text{ and } |\Gamma^*| \text{ respectively, where } \Gamma^*_\Phi \text{ represents the set of system authorities associated with } \Gamma^*, \text{ as follows:}$

* $q_1(x)$: Simulator $\mathcal{B}$ implicitly sets $q_1(0) = c$ and randomly chooses the rest of the points to define the polynomial $q_1(x)$ completely. Note that $q_1(1)$ and $q_1(2)$ values implicitly represent $d_i$ and $d_j$ of our original scheme respectively.

* $q_2(x)$: Simulator $\mathcal{B}$ sets $q_2(0) = q_1(1)$ and randomly chooses the rest of the points to define $q_2(x)$ completely.

* $q_3(x)$: Simulator $\mathcal{B}$ sets $q_3(0) = q_1(2)$ and randomly chooses the rest of the points to define $q_3(x)$ completely.

* $q_4(x)$: Simulator $\mathcal{B}$ sets $q_4(0) = q_1(1)$ and randomly chooses the rest of the points to define $q_4(x)$ completely.

* $q_5(x)$: Simulator $\mathcal{B}$ sets $q_5(0) = q_1(2)$ and randomly chooses the rest of the points to define $q_5(x)$ completely.

Now, simulator $\mathcal{B}$ computes a challenged ciphertext $\text{CT}_\omega =$

$\langle C_1, C_2, C_3, \{C_{4k}, C'_{4k}\}_{\forall k \in \Gamma^*}, \{C_{r_i^k}, C'_{r_i^k}\}_{\forall r_i^k \in \Gamma^*} \rangle$, where

$$ 
\begin{aligned}
C_1 &= K_\omega \cdot Z \\
C_2 &= g^{b \cdot \zeta_k \cdot q_1(2)} = B^{\zeta_k \cdot q_1(2)} \\
C_3 &= g^{b \cdot \vartheta_k \cdot \text{Priv}_c^k \cdot q_1(2)} = B^{\vartheta_k \cdot H_2(A^{\frac{h_{\text{ID}_u^*}}{\vartheta_k}}) \cdot q_1(2)} \\
C_{4k} &= g^{b \cdot \vartheta_k \cdot \text{Priv}_c^k \cdot q_2(i)} \\
&= B^{\vartheta_k \cdot H_2(A^{\frac{h_{\text{ID}_u^*}}{\vartheta_k}}) \cdot q_2(i)}, \quad 1 \le i \le |\Gamma^*_\Phi| \\
C'_{4k} &= g^{b \cdot \vartheta_k \cdot \text{Priv}_c^k \cdot q_3(i)} \\
&= B^{\vartheta_k \cdot H_2(A^{\frac{h_{\text{ID}_u^*}}{\vartheta_k}}) \cdot q_3(i)}, \quad 1 \le i \le |\Gamma^*_\Phi| \\
C_{r_i^k} &= g^{\frac{h_w \cdot b \cdot q_4(i)}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \prod_{\nabla_r^k \in \mathbb{R}_{r_i^k}} \alpha_{r^k_j}, \quad 1 \le i \le |\Gamma^*| \\
&= B^{\frac{h_w \cdot q_4(i)}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \prod_{\nabla_r^k \in \mathbb{R}_{r_i^k}} \alpha_{r^k_j} \\
C'_{r_i^k} &= g^{\frac{h_w \cdot b \cdot q_5(i)}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \prod_{\nabla_r^k \in \mathbb{R}_{r_i^k}} \alpha_{r^k_j}, \quad 1 \le i \le |\Gamma^*| \\
&= B^{\frac{h_w \cdot q_5(i)}{\prod_{\nabla_r^k} \alpha_{r^k_j}}} \prod_{\nabla_r^k \in \mathbb{R}_{r_i^k}} \alpha_{r^k_j}
\end{aligned} 
\quad (28) $$

Note that $c$ (implicitly) can be recovered using the LaGrange's polynomial interpolation from the values $q_1(1)$ and $q_1(2)$, and $q_1(1)$, $q_1(2)$ can be recovered from the polynomials $q_4(x)$ and $q_5(x)$ if and only if the entity (i.e., adversary $\mathcal{A}_1$) possesses a qualified set of roles. Hence, the distribution of the ciphertext $\text{CT}_\omega$ for $\Gamma^*$ is identical to the original scheme.

**PHASE 2 Same as PHASE 1**

**GUESS** The adversary $\mathcal{A}_1$ guesses a bit $\omega'$ which is sent to simulator $\mathcal{B}$. If $\omega' = \omega$ then the adversary $\mathcal{A}_1$ wins CPA game; otherwise it fails. If $\omega' = \omega$, simulator $\mathcal{B}$ answers “DBDH” in the game (i.e. outputs $l=0$); otherwise $\mathcal{B}$ answers “random” (i.e. outputs $l=1$).

If $Z = \hat{e}(g, g)^z$; then $C_1$ is completely random from the view of the adversary $\mathcal{A}_1$. So, the received ciphertext $\text{CT}_\omega$ is not compliant to the game (i.e. invalid ciphertext). Therefore, the adversary $\mathcal{A}_1$ chooses $\omega'$ randomly. Hence, the probability of the adversary $\mathcal{A}_1$ for outputting $\omega' = \omega$ is $\frac{1}{2}$.

If $Z = \hat{e}(g, g)^{abc}$, then adversary $\mathcal{A}_1$ receives a valid ciphertext. The adversary $\mathcal{A}_1$ wins the CPA game with non-negligible advantage $\epsilon$ (according to Theorem 2). As such, the probability of outputting $\omega' = \omega$ for the adversary $\mathcal{A}_1$ is $\frac{1}{2} + \epsilon$, where probability $\epsilon$ is for guessing that the received ciphertext is valid and probability $\frac{1}{2}$ is for guessing whether the valid encrypted message $C_1$ is related to $K_0$ or $K_1$.

Therefore, the overall advantage $\text{Adv}_{\text{IND-CPA}}^A$ of the simulator $\mathcal{B}$ is $\frac{1}{2}(\frac{1}{2} + \epsilon + \frac{1}{2}) - \frac{1}{2} = \frac{\epsilon}{2}$. $\square$

2) Security against Chosen Keyword Attack: Chosen keyword attack (CKA) security of the proposed scheme can be defined by the following theorem and proof.

**Theorem 3.** If a PPT adversary $\mathcal{A}_2$ wins the CKA security game defined in Section III-E2 with a non-negligible advantage $\epsilon$, then a PPT simulator $\mathcal{B}$ can be constructed to break DBDH assumption with non-negligible advantage $\frac{\epsilon}{2}$.
**Proof.** In this proof, we show that a simulator $\mathcal{B}$ can be constructed to help an adversary $\mathcal{A}_2$ to gain advantage $\frac{\epsilon}{2}$ against our proposed scheme.

The DBDH challenger $\mathcal{C}$ chooses random numbers $(a, b, c, z) \in \mathbb{Z}_q^*$ and flips a binary random coin $l$. It sets $Z = \hat{e}(g, g)^{abc}$ if $l = 0$ and $Z = \hat{e}(g, g)^z$ otherwise. Afterwards, challenger $\mathcal{C}$ sends $A = g^a, B = g^b, C = g^c$ and $Z$ to the simulator $\mathcal{B}$, and it asks the simulator $\mathcal{B}$ to output $l$. Now simulator $\mathcal{B}$ acts as a challenger in the rest of the security game.

In the following game simulator $\mathcal{B}$ interacts with the adversary $\mathcal{A}_2$ as follows:

**INIT** Adversary $\mathcal{A}_2$ sends a challenged role set $\Gamma^*$ and two identities $(\mathrm{ID}_c^*, \mathrm{ID}_u^*)$ to the simulator $\mathcal{B}$.

**SETUP** Simulator $\mathcal{B}$ chooses random numbers $\{\zeta_k, \vartheta_k, \vartheta_k\}_{\forall k \in \Phi}$. It also chooses random numbers $\{\alpha_{r_k^*}\}_{\forall i \in \Psi_k, \forall k \in \Phi} \in \mathbb{Z}_q^*$. Simulator $\mathcal{B}$ computes $Y = \hat{e}(g, g)^{ab} = \hat{e}(A, B), \{h_1^k = g^{b \cdot \zeta_k} = B^{\zeta_k}\}_{\forall k \in \Phi}$. It also computes $\mathrm{PK}_{r_k^*} = g^{b \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*}} \alpha_{r_k^*}} \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*}} \alpha_{r_k^*}$ for all $r_k^* \in \Psi_k$, where $1 \le k \le m$. Moreover, simulator $\mathcal{B}$ computes $\left\{ \mathrm{PKKey}_{r_k^*} = \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*} \setminus \{r_k^*\}} \alpha_{r_k^*} \right\}_{\forall r_k^* \in \mathrm{R}_{r_k^*} \setminus \{r_k^*\}}$ where $1 \le k \le m$.

Moreover, simulator $\mathcal{B}$ chooses a random number $\mathrm{s}_{\mathrm{ID}_u^*} \in \mathbb{Z}_q^*$ and computes $h_{id_u^*} = H_1(\mathrm{ID}_c^*)$. It then computes $\{\mathrm{Priv}_c^k, \mathrm{Pub}_c^{1k}, \mathrm{Pub}_c^{2k}, \mathrm{Pub}_{\mathrm{ID}_u^*}\}_{\forall k \in \Phi}$, where

$$ 
\begin{aligned}
\mathrm{Priv}_c^k &= H_2\left(g^{\frac{a \cdot b \cdot h_{id_c^*}}{b \cdot \vartheta_k}}\right) = H_2\left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right) \\
\mathrm{Pub}_c^{1k} &= g^{b \cdot \vartheta_k \cdot \mathrm{Priv}_c^k} = B^{\vartheta_k \cdot H_2\left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right)} \\
\mathrm{Pub}_c^{2k} &= g^{b \cdot \vartheta_k \cdot \mathrm{Priv}_c^k} = B^{\vartheta_k \cdot H_2\left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right)} \\
\mathrm{Pub}_{\mathrm{ID}_u^*}^k &= g^{\frac{\mathrm{s}_{\mathrm{ID}_u^*}}{s_{\mathrm{ID}_u^*}}} = g^{\frac{\mathrm{s}_{\mathrm{ID}_u^*}}{s_{\mathrm{ID}_u^*}}}
\end{aligned}
\quad (29) $$

Simulator $\mathcal{B}$ sends the following parameters to the adversary $\mathcal{A}_2$: $\langle q, \mathbb{G}_T, \hat{e}, H_1, H_2, Y, \{h_1^k\}_{\forall k \in \Phi}, \{\{\mathrm{PK}_{r_k^*}\}_{\forall r_k^* \in \Psi_k}\}_{\forall k \in \Phi}, \{\{\mathrm{PKKey}_{r_k^*}\}_{\forall r_k^* \in \mathrm{R}_{r_k^*} \setminus \{r_k^*\}}\}_{\forall r_k^* \in \Psi_k, \forall k \in \Phi}, \{\mathrm{Pub}_c^{1k}, \mathrm{Pub}_c^{2k}, \mathrm{Pub}_{\mathrm{ID}_u^*}\}_{\forall k \in \Phi} \rangle$. Simulator $\mathcal{B}$ also sends private keys $\{\mathrm{Priv}_c^k\}_{\forall k \in \Phi}$ and $\mathrm{Priv}_{\mathrm{ID}_u} = \mathrm{s}_{\mathrm{ID}_u^*}$ to the adversary $\mathcal{A}_2$.

**PHASE 1** Adversary $\mathcal{A}_2$ sends a set of roles $\mathcal{S}^*$ and a keyword $w$ to the simulator $\mathcal{B}$ for the trapdoor. Simulator $\mathcal{B}$ chooses random numbers $(v, t\mathcal{S}) \in \mathbb{Z}_q^*$. It computes $h_w = H_1(w)$. Simulator $\mathcal{B}$ computes the trapdoor Trap =

$\langle \mathrm{tr}_1, \mathrm{tr}_2, \mathrm{tr}_3, \mathrm{tr}_4, \{\mathrm{tr}_{r_x^1}, \mathrm{tr}_{r_x^2}\}_{\forall r_x^k \in \mathcal{S}^*} \rangle$, where

$$ 
\begin{aligned}
\mathrm{tr}_1 &= \frac{\mathrm{s}_{\mathrm{ID}_u^*} + t\mathcal{S}}{H_2\left(g^{\frac{a \cdot b \cdot \mathrm{s}_{\mathrm{ID}_u^*} + b \cdot \vartheta_k}{b \cdot \zeta_k}}\right)} \cdot \mathcal{V} = \frac{[\mathrm{s}_{\mathrm{ID}_u^*} + t\mathcal{S}] \cdot \mathcal{V}}{H_2\left(A^{\frac{\mathrm{s}_{\mathrm{ID}_u^*}}{\zeta_k}} \cdot g^{\frac{\vartheta_k}{\zeta_k}}\right)} \\
\mathrm{tr}_2 &= \left(g^{\frac{a \cdot b \cdot \mathrm{s}_{\mathrm{ID}_u^*} + b \cdot \vartheta_k}{b \cdot \zeta_k}}\right)^{\mathcal{V}} = A^{\frac{\mathrm{s}_{\mathrm{ID}_u^*}}{\zeta_k}} \cdot g^{\frac{\vartheta_k \cdot \mathcal{V}}{\zeta_k}} \\
\mathrm{tr}_3 &= g^{\frac{\mathcal{V}}{\mathrm{s}_{\mathrm{ID}_u^*}}} = g^{\frac{\mathcal{V}}{\mathrm{s}_{\mathrm{ID}_u^*}}} \\
\mathrm{tr}_4 &= g^{\mathcal{V}}
\end{aligned}
\quad (30) $$

For all $r_k^k \in \mathcal{S}^*$,

$$ 
\begin{aligned}
\mathrm{tr}_{r_x^1}^k &= \left( g^{\frac{a \cdot b \cdot \mathrm{s}_{\mathrm{ID}_u^*} + b \cdot \vartheta_k}{b \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*}} \alpha_{r_k^*}}} \right)^{\frac{\mathcal{V}}{h_w}} \\
&= A^{\frac{\mathrm{s}_{\mathrm{ID}_u^*} \cdot \mathcal{V}}{h_w \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*}} \alpha_{r_k^*}}} \cdot g^{\frac{\vartheta_k \cdot \mathcal{V}}{h_w \prod_{\forall r_k^* \in \mathrm{R}_{r_k^*}} \alpha_{r_k^*}}} \\
\mathrm{tr}_{r_x^2}^k &= \left( g^{\frac{a \cdot b \cdot \mathrm{s}_{\mathrm{ID}_u^*} + b \cdot \vartheta_k}{b \cdot \alpha_{r_x^k}}} \right)^{\frac{\mathcal{V}}{h_w}} = A^{\frac{\mathrm{s}_{\mathrm{ID}_u^*} \cdot \mathcal{V}}{h_w \cdot \alpha_{r_x^k}}} \cdot g^{\frac{\vartheta_k \cdot \mathcal{V}}{h_w \cdot \alpha_{r_x^k}}}
\end{aligned}
\quad (31) $$

Finally, simulator $\mathcal{B}$ sends trapdoor Trap to the adversary $\mathcal{A}_2$.

**CHALLENGE** When adversary $\mathcal{A}_2$ decides that **PHASE 1** is over, it submits two equal length keywords $w_0$ and $w_1$ to the simulator $\mathcal{B}$. Simulator $\mathcal{B}$ flips a random binary coin $\omega$ and encrypts $w_\omega$ with the challenged role set $\Gamma^*$.

Simulator $\mathcal{B}$ first computes $h_{w_\omega} = H_1(w_\omega)$. It then chooses a random element $K \in \mathbb{G}_T$ and five polynomials $q_1(x), q_2(x), q_3(x), q_4(x)$ and $q_5(x)$ of degree $2, |\Gamma^*|, |\Gamma^*|, |\Gamma^*|$, and $|\Gamma^*|$ respectively as follows:

* $q_1(x)$: Simulator $\mathcal{B}$ implicitly sets $q_1(0) = c$ and randomly chooses the rest of the points to define the polynomial $q_1(x)$ completely. Note that $q_1(1)$ and $q_1(2)$ implicitly represent $d_i$ and $d_j$ of our original scheme respectively.

* $q_2(x)$: Simulator $\mathcal{B}$ sets $q_2(0) = q_1(1)$ and randomly chooses the rest of the points to define $q_2(x)$ completely.

* $q_3(x)$: Simulator $\mathcal{B}$ sets $q_3(0) = q_1(2)$ and randomly chooses the rest of the points to define $q_3(x)$ completely.

* $q_4(x)$: Simulator $\mathcal{B}$ sets $q_4(0) = q_1(1)$ and randomly chooses the rest of the points to define $q_4(x)$ completely.

* $q_5(x)$: Simulator $\mathcal{B}$ sets $q_5(0) = q_1(2)$ and randomly chooses the rest of the points to define $q_5(x)$ completely.

Now, simulator $\mathcal{B}$ computes a challenged ciphertext $\mathrm{CT}_\omega =$
<table><caption>TABLE II: NOTATIONS</caption><thead><tr><th>Notation</th><th>Description</th></tr></thead><tbody><tr><td>|Γ|</td><td>Total number of roles associated with a ciphertext</td></tr><tr><td>|Γ<sub>Φ</sub>|</td><td>Total number of SAs associated with Γ (i.e., ciphertext)</td></tr><tr><td>|S<sub>ID<sub>u</sub></sub>|</td><td>Total number of roles associated with a trapdoor</td></tr><tr><td>n<sub>c</sub></td><td>Total number of ciphertext associated with a revoked role</td></tr><tr><td>n<sub>u</sub></td><td>Total number of users associated with a revoked role</td></tr><tr><td>n<sub>s</sub></td><td>Total number SA associated with a user</td></tr></tbody></table>

$\langle C_1, C_2, C_3, \{C_{4k}, C'_{4k}\}_{\forall k \in \Gamma_{\Phi}^*}, \{C_{r_i^k}, C'_{r_i^k}\}_{\forall r_i^k \in \Gamma^*} \rangle$, where

$$
\begin{align*}
C_1 &= \mathbf{K} \cdot Z \\
C_2 &= g^{b \cdot \zeta_k \cdot q_1(2)} = B^{\zeta_k \cdot q_1(2)} \\
C_3 &= g^{b \cdot \vartheta_k \cdot H_2 \left(g^{\frac{a \cdot b \cdot h_{id_c^*}}{b \cdot \vartheta_k}}\right) \cdot q_1(2)} = B^{\vartheta_k \cdot H_2 \left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right) \cdot q_1(2)} \\
C_{4k} &= \left\{ g^{b \cdot \vartheta_k \cdot H_2 \left(g^{\frac{a \cdot b \cdot h_{id_c^*}}{b \cdot \vartheta_k}}\right) \cdot q_2(i) \right. \\
&\qquad \left. = B^{\vartheta_k \cdot H_2 \left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right) \cdot q_2(i)} \right\}, \quad 1 \le i \le |\Gamma_{\Phi}^*| \\
C'_{4k} &= \left\{ g^{b \cdot \vartheta_k \cdot H_2 \left(g^{\frac{a \cdot b \cdot h_{id_c^*}}{b \cdot \vartheta_k}}\right) \cdot q_3(i) \right. \\
&\qquad \left. = B^{\vartheta_k \cdot H_2 \left(A^{\frac{h_{id_c^*}}{\vartheta_k}}\right) \cdot q_3(i)} \right\}, \quad 1 \le i \le |\Gamma_{\Phi}^*| \\
C_{r_i^k} &= \left\{ g^{h_{w_\omega} \cdot b \cdot q_4(i) \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}} \right. \\
&\qquad \left. = B^{h_{w_\omega} \cdot q_4(i) \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}} \right\}, \quad 1 \le i \le |\Gamma^*| \\
C'_{r_i^k} &= \left\{ g^{h_{w_\omega} \cdot b \cdot q_5(i) \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}} \right. \\
&\qquad \left. = B^{h_{w_\omega} \cdot q_5(i) \prod_{\forall r_j^k \in \mathbb{R}_{r_i^k}} \alpha_{r_j^k}} \right\}, \quad 1 \le i \le |\Gamma^*| \tag{32}
\end{align*}
$$

Similar with CPA proof VI-A1, the distribution of the ciphertext $CT_\omega$ for $\Gamma^*$ is identical to the original scheme.

### PHASE 2 Same as PHASE 1

**GUESS** The adversary $\mathcal{A}_2$ guesses a bit $\omega'$ and sends to the simulator $\mathcal{B}$. If $\omega' = \omega$ then the adversary $\mathcal{A}_2$ wins CPA game; otherwise it fails. If $\omega' = \omega$, simulator $\mathcal{B}$ answers “DBDH” in the game (i.e. outputs $l = 0$); otherwise $\mathcal{B}$ answers “random” (i.e. outputs $l = 1$).

If $Z = \hat{e}(g, g)^z$; then $C_1$ is completely random from the view of the adversary $\mathcal{A}_2$. So, the received ciphertext $CT_\omega$ is not compliant to the game (i.e. invalid ciphertext). Therefore, the adversary $\mathcal{A}_2$ chooses $\omega'$ randomly. Hence, the probability of the adversary $\mathcal{A}_2$ for outputting $\omega' = \omega$ is $\frac{1}{2}$.

If $Z = \hat{e}(g, g)^{abc}$, then adversary $\mathcal{A}_2$ receives a valid ciphertext. The adversary $\mathcal{A}_2$ wins the CPA game with non-negligible advantage $\epsilon$ (according to the Theorem 3). As such, the probability of outputting $\omega' = \omega$ for the adversary $\mathcal{A}_2$ is $\frac{1}{2} + \epsilon$, where probability $\epsilon$ is for guessing that the received ciphertext is valid and probability $\frac{1}{2}$ is for guessing whether the valid encrypted message $C_1$ is related to $w_0$ or $w_1$.

Therefore, the overall advantage $Adv_{\mathcal{A}_2}^{IND-CKA}$ of the simulator $\mathcal{B}$ is $\frac{1}{2}(\frac{1}{2} + \epsilon + \frac{1}{2}) - \frac{1}{2} = \frac{\epsilon}{2}$. $\square$

<figure><img src="image_5.png" /><figcaption>Fig. 4: Computation Time of Data Encryption and Trapdoor Generation Phases</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 5: Computation Time of AUTHENTICATION and PARTIALDEC Algorithms</figcaption></figure>

### B. Performance Analysis

This section evaluates functionality, computation, storage and communication overhead of our proposed scheme. The computational overhead is shown in terms of number of pairing ($T_p$) and group exponentiation operations ($Exp_{\mathbb{G}_1}$ and $Exp_{\mathbb{G}_T}$). We do not consider the other cryptographic operations such as hash and group element multiplication operations, as these operations take much less computation time compared with the pairing and group exponentiation operations (details can be seen in the Table VI). The storage and communication overheads are shown in terms of group element size $|\mathbb{Z}_q^*|$, $|\mathbb{G}_1|$ and $|\mathbb{G}_T|$. We use PBC library [34] which runs over GMP library [35] for the implementation purpose. Type A elliptic curve of 160-bit group order embedding degree 2 is used for the implementation. The chosen curve provides an equivalent of 1024-bit discrete log security. The elementary cryptographic operations that are performed by the owners and users are implemented using a commodity laptop Computer
<table><caption>TABLE III: Functionality Comparison</caption><thead><tr><th></th><th>Authorized Keyword Search</th><th>Authentication</th><th>Replay Attack</th><th>Conjunctive Keyword Search</th><th>Revocation</th><th>Decryption</th><th>Technique</th></tr></thead><tbody><tr><td>[9]</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✓</td><td>✗</td><td>ABE</td></tr><tr><td>[6]</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>ABE</td></tr><tr><td>[25]</td><td>✓</td><td>✗</td><td>✗</td><td>✓</td><td>✓</td><td>✓</td><td>ABE</td></tr><tr><td>[26]</td><td>✓</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>✗</td><td>ABE</td></tr><tr><td>Proposed scheme</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>RBE</td></tr></tbody></table>

<table><caption>TABLE IV: Evaluation of the Computation Overhead</caption><thead><tr><th colspan="2">Operations</th><th>Computation Complexity</th></tr></thead><tbody><tr><td colspan="2">Data Encryption</td><td>(4 + |Γ| + |Γ<sub>Φ</sub>|)Exp<sub>G<sub>1</sub></sub> + Exp<sub>G<sub>T</sub></sub></td></tr><tr><td colspan="2">Trapdoor Generation</td><td>(3 + 2|S<sub>ID<sub>u</sub></sub>|)Exp<sub>G<sub>1</sub></sub></td></tr><tr><td rowspan="3">Data Search</td><td>Authentication</td><td>(2 + |Γ<sub>Φ</sub>|)Exp<sub>G<sub>1</sub></sub> + 3T<sub>p</sub></td></tr><tr><td>KeySearch</td><td>&lt; (|Γ| + 1)Exp<sub>G<sub>1</sub></sub> + (2 + |Γ|)T<sub>p</sub></td></tr><tr><td>PartialDec</td><td>&lt; (|Γ| + |Γ<sub>Φ</sub>|)Exp<sub>G<sub>1</sub></sub> + (1 + |Γ|)T<sub>p</sub></td></tr><tr><td colspan="2">Decryption</td><td>Exp<sub>G<sub>T</sub></sub></td></tr><tr><td colspan="2">Revocation</td><td>&lt; (1 + 2n<sub>c</sub> + 2n<sub>u</sub>)Exp<sub>G<sub>1</sub></sub></td></tr></tbody></table>

<table><caption>TABLE V: Evaluation of the Storage and Communication Overhead</caption><thead><tr><th>Items</th><th>Overhead</th></tr></thead><tbody><tr><td>Ciphertext</td><td>(4 + 2|Γ|)|G<sub>1</sub>| + |G<sub>T</sub>|</td></tr><tr><td>Secret key</td><td>(1 + n<sub>s</sub>)|Z<sub>q</sub>| + 2|S<sub>ID<sub>u</sub></sub>| |G<sub>1</sub>|</td></tr><tr><td>Trapdoor</td><td>|Z<sub>q</sub>| + (3 + 2|Γ|)|G<sub>1</sub>|</td></tr></tbody></table>

<table><caption>TABLE VI: Computation Time (in Milliseconds) of Elementary Cryptographic Operations</caption><thead><tr><th rowspan="2"></th><th colspan="2">Exponentiation</th><th rowspan="2">Pairing</th><th colspan="2">Group multiplication</th><th rowspan="2">Hash</th></tr><tr><th>G<sub>1</sub></th><th>G<sub>T</sub></th><th>G<sub>1</sub></th><th>G<sub>T</sub></th></tr></thead><tbody><tr><td>Commodity Laptop</td><td>2.062</td><td>0.126</td><td>1.292</td><td>0.008</td><td>0.002</td><td>0.003</td></tr><tr><td>Workstation</td><td>1.153</td><td>0.091</td><td>0.645</td><td>0.005</td><td>0.001</td><td>0.002</td></tr></tbody></table>

<figure><img src="image_7.png" /><figcaption>Fig. 6: Computation Time of KEYSEARCH Algorithm for 1000 Ciphertexts</figcaption></figure>

with Ubuntu 17.10 (64-bit) operating system and having 2.4GHz Core i3 processor with 4GB memory. The elementary cryptographic operations that are performed by public cloud is implemented using a workstation with Ubuntu 17.10 (64-bit) operating system and having 3.5 GHz Intel(R) Xeon(R) CPU E5-2637 v4 processor with 16 GB memory. Table VI shows the time required to perform each cryptographic operations.

During the implementation, we consider that the number of SAs associated with a RBAC access policy is equal to the number of roles associated with a ciphertext, i.e., $|Γ_Φ| = |Γ|$. It is to be noted that all the implementation results are the mean of 50 trials. The notations used in the rest of this paper are shown in Table II.

Table III shows the functionality comparison of some notable ABE based keyword search schemes [6], [9], [25], [26] with our proposed scheme. From the Table III, it can be observed that all the ABE based schemes [6], [9], [25], [26] including our proposed scheme provide authorized keyword search functionality, as the owner can embed access policies of his/her choice on the encrypted data itself. However, unlike our proposed scheme, none of the schemes in [6], [9], [25], [26] address the user authentication problem, which allows the public cloud to authenticate the user before performing computationally expensive keyword search operations. As such, [6], [9], [25], [26] rely on some existing authentication mechanisms. Also, unlike [6], [9], [25], [26], our proposed scheme can prevent the replay attacks even if the trapdoors are exposed to the adversaries. In [6], [9], [25], [26], if an adversary gains access to a valid trapdoor, the adversary can re-use the trapdoor using a fresh random number. Further, our proposed scheme and [9], [25] support conjunctive keyword search and user revocation, while [6], [26] do not support. Moreover, our proposed scheme and [25] support both the keyword search and decryption functionalities; while [6], [9], [26] support only the keyword search functionality. Furthermore, [6], [9], [25], [26] are designed using ABE technique; while our proposed scheme is designed using RBE technique, which enables it to support the role hierarchy property. Thus, it makes our proposed scheme more suitable for the real world organizations/enterprises. Therefore, it can be observed that our proposed scheme supports more functionalities compared with the other notable works [6], [9], [25], [26].

Table IV shows the computation overhead of our proposed scheme<fnref n="9" />. The computation cost is shown in asymptotic upper bound in the worst cases. In Table IV, we consider the most frequently operated phases, e.g., *Data Encryption*, *Trapdoor Generation*, *Data Search*, *Decryption*, and *Revocation*.

a) *Data Encryption:* Owner encrypts the plaintext data and the associated keywords in the *Data Encryption* phase, which requires $(4 + 2|Γ|)$ group exponentiation operations on $G_1$ and one exponentiation operation on $G_T$. It can be observed that the encryption cost mainly depends on the number of roles associated with a ciphertext (i.e., associated with the chosen RBAC access policy). This can also be seen

<footnote n="9">⁹We do not consider [6], [9], [25], [26] for further comparison, as they are based on ABE; whereas our proposed scheme is based on RBE.</footnote>
from the Figure 4. It can be observed that approximately 31 milliseconds are required to generate a ciphertext associated with 5 roles and 5 SAs. It is to be noted that, the encryption operation is performed by the owner only once for a particular data.

b) Trapdoor Generation: A user needs to perform ($3 + 2|\mathbb{S}_{ID_u}|$) group exponentiation operations on $\mathbb{G}_1$ to compute a trapdoor. It can be observed that the cost for the generation of a trapdoor depends on the number of roles associated with the user (i.e., associated with the trapdoor). Figure 4, shows the experimental results of the *Trapdoor Generation* phase, which demonstrates that our proposed scheme incurs less computation overhead on the user side. It takes approximately 29 milliseconds to generate a trapdoor having 5 roles.

c) Data Search: In the *Data Search* phase, the public cloud first authenticates the user which requires $2+|\Gamma_{\Phi}|$ group exponentiation operations on $\mathbb{G}_1$ and three pairing operations. It can be observed that the cost of the user authentication operation (i.e., AUTHENTICATION algorithm) depends on the number of SAs associated with the RBAC access policy of a ciphertext. Figure 5 shows the computation time of AUTHENTICATION algorithm with respect to the number of SAs. It is to be noted that the AUTHENTICATION algorithm is performed only once per user request. After successful authentication of the user, the public cloud computes at most $|\Gamma| + 1$ group exponentiation operations on $\mathbb{G}_1$, and $2 + |\Gamma|$ pairing operations to complete the KEYSEARCH algorithm for the keyword search. It can be observed that the cost of the KEYSEARCH algorithm depends on the number of roles associated with the ciphertext, which can also be seen from the Figure 6. Finally, the public cloud computes at most $|\Gamma| + |\Gamma_{\Phi}|$ group exponentiation operations and $1 + |\Gamma|$ pairing operations to compute the PARTIALDEC algorithm. It can be observed that the cost to perform the PARTIALDEC algorithm depends on the number of roles and the number of SAs associated with the RBAC access policy. The computation time of PARTIALDEC algorithm is shown in the Figure 5. It is to be noted that the PARTIALDEC algorithm is performed for each ciphertext received from the KEYSEARCH algorithm.

d) Decryption: As most of the computationally expensive cryptographic operations are outsourced to the public cloud, a user requires only one group exponentiation operation on $\mathbb{G}_T$ to decrypt a ciphertext. It is to be noted that the time required to perform one group exponentiation operation on $\mathbb{G}_T$ is 0.126 milliseconds in a commodity laptop Computer. Hence, the decryption cost in our proposed scheme is considerably less. Thus, our proposed scheme is also suitable for an environment such as IoT, where the end-users have limited computing resources.

e) Revocation: The complete user revocation operation takes a minimal overhead in the system, as the SA can revoke the user simply by revoking (or removing) his/her public key (from the public bulletin board). On the other hand, the SA requires at most $1+2n_c+2n_u$ group exponentiation operations on $\mathbb{G}_1$ to revoke a role from a user. As the SA needs to re-encrypt all the ciphertexts and update role-keys of all the users related with the revoked roles, the cost of the role-level revocation depends mainly on the number of ciphertext and

users associated with the revoked roles.

1) Storage and Communication Overhead Comparison: Table V shows the storage and communication overhead of our proposed scheme. For the evaluation purpose, the ciphertext size, size of the secret keys possessed by a user, and the trapdoor size are considered. From Table V, it can be observed that the ciphertext size mainly depends on the number of roles associated with the ciphertext. For each role $r_i^k$, the owner computes two ciphertext components $C_{r_i^k}$ and $C'_{r_i^k}$. Hence, the ciphertext size linearly increases with the roles associated with a ciphertext.

A user keeps a private key $\text{Priv}_{\text{ID}_u}^k$ for each organization, and the user also keeps a common private key $\text{Priv}_{\text{ID}_u}$ for all the organizations. Moreover, the user keeps two role-keys for each role he/she possessed. Thus, the size of the secret key possessed by a user mainly depends on the number of SAs (i.e., number of organizations) and the number of roles associated with that user. Similarly, trapdoor size linearly increases with the roles associated with the trapdoor. The user computes two trapdoor components $tr_{r_x}^1$ and $tr_{r_x}^2$ for each role $r_x^k$ associated with the trapdoor.

## VII. CONCLUSION

This paper has proposed a novel authorized keyword search mechanism with efficient decryption using the RBE technique for a cloud environment, where multiple organizations can outsource their sensitive data. The proposed scheme enables the owners to define and enforce RBAC access policies on the encrypted data, thereby avoiding reducing the dependency on the service provider. It also enables the public cloud to authenticate the users first before performing computationally expensive search operations, which reduces overhead on the system. In addition, the proposed scheme helps to prevent replay attacks. Conjunctive keyword search is supported without introducing any significant overhead into the system. Further, the complete and role-level user revocation mechanisms are supported for revoking access privileges of the users in both organization level and role level respectively. Moreover, an outsourced decryption mechanism is introduced in the proposed scheme to reduce decryption processing cost at the end-user side, which makes it suitable for resource constrained environment. Furthermore, we have formally proved that the proposed scheme provides provable security against Chosen Plaintext and Chosen Keyword Attacks. Our performance analysis shows that the proposed scheme is suitable for real-world applications in terms of computation, communication and storage overhead.

This paper has introduced a new direction in designing a searchable encryption mechanism using the RBE technique. Further works include improving the efficiency of role-level revocation of RBE based keyword search schemes as well as for dynamic addition (removal) of roles into (from) a role hierarchy.

## ACKNOWLEDGEMENT

This paper is supported in part by European Union's Horizon 2020 research and innovation programme under the grant agreement No 830892, project SPARTA.
REFERENCES

[1] J. D. Ferrer, O. Farrs, J. Ribes-Gonzlez, and D. Snchez. Privacy-preserving cloud computing on sensitive data: A survey of methods, products and challenges. *Computer Communications*, 140-141:38–60, 2019.

[2] McAfee. Navigating a Cloudy Sky: Practical Guidance and the State of Cloud Security. White paper, 2018.

[3] P. Mell and T. Grance. The NIST definition of cloud computing. Technical report, National Institute of Standards and Technology, 2009. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf [Online accessed: 7-Feb.-2019].

[4] Christoph Bösch, Pieter Hartel, Willem Jonker, and Andreas Peter. A Survey of Provably Secure Searchable Encryption. *ACM Comput. Surv.*, 47(2):18:1–18:51, Aug. 2014.

[5] F. Han, J. Qin, and J. Hu. "secure searches in the cloud: A survey". *Future Generation Computer Systems*, 62:66 – 75, 2016.

[6] B. Hu, Q. Liu, X. Liu, T. Peng, G. Wang, and J. Wu. DABKS: Dynamic attribute-based keyword search in cloud computing. In *Proceedings of the 2017 IEEE International Conference on Communications (ICC)*, pages 1–6, May 2017.

[7] F. Bao, R. H. Deng, X. Ding, and Y. Yang. Private Query on Encrypted Data in Multi-user Settings. In *Proceedings of the 4th International Conference on Information Security Practice and Experience*, ISPEC’08, pages 71–85, 2008.

[8] M. Li, S. Yu, N. Cao, and W. Lou. Authorized Private Keyword Search over Encrypted Data in Cloud Computing. In *2011 31st International Conference on Distributed Computing Systems*, pages 383–392, June 2011.

[9] W. Sun, S. Yu, W. Lou, Y. T. Hou, and H. Li. Protecting Your Right: Verifiable Attribute-Based Keyword Search with Fine-Grained Owner-Enforced Search Authorization in the Cloud. *IEEE Transactions on Parallel and Distributed Systems*, 27(4):1187–1198, April 2016.

[10] L. Zhou, V. Varadharajan, and M. Hitchens. Achieving Secure Role-Based Access Control on Encrypted Data in Cloud Storage. *IEEE Transactions on Information Forensics and Security*, 8(12):1947–1960, Dec 2013.

[11] J. M. Marn Prez, G. M. Prez, and A. F. Skarmeta Gomez. SecRBAC: Secure data in the Clouds. *IEEE Transactions on Services Computing*, 10(5):726–740, Sep. 2017.

[12] L. Zhou, V. Varadharajan, and M. Hitchens. Enforcing Role-Based Access Control for Secure Data Storage in the Cloud. *The Computer Journal*, 54(10):1675–1687, Oct. 2011.

[13] Y. Zhu, G. Ahn, H. Hu, D. Ma, and S. Wang. Role-Based Cryptosystem: A New Cryptographic RBAC System Based on Role-Key Hierarchy. *IEEE Transactions on Information Forensics and Security*, 8(12):2138–2153, Dec 2013.

[14] R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Role-based access control models. *Computer*, 29(2):38–47, Feb 1996.

[15] J. Bethencourt, A. Sahai, and B. Waters. Ciphertext-Policy Attribute-Based Encryption. In *2007 IEEE Symposium on Security and Privacy (SP '07)*, pages 321–334, May 2007.

[16] Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters. Attribute-based Encryption for Fine-grained Access Control of Encrypted Data. In *Proceedings of the 13th ACM Conference on Computer and Communications Security*, CCS '06, pages 89–98, 2006.

[17] D. X. Song, D. Wagner, and A. Perrig. Practical techniques for searches on encrypted data. In *Proceeding 2000 IEEE Symposium on Security and Privacy. S P 2000*, pages 44–55, May 2000.

[18] R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. Searchable Symmetric Encryption: Improved Definitions and Efficient Constructions. In *Proceedings of the 13th ACM Conference on Computer and Communications Security*, CCS '06, pages 79–88, 2006.

[19] S. Kamara, C. Papamanthou, and T. Roeder. Dynamic Searchable Symmetric Encryption. In *Proceedings of the 2012 ACM Conference on Computer and Communications Security*, CCS '12, pages 965–976, 2012.

[20] J. Li, Y. Huang, Y. Wei, S. Lv, Z. Liu, C. Dong, and W. Lou. Searchable symmetric encryption with forward search privacy. *IEEE Transactions on Dependable and Secure Computing*, pages 1–1, 2019.

[21] T. Hoang, A. A. Yavuz, and J. Guajardo Merchan. A secure searchable encryption framework for privacy-critical cloud storage services. *IEEE Transactions on Services Computing*, pages 1–1, 2019.

[22] X. Liu, G. Yang, Y. Mu, and R. Deng. Multi-user Verifiable Searchable Symmetric Encryption for Cloud Storage. *IEEE Transactions on Dependable and Secure Computing*, pages 1–1, 2018.

[23] D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano. Public Key Encryption with Keyword Search. In *Proceedings of the International Conference on the Theory and Applications of Cryptographic Techniques: Advances in Cryptology, EUROCRYPT'04*, pages 506–522, 2004.

[24] D. Boneh and B. Waters. Conjunctive, Subset, and Range Queries on Encrypted Data. In *Proceedings of the 4th Conference on Theory of Cryptography*, TCC'07, pages 535–554, 2007.

[25] Y. Miao, J. Ma, X. Liu, X. Li, Q. Jiang, and J. Zhang. Attribute-Based Keyword Search over Hierarchical Data in Cloud Computing. *IEEE Transactions on Services Computing*, pages 1–1, 2017.

[26] P. Chaudhari and M. L. Das. Privacy Preserving Searchable Encryption with Fine-grained Access Control. *IEEE Transactions on Cloud Computing*, pages 1–1, 2019.

[27] N. H. Sultan, N. Kaaniche, M. Laurent, and F. A. Barbhuiya. Authorized Keyword Search over Outsourced Encrypted Data in Cloud Environment. *IEEE Transactions on Cloud Computing*, pages 1–1, 2019.

[28] S. G. Akl and P. D. Taylor. Cryptographic solution to a problem of access control in a hierarchy. *ACM Transactions on Computer Systems*, 1(3):239–248, Aug. 1983.

[29] Y.L. Lin and C. L. Hsu. Secure key management scheme for dynamic hierarchical access control based on ecc. *Journal of Systems and Software*, 84(4):679 – 685, 2011.

[30] S. Tang, X. Li, X. Huang, Y. Xiang, and L. Xu. Achieving simple, secure and efficient hierarchical access control in cloud computing. *IEEE Transactions on Computers*, 65(7):2325–2331, July 2016.

[31] Y. R. Chen and W. G. Tzeng. Hierarchical key assignment with dynamic read-write privilege enforcement and extended ki-security. In *Proceedings of the Applied Cryptography and Network Security*, pages 165–183, 2017.

[32] G. Pareek and B. R. Purushothama. Efficient strong key indistinguishable access control in dynamic hierarchies with constant decryption cost. In *Proceedings of the 11th International Conference on Security of Information and Networks*, SIN '18, pages 10:1–10:7, 2018.

[33] M. Burmester and Y. Desmedt. A Secure and Scalable Group Key Exchange System. *Information Processing Letters*, 94(3):137–143, May 2005.

[34] PBC (Pairing-Based Cryptography) library. http://crypto.stanford.edu/pbc/ [Online accessed: 12-August-2019].

[35] GMP(GNU Multiple Precision) arithmetic library. http://gmplib.org/ [Online accessed: 12-August-2019].