A Collusion-Resistant Identity-Based Proxy Reencryption Scheme with Ciphertext Evolution for Secure Cloud Sharing

In order to solve the challenges of user data security in the cloud computing (storage) environment, many encryption solutions with different features have been presented. Among them, proxy reencryption (PRE) based on public-key infrastructure (PKI) is a promising technology for secure cloud sharing. And identity-based proxy reencryption (IBPRE), which uses identity as the public key, eliminates burdensome certificate management and is, therefore, more preferable. However, most of the current IBPRE schemes only focus on the processing of data sharing while overlooking the functions of authorization revocation and ciphertext update, which are more closely related to the security of data itself. Moreover, the few existing schemes that involve ciphertext update turn out to be impractical because the length of ciphertext increases with the reencryption of ciphertext. In this paper, an improved IBPRE scheme, which provides improvements on the inadequacies of the scheme proposed by Ateniese et al. especially in terms of collusion safety and ciphertext evolution, is proposed. To the best of our knowledge, this is a practical IBPRE scheme integrating the functions of access authorization, delegation revocation, ciphertext update, reauthorization, and conditional reservation delegation.)e proposed technique has high practicability in the scenario where a large number of ciphertexts need to be updated synchronously. Lastly, the comparative analysis and simulation results show that the two reencryption algorithms in the proposed scheme have the shortest computing time than other schemes.


Introduction
With the advancement and prevalence of cloud computing technology, more and more users opt to store their user data on cloud servers due to its convenience and ubiquity of access. However, different from local storage, the control and ownership of data in cloud storage are separated, and the cloud server is not completely trustworthy. Outsourcing data to the cloud will face many security issues and challenges in data integrity, confidentiality, access authorization, ciphertext search, and ciphertext evolution. To solve these security problems, many scholars have conducted numerous relevant researches and proposed various solutions. For example, there are cloud storage public auditing schemes for data integrity [1], proxy reencryption (PRE) schemes for encrypted data authorization [2], identity-based encryption (IBE) schemes with keyword search [3], IBE schemes supporting ciphertext update evolution [4], and lattice-based encryption (LBE) schemes to achieve postquantum security [5]. Some of these solutions addressed multiple aspects of data security, while others focused on only one or two aspects of data security. For example, the PRE scheme [6] assumes that the proxy is semitrusted and will follow the protocol and not tamper with the user's data to ensure data integrity. It only focuses on confidentiality and access authorization of the data.
It is too complex and unrealistic to consider all security issues in one cloud storage solution, but it is feasible and necessary to assemble some security requirements into one system. For example, in a personal data public cloud sharing application scenario, it urgently requires an encryption solution, which includes functions of access authorization, key update, ciphertext update, authorization revocation, reauthorization, conditional reservation authorization, and avoids complex certificate management. e consideration is based on the reasons as follows: (1) Access authorization is the primary function of secure cloud data sharing. If a user's encrypted private data stored in the cloud are accessed only by himself but not shared with others, it is not as convenient as carrying a large mobile storage device around. At present, to realize secure authorization of encrypted data, PRE technology is considered as the most promising solution. Also, identity-based proxy reencryption (IBPRE) uses identity as the public key, eliminates burdensome certificate management, and is, therefore, more preferable. (2) Authorization revocation is also a function that must be considered in the personal data cloud sharing scheme. If a user's identity has expired or his key has been broken, his access permission should be revoked. (3) e necessity of reauthorization. If the original authorization expires or becomes invalid after the ciphertext is updated or the key is updated, the authorization must be renewed for the legitimate user. (4) e need for the key update. For cryptography systems, its security relies on the protection of the key. According to the Special Publication SP-80057 [7] issued by the National Institute of Technology (NIST), cryptograph-based ciphertext key has a strict life cycle; that is, the key needs to be updated after a certain period. (5) e requirement of ciphertext update. ere are two types of ciphertext update. e first one is passive update. If the authorized access permission is revoked, the encrypted ciphertext should be renewed to prevent the old authorization key and the revoked visitor from continuing to access the ciphertext. e second one is active update, also be termed ciphertext evolution. If the delegator updates his encryption key, the ciphertext needs to evolve synchronously. (6) Special requirements for conditional reservation authorization. Sometimes, the user wants to specify the requestor's access right at the reserved time to implement access control. For instance, one user with a solar energy collection system wants to sell the excess energy to others in the microgrid. Similarly, other prosumers also wish to sell their excess energy. ese suppliers will share their energy information to an energy consumer, who cannot access the report containing the energy price in advance. Otherwise, it may lead to malicious bidding or collusion.
As far as we know, the IBPRE scheme can basically achieve access authorization without complicated certificate management.
ere are also some proposals that have supported conditional authorization [8,9], some systems that have achieved authorization revocation [10,11], and some schemes that have even considered the function of updating ciphertext [10]. However, no satisfactory solution has been found to meet all of the above needs. erefore, this motivates our work to find a practical IBPRE scheme with functions of access authorization, ciphertext update, and delegation revocation.
1.1. Related Work. PRE allows a proxy to convert a ciphertext under one user's (delegator's) public key into another ciphertext which can be decrypted with another user's (delegatee's) private key, without disclosing the underlying plaintext and secret key information. Since Blaze et al. [12] proposed the first PRE scheme, a large number of PRE schemes with different characteristics have been presented.
In [13], Nuñez et al. reviewed, compared, and analyzed the main PRE researches. eir study included PKI-based proxy reencryption [14][15][16], identity-based proxy reencryption (IBPRE) [17,18], attribute-based proxy reencryption (ABPRE) [19,20], and lattice-based proxy reencryption (LBPRE) [21]. Among these studies, the IBPRE scheme is presented to be an important research direction. It combines identity-based encryption (IBE) [22,23] and PRE [12], where the user's identity is used as the public key for encryption, avoiding the complex public-key certificate management which is beneficial in several scenarios. Green and Ateniese [18] put forward the first IBPRE scheme, in which two noncollusion safe approaches were introduced, and some promising applications of IBPRE were mentioned. Subsequently, many improvements and applications were proposed to meet various needs and shortages of previous solutions. Wang et al. [24] proposed two IBPRE schemes that could resist collusion attacks. e first one has no ciphertext expansion, while the second one achieves CCA security. Wang et al. [25] gave an improved multiuse IBPRE scheme, which achieves CCA2 security in the random oracle model. eir solution gives a confirmable answer to the open problem mentioned in [18]. Shao and Cao [26] introduced the first CCA-secure and collusion-safe IBPRE scheme in the standard model. Xu et al. [8] presented a conditional identity-based broadcast PRE scheme and applied it to cloud e-mail. Zhou et al. [27] proposed an IBPRE scheme with version 2, which provides a ciphertext transformation from complicated identity-based broadcast encryption (IBBE) to simple IBE. Ge et al. [9] presented a secure fine-grained identity-based broadcast PRE scheme for encrypted microvideo sharing. e schemes mentioned above analyzed the efficiency, security, and access control of the algorithms in detail but did not consider the functions of permission revocation and ciphertext evolution.
Liang et al. [10] proposed an efficient cloud-based revocable IBPRE scheme for periodic key and ciphertext updates by updating time tokens, in which the length of ciphertext increases linearly with the number of times of reencryption. Sun et al. [4] proposed a CCA-secure revocable IBE with ciphertext evolution for data sharing in cloud storage, which emphasizes that the size of the ciphertext in the cloud remains in constant size regardless of evolutions. However, their approach is not based on PRE. e ciphertext stored in the cloud is encrypted by the data owner using the identity of the requester instead of his own identity, which means that there are multiple ciphertexts stored on the cloud corresponding to different requesters, instead of only one ciphertext in the PRE system. Shafagh et al. [6] realized a project that includes functions of authorization, revocation, key update, and ciphertext update in PKI-based architecture, which needs complex certificate management.
Intuitively, IBPRE (such as in [10,25,26]) can be used directly for updating ciphertext, but usually ciphertext grows with the number of encryption times, which is not practical.

