key: cord-0142857-j815gdo7
authors: Cheng, Xiang; Yang, Hanchao; Krishnan, Archanaa S; Schaumont, Patrick; Yang, Yaling
title: KHOVID: Interoperable Privacy Preserving Digital Contact Tracing
date: 2020-12-17
journal: nan
DOI: nan
sha: f3f19622597b56e1e8aa3782d17bd898957a0c1d
doc_id: 142857
cord_uid: j815gdo7

During a pandemic, contact tracing is an essential tool to drive down the infection rate within a population. To accelerate the laborious manual contact tracing process, digital contact tracing (DCT) tools can track contact events transparently and privately by using the sensing and signaling capabilities of the ubiquitous cell phone. However, an effective DCT must not only preserve user privacy but also augment the existing manual contact tracing process. Indeed, not every member of a population may own a cell phone or have a DCT app installed and enabled. We present KHOVID to fulfill the combined goal of manual contact-tracing interoperability and DCT user privacy. At KHOVID's core is a privacy-friendly mechanism to encode user trajectories using geolocation data. Manual contact tracing data can be integrated through the same geolocation format. The accuracy of the geolocation data from DCT is improved using Bluetooth proximity detection, and we propose a novel method to encode Bluetooth ephemeral IDs. This contribution describes the detailed design of KHOVID; presents a prototype implementation including an app and server software; and presents a validation based on simulation and field experiments. We also compare the strengths of KHOVID with other, earlier proposals of DCT.

The global pandemic of COVID-19 has been a big challenge to human society. By sacrificing economic growth, governments around the world are making efforts to control and mitigate its spreading. To effectively slow down the spreading of an infectious disease, the discovery rate of new infections should be considerably higher than the infection rate [15] . This requires contact tracing which identifies who was in close contact with diagnosed patients, so that precautions can be taken to prevent further spread of the infection.

Smartphone-based Digital Contact Tracing (DCT) systems have been proposed in an attempt to improve the speed of finding close contacts [12, 43, 46, 52] . These systems estimate pathogen exposure risk either through geolocation (e.g. Global Navigation Satellite System (GNSS)), or via proximity-measurement technologies like Bluetooth proximity sensing. DCT systems can automatically notify these contacts so that they can self-quarantine to prevent further spreading of the disease. In addition, when these individuals start to experience sickness symptoms, DCT systems will identify them as likely infected cases and prioritize them for testing. This will lead to more effective use of the limited test capacity and early treatment for patients.

Since the onset of COVID-19, various DCT systems have been developed and deployed around the world.

A majority of them identify contacts using Bluetooth rather than using GNSS due to privacy concerns. However, if the privacy issue can be solved, geolocation-based DCT systems will offer two major advantages over Bluetooth-based systems.

First, geolocation-based DCT systems are compatible with manual contact tracing, whereas Bluetooth-based systems are not. As of today, most of the contact tracing work is carried out manually. Contact tracers work with patients to identify their close contacts and the places they visited a few days before the onset of symptoms [27] . Apart from obtaining identities of close contacts from patients, manual contact tracing also identifies locations patients visited. This verifies contacts whom the patient does not personally know, such as a cashier in a supermarket or a server in a restaurant [6, 10] . Unfortunately, Bluetooth-based and other proximity-sensing-based DCT systems do not collect such absolute location data. Hence, they can neither benefit from nor aid manual contact tracing.

In comparison, geolocation-based DCT systems and manual contact tracing can exchange location information for mutual benefits. For example, a geolocation-based DCT can provide exposure risk levels in public areas (e.g. restaurants and grocery stores) to help manual contact tracing to identify high-risk service workers. A contact tracer can share a patient's past visited locations to a geolocation-based DCT system even if the patient did not use the DCT app before the onset of symptoms. By getting additional patient histories from manual contact tracing, geolocation-based DCT systems can warn more users and may achieve a reduction in disease spreading at a lower app adoption rate. This makes geolocationbased DCT systems useful under a gradual deployment timeline, and in a demographic where a large portion of the population does not have the app. The latter scenario reflects reality. In the US for example, only 53% of US seniors older than 65 own smartphones [50] . Yet, this age bracket is the most vulnerable to the disease.

Second, geolocation-based DCT systems can inform the health authorities about the spread of the disease in a particular location. By aggregation of patients' trajectory history, the health authorities may learn the disease's spreading pattern within a community, and make informed decisions such as allocating more medical resources to hot-spot areas , announcing lockdown for a specific region instead of the whole state, or warn about a recent high-risk activity to a local community. Unfortunately, Bluetooth-based DCT systems cannot provide such information to the health authorities.

(1) How can a DCT system preserve all users' privacy while recording their past trajectories? (2) How to minimize the effects of GNSS localization error in contact tracing, especially in complex environments like indoor or urban canyon environments?

The first challenge is critical since privacy concerns have greatly hindered the wide adoption of DCT apps [29, 49] . We consider two perspectives: (a) trajectory privacy that protects a user's visited places and any personal information inferred from the trajectory histories; (b) exposure privacy that hides the user's exposure risk provided by the DCT app. To protect users' trajectory privacy, we propose to use k-anonymity to mix users' real trajectories with synthesized trajectories, such that users' real trajectories are hidden from eavesdroppers and other parties in the DCT system [8, 37, 48] . Next, we protect users' exposure risk through an efficient multiparty computation (MPC) design. MPC is a secure computation technique, where a function is computed by multiple parties jointly over their input, while keeping these inputs and the output private. However, designing an MPC-based DCT protocol is nontrivial since MPC for general functions is currently not scalable due to its huge computational complexity [14] . To enable our MPC scheme to compute trajectory intersection efficiently even when a large number of synthesized trajectories exist, we customized the MPC scheme with a partial-homomorphic Paillier cryptosystem [36] , where the computation of location intersection and exposure risk is decomposed into a small set of homomorphic operations.

For the second challenge, we propose to integrate the Bluetooth technology with our geolocation-based DCT system, as Bluetooth has a better accuracy of proximity detection than GNSS in indoor environments. However, existing Bluetooth-based methods [4, 25, 39, 51] cannot fit into our geolocation-based design. A naive integration of Bluetooth and geolocation-based DCT system may cause a privacy risk which may be exploited by curious users to deanonymize patients' identities using exposure locations. To prevent this problem, we designed our Bluetooth protocol to be compatible with our geolocation-based DCT system, which maintains k-anonymity based user privacy.

Overall, in this paper, we propose KHOVID: a H ybrid DCT system that enhances geolocation-based contact tracing with Bluetooth while preserving user privacy using K-anonymity. In KHOVID, degradation of user privacy is avoided by building a customized MPC mechanism using the Paillier cryptosystem. In addition, to increase the accuracy of contact detection in complex environments, we combine the geolocation-based method with Bluetooth technology by designing a new Bluetooth DCT protocol. KHOVID offers accuracy and availability for multiple physical environments, interoperability with manual contact tracing, and the preservation of the privacy of all users in the system.

We make the following contributions:

