Privacy-preserving contact tracing in 5G-integrated and blockchain-based medical applications

Abstract

The current pandemic situation due to COVID-19 is seriously affecting our daily work and life. To block the propagation of infectious diseases, an effective contact tracing mechanism needs to be implemented. Unfortunately, existing schemes have severe privacy issues that jeopardize the identity-privacy and location-privacy for both users and patients. Although some privacy-preserving systems have been proposed, there remain several issues caused by centralization. To mitigate this issues, we propose a Privacy-preserving contact Tracing scheme in 5G-integrated and Blockchain-based Medical applications, named PTBM. In PTBM, the 5G-integrated network is leveraged as the underlying infrastructure where everyone can perform location checking with his mobile phones or even wearable devices connected to 5G network to find whether they have been in possible contact with a diagnosed patient without violating their privacy. A trusted medical center can effectively trace the patients and their corresponding close contacts. Thorough security and performance analysis show that the proposed PTBM scheme achieves privacy protection, traceability, reliability, and authentication, with high computation & communication efficiency and low latency.

1. Introduction

We are currently in a critical period of fighting the corona virus (COVID-19) epidemic, where everyone hopes that the whole society will restore to the original order as soon as possible. To achieve this, both commercial healthcare/pharmaceutical organizations and academic researchers in related fields are actively contributing. Until now, hundreds of COVID-19-related papers have been published that have enabled researchers and the general public to know more about overcoming the spread of disease. For example, researchers in [21] used natural language processing techniques to find the propagation characteristics of situation information related to COVID-19 in social media such as Sina Weibo1 .

Besides, more novel technicians have been used to help people fight for this aggressive epidemic. The 5G technology has been considered as one of the promising technicians during the COVID-19 pandemic, which enables higher communication resources with low latency. A report of the World Economic Forum (WEF) [14] shows that COVID-19 rises 5G to the 2nd rank of most discussed tech topics (before COVID-19 is 7th rank). Another report [13] figures that COVID-19 is accelerating 5G demand in some industries such as healthcare. Under this circumstance, more research papers related to 5G and healthcare [1], [9], [23], [31], [42] have been published, which indicates that it is valuable to research 5G-based medical applications especially COVID-19-related applications.

During those medical applications, contact tracing can be considered as an important step in the prevention and control of infectious diseases such as COVID-19. In a typical contact tracing scenario, the close contacts of a patient will be traced and advised to seek proactive treatment from medical organizations as they have a higher probability to be infected compared to non-contacts. A recent study published in Lancet [5] shows that aggressive close contact tracking and isolation is the key measure to Shenzhen city’s control of COVID-19 transmission. Hence, it will be helpful to stop the infectious virus from spreading further, if an effective solution of contact tracing is established.

In the current pandemic situation, the privacy of information has become an extremely sensitive issue, as, on one hand, immediate information sharing related to contacts is necessary, while on the flip side medical records (and identity) have to be kept confidential. Because users’ medical data seems to be more sensitive, medical-related privacy issues appear to be more serious and will cause greater losses compared with privacy issues in scenarios like IoT [35], [38], vehicular network [40], smart grid [36], and cloud computing [33], [34], [37], [39]. A report of IBM in 2019 [18] shows that the average cost of data loss per leakage has risen to $3.92 million, where healthcare suffers from the highest loss of $6.45 million per security breach. To mitigate these severe issues caused by privacy leakage, research in both academic and industrial areas has tried to propose new medical applications with the privacy-preserving properties. For example, MIT [27] uses Bluetooth signals from smartphones to perform automated contact tracing privately. Besides, Apple and Google jointly announced a contact tracing system that also makes use of Bluetooth-based proximity-detection technology to find close contacts without compromising location privacy [3].

Unfortunately, there are still some issues with existing contact tracing solutions that need to be solved. More specifically:

• • Centralized Architecture: All the existing schemes are based on a centralized architecture. In that case, the system may suffer from single-point failure (data breach) that will affect the availability of the whole system.
• • Unreliable Data Storage: Data stored on a centralized server can be easily deleted or tampered with, by malicious system administrators. Besides, malicious users may upload fake information to the system to evade supervision.
• • Limited Privacy Protection: Privacy protection cannot be fully guaranteed. Existing privacy-preserving solutions can prevent privacy from violating by external adversaries. However, different companies, entities, and agencies who possess the user’s private data have unlimited access privileges to them, which may also lead to privacy abuse.

In light of these issues that limit the practical use of existing contact tracing systems, we propose a novel privacy-preserving contact tracing scheme in blockchain-based medical applications, named PTBM. More specifically, the 5G-integrated network architecture is leveraged to achieve high communication bandwidth with low propagation & response latency. Blockchain is used to achieve reliable data storage & verification, and secure cryptographic primitives are also leveraged to protect identity privacy and location privacy for both users and patients. To the best of our knowledge, this is the first privacy-preserving contact tracing scheme with a decentralized architecture that achieves reliability in large scale emergency systems.

Following are the major contributions of this work.

• •We design a novel decentralized architecture of contact tracing applications, where the 5G-integrated blockchain network is leveraged as underlying infrastructures. Both permissionless and permissioned blockchains are used to achieve public location checking and supervised data storage & tracing, respectively.
• •We propose PTBM, a decentralized contact tracing scheme based on the hierarchy of blockchain and secure cryptographic primitives to protect the identity privacy and location privacy for both public users and patients without losing the tracing ability of trusted medical center.
• •We make thorough security analysis and performance evaluation to prove that the proposed PTBM scheme achieves privacy protection, reliability, authentication, and traceability with high computation & communication efficiency and low latency.

