Abstract

With the development of the Internet of Things and the demand for telemedicine, the smart healthcare system has attracted much attention in recent years. As a platform for medical data interaction, the smart healthcare system is demanded to ensure the privacy of both the receiver and the sender, as well as the security of data transmission. In this paper, we propose a privacy-preserving data transmission scheme where both secure ciphertext conversion and malicious users identification are supported. In particular, the protocol is introduced to guarantee the two-way privacy of communication parties. Meanwhile, we adopt proxy reencryption algorithm to support secure ciphertext conversion so as to ensure the confidentiality of data in many-to-many communication pattern. In addition, by taking advantage of the concept of blockchain technology, a novel protocol is proposed to prevent data from being tampered with and effectively identify malicious users. Theoretical and experimental analyses indicate that the proposed scheme is practical for smart healthcare with high security and efficiency.

1. Introduction

With the extension of average life expectancy and people’s increasing demand for health, the demand for smart healthcare systems such as telemedicine and e-health system is more and more urgent [13]. The smart healthcare system is an IoT health system composed of cloud computing, smart wearable devices, an expert system based on artificial intelligence, and so on [46]. The deep learning technology and data mining technology also promote the development of smart healthcare system [7, 8], which is convenient for doctors to quickly diagnose diseases and formulate medical plans and to ensure that everyone can get adequate medical resources [9]. In addition, some scholars introduce blockchain technology into the smart healthcare environment [1012]. They utilize the characteristics of blockchain such as decentralization and antitampering to design the smart healthcare schemes. Those schemes can realize data sharing and ensure the confidentiality and correctness of the data. During the research, scholars discovered that there were two security challenges in the process of medical data transmission [13, 14]: The first is how to ensure the confidentiality of medical data during the interaction; that is, malicious users cannot obtain or tamper with the data. The second is how to realize the two-way privacy protection between the server and the client side. Therefore, we need to discuss and solve the above two security challenges in this paper.

Consider the following situation: the patient who suffers from many diseases goes to different specialist hospitals for treatment, and so many medical records are stored by different servers of hospitals that are not connected in the same network. That is, it is difficult for doctors to obtain the data across the different networks. To settle the mentioned problem, we suppose that all the data are stored in the same server. However, all data in this server are returned to the doctor when he employs the oblivious transfer (OT) protocol to request the data, which leads to the high communication overhead. Thus, we assume that all data are stored in the distributed server, and the users, hospitals, and also servers are all in the smart healthcare system, where the patients’ records can be accessed by the departments’ doctors from the different hospitals. In fact, the stored data are susceptible to collusion or tampering because of the semitrusted server. The confidentiality of stored data cannot be ensured when users employ those data. Additionally, a user employs the amount of data to request it from the server, which can try to understand the corresponding relationship between the sequence number and the stored data. Some researchers utilize the oblivious random access memory (ORAM) protocol [15] to hide that relationship [16, 17]. Meanwhile, it is only applied to some simple systems due to its complex ORAM structure and the great increase in cost overheads. Thus, how to ensure that the server makes users know the data without knowing the serial number is one of the main contents of our scheme. Moreover, the public keys of the distributed servers are different for users owing to those servers which belonged to different hospitals. In view of the above, the data in such servers can be comprehended by users, which exposes the privacy of stored data. Then, some data are attacked by malicious users to focus on, in accordance with that private information. What is more, the authorities of the user can be faked or tampered with by the revoked or malicious users who can collude the data.

Motivation of This Paper. As is mentioned above, the existing data transmission schemes are not suitable for the smart healthcare environment. Therefore, our goals are to protect user privacy and guarantee the security of data transmission based on OT and blockchain technology under the smart healthcare environment. To accomplish this goal, the three following crucial issues should be considered for us. First, the confidentiality of data should be assured during the process of data transmission. The medical data are related to the life safety of patients; once they are tampered with or faked, this will endanger the lives of patients and put the hospital in financial compensation. Second, while guaranteeing that a piece of accessed data is not known by the server, the other data in it cannot be learned by the user. In addition, the stored data in such servers cannot be figured out. In case of reveal, the privacy of stored data may be leaked out. Finally, the revoked or malicious users who try to collude should be discerned by the group manager. They will go beyond their authority to access data or modify medical data, leading to medical accidents in the hospital.