• First, we proposed a geolocation-based contact tracing method that guarantees both trajectories and infection/exposure information are only known to users themselves. • Second, we designed a new Bluetooth-based DCT protocol that can coordinate with the geolocation-based method to boost contact tracing accuracy and availability of KHOVID . The novel design of EphIDs generation ensures that no additional personal information will be leaked compared to the geolocation-only method. • Third, we implemented a prototype of KHOVID, including both its app and server software. Field experiments were conducted to evaluate the effectiveness of KHOVID system and showed that KHOVID is highly scalable and can potentially slow and curb the spread of COVID-19 much faster than other DCT systems.

Organization: The rest of this paper is organized as follows. Section 2 summarizes existing DCT designs. Section 3 provides an overview of KHOVID's architecture and threat model. Section 5 describes our new Bluetooth-based DCT system and its hybrid operation with our geolocation-based DCT system described in Section 4. In Section 6, we analyse the system security of KHOVID, particularly against common attacks on DCT systems. Section 7 describes our simulation and field experiments on adoption rate and scalability of KHOVID, respectively. We conclude the paper by describing future work in Section 8.

A majority of DCT systems for COVID-19 are built on two technologies: Bluetooth and GNSS. The Bluetooth-based DCT exchanges Bluetooth beacons with nearby devices, and the GNSS-based DCT traces users' past visited places based on GNSS readings (i.e. latitude and longitude). In this section, we will briefly discuss related works based on these two types of contact tracing methods. The discussed limitations of these related works are summarized in Table 1 .

In a Bluetooth-based DCT, an app on a user's mobile device generates unique randomized EphIDs. The app continuously broadcasts its EphIDs to neighboring devices, while saving the received EphIDs from these neighbors. If a user is tested positive with COVID-19, the sick user's app uploads the EphIDs that it has transmitted/received in the past to a central server. Other users then can calculate their exposure risks by checking if their received/transmitted EphIDs match the patients' EphIDs. The exposure risks can be calculated either by the central server or by the users' mobile phones, leading to a centralized or decentralized method, respectively (Table 1) .

Centralized methods rely on central servers to calculate users' exposure risks and notify those with high exposure risk. Trace-Together [2, 5] in Singapore, COVIDSafe in Australia [32] , and TousAntiCovid [18, 25, 39] in France are examples of centralized design. However, the current centralized methods have raised many privacy concerns. For example, people are afraid that they may be forced into quarantine as the central server is aware of users' exposure risks. In addition, users' social interactions with their acquaintances are also exposed to the server [42] . Such concerns of privacy have hindered the adoption of centralized schemes in many regions [50] .

Decentralized methods conduct exposure risk analysis on users' mobile phones, by downloading patients' EphIDs from the server. DP-3T [51] and the Google/Apple Exposure Notification (GAEN) system [4] are examples of decentralized methods. A few of the decentralized apps [22, 26, 33, 34] , deployed in small-scale, ensure that exposure risks are only known to users themselves. But they also have limitations. These schemes reveal patients' EphIDs and encounter time to all users in decentralized systems. This has been shown to easily leak the identities of patients [42, 53, 54] and violate privacy protection for medical data. Besides security issues, Bluetooth-based DCT also struggles with three additional performance challenges. The first one is poor performance under low to medium adoption rate [9, 13] . Bluetoothbased DCT only helps when both parties of a contact event have the app. If Alice with a Bluetooth-based DCT app sits in a public library besides a stranger who does not have the app, the encounter will not be captured by the system. As a result, the effectiveness of Bluetooth-based DCT under medium to low adoption rate is very poor. For example, if only 10% of a population installs Bluetoothbased DCT in their phones, the chance that a random contact event can be captured by this app is only 1%.

A second major challenge is that present Bluetooth-based DCT deployments are incompatible with manual contact tracing. Bluetooth EPhIDs transmitted by the sick user Alice are useless to a person without the app. The only way that the app-less person can be warned is by manual contact tracing. Bluetooth-based DCT can neither provide the location of dangerous contact events to manual contact tracing nor benefit from the location information obtained from manual contact tracing. Since manual contact tracing is the dominant tracing mechanism and is the only effective tracing mechanism for populations that do not own smartphones, this incompatibility limits the effectiveness of Bluetooth-based DCT.

Third, these schemes can only capture cases where the disease spreads through direct face-to-face contact. However, time-lagged indirect spreading situations such as spreading through contaminated surfaces or lingering aerosols in poorly ventilated spaces cannot be captured by these schemes.

A geolocation-based DCT system records each user's past geotrajectories based on GNSS systems' output. The users' exposure risks are calculated based on the number of intersections between users' recorded trajectories and patients' trajectories in the past. However, logging users' trajectory information in a DCT system without any privacy protection must be avoided, as adversaries can easily infer users' personal information, such as identity, home and work addresses, and daily activities, from the data.

Designing a privacy-preserving geolocation-based DCT system is still a challenging problem, and only a few solutions make efforts to protect users' privacy. Kato et al's work [16] attempts to address 

Persons who have been diagnosed with COVID-19 and will share their contact tracing history to the DCT system.

A person that has been in close proximity with a patient sometime during the past 14 days of incubation period. [42] . Exposure risk Exposure risk reflects the probability that a person has been exposed to the virus. The more contact with patients, the higher the exposure risk.

the privacy issue by proposing a hardware-supported trusted execution environment in the server, where plaintext comparisons of trajectories are carried out. This scheme essentially gives the server full trust for both healthy users and patients' private data. Another set of projects [7, 17, 40, 41] relies on crypto-protocols such as Private Set Intersection (PSI) or MPC to protect the trajectory privacy of healthy users from an untrusted server. These schemes allow two parties to find the intersection of their data without revealing data not contained in the intersection. Yes, these schemes still have limitations. First, these schemes have to give the server full trust to store patient trajectory data in unprotected form, essentially sacrificing patients' privacy in exchange for healthy user's privacy. Unfortunately, survey data has shown that the general public is distrustful of such a DCT design [49] . Second, these schemes reveal to a healthy user the location and time of a contact with a diagnosed patient. Since the healthy user may remember who he/she met at the time and location, the patient's identity is essentially revealed by the location/time information. Third, similar to Bluetooth-based DCT, the privacy protection techniques used in these schemes also make them incapable of capturing indirect spreading of the disease. Our proposed method seeks to protect the users' privacy of both sick and healthy users from both untrusted servers and other users. In addition, our scheme seeks to support considerations of both direct and indirect spreading of COVID-19. More importantly, our proposed method is able to cooperate with Bluetooth technology without sacrificing privacy protection, thus addressing the GNSS's lack of indoor localization. To the best of our knowledge, we are the first privacy-preserving DCT protocol to combine GNSS with Bluetooth technology.

The design goal of KHOVID is a hybrid DCT system that can provide accurate privacy-preserving exposure notification service to app users by leveraging both geolocation and Bluetooth technology. In this section, we introduce the threat model and briefly describe the workings and interconnection among KHOVID components.

