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

Authors: Shimao Yao; Ravi Sankar; In-Ho Ra
Journal: Security and Communication Networks
 (2020)

---

## Abstract

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. The 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.


---

## Body

## 1. 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. The 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)
The 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)
The 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)
The requirement of ciphertext update. There are two types of ciphertext update. The 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. The 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. These 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. There 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. Therefore, 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. Their study included PKI-based proxy reencryption [14–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. The 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. Their 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. The 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. The 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.


### 1.2. 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. This 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. The ciphertext reencrypted (delegated) to the delegate, however, cannot be reencrypted (reauthorized). The 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). The 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.The rest of the paper is organized as follows. Section2 describes some of the cryptographic primitives, definitions, and some properties of the proxy reencryption. The system model and the assumptions of the proposed scheme are given in Section 3. The 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.


## 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. Their study included PKI-based proxy reencryption [14–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. The 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. Their 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. The 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. The 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.


## 1.2. 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. This 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. The ciphertext reencrypted (delegated) to the delegate, however, cannot be reencrypted (reauthorized). The 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). The 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.The rest of the paper is organized as follows. Section2 describes some of the cryptographic primitives, definitions, and some properties of the proxy reencryption. The system model and the assumptions of the proposed scheme are given in Section 3. The 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.


## 2. Preliminaries

### 2.1. Bilinear Map and Decisional Bilinear Diffie–Hellman Problem [25]

Definition 1 (bilinear map).
LetG1 and G2 are two cyclic groups of the same prime order q and g be a generator of G1. We say that e:G1×G1⟶G2 is a bilinear map if it satisfies the following properties:(1)
Bilinear: for alla,b∈ℤq∗ and g∈G1, ega,gb=eg,gab.(2)
Nondegenerate:eg,g≠1G2, where 1G2 is the unit of G2.(3)
Computability:e can be efficiently computed.Definition 2 (decisional bilinear Diffie–Hellman (DBDH) problem).
LetG1 and G2 are two cyclic groups of the same prime order q and g be a generator of G1. Support that e:G1×G1⟶G2 is a bilinear map. The decisional bilinear Diffie–Hellman (DBDH) problem is to decide, given a tuple of values g,ga,gb,gc,T∈G14×G2 (where a,b,c∈Rℤq∗), whether T=eg,gabc holds.
Letk be a security parameter of sufficient size. Formally, we say that the DBDH assumption holds in G1,G2,e, if for all probabilistic polynomial time (PPT) algorithm A, the following condition is true, where v⋅ is defined as a negligible function:(1)Pra,b,c⟵Rℤq∗;1⟵Ag,ga,gb,gc,eg,gabc−Pra,b,c⟵Rℤq∗;T⟵RG2;1⟵Ag,ga,gb,gc,T≤vk.


### 2.2. Definition and Security Model of IBPRE-CE

Definition 3 (identity-based proxy reencryption with ciphertext evolution).
An identity-based proxy reencryption scheme with ciphertext evolution (IBPRE-CE) is a tuple of algorithms (Setup, KeyGen, Encrypt, RKGen1, RKGen2, Reencrypt1, Reencrypt2, Decrypt1, and Decrypt2) as follows:(1)
Setup1k: taking a security parameter k as input, this algorithm generates both master public parameters (mpp) and master secret key (msk). The mpp is distributed to all participants, while the msk is kept secretly.(2)
KeyGenmpp,msk,id: taking mpp, msk, and an identity id as input, this algorithm outputs a corresponding private key skid.(3)
Encryptmpp,id,m: taking mpp, identity id, and message m as input, this algorithm computes an original ciphertext cid.(4)
RKGen1mpp,skid1,id1,id2,C1: taking mpp, skid1, identitiesid1,id2, and an element of ciphertext C1 as input, this algorithm calculates a delegation token rkid1⟶id2.(5)
RKGen2mpp,skid1,id1′,C1: taking mpp, old private key skid1, a new identity id1′, and an element of ciphertext C1 as input, this algorithm produces an update key rkid1⟶id1′.(6)
Reencrypt1mpp,rkid1⟶id2,cid1: taking mpp, delegation key rkid1⟶id2, and ciphertext cid1 as input, this algorithm converts the ciphertext cid1 into a delegation ciphertext cid2.(7)
Reencrypt1mpp,rkid1⟶id1′,cid1: taking mpp, update key rkid1⟶id1′, and old ciphertext cid1 as input, this algorithm updates the ciphertext cid1 into a new ciphertext cid1′.(8)
Decrypt1mpp,skid1,cid1: taking mpp, delegator’s (latest) private key skid1, and ciphertext cid1 as input, this algorithm outputs corresponding plaintext or an error flag ⊥.(9)
Decrypt2mpp,skid2,cid2: taking mpp, delegatee’s private key skid2, and delegation ciphertext cid2 as input, this algorithm outputs corresponding plaintext or an error flag ⊥.
We say that an IBPRE-CE scheme is consistent if for any valid identitiesid1, id2, and id1′, their secret keys skid1, skid2, and skid1′ (generated by KeyGen), the corresponding reencryption key rkid1⟶id1′ and rkid1⟶id2 (generated by RKGen2 and RKGen1), and ciphertexts cid1, cid2, and cid1′ (computed by Encrypt, Reencrypt1, and Reencrypt2), the following equations hold:①
Decrypt1mpp,skid1,Encryptmpp,id1,m=m.②
Decrypt1mpp,skid1′,Reencrypt2mpp,rkid1⟶id1′,Encryptmpp,id1,m=m.③
Decrypt2mpp,skid2,Reencrypt1mpp,rkid1⟶id2,Encryptmpp,id1,m=m.Definition 4 (IND-PrID-CPA security of IBPRE-CE).
An IBPRE-CE scheme is indistinguishable against chosen plaintext and identity attack (IND-PrID-CPA) secure if no probabilistic polynomial time (PPT) adversaryA wins the following game with a nonnegligible advantage:(1)
Setup. The challengerC runs Setup1k to generate the master public parameters (mpp) and the master secret key (msk). The mpp is sent to A, while the msk is kept securely.(2)
Phase 1.A issues some private key queries Osk, updates reencryption key queries Ouk, and delegation reencryption key queries Odk as follows:(i)
On receiving any query of the form (Osk, id), C returns skid←KeyGenmpp,msk,id to A.(ii)
On receiving any query of the form (Odk, id1, id2,C1), C returns rkid1⟶id2←RKGen1mpp,skid1,id1,id2,C1 to A, where skid1←KeyGenmpp,msk,id1 and C1 is an element of ciphertext.(iii)
On receiving any query of the form (Ouk, id1, id1′,C1), C returns rkid1⟶id1←RKGen2mpp,skid1,id1′,C1 to A, where skid1←KeyGenmpp,msk,id1 and C1 is an element of ciphertext.(4)
Challenge. At the end of phase 1,A outputs two equal-length messages m0 and m1, 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). The challenger C returns a challenge ciphertext c∗=Encryptmpp,id∗,mi, where i∈R0,1.(5)
Phase 2.A adaptively issues queries as phase 1 with some restrictions that the private key of id∗ and any trivial decryption key query (Osk, Ouk, Odk) have never been queried. The restrictions are as follows:(i)
The private key corresponding toid∗ has not been queried.(ii)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn, have been issued, the private key of any id in set ID = {id1,id2,…idn} has not been queried.(iii)
If the delegation key query fromid∗ to idj has been issued, the private key of idj has not been queried.(iv)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued, and delegation key from any id in set ID = {id1,id2,…idn} to idj has been queried, the private key of idj has not been queried.(6)
Guess.A gives a guess i′∈0,1.
The advantage ofA in the above game is defined by ɛ=Pri′=i−1/2.