1.1. Main Contributions

We design a privacy-preserving scheme for data transmission based on oblivious transfer and blockchain technology in the smart healthcare environment which is to resolve the above issues. The main contributions are as follows:(1)A novel protocol supporting two-way privacy-preserving and distributed servers is proposed. Suppose that data is stored in multiple servers. Once a doctor requires data, he needs to employ many private keys of servers to decrypt those ciphertexts. In that way, the privacy of servers where the data is stored will be exposed. By applying this novel protocol, a doctor can decrypt all the ciphertexts with only his key. In other words, this protocol not only queries data quickly but also protects the privacy of servers and doctors. In addition, the proposed protocol can efficiently support the access control of users and many-to-many data transmission pattern.(2)A secure data transmission scheme supporting collusion resistance and to prevent data from being tampered with is proposed. Our scheme is a data secure transmission protocol based on blockchain technology and OT technology. We utilize the characteristics of blockchain structure to store the user’s identity in blocks and then form three lists, namely, patient identity list, doctor identity list, and revocation user list. Therefore, our protocol can effectively verify revocation or malicious users and resist their collusion attacks. Meanwhile, in terms of the hash value in blockchain, malicious users cannot modify the data.(3)Data confidentiality is guaranteed and the computation of our scheme is effectively reduced. We analyze and prove the security of the proposed scheme. We provide a performance comparison between protocol and other protocols through a theoretical performance analysis and an experimental analysis.

1.2. Related Work

Oblivious transfer (OT) has gradually become an important research direction in the field of multiparty computation (MPC). At present, according to the total amount of data and the number of choices, the research of OT protocol is mainly divided into four categories: classical oblivious transfer protocol [18], 1-out-of-2 oblivious transfer protocol [19], 1-out-of-n oblivious transfer protocol [20], and k-out-of-n oblivious transfer protocol [21].

protocol was proposed by Brassard et al. [20] firstly in 1986; they invoked protocol times to implement protocol. On the basis of the above, Gertner et al. [22] firstly achieved a distributed version of protocol with information-theoretic security and sublinear communication complexity. In 2001, Naor et al. [23] described a novel protocol, which improved the efficiency of multiple invocations of OT applications. In 2004, Tzeng [24] designed a secure and efficient protocol under the assumption of the decisional Diffie-Hellman problem. After that, based on the above, an adaptive k-out-of-n oblivious transfer scheme was proposed by Chu and Tzeng [25], which allowed the receiver to choose the messages one by one adaptively. In 2015, the simplest and most efficient protocol for protocol was presented by Chou et al. [26] and it could resist some active attacks. Then, in 2007, Hauck et al. [27] proposed an protocol under the CDH assumption, which was built on ideas from the CO protocol. In 2020, Wang et al. [28] presented an protocol and the Private Set Intersection (PSI) protocol to protect user privacy in the case of VANET feature matching.

protocol was proposed by Bellare et al. [21] firstly in 1989, where a receiver could select and receive multiple ciphertexts at one time. Naor et al. [29] described a novel construction for protocol which is more efficient than k repetitions of protocol. Then, the classical and universal protocol was designed by Naor et al. [23]. In 2005, an protocol with adaptive queries was proposed by Naro et al. [30], and it was considerably more efficient than k repetitions of protocol. After that, Chu et al. [31] proposed several two-round protocols under the decisional Diffie-Hellman problem, in which a receiver sent data to a sender and he returned data. In 2010, a secure and low-bandwidth-consumption scheme based on bilinear pairings was proposed by Chen et al. [32]. A novel protocol for private information retrieval which was more suitable for smart cities was presented by Lou et al. [33]. In 2018, Lai el al. [34] proposed an scheme with the least communication cost, which preserved a sender’s security and the privacy of a receiver’s choice.

