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.
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. Section 2 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). Let and are two cyclic groups of the same prime order and be a generator of . We say that is a bilinear map if it satisfies the following properties:(1)Bilinear: for all and , .(2)Nondegenerate: , where is the unit of .(3)Computability: can be efficiently computed.
Definition 2 (decisional bilinear Diffie–Hellman (DBDH) problem). Let and are two cyclic groups of the same prime order and be a generator of . Support that is a bilinear map. The decisional bilinear Diffie–Hellman (DBDH) problem is to decide, given a tuple of values (where ), whether holds.
Let be a security parameter of sufficient size. Formally, we say that the DBDH assumption holds in , if for all probabilistic polynomial time (PPT) algorithm , the following condition is true, where is defined as a negligible function:
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): taking a security parameter as input, this algorithm generates both master public parameters () and master secret key (). The is distributed to all participants, while the is kept secretly.(2): taking , , and an identity as input, this algorithm outputs a corresponding private key .(3): taking , identity , and message as input, this algorithm computes an original ciphertext .(4): taking , , identities, and an element of ciphertext as input, this algorithm calculates a delegation token .(5): taking , old private key , a new identity , and an element of ciphertext as input, this algorithm produces an update key .(6): taking , delegation key , and ciphertext as input, this algorithm converts the ciphertext into a delegation ciphertext .(7): taking , update key , and old ciphertext as input, this algorithm updates the ciphertext into a new ciphertext .(8): taking , delegator’s (latest) private key , and ciphertext as input, this algorithm outputs corresponding plaintext or an error flag .(9): taking , delegatee’s private key , and delegation ciphertext as input, this algorithm outputs corresponding plaintext or an error flag .We say that an IBPRE-CE scheme is consistent if for any valid identities , , and , their secret keys , , and (generated by ), the corresponding reencryption key and (generated by and ), and ciphertexts , , and (computed by , , and ), the following equations hold:①.②.③.
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) adversary wins the following game with a nonnegligible advantage:(1)Setup. The challenger runs to generate the master public parameters () and the master secret key (). The is sent to , while the is kept securely.(2)Phase 1. issues some private key queries , updates reencryption key queries , and delegation reencryption key queries as follows:(i)On receiving any query of the form (, ), returns to .(ii)On receiving any query of the form (, , ,), returns to , where and is an element of ciphertext.(iii)On receiving any query of the form (, , ,), returns to , where and is an element of ciphertext.(4)Challenge. At the end of phase 1, outputs two equal-length messages and , and a challenging identity which does not exist in trivial decryption (e.g., holds a private key of or some transformation keys which are update reencryption keys or delegation reencryption keys from to and the decryption key of ). The challenger returns a challenge ciphertext , where .(5)Phase 2. adaptively issues queries as phase 1 with some restrictions that the private key of and any trivial decryption key query (, , ) have never been queried. The restrictions are as follows:(i)The private key corresponding to has not been queried.(ii)If a series of update key queries which originate from to , next from to ,…, from to , have been issued, the private key of any in set ID = {} has not been queried.(iii)If the delegation key query from to has been issued, the private key of has not been queried.(iv)If a series of update key queries which originate from to , next from to ,…, from to have been issued, and delegation key from any in set ID = {} to has been queried, the private key of has not been queried.(6)Guess. gives a guess .The advantage of in the above game is defined by .
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 ciphertext to ciphertext and from ciphertext to ciphertext . 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 as , where is the reencryption key known by the proxy, and is ’s (delegatee’s) private key, and is ’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, and can get .(5)Nontransferability: this property means that a delegatee (even if colludes with the proxy) cannot transfer the decryption ability to a third party or entity. For example, user generates the reencryption key to delegate the decryption capacity to the requestor who can decrypt the reencrypted ciphertext but cannot generate a new delegation key which originates from (i.e., ) or reencrypt the delegation ciphertext to generate a new ciphertext which can be decrypted by a third entity with the private key .(6)Unidirectionality: with the reencryption key , the proxy can convert user ’s ciphertext to another one that can be decrypted by the user , 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 Figure 1, the system consists of the user (data owner and delegator), the requester (delegatee), the private key generator (PKG), and the cloud server (proxy).
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 () 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 () 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 algorithm used to calculate the delegation ciphertext is single use. The newly added one 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 one is used by the data owner to decrypt ciphertext or updated ciphertext which have been reencrypted for several times. The second one 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, ) 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.
4.1. A Brief Description of Original Scheme
The original scheme has six algorithms as follows:(1): let be a bilinear map, where and are two cyclic groups of the same prime order and is a generator of . Select two hash functions and . Randomly select , set the master secret key , and output the master public parameters .(2): providing mpp, msk, and identity as input, the algorithm outputs a corresponding private key .(3): providing mpp, identity , and as input, randomly select , and the algorithm outputs a corresponding ciphertext .(4): providing mpp, private key , and identity as input, randomly select element from group and the algorithm computes and outputs a reencryption key , where .(5): providing mpp, the reencryption key , and ciphertext as input:①If is a level-1 ciphertext (original ciphertext), the algorithm computes , , and and outputs ciphertext .②If is a level-n () ciphertext, the algorithm computes , , and and outputs ciphertext .(6): providing mpp, private key , and ciphertext as input:①If is a level-1 ciphertext (original ciphertext), the algorithm computes .②If is a level-n ciphertext, consider the combination () as a level-1 ciphertext, the algorithm computes and , where is evaluated from to 2. Finally, the algorithm computes .
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 Figure 3. The description of the processes is as follows:(1): let be a bilinear map, where and are two cyclic groups of the same prime order and is a generator of . Select a random as the master secret key and two hash functions and . Output the master public parameters while keeping the master secret key private.(2): when PKG receives a key generation request from a legitimate user with identity, this algorithm takes as input (this parameter is included implicitly here and in following algorithms for simplicity), , and identity and generates the corresponding private key .(3): when a user wants to encrypt data with identity , the encryption algorithm picks and computes and to generate the ciphertext , which will be sent to a cloud server for storage. This resulting ciphertext is also called original ciphertext (level-1 ciphertext).(4): providing as input user’s private key , identities (, ), and an element of ciphertext , this algorithm generates a reencryption key (a.k.a. access token) , 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:①.②.(5): inputting user’s private key , a new identity and part of the ciphertext choose a random , the algorithm computes and and generates an update key , which is also a reencryption key.(6): providing reencryption key and ciphertext under identity as input, the algorithm computes and and outputs a delegation ciphertext , which can be decrypted by delegatee with . This ciphertext will be sent to the requester (delegatee) but not stored on the cloud server.(7): with update key and ciphertext as input, the algorithm computes and and outputs a new ciphertext which will replace the old ciphertext to store on the cloud server.(8): after downloading the ciphertext , original ciphertext or updated ciphertext, from the cloud server, the user (data owner and delegator) runs the algorithm to compute with the private key (usually the latest private key corresponding to the newest identity) to output the plaintext or an error flag .(9): the requester (delegatee) decrypts the delegation ciphertext with the private key to output plaintext or an error flag . The process is as follows:①.②.
4.3. Correctness of the Proposed Scheme
(1)The correctness of decrypting the original ciphertext with the original private key is verified as follows:(2)The correctness of processing updated ciphertext with the new private key corresponding to the new identity is verified as follows:(3)The correctness of processing delegation ciphertext with the delegatee’s private key is verified as follows:①②③
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 value rather than 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 . 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 value from the delegation key. If an attacker constructs another pair such as , a new update key can be calculated. If the proxy updates the ciphertext with this forged key, a spoofing attack will happen. However, we have assumed that the user can securely send the reencryption key to the proxy and the user needs to be authenticated, and the proxy is semitrusted, so the unauthenticated attacker cannot update the ciphertext even if he has built a new update key.
Next, we present the formal security proofs for the proposed scheme in the random oracle model as follows.
Theorem 1. Suppose the DBDH assumption holds, our IBPRE-CE scheme is IND-PrID-CPA secure in the random oracle model.
Proof. Let be a PPT algorithm that has a nonnegligible advantage in attacking the proposed scheme. We use to construct a second algorithm , which has a nonnegligible advantage at solving the DBDH problem in and . Algorithm accepts as input a properly distributed tuple and outputs 1 if . interacts with algorithm as follows.
First, algorithm treats the hash functions and as random oracles and performs the following simulation:(1)Simulation of . When a query for identity is received, simulator searches the hash table which includes some tuples like . If the exists in the , return h as the query result. Otherwise, flip a weighted coin that the probability of heads is (represented as ) to get a random . Select randomly and compute h. If , set ; otherwise, set . No matter , h is correctly distributed.(2)Simulation of . When a query for string X like where is received, simulator simply returns and records tuple into table .Then, the interaction simulation proceeds as follows:(1)Select. selects from set .(2)Setup. generates the system’s master public parameters and sends it to .(3)Phase 1. adaptively issues a series of queries.(1)Private key query. When sends an identity to to query its corresponding private key, evaluates as above to get () and returns to .(2)Update key query. When sends an update key query from identity to id′, selects randomly and evaluates and to obtain () and (). If , computes and returns it to . Note that this update key is incorrectly formed. If , computes and returns it to .(3)Delegation key query. When sends a delegation key query from identity to identity , selects and evaluates and to obtain () and (), computes , and returns it to . Note that when , this delegation key is correctly formed; when , this delegation key is incorrectly formed.(4)Challenge phase. At the end of phase 1, submits challenge identity and two same length message to who will evaluate and look for tuple from table and return challenge ciphertext to . Note that there are following restrictions on to avoid trivial decryption:(1)The private key corresponding to has not been queried.(2)If a series of update key queries which originate from to , next from to ,…, from to have been issued, the private key of any in set ID = {} has not been queried.(3)If the delegation key query from to has been issued, the private key of has not been queried.(4)If a series of update key queries which originate from to , next from to ,…, from to have been issued and delegation key from any in set ID = {} to has been queried, the private key of has not been queried.(5)Phase 2. issues query as in phase 1 except restrictions as above.(6)Guess. outputs its guess . If any of the following conditions are false, aborts the simulation. Otherwise, if , outputs 1 or 0 otherwise.
4.4.1. Conditions for Abort
(1)When the private key query for is issued, is chosen to be 1.(2)When the private key queries for other except are issued, is chosen to be 0.(3)When the update key queries from to () are issued, if lies along a path leading from , the value for is chosen to be 1. Or does not lie along a path leading from , the value for is chosen to be 0.(4)When the delegation key queries from to () are issued, if lies along a path leading from , the value for is chosen to be 1. Or does not lie along a path leading from , the value for is chosen to be 0.
Claim. If does not abort during the game, then ’s view is identical to the real attack, except reencryption keys of the form . The discussion of this case can refer to [18]. If the input to is a DBDH tuple, then the challenge ciphertext is correct encryption of under and hence (subject to the definition of and the argument above) . When the input to is random, represents the encryption of a random element. Since is unable to distinguish between the simulation and a real attack, it must hold that 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 number is selected to encrypt several files at the same time, while different random number 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 , and is a reencryption key list that contains some reencryption keys corresponding to the delegation. If this set is empty, this means the data are not allowed to be shared with others.
For the sake of analysis, let us assume this scenario: user has three types of files (, , and ), which are encrypted with the identity and stored on the cloud server. The first type of file is some study notes shared with a requester (a common learner with identity ). The second type of file is personal photos that involve some private information and should not be allowed to be accessed by others. The content of the third file 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 files , , and are encrypted with the same random number under the identity . 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 ’s access permission to files and is shown as follows: Step 1: generate a new identity. The user combines well-known information with an attribute (manufacturer/smart meter id: ) of microgrid devices (i.e., smart meter) as a new identity for the third type of file . In the same manner, the user will also combine another attribute as an encryption identity for the second type of file . Both operations are the same, and file 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 key . Step 3: compute a reencryption key for updating ciphertext. The user chooses a random and runs algorithm to generate and then send it to the cloud server. Step 4: update the ciphertext. After receiving the update reencryption key , the proxy uses it to convert the ciphertext to a new ciphertext , which will replace the old ciphertext to store in the cloud server. Note that the proxy does not save this reencryption key. Step 5: the user (data owner) decrypts the updated ciphertext with the new private key . The computation steps are as follows:(1).(2).(3).
Obviously, when the requester requests the data from the cloud server again, the new ciphertext transformed by proxy from the updated ciphertext with old reencryption key cannot be decrypted with the requester’s private key because
So, when the user revokes the delegation for the requester by updating the ciphertext, the proxy will delete the corresponding old reencryption key. And when the requester 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 to . It can now only be accessible to the data owner. However, file is required to be shared with other entities (other prosumers or the utility organization and assume identity is ) in the microgrid. For example, the user needs to reauthorize to energy consumers , and this process is shown as follows: Step 1: generate the reauthorization key. The user (delegator) runs the algorithm to compute a new reencryption key . The calculation process is shown as follows:(1).(2). 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 algorithm to convert the updated ciphertext to a new ciphertext . Then, the ciphertext is sent to the requester (delegatee). Step 3: decrypt the reauthorization ciphertext. After receiving the ciphertext from the proxy, the requester decrypts the ciphertext with the private key to get the plaintext. The decryption process is shown as follows:(1).(2).
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 is ) generates an energy information file and encrypts it with the identity. The ciphertext 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 identity .(2)The user generates a delegation reencryption key and uploads to the proxy and indicates the composition of the delegatee’s identity. Step 3: generate a private key. At the appointed time, the requester applies for the private key corresponding to the identity from PKG. Step 4: generate the delegation ciphertext. The proxy runs the algorithm to transform the ciphertext to the delegation ciphertext . And then the ciphertext is sent to the requester. Step 5: decrypt the delegation ciphertext. The requester decrypts the ciphertext with the private key to get the plaintext. The process is shown as follows:(1).(2).
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.
Table 2 shows some of the characteristics and achieved security notion of the schemes for two functions: update and delegation. Since the reencrypted ciphertext in scheme 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.
The characteristic comparison in Table 2 is important for secure data sharing application, and the definitions are described in Section 2. In most cases, the public-key certificate has an expiration date. In addition, a user’s key (both public and private key) needs to be changed for security consideration. 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. Table 3 compares the functions of some existing representative schemes and the proposed approach. It is observed that the proposed scheme is a comprehensive data sharing solution that supports all the essential features of delegation, delegation revocation, conditional reservation delegation, ciphertext update, and reauthorization required for secure cloud data sharing.
In Table 4, the computational cost of each phase is shown. For the sake of illustration, Setup, KeyGen, and Encrypt denote the setup algorithm, key generation algorithm, and encryption algorithm, respectively. 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. denotes the pairing computation time. denotes the time of the random computation. denotes the calculation time of group element multiplication or division operations (the inverse computation is seen as division operation). denotes the computation time of a group element power operation. In these calculations, the selection of random values, multiplication, division, and inverse takes tens of microseconds; exponentiation takes several milliseconds and pairing takes between 10 and 20 milliseconds.
Table 5 and Figure 4 show the computation time of each phase of the five schemes. For the convenience of calculation, the hash calculation in all algorithms is not considered. 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.
In Table 5, the setup time (the length of the user’s identity is 50 bits) of the LLWS scheme is larger than other systems because it is a waters-based architecture and often needs to generate more system parameters. Since the time of hash computation in KeyGen algorithm is not included, the computation time of this phase in the LLWS scheme is less than the BF architecture. For the purposes of simplifying comparison, the calculation times of the Setup phase and KeyGen phase are omitted. And it is shown that the computation time of LLWS is the longest, while SHB is the shortest. 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.
Figure 5 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.
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.
Data Availability
The simulation codes based on PBC used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This research was partially supported by the National Natural Science Foundation of China (Project no. 61662039), and it was supported by Institute for Information & Communications Technology Promotion (IITP) grant funded by the Korea government (MSIT) (Project no. 2018-0-00508) and in part by KETEP, Korean Government, Ministry of Trade, Industry, and Energy (MOTIE) (Project no. 20194010201800).