A Blockchain-Assisted Verifiable Outsourced Attribute-Based Signcryption Scheme for EHRs Sharing in the Cloud

The sharing of electronic health records (EHRs) has shown great advantages in the accurate treatment of patients and the development of medical institutions. However, it is easy to cause some security problems in the process of medical data sharing. Generally, after a patient’s EHRs are generated by different medical institutions, they are outsourced to the cloud server (CS) by the authorized medical institutions for storage, which causes the patient to lose control of EHRs. Moreover, malicious medical institutions and semi-trusted cloud servers may collude to tamper with EHRs to seek benefits, which threatens the integrity of EHRs. Therefore, we propose a blockchain-assisted verifiable outsourced attribute-based signcryption scheme (BVOABSC) which realizes the secure sharing of EHRs in a multi-authority cloud storge environment. Firstly, we use the attribute-based signcryption algorithm to realize the confidentiality and unforgeability of the EHRs and protect the privacy of the signer. Secondly, it greatly reduces the computational burden of users by using verifiable outsourcing computation mechanism. Most of the designcryption calculation is performed by the cloud server, and the correctness of the generated partial designcryption ciphertext is verified by users. Furthermore, we use blockchain technology to protect outsourced EHRs from tampering by illegal users. Specifically, each operation on outsourced EHRs is stored as a transaction on the public blockchain, which ensures that EHRs cannot be modified. At the same time, the auditor can verify the integrity of the outsourced EHRs by checking the corresponding transactions. In addition, the smart contract created by the patient can solve the problems in cloud storage, such as tampering EHRs and returning incorrect results. Finally, security analysis and performance evaluation show that the proposed BVOABSC scheme satisfies stronger security and higher efficiency than similar schemes.


I. INTRODUCTION
With the rapid development of the Internet and the introduction of our country's new medical reform policies, the number of electronic health records (EHRs) has increased dramatically. Taking the patients' health throughout life as the core, EHRs realize the dynamic collection of multi-channel information and meet the information resources required by The associate editor coordinating the review of this manuscript and approving it for publication was SK Hafizul Islam . patients for self-care. EHRs have great application value in the fields of hospital development, clinical services, clinical research, and patient health. For example, a variety of standardized templates and auxiliary tools provided by EHRs can free doctors from the heavy medical record writing work and assistant them to focus on the diagnosis and treatment of patients [1].
A large number of EHRs are generated after the patients undergo medical examinations, which are basically kept in separate hospitals. As a result, EHRs face a problem VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ called information island [2]. It takes a lot of resources and time to transfer EHRs among the databases of different medical institutions when patients and doctors need to use medical data. Fortunately, EHRs sharing among medical institutions can solve these problems. It can provide more historical reference materials for doctors' decision-making and improve the correct rate of diagnosis of the patient's diseases. However, EHRs sharing has many problems. First, the EHRs model used by various medical institutions is quite different and the EHRs format is not unified. Second, users need to verify their identity and audit their access rights to access EHRs, which leads to a long access cycle. Third, the huge EHRs system involves users' personal privacy, leading to the problems such as low storage security, data leakage, and data tampering. Therefore, how to solve the problems above is a research hotspot in the medical industry.
With the rise of cloud storage, EHRs have been significantly developed in recent years. In the cloud storage model, cheap computing and huge capacity attract more and more users to outsource EHRs to cloud servers to save local storage and maintenance costs. To improve the capability sharing of EHRs, cloud storage technology is used to build a regional medical information sharing platform, which integrates different medical institutions' systems comprehensively. Zhang et al. [3] firstly elaborated on the security requirements of an electronic medical record system based on cloud computing, and proposed a cloud-based system to achieve patient-centric medical services. An attribute-based medical data sharing system was introduced by [4], which achieves flexible access control for users to medical data stored in the cloud. Hua et al. [5] put forward that the encrypted medical data should be outsourced and stored in the cloud, which provides accurate medical services for patients and protects their privacy. Biswas et al. [6] considered that medical data are stored on a three-tier medical cloud, which facilitates users to access EHRs while ensuring the integrity of EHRs. A medical service model in the cloud (m-health) was constructed by scheme [7], which is an architecture based on distributed events and includes interoperable services with CCR standards. Khan et al. [8] pointed out the problems of multi-party data sharing in the cloud environment, and constructed a scheme that allows data owners to store their data safely in an untrusted cloud environment. These schemes above use the cloud to store and share medical data, which improves the efficiency of storage, retrieval, and sharing to a certain extent. However, these schemes also have the common problem, which is highly dependent on cloud service providers. If some targeted attacks are carried out on cloud service providers, data leakage is likely to occur [9]. For example, the vast majority of network devices are directly allowed to be accessed on the public network under the drive of profits, which leads to hackers to steal sensitive medical data through technical means and conduct illegal transactions to make huge profits. In addition, none of the schemes above consider that cloud servers will collude with doctors to tamper with the outsourced EHRs. If this behavior occurs, it is difficult to detect.
Blockchain technology has the characteristics of decentralization, immutability, and traceability, which can solve the problems of tampering, forgery, and leakage of EHRs. In addition, it can promote data sharing in the production practice of the medical and health field, and protect personal privacy and data security. Bera et al. designed a blockchain-envisioned secure data delivery and collection scheme to provide in-depth challenges [10]. Jiang et al. proposed a health information exchange platform based on blockchain. Offline storage and online verification are used to process data, so that the patient's privacy information is protected [11]. Azaria et al. [12] proposed a blockchain-based record management application for processing EHRs, solving the fragmentation of EHRs and the privacy protection of patients, and providing participants with data authorization, data auditing and data sharing. These schemes use blockchain technology to perfectly solve the problems of the concentration of medical data storage in the cloud storage model, and satisfy the need to complete authorization checks and data verification through a third party. Meanwhile, the security and privacy of medical data are increased, and the efficiency of data sharing is improved. However, all transactions must be disclosed to the nodes in the blockchain to reach a consensus in the blockchain network, which will leak the information in the transaction. How to protect the privacy of transaction information has become an important topic to promote the development of blockchain technology.
In order to solve the problem of privacy leakage of transaction information on the blockchain, scholars at home and abroad proposed that cryptography knowledge can be used to protect data on the blockchain. Essentially, EHRs can be regarded as a high-value privacy asset, and the use of blockchain-related cryptography technology can realize real-time supervision of EHRs authorization process. Peterson et al. [13] proposed a blockchain-based method to share medical data. This scheme requires all participants to share these data in a pre-agreed structure, which improves the efficiency of medical data utilization. However, it does not provide a general access control strategy, which may lead to the leakage of medical data. Dagher et al. [14] proposed an Ancile framework that uses the Ethereum platform to transfer the ownership and control of EHRs to the data owner, develops and utilizes a variety of smart contracts and uses proxy re-encryption technology to further protect the privacy of EHRs. However, the computational overhead is relatively large, and the system efficiency is low. Guo et al. [15] designed a system of the EHRs based on the blockchain, which ensures that EHRs cannot be tampered with or forged, and protects the privacy of patients simultaneously. Roehrs et al. [16] established a patient-centric medical architecture model by using blockchain, which integrates medical data distributed in different medical institutions into one view, and stores the data in the blockchain. However, limited by the storage space of nodes and the network, the blockchain cannot store a large amount of EMRs. Aste et al. [17] believed that the blockchain system has shortcomings such as high energy consumption, slow business processing, and difficulty in unified management. These disadvantages have become obstacles to the development of the blockchain system in actual production.
In response to the limited storage capacity of the blockchain, Zyskind [18] combined blockchain and cloud storage technology to build a private data management platform that can ensure that the participants can still control their own data after the data are uploaded. Through the use of blockchain to control visitors' access without trusting a third party, this platform provides participants with functions such as storing and sharing data. Xia et al. [19] designed a blockchain-based data sharing framework to solve the problem of sharing medical data among large medical databases in a trustless environment. However, the communication overhead of users sharing EHRs is relatively high. Esposito et al. [20] pointed out that medical data involves the privacy of patients, and blockchain can be used to protect the privacy of patients. Liu et al. [21] raised a medical data sharing scheme, which not only realizes the safe sharing of medical data, but also protects the identity privacy of users. This scheme stores encrypted medical data in the cloud, and then writes the index value of the data in the cloud to the blockchain. A cloud-assisted electronic health system based on blockchain was presented by [9]. Storing EHRs in blockchain transactions ensures that EHRs will not be changed and realizes the safe sharing of EHRs. However, storing a large number of EHRs in the block will reduce the efficiency of the system. Therefore, how to store and share EHRs safely and efficiently are challenges we face now.

