# Broadcast Proxy Reencryption Based on Certificateless Public Key Cryptography for Secure Data Sharing

Authors: Won-Bin Kim; Su-Hyun Kim; Daehee Seo; Im-Yeong Lee
Journal: Wireless Communications and Mobile Computing
 (2021)

---

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


---

## Body

## 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 Figure1, 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.Figure 1
Basic form of proxy reencryption.


### 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.Figure 2
Broadcast proxy reencryption.


## 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 Figure1, 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.Figure 1
Basic form of proxy reencryption.


## 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.Figure 2
Broadcast proxy reencryption.


## 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 Figure3, 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.Figure 3
Form of the proposed system model.


### 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λ⟶msk,mpk: this algorithm is performed by the KGC, which generates KGC’s master secret key msk and master public key mpk for each user to use the cloud and publishes the mpk(ii)
Set-secret-valuempk⟶Ti,IDi: this algorithm is performed by the user, wherein user i generates Ti using randomly selected ti and mpk and sends it to the KGC along with IDi(iii)
Partial-key-extractTi,IDi,msk,mpk⟶Ri,ki: this algorithm is performed by the KGC, which generates partial keys Ri,ki of user i using Ti and IDi transmitted by user i and its own msk and mpk and delivers it to user i(iv)
Set-private-keyti,Ri,ki,mpk⟶ski: this algorithm is performed by the user, wherein user i generates his/her own private key ski using the partial keys Ri,ki received from the KGC. The generated private key ski was kept secure(v)
Set-public-keyti,Ri,mpk⟶pki: this algorithm is performed by the user, wherein user i generates his/her public key pki using the partial key Ri,ki received from the KGC and the secret value ti generated by the user. The generated public key pki is made public so that anyone can use it(vi)
EncpkS,IDS,m,mpk⟶CT: this algorithm is performed by the sender, wherein sender S encrypts his/her data m∈M using public key pkS to obtain ciphertext CT and uploads it to the cloud(vii)
Re-key-genskS,pkℝ,IDS,IDℝ,mpk⟶rkS⟶ℝ: this algorithm is performed by the sender, wherein sender S specifies a receiver set ℝ=r1,r2,⋯,rn of receivers rj1≤j≤n to share their data with, generates a reencryption key for ℝ, and delivers it to the cloud(viii)
Re-encCT,rkS⟶ℝ,mpk⟶CTR: this algorithm is performed by the cloud, wherein the cloud reencrypts ciphertext CT of sender S using reencryption key rkS⟶ℝ of sender S to obtain reencrypted ciphertext CTR(ix)
Dec-1CT,skS,IDS,mpk⟶m: this algorithm is performed by the sender, wherein sender S downloads his/her ciphertext CT stored in the cloud and then uses his/her private key skS to decrypt it to obtain plaintext m(x)
Dec-2CTR,skj,IDj,mpk⟶m: this algorithm is performed by the receiver, wherein receiver rj downloads ciphertext CTR stored in the cloud and then uses his/her private key skj to decrypt it to obtain plaintext m


## 3.1. System Model

The system model used in this study, shown in Figure3, 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.Figure 3
Form of the proposed system model.


## 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λ⟶msk,mpk: this algorithm is performed by the KGC, which generates KGC’s master secret key msk and master public key mpk for each user to use the cloud and publishes the mpk(ii)
Set-secret-valuempk⟶Ti,IDi: this algorithm is performed by the user, wherein user i generates Ti using randomly selected ti and mpk and sends it to the KGC along with IDi(iii)
Partial-key-extractTi,IDi,msk,mpk⟶Ri,ki: this algorithm is performed by the KGC, which generates partial keys Ri,ki of user i using Ti and IDi transmitted by user i and its own msk and mpk and delivers it to user i(iv)
Set-private-keyti,Ri,ki,mpk⟶ski: this algorithm is performed by the user, wherein user i generates his/her own private key ski using the partial keys Ri,ki received from the KGC. The generated private key ski was kept secure(v)
Set-public-keyti,Ri,mpk⟶pki: this algorithm is performed by the user, wherein user i generates his/her public key pki using the partial key Ri,ki received from the KGC and the secret value ti generated by the user. The generated public key pki is made public so that anyone can use it(vi)
EncpkS,IDS,m,mpk⟶CT: this algorithm is performed by the sender, wherein sender S encrypts his/her data m∈M using public key pkS to obtain ciphertext CT and uploads it to the cloud(vii)
Re-key-genskS,pkℝ,IDS,IDℝ,mpk⟶rkS⟶ℝ: this algorithm is performed by the sender, wherein sender S specifies a receiver set ℝ=r1,r2,⋯,rn of receivers rj1≤j≤n to share their data with, generates a reencryption key for ℝ, and delivers it to the cloud(viii)
Re-encCT,rkS⟶ℝ,mpk⟶CTR: this algorithm is performed by the cloud, wherein the cloud reencrypts ciphertext CT of sender S using reencryption key rkS⟶ℝ of sender S to obtain reencrypted ciphertext CTR(ix)
Dec-1CT,skS,IDS,mpk⟶m: this algorithm is performed by the sender, wherein sender S downloads his/her ciphertext CT stored in the cloud and then uses his/her private key skS to decrypt it to obtain plaintext m(x)
Dec-2CTR,skj,IDj,mpk⟶m: this algorithm is performed by the receiver, wherein receiver rj downloads ciphertext CTR stored in the cloud and then uses his/her private key skj to decrypt it to obtain plaintext m


## 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 Figure4, 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.Figure 4
Overview of the proposed scheme.


### 4.2. System Parameters

