A multi-dimension traceable privacy-preserving prevention and control scheme of the COVID-19 epidemic based on blockchain

The outbreak of COVID-19 has brought great pain to people around the world. As an epidemic prevention and control measure, the health QR code (HC) has been designed to trace the confirmed cases and close contacts quickly. Although some existing health code schemes preserve the privacy, but most of them are either unsupported for fine-grained auditability or centralised health code storage. Therefore, we propose a multi-dimension traceable privacy-preserving HC scheme based on blockchain. It prevents health code information being tampered with and supports the traceability of virus transmission chain. We utilise attribute-based encryption to protect residents' privacy information and achieve fine-grained access control. Furthermore, to support the multi-dimension traceability by the epidemic prevention and control departments, the searchable encryption has been introduced. Finally, we give the security analysis and performance evaluation to verify the feasibility and practical significance of our scheme.


Introduction
COVID-19 pandemic broke out globally at the beginning of 2020. The virus has infected more than 510.9 million people until April 2022. 1 The number of new confirmed cases is under control with the implementation of routine disease prevention and control measures, and standardised epidemic prevention has become the main task in some countries. How to identify the health status of a person, improve the tracking ability of close contacts and prevent the recurrence of a large-scale infection are the significant problems at present. In order to prevent the spread of COVID-19, many countries or businesses around the world have adopted mobile technologies to trace close contacts. China, Singapore, Australia 2 and Israel 3 were the first countries to require their citizens to use apps for close contacts traceability. The technologies of close contact tracing attract more attention, and some epidemic prevention and control methods have been proposed, such as health QR code (HC). As a new tool to record the health status, HC records personal and visiting information of residents. However, the health code records basic and health information of residents, which makes personal privacy at risk of exposure. Personal privacy security did not receive due attention in the early days of the health code design. Preserving the private information behind the HC has also become an urgent issue in the adoption of health code.
Currently, the main health code schemes are classified into two categories. The first kind of scheme is based on close contact tracing and the other is based on the centralised health code management. The former includes Google-Apple Exposure Notification (GAEN) (Apple & Google, 2020) and Joseph (Liu et al., 2020) schemes. These schemes record the health code information of someone with whom they have recently contacted. The contact tracing service is achieved by the Bluetooth protocol. The advantage of these schemes is that the close contacts can be traced via a chain or tree searching from the confirmed cases. However, they do not support the searching and tracing based on timestamp and location. What is more, they are not conducive to the regular epidemic audit and control by government departments. The latter includes COVIDSafe (Australian Government, 2020) and HaMagen (Ministry, 2020) schemes. In this type of schemes, the data behind the health code is encrypted and stored centrally. Thus, it is beneficial to audit private information. However, the centralised storage method faces the risk of health code's privacy leakage and the single point of failure. Furthermore, the current schemes cannot support the finegrained audit according to the different types of auditors, such as government agency, doctor, etc.
In order to solve the problems mentioned above, we design a privacy preserving, efficient auditable and traceable health code scheme based on blockchain for epidemic control and prevention. The main contributions include: • We propose a non-contact security audit health code scheme based on blockchain called Auditable and Privacy Preserving Health QR Code (APHC). It supports efficient audit and tracing about the privacy information of the confirmed case and close contacts by health code. It achieves efficient epidemic prevention and control. • In order to preserve the privacy information behind the HC, we put forward an attributebased encryption (ABE) method to protect residents' information, such as ID, name, phone number, location etc., and to achieve fine-grained access control by audit institutions. • For the sake of efficient auditability and traceability, we design a keyword search method to achieve multi-dimensional information query such as ID, location, and timestamp. So, patients and close contacts can be traced effectively. • At last, we implement the prototype of this system and give a performance evaluation to prove the feasibility of this scheme.
The remainder of this paper is organised as follows. Related work will be discussed in Sections 2 and 3, and we will review the techniques used in this paper. In Section 4, the security objectives and threat model of this paper are given. Besides, we describe the model and specific design of this scheme. In Sections 5 and 6, we conduct security and efficiency analysis for the scheme. Finally, the conclusion of this paper will be given.
Compared to our conference version, we have made important enhancements. First, we give a more detailed explanation of the existing schemes, added the comparison between the existing schemes and our scheme, highlighting the advantages of APHC . Second, we redesigned the system scheme, adding searchable encryption (SE) to the scheme, so that keywords can be searched in ciphertext, ensuring that an adversary cannot obtain private information through keywords. Lastly, we have designed three algorithms for SE, decryption and search in the blockchain, in order to support keywords search on the chain.

