# Group Delegated ID-Based Proxy Reencryption for the Enterprise IoT-Cloud Storage Environment

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

---

## Abstract

In general, ID-based proxy reencryption (IBPRE) includes data transfer in a 1 : 1 manner between a sender and receiver. Therefore, only the data owner has the authority to decrypt or reencrypt the data that is encrypted with his/her public key. However, in an environment with data self-sovereignty, such as an enterprise IoT-cloud environment, the data are directly managed by cloud once data is uploaded from user-controlled IoT devices. In such a situation, there is no way of sharing data if the data owner has no access over the data due to being outside the workplace and other issues. In this study, to solve this problem, data can be shared even when the data cannot be accessed by delegating the authority of the data owner to generate the reencryption key to other users. In addition, by solving the security threats that may appear in this process, data sharing can be performed securely and efficiently in the corporate environment.


---

## Body

## 1. Introduction

Cloud storage technology is a technology that can store and use data remotely through a network by combining network technology with existing offline storage technology. When using cloud storage, the data owner uploads his or her data to the cloud storage. If another user requests this data in the future, it can be provided to the requestor through the provision of the data access path and authority of the cloud storage.These cloud storage technologies are used not only for personal data storage purposes but also for securely storing and utilizing all data generated inhouse in a corporate environment. From the perspective of a company, when using cloud storage, data generated within the company can be securely stored and managed and can be used for other purposes as needed. However, if the data source is uploaded to the cloud storage in original form, the data content can be exposed to other users. Hence, encryption must be applied to solve this problem.Encryption can be used for secure storage and sharing of data through cloud storage [1–5]. However, in general symmetric key encryption or public key encryption, it is difficult to change a key distribution problem or the user of already encrypted data. Therefore, proxy reencryption has been proposed to solve this problem. Proxy reencryption is a form of encryption technology that allows the sender to securely share data with the receiver [6, 7]. However, a feature that is different from the general encryption scheme is that the sender can provide data encrypted with his or her public key by converting it into an encrypted text that can be decrypted by the receiver with only the receiver’s public key. This feature allows the sender to avoid performing decryption and encryption or sharing a secret key with the receiver in order to provide encrypted data to the receiver. Therefore, in a cloud storage environment, it is possible to provide the encrypted text generated by the user with his/her key by converting it into data encrypted with the requestor’s key upon request.However, a corporate-like environment has one additional property. For security reasons, access to cloud storage may be blocked from outside the enterprise. Let us assume that the data owner is outside the company on a business trip. If data is requested from other employees and departments within the company, the request cannot be processed. In preparation for this situation, there are ways to share the private key with other employees, but this can lead to a serious security threat. Employees who have access to the private key of the owner can exercise all the rights of the owner. Therefore, it is necessary to be able to share designated data without sharing the private key. In this research, studies were conducted to satisfy these conditions. Our study provides an environment in which the owner of the data can provide the right to reencrypt specific data to other users. We propose a traceable group delegated ID-based proxy reencryption (IBPRE).


## 2. Related Works

This section describes related studies and theoretical constructs for understanding our study.


### 2.1. Proxy Reencryption

Proxy reencryption is an encryption technology that converts data encrypted with the sender’s public key into data encrypted with the receiver’s public key through a proxy. To this end, the sender generates a reencryption key using his/her own private key and the recipient’s public key of the recipient and delivers it to the proxy. Upon receiving the reencryption key, the proxy reencrypts the sender’s cipher text using the reencryption key to obtain the receiver’s cipher text as shown in Figure1(e) [6–8].Figure 1
Basic form of proxy reencryption.Thereafter, the recipient can obtain the plaintext from the ciphertext using his/her private key. The advantage of proxy reencryption is that the senders can share data without exposing their private keys or the original message to the proxy. Therefore, only the sender and receiver can know the source of the data.IBPRE uses ID-based encryption to encrypt a user’s ID as a public key or derive a public key from an ID. In this manner, a user can identify another user through an ID using a system such as a cloud and share data with the user [9–20]. Basically, proxy reencryption is a technique that allows data encrypted with the key of the data sender to be decrypted by a third party, the receiver, as shown in Figure 2.Figure 2
PRE in the enterprise environment.In 2012, Xu et al. proposed a certificate-free IBPRE [18]. Noncertificate ID-based encryption is a technology that generates a public key through a user’s ID without using a certificate. Therefore, the amount of computation is reduced compared to that in the scheme of generating the certificate. Additionally, it is secure with regards to the key escrow problem and the key exposure problem because the KGC (Key Generate Center) does not generate the key directly [19, 20].As evident from the above algorithm configuration, this scheme assumes a form of traditional 1 : 1 data sharing. Therefore, it is difficult to resolve a situation in which a data owner cannot control data, such as an enterprise environment as covered in this study. However, in this scheme, the existing IBPRE has been applied to present the multiproxy crtificateless proxy reencryption (CL-PRE) and the randomized CL-PRE, which aims at diversity in the traditional IBPRE approach [21, 22].


### 2.2. Proxy Reencryption in the Enterprise Environment

In recent years, an increasing number of companies have begun operating private clouds. The cloud of a company is a technology that enables the storage and use of data produced within the company. It helps to efficiently manage sensitive data for data management and prevention of leakage. In general, it is necessary to distinguish between personal data and public data and even the data generated during work within the company. Therefore, data encryption should be applied in order to prevent other employees from viewing personal business data. Additionally, as encrypted data cannot be decrypted by a third party, the data owner must be able to decrypt the shared user with his or her private key in order to share data with the third party [23, 24]. As a result, the owner’s ciphertext needs to be converted into the requestor’s ciphertext through a process such as proxy reencryption [25, 26].This process follows the IBPRE process described above. Therefore, data inside the company can be securely stored by blocking external access for data security as shown in Figure3.Figure 3
Problem of PRE in the enterprise environment.However, if the data owner is outside the premises of the organization, the data owner may not be able to share data as the owner cannot access the cloud outside the company as shown in Figure3. In this case, the data is not transmitted, which causes a delay. Therefore, a scheme to solve this problem is required.We hereby require a scheme for reencrypting data even when the owner of the data is absent. However, in the general IBPRE scheme, when there is a data request, a reencryption key is generated using the requestor’s public key and the owner’s private key. Therefore, it is impossible to create a reencryption key in advance because the data owner cannot know the identity of the data requestor before venturing out of the organization. As a result, a reencryption key must be generated whenever there is a data sharing request. However, reencryption is impossible because it is impossible to obtain the other party’s public key and upload the reencryption key from outside the company. We have previously conducted research to solve this problem [27]. In the previous study, we tried to solve by using the group delegation method in a more restrictive environment. However, in previous studies, problems in computational aspects and some improvement in security aspects were required.Therefore, in this study, we propose a scheme that allows the sender to generate a reencryption key through a delegatee. In this process, the group delegation is not used. Additionally, we present a scheme to trace the delegated reencryption key generator to confirm that the delegatee does not abuse the sender’s authority.


## 2.1. Proxy Reencryption

Proxy reencryption is an encryption technology that converts data encrypted with the sender’s public key into data encrypted with the receiver’s public key through a proxy. To this end, the sender generates a reencryption key using his/her own private key and the recipient’s public key of the recipient and delivers it to the proxy. Upon receiving the reencryption key, the proxy reencrypts the sender’s cipher text using the reencryption key to obtain the receiver’s cipher text as shown in Figure1(e) [6–8].Figure 1
Basic form of proxy reencryption.Thereafter, the recipient can obtain the plaintext from the ciphertext using his/her private key. The advantage of proxy reencryption is that the senders can share data without exposing their private keys or the original message to the proxy. Therefore, only the sender and receiver can know the source of the data.IBPRE uses ID-based encryption to encrypt a user’s ID as a public key or derive a public key from an ID. In this manner, a user can identify another user through an ID using a system such as a cloud and share data with the user [9–20]. Basically, proxy reencryption is a technique that allows data encrypted with the key of the data sender to be decrypted by a third party, the receiver, as shown in Figure 2.Figure 2
PRE in the enterprise environment.In 2012, Xu et al. proposed a certificate-free IBPRE [18]. Noncertificate ID-based encryption is a technology that generates a public key through a user’s ID without using a certificate. Therefore, the amount of computation is reduced compared to that in the scheme of generating the certificate. Additionally, it is secure with regards to the key escrow problem and the key exposure problem because the KGC (Key Generate Center) does not generate the key directly [19, 20].As evident from the above algorithm configuration, this scheme assumes a form of traditional 1 : 1 data sharing. Therefore, it is difficult to resolve a situation in which a data owner cannot control data, such as an enterprise environment as covered in this study. However, in this scheme, the existing IBPRE has been applied to present the multiproxy crtificateless proxy reencryption (CL-PRE) and the randomized CL-PRE, which aims at diversity in the traditional IBPRE approach [21, 22].