What is more, some researchers have integrated OT technology into blockchain scheme in order to solve the problem of easy exposure of private data in the blockchain. In 2017, Hsiao et al. [35] combined the advantages and properties of blockchain and secret sharing scheme, Paillier’s homomorphic encryption, and oblivious transfer to construct a decentralized e-voting system. This scheme could protect the anonymity of voter’s identity, the privacy of data transmission, and verifiability of ballots during the billing phase. In 2019, Tso et al. [36] proposed the decentralized electronic voting and bidding systems based on a blockchain and smart contract, which uses cryptographic techniques such as oblivious transfer and homomorphic encryptions to improve privacy protection. Then, in 2021, Li et al. [37] presented a fair scheme for big data exchanging that allows buyers and sellers to autonomously and fairly complete transactions, without involving any third-party middle person. This scheme employed OT technology to preserve the privacy of transactions.

1.3. Organization

The structure of the paper is organized as follows. Some preliminaries in cryptographic are presented in Section 2. The system model, design goals, and threat model are described in Section 3. The proposed scheme is introduced in detail in Section 4. The security and performance analyses are provided in Sections 5 and 6, respectively. Section 7 concludes this paper and our work.

2. Preliminaries

2.1. Proxy Reencryption Technology

We adopt the key-private proxy reencryption scheme which was proposed by Ateniese et al. [38]. This algorithm applies proxy reencryption technology to achieve ciphertext conversion, which converts a ciphertext of to a ciphertext of . The specific design of this scheme is as follows.(i)Step 1. : This is the initialization phase for generating parameters. Input security parameter and then the public parameters are output by this algorithm.(ii)Step 2. : This algorithm is applied to generate the public-private key pair for users. Public parameter is input, and then the key pair is produced for users.(iii)Step 3. : This algorithm is employed to encrypt the message via a public key from . and message are input, and then an original ciphertext is produced by this algorithm.(iv)Step 4. : This algorithm generates the conversion key, which realizes the transformation from to . A private key of and a public key of () are provided, and the conversion key is output. This phase is crucial for reencryption data.(v)Step 5. : To gain the transfer message , this algorithm utilizes the conversion key to reencrypt a message . Input A reencryption key and an original ciphertext are input, and then a reencryption ciphertext from to is output.(vi)Step 6. : Finally, a private key and a ciphertext are provided; this algorithm can compute a plaintext .

2.2. Oblivious Transfer Protocols

The concept of OT was first proposed by Rabin [18] in 1981. In Rabin’s protocol, the sender only wanted the receiver to get the message he chooses, and the receiver did not want the sender to know about other messages, which guaranteed the privacy of both parties. Then, the 1-out-of-2 data transmission protocol under the semihonest model through three public key cryptography operations was implemented by Naro and Pinkas [23]. The steps of protocol are as follows:(i)Setup: The system generates two prime orders and , where holds. is a p-order subgroup of ; and the system sets as the generator of .(ii)Input: The sender inputs , and receiver inputs .(iii)Output: The receiver outputs .

(a)Step 1. The sender generates a random number and , computes and , and broadcasts .(b)Step 2. The receiver generates a random number ; and two public keys and are generated, where and hold. Then, the number is sent to the sender.(c)Step 3. The sender calculates and . At the same time, he encrypts the data , respectively. The equations are as follows:(d)Step 4. The receiver computes and ; that is,

The concept of protocol is presented as follows. The sender encrypts the secret messages and sends them to the receiver; and the receiver can only recover of them:where holds. However, the receiver cannot determine which , from are required.

2.3. Blockchain Technology

Blockchain is a kind of ledger technology that is jointly maintained by multiple parties, can achieve consistent data storage, is difficult to tamper with, and prevents denial [39, 40]. It has also become a distributed ledger technology. The blockchain is classified into the permissioned blockchain and the unlicensed blockchain according to whether the system has the node access mechanism. The fabric is employed in our paper, which belongs to the consortium Blockchain and is also the first distributed system of blockchain with an access mechanism [41]. Fabric is a modular, extensible, general-purpose blockchain with an access mechanism that supports the execution of distributed applications written in standard programming languages. The key components of fabric are as follows [42].(i)Peers: There are four kinds of peers in Fabric.(a)Committing peer: Each peer in the channel is the committing peer. It receives the generated transaction block, obtains the block structure, and verifies the legitimacy of the block structure.(b)Endorsing peer: The client application must use its smart contract to complete the verification of the transaction, simulate the operation of the transaction, and generate a transaction response containing a digital signature.(c)Leader peer: When the channel has multiple peers, the leader peer is responsible for distributing transactions from the ordering peer to other committing peers.(d)Anchor peer: It helps to communicate with peers in other organizations.(ii)Channel: The channel includes many authorized users, and each user can belong to different channels.(iii)Consensus mechanism: It is defined as the comprehensive verification of the correctness of the blockchain transaction. It includes the SOLO, Kafka, PBFT, and SBFT.