Our Contributions.
Inspired by the work presented in [6], we propose an improved IBPRE scheme, which includes the functions above for a secure personal data cloud sharing application.
is improved approach has the characteristics of noninteractivity, unidirectionality, collusion safety, ciphertext optimization, and multiuse and nontransferability in the random oracle model. Moreover, the ciphertext update (reencryption) operations can be executed multiple times, and the ciphertext length remains the same. e ciphertext reencrypted (delegated) to the delegate, however, cannot be reencrypted (reauthorized). e improvements are based on Green and Ateniese [18] and aim to realize secure user data sharing on cloud servers by combining essential characteristics of data sharing, ciphertext updating, and attribute-based access permission granting and revocation. Furthermore, the scheme also highlights the properties of multiuse and collusion-resistant and the optimization of reencryption performance (that shortens reencryption time; ensure efficiency when many users access data, or much ciphertext updated concurrently). e main contributions of this paper are as follows: (1) Provide improvements in the work proposed in [18] that focuses on achieving collusion safety and multiuse without ciphertext expansion and minimizing reencryption time.
(2) Propose a practical IBPRE scheme that includes functions of access authorization, delegation revocation, ciphertext update, reauthorization, and conditional reservation delegation to implement secure cloud data sharing. (3) Apply the improved IBPRE scheme to a practical secure user data sharing application and provided an analysis comprehensively. e rest of the paper is organized as follows. Section 2 describes some of the cryptographic primitives, definitions, and some properties of the proxy reencryption. e system model and the assumptions of the proposed scheme are given in Section 3. e improved IBPRE algorithm is described in detail in Section 4, and the application of the improvements is deployed to a secure cloud data sharing scenario presented in Section 5. A comparison and analysis of the proposed scheme and existing schemes are provided in Section 6, and finally, the conclusion is given in Section 7.