A. OUR CONTRIBUTIONS
• We combine the attribute-based signcryption (ABSC) algorithm and blockchain technology to design a secure EHRs sharing scheme called BVOABSC. Our scheme can ensure the confidentiality, correctness and unforgeability of EHRs without relying on any trusted entities.
• Our scheme can implement flexible access control to EHRs stored in the cloud, which facilitates CS to verify the users' identity while protecting their privacy. In addition, the proposed scheme can provide anonymous authentication of the source of EHRs due to the characteristics of ABS, which ensures the EHRs are uploaded by authorized users and protects the privacy of signers.
• The proposed scheme ensures that the size of the ciphertext is constant, which means its size has nothing to do with the number of attributes. Hence, our scheme reduces bandwidth utilization and storage overhead, and it is suitable for EHRs sharing environments.
• Our scheme outsources most of the decryption operations to CS, which can reduce the users' computational burden. Moreover, the partial ciphertext generated by CS allows the user to verify its correctness, which means that our scheme satisfies the requirement of verifiability.
• Our scheme can resist malicious doctors and CS colluding to tamper with outsourced EHRs. Even if malicious doctors collude with cloud servers, their computing power cannot bifurcate the blockchain since it is immutable. Besides, the EHRs of each patient are usually generated by multiple doctors, so our scheme adds a time stamp to the EHRs generated by each doctor. Therefore, the safety of EHRs can be guaranteed.
• The proposed scheme is proved to have strong security in the standard model. Compared with similar schemes, it has higher computing performance and lower communication overhead.

B. ORGANIZATION
The rest of this article is organized as follows. In Section II, we review the related work. Section III introduces some preliminaries, such as bilinear maps, computational Diffie-Hellman assumption, the augmented multi-sequence of exponents computational Diffe-Hellman problem, and aggregation algorithm. Sections IV describes the system architecture, the structure of blockchain, security model, the construction of BVOABSC, and correctness. Afterwards, we analyze the security and estimate the performance of the proposed scheme in Sections V and VI, respectively. Finally, we summarize the conclusion in Section VII.

II. RELATED WORK
This section mainly focuses on the EHRs protection scheme based on cryptography, which can realize the safe storage and sharing of EHRs. In the face of massive EHRs, such as personal information, medical records, and drug records, using cloud servers to manage and store these information can free up local storage space and improve management efficiency. However, the security of the patient's sensitive data and the privacy of the users' identity are not protected [22], [23]. Therefore, it is necessary to not only consider reasonable, safe and effective access control, but also protect the privacy of users. The attribute-based encryption (ABE) scheme [24], [25] provide secure access control for EHRs, and attribute-based signature (ABS) realizes the privacy protection of the signer's identity. Nevertheless, both ABE and ABS only separately provide guarantees for the confidentiality or unforgeability of messages. The ABSC cryptographic mechanism combines the characteristics of ABE and ABS, which can simultaneously realize data confidentiality and unforgeability. Applying the ABSC scheme to the EHRs system has a stronger security. Further expansion of outsourcing functions on the basis of ABSC can reduce the amount of local calculations for users and greatly improve the practicality of attribute-based cryptosystems. However, there is a possibility for EHRs to be tampered with in this case. The birth of blockchain technology provides a decentralized and trusted platform. The non-tamperable and traceable characteristics of the blockchain can better solve the problems of EHRs management, sharing, transaction and VOLUME 8, 2020 auditing. The above discussion specifically elaborates from three aspects: attribute-based signcryption, attribute-based outsourcing signcryption, and the application of blockchain in EHRs.