3. Problem Statement

3.1. System Model

Our proposed scheme can be utilized to securely transfer data and also realize the privacy-preserving of the clients and servers. On the one hand, the private information of client side is protected. That is, a user has permission in virtue of the data’s serial number to access data, yet he does not know which server the data is stored in. On the other hand, the private information of servers is protected. That is, a user only can obtain the requested data, and the other data are cannot be learned. This scheme is mainly designed in accordance with the actual situation of the smart healthcare environment. Both doctors and other healthcare workers look forward to acquiring treatment records about a patient in all hospitals as soon as possible. Moreover, the confidentiality of data can be ensured in our scheme, in which a user employs his private key to decrypt the stored data in servers rather than private keys of servers. In addition, this scheme also resists collusion attacks by revoked or malicious users. The system model contains three entities, doctors/ patients (client side), a proxy (blockchain), and servers. Figure 1 shows a system model of the proposed scheme.

A patient cures his diseases in different hospitals or in the same hospitals. In general, the data is stored in the nearest server, which is a server of the current hospital. This means that if a patient has seen a disease in different hospitals, multiple servers (different hospitals) store the patient’s data. Our scheme implements a many-to-many model with users and servers. Firstly, doctors and patients register their identities with the blockchain. The blockchain generates a list of user identities and a list of revoked users so that it can verify their identities. Secondly, a doctor uses the private key of user to encrypt the medical records and then uploads them to a server of his hospital. When a patient goes to a hospital to treat his heart disease, his doctor of this department can gain his past medical records in servers. Thirdly, a doctor sends a request to blockchain for obtaining a patient’s records. The blockchain verifies and checks his identity. If yes, the ciphertext encrypted with the patient’s key needs to be converted into ciphertext which can be decrypted by doctors. The patient and blockchain run the encryption phase to complete the transformation of ciphertext. Fourthly, the blockchain transmits a request which includes some serial numbers of data to servers. Only servers that store the corresponding data respond to that request. Finally, the OT protocol is implemented between the doctor and the server to transmit and decrypt the request data.

3.2. Threat Model

In this section, the security goals and the security models for are provided.

Definition 1. A secure and privacy-preserving protocol should satisfy the following requirements:(1)The protocol should protect the privacy of servers; namely, the users cannot obtain data from the server other than what they requested.(2)The protocol should protect the privacy of users; namely, the servers cannot figure out what data the users access.The security model for server privacy of the protocol is described as follows. In this model, adversary plays the role of users and challenger plays the role of servers (the servers are trusted). The advantage of to break the server privacy is defined as follows:(i)Setup: The system generates system parameters and sends the private keys to the blockchain. Then the blockchain generates several necessary parameters for servers. Adversary chooses data that it can access and chooses the corresponding from . Adversary outputs its target . Then, the blockchain sends corresponding to adversary and the servers send all ciphertexts .(ii)Hash Query: Adversary can query the hash value via this oracle. It takes as input and outputs hash value.(iii)Decrypt Query: Adversary can query plaintext of ciphertext but not ciphertext .(iv)Decrypt: Adversary outputs plaintext . If is right, adversary breaks the server privacy of the protocol.The security model for user privacy of the protocol is described as follows. In this model, adversary plays the role of servers and the challenger plays the role of users (the users are trusted). The advantage of to break the server privacy is defined as follows:(i)Setup: The system generates system parameters and sends the private keys to the blockchain. Then the blockchain generates several necessary parameters for adversary . The users choose data that they can access and choose corresponding from . Then, the blockchain sends corresponding to the users and the servers sends all ciphertexts . Adversary outputs its target .(ii)Hash Query: Adversary can query the hash value via this oracle. It takes as input and outputs hash value.(iii)Challenge: The user selects and outputs and .(iv)Guess: Adversary outputs . If , wins.

4. The Proposed Scheme