### 2.3. 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 ciphertextcid1 to ciphertext cid2 and from ciphertext cid2 to ciphertext cid3. Therefore, 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 asrkid1⟶id2+skid2↛skid1, where rkid1⟶id2 is the reencryption key known by the proxy, and skid2 is id2’s (delegatee’s) private key, and skid1 is id1’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,rkid1⟶id2 and rkid2⟶id3 can get rkid1⟶id3.(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, userid1 generates the reencryption key rkid1⟶id2 to delegate the decryption capacity to the requestor id2 who can decrypt the reencrypted ciphertext but cannot generate a new delegation key which originates from id1 (i.e., rkid1⟶id3) or reencrypt the delegation ciphertext to generate a new ciphertext which can be decrypted by a third entity with the private key skid3.(6)
Unidirectionality: with the reencryption keyrkid1⟶id2, the proxy can convert user id1’s ciphertext to another one that can be decrypted by the user id2, but not vice versa.(7)
Ciphertext optimality: the ciphertext does not expand upon reencryption. This 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].


## 2.1. Bilinear Map and Decisional Bilinear Diffie–Hellman Problem [25]

Definition 1 (bilinear map).
LetG1 and G2 are two cyclic groups of the same prime order q and g be a generator of G1. We say that e:G1×G1⟶G2 is a bilinear map if it satisfies the following properties:(1)
Bilinear: for alla,b∈ℤq∗ and g∈G1, ega,gb=eg,gab.(2)
Nondegenerate:eg,g≠1G2, where 1G2 is the unit of G2.(3)
Computability:e can be efficiently computed.Definition 2 (decisional bilinear Diffie–Hellman (DBDH) problem).
LetG1 and G2 are two cyclic groups of the same prime order q and g be a generator of G1. Support that e:G1×G1⟶G2 is a bilinear map. The decisional bilinear Diffie–Hellman (DBDH) problem is to decide, given a tuple of values g,ga,gb,gc,T∈G14×G2 (where a,b,c∈Rℤq∗), whether T=eg,gabc holds.
Letk be a security parameter of sufficient size. Formally, we say that the DBDH assumption holds in G1,G2,e, if for all probabilistic polynomial time (PPT) algorithm A, the following condition is true, where v⋅ is defined as a negligible function:(1)Pra,b,c⟵Rℤq∗;1⟵Ag,ga,gb,gc,eg,gabc−Pra,b,c⟵Rℤq∗;T⟵RG2;1⟵Ag,ga,gb,gc,T≤vk.


## 2.2. Definition and Security Model of IBPRE-CE

Definition 3 (identity-based proxy reencryption with ciphertext evolution).
An identity-based proxy reencryption scheme with ciphertext evolution (IBPRE-CE) is a tuple of algorithms (Setup, KeyGen, Encrypt, RKGen1, RKGen2, Reencrypt1, Reencrypt2, Decrypt1, and Decrypt2) as follows:(1)
Setup1k: taking a security parameter k as input, this algorithm generates both master public parameters (mpp) and master secret key (msk). The mpp is distributed to all participants, while the msk is kept secretly.(2)
KeyGenmpp,msk,id: taking mpp, msk, and an identity id as input, this algorithm outputs a corresponding private key skid.(3)
Encryptmpp,id,m: taking mpp, identity id, and message m as input, this algorithm computes an original ciphertext cid.(4)
RKGen1mpp,skid1,id1,id2,C1: taking mpp, skid1, identitiesid1,id2, and an element of ciphertext C1 as input, this algorithm calculates a delegation token rkid1⟶id2.(5)
RKGen2mpp,skid1,id1′,C1: taking mpp, old private key skid1, a new identity id1′, and an element of ciphertext C1 as input, this algorithm produces an update key rkid1⟶id1′.(6)
Reencrypt1mpp,rkid1⟶id2,cid1: taking mpp, delegation key rkid1⟶id2, and ciphertext cid1 as input, this algorithm converts the ciphertext cid1 into a delegation ciphertext cid2.(7)
Reencrypt1mpp,rkid1⟶id1′,cid1: taking mpp, update key rkid1⟶id1′, and old ciphertext cid1 as input, this algorithm updates the ciphertext cid1 into a new ciphertext cid1′.(8)
Decrypt1mpp,skid1,cid1: taking mpp, delegator’s (latest) private key skid1, and ciphertext cid1 as input, this algorithm outputs corresponding plaintext or an error flag ⊥.(9)
Decrypt2mpp,skid2,cid2: taking mpp, delegatee’s private key skid2, and delegation ciphertext cid2 as input, this algorithm outputs corresponding plaintext or an error flag ⊥.
We say that an IBPRE-CE scheme is consistent if for any valid identitiesid1, id2, and id1′, their secret keys skid1, skid2, and skid1′ (generated by KeyGen), the corresponding reencryption key rkid1⟶id1′ and rkid1⟶id2 (generated by RKGen2 and RKGen1), and ciphertexts cid1, cid2, and cid1′ (computed by Encrypt, Reencrypt1, and Reencrypt2), the following equations hold:①
Decrypt1mpp,skid1,Encryptmpp,id1,m=m.②
Decrypt1mpp,skid1′,Reencrypt2mpp,rkid1⟶id1′,Encryptmpp,id1,m=m.③
Decrypt2mpp,skid2,Reencrypt1mpp,rkid1⟶id2,Encryptmpp,id1,m=m.Definition 4 (IND-PrID-CPA security of IBPRE-CE).
An IBPRE-CE scheme is indistinguishable against chosen plaintext and identity attack (IND-PrID-CPA) secure if no probabilistic polynomial time (PPT) adversaryA wins the following game with a nonnegligible advantage:(1)
Setup. The challengerC runs Setup1k to generate the master public parameters (mpp) and the master secret key (msk). The mpp is sent to A, while the msk is kept securely.(2)
Phase 1.A issues some private key queries Osk, updates reencryption key queries Ouk, and delegation reencryption key queries Odk as follows:(i)
On receiving any query of the form (Osk, id), C returns skid←KeyGenmpp,msk,id to A.(ii)
On receiving any query of the form (Odk, id1, id2,C1), C returns rkid1⟶id2←RKGen1mpp,skid1,id1,id2,C1 to A, where skid1←KeyGenmpp,msk,id1 and C1 is an element of ciphertext.(iii)
On receiving any query of the form (Ouk, id1, id1′,C1), C returns rkid1⟶id1←RKGen2mpp,skid1,id1′,C1 to A, where skid1←KeyGenmpp,msk,id1 and C1 is an element of ciphertext.(4)
Challenge. At the end of phase 1,A outputs two equal-length messages m0 and m1, 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). The challenger C returns a challenge ciphertext c∗=Encryptmpp,id∗,mi, where i∈R0,1.(5)
Phase 2.A adaptively issues queries as phase 1 with some restrictions that the private key of id∗ and any trivial decryption key query (Osk, Ouk, Odk) have never been queried. The restrictions are as follows:(i)
The private key corresponding toid∗ has not been queried.(ii)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn, have been issued, the private key of any id in set ID = {id1,id2,…idn} has not been queried.(iii)
If the delegation key query fromid∗ to idj has been issued, the private key of idj has not been queried.(iv)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued, and delegation key from any id in set ID = {id1,id2,…idn} to idj has been queried, the private key of idj has not been queried.(6)
Guess.A gives a guess i′∈0,1.
The advantage ofA in the above game is defined by ɛ=Pri′=i−1/2.