The following are the system parameters used in this proposed scheme.(i)
∗: participants (KGC, sender S, receiver set ℝ, receiver rj, and user i)(ii)
p,q: λ-bit prime integer(iii)
E: elliptic curve(iv)
Fq: finite field for q(v)
λ: security parameter(vi)
l1,l2: length of message space (determined by the λ)(vii)
P: random generator in Gq (P∈Gq)(viii)
G: additive group on elliptic curve E(ix)
Gq: subgroup of G with prime order q(x)
ID∗: identity of participant ∗ (ID∗∈0,1∗)(xi)
msk: KGC’s system master secret key(xii)
mpk: KGC’s system master public key(xiii)
ski: user i’s full private key(xiv)
pki: user i’s full public key(xv)
rkS⟶ℝ: reencryption key (sender S delegates to receiver set ℝ)(xvi)
M: message space(xvii)
m: plaintext (message) m∈M(xviii)
CT: ciphertext(xix)
CTR: reencrypted ciphertext(xx)
H1: one-way hash function Zq∗⟶Zq∗(xxi)
H2: one-way hash function 0,1l1+l2⟶Zq∗(xxii)
H3: one-way hash function Gq×0,1∗⟶Zq∗(xxiii)
H4: one-way hash function Zq∗×Zq∗⟶0,1l1+l2(xxiv)
H5: one-way hash function Zq∗×0,1∗×0,1∗⟶Zq∗(xxv)
H6: one-way hash function Zq∗⟶0,1l2(xxvi)
H7: one-way hash function Gq×Gq⟶Zq∗


### 4.3. Construction

The overall structure of this proposed scheme is shown in Figure4. 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 thesetup 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λ⟶msk,mpk: 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 p,q and an elliptic curve E defined on Fp. Let G be the additive group on elliptic curve E and Gq be the subgroup of G with prime order q(2)
Select randomly a generatorP∈Gq(3)
Randomly choosed∈Zq∗ as the msk and calculate Ppub=d∙P which is part of mpk(4)
Select five secure one-way hash functions are follows:(1)H1:Zq∗⟶Zq∗,H2:0,1l1+l2⟶Zq∗,H3:Gq×0,1∗⟶Zq∗,H4:Zq∗×Zq∗⟶0,1l1+l2,H5:Zq∗×0,1∗×0,1∗⟶Zq∗,H6:Zq∗⟶0,1l2,H7:Gq×Gq×0,1∗⟶Zq∗,where l1 and l2 mean the length of the bit string and is determined by the security parameter λ(5)
Publish the system’s maser public keympk=p,q,l1,l2,E,G,Gq,P,Ppub,H1,H2,H3,H4,H5,H6,H7 and message space M=0,1l1


#### 4.3.2. Key Generation Phase

This phase includesset-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 i. A user i randomly selects ti∈Zq∗ and keeps it secure. User i computes Ti=ti∙P as the public key, and user i sends Ti,IDi to the KGC(ii)
Partial-key-extract: this algorithm is an algorithm performed by the KGC. According to the identity IDi of user i, the KGC performs the following steps:
(1)
Randomly selectri∈Zq∗ and compute Ri=ri∙P(2)
Calculate a part of the partial private keyki as follows:(2)ki⟵ri+dH3Ri,Ti,IDi+H3dTi,IDimodq(3)
After that, partial keyRi,ki is delivered to user i through the public channel(iii)
Set-private-key: this algorithm is an algorithm performed by user i. After receiving partial key Ri,ki from the KGC, user i verifies these like equations (3) and (4). If verification passes, user i is compute private key ski=si,ti as the following steps:(1)
Verify whether the following equation holds:(3)ki∙P=?Ri+H7Ri,Ti,IDiPPub+H3tiPPub,IDiP(2)
If not, return⊥; otherwise, user i computes si as follows:(4)si⟵ki−H3tiPPub,IDi(3)
After that, useri keeps secret ski=si,ti as his/her the full private key(iv)
Set-public-key: this algorithm is an algorithm performed by user i. User i keeps pki=Ri,Ti as the full public keyFigure 5
Key generation phase.


#### 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 Figure6.
(i)
Enc: this algorithm is an algorithm performed by the sender S. Sender S encrypts message m with ciphertext CT by entering his/her public key pkS=RS,TS and message m∈M. Then, upload the ciphertext CT to the cloud(1)
Computew, z, and Z using the given message m∈M and pkS=RS,TS(5)w⟵H7RS,TS,IDS,z⟵H2mw,Z⟵zP(2)
Then, senderS calculates US using z and pkS=RS,TS(6)US⟵z∙RS+H7RS,TS,IDSPpub+TS(3)
SenderS calculates α,θ, and C as follows:(7)α⟵H1sS·tS,θ⟵H1US·α,C⟵H4Z,θ⊕mw(4)
Generate ciphertextCT⟵C1,C2=Z,C. Then, the generated CT is uploaded and stored to the cloud(ii)
Dec-1: this algorithm is an algorithm performed by the sender S. The sender S can download the ciphertext CT=C1,C2=Z,C from cloud. The sender S who has downloaded the ciphertext CT can obtain the plaintext m by decrypting the ciphertext CT with his/her private key skS=sS,tS(4)
SenderS calculates US′ using its private key skS=sS,tS and the given ciphertext CT=C1,C2,C3(8)US′⟵sS+tS∙C1(5)
Calculateα and θ′ by inputting skS and US′(9)α⟵H1sS·tS,(10)θ′⟵H1US′·α(6)
Calculatem by inputting C1,C2,θ′(11)mw⟵C2⊕H4C1,θ′,(12)∵C2⊕H4C1,θ′=H4Z,θ⊕mw⊕H4C1,θ′=H4Z,θ⊕mw⊕H4Z,θ′=mw,where C1=Z(7)
Verify whether the following equation holds. If not, return⊥; otherwise, sender S keeps plaintext m(13)C1=?H2mH7RS,TS,IDSP,(14)∵C1=H2mH7RS,TS,IDSP=H2mwP=zP=Z,where Z=zP and z=H2mwFigure 6
Data storing phase.


#### 4.3.4. Data Broadcast Phase