Like all DCT systems, KHOVID system also involves three types of interacting parties: patients, DCT servers, and healthy users. The terms "patients" and "healthy users" are defined in Table 2 . DCT Servers are responsible for data storage and system operations. We consider two types of attackers against such a system: Adversarial users: The goal of adversarial users is to use any possible strategies to deviate from the DCT protocol, and they can be either active or passive adversarial users. Active adversarial users actively participate in the protocol by injecting malicious messages. For example, an active adversary can fake as a patient and send spurious information to the central server or other users. Passive adversarial users refer to curious users who are interested in identifying other users' personal information, such as home addresses, workplaces, etc., by observing legitimate messages. We assume that hardware is trusted in our system, and consider hardware attacks to be out of scope of the paper .

Curious Servers: A curious server refers to the honest-but-curious central server in a DCT system, usually maintained by tech companies, health authority or government. The objective of a curious server is to derive sensitive user information based on received protocol messages while following the DCT protocols. For example, the central server may learn users' home addresses, exposure risks, or build social graphs from the uploaded location information. If there are multiple servers in the system, we assume that the servers do not collude with each other (e.g. operated by different agencies). Figure 1 illustrates the architecture of KHOVID, which includes patients, healthy users and two servers: RedZone Collector and Risk Interpreter. Risk Interpreter is a central server responsible for key distribution and ciphertext decryption. The server generates a Paillier public/private key pairs ( , ). The public key, , is distributed to all users and the RedZone Collector. The private key, , is kept as a secret only known to the Risk Interpreter, which means Risk Interpreter is the only party who can decrypt a Paillier ciphertext in the system. RedZone Collector stores data and conducts contact tracing history comparisons between healthy users and patients. Both patients and healthy users have downloaded the KHOVID smartphone app that locally logs a user's trajectory and its encounter with other KHOVID phones in the past two weeks, where the two-week time span is the maximum incubation period.

When a user is tested positive with COVID-19 and becomes a patient, he/she can voluntarily let the app upload his/her past trajectories and contact event information to RedZone Collector. The uploaded information is under strict privacy protection as it is masked using k-anonymity and Paillier encryption before uploading. Manual contact tracing data about patients' whereabouts can also be uploaded to RedZone Collector by healthcare authorities using the same privacy-preserving mechanism. A healthy user, who wants to evaluate his risk of contracting the disease from patients, queries the RedZone Collector to compute his exposure risk. RedZone Collector performs secure computation to produce a homomorphically encrypted query response. The healthy user sends a masked version of the encrypted response to the Risk Interpreter, which decrypts the masked results, and returns the decryption results to the healthy user. The healthy user removes the mask to turn the decryption results into the exposure risk. The above KHOVID operations are carried out under strong privacy protection, so that both patients' and healthy users' trajectories and other private information are not exposed to app users, the servers or any other parties. (See Section 4 and 5 for details).

This section depicts the details of our geolocation-based DCT system design. We first introduce the cryptosystem used in the design, and then discuss the three major design parts: patient data preparation, patient data integration, and exposure risk computation. Key notions are listed in Table 7 in Appendix.

KHOVID leverages a partially homomorphic cryptosystem that allows homomorphic addition and scaling computations in the ciphertext domain. Since KHOVID does not require fully homomorphic operations, its computational complexity is not high and can be scaled to handle large number of users. We demonstrate a realization of the required homomorphic system by means of the Paillier Cryptosystem. The Paillier cryptosystem [36] is based on arithmetic in the ring of integers modulo 2 , where is the product of two large primes. It is a probabilistic encryption mechanism that introduces a random value in each encryption to ensure that encrypting the same message several times will, in general, yield different ciphertexts. It efficiently supports additive (⊕) and scalar-multiplication (⊗) homomorphic operations. The details of Paillier cryptosystem's operations are shown in Algorithm 1 in Appendix, where the encryption result of a plaintext message m is denoted by .

Suppose Alice is a patient and she installed the KHOVID app before she gets infected. The app records Alice's location trajectory and securely stores the trajectory on the phone [3, 21] . The location trajectory is a list := {( , )| ∈ + }, where the tuple ( , ) means that Alice visited location at time . Location is defined by longitude and latitude. Once Alice is diagnosed with the disease, she can choose to voluntarily upload her trajectory data of the past two weeks to RedZone Collector as follows.

Alice's app first removes all locations that Alice has set to be sensitive (e.g. near home locations) from the recorded data. Then, the app synthesizes sets of fake trajectories

where each fake trajectory needs to mimic real human trajectories. We also define a binary flag for each trajectory and .

= 1 means trajectory is a real trajectory and = 0 indicates is a fake trajectory. The fake trajectories and real trajectories are mixed together to form a superlist˜, where˜=

where the real trajectory ( , )'s position in the list is randomly picked. In the next step, the flag associated with each trajectory is encrypted by Paillier cryptosystem using the public key, , that is published by the Risk Interpreter. The encrypted flag for a trajectory is denoted as and the trajectory superlist containing encrypted flags is denoted as ˜ , where ˜ := {( , )|∀ ∈˜}. Finally, ˜ is uploaded to RedZone Collector, as shown in step 1a in Figure 2 . Note that , which flags Alice's true and fake trajectory data, cannot be decrypted by RedZone Collector since it does not have the decryption key.

Unlike Bluetooth-based method, the above Data Collection process also works with manual contact tracing. If Alice did not install the app before she is diagnosed, as long as she still remembers the places that she visited earlier, she can report these places to a contact tracing worker. The contact tracer can then manually convert this oral description into , use software to generate fake trajectories and upload the true and fake trajectories to Red-Zone Collector following the same data upload protocol as the app. By coordinating with manual contact tracing efficiently, RedZone Collector will have a richer collection of patient data and hence discover more encounters with patients.

Note that before Alice uploads her trajectory information, an authentication process is required to ensure she is truly positive. The health authority provides a secret code in its positive test report to Alice, which is used for authentication and grants the app permission to upload data. The secret code remains valid only for a short period of time, to prevent selling the code to others.

A major design trade-off in the above design is between communication cost and privacy protection. The number of fake trajectories (denoted as k) provides k-anonymity for the patient. The larger k is , the more secure the user's trajectory data will be. However, too large a k value will also increase the amount of data to upload, process and store at RedZone Collector. Thus, the proper setting of k can be chosen according to network communication capacity and RedZone Collector's process and storage capacity.

In addition, to ensure real trajectories will not be exposed even if RedZone Collector uses advanced data analysis tools, the fake trajectories need to have realistic mobility patterns as real trajectories do. We achieve this by adopting methods from [37] , where each set of fake trajectories have different home addresses, workplaces and leisure places, and the time spent in those places remains similar to real human trajectories. Results from [37] have shown that the method has a good capability to mimic the real trajectories. Other trajectory synthesis algorithms can always be used if they can imitate real trajectories well.

Although RedZone Collector cannot decrypt Alice's trajectory data, it can still integrate Alice's input with other patients' data into a 2-dimensional matrix := { } for all possible location in the service region and time point < 2 weeks.