## 2.3. 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 ciphertextcid1 to ciphertext cid2 and from ciphertext cid2 to ciphertext cid3. Therefore, 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 asrkid1⟶id2+skid2↛skid1, where rkid1⟶id2 is the reencryption key known by the proxy, and skid2 is id2’s (delegatee’s) private key, and skid1 is id1’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,rkid1⟶id2 and rkid2⟶id3 can get rkid1⟶id3.(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, userid1 generates the reencryption key rkid1⟶id2 to delegate the decryption capacity to the requestor id2 who can decrypt the reencrypted ciphertext but cannot generate a new delegation key which originates from id1 (i.e., rkid1⟶id3) or reencrypt the delegation ciphertext to generate a new ciphertext which can be decrypted by a third entity with the private key skid3.(6)
Unidirectionality: with the reencryption keyrkid1⟶id2, the proxy can convert user id1’s ciphertext to another one that can be decrypted by the user id2, but not vice versa.(7)
Ciphertext optimality: the ciphertext does not expand upon reencryption. This 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].


## 3. System Model and Assumptions

### 3.1. System Model

As shown in Figure1, the system consists of the user (data owner and delegator), the requester (delegatee), the private key generator (PKG), and the cloud server (proxy).Figure 1
System model.The 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. Then, the generated private key (and the master public parameters) will be sent to the user securely.The 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. The 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). This 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.The 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. The 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.The 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.


### 3.2. System Security Assumptions

The proposed work assumes that the user’s private key can be transported secretly from the PKG to the user. The user’s delegation key can be securely sent to the proxy (cloud server) too. The 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 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.


## 3.1. System Model

As shown in Figure1, the system consists of the user (data owner and delegator), the requester (delegatee), the private key generator (PKG), and the cloud server (proxy).Figure 1
System model.The 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. Then, the generated private key (and the master public parameters) will be sent to the user securely.The 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. The 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). This 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.The 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. The 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.The 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.


## 3.2. System Security Assumptions

The proposed work assumes that the user’s private key can be transported secretly from the PKG to the user. The user’s delegation key can be securely sent to the proxy (cloud server) too. The 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 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.


## 4. Proposed Scheme

The 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)
There are two reencryption key generation algorithms in our proposal. The first one (RKGen1) 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. Thus, this achieves collusion resistance. The second one (RKGen2) 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. The first reencryption algorithmREncrypt1 used to calculate the delegation ciphertext is single use. The newly added one REncrypt2 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. The first oneDecrypt1 is used by the data owner to decrypt ciphertext or updated ciphertext which have been reencrypted for several times. The second one Decrypt2 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. Then, 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.Figure 2
Process flow of the original scheme.Figure 3
Process flow with additional improvement algorithms.


### 4.1. A Brief Description of Original Scheme

The original scheme has six algorithms as follows:(1)
Setup: let e:G1×G1⟶G2 be a bilinear map, where G1 and G2 are two cyclic groups of the same prime order q and g is a generator of G1. Select two hash functions ℋ1:0,1∗⟶G1 and ℋ2:G2⟶G1. Randomly select s∈ℤq∗, set the master secret key msk=s, and output the master public parameters mpp=G1,G2,q,g,gs,ℋ1,ℋ2.(2)
KeyGenmpp,msk,id: providing mpp, msk, and identity id∈0,1∗ as input, the algorithm outputs a corresponding private key skid=ℋ1ids.(3)
Encryptmpp,id,m: providing mpp, identity id, and datam as input, randomly select r∈ℤq∗, and the algorithm outputs a corresponding ciphertext cid=gr,m⋅egs,ℋ1idr.(4)
RKGenmpp,skid1,id2: providing mpp, private key skid1, and identity id2 as input, randomly select element X from group G2, and the algorithm computes R1,R2=Encryptmpp,id2,X and outputs a reencryption key rkid1⟶id2=R1,R2,R3, where R3=ℋ2X/skid1.(5)
REncryptmpp,rkid1⟶id2,cid1: providing mpp, the reencryption key rkid1⟶id2, and ciphertext cid1 as input:①
Ifcid1=C1,C2 is a level-1 ciphertext (original ciphertext), the algorithm computes C2′=C2⋅eC1,R3, C3=R1, and C4=R2 and outputs ciphertext cid2=C1,C2′,C3,C4.②
Ifcid1=C1,C2,…,C2n−1,C2n is a level-n (n>1) ciphertext, the algorithm computes C2n′=C2n⋅eC2n−1,R3, C2n+1=R1, and C2n+2=R2 and outputs ciphertext cid2=C1,C2,…,C2n−1,C2n′,C2n+1,C2n+2.(6)
Decryptmpp,skid,cid: providing mpp, private key skid, and ciphertext cid as input:①
Ifcid=C1,C2 is a level-1 ciphertext (original ciphertext), the algorithm computes m=C2/eC1,skid.②
Ifcid=C1,C2,…,C2n−1,C2n is a level-n ciphertext, consider the combination (C2n−1,C2n) as a level-1 ciphertext, the algorithm computes Xn=C2n/eC2n−1,skid and Xi=C2i/eC2i−1,ℋ2Xi+1, where i is evaluated from n−1 to 2. Finally, the algorithm computes m=C2/eC1,ℋ2X2.The original ciphertext contains two elements, the length of which increases by two elements for each reencryption. Theoretically, the ciphertext can be reencrypted any number of times.


### 4.2. Detailed Design of the Proposed Scheme

There are nine algorithms in the proposed scheme, and the process flow is depicted in Figure3. The description of the processes is as follows:(1)
Setup: let e:G1×G1⟶G2 be a bilinear map, where G1 and G2 are two cyclic groups of the same prime order q and g is a generator of G1. Select a random s∈ℤq∗ as the master secret key msk and two hash functions ℋ1:0,1∗⟶G1 and ℋ2:0,1∗⟶G1. Output the master public parameters mpp=ℋ1,ℋ2,g,gs,q while keeping the master secret key msk=s private.(2)
KeyGenmsk,id: when PKG receives a key generation request from a legitimate user with identityid, 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 skid=ℋ1ids.(3)
Encryptid,m: when a user wants to encrypt data m∈G2 with identity id, the encryption algorithm picks r∈Rℤq∗ and computes C1=grand C2=m⋅egs,ℋ1idr to generate the ciphertext cid=C1,C2, which will be sent to a cloud server for storage. This resulting ciphertext is also called original ciphertext (level-1 ciphertext).(4)
RKGen1skid1,id1,id2,C1: providing as input user’s private key skid1, identities (id1, id2), and an element of ciphertext C1, this algorithm generates a reencryption key (a.k.a. access token) rkid1⟶id2, which will be sent to proxy for storage and converting the ciphertext upon receiving the request from the delegatee. The calculation processing is as follows:①
Kid1,id2=eskid1,ℋ1id2.②
rkid1⟶id2=eC1,ℋ2Kid1,id2id1id2⋅skid1.(5)
RKGen2skid1,id1′,C1: inputting user’s private key skid1, a new identity id1′ and part of the ciphertext C1 choose a random r′∈ℤq∗, the algorithm computes R1=gr′and R2=egs,ℋ1id1′r′/eC1,skid1 and generates an update key rkid1⟶id1′=R1,R2, which is also a reencryption key.(6)
REncrypt1rkid1⟶id2,cid1: providing reencryption key rkid1⟶id2 and ciphertext cid1=C1,1,C1,2 under identity id1 as input, the algorithm computes C2,1=C1,1 and C2,2=C1,2/rkid1⟶id2 and outputs a delegation ciphertext cid2=C2,1,C2,2, which can be decrypted by delegatee with skid2. This ciphertext will be sent to the requester (delegatee) but not stored on the cloud server.(7)
REncrypt2rkid1⟶id1′,cid1: with update key rkid1⟶id1′=R1,R2 and ciphertext cid1=C1,1,C1,2 as input, the algorithm computes C1,1′=R1 and C1,2′=C1,2⋅R2 and outputs a new ciphertext cid1′=C1,1′,C1,2′ which will replace the old ciphertext cid1 to store on the cloud server.(8)
Decrypt1skid,cid: after downloading the ciphertext cid=C1,1,C1,2, original ciphertext or updated ciphertext, from the cloud server, the user (data owner and delegator) runs the algorithm to compute m=C1,2/eC1,1,skid with the private key (usually the latest private key corresponding to the newest identity) to output the plaintext or an error flag ⊥.(9)
Decrypt2skid2,cid2: the requester (delegatee) decrypts the delegation ciphertext cid2=C2,1,C2,2 with the private key skid2=ℋ1id2s to output plaintext or an error flag ⊥. The process is as follows:①
Kid2,id1=eskid2,ℋ1id1.②
m=C2,2⋅eC2,1,ℋ2Kid2,id1id1id2.