Related work
Currently, the main methods of preventing and controlling the epidemic are divided into two categories: the first part describes the close contacts tracing schemes especially targeting the COVID-19. The second part describes some personal health record (PHR) security sharing protocols which may be applied in the prevention and control platform for epidemic disease. We also give a comparison of these existing schemes.

Close contacts tracing schemes
The current close contact tracing schemes are mainly based on the Bluetooth protocol or Global Positioning System (GPS). They are mainly deployed by two ways, the one is dominated by the government and the other is promoted by companies.
The South Korean government's scheme requires residents to provide real identity information, and the device's GPS permissions must be turned on to ensure that the government can fully obtain residents' locations at any time. HaMagen proposed by the Israeli Health Department (Ministry, 2020) downloads the infected user's GPS information periodically from the government cloud server to trace the close contacts. The Singapore government proposed the TraceTogether (Government, 2021) scheme. When the residents interact with each other in close proximity, their anonymous IDs generated by the government agency are shared by their smartphones through Bluetooth protocol. The anonymous IDs can be decrypted by the government if necessary. The Australian official applies COVIDsafe (Australian Government, 2020) to help assist health departments understand and contain the spread of COVID-19. It uses Bluetooth technology to help identify the residents who have been in contact with the positive cases. The government can obtain the close contacts' IDs from the confirmed cases' devices and trace them. These schemes are dominated by the government. In other words, they are centralised management method. Therefore, the residents' information may suffer with the data tampering or loss. What is more, some schemes are at the risk of location privacy disclosure.
In addition, some commercial companies have also put forward schemes to trace the contacts. GAEN (Apple & Google, 2020) is applied in Some European and American countries. This scheme uses rolling proximity identifiers that are broadcast through the Bluetooth radios in a user's phone and can be heard by other nearby Bluetooth-enabled phones. A trusted authority (e.g. a public health department) can then reveal which of these encounters involved a confirmed case. However, some researchers found that Google's implementation of GAEN logs crucial pieces of information to the system log, which can be read by hundreds of third-party apps and used for the privacy attacks (Reardon, 2021). In the Covid Watch scheme (Sydney et al., 2020), the close contacts' devices will exchange and record the contact event numbers from each other. If one of the phone owners is diagnosed positive, they are given a permission number by health authorities (HA), and the confirmed case' number will be transmitted to the contacts' phones. However, the Bluetooth protocol is susceptible to man-in-the-middle attacks, which causes the random number information to be destroyed or tampered with. Similarly, WeTrace (De Carli et al., 2020) uses the Bluetooth protocol to transmit public keys. When a resident is confirmed case, his (or her) information will be decrypted and broadcast to all users. The back-end does not store any personal data, however, this system does not require authentication. That is to say, it is extremely vulnerable to DDos attacks. A more secure solution (Liu et al., 2020) is proposed, which supports users to completely hide location information from the government. This scheme effectively avoids the false positive attack of malicious users and achieves the security of personal private information. However, this scheme is not conducive to the government's epidemiological investigation.
Some scholars have proposed the blockchain framework that can be used to build contact tracing schemes, such as COVID-19 blockchain framework (Torky & Hassanien, 2020) and the CovidChain (Choudhury et al., 2020). The health code ciphertexts are stored in blockchain, so that residents' information can be audited by the government or other institutions. The distributed storage scheme can ensure that private information cannot be tampered with. However, HAs can only audit part of the information from the blockchain and cannot search based on key information, such as time, location, etc. Therefore, they are inefficient in epidemic traceability by government department. Zhang et al. (2021) proposed a blockchain-based privacy-preserving framework for online social networks. It utilised the SE and access control that also can be introduced in HC for Covid-19 control and prevention. But this scheme does not take the auditability and traceability into consideration. And Li et al. (2021) proposed a blockchain-based role-based access control (RBAC) model to trace status of products in processes of production, transportation, and sales. However, it does not support the multi-dimension traceability.
We make a full comparison of the existing schemes with our scheme as shown in Table 1.