## 2.2. Proxy Reencryption in the Enterprise Environment

In recent years, an increasing number of companies have begun operating private clouds. The cloud of a company is a technology that enables the storage and use of data produced within the company. It helps to efficiently manage sensitive data for data management and prevention of leakage. In general, it is necessary to distinguish between personal data and public data and even the data generated during work within the company. Therefore, data encryption should be applied in order to prevent other employees from viewing personal business data. Additionally, as encrypted data cannot be decrypted by a third party, the data owner must be able to decrypt the shared user with his or her private key in order to share data with the third party [23, 24]. As a result, the owner’s ciphertext needs to be converted into the requestor’s ciphertext through a process such as proxy reencryption [25, 26].This process follows the IBPRE process described above. Therefore, data inside the company can be securely stored by blocking external access for data security as shown in Figure3.Figure 3
Problem of PRE in the enterprise environment.However, if the data owner is outside the premises of the organization, the data owner may not be able to share data as the owner cannot access the cloud outside the company as shown in Figure3. In this case, the data is not transmitted, which causes a delay. Therefore, a scheme to solve this problem is required.We hereby require a scheme for reencrypting data even when the owner of the data is absent. However, in the general IBPRE scheme, when there is a data request, a reencryption key is generated using the requestor’s public key and the owner’s private key. Therefore, it is impossible to create a reencryption key in advance because the data owner cannot know the identity of the data requestor before venturing out of the organization. As a result, a reencryption key must be generated whenever there is a data sharing request. However, reencryption is impossible because it is impossible to obtain the other party’s public key and upload the reencryption key from outside the company. We have previously conducted research to solve this problem [27]. In the previous study, we tried to solve by using the group delegation method in a more restrictive environment. However, in previous studies, problems in computational aspects and some improvement in security aspects were required.Therefore, in this study, we propose a scheme that allows the sender to generate a reencryption key through a delegatee. In this process, the group delegation is not used. Additionally, we present a scheme to trace the delegated reencryption key generator to confirm that the delegatee does not abuse the sender’s authority.


## 3. System Model

This section describes the necessary mathematical basis before describing the proposed scheme and presents the construction and security requirements accordingly.In this study, the concept of group delegated ID-based proxy reencryption (GD-PRE) is proposed. The form of this concept is shown in Figure4. In the absence of the data owner, another user who has been delegated the owner’s authority creates a delegated reencryption key and can share the data with a third party on behalf of the owner. In this process, the user who has been delegated the owner’s authority cannot know the owner’s private key or the contents of the original data and can only generate the reencryption key for the data designated by the owner. The composition and role of participants in this scheme are described in the next section.Figure 4
System model of GD-PRE.


### 3.1. Role of Participants

#### 3.1.1. KGC (Key Generation Center)

It is an administrator that issues and manages the keys to all participants in the system. In order to use this system, a private key must be issued and registered by the KGC, and the parameters disclosed by the KGC must be used.


#### 3.1.2. Proxy

This is a device that stores user data and performs reencryption upon request. Represented by cloud storage, it responds honestly to user requests, but has the characteristic of honest-but-curious, i.e., wants to know the contents of the data.


#### 3.1.3. Users

Users include all senders, receivers, and delegates who use the system provided by the KGC. Any user can act as a sender, receiver, or delegate group member.


#### 3.1.4. Sender

The sender is the owner of the data. Therefore, after encrypting the data using his/her own public key, they upload to the proxy. Thereafter, a reencryption key is generated according to the receiver’s request, and the reencrypted encrypted text is provided to the receiver through a proxy. In addition, the sender can delegate the authority to generate the reencryption key to another user in case they are absent, and the delegated user is called the delegate group member.


#### 3.1.5. Delegate Group

The delegate group is a group composed of the sender and delegate group member. The delegate group member is a user who has been delegated the authority to generate reencryption keys from the sender. The delegate group member has been delegated some authorities from the sender, but cannot know the sender’s private key or the origin of the message, and can only generate the delegated reencryption key and deliver it to the proxy.


#### 3.1.6. Receiver

The recipient is among the users. Encrypted data can be obtained by requesting data from the sender along with his/her public key. Recipients who have properly obtained data from the sender can decrypt the encrypted data using his/her own private key.


### 3.2. Algorithms of GD-PRE

This section describes the algorithms included in the proposed technique. The algorithms are of ten types and include setup to encryption, decryption, and reencryption. Detailed formulae and explanations for the algorithms are presented in Section4.


#### 3.2.1. Setup (λ)

Algorithm performed by the KGC, the KGC uses the security parameterλ as an input and executes a probability-reducing algorithm that outputs the parameter params shared with all the users, while the master secret key x remains private.


#### 3.2.2. Partial Private Key Extraction (params,x, IDi)

This is the process in which the KGC receives an input from the master secret keyx and the user’s identifier IDi∈0,1∗, outputs the individual partial private key Di that corresponds to the IDi, and sends it securely to the user.


#### 3.2.3. Private Key Generation (params,Di)

Algorithm performed by the user, the user generates a complete private keyski using the partial private key Di received from the KGC. The private key is then kept securely.


#### 3.2.4. Public Key Generation (params, IDi)

Algorithm performed by the user, the user creates a public keypki using params and his/her IDi and distributes this public key pki.


#### 3.2.5. Encryption (params,IDS,pkS,m)

Algorithm performed by the user, the user computes first-level ciphertextCS by encrypting message m by the sender inputting message m∈M and IDS.


#### 3.2.6. Reencryption Key Generation (params,skS,pkR)

Algorithm performed by the sender, the sender generates a reencryption keyRKS→R to delegate CR ciphertext to the receiver. For this purpose, the sender generates a reencryption key RKS→R by using its own private key and public key of the receiver.


#### 3.2.7. Reencryption (params,RKS→R,CS)

Algorithm performed by the proxy, the proxy takes the first-level ciphertextCS and the reencryption key RKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


#### 3.2.8. Group Delegation (params,IDGj)

Algorithm performed by the sender, the sender establishes a delegate groupG who will be delegated the authority to generate his/her reencryption key RKS→R in case he/her are away from the company.


#### 3.2.9. Proxy Delegation (params, IDGj)

Algorithm performed by the sender, the sender adds the valueσ′′ to his ciphertext uploaded to the proxy so that reencryption can be performed by the delegated group member. Through this, the delegated group member can generate the delegated reencryption key DRKS→R instead of the sender even if they do not know the sender’s private key skS.


#### 3.2.10. Delegated Group Member Setup (params,σ′)

Algorithm performed by a delegated group member, each member can obtainv required to generate the delegated reencryption key DRKS→R using the σ′ received from the sender.


#### 3.2.11. Delegated Reencryption Key Generation (params,v,skGj)

Algorithm performed by the delegated group member, the delegated group member generates a delegated reencryption keyDRKS→R for the receiver without the sender’s private key skS. DRKS→R enables the creation of CR by reencrypting the sender’s first-level ciphertext CS.


#### 3.2.12. Delegated Reencryption (params,DRKS→R,CS)

Algorithm performed by the proxy, the proxy receives the first-level ciphertextCS and the delegated reencryption key DRKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


#### 3.2.13. Decryption/Redecryption/Delegated Redecryption (params,CR,skR)

The decryption algorithms are algorithms executed by the owner. When the ciphertextCR and the receiver R’s private key skR are input, the algorithm outputs a message m∈M or an error message.


#### 3.2.14. Trace (params,DRKS→R,IDGj)

Algorithm performed by the sender, the sender can search for the delegated group member who generated the delegated reencryption key on their behalf. For this, the delegated reencryption keyDRKS→R generated by the delegated group member and the delegated group member’s IDGj are used.


### 3.3. Security Requirements

In order to design a more secure GD-IBPRE, there are seven security requirements in this study, which are as follows.


#### 3.3.1. Confidentiality

In all processes, users without data authority must not be able to know the contents of the data. The owner of the data can provide data decryption authority to the user requesting the data through reencryption.


#### 3.3.2. Integrity

In all processes, such as data transfer and storage, data must remain intact. If the contents of the data are changed, the data owner and the user who has access to the data must know that the data has been changed.


#### 3.3.3. Availability

Legitimate users must be able to access stored data in the proxy. To this end, users who access the data must prove that they are legitimate users and must be able to use the desired data at any time.


#### 3.3.4. Access Control