is an encrypted historical record of virus density at various (location, time) points, which are computed as follows.

When initializing 's entry , set ← 0 and mark the state of as "untainted". For every uploaded patient trajectory and every location ∈ , the accumulated amount of virus that the patient had expelled to location at time can be expressed by:

Here, ( − ) is a positive decreasing weight function that captures the dying down of COVID-19 virus in an environment over time [47] , and represents the maximum lifespan of COVID-19 virus in a normal environment. (.) is introduced to capture both direct person-to-person transfer cases and the cases where COVID-19 spreads indirectly through contaminated surface or aerosols. The exact shape of (.) and setting of are controlled by RedZone Collector and can be updated according to new medical science discoveries or environment consideration at location . The virus load is then integrated into . If entry 's state is "untainted", RedZone Collector assign ← and mark 's state as "updated". If 's state is already "updated", RedZone Collector computes ← ⊕ . After the aggregation, if an entry is the ciphertext of a positive number (denoted as ), it means some patient(s) were at location no more than time ago and the value represents the virus load that is left by these patients at location at .

= 0 happens when no patient visited location recently.

To ensure only maintains history in the past 14 days, Red-Zone Collector periodically updates by deleting entries with earlier than 14 days ago.

Now, consider a healthy user Bob who wants to evaluate his risk of contracting COVID-19. Using the same method of k-anonymity through fake trajectories , Bob's app generates a trajectory superlist , which includes both Bob's real trajectory history and a ′ number of fake trajectories { }. As shown in Figure 2 step 2a,ĩ s sent to RedZone Collector as a query request. For each trajectory ∈˜, RedZone Collector calculates an encrypted exposure risk value through homomorphic addition operations:

Bob's app receives the list of encrypted exposure risks = { 1 , 2 , ..., } from RedZone Collector. Bob picks the one that corresponds to his real trajectory since Bob knows the position of his true trajectory in the original˜. Then, Bob needs to ask Risk Interpreter to decrypt the exposure risk for him, which is the only entity in the entire KHOVID system that holds the decryption key ( ). In order to keep the exposure risk secret, Bob's app firstly generates a random masking number and then sends a masked exposure risk ˆ to Risk Interpreter, where

Risk Interpreter decrypts ˆ and returns the decryption result to Bob's app. Bob's app then recovers his plaintext risk by removing the mask (a.k.a.

=ˆ− ) and display the exposure risk to Bob. ≥ 0 indicates that there is a chance that Bob contracted COVID-19, either through a direct encounter with some patient(s) at some location(s) or visiting the location(s) a short time after the patient(s). The exposure risk is proportional to the virus load in the locations that Bob visited, which considers the life span of COVID-19 virus in an environment. The larger the value of , the greater the risk.

In the above design, both the patients' and the users' real trajectories and the users' chance of contracting COVID-19 (a.k.a. exposure risk) are not revealed to any entity in the KHOVID system except the user himself. Also, all the communications between clients and servers are through a secure TLS channel. Thus, users' personal information cannot be leaked to any entity eavesdropping on the KHOVID system. In addition, the exposure risk is a single value, which does not reveal when and where encounters with patients happened. This ensures that Bob is unlikely to derive the identity of patients by cross-checking the exposure risk with his memory.

In this section, we introduce the Bluetooth protocol of KHOVID, which works with the geolocation-based protocol described in the previous section without compromising security and privacy. Besides Bluetooth, other technologies like ultrasound [30] can also be utilized for accurate close-contact detection and be combined with the geolocation side of KHOVID. Without loss of generality, we choose Bluetooth to describe our design, since it is widely used in most existing DCT apps.

We start by describing the key design intuition behind our new Bluetooth-based protocol.

Design choice 1: Cryptosystem and MPC. Among the existing Bluetooth-based methods shown in Table 1 , both centralized methods and decentralized methods have privacy issues. We choose to solve the privacy problems of Bluetooth using the Paillier cryptosystem and MPC. Essentially, we can let the healthy users compare EphID records in ciphertext domain through homomorphic computation. Risk Interpreter then decrypts the encrypted comparison result and converts it into an exposure risk that does not reveal patient encounter time. The exposure risk is then sent to the healthy user. By adding Risk Interpreter to the comparison procedure, the encounter time with a patient is not revealed, thus protecting patients' identities from other curious users.

Nevertheless, introducing the Paillier homomorphic cryptosystem raises the problem of communication overhead. In a typical existing decentralized system, healthy users usually download all the patients' EphID records from the central server for comparison. Since these records are downloaded in plaintext (e.g., 128-256 bits per plaintext), the data size is small and hence the scheme is scalable. However, in a privacy-perserving design, a healthy user needs to receive patients' EphIDs in ciphertext form (e.g., 2048 bits per ciphertext ) to ensure the patients' identities are not revealed to the healthy user. This may cause communication overhead if there is a large number of patient EphIDs. To reduce the communication overhead, the number of records to be downloaded should be decreased, which leads to our next design decision.

Design choice 2: Integration of Spatio-temporal Information. Instead of pulling all patients' EphIDs from the central server, a healthy user can reduce communication overhead by only retrieving EphIDs of patients whose reported trajectories (fake or real) intersect with the healthy user's trajectories. To achieve this, we decide to integrate location and time information with an EphID. Location information can be a region code representing a certain area, and time information can be the timestamp of broadcasting the EphID. As patients' EphIDs are uploaded, RedZone Collector can organize EphIDs according to their locations and timestamps. Then, before downloading records, healthy users can specify the region and duration where trajectory intersections may happen and only retrieve EphIDs related to these trajectory intersections.

In our design, we keep the granularity of region codes in EphIDs as a tunable parameter. The larger area a region code covers, the more encrypted patients' EphIDs that the user needs to retrieve. While a smaller area can decrease the amount of data to download, it may also cause patients' past trajectories to be leaked. To understand this drawback, recall that our Bluetooth-based scheme should work with geolocation-based protocol together. When a patient uploads his advertised EphIDs containing region codes, his past trajectories are uploaded too. Then, a curious central server can distinguish fake trajectories if they are outside of the regions claimed by EphIDs. The smaller area a region code covers, the more fake trajectories will be exposed and removed by the central server. Thus, it is important to determine how to make the granularity of region codes small enough so that the communication cost can be reduced to a reasonable level while keeping users' trajectories protected. We solve this problem through the next design decision.

Design choice 3: Cooperation with fake trajectories. To ensure the EphIDs will not expose the fake/real status of uploaded trajectories, we make the uploaded patient EphIDs contain some fake EphIDs whose region codes are consistent with fake trajectories. The basic idea is that when a patient uploads advertised EphIDs, he not only claims that the EphIDs are broadcasted in the real visited places but also pretends EphIDs are broadcasted in other fake places.

With the above design choices, our new Bluetooth-based protocol cooperates with geolocation-based protocol efficiently and privately. The main data flows in the protocol are demonstrated in Figure 2 , and the detailed procedures are described as follows.