Secure PHR schemes
The schemes of PHR are similar to health code used for close contract tracing. The PHRs have been defined in 2005. ABE was applied in PHR to achieve flexible access control (Ibraimi, Asim, et al., 2009). Zhang and Liu (2010) proposed a variety of frameworks for the security of PHR and electronic health record. Zhang and Liu (2010) proposed a scheme that introduces a RBAC list in the cloud environment. These schemes gave the idea for PHR without substantive solutions. Xiong et al. (2013) put forward a scheme that combined Ciphertext Policy Attribute-Based Encryption (CP-ABE ) and SE in the cloud environment. Later, a cloud service that adopts the ABE to encrypt medical information was proposed (Xhafa et al., 2015). Sedghi et al. (2009) utilised the efficient symmetric SE in the PHR system and used the keyword search in ciphertext without decryption. Meanwhile, numerous studies have shown that SE is suitable for ciphertext search in the cloud environment (Li et al., 2010;Liang & Susilo, 2015). The data sharing scheme with ABE and SE received attention. However, the centralised cloud environment cannot avoid data tampering or losing. The application of blockchain has provided a new direction for the safety of PHR (Lazarovich, 2015). Next, Xia, Sifah, Smahi, et al. (2017) and Xia, Sifah, Asamoah, et al. (2017) proposed PHR sharing schemes based on blockchain. In these schemes, blockchain is introduced to store data and solve the security problem of sensitive information in cloud storage. These schemes mainly realise the management of access through the authorisation mechanism of blockchain but ignore the illegal access of authorised users of the blockchain. In Note: Y, yes; N, no; W, weak; M, middle; S, strong; -, unknown. a Fine-grained Access Control (AC): the ability of data auditors to access resident data based on their attributes. It is not considered in other existing schemes. b Traceability: the ability to trace infected patients and their close contacts based on the information of health code. c Privacy: the privacy of information can be preserved during the process of sharing and tracing health code information. This indicator is divided into strengths and weaknesses. d Cluster formation: it represents a diffuse search based on a resident's information, rather than a chain query. e Anonymity: in the process of tracing close contacts based on health code, the two interacting parties are not aware of each other's information. f Epidemiological record: it is an indicator that evaluates the content of the health code involved in the scheme, and whether it is complete health code information. g Auditability: the third-party audit institution can audit the health code data.
other words, the security data cannot be guaranteed effectively. Zhang and Lin (2018) proposed a data sharing scheme for privacy preserving in the PHR system using blockchain. Wang and Song (2018) proposed a secure Electronic Medical Record (EMR) system based on ABE and blockchain technology, aiming to achieve confidentiality and integrity of medical data and support fine-grained access control. However, these schemes do not satisfy the need of cipher-text searching. That is to say, the HAs cannot achieve the efficient epidemic audit and close contacts tracing in task of COVID-19 prevention and control. During recent outbreak of COVID-19 pandemic, the necessity of Internet of Medical Things (IoMT) for remote healthcare services has significantly been realised. Ahamad and Pathan (2021) proposed a community cloud framework in an IoMT setting that ensures end-to-end security and circumvents many of the existing negative aspects using the trusted platform module (Ahamad & Pathan, 2021). Xiao et al. (2021) put forward a lightweight authentication scheme for telecare medical information system, while it is not suitable for the large scale of accessing with HC.
After the above analysis, we can find that the existing PHR schemes pay more attention to the sharing of private data but not the traceability and auditability. Thus, the existing PHR schemes are not used to solve the problems in health code privacy-preserving requirement.

Preliminaries
In this section, we will introduce some basic technologies used in our scheme and review the applications of these technologies.

Blockchain
Blockchain is a decentralised distributed storage technology (Nakamoto, 2008). It has a timestamp-based chained data storage structure. It is generally composed of data layer, network layer, consensus layer, contract layer and application layer (Zheng et al., 2017). The data layer describes the data structure of the blockchain that is a structure of "block + chain ". Blocks are generally composed of a block header and a block body (Risius & Spohrer, 2017). All blocks are linked into a chain through the hash function in chronological order. In the network layer, the blockchain nodes communicate with each other by point-to-point protocols, data transmission mechanism and some other network protocols. Consensus layer solves the issue of data consistency. So far, the popular consensus mechanisms include Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT), PoSpace, PoCapacity and so on. In the contract layer, smart contracts (SCs) are some script codes or protocols which do not require third-party trust endorsement. They can execute automatically when the certain condition has been triggered. The top layer is about the concrete application that is a privacy preserving and auditable health code in this paper.
Currently, blockchain is divided into public, consortium and private chain. The public chain is openness without permission. It is difficult to audit and supervise the data on the chain. The private chain is not suitable for multi-participation and dynamically changed membership. The consortium chain is based on a certain access mechanism such as a Public Key Infrastructure (PKI) system. Only authorised nodes can join it. Therefore, we choose the consortium chain to implement our system.

SE
SE (Song et al., 2000) is an effective encryption method. It is divided into two types: symmetric SE (Boneh et al., 2004) and asymmetric SE (Baek et al., 2008;Boneh et al., 2004). The public key searchable encryption with keyword search (PEKS) algorithm can be achieved through the following process: • (pk_peks, sk_peks) ← KeyGen(λ): takes λ as the input parameter, and outputs the searchable and encrypted public key and private key (pk_peks, sk_peks). • C w ← Encrypt(pk_peks, w): input the public key pk_peks and the keyword w, output the ciphertext of the keyword C w . • T w ← Trapdoor(sk_peks, w): input the private key sk_peks and keywords w, output the trapdoor T w .