The rest of the paper is organized into seven sections. Section 2 gives the background and motivation of the scheme including the related works. Section 3 introduces the fundamentals of blockchain, PCSD cryptosystem, and the bloom filter. Section 4 presents the formalized system model, security model, and design goals of PTBM. In Section 5, we elaborate on the complete working of the proposed scheme, followed by the security analysis and performance evaluation in sections 6 and 7, respectively. Finally, Section 8 concludes the paper.

2. Related works and motivations

In this section, some related works about blockchain with 5G, existing contact tracing mechanism and blockchain-based medical applications are introduced, which prove the novelty of the proposed scheme because to the best of our knowledge, none of the existing schemes supports reliable and privacy-preserving contact tracing with low latency.

2.1. Blockchain with 5G technology

Both the blockchain and 5G can be considered as the next-generations technology, hence their integration also attracts the attention of researchers, which covers a variety of scenarios including Internet-of-Things (IoT) [4], [17], [41], and edge computing [15], [19], [28].

In the IoT scenario, Zhang et al. [41] proposed an edge intelligence and blockchain empowered IIoT framework under the 5G environment. The proposed scheme includes a cross-domain resource scheduling mechanism and a credit-differentiated edge transaction approval mechanism. It also achieves secure service management and low latency with the help of blockchain and 5G. Hewa et al. [17] presented an automatic certificate revocation scheme, where Elliptic Curve Qu Vanstone (ECQV) certificates are used to achieve lightweight authentication for the resource-restricted IoT devices, and smart contracts are used to achieve reliable and automatic certificate revocation. The proposed scheme realizes a lightweight certificate store, update, and revocation, hence it is suitable for the 5G-based wireless network that interconnects millions of IoT devices. Bera et al. [4] introduced the issues and challenges of applying blockchain in the 5G-based IoT environment. They also presented a secure framework for blockchain-based data management that can resist several potential attacks and achieve reliability. Detailed analysis shows that the proposed scheme provides less communication and computation overheads as compared to other relevant works.

In the edge computing scenario, Nkenyereye et al. [28] adopted a 5G cellular architecture of Emergency Driven Message (EDM) Protocol which provides higher scalability with lower latency. They also constructed a blockchain-based system where each node is seen as an edge node to reliably store EDM records of which the privacy is protected by a lightweight signcryption scheme. Jangirala et al. [19] designed a lightweight RFID-based authentication protocol for supply chains, named LBRAPS. Their proposed LBRAPS protocol uses several lightweight cryptographic primitives such as bitwise XOR and one-way hash functions, hence it is suitable for the 5G mobile edge computing environment. Gao et al. [15] incorporated another novel technique, software-defined networks (SDNs) to ensure effective management for blockchain-enabled fog computing in 5G networks. The article also shows that the combination of blockchain and the SDN relieves the pressure of the centralized controller.

Besides, some privacy-preserving schemes that try to leverage 5G technology in blockchain-oriented solutions have been presented [7], [10], [11], [16], [22], [26]. We can conclude that more and more researchers are paying attention to solve the privacy issues in 5G-integrated blockchain networks.

2.2. Contact tracing

The current outbreak of coronavirus in the world has attracted extensive attention from both academic institutions and researchers in various fields. The work in [30] analyzed the advantages and shortcomings of several existing privacy-aware contact tracing solutions. It concludes from observations in existing solutions that: 1) the importance of location information is usually ignored, 2) the privacy concerns and trust relationship are generally missing, 3) the reliability cannot be guaranteed because large companies or malicious users can manipulate the uploaded data, and 4) deployment of the systems in the real-world scenario is not specified.

In the contact tracing scenario, Ahmed et al. [2] summarizes existing mobile contact tracing APPs which can be divided into three architectures: centralizing, decentralizing, and hybrid. It also concludes that security and privacy issues are one of the most concerns that these APPs are still facing. Fitzsimons et al. [12] designed a privacy-preserving contact tracing mechanism by introducing secure two-party computation (2PC). More specifically, 2PC is used to securely calculate the distance between the location trajectory for a patient and a user. If the calculated distance is below the given threshold, the user will be considered as a close contact of the patient. However, the computation and communication costs of verification are relatively high because the 2PC protocol should be followed for each user who wants to perform the contact tracing operation.

Xu et al. presented BeepTrace [32], a blockchain-based privacy-preserving contact tracing scheme where pseudonyms are used to achieve the unlinkability between the on-chain data and the real-world identity, and the uploaded on-chain data are also encrypted by the corresponding user. Compared with other existing technicians, BeepTrace achieves privacy protection with a decentralized architecture. Unfortunately, the user uses Geo public key to encrypt the location information, and the location privacy cannot be well guaranteed if the Geo Solver who holds the decryption private key is malicious. Besides, it cannot actively trace the contact of a given patient.

2.3. Blockchain-based medical applications

Because of the decentralization and immutability of the blockchain, several works have introduced blockchain in medical applications to achieve reliable medical data storage, analysis, and sharing. Biswas et al. [6] present a comprehensive analysis of challenges and solutions for using blockchain effectively in e-healthcare systems. Liu at al[24]. proposed a blockchain-based data sharing scheme to address the privacy issue of Electronic Medical Record (EMR) sharing. The proposed scheme also used CP-ABE-based access control and the content extraction signature scheme. Li et al. [20] proposed a blockchain-based medical data preservation system to realize privacy-preserving and verifiable medical data storage. Shen et al. [29] presented a privacy-preserving image retrieval mechanism for medical IoT systems that used customized blockchain transaction structures to store the feature vector for each image. Smart contracts are also used to execute privacy-preserving image retrieval based on the feature vectors. Chang et al. [8] discussed how blockchain can help people in the fight against COVID-19. From their perspective, blockchain will be widely used in future medical applications.

2.4. Motivations

Based on the above analysis, we make three conclusions that form the major motivation of this work:

