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.
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 Figure 1(e) [6–8].
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.
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 Figure 3.
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 Figure 3. 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 Figure 4. 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.
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 Section 4.
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 shared with all the users, while the master secret key remains private.
3.2.2. Partial Private Key Extraction (params, , IDi)
This is the process in which the KGC receives an input from the master secret key and the user’s identifier , outputs the individual partial private key that corresponds to the , and sends it securely to the user.
3.2.3. Private Key Generation (params, )
Algorithm performed by the user, the user generates a complete private key using the partial private key 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 key using and his/her and distributes this public key .
3.2.5. Encryption (params, )
Algorithm performed by the user, the user computes first-level ciphertext by encrypting message by the sender inputting message and .
3.2.6. Reencryption Key Generation (params, )
Algorithm performed by the sender, the sender generates a reencryption key to delegate ciphertext to the receiver. For this purpose, the sender generates a reencryption key by using its own private key and public key of the receiver.
3.2.7. Reencryption (params, )
Algorithm performed by the proxy, the proxy takes the first-level ciphertext and the reencryption key as input and outputs a reencrypted ciphertext , called the second-level ciphertext.
3.2.8. Group Delegation (params, )
Algorithm performed by the sender, the sender establishes a delegate group who will be delegated the authority to generate his/her reencryption key in case he/her are away from the company.
3.2.9. Proxy Delegation (params, )
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 instead of the sender even if they do not know the sender’s private key .
3.2.10. Delegated Group Member Setup (params, )
Algorithm performed by a delegated group member, each member can obtain required to generate the delegated reencryption key using the received from the sender.
3.2.11. Delegated Reencryption Key Generation (params, )
Algorithm performed by the delegated group member, the delegated group member generates a delegated reencryption key for the receiver without the sender’s private key . enables the creation of by reencrypting the sender’s first-level ciphertext .
3.2.12. Delegated Reencryption (params, )
Algorithm performed by the proxy, the proxy receives the first-level ciphertext and the delegated reencryption key as input and outputs a reencrypted ciphertext , called the second-level ciphertext.
3.2.13. Decryption/Redecryption/Delegated Redecryption (params, )
The decryption algorithms are algorithms executed by the owner. When the ciphertext and the receiver s private key are input, the algorithm outputs a message or an error message.
3.2.14. Trace (params, )
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 key generated by the delegated group member and the delegated group member’s 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.
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. : user () : sender () : receiver () : number of delegated group members : delegated group member () : delegated group () : identifier of user : circulation group on prime : bilinear mapping :hash function :hash function : hash function : hash function : master key of KGC : partial private key of user created by KGC : user s complete private key : user s public key : reencryption key to reencrypt s ciphertext to s ciphertext : delegated reencryption key created by delegated group member : plaintext : ciphertext of user : data encryption algorithm (explained in 4.2.2 Data Storing Phase) : 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 Section 3.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.
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 be two cyclic groups of prime order and be a bilinear map. Set the two -bit integers and the message space . A random generator is chosen. The KGC randomly picks an integer as the master key and publishes .
(2) Partial Private Key Extraction. User sends his/her identity to the KGC. The KGC calculates using and the master key and sends user ’s partial private key to user . The same operation continues with the other users.
(3) Private Key Generation. User randomly selects and keeps secret and computes his/her private key :
(4) Public Key Generation. User computes his/her public key :
The user creates a public key using and his/her and distributes this public key . User publishes , and anyone can use to provide ciphertext to user . 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 Figure 5. After that, the sender can obtain his ciphertext uploaded to the proxy and decrypt it with his/her own private key.
(1) Encryption. Sender selects a random integer and the public key of the target and calculates the message as a ciphertext that can only decrypt as follows:
As a result, the ciphertext becomes . In this proposed environment, sender creates using his public key and uploads to proxy.
(2) Decryption. User can download the stored in the proxy and decrypt it using his/her private key as follows.
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 Figure 5.
(1) Reencryption Key Generation. The sender receiving the request of the recipient selects random value and . Then, the reencryption key is generated for converting to .
is then sent to the proxy by sender .
(2) Reencryption. The proxy generates the reencrypted ciphertext using the following operation using the ciphertext and the reencryption key of sender .
is then sent to receiver by proxy.
If sender cannot access the proxy, any member of group can perform the 4.2.5 delegated data sharing phase on behalf of the sender .
(3) Redecryption. Receiver decrypts a ciphertext received from a proxy by using his/her private key to obtain . Finally, receiver can compute the plaintext .
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 Figure 6.
(1) Group Delegation. Sender sets up the delegate group to delegate its authority. Sender randomly selects and and computes
Then, sender computes and for .
Sender computes and and outputs .
Sender sends sender uploads to the delegated group members.
(2) Proxy Delegation. Sender 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.
Sender uploads 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 Figure 6.
(1) Delegated Group Member Setup. Sender sends to all delegate group members. And each group member constructs and obtains using as follows:
Each group member checks as follows:
(2) Delegated Reencryption Key Generation. Group member generates a delegated reencryption key using the acquired .
is then sent to the proxy by one of group member .
(3) Delegated Reencryption. The proxy generates the reencrypted ciphertext using the following operation using ciphertext and the delegated reencryption key of sender .
is then sent to receiver by the proxy.
(4) Delegated Redecryption. Receiver decrypts a ciphertext received from a proxy by using his/her private key to obtain . Finally, receiver can compute the plaintext .
(5) Trace. If illegal generation of the delegated reencryption key is confirmed, sender can browse the information of the group member who generated the delegated reencryption key. To do this, sender 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 is used, the correct is created, and the perpetrator can be identified through this.
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 key , converts it to , and uploads it before uploading the data to the proxy. In addition, the decryption of the encrypted data must use the private key corresponding to the public key used for data encryption. The decryption operation is as follows, and the data source can be obtained through the decryption operation.
5.1.2. Integrity
The ciphertext stored in the proxy consists of . is necessary for decrypting , and if or 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
Sender can decrypt data using his/her private key , and receiver can decrypt ciphertext with his/her private key as follows.
5.1.4. Access Control
Sender stores their generated ciphertext in a proxy. Thereafter, when another user requests the use of the data, the sender can generate a reencryption key by combining his/her private key and the receiver ’s public key. The generated reencryption key is transmitted to the proxy to generate a ciphertext that the receiver can decrypt as follows.
Thereafter, the receiver who has received the reencrypted data can obtain the data source by decrypting the corresponding ciphertext with his/her private key .
5.1.5. Forward Secrecy
Sender uses his/her private key and the receiver ’s public key to generate a reencryption key . In addition, the sender creates the reencryption key using the one-way function and the difficulty of discrete algebra (DLP) such that he/she cannot extract his/her private key from the reencryption key.
5.1.6. Delegated Reencryption
If sender 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 private key . For this, the sender performs a separate operation as follows so that the delegated group member can generate the delegated reencryption key .
5.2. Efficiency Analysis of the Proposed GD-PRE Scheme
Table 1 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.
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.
Data Availability
No data were used.
Conflicts of Interest
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This research was supported by the MSIT ((Ministry of Science, ICT), Korea, under the High-Potential Individuals Global Training Program) (2020-0-01596) supervised by the IITP (Institute for Information & Communications Technology Planning & Evaluation) and the Soonchunhyang University Research Fund and the BK21 FOUR (Fostering Outstanding Universities for Research) (No. 5199990914048).