This phase includesre-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 S to delegate a ciphertext to set of recipients ℝ=r1,r2,⋯,rn of selected receiver rj with identity IDj1≤j≤n. The following steps will be performed in this algorithm(1)
ComputeUj, where j=1,2,⋯,n.(15)Uj⟵z∙Rj+H7Rj,Tj,IDjPpub+Tj(2)
Compute a polynomialfx with degree n using β∈Zq∗ as follows:(16)fx=∏i=0nx−Uj+βmodq=xn+an−1xn−1+⋯+a1x+a0,where, ai∈Zp∗i=0,1,⋯,n−1(3)
Computex using skS, α, and β−1 as follows:(17)x⟵sS+tS·α·β−1(4)
SenderS generates reencryption key rkS⟶ℝ=rk1,rk2=x,a0,a1,⋯,an−1 and sends rkS⟶ℝ to cloud(ii)
Re-Enc: this algorithm is executed by cloud. This algorithm reencrypts ciphertext CT to ciphertext CTR using reencryption key rkS⟶ℝ. The following steps will be performed in this algorithm
(1)
ComputeCTR using ciphertext CT and reencryption key rkS⟶ℝ(18)C1′⟵C1,(19)C2′⟵C2,(20)C3′⟵rk1·C1,(21)C4′⟵rk2(2)
OutputCTR=C1′,C2′,C3′,C4′ and send CTR to receivers ℝ(iii)
Dec-2: this algorithm is executed by the selected receiver rj to extract the plaintext from the received ciphertext CTR=C1′,C2′,C3′,C4′. Receiver rj performs following steps:
(1)
ComputeUj(22)Uj′⟵sj+tj∙C1′(2)
Generate polynomialfx and compute β′(23)fx=xn+an−1xn−1+⋯+a1x+a0,(24)β′=fUj′(3)
Computeθ′ as input C3′ and β′(25)θ′=H1C3′·β′,(26)∵C3′·β′=rk1·C1·β′=x·C1·β′=sS+tS·α·β−1·C1·β′=US·α(4)
Computem as input C1′,C2′,θ′(27)m⟵C2′⊕H4C1′,θ′,(28)∵C2′⊕H4C1′,θ′=H4Z,θ⊕m⊕H4C1′,θ′=H4Z,θ⊕m⊕H4Z,θ′=m,where C1′=C1=Z(5)
Verify messagem. If not, return ⊥; otherwise, receiver i outputs the plaintext m(29)C1′=?H2mP,(30)∵C1′=H2mP=zP=Z,where Z=zP and z=H2mFigure 7
Data broadcast phase.


### 4.4. Correctness

In this section, we will prove the correctness of the scheme proposed in Section4. 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.
Useri can verify whether the partial key Ri,ki received from the KGC is a value generated from the Ti,IDi created by him/her and the mpk of the correct KGC. This process corresponds to equations (2)–(4).Proof.
Assuming that one of the users isU1, U1 can perform the following process using R1,k1 received from the KGC and its own value T1,ID1 and KGC’s master public key mpk.☐U1 can verify whether the received partial key Ri,ki is correct by using the Ti,IDi and mpk. This process corresponds to equation (3).
(31)ki∙P=?R1+H7R1,T1,IDiPPub+H1t1PPub,ID1P,∵k1∙P=r1∙P+H7R1,T1,ID1·d·P+H3t1PPub,ID1P=r1+H7R1,T1,ID1·d+H3t1·d·P,ID1P=r1+d·H7R1,T1,ID1+H3T1·d1,ID1P=k1P,where ki=ri+dH7Ri,Ti,IDi+H3dTi,IDi.Theorem 2.
The senderS can perform decryption using the ciphertext CT received from the cloud and his/her private key and obtain the plaintext m. This process corresponds to equations (8)–(13).Proof.
Assuming that one of the senders isS, S can perform the following process using CT=C1,C2,C3,C4 received from the sender and its own private key skS=sS,tS.☐S creates US′ as follows using his/her private key skS=sS,tS. This process corresponds to equations (8) and (9).
(32)US′⟵sS+tS∙Z,US=z∙RS+H7RS,TS,IDSPpub+TS=z∙rSP+H7RS,TS,IDSdP+tSP=z∙rS+H7RS,TS,IDSd+tSP=rS+dH7RS,TS,IDS+tSZ=rS+dH7RS,TS,IDS+H3dTS,IDS−H3dTS,IDS+tSZ=kS−H7tSPPub,IDS+tSZ=sS+tSZ=sS+tSC1=US′.S obtains θ′ using the generated equations (9) and (10) as follows:
(33)α⟵H1sS·tS,θ′⟵H1US′·α.S can obtain m as follows using C1, C2 and the acquired θ′ in equation (11).
(34)m∥w⟵C2⊕H4C1,θ′,∵C2⊕H4C1,θ′=C⊕H4Z,θ′=H4Z,θ⊕mw⊕H4Z,θ′=mw,where CT=C1,C2=Z,C and C=H4Z,θ⊕mw.Theorem 3.
The receiversℝ can perform decryption using the reencrypted ciphertext CTR received from the cloud and his/her private key and obtain the plaintext m. This process corresponds to equations (18)–(29).Proof.
Assuming that one of the receivers isr1, r1 can perform the following process using CTR=C1′,C2′,C3′,C4′ received from the sender and its own private key skr1=sr1,tr1.☐r1 creates Ur1 as follows using his/her private key skR=sR,tR. This process corresponds to equations (18) and (22).
(35)Ur1′⟵sr1+tr1∙Z,Ur1=z∙Rr1+H7Rr1,Tr1,IDr1Ppub+Tr1=z∙rr1P+H7Rr1,Tr1,IDr1dP+tr1P=z∙rr1+H7Rr1,Tr1,IDr1d+tr1P=rr1+dH7Rr1,Tr1,IDr1+tr1Z=rr1+dH7Rr1,Tr1,Ir1+H3dTr1,IDr1−H3dTr1,IDr1+tr1Z=kr1−H7tr1PPub,IDr1+tr1Z=sr1+tr1Z=sr1+tr1C1=Ur1′.r1 obtains θ′ using the generated equations (23)–(25) as follows:
(36)β′⟵fUr1=∏i=0nUr1−Ui+βmodq=Ur1−Ur1∙Ur1−Ur2⋯Ur1−Uri+βmodq=0∙Ur1−Ur2⋯Ur1−Uri+βmodq.r1 can obtain m using C1′, C2′ and the acquired θ′ in equation (27).
(37)mw⟵C2′⊕H4C1′,θ′,∵C2′⊕H4C1′,θ′=C⊕H4Z,θ′=H4Z,θ⊕m∥w⊕H4Z,θ′=mw,where CTR=C1′,C2′,C3′,C4′=Z,C,x·Z,rk2 and C=H4Z,θ⊕mw.


## 4.1. Technical Overview

The basic model of BRE, shown in Figure4, 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.Figure 4
Overview of the proposed scheme.


## 4.2. System Parameters