### 4.3. Correctness of the Proposed Scheme

(1)
The correctness of decrypting the original ciphertextcid=C1,1,C1,2 with the original private key skid1=ℋ1id1s is verified as follows:(2)C1,2eC1,1,skid1=m⋅egs,ℋ1id1regr,ℋ1id1s=m.(2)
The correctness of processing updated ciphertextcid1′=C1,1′,C1,2′=R1,C1,2⋅R2 with the new private key skid1′=ℋ1id1′s corresponding to the new identity id1′ is verified as follows:(3)C1,2′eC1,1′,skid1′=C1,2⋅R2eR1,skid1′=m⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′/eC1,skid1egr′,ℋ1id1′s=m⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′egr,skid1⋅egr′,ℋ1id1′s=m.(3)
The correctness of processing delegation ciphertextcid2=C1,1,C1,2/rkid1⟶id2=C2,1,C2,2 with the delegatee’s private key skid2=ℋ1id2s is verified as follows:①
C2,2=C1,2/rkid1⟶id2=m⋅egs,ℋ1id1r/eC1,ℋ2Kid1,id2id1id2⋅skid1=m⋅egs,ℋ1id1r/egr,ℋ2Kid1,id2id1id2⋅egr,ℋ1id1s=m/egr,ℋ2Kid1,id2id1id2②
Kid2,id1=eskid2,ℋ1id1=eℋ1id2s,ℋ1id1=eℋ1id1s,ℋ1id2=eskid1,ℋ1id2=Kid1,id2③
C2,2⋅eC2,1,ℋ2Kid2,id1id1id2=m/egr,ℋ2Kid1,id2id1id2⋅egr,ℋ2Kid2,id1id1id2=m


### 4.4. 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 valueegr,skid1 rather than skid1 which means achieving collusion safety. The ciphertext obtained by the former one is in the same format as the ciphertext is generated directly with the new identity id1′. 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. The delegatee and the proxy conspire to compute a valueegr,skid1 from the delegation key. If an attacker constructs another pair such as gr′,egs,ℋ1id1′r′, a new update key rkid1⟶id1′=gr′,egs,ℋ1id1′r′/eC1,skid1 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.
LetA be a PPT algorithm that has a nonnegligible advantage ϵ in attacking the proposed scheme. We use A to construct a second algorithm ℬ, which has a nonnegligible advantage at solving the DBDH problem in G1 and G2. Algorithm ℬ accepts as input a properly distributed tuple G1=g,ga,gb,gc,T∈G14×G2 and outputs 1 if T=eg,gabc. A interacts with algorithm ℬ as follows.
First, algorithmℬ treats the hash functions ℋ1 and ℋ2 as random oracles and performs the following simulation:(1)
Simulation ofℋ1:0,1∗⟶G1. When a query for identity id is received, simulator searches the hash table L1 which includes some tuples like id,h,z,α. If the id exists in the L1, return h as the query result. Otherwise, flip a weighted coin that the probability of heads is γ (represented as Prα=1=γ) to get a random α∈0,1. Select z∈Zq∗ randomly and compute h. If α=1, set h=gz; otherwise, set h=gcz. No matter α=1or0, h is correctly distributed.(2)
Simulation ofℋ2:0,1∗⟶G1. When a query for string X like Kid1id2 where K=eskid1,ℋ1id2 is received, simulator simply returns x∈G1 and records tuple X,x into table L2.
Then, the interaction simulation proceeds as follows:(1)
Select.A selects i from set 0,1.(2)
Setup.ℬ generates the system’s master public parameters mpp=ℋ1,ℋ2,g,ga,q and sends it to A.(3)
Phase 1.A adaptively issues a series of queries.(1)
Private key query. WhenA sends an identity id to ℬ to query its corresponding private key, ℬ evaluates ℋ1id as above to get (id,h,z,α) and returns skid=gaz to A.(2)
Update key query. WhenA sends an update key query from identity id to id′, ℬ selects r,r′∈Zq∗ randomly and evaluates ℋ1id and ℋ1id′ to obtain (z,α) and (z′,α′).Ifα=0, ℬ computes rkid⟶id′=ega,ℋ1id′r′/Tz and returns it to A. Note that this update key is incorrectly formed.Ifα=1, ℬ computes rkid⟶id′=ega,ℋ1id′r′/egr,gaz and returns it to A.(3)
Delegation key query. WhenA sends a delegation key query from identity id1 to identity id2, ℬ selects r1∈Zq∗ and evaluates ℋ1id1 and ℋ1id2 to obtain (z1,α1) and (z2,α2), computes rkid1⟶id2=egr1,gaz1⋅ℋ2egaz1,ℋ1id2id1id2, and returns it to A. Note that when α=1, this delegation key is correctly formed; when α=0, this delegation key is incorrectly formed.(4)
Challenge phase. At the end of phase 1,A submits challenge identity id∗ and two same length message m0,m1∈G2 to ℬ who will evaluate ℋ1id∗ and look for tuple id∗,h,z,α from table L1 and return challenge ciphertext c∗=gb,mi⋅Tz to A. Note that there are following restrictions on id∗ to avoid trivial decryption:(1)
The private key corresponding toid∗ has not been queried.(2)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued, the private key of any id in set ID = {id1,id2,…idn} has not been queried.(3)
If the delegation key query fromid∗ to idj has been issued, the private key of idj has not been queried.(4)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued and delegation key from any id in set ID = {id1,id2,…idn} to idj has been queried, the private key of idj has not been queried.(5)
Phase 2.A issues query as in phase 1 except restrictions as above.(6)
Guess.A outputs its guess i′∈0,1. If any of the following conditions are false, ℬ aborts the simulation. Otherwise, if i′=i, ℬ outputs 1 or 0 otherwise.


#### 4.4.1. Conditions for Abort

(1)
When the private key query forid∗ is issued, α is chosen to be 1.(2)
When the private key queries for otherid except id∗ are issued, α is chosen to be 0.(3)
When the update key queries fromidj to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.(4)
When the delegation key queries fromidi to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.Claim. Ifℬ does not abort during the game, then A’s view is identical to the real attack, except reencryption keys of the form rkid∗⟶⋯. The discussion of this case can refer to [18]. If the input to ℬ is a DBDH tuple, then the challenge ciphertext c∗ is correct encryption of mi under id∗ and hence (subject to the definition of A and the argument above) Pri′=i−1/2≥ɛ. When the input to ℬ 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 Pri′=i≥ϵ+1/2 for a nonnegligible ϵ. Hence, ℬ succeeds with nonnegligible advantage.


## 4.1. A Brief Description of Original Scheme

