A Survey of COVID-19 Contact Tracing Apps

06/18/2020 ∙ by Nadeem Ahmed, et al. ∙ 0

The recent outbreak of COVID-19 has taken the world by surprise, forcing lockdowns and straining public health care systems. COVID-19 is known to be a highly infectious virus, and infected individuals do not initially exhibit symptoms, while some remain asymptomatic. Thus, a non-negligible fraction of the population can, at any given time, be a hidden source of transmissions. In response, many governments have shown great interest in smartphone contact tracing apps that help automate the difficult task of tracing all recent contacts of newly identified infected individuals. However, tracing apps has generated much discussion around their key attributes, including system architecture, data management, privacy, security, proximity estimation, and attack vulnerability. In this article, we provide the first comprehensive review of these much-discussed tracing app attributes. We also present an overview of many proposed tracing app examples, some of which have been deployed countrywide, and discuss the concerns users have reported regarding their usage. We close by outlining potential research directions for next-generation app design, which would facilitate improved tracing and security performance, as well as wide adoption by the population at large.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 18

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

Abstract

The recent outbreak of COVID-19 has taken the world by surprise, forcing lockdowns and straining public health care systems. COVID-19 is known to be a highly infectious virus, and infected individuals do not initially exhibit symptoms, while some remain asymptomatic. Thus, a non-negligible fraction of the population can, at any given time, be a hidden source of transmissions. In response, many governments have shown great interest in smartphone contact tracing apps that help automate the difficult task of tracing all recent contacts of newly identified infected individuals. However, tracing apps has generated much discussion around their key attributes, including system architecture, data management, privacy, security, proximity estimation, and attack vulnerability. In this article, we provide the first comprehensive review of these much-discussed tracing app attributes. We also present an overview of many proposed tracing app examples, some of which have been deployed countrywide, and discuss the concerns users have reported regarding their usage. We close by outlining potential research directions for next-generation app design, which would facilitate improved tracing and security performance, as well as wide adoption by the population at large.

1 Introduction

The year 2020 will be forever marked in history by the worldwide outbreak of the pandemic caused by Severe Acute Respiratory Syndrome Coronavirus 2 (SARS-CoV-2) a.k.a COVID-19. As the virus began to spread globally, the World Health Organisation (WHO) declared on the 30th of January 2020 that COVID-19 was a Public Health Emergency of International Concern (PHEIC) [1]. The virus outbreak has changed the lifestyle of everyone around the world forcing governments to mandate lockdowns, recommend self-isolation, stipulate work-from-home policies, instigate strict social distancing criteria, and deploy emergency health responses - the latter including substantial new infrastructure for the treatment and mass testing of the population at large. All these measures are aimed at decreasing the rate of spread of the virus and leading to a so-called ‘flattening of the curve’111Flattening of the curve aims to decrease the infectious rate so that the available health resources remain compatible with the infected caseload. until an approved vaccine/treatment is developed.

COVID-19 is more infectious compared to other known viruses (such as SARS and MERS) albeit with a lower mortality rate. Furthermore, a COVID-19 carrier can be contagious without experiencing any symptoms. Thus, by the time the carrier actually tests positive they may have already spread the virus to many others who came in contact with them. This necessitates a process called ‘contact tracing,’ to identify individuals who had close contact with the positive carrier, as these individuals may themselves now be infected.

Contact tracing is normally accomplished through a manual interview of the infected individuals, conducted by the health authorities. The aim of the interview is to collect contacts the infected individual had with other individuals in the past 14-21 days (identified as the incubation period for COVID-19). The health officials can then use that information to compute a risk-score for each of the contacts, based on the context (e.g., indoors/outdoors), duration, and proximity (distance between the contacts). However, it is challenging for people to accurately recall each person that they may have met in the last three weeks. Besides, an infected individual might have infected many persons that they cannot identify, for example, contact with unknown persons standing in a supermarket checkout queue. Moreover, many subsequent interviews require a considerable workforce of health officials trained in the art of manual contact tracing.

In this context, researchers have been focusing on technological solutions to automate the contact tracing process with the aim of quickly and reliably identifying contacts that might be at significant infection risk. The ubiquity of smartphones and their ability to keep track of their location (e.g., via GPS and WiFi), along with their in-built Bluetooth interface allowing communication and proximity detection with nearby smartphones, makes them ideal devices for automated and reliable contact tracing. As a result, many smartphone contact tracing apps have been proposed, with some already deployed.222MIT Technology Review has a list of 25 such apps that have been developed and are being used in many countries [mit] Using the Bluetooth interface these tracing apps automatically collect the contact data of their users - data to be subsequently used in the future event of a user being identified as infected with COVID-19.

The introduction of contact tracing apps has led to a debate regarding their architecture, data management, efficacy, privacy, and security [62, bbc, duball, jennings, 49, farrell]. Most of these apps claim to be privacy-preserving - meaning that they do not reveal any Personally Identifiable Information (PII), identity, or location information of the contacts without explicit user permission. Indeed, privacy concerns associated with contact tracing apps is one of the factors that can potentially influence their adoption [51]. Another primary concern of privacy advocates is the extent to which the apps can be re-purposed to track their users, and how the collected data may be used when the current pandemic ends.

This article describes the salient features of current contact tracing apps and provides insights into their privacy and security implications. Our article is based on public information about current tracing apps, and our understanding of the evolving protocols being designed for upcoming apps. Existing surveys on contact tracing apps [LG20] are either not comprehensive or focus only on user privacy [59]. Kuhn et al. [KBS20] describes formal notions of tracing app design, but do not discuss architectural details, vulnerability, or privacy concerns.

The remainder of this article is organised as follows. In Section 2

, we classify the tracing apps in three main architectures as centralised, decentralised, or hybrid. Section

3 discusses the security, privacy, and data management implications of these different architectures. In Section 4, we highlight the Bluetooth Low Energy (BLE)-based proximity estimation technique used in most of the tracing apps. The most common attacks and vulnerabilities that could affect tracing apps in discussed in Section 5. In Section 6 a more detailed analysis of the most widely discussed apps is presented, and some common user concerns associated with these apps analysed in Section 7. In Section 8 potential future research directions are given. Finally, Section 9 concludes this article.

Figure 1: Tracing apps centralised architecture

2 System Architecture

The type of architecture adopted for the data collection aspects of tracing apps has been a matter of much discussion due to both security and privacy concerns. We will discuss three distinct system architectures commonly used or proposed for developing COVID-19 tracing applications. These are the centralised, the decentralised, and the hybrid approach that combines features from both the centralised and the decentralised architectures. Our classification criteria consider how the server is used and what data is required (or stored) by it. We now discuss each of the three architectures detailing their salient features. We will discuss some specific tracing apps that employ each of our three architectures in a later section.

2.1 Centralised

Figure 1 shows the main entities and interactions of a centralised architecture. We note that the centralised architecture we describe is based on the Bluetrace protocol [8]. The initial requirement for the app is that a user has to pre-register with the central server. The server generates a privacy-preserving Temporary ID (TempID) for each device. This TempID is then encrypted with a secret key (known only to the central server authority) and sent to the device. Devices exchange these TempIDs (in Bluetooth encounter messages) when they come in close contact with each other. Once a user tests positive, they can volunteer to upload all of their stored encounter messages to the central server. The server maps the TempIDs in these messages to individuals to identify at-risk contacts. More details on the centralised architecture’s key processes are now given.

2.1.1 Registration Phase

Figure 2 shows the steps required to register a user in a centralised architecture. A user downloads the app (steps 1 and 2) and registers details such as name, mobile phone number, age bracket, and postcode with the server (step 3). The server verifies the mobile number by sending a One Time Password (OTP) by SMS (steps 4 and 5). Upon verification, the server computes a TempID (step 6), which is only valid for a short time (Bluetrace recommended expiry time is 15 min). The TempID and the expiry time are then transmitted to the user’s app.

Figure 2: Centralised tracing app registration process

2.1.2 Registering encounters/contacts information

Once a user comes in contact with another app user, they exchange an “Encounter Message” using Bluetooth, as presented in Figure 3. An encounter message comprises the exchange of TempID, Phone Model, and Transmit Power (TxPower) (steps 1 and 3). Each device also records the Received Signal Strength Indicator (RSSI) and the timestamp of the message delivery (steps 2 and 4). Note that phone numbers are not included in these messages. Since the TempIDs are generated and encrypted by the server they do not reveal any personal information of the app user. Thus, both app users have a symmetric record of the encounter that is stored on their respective phones’ local storage. The protocol uses a temporary blacklist to avoid a user registering duplicated contacts. Thus, once a user receives an Encounter Message, the app automatically blacklists the sender for a short time.

Figure 3: Centralised tracing app contact exchange operation

2.1.3 Uploading encounters data

All encounter records are stored locally and are not automatically uploaded to the server. Figure 4 shows the application flow when a user tests positive for COVID-19 (step 1). The health official confirms whether the user has the tracing app installed, and flags the user as infected (step 2). The encounter data upload is voluntary. If the user agrees to upload the data, the health official sets this up in the back-end server, and the server generates an OTP for verification (step 3). Once verified, the encounter data is uploaded to the server (step 4).

Figure 4: Centralised tracing app notification

2.1.4 Server-side processing of the uploaded data

The server iterates through the list of encounter messages, decrypting each TempID with its secret key. This TempID is then mapped to the user’s mobile number. The server uses the TxPower and RSSI values to approximate the distance (proximity) separating the users during the reported encounter. The proximity estimation can also be performed locally on the phone, but this has battery usage implications. This proximity data, in conjunction with the timestamps, is used to ascertain the risk profile (closeness and duration) of the encounter (step 5, Figure 4). A list is prepared with all the required information (step 6) for further processing by the relevant health official (step 7).

Figure 5: Tracing apps decentralised architecture.

To summarise: In the centralised architecture, the central server plays a key role in performing core functionalities such as storing encrypted PII information, generating anonymous TempIDs, risk analysis, and notifications for close contacts. This accumulation of responsibilities raises privacy concerns that are discussed in detail in Section 3. The server is assumed trusted in this architecture, with some countries introducing strict privacy-protection regulations for safeguarding the use and life cycle of the collected data [46].

2.2 Decentralised

In contrast to the centralised architecture, the decentralised architecture proposes to move core functionalities to the user devices, leaving the server with minimal involvement in the contact tracing process. The idea is to enhance user privacy by generating anonymous identifiers at the user devices (keeping real user identities secret from the other users as well as the server) and processing the exposure notifications on individual devices instead of the centralised server. We discuss the privacy and security implications of this design in Section 3.

We take the Private Automated Contact Tracing protocol (PACT) [53] as a base to describe the decentralised architecture. The decentralised approach does not require app users to ‘pre-register’ before use, thus avoiding the storage of any PII with the server. Devices generate their random seeds (used as input for a pseudorandom function), which are used in combination with the current time to generate privacy-preserving pseudonyms or ‘chirps’ with a very short lifetime of about 1 min (see Figure 5). These chirps are subsequently periodically exchanged with other devices that come in close contact. Once a user is positively diagnosed with COVID-19, they can volunteer to upload their seeds and the relevant time information to a central server. This is in contrast to the centralised architecture where the complete list of encounter messages is uploaded. Uploading of seeds, instead of all used chirps, improves latency and provides improved bandwidth utilisation.

The central server only acts as a rendezvous point, akin to a bulletin board to advertise the seeds of the infected users. This server is considered ‘honest-but-curious’. Other app users can download these seeds to reconstruct the chirps (by using timestamps) that were sent by the infected users. The server, as well as other users, cannot derive any identifying details just by knowing the seeds and chirps. Only the other app users can perform a risk analysis to check if they are exposed for a long enough duration. This one-way lookup against the downloaded seeds restricts the server’s functionality and alleviates some of the privacy risks (see Section 3). More details on the decentralised architecture’s key processes are now given.

2.2.1 App Installation

COVID-19 tracing apps that adopt the decentralised architecture do not necessarily require an interactive registration process during the app installation stage. The app installation process only verifies a user’s smartphone and deploys a random seed generation algorithm that is not linked to the phone (see Figure 6).

Figure 6: Decentralised tracing app installation process

2.2.2 Generating seeds, chirps and exchanging chirps

Once the decentralised tracing app is installed, the seed is generated (with an expiry period of one hour) by the user’s device (see Figure 7). This seed and the current time are subsequently used in a pseudorandom function to generate the chirp. The chirps are not linked to an individual or their phone - so in principle, they are anonymous. The app generates new chirps with a time granularity of 1 min. These are broadcasted every few seconds via the Bluetooth beacon. In the listener’s phone, the app will automatically store all chirps received (step 4 in Figure 7 ). The information stored in the receiving app includes the chirp, the timestamp when the chirp is received, and the maximum RSSI value. Identical chirps received within 1 min are ignored. Note the critical difference from the centralised architecture where TempIDs are created by the server - in the decentralised case, the seeds and chirps are generated at the device.

Figure 7: Decentralised tracing app encounter exchange

2.2.3 Uploading encounters data

If a user is diagnosed positive, they are given a unique “permission number” by the relevant authority to authorise the upload of all used seeds that are locally stored in their phone (illustrated in Figure 8), as well as the creation and expiry times of the seeds. Note, the server in the decentralised architecture only gets the seeds associated with a single identified user. This is to be compared with the centralised architecture where the complete contact list (with TempIDs) of all encountered individuals is uploaded to the server.

Figure 8: Decentralised tracing app tracing process
Figure 9: Hybrid tracing app architecture

2.2.4 The contact tracing process

Contrary to the centralised architecture, the tracing process in the decentralised architecture is performed locally by the app user on their device (instead of the central server). The app users can communicate with the server, typically once per day, to download any seeds uploaded by infected users. Given such seeds are downloaded (step 8 in Figure 8), the user’s app then reconstructs all the corresponding chirps (using pseudorandom calculations based on the seeds and discrete-time intervals between the start and expiry time). Finally, the app performs a lookup to check if any of the reconstructed chirp information appears in its local encounter chirp log. If so, proximity and duration times are then derived (based on timestamps and RSSI values) for risk analysis purposes. No human intervention is required.

2.3 Hybrid

In the centralised architecture, the server performs all the complex tasks, e.g., TempID calculations, encryption, decryption, risk analysis, and notifications of alerts for the at-risk contacts. On the other hand, all these functionalities are delegated to devices in the decentralised architecture, keeping the server only as a bulletin board for lookup purposes. The hybrid architecture proposes that these functionalities are split between the server and the devices. More specifically, the TempID generation and management remain decentralised (i.e., handled by devices) to ensure privacy and anonymisation, whilst the risk analysis and notifications should be the responsibility of the centralised server. There are three main reasons for performing the tracing process at the server; i) In the decentralised architecture, the server is unaware of the number of at-risk users as the devices make this risk analysis without taking the server into the loop. Thus, the server does not have any statistical information and is unable to run any data analytics to identify exposure clusters. ii) Risk analysis and notifications are considered as a sensitive process that should be handled by the authorities keeping the existing infrastructure resources and state of the pandemic in mind. iii) The uploaded encounter information from infected users is not made available to the other users but retained only at the server. This is to avoid user de-anonymisation attacks (details in Section 5.6) possible in the decentralised architecture.

Figure 10: Hybrid tracing app registration process

Figure 9 shows the interaction sequence in the hybrid architecture based on the Desire protocol [14]. This protocol requires the user’s app registration process to assign a unique device ID without recording any PII. Devices then cryptographically generate and exchange Ephemeral IDs with other devices over BLE. For each received EphID, two un-linkable Private Encounter Tokens (PETs) are generated and stored to represent an encounter. Once a user is tested positive, a list of the locally generated PETs is uploaded to the server. Any device can now send their second generated PET tokens to the server, which then performs risk analysis and notification. The server cannot infer any identifying information from the PETs, and all communication between the server and devices is routed through a proxy or anonymisation network. More details on the hybrid architecture’s key processes are now given.

2.3.1 Installation and registration

The registration process in the hybrid architecture requires a two-step authentication process, phone number verified by OTP, and app verified through an authorisation token issued by the server. Figure 10 shows the process. As the server is not allowed to store any PII, it deletes the phone number after verification. The server then assigns the app a unique ID and generates an encryption key that is sent to the app. The server then deletes the encryption key. The client, in the future, will identify itself using this ID.