The following are the system parameters used in this proposed scheme.(i)
∗: participants (KGC, sender S, receiver set ℝ, receiver rj, and user i)(ii)
p,q: λ-bit prime integer(iii)
E: elliptic curve(iv)
Fq: finite field for q(v)
λ: security parameter(vi)
l1,l2: length of message space (determined by the λ)(vii)
P: random generator in Gq (P∈Gq)(viii)
G: additive group on elliptic curve E(ix)
Gq: subgroup of G with prime order q(x)
ID∗: identity of participant ∗ (ID∗∈0,1∗)(xi)
msk: KGC’s system master secret key(xii)
mpk: KGC’s system master public key(xiii)
ski: user i’s full private key(xiv)
pki: user i’s full public key(xv)
rkS⟶ℝ: reencryption key (sender S delegates to receiver set ℝ)(xvi)
M: message space(xvii)
m: plaintext (message) m∈M(xviii)
CT: ciphertext(xix)
CTR: reencrypted ciphertext(xx)
H1: one-way hash function Zq∗⟶Zq∗(xxi)
H2: one-way hash function 0,1l1+l2⟶Zq∗(xxii)
H3: one-way hash function Gq×0,1∗⟶Zq∗(xxiii)
H4: one-way hash function Zq∗×Zq∗⟶0,1l1+l2(xxiv)
H5: one-way hash function Zq∗×0,1∗×0,1∗⟶Zq∗(xxv)
H6: one-way hash function Zq∗⟶0,1l2(xxvi)
H7: one-way hash function Gq×Gq⟶Zq∗


## 4.3. Construction

The overall structure of this proposed scheme is shown in Figure4. 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 thesetup 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λ⟶msk,mpk: 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 p,q and an elliptic curve E defined on Fp. Let G be the additive group on elliptic curve E and Gq be the subgroup of G with prime order q(2)
Select randomly a generatorP∈Gq(3)
Randomly choosed∈Zq∗ as the msk and calculate Ppub=d∙P which is part of mpk(4)
Select five secure one-way hash functions are follows:(1)H1:Zq∗⟶Zq∗,H2:0,1l1+l2⟶Zq∗,H3:Gq×0,1∗⟶Zq∗,H4:Zq∗×Zq∗⟶0,1l1+l2,H5:Zq∗×0,1∗×0,1∗⟶Zq∗,H6:Zq∗⟶0,1l2,H7:Gq×Gq×0,1∗⟶Zq∗,where l1 and l2 mean the length of the bit string and is determined by the security parameter λ(5)
Publish the system’s maser public keympk=p,q,l1,l2,E,G,Gq,P,Ppub,H1,H2,H3,H4,H5,H6,H7 and message space M=0,1l1


### 4.3.2. Key Generation Phase

This phase includesset-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 i. A user i randomly selects ti∈Zq∗ and keeps it secure. User i computes Ti=ti∙P as the public key, and user i sends Ti,IDi to the KGC(ii)
Partial-key-extract: this algorithm is an algorithm performed by the KGC. According to the identity IDi of user i, the KGC performs the following steps:
(1)
Randomly selectri∈Zq∗ and compute Ri=ri∙P(2)
Calculate a part of the partial private keyki as follows:(2)ki⟵ri+dH3Ri,Ti,IDi+H3dTi,IDimodq(3)
After that, partial keyRi,ki is delivered to user i through the public channel(iii)
Set-private-key: this algorithm is an algorithm performed by user i. After receiving partial key Ri,ki from the KGC, user i verifies these like equations (3) and (4). If verification passes, user i is compute private key ski=si,ti as the following steps:(1)
Verify whether the following equation holds:(3)ki∙P=?Ri+H7Ri,Ti,IDiPPub+H3tiPPub,IDiP(2)
If not, return⊥; otherwise, user i computes si as follows:(4)si⟵ki−H3tiPPub,IDi(3)
After that, useri keeps secret ski=si,ti as his/her the full private key(iv)
Set-public-key: this algorithm is an algorithm performed by user i. User i keeps pki=Ri,Ti as the full public keyFigure 5
Key generation phase.


### 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 Figure6.
(i)
Enc: this algorithm is an algorithm performed by the sender S. Sender S encrypts message m with ciphertext CT by entering his/her public key pkS=RS,TS and message m∈M. Then, upload the ciphertext CT to the cloud(1)
Computew, z, and Z using the given message m∈M and pkS=RS,TS(5)w⟵H7RS,TS,IDS,z⟵H2mw,Z⟵zP(2)
Then, senderS calculates US using z and pkS=RS,TS(6)US⟵z∙RS+H7RS,TS,IDSPpub+TS(3)
SenderS calculates α,θ, and C as follows:(7)α⟵H1sS·tS,θ⟵H1US·α,C⟵H4Z,θ⊕mw(4)
Generate ciphertextCT⟵C1,C2=Z,C. Then, the generated CT is uploaded and stored to the cloud(ii)
Dec-1: this algorithm is an algorithm performed by the sender S. The sender S can download the ciphertext CT=C1,C2=Z,C from cloud. The sender S who has downloaded the ciphertext CT can obtain the plaintext m by decrypting the ciphertext CT with his/her private key skS=sS,tS(4)
SenderS calculates US′ using its private key skS=sS,tS and the given ciphertext CT=C1,C2,C3(8)US′⟵sS+tS∙C1(5)
Calculateα and θ′ by inputting skS and US′(9)α⟵H1sS·tS,(10)θ′⟵H1US′·α(6)
Calculatem by inputting C1,C2,θ′(11)mw⟵C2⊕H4C1,θ′,(12)∵C2⊕H4C1,θ′=H4Z,θ⊕mw⊕H4C1,θ′=H4Z,θ⊕mw⊕H4Z,θ′=mw,where C1=Z(7)
Verify whether the following equation holds. If not, return⊥; otherwise, sender S keeps plaintext m(13)C1=?H2mH7RS,TS,IDSP,(14)∵C1=H2mH7RS,TS,IDSP=H2mwP=zP=Z,where Z=zP and z=H2mwFigure 6
Data storing phase.


### 4.3.4. Data Broadcast Phase