The original scheme has six algorithms as follows:(1)
Setup: let e:G1×G1⟶G2 be a bilinear map, where G1 and G2 are two cyclic groups of the same prime order q and g is a generator of G1. Select two hash functions ℋ1:0,1∗⟶G1 and ℋ2:G2⟶G1. Randomly select s∈ℤq∗, set the master secret key msk=s, and output the master public parameters mpp=G1,G2,q,g,gs,ℋ1,ℋ2.(2)
KeyGenmpp,msk,id: providing mpp, msk, and identity id∈0,1∗ as input, the algorithm outputs a corresponding private key skid=ℋ1ids.(3)
Encryptmpp,id,m: providing mpp, identity id, and datam as input, randomly select r∈ℤq∗, and the algorithm outputs a corresponding ciphertext cid=gr,m⋅egs,ℋ1idr.(4)
RKGenmpp,skid1,id2: providing mpp, private key skid1, and identity id2 as input, randomly select element X from group G2, and the algorithm computes R1,R2=Encryptmpp,id2,X and outputs a reencryption key rkid1⟶id2=R1,R2,R3, where R3=ℋ2X/skid1.(5)
REncryptmpp,rkid1⟶id2,cid1: providing mpp, the reencryption key rkid1⟶id2, and ciphertext cid1 as input:①
Ifcid1=C1,C2 is a level-1 ciphertext (original ciphertext), the algorithm computes C2′=C2⋅eC1,R3, C3=R1, and C4=R2 and outputs ciphertext cid2=C1,C2′,C3,C4.②
Ifcid1=C1,C2,…,C2n−1,C2n is a level-n (n>1) ciphertext, the algorithm computes C2n′=C2n⋅eC2n−1,R3, C2n+1=R1, and C2n+2=R2 and outputs ciphertext cid2=C1,C2,…,C2n−1,C2n′,C2n+1,C2n+2.(6)
Decryptmpp,skid,cid: providing mpp, private key skid, and ciphertext cid as input:①
Ifcid=C1,C2 is a level-1 ciphertext (original ciphertext), the algorithm computes m=C2/eC1,skid.②
Ifcid=C1,C2,…,C2n−1,C2n is a level-n ciphertext, consider the combination (C2n−1,C2n) as a level-1 ciphertext, the algorithm computes Xn=C2n/eC2n−1,skid and Xi=C2i/eC2i−1,ℋ2Xi+1, where i is evaluated from n−1 to 2. Finally, the algorithm computes m=C2/eC1,ℋ2X2.The original ciphertext contains two elements, the length of which increases by two elements for each reencryption. Theoretically, the ciphertext can be reencrypted any number of times.


## 4.2. Detailed Design of the Proposed Scheme

There are nine algorithms in the proposed scheme, and the process flow is depicted in Figure3. The description of the processes is as follows:(1)
Setup: let e:G1×G1⟶G2 be a bilinear map, where G1 and G2 are two cyclic groups of the same prime order q and g is a generator of G1. Select a random s∈ℤq∗ as the master secret key msk and two hash functions ℋ1:0,1∗⟶G1 and ℋ2:0,1∗⟶G1. Output the master public parameters mpp=ℋ1,ℋ2,g,gs,q while keeping the master secret key msk=s private.(2)
KeyGenmsk,id: when PKG receives a key generation request from a legitimate user with identityid, 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 skid=ℋ1ids.(3)
Encryptid,m: when a user wants to encrypt data m∈G2 with identity id, the encryption algorithm picks r∈Rℤq∗ and computes C1=grand C2=m⋅egs,ℋ1idr to generate the ciphertext cid=C1,C2, which will be sent to a cloud server for storage. This resulting ciphertext is also called original ciphertext (level-1 ciphertext).(4)
RKGen1skid1,id1,id2,C1: providing as input user’s private key skid1, identities (id1, id2), and an element of ciphertext C1, this algorithm generates a reencryption key (a.k.a. access token) rkid1⟶id2, which will be sent to proxy for storage and converting the ciphertext upon receiving the request from the delegatee. The calculation processing is as follows:①
Kid1,id2=eskid1,ℋ1id2.②
rkid1⟶id2=eC1,ℋ2Kid1,id2id1id2⋅skid1.(5)
RKGen2skid1,id1′,C1: inputting user’s private key skid1, a new identity id1′ and part of the ciphertext C1 choose a random r′∈ℤq∗, the algorithm computes R1=gr′and R2=egs,ℋ1id1′r′/eC1,skid1 and generates an update key rkid1⟶id1′=R1,R2, which is also a reencryption key.(6)
REncrypt1rkid1⟶id2,cid1: providing reencryption key rkid1⟶id2 and ciphertext cid1=C1,1,C1,2 under identity id1 as input, the algorithm computes C2,1=C1,1 and C2,2=C1,2/rkid1⟶id2 and outputs a delegation ciphertext cid2=C2,1,C2,2, which can be decrypted by delegatee with skid2. This ciphertext will be sent to the requester (delegatee) but not stored on the cloud server.(7)
REncrypt2rkid1⟶id1′,cid1: with update key rkid1⟶id1′=R1,R2 and ciphertext cid1=C1,1,C1,2 as input, the algorithm computes C1,1′=R1 and C1,2′=C1,2⋅R2 and outputs a new ciphertext cid1′=C1,1′,C1,2′ which will replace the old ciphertext cid1 to store on the cloud server.(8)
Decrypt1skid,cid: after downloading the ciphertext cid=C1,1,C1,2, original ciphertext or updated ciphertext, from the cloud server, the user (data owner and delegator) runs the algorithm to compute m=C1,2/eC1,1,skid with the private key (usually the latest private key corresponding to the newest identity) to output the plaintext or an error flag ⊥.(9)
Decrypt2skid2,cid2: the requester (delegatee) decrypts the delegation ciphertext cid2=C2,1,C2,2 with the private key skid2=ℋ1id2s to output plaintext or an error flag ⊥. The process is as follows:①
Kid2,id1=eskid2,ℋ1id1.②
m=C2,2⋅eC2,1,ℋ2Kid2,id1id1id2.


## 4.3. Correctness of the Proposed Scheme

(1)
The correctness of decrypting the original ciphertextcid=C1,1,C1,2 with the original private key skid1=ℋ1id1s is verified as follows:(2)C1,2eC1,1,skid1=m⋅egs,ℋ1id1regr,ℋ1id1s=m.(2)
The correctness of processing updated ciphertextcid1′=C1,1′,C1,2′=R1,C1,2⋅R2 with the new private key skid1′=ℋ1id1′s corresponding to the new identity id1′ is verified as follows:(3)C1,2′eC1,1′,skid1′=C1,2⋅R2eR1,skid1′=m⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′/eC1,skid1egr′,ℋ1id1′s=m⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′egr,skid1⋅egr′,ℋ1id1′s=m.(3)
The correctness of processing delegation ciphertextcid2=C1,1,C1,2/rkid1⟶id2=C2,1,C2,2 with the delegatee’s private key skid2=ℋ1id2s is verified as follows:①
C2,2=C1,2/rkid1⟶id2=m⋅egs,ℋ1id1r/eC1,ℋ2Kid1,id2id1id2⋅skid1=m⋅egs,ℋ1id1r/egr,ℋ2Kid1,id2id1id2⋅egr,ℋ1id1s=m/egr,ℋ2Kid1,id2id1id2②
Kid2,id1=eskid2,ℋ1id1=eℋ1id2s,ℋ1id1=eℋ1id1s,ℋ1id2=eskid1,ℋ1id2=Kid1,id2③
C2,2⋅eC2,1,ℋ2Kid2,id1id1id2=m/egr,ℋ2Kid1,id2id1id2⋅egr,ℋ2Kid2,id1id1id2=m