• 1.The integration of blockchain achieves reliable data storage and program execution in a decentralized manner, which also mitigates the computation & computation loads and the probability of single-point failure of centralized servers. Unfortunately, the communication delay of blockchain is relatively high because of the decentralization property.
• 2.The incorporation of the 5G network brings out more powerful communication ability with higher bandwidth and lower latency compared with the existing 4G-based wireless networks. However, most of the 5G devices are small IoT or fog devices such as communication base station, smartphone, or even wearable devices, has relative low computation ability and storage capacity, which results in unreliable data storage and transmission.
• 3.The techniques of contact tracing are just in their infancy, which means more effective mechanisms and solutions need to be developed. Besides, the decentralization property of blockchain can be widely used in medical applications to solve the issues caused by centralized architecture.

In PTBM, we use the blockchain-based 5G network and lightweight cryptographic primitives as the underlying infrastructure and higher construction respectively to achieve reliable and privacy-preserving contact tracing with high efficiency and low latency. More specifically, the reliability of blockchain and enhanced communication bandwidth with low latency of 5G network will be utilized, whereas the deficiencies bring from using either of them alone will be eliminated. The privacy of the user’s identity and the patient route can be well protected, whereas the traceability can be also guaranteed.

3. Preliminaries

In this section, some basic primitives used in the proposed scheme are introduced. These include the blockchain system, public-key cryptosystem with strong key decryption (PCSD), and the bloom filter (BF).

3.1. Blockchain

The concept of blockchain originates from the Bitcoin cryptocurrency that achieves reliable transactions under decentralized and trust-less circumstances. Blockchain can be seen as a distributed and append-only ledger with immutability, hence the data stored on the blockchain cannot be deleted or tampered with.

Blockchain can be primarily categorized into two types: permissioned and permissionless blockchain. Before participating in the permissioned blockchain, all users must register with the Trusted Authority (TA), hence only the authorized (registered) users can get access to the data block stored on the ledger. The permissionless blockchain does not need access control, and anyone can participate in and query the data stored on the blockchain, however, this leads to scalability and public accountability as well as some privacy issues. For example, external attackers can perform inference attacks that use statistical analysis to shrink the data privacy and identity privacy of the blockchain users with the help of background knowledge.

For the purpose of mitigating these privacy issues, we use the hierarchical architecture of blockchain with secure cryptographic primitives to achieve privacy protection without losing the decentralization & accountability properties.

3.2. Public-key cryptosystem with strong private key decryption

The concept of PCSD derives from the Public-Key Cryptosystem with Distributed Decryption (PCDD) presented in [25]. PCSD consists of the following algorithms:

• • $(msk,(p{k}_1,s{k}_1),\cdots ,(p{k}_n,s{k}_n))\leftarrow \mathsf{KeyGen}(\lambda ,n)$ is a probabilistic algorithm that receives a security parameter $\lambda$ and a number of key-pairs $n$ as input, and outputs a strong private key $msk$ and $n$ key-pairs $(p{k}_1,s{k}_1),$ $\cdots ,$ $(p{k}_n,s{k}_n)$. Let $p,q$ be two large prime numbers that satisfy $\left|p\right|=\left|q\right|=\lambda$. Set $N=pq$ and $\alpha =lcm(p-1,q-1)/2$. Choose $g\in {\mathbb{Z}}_{N^2}^{*}$ with order $(p-1)(q-1)/2,$ and define a function $L\left(x\right)=(x-1)/N$. For each $i\in {\mathbb{Z}}_n,$ compute $h_i=g^{{\beta }_i}\text{mod}{N}^2$ where ${\beta }_i\in [1,N/4]$ is randomly selected. The public key and private key for $i$ is $p{k}_i=(N,g,h_i)$ and $s{k}_i={\beta }_i,$ respectively. The strong private key is $msk=\alpha$.
• • $c_i\leftarrow \mathsf{Enc}(p{k}_i,m_i)$ is a probabilistic algorithm that receives $i$’s public key $p{k}_i$ and a message $m_i,$ and outputs a ciphertext $c_i$ associated with $m$. Given $i$’s public key $p{k}_i$ and a message $m_i\in {\mathbb{Z}}_N,$ choose $r_i\in [1,N/4]$ randomly and compute the ciphertext $c_i=\{T_{i1},T_{i2}\},$ where $T_{i1}=h_i^{r_i}(1+mN)\text{mod}{N}^2,$ and $T_{i2}=g^r\text{mod}{N}^2$.
• • $m_i\leftarrow \mathsf{Dec}(s{k}_i,c_i)$ is a deterministic algorithm that receives $i$’s private key $s{k}_i$ and a ciphertext $c_i,$ and outputs the message $m_i$. With $i$’s private key $s{k}_i,$ the message $m_i$ can be recovered by computing $m_i=L\left((T_{i1}·{\left(T_{i2}^{{\beta }_i}\right)}^{-1})\text{mod}{N}^2\right)\text{mod}N$.
• • $m\leftarrow \mathsf{SDec}(msk,c)$ is a deterministic algorithm that receives a strong private key $msk$ and a ciphertext $c$ as input, and outputs the message $m$. For any ciphertext $c,$ the corresponding message $m$ can be recovered by computing $m=L\left(T_1^{\alpha }\text{mod}{N}^2\right)·{\alpha }^{-1}\text{mod}N$.

Assume $c_i$ is encrypted by $i$’s public key $p{k}_i,$ note that for all $1\le i\le n,$ the corresponding message $m_i$ can be recovered by using $msk$. Hence we call $msk$ a strong private key. Entities (other users and attackers) that do not know $msk$ or $s{k}_i,$ the cyphertext $c_i$ cannot be decrypted. We leverage this property of PCSD to achieve privacy-preserving tracing in the proposed PTBM scheme.

3.3. Bloom filter