2.3.2 Generating and exchanging Ephemeral IDs

In the operation phase, the device generates a new Ephemeral ID (EphID) using the Diffie Hellman key exchange mechanism [DH], which is valid for typically 15 min and synchronised with the Bluetooth MAC address rotation interval. The device starts broadcasting this EphID (= ) through Bluetooth. Once an EphID is received from another device (say with exponent b), the app generates two PETs {PET1 = , PET2 = . The app maintains two tables, referred to as upload and query tables. One PET is stored in the query table, and the other one, along with the time and duration of the contact, is stored in the upload table.

Figure 11: Hybrid tracing app encounter process
Figure 12: Hybrid tracing app notification process

2.3.3 Uploading Encounter data

Once a user is diagnosed with COVID-19, explicit consent is required for the data upload. The user uploads ID, encryption key, and PETs in the upload table along with time and duration values (steps 1-3 Figure 12). The server records these PET values and associated data and uses the encryption key to update the user record (status).

2.3.4 Contact tracing process

Any user who wants to check their risk exposure to an infected case uploads the PETs in the query table to the server by using a proxy or anonymisation network (step 5 Figure 12). The server performs risk analysis by matching the PETs from the query table with the PETs uploaded by the infected user. Using the time and duration values, the server evaluates whether the user is at-risk or not. Any at-risk user is notified through the app to contact the health authority. Note that the server is not able to identify any user based solely on their PET values.

2.4 Architecture summary

We have discussed the three base architectures employed for developing applications for contact tracing purposes. The architectures are categorised based on the functionality and level of privacy preservation at the central server. In the centralised architecture, the server manages the security keys, generation of anonymous IDs, contact risk analysis, and notification processes. All these roles are transferred to the devices in the decentralised architecture while the server acts simply as a bulletin board. The hybrid architecture tries to balance the load on the server and improve privacy preservation by splitting functionalities between the end-user device and the server. One distinct advantage of using an architecture that pushes the risk analysis and notification process to the centralised server (i.e., both centralised and hybrid architectures) is that health officials can decide the rate of notifications depending on the pandemic circumstances (e.g., the availability of test kits). On the other hand, decentralised and hybrid architectures aim to keep the user identities secret from the central server. A server security breach in this latter architecture would, therefore, result in lower information leakage.

3 Data Management, Privacy and Security

Data management in tracing applications refers to the life cycle of data covering three distinct phases: i) Registration, ii) Operation and iii) Positive case identification phases. It encompasses the following questions:

  • What data is produced and by whom?

  • What data is exchanged between whom and when?

  • What data is stored where and by whom?

  • Who can access what piece of data?

In this section, we will first discuss the data life cycle for the three architectures described in Section 2 and then focus on the privacy and security issues associated with these architectures. We consider three key stakeholders in the attack ecosystem; i) government ii) administrator controlling the central server (referred to as server for brevity) iii) malicious users. All architectures assume that health authorities333Health authorities include health officials, testing centres, and allied facilities managing COVID-19. already know the real identities of all positive cases as all uploads are authorised through the health authorities to prevent fake data being uploaded.

Storage Registration phase Operation phase Positive case identification phase
Server Phone Number, Name, Generates and stores List and contact details of all
Age range, ZIP code TempIDs for each user i) positive cases
ii) close contacts of each positive case
Devices - Own TempID & Phone model -
Encounter messages received from contacts
(TempIDs of contact, time stamp, RSSI
TxPower, Phone model)
Table 1: Data storage for centralised tracing architecture
Storage Registration phase Operation phase Positive case identification phase
Server - - Seeds (and validity period) received from all positive cases
Devices - Generates own seeds and chirps Seeds for all positive cases received from the server
Chirps received from contacts, Generates chirps based on seeds/validity period of positive cases
time stamp, RSSI
Table 2: Data storage for decentralised tracing architecture

3.1 Data management

Details of data storage in the centralised architectures, appear in Table 1. The server is responsible for i) storing PII collected when a user registers, ii) generating, storing and transferring the TempIDs to all registered users periodically (after every 15 min for example) and iii) maintaining a list of all individuals who are diagnosed as positive and their close contacts. In contrast, the user devices, after receiving the TempID from the server, carry out the following two tasks: i) generate, exchange, and store the contacts it has had with peers for a specified period of time, usually of 21 days, and ii) upon request, share contact data it has stored with the server with the consent of the user.

Data storage details for the decentralised architectures are presented in Table 2. The user devices are responsible for generating the hourly seed and computing the chirps based on the seed and the current time. In addition, they are responsible for exchanging and storing these chirps, the RSSI, and the received timestamp information with peers. There is also the option for the device to store additional metadata, such as location information. The server plays a limited role compared to the centralised architecture. It is only called into action when a user is diagnosed as COVID-19 positive and voluntarily uploads the seeds and time validity data as described in Section  2.2.2. This data, stored at the server, can now be used for lookup by other users who have come in contact with the infected user, by reconstructing the chirps using the seeds.

Storage Registration phase Operation phase Positive case identification phase
Server Device ID Device ID Stores PETs (and validity period) received from all positive cases
Stores metadata about positive cases
Stores query PETs from other users
Devices Device ID, Generates and store own EphID -
Encryption key Maintain two tables of PETs
Stores timestamp, duration
and signal strength for PETs
Table 3: Data storage for hybrid tracing architecture

Table 3 shows data storage during the various phases of hybrid tracing architecture. In the operation phase, the devices store all encounters as PET entries in two different tables. The server records the device IDs (with blank metadata such as risk score, notified or not, etc.). The server only obtains the PETs from users who have tested positive and volunteers to upload this information. Another significant difference compared to decentralised architecture is that these PETs are not transferred to other devices, rather other devices upload their PETs from their query table for a risk analysis to be carried out by the server.

3.2 Privacy

The success of any automatic contact tracing app depends on several factors, such as: how seamlessly and accurately it can capture close contacts. Another factor is the confidence the users have about their privacy and security when using the app. A naive approach for contact tracing could be to develop a privacy-agnostic system that advertises and exchanges the mobile phone numbers of the participants and periodically registers their location with a centralised server [53]. Such an application would raise serious privacy concerns, and would likely not be accepted by users. Therefore, all the architectures have privacy protection built-in. However, the amount of protection provided differs considerably and depend on the attack models, trust assumptions, and the protection measures they adopt [Fraunhofer].

In the previous section, we discussed the data management aspects highlighting the source and storage of different types of data in the three architectures. From the privacy perspective, we classify the data that is to be stored into three categories: i) PII of participants (e.g., names, phone numbers, tested positive or not, etc.) ii) Contact advertisement messages (pseudonyms exchanged between devices) iii) Social/proximity graph, an indication of the interaction between users and people they came in close contact. Each data category has different privacy implications.

We first explore the privacy implications from the perspective of the smartphone, which is typically less secure than a server. In this case, attacks like theft or coercion (a user being forced or persuaded) will result in the content stored in the smartphone being revealed. This type of threat is present in all of the architectures. However, the difference between the different architectures is what is stored on the smartphones (see Tables 1, 2, 3). Data such as details of encounter messages that may be stored at the devices is considered to be less sensitive as this information cannot be used directly to identify the contacts.

In a centralised architecture, the servers have access to all three types of data. Therefore, if the people who have access to the servers are malicious or the server is compromised, the privacy of users will be compromised as it will be possible to identify all individuals and their contacts. Hence, centralised architectures need to provide adequate protection of the servers to ensure guarantees of user privacy.

In the decentralised architecture, all users can access the public server to download the list of seeds and calculate the chirps used by an infected user. However, as these seeds are uploaded together with their expiry periods, they can result in the unauthorised identification of infected individuals using other side-channel information. For example, malicious persons/apps/organisations can keep collecting the ephemeral identifiers, and the seeds from reported cases and link the identifiers/chirps with the accessed auxiliary information. Also, as only an infected user uploads seeds to the server, a traffic analysis attack, launched by a malicious user who can eavesdrop, would be able to identify a COVID-19 positive user uploading seeds to the server. These attacks are discussed further in section 5.

The hybrid architecture adopts additional advanced privacy enhancement methods such as secret sharing [56], decisional Diffie-Hellman (DDH) [ddh], and private set intersection [PSI]444Readers are encouraged to follow the provided references for details of these privacy preserving secret sharing techniques.. In general, a user’s secret is shared by the user and the server. Furthermore, part of the infection risk analysis is computed at the server using privacy preserving secret sharing. Therefore, compromising of one party cannot reveal/decrypt the entire secret or the risk analysis result. These privacy enhancement methods help protect the identity of infected users from being revealed by malicious users or compromised servers. However, these enhanced privacy protections still cannot prevent the users’ PII getting de-anonymised if a malicious user can successfully access data collected from side-channel context information.

3.3 Security

The notion of security encompasses limiting an adversary’s abilities to introduce false negatives and false positives in the system, in addition to ensuring system integrity and availability. The motivation for carrying out an attack varies and can range from political and ideological to financial. In the context of contact tracing, an attacker may aim to inject erroneous entries or cause a denial of service conditions.

As all three architectures discussed in this article involve a centralised server, it is pertinent to explore the specific security threats for each of the architectures. The potential security threat depends on what data originates from a server, what data is shared and accessible to a server and in what form the data is collected and stored (e.g., pseudonymous, encrypted, unencrypted). Furthermore, it depends on the modus operandi of the server, namely whether it is i) A trusted server, ii) An honest-but-curious server, iii) A compromised/malicious server, or iv) A colluding server.

A malicious/compromised server can disrupt all types of communications or inject false exposure notifications in all architectures. Similarly, a colluding server can liaise with other malicious entities to perform user de-anonymisation.

In the centralised architecture, the server is considered trusted. It is responsible for storing users’ PII and managing security keys used to encrypt/decrypt TempIDs. This poses the risk of data theft if the server gets compromised, a general threat against any centralised server. In this context, the server application needs to run in a trusted environment and use appropriate authentication and access control mechanisms. All information exchanged between the server and the user’s smartphone as well as between the server and the health officials need to be authorised and secure. Thus, centralised architectures only consider malicious users in their attack models and aims to keep the information of all users secure to prevent loss of users’ privacy as described in Section 5.6. This ensures that no malicious third party can access any information sent/received or exfiltrate information. However, malicious users in centralised architectures could exploit the un-authenticated BLE contact information exchanged between devices to spread incorrect contact information by relaying or replaying. These type of attacks, discussed further in Section 5.1, would result in false positives during the contact tracing process forcing users to be in-correctly notified as close contacts.

Decentralised and hybrid architectures, on the other hand, assume an honest-but-curious server that performs all the tasks assigned to it and passively harvests sensitive data, if available. The attack model considers the government and the server to be untrustworthy and only reveals the user identities to the health authorities. As mentioned earlier, the primary user concern relates to the government using the data for purposes other than contact tracing. Therefore, these architectures aim to hide the user identities and generate anonymous IDs at the devices, thereby preventing the ability of the server to map IDs to user information. The decentralised architecture delegates data management to the users’ smartphones, making the solution more robust against a single point of failure/attack, such as the central server. However, the decentralised architecture still requires a minimally functioning central server. Therefore, it will be vulnerable to a much lower number of server-based attacks. In decentralised architectures, anonymous IDs are uploaded to the server, which are then potentially accessible by other smartphones for matching. Thus an honest-but-curious server will not be able to learn any PII, link the anonymous IDs or build social graphs unless it has access to some side-channel information. In case of a data breach, there will be no impact as the attackers only have access to the seeds/tokens of infected users, which are already public. A malicious user, on the other hand, can still cause false positives by relaying the chirps and launch Denial of Service (DoS) attacks by broadcasting fake but correctly formatted advertisements.

The hybrid architecture carries out the contact risk analysis and notification processes at the server. This prevents any re-identification/de-anonymisation attacks, as discussed in Section 5. In addition, the hybrid architecture provides additional mechanisms to hide user identities from the server while enabling centralised matching of contacts. Similar to the decentralised architectures, it proposes the generation of ephemeral IDs at the devices. The rationale is that devices keep full control over their secret identifiers, making them less susceptible to breaches at the server.

4 Proximity Estimation

The chance of COVID-19 infection increases with prolonged and close contact with an infected person. Hence, estimation of distance, a.k.a proximity is an important piece of information along with the duration of the contact to assess the potential spread of infection. Contact tracing apps aim to record such encounters. A smartphone-based automated contact tracing system can mainly utilise two (sensor) technologies: GPS and Bluetooth for proximity estimation555We note that WiFi can also be used for limited proximity estimation [54]. However, it requires the necessary infrastructure support and setup.. GPS used in navigation systems can provide reasonably accurate location information within the margin of errors, especially when used outdoors. However, the storage of absolute location information comes with privacy costs if transferred to the server. Also, GPS is not suitable for proximity estimation in COVID apps for several reasons. i) GPS performs poorly in heavy build-up outdoor spaces such as CBD; ii) GPS does not generally work indoors and, when it works, provides very low accuracy; iii) It has high power consumption and can drain the mobile battery rapidly if used for a prolonged period.

The Bluetooth interface present in most modern mobile phones allows capturing the Received Signal Strength Indicator (RSSI) values aiding the proximity estimation task. The wireless signal emitted from a transmitter decays/attenuates as it travels through the air. Equation 1 shows this behaviour where the average (in dBm) at a distance from the transmitter is given by

(1)

where is the average RSSI (in dBm) at the reference distance of 1m, and is the path loss exponent [50]. The receiver can approximately estimate how far away the transmitter is by recording the RSSI values. However, there are several issues with proximity estimation solely based on RSSI values. The wireless signal can be influenced by several factors other than distance. The objects in the operating environment666Some of the environmental factors are captured by variation in the path loss exponent . such as furniture, walls, people, etc. in the path between a sender and a receiver impacts the signal attenuation. Other wireless signals using the same frequency may also cause interference and further attenuate the signal. Besides, different mobile phones transmit Bluetooth signals with different power levels, affecting the distance estimation [rssi]. Finally, transmission pattern from the same phone varies based on the phone’s orientation (antenna to be precise) and the presence or absence of a phone case. These effects can be somewhat mitigated by calibrating the RSSI values/signal attenuation based on known transmit powers.

To summarise, with the techniques used by current apps for proximity estimation, there would still be many false positives and false negatives. The proximity estimate may indicate close contact, whereas the actual contact is far off or erroneously indicates that it is far off while it is nearby. Similarly, a close contact as perceived by distance estimation does not always translate into an exposed case as there may be a wall/obstruction between the two individuals (e.g., two adjacent apartments), or the contact has occurred in open space where chances of infection are lower. However, getting false positives is not as disastrous, as they only result in additional tests for these false cases. False negatives are a more significant issue as these are considered a missed opportunity to register contact with a positive case. However, we believe that the data from these apps would help health professionals make better decisions in conjunction with other context information obtained during the interview.

5 Attacks

In this section, we will cover some of the possible attacks that can be launched against different app architectures.

5.1 Replay/Relay attack

For these attacks, the goal of an adversary is to force the users to store misleading contact information, resulting in false positives. This is achieved by forwarding any received message from honest users at the same or a different location. The adversary requires minimum resources to launch this attack but may use directional antennas for relaying to extend the area of its influence further. A relay/replay attack is the simplest of the attacks that can be launched against users of a tracing app. An adversary can capture the advertised message by a user and immediately relay the captured message at the same location extending the range of the message or replay it at another location later on. Note that we classify an attack in this category if the replayed/relayed message has a valid ID (the TempID or chirp); otherwise, it is categorised as a DoS attack (discussed later in Section 5.5).

In the centralised systems, since the TempID has a short expiry time, Bluetrace recommended 15 min; the replay attack can be launched before the expiry of the advertised TempID. If any person who has received this replay message tests positive, the originator will be identified as a close contact of the affected person (false positive) and may be asked to get tested. A more focused attack is also possible if the replay attack is executed near an epidemic testing clinic or a treatment ward/hospital. Individuals, already diagnosed with COVID-19, thus, register the originators’ replayed messages as a close contact.