The proposed scheme is presented in detail in this section. Our scheme can be divided into four parts, in which the initialization phase is introduced in Section 4.1, the user registration phase is described in Section 4.2, the encryption phase is stated in Section 4.3, and the data access phase and protocol phase among three roles are illustrated in Sections 4.4 and 4.5, respectively.

In the smart healthcare system, in the face of complex diseases, the attending doctor will conduct multidepartment consultations or cross-hospital consultations, which are more common. In addition, a patient can treat diseases in different hospitals, a hospital has its own servers, and the users who have access permission can request the data of servers in the smart healthcare system. In our scheme, to protect the two-way privacy of the server and user, the data are allocated to the nearest server randomly, which obeys the principle of proximity; that is, the user with permission can store the data in which the server is near. We show the main idea of the system by giving an example. A patient suffers from high blood pressure, heart disease, and toothache. When he goes to the dental clinic, the doctor not only needs to diagnose his teeth but also prescribes medicine or prepares for surgery based on his other medical history. At this moment, an attending doctor verifies his permission to request all the data about that patient. The requests can be sent to the determined server which has stored the data of that patient. Then, to protect the privacy information, only the determined server delivers all its data to the requester by using the designed protocol. This protocol guarantees that the server does not have idea about the accessed data, and the user cannot obtain the extra data and figure out the source of data. For instance, if the sequence number 5 is requested from the user, he sends the requirement to all the servers in the smart healthcare system. Only sever that has the data about that patient responds to the request. More comprehensively, assume that the sequence number is accessed; the user sends the requests to servers (the needed data are in servers and ). At last, servers and have the opportunity to communicate with the user. In the meantime, blockchain technology is merged into our scheme, which maintains the attributes list and stops user attributes from being tampered with. Correspondence between symbols and definitions is shown in Table 1.

4.1. Initialization Phase

We hypothesize that there are distributed servers, and the users with permission to manipulate data (e.g., the doctor, nurse, and healthcare worker) have data, and each piece of data has the same bits.

Input the security parameter , and then the system randomly selects the number , where the formal () holds, server possesses , and is stored in the blockchain. Set as the multiplicative cyclic groups, with bilinear mapping , randomly choose generator , and compute . Set the hash functions and , where is the fixed value.

We initialize the device of proxy based on the blockchain. The security parameter is input; the blockchain computes the formulas and , where represents the label of the patient’s medical data. Then, the blockchain computes and the following finite sets are satisfied, where and hold. is sent to the user. Then are sent to servers orderly.

The symbols and the corresponding meanings are shown in Table 1.

4.2. User Registration Phase

We integrate blockchain technology into user registration phase to maintain the identity lists about users. The data is requested via proxy, while the blockchain inquires and verifies the user’s identity in accordance with his tag. Only through the verification can the protocol be executed to transmit the data. There are five functions of blockchain in our scheme; they are described briefly as follows:(i)The committing peer generates and maintains blocks for users.(ii)The identity of required users is verified.(iii)The endorsing peer verifies the legality of updated identities; if the transaction is legal, the peer simulates to perform the smart contract. Then, it sends the updated lists to users.(iv)The attributes are prevented from being faked through utilizing the structural characteristics of the block.(v)The revoked and malicious users are distinguished to preclude them from colluding the data.

The user registration phase contains the four following steps to accomplish the registration:(i)Step 1. The key generation center (KGC) chooses as the patient’s private key and computes the patient’s public key . Then, it sends to the patient through the secure channel.(ii)Step 2. The key generation center (KGC) chooses as the doctor’s private key and computes the doctor’s public key . Then, it sends to the doctor through the secure channel.(iii)Step 3. KGC inserts into the patient list and inserts into the doctor list. Then KGC sends the above lists to the blockchain via the smart contract.

4.3. Encryption Phase

After the doctor diagnoses the patient, he records the medical data on the computer. Subsequently, the encryption algorithm will be executed on the data.(i)Step 1. : The doctor chooses , computes and , , and computes responses and . Then, the doctor sends and to the blockchain. Once the blockchain obtains , it computes and checks whether and . If the above equation holds, the blockchain checks whether the tuple belongs to the doctors list. If yes, the verification process is completed. Then, the doctor can upload data.(ii)Step 2. : In order to facilitate users to accurately access data, the data needs to be classified in the light of departments and patients. Generate a tag corresponding to the departments and patients , and add it to . The advantage of this is that the doctor can accurately acquire all the data about a certain department of this patient, and some invalid data are automatically removed, where the communication overhead of gained data by the OT protocol is reduced.(iii)Step 3. : The doctor encrypts data of patient, which employs the patent’s public key and encryption (Enc) algorithm from scheme [38]. Then, upload the ciphertext to the server.