Users who want to access data can use it by showing that they have permission to use it. To do this, one needs to verify the identity of the user, which is accessed by the proxy (cloud) or makes it available only to legitimate users of the data itself.


#### 3.3.5. Forward Secrecy

It should not be possible to obtain the data owner’s private key and personal information using a reencrypted ciphertext or reencrypted key. In addition, it should not be possible to derive a new reencryption key or reencryption statement using the public reencryption key or reencryption statement.


#### 3.3.6. Delegated Reencryption

If the data owner cannot access the data due to absence or other reasons, a delegated group member (delegatee) should be able to reencrypt the data. In this process, the group member must not know the private key of the data owner.


#### 3.3.7. Traceability

The sender delegates the authority to reencrypt his/her data to the delegated group member. However, this privilege can be abused to provide data to unauthorized users. Therefore, the sender must be able to identify the member who abused the authority by identifying who generated the reencryption key among the members of the delegated group.


## 3.1. Role of Participants

### 3.1.1. KGC (Key Generation Center)

It is an administrator that issues and manages the keys to all participants in the system. In order to use this system, a private key must be issued and registered by the KGC, and the parameters disclosed by the KGC must be used.


### 3.1.2. Proxy

This is a device that stores user data and performs reencryption upon request. Represented by cloud storage, it responds honestly to user requests, but has the characteristic of honest-but-curious, i.e., wants to know the contents of the data.


### 3.1.3. Users

Users include all senders, receivers, and delegates who use the system provided by the KGC. Any user can act as a sender, receiver, or delegate group member.


### 3.1.4. Sender

The sender is the owner of the data. Therefore, after encrypting the data using his/her own public key, they upload to the proxy. Thereafter, a reencryption key is generated according to the receiver’s request, and the reencrypted encrypted text is provided to the receiver through a proxy. In addition, the sender can delegate the authority to generate the reencryption key to another user in case they are absent, and the delegated user is called the delegate group member.


### 3.1.5. Delegate Group

The delegate group is a group composed of the sender and delegate group member. The delegate group member is a user who has been delegated the authority to generate reencryption keys from the sender. The delegate group member has been delegated some authorities from the sender, but cannot know the sender’s private key or the origin of the message, and can only generate the delegated reencryption key and deliver it to the proxy.


### 3.1.6. Receiver

The recipient is among the users. Encrypted data can be obtained by requesting data from the sender along with his/her public key. Recipients who have properly obtained data from the sender can decrypt the encrypted data using his/her own private key.


## 3.1.1. KGC (Key Generation Center)

It is an administrator that issues and manages the keys to all participants in the system. In order to use this system, a private key must be issued and registered by the KGC, and the parameters disclosed by the KGC must be used.


## 3.1.2. Proxy

This is a device that stores user data and performs reencryption upon request. Represented by cloud storage, it responds honestly to user requests, but has the characteristic of honest-but-curious, i.e., wants to know the contents of the data.


## 3.1.3. Users

Users include all senders, receivers, and delegates who use the system provided by the KGC. Any user can act as a sender, receiver, or delegate group member.


## 3.1.4. Sender

The sender is the owner of the data. Therefore, after encrypting the data using his/her own public key, they upload to the proxy. Thereafter, a reencryption key is generated according to the receiver’s request, and the reencrypted encrypted text is provided to the receiver through a proxy. In addition, the sender can delegate the authority to generate the reencryption key to another user in case they are absent, and the delegated user is called the delegate group member.


## 3.1.5. Delegate Group

The delegate group is a group composed of the sender and delegate group member. The delegate group member is a user who has been delegated the authority to generate reencryption keys from the sender. The delegate group member has been delegated some authorities from the sender, but cannot know the sender’s private key or the origin of the message, and can only generate the delegated reencryption key and deliver it to the proxy.


## 3.1.6. Receiver

The recipient is among the users. Encrypted data can be obtained by requesting data from the sender along with his/her public key. Recipients who have properly obtained data from the sender can decrypt the encrypted data using his/her own private key.


## 3.2. Algorithms of GD-PRE

This section describes the algorithms included in the proposed technique. The algorithms are of ten types and include setup to encryption, decryption, and reencryption. Detailed formulae and explanations for the algorithms are presented in Section4.


### 3.2.1. Setup (λ)

Algorithm performed by the KGC, the KGC uses the security parameterλ as an input and executes a probability-reducing algorithm that outputs the parameter params shared with all the users, while the master secret key x remains private.


### 3.2.2. Partial Private Key Extraction (params,x, IDi)

This is the process in which the KGC receives an input from the master secret keyx and the user’s identifier IDi∈0,1∗, outputs the individual partial private key Di that corresponds to the IDi, and sends it securely to the user.


### 3.2.3. Private Key Generation (params,Di)

Algorithm performed by the user, the user generates a complete private keyski using the partial private key Di received from the KGC. The private key is then kept securely.


### 3.2.4. Public Key Generation (params, IDi)

Algorithm performed by the user, the user creates a public keypki using params and his/her IDi and distributes this public key pki.


### 3.2.5. Encryption (params,IDS,pkS,m)

Algorithm performed by the user, the user computes first-level ciphertextCS by encrypting message m by the sender inputting message m∈M and IDS.


### 3.2.6. Reencryption Key Generation (params,skS,pkR)

Algorithm performed by the sender, the sender generates a reencryption keyRKS→R to delegate CR ciphertext to the receiver. For this purpose, the sender generates a reencryption key RKS→R by using its own private key and public key of the receiver.


### 3.2.7. Reencryption (params,RKS→R,CS)

Algorithm performed by the proxy, the proxy takes the first-level ciphertextCS and the reencryption key RKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


### 3.2.8. Group Delegation (params,IDGj)

Algorithm performed by the sender, the sender establishes a delegate groupG who will be delegated the authority to generate his/her reencryption key RKS→R in case he/her are away from the company.


### 3.2.9. Proxy Delegation (params, IDGj)

Algorithm performed by the sender, the sender adds the valueσ′′ to his ciphertext uploaded to the proxy so that reencryption can be performed by the delegated group member. Through this, the delegated group member can generate the delegated reencryption key DRKS→R instead of the sender even if they do not know the sender’s private key skS.


### 3.2.10. Delegated Group Member Setup (params,σ′)

Algorithm performed by a delegated group member, each member can obtainv required to generate the delegated reencryption key DRKS→R using the σ′ received from the sender.


### 3.2.11. Delegated Reencryption Key Generation (params,v,skGj)

Algorithm performed by the delegated group member, the delegated group member generates a delegated reencryption keyDRKS→R for the receiver without the sender’s private key skS. DRKS→R enables the creation of CR by reencrypting the sender’s first-level ciphertext CS.


### 3.2.12. Delegated Reencryption (params,DRKS→R,CS)

Algorithm performed by the proxy, the proxy receives the first-level ciphertextCS and the delegated reencryption key DRKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


### 3.2.13. Decryption/Redecryption/Delegated Redecryption (params,CR,skR)

The decryption algorithms are algorithms executed by the owner. When the ciphertextCR and the receiver R’s private key skR are input, the algorithm outputs a message m∈M or an error message.


### 3.2.14. Trace (params,DRKS→R,IDGj)

Algorithm performed by the sender, the sender can search for the delegated group member who generated the delegated reencryption key on their behalf. For this, the delegated reencryption keyDRKS→R generated by the delegated group member and the delegated group member’s IDGj are used.


## 3.2.1. Setup (λ)

Algorithm performed by the KGC, the KGC uses the security parameterλ as an input and executes a probability-reducing algorithm that outputs the parameter params shared with all the users, while the master secret key x remains private.


## 3.2.2. Partial Private Key Extraction (params,x, IDi)

This is the process in which the KGC receives an input from the master secret keyx and the user’s identifier IDi∈0,1∗, outputs the individual partial private key Di that corresponds to the IDi, and sends it securely to the user.


## 3.2.3. Private Key Generation (params,Di)

Algorithm performed by the user, the user generates a complete private keyski using the partial private key Di received from the KGC. The private key is then kept securely.


## 3.2.4. Public Key Generation (params, IDi)

Algorithm performed by the user, the user creates a public keypki using params and his/her IDi and distributes this public key pki.


## 3.2.5. Encryption (params,IDS,pkS,m)

Algorithm performed by the user, the user computes first-level ciphertextCS by encrypting message m by the sender inputting message m∈M and IDS.


## 3.2.6. Reencryption Key Generation (params,skS,pkR)

Algorithm performed by the sender, the sender generates a reencryption keyRKS→R to delegate CR ciphertext to the receiver. For this purpose, the sender generates a reencryption key RKS→R by using its own private key and public key of the receiver.


## 3.2.7. Reencryption (params,RKS→R,CS)