The decentralised version has marked differences in behaviour when viewed with the lens of replay/relay attacks. The chirp generation mechanism, as discussed in Section 2.2.2, involves using seed that is valid for 1 hour. The current timestamp randomises the chirps with 1-minute precision. Finally, the receiver also records the time at which each chirp is received. During the tracing process, described in Section 2.2.4, the app validates the received timestamp of each stored chirp with the time of the creation of each reconstructed chirp, only accepting the received chirp as valid if these two times approximately match. This mechanism thus provides safeguard against the replay attack. Theoretically, it can still be launched within 1 minute expiry time of the chirp message. Relay attacks can still be effective as these are not delayed, resulting in valid chirps.

For the case of hybrid architecture, it is still possible to launch relay attacks, as symmetric information would still exist in the PET tables maintained by two hosts with a malicious relay. However, the replay attacks are not possible as only one of the users would receive the replayed EphID, and the calculated PETs would only exist at the receiver of the replayed message. If that receiver tests positive, the uploaded replayed PETs would not match with any other PET.

Another difference between the centralised and the decentralised architectures w.r.t. the replay attack is the scope of the victim. In the centralised version, the victim is the originator (a single person) of the message being replayed while in the decentralised version, victims are the multiple recipients of the replayed message. If the originator tests positive, he/she will upload the seeds to the server (see Section 2.2.3). The recipients of the replay messages will identify themselves as close contact with the originator by comparing the originator’s uploaded encounter chirps. On the other hand, in the centralised version, if any person who has received the replay/relay message tests positive, the originator is falsely identified as a close contact. On the other hand, the relay attack has the same purview in all architectures, affecting both the originator and the recipient of the relayed encounter message.

5.2 Wireless device tracking

The attacker’s goal in this type of attack is to track the device by the BLE information broadcast by the COVID-19 tracing apps. Consider a shopping mall that wants to track the general movement pattern of its customers. It can deploy BLE nodes, like Apple’s iBeacons, strategically in the entire shopping centre, passively listening for the advertisements from tracing apps. These nodes can send the captured BLE messages to a central tracking server for further processing. The tracking server can now use simple triangulation [63] and timestamps to estimate the location of each device. This enables tracking, even recording how much time each customer (device) spends in each store.

For apps that use the centralised architecture, TempIDs, and phone model information can be used to identify a device uniquely. Since TempIDs are changed after a short time (typically 10-15min), tracking a device beyond the point where the device starts advertising a new TempID would require extra intelligence to link the two different TempIDs (also see Section 5.8) to the same device, advertising the same phone model. In the decentralised architecture, chirps with 1 minute lifetime provide limited opportunity for tracking. The tracking server can still enumerate the total number of users in the area, but it is hard to track the movement of a device without a phone model except for corner cases such as a few customers or a stationary target. Hybrid architectures behave like the centralised architecture as the devices advertise EphID with a lifetime of 15 minutes, making it possible to track a device based on EphIDs.

5.3 Location confirmation

In this attack, the attackers’ goal is to discover the presence of a user in a known location/environment, such as a neighbourhood. The BLE advertisements and information contained in the exchange of encounter messages in the centralised architecture can be used for confirmation of a user’s location. Assume Alice is the only one in her family that owns an iPhone 9, and this is known to an adversary Eve. Eve can confirm whether Alice is at home or not by listening to the encounter messages that have the phone model information. One simple way to mitigate this issue is to include the mobile model number in the registration process. This way, the server still has the required model number information for proximity calculations (see Section 4) while the phone model number can now be excluded from the encounter messages. The location confirmation attack is not possible in the decentralised and hybrid architectures due to the use of ephemeral chirps/IDs and suppressing any user/device linking information.

5.4 Enumeration attack

The primary goal of this attack is to count the number of users who have tested positive. Enumeration refers to any app user’s ability to estimate the number of positive test cases that have volunteered to upload their contact tracing data to the server. Note that enumeration does not include the server’s ability to count the number of positive cases. In the centralised architecture, the information of positive cases and their close contacts remains with the server, and that does not allow any user to enumerate.

Figure 13: Encoding chirps into a Bloom Filter.

In the decentralised architecture, each positive case uploads all of their seed used during the last 21 days (21 days x 24 seeds per day = 504 seeds). All app users can download the list of all seeds from the server and can estimate the number of positive cases. One option to conceal this information is to calculate all the chirps at the server and store these in a bloom filter ([Boston] and Section 6.2.5). This bloom filter (see Figure 13) is then retrieved by the apps to check any match of their contact chirps without revealing other details. The enumeration attack can also be mitigated, in the decentralised architecture, if the infected user is provided with the capability to redact some contact information while uploading their contacts. Enumeration attacks are also not possible in the hybrid architecture as the server conceals the list of infected user IDs from other users.

5.5 Denial of service

The goal of this attack is to consume the resources (battery, bandwidth, processing, etc.) available in the system (user mobile, server). In this regard, we discuss the issue of an adversary injecting bogus encounter messages/chirps in the contact tracing environment. This is done with the following possible malafide intentions:

  • Consume mobile device storage and battery (All three architectures)

  • Cause upload of these bogus messages to the server once a user tests positive (centralised and hybrid only)

  • Increase processing time at the server (centralised and hybrid only)

  • Increase processing time at the mobile device (more profound in decentralised as all chirps (including the bogus one’s) need to be compared with the reconstructed chirps)

Figure 14: Linkage attack for decentralised architecture.

Note that in the centralised version, the server will process the bogus encounter messages but will discard these because of the validity check by the server. On the other hand, for the decentralised version, there is no way to check the validity of the received chirp as long as it is correctly formatted.

5.6 De-anonymising the users/Linkage attack

In this attack, a user aims to de-anonymise another user’s identity by correlating the anonymous broadcast data with information gathered through side-channels, i.e., linking the anonymous ID with the user identity also called linkage attack. Most of the contact tracing apps have been designed with the privacy of the data and the user in mind. However, in the decentralised architecture, it is still possible to identify users once they test positive to the epidemic. Figure 14 presents the steps required to launch the attack. Consider user A of a decentralised app that records the details of his encounters with other persons (day/time/duration/location/gender, etc.) (step 5). If this user receives an alert (step 6) by comparing the reconstructed chirps (step 7), by looking at the time stamp (and duration) of the chirps and comparing his collected records (step 8), the user can easily identify the infected user. Some of this malicious record keeping can also be made automatically by a modified app collecting location information using GPS/WiFi etc.

For the centralised architecture, it is possible to de-anonymise the close contacts, but it is hard to de-anonymise a positive case since an app user is not provided with a list of TempIDs for comparison. A positive case can still be identified, if a user is in isolation and only met one person and then receives a notification of close contact. TempIDs can be easily associated with a user by looking at the advertised mobile model number. The time duration of contact and an isolated encounter will increase the chances of linking TempIDs with a particular user. Similarly, a Sybil attack [douceur2002sybil] can also be launched whereby an attacker can deploy multiple devices and only use a single device for a short time. Now, if the user receives a notification from the server on one of the devices, he can narrow the linkage attack to a short time window when that device was active.

An attacker can launch another kind of linkage attack called a Paparazzi attack [62] [61] in the decentralised apps using passive BLE devices. When a user tests positive, the server receives the seeds, which are, in turn, send to the users, including the attacker. The attacker reconstructs chirps and combines these data with that obtained from the passive BLE devices. It can then track the positive case throughout the contagion period. Similar to the Paparazzi attack, attackers can trace infected users by deploying a large number of passive BLE devices while colluding with the server. This is termed as Orwell attack [6].

Besides, hybrid protocols are generally considered un-linkable as these do not share the PETs from infected users to other users and perform the risk-analysis/notification similar to the centralised version.

5.7 Abuse of app

The goal of this attack is to mislead the tracing app with information produced through wrong app usage. All tracing apps, whether based on centralised, decentralised, or hybrid architecture, are prone to user abuse. A recent Google maps experiment is referred to where a user carted 99 mobile phones on an empty road, and Google maps showed high congestion [GmapsHack]. On the same lines, a tracing app cannot recognise if the phone is being carried by someone else or tied to a pet running in the park [oxymoron].

New measures could be introduced to circumvent these activities, such as using other sensors on the phone to record activity/gait recognition. However, from the privacy perspective, more contextual or personal data being captured may result in lowering privacy guarantees.

5.8 Carryover attack

This attack is supplementary to the device tracking attack discussed in 5.2. An attacker aims to continue the device tracking period beyond the anonymous ID expiration time. Most of the current devices randomise their Bluetooth MAC addresses to avoid device tracking. The temporary identifiers (TempIDs and chirp) also get changed after a short time. Address carryover attack [9] is possible when the changeover time of Bluetooth MAC address and the temporary identifier is not synchronised. For example, let us assume that the TempID gets changed every 15 min, while the Bluetooth MAC changes every 10 min. A listener can easily link the multiple Bluetooth MAC addresses advertised within the lifetime of the same TempID. Conversely, a TempID change can be linked to the same Bluetooth address. Full synchronisation of temporary ephemeral identifiers and the Bluetooth random MAC address change is proposed in some of the apps. The changeover synchronisation, however, requires support from the OS Bluetooth module.

Note that even when the changeover of multiple identifiers is fully synchronised, a careful listener can still link different Bluetooth addresses (or temporary IDs) for wireless tracking by analysing the disappearance of an identifier and its immediate replacement by a new one. However, for our vulnerability analysis of apps (in Section 6), we do not consider this case.

5.9 Disclosure of social graph

A social graph illustrates the interaction between individuals by representing the individuals as nodes and edges between individuals if they are in close proximity. An attacker can build the social graph by mining the available data to infer the contact profiles for users. Disclosure of the social graph or even a part of it is undesirable, though some countries like India have done so despite concerns from civil societies. Both centralised and decentralised systems are vulnerable to disclosure of (partial) social graph.

In a decentralised system, if a malicious server wants to know if an infected user A and a target user B were in contact, then it sends the seeds uploaded by A along with some other fake seeds to B. Now, by using a side-channel, if it observes that B has received an alert or gone into isolation, then it can say that A and B had been in contact. In the centralised architecture, positive cases can choose to upload their contacts to the server. A malicious server can construct part of the social graph (positive cases and their close contacts) because it knows the mapping between the TempIDs and individuals. Construction of a complete social graph is impossible unless the server is powerful enough to control the communication network and later perform huge data mining tasks. In any of the discussed architectures, it is to be noted that a malicious server cannot disclose the interaction between individuals who are neither tested positive nor have been in contact with other positive patients. Theoretically, an attacker could steal several phones and possibly correlate symmetric encounters across users.

To hide the social graph construction by the server, apps from the centralised and hybrid categories have introduced additional measures (such as random, independent upload of contact identifiers/EphIDs, maintaining separate upload and query identifiers, etc.). These measures will be discussed in Section 6 when we explore different protocols and apps in detail.

6 Analysis of Specific Apps and Protocols

Figure 15: Summary of apps and protocols.

In the above, we have discussed the salient features, capabilities, and exposure to different kinds of attacks for the three broad architectures that have been proposed for contact tracing applications. In this section, we delve into the instantiation of these architectures and introduce various tracing apps and protocols that are being proposed, developed, and deployed in many countries. We divide this discussion into three sections, each covering a different system architecture. To keep the discussions concise, we only focus on the salient features of each app/protocol and highlight any additional measures introduced on top of the corresponding base architecture. Figure 15 illustrates the protocols and the apps discussed in this section. Additionally, we provide an attack matrix (Table 4) that highlights possible attacks on each app/protocol that is part of our discussion.

6.1 Apps/Protocols based on centralised architecture

In Section 2, we explained the centralised architecture that was based on the Bluetrace [8] protocol. ROBERT [2] is a similar protocol that relies on a centralised architecture. We will provide an overview of TraceTogether (Singapore) [48] and CovidSafe (Australia) [20] apps which are based on the Bluetrace protocol and the StopCovid (France) app [3] which implements the ROBERT protocol. The Aarogya Setu (India) is another instantiation of the centralised architecture and uses both Bluetooth and GPS.

6.1.1 TraceTogether

The TraceTogether app launched by the Singaporean government in March 2020, was amongst the first contract tracing apps deployed to the general public. The source code of the reference implementation, OpenTrace has been released in the public domain [48]. We only detail one additional BlueTrace protocol feature that has been implemented in the TraceTogether app but was omitted in the centralised architecture description presented in Section 2. The server issues forward-dated TempIDs to each device instead of a single TempID. This is to ensure that each device has a supply of valid TempIDs even when the Internet connection is unstable.

6.1.2 CovidSafe (AU)

CovidSafe was released by the Australian government on 26th April 2020, with the source code for both Android and iOS clients released on 8th May 2020 [covidSafe-Source]. Covid-Safe follows the Bluetrace protocol and thus CovidSafe and TraceTogether exhibit many similar characteristics, including vulnerability to the different types of attacks listed in Table 4.

The two apps differ in the lifeTime of TempIDs. TraceTogether uses a value of 15 minutes as recommended in the BlueTrace protocol specifications, while CovidSafe employs 2 hours. This makes CovidSafe more vulnerable to replay attacks. The relative advantage of CovidSafe over TraceTogether is that the devices do not have to download TempIDs frequently. Another difference between the two apps is in the backend infrastructure. While TraceTogether uses Google Cloud to provide the backend services, CovidSafe makes use of Amazon AWS servers that are located within Australia.

6.1.3 StopCovid - ROBERT

ROBust and privacy-presERving proximity Tracing protocol (ROBERT) is a centralised tracing app protocol, that is jointly developed by researchers at INRIA (France) and Fraunhofer (Germany) [2]. The StopCovid app, which is under development in France at the time of this writing and expected to be available in June 2020, will use the ROBERT protocol. The source code for StopCovid app is already available [stopCovid-Source].

The main difference between the BlueTrace and ROBERT protocols is the type of user data that is stored on the server. While the former stores PII, the latter only stores anonymous identifiers referred to as EphIDs, thus providing a level of privacy. The protocols also differ in the notification process, i.e., how the at-risk users are notified. ROBERT requires all users to frequently check their used EphIDs with the server to determine if they were flagged to be at-risk. In contrast, in BlueTrace, the health authorities would proactively notify at-risk users. The notification process is possible because BlueTrace can map the TempIDs to the collected personal information.

In ROBERT, a positively identified user uploads the EphIDs in a staggered and random order. This is in contrast to the BlueTrace protocol, where all contacts are uploaded in one go. This is done to break the link of all contacts with the same person and to prevent social graph analysis by the server. However, analysing the network traffic exchanged by a device may potentially allow an adversary to link the reports together.

6.1.4 Aarogya Setu

Aarogya Setu is an app deployed in India based on the centralised architecture. The code for their Android app has been released (iOS and server code not yet available) on 26th May 2020 [43]. In addition to collecting PII and contact data, this app also gathers location data (GPS coordinates) and self-assessment data (responses provided by an individual to the self-assessment test) [42]. It performs data analytics on the gathered information to indicate how many positive cases are in a radius of 500m to 10km from a user’s current location. Users can upload the trace data if they are COVID-19 positive, or they fail the self-assessment test. In contrast to other apps, the government of India has made it mandatory for all government employees and those living in disease containment zones to install the Aarogya Setu app.

6.2 Apps/Protocols based on decentralised architecture

In this section, we first briefly discuss the Apple/Google alliance for providing APIs and OS-level support for privacy-preserving contact tracing. Next, we provide a short review of the Private Automated Contact Tracing (PACT) protocol by MIT [53], which was used as the basis for describing the decentralised system architecture in Section 2.2. Another protocol sharing the same name, PACT (Privacy-sensitive protocols And mechanisms for mobile Contact Tracing), developed by a team from the University of Washington [15], is also discussed. To distinguish the two PACT protocols, we use the nomenclature: “PACT West-coast” (by UoW) and “PACT East-coast” (by MIT). Other contact tracing protocols including DP-3T [28], TCN [19], Hamagen [35], COVID Safe Paths [29] and Pronto-C2 [6] are also covered in this section.

6.2.1 Apple/Google Exposure Notification APIs