A. ATTRIBUTE BASED SIGNCRYPTION
The idea of ABE was first proposed by Sahai and Waters [26], which is a one-to-many encryption mechanism. In this scheme, attributes are used to identify the user's identity information, and the users can encrypt the plaintext message according to a certain access control strategy to achieve fine-grained data access control. As a new encryption mechanism, [27] can solve the shortcomings of the identity-based encryption scheme of a single communication mode and the system taking up a lot of system resources. Applying the ABE scheme to the EHRs system effectively realizes the access control to the EHRs and ensures the confidentiality of the EHRs. Liang et al. [28] proposed an attribute-oriented authentication scheme that can help users establish social relationships and share health information with other trusted users. Lu et al. [29] introduced a user-centric access control scheme, and allowed medical users to decide who can participate in the calculation to assist in the processing of EHRs. Liu et al. [30] presented an online/offline ABE scheme in which the data owners of EHR performed most of the encryption calculations in the offline encryption phase. When the encryption party knows the access policy and EHRs in the online encryption phase, the owner can quickly integrate the information to generate the final ciphertext. Attribute-Based Signature (ABS) was derived from the fuzzy identity signature scheme proposed by Yang et al. [31]. Maji et al. [32] proposed the primitives of attribute-based signatures for the first time and constructed an ABS scheme that supports effective privacy protection and resists collusion attacks. Subsequently, domestic and foreign scholars have done a lot of researches on attribute-based signature, and proposed some applications of ABS in terms of function extension and security improvement. Shahandashti and Safavi-Naini [33] raised a threshold attribute-based signature scheme that can be used for anonymous authentication, and proved its unforgeability based on the computational Diffie-Hellman assumption. Okamoto and Takashima [34] considered the limited number of attributes given to signers by a single trusted authority, and proposed a multi-authority ABS scheme. Tang et al. [35] put forward an efficient authentication scheme for EHRs that implements fine-grained access control in a cloud computing environment. Liu et al. [36] proposed an online/offline attribute-based signature scheme, which realizes data integrity and the privacy protection of signer identity with low local computing cost.
Zheng [37] first introduced the concept of signcryption. The design core of the signcryption scheme is to realize both encryption and signature in an effective step. A reasonable signcryption scheme can achieve a higher level of security. Inspired by [37], Gagné et al. [38] proposed an ABSC scheme by using a threshold access strategy, in which users must determine their access structure before the system establishment. Mandal et al. presented a new three-factor signcryption-based user access control scheme in [39]. Hu et al. [40] constructed a new secure fuzzy ABSC scheme. This scheme can perform data encryption, digital signature and access control on the patient's medical information in the body area network. Based on the linear secret sharing access structure, Rao and Dutta [41] raised an efficient KP-ABSC scheme with a constant ciphertext length. Liu et al. [42] proposed a CP-ABSC scheme, which can realize safe data sharing in the personal health record system, solve the problem of fine-grained access control, and prove the safety of the scheme. However, Rao [43] pointed out some errors and problems in the scheme [42], which cannot resist selected ciphertext attacks, and cannot satisfy the public verifiability.

B. OUTSOURCING ATTRIBUTE BASED SIGNCRYPTION
The goal of secure outsourcing computing technology is to blind the user's sensitive information by some means, so that the service party can only access the blind information and bear the user's computing overhead when the original data cannot be explored. Although there are many research results on attribute-based cryptosystems, most of the schemes have not yet been put into practice. The reason is that a large number of expensive computing operations in attribute-based cryptosystems are considered to be the biggest obstacle. If the computational overhead can be properly reduced, the practicability of the attribute-based cryptosystem can be greatly improved. Green et al. [44] used outsourcing technology in the decryption process, transferring a large number of bilinear pairing operations to the outsourced computing party for execution. Zhang et al. [45] presented a blockchain-based PDP scheme in cloud computing and an outsourcing computing protocol suitable for fog computing, which can illustrate the application of BCPay. In order to achieve overall security and fair payment for outsourcing services without relying on any third party, scheme [46] introduced the blockchain-based fair payment framework BPay for outsourcing services in cloud computing. Deng et al. [47] introduced a verifiable outsourcing ABSC scheme that enables users to verify the correctness of the generated partial ciphertext. Liu et al. [48] presented a KP-ABSC scheme, which entrusts a trusted server to complete outsourcing and decryption. However, since the user shares the secret key with the server, the server can obtain part of the decrypted ciphertext. A multiauthorized attribute-based signcryption scheme was proposed by [49], which protects users' attribute privacy while outsourcing to the cloud server for partial decryption. However, this scheme still has high computational overhead. The attribute-based signcryption scheme based on the ciphertext strategy can be applied to the EHRs sharing system [50]. A large number of decryption calculations are outsourced to the cloud server, which relieves the users' calculation pressure and has high practicability.

C. APPLICATION of BLOCKCHAIN in EHRs
Blockchain is a decentralized, non-tamperable, and credible distributed ledger that provides a safe, stable, transparent, and auditable way of recording transactions and information interaction. We can solve the problems of access control and data authorization in traditional medical data protection model by using blockchain technology. Ariel Ekblaw et al.
proposed the Medrec prototype [51], which uses Ethereum to record medical data and allows patients to have control over personal medical data. The work records of medical researchers on the public chain will be given back to the corresponding digital currency to encourage medical researchers to continue to use the platform. Wang and Song [52] designed an attribute-based/identity-based combined encryption and signature (C-AB/IB-ES) scheme to ensure the data integrity and immutability of EHRs. However, this scheme incurs a lot of computational overhead for users. On the basis of [52], Yang et al. [53] introduced an attribute-based outsourcing decryption mechanism, which greatly reduces the users' computational overhead. In addition, the use of ABE and ABS improves the computational efficiency of the EHRs system. Scheme [54] combines the ABSC with blockchain technology to realize the secure sharing of cloud data. Compared with the "encryption then signature" adopted by Yang et al. [53], there are higher savings in computing overhead and communication costs. However, the computational cost of data encryption and authentication still needs to be improved.
In this article, we design a blockchain-based verifiable outsourcing attribute signcryption scheme to meet the confidentiality and unforgeability of the EHRs stored in the cloud, and reduce the user's computational overhead for decryption. Moreover, the transaction information stored on the blockchain ensures that the EHRs cannot be tampered with, and the smart contract ensures that the user and the cloud server honestly execute the agreement.

III. PRELIMINARIES
In this section, we review the notations and definitions related to the proposed scheme.

A. BILINEAR MAPS
Define a pair of multiplicative groups (G, G T ) with prime order p, where e : G × G → G T is an effective computable map and g, g 1 are generators of G. For any (g, g 1 ) ∈ G × G, we can get e(g a , g 1 b ) = e(g, g 1 ) ab for a, b ∈ Z p and e(g, g 1 ) = 1 for g, g 1 = 1 [55].