Once the Bluetooth option is turned on in a KHOVID app, it starts to generate EphIDs which are used to exchange with nearby KHOVID devices. In our design, instead of using a random string [4, 51] , an EphID is generated by concatenating the smartphone's last available location with a random string. The detailed procedure for generating and exchanging EphIDs are described as follows:

(1) The first step is to generate unique and random strings at each mobile device, using a similar method as existing Bluetooth methods [4, 51] . Specifically, to avoid location tracking via the EphIDs, the random string used in EphID changes at every minute. We denote the sequence of these random strings as { }. (2) In the second step, KHOVID app reads the last available location and converts it to an − ℎ geohash-code. Geohash is a public domain function that encodes a geographic location into a short length of geohash code containing letters or digits, and each geohash code stands for a grid on the map where shorter codes mean larger grids. For example, an 8 − ℎ geohash code stands for a 19 × 19 grid on the map. We denote geohash code as .

(3) In the third step, the geohash code and a random string are concatenated into a string, and this string is the EphID = || , where || is a concatenation operator. For every minute, a new EphID is generated. (4) In the final step, once the EphID is generated, it is continuously broadcasted by the app. All the used EphIDs along with the broadcast timestamps (1-minute granularity) in 14 days, denoted as := {( , , )| ∈ + } and called temporal-EphIDs, will be stored securely on the phone. (5) When the app receives another device's EphID = || , it will first check if the geohash code is within meters from itself. If the answer is yes, a temporal-EphIDs ( , , ) will be created for the EphID and be saved on the phone in the received EphID set . Otherwise, the received EphID will be discarded. The purpose of comparing the geohash code in the received EphIDs with the receiver's location is to avoid Bluetooth relay and replay attacks, which are two of the main weakness in existing Bluetooth DCT works [23, 42, 53] . In these two attacks, attackers collect EphIDs transmitted by a patient and replay the EphIDs in other locations to create false contact cases. As long as these other locations are more than meters away from the patient's location, such replayed EphIDs will be dropped by our scheme's comparison of the geohash code in the EphIDs with receiver's location. More discussions regarding the relay attacks can be found in Appendix C. Once Alice has been diagnosed with the disease, she can choose to upload = {( , , )| ∈ + }, which includes her advertised BLE EphIDs along with timestamps, to RedZone Collector. Before Alice sends her EphIDs, to prevent the EphIDs to compromise the privacy of the geolocation-based side of KHOVID, a cloaking process is used to generate a superset˜of , where˜= ∪ . Here, is a set of fake temporal-EphIDs which are generated based on the fake trajectories in as shown in Figure 3 . First, all the ( , ) that have been visited by the fake trajectories are identified by converting ( , ) ∈ ∈ to ( , ). If any ( , ) does not appear in , the corresponding ( , , ) is added into , where is the real broadcasted at . Otherwise, the ( , ) is discarded. Finally, the EphID superset˜and encrypted location superset ˜ will be uploaded to RedZone Collector together.

Once RedZone Collector received the temporal-EphIDs from patients, it will first extract from the EphIDs, reverse its sign and encrypt − by Paillier cryptosystem. It stores the ciphertext − and indexes the storage location using the geohash code and timestamp . RedZone Collector does not know which EphID is real or fake because their geohash codes are consistent with locations in ˜ , and all the has the same pattern as they are generated using the same pseudo-random function. RedZone Collector will automatically delete EphIDs older than 14-days.

As shown step 2b in Figure 2 , when a healthy user Bob wants to check his exposure risk, his KHOVID app queries RedZone Collector by uploading superset˜= {( , )| ∈ + } = ∪ . Here, holds true ( , ) from the geohash codes of the EphIDs that Bob received in the last 14 days with timestamps of the reception.

holds fake ( , ) pairs that are generated based on the set of fake trajectories { } at the geolocation side protocol (see section 4.4). These fake ( , ) pairs ensure the true location trajectory will not be revealed. Also, to reduce the false-positive rate, only EphIDs with sufficient contact duration will be selected for the query, those EphIDs with contact duration under the threshold will be ignored. Once RedZone Collector receives the query request, RedZone Collector retrieves EphIDs that matches ( , ) ∈˜in its own storage. If there is a match, RedZone Collector sends the matching EphID's , denoted as , back to Bob in the encrypted form of ( , , − ). After Bob's app get all the responses from RedZone Collector, it discards the − corresponding to the fake ( , ). Then, it performs the homomorphic addition between the rest of − and the from locally stored received EphIDs: = ⊕ − , where = 0 if = , which means Bob have a contact with an infected user, otherwise, ≠ 0. After checking all the returned results, Bob will get a list of encrypted subtraction results = { 1 , 2 ... }. Note that Bob's concern is how many infected users he has contacted in the past 14 days, which is equivalent to how many 0 exist in . To figure out that, as showed in step 4b and 5b in Figure 2 , Bob's app sends a masked comparison result list ˆ = ⊕ to Risk Interpreter. Risk Interpreter decrypts ˆ , randomly shuffles the sequence of entries in the decrypted lists and returns the final listˆ= {ˆ1,ˆ2...ˆ} back to Bob's app, which then recovers the by removing the mask from all list entries. Now Bob can see how many infected users he has contacted, which is the number of 0 in the list .

In the above design, the exposure risk is only known to Bob himself. RedZone Collector does not know because the EphID comparisons are conducted on the smartphone. Risk Interpreter does not know because the comparison results ˆ is masked by . What's more, Bob can not infer encounter time/location with patients because the shuffling of entries inˆbefore it is returned from Risk Interpreter decouples the comparison results from location and time information. Besides, none of the healthy users' and infected users' trajectories, social graphs are revealed to any entity in or outside of the KHOVID system because they are hidden under fake trajectories and fake EphIDs. 

In this section, we discuss the possible attacks on KHOVID and how they are mitigated in our design. Table 3 summarizes the attacks and our defense mechanisms, of which we discuss two main attacks in this section and discuss the rest in Appendix C.

A cross-reference attack occurs when an attacker attempts to get users' personal information by cross-checking different types of data. In our design, we consider RedZone Collector as a possible attacker since it accepts data from both patients and healthy users. The goal of RedZone Collector is to pick out an app user's real trajectories from the cloaking trajectories, it can either cross-check trajectories with the EphIDs from the same user or cross-check trajectories with other users' uploaded records. However, our protocols can prevent such attacks in both ways because of the following reasons. First, when the attacker cross-checks cloaking trajectories with the user's EphIDs, it compares the ( , ) in EphIDs with every ( , ) from trajectories, and any trajectories containing a ( , ) without a corresponding ( , ) existed suggests a fake trajectory. KHOVID's Bluetooth protocol prevents this happening as fake EphIDs are synthesized along with fake trajectories. It ensures that both real and fake ( , ) always have a corresponding ( , ) in EphIDs.