The BF can be considered as an indexed structure used for membership queries. The idea of BF is to choose $o$ independent secure hash functions $H_1,\cdots ,H_o$ with the same domain $D=\{a_1,\cdots ,a_n\}$ and range $R={\mathbb{Z}}_m$. The BF consists of three algorithms described as follows:

• • Init: Choose an $m$-bit vector $\mathcal{B}$ that will be used to store the membership information. All the bits in $\mathcal{B}$ are set to 0.
• • Insert: All the members in $D$ will be inserted into the vector $\mathcal{B}$. More specifically, to insert a membership $a_i,$ $o$ hashed values ${\bigcup }_{k=1}^o{H}_k\left(a_i\right)$ will be computed, and each $H_k\left(a_i\right)$ position of $\mathcal{B}$ will be set to 1.
• • Query: To query whether $a\in D,$ $o$ hashed values ${\bigcup }_{k=1}^o{H}_k\left(a\right)$ will be computed. If there exists an $H_k\left(a\right)$ such that the corresponding position of $\mathcal{B}$ is 0, it means $a\notin D,$ otherwise $a\in D$.

Note that $\mathcal{B}$ can also be implemented using a hash table. The Insert algorithm inserts all the entries indexed by $H_1\left(a_i\right),\cdots ,H_o\left(a_i\right)$ with value 1 (i.e., for each $H_k\left(a_i\right),$ $\mathcal{B}\left[H_k\left(a_i\right)\right]=1$). In the Query algorithm if there exists an $H_k\left(a\right)$ such that $\mathcal{B}\left[H_k\left(a\right)\right]=\perp ,$ it means $a\notin D$. In the proposed scheme, we use this implementation to store the location state information to protect the user’s location privacy as well as realizing efficient location checking operations.

4. Problem formalization

In this section, we formalize the system model, threat model, and design goals of the proposed PTBM scheme.

4.1. System model

The system consists of five entities: Medical Center (MC), Fog Nodes, Users, Medical Organization (MO), and Blockchain systems, as shown in Fig. 1 .

Fig. 1.

System model.

4.1.1. Medical center

The MC can be considered as a trusted authority controlled by the government. It performs the registration operation to generate & distribute the system parameter and key-pairs for each user, MO, and fog node. MC will stay offline after registration unless it needs to trace the patient information or MO’s misbehavior. In that case, it will trace the data stored on the permissioned blockchain. Hence, the introduction of MC cannot violate the decentralization property of the blockchain. Furthermore, this allows that any MC (public or private sector entity) can be easily made part of the existing healthcare infrastructure.

4.1.2. Fog nodes

The fog nodes are deployed beside the checkpoints that are also controlled by the government. These checkpoints are specially set up to check body temperature and/or other parameters for public health monitoring. Because we utilize the 5G-integrated network as the underlying infrastructure, which means all the fog nodes are connected by 5G wireless network via 5G base station. Besides, then can also connect other 5G terminals such as the user’s mobile phone or other 5G-supported wireless devices. It uploads the user’s encrypted location checking information and periodically uploads its current state to the permissioned blockchain.

4.1.3. Users

When a user wants to cross a checkpoint, they will use their mobile phone to upload their identity and location information encrypted by their respective public key via 5G wireless channel. Besides, they can execute location checking on the permissionless blockchain to check whether their historical route includes dangerous areas where infected patients have been found.

4.1.4. Medical organizations

The MOs can be seen as primary healthcare institutions (e.g., community clinics) that treat infectious patients. MO will maintain several nodes in both permissioned and permissionless blockchain for patient route query and location publication respectively. The patients’ activity areas will be published to the permissionless blockchain so that every user can check whether they have been to these areas. If they have, then they can go to a nearby MO for examination and treatment in time.

4.1.5. Blockchain

In our proposed system, there exist two kinds of blockchain: permissionless and permissioned blockchain. Everyone can get access to the data stored on the permissionless blockchain, whereas, only the MC, MO, and Fog Nodes have the read & write permissions for the permissioned blockchain. The hierarchical architecture of blockchain enables enhanced security guarantees and advanced privacy protection for both users and patients. Note that all the blockchain nodes can be also connected via 5G wireless networks which enable higher communication channel capacity with lower latency.

4.2. Threat model

In our threat model, we assume that MC cannot be compromised, and the data stored in MC cannot be leaked. Moreover, MC distributes the system parameter and key-pairs via secure channels.

Both the fog nodes and MOs are honest-but-curious, which means that they exactly perform the presented algorithms and protocols, however, they try to infer both users’ and patients’ private information from the data stored on the blockchain. Note that the collusion between fog nodes and MOs is not allowed because fog nodes are controlled by the government as mentioned earlier.

Most of the users are honest, however, there exist several malicious users that try to impersonate other legitimate users to upload fake information to evade supervision.

4.3. Design goals

Here we introduce the design goals of PTBM. Note that in Section 6, we prove that PTBM realizes all of these design goals.

Privacy Protection: The proposed scheme should protect every user/patient’s identity privacy and route location privacy simultaneously. More specifically, both honest-but-curious MO and external adversaries cannot infer the real-world identity or recover the exact route of both users and patients.

Reliability & Authentication: The data uploaded by both users and MOs cannot be modified by both external or internal adversaries, and all the users, fog nodes, MOs, and MC can obtain the correct query/tracing result. Besides, an effective authentication mechanism should be introduced to avoid impersonation attacks by malicious users.

Traceability: Given a designated patient, his route should be traced, and all the users that might have been in close contact with the patient should also be traced. Note that this tracing operation should only be executed by MC. Besides, MC can also trace the misbehavior of MO.

Efficiency: Due to the limited computation and storage capacity of the devices in the 5G-integrated network, the computation complexity should be as low as possible, especially for users and fog nodes that make use of mobile and IoT devices, respectively. Besides, the communication costs should also below to save the channel resource and bring out low latency.

5. The proposed PTBM scheme