B. COMPLEXITY ASSUMPTION 1) COMPUTATIONAL DIFFIE-HELLMAN ASSUMPTION
Computational Diffie-Hellman (CDH) Assumption means that, given the input (g, g a , g b ) for a, b R ← Z p , and then calculate g ab .
Definition 1 (CDH Assumption): For the adversary A 1 of arbitrary probability polynomial time, the probability of solving the CDH problem is negligible, which is formally expressed as Pr[A(g, g a , [56].

2) THE AUGMENTED MULTI-SEQUENCE OF EXPONE-NTS COMPUTATIONAL DIFFE-HELLMAN PROBLEM
The (l,m,t) augmented multi-sequence of exponents computational Diffe- (X + x i ), and set some values as follows: where k, α, γ , ω are random elements selected from Z p , and g 0 and h 0 are generators of G [57].

IV. THE PROPOSED BVOABSC
The system architecture, the structure of the blockchain and security model are presented in this section.

A. SYSTEM ARCHITECTURE
The system model diagram of our scheme is shown in Fig.1, it contains seven entities, which are Attribute Authorties (AAs), Data Owner (DO), Medical Data Providers (MDP), Medical Data Requester (MDR), Blockchain, Cloud Server(CS) and Auditor.
• AAs. Attribute Authorties (AAs) contain various different organizations, such as hospitals, medical insurance organizations and medical research institutions. Based on the attributes submitted by users, each authority is mainly responsible for distributing corresponding keys for them. AAs are not full trusted by the other entities VOLUME 8, 2020 FIGURE 1. System model.
in our system since they may be corrupted and reveal the secret key information from the users. If no polynomial time adversary can sign or decrypt ciphertexts through mutual cooperation without authorization, collusion attacks between users and cloud servers can be prevented.
• DO. The patient is the owner of the EHRs, which means the source of the EHRs. First, the patient goes to the hospital to register and provides information about his/her symptoms. After receiving the initial diagnosis information from the hospital (including the information of the assigned doctor, diagnosis time and location, etc.), the patient describes the symptoms in detail to the designated doctor, and sends a letter of authorization to entrust the doctor to diagnose and treat at the specified time. Then, the patient formulates an access control strategy, which enables the users whose attributes meet the conditions to access the EHRs. The access control strategy is sent to the doctor, who is authorized to signcrypt and upload the generated EHRs. Finally, the patient creates a smart contract and uploads it to the blockchain.
• MDP. Medical Data Providers (MDP) include hospitals and doctors. After diagnosis and treatment, the doctor signscrypts the generated EHRs according to the access control strategy formulated by the patient, and uploads the ciphertext to the cloud server. After receiving the storage address returned by the cloud server, the doctor sends the address to the patient. At the same time, the doctor creates a transaction, including the storage address of the ciphertext, account information, signature, authorization letter, current time and other information. Finally, the transaction is uploaded to the blockchain by the doctor.
• Blockchain.The type of blockchain is the Ethereum blockchain. It is mainly responsible for collecting transaction information, recording all user access requests and access activities, avoiding outsourced EHRs from being illegally modified and ensuring the security of transactions. In addition, the blockchain stores smart contracts created by the patient, ensuring that EHRs are safely shared among different users. Since the blockchain is public, transaction information and smart contracts can be browsed and accessed by all users.
• CS. Cloud Server(CS) is honest but curious. It is mainly responsible for storing the ciphertext of EHRs uploaded by doctors. The validity of the ciphertext can be verified. If the ciphertext is invalid, CS can refuse to store it. At the same time, CS can verify the identity of the doctor, whether it is authorized by the patient. Moreover, CS can partially decrypt the outsourced EHRs, which reduces the computational burden of the MDR. The correctness of the partially decrypted ciphertext generated by CS can be checked.
• MDR. In order to access the EHRs, the users' decryption attributes should meet the encryption strategy formulated by the patient. First, the MDR browse the address index of EHRs on the smart contract. Then, they request access to the EHRs to the CS by submitting the decryption attribute, the ciphertext address index and the transformed key. If the verification is passed, CS will partially decrypt the corresponding ciphertext of EHRs and send the generated partial ciphertext to the MDR. Finally, the MDR can recover the EHRs by using their private key.
• Auditor. The auditor can ensure the integrity and correctness of the outsourced EHRs by verifying the transaction number, transaction time and transaction information.
The specific operation of our BVOABSC scheme is shown in Fig.1, and described as follows.
1) According to the attributes submitted by users, each authority AA j sends the corresponding key to them. Thus, the patient, MDR and doctors can respectively receive the attribute private key sk O,j , sk V ,j and sk D,j . 2) The patient sends a letter of authorization (W j , W j ) to the doctor, and entrusts the doctor for diagnosis and treatment at a specified time. Then, the patient authorizes the doctor to signscrypt the generated EHRs by formulating the encryption strategy (t, R e,j ) and the signature strategy (t, R s,j ). 3) After diagnosis and treatment, the doctor generates the patient's EHRs. Then, the EHRs are signcrypted according to the access control strategy formulated by the patient. 4) The doctor uploads the ciphertext SCT to CS for storage.
Then CS needs verify the validity of the SCT . If the verification fails, the CS refuses to store SCT ; otherwise, the CS accepts the SCT and sends the storage address of SCT to the doctor. Afterwards, the doctor sends the address to the patient. Finally, the doctor creates a transaction Ts and uploads it to the block. 5) The patient creates a smart contract and uploads it to the blockchain. 6) The MDR access the ciphertext index Inx(SCT ) on the smart contract as required, and then request the CS to access the EHRs by submitting the decryption attributes, Inx(SCT ) and the transformed key tpk. If the verification is passed, the CS partially decrypts the ciphertext and returns the generated partial ciphertext SCT P to the MDR. Finally, MDR decrypt SCT P and recover the EHRs by using the secret key tsk.

B. THE STRUCTURE OF THE BLOCKCHAIN
The blockchain structure of our scheme is composed of the hash value of the block, the hash value of the previous block, the Nonce value, the timestamp and the transaction, as shown in Figure 2. The following specifically introduces the composition of transaction and the design of smart contract.

1) TRANSACTION STRUCTURE
As shown in Fig.2  of creating a new transaction when they generate an EHR for the patient. Storing transactions in the Ethereum ensures that it cannot be tampered with. Of course, doctors need to pay service fees for storing transactions in Ethereum. Therefore, we create an account for each doctor and CS in the system.