Second, when the attacker cross-checks a user's cloaking trajectories with others users' uploaded records, it checks whether the user's trajectories intersect with others' while their EphIDs exchanges at the same ( , ). The insight is that intersections among real trajectories usually are accompanied by some exchange of EphIDs, while fake trajectories' intersections do not have such records of EphIDs exchange. However, in the proposed system Red-Zone Collector cannot exam whether two users exchange EphIDs, since patients only upload their advertised EphIDs to RedZone Collector, while healthy users downloads patients EphIDs and exam EphIDs exchange on the user-side. To sum up, the protocol design of KHOVID can securely protect users' privacy from the crossreference attack.

If an attacker wants to identify the infect status of an individual, the attacker can create a new account and only contact the person or stay at the place which is highly related to the individual (e.g. home or workplace). We call this one-contact/place attack. In KHOVID, a patient has redacted specific locations/time before they upload their trajectories and EphIDs to the RedZone Collector, which prevents this attack from happening. For example, an attacker who wants to know the infect status of his neighbor can deploy a one-place attack targeting the home/workplace of the neighbor. However, if the neighbor is infected but chooses to remove any trajectories and EphIDs associated with home/workplace before sharing records with the RedZone Collector, the attacker can will not get a high exposure risk regarding the targeted place.

In this section, we demonstrate KHOVID's interoperability, and its scalability to large deployments.

Interoperability, in this paper, means the ability to merge KHOVID's DCT with manual contact tracing. Using a simulation of COVID-19 spreading, we compare KHOVID with Bluetooth-based DCT.

The simulation results show that by combination with manual contact tracing, KHOVID can reduce infections more dramatically compared to Bluetooth-based DCT under the same adoption rate.

We ran the simulations based on an individual-based computational model called OpenABM-Covid19 [24] . OpenABM-Covid19 can evaluate non-pharmaceutical interventions during the Covid-19 pandemic, including both manual and digital contact tracing. It uses epidemiological and demographic parameters as a guide, seeking to simulate individuals and their interactions in home, work, and community contexts. OpenABM-Covid19 has been used to explore manual/digital contact tracing interventions in the UK [24] and Washington state in US [1] .

We set the pandemic model parameters in the simulations based on population, demographic, and occupational structure from King, Pierce, and Snohomish counties in Washington state. Three different tracing modes are considered: (1) Manual only, where contact tracing is carried out by hand, (2) Bluetooth + Manual, where the two tracing schemes work independently from each other, and (3) KHOVID + Manual, where the two tracing schemes collaborate with each other. We assume the adoption rate of KHOVID or Bluetooth DCT is all 30%. Other important parameters are listed in Table 4 .

Some of the parameters in Table 4 are set differently for Bluetooth DCT and KHOVID DCT because KHOVID can collaborate with manual tracing. First, the manual contact tracers can help patients who did not install KHOVID app to provide trajectories to KHOVID. We assume 40% of the trajectory data identified by these manual interviews are shared with KHOVID. Second, a patient who installed KHOVID app can give manual contact tracer his recorded trajectory so that the interview time can be greatly shortened comparing with oral description of past trajectory. Assume that a manual tracer spent 80% of his time in interviews with patients and 20% of time in sending notifications to the contacts of the patients. Assume 30% of the interviewed patients have KHOVID app and can hence shorten the interview time by 80%. These assumptions lead to a saving of 20% of a contact tracer's time, which we assumed is invested to notify more contacts of the patients and leads to doubling in the contacts that a tracer can notify per day. Other parameters not listed are the same among three settings. A complete list can be found in [1] . Each setting is simulated for 5 iterations, with a different random seed in each iteration. The number of infections prevented by using a geolocationbased DCT app is higher than by using a Bluetooth-based DCT app. Using a geolocation-based DCT app, the infection peak is reduced by 53.6%, 48.9% and 91.7% in King, Pierce, and Snohomish counties, respectively.

In this section, we evaluate the scalability of a KHOVID prototype from three perspectives: (1) communication overhead, (2) computation overhead, and (3) battery consumption. We also compare with other DCT schemes.

We built the KHOVID system by implementing a contact tracing app, a RedZone Collector server, and a Risk Interpreter server. The system is used as a proof-of-concept for evaluation.

Contact tracing app. The contact tracing app is built on Android platform, in which we implemented the geolocation and the Bluetooth protocols based on an open-source Safe-Path framework [38] 1 . The app has been tested over multiple phone models, including Xiaomi MIX2 (Android8.0, Snapdragon 835), Realme X(Android10.0, Snapdragon 710 ), and Google Pixel 3 (Android 9.0, Snapdragon 835). All the functions inside the app follow the protocol described in section 4 and 5.

Central Servers. We also built a RedZone Collector server and a Risk Interpreter server in the system. The data collection, data integration, and exposure risk computation in the servers are implemented through Firebase [20] , which provides a NoSQL cloud database for app developments. Note that the servers can also be built on other platforms. In our evaluation, we tested the servers on a Firebase emulator running on a Ubuntu machine with an AMD Ryzen 93900 12-core processor with 16GB memory. [11] 108 collects the smartphone's location and records EphID exchanges when the user is out-of-home. The app sends an exposure risk query every day. Two weeks later, the user is tested positive and decides to share his records to RedZone Collector. The important parameters of the experiment are presented in Table 5 . Specifically, we set the app's daily logging duration to a random value between 10 and 16 hours. For each trajectory uploaded by the healthy user during a query, the number of intersections with patients' records is set to 108 * 0.013 * = 1.40 * , where is the parameter in kanonymity and the number of average daily contacts is 108 (derived from [11] ). The probability that a contact is a patient is 0.013, which is calculated by assuming a two-week window over the maximum daily new infection rate (2k/2.2M=0.0009) from King County in Figure 4 .

Communication Overhead. We evaluate the system's communication overhead from three perspectives: (1) the daily upstream data usage for a healthy user, (2) the daily downstream data usage for a healthy user, and (3) upstream data usage for a patient uploading records of past 14 days. We measured the data usages in each perspective with ranging from 5 to 100. The measurement results are presented in Figure 5 .

We have two key observations. First, the communication overhead is trivial for both healthy users and patients when is small. For example, when is 5, the total amount of exchanged data between a healthy user and KHOVID servers is only 0. The main takeaway from the above results is that users of KHOVID app can adaptively change the value of based on the communication environment. For example, when the smartphone is connected to WiFi, a large can be used so that stronger privacy protection can be provided. When the smartphone's communication capacity is scarce, a smaller can be used to save the data usage while sacrificing some privacy protection.

Computation Overhead. The main computation overhead comes from the Paillier cryptosystem. The smartphone's operations involve Paillier encryption and addition, RedZone Collector involves Paillier encryption, addition, and scaling. Table 6 presents the benchmark of Paillier cryptosystem measured on a smartphone and a desktop separately. In addition, we measure the practical computation time for four tasks: (1) processing a risk query result at a healthy user's phone, (2) encrypting a two-week window of data at a patient's phone, (3) integrating a patient's data input at RedZone Collector, (4) exposure risk computation at RedZone Collector. The measurement results are shown in Figure 6 . Figure 6 : Computation time of (1) processing risk query result, (2) encrypting patient's data, (3) integrating patient data input and (4) computing exposure risk for a query.