In this section, a detailed description of the proposed PTBM scheme is given. The notations used in this work are illustrated in Table 1 .

Table 1.

List of notations.

Notation	Description
$\lambda$	Security parameter
$m$	The number of users
$n$	The number of fog nodes
$ui{d}_i,ni{d}_j$	The pseudonym of user $i$ and fog node $j$
$(up{k}_i,us{k}_i)$	Signature key-pair for user $i$
$(np{k}_j,ns{k}_j)$	Encryption key-pair for fog node $j$
$K,msk$	Secret key and strong private key for MC
$F$	A secure pseudo-random function.
$H,H_1,\cdots ,H_o$	$o+1$ secure hash functions

5.1. Registration

In this process, MC first generates a secret key $K\leftarrow {\{0,1\}}^{\lambda }$ held by MC itself, and the strong private key & signature key-pair $(msk,{\bigcup }_{j=1}^n(np{k}_j,ns{k}_j))\leftarrow \mathsf{PCSD}.\mathsf{KeyGen}(\lambda ,n),$ where the key-pairs will be distributed to the corresponding fog nodes.

Besides, MC randomly chooses a secure digital signature scheme DS that consists of three algorithms: KeyGen (key generation), Sig (signature), and Ver (verification). Then it chooses a secure random function $F:{\{0,1\}}^{\lambda }\times {\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$ and $o+1$ secure hash functions $H,H_1,\cdots ,H_o:{\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$. These functions can be seen as system parameters that will be sent to all the users and fog nodes.

For each user $i$ associated with the real identity $u_i,$ MC generates $i$’s pseudonym $ui{d}_i=F(K,u_i)$ and signature key-pair $(up{k}_i,us{k}_i)\leftarrow \mathsf{DS}.\mathsf{KeyGen}\left(\lambda \right)$. Then it sends $(ui{d}_i,up{k}_i,us{k}_i)$ to user $i$ through secure channels, and publishes $(ui{d}_i,up{k}_i)$ to the permissioned blockchain. Besides, it will initialize a list $L\left[ui{d}_i\right]$ on permissioned blockchain for each user $i$ that will be used to store the encrypted route information.

For each fog node $j$ associated with the real identity $n_j,$ MC also generates the pseudonym $ni{d}_j=F(K,n_j)$. Then is sends $(ni{d}_j,np{k}_j,ns{k}_j)$ to fog node $j$ through secure channels. Besides, it will initialize a dictionary $S$ on the permissioned blockchain that will be used to store the encrypted state information. Note that each $nid$ is associated with a geographic location about the checkpoint, of which the correspondence is held by MC secretly.

For each MO $M,$ it needs the real identity $mi{d}_M$ and the public key $p{k}_M$ for registration. MC will generate the corresponding blockchain address $add{r}_M$ used on both permissioned and permissionless blockchain to invoke smart contracts of Route Query and Location Publishing, respectively. Finally, MC publishes $(mi{d}_M,add{r}_M)$ to the permissioned blockchain.

5.2. Information uploading

When a user $i$ wants to cross a checkpoint associated with fog node $j,$ it first sends a request ${\mathcal{R}}_i=(ui{d}_i,t_i,{\sigma }_i)$ to $j,$ where $t_i$ is the current timestamp and ${\sigma }_i=\mathsf{DS}.\mathsf{Sig}(us{k}_i,H(ui{d}_i\parallel t_i))$ is the signature generated by $i$’s private key.

After receiving ${\mathcal{R}}_i,$ $j$ first check whether the timestamp $t_i$ is obsolete. If the difference between current time $t$ and $t_i$ exceeds the threshold $t_{\theta },$ ${\mathcal{R}}_i$ will be rejected. If the time checking is successful, it queries $i$’s public key $up{k}_i$ by searching the permissioned blockchain with the index $ui{d}_i,$ and verifies the signature ${\sigma }_i$ by executing $\mathsf{DS}.\mathsf{Ver}(up{k}_i,{\sigma }_i,H(ui{d}_i\parallel t_i))$. If the verification returns true, it inserts ${\bigcup }_{k=1}^o{H}_k\left(ui{d}_i\right)$ to the bloom filter ${\mathcal{B}}_{s_j},$ where $s_j\leftarrow {\{0,1\}}^{\lambda }$ is a random string that represents $j$’s current state. If the verification returns false, ${\mathcal{R}}_i$ will also be rejected. Finally, $j$ adds $(s_j,t_j)$ to $L\left[uid\right]$ stored on the permissioned blockchain where $t_j$ represents the current timestamp.

Note that $s_j$ is periodically updated, and $j$ will upload the current state information $(E_j,U_{s_j},{\mathcal{B}}_{s_j})$ to $S\left[s_j\right]$ stored on the permissioned blockchain before the update operation, where $E_j=\mathsf{PCSD}.\mathsf{Enc}(np{k}_j,ni{d}_j)$ is the encrypted pseudonym of $j,$ and $U_{s_j}$ represents the users that passed-by in this time period. For each $u_i^{\prime }\in U_{s_j},$ $u_i^{\prime }=\mathsf{PCSD}.\mathsf{Enc}(np{k}_j,ui{d}_i)$.

5.3. Route query

When a medical organization MO receives a patient $p,$ it uses the address $add{r}_M$ to execute route query contract of the corresponding $ui{d}_p$ given by $p$ with the preset start timestamp $t_s$. More specifically, MO queries the permissioned blockchain and obtains $p$’s recent route $L_p\subseteq L\left[ui{d}_p\right]$ where each $(s,t)\in L_p$ satisfies $t\ge t_s$. Note that elements in $L\left[ui{d}_p\right]$ are arranged in chronological order, hence the elements in $L_p$ also follow a chronological order.

5.4. Location publication

During the route tracing operation, MO obtains $p$’s recent route $L_p,$ then it uses the address $add{r}_M$ to perform location publication contract. More specifically, for each $(s,t)\in L_p,$ MO obtains $S\left[s\right]=(E_s,U_s,{\mathcal{B}}_s)$ from the permissioned blockchain. The encrypted pseudonym $E_s$ and user’s information $U_s$ are used for MC’s tracing, and the corresponding bloom filter ${\mathcal{B}}_s$ will be published as the activity area information to the permissionless blockchain.

In our scenario, all the patients are seen as infectious disease patients, hence their recent activity areas should be published under the premise of protecting their privacy. In that case, everyone can check whether their historical route includes these dangerous areas. If so, they can go to the medical organizations nearby for further examination.

5.5. Location checking

Each user $i$ can use his mobile phones or other 5G-support devices to check the location information $\mathcal{B}$ published on the permissionless blockchain to check whether they have been to these dangerous areas. More specifically, $i$ computes ${\bigcup }_{k=1}^o{H}_k\left(ui{d}_i\right)$ and finds whether all the $k$ hashed values appear in the bloom filter $\mathcal{B}$. If so, it means $i$ should go to the MO nearby for further examination because the published area includes the patient’s recent activity area.

Note that $\mathcal{B}$ is based on the time state which means $i$ and the patient are in the same location at the same time period if all the ${\bigcup }_{k=1}^o{H}_k\left(ui{d}_i\right)$ are in $\mathcal{B}$. It is obvious to conclude that the user $i$ was in close contact with the patient with a high probability. Therefore, $i$ should go to an MO nearby to determine whether they are infected or not.

5.6. Tracing

Note that not all patients are active in executing the location checking operation. In that case, the MC can trace the users who might have been in close contact with the patient $p$ and inform them to get a thorough examination. More specifically, like Route Query and Location Publication, the MC finds $L_p\subseteq L\left[ui{d}_p\right]$ and $S\left[s\right]=(E_s,U_s,{\mathcal{B}}_s)$ for each $(s,t)\in L_p$. Then for each $u^{\prime }\in U_s,$ it recovers the user’s pseudonym $uid$ by executing $\mathsf{PCSD}.\mathsf{SDec}(msk,u^{\prime })$. Because in the registration operation, each user uses their real identity to register, MC can contact them easily.

Besides, for an MO $M,$ it uses its address $add{r}_M$ to invoke the contract of route query and location publication, and all the operations will be recorded to the immutable blockchain. During the Registration process, $M$ uses the real-world identity $mi{d}_M$ to register from MC and obtains $add{r}_M$. Hence, each address $addr$ is associated with the corresponding MO’s real-world identity, which means that the misbehavior of MO (e.g., publishing fake location information, abusing the route query operation) can be traced by MC.

6. Theoretical analysis

To show that the proposed PTBM scheme achieves the aforementioned design goals of privacy protection, reliability, authentication, and traceability, here we present a thorough analysis.

6.1. Privacy protection

In the proposed scheme, both the privacy of patients and other users should be protected, which includes identity privacy and route privacy.

6.1.1. Identity privacy

In PTBM, each user will be assigned a pseudonym generated by MC by computing $ui{d}_i=F(K,u_i)$. If the pseudo-random function $F$ is secure, the user $i$’s pseudonym $ui{d}_i$ and the corresponding real-world identity $u_i$ is unlinkable without knowing the secret key $K$ held by MC.

The patient $p$ can be considered as a special kind of user. During the Route Query process, their pseudonym $ui{d}_p$ will be used. As mentioned above, the proposed PTBM scheme achieves unlinkability between $u_p$ and $ui{d}_p$. Hence, only the query requester MO knows the real identity of $p,$ which is inevitable because the MO is responsible for $p$’s examination and treatment.

For external adversaries, the inference attack cannot be performed because they can only access the permissionless blockchain that only stores the published location information.

Therefore, both honest-and-curious MO and external adversaries cannot infer the real-world identity of both patients and other users, which means the proposed PTBM scheme achieves identity privacy protection.

6.1.2. Route privacy

In the permissioned blockchain, given a pseudonym $ui{d}_i,$ the encrypted route information $L_i=L\left[ui{d}_i\right]$ can be obtained, where $(s,t)\in L_i$ reflects the user $i$’s location at time $t$. For each state $s,$ the state dictionary $S$ stores the tuple $S\left[s\right]=(E_s,U_s,{\mathcal{B}}_s)$. Assuming $s$ represents one of the fog node $j$’s states, only the corresponding private key $s{k}_j$ and MC’s strong private key $msk$ can recover the encrypted result. Note that $E_s$ and $U_s$ is encrypted by $p{k}_j$. The bloom filter ${\mathcal{B}}_s$ only stores an obfuscated location information which consists of several hashed values of users’ pseudonym. If all the hash function $H_1,\cdots ,H_o$ are secure, then all the pre-hash value (i.e., the user’s pseudonym) cannot be recovered. In summary, for each state $s,$ $S\left[s\right]$ cannot leak the location information for any user.

In the permissionless blockchain, only the bloom filter $\mathcal{B}$ associated with a patient $p$’s activity area is published. As mentioned above, external adversaries cannot find which user has been to this area associated with $\mathcal{B}$.

Therefore, both honest-and-curious MO and external adversaries cannot recover the exact route of any user $i,$ which means the proposed PTBM scheme achieves location privacy protection.

6.2. Reliability & authentication

Due to the reliability of blockchain which has been well established in the literature, all the data stored on the permissionless and permissioned blockchain cannot be modified or deleted. Hence, the correctness of query/tracing results on the blockchain can also be guaranteed.

In PTBM, each user is assigned a key-pair for generating digital signatures. For a malicious user, it cannot impersonate another legitimated user to upload the information without knowing the private key. Besides, we use timestamp $t_i$ to resist replay attacks, which means the malicious users cannot use the obsolete request of others. Therefore, PTBM achieves effective user authentication.

6.3. Traceability

As mentioned above, MC can perform route tracing operations of a given pseudonym $ui{d}_p$ of a patient $p,$ or tracing of all the users that might have been in close contact with $p$. Besides, all misbehaviors can be traced by MC with the help of access mechanisms in the permissioned blockchain and registration rules in PTBM scheme. In that case, MC can punish the misbehaving MOs by both economical and administrative mechanisms to regulate their behavior.

7. Performance evaluation

In this section, we evaluate both computation & communication complexity based on a blockchain platform to prove that the proposed PTBM scheme has high computation efficiency with low communication costs.

7.1. Experimental setup

We have implemented the proposed PTBM scheme in the Go language, which includes the implementation of PCSD scheme based on [25]. The security parameter $\lambda =256,$ and the number of shared keys in the bloom filter is set to $o=5$. All the pseudo-random functions and hash functions are instantiated by HMAC-256 and SHA256, respectively. All programs are compiled in Go 1.14 x64 environment.

We choose the Hyperledger Fabric2 as the underlying blockchain platform. Hyperledger Fabric provides permissioned management with flexible programmability & efficiency. Fabric is suitable for our scenario where both permissioned & permissionless blockchains are required, and its high transaction throughput as compared with Bitcoin and Ethereum makes it a practical real-world solution.

We deploy four peer nodes of Fabric as the test blockchain network, where each node is running on a virtualized server on an Intel i7-9700K CPU and 8GB RAM with a 64-bit Ubuntu 16.04 operating system. The client-side programs (by users, fog nodes, and MOs) are executed on a tablet with Intel i5-7300U CPU and 4GB RAM with a 64-bit Windows 10 operating system.

7.2. Computational costs

To evaluate the computational performance of PTBM, we set the number of users $m$ ranging from 1000 to 10,000 with increments of 1000, the number of fog nodes $n=100,$ the number of patients $m/1000,$ and the number of users that perform location checking operation to $m*20\%$. We randomly generate the route of each user, and the patients are also uniformly & randomly selected. All the evaluations are executed 5 times, and we calculate the average execution time for each process to remove relative errors. The results are shown in Fig. 2 .

Fig. 2.

Experimental evaluation of computational costs.

7.2.1. Registration

During the Registration process, each user $i$ is assigned as a pseudonym $ui{d}_i$ and a signature key-pair $(up{k}_i,us{k}_i),$ each fog node $j$ is assigned as a pseudonym $ni{d}_j$ and an encryption/decryption key-pair $(np{k}_j,ns{k}_j)$. Assume $\tau \left(o\right)$ represents the average execution time of operation $o,$ the average execution time of Registration is $m·\tau \left(\mathsf{DS}.\mathsf{KeyGen}\right)+n·\tau \left(\mathsf{PCSD}.\mathsf{KeyGen}\right)+(m+n)·\tau \left(F\right),$ where $m$ and $n$ represents the number of user and fog node, respectively. Therefore, the corresponding computation complexity is $O(m+n)$ for MC.

Because the number of fog nodes is relatively fixed, we mainly evaluate the time cost by different numbers of users. It can be seen in Fig. 2a, as the number of users increases, the time cost also increases. Note that even if the number of users raises to 10000, it only takes about 1 min for registration. Besides, the registration operation only performs once, and in the real world situation, it will be done immediately when a new user joins.

7.2.2. Information uploading

During the Information Uploading process, the user $i$ generates a request ${\mathcal{R}}_i$ which includes $i^{\prime }s$ pseudonym $ui{d}_i,$ a timestamp $t_i,$ and a signature ${\sigma }_i$. Hence for user, it takes $\tau \left(\mathsf{DS}.\mathsf{Sig}\right)$ to generate ${\mathcal{R}}_i$ in the Information Uploading process, and the corresponding time complexity is $O\left(1\right)$. Note that we omit the calculation of negligible time consuming such as generating hash value.

For each ${\mathcal{R}}_i,$ the fog node $j$ checks the timestamp and verifies the signature. If the checking & verification are successful, $i$’s state will be updated with the current state $s_j$ of $j$ via Update operation of smart contract. Periodically, the state information will be uploaded to the permissioned blockchain which includes several encrypted user’s pseudonym passed by $j$ in this period of time, and $j$’s encrypted pseudonym. Assume the number of users pass by is $m_j,$ the time cost in the Information Uploading process for a fog node is $m_j·\tau \left(\mathsf{DS}.\mathsf{Sig}\right)+(m_j+1)·\tau \left(\mathsf{PCSD}.\mathsf{Enc}\right)+(m_j+1)·\tau \left(\mathsf{Update}\right),$ and the corresponding time complexity is $O\left(m_j\right)$. However, in the real-world scenario, a fog node can handle the users’ request in parallel, which means the time complexity can be decreased to $O\left(1\right)$.

As is illustrated in Fig. 2(b), the execution time is not related to the number of users pass by. We also notice that the execution time slightly increases with the number of users increases. That is because a larger number of users bring out a larger size of state information for node $j$ that will be uploaded to the permissioned blockchain, which results in higher communication delay.

7.2.3. Route query & location publication

During the Route Query process, the MO queries the patient $p$’s route $L\left[ui{d}_p\right]$ with the help of $ui{d}_p,$ which only needs one Query operation of smart contract. Hence, the time cost of Route Query for MO is $\tau \left(\mathsf{Query}\right)$ with the corresponding time complexity $O\left(1\right)$.

During the Location Publication process, the MO queries the permissioned blockchain to obtain $p$’s recent activity areas, and uploads the associated bloom filter to the permissionless blockchain. Assume the number of $p$’s recent activity area is $n_p,$ the time cost of Location Publication process for MO is $\tau \left(\mathsf{Query}\right)+\tau \left(\mathsf{Update}\right),$ the corresponding time complexity is $O\left(1\right)$.

As can be seen in Fig. 2(c), the execution time is not related to the number of users, and it only takes about 40ms to perform the complete route query & location publication process.

7.2.4. Location checking

During the Location Checking process, each user $i$ will check the location information published by MO previously. Assume that only one bloom filter $\mathcal{B}$ is published, and in that case, $i$ only executes the Query algorithm once, which is negligible. Hence, the time cost of Location Checking process for user is $\tau \left(\mathbf{Query}\right),$ the corresponding time complexity is also $O\left(1\right)$.

As is illustrated in Fig. 2(d), although the number of users increases from 1000 to 10000, the execution time looks almost the same, which proves that the proposed PTBM scheme achieves $O\left(1\right)$ complexity during this process.

7.2.5. Patient tracing

During the Patient Tracing process, the MC obtains the state information related to $p$’s recent activity as what the MO does in the Location Publication process. Hence, the time cost of Patient Tracing for MC is $\tau \left(\mathsf{Query}\right)$ with the corresponding time complexity $O\left(1\right)$.

As is seen in Fig. 2(e), the execution time is irrelevant to the number of users and ranges from 35ms to 45ms, which is efficient.

7.2.6. Contact tracing

During the Contact tracing process, MC recovers each contact’s pseudonym by executing PCDD.SDec operations for each state $s$ obtained by Patient Tracing process. Hence, it takes $m_j·n_p·\tau \left(\mathsf{PCSD}.\mathsf{SDec}\right)$ to recover all the pseudonym for all states, and the corresponding time complexity is $O(m_j·n_p)$.

As is seen in Fig. 2(f), the execution time is irregular, that is because, in our experimental setting, each user’s route is randomly generated which results in random $m_j$ and $n_p$.

7.3. Communication costs

The communication behavior mainly happens during the Information Uploading, Location Query, Location Publication and Location Checking process. For users, it is obvious that the communication complexity of Information Uploading and Location Checking processes are both $O\left(1\right)$ because he only sends one request and performs one query operation, respectively. For fog node, the communication complexity is $O\left(m_j\right)$ because $m_j$ encrypted pseudonyms will be uploaded to the permissioned blockchain. For MO, it takes $O\left(n_p\right)$ communication complexity for both Location Query and Location Publication processes because the information of $m_j$ states will be obtained by querying the permissioned blockchain and uploading on the permissionless blockchain, respectively.

We evaluate the communication cost for users, fog nodes, and MOs in our experiment, as shown in Table 2 , where we set the number of users $m=1000$. It can be observed that the communication costs for users, fog nodes, and MOs are all less than 10KB, which is quite efficient. Therefore, PTBM achieves high communication efficiency and can well save the bandwidth usage and reduce the delay of the 5G-integrated infrastructure.

Table 2.

Communication costs.

Operation	User	Fog Node	MO
Information Uploading	$<$1KB	8.74KB	-
Route Query	-	-	$<$1KB
Location Publication	-	-	5.61KB
Location Ckecking	5.24KB	-	-

7.4. Summary

Table 3 shows both the time and communication complexity of the proposed PTBM. Through the experimental evaluation, it is observed that the execution time of the most aforementioned processes (except the Registration process that is executed only once) is not related to the number of users. More specifically, it only takes less than 40ms for each of the given operations to complete. Hence, PTBM can operate with high computation efficiency, which means that the fog nodes can handle a large number of user requests. For users and MOs, they can efficiently check the published location and query the location of a given patient, respectively. Besides, MC can quickly trace the information of patient activity or contacts uploaded by fog nodes. Besides, the empowerment of the 5G-integrated and blockchain-based network eliminates the burden of the centralized server compared to existing schemes with centralized architecture with higher communication bandwidth & lower delay.

Table 3.

Time and communication complexity of PRVB.

Process	Entity	Time Complexity	Communication Complexity
Registration	MC	$O(m+n)$	-
Information Uploading	User	$O\left(1\right)$	$O\left(1\right)$
	Fog Node	$O\left(1\right)$	$O\left(m_j\right)$
Route Query	MO	$O\left(1\right)$	$O\left(n_p\right)$
Location Publication	MO	$O\left(1\right)$	$O\left(n_p\right)$
Location Checking	User	$O\left(1\right)$	$O\left(1\right)$
Patient Tracing	MC	$O\left(1\right)$	-
Contact Tracing	MC	$O(m_j·n_p)$	-

8. Conclusion and future work

Int his work, we propose PTBM, a privacy-preserving patient contact tracing scheme that enables tracing the current route of a patient with infectious diseases (e.g., COVID-19), and location checking of public without violating their identity & location privacy. More specifically, permissionless and permissioned blockchain is used to achieve public location checking and reliable route storage respectively. Bloom filters, PCSD cryptosystem, pseudo-random functions, and hash function also enhance the privacy-preserving property of the proposed scheme. Theoretical analysis and experimental evaluations also show that the proposed PTBM scheme achieves privacy protection, reliability, and traceability with low computation & communication complexity.

For future work, we will consider leveraging this blockchain-based solution for more comprehensive patient management, vaccination protocols, and protected information sharing with the international organizations in a global pandemic scenario. Besides, how to integrate the emerging 5G technology to other relevant medical application that demands high communication reliability and low latency is also a promising research direction.

CRediT authorship contribution statement

Can Zhang: Conceptualization, Methodology, Software, Writing - original draft. Chang Xu: Resources, Investigation, Formal analysis. Kashif Sharif: Writing - review & editing. Liehuang Zhu: Supervision, Funding acquisition.

Declaration of Competing Interest

We declare that we have no conflicts of interest to this work. We do not have any commercial or associative interest that represents a conflict of interest in connection with the work submitted.