## 4.4. 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 valueegr,skid1 rather than skid1 which means achieving collusion safety. The ciphertext obtained by the former one is in the same format as the ciphertext is generated directly with the new identity id1′. 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. The delegatee and the proxy conspire to compute a valueegr,skid1 from the delegation key. If an attacker constructs another pair such as gr′,egs,ℋ1id1′r′, a new update key rkid1⟶id1′=gr′,egs,ℋ1id1′r′/eC1,skid1 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.
LetA be a PPT algorithm that has a nonnegligible advantage ϵ in attacking the proposed scheme. We use A to construct a second algorithm ℬ, which has a nonnegligible advantage at solving the DBDH problem in G1 and G2. Algorithm ℬ accepts as input a properly distributed tuple G1=g,ga,gb,gc,T∈G14×G2 and outputs 1 if T=eg,gabc. A interacts with algorithm ℬ as follows.
First, algorithmℬ treats the hash functions ℋ1 and ℋ2 as random oracles and performs the following simulation:(1)
Simulation ofℋ1:0,1∗⟶G1. When a query for identity id is received, simulator searches the hash table L1 which includes some tuples like id,h,z,α. If the id exists in the L1, return h as the query result. Otherwise, flip a weighted coin that the probability of heads is γ (represented as Prα=1=γ) to get a random α∈0,1. Select z∈Zq∗ randomly and compute h. If α=1, set h=gz; otherwise, set h=gcz. No matter α=1or0, h is correctly distributed.(2)
Simulation ofℋ2:0,1∗⟶G1. When a query for string X like Kid1id2 where K=eskid1,ℋ1id2 is received, simulator simply returns x∈G1 and records tuple X,x into table L2.
Then, the interaction simulation proceeds as follows:(1)
Select.A selects i from set 0,1.(2)
Setup.ℬ generates the system’s master public parameters mpp=ℋ1,ℋ2,g,ga,q and sends it to A.(3)
Phase 1.A adaptively issues a series of queries.(1)
Private key query. WhenA sends an identity id to ℬ to query its corresponding private key, ℬ evaluates ℋ1id as above to get (id,h,z,α) and returns skid=gaz to A.(2)
Update key query. WhenA sends an update key query from identity id to id′, ℬ selects r,r′∈Zq∗ randomly and evaluates ℋ1id and ℋ1id′ to obtain (z,α) and (z′,α′).Ifα=0, ℬ computes rkid⟶id′=ega,ℋ1id′r′/Tz and returns it to A. Note that this update key is incorrectly formed.Ifα=1, ℬ computes rkid⟶id′=ega,ℋ1id′r′/egr,gaz and returns it to A.(3)
Delegation key query. WhenA sends a delegation key query from identity id1 to identity id2, ℬ selects r1∈Zq∗ and evaluates ℋ1id1 and ℋ1id2 to obtain (z1,α1) and (z2,α2), computes rkid1⟶id2=egr1,gaz1⋅ℋ2egaz1,ℋ1id2id1id2, and returns it to A. Note that when α=1, this delegation key is correctly formed; when α=0, this delegation key is incorrectly formed.(4)
Challenge phase. At the end of phase 1,A submits challenge identity id∗ and two same length message m0,m1∈G2 to ℬ who will evaluate ℋ1id∗ and look for tuple id∗,h,z,α from table L1 and return challenge ciphertext c∗=gb,mi⋅Tz to A. Note that there are following restrictions on id∗ to avoid trivial decryption:(1)
The private key corresponding toid∗ has not been queried.(2)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued, the private key of any id in set ID = {id1,id2,…idn} has not been queried.(3)
If the delegation key query fromid∗ to idj has been issued, the private key of idj has not been queried.(4)
If a series of update key queries which originate fromid∗ to id1, next from id1 to id2,…, from idn−1 to idn have been issued and delegation key from any id in set ID = {id1,id2,…idn} to idj has been queried, the private key of idj has not been queried.(5)
Phase 2.A issues query as in phase 1 except restrictions as above.(6)
Guess.A outputs its guess i′∈0,1. If any of the following conditions are false, ℬ aborts the simulation. Otherwise, if i′=i, ℬ outputs 1 or 0 otherwise.


### 4.4.1. Conditions for Abort

(1)
When the private key query forid∗ is issued, α is chosen to be 1.(2)
When the private key queries for otherid except id∗ are issued, α is chosen to be 0.(3)
When the update key queries fromidj to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.(4)
When the delegation key queries fromidi to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.Claim. Ifℬ does not abort during the game, then A’s view is identical to the real attack, except reencryption keys of the form rkid∗⟶⋯. The discussion of this case can refer to [18]. If the input to ℬ is a DBDH tuple, then the challenge ciphertext c∗ is correct encryption of mi under id∗ and hence (subject to the definition of A and the argument above) Pri′=i−1/2≥ɛ. When the input to ℬ 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 Pri′=i≥ϵ+1/2 for a nonnegligible ϵ. Hence, ℬ succeeds with nonnegligible advantage.


## 4.4.1. Conditions for Abort

(1)
When the private key query forid∗ is issued, α is chosen to be 1.(2)
When the private key queries for otherid except id∗ are issued, α is chosen to be 0.(3)
When the update key queries fromidj to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.(4)
When the delegation key queries fromidi to idj (rkidi⟶idj) are issued, if idi⟶idj lies along a path leading from id∗, the value α for idj is chosen to be 1. Or idi⟶idj does not lie along a path leading from id∗, the value α for idi is chosen to be 0.Claim. Ifℬ does not abort during the game, then A’s view is identical to the real attack, except reencryption keys of the form rkid∗⟶⋯. The discussion of this case can refer to [18]. If the input to ℬ is a DBDH tuple, then the challenge ciphertext c∗ is correct encryption of mi under id∗ and hence (subject to the definition of A and the argument above) Pri′=i−1/2≥ɛ. When the input to ℬ 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 Pri′=i≥ϵ+1/2 for a nonnegligible ϵ. Hence, ℬ succeeds with nonnegligible advantage.


## 5. 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 numberr 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 Ci=gri,mi⋅egs,ℋ1id1ri, and REKi⊆rkid1⟶id2,rkid1⟶id3,… 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.Table 1
Plaintext, ciphertext, random, encryption time, and reencryption key list information.
DataRandomCiphertextTimeREK listm1r1C1T1REK1m2r2C2T2REK2……………mnrnCnTnREKnFor the sake of analysis, let us assume this scenario: userid1 has three types of files (m1, m2, and m3), which are encrypted with the identity and stored on the cloud server. The first type of file m1 is some study notes shared with a requester (a common learner with identity id2). The second type of file m2 is personal photos that involve some private information and should not be allowed to be accessed by others. The content of the third file m3 is several relevant information that a user (assumed as a prosumer) shares with the utility organization or other prosumers in a microgrid.


