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

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.


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

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][4][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.

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][8][9][10][11][12][13][14][15][16][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][23][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. [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.

Broadcast Proxy Reencryption. Broadcast encryption (BE) is a technique first introduced by Berkovits
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 2 Wireless Communications and Mobile Computing 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][32][33][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.

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.

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 3 Wireless Communications and Mobile Computing 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   Wireless Communications and Mobile Computing (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-value ðmpkÞ ⟶ ðT i , ID i Þ: this algorithm is performed by the user, wherein user i generates T i using randomly selected t i and mpk and sends it to the KGC along with ID i (iii) Partial-key-extract ðT i , ID i , msk, mpkÞ ⟶ ðR i , k i Þ : this algorithm is performed by the KGC, which generates partial keys ðR i , k i Þ of user i using T i and ID i transmitted by user i and its own msk and mpk and delivers it to user i (iv) Set-private-key ðt i , R i , k i , mpkÞ ⟶ sk i : this algorithm is performed by the user, wherein user i generates his/her own private key sk i using the partial keys ðR i , k i Þ received from the KGC. The generated private key sk i was kept secure (v) Set-public-key ðt i , R i , mpkÞ ⟶ pk i : this algorithm is performed by the user, wherein user i generates his/her public key pk i using the partial key ðR i , k i Þ received from the KGC and the secret value t i generated by the user. The generated public key p k i is made public so that anyone can use it (vi) Enc ðpk S , ID S , m, mpkÞ ⟶ CT: this algorithm is performed by the sender, wherein sender S encrypts his/her data m ∈ M using public key pk S to obtain ciphertext CT and uploads it to the cloud (vii) Re-key-gen ðsk S , pk ℝ , ID S , ID ℝ , mpkÞ ⟶ rk S⟶ℝ : this algorithm is performed by the sender, wherein sender S specifies a receiver set ℝ = ðr 1 , r 2 ,⋯,r n Þ of receivers r j ð1 ≤ j ≤ nÞ to share their data with, generates a reencryption key for ℝ, and delivers it to the cloud (viii) Re-enc ðCT, rk S⟶ℝ , mpkÞ ⟶ CT R : this algorithm is performed by the cloud, wherein the cloud reencrypts ciphertext CT of sender S using reencryption key rk S⟶ℝ of sender S to obtain reencrypted ciphertext CT R (ix) Dec-1 ðCT, sk S , ID S , 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 sk S to decrypt it to obtain plaintext m (x) Dec-2 ðCT R , sk j , ID j , mpkÞ ⟶ m: this algorithm is performed by the receiver, wherein receiver r j downloads ciphertext CT R stored in the cloud and then uses his/her private key sk j to decrypt it to obtain plaintext m

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

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 ðλÞ ⟶ ð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 F p . Let G be the additive group on elliptic curve E and G q be the subgroup of G with prime order q (2) Select randomly a generator P ∈ G q (3) Randomly choose d ∈ Z * q as the msk and calculate P pub = d•P which is part of mpk

Wireless Communications and Mobile Computing
where l 1 and l 2 mean the length of the bit string and is determined by the security parameter λ

Key Generation
Phase. This phase includes set-secretvalue, 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 t i ∈ Z * q and keeps it secure. User i computes T i = t i •P as the public key, and user i sends ðT i , ID i Þ to the KGC (ii) Partial-key-extract: this algorithm is an algorithm performed by the KGC. According to the identity ID i of user i, the KGC performs the following steps: (1) Randomly select r i ∈ Z * q and compute R i = r i •P (2) Calculate a part of the partial private key k i as follows: (3) After that, partial key ðR i , k i Þ 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 ðR i , k i Þ from the KGC, user i verifies these like equations (3) and (4). If verification passes, user i is compute private key sk i = ðs i , t i Þ as the following steps: (1) Verify whether the following equation holds: (2) If not, return ⊥; otherwise, user i computes s i as follows: (3) After that, user i keeps secret sk i = ðs i , t i Þ as his/her the full private key (iv) Set-public-key: this algorithm is an algorithm performed by user i. User i keeps pk i = ðR i , T i Þ as the full public key

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 S. Sender S encrypts message m with ciphertext CT by entering his/her public key pk S = ðR S , T S Þ and message m ∈ M. Then, upload the ciphertext CT to the cloud (1) Compute w, z, and Z using the given message m ∈ M and pk S = ðR S , (2) Then, sender S calculates U S using z and pk S = ð R S , T S Þ (3) Sender S calculates α, θ, and C as follows:

Wireless Communications and Mobile Computing
(4) Generate ciphertext CT ⟵ ðC 1 , C 2 Þ = ð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 = ðC 1 , C 2 Þ = ð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 sk S = ðs S , t S Þ (4) Sender S calculates U S ′ using its private key sk S = ð s S , t S Þ and the given ciphertext CT = ðC 1 , (5) Calculate α and θ ′ by inputting sk S and U S ′   Wireless Communications and Mobile Computing where C 1 = Z (7) Verify whether the following equation holds. If not, return ⊥; otherwise, sender S keeps plaintext m where Z = zP and z = H 2 ðmkwÞ

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 S to delegate a ciphertext to set of recipients ℝ = ðr 1 , r 2 , ⋯,r n Þ of selected receiver r j with identity ID j ð1 ≤ j ≤ nÞ. The following steps will be performed in this algorithm (1) Compute U j , where j = 1, 2, ⋯, n.
(2) Compute a polynomial f ðxÞ with degree n using β ∈ Z * q as follows: where, a i ∈ Z * p ði = 0, 1, ⋯, n − 1Þ (3) Compute x using sk S , α, and β −1 as follows: (4) Sender S generates reencryption key rk S⟶ℝ = ðrk 1 , rk 2 Þ = ðx, fa 0 , a 1 ,⋯,a n−1 gÞ and sends rk S⟶ℝ to cloud (ii) Re-Enc: this algorithm is executed by cloud. This algorithm reencrypts ciphertext CT to ciphertext C T R using reencryption key rk S⟶ℝ . The following steps will be performed in this algorithm (1) Compute CT R using ciphertext CT and reencryption key rk S⟶ℝ (2) Output CT R = ðC 1 ′, C 2 ′, C 3 ′, C 4 ′Þ and send CT R to receivers ℝ (iii) Dec-2: this algorithm is executed by the selected receiver r j to extract the plaintext from the received ciphertext CT R = ðC 1 ′ , C 2 ′ , C 3 ′ , C 4 ′ Þ. Receiver r j performs following steps: (2) Generate polynomial f ðxÞ and compute β ′ f x ð Þ = x n + a n−1 x n−1 +⋯+a 1 x + a 0 , ð23Þ (3) Compute θ ′ as input C 3 ′ and β ′ 9 Wireless Communications and Mobile Computing (4) Compute m as input C 1 ′, C 2 ′, θ′ where C 1 ′ = C 1 = Z (5) Verify message m. If not, return ⊥; otherwise, receiver i outputs the plaintext m where Z = zP and z = H 2 ðmÞ 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-privatekey 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 i can verify whether the partial key ðR i , k i Þ received from the KGC is a value generated from the ðT i , ID i Þ 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 is U 1 , U 1 can perform the following process using ðR 1 , k 1 Þ received from the KGC and its own value ðT 1 , ID 1 Þ and KGC's master public key mpk.☐ U 1 can verify whether the received partial key ðR i , k i Þ is correct by using the ðT i , ID i Þ and mpk. This process corresponds to equation (3).

10
Wireless Communications and Mobile Computing where Theorem 2. The sender S 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 is S, S can perform the following process using CT = ðC 1 , C 2 , C 3 , C 4 Þ received from the sender and its own private key sk S = ðs S , t S Þ.☐ S creates U S ′ as follows using his/her private key sk S = ðs S , t S Þ. This process corresponds to equations (8) and (9).
S obtains θ ′ using the generated equations (9) and (10) as follows: S can obtain m as follows using C 1 , C 2 and the acquired θ ′ in equation (11).
Theorem 3. The receivers ℝ can perform decryption using the reencrypted ciphertext CT R 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 is r 1 , r 1 can perform the following process using CT R = ðC 1 ′ , C 2 ′ , C 3 ′ , C 4 ′ Þ received from the sender and its own private key sk r 1 = ð s r 1 , t r 1 Þ.☐ r 1 creates U r 1 as follows using his/her private key sk R = ðs R , t R Þ. This process corresponds to equations (18) and (22).

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.

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 ECCbased 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, 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Þ μ i can obtain the θ through the following process: If an attacker attempts to create U i ′ with only the public key of the recipient i, U i ′ cannot be generated normally, as follows: According to the above formula, because the attacker does not know z, it is impossible to forge U i ′.
(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 Z = zP and z = H 2 ðmkwÞ. The receiver that decrypts ciphertext CT R can obtain message m and verification value w. Here, H 2 ðmkwÞ is equal to z, and thus, the integrity of the message can be verified by comparing whether H 2 ðmÞP is equal to C 1 = 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-keyextract, set-private-key, and set-public-key First, the set-secret-value algorithm generates T i using secret value t i , randomly selected by the user, and the master public key value P of the KGC. At this time, t i is safely stored only by the user and T i and ID i are delivered to the KGC through an open channel.
In the partial-key-extract algorithm, using the T i and ID i received by the KGC from the user, partial keys R i and k i are generated through the following process and delivered to the user.
In the set-private-key algorithm, the private key is calculated using the R i and k i received by the user from the KGC. At this time, the user does not use ðR i , k i Þ as the private key, but uses t i, which only the user knows, and s i , which is generated based on the k i received from the KGC, as the private key.
Finally, in the set-public-key algorithm, T i generated by the user and R i generated by the KGC are used as public keys.
As a result, the KGC must know t i to obtain the user's private key sk i = ðs i , t i Þ. However, because t i is a secret value stored safely by the user, the key escrow problem by the KGC does not occur.
The KGC only knows pk i = ðT i , R i Þ and k i , and the KGC cannot know sk i = ðs i , t i Þ: (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 where, k i = r i + dH 7 ðR i , T i , ID i Þ + H 3 ðdT i , ID i Þ, R i = r i P, T i = t i P, P pub = dP: Through the above calculation, user i can know that the partial key that it has received is based on secret value r i 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: Þ+ β mod q ð Þ = x n + a n−1 x n−1 +⋯+a 1 x + a 0 , 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 U i ′ .
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 f ðxÞ, a polynomial that targets all receivers.

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 keygen IBE algorithm as follows: where master secret key mk = g α 2 and random value α, u, x ∈ Z * : p 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