Abstract
With the fantastic development of cloud computing technology, cloud storage has been widely applied in the field of medical data sharing due to its efficiency and flexibility. Attribute-based encryption (ABE), as a promising technology, plays an important role in the fine-grained sharing of medical data. However, there are two issues: (1) an access policy specified in the encryption phase may need to be updated after a period of time, and (2) the considerable decryption overhead in ABE is too heavy for resource-limited devices. To address these issues, a fine-grained medical data sharing scheme with ciphertext reencryption is proposed. Users with decryption permission can produce reencryption keys and cloud server can reencrypt initial ciphertext. The cloud server can predecrypt ciphertext, which reduces user’s decryption overhead. Moreover, the traditional centralized server is replaced with a decentralized blockchain that performs system initialization, key management, and user revocation. We compared the proposed scheme with some existing schemes in terms of function and efficiency; the results show that the efficiency of the proposed scheme outperforms other related schemes. The security analysis shows that the proposed scheme is security and correctness.
1. Introduction
Since cloud computing was proposed, it has received increasing attention [1]. On the one hand, it is an Internet-based value-added service [2], which means that users can obtain cloud services through the network anywhere and anytime. On the other hand, with the continuous development of big data, cloud computing, as a novel and efficient computing paradigm [3], can store and manage huge amounts of data for users. As a result, an increasing number of individuals and enterprises outsource their data to the cloud, promoting the growth of cloud computing.
Cloud storage, a new storage mechanism evolved from cloud computing, can provide users with ubiquitous data storage and access services by centrally processing resources stored in its area. At the same time, by taking use of cloud storage’s services, customers not only save costs on local data storage and maintenance but also get access to and share data with greater ease. Therefore, cloud storage is widely used in people’s daily life due to its flexibility, convenience, and economy [4].
In the medical field, cloud storage has the advantages of low cost, convenient deployment and efficient storage, and the operations on its platform are basically automated, making it the most ideal environment for deploying standard data security access and sharing mechanisms [5]. On the one hand, the generation, collection, storage, integration, and application of data are decentralized, and cloud storage makes it possible to obtain high-quality medical services through the collection, management, and utilization of these data. On the other hand, with the explosive growth of data and the development of Internet of Things technology, users can effectively save the cost of local data management and maintenance by outsourcing their massive medical data to the cloud for storage.
In the secure access and sharing mechanism of medical data stored in the cloud, as long as users are authorized, they can obtain safe, convenient, and high-quality medical services in a timely manner by sharing corresponding medical resources in the cloud. This not only greatly improves the storage and sharing efficiency of medical information but also effectively solves the problems of the traditional medical model, such as few medical channels for users, high medical costs for users, and unreasonable medical services for users. Therefore, the secure access and sharing mechanism of cloud storage medical data has become a hot topic in the field of medical and health research [6].
The basic model of secure accessing and sharing mechanism of medical data is shown in Figure 1. In the secure accessing and sharing mechanism of cloud storage medical data, data owners first encrypt the medical data, by paying a fee, the obtained ciphertext can be hosted to the cloud storage center, and the cloud storage center uses access control technology to manage users’ permissions to the sharing data.
However, patients’ medical data is sensitive and confidential; they may include social security numbers, credit card information, and treatment history. CSP cannot be fully trusted due to various attacks in an untrusted network environment. Once medical data leaked, it may cause serious medical accidents and economic losses, which restricts the application of medical data sharing [7–9]. Therefore, we need to address security and privacy issues when designing practical and secure EHR sharing systems adapted to the cloud environment.
Access control (AC) [10], as a part of the secure accessing and sharing mechanism of medical data, plays a significant role in medical data protection. As in an untrusted cloud storage environment, data owners encrypt the medical data before storing it in the cloud and ensuring that data requesters with decryption capabilities may access the data, therefore realizing the security of medical data cloud storage. Traditional ciphertext AC techniques, however, are no longer suited for cloud-based data sharing due to issues such as low work efficiency, high computing costs, and large bandwidth. This problem has been significantly improved by the proposal of the ciphertext-policy attribute-based encryption (CP-ABE) technique. In CP-ABE, data owners define the AC to ensure that only the data requesters who meet the access policy can decrypt the corresponding ciphertext. This provides not just fine-grained AC but also “one-to-many” encryption. Therefore, with the help of CP-ABE, safe access control and sharing of cloud-storage medical data can be implemented.
In secure accessing and sharing mechanism of medical data based on cloud storage, there are also a large number of scenarios where the ciphertext needs to be reencrypted. For example, ciphertext reencryption technology enables doctor Alice working in P city’s hospital to share a patient’s medical data with doctor Bob working in Q city’s hospital. The ciphertext reencryption technology also enables the doctor Alice, who is on leave, to share her patient’s medical data to another doctor Eve in the same hospital. The straightforward solution to reencryption the ciphertext is that Alice first downloads the ciphertext from the cloud, decrypts the ciphertext, and reencrypts the plaintext with the new access policy. After encryption, Alice uploads the new ciphertext to the cloud. When a large amount of patients’ ciphertexts need to be reencrypted, this method not only incurs large computing overhead but also increases the communication cost between the cloud and Alice. In order to share data more effectively, proxy reencryption (PRE) [11] is introduced into CP-ABE, which is called ciphertext-policy attribute-based proxy reencryption scheme (CP-ABPRE). In response to the above situation, Alice generates a reencryption key and sends the key to the proxy server. The proxy server can use the key to encrypt the original ciphertexts, so that Bob(Eve) can decrypt the encrypted ciphertext data and realize the sharing of medical data.
In PRE, the ciphertext encrypted under A’s public key can be transformed into ciphertext encrypted under B’s public key by a semitrusted proxy, and the proxy will not get any information about the underlying encrypted medical data. By implementing the permission of decryption authority, CP-ABPRE can securely and effectively reencrypt ciphertexts and assure the secure access and sharing of medical data. Since the proxy only needs to verify that the attributes in the user-generated reencryption key satisfy the access policy of the original ciphertexts, the proxy server can reencrypt a batch of such ciphertexts. As a result of its great security and low computing overhead, this technology is suitable for a large number of ciphertext reencryption scenarios.
Overall, CP-ABPRE can not only perform one-to-many encryption but it can also safely reencrypt the relevant ciphertexts. It is suitable for the sharing of medical data. For one thing, the proxy can reencrypt the ciphertexts corresponding to access policy A into access policy B without changing the plaintexts. This not only allows for fine-grained access control for medical data users, but it also assures the security of medical data stored in the cloud. In other words, the proxy does not have to decrypt the ciphertext and then reencrypt the plaintext during the whole process. Instead, it may simply complete the ciphertext conversion by directly performing operations on the ciphertexts, which considerably decreases the proxy’s computing cost. Therefore, CP-ABPRE is critical for the secure accessing and sharing mechanism of medical data in cloud storage.
However, most of the existing CP-ABPRE schemes must have a trusted center or key generation center (KGC), and the keys are generated and maintained through the KGC. In addition, centralized KGCs are vulnerable to attacks such as a single point of failure, once KGC is compromised by malicious organizations, and it will lead to serious information leakage. Blockchain technology has the potential to tackle this issue effectively. This technology was invented by Nakamoto [12] in 2008, and it has gained global notice. The benefits of blockchain include distributed storage, nontampering, and traceability. As a result, it has a wide range of applications in a variety of industries, including finance, communications, and the Internet of Things. In this paper, blockchain is used to replace the traditional trusted center, and users’ keys are generated by consensus nodes and users themselves, which solves the problem of centralization of key generation in traditional CP-ABPRE.
2. Related Work
In the traditional public key cryptosystem, the data owner can encrypt the medical data with the public key so that only the data user with the corresponding private key can decrypt ciphertexts, which effectively solves the problem of key distribution. However, due to issues with certificate administration and key escrow, this approach is inapplicable when large-scale medical data owners need to exchange their data. At the same time, in most cases, data owners may not know the particular receivers but aim to accomplish fine-grained access control through strategies created by data owners. As a result, the standard public key cryptosystem is incapable of addressing the issue of data access and sharing in cloud storage.
With the continuous development of cryptographic research, Sahai and Waters [13] prompted an ABE scheme in 2005. Subsequently, Goyal et al. [14] proposed a key-policy attribute-based encryption (KP-ABE) scheme, in which the access policy is bound to the user secret key, and the attribute set is related to the ciphertext. When the attribute set in the ciphertext satisfies the policy in the key, the ciphertext can be decrypted. Bethencourt et al. [15] proposed a ciphertext-policy attribute-based encryption (CP-ABE) scheme. In CP-ABE, the access policy is bound to the ciphertext while the attribute set is related to the user secret key. Only when the attribute set in the key satisfies the access policy in the ciphertext can the ciphertext be decrypted. Since the access policy can be defined by the data owner, CP-ABE is suitable for medical data sharing in cloud storage. In 2011, Waters [16] proposed a CP-ABE scheme that uses linear secret sharing scheme (LSSS). Compared with the scheme of Bethencourt et al. [15], the efficiency has been improved.
In order to address the problem of access policy updating, in 2009, Liang et al. [17] proposed a ciphertext-policy attribute-based proxy reencryption (CP-ABPRE) scheme, which allows a proxy to reencrypt a ciphertext encrypted by policy A to policy B and the proxy cannot obtain any information about the plaintext. However, their scheme cannot resist choose plaintext attacks. To solve this problem, Liang et al. [18] proposed a proxy reencryption scheme based on CP-ABE in 2013, which can resist choose plaintext attacks. However, both the generation of the reencryption key and the reencryption ciphertext require a large amount of calculation. In 2016, Yang et al. [19] employed a cloud server to implement dynamic attribute-based access control, which greatly improved the efficiency of reencryption and reduced the user’s decryption overhead. However, the proposed scheme only supports tree access structure. In 2017, Feng et al. [20] prompted an attribute-based proxy reencryption (AB-PRE) scheme which supports LSSS, but it only supports AND gates. In the same year, Ma et al. [21] proposed a verifiable outsourced decryption scheme; the outsourced decryption operation was completed by a decryption server. In 2019, Xu et al. [22] proposed a novel healthcare IoT system fusing advantages of attribute-based encryption, cloud, and edge computing, which provides an efficient, flexible, secure fine-grained access control mechanism with data verification in healthcare IoT network without any secure channel and enables data users to enjoy the lightweight decryption. In 2020, Deng et al. [23] proposed an AB-PRE scheme that supports arbitrary monotonic access policies, but the reencrypted ciphertext only supports identity-based encryption (IBE), and the scalability of reencryption is not as good as ABE. In 2020, Paul et al. [24] proposed an efficient attribute-based proxy reencryption with constant size ciphertext, but his scheme did not support user revocation. In 2021, Xu et al. [25] proposed a practical and secure dynamic EHR sharing system via Cloud. The user decryption keys of the works above are all generated by the KGC. Once the KGC is compromised, it will cause serious information leakage.
Blockchain was first proposed as the underlying technology of Bitcoin [12]. It is an open distributed public ledger. Due to the hash function and consensus protocol used in the blockchain, it can not only ensure the unforgeability of the data stored in it but also guarantees traceability. Any user can access all the data stored in the ledger, and it is impossible for a malicious user to tamper with this data. In 2017, Huh et al. [26] used public blockchain to manage IoT devices; all the public key of users are stored in blockchain. In 2017, Liu et al. [27] used private blockchain to ensure data integrity. In 2019, Hu et al. [28] proposed a blockchain-based data sharing scheme, a decentralized system is established based on smart contracts.
2.1. Contributions
In this paper, we proposed a blockchain-aided fine-grained medical data sharing scheme supporting ciphertext reencryption. The characteristics of the scheme are as follows.
2.1.1. Blockchain-Aided ABE
The proposed scheme allows users to generate private keys by themselves. This prevents the usage of users’ private keys created by KGC in traditional schemes. The KGC in traditional ABE is replaced by the consensus nodes of the distributed consensus blockchain, and the immutable ledger can store transactions. The user’s public key and system public parameters can be uploaded to the blockchain to ensure that the data is not tampered with.
2.1.2. Ciphertext Reencryption
The proposed scheme allows the cloud to reencrypt a ciphertext decryptable by user A into a ciphertext decryptable by user B without disclosing the plaintext or the authorizer’s private key. The complete procedure does not necessitate decryption.
2.1.3. Collusion Resistance
The proposed scheme adopts the user’s Global Identifier (GID) to bind attributes of users. Only attributes belonging to the same user can decrypt the ciphertext, thereby preventing the system from colluding attacks.
2.1.4. Lightweight Decryption and Verification
The proposed scheme allows the cloud to pre-decrypt the ciphertext, lowering the user’s computational cost in the decryption process. Data user can decrypt the final ciphertext with only one exponentiation computation, and the user can verify if the cloud has made the correct transformation.
2.1.5. Efficient User Revocation
For situations such as the resignation of doctors and the recovery of patients, their access rights need to be revoked. The proposed scheme supports efficient user revocation.
2.2. Paper Organization
Section 3 introduces the background knowledge. The system architecture model is formally defined in Section 4. Details of the proposed scheme are depicted in Section 5. Section 6 introduces the performance analysis. Ultimately, the conclusion is given in Section 7.
3. Preliminaries
3.1. Notations
Related notations and definitions used in the proposed scheme are presented in Table 1.
3.2. Access Structures
Let be the set of participants. For set , if , , , then is said to be monotonic. Among them, the set belonging to is called authorized set; otherwise, it is called unauthorized set [29].
3.3. Bilinear Maps
Let and be two multiplicative cyclic groups of order . is a generator of and is a map with three properties: (1) bilinearity—for and , ; (2) nondegeneracy—; and (3) computability—for all , there exists effective algorithms to calculate .
3.4. Linear Secret Sharing Schemes
Let denote the attribute university and denote a prime number. The secret sharing scheme on the secret space realizes the access policy on . If satisfies the following two properties, then, is linear [30]. (1)Each part of the secret corresponds to an attribute in A, and each part constitutes a vector on (2)For the access policy , is a secret sharing matrix. The function maps the row of to an attribute of the attribute set A. For example, construct a column vector , where are random numbers used to hide the secret value . Then, is a vector with rows and column. That is, the secret value is divided into parts according to . corresponds to the attribute , where
Every LSSS has linear reconstruction property. Suppose that is a LSSS for the access structure . is the set of arbitrary authorization, and . For any legal sharing of , there exists a set of constants that can be calculated in polynomial time. For the unauthorized set , there is no such constant set as .
3.5. Blockchain Technology
Blockchain is a specific data structure based on transparent and trusted consensus rules in a peer-to-peer network. It combines data blocks in a chronological order to form a specific data structure. Blockchain cryptographically guarantees a decentralized and credible distributed shared ledger system whose data cannot be tampered with, forged or traced. Blockchain is mainly divided into three types: public blockchain, consortium blockchain, and private blockchain. The consortium blockchain usually designates one or more preselected consensus nodes as the bookkeeper. The generation of each block is jointly determined by all consensus nodes. The connected nodes can participate in activities on the chain but do not care about the process of accounting. The public blockchain adopts a proof of work mechanism to exchange efficiency for fairness. The private blockchain sets a single central accounting node to exchange fairness for efficiency. Compared with the public blockchain and private blockchain, the participants in the consortium blockchain know each other’s digital identities and can reach business consensus in advance. The proof-of-work mechanism is no longer needed; thus, this can reduce energy consumption and improve efficiency. Since the consortium blockchain takes into account both efficiency and fairness, it is considered by many researchers to be the most suitable blockchain for medical data sharing application scenarios.
3.6. Random Oracle Model
The random oracle model (ROM) was proposed in 1993 [31]; the ROM uses the character of a random oracle to show the security of the algorithm. The random oracle can be considered a black box in theory, and the black box is embedded with a certain algorithm so that the inquirer cannot obtain any information no matter how many inquiries are made. Among them, the returned value is collision resistant, the value is the same for the same query, and the value is unpredictable for different queries. The random oracle is a specific type of hash function, and the function satisfies the following characteristics: (1)Uniformity: given the result after operation, the distribution of on is uniform.(2)Effectiveness: given a string , 𝐻 can do certain operations to get . is the effective output of in low-order polynomial time of length.(3)Certainty: if the two numbers input by the oracle are the same, then the two corresponding outputs must be the same.
3.7. q-DBPBDHE2 Assumption
The system selects two multiplicative cyclic groups and whose order is prime , is the generator of group , and is a bilinear mapping. The system randomly selects and . The system defines a vector . If the adversary cannot distinguish a random factor from with a nonnegligible advantage in probabilistic polynomial time (PPT), then q-DBPBDHE2 assumption establish. Advantage is defined as .
4. System Architecture
4.1. Functionalities of Each Entity
The proposed scheme includes 4 entities. As shown in Figure 2, they are consensus node (CN), cloud server provider (CSP), medical data owner (MDO), and medical data user (MDU).
4.1.1. Consensus Node
Consensus nodes are the maintainer of the consortium blockchain. Each consensus node manages the attributes of MDUs, initializing the system, generating transfer keys for MDU, and maintaining a revocation list.
4.1.2. Cloud Server Provider
CSP is responsible for storing ciphertext and managing the attribute transfer keys for each user. CSP receives the reencryption key and generates the corresponding reencryption ciphertext. CSP also performs outsourcing decryption for MDU. Furthermore, CSP needs to revoke illegal users in the system.
4.1.3. Medical Data Owner
MDO first encrypts medical data with a symmetric key encryption algorithm, then encrypts the symmetric-key with a CP-ABPRE, and finally uploads the ciphertext to the CSP.
4.1.4. Medical Data User
MDU with sufficient attributes can request the CSP to perform the semidecryption algorithm and then decrypt the semidecrypted ciphertext with their own private key efficiently. MDU also generates a reencryption key and uploads it to the CSP. It is worth noting that the MDU can only obtain the semidecrypted ciphertext after outsourcing decryption of the CSP but cannot obtain the original ciphertext in the CSP.
4.2. Formal Definition
(1): the algorithm inputs the security parameters according to the security requirements of the scheme and attribute universe and outputs the system public parameter , an empty revocation list .(2): this algorithm takes the public parameters and CN’s identity as input and outputs CN’s node public key and node secret key .(3): the algorithm inputs the and user and outputs the user public key and user private key .(4): the algorithm inputs the public parameter , user , user attribute set , node secret key and user public key and outputs the user’s transfer key . CN sends it to the user and CSP; CSP adds to the key list .(5): this algorithm inputs the public parameter , a EHR plaintext , an access policy , and node public key and outputs the ciphertext .(6): this algorithm inputs the public parameter , transfer key , user private key , node public key , user attribute set , and a new access policy and outputs the reencryption key .(7): this algorithm inputs the public parameter , reencryption key , and ciphertext and outputs the reencryption ciphertext .(8): this algorithm inputs the public parameter , ciphertext , user attribute set , transform key , and user public key and outputs the semidecrypted ciphertext .(9): this algorithm inputs the user private key and outputs the plaintext .(10): this algorithm inputs the public parameter , ciphertext , user attribute set , and transform key and outputs the semidecrypted ciphertext .(11): this algorithm inputs the public parameter , user private key , and semidecrypted ciphertext and outputs the plaintext (12): this algorithm inputs the identity of the revoked user , revocation list , and key list and outputs an updated revocation list and an updated key list .
4.3. Threat Model
In the system, consensus nodes and MDO are fully trusted. Each consensus node manages the attributes of MDUs, initializing the system, generating transfer keys for MDU, and maintaining a revocation list. MDO honestly encrypts medical data and generates ciphertext according to its own wishes and uploads it to CSP.
The CSP is semitrusted. CSP is semitrusted, and it follows our scheme but tries to learn sensitive data without any active attack. In addition to this, CSP may also dishonestly decrypt ciphertext for MDU to ease the burden of data storage or for any other reason.
MDU are untrusted. MDU try to learn about unauthorized data and even try to collude with other MDU to gain access to sensitive data. To prevent attacks from untrusted DUs, we apply cryptosystems to ensure data confidentiality.
From the above, the security of our proposed scheme depends on the blockchain and cryptosystem. As we all know, all data stored on the blockchain cannot be tampered with. The cryptosystems in our scheme are hash functions, symmetric encryption, and our scheme. We apply a collision-resistant hash function to prevent adversaries from compromising data integrity. Symmetric encryption is known to be resistant to all kinds of attacks. For the security of our scheme, we propose a formal security model in the next subsection to demonstrate the security of our scheme.
4.4. Security Model
The security model of the proposed scheme is a static security model. The static security model satisfies the confidentiality of messages; it can be defined by a security game between an adversary and a challenger . The game is performed in the form of query-answer between and . All inquiries must be completed before the challenge phase. Since static security model of the scheme is mainly aimed at the collusion attack of multiple legitimate MDUs, it is required that can ask the MDU for the private key many times and ask other legitimate MDUs: GID to partially decrypt the ciphertext . The implementation of the latter is based on that can ask for the corresponding transform key, so that can obtain the GID’s according to the transform key of .
Definition 1. Given a probabilistic polynomial time, if there is no one adversary can win the following game with a nonnegligible advantage, the proposed scheme is static security. In the game, represents attribute universe of the protocol, and represents the consensus node set. Assume that each attribute is assigned to a consensus node (although each consensus node can manage multiple properties).
The game consists of the following 4 phases. (1)Initialization phase: the initialization phase is performed by challenge . inputs according to security requirements. Then, the algorithm is performed, and the public parameter is sent to .(2)Query phase: define consensus nodes as . does the following query to .(i)Query 1: chooses some ; asks for their corresponding public key .(ii)Query 2: selects some MDUs’ and asks for their key pairs .(iii)Query 3: asks for the transfer key: input MDUs’ and their attribute sets ; performs to generate transfer key . Then, returns to . At the same time, the query made by includes not only the query to obtain the transfer key corresponding to the MDUs’ but also the query to obtain the transfer key corresponding to other MDUs (that is, if 𝑛 is larger than 𝑚).(iv)Query 4: asks for reencryption key: input user , user attribute sets , and access policy ; performs to generate reencryption key . Then, returns to . is generated by algorithm.(3)Challenge phase: submits two equal-length plaintexts , , and an access policy to . randomly selects and executes algorithm to calculate challenge ciphertext and return it to . The limitation is that the of the user who asked for the private key during the query; their attribute set does not satisfy (4)Guess phase: outputs guess on b. If , wins the game. The advantage of winning is defined as .
5. Proposed Scheme
5.1. Concrete Construction
This section will give the design of the protocol. To better understand the protocol, the access policy of the protocol is represented by a two-tuple , where is a matrix of and maps each row of to an attribute . At the same time, define a function ; represents attribute universe of the protocol, and represents attributes managed by a consensus node (CN) with identity : ; this function can implement the mapping of the attribute to . The corresponding function can realize the mapping of the rows of the matrix to a consensus node. The concrete construction is as follows: (1): the algorithm is performed by all CNs. They take a security parameter and system attribute universe as input and outputs system public parameter , an empty revocation list . The algorithm randomly selects a security parameter . Let and be two multiplicative cyclic groups with prime order , be a generator of , be the key space of symmetric encryption, and be a nondegenerate bilinear pair. The algorithm selects 4 safety hash functions: , , , and , and a symmetric-key encryption algorithm: . In , is a symmetric encryption algorithm. At last, CNs output global public parameters , an empty revocation list , and sends them to the blockchain.(2): the algorithm is performed by all CNs. Each takes public parameters and identity as input, output node public key , and node secret key . Each randomly selects and computes . They keep confidential and publish .(3): MDU performs the algorithm. The algorithm inputs and user and outputs MDU’s user public key and user private key . The algorithm randomly selects and computes , . It sets and .(4): CN performs the algorithm. The algorithm inputs public parameter , user , user attribute set , node secret key and user public key and outputs transfer key . For all attributes, , if u is managed by . Then randomly selects and computes and . Then, sets and sends it to MDU and CSP. CSP adds to the key list .(5): MDO performs the algorithm. Let be a matrix and be the function that maps each row of to an attribute. The algorithm randomly selects and sets , selects a positive integer , and concatenates bit 0 string after the message , which is used for outsourced decryption verification. The algorithm uses the algorithm to obtain the ciphertext of the message : , where || denotes concatenation of a string. Then, it computes .The algorithm randomly selects and sets vector , . For , the algorithm randomly selects and computes , ,, , , , , , and . The algorithm uploads to CSP and uploads to blockchain.(6): MDU performs the algorithm. It inputs public parameter , transfer key , user private key , node public key , user attribute set , and a new access policy and outputs reencryption key . The algorithm randomly selects , and sets two vectors and . Then, for , the algorithm sets and . The algorithm computes , , , and and then sets , , , and . Finally, the algorithm generates and sends to CSP.(7): CSP performs the algorithm. It inputs public parameter , reencryption key , and ciphertext and outputs reencryption ciphertext . After receiving sent by the MDU, the algorithm will check whether the attribute set in matches the access policy in . If does not match , it indicates is illegal, and CSP terminates the reencryption operation. If matches , the algorithm performs the following steps to compute the reencrypted ciphertext . The algorithm sets and computes constant to let . Then, the algorithm computes and and then computes . Finally, the algorithm outputs .(8): CSP performs the algorithm. It inputs public parameter , ciphertext , user attribute set , transform key , and user public key and outputs semidecrypted ciphertext The algorithm checks whether matches in ; if does not match , it aborts; otherwise, the algorithm lets and computes to let . Thus, , . The algorithm computes and . The algorithm sends semidecrypted ciphertext to MDU.(9): this algorithm is performed by MDU; MDU uses to decrypt and obtains . The algorithm computes . It recovers and computes , . The algorithm checks if there is a redundancy appended after ; if it is, . Then, it checks if ( can be obtained in blockchain); if it is, the message can be obtained by truncating -bit 0 string. Otherwise, CSP is dishonest to return an incorrect semidecrypted ciphertext, and algorithm outputs .(10): CSP performs the algorithm. It inputs public parameter , ciphertext , user attribute set , and transform key and outputs semidecrypted ciphertext The algorithm checks whether matches in ; if does not match , it aborts. Otherwise, the algorithm performs the following steps: CSP let and computes to let . It then computes and . The algorithm sends semidecrypted ciphertext to MDU.(11): This algorithm is performed by MDU; it inputs to decrypt to obtain . The algorithm uses to compute and then recovers. MDU computes and . The algorithm then checks if there is a redundancy appended after , if it is, . Then, it checks if ( can be obtained in blockchain), if it is, the message can be acquired by omitting -bit 0 string. If not, CSP is dishonest to return an incorrect semidecrypted ciphertext and the algorithm outputs .(12): the algorithm is performed by CN and CSP; CN first updates and uploads the latest to blockchain. CSP checks the latest in blockchain and inputs malicious user’s in and and outputs an updated . If the user’s needs to be revoked, CSP will find {} in and delete in .
5.2. Correctness
5.2.1. Correctness of Decryption of Original Ciphertext
The CSP checks whether matches in ; if does not match , it aborts; otherwise, the algorithm lets and computes to let . Thus, , . There is . CSP computes formula (3) to acquire .
CSP then computes formula (4) to acquire .
MDU computes formula (5) to acquire .
It recovers and computes , . MDU checks if there is a redundancy appended after ; if it is, . Then, it checks if ( can be obtained in blockchain); if it is, the message can be obtained by truncating -bit 0 string. Otherwise, CSP is dishonest to return an incorrect semidecrypted ciphertext and algorithm outputs .
5.2.2. Correctness of Decryption of Reencryption Ciphertext
First, compute and separately.
Then, compute .
The CSP checks whether matches in ; if does not match , it aborts. Otherwise, CSP performs the following steps: CSP let and computes to let . CSP computes formula (6) to acquire .
CSP then computes formula (7) to acquire .
MDU computes formula (8) to acquire .
Then MDU can recover . MDU computes and . The algorithm then checks if there is a redundancy appended after ; if it is, . Then it checks if ( can be obtained in blockchain), if it is, the message can be acquired by omitting -bit 0 string. If not, CSP is dishonest to return an incorrect semidecrypted ciphertext and the algorithm outputs .
5.3. Security Analysis
Theorem 2. If the q-DBPBDHE2 assumption holds, then the proposed scheme is statically secure under ROM.
The proof of Theorem 2 is based on the establishment of Lemmas 3 and 4. Therefore, the proofs of Lemmas 3 and 4 will be given as follows, respectively.
Lemma 3. If the q-DBPBDHE2 assumption holds, then the RW scheme proposed in [32] is statically secure under ROM.
Proof. Lemma 3 is proved in [32], so Lemma 3 is valid.
Lemma 4. If the RW scheme constructed in [32] is statically secure under ROM, then the proposed scheme is statically secure under ROM.
Proof. Assuming there is a PPT adversary Adv that can break the proposed scheme with a non-negligible advantage ε, then there must exist a simulator B who can break the RW scheme with advantage ε. Among them, B can break the proposed scheme with Adv and the challenger C in RW. The relevant phases are as follows. (1)Initialization phase: sends the public parameter in the RW scheme to the simulator . performs algorithm and sends the uploaded public parameter to .(2)Query phase: does the following query to .
Query 1: chooses some , asks for the corresponding public key , then sends to . performs in [32] to generate and sends it to . After that, performs to generate , then updates public key and sends them to .
Query 2: selects some legitimate users and asks for their key pairs . performs to generate the corresponding and , then sends to .
Query 3: asks for the transfer key: first forwards the query to to get the result output by scheme [32]. Then performs to generate transfer key and return it to . During the inquiry process, calculates the transfer key corresponding to in two cases, specifically:
Case 1. For , attribute , randomly selects and computes , . then acquires the transfer key .
Case 2. For , attribute , randomly selects , , computes and . Since is in , there must be an unknown that can make . Thus, the corresponding transfer key can be obtained as , . then sends the transfer key to .
Query 4: asks for re-encryption key: first forwards the query to to get the result output by scheme [32]. Then, sends users’ , users’ attribute sets and a new access policy to . performs to generate re-encryption key . Then returns to . is generated by algorithm. (3)Challenge Phase: submits two equal-length plaintexts , , and an access policy to . randomly selects , executes algorithm to calculate challenge ciphertext and return it to . The limitation is that the of the MDUs who asked for the private key during the query, their attribute set does not satisfy .(4)Guess Phase: outputs guess on b. At this time, gives different guess values 𝑏 according to the different guesses of .
In the above game, can consider that is the challenger in scheme [32] The transfer key sent by corresponds to the user private key generated by 𝑈𝑠𝑒𝑟𝐾𝑒𝑦𝐺𝑒𝑛 algorithm in the scheme [32]. At the same time, can determine the symmetric key in the proposed scheme according to the value of . Mainly, the corresponds to the message input by the algorithm in the scheme [32]. Since the RW scheme is statically secure, the proposed scheme is also statically secure. Lemma 4 is proved.
In summary, from the proofs of Lemmas 3 and 4, it can be proved that Theorem 2 is also valid. Therefore, the proposed scheme is statically secure under ROM.
6. Performance Analysis
In this section, the function and efficiency of the proposed scheme and other related schemes [19, 20, 23, 24, 28] are evaluated and compared. We compared the aforementioned 5 schemes with our scheme in terms of system functions. The specific comparison is shown in Tables 2 and 3.
Figures 3–5 shows the operating time of different algorithms. We use Java language in the Windows10 environment, and Java Pairing Based Cryptography (JPBC) is used as the cryptography library. and are selected from the elliptic curve . is a symmetric bilinear map. The length of the elements in and is 1024 bits. The encryption algorithm is used as a symmetric-key encryption algorithm. The hardware is AMD R5 4600u CPU, 2.1 GHz frequency, and 8GB memory.
Table 2 shows the function comparison; schemes [19, 20, 23, 24] support ciphertext reencryption and collision resistance. Compared with the 4 schemes, the proposed scheme has the most comprehensive functions. Though scheme [19, 20] support ciphertext reencryption, they do not support outsourced decryption. Thus, MDU will face huge decryption costs. Although schemes [19, 20, 28] realize user revocation, the keys of unrevoked users need to be updated when the revocation occurs, which brings additional computational overhead. The user private keys in schemes [19–24] are all generated by KGC; once KGC is compromised, it will cause serious information security incidents. In fact, there exists no fully trusted KGC in the world. The proposed scheme does not need a KGC, and the user private keys are generated by users. Besides, consortium blockchain is introduced to ensure medical data will not be tampered with; consensus nodes work together to ensure blockchain operation. Schemes [20, 24] cannot realize user revocation. Even if a user leaves the system, his private key can still decrypt the ciphertext in the system, which may lead to abuse of key authority. Although schemes [20, 28] support decryption outsourcing, they lack decryption verification. This makes data users cannot distinguish whether the CSP has tampered with the result of outsourced decryption. In addition, the scheme [23] only realizes the reencryption from ABE to IBE, not the reencryption from ABE to ABE. ABE can realize “one-to-many” encryption, while IBE can only realize “one-to-one” encryption. In summary, the proposed scheme is practical in functions and is suitable for cloud storage environments.
Table 3 shows the system efficiency comparison of different schemes. For simplicity, denotes the number of user’s attributes, denotes the number of rows in , denotes the number of rows used for decryption in , denotes the bilinear pairing operation in , and denotes the exponential operation in . Since the calculation cost of the schemes is related to 𝑙, |𝐼|, |𝑆|, the variables are unified for the convenience of discussion. Let the user attribute be a subset of the policy attribute; the user attributes always satisfy the access policy so that |𝐼| is consistent with |𝑆|. Thus, the computational cost of the solution is related to 𝑙 and |𝑆|.
It can be seen from the results given in Table 2 and Figures 3–5, schemes [23, 28] have a lower computational cost. The main reason is that in scheme [23], the ciphertext after reencryption is in IBE form, not ABE form, which makes its reencryption key cost is low. Scheme [28] does not support reencryption, so it has a low computational cost. Meanwhile, although schemes [20, 24] share the computational cost of the reencryption key to the trusted center, compared with the proposed scheme, the above two schemes have higher computational costs in the decryption stage. The computational cost of scheme [19] is the highest in all phases. Finally, from the perspective of total computational cost, the users in the proposed scheme have a lower computational overhead than users in schemes [19, 20, 24]. Therefore, the proposed scheme is efficient in computing.
7. Conclusion
This paper proposed a medical data sharing scheme supporting ciphertext reencryption. The proposed scheme can employ attribute-based proxy reencryption technology to allow the cloud to reencryption ciphertext. The reencryption key was provided by a user with decryption authority and the cloud cannot obtain the plaintext. It can effectively reduce the bandwidth and time cost caused by the round-trip transmission of ciphertext. Simultaneously, the proposed scheme makes use of a consortium blockchain to store public keys and public parameters and update the revocation list. The data stored on the blockchain is secure and cannot be tampered with. Consensus nodes jointly maintain the consortium blockchain, which can prevent security and privacy issues caused by KGC’s overcentralization. Ultimately, based on the q-DBPBDHE2 difficult problem assumption, the proposed scheme is proved to be statically secure. Hence, the proposed scheme is practical for secure access control and sharing of medical data in the cloud storage environment.
Data Availability
All data, models, and codes generated or used during the study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work is supported by the National Natural Science Foundation of China (Grant No. 61972094) and the Foundation of State Key Laboratory of Information Security (Grant No. 2021-ZD-02).