From Figure 6 , we can observe that when a healthy user sends a query, the computation time of both task (1) and (4) is trivial which take less than 2 seconds even when = 100. In addition, task 2 and task 3 take longer time where patients' data are processed. It takes 4.71 seconds and 20.20 seconds for task 2 and task 3 when = 100, respectively. The reason that data integration takes longer time than other tasks is that it considers the dying down of the virus in an environment over time, which requires additional homomorphic scaling and addition computations when compared to other tasks.

Daily Battery Consumption. We measure the daily battery consumption of the KHOVID app. The daily battery consumption is dominated by geolocation logging and broadcasting Bluetooth EphIDs during the day. When setting the GNSS logging frequency to one log per 15 seconds, the app consumed an averagely 439 mAh/day, which is roughly 12% of the total battery.

It is important to note that the power consumption can be further reduced if we adapt the GNSS logging frequency based on different mobility patterns following methods similar to [28] . For example, based on Sila-Nowicka et al's work on human mobility [44] , a person spends 1.74 hours in driving or public transporting, 0.66 hours in walking, and 9.6 hour in a stationary state. These mobility modes can be easily detected using IMU sensors in a smartphone [28] . Then, we can adapt the GNSS logging frequency based on mobility modes, where 1 GNSS log is performed for every 15 seconds during walking, driving or public transporting period and 1 GNSS log is performed per 5 minutes during stationary mode. In our measurement, using this adaptive logging strategy, KHOVID app consumes at average 121 mAh, which is 3.2% of the total battery.

We also measure the battery consumption at a smartphone for processing KHOVID data. The measurement results are presented in Figure 7 in Appendix. The results indicate that cryptography protocols consume trivial battery power. When = 100, the power consumption for a healthy user is less than 0.5% of total battery and less than 2% for a patient.

In this section, we compare the performance of KHOVID with other existing DCT methods. Communication and computation overhead for most Bluetooth-based methods is negligible compared with KHOVID. Take DP-3T as an example, the up-link size for a patient is less than 1KB, and down-link size for a healthy user varies from 72KB to 6MB assuming 2000 new cases a day [51] . The computation overhead of DP-3T mainly comes from comparing EphIDs in plaintext, which is trivial compared with Paillier operations used in KHOVID. For geolocation-based methods, most of current protocols did not provide implementations. Here we choose one geolocation-based method called covid-alert [35] for comparison, which uses PSI and Paillier cryptosystem with code provided. In our measurement, the up-link size for a patient in covid-alert is 2.5MB, the uplink size for an healthy user is 57.7MB, which is much larger than healthy users' uplink size in KHOVID. Besides, it takes around 2.6 minutes for a healhty user's app to process all the data during a query. It is also worth pointing out that covid-alert does not protect patient privacy against untrusted servers.

In this paper, we proposed KHOVID to supplement manual contact tracing. It uses both geolocation-based and Bluetooth-based location data and protects all user privacy using k-anonymity, homomorphic encryption, and MPC. In the future, we plan to enhance its accuracy and interoperability in several ways. First, other types of location data may be incorporated with ease because our privacy protection scheme and exposure risk computation techniques are independent of the type of location data used. We provide an example of integrating WiFi access point based location data to KHOVID in Appendix B. Second, we plan to use open-source transportation mode detection(TMD) tools [19] and IMU and/or GNSS speed sensors in mobile phones to enhance the accuracy of KHOVID app. Since an app may be in motion when the app logs the contact information, detecting the mode of transportation will aid in accurate location logging and exposure risk computation. Third, we plan to design a dedicated interface for adding authorized data from manual contact tracing and utilizing the patients' location data from the RedZone Collector. The former will help KHOVID app users who did not personally know the patients without KHOVID app by allowing manual contact tracers to add such patients' past geolocation data to the RedZone Collector. The latter will provide recommendations to health authorities for zonal lockdown instead of a statewide lockdown by identifying potential hot-spots and super-spreader events from the patients' location data in the Red-Zone Collector. With these added features, we plan to perform a small-scale study of KHOVID app on a university campus. We also plan to open-source the code for KHOVID after the review process.

We put other supplementary materials in this section. Figure 7 shows the measurement results of a smartphone's battery consumption for processing the data from a patient and a healthy user, respectively. Note that the app can choose to process the data only if it is charged. Algorithm 1 describes the Paillier cryptosystem which is used in KHOVID. Table 7 lists the symbols used for describing KHOVID. ( − 1, − 1) ; 3. Choose random integer where ∈ Z * 2 , compute = ( ( mod 2 )) −1 mod , where ( ) = −1 ; 4. The public key is (n,g), and the secret key is ( , ); Encryption: 1. Let is a message to be encrypted where ∈ Z ; 2. Select random in ∈ Z ; 3. Encrypt and get its ciphertext by = ( , ) = ( + ) mod 2 ; Decryption: 1. Decrypt and get its plaintext by = ( mod 2 ) · mod ; Homomorphic property: Addition: (notation: 1 ⊕ 2 )

( 1 , 1 ) ( 2 , 2 ) mod 2 = ( 1 + 2 , 1 + 2 ) mod 2 Scale: (notation: 2 ⊗ 1 )

( 1 , 1 ) 2 mod 2 = ( 1 · 2 , 1 · 2 ) mod 2 B APPENDIX: ENHANCING ACCURACY WITH WIFI ACCESS POINT BASED LOCATION DATA

As mentioned in Section 8, KHOVID is not restricted using to just Bluetooth or geolocation based location. The privacy protection scheme and exposure notification computations are generic and may be applied to any location data including WiFi access points IDs and ultrasound measurements [31] . In this appendix, we provide an example of integrating MAC addresses from WiFi access points as the third location data type to KHOVID. A similar approach may be used for interoperability with other location data. Since the GNSS signals are usually weak indoor, neighboring WiFi access points' MAC addresses are also recorded in addition to users' longitude and latitude using existing smartphone programming APIs.

Using the example described in Section 4, Alice's location trajectory becomes := {( , , )| ∈ + }, where is a set of received MAC addresses at time :

= { 1 , 2 . . . }. During the data encryption phase, fake MAC addresses are generated from a public geo-mac-address databases [55] to match the fake trajectories, . All the real and fake MAC addresses are hashed using a one-way hash function, denoted by ℎ ℎ( ). The encrypted trajectory data becomes := {( , , , ℎ ℎ( ))|∀( , ) ∈˜}, where ℎ ℎ( ) = {ℎ ℎ( 1 ), ℎ ℎ( 2 ) . . . ℎ ℎ( )}. Note that only WiFi mac addresses with strong signal strength will be recorded to reduce false positives in exposure risk computation.

The RedZone Collector creates a new MAC-address risk flag through homomorphic addition: = ⊕ , similar to , = for some ≥ 1. The flag indicates if confirmed COVID-19 patient(s) have been in the range of WiFi access point at time . As in Section 4.4, Bob queries the RedZone Collector for his exposure risk with his cloaked superset of real and fake trajectories with their corresponding MAC addresses. In addition to replying with the exposure risks for geolocation ( ), the RedZone Collector also replies to Bob with a list of exposure risks at WiFi access point at time ,