Algorithm performed by the proxy, the proxy takes the first-level ciphertextCS and the reencryption key RKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


## 3.2.8. Group Delegation (params,IDGj)

Algorithm performed by the sender, the sender establishes a delegate groupG who will be delegated the authority to generate his/her reencryption key RKS→R in case he/her are away from the company.


## 3.2.9. Proxy Delegation (params, IDGj)

Algorithm performed by the sender, the sender adds the valueσ′′ to his ciphertext uploaded to the proxy so that reencryption can be performed by the delegated group member. Through this, the delegated group member can generate the delegated reencryption key DRKS→R instead of the sender even if they do not know the sender’s private key skS.


## 3.2.10. Delegated Group Member Setup (params,σ′)

Algorithm performed by a delegated group member, each member can obtainv required to generate the delegated reencryption key DRKS→R using the σ′ received from the sender.


## 3.2.11. Delegated Reencryption Key Generation (params,v,skGj)

Algorithm performed by the delegated group member, the delegated group member generates a delegated reencryption keyDRKS→R for the receiver without the sender’s private key skS. DRKS→R enables the creation of CR by reencrypting the sender’s first-level ciphertext CS.


## 3.2.12. Delegated Reencryption (params,DRKS→R,CS)

Algorithm performed by the proxy, the proxy receives the first-level ciphertextCS and the delegated reencryption key DRKS→R as input and outputs a reencrypted ciphertext CR, called the second-level ciphertext.


## 3.2.13. Decryption/Redecryption/Delegated Redecryption (params,CR,skR)

The decryption algorithms are algorithms executed by the owner. When the ciphertextCR and the receiver R’s private key skR are input, the algorithm outputs a message m∈M or an error message.


## 3.2.14. Trace (params,DRKS→R,IDGj)

Algorithm performed by the sender, the sender can search for the delegated group member who generated the delegated reencryption key on their behalf. For this, the delegated reencryption keyDRKS→R generated by the delegated group member and the delegated group member’s IDGj are used.


## 3.3. Security Requirements

In order to design a more secure GD-IBPRE, there are seven security requirements in this study, which are as follows.


### 3.3.1. Confidentiality

In all processes, users without data authority must not be able to know the contents of the data. The owner of the data can provide data decryption authority to the user requesting the data through reencryption.


### 3.3.2. Integrity

In all processes, such as data transfer and storage, data must remain intact. If the contents of the data are changed, the data owner and the user who has access to the data must know that the data has been changed.


### 3.3.3. Availability

Legitimate users must be able to access stored data in the proxy. To this end, users who access the data must prove that they are legitimate users and must be able to use the desired data at any time.


### 3.3.4. Access Control

Users who want to access data can use it by showing that they have permission to use it. To do this, one needs to verify the identity of the user, which is accessed by the proxy (cloud) or makes it available only to legitimate users of the data itself.


### 3.3.5. Forward Secrecy

It should not be possible to obtain the data owner’s private key and personal information using a reencrypted ciphertext or reencrypted key. In addition, it should not be possible to derive a new reencryption key or reencryption statement using the public reencryption key or reencryption statement.


### 3.3.6. Delegated Reencryption

If the data owner cannot access the data due to absence or other reasons, a delegated group member (delegatee) should be able to reencrypt the data. In this process, the group member must not know the private key of the data owner.


### 3.3.7. Traceability

The sender delegates the authority to reencrypt his/her data to the delegated group member. However, this privilege can be abused to provide data to unauthorized users. Therefore, the sender must be able to identify the member who abused the authority by identifying who generated the reencryption key among the members of the delegated group.


## 3.3.1. Confidentiality

In all processes, users without data authority must not be able to know the contents of the data. The owner of the data can provide data decryption authority to the user requesting the data through reencryption.


## 3.3.2. Integrity

In all processes, such as data transfer and storage, data must remain intact. If the contents of the data are changed, the data owner and the user who has access to the data must know that the data has been changed.


## 3.3.3. Availability

Legitimate users must be able to access stored data in the proxy. To this end, users who access the data must prove that they are legitimate users and must be able to use the desired data at any time.


## 3.3.4. Access Control

Users who want to access data can use it by showing that they have permission to use it. To do this, one needs to verify the identity of the user, which is accessed by the proxy (cloud) or makes it available only to legitimate users of the data itself.


## 3.3.5. Forward Secrecy

It should not be possible to obtain the data owner’s private key and personal information using a reencrypted ciphertext or reencrypted key. In addition, it should not be possible to derive a new reencryption key or reencryption statement using the public reencryption key or reencryption statement.


## 3.3.6. Delegated Reencryption

If the data owner cannot access the data due to absence or other reasons, a delegated group member (delegatee) should be able to reencrypt the data. In this process, the group member must not know the private key of the data owner.


## 3.3.7. Traceability

The sender delegates the authority to reencrypt his/her data to the delegated group member. However, this privilege can be abused to provide data to unauthorized users. Therefore, the sender must be able to identify the member who abused the authority by identifying who generated the reencryption key among the members of the delegated group.


## 4. Proposed Scheme

This section describes the proposed scheme. For this, first, the system parameters are described. Subsequently, detailed equations and explanations for this proposed scheme are presented.


### 4.1. System Parameters

The parameters and functions used in the proposed scheme are as follows.Ui: user i (Ui∈U)S: sender (S∈U)R: receiver (R∈U)k: number of delegated group G membersGj: delegated group member j (Gj∈U)G: delegated group (G=U1,⋯Uk)ID∗: identifier of userG1,G2: circulation group on prime pG1×G1→G2: bilinear mappingH1:hash function 0,1∗→G1H2:hash function G2→G1H3−H4: hash function 0,1∗→ℤq∗H5: hash function 0,1∗→0,1l1+l2x: master key of KGCDi: partial private key of user Ui created by KGCski: user Ui’s complete private keypki: user Ui’s public keyRKS→R: reencryption key to reencrypt S’s ciphertext to R’s ciphertextDRKS→R: delegated reencryption key created by delegated group memberm: plaintextCi: ciphertext of user UiEnc∗·: data encryption algorithm (explained in 4.2.2 Data Storing Phase)Dec∗·: data decryption algorithm (explained in 4.2.2 Data Storing Phase)


### 4.2. Proposed GD-PRE Scheme

The algorithm composition of the proposed scheme and each role described in Section3.1.3 are shown in Figures 5 and 6. Each algorithm can be classified into a key generation, group delegation, data storing, data sharing, and delegated data sharing phase according to the role and procedure. The detailed procedure is as follows.Figure 5
System flow of data storing and sharing phase.Figure 6
System flow of initialize of the group delegation phase and delegated data sharing phase.


#### 4.2.1. Key Generation Phase

First, with the given security parameterλ, the KGC sets the common and secret parameters. Thereafter, each user receives a public key and a private key from the KGC using a common parameter.(1) Setup. Let G1,G2 be two cyclic groups of prime order q and e:G1×G1→G2 be a bilinear map. Set the two λ-bit integers l1,l2 and the message space M∈0,1l1. A random generator g∈G1 is chosen. The KGC randomly picks an integer x∈ℤq∗ as the master key and publishes params=G1,G2,e,H1,H2,H3,gx,g,λ,l1,l2 .(2) Partial Private Key Extraction. User Ui sends his/her identity IDi to the KGC. The KGC calculates gi=H1IDi,Di=gix using IDi and the master key x and sends user Ui’s partial private key Di to user Ui. The same operation continues with the other users.(3) Private Key Generation. User Ui randomly selects di∈ℤq∗ and keeps secret and computes his/her private key ski:
(1)ski←Didi=gix·di.(4) Public Key Generation. User Ui computes his/her public key pki:
(2)pki=gi,gx·di.The user creates a public keypki using params and his/her IDi and distributes this public key pki. User Ui publishes pki, and anyone can use pki to provide ciphertext to user Ui. When the key generation phase is completed, the users who want to form the group perform the initialize of the group delegation phase described in Section 4.2.4.


#### 4.2.2. Data Storing Phase

In this phase, the sender encrypts the data using his/her own public key and stores it in the proxy as shown in Figure5. After that, the sender can obtain his ciphertext uploaded to the proxy and decrypt it with his/her own private key.(1) Encryption. Sender S selects a random integer r∈ℤq∗ and the public key pki of the target Ui and calculates the message m∈G2 as a ciphertext that can only decrypt Ui as follows:
(3)c1←gr,c2←m·egir,gxdi.As a result, the ciphertext becomesCi=c1,c2. In this proposed environment, sender S creates CS using his public key and uploads CS to proxy.(2) Decryption. User Ui can download the Ci stored in the proxy and decrypt it using his/her private key ski as follows.
(4)Ci=c1,c2,m←c2/eski,c1=m·egir,gx·di/egix·di,gr=m·egi,gr·x·di/egi,gr·x·di.