CP-ABE
In 2007, Sahai and Waters proposed an ABE method (Bethencourt et al., 2007). After that, Goyal et al. (2006) introduced two kinds of ABE schemes, namely encryption based on CP-ABE and encryption based on key policy attributes. The essence of ABE is a method of adding the access structure to the identity-based encryption scheme (Boneh & Franklin, 2003). An access control structure is added to the resident's private key or ciphertext, so that some authorised residents with attributes can satisfy the access control structure. The algorithm of CP-ABE mainly includes the following steps: • (Psk, Msk) ← Setup(k): input the security parameter k, output system public key Psk and master key Msk. • Usk ← KeyGen(Psk, Msk, A): input system public key Psk, master key Msk and the attribute set A of the data owner, output the private key Usk of the data owner. • CT ← Encrypt(Psk, T, A cp ): input the system public key Psk, the plaintext T and the access control structure A cp associated with the access policy, output the ciphertext CT. • T ← Decrypt(Psk, Usk, CT): input the system public key Psk, resident's private key Usk and the ciphertext CT, output the plaintext T.

Bilinear mapping
Assuming e : G × G → G t , G and G t are two cyclic groups of prime order P, and g is the generator of G. If the following three properties are satisfied, e is a bilinear map (Goyal et al., 2006).
• Computability: ∀g, h ∈ G, e(g, h) can be calculated effectively in polynomial time.

System model
In this section, we give the system model of APHC and briefly describe the entities and workflow involved in this model. As shown in Figure 1, this scheme includes four entities and four stages.
• Key distribution centre (KDC). The KDC is a trusted third party. In reality, it can be the related government agency in various regions. It is responsible for the key generation and distribution. • Resident. A resident is the holder of health code. He (or she) registers at the authorised KDC and obtains a public key, which is used to encrypt the personal information in health code, such as ID, phone number or home address. • HAs. HA mainly initiates the auditing and tracing of data. The audit institutions can decrypt, audit and trace the health code private information. • HC recorder. In practice, schools, supermarkets or business districts act as the health code recorders. They record residents' visiting information such as location and timestamp by scanning the health code. This information will be encrypted and uploaded to the blockchain.

Threat model
We designed the threat model as follows. We assume that all parties follow the cryptographic primitives in this scheme. We do not consider network security attacks (DDos attacks, etc.), computer virus attacks and hardware attacks (destroying servers and other smart devices, powering off, etc.). We suppose that the KDC must be a trusted third party.
The key can only be held by each entity and cannot be shared with others. HC recorders may be honest but curious. They honestly pass the ciphertext of the private health code information, but they are also curious about the content of health code ciphertexts and hope to decrypt it.