2) SMART CONTRACT
The smart contract is the key of the blockchain, and is an event-driven computer program deployed in the blockchain [59]. Our scheme applies it to Ethereum, which promotes the reliable execution of transactions without the involvement of a third party, and ensures that all transactions are traceable and irreversible. In addition, the proposed scheme uses smart contracts to securely share EHRs between patients and MDR. First, the patient formulates a smart contract and sets its execution conditions. Then, the smart contract is encrypted according to the user's key, and the encrypted smart contract is broadcast to the blockchain. When the requester 1 accesses medical-related information, the smart contract will be triggered to execute. The smart contract verifies whether it is a legitimate user based on the attributes of the requester 1. If the verification fails, the access fails. Otherwise, the requester 1 is allowed to decrypt the contract to obtain corresponding information. If the information in the smart contract is correct, the requester 1 uses the key of the requester 2 to encrypt the contract and broadcast it to the blockchain. Similar to the execution process of the requester 1, the requester 2 encrypts the contract with the patient's key and sends it to the patient after verifying the content of the contract. Then, the patient decrypts the contract to check the correctness of the contract, and returns the verification result to the requester 2. Similarly, the process of other requesters such as doctors and medical institutions accessing the contract is consistent with the above description. We can conclude that only users who meet the access conditions can view the contents of the contract. The process of creating a smart contract and reaching a consensus with requesters is clearly shown in Fig.3.

C. SECURITY MODEL
The BVOABSC scheme fulfills the requirements of confidentiality, unforgeability, privacy, non-tamperability and timeliness of the EHRs.

1) CONFIDENTIALITY
If there is no adversary A to win the game with a non-negligible advantage in the polynomial time algorithm (PPT), the BVOABSC scheme is indistinguishable from non-adaptively selected ciphertext attacks. A formal definition is given in the following interactive game between the challenger C and adversary A.
Initialization: The adversary A first selects an encryption strategy (t, R e,j * ), where j ∈ N * , N * is a set of the authorities and (t, R e,j * ) is specified by the authorized institution AA j * . Then, A sends (t, R e,j * ) to C. Setup: The challenger C runs GlobalSetup to generate public parameters GP and sends it to the adversary A.

AuthoritySetup:
The challenger C runs AuthoritySetup and sends the generated public key PK to adversary A.
Query Phase 1: C creates an empty list Tab. A can request the following queries at several times. formed key tk A . Then, C searches for (A A * , sk A , tk A ) in the Tab. If it exists, it will be returned tk A to A, otherwise, the transformation key generated by running TransformationKeyGen and be sent to A.
an encryption strategy (t, R e,j * ) and a signature strategy (t, R s,j * ). C executes the Signcryption algorithm and sends the generated signcryption ciphertext SCT to A.
• Decsigncryption Query O DS . After receiving SCT , threshold value t and the attribute set A A * submitted by A, C executes the Decsigncryption algorithm and sends m to A. Challenge: A chooses two messages of equal length m 0 and m 1 , the encryption strategy (t, R e,j * ) and signature strategy (t, R s,j * ), and then sends them to C. C randomly selects a bit b ∈ {0, 1} * , and returns SCT * to A as the challenge ciphertext by running the Signcryption algorithm.
Query Phase 2: Similar to the Phase 1, except that A cannot ask the ciphertext that has been challenged. The advantage of A in this game is defined as If the probability of any polynomial adversary winning the above game is negligible, then the BVOABSC scheme is indistinguishable under the Chosen Ciphertext Attack (CCA2) and satisfies the characteristics of confidentiality.

2) UNFORGEABILITY
If there is no adversary to win the game with a non-negligible advantage in the polynomial time algorithm (PPT), the BVOABSC scheme is unforgeable under the selective message attack (EUF-CMA). The interactive game between C and A is defined as follows.
The Initialization and setup are consistent with those description in confidentiality.
Query Phase 1: C creates an empty Tab, and A can initiate the following inquiry multiple times.
• Secret Key Query O sk . A queries the signcryption attribute set A A * and threshold value t, which satisfy |A A * ∩ R e,j * | < t and |A A * ∩ R s,j * | < t. Then, C runs SecretGen and sends sk A to A.
• Signcryption Query O SC . A submits a message m, (t, R e,j * ) and (t, R s,j * ). C runs the Signcryption algorithm and returns SCT to A.
• Forgery. A sends SCT * , the encryption policy (t * , R e,j * ) and signature policy (t * , R s,j * ) to C (i.e; (t * , R e,j * ) and s(t * , R s,j * ) have not been asked, and t * < t). C executes the Decsigncryption algorithm to get the message m * . If SCT * is correct and m * has never been asked before, A wins the game. The advantage of A to win the game is Adv Priv If the probability of any adversary winning the above game within the polynomial time algorithm is negligible, the BVOABSC scheme is unforgeable under the selective message attack (EUF-CMA).

3) PRIVACY
The adversary A cannot determine the corresponding signcryptor through the signcryption message, which protects the identity privacy of the signcryptor. We introduce the safe game between A and C as below.
setup: After receiving a set of attributes A A * sent by A, C runs the Setup algorithm. Then, adversary A can receive the generated public parameters GP.
Challenge: A selects the encryption strategy (t, R e,j * ) and the signature strategy (t, R s,j * ) for 1 t |R s,j * | = |R e,j * |, two attribute sets A A,1 * and A A,2 is sent to C. The challenger C selects a random bit b ∈ {0, 1} * and runs the SecretGen to generate sk C . Finally, C runs the Signcryption algorithm to generated SCT b for A.
Guess: A tries to guess which message m b corresponds to the ciphertext SCT * , where b ∈ {0, 1}. Then, A outputs one bit b . If b = b, A wins the game. The advantage of A in the above game is Adv Priv

Definition 3:
If there is no adversary who wins the above safe game with a non-negligible probability within the polynomial time algorithm, the BVOABSC scheme satisfies computational privacy.