#### 4.2.3. Data Sharing Phase

This phase is performed when the sender uploads the ciphertext to the proxy and then the receiver requests data. In this phase, the sender who receives the request from the receiver generates a reencryption key using his/her private key and the receiver’s public key and delivers it to the proxy. The proxy receiving the reencryption key may obtain the receiver’s cipher text by reencrypting the sender’s ciphertext with the reencryption key as shown in Figure5.(1) Reencryption Key Generation. The sender S receiving the request of the recipient R selects random value π∈G2 and t∈ℤq∗. Then, the reencryption key RKS→R is generated for converting CS to CR.
(5)CRπ←EncpkRπ,RKS→R←gS−x·dS·H2tπ,CRπ,gtr.RKS→R is then sent to the proxy by sender S.(2) Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using the ciphertext CS and the reencryption key RKS→R of sender S.
(6)c1←gtr,c2′←c2/egS−x·dS·H2tπ,c1=m·eH2tπ,gr,c3←CRπ=EncpkRπ.CR=c1,c2′,c3 is then sent to receiver R by proxy.If senderS cannot access the proxy, any member of group G can perform the 4.2.5 delegated data sharing phase on behalf of the sender S.(3) Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain w=DecskRc4. Finally, receiver R can compute the plaintext m.
(7)CR←c1,c2′,c3,m←c2′/eH2π,c1=m·eH2tπ,greH2π,gtr.


#### 4.2.4. Initialize of the Group Delegation Phase

In this phase, the sender generates and transmits a value to the proxy and the delegates who will generate the reencryption key on their behalf, as shown in Figure6.(1) Group Delegation. Sender S sets up the delegate group G=G1,⋯,GkGk∈Ui to delegate its authority. Sender S randomly selects a,δ∈ℤq∗ and w∈0,1l2 and computes ga,z.(8)v←t∙δ,z←H3s,w,ga.Then, senderS computes Li and yj for j=1,2,⋯,k.
(9)Lj←egja,gx∙dj.yj←H4z,Li,ga.SenderS computes fx and E and outputs σ.
(10)f1x←∏j=1kx−yj+s=xn+gn−1′sn−1+⋯+g1′x1+g0′,E←H5s,z,ga⊕v∥w,σ′=E,ga,z,gn−1′,⋯,g1′,g0′.SenderS sends sender S uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the delegated group members.(2) Proxy Delegation. Sender S uploads an additional value σ′′ to the proxy to enable delegate reencryption. σ′′ is a value that enables the proxy to be reencrypted by the delegated group member.
(11)Tj←H4H3egja,gx∙dj,gj,f2x←∏j=1kx−Tj+γ=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′,c4←γgS−x·dS∙δ,grδ,σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′.SenderS uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the proxy.


#### 4.2.5. Delegated Data Sharing Phase

When the sender leaves the company due to a business trip, etc., they can add the delegation information to the data, which is to be delegated to the concerned authority. Thereafter, when the sender is absent, the delegated group member can generate a delegation reencryption key using the delegated information on behalf of the sender and provide the reencrypted data to the receiver as shown in Figure6.(1) Delegated Group Member Setup. Sender S sends σ′ to all delegate group members. And each group member Gj constructs fx and obtains m using σ′=E,ga,z,gn−1,⋯,g1,g0 as follows:
(12)fx=xn+gn−1sn−1+⋯+g1x1+g0=∏j=1kx−yj+s,Lj←egjx∙dj,ga,yj←H4z,Li,ga,s←fyj=∏j=1kyj−yj+s,v∥w←H5s,z,ga⊕E.Each group memberGj checks z as follows:
(13)z=?H3s,w,ga.(2) Delegated Reencryption Key Generation. Group member Gj generates a delegated reencryption key DRKS→R using the acquired v.
(14)c3←CRπ=EncpkRπ,DRKS→R=c3,H2vπ,H3egja,gx∙dj.DRKS→R is then sent to the proxy by one of group member Gj.(3) Delegated Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using ciphertext CS and the delegated reencryption key DRKS→R=c3,H2vπ,H3egja,gx∙dj of sender S.
(15)CS=c1,c2=gr,m·egSr,gx∙dS,Tj←H4H3egja,gx∙dj,H1IDj,f2x=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′=∏j=1kx−Tj+γ,γ←f2Tj=∏j=1kTj−Tj+γ,c1←gtr,c2′←c2·eγgS−x·dS∙δγ∙H2vπ,grδ=c2·egS−x·dS∙δ∙H2t∙δπ,grδ=c2·egS−x·dS∙H2tπ,grδδ=m·egSr,gx∙dS·egS−x·dS∙H2tπ,gr=m·eH2tπ,gr,c3=CRπ=EncpkRπ,CR=c1,c2′,c3.CR=c1,c2′,c3 is then sent to receiver R by the proxy.(4) Delegated Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain ω. Finally, receiver R can compute the plaintext m.
(16)CR=c1,c2′,c3,ω=DecskRc3,m←c3′/eH3ω,c1=m·eH3tω,greH3ω,gtr.(5) Trace. If illegal generation of the delegated reencryption key is confirmed, sender S can browse the information of the group member who generated the delegated reencryption key. To do this, sender S creates γ using the IDs of all members in the group. In this process, if the ID of the user who created the delegated reencryption key DRKS→R is used, the correct γ is created, and the perpetrator can be identified through this.
(17)G?=DRKS→R=c3,H2vπ,H3eg?a,gx∙d?,findγ=?T?←H4H3eg?a,gx∙d?,H1IDjforj=1,⋯,k.


## 4.1. System Parameters

The parameters and functions used in the proposed scheme are as follows.Ui: user i (Ui∈U)S: sender (S∈U)R: receiver (R∈U)k: number of delegated group G membersGj: delegated group member j (Gj∈U)G: delegated group (G=U1,⋯Uk)ID∗: identifier of userG1,G2: circulation group on prime pG1×G1→G2: bilinear mappingH1:hash function 0,1∗→G1H2:hash function G2→G1H3−H4: hash function 0,1∗→ℤq∗H5: hash function 0,1∗→0,1l1+l2x: master key of KGCDi: partial private key of user Ui created by KGCski: user Ui’s complete private keypki: user Ui’s public keyRKS→R: reencryption key to reencrypt S’s ciphertext to R’s ciphertextDRKS→R: delegated reencryption key created by delegated group memberm: plaintextCi: ciphertext of user UiEnc∗·: data encryption algorithm (explained in 4.2.2 Data Storing Phase)Dec∗·: data decryption algorithm (explained in 4.2.2 Data Storing Phase)


## 4.2. Proposed GD-PRE Scheme

The algorithm composition of the proposed scheme and each role described in Section3.1.3 are shown in Figures 5 and 6. Each algorithm can be classified into a key generation, group delegation, data storing, data sharing, and delegated data sharing phase according to the role and procedure. The detailed procedure is as follows.Figure 5
System flow of data storing and sharing phase.Figure 6
System flow of initialize of the group delegation phase and delegated data sharing phase.


### 4.2.1. Key Generation Phase

First, with the given security parameterλ, the KGC sets the common and secret parameters. Thereafter, each user receives a public key and a private key from the KGC using a common parameter.(1) Setup. Let G1,G2 be two cyclic groups of prime order q and e:G1×G1→G2 be a bilinear map. Set the two λ-bit integers l1,l2 and the message space M∈0,1l1. A random generator g∈G1 is chosen. The KGC randomly picks an integer x∈ℤq∗ as the master key and publishes params=G1,G2,e,H1,H2,H3,gx,g,λ,l1,l2 .(2) Partial Private Key Extraction. User Ui sends his/her identity IDi to the KGC. The KGC calculates gi=H1IDi,Di=gix using IDi and the master key x and sends user Ui’s partial private key Di to user Ui. The same operation continues with the other users.(3) Private Key Generation. User Ui randomly selects di∈ℤq∗ and keeps secret and computes his/her private key ski:
(1)ski←Didi=gix·di.(4) Public Key Generation. User Ui computes his/her public key pki:
(2)pki=gi,gx·di.The user creates a public keypki using params and his/her IDi and distributes this public key pki. User Ui publishes pki, and anyone can use pki to provide ciphertext to user Ui. When the key generation phase is completed, the users who want to form the group perform the initialize of the group delegation phase described in Section 4.2.4.


### 4.2.2. Data Storing Phase