This phase includesre-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 S to delegate a ciphertext to set of recipients ℝ=r1,r2,⋯,rn of selected receiver rj with identity IDj1≤j≤n. The following steps will be performed in this algorithm(1)
ComputeUj, where j=1,2,⋯,n.(15)Uj⟵z∙Rj+H7Rj,Tj,IDjPpub+Tj(2)
Compute a polynomialfx with degree n using β∈Zq∗ as follows:(16)fx=∏i=0nx−Uj+βmodq=xn+an−1xn−1+⋯+a1x+a0,where, ai∈Zp∗i=0,1,⋯,n−1(3)
Computex using skS, α, and β−1 as follows:(17)x⟵sS+tS·α·β−1(4)
SenderS generates reencryption key rkS⟶ℝ=rk1,rk2=x,a0,a1,⋯,an−1 and sends rkS⟶ℝ to cloud(ii)
Re-Enc: this algorithm is executed by cloud. This algorithm reencrypts ciphertext CT to ciphertext CTR using reencryption key rkS⟶ℝ. The following steps will be performed in this algorithm
(1)
ComputeCTR using ciphertext CT and reencryption key rkS⟶ℝ(18)C1′⟵C1,(19)C2′⟵C2,(20)C3′⟵rk1·C1,(21)C4′⟵rk2(2)
OutputCTR=C1′,C2′,C3′,C4′ and send CTR to receivers ℝ(iii)
Dec-2: this algorithm is executed by the selected receiver rj to extract the plaintext from the received ciphertext CTR=C1′,C2′,C3′,C4′. Receiver rj performs following steps:
(1)
ComputeUj(22)Uj′⟵sj+tj∙C1′(2)
Generate polynomialfx and compute β′(23)fx=xn+an−1xn−1+⋯+a1x+a0,(24)β′=fUj′(3)
Computeθ′ as input C3′ and β′(25)θ′=H1C3′·β′,(26)∵C3′·β′=rk1·C1·β′=x·C1·β′=sS+tS·α·β−1·C1·β′=US·α(4)
Computem as input C1′,C2′,θ′(27)m⟵C2′⊕H4C1′,θ′,(28)∵C2′⊕H4C1′,θ′=H4Z,θ⊕m⊕H4C1′,θ′=H4Z,θ⊕m⊕H4Z,θ′=m,where C1′=C1=Z(5)
Verify messagem. If not, return ⊥; otherwise, receiver i outputs the plaintext m(29)C1′=?H2mP,(30)∵C1′=H2mP=zP=Z,where Z=zP and z=H2mFigure 7
Data broadcast phase.


## 4.3.1. Setup Phase

This phase includes thesetup 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λ⟶msk,mpk: 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 p,q and an elliptic curve E defined on Fp. Let G be the additive group on elliptic curve E and Gq be the subgroup of G with prime order q(2)
Select randomly a generatorP∈Gq(3)
Randomly choosed∈Zq∗ as the msk and calculate Ppub=d∙P which is part of mpk(4)
Select five secure one-way hash functions are follows:(1)H1:Zq∗⟶Zq∗,H2:0,1l1+l2⟶Zq∗,H3:Gq×0,1∗⟶Zq∗,H4:Zq∗×Zq∗⟶0,1l1+l2,H5:Zq∗×0,1∗×0,1∗⟶Zq∗,H6:Zq∗⟶0,1l2,H7:Gq×Gq×0,1∗⟶Zq∗,where l1 and l2 mean the length of the bit string and is determined by the security parameter λ(5)
Publish the system’s maser public keympk=p,q,l1,l2,E,G,Gq,P,Ppub,H1,H2,H3,H4,H5,H6,H7 and message space M=0,1l1


## 4.3.2. Key Generation Phase

This phase includesset-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 i. A user i randomly selects ti∈Zq∗ and keeps it secure. User i computes Ti=ti∙P as the public key, and user i sends Ti,IDi to the KGC(ii)
Partial-key-extract: this algorithm is an algorithm performed by the KGC. According to the identity IDi of user i, the KGC performs the following steps:
(1)
Randomly selectri∈Zq∗ and compute Ri=ri∙P(2)
Calculate a part of the partial private keyki as follows:(2)ki⟵ri+dH3Ri,Ti,IDi+H3dTi,IDimodq(3)
After that, partial keyRi,ki is delivered to user i through the public channel(iii)
Set-private-key: this algorithm is an algorithm performed by user i. After receiving partial key Ri,ki from the KGC, user i verifies these like equations (3) and (4). If verification passes, user i is compute private key ski=si,ti as the following steps:(1)
Verify whether the following equation holds:(3)ki∙P=?Ri+H7Ri,Ti,IDiPPub+H3tiPPub,IDiP(2)
If not, return⊥; otherwise, user i computes si as follows:(4)si⟵ki−H3tiPPub,IDi(3)
After that, useri keeps secret ski=si,ti as his/her the full private key(iv)
Set-public-key: this algorithm is an algorithm performed by user i. User i keeps pki=Ri,Ti as the full public keyFigure 5
Key generation phase.


## 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 Figure6.
(i)
Enc: this algorithm is an algorithm performed by the sender S. Sender S encrypts message m with ciphertext CT by entering his/her public key pkS=RS,TS and message m∈M. Then, upload the ciphertext CT to the cloud(1)
Computew, z, and Z using the given message m∈M and pkS=RS,TS(5)w⟵H7RS,TS,IDS,z⟵H2mw,Z⟵zP(2)
Then, senderS calculates US using z and pkS=RS,TS(6)US⟵z∙RS+H7RS,TS,IDSPpub+TS(3)
SenderS calculates α,θ, and C as follows:(7)α⟵H1sS·tS,θ⟵H1US·α,C⟵H4Z,θ⊕mw(4)
Generate ciphertextCT⟵C1,C2=Z,C. Then, the generated CT is uploaded and stored to the cloud(ii)
Dec-1: this algorithm is an algorithm performed by the sender S. The sender S can download the ciphertext CT=C1,C2=Z,C from cloud. The sender S who has downloaded the ciphertext CT can obtain the plaintext m by decrypting the ciphertext CT with his/her private key skS=sS,tS(4)
SenderS calculates US′ using its private key skS=sS,tS and the given ciphertext CT=C1,C2,C3(8)US′⟵sS+tS∙C1(5)
Calculateα and θ′ by inputting skS and US′(9)α⟵H1sS·tS,(10)θ′⟵H1US′·α(6)
Calculatem by inputting C1,C2,θ′(11)mw⟵C2⊕H4C1,θ′,(12)∵C2⊕H4C1,θ′=H4Z,θ⊕mw⊕H4C1,θ′=H4Z,θ⊕mw⊕H4Z,θ′=mw,where C1=Z(7)
Verify whether the following equation holds. If not, return⊥; otherwise, sender S keeps plaintext m(13)C1=?H2mH7RS,TS,IDSP,(14)∵C1=H2mH7RS,TS,IDSP=H2mwP=zP=Z,where Z=zP and z=H2mwFigure 6
Data storing phase.