Bilinear Map and Decisional Bilinear Diffie-Hellman
Problem [25] Definition 1 (bilinear map). Let G 1 and G 2 are two cyclic groups of the same prime order q and g be a generator of G 1 . We say that e: G 1 × G 1 ⟶ G 2 is a bilinear map if it satisfies the following properties: (1) Bilinear: for all a, b ∈ Z * q and g ∈ G 1 , e(g a , g b ) � e(g, g) ab .
Definition 2 (decisional bilinear Diffie-Hellman (DBDH) problem). Let G 1 and G 2 are two cyclic groups of the same prime order q and g be a generator of G 1 . Support that e: G 1 × G 1 ⟶ G 2 is a bilinear map. e decisional bilinear Diffie-Hellman (DBDH) problem is to decide, given a tuple of values (g, g a , g b , g c , T) ∈ G 4 1 × G 2 (where a, b, c∈ R Z * q ), whether T � e(g, g) abc holds.
Let k be a security parameter of sufficient size. Formally, we say that the DBDH assumption holds in G 1 , G 2 , e, if for all probabilistic polynomial time (PPT) algorithm A, the following condition is true, where v(·) is defined as a negligible function:
We say that an IBPRE-CE scheme is consistent if for any valid identities id 1 , id 2 , and id 1 ′ , their secret keys sk id 1 , sk id 2 , and sk id 1 ′ (generated by KeyGen), the corresponding reencryption key rk id 1 ⟶ id 1 ′ and rk id 1 ⟶ id 2 (generated by RKGen 2 and RKGen 1 ), and ciphertexts c id 1 , c id 2 , and c id 1 ′ (computed by Encrypt, Reencrypt 1 , and Reencrypt 2 ), the following equations hold: (1) Setup. e challenger C runs Setup(1 k ) to generate the master public parameters (mpp) and the master secret key (msk). e mpp is sent to A, while the msk is kept securely. (2) Phase 1. A issues some private key queries O sk , updates reencryption key queries O uk , and delegation reencryption key queries O dk as follows: (i) On receiving any query of the form (O sk , id), C returns sk id ←KeyGen(mpp, msk, id) to A. (ii) On receiving any query of the form (O dk , id 1 , id 2 , C 1 ), C returns rk id 1 ⟶ id 2 ←RKGen 1 (mpp, sk id 1 , id 1 , id 2 , C 1 ) to A, where sk id 1 ← KeyGen(mpp, msk, id 1 ) and C 1 is an element of ciphertext. (iii) On receiving any query of the form (O uk , id 1 , id 1 ′ , C 1 ), C returns rk id 1 ⟶ id 1 ←RKGen 2 (mpp, sk id 1 , id 1 ′ , C 1 ) to A, where sk id 1 ←KeyGen (mpp, msk, id 1 ) and C 1 is an element of ciphertext.
(4) Challenge. At the end of phase 1, A outputs two equal-length messages m 0 and m 1 , and a challenging identity id * which does not exist in trivial decryption (e.g., A holds a private key of id * or some transformation keys which are update reencryption keys or delegation reencryption keys from id * to id and the decryption key of id ). e challenger C returns a challenge ciphertext A adaptively issues queries as phase 1 with some restrictions that the private key of id * and any trivial decryption key query (O sk , O uk , O dk ) have never been queried. e restrictions are as follows: (i) e private key corresponding to id * has not been queried. (ii) If a series of update key queries which originate from id * to id 1 , next from id 1 to id 2 ,. . ., from id n− 1 to id n , have been issued, the private key of any id in set ID = {id 1 , id 2 , . . . id n } has not been queried. (iii) If the delegation key query from id * to id j has been issued, the private key of id j has not been queried. (iv) If a series of update key queries which originate from id * to id 1 , next from id 1 to id 2 ,. . ., from id n− 1 to id n have been issued, and delegation key from any id in set ID = {id 1 , id 2 , . . . id n } to id j has been queried, the private key of id j has not been queried.