In this phase, the sender encrypts the data using his/her own public key and stores it in the proxy as shown in Figure5. After that, the sender can obtain his ciphertext uploaded to the proxy and decrypt it with his/her own private key.(1) Encryption. Sender S selects a random integer r∈ℤq∗ and the public key pki of the target Ui and calculates the message m∈G2 as a ciphertext that can only decrypt Ui as follows:
(3)c1←gr,c2←m·egir,gxdi.As a result, the ciphertext becomesCi=c1,c2. In this proposed environment, sender S creates CS using his public key and uploads CS to proxy.(2) Decryption. User Ui can download the Ci stored in the proxy and decrypt it using his/her private key ski as follows.
(4)Ci=c1,c2,m←c2/eski,c1=m·egir,gx·di/egix·di,gr=m·egi,gr·x·di/egi,gr·x·di.


### 4.2.3. Data Sharing Phase

This phase is performed when the sender uploads the ciphertext to the proxy and then the receiver requests data. In this phase, the sender who receives the request from the receiver generates a reencryption key using his/her private key and the receiver’s public key and delivers it to the proxy. The proxy receiving the reencryption key may obtain the receiver’s cipher text by reencrypting the sender’s ciphertext with the reencryption key as shown in Figure5.(1) Reencryption Key Generation. The sender S receiving the request of the recipient R selects random value π∈G2 and t∈ℤq∗. Then, the reencryption key RKS→R is generated for converting CS to CR.
(5)CRπ←EncpkRπ,RKS→R←gS−x·dS·H2tπ,CRπ,gtr.RKS→R is then sent to the proxy by sender S.(2) Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using the ciphertext CS and the reencryption key RKS→R of sender S.
(6)c1←gtr,c2′←c2/egS−x·dS·H2tπ,c1=m·eH2tπ,gr,c3←CRπ=EncpkRπ.CR=c1,c2′,c3 is then sent to receiver R by proxy.If senderS cannot access the proxy, any member of group G can perform the 4.2.5 delegated data sharing phase on behalf of the sender S.(3) Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain w=DecskRc4. Finally, receiver R can compute the plaintext m.
(7)CR←c1,c2′,c3,m←c2′/eH2π,c1=m·eH2tπ,greH2π,gtr.


### 4.2.4. Initialize of the Group Delegation Phase

In this phase, the sender generates and transmits a value to the proxy and the delegates who will generate the reencryption key on their behalf, as shown in Figure6.(1) Group Delegation. Sender S sets up the delegate group G=G1,⋯,GkGk∈Ui to delegate its authority. Sender S randomly selects a,δ∈ℤq∗ and w∈0,1l2 and computes ga,z.(8)v←t∙δ,z←H3s,w,ga.Then, senderS computes Li and yj for j=1,2,⋯,k.
(9)Lj←egja,gx∙dj.yj←H4z,Li,ga.SenderS computes fx and E and outputs σ.
(10)f1x←∏j=1kx−yj+s=xn+gn−1′sn−1+⋯+g1′x1+g0′,E←H5s,z,ga⊕v∥w,σ′=E,ga,z,gn−1′,⋯,g1′,g0′.SenderS sends sender S uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the delegated group members.(2) Proxy Delegation. Sender S uploads an additional value σ′′ to the proxy to enable delegate reencryption. σ′′ is a value that enables the proxy to be reencrypted by the delegated group member.
(11)Tj←H4H3egja,gx∙dj,gj,f2x←∏j=1kx−Tj+γ=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′,c4←γgS−x·dS∙δ,grδ,σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′.SenderS uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the proxy.


### 4.2.5. Delegated Data Sharing Phase

When the sender leaves the company due to a business trip, etc., they can add the delegation information to the data, which is to be delegated to the concerned authority. Thereafter, when the sender is absent, the delegated group member can generate a delegation reencryption key using the delegated information on behalf of the sender and provide the reencrypted data to the receiver as shown in Figure6.(1) Delegated Group Member Setup. Sender S sends σ′ to all delegate group members. And each group member Gj constructs fx and obtains m using σ′=E,ga,z,gn−1,⋯,g1,g0 as follows:
(12)fx=xn+gn−1sn−1+⋯+g1x1+g0=∏j=1kx−yj+s,Lj←egjx∙dj,ga,yj←H4z,Li,ga,s←fyj=∏j=1kyj−yj+s,v∥w←H5s,z,ga⊕E.Each group memberGj checks z as follows:
(13)z=?H3s,w,ga.(2) Delegated Reencryption Key Generation. Group member Gj generates a delegated reencryption key DRKS→R using the acquired v.
(14)c3←CRπ=EncpkRπ,DRKS→R=c3,H2vπ,H3egja,gx∙dj.DRKS→R is then sent to the proxy by one of group member Gj.(3) Delegated Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using ciphertext CS and the delegated reencryption key DRKS→R=c3,H2vπ,H3egja,gx∙dj of sender S.
(15)CS=c1,c2=gr,m·egSr,gx∙dS,Tj←H4H3egja,gx∙dj,H1IDj,f2x=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′=∏j=1kx−Tj+γ,γ←f2Tj=∏j=1kTj−Tj+γ,c1←gtr,c2′←c2·eγgS−x·dS∙δγ∙H2vπ,grδ=c2·egS−x·dS∙δ∙H2t∙δπ,grδ=c2·egS−x·dS∙H2tπ,grδδ=m·egSr,gx∙dS·egS−x·dS∙H2tπ,gr=m·eH2tπ,gr,c3=CRπ=EncpkRπ,CR=c1,c2′,c3.CR=c1,c2′,c3 is then sent to receiver R by the proxy.(4) Delegated Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain ω. Finally, receiver R can compute the plaintext m.
(16)CR=c1,c2′,c3,ω=DecskRc3,m←c3′/eH3ω,c1=m·eH3tω,greH3ω,gtr.(5) Trace. If illegal generation of the delegated reencryption key is confirmed, sender S can browse the information of the group member who generated the delegated reencryption key. To do this, sender S creates γ using the IDs of all members in the group. In this process, if the ID of the user who created the delegated reencryption key DRKS→R is used, the correct γ is created, and the perpetrator can be identified through this.
(17)G?=DRKS→R=c3,H2vπ,H3eg?a,gx∙d?,findγ=?T?←H4H3eg?a,gx∙d?,H1IDjforj=1,⋯,k.


## 4.2.1. Key Generation Phase

First, with the given security parameterλ, the KGC sets the common and secret parameters. Thereafter, each user receives a public key and a private key from the KGC using a common parameter.(1) Setup. Let G1,G2 be two cyclic groups of prime order q and e:G1×G1→G2 be a bilinear map. Set the two λ-bit integers l1,l2 and the message space M∈0,1l1. A random generator g∈G1 is chosen. The KGC randomly picks an integer x∈ℤq∗ as the master key and publishes params=G1,G2,e,H1,H2,H3,gx,g,λ,l1,l2 .(2) Partial Private Key Extraction. User Ui sends his/her identity IDi to the KGC. The KGC calculates gi=H1IDi,Di=gix using IDi and the master key x and sends user Ui’s partial private key Di to user Ui. The same operation continues with the other users.(3) Private Key Generation. User Ui randomly selects di∈ℤq∗ and keeps secret and computes his/her private key ski:
(1)ski←Didi=gix·di.(4) Public Key Generation. User Ui computes his/her public key pki:
(2)pki=gi,gx·di.The user creates a public keypki using params and his/her IDi and distributes this public key pki. User Ui publishes pki, and anyone can use pki to provide ciphertext to user Ui. When the key generation phase is completed, the users who want to form the group perform the initialize of the group delegation phase described in Section 4.2.4.


## 4.2.2. Data Storing Phase

In this phase, the sender encrypts the data using his/her own public key and stores it in the proxy as shown in Figure5. After that, the sender can obtain his ciphertext uploaded to the proxy and decrypt it with his/her own private key.(1) Encryption. Sender S selects a random integer r∈ℤq∗ and the public key pki of the target Ui and calculates the message m∈G2 as a ciphertext that can only decrypt Ui as follows:
(3)c1←gr,c2←m·egir,gxdi.As a result, the ciphertext becomesCi=c1,c2. In this proposed environment, sender S creates CS using his public key and uploads CS to proxy.(2) Decryption. User Ui can download the Ci stored in the proxy and decrypt it using his/her private key ski as follows.
(4)Ci=c1,c2,m←c2/eski,c1=m·egir,gx·di/egix·di,gr=m·egi,gr·x·di/egi,gr·x·di.


## 4.2.3. Data Sharing Phase