### 5.2. 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 filesm1, m2, and m3 are encrypted with the same random number under the identity id1. 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. The processing of revoking the requestor id2’s access permission to files m2 and m3 is shown as follows:Step 1: generate a new identity. The user combines well-known information with an attribute (manufacturer/smart meter id:idsm) of microgrid devices (i.e., smart meter) as a new identityid1′=id1idsm for the third type of file m3. In the same manner, the user will also combine another attribute as an encryption identity for the second type of file m2. Both operations are the same, and file m3 is considered for the following analysis.Step 2: generate a new private key. The user sends the new identity to the PKG to generate a new private keyskid1′=ℋ1id1′s.Step 3: compute a reencryption key for updating ciphertext. The user chooses a randomr′∈ℤq∗ and runs algorithm RKGen2skid1,id1′,C1,1 to generate rkid1⟶id1′=R1,R2=gr′,egs,ℋ1id1′r′/eC1,1,skid1 and then send it to the cloud server.Step 4: update the ciphertext. After receiving the update reencryption keyrkid1⟶id1′=R1,R2, the proxy uses it to convert the ciphertext cid1 to a new ciphertext cid1′=R1,C1,2⋅R2=C1,1′,C1,2′, which will replace the old ciphertext cid1 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 keyskid1′. The computation steps are as follows:(1)
C1,1′=R1=gr′.(2)
C1,2′=C1,2⋅R2=m3⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′/egr,skid1=m3⋅egs,ℋ1id1′r′.(3)
C1,2′/eC1,1′,skid1′=m3⋅egs,ℋ1id1′r′/eC1,1′,skid1′=m3⋅egs,ℋ1id1′r′/egr′,ℋ1id1′s=m3.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 keyrkid1⟶id2 cannot be decrypted with the requester’s private key skid2=ℋ1id2s because(4)C2,2′=m3⋅gs,ℋ1id1′r′rkid1⟶id2=m3⋅egs,ℋ1id1′r′egr,ℋ2Kid1,id2id1id2⋅ℋ1id1s.So, when the user revokes the delegation for the requesterid2 by updating the ciphertext, the proxy will delete the corresponding old reencryption key. And when the requester id2 requests the data, the user will refuse to generate a delegation key.


### 5.3. Reauthorization Management

After the above ciphertext update operation, given that these operations were also applied tom2. It can now only be accessible to the data owner. However, file m3is required to be shared with other entities (other prosumers or the utility organization and assume identity is id3) in the microgrid. For example, the user needs to reauthorize to energy consumers id3, and this process is shown as follows:Step 1: generate the reauthorization key. The user (delegator) runs the algorithmRKGen1skid1′,id1′,id3,C1,1′ to compute a new reencryption key rkid1′⟶id3. The calculation process is shown as follows:(1)
Kid1′,id3=eskid1′,ℋ1id3.(2)
rkid1′⟶id3=eC1,1′,ℋ2Kid1′,id3id1′id3⋅skid1′.Then, 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 algorithmREncrypt1rkid1′⟶id3,cid1′ to convert the updated ciphertext cid1′ to a new ciphertext cid3=C1,1′,C1,2′/rkid1′⟶id3=C3,1,C3,2. Then, the ciphertext cid3 is sent to the requester (delegatee).Step 3: decrypt the reauthorization ciphertext. After receiving the ciphertext from the proxy, the requester decrypts the ciphertextcid3 with the private key skid3=ℋ1id3s to get the plaintext. The decryption process is shown as follows:(1)
Kid3,id1′=eskid3,ℋ1id1′.(2)
m=C3,2⋅eC3,1,ℋ2Kid3,id1′id1′id3.


### 5.4. Conditional Reservation Delegation Management

This 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. These 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. This 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. The user (seller, identity isid1) generates an energy information file and encrypts it with the identity. The ciphertext cid1=C1,1,C1,2 is uploaded to the cloud server and can be shared with other users.Step 2: generate conditional reservation delegation key:(1)
The 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 identityid3=identityidsmduration.(2)
The user generates a delegation reencryption keyrkid1⟶id3=eC1,1,ℋ2Kid1,id3id1id3⋅skid1 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 keyskid3=ℋ1id3s corresponding to the identity id3=identityidsmduration from PKG.Step 4: generate the delegation ciphertext. The proxy runs the algorithmREncrypt1rkid1⟶id3,cid1 to transform the ciphertext cid1 to the delegation ciphertext cid3=C1,1,C1,2/rkid1⟶id3=C3,1,C3,2. And then the ciphertext cid3 is sent to the requester.Step 5: decrypt the delegation ciphertext. The requester decrypts the ciphertextcid3 with the private key skid3=ℋ1id3s to get the plaintext. The process is shown as follows:(1)
Kid3,id1=eskid3,ℋ1id1.(2)
m=C3,2⋅eC3,1,ℋ2Kid3,id1id1id3.


## 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 numberr 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 Ci=gri,mi⋅egs,ℋ1id1ri, and REKi⊆rkid1⟶id2,rkid1⟶id3,… 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.Table 1
Plaintext, ciphertext, random, encryption time, and reencryption key list information.
DataRandomCiphertextTimeREK listm1r1C1T1REK1m2r2C2T2REK2……………mnrnCnTnREKnFor the sake of analysis, let us assume this scenario: userid1 has three types of files (m1, m2, and m3), which are encrypted with the identity and stored on the cloud server. The first type of file m1 is some study notes shared with a requester (a common learner with identity id2). The second type of file m2 is personal photos that involve some private information and should not be allowed to be accessed by others. The content of the third file m3 is several relevant information that a user (assumed as a prosumer) shares with the utility organization or other prosumers in a microgrid.


## 5.2. 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 filesm1, m2, and m3 are encrypted with the same random number under the identity id1. 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. The processing of revoking the requestor id2’s access permission to files m2 and m3 is shown as follows:Step 1: generate a new identity. The user combines well-known information with an attribute (manufacturer/smart meter id:idsm) of microgrid devices (i.e., smart meter) as a new identityid1′=id1idsm for the third type of file m3. In the same manner, the user will also combine another attribute as an encryption identity for the second type of file m2. Both operations are the same, and file m3 is considered for the following analysis.Step 2: generate a new private key. The user sends the new identity to the PKG to generate a new private keyskid1′=ℋ1id1′s.Step 3: compute a reencryption key for updating ciphertext. The user chooses a randomr′∈ℤq∗ and runs algorithm RKGen2skid1,id1′,C1,1 to generate rkid1⟶id1′=R1,R2=gr′,egs,ℋ1id1′r′/eC1,1,skid1 and then send it to the cloud server.Step 4: update the ciphertext. After receiving the update reencryption keyrkid1⟶id1′=R1,R2, the proxy uses it to convert the ciphertext cid1 to a new ciphertext cid1′=R1,C1,2⋅R2=C1,1′,C1,2′, which will replace the old ciphertext cid1 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 keyskid1′. The computation steps are as follows:(1)
C1,1′=R1=gr′.(2)
C1,2′=C1,2⋅R2=m3⋅egs,ℋ1id1r⋅egs,ℋ1id1′r′/egr,skid1=m3⋅egs,ℋ1id1′r′.(3)
C1,2′/eC1,1′,skid1′=m3⋅egs,ℋ1id1′r′/eC1,1′,skid1′=m3⋅egs,ℋ1id1′r′/egr′,ℋ1id1′s=m3.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 keyrkid1⟶id2 cannot be decrypted with the requester’s private key skid2=ℋ1id2s because(4)C2,2′=m3⋅gs,ℋ1id1′r′rkid1⟶id2=m3⋅egs,ℋ1id1′r′egr,ℋ2Kid1,id2id1id2⋅ℋ1id1s.So, when the user revokes the delegation for the requesterid2 by updating the ciphertext, the proxy will delete the corresponding old reencryption key. And when the requester id2 requests the data, the user will refuse to generate a delegation key.


## 5.3. Reauthorization Management

