Abstract
Broadcast proxy reencryption (BPRE), which combines broadcast encryption (BE) and proxy reencryption (PRE), is a technology used for the redistribution of data uploaded on the cloud to multiple users. BPRE reencrypts data encrypted by the distributor and then uploads it to the cloud into a ciphertext that at a later stage targets multiple recipients. As a result of this, flexible data sharing is possible for multiple recipients. However, various inefficiencies and vulnerabilities of the BE, such as the recipient anonymity problem and the key escrow problem, also creep into BPRE. Our aim in this study was to address this problem of the existing BPRE technology. The partial key verification problem that appeared in the process of solving the key escrow problem was solved, and the computational efficiency was improved by not using bilinear pairing, which requires a lot of computation time.
1. Introduction
The cloud technology allows users to access a range of services anytime, anywhere. Depending on the requirement of users, the cloud provides a range of services, including software-as-a-service (SaaS), platform-as-a-service (PaaS), and infrastructure-as-a-service (IaaS). Recently, it has become easier to use the cloud owing to the rapid development of communication and computing technology, and consequently, the cloud has been introduced and used in various domains and environments.
In general, the cloud technology is recognized as a remote storage environment or as a software that can be used without the need for installing it on a local device. Microsoft’s Office 365 products or Adobe’s CC product line can be seen as cloud-based software, and Google Drive and Microsoft’s One Drive are representative examples of cloud-based remote storage. These products, running on the Internet, provide functions that local storage fails to provide and can be easily used anytime, anywhere. However, the cloud is not limited to the range of services described above. Its scope has expanded into more diverse and extensive areas and domains in recent times.
Cloud technology requires an Internet connection to work. In other words, the cloud is an online technology. As a result of this, the working environment of the cloud can be shared online at any given time. For example, the cloud in an enterprise environment is not just for each employee to store their own data. It can also be used by employees as an efficient tool to share their work with each other. In light of this, there is an increasingly urgent need for technologies that can store and share data through such a cloud [1, 2].
The cloud essentially is a proxy server, that is, it is a remote server that can be accessed and used via a network. However, the proxy server responds to the request but it is always considered a semitrusted server because it always wants to know its contents. Therefore, for data to be stored safely in the cloud, data encryption is essential. In addition, to further share the data stored in the cloud, the recipient must be able to easily decrypt the encrypted data. Moreover, for the data sender to decrypt the encrypted data, a decryption key is required. However, the two most popular methods for this, symmetric key encryption and asymmetric key encryption, suffer from the key distribution problem. Therefore, proxy reencryption (PRE) has been proposed to securely share data without exposing the data contents and decryption keys to risks during the data sharing process.
PRE reencrypts data encrypted using the sender’s public key in the proxy so that the receiver can decrypt it by using their own private key. As a result, the private keys of the sender and receiver are not exposed to risks during data sharing and the cloud, too, has no access to the contents of the encrypted data. However, because this PRE is based on one-to-one transmission, it is not suitable for environments where the same data are distributed to multiple recipients (for example, environments such as update servers or secure e-mail). In such a scenario, if the existing proxy reencryption is used, reencryption key generation and reencryption must be performed as many times as the number of recipients.
Broadcast proxy reencryption (BPRE) combines broadcast encryption (BE), which enables sending of the same data to multiple recipients by using a single encryption, and PRE. Therefore, BPR can reencrypt encrypted data stored in the cloud and distribute it to multiple recipients, enabling flexible data sharing. However, because BPRE is an encryption method based on BE, it also suffers from some security vulnerabilities that are typical to BE. For example, the lack of receiver anonymity in BE, wherein the identity of a specific receiver in a communication channel gets exposed, leading to serious privacy issues, is also present in BPRE. In addition, the security threat caused by BE’s public key generation method also appears in BPRE.
Typically, there is a key escrow problem that appears in ID-based cryptography (IBC) and the certificateless (CL) cryptography can be applied to solve this problem. In addition, the partial key verification problem of the CL cryptography must also be considered. Finally, existing BPRE schemes were designed using a bilinear pairing operation. However, bilinear pairing operation is a time-consuming process, which increases the computing cost in BPRE. Therefore, the goal of this study is to provide a relatively safe environment for data sharing by solving the security threats presented above, as well as to develop a more efficient BPRE technology by leaving out the bilinear pairing operation.
2. Related Works
This section describes related studies and theoretical constructs for understanding the concepts discussed in the present study.
2.1. Data Sharing
Data sharing refers to the sharing of data owned by the data owner (sender) with other users. Encryption becomes essential when sharing data safely over a network [3–5]. In the absence of encryption, data may be exposed or tampered with by eavesdropping events during the communication process. In addition, to share encrypted data, the receiver must be able to decrypt the data. If the sender encrypts data using the symmetric key method, the symmetric key must be safely delivered to the receiver. This, however, is difficult to achieve. Conversely, when using the asymmetric key (public key) method, the sender and receiver can share data by exchanging only the public key with each other. However, in both of the above two methods, the sender and the receiver must both remain online until the data transmission is completed, which is not possible at times. To solve this problem, a data sharing method using a cloud (proxy) has been proposed: after uploading data to the cloud, the sender can use the method of allowing access to the data stored in the cloud according to the request of the receiver. Encryption is indispensable even when using this method to ensure the contents of the data is not exposed. However, to decrypt data encrypted with the sender’s public key using the receiver’s private key, it is necessary to encrypt the data with the receiver’s public key after decryption in the cloud; however, during this process, the data are inevitably exposed to the cloud. Therefore, PRE has been proposed to ensure that the private key or the contents of the data are not exposed while sharing data through the cloud.
2.2. Proxy Reencryption
PRE delegates decryption authority to other users by reencrypting data through a proxy represented by the cloud. As shown in Figure 1, the sender encrypts data with his/her public key, uploads it to the cloud, and generates a reencryption key at the request of the receiver and sends it to the cloud. Upon receiving the ciphertext and the reencryption key, the cloud reencrypts the ciphertext to generate a reencrypted ciphertext and transmits it to the receiver. PRE was first introduced in 1998 by Blaze et al. [6]. Since then, a number of traditional public key cryptography (PKC) PREs have been proposed [7–17, 18]. Such a PRE requires a public key certificate to prove the validity of the public key. However, the generation and storage of public key certificates involve considerable overhead. To address this, several ID-based PRE (IBPRE) methods [19] have been proposed [14, 20, 21]. However, the key generation center (KGC) generates the full private key of each user in IBPRE, which gives rise to the key escrow problem. To solve the key escrow problem, certificateless PRE (CL-PRE) has been proposed [22–24, 25]. In CL-PRE, the KGC does not generate the user’s full private key but generates a partial key and delivers it to the user. As a result, the KGC cannot know the user’s private key.
2.3. Broadcast Proxy Reencryption
Broadcast encryption (BE) is a technique first introduced by Berkovits [26]. BE is an access control technology designed to securely transmit data such as digital media, notifications or messages, and distance education to multiple recipients. BE can be divided into a symmetric broadcast encryption method and an asymmetric broadcast encryption method according to an encryption method. The symmetric broadcast encryption method is a method of delivering data to multiple receivers using a symmetric key method. Representative examples include Berkovits’ scheme [26], Naor et al.’s scheme [27], and Halevy and Shamir’s scheme [28]. This symmetric broadcast encryption method makes it difficult to distribute and manage keys.
On the other hand, asymmetric broadcast encryption is a method of delivering data to multiple recipients using a public key method. Therefore, the roles of encryption and decryption can be distinguished by utilizing the easy key distribution and management, which are the advantages of the existing public key encryption method. Asymmetric broadcast encryption was first proposed by Dodis and Fazio [29] in 2002. However, this scheme has the disadvantage that the size of the encryption key is too large. In [30], Delerablée et al. proposed a scheme to perform BE using a dynamic method to target unpredictable users. Since then, BE schemes such as [31–34, 35] have been proposed.
Meanwhile, with the development of communication and storage technologies, the movement to utilize cloud storage has gradually increased. Also, a method for sharing data stored in cloud storage to other users was required. However, in order to make the encrypted data stored in the cloud available to other users, it is difficult to reencrypt after decryption or to deliver the decryption key. These problems increase the network load and reduce the efficiency. Therefore, PRE was proposed to solve this problem and research was conducted to deliver data to multiple recipients using cloud storage by combining this PRE with BE.
Chu et al. first proposed CPBRE by combining conditional proxy reencryption with BE [36]. Since then, various broadcast proxy reencryption (BPRE) has been proposed as shown in Figure 2. BPRE, proposed by Wang et al. in 2009, provides recipient anonymity. Also, data distribution is controlled by the KGC or broadcast center (BC). However, it requires a high computational overhead by using bilinear pairing and a key escrow problem also appears. Various methods of research were also conducted in the relatively recently proposed studies of Maiti and Misra [37], Sun et al. [38], Yin et al. [39], and Chunpeng et al. [40]. However, both of these methods use bilinear pairing and incur high computational overhead. In addition, there is a problem that the key escrow problem occurs.
3. Preliminaries
This section describes the basic environment and settings used to understand the scheme proposed in this study. To this end, the system model, security requirements, and algorithm used in the proposed scheme are explained.
3.1. System Model
The system model used in this study, shown in Figure 3, comprises a sender, receiver, cloud (proxy), and the KGC. (i)Sender: the sender is the owner of the data and the user with whom the data are shared. The sender encrypts the plaintext with his/her public key and uploads it to the cloud. Then, to distribute the data, a reencryption key is generated and transmitted to the cloud. The sender can also download the data that he/she uploaded to the cloud and decrypt it with his/her private key to obtain the plaintext(ii)Receiver: the receiver receives sender’s data. The receiver may receive the reencrypted ciphertext from the cloud and decrypt the data with his/her private key to obtain the plaintext(iii)Cloud (proxy): the cloud is assumed to be the same object as the remote proxy server. Because the cloud is a semitrusted server, it comes with a danger of data leakage. Therefore, the sender must apply data encryption to safely store data in the cloud. In addition, during data sharing, the plaintext or the user’s private key should not be exposed to the cloud. Finally, users with legitimate rights should be able to access and use data in the cloud at any time(iv)Key generation center (KGC): the KGC is an object that generates and issues a user key. Although the KGC is involved in generating each user’s private key, in this study, to solve the key escrow problem, the KGC does not generate the user’s full private key but generates a partial key and delivers it to each user. In addition, all users must use the public parameters created by the KGC to perform data encryption, decryption, and reencryption.
3.2. Security Requirements
This study consists of seven security requirements. The details are as follows: (i)Confidentiality: the data that are kept in the proxy and the data delivered through the proxy shall not be unknown other than the authorized user. To do this, the data must be encrypted using the encryption key and the user who does not have a legitimacy decryption key should not be able to decrypt the contents(ii)Integrity: data uploaded and shared by the sender must not be changed without permission in the process of being delivered to the cloud and the receiver and stored in the cloud. If at all the contents are changed, the sender or receiver who shares the data must be made aware of the change(iii)Key escrow problem: all users who want to use the cloud must communicate with the KGC to generate a private key and public key pair. In this process, the KGC generates a user’s full private key and the KGC may arise the user’s authority. This problem is called a key escrow problem, and a method for solving this problem is required(iv)Partial key verifiability: to solve the previously described key escrow problem, a key generation method in the form of a partial key can be used. In this case, each user must be able to verify whether the partial key generated and issued by the KGC to each user is legitimately generated by the correct KGC(v)Receiver anonymity: the reencrypted ciphertext in cloud storage can be decrypted by a number of designated receivers. For this purpose, the reencryption key and reencrypted ciphertext include information generated by the public key of each receiver. However, privacy issues arise when such information allows a particular recipient or third party to identify another receiver(vi)Decryption fairness: each legitimate receiver designated by the sender can decrypt the reencrypted ciphertext. However, in this process, a specific receiver should not be discriminated against or disadvantaged in the decryption process by a specific receiver or a third party
3.3. Algorithms
A total of 10 algorithms were used in the scheme proposed in this study. The purpose and details of each algorithm are as follows. (i)Setup : this algorithm is performed by the KGC, which generates KGC’s master secret key and master public key for each user to use the cloud and publishes the (ii)Set-secret-value : this algorithm is performed by the user, wherein user generates using randomly selected and and sends it to the KGC along with (iii)Partial-key-extract : this algorithm is performed by the KGC, which generates partial keys of user using and transmitted by user and its own and and delivers it to user (iv)Set-private-key : this algorithm is performed by the user, wherein user generates his/her own private key using the partial keys received from the KGC. The generated private key was kept secure(v)Set-public-key : this algorithm is performed by the user, wherein user generates his/her public key using the partial key received from the KGC and the secret value generated by the user. The generated public key is made public so that anyone can use it(vi)Enc : this algorithm is performed by the sender, wherein sender encrypts his/her data using public key to obtain ciphertext and uploads it to the cloud(vii)Re-key-gen : this algorithm is performed by the sender, wherein sender specifies a receiver set of receivers to share their data with, generates a reencryption key for , and delivers it to the cloud(viii)Re-enc : this algorithm is performed by the cloud, wherein the cloud reencrypts ciphertext of sender using reencryption key of sender to obtain reencrypted ciphertext (ix)Dec-1 : this algorithm is performed by the sender, wherein sender downloads his/her ciphertext stored in the cloud and then uses his/her private key to decrypt it to obtain plaintext (x)Dec-2 : this algorithm is performed by the receiver, wherein receiver downloads ciphertext stored in the cloud and then uses his/her private key to decrypt it to obtain plaintext
4. Proposed CL Broadcast Proxy Reencryption
This section describes the scheme proposed in this study. For this, a technical overview, system parameters, and algorithm construction are described.
4.1. Technical Overview
The basic model of BRE, shown in Figure 4, can be broadly divided into four phases: a setup phase, key generation phase, data storage phase, and data broadcast phase. More details about these phases are presented in Sections 4.2 and 4.3.
4.2. System Parameters
The following are the system parameters used in this proposed scheme. (i): participants (KGC, sender , receiver set , receiver , and user )(ii): -bit prime integer(iii): elliptic curve(iv): finite field for (v): security parameter(vi): length of message space (determined by the )(vii): random generator in ()(viii): additive group on elliptic curve (ix): subgroup of with prime order (x): identity of participant ()(xi): KGC’s system master secret key(xii): KGC’s system master public key(xiii): user ’s full private key(xiv): user ’s full public key(xv): reencryption key (sender delegates to receiver set )(xvi): message space(xvii): plaintext (message) (xviii): ciphertext(xix): reencrypted ciphertext(xx) one-way hash function (xxi) one-way hash function (xxii) one-way hash function (xxiii) one-way hash function (xxiv) one-way hash function (xxv) one-way hash function (xxvi) one-way hash function
4.3. Construction
The overall structure of this proposed scheme is shown in Figure 4. This scheme is mainly composed of four phases, each of which is composed of the setup phase, key generation phase, data storage phase, and data broadcast phase. A detailed description of each phase proceeds in each phase.
4.3.1. Setup Phase
This phase includes the setup algorithm. This phase is performed by the KGC in advance so that each user can use the cloud. Here, a master public key that can be commonly used by each user and a master secret key known only to the KGC are generated. (i)Setup : this algorithm is an algorithm performed by the KGC. With the security parameter as input, the KGC performs the following process (1)Choose two -bit prime integers and an elliptic curve defined on . Let be the additive group on elliptic curve and be the subgroup of with prime order (2)Select randomly a generator (3)Randomly choose as the and calculate which is part of (4)Select five secure one-way hash functions are follows:where and mean the length of the bit string and is determined by the security parameter (5)Publish the system’s maser public key and message space
4.3.2. Key Generation Phase
This phase includes set-secret-value, partial-key-extract, set-private-key, and set-public-key algorithms. In this phase, each user generates their own private key and public key pair so that they can use the cloud. In this phase, each user communicates with the KGC to receive a partial key and uses the partial key to generate their own public key and private key pair as shown in Figure 5. (i)Set-secret-value: this algorithm is an algorithm performed by user . A user randomly selects and keeps it secure. User computes as the public key, and user sends to the KGC(ii)Partial-key-extract: this algorithm is an algorithm performed by the KGC. According to the identity of user , the KGC performs the following steps: (1)Randomly select and compute (2)Calculate a part of the partial private key as follows:(3)After that, partial key is delivered to user through the public channel(iii)Set-private-key: this algorithm is an algorithm performed by user . After receiving partial key from the KGC, user verifies these like equations (3) and (4). If verification passes, user is compute private key as the following steps:(1)Verify whether the following equation holds:(2)If not, return ; otherwise, user computes as follows:(3)After that, user keeps secret as his/her the full private key(iv)Set-public-key: this algorithm is an algorithm performed by user . User keeps as the full public key
4.3.3. Data Storing Phase
This phase includes the Enc and Dec-1 algorithms. This phase represents the process of the sender encrypting his/her data with his/her public key and storing it in the cloud. In addition, the sender downloads his/her own data stored in the cloud and a decryption process is also included using the private key to obtain the data source again as shown in Figure 6. (i)Enc: this algorithm is an algorithm performed by the sender . Sender encrypts message with ciphertext by entering his/her public key and message . Then, upload the ciphertext to the cloud(1)Compute , , and using the given message and (2)Then, sender calculates using and (3)Sender calculates , and as follows:(4)Generate ciphertext . Then, the generated is uploaded and stored to the cloud(ii)Dec-1: this algorithm is an algorithm performed by the sender . The sender can download the ciphertext from cloud. The sender who has downloaded the ciphertext can obtain the plaintext by decrypting the ciphertext with his/her private key (4)Sender calculates using its private key and the given ciphertext (5)Calculate and by inputting and (6)Calculate by inputting where (7)Verify whether the following equation holds. If not, return ; otherwise, sender keeps plaintext where and
4.3.4. Data Broadcast Phase
This phase includes re-key-gen, re-enc, and dec-2 algorithms. In this phase, the sender generates a reencryption key for a set of recipients and passes it to the proxy. After receiving the reencryption key, the proxy reencrypts the encrypted data and broadcasts it to the recipients. The receiver who has received the broadcast ciphertext can obtain the message by decrypting the ciphertext with their private key as shown in Figure 7. (i)Re-key-gen: this algorithm is executed by sender to delegate a ciphertext to set of recipients of selected receiver with identity . The following steps will be performed in this algorithm(1)Compute , where .(2)Compute a polynomial with degree using as follows:where, (3)Compute using , and as follows:(4)Sender generates reencryption key and sends to cloud(ii)Re-Enc: this algorithm is executed by cloud. This algorithm reencrypts ciphertext to ciphertext using reencryption key . The following steps will be performed in this algorithm (1)Compute using ciphertext and reencryption key (2)Output and send to receivers (iii)Dec-2: this algorithm is executed by the selected receiver to extract the plaintext from the received ciphertext . Receiver performs following steps: (1)Compute (2)Generate polynomial and compute (3)Compute as input and (4)Compute as input where (5)Verify message . If not, return ; otherwise, receiver outputs the plaintext where and
4.4. Correctness
In this section, we will prove the correctness of the scheme proposed in Section 4. First, Theorem 1 describes in detail the execution process of the set-private-key algorithm, which is a process in which the user verifies whether the partial key received from the KGC is a correct value. Second, Theorem 2 describes in detail the execution process of the Dec-1 algorithm, which is an algorithm for the sender to decrypt his/her data. Finally, Theorem 2 describes in detail the execution process of the Dec-2 algorithm, which is an algorithm for the receiver to decrypt the reencrypted data.
Theorem 1. User can verify whether the partial key received from the KGC is a value generated from the created by him/her and the of the correct KGC. This process corresponds to equations (2)–(4).
Proof. Assuming that one of the users is , can perform the following process using received from the KGC and its own value and KGC’s master public key .☐
can verify whether the received partial key is correct by using the and . This process corresponds to equation (3). where
Theorem 2. The sender can perform decryption using the ciphertext received from the cloud and his/her private key and obtain the plaintext . This process corresponds to equations (8)–(13).
Proof. Assuming that one of the senders is , can perform the following process using received from the sender and its own private key .☐
creates as follows using his/her private key . This process corresponds to equations (8) and (9).
obtains using the generated equations (9) and (10) as follows:
can obtain as follows using , and the acquired in equation (11). where and .
Theorem 3. The receivers can perform decryption using the reencrypted ciphertext received from the cloud and his/her private key and obtain the plaintext . This process corresponds to equations (18)–(29).
Proof. Assuming that one of the receivers is , can perform the following process using received from the sender and its own private key .☐
creates as follows using his/her private key . This process corresponds to equations (18) and (22).
obtains using the generated equations (23)–(25) as follows:
can obtain using , and the acquired in equation (27). where and .
5. Analysis of the Proposed CL-BPRE Scheme
In this section, we analyze the efficiency of the proposed scheme and explain how to achieve data security. In addition, the advantages of the proposed scheme are explained through a comparison with previous studies.
5.1. Analysis of Security Requirements
We analyze whether the proposed scheme is successful in achieving the security requirements presented in Section 3.2. There are a total of 7 security requirements, each of which is confidentiality, integrity, key escrow problem, partial key verifiability, receiver anonymity, and decryption fairness as shown in Table 1. (i)Confidentiality: in the proposed scheme, an ECC-based encryption operation is performed to provide data confidentiality. In this process, the message itself is not encrypted with the public key of each recipient but a session key is created to encrypt the message. Therefore, to decrypt a message, a session key must be obtained, and to obtain a session key, only a legitimate recipient must carry out the computation
Here, is and is . Therefore, each recipient must have its own private key to generate and the user who generates can obtain the through the following process:
can obtain the through the following process:
If an attacker attempts to create with only the public key of the recipient , cannot be generated normally, as follows:
According to the above formula, because the attacker does not know , it is impossible to forge . (ii)Integrity: recipients who have decrypted the data can verify the integrity of the data using the values contained in the integrity ciphertext and the parameters of the public KGC, as in Theorem 3 of Section 4.4. The proof of this is as follows:where and .
The receiver that decrypts ciphertext can obtain message and verification value . Here, is equal to , and thus, the integrity of the message can be verified by comparing whether is equal to . (iii)Key escrow problem: the proposed scheme uses a certificateless PKC method that has been demonstrated to be successful in solving the key escrow problem. To solve the key escrow problem, the KGC must not know the user’s complete private key. In the existing IBC, in the private-key-gen algorithm, the KGC generates a user’s complete private key and delivers it to each user. The key escrow problem is by dividing the key generation process into four algorithms: set-secret value, partial-key-extract, set-private-key, and set-public-key
First, the set-secret-value algorithm generates using secret value , randomly selected by the user, and the master public key value of the KGC. At this time, is safely stored only by the user and and are delivered to the KGC through an open channel.
In the partial-key-extract algorithm, using the and received by the KGC from the user, partial keys and are generated through the following process and delivered to the user.
In the set-private-key algorithm, the private key is calculated using the and received by the user from the KGC. At this time, the user does not use as the private key, but uses , which only the user knows, and , which is generated based on the received from the KGC, as the private key.
Finally, in the set-public-key algorithm, generated by the user and generated by the KGC are used as public keys.
As a result, the KGC must know to obtain the user’s private key . However, because is a secret value stored safely by the user, the key escrow problem by the KGC does not occur.
The KGC only knows and and the KGC cannot know (iv)Partial key verifiability: the proposed scheme is designed to satisfy several security requirements. In this process, there was an increase in the amount of computationwhere,
Through the above calculation, user can know that the partial key that it has received is based on secret value generated by user and that it is generated by a legitimate KGC (v)Receiver anonymity: in the proposed scheme, a Lagrange interpolation polynomial is applied to provide the recipient’s anonymity. In this method, the information of the user included in the polynomial cannot be obtained because the recipient is only confirmed by a polynomial. The formula for this polynomial is as follows:
To identify a specific recipient in the above polynomial, it is possible to generate of the specific receiver. However, as in the confidentiality item above, an attacker cannot forge .
As a result, the attacker cannot identify the recipient. (vi)Decryption fairness: in the decoding process of the recipient data included in the recipient list, the decoding should not be disadvantageous because of the intervention of a third party or the KGC. To this end, in the proposed scheme, it is not possible to change the list of recipients by configuring a polynomial or adding an amount of computation by designating only specific recipients. This takes advantage of the property of the following polynomial, and in order for an attacker to make a specific recipient disadvantageous, he/she must be able to completely forge , a polynomial that targets all receivers.
5.2. Comparison of Schemes
(i)Security requirements: the proposed scheme of this study was designed to satisfy various requirements that the existing schemes do not provide. Wang and Yang [41] and Maiti and Misra [37], and Sun et al. [38] proposed IBC-based BPRE. Since these two schemes operate in the IBC method, the KGC generates and issues the user’s private key. Since these two schemes operate in the IBC method, the KGC generates and issues the user’s private key. Sur et al. generated the user’s private key through the algorithm as follows:where master secret key and random value
According to the above formula, each user’s private key can be generated only by the KGC that owns the master secret key and a complete private key is generated, which may cause a key escrow problem. Maiti et al. also generated the user’s private key in the KG algorithm. In this process, the KGC generates a complete private key through the following operation, which may cause a key escrow problem. where the system secret key is .
Sun et al. also generated the user’s private key in the keygen algorithm as follows. where system secret key .
This also causes Sun et al. key escrow problems. In addition, both Wang et al. and Maiti et al., Sun et al., Yin et al., and Chunpeng et al. use a pairing operation, which takes a lot of computation time. Yin et al. and Chunpeng et al. all proposed certificateless BPRE. However, since all three methods use a pairing operation, a lot of computation time is required. Additionally, Yin et al. pose a threat of privacy invasion because the anonymity of the recipient is not guaranteed. where
Therefore, the proposed scheme uses the CL method and does not use the pairing operation, so that the BPRE can be performed in less time. In addition, it is possible to use BPRE more safely and efficiently by solving the problem of key escrow and recipient anonymity. (ii)Computational efficiency: the proposed scheme of this study was designed with a lower number of calculations compared to the existing schemes as shown in Table 2. Since the pairing operation is not basically used, BPRE can be performed with less computation time compared to the existing methods. In addition, it has a lower number of operations by simplifying encryption and decryption operations. However, the number of operations for generating the reencryption key has increased. Therefore, some computational efficiency may be lowered in an environment where the list of recipients is constantly changing. However, since the amount of data encryption and decryption operations is low, the burden on the user terminal can be reduced. The computation time chart is shown in Figure 8.
6. Conclusion
Data sharing using the cloud is related to data confidentiality and key management issues. First, the cloud is a semitrusted environment and data can be exposed at any time by an insider or external attack. Therefore, in order to solve this problem, the application of encryption is essential. However, in order to share encrypted data with other users, it is essential to distribute a key that can decrypt the data. However, in a data storage and sharing environment using the cloud, it is very difficult to distribute the key because the key cannot be delivered face to face. To solve this problem, proxy reencryption has been proposed that allows data being stored encrypted in the cloud to be shared with other users. Proxy reencryption is a technology that reencrypts data that has been encrypted once to data that other users can decrypt without having to decrypt the data and share the private key. However, since the existing proxy reencryption can reencrypt by specifying only one recipient at a time, if the number of recipients increases, the number of reencryption also increases and the number of times to generate a reencryption key for reencryption also increases. Therefore, broadcast proxy reencryption has been proposed to solve this problem. Broadcast proxy reencryption is a combination of broadcast encryption technology and proxy reencryption technology. The broadcast encryption method is effective when distributing the same data to multiple recipients at the same time because multiple recipients can be specified with only one encryption. By combining these features with proxy reencryption, broadcast encryption can be used when data encrypted once is shared with multiple users at the same time. Therefore, it can be applied to various environments such as update servers that distribute data to many recipients at the same time, secure email, and IoT. However, the receiver anonymity, key escrow problem, decryption fairness, partial key verification problem, etc. that appear in the broadcast encryption method also appear in the broadcast proxy reencryption. Therefore, you can safely use broadcast proxy reencryption only after solving these problems. To this end, in this study, in the process of designating a plurality of receivers, the receiver cannot be identified using a polynomial and the receiver is additionally modulated by modulating the polynomial to change the receiver or a specific receiver is designed so that it does not have a disadvantage in decoding. In addition, by not using the pairing operation in this process, the calculation time is reduced and the amount of calculation is simplified, so that data can be broadcast even with a lower operation. In the key generation process, the key escrow problem caused by KGC was solved by using the certificateless method instead of the existing IBC type. As a result, the proposed scheme solves the security threats of the existing schemes and at the same time reduces the amount of computation and the computation time, so that it is possible to provide a more secure and efficient broadcast proxy reencryption.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare no conflict of interest.
Authors’ Contributions
Won-Bin Kim and Su-Hyun Kim contributed equally to this work.
Acknowledgments
This research was supported by Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (NRF-2019R1A2C1085718) and the Soonchunhyang University Research Fund and the BK21 FOUR (Fostering Outstanding Universities for Research) (No. :5199990914048).