This phase is performed when the sender uploads the ciphertext to the proxy and then the receiver requests data. In this phase, the sender who receives the request from the receiver generates a reencryption key using his/her private key and the receiver’s public key and delivers it to the proxy. The proxy receiving the reencryption key may obtain the receiver’s cipher text by reencrypting the sender’s ciphertext with the reencryption key as shown in Figure5.(1) Reencryption Key Generation. The sender S receiving the request of the recipient R selects random value π∈G2 and t∈ℤq∗. Then, the reencryption key RKS→R is generated for converting CS to CR.
(5)CRπ←EncpkRπ,RKS→R←gS−x·dS·H2tπ,CRπ,gtr.RKS→R is then sent to the proxy by sender S.(2) Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using the ciphertext CS and the reencryption key RKS→R of sender S.
(6)c1←gtr,c2′←c2/egS−x·dS·H2tπ,c1=m·eH2tπ,gr,c3←CRπ=EncpkRπ.CR=c1,c2′,c3 is then sent to receiver R by proxy.If senderS cannot access the proxy, any member of group G can perform the 4.2.5 delegated data sharing phase on behalf of the sender S.(3) Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain w=DecskRc4. Finally, receiver R can compute the plaintext m.
(7)CR←c1,c2′,c3,m←c2′/eH2π,c1=m·eH2tπ,greH2π,gtr.


## 4.2.4. Initialize of the Group Delegation Phase

In this phase, the sender generates and transmits a value to the proxy and the delegates who will generate the reencryption key on their behalf, as shown in Figure6.(1) Group Delegation. Sender S sets up the delegate group G=G1,⋯,GkGk∈Ui to delegate its authority. Sender S randomly selects a,δ∈ℤq∗ and w∈0,1l2 and computes ga,z.(8)v←t∙δ,z←H3s,w,ga.Then, senderS computes Li and yj for j=1,2,⋯,k.
(9)Lj←egja,gx∙dj.yj←H4z,Li,ga.SenderS computes fx and E and outputs σ.
(10)f1x←∏j=1kx−yj+s=xn+gn−1′sn−1+⋯+g1′x1+g0′,E←H5s,z,ga⊕v∥w,σ′=E,ga,z,gn−1′,⋯,g1′,g0′.SenderS sends sender S uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the delegated group members.(2) Proxy Delegation. Sender S uploads an additional value σ′′ to the proxy to enable delegate reencryption. σ′′ is a value that enables the proxy to be reencrypted by the delegated group member.
(11)Tj←H4H3egja,gx∙dj,gj,f2x←∏j=1kx−Tj+γ=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′,c4←γgS−x·dS∙δ,grδ,σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′.SenderS uploads σ′′=c4,gtr,gn−1′′,⋯,g1′′,g0′′ to the proxy.


## 4.2.5. Delegated Data Sharing Phase

When the sender leaves the company due to a business trip, etc., they can add the delegation information to the data, which is to be delegated to the concerned authority. Thereafter, when the sender is absent, the delegated group member can generate a delegation reencryption key using the delegated information on behalf of the sender and provide the reencrypted data to the receiver as shown in Figure6.(1) Delegated Group Member Setup. Sender S sends σ′ to all delegate group members. And each group member Gj constructs fx and obtains m using σ′=E,ga,z,gn−1,⋯,g1,g0 as follows:
(12)fx=xn+gn−1sn−1+⋯+g1x1+g0=∏j=1kx−yj+s,Lj←egjx∙dj,ga,yj←H4z,Li,ga,s←fyj=∏j=1kyj−yj+s,v∥w←H5s,z,ga⊕E.Each group memberGj checks z as follows:
(13)z=?H3s,w,ga.(2) Delegated Reencryption Key Generation. Group member Gj generates a delegated reencryption key DRKS→R using the acquired v.
(14)c3←CRπ=EncpkRπ,DRKS→R=c3,H2vπ,H3egja,gx∙dj.DRKS→R is then sent to the proxy by one of group member Gj.(3) Delegated Reencryption. The proxy generates the reencrypted ciphertext CR using the following operation using ciphertext CS and the delegated reencryption key DRKS→R=c3,H2vπ,H3egja,gx∙dj of sender S.
(15)CS=c1,c2=gr,m·egSr,gx∙dS,Tj←H4H3egja,gx∙dj,H1IDj,f2x=xn+gn−1′′sn−1+⋯+g1′′x1+g0′′=∏j=1kx−Tj+γ,γ←f2Tj=∏j=1kTj−Tj+γ,c1←gtr,c2′←c2·eγgS−x·dS∙δγ∙H2vπ,grδ=c2·egS−x·dS∙δ∙H2t∙δπ,grδ=c2·egS−x·dS∙H2tπ,grδδ=m·egSr,gx∙dS·egS−x·dS∙H2tπ,gr=m·eH2tπ,gr,c3=CRπ=EncpkRπ,CR=c1,c2′,c3.CR=c1,c2′,c3 is then sent to receiver R by the proxy.(4) Delegated Redecryption. Receiver R decrypts a ciphertext CR received from a proxy by using his/her private key skR to obtain ω. Finally, receiver R can compute the plaintext m.
(16)CR=c1,c2′,c3,ω=DecskRc3,m←c3′/eH3ω,c1=m·eH3tω,greH3ω,gtr.(5) Trace. If illegal generation of the delegated reencryption key is confirmed, sender S can browse the information of the group member who generated the delegated reencryption key. To do this, sender S creates γ using the IDs of all members in the group. In this process, if the ID of the user who created the delegated reencryption key DRKS→R is used, the correct γ is created, and the perpetrator can be identified through this.
(17)G?=DRKS→R=c3,H2vπ,H3eg?a,gx∙d?,findγ=?T?←H4H3eg?a,gx∙d?,H1IDjforj=1,⋯,k.


## 5. Analysis of Proposed Scheme

This section analyzes the proposed scheme and explains the results. We analyze the achievement of the proposed scheme with respect to the security requirements and then the efficiency.


### 5.1. Analysis of Security Requirements

This section analyzes whether the proposed scheme meets the security requirements.


#### 5.1.1. Confidentiality

The owner of the data encrypts the data source m with his/her public keypki, converts it to Ci, and uploads it before uploading the data to the proxy. In addition, the decryption of the encrypted data must use the private key ski corresponding to the public key pki used for data encryption. The decryption operation is as follows, and the data source m can be obtained through the decryption operation.
(18)m=?c3eski,c1=m·egi,gx·diregix·di,gr=m·egi,gx·di·regi,gx·di·r.


#### 5.1.2. Integrity

The ciphertextCi stored in the proxy consists of Ci=c1,c2. c1 is necessary for decrypting c2, and if c1or c2 is tampered with, the data owner cannot confirm that the source data is correct, and thus the data is tampered with.


#### 5.1.3. Availability

SenderS can decrypt data using his/her private key skS, and receiver R can decrypt ciphertext CS with his/her private key skR as follows.
(19)m←c3eskS,c1=m·egS,gx·dSregSx·dS,gr=m·egS,gx·dS·regS,gx·dS·r.


#### 5.1.4. Access Control

SenderS stores their generated ciphertext in a proxy. Thereafter, when another user requests the use of the data, the sender S can generate a reencryption key RKS→R by combining his/her private key and the receiver R’s public key. The generated reencryption key RKS→R is transmitted to the proxy to generate a ciphertext CR that the receiver R can decrypt as follows.
(20)c3′←m·egS,gx·dSregS−x·dS·H2tω,c1=m·egSx·dS,gregS−x·dS·H2tω,gr=m·egSx·dS·gS−x·dS·H2tω,gr=m·eH2tω,gr.Thereafter, the receiver who has received the reencrypted dataCR can obtain the data source by decrypting the corresponding ciphertext with his/her private key skR.
(21)m←c2′eH3ω,c2=m·eH3tω,greH3ω,gtr=m·eH3ω,gtreH3ω,gtr.


#### 5.1.5. Forward Secrecy

SenderS uses his/her private key skS and the receiver R’s public key pkR to generate a reencryption key RKS→R. In addition, the sender S creates the reencryption key RKS→R using the one-way function H2· and the difficulty of discrete algebra (DLP) such that he/she cannot extract his/her private key skS from the reencryption key.


#### 5.1.6. Delegated Reencryption

If senderS is unable to access the data, the other members of the preconfigured group are delegated the authority to reencrypt the encrypted data without the sender S’s private key skS. For this, the sender S performs a separate operation as follows so that the delegated group member Gj can generate the delegated reencryption key DRKS→R.


### 5.2. Efficiency Analysis of the Proposed GD-PRE Scheme