Apple and Google [Apple, Google] have joined hands to support privacy-preserving contact tracing by developing an exposure notification system. Their proposed tracing mechanism matches with the decentralised architecture described earlier in Section 2.2. Their system was planned to be rolled out into two phases. In the first phase, APIs have been released on 20th May 2020 to support apps developed by health authorities to work seamlessly on iOS and Android devices. This promises to help manage issues related to BLE scanning and advertisements as faced by current apps [8]. Apps built on top of Apple and Google recently released APIs can use the proposed Associated Encrypted Metadata (AEM) during the exposure notification service. AEM is privacy-preserving encrypted metadata that includes transmit power to aid in better proximity estimation results.

In the second phase, Apple/Google plan to incorporate OS-level support to help broader adaptation by eliminating the need for an app to perform contact tracing. An app called SwissCoviD, discussed later in Section 6.2.4, was released on 25th May 2020 for pilot testing by the DP-3T team [28] that is based on these APIs. Another project named Aurora [aurora] is under development by the PathCheck team to utilise the APIs developed by Apple/Google. Moreover, many of the existing apps, including some from the centralised category, have already started exploring ways to migrate their existing code base to the APIs released by Apple/Google.

6.2.2 PACT (East-coast)

The PACT (East-coast) protocol design was used as the basis to explain the decentralised architecture, including installation, encounter exchange, and tracing process in Section 2.2. A research collaboration led by MIT [1] developed this protocol.

In addition to locally stored seed data (used to generate chirps) and chirp data (including received time and its signal strength), the PACT (East-coast) also allows the user to optionally store extra metadata, such as location information, in its local log file while receiving a chirp. The location data can help determine the place of contact, for example, a restaurant or a park etc. This optional metadata can help reduce false positives and increase the system accuracy by involving more context information.

6.2.3 CovidSafe - PACT (West-coast)

Privacy-sensitive protocols And mechanisms for mobile Contact Tracing - PACT (West-coast) [15] is a tracing protocol proposed by researchers from the University of Washington. The core mobile tracing function takes a very similar process compared to the baseline decentralised systems (PACT East-coast), where all personal data are locally stored (and encrypted) on the phone, devices broadcast pseudorandom IDs, and it is voluntary for a user to publish/upload the data. PACT (West-coast) adopts a different key-based generation mechanism to generate the pseudorandom ID used for broadcasting. A 128-bit key is initially fed into the pseudorandom generator, and a 256-bit length output is generated (take SHA-256 as an example). The half-length of that result (128-bit) is used as the temporary pseudorandom ID within a specified period and the other half is used as the input for the next pseudorandom generator. This key-chain design saves storage, storing fewer seeds than the PACT (East-coast). Afterwards, those pseudorandom IDs are broadcast and collected similar to the PACT (East-coast).

Like all decentralised protocols, PACT (West-coast) is also susceptible to the Linkage, and Enumerations attacks (discussed in Section 5) as the seeds from infected users are uploaded to the server and later on shared with all users. CovidSafe (UoW) app [47], for which the beta version has been released in May 2020, is based on the PACT (West-coast) protocol.

6.2.4 SwissCoviD - DP-3T

Decentralised Privacy-Preserving Proximity Tracing (DP-3T) [28] is a protocol specification based on the decentralised architecture proposed by a consortium of universities and organisations from Europe led by EPFL, Switzerland. A pilot app named SwissCovid [55] has been released on 25th May, 2020777This is the first official release that is based on APIs developed by Apple/Google. There are two versions covered in the specifications, we explain the ‘low cost’ version here, while the other ‘un-linkable’ version is covered in the next section.

The protocol is very similar in functionality to base decentralised architecture discussed earlier (Section 2.2). A daily key is generated by each device, using the hash-chain from the previous daily key, and then used to generate the EphIDs. Messages are exchanged with other devices which come in contact over Bluetooth containing these EphIDs with expiry information and coarse time (date). The exchanged data remains in the local storage until a user tests positive. Health officials determine the contagious window, i.e., during what time a positive case was contagious and might have infected others. Identified users only upload their daily keys starting from this date. Once data is uploaded, the infected user changes their random key for generating future daily keys to prevent future tracking/identification. Other users download the daily keys uploaded by the infected user and compare their stored EphIDs with EphIDs reconstructed from the infected person’s daily keys. The risk analysis process is thus performed locally on individual devices. The app notifies the user if they are found to be in close contact and asks for permission to upload their daily keys.

6.2.5 DP-3T Unlinkable

DP-3T specification document [28] also has a second version called ’Un-linkable’ design. This design is in response to the claims that the decentralised design is subject to Linkage and Enumeration attacks, discussed in Section 5, as the daily keys for infected users are made available to all other devices.

The primary change in this design is that the daily keys uploaded by infected users are converted into their corresponding EphIDs by the server. The server hashes these values in a Cuckoo filter [cuckoo] before advertising these to the other users. The users can still check whether their received EphIDs, that are cryptographically hashed with the received time, matches any entry in the Cuckoo filter or not. The user cannot access other information, including how many or which other EphIDs have been encoded in the Cuckoo filter.

The processing time at the server increases as compared with the low-cost version of DP-3T. Also, the Cuckoo filter needs to be carefully designed to minimise the chances of false positives, while false negatives are not possible in the Cuckoo filter. This design also enables a user to selectively upload encounters (by suppression/redaction of some encounters) in the upload phase.

Another proposed feature is to use k-out-of-n secret sharing to minimise the chances of EphIDs collection for contact duration of very short period, contacts of very short duration will be eventually screened out at risk analysis phase. Contact has to collect at least k advertisements to reconstruct an EphID successfully. This restricts the effective EphIDs to contacts that are made for sufficient duration.

6.2.6 CovidWatch - TCN

Researchers from Stanford University and Waterloo University developed Covid-Watch [58]. At the time of writing this article, the app is still in a pilot phase. The source code is publicly available [64] and it follows the TCN (Temporary Contact Number) Coalition protocol [19].

The TCN protocol generates the keychain, such that each key (same as seed) derived from the master key generates one unique temporary contact number (same as chirp). Like other decentralised protocols, TCN only uploads the compact seed data (the Master key, the expiry time, etc.) to the server rather than the entire list of TCNs. All seeds that belong to a report can be proved/verified by the server as they are generated and bound to the same master key. The malicious entities can potentially launch the linkage attack (see Section 5.6) to find out the linkable TCNs by observing multiple TCNs from the reports that use the same master key. Therefore, frequent master key rotation can be performed to make TCNs un-linkable from different reports. However, this increases the number of keys that need to be maintained, raising the issue of scalability. An app thus needs to consider the trade-off between scalability and linkability while selecting the master key rotation period.

6.2.7 Pronto-C2

Researchers from the University of Salerno, Italy proposed the Pronto-C2 contact tracing system [6]. It is a decentralised app that lets the devices communicate anonymously with each other while hiding these communications from the central server to avert mass surveillance.

At the heart of the protocol are two cryptographic tools Diffie Hellman (DH) Key exchange [DH] discussed in Section 2.3 and blind signatures [16]. A secret and the ephemeral ID are generated by Alice’s device and stored in the server. The address is noted by the device where its generated ephemeral ID is stored on the server (this storage can also be realised using a blockchain). The device broadcasts this address and receives addresses from other devices in its vicinity. This is contrary to decentralised designs that share ephemeral IDs. Alice stores the tuple when it receives the from Bob. Here is the secret key from the previous update , and contains auxiliary information like BLE signal strength, time, etc.

If Alice tests positive, she fetches the ephemeral ID of each contact from her contact list. For a contact Bob, she receives using the . Alice calculates which is the DH key between herself and Bob, and a key . She then sends the (blinded) information of to an authentication server, which appends a blind signature to . The signature prevents DoS attacks and ensures that the authorisation server cannot perform social graph analysis.

A user who wishes to test their risk can download the ephemeral IDs from their contact list in address . They then compute the DH key between themselves and the ephemeral ID at . It computes . downloads the recently available keys (of infected individuals) from the server and checks if belongs to this set. If a match is found, then the user is at risk. The devices communicate with the server using anonymous channels like TOR to prevent linking ephemeral keys to users.

6.2.8 Hamagen

The Hamagen application is developed by Israel’s Ministry of Health. Hamagen is different from many other contact tracing applications in that it does not rely on recording encounters with other phones in the vicinity using Bluetooth. The application cross-checks the GPS history of a mobile phone with the historical geographical data of identified cases from the Ministry of Health. The check is conducted on the individual’s mobile phone locally. Each individual’s location data does not leave their device, and neither is it sent to a third party. The app will periodically, currently set to hourly, download a file containing an anonymised list of locations that were visited by cases diagnosed with COVID-19 over the past 14 days. This file is sourced from the Ministry of Health and populated with information of those people who have undergone epidemiological investigation by the various tools at the Ministry’s disposal. The application then cross-references these locations (including timestamps) with the location data stored locally on the individual’s device. Should the application discover that there is a possibility that the individual has been at the same place and at the same time as a diagnosed case, a notification is shown on the phone with the details of the location and times where the individual may have been exposed to a positive case. The phone user has the option to review the notification. If the message is perceived to be incorrect, e.g., if the user was not at the noted location at the stated time, the user can indicate that the information is false. If the user confirms their presence at the contact location, they are directed to the Ministry of Health’s website for information on what to do next.

The application must be given access to the location history (GPS data) of the phone and the list of cellular base stations and WiFi access points encountered over the past two weeks. This information is stored in SQLite. The app also requires Internet access to periodically download an updated file from the Ministry of Health server. The application source code has been developed using React Native and is open-source on GitHub 

[35].

6.2.9 COVID Safe Paths

The PathChecks team [pathCheck] has developed this app and its source code for Andriod and iOS is publicly available [29]. The app is similar to the Hamagen in functionality as it also employs logging of GPS location trajectories. A browser-based map tool called “Safe Places” has also been released that can interact with the Safe Paths app. The diagnosed users can voluntarily share their location trails with the health authorities using the Safe Places map tool. Other users can download the anonymised and aggregated data sets of public locations to check whether they have come in contact with an identified individual, without uploading their path trajectories.

6.3 Apps/Protocols based on hybrid architecture

Hybrid protocols (Section 2.3) have been proposed to combine features of both centralised and decentralised architectures. We discuss three reference protocols in this section, DESIRE [14], ConTra Corona [10] and EpiOne [60].

6.3.1 Desire

The explanation of the hybrid architecture in Section 2.3 is based on the DESIRE protocol specification [14]. The use of cryptographically generated PETs gives users more control while keeping these different from the advertised EphIDs. This avoids the potential harvesting of contact data for social graph analysis. All data stored at the server is encrypted with keys which are stored at the clients. This protects the client data in case the server has a data breach.

The risk analysis and notification are handled by the server (instead of the clients as in case of decentralised versions), which limits the likelihood of other users launching Enumeration and Linkage attacks.

6.3.2 ConTra Corona

ConTra Corona[10] is a hybrid protocol proposed by German researchers from FZI Research Center for Information Technology and Karlsruhe Institute of Technology. Contra Corona improves privacy protection by mitigating the linkage attacks that can be launched on the decentralised apps. This is achieved by adopting a DDH key-exchange mechanism to verify the process of data upload for a person diagnosed to be infected. Additionally, Contra Corona proposes strict server separation by employing three different servers; the submission server, the matching server, and the notification server.

The Contra Corona proposal is significantly different from the base hybrid architecture (based on the DESIRE protocol). However, the underlying assumptions are the same. Devices generate their IDs, and the centralised server(s), are responsible for the risk-analysis and notification process.

Section Tracing Replay/ Wireless Location Enumeration DoS Linkage Carryover Social
No. Apps & Protocols Relay tracking confirmation graph
6.1.1 Trace Together Easy
(BlueTrace)
6.1.2 CovidSafe (AU) Easy
(BlueTrace)
6.1.3 StopCovid
(ROBERT)
6.1.4 Aarogya Setu Easy
6.2.2 PACT (East coast) Limited Replay Difficult
Relay
6.2.3 CovidSafe (UoW) Limited Replay Difficult
(PACT-West Coast) Relay
6.2.4 SwissCovid - DP-3T Difficult
(low cost)
6.2.5 DP-3T Difficult
(unlinkable)
6.2.6 CovidWatch Difficult
(TCN)
6.2.7 Pronto-C2
6.2.8 Hamagen
6.2.9 COVID Safe Paths
6.3.1 DESIRE Relay only Difficult
6.3.2 ConTra Corona Difficult
6.3.3 EpiOne
Table 4: Possible Attacks on Tracing Apps and Protocols 888Abuse of the app (Section 5.7) is common for all apps/protocols, hence not shown in Table 4. denotes not enough information is available

Each user generates a warning identifier () for each day based on their real identifier (e.g., name). For each , the device computes 96 ’s (regarded as seed identifiers) encrypted with the submission server’s public key and (pseudorandom identifier encrypted and hashed based on ). and are uploaded to the submission server. Initially, the submission server collects all users’ pairs. Once the submission server has accumulated sufficient client pairs, it shuffles these and then sends them to the matching server (this helps to mitigate the enumeration attack). If the matching server receives a uploaded by one of the infected users, the matching server looks up the respective of all potentially contaminated users and sends them to the notification server. Finally, the notification server decrypts the to recover the user’s warning identifier () and publishes the list. All users regularly fetch the list from the notification server and compare it with the ’s (stored locally) that they have used for the previous 28 days.

Contra Corona protocol utilises n-out-of-k secret sharing of (n is taken as 15 and k as 45) and selects a random identifier (for example, may be taken as the Bluetooth MAC address). A random but never used secret sharing of plus the is broadcast every minute. Users who received and accumulated 15 such broadcasts sharing secret of the same user can reconstruct the of that contact event and further store that contact event on the device.

ConTra Corona’s privacy enhancement is based on the premise that the servers are non-colluding, and all communication channels are anonymised or authenticated. The submission server is assumed to be the most trusted component as it has all the matching pairs of identifiers generated by each user. The additional encryption and randomisation are used to prevent disclosure of infected user’s status to other users. The protocol also involves the health authority to verify the source integrity of the report (uploaded by the infected person) to decrease the false negatives of the system (and also prevent the DoS attack).

6.3.3 EpiOne

EpiOne [60] has been proposed by a team of researchers led by the University of California at Berkeley to protect against linkage and social graph analysis attacks discussed in Section 5. The source code is not available as of the time of writing of this article. At the heart of the protocol is a cryptographic technique known as Private Set Intersection (PSI)[PSI, 18].

At a high level, devices generate and share random IDs (tokens) using a seed. Each device maintains sent and received token lists. If a user tests positive, they upload their seeds through the health officials that are used by the server to construct their sent tokens. A user who wants to check his close contacts and server follow a private set intersection protocol to check if there is an intersection between their received tokens and set of tokens maintained at the server. The user is notified once a match is found. The private set intersection protocol guarantees that neither the user nor the server knows the complete set of tokens preventing social graph analysis.

At a more fundamental level, EpiOne consists of two servers, a collection server with the healthcare officials and an untrusted verification server. Before the start of the protocol, all participants, including the users, healthcare professionals and verification server first agree on the security parameters. The verification server generates a public/private secret key pair and publishes the corresponding public key. Every user can choose a random seed and derive the tokens using input seed, the day, and the time slot within the day. This is useful because the verification server can, later on, reconstruct the token if it knows the corresponding seed.

When users come in contact with each other, they exchange the tokens. The list of tokens sent and received are stored on the mobile device. When a user tests positive, it uploads the encrypted seeds (encrypted with the verification server’s public key) to the collection server maintained by health officials. The health officials, in turn, shuffle the encrypted seeds and send them to the verification server that can decrypt the seeds and reconstructs all the tokens.

A user can find out if it was in close proximity to a positive COVID case by computing securely (using Private set intersection protocol) the cardinality of the intersection between the two sets of tokens. Neither does the server reveal the set of tokens of positive cases (preventing enumeration attack), nor does the user reveal the set of tokens it received from other users (preventing social graph construction).