4) VERIFIABILITY
The honest MDR can verify the correctness of the partial ciphertext obtained from CS. We have defined the following safe games between A and C.
The adversary A generates an encryption strategy (t, R e,j * ) and a signature strategy (t, R s,j * ) as a challenge access strategy during the initialization and setup phase, and requests the public key, which is similar to the description in confidentiality.
Query Phase 1: C creates an empty Tab and A can request the following queries repeatedly. (A A * , sk A , tk A ). If it exists, C returns tk A to A, otherwise, it runs the TransformationKeyGen and returns the transformation key tk A to A.
• Signcryption Query O SC . A requests the signcryptiom ciphertext of the message m, which is related to the encryption strategy (t, R e,j * ) and the signature strategy (t, R s,j * ). Subsequently, C executes the Signcryption algorithm to get the ciphertext SCT , and forwards it to A.
• Decsigncryption Query O DS . A requests the designcryption of SCT related to the threshold value t and the attribute set A A * . C runs the Decsigncryption algorithm, and sends m to A.
Challenge: A picks a challenge message m * and forwards it to C. Then, C generates a challenge signcryption ciphertext m * by running the Signcryption algorithm and returns it to A.
Query Phase 2: Similar to Phase 1, except that A cannot ask the challenge ciphertext SCT * that has been received.
Forgery: A generates a set of attributes A A * and a random partial ciphertext SCT P * , which is not generated by the PartialDecryption. C executes the TransformationKeyGen to get tk A and then recovers the message m. If m / ∈ {m * , ⊥} and SCT P * are verified to be valid, A wins the game.
Definition 4: If there is no polynomial adversary which can win the above game with a non-negligible probability, then the BVOABSC scheme meets the requirement of verifiability.

D. THE CONSTRUCTION OF BVOABSC 1) SYSTEM INITIALIZATION
In the initialization phase, the system generates public parameters. After the user registers the information in the system, the authority generates the public key and the master private key.
Phase 2: register First, different entities (such as patients, MDP, MDR, and auditor) register information to join the system. At the same time, each doctor creates an account in Ethereum and then publishes it to others. The cloud server also creates an externally owned account in Ethereum and sends it to doctors and auditors.
Phase 3: AuthoritySetup After registration, each authority AA j generates a public key and a master private key by performing the following process, where j ∈ [1, N ] and N is the number of authority. 1) AA j defines a function F :Ũ → (Z /pZ ) * , whereŨ = {a j,1 , · · · , a j,k } is a set of attributes. For each attribute a j,k ∈Ũ , the encoded attribute values F(a j,k ) = x are pairwise different. 2) Randomly choose α j , γ j from Z p * and calculate j = e(g α j , g 1 ) and µ j = g α j γ j . 3) Let the public key PK = { j , {g 1 α j γ j ε } {ε=0,··· ,k} , µ j , F} be in public, and keep the master key MSK = {α j , γ j } secret.

Phase 4: SecretGen
The authority AA j distributes the secret key for the users according to their attributes. The detailed description is as follows.
1) AA j defines A w as the attribute set of an entity, where A w ∈ U , ω represents the entity's type. A O represents the data owner when ω = O and A V means the data requester when ω = V , and if ω = D, A D represents the doctor. 2) Randomly choose r w,j from Z p * , then

2) APPOINTMENT
The following describes the process of interaction between patients, hospitals and doctors.
1) The patient randomly selects ψ j ∈ Z p * to compute P j = g ψ j .
2) After receiving the patient's registration information, the hospital assigns a group of doctors {D l } (l∈I ) , where I is the index of the designated doctors.
3) The patient entrusts D l to generate EHRs by calculating a letter of authorization (W j, , W j, ), such that W j, = tp l ||rea l and W j, = ψ j · H 1 (W j, ), tp l is effective time, and rea l represents medical-related information.

3) THE STORAGE OF EHRs
The generation of EHRs is divided into two situations, one is generated by a doctor, and the other is generated by multiple doctors in turn.

Phase 2:
Verification and storage.
1) The CS verifies the service fee that has been received, checks the validity of tp l and Bhash T |I | , and verifies whether the following two equations hold: F(a j,k ) . If the verification fails, CS refuses to store he signcryption ciphertext SCT 1 ; otherwise, it accepts it and returns the storage address CL 1 of SCT 1 to D 1 . 2) After receiving CL 1 sent by D 1 , the patient calculates H 1 (CL 1 ) and generates Inx(H 1 (CL)). Finally, the patient writes Inx(H 1 (CL)) into the smart contract.

Case 2:
The patient's EHRs are sequentially generated by multiple doctors. Suppose D 1 is the first doctor who generates the EHRs, and D |I | is the last doctor who generates the EHRs.
Phase 1: The generation of the signcryption ciphertext SCT |I | and the transaction Ts D |I | . 1) First, D 1 generates SCT 1 of m 1 and the corresponding transaction (the process is the same as Case 1). Then, from D l−1 , D l verifies its validity through the equation e(W j, −1 , g) = e(H (W j, −1 ), P j ), where l = 2, · · · , |I − 1|. Then, {m 1 , · · · , m l−1 } can be obtained by decrypting SCT l−1 . 3) D 1 generates the current EHR m l , and then signcrypts it through the following process.
F(a j,k ) . 2) If the verification fails, CS refuses to store the SCT |I | ; otherwise, it accepts and returns its storage address CL to D |I | . 3) After receiving CL sent byD |I | , the patient calculates H 1 (CL) and generates H 1 (CL). Finally, the patient will write Inx(H 1 (CL)) into smart contract.
1) MDR pick a random number z ∈ Z p * as a retrieval key tsk = z, and calculate tpk = (sk w1,j +F(a j,k )) } a j,k ∈ AA j ∩ A w , sk w3,j 2) The MDR ask the CS to query the EHRs by sending the decryption attribute, address index and transformed key. 3) If the decryption attributes of the MDR meet the encryption strategy (t, R e,j ) formulated by the patient, the CS can use the transformed key tpk sent by MDR to partially decrypt the ciphertext of the EHRs. The process is as follows.
-For all a j,k ∈ AA j ∩ A V , the CS uses aggregate functions Aggreg to aggregate the user's key . -The CS calculates the partial signcryption ciphertext SCT P = e(SCT 1 , sk V 3,j 1 z ) · e(g, sig 3 1 z ) · e(X 2 , SCT 2 ). 4) The CS sends SCT P to MDR. to verify the correctness of m, which is the correctness of the partial ciphertext generated by CS. 2) If θ = sig 3 , it means that the partial ciphertext SCT P calculated by CS is correct, otherwise, MDR discard it.

5) AUDIT
The auditor verifies the correctness and timeliness of the EHRs through the following steps.
• Extract the transaction from the blockchain and obtain the corresponding account information.
• Verify that the number of created transactions is consistent with the number of EHRs.
• Check the validity of the letter of authorization W j, .
• Verify the timeliness of medical data by checking transaction time.
• Calculate (Bhash T , SCT , W j , W j ), and check whether it matches the transaction information.