4.4. Data Access Phase

(i)Step 1. When doctor sees a patient , he sends and to the blockchain, along with the proof , where , , , and .(ii)Step 2. The blockchain computes and checks whether and . If the above equation holds, the blockchain checks whether the tuple belongs to the doctors list. If yes, the blockchain executes the next step.(iii)Step 3. The blockchain sends to patient . The patient computes transform key via in the scheme and sends it to the blockchain.(iv)Step 4. The blockchain sends and to all servers. The servers transform ciphertext of patient , namely, compute .

4.5. Protocol Phase

Assume that doctor treats ’s heart disease; he sends a data request which includes all the serial numbers of data from different hospitals about this patient’s heart treatment records to servers. Suppose that the doctor needs to require the data with the serial number , and those data are stored in servers , . The steps of the algorithm are shown in Figure 2.(i)Step 1. The doctor (client side) transmits request to the blockchain side. Then, server responds and executes the following steps.(ii)Step 2. The client side selects parameters randomly and computes all parameters of serial number of data; that is, , where holds and parameters are calculated previously. Then, () is sent to the blockchain.(iii)Step 3. The blockchain side computes and and sends to server . Then, it delivers and to the client side.(iv)Step 4. The server side computes all the ciphertexts of its and transmits to the client side.(v)Step 5. Only if meets, the formulas and can be computed. After that, the ciphertexts of requested data are calculated.(vi)Step 6. . The doctor employs his key to decrypt the above ciphertext. Finally, the doctor obtains all the heart disease records about that patient.

5. Security Analysis

Theorem 1. The proposed is server privacy, if the CDH assumption holds. Assume that any probability polynomial time adversary can break the server privacy of the scheme; it can be utilized to solve CDH problem. The definition of CDH problem is that, given a tuple where , the adversary should compute .(i)Setup: In this phase, after challenger obtains the CDH tuple where , it sets and . Then, it generates other system parameters to complete the setup of the whole scheme.(ii)Query: In the hash query phase, adversary queries the value of . Challenger setsand outputs to adversary . In the Decrypt query phase, adversary cannot query the plaintext of ciphertext .(iii)Decrypt: Adversary outputs plaintext . If , wins this game.

Proof:. If is right, it means that can compute , where . Therefore, challenger can utilize the adversary to output the solution of the CDH problem. In conclusion, if wins, challenger can output to solve the CDH problem. We can obtain that .

Theorem 2. The proposed is user privacy, if the DDH assumption holds. Assume that any probability polynomial time adversary can break the user privacy of the scheme; it can be utilized to solve DDH problem. The definition of DDH problem is that, given a tuple where , , or , the adversary should decide whether .(i)Setup: In this phase, after challenger obtains the DDH tuple where and or , it sets and . Then, it generates other system parameters to complete the setup of the whole scheme.(ii)Query: In this phase, adversary queries the value of , and challenger guesses the targets of adversary A, t0 and . Then, it setsand outputs to adversary .(iii)Challenge: Challenger chooses and sets and .(iv)Guess: Adversary outputs . If , challenger outputs (i.e., ). Otherwise, outputs (i.e., ).

Proof:. We assume that the probability of challenger obtaining is and the probability of obtaining is also . We assume that the advantage of winning is and denote by challenger solving the DDH problem. It is easily deduced that and . Therefore, we can get . So, . Since the DDH assumption holds, it is difficult for to decide whether . Therefore, adversary ’s advantage to break the user privacy is negligible.

Theorem 3. Any revoked user cannot tamper with the data or his identity. Malicious or revoked users cannot get through the verification at our scheme. Meanwhile, if they attempt to request data, then they would be identified via the scheme. Therefore, the malicious or revoked users do not obtain the permission to request the data.