Architecture Encounter exchanges Downloads from server Data upload to server Processing at device
(Once for a positive case)
Centralised BLE periodic exchange Periodic download Upload all encounter Minimal processing
of short messages of TempIDs messages for the
(TempIDs) (once in 15 min) past 21 days
Decentralised BLE periodic exchange Download of seeds Upload seeds used High processing
of short messages for positive cases for the past device periodically generates
(Chirps) (once in 24 hours) 21 days seeds/chirps
Hybrid BLE periodic exchange - Upload PETs used for High processing
of short messages the past 21 days device periodically generates
(EphIDs) *Upload PETs for risk EphIDs and calculates,
analysis by server two PETs for each EphID
Table 5: Comparison of factors affecting device battery usage

7 Common user concerns

The COVID-19 tracing application has seen increased adoption in many countries; for example, more than 5 million users downloaded the CovidSafe (AU) app within two weeks of its initial release in Australia. Similarly, downloads for the Indian tracing app Aarogya Setu has crossed the 114 million mark. However, there are remaining concerns surrounding these tracing applications. We discussed concerns related to user data privacy and security in Sections 3 and 5. In this section, we discuss several additional user concerns.

7.1 Battery Usage

Excessive battery consumption is a recurring problem for mobile apps. Mobile battery consumption is affected by many factors such as app processor utilisation, frequency, and scale of data management, the number of messages exchanged, etc. Most tracing apps rely on the BLE communication protocol to exchange information with peers, while the apps use regular cellular or Wifi connections to communicate with the servers. The BLE protocol allows the app to exchange a small amount of data with the peers periodically. On the other hand, the communication with the server relies on traditional secure application protocols, e.g., HTTPs. The main impact on the battery utilisation for these protocols is related to the number of information exchanges with the server. Table 5 shows the comparison of different factors that affect mobile battery consumption. For the apps that rely on a centralised architecture, a fixed-sized message is retrieved from the server periodically to get a new TempID.

In contrast, for the decentralised version, there is no periodic data retrieval during the operation stage. Data is only downloaded once the server publishes the seeds uploaded by a positive case. The app nevertheless checks for any new download after every 24 hours. Decentralised apps upload rate is lower compared to the centralised counterparts. In decentralised case, the upload consists of all seeds used during the past 21 days, whereas the centralised apps upload all encounter messages captured in the last 21 days. Centralised apps perform better in terms of processing at the devices as this involves minimal processing compared to the decentralised apps that need to generate and maintain seeds (after every 1 hour) and chirps (after every 1 min). For the hybrid architecture, devices generate EphIDs as well as two PETs for each received EphID. The hybrid apps upload the highest amount of data to the server: PETs from identified positive cases and Query PETs from all other users for the purpose of checking their risk status. On the other hand, download from the server is lower compared to other architectures.

The battery consumption is also affected by the execution aspect, since the app that runs in the foreground demands more power than apps that run in the background. Typically this design choice is dependant on the operating system support for these apps. As a case in point, CovidSafe and TraceTogether IoS apps face these documented issues when the app is running in the background [8]. Google and Apple, the two leading smartphone operating system providers, have teamed up to provide the exposure notification APIs, that improve the tracing application integration with the operating system. These APIs are expected to improve the apps development process and reduce power consumption.

7.2 Compatibility of OS versions and different apps

There are several models of smartphones. Hence, developing an app that works in both new and old models is not a trivial task. These smartphones run different versions of the operating system (OS), Android and iOS being the two dominant OSs. Most of the tracing apps have been developed for the newer OS versions; for example, both TraceTogether and CovidSafe require iOS version 10 or higher. TraceTogether requires Android 5.1 or higher, while CovidSafe works on Android 6.0 or higher. CovidSafe requires the newer OS versions for security reasons and improved Bluetooth capabilities [45].

A secondary concern is cross-app compatibility. Consider a case when a user of an app released for a specific geographic region travels to areas where another app has been deployed. It is not clear how an app would behave if a second tracing app is installed on the same device due to the architectural differences discussed earlier.

7.3 Consent withdrawal

Consent withdrawal refers to the ability of a user to stop participating in the data sharing for the tracing apps. Consent withdrawal provides the necessary guarantee that users can ask to delete their data or eliminate their existence from the tracing app ecosystem whenever they wish. We consider the consent withdrawal process at various stages of operation of a tracing app.

  • Data collection phase: Since the encounter data is only locally stored at the user devices (for a limited period of 21 days for instance), deleting an app implies the removal of all encounter data from the device immediately without transfer of any of these to a server. Additionally, for the centralised architecture, app deletion is assumed to result in the removal of all personal data captured at the registration stage. However, as the encounter data exchange is symmetric, other active users would have encounter messages/chirps stored in their devices for 21 days. Similarly, for the hybrid architecture, if a user withdraws consent and deletes the local data, PETs generated using their broadcasted EphIDs would remain in the local storage of contacts.

  • Data already uploaded to the server: If a user voluntarily uploads the data to the server after testing positive, and subsequently wants to exercise consent withdrawal, can the system support it? In the centralised architecture, the uploaded data consist of encounter information of all close contacts of the positive case. The server processes this data to alert close contacts. As this contact data is not transferred to the close contacts, the server can easily remove the uploaded data as it has already been utilised. In terms of systems, the deletion of such data and providing some sort of receipt or feedback to the user is technically feasible.

    In the case of the decentralised architecture, the consent withdrawal process is more involved as the uploaded seeds from an infected user are made available to other app users for self-checking. If the infected user requests data deletion, the server can remove the stored data, but it is not clear how the seeds already transferred to other devices (and the reconstructed chirps) can be immediately expunged from their devices. These transferred seeds would automatically get removed after 21 days to mitigate this issue. As discussed earlier, the use of bloom filters for encoding hashed chirps at the server could provide an additional level of data protection (Section 5.4). For the hybrid case, if a user withdraws consent after uploading the PETs, the server can remove the PETs as these are not transferred to other users.

  • End of pandemic: Most of the authorities managing tracing apps have indicated that the data collected through these apps would be removed once the system gets de-activated at the end of the pandemic, often referred as the sunset clause, unless a user requests explicit earlier removal of their stored data. However, the end of the pandemic is a very vague term to describe the lifetime of these apps. Proposals such as DP-3T has an automatic mechanism for the removal of data from the server and the clients after a fixed period.

7.4 Transparency

There is a genuine public concern about the nature of information being collected from the user’s smartphone and its usage by various parties. There are two essential approaches to achieving transparency. The first option is to make the source code of the app open. Publishing the app source code improves the transparency and trust in the system, as the implemented privacy and security features can be scrutinised by the research and academic community. This includes the publication of both the app and the server-side code, as they together form the tracing system. Although this is the preferred option, public source code is not a panacea to ensure security. Many risks arise from system configurations and the use of a system that is not readily observable from the source code analysis.

A better approach would be to ensure that the code is subjected to periodic review and trusted third-party audits to verify the functionalities against documented features to ensure that all future versions are compliant with the specifications on privacy and security.

While transparency is a key to wider adoption by the end-users, it is essential to note that ultimately a degree of trust is required in the use of any mobile app. This includes trusting the developers, the independent test and verification team, the operators and owners of the service, and importantly, the companies providing essential infrastructure such as the mobile phone operating systems.

Finally, all functional apps should be accompanied by the Privacy Impact Assessment (PIA) documents. To the best of our knowledge, among the apps that have been covered in this article, only CovidSafe (AU) and DP-3T are accompanied by a PIA [44] [52].

8 Future Directions

The current COVID-19 crisis has started the trend of using a virus tracking app at scale. We could have been better prepared for a pandemic of this proportions if these applications had been in place, fully tried and tested before the onset of the pandemic. There is already a flurry of research activities around the globe to develop the next-generation tracking applications ready for instant deployment should the world face a similar, or potentially even more dangerous pandemic. We consider some future research directions next.

In considering research areas for future tracing applications, it is probably best to consider near-term development, say the next five years, with more “blue sky” type research pushed to post 5-year horizon. For the near-term, we identify the following as some important topics.

  • Improvement in proximity accuracy

    : Current challenges related to proximity accuracy have been highlighted in our earlier discussions. The Bluetooth technology was not designed with location or proximity determination as a critical part of the design process. However, the latest version of BLE released in 2020 has added features which will be helpful for next-generation apps. Additionally, new “Bluetooth-like” protocols should be designed with an emphasis on location/proximity services during the inception phase. Antenna design should be part of this process, allowing for not only distance accuracy but also direction-finding. Indeed, direction-finding is embedded as part of the Bluetooth 5.1 protocol albeit with low accuracy. Currently, no Covid19 tracing app has included such direction capabilities within their proximity analysis. The use of time-of-arrival metrics could also be used as hardware technology improves, and sub-nanosecond timing becomes commonplace within devices. Indeed, several smartphone manufacturers have moved to embed a dedicated Ultra-Wideband (UWB) chipset - specifically with Bluetooth proximity analyses in mind. Compared to the small bandwidth utilised by Bluetooth (2MHz), UWB utilises 500MHz, potentially resulting in cm-type precision for the proximity determination. Research on fusing radio data with other location information garnered from other sensors embedded on the phone, such as location-designed WiFi, Enhanced-GPS, gyroscopes, accelerometers, and magnetometers is promising to improve the proximity accuracy. These sensors could be aided by advances in software solutions such as advanced digital processing for location tracking and artificial intelligence-based algorithms. One can imagine new “proximity” designs specifically aimed at integrating all relevant hardware, software, and protocol design into a single chip.

  • A fully decentralised architecture for infection tracing: One of the “takeaway messages” from the COVID-19 crisis is that privacy concerns have to be addressed for wider adoption by the public. None of the applications we have described above can be considered as encompassing a fully decentralised architecture - they all use a central server to differing degrees, usually under the control of a governing authority. Research on a fully decentralised system using some form of a peer-to-peer network to facilitate privacy-preserving information sharing amongst the user-devices should be pursued.

  • Artificial Intelligence-based algorithms: AI algorithms are increasingly being used as the processing power within phones improves. The use of such algorithms in aiding the decision-making process of infection likelihood is obvious. Via metrics such as true infection identification, missed detections, and false-positive outcomes, the algorithms can become “live” in the sense that they dynamically adapt and self-improve in their reliability and accuracy. We anticipate much research in this area, especially with the integration of AI and the decentralised architecture.

In a post-5-year time scale, research outcomes are harder to predict. Much depends on the hardware development and the emergence of new technologies that are touted to become available. However, perhaps the most exciting of these emerging technologies lies in the quantum arena.

  • Quantum computing [57] is considered by many to be on the threshold of a breakthrough both in development and in commercialisation. Future research on tracing solutions that exploit the use of the exponentially more powerful computing resources afforded by quantum computing should commence now. These could include quantum-based artificial learning algorithms and advanced Monte-Carlo or particle filter type tracking solutions. In this paradigm, information from the phones will be sent to a central quantum computer for processing.

  • Quantum sensing [quantumSensing] is another area of current research that is also touted to bring major advances in the coming years. This technology exploits hypersensitivity embedded in quantum entanglement as a source of improved timing, network synchronisation, accelerometer accuracy, and location accuracy, to name a few. Clearly, all these issues could be brought to the contact tracing arena to maximise the overall performance and efficacy of the applications.

  • Quantum communications [quantumComm] is the most advanced of all the new quantum applications, at least in the sense of deployment. Commercial offerings in the quantum communications area already exist, and proof-of-principle deployment in space has already occurred. The major impact of this technology on tracing applications will likely be in the advanced communications security and enhanced privacy protections it offers. In principle, if properly deployed, security and privacy in future virus-tracking applications will be unconditional – hacking and unauthorised access to virus-tracking data will be made obsolete.

9 Conclusions

The COVID-19 pandemic continues to affect the way of life of everyone. The contact tracing apps are likely to play a vital role in aiding health authorities quickly identify individuals that may have been exposed to the virus. The imminent interest and adoption of tracing app technology will improve the tracing capability of health authorities; however, as this article highlighted, it is not a silver bullet. These apps still face many concerns from users, data protection agencies, and researchers. The main concerns are related to the user data management, potentially non-trivial false positive and negative instances, and the security and privacy issues of these apps. Guided by these concerns, this article presented an overview of the three common tracing app architectures: centralised, decentralised, and hybrid; and an overview of popular apps within these categories. Additionally, the paper focused on the privacy and security aspects, mapping attacks that could be possibly performed in each of the three architectures. This article also elucidates some other users’ concerns regarding battery drain, compatibility, consent withdrawal, and transparency. Finally, we discussed some of the near and long term future research directions.

We note that each architecture has pros and cons, different attack models and protections, varying complexity of implementation, and operating costs. The adoption of a particular architecture, by a government, is based on familiarity with technology, integration with existing tracing processes, and ease of deployment. On the other hand, the adoption of an app by users is voluntary. The users have their due concerns regarding the privacy and security of their PII collected through these apps. The adoption rate by users can be increased significantly if complete transparency and legislative guarantees against misuse of data originating from this ecosystem can be assured by the authorities.

We also highlight that government agencies and service providers such as ISPs, and large corporations such as Apple/Google can already track people by using traditional apps and technologies such as WiFi connections, the cellular communication tower areas, GPS navigation apps and a whole range of cameras deployed across cities. Since many users already install a myriad of apps on their phones or smart watches (games, social media, etc.) without knowing the security/privacy implications, installing a tracing app that primarily aims at helping in a noble cause of keeping the community safe from spreading the COVID-19 disease, in the opinion of the authors, should not cause undue concern.

We hope that this article will aid the research community to understand various technological and cybersecurity aspects of tracing apps and help users and agencies to make a more informed decision about the voluntary adoption of an app offered in their geographical areas.

Acknowledgements

The work has been supported by the Cyber Security Research Centre Limited (CSCRC) whose activities are partially funded by the Australian Government’s Cooperative Research Centres Programme.