Table1 shows the characteristics of the proposed scheme. This proposed scheme was designed by applying an encryption scheme using the existing multireceiver encryption [28–31]. Here, the delegate group includes the sender and the delegate group member, and users included in the delegate group can generate the delegate reencryption key. In this proposed scheme, there is no separate group formation process, and the sender designates a user to delegate his/her authority and transmits the value in one direction. Therefore, even if the number of members of the delegation group increases, the number of communications does not increase. As a result, it is possible to share data through a member of a delegated group when the sender is absent, without showing significant difference in terms of general proxy reencryption and computational requirements.Table 1
Comparison of computational amount of each algorithm.
Encryption timeReencryption timeDelegated reencryption timeDecryption time3Te+1Tm+1Tbi2Te+2Tm+1Tbi+1Th3Tm+2Tbi+1Th1Tm+1TbiTe: time for a exponentiation operation; Tm: time for a multiplication operation; Tbi: time for a bilinear pairing operation; Th: time for a hash function operation; n: number of users.


## 5.1. Analysis of Security Requirements

This section analyzes whether the proposed scheme meets the security requirements.


### 5.1.1. Confidentiality

The owner of the data encrypts the data source m with his/her public keypki, converts it to Ci, and uploads it before uploading the data to the proxy. In addition, the decryption of the encrypted data must use the private key ski corresponding to the public key pki used for data encryption. The decryption operation is as follows, and the data source m can be obtained through the decryption operation.
(18)m=?c3eski,c1=m·egi,gx·diregix·di,gr=m·egi,gx·di·regi,gx·di·r.


### 5.1.2. Integrity

The ciphertextCi stored in the proxy consists of Ci=c1,c2. c1 is necessary for decrypting c2, and if c1or c2 is tampered with, the data owner cannot confirm that the source data is correct, and thus the data is tampered with.


### 5.1.3. Availability

SenderS can decrypt data using his/her private key skS, and receiver R can decrypt ciphertext CS with his/her private key skR as follows.
(19)m←c3eskS,c1=m·egS,gx·dSregSx·dS,gr=m·egS,gx·dS·regS,gx·dS·r.


### 5.1.4. Access Control

SenderS stores their generated ciphertext in a proxy. Thereafter, when another user requests the use of the data, the sender S can generate a reencryption key RKS→R by combining his/her private key and the receiver R’s public key. The generated reencryption key RKS→R is transmitted to the proxy to generate a ciphertext CR that the receiver R can decrypt as follows.
(20)c3′←m·egS,gx·dSregS−x·dS·H2tω,c1=m·egSx·dS,gregS−x·dS·H2tω,gr=m·egSx·dS·gS−x·dS·H2tω,gr=m·eH2tω,gr.Thereafter, the receiver who has received the reencrypted dataCR can obtain the data source by decrypting the corresponding ciphertext with his/her private key skR.
(21)m←c2′eH3ω,c2=m·eH3tω,greH3ω,gtr=m·eH3ω,gtreH3ω,gtr.


### 5.1.5. Forward Secrecy

SenderS uses his/her private key skS and the receiver R’s public key pkR to generate a reencryption key RKS→R. In addition, the sender S creates the reencryption key RKS→R using the one-way function H2· and the difficulty of discrete algebra (DLP) such that he/she cannot extract his/her private key skS from the reencryption key.


### 5.1.6. Delegated Reencryption

If senderS is unable to access the data, the other members of the preconfigured group are delegated the authority to reencrypt the encrypted data without the sender S’s private key skS. For this, the sender S performs a separate operation as follows so that the delegated group member Gj can generate the delegated reencryption key DRKS→R.


## 5.1.1. Confidentiality

The owner of the data encrypts the data source m with his/her public keypki, converts it to Ci, and uploads it before uploading the data to the proxy. In addition, the decryption of the encrypted data must use the private key ski corresponding to the public key pki used for data encryption. The decryption operation is as follows, and the data source m can be obtained through the decryption operation.
(18)m=?c3eski,c1=m·egi,gx·diregix·di,gr=m·egi,gx·di·regi,gx·di·r.


## 5.1.2. Integrity

The ciphertextCi stored in the proxy consists of Ci=c1,c2. c1 is necessary for decrypting c2, and if c1or c2 is tampered with, the data owner cannot confirm that the source data is correct, and thus the data is tampered with.


## 5.1.3. Availability

SenderS can decrypt data using his/her private key skS, and receiver R can decrypt ciphertext CS with his/her private key skR as follows.
(19)m←c3eskS,c1=m·egS,gx·dSregSx·dS,gr=m·egS,gx·dS·regS,gx·dS·r.


## 5.1.4. Access Control

SenderS stores their generated ciphertext in a proxy. Thereafter, when another user requests the use of the data, the sender S can generate a reencryption key RKS→R by combining his/her private key and the receiver R’s public key. The generated reencryption key RKS→R is transmitted to the proxy to generate a ciphertext CR that the receiver R can decrypt as follows.
(20)c3′←m·egS,gx·dSregS−x·dS·H2tω,c1=m·egSx·dS,gregS−x·dS·H2tω,gr=m·egSx·dS·gS−x·dS·H2tω,gr=m·eH2tω,gr.Thereafter, the receiver who has received the reencrypted dataCR can obtain the data source by decrypting the corresponding ciphertext with his/her private key skR.
(21)m←c2′eH3ω,c2=m·eH3tω,greH3ω,gtr=m·eH3ω,gtreH3ω,gtr.


## 5.1.5. Forward Secrecy

SenderS uses his/her private key skS and the receiver R’s public key pkR to generate a reencryption key RKS→R. In addition, the sender S creates the reencryption key RKS→R using the one-way function H2· and the difficulty of discrete algebra (DLP) such that he/she cannot extract his/her private key skS from the reencryption key.


## 5.1.6. Delegated Reencryption

If senderS is unable to access the data, the other members of the preconfigured group are delegated the authority to reencrypt the encrypted data without the sender S’s private key skS. For this, the sender S performs a separate operation as follows so that the delegated group member Gj can generate the delegated reencryption key DRKS→R.


## 5.2. Efficiency Analysis of the Proposed GD-PRE Scheme

Table1 shows the characteristics of the proposed scheme. This proposed scheme was designed by applying an encryption scheme using the existing multireceiver encryption [28–31]. Here, the delegate group includes the sender and the delegate group member, and users included in the delegate group can generate the delegate reencryption key. In this proposed scheme, there is no separate group formation process, and the sender designates a user to delegate his/her authority and transmits the value in one direction. Therefore, even if the number of members of the delegation group increases, the number of communications does not increase. As a result, it is possible to share data through a member of a delegated group when the sender is absent, without showing significant difference in terms of general proxy reencryption and computational requirements.Table 1
Comparison of computational amount of each algorithm.
Encryption timeReencryption timeDelegated reencryption timeDecryption time3Te+1Tm+1Tbi2Te+2Tm+1Tbi+1Th3Tm+2Tbi+1Th1Tm+1TbiTe: time for a exponentiation operation; Tm: time for a multiplication operation; Tbi: time for a bilinear pairing operation; Th: time for a hash function operation; n: number of users.


## 6. Conclusions

Proxy reencryption is a technology that converts (reencrypts) data encrypted with a public key such that other users can decrypt it with their private key. Therefore, it is not necessary to decrypt the encrypted data for data sharing; hence, it has the efficiency of operation and communication. In addition, when proxy reencryption is used, data is encrypted and uploaded to the cloud storage, such that it can later be easily shared through the generation of a reencryption key at the request of another user. By utilizing these features, corporate cloud storage can efficiently manage data such as collaboration and business data delivery.However, in a corporate environment, employees are not always resident in the company, but often leave the workplace on business trips, vacations, etc. When the data owner is away and receives a request to share data from another employee, the data owner must return to the company to provide the data. If the data owner urgently needs important business data while on a long-term overseas business trip, they have no alternative other than providing his/her own private key. However, such private key sharing is a serious security breach and can pose considerable risk to the company and the individual themselves. This study was conducted to solve this problem.In this study, we propose a scheme that allows a preformed group to perform reencryption key generation in the event of an emergency by applying existing IBPRE techniques. The proposed scheme is designed for situations in which general IBPRE techniques cannot be used by owners of data in data self-sovereign environments, such as enterprise environments. In such environments, as the individual directly controls his/her own data, the sovereignty of his/her data can be guaranteed. However, if an individual cannot exercise sovereignty, such as when they are rendered unconscious in an emergency, data that are necessary for handling the emergency cannot be accessed. Therefore, in the proposed scheme, users form groups with other trusted individuals in advance. Therefore, in the event of an emergency, group members can control data by reencrypting the data of other users on their behalf, which can solve the limitations of self-sovereign data in existing enterprise environments.



---

*Source: 7641389-2021-06-15.xml*