Proof:. Firstly, the user needs to get through the identity authentication at the data access phase. Whether this formula , is satisfied is checked. In general, a malicious user’s commitment value cannot meet the calculation formula, and he would be judged as an invalid user by scheme. Secondly, even if a malicious user tries to modify his identity, the list of user identities is stored in the blockchain. That is, the modified identity cannot satisfy the formula . Then, that malicious user would be judged as an invalid user.
ensures the two-way privacy of communication parties, and the proxy reencryption algorithm is secure. Therefore, the confidentiality of data can be protected by our proposed scheme.

6. Performance

In this section, we first analyze the proposed scheme and provide a simplified comparison in Table 2. Then, an experimental evaluation of the proposed scheme is presented.

6.1. Performance Analysis

In our scheme, most of computation cost comes from the XOR operation, hash operation, Weil operation, power operation in , and power operation in , which are denoted as , , , , and . In Table 2, presents the number of doctors registered, describes the number of patients registered, is the number of patient ciphertexts, illustrates the number of servers, and states the number of .

In registration phase, KGC generates the public-private key pairs for doctors and patients, and it costs computation overhead . In encryption phase, blockchain verifies and checks the identities of client via lists to discern malicious or revoked users, which costs computation overhead. Also, this phase is applied to encrypt the plaintext by using private key of patients, which defends the data confidentiality and costs computation overhead. In data access phase, the ciphertext encrypted with the user’s key should be converted into the ciphertext encrypted with the doctor’s key, which costs computation overhead. Moreover, this phase is also not involved in the general OT protocol, mainly to hide the access path of the server. In the phase, it realizes the privacy-preserving of clients and servers.

6.2. Performance Evaluation

We simulate our proposed scheme employing the C language with PBC library (pbc-0.5.14) and GMP library (GMP-6.1.2) to evaluate the protocol. All simulations are implemented on a desktop computer with the following features: (1) CPU: Intel(R) Core(TM) i5-9500 CPU @ 3.00 GHz 3.00 GHz; (2) random access memory: 8.0 GB; (3) OS: Ubuntu 14.04 over VMware workstation full 12.5.2; (4) system type: 64-bit.

We provide the computation comparison between doctors and patients in the protocol in Figure 3. The X-axis describes the number of requested by doctors. The Y-axis represents the time cost to perform the protocol in doctor side and patient side. As shown in Figure 3, the time cost of doctors is higher than that of patients. The patient only needs to assist the blockchain to complete the transformation of the ciphertext. However, doctors need to participate in all the protocols and calculate the transmission ciphertext of data. Meanwhile, if the length of the ciphertext is fixed, the cost of transforming the ciphertext is roughly the same. Therefore, the patient’s expenditure at this phase is approximately straight.

We provide the computation comparison of client side, blockchain, and servers in Figure 4. In order to make the comparison more obvious, the three entities are put in Figures 4 and 5. The computational overhead of the client side and blockchain is described in Figure 4; the X-axis represents the number of and assumes that the number of servers is 10. For the server side, the X-axis represents the number of patient ciphertexts in Figure 5. As shown in the figures, we find that the overhead of the client is much higher than that of other entities. The proposed protocol is an interactive protocol, which requires interaction between client side and servers to complete data transmission. At the meantime, this protocol uses the many-to-many data transmission pattern.

7. Conclusion

In this paper, a privacy-preserving data transmission scheme based on the oblivious transfer and blockchain technology in the smart healthcare system is proposed. Based on the proxy reencryption technology, the proposed protocol can implement the ciphertext conversion to ensure the privacy of servers. Meantime, the two-way privacy between the client side and servers is guaranteed via the proposed protocol, which also ensures the security and efficiency of data transmission. By taking advantage of blockchain technology, the proposed scheme can prevent data from being tampered with and effectively identify malicious users. After analyzing the protocol security, the confidentiality of data and security of our scheme are proved. Finally, the results of performance evaluation and experimental comparison can be considered as a validation of our protocol, making it substantially more convincing.

Data Availability

The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported by the National Natural Science Foundation of China under Grant nos. U1836115, 61672295, 61922045, and 61672290; the Peng Cheng Laboratory Project of Guangdong Province PCL2018KP004; the Postgraduate Research and Practice Innovation Program of Jiangsu Province (KYCX21_1003, KYCX21_0998, and KYCX21_1002); the CICAEET fund; and the PAPD fund.