E. CORRECTNESS
If the set A V of attributes of the MDR meets the encryption policy (t, R e,j ) and signature policy (t, R s,j ) formulated by the patient, the MDR can use their attributes and the corresponding private key to retrieve EHRs. First, the MDR compute the transformed key tk = (tpk, tsk) and send tpk to the CS. Then CS verifies the correctness of the signature of the doctor who uploads the EHRs, as shown below.
• Decsigncryption Query O DS . A sends a requirement for designcrypting SCT to C. First, C verifies the attribute set A A * submitted by A. If the verification fails, C aborts. Otherwise, C executes SecretGen to generate sk A and runs Designcryption algorithm to obtain the message m. Finally, C sends it to A. Challenge: A submits two messages of equal length m 0 , m 1 and the attribute set A A * to C. Later, C selects a random bit b ∈ {0, 1} * , and signcrypts m b based on the attribute set A A * . Finally, the generated challenge ciphertext SCT * is returned to A.
Query Phase 2: Repeat the Phase 1. Except that the ciphertext SCT * and attribute set A A * have been challenged cannot be asked.
Guess: A outputs a guessed bit b . If b = b, then C answers the aMSE-CDH problem with the solution of the given instance, which means Y = e(g 0 , g 1 ) (κ+H m b )) · f γ j . Otherwise, C answers 0, which means Y is a random element.
Due to the difficulty of the aMSE-CDH problem, it is difficult for A to guess γ and r selected randomly during the key generation phase. Therefore, the adversary A cannot guess the message m correctly. We can get the advantage of C as Adv aMSE−CDH C ≥ Adv A , and the advantage of A can be ignored.
Ultimately, it shows that our BVOABSC scheme is safe based on the aMSE-CDH problem, under the selected ciphertext attack, and satisfies the characteristics of confidentiality.

B. UNFORGEABILITY
Theorem 2: If the aMSE-CDH problem holds, BVOABSC is unforgeable under the selected message attack.
Proof: C exploits the adversary A to solve the aMSE-CDH problem. A tries to calculate a signcryption ciphertext, and C can verify the correctness of it. Our scheme inherits the unforgeability of the scheme proposed in [61], which is described in detail as follows.
The Initialization and Setup phase are consistent with the definition of confidentiality in the security model. A selects a set of signcryption attributes R j * and t * . Then, A requests the secret key by changing the threshold t * , and utilizes different signcryption attribute sets to ask the sign ciphertext of m. A tries to get the secret value by executing Secret Key Query and Signcryption Query multiple times.
• Secret Key Query O sk . A asks C for the signcryption attribute set A A * and t * , where |A A * ∩ R e,j * γ j ) by running the SecretGen algorithm and sends the generated sk A to A.
• Signcryption Query O SC . A submits a message m, (t, R e,j * ) and (t, R s,j * ). C executes SecretGen algorithm to generate sk C . C first calculates Q(γ j )/λ = a∈A A * (γ j + F(a j,k )), and then executes Signcryption algorithm to generate the signcrypyion ciphertext SCT , as follows: Finally, C calculates SCT 1 = g −η 1 ·α j ·γ j , and SCT 3 = e(g, g 1 ) α j ·η 1 e(g, g 1 ) α j ·H (m) · m. Consequently, the signcrypyion ciphertext Forgery. A attempts to generate a valid signcryption ciphertext SCT 1 * , SCT 2 * , SCT 3 * and sig 3 * related to the encryption strategy (t * , R e,j * ) and the signature strategy (t * , R s,j * ). A must calculate sig 1 * and sig 2 * if he/she wants to win the game. Therefore, A must solve the aMSE-CDH problem to prove that the attributes he asks satisfy (t * , R j * ). Similarly, A has to solve the CDH problem to guess the random value in the generated signature.
Therefore, based on the difficulty of the aMSE-CDH problem, our BVOABSC scheme is unforgeable under the selected message attack.

Theorem 3:
The following proof shows that the BVOABSC scheme has computational privacy.
Proof: The security game has been introduced in security model. The adversary A tries to distinguish the correct signatures generated by the two same attributes that have been obtained. That is, an adversary cannot obtain the identity of the corresponding signature entity through the signature message. If the probability of A winning the game is negligible, it indicates that the BVOABSC scheme is computationally private.
After receiving the public key generated by C, A selects the attribute set A A,1 and A A,2 that satisfy the access control policy (t * , R e,j * ) and (t * , R s,j * ), and sends them to C. Then, C generates the private key related to the attribute set A A,1 and A A,2 as follows: Challenge: First, A asks the challenger C to inquire about the signcryption ciphertext of the message m by using sk C,1 or sk C,2 . Then, C selects a random bit b ∈ {0, 1} * , and generates a signcryption ciphertext CT b by executing the Signcryption algorithm. C can obtain a valid signcryption ciphertext about Therefore, as long as the signcryption ciphertexts generated by sk C,1 or sk C,2 are the same, the privacy of our scheme can be proved.
C uses sk C,b to generate signcryption ciphertext as follows: (γ j +F(a j,k )) SCT 3 = e(g, g 1 ) α j ·η 1 e(g, g 1 ) α j ·H (m) · m After receiving SCT b sent by C, the adversary A verifies the validity of the signature by the following formula.
We can prove the generated signatures are the same by using the attribute sets A A,1 and A A, Thus, A does not know which attribute set to use to generate the signature due to the difficulty of the CDH problem.
Therefore, our BVOABSC scheme achieves computational privacy based on the CDH assumption. Proof: The purpose of the adversary A is to forge a partially decrypted ciphertext, which can successfully pass the veryfication of the challenger C.
We define a safe game between A and C. A initiates to a collusion attack of hash function H to C, which purpose is to prove that the advantage of A in winning the game is less than C. The following is a specific description of the game.
A attempts to obtain the private information of the unsigncryption process by separately requesting SecretGen, PartialDecryption and FullDecryption.
Query Phase 1: The challenger C first creates an empty list Tab. The adversary A can initiate Secret Key Query, Transformation Key Query, Signcryption Query and Designcryption Query multiple times, and these queries are consistent with the definition in security model. Query Phase 2: A repeats Phase 1 many times, except that it cannot inquire the decryption of the message m b that has been challenged.
Forgery. A attempts to generate a set of signcryption attributes A A * and a valid partially decrypted ciphertext without performing PartialDecryption algorithm. If A wants to win the game, he/she must break the collusion resistance of H . Due to the collusion-resistant nature of the hash function, A cannot generate H (m part ), so that V = sig 3 can be obtained without knowing m. So if m part = m , then V = sig 3 .
Therefore, based on the collusion resistance of the hash function, the BVOABSC scheme is verifiable against the attacks of CS.