The privacy of KHOVID is maintained using the original homomorphic encryption, k-anonymity, and MPC based protection scheme. By using a public database to generate MAC addresses for fake trajectories, we ensure that k-anonymity is maintained with the addition of a new type of location data. Thus, the addition of neighboring WiFi access point's MAC address enhances the accuracy of geolocation-based DCT in indoor environments without compromising KHOVID's privacy.

We describe the rest of the attacks in Table 3 C

One problem with Bluetooth-based methods is that an attacker may collect advertised EphIDs from a patient in one place (e.g. hospital) and broadcast them in other places, causing devices received the replayed EphIds to later falsely believe they met patients. Relay attacks occur when the EphIDs are re-broadcasted immediately at a different location, while replay attacks occur when EphIDs are collected and broadcasted at different times. Some of the existing works [4, 5, 51] integrate time information into EphIDs and validate if the received EphIDs are in the correct time slots to prevent replay attacks. Relay attacks may be prevented by using geolocation data along with EphIDs [23, 42] . Our EphIDs contain both the timestamp and geo hash which detects both relay and replay attacks. By checking the geohash code from a received EphID, the KHOVID app can obtain the sender's rough location and discard EphIDs whose locations are too far away from the receiver.

As most of the current DCT apps rely on Bluetooth technology, an attacker may attempt to stop DCT apps functioning in specific premises by disrupting Bluetooth broadcasting:

• Bluetooth jamming: The attacker can undermine the BLE tracing function with a Bluetooth jammer to block the exchange of EphIDs in a certain area. • Bluetooth overwhelming and storage draining: The attacker can deploy plenty of low-cost BLE devices and broadcast massive EphIDs. This can drain up the storage and energy of the phone.

The above attacks may force app users to turn off Bluetooth in their smartphone. Bluetooth-only DCT apps thus cannot recover from these attacks. However, turning off Bluetooth will not stop KHOVID from working as it also uses localization techniques for contact tracing. One may argue that GNSS signals can also be jammed and messed with. However, smartphones do not only rely on GNSS signals for localization but also use WiFi and cellular networks. The cost for disrupting smartphone localization is much higher than achieving the same in Bluetooth.

Data poisoning attack [45] occurs when an attacker adds malicious data like false trajectories to RedZone Collector. KHOVID can prevent data poisoning attack by considering three types of attackers.

First, for the attacker who is uninfected but claims to be a patient, certificates have been utilized to ensure only patients verified by health authorities are allowed to upload their data to the RedZone Collector. The patients who did not install the app before diagnosis and who are willing to manually upload their visited places will be assisted by their contact tracers, as mentioned in section 4.2. We assume the communications between patients and contact tracers are honest, which is a fundamental assumption in manual contact tracing. Second, for the attacker who is an infected user with the secret code but attempts to upload incorrect data to RedZone Collector, the data modification is avoided as we use secure storage to store data on the phone [3, 21] . Third, for the attacker who is uninfected and query with incorrect data, either trajectories or EphIDs from health users will not be used for computing others' exposure risks, thus these incorrect data cannot pollute RedZone Collector.

This attack occurs when the app and servers' communications are not authenticated. In this scheme, an attacker can alter a patient's trajectory data sent to the RedZone Collector or modify the plaintext risk level returned from the Risk Interpreter. However, in the proposed system we ensure all the communications between the app and servers are mutually authenticated and encrypted through TLS channel, which prevents this attack.

Modeling the Combined Effect of Digital Exposure Notification and Non-pharmaceutical Interventions on the COVID-19 Epidemic in Washington State

IOS NSFileProtectionComplete

Exposure Notifications: Using technology to help public health authorities fight COVID-19

BlueTrace: A privacy-preserving protocol for Community-driven Contact Tracing Across Borders

BBC. 2020. Coronavirus: How Does Contact Tracing Work? BBC News

Assessing Disease Exposure Risk with Location Data; A Proposal for Cryptographic Preservation of Privacy

Synthesizing Plausible Privacy-preserving Location Traces

2020. Mass. Begins Work on Tracing App, But Will It Matter? Boston Globe

Key Information to Collect During a Case Interview

Social Encounter Networks: Characterizing Great Britain

UK App Aims to Help Researchers Track Spread of Coronavirus. The Guardian

Contact Tracing Apps Were Big Tech's Best Idea for Fighting COVID-19. Why Haven't They Helped? Time Magazine

2 -SAS: Privacypreserving Centralized Dynamic Spectrum Access System

Contact Tracing and Disease Control

PCT-TEE: Trajectory-based Private Contact Tracing System with Trusted Execution Environment

A Note on Blind Contact Tracing at Scale with Applications to the COVID-19 Pandemic

Info Coronavirus COVID-19 -Application Tousanticovid

APIs for Android ActivityRecognitionClient

Work With Data More Securely

Security Analysis of the Covid-19

OpenABM-Covid19-an Agent-based Model for Mon-pharmaceutical Interventions Against COVID-19 Including Contact Tracing

ROBERT-proximity-tracing/documents

Open-Source Project Corona-Warn-App

What's It Like to Be a Contact Tracer? Probulica Illinois

Entracked: Energyefficient Robust Position Tracking for Mobile Devices

Privacy Concerns Hindering Digital Contact Tracing. WebMD

2020. Flipping the Perspective in Contact Tracing

Novid: A Mobile App for Pre-exposure Notification

Australian Department of Health

Virginia Department of Health. 2020. COVIDWISE -Virginia.gov

Federal Office of Public Health of the Swiss Confederation

Covid-alert

Public-key Cryptosystems Based on Composite Degree Residuosity Classes

Data-driven Generation of Spatio-temporal Routines in Human Mobility

Path-Check/safeplaces-dct-app

ppep pt.org. 2020. PEPP-PT Pan-European Privacy-Preserving Proximity Tracking. Retrieved

OpenMined Project. 2020. Maximizing Privacy and Effectiveness in COVID-19

Privacy-Preserving Contact Tracing of COVID-19 Patients

Cellphone Tracking Could Help Stem the Spread of Coronavirus. Is Privacy the Price? Science Magazine

Analysis of Human Mobility Patterns from GPS Trajectories and Contextual Information

Certified Defenses for Data Poisoning Attacks

An Official WHO Coronavirus App Will Be a "Waze for COVID-19

Sustainability of Coronavirus on Different Surfaces

k-anonymity: A Model for Protecting Privacy

Government Efforts to Track Virus Through Phone Location Data Complicated by Privacy Concerns

Most Americans Are not Willing or Able to Use an App Tracking Coronavirus Infections. That's a Problem for Big Tech's Plan to Slow the Pandemic

Translating a Surveillance Tool into a Virus Tracker for Democracies

Analysis of DP3T: Between Scylla and Charybdis. EFPL

Centralized or Decentralized? The Contact Tracing Dilemma

WiGLE: Wireless Geographic Logging Engine