Design goals
• Privacy preservation. The health code private information should not be leaked or tampered during sharing and storage. Any unauthorised data auditor cannot acquire the private information, including the personal and visiting information of the residents. • Auditability. HA can audit the close contacts. When a confirmed case appears, only those HAs with corresponding authority can decrypt, view and audit the personal and visiting information. • Multi-dimension traceability. HA can upload search keywords (the personal and visiting information of the confirmed case), perform keywords matching and obtain the new traceable keywords (HC residents' spatio-temporal trajectory) in next round. Then, HA can use this trajectory for multi-dimensional matching to achieve breadth and depth contact tracing.

The workflow of APHC
In this section, we will give a description of the health code workflow in the epidemic prevention and control. The main four stages throughout this workflow are described as follows.

Entities registration and key distribution
At the beginning of this system, all the entities should register with the KDC to request key pairs for health code information encryption. The KDC takes charge of generating two types of key pairs: attribute-based public and private key pairs and SE public and private key pairs. Besides, it needs to complete the key distribution for the authenticated residents and HAs. The process of secure key distribution is not considered in this paper.
(a) Resident's ABE keys request. A resident u i initiates a registration request Req = {pID, Status H } to KDC for the ABE key. KDC calls the ABE.KeyGen algorithm (described in 4.5.1) to generate the key (Pk u i , Sk u i ). Then, the KDC will record the Resident's anonymous-ID pID and the key pairs and respond with the Pk u i to u i . Pk u i is used to encrypt a resident's personal information including ID, phone number, home address and so on. ABE encryption ensures the confidentiality of residents' personal information when they scan the HC for a HC's entrance permission.
(b) HC recorders' SE keys request. Before recording the residents' visiting information, a HC recorder requests for SE key from KDC. Then, KDC will call the PEKS.KeyGen algorithm (described in 4.5.2) to generate a SE key pair (pk_peks, sk_peks) and respond with pk_peks to the request. HC recorder encrypts the residents' visiting information and their encrypted personal information, which will be recorded into blockchain.
(c) HA's auditable and traceable key request. When a confirmed case appears, HA can audit the epidemic according to the location and timestamp. It also can trace a confirmed case's visited location and then zone the high-risk area. The personal and visiting information are encrypted by two types of algorithms for different requirements. So, a HA needs to request the sk_peks from KDC to get the visiting information. Some HA with the particular attribution can request sk u i from KDC to obtain residents' personal information.

HC record and upload
When a resident visited any HC recorder (such as a supermarket, a commercial district or a school), he (she) must scan the HC code to submit his (her) personal information. And then, the HC recorder will collect this visitor's anonymous ID and visiting information, and then upload it to the fabric network.
In detail, the resident executes ABE.Encrypt to encrypt his (her) own personal information locally and upload ABE−Ciphertext to the HC recorder through HC scanning. This process is shown in phase 1 of Figure 2. Then, HC recorder calls PEKS.Encrypt algorithm with the input of encrypted personal information and visiting information as shown in phase 2 of Figure 2. Note that the location and timestamp should be uploaded as keywords then an index table I will be generated. Finally, HC recorder executes PEKS.Upload algorithm to upload the double encrypted result SE−ABE−ciphertext to the blockchain through SC.

Epidemic audit
The government, hospital, healthcare commission and some organisations serve as the HA who audit the status of epidemic prevention and control. With different attributes, HAs can audit the state of epidemic according to location, timestamp and so on.
In detail, HA can call the PEKS.Trapdoor and PEKS.Retrieve functions for keywords (such as location and scan time) to search for the SE−ABE−ciphertext on the blockchain. After obtaining the matching cipher-text, HA can use PEKS.Decrypt function to decrypt the cipher-text and obtain ABE−Ciphertext. HAs with different permissions can apply to KDC for different ABE decryption keys based on their audit attributes. Therefore, HAs can obtain the health code plain-text and perform epidemic audits on health code plain-text.
HAs have different access rights to obtain the ABE decryption keys. We assume three different roles of auditors, such as commercial security inspector, doctors and government audit agencies. • Security inspector can only obtain residents' health code status. If the red status appears, they can request the corresponding keys from KDC to access the personal information of the resident with red status. • Doctors can not only obtain the health code status but also get the residents' temperature, symptoms and so on. Therefore, doctors can obtain the decryption authority direct at those residents with red status or yellow status but with abnormal temperature. • Government audit agency can investigate whether residents have accessed high-risk areas or not. The personal information of these residents who have visited a high-risk area should be traced by an audit institution regardless of their health code status.

Close contacts tracing
When a HA discovers an infected patient, it needs to trace close contacts based on the information of this confirmed case. First of all, the HA calls PEKS.Decrypt and ABE.Decrypt to obtain the patient's personal information, previous visited location and timestamp. And this information is regarded as keywords for breadth search, so the close contact tracing can be realised.
Second, when HA needs to trace close contacts, it needs to apply to KDC for an audit and trace key, and uses the previous address as the keywords. Then, HA calls the PEKS.Trapdoor to generate the keyword Trapdoor and calls the PEKS.Retrieve through the SC to implement keyword search on the blockchain. Therefore, HA will obtain the health code information of the matched close contacts.
Finally, HA will initiate a close contact's key request to KDC based on the anonymous-ID, and then HA can call the ABE.Encrypt to decrypt the close contact's health code ciphertext, so as to obtain a wider range of close contact information and achieve diffusion of close contact tracing.

Algorithms
In order to achieve the "one-to-many" relationship between a HA and residents, this scheme uses the access control tree policy to perform ABE to achieve the security of health code information. For the purpose of efficient keywords search and the security of the diffusion search, we introduce the SE to protect the security of information and keywords. This section will construct a specific SE scheme with fine-grained access control. The variables that will be used in the specific scheme are explained in Table 2. We define the user's attribute set ϕ = {ϕ 1 , ϕ 2 , . . . , ϕ 3 } and a hash function {0, 1} * → G.
Initialisation algorithm Setup(k): The initialisation algorithm takes security parameter k as input and selects a group G with prime number p as the order, where the generator is g, and a series of random numbers are set α, t 1 , t 2 , . . . , t n ∈ {Z * p }, so that we can calculate y = e(g, g) α and T i = g t i . Then we can get the global security parameters GP = (g, y, T i ) and Master key Msk = (α, t i ).
The functional algorithms are classified into two types: ABE-based HC privacy-preserving algorithms and PEKS-based close contact auditing and tracing algorithms. Next, the detail design of these algorithms is given as follows.

ABE-based HC privacy-preserving algorithms
There are three main algorithms described as follows: ABE.Encrypt(M, Pk u i , A cp ): executed by a resident with the input of public key Pk u i , the plaintext M (HC personal data) and access control policy A cp , output the CT(ABE−ciphertext). The algorithm process is as follows: • Choose a random number s ∈ Z * p , and compute C 0 = g s , C 1 = M · y s . • The access control tree T corresponding to the access control policy A cp is shown in Figures 3 and 4. We set the root node value of T to be s, and the logical parent and child nodes relationship is set as "AND" or "OR": "OR" relationship: the value assigned to the child node is also s. "AND" relationship: for each child node except the last one, assign a random value s i , the last child node is s t , s t = s − t−1 i=1 s i . • The access control tree leaf values are used to generate ciphertext elements. For each attribute ϕ i,j ∈A cp , C j,i = T s i j (i represents the index of the attribute in access control tree, Tem anomaly is 1, Sym C−19 is 2). Therefore, the ciphertext CT = {T, C 0 , C 1 , C j,i } of the plaintext M can be obtained.
ABE.Decrypt(CT, Sk u i , ϕ i ): after obtaining the ciphertext set CT, HA can decrypt the CT by the private key Sk u i . If A u i = {ϕ 1 , ϕ 2 , . . . , ϕ i } satisfies the access control policy A cp , as shown in Equations (1) and (2), the plaintext M can be obtained.

PEKS-based close contact auditing and tracing algorithms
Blockchain-based SE scheme is mainly composed of six main polynomial time algorithms: PEKS.KeyGen (1 λ → (Msk, (pk_peks, sk_peks))). With global security parameters λ as input, PEKS.KeyGen returns a master key Msk, an asymmetric SE key pair (pk_peks, sk_peks), (Msk, (pk_peks, sk_peks) PEKS.Encrypt (M ct , pk_peks, w) → (I, CT ). Taking M ct (the HC data ABE−ciphertext), keywords w (anonymous-ID, location, scan-time, etc.) and public key pk_peks as input, this algorithm outputs the ciphertext (SE−ABE−ciphertext) CT and keywords index table I. Note that I is generated by the HC recorder according to the algorithm proposed in Tahir et al. (2017). This algorithm is also based on the property of modular inverse, which helps to map probability trapdoors. The above encryption algorithm is represented in Algorithm 1.
PEKS.Upload ((CT , I), T w ) → Append. Given the SE−ABE−ciphertext and index table (CT , I) or trapdoor T w , the algorithm appends the content to ledger. At first, HC recorder and HA require identity verification. Then, the consensus function will be triggered. After the transaction is verified by the verification peer, it will be added to the ledger. This process is shown in Algorithm 2.
PEKS.Trapdoor(sk_peks, w) → T w . This is a probability algorithm run by HA. It uses private key sk_peks and keyword w as input and outputs trapdoor T w . In order to search for keywords on encrypted ciphertexts stored on the blockchain, HA generates a probability trapdoor. The trapdoor T w will be transmitted to the SC for keywords search. This process is shown in Algorithm 3.
PEKS.Retrieve(sk_peks, I, T w ) → CT . This is a deterministic algorithm run by HA with the help of SC. This algorithm triggers the search algorithm in SC, which takes index The latest transaction is appended to the blockchain network.
Upload: 2: --The HC recorder and HA aew authenticated by the MSP through CA using Sig.
--The HC recorder or HA propose a transaction((CT ,I) or T w ).

4:
--The endorsing peers validate and endorse the transaction.
--The ordering peers order the transaction into blocks. 6: --The transaction is broadcast to the peers.

Algorithm 3 PEKS.Trapdoor
Require: secret key sk_peks, keyword w Ensure: Transmit T w , append to SC. Trapdoor: table I and trapdoor T w as input and returns a set of SE−ABE−ciphertext CT . This is shown in Algorithm 4.
Retrieve: 4: for 1 ≤ l ≤ I do --if (d == H sk_peks (c * a −1 mod P)); The calling sequence of the above algorithms is shown in Figure 5.

Security analysis
In this section, we will analyze the security of our COVID-19 prevention and control scheme from the following aspects.

Algorithms security analysis
We discuss the security properties of the two main algorithms.
The most concerned property of CP-ABE scheme is anti-collusion attack. In the health code application, the collusion is that different HAs with non-overlapping attributes may combine their keys and then decrypt residents' private information. In order to prevent this attack, different random value r is chosen for each resident, when the KDC calls ABE.KeyGen algorithm to generate residents' key pairs. If the adversary wants to decrypt the extra information, it must recover y s = e(g, g) αs . For this purpose, it should have the secret key blinded with the same random value. Thus, the keys from different HA cannot be combined to get the extra information. The full proof of this algorithm was given in Ibraimi, Asim, et al. (2009).
The correctness and soundness properties of the SE scheme are analyzed. As mentioned in Tahir et al. (2017), for the security parameter λ, the master key Msk generated by PEKS.KeyGen, with input of index table I, the search process always returns the correct set of encrypted massage. With input of the trapdoor T w , the search always returns the sound results, which contains no false positives. Thus, this PEKS scheme is correct and sound.

Application security analysis
We discuss the application security of this scheme and prove that it can achieve the prospective security goals.

HC information privacy protection
The security storage of health code data is an important feature in this scheme. It can be ensured that the health code information is secure during the process of encryption, storage and auditing. Before uploading the health code privacy data to the blockchain for storage, the encryption has been performed locally by residents and HC recorders. Any operation on the blockchain will be recorded, so only authorised HAs can obtain the health code ciphertext, and the HA with the corresponding attribute set can decrypt it. The ABE algorithm used in this scheme is proved to be secure in Ibraimi, Tang, et al. (2009), so the ciphertext of the HC information is privacy-protected.

HC information tamper-proof
In this scheme, the health code information is stored in the blockchain. It is well known that any data are written on this distributed ledger through a consensus protocol among the multiple nodes. This data structure and consensus mechanism make the data stored in the blockchain not be tampered with or destroyed. Besides, the data are stored on this ledger in the form of ciphertext. Even if an adversary can access the data in the blockchain, it cannot obtain any effective private information.

HC information auditability and traceability
In order to achieve a search through the keywords like anonymity-ID, location and time, we integrate the keywords search into blockchain. In our scheme, the HC recorders collect the ABE−ciphertext of residents' personal information in the way of scanning the health code. They can combine this information with visiting information, such as timestamp, location and so on, and then send this data on the peer nodes. The health code, anonymity-ID, location and time information will be extracted as keywords for multi-dimension epidemic auditability and traceability. The PEKS algorithm used in this scheme has been proven to be secure in Tahir et al. (2017). Therefore, the ciphertext search method proposed in this paper is security.
Without the corresponding keys, the malicious adversary cannot obtain any plaintext information through keywords, ensuring that the HC information cannot be leaked during the trace process.

Performance evaluation
We implement the prototype of our scheme on the HyperLedger Fabric (HLF) blockchain platform. And then, the execution time and capacity cost of the scheme are analyzed.

Deployment and implementation
In order to verify the design in this scheme, we test the practical performance of our proposed HC scheme through experimental evaluation on a real blockchain platform. HLF is suitable for complex information queries and sharing transactions in the health code scheme. In the fabric network, participants (peers) in a channel jointly maintain a ledger, and peers of this channel can only access the ledger. SCs (called chaincode in HLF) are programmes installed by peers, and peers control access to the general ledger through chaincode. As shown in Figure 6, a consortium blockchain network based on the HLF platform is designed to audit and trace the health code information. This blockchain network includes information sharing organisations, HC recorders, and HAs.
We deploy this scheme on the Ubuntu system, using docker as the chaincode management environment. HLF v1.4 is chosen to develop the blockchain system. Besides, we use the Hyperledger explorer to visualise the transaction process.

Setup
At first, the members need to be initialised. In this scheme, Membership Service Provider (MSP) will assign a unique certificate to each HC recorder and HA that joins this network. When any commercial organisation/hospital, etc. applies to join in the network, MSP will assign a certificate and verify whether the client is part of this channel. If the signature is valid, the output is "accept ", the peer is authorised to join the network, otherwise it will be rejected.
Next, we define the main chaincode in APHC that is installed into peers and are initialised. Its pseudocode is exhibited in appendix. The chaincode consists of key SCs PutHC(), QueryHC(). In this chaincode, we call some Application Programming Interfaces (APIs) in Fabric to achieve the function of upload and query. shim.ChaincodeStub provides the API of operating the state of ledger data, including the query of the state data and transaction processing. In our scheme, the HC information can be proposed as a transaction by the API PutState(key string, value []byte) error, and the pair of keys and values are added to the write set, waiting for further validation by the Committer before it is actually written to the ledger. The API GetState(key string) ([]byte, error) can be called to queries the ledger and returns the value of the specified key.
After the initialisation is complete, different peers will use chaincode to complete logical operations. HC recorder calls the function PutHC() to upload HC information, and the HAs call the function QueryHC() to search the close contact and then download encrypted HC information. Figure 7 shows the ciphertext search operation in HLF. In this blockchain network, HC information is converted into transaction submissions. These transaction proposals require a consensus agreement generated by endorsing peers before being added to the ledger.
When the HC recorder completes health code data and keywords encryption, it needs to call the PutHC() function in the chaincode to upload the ciphertext and the index table I of keywords. When the HA performs a ciphertext search, it needs to call the QueryHC() function in the chaincode for keyword search. If the keyword matches an element in the index table I, the searchable ciphertext will be downloaded and decrypted for the further tracing.

Performance analysis
In this application, the network communication performance depends on the real network environment. The CP-ABE and PEKS protocols may cause some interactions between the resident's device and peer node. However, because the distributed system will balance the network loads, the real-time requirement of the health code information uploading is not strict. Therefore, the network performance can satisfy the practical requirement. Next, we will give a performance analysis on computation and storage.

Computation cost measurement
This paper uses pairing-based cryptography (Lynn, 2010) to generate the keys and the HLF blockchain platform to test the scheme, and uses the discrete logarithmic difficulty equivalent to 1024 bit for the test.
Assume that a KDC contains 1,000,000 HC residents, 500 HC recorders and 50 HAs. There are three keywords for each HC resident, each HA with eight attributes and the access control tree with eight leaf nodes. Each HC resident and HC recorder hold a pair of attributebased keys. The keys are updated every day, and 50,000,000 key pairs will be generated. The performance of main algorithms is displayed in Table 3. At the KDC, the time of each pair executing ABE.Setup + ABE.KeyGen is about 0.01 s. Each HC resident spends about 0.082 s in executing health code encryption ABE.Encrypt. The HC recorder spends about 0.069 s in executing SE PEKS.Encrypt. The HA needs about 0.037 s to construct trapdoor PEKS.Trapdoor for the keyword to be searched. The PEKS.Retrieve execution time of the retrieval and verification algorithm in SC is at most 0.074 s. After the verification, the HA spends 0.062 s in executing the searchable decryption algorithm PEKS.Decrypt. Finally, it will take the HA about 0.065 s to conduct attribute-based decryption ABE.Decrypt on the ciphertext of the health code private information.
According to the above simulation data, for a HC resident uploading the health code private information, the entire process takes about 0.4 s, leaving out the network communication process. In order to obtain the location in a diffusion way, only relevant operations of SE need to be executed, so the time required is about 0.11 s. Moreover, in this system, only the ABE encryption algorithm and PEKS encryption processes have strict requirements on the time, others processes are not. Hence, this scheme is feasible in time complexity.

Capacity cost analysis
The size of each block head defaults to 80 bytes. For the health code data blockchain, each transaction mainly contains attribute-based encrypted ciphertext, encryption time and location. It is assumed that the space occupied by one storage is 1 kb, and a block contains 2000 transactions, then the memory space occupied by a block is about 2 MB. When recording by 1,000,000 people every day, and calculating by 10 HC recorders everyone enters every day, then the space occupied by the health code privacy data generated every day is about 10 GB. Thus, during three periods (the latency period of COVID-19 is 14 days; Government, 2021), 420 GB of health code privacy data will be generated. This means that blockchain storage can satisfy the capacity demand. Therefore, this scheme is feasible in space complexity.

Conclusion
In this paper, we propose a new health code privacy preserving and auditable scheme. Through the analysis of the existing close contacts tracing scheme and information sharing scheme, we have identified critical challenges in the current health code privacy-preserving and auditable scheme. In this design, we focus on designing a secure and efficient health code information auditable scheme that can achieve fine-grained access control. We integrate ABE, SE and blockchain into this scheme to achieve our design goals. Finally, we establish a prototype system by the HLF blockchain platform and verified the feasibility of this scheme through performance comparison analysis. In this paper, the efficiency, availability and security of these cryptography algorithms can be improved in the future work. For instance, an ABE scheme based on SM9-IBE was proposed to preserve users' privacy and achieve access control with fine grain (Ji et al., 2021). It has been proven to be of great security in the selective Chosen-Plaintext Attack (CPA) model under Decisional Bilinear Diffie-Hellman (DBDH) assumption. And a method of multi-keyword ranked search based on mapping set matching (Xiao et al., 2020) may be introduced into this scheme to improve the retrieval efficiency. Notes 1. https://coronavirus.jhu.edu/map.html 2. https://www.health.gov.au/resources/apps-and-tools/covidsafe-app, 2020. 3. https://govextra.gov.il/ministry-of-health/hamagen-app/download-en/, 2020.

Disclosure statement
No potential conflict of interest was reported by the author(s). i f e r r != n i l { fmt . P r i n t f ( ' ' E r r o r c r e a t i n g new APHC Chaincode : %s " , e r r ) } }