References

  • [1] (2020) Note: https://pact.mit.edu/ Cited by: §6.2.2.
  • [2] (2020) Note: https://github.com/ROBERT-proximity-tracing/document Cited by: §6.1.3, §6.1.
  • [3] (2020) Note: https://www.euronews.com/2020/04/29/coronavirus-french-mps-approve-covid-19-tracing-app-despite-privacy-concerns Cited by: §6.1.
  • [4] F. AISEC (2020) Pandemic contact tracing apps: dp-3t, pepp-pt ntk, and robert from a privacy perspective. Note: Cryptology ePrint Archive, Report 2020/489https://eprint.iacr.org/2020/489 Cited by: §3.2.
  • [5] Apple (2020) Privacy preserving contact tracing. Note: https://www.apple.com/covid19/contacttracing Cited by: §6.2.1.
  • [6] G. Avitabile, V. Botta, V. Iovino, and I. Visconti (2020) Towards defeating mass surveillance and sars-cov-2: the pronto-c2 fully decentralized automatic contact tracing system. Note: Cryptology ePrint Archive, Report 2020/493https://eprint.iacr.org/2020/493 Cited by: §5.6, §6.2.7, §6.2.
  • [7] B. Barrett (2020) An artist used 99 phones to fake a google maps traffic jam. Note: https://www.wired.com/story/99-phones-fake-google-maps-traffic-jam/ Cited by: §5.7.
  • [8] J. Bay, J. Kek, A. Tan, C. S. Hau, L. Yongquan, J. Tan, and T. A. Quy (2020) BlueTrace: a privacy-preserving protocol forcommunity-driven contact tracing across borders. Note: https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf Cited by: §2.1, §6.1, §6.2.1, §7.1.
  • [9] J. K. Becker, D. Li, and D. Starobinski (2019) Tracking anonymized bluetooth devices. Proceedings on Privacy Enhancing Technologies 2019 (3), pp. 50–65. Cited by: §5.8.
  • [10] W. Beskorovajnov, F. Dörre, G. Hartung, and et. al (2020) ConTra corona: contact tracing against the coronavirus by bridging the centralized–decentralized divide for stronger privacy. Note: Cryptology ePrint Archive, Report 2020/505, https://eprint.iacr.org/2020/505 Cited by: §6.3.2, §6.3.
  • [11] D. Boneh (1998) The decision diffie-hellman problem. In Algorithmic Number Theory, Berlin, Heidelberg, pp. 48–63. External Links: ISBN 978-3-540-69113-6 Cited by: §3.2.
  • [12] X. Bonnetain and et al. (2020) Anonymous tracing, a dangerous oxymoron, a risk analysis for non-specialists. Note: https://tracing-risks.com/docs/tracing-risks.pdf Cited by: §5.7.
  • [13] R. Canetti, A. Trachtenberg, and M. Varia (2020, arXiv 2003.13670v4) Anonymous collocation discovery: harnessing privacy to tame the coronavirus. External Links: 2003.13670v4 Cited by: §5.4.
  • [14] C. Castelluccia, N. Bielova, A. Boutet, and et al (2020) DESIRE: a third way for a european exposure notification system leveraging the best of centralized and decentralized systems. Technical report hal-02570382. External Links: Link Cited by: §2.3, §6.3.1, §6.3.
  • [15] J. Chan, S. Gollakota, E. Horvitz, J. Jaeger, S. Kakade, T. Kohno, J. Langford, J. Larson, S. Singanamalla, J. Sunshine, et al. (2020) Pact: privacy sensitive protocols and mechanisms for mobile contact tracing. arXiv preprint arXiv:2004.03544. Cited by: §6.2.3, §6.2.
  • [16] D. Chaum (1983) Blind signatures for untraceable payments. In Advances in Cryptology, D. Chaum, R. L. Rivest, and A. T. Sherman (Eds.), Boston, MA, pp. 199–203. Cited by: §6.2.7.
  • [17] P. Check (2020) Project aurora: a new open source solution for the google apple exposure notification api. Note: https://covidsafepaths.org/a-new-open-source-solution-for-the-google-apple-exposure-notification-api/ Cited by: §6.2.1.
  • [18] H. Chen, K. Laine, and P. Rindal (2017) Fast private set intersection from homomorphic encryption. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017, pp. 1243–1255. External Links: Link, Document Cited by: §6.3.3.
  • [19] T. Coalition TCN protocol for decentralized, privacy-preserving contact tracing. Note: https://github.com/TCNCoalition/TCN Cited by: §6.2.6, §6.2.
  • [20] COVIDSafe COVIDSafe. Note: https://github.com/AU-COVIDSafe Cited by: §6.1.
  • [21] C. Criddle and L. Kelion (2020) Coronavirus contact-tracing: world split between two types of app. Note: https://www.bbc.com/news/technology-52355028 Cited by: §1.
  • [22] E. De Cristofaro and G. Tsudik (2010) Practical private set intersection protocols with linear complexity. In International Conference on Financial Cryptography and Data Security, pp. 143–159. Cited by: §3.2, §6.3.3.
  • [23] C. L. Degen, F. Reinhard, and P. Cappellaro (2017) Quantum sensing. Reviews of modern physics 89 (3), pp. 035002. Cited by: 2nd item.
  • [24] W. Diffie and M. E. Hellman (Nov, 1976) New directions in cryptography. IEEE Transactions on Information Theory. 22 (6), pp. 644–654. Cited by: §2.3.2, §6.2.7.
  • [25] J. R. Douceur (2002) The sybil attack. In International workshop on peer-to-peer systems, pp. 251–260. Cited by: §5.6.
  • [26] DTA (2020) Covid safe. Note: https://github.com/AU-COVIDSafe Cited by: §6.1.2.
  • [27] J. Duball (2020) Centralized vs. decentralized: eu’s contact tracing privacy conundrum. Note: https://iapp.org/news/a/centralized-vs-decentralized-eus-contact-tracing-privacy-conundrum/ Cited by: §1.
  • [28] C. T. et.al. DP-3t. Note: https://github.com/DP-3T Cited by: §6.2.1, §6.2.4, §6.2.5, §6.2.
  • [29] R. R. et.al. COVID-safepaths. Note: https://github.com/Path-Check/covid-safe-paths Cited by: §6.2.9, §6.2.
  • [30] B. Fan, D. G. Andersen, M. Kaminsky, and M. D. Mitzenmacher (2014) Cuckoo filter: practically better than bloom. In Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies, pp. 75–88. Cited by: §6.2.5.
  • [31] P. Farrell (2020) Experts raise concerns about security of coronavirus tracing app covidsafe. Note: https://www.abc.net.au/news/2020-05-14/experts-concerned-about-coronavirus-tracing-covidsafe-security/12245122 Cited by: §1.
  • [32] P. C. Foundation (2020) COVID safe paths. Note: https://covidsafepaths.org/ Cited by: §6.2.9.
  • [33] Google (2020) Exposure notification api. Note: https://www.google.com/covid19/ exposurenotifications/ Cited by: §6.2.1.
  • [34] L. Guoquan, G. Enxu, Y. Zhouyang, X. Yongjun, and P. Yu. (2018) Indoor positioning algorithm based on the improved rssi distance model. Sensors 18 (9), pp. . Cited by: §4.
  • [35] Hamagen Israel’s ministry of health’s covid-19 exposure prevention app.. Note: https://github.com/MohGovIL/hamagen-react-native/blob/master/README.md Cited by: §6.2.8, §6.2.
  • [36] INRIA (2020) StopCovid 19. Note: https://gitlab.inria.fr/stopcovid19 Cited by: §6.1.3.
  • [37] R. Jennings (2020) What are the data privacy considerations of contact tracing apps?. Note: https://ukhumanrightsblog.com/2020/05/01/what-are-the-data-privacy-considerations-of-contact-tracing-apps/ Cited by: §1.
  • [38] C. Kuhn, M. Beck, and T. Strufe (2020) Covid notions: towards formal definitions – and documented understanding – of privacy goals and claimed protection in proximity-tracing services. Note: https://arxiv.org/abs/2004.07723 Cited by: §1.
  • [39] J. Li and X. Guo (2020) COVID-19 contact-tracing apps: a survey on the global deployment and challenges. Note: https://arxiv.org/abs/2005.03599 Cited by: §1.
  • [40] A. Manzalini (2020) Quantum communications in future networks and services. Quantum Reports 2 (1), pp. 221–232. Cited by: 3rd item.
  • [41] P. H. O’Neill, T. Ryan-Mosley, and B. Johnson (2020) A flood of coronavirus apps are tracking us. now it’s time to keep track of them. Note: https://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/ Cited by: footnote 2.
  • [42] M. of Electronics and I. Technology Notification of the aarogya setu data access and knowledge sharing protocol. Note: https://meity.gov.in/writereaddata/files/Aarogya_Setu_data_access_

    References

    • [1] knowledge_Protocol.pdf 2020 Accessed: 2020-05-18 @misc{setu2, author = {\relax Ministry of Electronics and \relax Information Technology}, title = {Notification of the Aarogya Setu data access and knowledge sharing protocol}, howpublished = {\url{https://meity.gov.in/writereaddata/files/Aarogya\_Setu\_data\_access\_ knowledge\_Protocol.pdf}}, year = {2020}, lastaccessed = {Accessed: 2020-05-18}}
    • O’NeillPatrick HowellRyan-MosleyTateJohnsonBobbieA flood of coronavirus apps are tracking us. now it’s time to keep track of themhttps://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/2020Accessed: 2020-05-15@misc{mit, author = {Patrick Howell O'Neill and Tate Ryan-Mosley and Bobbie Johnson}, title = {A flood of coronavirus apps are tracking us. Now it’s time to keep track of them}, howpublished = {\url{https://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-15}} CriddleCristinaKelionLeoCoronavirus contact-tracing: world split between two types of apphttps://www.bbc.com/news/technology-523550282020Accessed: 2020-05-21@misc{bbc, author = {Cristina Criddle and Leo Kelion}, title = {Coronavirus contact-tracing: World split between two types of app}, howpublished = {\url{https://www.bbc.com/news/technology-52355028}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} DuballJoeCentralized vs. decentralized: eu’s contact tracing privacy conundrumhttps://iapp.org/news/a/centralized-vs-decentralized-eus-contact-tracing-privacy-conundrum/2020Accessed: 2020-05-21@misc{duball, author = {Joe Duball}, title = {Centralized vs. decentralized: EU's contact tracing privacy conundrum}, howpublished = {\url{https://iapp.org/news/a/centralized-vs-decentralized-eus-contact-tracing-privacy-conundrum/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} JenningsRafeWhat are the data privacy considerations of contact tracing apps?https://ukhumanrightsblog.com/2020/05/01/what-are-the-data-privacy-considerations-of-contact-tracing-apps/2020Accessed: 2020-05-21@misc{jennings, author = {Rafe Jennings}, title = {What are the data privacy considerations of Contact Tracing Apps?}, howpublished = {\url{https://ukhumanrightsblog.com/2020/05/01/what-are-the-data-privacy-considerations-of-contact-tracing-apps/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} FarrellPaulExperts raise concerns about security of coronavirus tracing app covidsafehttps://www.abc.net.au/news/2020-05-14/experts-concerned-about-coronavirus-tracing-covidsafe-security/122451222020Accessed: 2020-05-21@misc{farrell, author = {Paul Farrell}, title = {Experts raise concerns about security of coronavirus tracing app COVIDSafe}, howpublished = {\url{https://www.abc.net.au/news/2020-05-14/experts-concerned-about-coronavirus-tracing-covidsafe-security/12245122}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} PalmerDannySecurity experts warn: don’t let contact-tracing app lead to surveillancehttps://www.zdnet.com/article/security-experts-warn-dont-let-contact-tracing-app-lead-to-surveillance/2020Accessed: 2020-05-21@misc{palmer, author = {Danny Palmer}, title = {Security experts warn: Don't let contact-tracing app lead to surveillance}, howpublished = {\url{https://www.zdnet.com/article/security-experts-warn-dont-let-contact-tracing-app-lead-to-surveillance/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} of HealthDepartmentCOVIDSafe application privacy impact assessmenthttps://www.health.gov.au/resources/publications/covidsafe-application-privacy-impact-assessmentAccessed: 2020-05-21@misc{PIACovidSafe, author = {\relax Department of Health}, title = {COVIDSafe Application Privacy Impact Assessment}, howpublished = {\url{https://www.health.gov.au/resources/publications/covidsafe-application-privacy-impact-assessment}}, lastaccessed = {Accessed: 2020-05-21}} of WashingtonUniversityMicrosoftCOVIDSafehttps://covidsafe.cs.washington.edu/t2020Accessed: 2020-05-21@misc{uow-CovidSafe, author = {\relax University of Washington and Microsoft}, title = {COVIDSafe}, howpublished = {\url{https://covidsafe.cs.washington.edu/t}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} DiffieWhitfieldHellmanMartin E.New directions in cryptographyIEEE Transactions on Information Theory.22 (6)644–654Nov, 1976@article{DH, author = {Diffie, Whitfield and Hellman, Martin E.}, title = {New Directions in Cryptography}, journal = {IEEE Transactions on Information Theory.}, volume = {22 (6)}, pages = {644-654}, year = {Nov, 1976}} StanfordCOVID watchhttps://www.covid-watch.org2020Accessed: 2020-05-21@misc{CovidWatch, author = {\relax Stanford}, title = {COVID Watch}, howpublished = {\url{https://www.covid-watch.org}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} WatchCovidCOVID watch sourcecodehttps://github.com/covid19risk/2020Accessed: 2020-06-06@misc{CovidWatchSource, author = {Covid Watch}, title = {COVID Watch Sourcecode}, howpublished = {\url{https://github.com/covid19risk/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-06}} KaafarD.et al.Joint statement on contact tracing.https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/April 19th, 2020Accessed: 2020-05-21@misc{jointstate, author = {D. Kaafar and et al.}, title = {Joint Statement on Contact Tracing.}, howpublished = {\url{https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/}}, year = {April 19th, 2020}, lastaccessed = {Accessed: 2020-05-21}} Anonymous collocation discovery: harnessing privacy to tame the coronavirusCanettiRanTrachtenbergAriVariaMayank2020, arXiv 2003.13670v42003.13670v4arXivcs.CY@misc{Boston, title = {Anonymous Collocation Discovery: Harnessing Privacy to Tame the Coronavirus}, author = {Ran Canetti and Ari Trachtenberg and Mayank Varia}, year = {2020, arXiv 2003.13670v4}, eprint = {2003.13670v4}, archiveprefix = {arXiv}, primaryclass = {cs.CY}} GoogleExposure notification apihttps://www.google.com/covid19/ exposurenotifications/2020Accessed: 2020-05-21@misc{Google, author = {Google}, title = {Exposure notification API}, howpublished = {\url{https://www.google.com/covid19/ exposurenotifications/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} ApplePrivacy preserving contact tracinghttps://www.apple.com/covid19/contacttracing2020Accessed: 2020-05-21@misc{Apple, author = {Apple}, title = {Privacy Preserving Contact Tracing}, howpublished = {\url{https://www.apple.com/covid19/contacttracing}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} OrganizationWorld HealthWHO timeline - covid-19https://www.who.int/news-room/detail/27-04-2020-who-timeline—covid-192020Accessed: 2020-05-25@misc{WHO, author = {\relax World Health Organization}, title = {WHO Timeline - COVID-19}, howpublished = {\url{https://www.who.int/news-room/detail/27-04-2020-who-timeline—covid-19}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} SchmidFranziskaSwiss tracing app goes on trialhttps://ethz.ch/en/news-and-events/eth-news/news/2020/05/swiss-covid-app.html2020Accessed: 2020-05-26@misc{swissCovid, author = {Franziska Schmid}, title = {Swiss tracing app goes on trial}, howpublished = {\url{https://ethz.ch/en/news-and-events/eth-news/news/2020/05/swiss-covid-app.html}}, year = {2020}, lastaccessed = {Accessed: 2020-05-26}} SapiezynskiP.StopczynskiA.WindD. K.LeskovecJ.JørgensenS. L.Inferring person-to- person proximity using wifi signalsACM on Interactive, Mobile, Wearable and Ubiquitous Technologie2017ACM@inproceedings{WiFi, author = {P. Sapiezynski and A. Stopczynski and D. K. Wind and J. Leskovec and S. L. Jørgensen}, title = {Inferring Person-to- person Proximity Using WiFi Signals}, booktitle = {ACM on Interactive, Mobile, Wearable and Ubiquitous Technologie}, year = {2017}, publisher = {ACM}, pages = {}} RedmilesElissa M.User concerns & tradeoffs in technology-facilitated contact tracinghttps://arxiv.org/abs/2004.132192020Accessed: 2020-05-25@misc{Redmiles, author = {Elissa M. Redmiles}, title = {User Concerns \& Tradeoffs in Technology-Facilitated Contact Tracing}, howpublished = {\url{https://arxiv.org/abs/2004.13219}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} LiTianshiYangJackieFaklarisCoriKingJenniferYuvraj AgarwalLaura DabbishHongJason I.Decentralized is not risk-free: understanding public perceptions of privacy-utility trade-offs in covid-19 contact-tracing appshttps://arxiv.org/abs/2005.119572020Accessed: 2020-05-25@misc{LFFK, author = {Tianshi Li and Jackie Yang and Cori Faklaris and Jennifer King and Yuvraj Agarwal, Laura Dabbish and Jason I. Hong}, title = {Decentralized is not risk-free: Understanding public perceptions of privacy-utility trade-offs in COVID-19 contact-tracing apps}, howpublished = {\url{https://arxiv.org/abs/2005.11957}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} LiJinfengGuoXinyiCOVID-19 contact-tracing apps: a survey on the global deployment and challengeshttps://arxiv.org/abs/2005.035992020Accessed: 2020-05-25@misc{LG20, author = {Jinfeng Li and Xinyi Guo}, title = {COVID-19 Contact-tracing Apps: a Survey on the Global Deployment and Challenges}, howpublished = {\url{https://arxiv.org/abs/2005.03599}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} TangQiangPrivacy-preserving contact tracing: current solutions and open questionshttps://arxiv.org/abs/2004.068182020Accessed: 2020-05-25@misc{T20, author = {Qiang Tang}, title = {Privacy-Preserving Contact Tracing: current solutions and open questions}, howpublished = {\url{https://arxiv.org/abs/2004.06818}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} KuhnChristianeBeckMartinStrufeThorstenCovid notions: towards formal definitions – and documented understanding – of privacy goals and claimed protection in proximity-tracing serviceshttps://arxiv.org/abs/2004.077232020Accessed: 2020-05-25@misc{KBS20, author = {Christiane Kuhn and Martin Beck and Thorsten Strufe}, title = {Covid Notions: Towards Formal Definitions – and Documented Understanding – of Privacy Goals and Claimed Protection in Proximity-Tracing Services}, howpublished = {\url{https://arxiv.org/abs/2004.07723}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} of HealthDepartmentCOVIDSafe legislationhttps://www.ag.gov.au/RightsAndProtections/Privacy/Pages/ COVIDSafelegislation.aspx2020Accessed: 2020-05-25@misc{regulation1, author = {\relax Department of Health}, title = {COVIDSafe Legislation}, howpublished = {\url{https://www.ag.gov.au/RightsAndProtections/Privacy/Pages/ COVIDSafelegislation.aspx}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} The sybil attackDouceurJohn RInternational workshop on peer-to-peer systems251–2602002Springer@inproceedings{douceur2002sybil, title = {The sybil attack}, author = {Douceur, John R}, booktitle = {International workshop on peer-to-peer systems}, pages = {251–260}, year = {2002}, organization = {Springer}} AISECFraunhoferPandemic contact tracing apps: dp-3t, pepp-pt ntk, and robert from a privacy perspectiveCryptology ePrint Archive, Report 2020/4892020https://eprint.iacr.org/2020/489@misc{Fraunhofer, author = {Fraunhofer AISEC}, title = {Pandemic Contact Tracing Apps: DP-3T, PEPP-PT NTK, and ROBERT from a Privacy Perspective}, howpublished = {Cryptology ePrint Archive, Report 2020/489}, year = {2020}, note = {\url{https://eprint.iacr.org/2020/489}}} RappaportTheodoreWireless communications: principles and practice2001ISBN 0130422320Prentice Hall PTRUSA2nd@book{rappaport, author = {Rappaport, Theodore}, title = {Wireless Communications: Principles and Practice}, year = {2001}, isbn = {0130422320}, publisher = {Prentice Hall PTR}, address = {USA}, edition = {2nd}} Bluetooth positioning using rssi and triangulation methodsWangYapengYangXuZhaoYutianLiuYueCuthbertLaurie2013 IEEE 10th Consumer Communications and Networking Conference (CCNC)837–8422013IEEE@inproceedings{triangulation, title = {Bluetooth positioning using RSSI and triangulation methods}, author = {Wang, Yapeng and Yang, Xu and Zhao, Yutian and Liu, Yue and Cuthbert, Laurie}, booktitle = {2013 IEEE 10th Consumer Communications and Networking Conference (CCNC)}, pages = {837–842}, year = {2013}, organization = {IEEE}} BarrettBrianAn artist used 99 phones to fake a google maps traffic jamhttps://www.wired.com/story/99-phones-fake-google-maps-traffic-jam/2020Accessed: 2020-05-25@misc{GmapsHack, author = {Brian Barrett}, title = {An Artist Used 99 Phones to Fake a Google Maps Traffic Jam}, howpublished = {\url{https://www.wired.com/story/99-phones-fake-google-maps-traffic-jam/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} Cuckoo filter: practically better than bloomFanBinAndersenDave GKaminskyMichaelMitzenmacherMichael DProceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies75–882014@inproceedings{cuckoo, title = {Cuckoo filter: Practically better than bloom}, author = {Fan, Bin and Andersen, Dave G and Kaminsky, Michael and Mitzenmacher, Michael D}, booktitle = {Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies}, pages = {75–88}, year = {2014}} BonnetainXavieret al.Anonymous tracing, a dangerous oxymoron, a risk analysis for non-specialistshttps://tracing-risks.com/docs/tracing-risks.pdf2020Accessed: 2020-05-29@misc{oxymoron, author = {Xavier Bonnetain and et al.}, title = {Anonymous tracing, a dangerous oxymoron, A risk analysis for non-specialists}, howpublished = {\url{https://tracing-risks.com/docs/tracing-risks.pdf}}, year = {2020}, lastaccessed = {Accessed: 2020-05-29}} research groupLSTSCorona appshttps://lsts.research.vub.be/en/corona-apps2020Accessed: 2020-06-2@misc{lsts, author = {\relax LSTS research group}, title = {Corona Apps}, howpublished = {\url{https://lsts.research.vub.be/en/corona-apps}}, year = {2020}, lastaccessed = {Accessed: 2020-06-2}} GuoquanLiEnxuGengZhouyangYeYongjunXuYu.PangIndoor positioning algorithm based on the improved rssi distance modelSensors18 (9)2018@article{rssi, author = {Li Guoquan and Geng Enxu and Ye Zhouyang and Xu Yongjun and Lin Jinzhao, and Pang Yu.}, title = {Indoor Positioning Algorithm Based on the Improved RSSI Distance Model}, journal = {Sensors}, volume = {18 (9)}, pages = {}, year = {2018}} of ElectronicsMinistryTechnologyInformationAarogya setuhttps://github.com/nic-delhi/AarogyaSetu_Android2020Accessed: 2020-06-2@misc{setu-Source, author = {\relax Ministry of Electronics and \relax Information Technology}, title = {Aarogya Setu}, howpublished = {\url{https://github.com/nic-delhi/AarogyaSetu\_Android}}, year = {2020}, lastaccessed = {Accessed: 2020-06-2}} INRIAStopCovid 19https://gitlab.inria.fr/stopcovid192020Accessed: 2020-06-5@misc{stopCovid-Source, author = {\relax INRIA}, title = {StopCovid 19}, howpublished = {\url{https://gitlab.inria.fr/stopcovid19}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} CheckPathProject aurora: a new open source solution for the google apple exposure notification apihttps://covidsafepaths.org/a-new-open-source-solution-for-the-google-apple-exposure-notification-api/2020Accessed: 2020-06-5@misc{aurora, author = {Path Check}, title = {Project Aurora: A New Open Source Solution for the Google Apple Exposure Notification API}, howpublished = {\url{https://covidsafepaths.org/a-new-open-source-solution-for-the-google-apple-exposure-notification-api/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} FoundationPath CheckCOVID safe pathshttps://covidsafepaths.org/2020Accessed: 2020-06-5@misc{pathCheck, author = {Path Check Foundation}, title = {COVID Safe Paths}, howpublished = {\url{https://covidsafepaths.org/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} DTACovid safehttps://github.com/AU-COVIDSafe2020Accessed: 2020-06-1@misc{covidSafe-Source, author = {\relax DTA}, title = {Covid Safe}, howpublished = {\url{https://github.com/AU-COVIDSafe}}, year = {2020}, lastaccessed = {Accessed: 2020-06-1}} How to share a secretShamirAdiCommunications of the ACM2211612–6131979ACM New York, NY, USA@article{secretSharing, title = {How to share a secret}, author = {Shamir, Adi}, journal = {Communications of the ACM}, volume = {22}, number = {11}, pages = {612–613}, year = {1979}, publisher = {ACM New York, NY, USA}} Practical private set intersection protocols with linear complexityDe CristofaroEmilianoTsudikGeneInternational Conference on Financial Cryptography and Data Security143–1592010Springer@inproceedings{PSI, title = {Practical private set intersection protocols with linear complexity}, author = {De Cristofaro, Emiliano and Tsudik, Gene}, booktitle = {International Conference on Financial Cryptography and Data Security}, pages = {143–159}, year = {2010}, organization = {Springer}} BonehDanThe decision diffie-hellman problemAlgorithmic Number Theory1998Springer Berlin HeidelbergBerlin, Heidelberg48–63ISBN 978-3-540-69113-6@inproceedings{ddh, author = {Boneh, Dan}, title = {The Decision Diffie-Hellman problem}, booktitle = {Algorithmic Number Theory}, year = {1998}, publisher = {Springer Berlin Heidelberg}, address = {Berlin, Heidelberg}, pages = {48–63}, isbn = {978-3-540-69113-6}} Photonic quantum information processing: a concise reviewSlussarenkoSergeiPrydeGeoff JApplied Physics Reviews640413032019AIP Publishing LLC@article{quantumComputing, title = {Photonic quantum information processing: A concise review}, author = {Slussarenko, Sergei and Pryde, Geoff J}, journal = {Applied Physics Reviews}, volume = {6}, number = {4}, pages = {041303}, year = {2019}, publisher = {AIP Publishing LLC}} Quantum communications in future networks and servicesManzaliniAntonioQuantum Reports21221–2322020Multidisciplinary Digital Publishing Institute@article{quantumComm, title = {Quantum Communications in Future Networks and Services}, author = {Manzalini, Antonio}, journal = {Quantum Reports}, volume = {2}, number = {1}, pages = {221–232}, year = {2020}, publisher = {Multidisciplinary Digital Publishing Institute}} Quantum sensingDegenChristian LReinhardFCappellaroPaolaReviews of modern physics8930350022017APS@article{quantumSensing, title = {Quantum sensing}, author = {Degen, Christian L and Reinhard, F and Cappellaro, Paola}, journal = {Reviews of modern physics}, volume = {89}, number = {3}, pages = {035002}, year = {2017}, publisher = {APS}}
    Cited by: §6.1.4.
  • [43] M. of Electronics and I. Technology (2020) Aarogya setu. Note: https://github.com/nic-delhi/AarogyaSetu_Android Cited by: §6.1.4.
  • [44] D. of Health COVIDSafe application privacy impact assessment. Note: https://www.health.gov.au/resources/publications/covidsafe-application-privacy-impact-assessment Cited by: §7.4.
  • [45] D. of Health COVIDSafe help. Note: https://www.health.gov.au/resources/apps-and-tools/covidsafe-app/covidsafe-help Cited by: §7.2.
  • [46] D. of Health (2020) COVIDSafe legislation. Note: https://www.ag.gov.au/RightsAndProtections/Privacy/Pages/ COVIDSafelegislation.aspx Cited by: §2.1.4.
  • [47] U. of Washington and Microsoft (2020) COVIDSafe. Note: https://covidsafe.cs.washington.edu/t Cited by: §6.2.3.
  • [48] OpenTrace OpenTrace. Note: https://github.com/opentrace-community Cited by: §6.1.1, §6.1.
  • [49] D. Palmer (2020) Security experts warn: don’t let contact-tracing app lead to surveillance. Note: https://www.zdnet.com/article/security-experts-warn-dont-let-contact-tracing-app-lead-to-surveillance/ Cited by: §1.
  • [50] T. Rappaport (2001) Wireless communications: principles and practice. 2nd edition, Prentice Hall PTR, USA. External Links: ISBN 0130422320 Cited by: §4.
  • [51] E. M. Redmiles (2020) User concerns & tradeoffs in technology-facilitated contact tracing. Note: https://arxiv.org/abs/2004.13219 Cited by: §1.
  • [52] L. research group (2020) Corona apps. Note: https://lsts.research.vub.be/en/corona-apps Cited by: §7.4.
  • [53] R. L. Rivest, J. Callas, R. Canetti, and et al. (April, 2020) The pact protocol specifications. Technical report 0.1, pp. . External Links: Link Cited by: §2.2, §3.2, §6.2.
  • [54] P. Sapiezynski, A. Stopczynski, D. K. Wind, J. Leskovec, and S. L. Jørgensen (2017) Inferring person-to- person proximity using wifi signals. In ACM on Interactive, Mobile, Wearable and Ubiquitous Technologie, pp. . Cited by: footnote 5.
  • [55] F. Schmid (2020) Swiss tracing app goes on trial. Note: https://ethz.ch/en/news-and-events/eth-news/news/2020/05/swiss-covid-app.html Cited by: §6.2.4.
  • [56] A. Shamir (1979) How to share a secret. Communications of the ACM 22 (11), pp. 612–613. Cited by: §3.2.
  • [57] S. Slussarenko and G. J. Pryde (2019) Photonic quantum information processing: a concise review. Applied Physics Reviews 6 (4), pp. 041303. Cited by: 1st item.
  • [58] Stanford (2020) COVID watch. Note: https://www.covid-watch.org Cited by: §6.2.6.
  • [59] Q. Tang (2020) Privacy-preserving contact tracing: current solutions and open questions. Note: https://arxiv.org/abs/2004.06818 Cited by: §1.
  • [60] N. Trieu, K. Shehata, P. Saxena, R. Shokri, and D. Song (2020, arXiv 2004.13293) Epione: lightweight contact tracing with strong privacy. External Links: 2004.13293 Cited by: §6.3.3, §6.3.
  • [61] S. Vaudenay (2020) Analysis of dp3t: between scylla and charybdis. IACR Cryptol. ePrint Arch. 2020, pp. 399. External Links: Link Cited by: §5.6.
  • [62] S. Vaudenay (2020) Centralized or decentralized? the contact tracing dilemma. IACR Cryptol. ePrint Arch. 2020, pp. 531. External Links: Link Cited by: §1, §5.6.
  • [63] Y. Wang, X. Yang, Y. Zhao, Y. Liu, and L. Cuthbert (2013) Bluetooth positioning using rssi and triangulation methods. In 2013 IEEE 10th Consumer Communications and Networking Conference (CCNC), pp. 837–842. Cited by: §5.2.
  • [64] C. Watch (2020) COVID watch sourcecode. Note: https://github.com/covid19risk/ Cited by: §6.2.6.

References

  • [1] knowledge_Protocol.pdf 2020 Accessed: 2020-05-18 @misc{setu2, author = {\relax Ministry of Electronics and \relax Information Technology}, title = {Notification of the Aarogya Setu data access and knowledge sharing protocol}, howpublished = {\url{https://meity.gov.in/writereaddata/files/Aarogya\_Setu\_data\_access\_ knowledge\_Protocol.pdf}}, year = {2020}, lastaccessed = {Accessed: 2020-05-18}}
  • O’NeillPatrick HowellRyan-MosleyTateJohnsonBobbieA flood of coronavirus apps are tracking us. now it’s time to keep track of themhttps://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/2020Accessed: 2020-05-15@misc{mit, author = {Patrick Howell O'Neill and Tate Ryan-Mosley and Bobbie Johnson}, title = {A flood of coronavirus apps are tracking us. Now it’s time to keep track of them}, howpublished = {\url{https://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-15}} CriddleCristinaKelionLeoCoronavirus contact-tracing: world split between two types of apphttps://www.bbc.com/news/technology-523550282020Accessed: 2020-05-21@misc{bbc, author = {Cristina Criddle and Leo Kelion}, title = {Coronavirus contact-tracing: World split between two types of app}, howpublished = {\url{https://www.bbc.com/news/technology-52355028}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} DuballJoeCentralized vs. decentralized: eu’s contact tracing privacy conundrumhttps://iapp.org/news/a/centralized-vs-decentralized-eus-contact-tracing-privacy-conundrum/2020Accessed: 2020-05-21@misc{duball, author = {Joe Duball}, title = {Centralized vs. decentralized: EU's contact tracing privacy conundrum}, howpublished = {\url{https://iapp.org/news/a/centralized-vs-decentralized-eus-contact-tracing-privacy-conundrum/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} JenningsRafeWhat are the data privacy considerations of contact tracing apps?https://ukhumanrightsblog.com/2020/05/01/what-are-the-data-privacy-considerations-of-contact-tracing-apps/2020Accessed: 2020-05-21@misc{jennings, author = {Rafe Jennings}, title = {What are the data privacy considerations of Contact Tracing Apps?}, howpublished = {\url{https://ukhumanrightsblog.com/2020/05/01/what-are-the-data-privacy-considerations-of-contact-tracing-apps/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} FarrellPaulExperts raise concerns about security of coronavirus tracing app covidsafehttps://www.abc.net.au/news/2020-05-14/experts-concerned-about-coronavirus-tracing-covidsafe-security/122451222020Accessed: 2020-05-21@misc{farrell, author = {Paul Farrell}, title = {Experts raise concerns about security of coronavirus tracing app COVIDSafe}, howpublished = {\url{https://www.abc.net.au/news/2020-05-14/experts-concerned-about-coronavirus-tracing-covidsafe-security/12245122}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} PalmerDannySecurity experts warn: don’t let contact-tracing app lead to surveillancehttps://www.zdnet.com/article/security-experts-warn-dont-let-contact-tracing-app-lead-to-surveillance/2020Accessed: 2020-05-21@misc{palmer, author = {Danny Palmer}, title = {Security experts warn: Don't let contact-tracing app lead to surveillance}, howpublished = {\url{https://www.zdnet.com/article/security-experts-warn-dont-let-contact-tracing-app-lead-to-surveillance/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} of HealthDepartmentCOVIDSafe application privacy impact assessmenthttps://www.health.gov.au/resources/publications/covidsafe-application-privacy-impact-assessmentAccessed: 2020-05-21@misc{PIACovidSafe, author = {\relax Department of Health}, title = {COVIDSafe Application Privacy Impact Assessment}, howpublished = {\url{https://www.health.gov.au/resources/publications/covidsafe-application-privacy-impact-assessment}}, lastaccessed = {Accessed: 2020-05-21}} of WashingtonUniversityMicrosoftCOVIDSafehttps://covidsafe.cs.washington.edu/t2020Accessed: 2020-05-21@misc{uow-CovidSafe, author = {\relax University of Washington and Microsoft}, title = {COVIDSafe}, howpublished = {\url{https://covidsafe.cs.washington.edu/t}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} DiffieWhitfieldHellmanMartin E.New directions in cryptographyIEEE Transactions on Information Theory.22 (6)644–654Nov, 1976@article{DH, author = {Diffie, Whitfield and Hellman, Martin E.}, title = {New Directions in Cryptography}, journal = {IEEE Transactions on Information Theory.}, volume = {22 (6)}, pages = {644-654}, year = {Nov, 1976}} StanfordCOVID watchhttps://www.covid-watch.org2020Accessed: 2020-05-21@misc{CovidWatch, author = {\relax Stanford}, title = {COVID Watch}, howpublished = {\url{https://www.covid-watch.org}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} WatchCovidCOVID watch sourcecodehttps://github.com/covid19risk/2020Accessed: 2020-06-06@misc{CovidWatchSource, author = {Covid Watch}, title = {COVID Watch Sourcecode}, howpublished = {\url{https://github.com/covid19risk/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-06}} KaafarD.et al.Joint statement on contact tracing.https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/April 19th, 2020Accessed: 2020-05-21@misc{jointstate, author = {D. Kaafar and et al.}, title = {Joint Statement on Contact Tracing.}, howpublished = {\url{https://drive.google.com/file/d/1OQg2dxPu-x-RZzETlpV3lFa259Nrpk1J/}}, year = {April 19th, 2020}, lastaccessed = {Accessed: 2020-05-21}} Anonymous collocation discovery: harnessing privacy to tame the coronavirusCanettiRanTrachtenbergAriVariaMayank2020, arXiv 2003.13670v42003.13670v4arXivcs.CY@misc{Boston, title = {Anonymous Collocation Discovery: Harnessing Privacy to Tame the Coronavirus}, author = {Ran Canetti and Ari Trachtenberg and Mayank Varia}, year = {2020, arXiv 2003.13670v4}, eprint = {2003.13670v4}, archiveprefix = {arXiv}, primaryclass = {cs.CY}} GoogleExposure notification apihttps://www.google.com/covid19/ exposurenotifications/2020Accessed: 2020-05-21@misc{Google, author = {Google}, title = {Exposure notification API}, howpublished = {\url{https://www.google.com/covid19/ exposurenotifications/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} ApplePrivacy preserving contact tracinghttps://www.apple.com/covid19/contacttracing2020Accessed: 2020-05-21@misc{Apple, author = {Apple}, title = {Privacy Preserving Contact Tracing}, howpublished = {\url{https://www.apple.com/covid19/contacttracing}}, year = {2020}, lastaccessed = {Accessed: 2020-05-21}} OrganizationWorld HealthWHO timeline - covid-19https://www.who.int/news-room/detail/27-04-2020-who-timeline—covid-192020Accessed: 2020-05-25@misc{WHO, author = {\relax World Health Organization}, title = {WHO Timeline - COVID-19}, howpublished = {\url{https://www.who.int/news-room/detail/27-04-2020-who-timeline—covid-19}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} SchmidFranziskaSwiss tracing app goes on trialhttps://ethz.ch/en/news-and-events/eth-news/news/2020/05/swiss-covid-app.html2020Accessed: 2020-05-26@misc{swissCovid, author = {Franziska Schmid}, title = {Swiss tracing app goes on trial}, howpublished = {\url{https://ethz.ch/en/news-and-events/eth-news/news/2020/05/swiss-covid-app.html}}, year = {2020}, lastaccessed = {Accessed: 2020-05-26}} SapiezynskiP.StopczynskiA.WindD. K.LeskovecJ.JørgensenS. L.Inferring person-to- person proximity using wifi signalsACM on Interactive, Mobile, Wearable and Ubiquitous Technologie2017ACM@inproceedings{WiFi, author = {P. Sapiezynski and A. Stopczynski and D. K. Wind and J. Leskovec and S. L. Jørgensen}, title = {Inferring Person-to- person Proximity Using WiFi Signals}, booktitle = {ACM on Interactive, Mobile, Wearable and Ubiquitous Technologie}, year = {2017}, publisher = {ACM}, pages = {}} RedmilesElissa M.User concerns & tradeoffs in technology-facilitated contact tracinghttps://arxiv.org/abs/2004.132192020Accessed: 2020-05-25@misc{Redmiles, author = {Elissa M. Redmiles}, title = {User Concerns \& Tradeoffs in Technology-Facilitated Contact Tracing}, howpublished = {\url{https://arxiv.org/abs/2004.13219}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} LiTianshiYangJackieFaklarisCoriKingJenniferYuvraj AgarwalLaura DabbishHongJason I.Decentralized is not risk-free: understanding public perceptions of privacy-utility trade-offs in covid-19 contact-tracing appshttps://arxiv.org/abs/2005.119572020Accessed: 2020-05-25@misc{LFFK, author = {Tianshi Li and Jackie Yang and Cori Faklaris and Jennifer King and Yuvraj Agarwal, Laura Dabbish and Jason I. Hong}, title = {Decentralized is not risk-free: Understanding public perceptions of privacy-utility trade-offs in COVID-19 contact-tracing apps}, howpublished = {\url{https://arxiv.org/abs/2005.11957}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} LiJinfengGuoXinyiCOVID-19 contact-tracing apps: a survey on the global deployment and challengeshttps://arxiv.org/abs/2005.035992020Accessed: 2020-05-25@misc{LG20, author = {Jinfeng Li and Xinyi Guo}, title = {COVID-19 Contact-tracing Apps: a Survey on the Global Deployment and Challenges}, howpublished = {\url{https://arxiv.org/abs/2005.03599}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} TangQiangPrivacy-preserving contact tracing: current solutions and open questionshttps://arxiv.org/abs/2004.068182020Accessed: 2020-05-25@misc{T20, author = {Qiang Tang}, title = {Privacy-Preserving Contact Tracing: current solutions and open questions}, howpublished = {\url{https://arxiv.org/abs/2004.06818}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} KuhnChristianeBeckMartinStrufeThorstenCovid notions: towards formal definitions – and documented understanding – of privacy goals and claimed protection in proximity-tracing serviceshttps://arxiv.org/abs/2004.077232020Accessed: 2020-05-25@misc{KBS20, author = {Christiane Kuhn and Martin Beck and Thorsten Strufe}, title = {Covid Notions: Towards Formal Definitions – and Documented Understanding – of Privacy Goals and Claimed Protection in Proximity-Tracing Services}, howpublished = {\url{https://arxiv.org/abs/2004.07723}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} of HealthDepartmentCOVIDSafe legislationhttps://www.ag.gov.au/RightsAndProtections/Privacy/Pages/ COVIDSafelegislation.aspx2020Accessed: 2020-05-25@misc{regulation1, author = {\relax Department of Health}, title = {COVIDSafe Legislation}, howpublished = {\url{https://www.ag.gov.au/RightsAndProtections/Privacy/Pages/ COVIDSafelegislation.aspx}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} The sybil attackDouceurJohn RInternational workshop on peer-to-peer systems251–2602002Springer@inproceedings{douceur2002sybil, title = {The sybil attack}, author = {Douceur, John R}, booktitle = {International workshop on peer-to-peer systems}, pages = {251–260}, year = {2002}, organization = {Springer}} AISECFraunhoferPandemic contact tracing apps: dp-3t, pepp-pt ntk, and robert from a privacy perspectiveCryptology ePrint Archive, Report 2020/4892020https://eprint.iacr.org/2020/489@misc{Fraunhofer, author = {Fraunhofer AISEC}, title = {Pandemic Contact Tracing Apps: DP-3T, PEPP-PT NTK, and ROBERT from a Privacy Perspective}, howpublished = {Cryptology ePrint Archive, Report 2020/489}, year = {2020}, note = {\url{https://eprint.iacr.org/2020/489}}} RappaportTheodoreWireless communications: principles and practice2001ISBN 0130422320Prentice Hall PTRUSA2nd@book{rappaport, author = {Rappaport, Theodore}, title = {Wireless Communications: Principles and Practice}, year = {2001}, isbn = {0130422320}, publisher = {Prentice Hall PTR}, address = {USA}, edition = {2nd}} Bluetooth positioning using rssi and triangulation methodsWangYapengYangXuZhaoYutianLiuYueCuthbertLaurie2013 IEEE 10th Consumer Communications and Networking Conference (CCNC)837–8422013IEEE@inproceedings{triangulation, title = {Bluetooth positioning using RSSI and triangulation methods}, author = {Wang, Yapeng and Yang, Xu and Zhao, Yutian and Liu, Yue and Cuthbert, Laurie}, booktitle = {2013 IEEE 10th Consumer Communications and Networking Conference (CCNC)}, pages = {837–842}, year = {2013}, organization = {IEEE}} BarrettBrianAn artist used 99 phones to fake a google maps traffic jamhttps://www.wired.com/story/99-phones-fake-google-maps-traffic-jam/2020Accessed: 2020-05-25@misc{GmapsHack, author = {Brian Barrett}, title = {An Artist Used 99 Phones to Fake a Google Maps Traffic Jam}, howpublished = {\url{https://www.wired.com/story/99-phones-fake-google-maps-traffic-jam/}}, year = {2020}, lastaccessed = {Accessed: 2020-05-25}} Cuckoo filter: practically better than bloomFanBinAndersenDave GKaminskyMichaelMitzenmacherMichael DProceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies75–882014@inproceedings{cuckoo, title = {Cuckoo filter: Practically better than bloom}, author = {Fan, Bin and Andersen, Dave G and Kaminsky, Michael and Mitzenmacher, Michael D}, booktitle = {Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies}, pages = {75–88}, year = {2014}} BonnetainXavieret al.Anonymous tracing, a dangerous oxymoron, a risk analysis for non-specialistshttps://tracing-risks.com/docs/tracing-risks.pdf2020Accessed: 2020-05-29@misc{oxymoron, author = {Xavier Bonnetain and et al.}, title = {Anonymous tracing, a dangerous oxymoron, A risk analysis for non-specialists}, howpublished = {\url{https://tracing-risks.com/docs/tracing-risks.pdf}}, year = {2020}, lastaccessed = {Accessed: 2020-05-29}} research groupLSTSCorona appshttps://lsts.research.vub.be/en/corona-apps2020Accessed: 2020-06-2@misc{lsts, author = {\relax LSTS research group}, title = {Corona Apps}, howpublished = {\url{https://lsts.research.vub.be/en/corona-apps}}, year = {2020}, lastaccessed = {Accessed: 2020-06-2}} GuoquanLiEnxuGengZhouyangYeYongjunXuYu.PangIndoor positioning algorithm based on the improved rssi distance modelSensors18 (9)2018@article{rssi, author = {Li Guoquan and Geng Enxu and Ye Zhouyang and Xu Yongjun and Lin Jinzhao, and Pang Yu.}, title = {Indoor Positioning Algorithm Based on the Improved RSSI Distance Model}, journal = {Sensors}, volume = {18 (9)}, pages = {}, year = {2018}} of ElectronicsMinistryTechnologyInformationAarogya setuhttps://github.com/nic-delhi/AarogyaSetu_Android2020Accessed: 2020-06-2@misc{setu-Source, author = {\relax Ministry of Electronics and \relax Information Technology}, title = {Aarogya Setu}, howpublished = {\url{https://github.com/nic-delhi/AarogyaSetu\_Android}}, year = {2020}, lastaccessed = {Accessed: 2020-06-2}} INRIAStopCovid 19https://gitlab.inria.fr/stopcovid192020Accessed: 2020-06-5@misc{stopCovid-Source, author = {\relax INRIA}, title = {StopCovid 19}, howpublished = {\url{https://gitlab.inria.fr/stopcovid19}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} CheckPathProject aurora: a new open source solution for the google apple exposure notification apihttps://covidsafepaths.org/a-new-open-source-solution-for-the-google-apple-exposure-notification-api/2020Accessed: 2020-06-5@misc{aurora, author = {Path Check}, title = {Project Aurora: A New Open Source Solution for the Google Apple Exposure Notification API}, howpublished = {\url{https://covidsafepaths.org/a-new-open-source-solution-for-the-google-apple-exposure-notification-api/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} FoundationPath CheckCOVID safe pathshttps://covidsafepaths.org/2020Accessed: 2020-06-5@misc{pathCheck, author = {Path Check Foundation}, title = {COVID Safe Paths}, howpublished = {\url{https://covidsafepaths.org/}}, year = {2020}, lastaccessed = {Accessed: 2020-06-5}} DTACovid safehttps://github.com/AU-COVIDSafe2020Accessed: 2020-06-1@misc{covidSafe-Source, author = {\relax DTA}, title = {Covid Safe}, howpublished = {\url{https://github.com/AU-COVIDSafe}}, year = {2020}, lastaccessed = {Accessed: 2020-06-1}} How to share a secretShamirAdiCommunications of the ACM2211612–6131979ACM New York, NY, USA@article{secretSharing, title = {How to share a secret}, author = {Shamir, Adi}, journal = {Communications of the ACM}, volume = {22}, number = {11}, pages = {612–613}, year = {1979}, publisher = {ACM New York, NY, USA}} Practical private set intersection protocols with linear complexityDe CristofaroEmilianoTsudikGeneInternational Conference on Financial Cryptography and Data Security143–1592010Springer@inproceedings{PSI, title = {Practical private set intersection protocols with linear complexity}, author = {De Cristofaro, Emiliano and Tsudik, Gene}, booktitle = {International Conference on Financial Cryptography and Data Security}, pages = {143–159}, year = {2010}, organization = {Springer}} BonehDanThe decision diffie-hellman problemAlgorithmic Number Theory1998Springer Berlin HeidelbergBerlin, Heidelberg48–63ISBN 978-3-540-69113-6@inproceedings{ddh, author = {Boneh, Dan}, title = {The Decision Diffie-Hellman problem}, booktitle = {Algorithmic Number Theory}, year = {1998}, publisher = {Springer Berlin Heidelberg}, address = {Berlin, Heidelberg}, pages = {48–63}, isbn = {978-3-540-69113-6}} Photonic quantum information processing: a concise reviewSlussarenkoSergeiPrydeGeoff JApplied Physics Reviews640413032019AIP Publishing LLC@article{quantumComputing, title = {Photonic quantum information processing: A concise review}, author = {Slussarenko, Sergei and Pryde, Geoff J}, journal = {Applied Physics Reviews}, volume = {6}, number = {4}, pages = {041303}, year = {2019}, publisher = {AIP Publishing LLC}} Quantum communications in future networks and servicesManzaliniAntonioQuantum Reports21221–2322020Multidisciplinary Digital Publishing Institute@article{quantumComm, title = {Quantum Communications in Future Networks and Services}, author = {Manzalini, Antonio}, journal = {Quantum Reports}, volume = {2}, number = {1}, pages = {221–232}, year = {2020}, publisher = {Multidisciplinary Digital Publishing Institute}} Quantum sensingDegenChristian LReinhardFCappellaroPaolaReviews of modern physics8930350022017APS@article{quantumSensing, title = {Quantum sensing}, author = {Degen, Christian L and Reinhard, F and Cappellaro, Paola}, journal = {Reviews of modern physics}, volume = {89}, number = {3}, pages = {035002}, year = {2017}, publisher = {APS}}