## 4.3.4. Data Broadcast Phase

This phase includesre-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 S to delegate a ciphertext to set of recipients ℝ=r1,r2,⋯,rn of selected receiver rj with identity IDj1≤j≤n. The following steps will be performed in this algorithm(1)
ComputeUj, where j=1,2,⋯,n.(15)Uj⟵z∙Rj+H7Rj,Tj,IDjPpub+Tj(2)
Compute a polynomialfx with degree n using β∈Zq∗ as follows:(16)fx=∏i=0nx−Uj+βmodq=xn+an−1xn−1+⋯+a1x+a0,where, ai∈Zp∗i=0,1,⋯,n−1(3)
Computex using skS, α, and β−1 as follows:(17)x⟵sS+tS·α·β−1(4)
SenderS generates reencryption key rkS⟶ℝ=rk1,rk2=x,a0,a1,⋯,an−1 and sends rkS⟶ℝ to cloud(ii)
Re-Enc: this algorithm is executed by cloud. This algorithm reencrypts ciphertext CT to ciphertext CTR using reencryption key rkS⟶ℝ. The following steps will be performed in this algorithm
(1)
ComputeCTR using ciphertext CT and reencryption key rkS⟶ℝ(18)C1′⟵C1,(19)C2′⟵C2,(20)C3′⟵rk1·C1,(21)C4′⟵rk2(2)
OutputCTR=C1′,C2′,C3′,C4′ and send CTR to receivers ℝ(iii)
Dec-2: this algorithm is executed by the selected receiver rj to extract the plaintext from the received ciphertext CTR=C1′,C2′,C3′,C4′. Receiver rj performs following steps:
(1)
ComputeUj(22)Uj′⟵sj+tj∙C1′(2)
Generate polynomialfx and compute β′(23)fx=xn+an−1xn−1+⋯+a1x+a0,(24)β′=fUj′(3)
Computeθ′ as input C3′ and β′(25)θ′=H1C3′·β′,(26)∵C3′·β′=rk1·C1·β′=x·C1·β′=sS+tS·α·β−1·C1·β′=US·α(4)
Computem as input C1′,C2′,θ′(27)m⟵C2′⊕H4C1′,θ′,(28)∵C2′⊕H4C1′,θ′=H4Z,θ⊕m⊕H4C1′,θ′=H4Z,θ⊕m⊕H4Z,θ′=m,where C1′=C1=Z(5)
Verify messagem. If not, return ⊥; otherwise, receiver i outputs the plaintext m(29)C1′=?H2mP,(30)∵C1′=H2mP=zP=Z,where Z=zP and z=H2mFigure 7
Data broadcast phase.


## 4.4. Correctness

In this section, we will prove the correctness of the scheme proposed in Section4. 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.
Useri can verify whether the partial key Ri,ki received from the KGC is a value generated from the Ti,IDi created by him/her and the mpk of the correct KGC. This process corresponds to equations (2)–(4).Proof.
Assuming that one of the users isU1, U1 can perform the following process using R1,k1 received from the KGC and its own value T1,ID1 and KGC’s master public key mpk.☐U1 can verify whether the received partial key Ri,ki is correct by using the Ti,IDi and mpk. This process corresponds to equation (3).
(31)ki∙P=?R1+H7R1,T1,IDiPPub+H1t1PPub,ID1P,∵k1∙P=r1∙P+H7R1,T1,ID1·d·P+H3t1PPub,ID1P=r1+H7R1,T1,ID1·d+H3t1·d·P,ID1P=r1+d·H7R1,T1,ID1+H3T1·d1,ID1P=k1P,where ki=ri+dH7Ri,Ti,IDi+H3dTi,IDi.Theorem 2.
The senderS can perform decryption using the ciphertext CT received from the cloud and his/her private key and obtain the plaintext m. This process corresponds to equations (8)–(13).Proof.
Assuming that one of the senders isS, S can perform the following process using CT=C1,C2,C3,C4 received from the sender and its own private key skS=sS,tS.☐S creates US′ as follows using his/her private key skS=sS,tS. This process corresponds to equations (8) and (9).
(32)US′⟵sS+tS∙Z,US=z∙RS+H7RS,TS,IDSPpub+TS=z∙rSP+H7RS,TS,IDSdP+tSP=z∙rS+H7RS,TS,IDSd+tSP=rS+dH7RS,TS,IDS+tSZ=rS+dH7RS,TS,IDS+H3dTS,IDS−H3dTS,IDS+tSZ=kS−H7tSPPub,IDS+tSZ=sS+tSZ=sS+tSC1=US′.S obtains θ′ using the generated equations (9) and (10) as follows:
(33)α⟵H1sS·tS,θ′⟵H1US′·α.S can obtain m as follows using C1, C2 and the acquired θ′ in equation (11).
(34)m∥w⟵C2⊕H4C1,θ′,∵C2⊕H4C1,θ′=C⊕H4Z,θ′=H4Z,θ⊕mw⊕H4Z,θ′=mw,where CT=C1,C2=Z,C and C=H4Z,θ⊕mw.Theorem 3.
The receiversℝ can perform decryption using the reencrypted ciphertext CTR received from the cloud and his/her private key and obtain the plaintext m. This process corresponds to equations (18)–(29).Proof.
Assuming that one of the receivers isr1, r1 can perform the following process using CTR=C1′,C2′,C3′,C4′ received from the sender and its own private key skr1=sr1,tr1.☐r1 creates Ur1 as follows using his/her private key skR=sR,tR. This process corresponds to equations (18) and (22).
(35)Ur1′⟵sr1+tr1∙Z,Ur1=z∙Rr1+H7Rr1,Tr1,IDr1Ppub+Tr1=z∙rr1P+H7Rr1,Tr1,IDr1dP+tr1P=z∙rr1+H7Rr1,Tr1,IDr1d+tr1P=rr1+dH7Rr1,Tr1,IDr1+tr1Z=rr1+dH7Rr1,Tr1,Ir1+H3dTr1,IDr1−H3dTr1,IDr1+tr1Z=kr1−H7tr1PPub,IDr1+tr1Z=sr1+tr1Z=sr1+tr1C1=Ur1′.r1 obtains θ′ using the generated equations (23)–(25) as follows:
(36)β′⟵fUr1=∏i=0nUr1−Ui+βmodq=Ur1−Ur1∙Ur1−Ur2⋯Ur1−Uri+βmodq=0∙Ur1−Ur2⋯Ur1−Uri+βmodq.r1 can obtain m using C1′, C2′ and the acquired θ′ in equation (27).
(37)mw⟵C2′⊕H4C1′,θ′,∵C2′⊕H4C1′,θ′=C⊕H4Z,θ′=H4Z,θ⊕m∥w⊕H4Z,θ′=mw,where CTR=C1′,C2′,C3′,C4′=Z,C,x·Z,rk2 and C=H4Z,θ⊕mw.