After the above ciphertext update operation, given that these operations were also applied tom2. It can now only be accessible to the data owner. However, file m3is required to be shared with other entities (other prosumers or the utility organization and assume identity is id3) in the microgrid. For example, the user needs to reauthorize to energy consumers id3, and this process is shown as follows:Step 1: generate the reauthorization key. The user (delegator) runs the algorithmRKGen1skid1′,id1′,id3,C1,1′ to compute a new reencryption key rkid1′⟶id3. The calculation process is shown as follows:(1)
Kid1′,id3=eskid1′,ℋ1id3.(2)
rkid1′⟶id3=eC1,1′,ℋ2Kid1′,id3id1′id3⋅skid1′.Then, 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 algorithmREncrypt1rkid1′⟶id3,cid1′ to convert the updated ciphertext cid1′ to a new ciphertext cid3=C1,1′,C1,2′/rkid1′⟶id3=C3,1,C3,2. Then, the ciphertext cid3 is sent to the requester (delegatee).Step 3: decrypt the reauthorization ciphertext. After receiving the ciphertext from the proxy, the requester decrypts the ciphertextcid3 with the private key skid3=ℋ1id3s to get the plaintext. The decryption process is shown as follows:(1)
Kid3,id1′=eskid3,ℋ1id1′.(2)
m=C3,2⋅eC3,1,ℋ2Kid3,id1′id1′id3.


## 5.4. Conditional Reservation Delegation Management

This 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. These 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. This 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. The user (seller, identity isid1) generates an energy information file and encrypts it with the identity. The ciphertext cid1=C1,1,C1,2 is uploaded to the cloud server and can be shared with other users.Step 2: generate conditional reservation delegation key:(1)
The 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 identityid3=identityidsmduration.(2)
The user generates a delegation reencryption keyrkid1⟶id3=eC1,1,ℋ2Kid1,id3id1id3⋅skid1 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 keyskid3=ℋ1id3s corresponding to the identity id3=identityidsmduration from PKG.Step 4: generate the delegation ciphertext. The proxy runs the algorithmREncrypt1rkid1⟶id3,cid1 to transform the ciphertext cid1 to the delegation ciphertext cid3=C1,1,C1,2/rkid1⟶id3=C3,1,C3,2. And then the ciphertext cid3 is sent to the requester.Step 5: decrypt the delegation ciphertext. The requester decrypts the ciphertextcid3 with the private key skid3=ℋ1id3s to get the plaintext. The process is shown as follows:(1)
Kid3,id1=eskid3,ℋ1id1.(2)
m=C3,2⋅eC3,1,ℋ2Kid3,id1id1id3.


## 6. 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. Identity-based 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. The GA1 and GA2 correspond to basic IBP1 in the GA scheme, and GA2 is an optimization of GA1 in terms of the absence of ciphertext expansion during reencryption but is not multiusable and nontransferable.Table2 shows some of the characteristics and achieved security notion of the schemes for two functions: update and delegation. Since the reencrypted ciphertext in scheme GA2 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. There 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 “-.” The 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.Table 2
Comparison of the representative scheme and the proposed scheme based on essential characteristics.
CharacteristicsUpdateDelegationSHBLLWSGA1ProposedSHBGA1GA2ProposedInteractiveYesNoNoNoNoNoNoNoMultiuseTMEMEMTMNoEMNoNoTransitiveYesNoNoYesNoNoNoNoTransferable————NoYesYesNoCollusion safeNoYesNoYesYesNoNoYesCiphertext optimalYesNoNoYesYesNoYesYesAchieved securityCPACPACPACPACPACPACPACPAStandard modelYesYesNoNoYesNoNoNoIdentity-basedNoYesYesYesNoYesYesYesThe characteristic comparison in Table2 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. These changes will cause the ciphertext to be updated. Thus, 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. Thus, 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. Thus, this requires that the scheme should be nontransferable, but the schemes GA1 and GA2 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.The essential feature of PRE is delegation. Thus, 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. Table3 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.Table 3
Functionality comparison of the different PRE schemes.
FunctionalitiesSHBLLWSGAProposedDelegationYesYesYesYesDelegation revocationYesYesNoYesConditional reservation delegationNoNoYesYesCiphertext updateYesYesNoYesReauthorizationNoYesNoYesDetail analysisNoNoNoYesIn Table4, 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. Decrypt1 denotes the decryption algorithm used by the data owner to decrypt the ciphertext (original or updated). Decrypt2 denotes the decryption algorithm used by the delegatee to decrypt the reencrypted delegation ciphertext. RKGen1 denotes the delegation key generation algorithm. RKGen2 denotes an update key generation algorithm. REncrypt1 denotes the reencryption algorithm for generating a delegation ciphertext. REncrypt2 denotes the reencryption algorithm for updating ciphertext. tP denotes the pairing computation time. tR denotes the time of the random computation. tM denotes the calculation time of group element multiplication or division operations (the inverse computation is seen as division operation). tE 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 4
Computation cost comparison of each phase in the different schemes.
AlgorithmsSHBLLWSGA1GA2ProposedSetuptR3tE,n+7tRtE,2tRtE,2tRtE,2tRKeyGentE,tR11tE,7tR,n+11tMtEtEtEEncrypt2tE,tR,tP,tM4tE,tR,tP,tM2tE,tR,tP,tM2tE,tR,tP,tM2tE,tR,tP,tMDecrypt1tE,tP,2tM3tP,3tMtP,tMtP,tMtP,tMRKGen1tE,tM—2tE,2tR,tP,tMtP,tM2tP,tMREncrypt1tP—tP,tMtPtMDecrypt2tE,2tM4tP,tE,5tM2tP,2tM2tP,tM2tP,tMRKGen2tM8tE,3tR,tP,5tM——2tE,tR,2tP,tMREncrypt2tP2tP,tM——tMTable5 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. The SHB scheme is the ElGamal algorithm based on the elliptic curve. The LLWS scheme is mainly used for ciphertext updating. Thus, the run time of algorithm RKGen1 and REncrypt1 for authorization is not provided. Note that the run time of the algorithm Decrypt1 is for decrypting the original ciphertext, while the run time of the algorithm Decrypt2 is for decrypting the reencrypted ciphertext, which is updated only once. The 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 calculated. These performance evaluations are performed on a computer with 3.4 GHz Intel Core i5-3570 processor, 8 GB RAM, and the operating system is Windows 7 Professional with Service Pack 1. All the programs are based on the PBC library [28], where the parameter is the type A curve.Table 5
Comparison of the computation time (in ms) of each algorithm in different schemes.
AlgorithmsSHBLLWSGA1GA2ProposedSetup6.474376.15912.80113.11313.025KeyGen6.46771.02721.66922.0122.146Encrypt21.05633.70121.01921.32721.033Decrypt119.55239.17413.12113.25513.009RKGen16.472—21.10313.27826.068REncrypt113.065—13.10913.2140.02Decrypt21.55758.60726.21526.5226.076RKGen20.00559.323——34.592REncrypt26.45326.089——0.011Figure 4
Comparison of the computation time (in ms) of each algorithm in different schemes.In Table5, 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. The computation time of Setup, KeyGen, Encrypt, and Decrypt1 are the same in GA1 and GA2 and the proposed proposal because these approaches are based on BF architecture. And the computation time for Decrypt2 of the three schemes is approximately the same. During the RKGen1 phase, the proposed scheme needs two pairing computations making the computation time larger than GA1 and GA2. Although the computation time of RKGen2 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 REncrypt1 and REncrypt2 in the proposed scheme is very short. Therefore, 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.Figure5 shows the time required to update the ciphertext from 100 MB to 1 GB, respectively. The SHB scheme needs 26,873.24 seconds to update 1 GB ciphertext, while the proposed work only needs 44 seconds. This value plus the time of reencryption key generation (34.592 ms) is also much less than the time required by SHB. This 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.Figure 5
Computation time of updating 100 MB to 1 GB ciphertext in SHB and proposed scheme.


## 7. Conclusions

In this paper, an improved IBPRE scheme is proposed to realize secure cloud data sharing. The 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.



---

*Source: 8833693-2020-10-14.xml*