E. IMMUTABILITY
The generation of EHRs in our scheme is divided into two situations, one is a doctor, and the other is multiple doctors. In the case of a doctor, it can prove to be resistant to tampering attacks. On the one hand, the BVOABSC scheme uses a secure delegation mechanism. The authorization letter prepared by the patient is sent to the doctor for diagnosis and treatment. The establishment of the authorization is based on a secure signature algorithm, which satisfies unforgeability. On the other hand, the authorization letter and medical-related information are written into the transaction on the Ethereum by using the immutability of the blockchain. If A wants to successfully tamper the EHRs, the security of the Ethereum blockchain must be break. The situation of multiple doctors is an extension of a single doctor. On the basis of the above description, it is necessary to ensure the chronological order of the EHRs generated by multiple doctors.

F. TIMELINESS
Each EHR generated corresponds to a transaction on the blockchain. The timeliness of an EHR reflects the time of corresponding transactions on the blockchain. Therefore, anyone can extract the time when the EHRs are generated from the transaction in the Ethereum. In addition, the EHRs of each patient are typically generated by multiple doctors. The timeliness of the EHRs can reflect the order in which the EHRs are generated, and the identity of each doctor can be traced back in order. As the medical-related information stored on the blockchain is as difficult to fork, the adversary A cannot destroy the timeliness of the EHRs.

VI. PERFORMANCE EVALUATION
The purpose of this section is to compare the performance of our BVOABSC scheme with the existing relevant ABSC schemes [42], [47], [49], [50], [52], [54]. The complete EHRs owned by a patient are usually generated by multiple doctors, but most EHRs protection schemes only discuss the process of generating the EHR by one doctor. Therefore, our next discussion will only focus on the generation of an EHR, which is generated after a doctor performs diagnosis and treatment. Next, we mainly evaluate the performance from two aspects of communication overhead and computational overhead. The definition of notations are shown in table 1. Table 2 summarizes the security and functional requirements related to signer privacy protection, outsourcing computing, multiple authorities, verifiability, and immutability. The results show that our scheme meets all the above requirements. Scheme [52] does not support the privacy protection of signcryptors, [42], [50], [52], [54] cannot realize the outsourcing operations, and [52], [54] is not verifiable. Only scheme [49] and our scheme have multiple authorities. Scheme [52], [54] and our scheme use blockchain technology to ensure that EHRs cannot be tampered with, which is a feature that other schemes do not have.   In table 3, we compare these schemes in terms of computational overhead, mainly considering the cost of signcryption, user unsigncryption, and CS unsigncryption. For signcryption, our scheme has lower computational overhead than schemes [42], [47], [49], [50], [52], [54], and only needs to perform 6E 1 + 2E T operations. Moreover, the BVOABSC scheme uses attribute-based outsourcing unsigncryption technology to allow CS to undertake greater computational pressure and let users perform only one E T operation to complete decryption. Without this technology, the schemes [42], [50], [52], [54] make users face a huge computational burden. Although the schemes [47], [49] allow CS to perform the partial decryption operation, the calculation cost for users to complete the remaining part of the ciphertext is still higher than our scheme. Table 4 describes the communication cost comparison. Since the CS performs a partial designcryption operation, it needs to generate the overhead of transformed key. Schemes [47], [49] and our scheme use outsourcing computing technology, but our scheme has a lower cost of generating signcryption ciphertext. The size of the ciphertext generated by the BVOABSC scheme is constant and will not change with the growth of the number of attributes. Therefore, our scheme has greater advantages in terms of communication overhead.
For the comparisons of computation effciency, a simulation experiment was implemented, which uses Stanford Pairing-Based Crypto (PBC) library [62] in VC++ 6.0. The computer provides 3GHz Intel Core i5-7400 CPU with 4GB RAM and 64-bit Windows 10 operating system for our implementation. Furthermore, type A bilinear [62] is used in our experiments, and the experimental results are shown in Fig.4. We can know that the time of P, E 1 and E 2 are 11.23ms, 5.62ms and 1.56ms, respectively, which was executed 10 trials.
EHRs usually contain many different types of data, that is, a large number of attributes. This will result in a lot of time on signcryption of these data. In response to this situation, our BVOABSC scheme provides a good solution. The   length of the signcryption ciphertext generated is constant, which has nothing to do with the number of attributes, so the signcryption time in our scheme is constant. In addition, users only need to perform an exponential calculation on G T to obtain EHRs by using outsourcing computation. The BVOABSC scheme and schemes [52], [54] compare the time of signcryption and unsigncryption phase because they all use blockchain technology. It can be found from the Fig.5 that when the number of attributes is 60, our scheme requires 69.24ms and 2.53ms for signcryption and unsigncryption (user side), respectively, which is lower than the time spent on [52] and [54]. Therefore, when the number of attributes is large, our scheme has a considerable time advantage compared with similar schemes.
The Fig.6 shows the time taken to perform the signcryption operation. When the number of attributes is 25, our scheme takes more time than schemes [52] and [54]. Nevertheless, the length of the signcryption ciphertext of [52] and [54] is positively related to the number of attributes. Thus, as the number of attributes increases, they take longer. However, the signcryption time of our scheme remains constant. When the number of attributes is higher than 25, the advantages of our scheme gradually appear.
From the Fig.7, we can clearly see that the time taken for the three schemes to perform designcryption (user side) operations has nothing to do with the attributes, but the time spent advantage of our scheme has always been higher than schemes [52] and [54].

VII. CONCLUSION
We propose an attribute-based verifiable outsourcing signcryption scheme based on blockchain, which realizes the secure storage and sharing of EHRs in the cloud. The proposed scheme has the advantages of attribute-based signcryption, blockchain and cloud storage, which meets the characteristics of fine-grained access control, confidentiality, unforgeability, verifiability, privacy protection and non-tampering. Moreover, our scheme uses outsourcing computing technology to allow most of the calculations to be performed by CS, alleviating the user's computing burden. In addition, our scheme has been proven to be safe in the standard model. Consequently, performance analysis shows that our scheme has high efficiency and can be applied in practice.