## 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 Section3.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(38)fx=∏i=0nx−μi+βmodq=xn+an−1xn−1+⋯+a1x+a0.Table 1
Comparison of the security requirements.
Bilinear pairingKey escrow problemReceiver anonymityRe-key-generationWang and Yang [41]UsedInsecureOfferKGC/BCMaiti and Misra [37]UsedInsecureOfferSenderSun et al. [38]UsedInsecureOfferSenderYin et al. [39]UsedInsecureOfferSenderChunpeng et al. [40]UsedInsecureOfferSenderProposed schemeNot usedSecureOfferSenderHere,μi is μi⟵H3Ui,IDi,w and Ui is Ui⟵z∙Ri+H7Ri,Ti,IDiPPub+Ti. Therefore, each recipient must have its own private key to generate μi and the user who generates μi can obtain the θ through the following process:
(39)β′⟵fμi=∏i=0nμi−μi+βmodq=μ1−μ1∙μ1−μ2⋯μ1−μn+βmodq=0∙μ1−μ2⋯μ1−μn+βmodq.μi can obtain the θ through the following process:
(40)m⟵C⊕H4Z,θ.If an attacker attempts to createUi′ with only the public key of the recipient i, Ui′ cannot be generated normally, as follows:
(41)Ui′⟵z?∙Ri+H7Ri,Ti,IDiPPub+Ti.According to the above formula, because the attacker does not knowz, it is impossible to forge Ui′.
(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:(42)C1′=?H2mwP,∵C1′=H2mwP=zP=Z,where Z=zP and z=H2mw.The receiver that decrypts ciphertextCTR can obtain message m and verification value w. Here, H2mw is equal to z, and thus, the integrity of the message can be verified by comparing whether H2mP is equal to C1=Z.
(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-keyFirst, theset-secret-value algorithm generates Ti using secret value ti, randomly selected by the user, and the master public key value P of the KGC. At this time, ti is safely stored only by the user and Ti and IDi are delivered to the KGC through an open channel.In thepartial-key-extract algorithm, using the Ti and IDi received by the KGC from the user, partial keys Ri and ki are generated through the following process and delivered to the user.
(43)Ri=ri∙P,ki⟵ri+dH7Ri,Ti,IDi+H3dTi,IDimodP.In theset-private-key algorithm, the private key is calculated using the Ri and ki received by the user from the KGC. At this time, the user does not use Ri,ki as the private key, but uses t_i, which only the user knows, and si, which is generated based on the ki received from the KGC, as the private key.
(44)si⟵ki−H3tiPPub,IDi.Finally, in theset-public-key algorithm, Ti generated by the user and Ri generated by the KGC are used as public keys.As a result, the KGC must knowti to obtain the user’s private key ski=si,ti. However, because ti is a secret value stored safely by the user, the key escrow problem by the KGC does not occur.The KGC only knowspki=Ti,Ri and ki, and the KGC cannot know ski=si,ti.(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 computation(45)ki∙P=?Ri+H7Ri,Ti,IDiPPub+H3tiPPub,IDiP,∵ki∙P=ri∙P+H7Ri,Ti,IDi·d·P+H3tiPPub,IDiP=ri+H7Ri,Ti,IDi·d+H3ti·d·P,IDiP=ri+d·H7Ri,Ti,IDi+H3Ti·di,IDiP=kiP,where, ki=ri+dH7Ri,Ti,IDi+H3dTi,IDi,(46)Ri=riP,Ti=tiP,Ppub=dP.Through the above calculation, useri can know that the partial key that it has received is based on secret value ri generated by user i 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:(47)fx=∏i=0nx−μi+βmodq=x−μ1∙x−μ2∙⋯∙x−μn+βmodq=xn+an−1xn−1+⋯+a1x+a0,Uj′=sj+tj∙C1′To identify a specific recipient in the above polynomial, it is possible to generateμi′ of the specific receiver. However, as in the confidentiality item above, an attacker cannot forge Ui′.
(48)Ui′⟵z?∙Ri+H7Ri,Ti,IDiPPub+Ti.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 fx, a polynomial that targets all receivers.(49)fx=∏i=0nx−μi+βmodq=x−μ1∙x−μ2∙⋯∙x−μn+βmodq=xn+an−1xn−1+⋯+a1x+a0.


### 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 keygenIBE algorithm as follows:(50)skID=d0,d1,d2=gα2g1IDgu,gu,gu/α,where master secret key mk=g2α and random value α,u,x∈Zp∗.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.(51)skIDA=g1/α+H1IDA,where the system secret key is α.Sun et al. also generated the user’s private key in the keygen algorithm as follows.(52)ski=giγ,where system secret key msk=γ.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.(53)rk=rk1,rk2,rk3,rk4,rk5,rk6,ii∈1,2,⋯,k+1,where rk6,i=μis,for(54)i∈1,2,⋯,k+1.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.Table 2
Comparison of the computation efficiency.
EncRe-key-genRe-encDec-2Wang and Yang [41]2TM+4Te+1TP.10+3nTM+1Te6Te7TM+7Te+5TPMaiti and Misra [37]4TM+3Te3+n2+nTM+3+nTe1TM+1TP1TM+2TPSun et al. [38]2+nTM+5Te+1TP3+nTM+6Te+1Tp1+nTM+2TP4+nTM+2TeYin et al. [39]4+2nTM+4Te5+nTM+6Te4+3nTM+2Te+2Tp7TM+1Te+3TPChunpeng et al. [40]2TM+3Te5+nTM+5+nTe+1Tp1TM+2Tp6TM+2Te+2TpProposed scheme2TEM+2TEA1+nTM+2nTEM+2nTEA1TEM2TEMTM: computation time of modular multiplication operation; TEM: computation time of ECC multiplication operation; TEA: computation time of ECC point add operation; Te: computation time of exponent operation; Tp: computation time of bilinear pairing operation.Figure 8
Computation time of schemes.


## 5.1. Analysis of Security Requirements

We analyze whether the proposed scheme is successful in achieving the security requirements presented in Section3.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(38)fx=∏i=0nx−μi+βmodq=xn+an−1xn−1+⋯+a1x+a0.Table 1
Comparison of the security requirements.
Bilinear pairingKey escrow problemReceiver anonymityRe-key-generationWang and Yang [41]UsedInsecureOfferKGC/BCMaiti and Misra [37]UsedInsecureOfferSenderSun et al. [38]UsedInsecureOfferSenderYin et al. [39]UsedInsecureOfferSenderChunpeng et al. [40]UsedInsecureOfferSenderProposed schemeNot usedSecureOfferSenderHere,μi is μi⟵H3Ui,IDi,w and Ui is Ui⟵z∙Ri+H7Ri,Ti,IDiPPub+Ti. Therefore, each recipient must have its own private key to generate μi and the user who generates μi can obtain the θ through the following process:
(39)β′⟵fμi=∏i=0nμi−μi+βmodq=μ1−μ1∙μ1−μ2⋯μ1−μn+βmodq=0∙μ1−μ2⋯μ1−μn+βmodq.μi can obtain the θ through the following process:
(40)m⟵C⊕H4Z,θ.If an attacker attempts to createUi′ with only the public key of the recipient i, Ui′ cannot be generated normally, as follows:
(41)Ui′⟵z?∙Ri+H7Ri,Ti,IDiPPub+Ti.According to the above formula, because the attacker does not knowz, it is impossible to forge Ui′.
(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:(42)C1′=?H2mwP,∵C1′=H2mwP=zP=Z,where Z=zP and z=H2mw.The receiver that decrypts ciphertextCTR can obtain message m and verification value w. Here, H2mw is equal to z, and thus, the integrity of the message can be verified by comparing whether H2mP is equal to C1=Z.
(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-keyFirst, theset-secret-value algorithm generates Ti using secret value ti, randomly selected by the user, and the master public key value P of the KGC. At this time, ti is safely stored only by the user and Ti and IDi are delivered to the KGC through an open channel.In thepartial-key-extract algorithm, using the Ti and IDi received by the KGC from the user, partial keys Ri and ki are generated through the following process and delivered to the user.
(43)Ri=ri∙P,ki⟵ri+dH7Ri,Ti,IDi+H3dTi,IDimodP.In theset-private-key algorithm, the private key is calculated using the Ri and ki received by the user from the KGC. At this time, the user does not use Ri,ki as the private key, but uses t_i, which only the user knows, and si, which is generated based on the ki received from the KGC, as the private key.
(44)si⟵ki−H3tiPPub,IDi.Finally, in theset-public-key algorithm, Ti generated by the user and Ri generated by the KGC are used as public keys.As a result, the KGC must knowti to obtain the user’s private key ski=si,ti. However, because ti is a secret value stored safely by the user, the key escrow problem by the KGC does not occur.The KGC only knowspki=Ti,Ri and ki, and the KGC cannot know ski=si,ti.(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 computation(45)ki∙P=?Ri+H7Ri,Ti,IDiPPub+H3tiPPub,IDiP,∵ki∙P=ri∙P+H7Ri,Ti,IDi·d·P+H3tiPPub,IDiP=ri+H7Ri,Ti,IDi·d+H3ti·d·P,IDiP=ri+d·H7Ri,Ti,IDi+H3Ti·di,IDiP=kiP,where, ki=ri+dH7Ri,Ti,IDi+H3dTi,IDi,(46)Ri=riP,Ti=tiP,Ppub=dP.Through the above calculation, useri can know that the partial key that it has received is based on secret value ri generated by user i 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:(47)fx=∏i=0nx−μi+βmodq=x−μ1∙x−μ2∙⋯∙x−μn+βmodq=xn+an−1xn−1+⋯+a1x+a0,Uj′=sj+tj∙C1′To identify a specific recipient in the above polynomial, it is possible to generateμi′ of the specific receiver. However, as in the confidentiality item above, an attacker cannot forge Ui′.
(48)Ui′⟵z?∙Ri+H7Ri,Ti,IDiPPub+Ti.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 fx, a polynomial that targets all receivers.(49)fx=∏i=0nx−μi+βmodq=x−μ1∙x−μ2∙⋯∙x−μn+βmodq=xn+an−1xn−1+⋯+a1x+a0.


## 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 keygenIBE algorithm as follows:(50)skID=d0,d1,d2=gα2g1IDgu,gu,gu/α,where master secret key mk=g2α and random value α,u,x∈Zp∗.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.(51)skIDA=g1/α+H1IDA,where the system secret key is α.Sun et al. also generated the user’s private key in the keygen algorithm as follows.(52)ski=giγ,where system secret key msk=γ.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.(53)rk=rk1,rk2,rk3,rk4,rk5,rk6,ii∈1,2,⋯,k+1,where rk6,i=μis,for(54)i∈1,2,⋯,k+1.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.Table 2
Comparison of the computation efficiency.
EncRe-key-genRe-encDec-2Wang and Yang [41]2TM+4Te+1TP.10+3nTM+1Te6Te7TM+7Te+5TPMaiti and Misra [37]4TM+3Te3+n2+nTM+3+nTe1TM+1TP1TM+2TPSun et al. [38]2+nTM+5Te+1TP3+nTM+6Te+1Tp1+nTM+2TP4+nTM+2TeYin et al. [39]4+2nTM+4Te5+nTM+6Te4+3nTM+2Te+2Tp7TM+1Te+3TPChunpeng et al. [40]2TM+3Te5+nTM+5+nTe+1Tp1TM+2Tp6TM+2Te+2TpProposed scheme2TEM+2TEA1+nTM+2nTEM+2nTEA1TEM2TEMTM: computation time of modular multiplication operation; TEM: computation time of ECC multiplication operation; TEA: computation time of ECC point add operation; Te: computation time of exponent operation; Tp: computation time of bilinear pairing operation.Figure 8
Computation time of schemes.


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



---

*Source: 1567019-2021-12-16.xml*