Properties of Proxy Reencryption.
In literature [13], Nuñez et al. summarized several security concepts and properties of PRE and described that the existing schemes are either unidirectional or bidirectional, single use or multiuse, collusion safe or not, transferable or nontransferable, transitive or nontransitive, identity-based or not, and interactive or noninteractive. In addition, based on the achieved notion of security, PRE schemes can achieve chosen plaintext attacks (CPAs) security or chosen ciphertext attacks (CCAs) security. For clarity, this subsection briefly reiterates some of these properties, in particular, giving focus to those that are provided by the proposed scheme and are relevant for practical instantiations of IBPRE: (1) Noninteractivity: this property means that the user does not need to interact with the requester or trusted third party because there is no need for their secret information (e.g., private key or master system key) to generate the reencryption key. With this property, the user can delegate access permission to the requester without interaction and can even assign a requester's decryption condition associated with its identity.
(2) Multiuse capability: the ciphertext can be converted multiple times, e.g., from the ciphertext c id 1 to ciphertext c id 2 and from ciphertext c id 2 to ciphertext c id 3 . erefore, the data owner can update the ciphertext multiple times as needed.
(3) Collusion safety: in this characteristic, even if the delegatee colludes with the proxy, the delegator's private key does not be compromised. And we can denote it as rk id 1 ⟶ id 2 + sk id 2 ↛sk id 1 , where rk id 1 ⟶ id 2 is the reencryption key known by the proxy, and sk id 2 is id 2 's (delegatee's) private key, and sk id 1 is id 1 's (delegator's) private key.
(4) Nontransitivity: in this characteristic, the proxy (or two colluded proxies) cannot derive a reencryption key from two continuous reencryption keys. For example, rk id 1 ⟶ id 2 and rk id 2 ⟶ id 3 can get rk id 1 ⟶ id 3 .
(5) Nontransferability: this property means that a delegatee (even if colludes with the proxy) cannot transfer the decryption ability to a third party or entity. For example, user id 1 generates the reencryption key rk id 1 ⟶ id 2 to delegate the decryption capacity to the requestor id 2 who can decrypt the reencrypted ciphertext but cannot generate a new delegation key which originates from id 1 (i.e., rk id 1 ⟶ id 3 ) or reencrypt the delegation ciphertext to generate a new ciphertext which can be decrypted by a third entity with the private key sk id 3 . (6) Unidirectionality: with the reencryption key rk id 1 ⟶ id 2 , the proxy can convert user id 1 's ciphertext to another one that can be decrypted by the user id 2 , but not vice versa. (7) Ciphertext optimality: the ciphertext does not expand upon reencryption. is property means that the size of the ciphertext will be constant when transformed. (8) Key optimality: the requester needs only one private key to decrypt the ciphertext encrypted by himself or the reencrypted ciphertext comes from different proxies.
Besides the characteristics described above, it is also worthy to note that there are other properties identified to be essential for some applications of PRE introduced in [13,14,18,24].

System Model and Assumptions
3.1. System Model. As shown in Figure 1, the system consists of the user (data owner and delegator), the requester (delegatee), the private key generator (PKG), and the cloud server (proxy). e PKG is responsible for generating the master public parameters and master secret key of the system, so it should be a trusted third party. All the participants in the system can get the master public parameters, but only PKG knows the master secret key. In addition, the PKG will generate a corresponding private key when it receives a legal key generation request for a user's identity. en, the generated private key (and the master public parameters) will be sent to the user securely. e user is assumed to subscribe to a cloud service from a cloud service provider for user data storage and/or data processing. After getting the public parameters from the PKG, the user can encrypt the user data with the identity before uploading it to the cloud server for storage. e user can download and decrypt the ciphertext with his own secret key. If the data needs to be shared with some requesters (e.g., friends or cooperators), the user needs to generate a corresponding reencryption key (a.k.a. delegation key). is reencryption key also needs to be sent to the proxy secretly. Moreover, the user generates an update key, which is also a reencryption key for updating the ciphertext on the cloud server through the proxy. e requester may be a friend or a cooperative partner who wants to access some of the data encrypted by the data owner and stored on a cloud server. e requester, who is a valid delegatee, can decrypt the delegation ciphertext converted by the proxy to get the delegator's data. To reduce the complexity, the authentication of the requester is not considered in this work. e proxy stores the ciphertext encrypted by the user and transforms the ciphertext with the reencryption key. If the reencryption key is for updating ciphertext, the proxy transforms the ciphertext to a new ciphertext directly. If the reencryption key is for delegation, the proxy will keep it secret and use it to generate a new delegation ciphertext when the legitimate delegatee requests the user data. Finally, the proposed scheme assumes that the cloud server only keeps one copy of the data.

System Security Assumptions.
e proposed work assumes that the user's private key can be transported secretly from the PKG to the user. e user's delegation key can be securely sent to the proxy (cloud server) too. e cloud service is robust but not wholly trusted; that is, the user data and delegation key stored on it will not be lost due to some Security and Communication Networks physical disasters or not be modified, but the cloud server or its administrators because of several reasons (curiosity or specific purpose) are interested in obtaining user data as well as some of the user's key. Moreover, the cloud servers might collude with some malicious users, or a former authorized user whose permission has been revoked is also considered in the improvements. All entities in the system will follow the communication protocol that will respond to the request correctly.

Proposed Scheme
e differences between the proposed scheme and the original scheme in [18] exist in three aspects: reencryption key generation algorithm, reencryption algorithm, and decryption algorithm: (1) ere are two reencryption key generation algorithms in our proposal. e first one (RKGen 1 ) improves the key generation algorithm of the original scheme by replacing the multiplication operation in the function with a bilinear mapping operation. In this way, if the proxy colludes with the delegatee, they can only get the bilinear pair, but not the private key. us, this achieves collusion resistance. e second one (RKGen 2 ) is a new reencryption key generation algorithm, wherein the generated key is used for updating ciphertext and is discussed in detail in Section 5.
(2) Our approach has two reencryption algorithms with different functions, while the original scheme only has one reencryption algorithm used for delegation. e first reencryption algorithm REncrypt 1 used to calculate the delegation ciphertext is single use. e newly added one REncrypt 2 used for ciphertext update is multiuse. We utilize these two algorithms to perfectly solve the contradiction between requiring multiple reencryption and not allowing reencryption.
(3) Two decryption algorithms are used in the proposed system. e first one Decrypt 1 is used by the data owner to decrypt ciphertext or updated ciphertext which have been reencrypted for several times. e second one Decrypt 2 is utilized by the delegatee to decrypt the delegated ciphertext. In the original scheme, however, there is only one decryption algorithm used to decrypt original (level-1) ciphertext and reencrypted (level-n, n > 1) ciphertext. And for the delegation ciphertext, the decryption needs to be performed recursively. Firstly, the latter two terms of the ciphertext are decrypted with the private key of the delegatee to get the random number selected in the calculation of the reencryption key. en, the random number is used to calculate the plaintext. However, in the proposed scheme, the decryption object is an optimized ciphertext (ciphertext is not extended when reencrypting), so there is no need for recursive decryption.
For the sake of simplicity and comparison of the Green and Ateniese [18] (shown in Figure 2) and the proposed scheme (shown in Figure 3), a description and a detailed discussion are given below.

A Brief Description of Original Scheme.
e original scheme has six algorithms as follows: where G 1 and G 2 are two cyclic groups of the same prime order q and g is a generator of G 1 . Select two hash functions q , set the master secret key msk � s, and output the master public parameters mpp � (G 1 , G 2 , q, g, g s , H 1 , H 2 ).
(3) Encrypt(mpp, id, m): providing mpp, identity id, and data m as input, randomly select r ∈ Z * q , and the algorithm outputs a corresponding ciphertext c id � (g r , m · e(g s , H 1 (id)) r ).

Detailed Design of the Proposed Scheme.
ere are nine algorithms in the proposed scheme, and the process flow is depicted in Figure 3. e description of the processes is as follows: (1) Setup: let e: G 1 × G 1 ⟶ G 2 be a bilinear map, where G 1 and G 2 are two cyclic groups of the same prime order q and g is a generator of G 1 . Select a random s ∈ Z * q as the master secret key msk and two hash functions Output the master public parameters mpp � (H 1 , H 2 , g, g s , q) while keeping the master secret key msk � s private. (2) KeyGen(msk, id): when PKG receives a key generation request from a legitimate user with identity id, this algorithm takes as input mpp (this parameter is included implicitly here and in following algorithms for simplicity), msk, and identity id and generates the corresponding private key sk id � H 1 (id) s . (3) Encrypt(id, m): when a user wants to encrypt data m ∈ G 2 with identity id, the encryption algorithm picks r∈ R Z * q and computes C 1 � g r and C 2 � m · e(g s , H 1 (id) r ) to generate the ciphertext c id � (C 1 , C 2 ), which will be sent to a cloud server for storage.
and ciphertext c id 1 � (C 1,1 , C 1,2 ) as input, the algorithm computes C 1,1 ′ � R 1 and C 1,2 ′ � C 1,2 · R 2 and outputs a new ciphertext c id 1 ′ � (C 1,1 ′ , C 1,2 ′ ) which will replace the old ciphertext c id 1 to store on the cloud server. (8) Decrypt 1 (sk id , c id ): after downloading the ciphertext c id � (C 1,1 , C 1,2 ), original ciphertext or updated ciphertext, from the cloud server, the user (data owner and delegator) runs the algorithm to compute m � (C 1,2 /e(C 1,1 , sk id )) with the private key (usually the latest private key corresponding to the newest identity) to output the plaintext or an error flag ⊥. (9) Decrypt 2 (sk id 2 , c id 2 ): the requester (delegatee) decrypts the delegation ciphertext c id 2 � (C 2,1 , C 2,2 ) with the private key sk id 2 � H 1 (id 2 ) s to output plaintext or an error flag ⊥. e process is as follows:

Security Analysis of the Proposed Scheme.
In this study, two reencryption key generation algorithms are employed, the reencryption key generation algorithm for ciphertext update is a new one, and the other for the delegation is an improved one. In an event where the delegatee colludes with the proxy, it can obtain the value e(g r , sk id 1 ) rather than sk id 1 which means achieving collusion safety. e ciphertext obtained by the former one is in the same format as the ciphertext is generated directly with the new identity id 1 ′ . So the security analysis is the same as the scheme [18].
In addition, we analyze the possible security problems caused by the collaboration of two reencryption key generation algorithms. e delegatee and the proxy conspire to compute a value e(g r , sk id 1 ) from the delegation key. If an attacker constructs another pair such as (g r′ , e(g s , H 1 (id 1 ′ ) r′ )), a new update key rk id 1 ⟶ id 1 ′ � (g r′ , e(g s , H 1 (id 1 ′ ) r′ )/e(C 1 , sk id 1 )) can be calculated. If the proxy updates the ciphertext with this forged key, a spoofing attack will happen. However, we have assumed that the user can securely send the reencryption key to the proxy and the user needs to be authenticated, and the proxy is semitrusted, so the unauthenticated attacker cannot update the ciphertext even if he has built a new update key.
Next, we present the formal security proofs for the proposed scheme in the random oracle model as follows.

Theorem 1. Suppose the DBDH assumption holds, our IBPRE-CE scheme is IND-PrID-CPA secure in the random oracle model.
Proof. Let A be a PPT algorithm that has a nonnegligible advantage ϵ in attacking the proposed scheme. We use A to construct a second algorithm B, which has a nonnegligible advantage at solving the DBDH problem in G 1 and G 2 . Algorithm B accepts as input a properly distributed tuple (G 1 � g, g a , g b , g c , T) ∈ G 4 1 × G 2 and outputs 1 if T � e(g, g) abc . A interacts with algorithm B as follows.
First, algorithm B treats the hash functions H 1 and H 2 as random oracles and performs the following simulation: (1) Simulation of H 1 : 0, 1 { } * ⟶ G 1 . When a query for identity id is received, simulator searches the hash table L 1 which includes some tuples like (id, h, z, α). If the id exists in the L 1 , return h as the query result. Otherwise, flip a weighted coin that the probability of heads is c (represented as Pr[α � 1] � c) to get a random α ∈ 0, 1 { }. Select z ∈ Z * q randomly and compute h. If α � 1, set h � g z ; otherwise, set h � (g c ) z . No matter α � 1 or 0, h is correctly distributed.
(2) Simulation of H 2 : 0, 1 { } * ⟶ G 1 . When a query for string X like K‖id 1 ‖id 2 where K � e(sk id 1 , H 1 (id 2 )) is received, simulator simply returns x ∈ G 1 and records tuple (X, x) into table L 2 . en, the interaction simulation proceeds as follows: (1) Select. A selects i from set 0, 1 { }. (1) Private key query. When A sends an identity id to B to query its corresponding private key, B evaluates H 1 (id) as above to get (id, h, z, α) and returns sk id � (g a ) z to A. (2) Update key query. When A sends an update key query from identity id to id′, B selects r, r ′ ∈ Z * q randomly and evaluates H 1 (id) and H 1 (id ′ ) to obtain (z, α) and (z ′ , α ′ ). If α � 0, B computes rk id⟶id ′ � (e(g a , H 1 (id ′ ) r′ )/ T z ) and returns it to A. Note that this update key is incorrectly formed.
(4) Challenge phase. At the end of phase 1, A submits challenge identity id * and two same length message m 0 , m 1 ∈ G 2 to B who will evaluate H 1 (id * ) and look for tuple (id * , h, z, α) from table L 1 and return challenge ciphertext c * � (g b , m i · T z ) to A. Note that there are following restrictions on id * to avoid trivial decryption: (1) e private key corresponding to id * has not been queried. (2) If a series of update key queries which originate from id * to id 1 , next from id 1 to id 2 ,. . ., from Security and Communication Networks id n− 1 to id n have been issued, the private key of any id in set ID = {id 1 , id 2 , . . . id n } has not been queried. (3) If the delegation key query from id * to id j has been issued, the private key of id j has not been queried. (4) If a series of update key queries which originate from id * to id 1 , next from id 1 to id 2 ,. . ., from id n− 1 to id n have been issued and delegation key from any id in set ID = {id 1 , id 2 , . . . id n } to id j has been queried, the private key of id j has not been queried.
(5) Phase 2. A issues query as in phase 1 except restrictions as above.

Conditions for Abort
(1) When the private key query for id * is issued, α is chosen to be 1. (2) When the private key queries for other id except id * are issued, α is chosen to be 0. (3) When the update key queries from id j to id j (rk id i ⟶ id j ) are issued, if id i ⟶ id j lies along a path leading from id * , the value α for id j is chosen to be 1. Or id i ⟶ id j does not lie along a path leading from id * , the value α for id i is chosen to be 0. (4) When the delegation key queries from id i to id j (rk id i ⟶ id j ) are issued, if id i ⟶ id j lies along a path leading from id * , the value α for id j is chosen to be 1. Or id i ⟶ id j does not lie along a path leading from id * , the value α for id i is chosen to be 0.
Claim. If B does not abort during the game, then A's view is identical to the real attack, except reencryption keys of the form rk id * ⟶ ··· . e discussion of this case can refer to [18]. If the input to B is a DBDH tuple, then the challenge ciphertext c * is correct encryption of m i under id * and hence (subject to the definition of A and the argument above) |Pr[i ′ � i] − (1/2)| ≥ ε. When the input to B is random, c * represents the encryption of a random element. Since A is unable to distinguish between the simulation and a real attack, it must hold that Pr[i ′ � i] ≥ ϵ + (1/2) for a nonnegligible ϵ. Hence, B succeeds with nonnegligible advantage.

Application Scenario Implementation of the Proposed Scheme
In this section, we introduce a secure cloud data management scenario and apply the improved algorithms mentioned above to implement three secure data management functions: (1) Update ciphertext and update the key to achieve access permission revocation (2) Reauthorization after the ciphertext is updated (3) Conditional reservation authorization 5.1. Secure Cloud Data Management Scenario. In a cloud data sharing environment, the user encrypts data with the identity and uploads it to the cloud server. User data may be encrypted and uploaded to the cloud server at different times. Usually, the same random number r is selected to encrypt several files at the same time, while different random number r is chosen to encrypt files at different times. In order to share the encrypted data to others, the user needs to calculate the corresponding reencryption key for the ciphertext. Table 1 shows the relations of plaintext, ciphertext, random number, and time (can be utilized to compute the lifetime of the key) during encryption and reencryption keys list (REK list) for delegation. In Table 1, the random value and the time can be the same which means that these data were encrypted at the same time, where C i � (g r i , m i · e (g s , H 1 (id 1 ) r i )), and REK i ⊆ rk id 1 ⟶ id 2 , rk id 1 ⟶ id 3 , . . . is a reencryption key list that contains some reencryption keys corresponding to the delegation. If this set is empty, this means the data are not allowed to be shared with others.
For the sake of analysis, let us assume this scenario: user id 1 has three types of files (m 1 , m 2 , and m 3 ), which are encrypted with the identity and stored on the cloud server. e first type of file m 1 is some study notes shared with a requester (a common learner with identity id 2 ). e second type of file m 2 is personal photos that involve some private information and should not be allowed to be accessed by others. e content of the third file m 3 is several relevant information that a user (assumed as a prosumer) shares with the utility organization or other prosumers in a microgrid.

Delegation Revocation Management.
From the construction of the reencryption key, we can find that the delegation reencryption key has nothing to do with the second part of the ciphertext but only with the random number chosen for the ciphertext, the delegator, and the delegatee. Assume that the files m 1 , m 2 , and m 3 are encrypted with the same random number under the identity id 1 . In this situation, as long as one of the user's files is authorized to the requester, the proxy can use the delegation reencryption key to delegate all other data to the requester. So it is not security. To keep the user's other files safe, the user needs to revoke the delegation of the requester. Here, it can revoke access rights by updating the ciphertext. e processing of revoking the requestor id 2 's access permission to files m 2 and m 3 is shown as follows: Step 1: generate a new identity. e user combines wellknown information with an attribute (manufacturer/ smart meter id: id sm ) of microgrid devices (i.e., smart meter) as a new identityid 1 ′ � id 1 ‖id sm for the third type of file m 3 . In the same manner, the user will also combine another attribute as an encryption identity for the second type of file m 2 . Both operations are the same, and file m 3 is considered for the following analysis.
Step 2: generate a new private key. e user sends the new identity to the PKG to generate a new private key sk id 1 ′ � H 1 (id 1 ′ ) s .
Step 4: update the ciphertext. After receiving the update reencryption key rk id 1 ⟶ id 1 ′ � (R 1 , R 2 ), the proxy uses it to convert the ciphertext c id 1 to a new ciphertext c id 1 ′ � (R 1 , C 1,2 · R 2 ) � (C 1,1 ′ , C 1,2 ′ ), which will replace the old ciphertext c id 1 to store in the cloud server. Note that the proxy does not save this reencryption key.
Step 5: the user (data owner) decrypts the updated ciphertext with the new private key sk id 1 ′ . e computation steps are as follows: (1) C 1,1 ′ � R 1 � g r′ .
Obviously, when the requester requests the data from the cloud server again, the new ciphertext transformed by proxy from the updated ciphertext with old reencryption key rk id 1 ⟶ id 2 cannot be decrypted with the requester's private key sk id 2 � H 1 (id 2 ) s because So, when the user revokes the delegation for the requester id 2 by updating the ciphertext, the proxy will delete the corresponding old reencryption key. And when the requester id 2 requests the data, the user will refuse to generate a delegation key.

Reauthorization Management.
After the above ciphertext update operation, given that these operations were also applied to m 2 . It can now only be accessible to the data owner. However, file m 3 is required to be shared with other entities (other prosumers or the utility organization and assume identity is id 3 ) in the microgrid. For example, the user needs to reauthorize to energy consumers id 3 , and this process is shown as follows: Step 1: generate the reauthorization key. e user (delegator) runs the algorithm RKGen 1 (sk id 1 ′ , id 1 ′ , id 3 , C 1,1 ′ ) to compute a new reencryption key rk id 1 ′ ⟶ id 3 . e calculation process is shown as follows: . en, this reencryption key is sent to the proxy to update the reencryption key list.
Step 2: generate reauthorization ciphertext. When the requester (delegatee) wants to access the data, the proxy runs the algorithm REncrypt 1 (rk id 1 ′ ⟶ id 3 , c id 1 ′ ) to convert the updated ciphertext c id 1 ′ to a new ciphertext . en, the ciphertext c id 3 is sent to the requester (delegatee).
Step 3: decrypt the reauthorization ciphertext. After receiving the ciphertext from the proxy, the requester decrypts the ciphertext c id 3 with the private key sk id 3 � H 1 (id 3 ) s to get the plaintext. e decryption process is shown as follows:

Conditional Reservation Delegation Management.
is function is added to handle the time period access control in scenarios where a user wants to grant access to a requester at a future time. For example, one user with a solar energy collection system wants to sell the excess energy to others in the microgrid. Similarly, other prosumers also wish to sell their excess energy. ese suppliers will share their energy information to an energy consumer, who cannot access the data containing the energy price in advance. Otherwise, it may lead to malicious bidding or collusion. is situation may require conditional reservation delegation. In this work, this process is shown as follows: Step 1: encrypt the bidding file and upload it to the cloud. e user (seller, identity is id 1 ) generates an energy information file and encrypts it with the identity. e ciphertext c id 1 � (C 1,1 , C 1,2 ) is uploaded to the cloud server and can be shared with other users.
Step 2: generate conditional reservation delegation key: (1) e user assigns the combination of the requester's identity, another information attribute (i.e., smart meter id), and a date constraint (i.e., trade schedule) as the identity id 3 � identity||id sm ||duration. (2) e user generates a delegation reencryption key rk id 1 ⟶ id 3 � e(C 1,1 , H 2 (K id 1 ,id 3 ‖id 1 ‖id 3 ) · sk id 1 ) and uploads to the proxy and indicates the composition of the delegatee's identity. Step 3: generate a private key. At the appointed time, the requester applies for the private key sk id 3 � H 1 (id 3 ) s corresponding to the identity id 3 � identity||id sm ||duration from PKG.
Step 5: decrypt the delegation ciphertext. e requester decrypts the ciphertext c id 3 with the private key sk id 3 � H 1 (id 3 ) s to get the plaintext. e process is shown as follows: (1) K id 3 ,id 1 � e(sk id 3 , H 1 (id 1 )).

Comparison and Analysis
In this section, we compare the proposed scheme with three PRE schemes in terms of characteristics, functionality, computation cost, and efficiency. In literatures, several works that implement secure data sharing with PRE can be divided into two categories. One is based on PKI, and the other is identity-based. Identitybased architecture can be further divided into two categories: BF (Boneh-Franklin) [22] architecture in the random oracle model and waters [23] architecture in the standard model. For convenience and simplicity of comparison and analysis, GA (Green-Ateniese) [18] is chosen as the representative of BF architecture, LLWS (Liang-Liu-Wong-Susilo) [10] for waters architecture, and SHB (Shafagh-Hithnawi-Burkhalter) [6] for PKI architecture to compare with the proposed scheme. e GA 1 and GA 2 correspond to basic IBP1 in the GA scheme, and GA 2 is an optimization of GA 1 in terms of the absence of ciphertext expansion during reencryption but is not multiusable and nontransferable. Table 2 shows some of the characteristics and achieved security notion of the schemes for two functions: update and delegation. Since the reencrypted ciphertext in scheme GA 2 is non-reencryptable [25], this method cannot be used to update the ciphertext and not included in the comparison set supporting updates. Similarly, the delegation function is not discussed in the scheme LLWS, so it is not included in the function comparison set of delegation. For the update function, the decryptor is still the data owner himself regardless of the original ciphertext or the updated ciphertext.
ere is no change in the access right. It is of no need to consider transferability, which is not compared in the table and filled with "-." e TM and EM represent true multiuse and expansive multiuse, respectively [13]. Note that although the reencryption key generation algorithm needs an element of the ciphertext, the proposed scheme is still noninteractive because the ciphertext component can be downloaded from the cloud server without the involvement of proxy. e characteristic comparison in Table 2 is important for secure data sharing application, and the definitions are described in Section 2. In most cases, the public-key certificate has an expiration date. In addition, a user's key (both public and private key) needs to be changed for security consideration. ese changes will cause the ciphertext to be updated.
us, in the process of user data management, ciphertext update is a very common operation, and the proxy reencryption algorithm must support multiple encryptions (multiuse). Furthermore, reencryption that leads to the extension of ciphertext length is not allowed. us, the scheme should achieve ciphertext optimization. Moreover, in cloud servers, the delegation ciphertext is not permitted to be shared again, which is a typical security policy for data sharing.
us, this requires that the scheme should be nontransferable, but the schemes GA 1 and GA 2 are transferable. In the PRE system, the CPA security is a minimum requirement, and the private key of the delegator should be safe even if the delegatee colludes with the proxy; this means that the scheme should be collusion safe as achieved by the proposed one. If the user data need to be shared with multiple requesters in the PKI-based system, the user has to maintain a lot of public-key certificates. It will induce a higher overhead to the user. However, since the proposed proposal is identity-based, this situation is avoided. e essential feature of PRE is delegation. us, it is used as the basis of underlying encryption in many secure data sharing systems. However, many proposals in literature only considered the delegation function but did not include the function of revoking delegation. Some systems employ conditional authorization, but very few schemes have taken the conditional reservation delegation into account. Furthermore, fewer schemes in the literature involve the ciphertext/key update and reauthorization, and even if there are, the analysis is not detailed enough. Table 3 compares the functions of some existing representative schemes and the proposed approach. It is observed that the proposed scheme is a comprehensive data sharing solution that supports all the essential features of delegation, delegation revocation, conditional reservation delegation, ciphertext update, and reauthorization required for secure cloud data sharing.
In Table 4, the computational cost of each phase is shown. For the sake of illustration, Setup, KeyGen, and Encrypt denote the setup algorithm, key generation algorithm, and encryption algorithm, respectively. Decrypt 1 denotes the decryption algorithm used by the data owner to decrypt the ciphertext (original or updated). Decrypt 2 denotes the decryption algorithm used by the delegatee to decrypt the reencrypted delegation ciphertext. RKGen 1 denotes the delegation key generation algorithm. RKGen 2 denotes an update key generation algorithm. REncrypt 1 denotes the reencryption algorithm for generating a delegation ciphertext. REncrypt 2 denotes the reencryption algorithm for updating ciphertext. t P denotes the pairing computation time. t R denotes the time of the random computation. t M denotes the calculation time of group element multiplication or division operations (the inverse computation is seen as division operation). t E denotes the computation time of a group element power operation. In these calculations, the selection of random values, multiplication, division, and inverse takes tens of microseconds; exponentiation takes several milliseconds and pairing takes between 10 and 20 milliseconds. Table 5 and Figure 4 show the computation time of each phase of the five schemes. For the convenience of calculation, the hash calculation in all algorithms is not considered. e SHB scheme is the ElGamal algorithm based on the elliptic curve. e LLWS scheme is mainly used for ciphertext updating. us, the run time of algorithm RKGen 1 and REncrypt 1 for authorization is not provided. Note that the run time of the algorithm Decrypt 1 is for decrypting the original ciphertext, while the run time of the algorithm Decrypt 2 is for decrypting the reencrypted ciphertext, which is updated only once. e GA work does not include ciphertext update or is not suitable for updating ciphertext (e.g., ciphertext expands with reencryption), and the time of update key generation and ciphertext update was also not   [28], where the parameter is the type A curve. In Table 5, the setup time (the length of the user's identity is 50 bits) of the LLWS scheme is larger than other systems because it is a waters-based architecture and often needs to generate more system parameters. Since the time of hash computation in KeyGen algorithm is not included, the computation time of this phase in the LLWS scheme is less than the BF architecture. For the purposes of simplifying comparison, the calculation times of the Setup phase and KeyGen phase are omitted. And it is shown that the computation time of LLWS is the longest, while SHB is the shortest. e computation time of Setup, KeyGen, Encrypt, and Decrypt 1 are the same in GA 1 and GA 2 and the proposed proposal because these approaches are based on BF architecture. And the computation time for Decrypt 2 of the three schemes is approximately the same. During the RKGen 1 phase, the proposed scheme needs two pairing computations making the computation time larger than GA 1 and GA 2 . Although the computation time of RKGen 2 is very long, the impact on the overall system will be modest because the number of keys needed to be calculated is few and the ciphertext update frequency is not too high. Furthermore, the computation time of REncrypt 1 and REncrypt 2 in the proposed scheme is very short. erefore, the proposed algorithm has the quickest processing time when the proxy responds to the request for delegation or update, which is especially important when there are many access requests, or there are many ciphertexts that need to be updated. Since in practice, once the user refreshes the key, the ciphertext needs to be updated synchronously, and the reencryption (update) algorithm in our scheme only needs tens of microseconds, so it is very efficient to update a large number of ciphertext synchronously in practical applications.     Figure 5 shows the time required to update the ciphertext from 100 MB to 1 GB, respectively. e SHB scheme needs 26,873.24 seconds to update 1 GB ciphertext, while the proposed work only needs 44 seconds. is value plus the time of reencryption key generation (34.592 ms) is also much less than the time required by SHB. is means that the proposed scheme has high efficiency and practicability in the scenario that a lot of ciphertext needs to be updated synchronously after the key update.

Conclusions
In this paper, an improved IBPRE scheme is proposed to realize secure cloud data sharing. e approach fully considers the ciphertext update while considering the access authorization and supports file security management operations such as access authorization, authorization revocation, ciphertext update, reauthorization, and conditional reservation authorization. Moreover, the scheme included the characteristics of unidirectionality, noninteractivity, collusion safety, multiuse, nontransferability, ciphertext optimization, and key optimization, which are essential and practical for general applications. From the performed simulation and analysis, the two reencryption algorithms in the proposed proposal require only one multiplication of group elements, in which the processing time of simultaneously responding to multiple delegation requests or updating numerous ciphertexts is shorter compared with other schemes. However, as of this writing, the design only achieves CPA security in the random oracle model but aims to achieve CCA security in the future iteration.

Data Availability
e simulation codes based on PBC used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.