key: cord-0514088-ungcc6j5
authors: Martin, Tania; Karopoulos, Georgios; Hern'andez-Ramos, Jos'e L.; Kambourakis, Georgios; Centre, Igor Nai Fovino European Commission Joint Research; Ispra,; Italy,
title: Demystifying COVID-19 digital contact tracing: A survey on frameworks and mobile apps
date: 2020-07-22
journal: nan
DOI: nan
sha: aa57e69c51803b2be67a51dd5bd9a15e1245239b
doc_id: 514088
cord_uid: ungcc6j5

The coronavirus pandemic is a new reality and it severely affects the modus vivendi of the international community. In this context, governments are rushing to devise or embrace novel surveillance mechanisms and monitoring systems to fight the outbreak. The development of digital tracing apps, which among others are aimed at automatising and globalising the prompt alerting of individuals at risk in a privacy-preserving manner is a prominent example of this ongoing effort. Very promptly, a number of digital contact tracing architectures has been sprouted, followed by relevant app implementations adopted by governments worldwide. Bluetooth, and specifically its Low Energy (BLE) power-conserving variant has emerged as the most promising short-range wireless network technology to implement the contact tracing service. This work offers the first to our knowledge, full-fledged review of the most concrete contact tracing architectures proposed so far. This endeavour does not only embrace the diverse types of architectures and systems, namely centralised, decentralised, or hybrid, but it equally addresses the client side, i.e., the apps that have been already deployed by European countries. There is also a full-spectrum adversary model section, which does not only amalgamate the previous work in the topic, but also brings new insights and angles to contemplate upon.

The World Health Organization (WHO) on March 11, 2020 declared COVID-19 a pandemic 1 , whose effects will probably determine the evolution of our society for many years to come. The direction of this evolution will greatly depend on the capacity of our society to swiftly and jointly converge toward the best mitigation solutions. Until a vaccine will be available or unless the pandemic will spontaneously disappear, the best weapons in the hands of countries will be prevention and fast diagnosis of infected people. Indeed, in the global race against the spread of the COVID-19, countries, public and private organisations, the academia, and others have quickly joined the forces to orchestrate appropriate countermeasures.

In this context, the development of contact tracing approaches is currently considered as one of the main weapons to confront the spread of the COVID-19 worldwide. Indeed, contact tracing is considered by the WHO as a key component of the infection monitoring by including contact identification, listing and follow-up aspects [1] . So far, contact tracing has been mainly based on manual procedures, in which infected people are interviewed in an attempt to trace their contacts. Then, the health authority reaches each contact to check if they present any symptoms and advises them accordingly, e.g., get tested and/or self-quarantine. This approach is time consuming, resource demanding, and prone to errors, since people might not remember all their contacts or, even if they do, they might not know them in person or how to contact them.

To cope with these issues, digital contact tracing has emerged with different initiatives, which are currently driven by organisations and governments worldwide. The main purpose is to efficiently detect people who have been in close contact with infected individuals, so they can be promptly and properly advised on the next steps to follow. This way, potentially infected individuals can be easily detected and self-isolated even before showing symptoms. Therefore, the infection chain is interrupted as early as possible.

During the last few months, numerous contact tracing frameworks and smartphone applications (apps) have emerged. These frameworks comprise the backend infrastructure and the protocols used to communicate among subsystems, whereas the apps are installed on peoples' smartphones and interact with the backend infrastructure. However, the development of such frameworks and apps poses security and data protection issues, in addition to interoperability concerns. Indeed, at the European Union level, these aspects are highlighted by recent legal instruments, such as the EU Recommendation 2020/518 [2] and the Commission Communication 2020/C 124 I/01 [3] .

Our contribution: Taking into account the current landscape of digital contact tracing frameworks and apps, this work endeavours to provide a comprehensive overview of such efforts and to analyse the main security and data protection aspects around these initiatives. In particular, we scrutinise recent frameworks jointly developed by industry and academia, such as the Decentralised Privacy-Preserving Proximity Tracing (DP-3T) [4] or the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) [5] . Furthermore, we describe a full-fledged adversarial model, which brings new insights and angles to be considered for the development and evolution of ongoing contact tracing initiatives. Such a model is used to analyse the different frameworks around different security and data protection concerns. Finally, we provide an extensive overview of the main EU apps that are already deployed or currently in development in different countries. To the best of our knowledge, this is the first paper providing a sweeping overview of current contact tracing frameworks and mobile apps coping with the COVID-19 pandemic. We believe that our work could be used as a reference for researchers working in the definition of digital contact tracing approaches to restrain the spread of the COVID-19, as well as general contact tracing initiatives focused on security and data protection aspects.

The remainder of this paper is organised as follows. Section 2 details on the main contact tracing frameworks developed so far. Section 3 offers an adversarial model that is well-suited to anatomise the security and privacy aspects of the various approaches. Furthermore, Section 4 explores the mobile apps already deployed or in development across the European continent. Finally, a conclusion is drawn in Section 5.

As already mentioned, the definition of contact tracing approaches has attracted a significant interest recently. This section scrutinises the existing contact tracing frameworks, and analyses their chief operational aspects. The main centralised and decentralised frameworks used by most contact tracing apps are described in more detail, while a brief description of the rest is provided given that their operation is very similar to the former.

The Decentralised Privacy-Preserving Proximity Tracing (DP-3T) represents a decentralised contact tracing approach, which is driven by several international experts from academia and research institutions. The DP-3T consortium was formed by several members of the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) initiative (which is described in the next subsection) as a decentralised alternative, which is open source at a GitHub repository [4] . According to the DP-3T team [6] , the main objectives of the system are to enable a quick notification of contact people at risk, and to help epidemiologists to analyse the spread of the virus. Furthermore, the consortium has recently defined additional goals, including the communication with interested stakeholders to improve tracing systems, contributions about the effectiveness of tracing solutions, or collaboration for the development of related apps [7] .

The DP-3T system is based on the broadcast of identifiers (IDs) through Bluetooth Low Energy (BLE) by the user's smartphone. Therefore, nearby users are enabled to receive and store such IDs. In case an infected person is detected, their smartphone is authorised to send their IDs to the backend, which in turn broadcasts the IDs to the users of the system. This way, each receiving user compares the received IDs against the list of stored IDs and, in case of an ID match, the app notifies the user that they have been in contact with an infected person.

From an architectural perspective, the DP-3T system only requires a backend server and the users' smartphones, where the corresponding app is installed. Furthermore, the existence of a health authority is assumed. Then, the following two main processes are defined: Figure 1 : DP-3T processing and storing of observed EphIDs [6] • Generation and storage of ephemeral IDs (EphIDs).

• Proximity tracing.

As already pointed out, the approach defines a core solution in which each smartphone broadcasts changing ephemeral IDs (EphIDs), which are sent through BLE beacons (advertisements). These IDs are generated from a secret key SK t , where t represents the current day. Furthermore, the same key is refreshed every day by using a hash function H, in such a way that SK t = H(SK t−1 ). This is a hash chain scheme, meaning that if a key is compromised, then all the subsequent SKs are revealed, but not the SKs before it. Then, SK t is used to derive a set of EphIDs by using a pseudo-random function P RF , say, HMAC-SHA-256, and a pseudorandom generator P RG, say, AES in counter mode:

EphID 1 ||...||EphID n = P RG(P RF (SK t , "broadcast key"))

To avoid location tracking, each EphID has a validity period of several minutes. EphIDs are received by nearby users through BLE advertisements. Then, each EphID is stored by these users together with an exposure measurement, e.g., signal attenuation, and the day when the beacon was received. This process is shown in Figure 1 . Furthermore, each user's app locally stores their own keys SK t that were generated during the past 14 days.

The process of proximity tracing illustrated in Figure 2 is triggered when a user is diagnosed as infected by the health authority. The latter authority is responsible for notifying test results 1 , authorising users to upload information to the backend server, and calculating the time during a patient is contagious, also known as "contagious window". When a person is diagnosed as contagious and is authorised by the health authority, say, via an authorisation code, they upload the key SK t and the first day t that they were considered to be contagious 2 . This information can be encoded in the authorisation code. Therefore, the backend will receive a pair (SK t , t) of each infected individual. Then, the different (SK t , t) pairs are periodically downloaded by the registered users 3 . It should be noted that the backend is only intended to broadcast this information, instead of processing any data. With this information, users are enabled to compute the list of EphIDs associated to a given (SK t , t) pair. In case such an EphID is included in their stored list, it means the user was in contact with an infected person. Then, for each matching beacon, the data on receive time and exposure measurement is sent to a exposure estimation component, which is intended to estimate the duration of the smartphone owner's exposure to infected users in the past.

The previous description pertains to the DP-3T design "Low-cost decentralized proximity tracing". However, the DP-3T consortium has also proposed an alternative approach called "unlinkable decentralized proximity tracing" [6] , which is intended to provide better privacy properties, but at the expense of stronger performance requirements on the smartphone side. In this case, when a user is diagnosed as infected, they can decide which IDs are shared to avoid the potential linking of EphIDs. For example, a user may choose not to share the IDs corresponding to a certain period, e.g., Sunday morning. The approach is based on the use of Cuckoo filters [8] , in which the IDs of an infected person are hashed and stored.

Furthermore, a third alternative has been defined in the latest version of the DP-3T white paper [6] , which integrates the advantages of the aforementioned designs. Precisely, it is called "Hybrid decentralized proximity tracing" in which seeds are generated and used to create ephemeral IDs according to the first design, but these seeds are only uploaded in case they are relevant to exposure estimation for other users. This way, protection against linking ephemeral IDs is enhanced compared to the low-cost design, but tracking protection is weaker than for the unlinkable design. It should be noted that, according to DP-3T [6] , this design closely resembles the Google/Apple framework [9] in which time windows are 1-day long, so one seed is used to generate the ephemeral IDs of that day.

Moreover, the DP-3T consortium has proposed [6] an enhancement that can be applied to diverse proximity tracing systems called "EphID Spreading with Secret Sharing". The main goal of this approach is to block an adversary from Figure 2 : DP-3T proximity tracing process [6] recording a proximity event, even in case the contact was during a very short period of time, or when the distance is actually long among people. Therefore, such an attacker could acquire a potentially large amount of EphIDs that could be used to infer additional information about a certain user. To mitigate such an issue, the approach is based on splitting each EphID into different shares, so that each share is transmitted using a certain BLE advertisement. On the downside, a potential receiver needs to get a minimum number of shares to be able to construct the corresponding EphID.

Google/Apple Exposure Notification It should be noted that the solution proposed by Google and Apple, namely Exposure Notification [10] , follows a decentralised approach, which was "heavily inspired" by DP-3T, according to Google [11] . Indeed, as already mentioned, the last version of DP-3T considers that this approach could be seen as a particular case of the "Hybrid decentralized proximity tracing" design. In Exposure Notification, the pseudorandom IDs that are broadcast over BLE, namely Rolling Proximity Identifiers (RPIs), are generated in a similar way as in DP-3T: a Temporary Exposure Key, which is changed every day, is used to derive the RPIs employing a hash function and the AES algorithm. The RPIs are renewed every time the BLE randomised address is changed, namely about every 15 min, to prevent linkability and wireless tracking. Whenever a user is diagnosed as positive to COVID-19, they share the latest Temporary Exposure Keys, e.g., covering the most recent 14 days, with a central server. The mechanism followed by an infected user to report the collected temporary IDs will be determined by their public health authority, say by using a one-time password, but this is not specified by the protocol. The server aggregates all the received Temporary Exposure Keys and the users of the Exposure Notification system periodically download this list of keys. If a user is never diagnosed as positive, their Temporary Exposure Keys do not leave the smartphone. The deployment of Exposure Notification has already started on May 25, 2020 with a large scale pilot in Switzerland [12] . Furthermore, other countries are also considering the use of this approach for their mobile apps, as described in Section 4. For information about security considerations of the approach, the reader can refer to [13] .

The Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) is a digital proximity-tracing framework that uses BLE advertisements to discover and locally log to a user's smartphone other users that are in close proximity. According to its designers [14] , it notifies people at risk with a 90% true positive and 10% false negative rates. Initially, many different systems following either the centralised or decentralised approach were participating under this initiative, including DP-3T, whose partners eventually resigned from the PEPP-PT consortium. In the rest of this section, PEPP-PT refers to two very similar centralised systems, the PEPP-PT NTK [15] and ROBERT [16] . These systems employ a centralised reporting server to process contact logs and individually notify clients of potential contact with an infected patient.

The PEPP-PT system comprises the following components:

• A user mobile app for proximity tracing.

• A backend server for generating temporary IDs used with the app and processing the data received by the app.

• A push notification service 2 to trigger the app to pull notification from the backend.

An overview of the data stored in the different subsystems of PEPP-PT is presented in Table 1 . The interactions among the aforementioned components are depicted in Figure 3 . These interactions are facilitated by the following protocols that will be analysed in the rest of this section:

• User registration.

• Proximity-tracing of other smartphones.

• Sharing collected proximity data with the server.

• Federation with other backends.

When a user installs a PEPP-PT-based app, the latter is always active in the background. During user registration, a pseudonymous user ID is generated by the server and sent to the app. Since attributes like email accounts and phone numbers are not used in PEPP-PT, a combination of a Proof-of-Work (PoW) and a Captcha is used in order to impede mass creation of user accounts. The PoW makes registrations quite expensive and prevents DoS attacks by unauthenticated requests, while Captcha requires human interaction. The registration steps are the following: 5. The app receives OAuth2 client credentials, i.e., random client ID and client secret.

6. The backend stores the app's OAuth2 client credentials, a unique 128-bit random pseudonymous persistent user ID (P U ID) and a push notification ID (PID).

After registration, when the app needs to communicate with the backend, it uses its OAuth2 credentials to retrieve an OAuth2 access token. Then, the app uses this token to get authenticated by the backend. The tokens are solely used for this authentication, and they are valid for a limited period of time. The OAuth2 credentials are only used to issue access tokens. Whenever needed, the server uses the P U ID to generate and send to the app one or a batch of pseudorandom temporary IDs.

This section describes PEPP-PT NTK [15] ; ROBERT [16] follows a similar approach. For every period t, say, 1h, the backend generates a single secret key BK t shared with all users. The backend generates enough BK t keys to cover a larger period in the future, say 2 days. Then, for each user, the backend generates an ephemeral BLE ID (EBID) for every t, by encrypting their P U ID with the BK t :

EBID t (P U ID) = AES(BK t , P U ID)

Each app broadcasts its current valid EBID t via BLE advertisements using the BLE privacy feature to prevent tracking of users who send out continuous BLE advertisements. Using this feature, temporary addresses instead of fixed hardware (MAC) addresses are transmitted. The app implementation must use a new temporary address with every new EBID, to avoid linking of these two IDs.

Each app also constantly scans for other BLE broadcasts from PEPP-PT apps and records the received EBIDs, the current time and metadata of the BLE connection. The metadata include parameters like the Received Signal Strength Indicator (RSSI) and outgoing and incoming signal levels (TX/RX power), which can assist in calculating the distance between the two communicating smartphones. The above data are stored only on the smartphone for as long as the user is not infected, and they are deleted after the epidemiological relevant time, say, 21 days.

When a user is tested as infected, the collected data are sent to the backend for assessing which other users are at risk and notify them. The backend holds these data for up to 3 weeks. To upload the data to the backend, a healthcare professional provides a Transaction Authentication Number (TAN) to the infected user by out-of-band means. The backend associates each EBID received with its corresponding P U ID and calculates the risk for the P U ID holder.

To protect the privacy of infected users from eavesdroppers, in the NTK proposed implementation, the backend pushes notifications to infected as well as a random number of other user apps. The push notification acts as a trigger for the app to send a pull request to the backend. For users at risk, the pull request returns information to the user about potential infection and instructions. For the rest of the users the exchanged messages are just "noise" and no information or instructions are provided by the app. In ROBERT, a pure pull approach is followed where the app regularly inquires the backend server with its EBIDs. According to the risk assessment procedure run on the server, the app pulls a notification informing the user whether they are at risk or not.

The federation of PEPP-PT with other systems is considered out of scope of the specification; however, some general guidelines are provided. To facilitate the federation of backend services, it is only necessary for a backend to recognise the originating backend of an EBID. This can be achieved by including an Encrypted Country Code (ECC) into the EBID so that, for example, the ECC consumes 1 byte out of the 16 bytes available for the EBID. When a foreign backend receives an EBID that does not belong to it, it just forwards it to the home backend. The home backend is responsible to determine how the BK t keys and the EBID are constructed, as well as how the risk analysis is performed.

While the previous frameworks represent the main contact tracing approaches nowadays, additional solutions have been recently proposed, and they are described below.

BlueTrace [18] This framework represents the approach used by the TraceTogether app [19] , which was initially developed by Singapore's Government Technology Agency and Ministry of Health. The approach follows a centralised solution in which users register their phone numbers in the backend service, which provides random IDs that are associated with such numbers. These IDs are used during smartphones' encounters. However, in case a user is infected, they will be authorised to share their encounter history with the health authority, which in turn can obtain the phone number of the infected person, and the number of people who were in contact with them. Therefore, based on the BlueTrace design, the backend service is able to access users' personally identifiable information.

TraceSecure [20] In this case, two alternative solutions are proposed. The first is based on the framework provided by the TraceTogether app and employs public key cryptography. Specifically, the authors define two versions requiring two or three separate non-colluding parties who administer the system that can be associated to health authorities or other government services. The second approach is based on the use of homomorphic encryption by leveraging the ability of the parties to exchange secrets for the sake of providing advanced privacy features.

This system has been recently proposed by INRIA and integrates different aspects of centralised and decentralised models. Specifically, DESIRE follows the ROBERT architecture in which risk scores and notifications are handled by a server. Nevertheless, the approach relies on the concept of Private Encounter Tokens (PETs), which are privately generated by users, and thus are unlinkable. The server is intended to match the PETs provided by infected users with the PETs of requesting people. Furthermore, the information hosted by the server is encrypted with cryptographic keys, which however are locally stored in the users' smartphones.

TCN [22] The Temporary Contact Numbers (TCN) is a decentralised contact tracing protocol based on the exchange of 128-bit temporary IDs among nearby smartphones using BLE. These IDs are pseudorandom and generated locally on the smartphone. When a user develops symptoms or is diagnosed as infected, the app can upload a report with the collected IDs to a central portal. Users' apps connect periodically to the portal to check if their ID has been reported by an infected user. One of the characteristics of TCN is that the involvement of a health authority is optional. If a health authority is involved, then the test results are verified by a signature from the health authority to guarantee the report's integrity. If not, the user creates a self-report of their symptoms to inform other users who have been in proximity.

PACT (UW) [23] , [24] The approach of the Privacy-sensitive protocols And mechanisms for mobile Contact Tracing (PACT) is mainly developed by researchers from the University of Washington and is based on the definition of a third-party free framework for mobile contact tracing. Particularly, the authors define a set of protocols to strengthen privacy aspects by keeping users' data in their smartphones. Indeed, this approach is related to the DP-3T system, as only infected people will be enabled to share their data on a voluntary basis.

The Private Automated Contact Tracing (PACT) protocol has been mainly developed by researchers of the Massachusetts Institute of Technology (MIT) and bears similarities with other relevant decentralised solutions like TCN, DP-3T, and PACT (UW). The user's app generates locally pseudorandom IDs, called chirps, which change every few minutes. The chirps are broadcast using BLE and stored locally in the phone for up to 3 months. The receiving apps can store chirps for up to 3 months as well; optionally, the receiving smartphone can also store the location of the encounter. The upload of collected chirps from infected individuals to a central database is authorised by health professionals via one-time passwords. Regularly, the apps download the database locally and check if the chirps contained in the database are present in their local contact list as well.

OpenCovidTrace [26] This is an open-source platform following a decentralised approach. Its aim is to integrate the most popular contact tracing protocols based on BLE and provide additional features on top of them. Such protocols include DP-3T, Google/Apple Exposure Notification, and BlueTrace. This integration is envisaged to facilitate interoperability between open-source, say, DP-3T and proprietary platforms, including Google/Apple Exposure Notification and BlueTrace. OpenCovidTrace follows the original DP-3T specifications. When the Google/Apple framework is used, pseudorandom temporary IDs are generated locally on the user's smartphone, following the DP-3T approach. If a user reports COVID-19 symptoms, the app sends to a central server the keys used to generate the temporary IDs and the location (i.e., city) of the user in the last 14 days. Periodically, the user's app downloads the keys of users reporting symptoms from the server and information on who has been in the same area with the requesting user. If a match is found, the user is notified as potentially being at risk. The BlueTrace is not yet supported by OpenCovidTrace, but it reportedly will in its next release.

Whisper Tracing [27] This protocol follows a decentralised approach. The temporary IDs are periodically generated in the user's smartphone and exchanged with nearby smartphones over BLE. When a user is infected, the app uploads to a central server the seeds that were used to produce the temporary IDs of the last 2 weeks. No health authority is involved in certifying the infection and no authorisation is foreseen to upload the collected temporary IDs. Each user's app is sporadically synchronised with the central server and, when there are new keys, they are downloaded and processed locally to produce the temporary IDs of infected users. If a match is found, it means that the local user has been in contact with an infected user; an algorithm to estimate the exposure risk is out of the scope of the protocol.

To optimise the process of temporary ID downloading, the authors propose to include a location dimension to the uploaded data, so that a user only downloads temporary IDs from infected users that have visited the same geographic area.

One common aspect of all the reviewed frameworks is the technology used for exchanging the IDs among user smartphones, which is BLE. There are some common characteristics of the aforementioned frameworks related to whether they are centralised or decentralised, the main one being what kind of information is exchanged between the app and the backend server. Namely, in decentralised frameworks, the app of an infected person uploads to the backend its temporary IDs (or the seeds to regenerate them) and each app downloads the list of these IDs. On the other hand, in centralised frameworks, the app of a tested positive user uploads its collected IDs to the server, and only the apps of potentially infected users receive a notification with further instructions. Some apps do receive dummy traffic as a measure against traffic analysis, but in this case no notification is shown to the user.

In Table 2 , the main aspects of the contact tracing frameworks presented above are summarised based on five diverse criteria. The "Approach" column shows whether a centralised or decentralised approach is followed. The "Source [35] and an Android app [36] . 2 The goal of the consortium is to open-source the code but the repositories are not available yet [37] ;

open-source reference implementation is provided for an Android app [38, 39] . 3 While the approach is based on TraceTogether, it adds additional mechanisms (e.g., homomorphic encryption) to improve privacy aspects. 4 It integrates some of the advantages of centralised and decentralised approaches. While users do not need to register as in the case of BlueTrace, the backend server still is able to match infected and requesting users based on PET and the risk score computation. 5 When the Google/Apple protocol is used.

code" column demonstrates whether an open source or proprietary implementation is already available, or no implementation is available. The "Health authority" column shows if such an authority has been considered in the system design and whether its presence is compulsory or optional. The "Location data collected" column describes if it is necessary for the correct operation of the framework the collection of location data by the smartphone. Finally, "Self-reporting" indicates whether it is possible for an infected user to directly inform the rest of the users without the involvement of a health authority certifying the infection or not.

It should be noted that some works have been recently proposed to analyse and compare some of these approaches. In particular, [28] discusses the main vulnerabilities and advantages of both centralised and decentralised solutions systematically. Furthermore, [29] analyses DP-3T, PEPP-PT NTK, and ROBERT from a privacy perspective.

This section details on the adversaries (Adv) and their capabilities and discusses the most relevant attacks. It also identifies the assets and any assumption made. The analysis is mostly done in a generic way, that is, it is not focused on a specific digital contact tracing architecture, namely centralised [5, 16] , semi-centralised [21] , or decentralised [10, 6] . To this matter, the interested reader can refer to the heretofore relevant work examining the pros and cons of each approach [40, 28, 41, 42, 43, 44, 45, 46] . Nevertheless, given that from a practical standpoint, i.e., in regard to the available API/SDK, the most pertinent solution for implementing such a service is the Google/Apple framework, the current section assumes that the advertisement service (beaconing 3 ) is based on BLE, in particular the "Exposure Notification" framework [47, 48, 49] .

Adversaries are individuals, groups, or organisations who attempt to compromise the security/privacy of the contact tracing service or disrupt its operation. The model considers a (i) passive or active, (ii) honest-but-curious or malicious, and (iii) outsider or insider Adv who might try to put in place the following line of actions in order to attack a digital contract tracing system: 1. intercept, block, modify, inject, or replay any message in the public communication channel; 2. use the mobile app to access the system and enable or disable the app's notification service at will; 3. where applicable, the same Adv can try to register with the service multiple times, i.e., create multiple profiles;

4. the same Adv can carry multiple devices (smartphones) and install the app(s) on each of them;

5. the same Adv can try to install the legitimate app along with custom-made ones on the same device;

6. install high-power antennas to amplify their reception and transmission signal to cover a wider area with the purpose of magnifying their tracking or broadcasting capacity;

7. access the data stored in the device;

8. cause Denial of Service (DoS), commotion to the system, harassment to the end-user, or contaminate the data provided to the system; 9. setup and operate their own rogue backend server; 10 . have access to the source code of the backend server;

11. collude with other end-user(s), persons working for the health or law enforcement authorities, or backend server admins;

12. compromise a backend server and the underlying IT infrastructure;

13. trick/lure end-users into installing malware on their devices, say, by exercising social engineering techniques.

The following assumptions are made:

• The Adv adheres to all cryptographic assumptions, e.g., they are unable to decrypt a properly encrypted message without knowing the decryption key.

• All the communication channels between the backend server and any health authority and between the server and the end-users are secured, say, by means of a TLS tunnel and the use of strong ciphersuites. This also means that the server holds and is associated with the expected valid X.509 certificate or public key. Assuming the use of Domain Name System Security Extensions (DNSSEC), an alternative method is for clients to obtain authenticated data directly from zone operators, say, by means of the DNS-based Authentication of Named Entities (DANE) protocol [50] .

• For interoperable contact tracing systems, say, between different countries, it is assumed that the respective inter-communication links are secured either at the transport layer (TLS) or preferably the network layer (IPsec).

• Network perimeter security is enabled on the system's IT infrastructure, including the backend server and its subsystems, and the respective systems of the involved authorities.

• As per the Kerckhoffs's desideratum, and as a rule of thumb, the implementers must avoid a security by obscurity strategy. Therefore, it is assumed that the source code of the app along with the technical specifications of the system are publicly available. The same must apply to any server-side code.

• The client-side app only requests the minimum set of permissions necessary for its operation.

• Participation is fully voluntary (opt-in). The user can at any time uninstall the app, deny providing its observed interactions, etc.

We consider the following categories of adversaries:

• Non-tech-savvy: They have access to the app and may be interested in pieces of data about other users that possibly leak from the app via the user interface, the app's internal storage, or otherwise. Such opponents are basically semi-honest, also known as honest-but-curious 4 .

• Advanced: They have the knowledge, technical skills, and considerable resources to exercise any attack against the system. Their goals include: DoS or harassment, identify infected persons with whom they have been in close proximity, monitor all kinds of traffic, including BLE beacons, app-backend communication, and exit nodes of mix networks, tracking users in short, mid or long run either by eavesdropping on weak constructed ephemeral IDs 5 or pseudonyms or other permanent IDs like the device's MAC address, compromise the backend server, etc. This category embraces any kind of hacker, researcher, IT security professional, etc. These actors are supposed to be mostly malicious, but in certain cases, they can also be honest-but-curious, e.g., academic researchers.

• Powerful: They comprise advanced adversaries with unlimited resources, hence they are in position to exercise any kind of attack, including persistent ones, in large-scale, say, conduct tactical espionage operations or infiltrate and obtain complete control over the system's IT infrastructure. They typically seek to learn information and extrapolate conclusions about the population of users, track specific targets (individuals) of interest or even construct the social interaction graph of a large part of the population, sabotage, cripple or paralyse the system, broadcast a surge of bogus notifications that would cause panic, undermine the credibility of the system and subvert the authorities, etc. This category encompasses state-sponsored actors and large organisations.

• Peripheral: If motivated properly, say, monetary gain, bribe, revenge, corruption, extortion, hacktivism, etc., these insiders might act individually or, more likely, collude with the previous two categories of adversaries (outsiders) to inflict damage or exfiltrate confidential information. This category includes members of the family, system administrators, and persons working for the health, law enforcement, or other authorities, and thus their capacity depends on their role in the organisation. For example, they may have admin access to a centralised architecture, be able to obtain subpoenas, counterfeit diagnosis tests, and so forth, granting them privileged access and elevated power. Such actors are mainly classified as honest-but-curious with more legitimate information available, but malicious behavior is not to be ruled out, e.g., think of a dissatisfied employee, a paid-off official, etc.

The following key assets are identified:

• Any piece of data stored on or leaked from the smartphone, the protocol, say, BLE, or the app. These include the received and transmitted ephemeral IDs or pseudonyms, timestamp of interactions, device or service or app IDs like MAC address, IP address, and BLE exposure notification service metadata, say, the transmission power used to calculate the distance between the devices.

• Any piece of data stored on or leaked from any server in the system.

• Any information that can be inferred by eavesdropping on wireless or wired communication links.

• The relevant IT infrastructure, including the machines along with any network asset.

Attacks that directly stem from the voluntary use of the app, e.g., disable notifications, or others that their impact is rather minor, e.g., inferring individuals who have installed and use the app, are out of scope of this section. The interested reader may also refer to the relevant work conducted by the ROBERT [16] , DESIRE [21] , DP-3T [6] and other teams [44, 46, 51, 52] . The potential attack scenarios described below are related to all frameworks except when explicitly mentioned otherwise, e.g., some attacks apply to centralised frameworks only.

A1. Identify infected persons (with whom the Adv was in proximity): The Adv, being also user of the legitimate app, needs to keep an external log of their personal interactions over time, i.e., who they met. If a notification about an infected person arrives, say from the backend server, then the Adv tries to match its log, say, notes or pictures, against the data in the notification, i.e., the ephemeral IDs of the infected person and the corresponding timeframe. To this end, the Adv may register and use multiple accounts (sybils) in the system and rotate frequently between them. Thereby, they can narrow down the list of possibly infected individuals or even directly identify the infected person. Micropayments, captchas, and similar methods can alleviate the problem of creating multiple accounts, but all these antidotes can be easily outsmarted by a motivated Adv.

A2. Identify areas that infected persons frequently move or live: The Adv uses a long-range antenna connected to their device and wanders around certain areas of interest at specific times of the day, say, at night, to collect the respective ephemeral IDs. Then, they combine the notifications received against the collected data on its app to geographically map the infected individuals. In an alternative scenario, the Adv installs passive BLE receivers (readers) in several different strategic geographical areas to collect -and possibly upload to a server -as many ephemeral IDs along with the corresponding timestamps as possible. Then, they try to correlate the collected data against those included in the received notifications for infected persons. Such a strategy is effective at least for the relevant app's contagion time window, say, 14 days. The magnitude of this strategy is augmented if the Adv colludes with a peripheral actor, e.g., a backend server administrator. A proof-of-concept implementation of such a BLE contact tracing sniffer is given in [53] .

A3. Injection of false information: The Adv attaches a long-range antenna to their transmitting device and places it in crowded areas. In this way, they can transmit their own ephemeral IDs to a much longer distance than that of the typical transmission range of the BLE advertisement. Therefore, many more devices will perceive and log the Adv's ephemeral ID(s). Next, the Adv must flag its status as "infected". This can be achieved in different ways, including going to the hospital, which verifies their infection (if already), bribes an infected individual to bring the Adv's smartphone to the hospital, colludes with the health authorities, compromises the backend server, etc. A different flavor of the same attack may arise if the Adv achieves to directly compromise the backend server or collude with peripheral actors, who will enable the Adv to directly transmit bogus notifications or events. Another possibility is to turn a short encounter with a user (that would not be relevant for a COVID-19 infection) into a longer encounter that might be deemed as relevant by the risk scoring algorithm.

A4. Beacon proxying: The Adv simply relays interactions (beacons) gathered with smartphones whose end-users have high probability of being diagnosed as infected. The Adv may for example capture and immediately or later relay elsewhere all interactions captured from individuals entering or exiting a hospital or other medical facility offering COVID-19 testing. In a similar scenario, the Adv collects a plethora of ephemeral IDs and uses a long-range antenna to replay (broadcast) it to crowded places. In this way, the receiving apps will store and possibly report in case of an infection falsified data, causing at the very least commotion to the system, undermining its credibility.

A5. Beacon wormholing: The Adv uses a custom-made app that collects beacons in a certain location. At the same time or later, they send the collected beacons over the Internet to another device for re-transmitting them in a different area. In such a scenario, the system is forced into believing that a given individual(s) was in proximity with certain persons in a disparate geographical area. By combining this strategy with that in A4 and exercising it in a broad scale would subvert the trustworthiness of the system.

A6. Tracking of individuals: The Adv may attempt to track certain users within range via permanent IDs possibly leaked from the device, the underlying service, or the app. Such IDs include the MAC or IP address, cellular IDs like IMSI, TMSI, GUTI, etc. In particular, BLE is prone to such an attack if either the underlying operating system does not implement a robust MAC address randomisation scheme (in this case of type "random non-resolvable") or the synchronisation between MAC address randomisation and Bluetooth IDs is not in place 6 . In the latter case, the Adv may be able to associate a new MAC with an old ephemeral ID or new ephemeral ID with old MAC. Recent work [54] has demonstrated that several state-of-the-art devices which do implement MAC randomisation as an anonymisation measure are indeed susceptible to passive tracking.

A7. End-user identification: In cases the smartphone of an end-user directly uploads proximity tracing data to, say, a backend server, the admin(s) of that server, any passive eavesdropper exercising traffic analysis on any hop of the connection, or other actor, including the Internet Service Provider (ISP), Wi-Fi or cellular provider, are able to perceive the ID and relative location of this user by means of the associated network IDs, e.g., the IP address. Note that Transport Layer Security (TLS) does not protect against traffic analysis. This threat is more significant for infected end-users, and depending on the case, can be partially or fully mitigated using IPsec tunnels, injection of dummy traffic, trusted proxies, or anonymity networks like Tor or I2P, but, say, "Torification" of the app is required. Note however that all such remedies typically come at a substantial cost, namely they induce a considerable overhead in communication and processing time, drain the battery faster, and increase the volume of the data transferred, which may lead to extra charges if the user employs a cellular connection. As a side note, the number of observed ephemeral IDs may be quite large, especially in periods where the lockdown measures are eased.

A8. Leakage of information stored by the app: This requires the Adv to obtain direct access to the device, e.g., members of the family, authorities, blackmailers, thieves, etc. If so, and given that apps keep locally their own broadcast IDs along with the observed ones, the Adv is in position to learn the targeted-person's interactions and possibly track them in a certain timeframe. Precisely, the Adv can learn the corresponding ephemeral IDs, both received and broadcast, enabling them to extract useful information about the social interactions of the user, track them (via the latter IDs), or possibly, if they have the technical skills, to forge the risk score calculated by the app. This means that apps must diminish the data stored on the device to the bare minimum, and only for as long as is required. This threat can be mitigated if the relevant pieces of data are encrypted.

A9. Linkability 7 : The Adv is in position to link broadcast IDs belonging to the same infected individual. As per A6, if the smartphone of an infected user directly transmits data to the backend server, the latter is enabled to (a) learn the number of ephemeral IDs the infected person gathered during the contagious period, (b) indirectly deduce if some users were co-located, e.g., in case the same ephemeral ID is reported by two or more infected persons during the same timeframe, and (c) possible associate all different ephemeral IDs to the same persistent network ID. Third users have also the same capacity (c), given that the IDs of the infected individuals are shared. This exposure may be for the whole contagious timeframe or a part of it, say, one day, depending on the information shared to users for reconstructing an infected individual's ephemeral IDs. For example, the Adv might observe that they came across the same infected person at 11:00 AM and 15:00 PM. This also means that with reference to A1 and assuming that the timestamps associated with the ephemeral IDs are not obfuscated, the identification of the infected person is immediate, lifting the need for the Adv to create multiple IDs in the system.

A10. Use of pseudonyms: Typically, centralised systems rely on some type of pseudonymity, namely the central server must be able to de-obfuscate ephemeral IDs to the corresponding permanent or long-term ID of the user in order to notify the corresponding at-risk device owner. That is, in such designs, a permanent ID is assigned to the end-user during the registration phase, and the backend server generates the ephemeral IDs and pushes them to the client's device. This also means that server admins, peripheral actors, and any Adv who colludes with the former entities may be in position to learn (a) which people are at-risk, and (b) deanomymise and persistently track specific users of interest in the long run. Additionally, as more and more infected individuals upload their contact history, the central server can gradually expose the social interaction graph of a considerable part of the population for a certain epoch, including non-infected users that came in proximity with at least one infected. The wealth of privacy-sensitive information [56] stored in such a system and the potential for function creep 8 , makes it a far more alluring target for the motivated Adv, especially for powerful ones, and thus more prone to data breaches and leaks.

A11. Radio jamming: Using a radio jammer the Adv blocks device proximity interactions in a certain area. The stronger the jammer the larger the affected area.

A12. Blocking: In some centralised approaches, the ephemeral IDs are created on the server and sent to the client. Typically, a batch of future IDs is created, e.g., enough for two days. An Adv could mount a DoS attack to prevent the IDs from reaching the client. The Adv may also block the upload of the list of ephemeral IDs to the backend.

A13. Resource exhaustion: The Adv creates an upsurge of proximity events with the aim of exhausting the recipients' smartphone computing resources, including battery, memory, and CPU. On top of that, legitimate events may be missed or dropped by the overstressed device or app. The use of a long-range antenna is anticipated to maximise the magnitude of this tactic.

A14. Beacon silencing: The Adv tries to fool a reader into thinking that a BLE beacon is remote, while it actually exists in its vicinity. This may be feasible if the transmitted power field (txPower) also known as measured power of the beacon frame is exposed. txPower is typically a factory-calibrated constant, which denotes what is the expected Received Signal Strength Indicator (RSSI) at a distance of one meter to the beacon. As already pointed out, the txPower is used along with the RSSI in the proximity calculation. For instance, if the smartphone realises that its RSSI is identical to the txPower field contained in the advertisement, it assumes that it is exactly one meter away. Pertinent is also the fact that due to the high fluctuations of the RSSI value, the proximity calculation is typically averaged by multiple signals. The Adv may transmit a flood of spoofed beacons with a greater txPower value, thus biasing the estimation of proximity toward the fake readings, which in turn yields to a faulty proximity estimation. Lately, the specification of the Google/Apple joint framework mandates the encryption of the "Associated Encrypted Metadata" field, which contains the txPower value. Therefore, this field can only be decapsulated after a user is diagnosed as infected and agrees to share their daily key 9 . Note that signal attenuation (txPower -RSSI) is one of the risk parameters for calculating the overall exposure risk [9] . Given the above analysis, if an amplifying antenna is being employed, any smartphone close to it, but not the ones away from it, will observe unusual strong RSSIs. Therefore, as an defensive measure, the receiving app can be instructed to at least drop "too loud" advertisements. Moreover, similar to typical beacons, contact tracing apps will set txPower to a constant value, meaning that at a minimum any instance of the same app will be aware of the proper txPower value. This also means that certain thresholds regarding txPower and RSSI values need to be determined.

A15. Sybils: The Adv may install more than one contact tracing apps on the same device, i.e., the legitimate one and one or more custom-made. From a receiving (reader) device's viewpoint, these, say, two apps running on the same smartphone will be perceived as two different devices (persons). Given MAC randomisation, it is not trivial to associate the beacons stemming from these apps with the same device. In a similar approach, the Adv carries with them more than one device with one or more apps running on each device. Such a tactic, especially if combined with A3, is certain to pollute the data received by readers, create commotion to the system, and possibly taint epidemiological analysis.

A16. Malware: The Adv may lure the user into installing a spyware-like app on their device with the purpose of realising A8. Specifically, such an app will secretly monitor for, say, BLE beacons and will report any incident of sensing these beacons to a remote service controlled by the attacker. Such an app may also ask for location permissions, e.g., for activating GPS, thus enabling the Adv to profile the user in the long-term. In another scenario, the Adv may lure the victim into downloading a repackaged app instead of the legitimate one, say, by means of malvertising. Such an app may track relevant data and transmit it to the Adv via a covert channel, display fake notifications to the user, block the receiving/uploading of certain messages, forge messages and risk-scores, to name a few.

A17. Man-in-the-middle: Some systems, especially the centralised ones, require user registration prior to allowing access to the service. In such a case, the Adv, residing in the same network as the victim(s) or colluding with one who does, may attempt to gather user credentials, namely username and password by exercising a Man-In-The-Middle (MITM) attack. To this end, the Adv uses, say, the SET tool [57] and clones the legitimate website enabling registration at the backend on the local host running Apache server. Next, the Adv needs to redirect the victim(s) on the local network from the legitimate website to the cloned one. For this, they typically need to create a DNS file that will enable the redirection. Also, the Adv must find a way to overcome TLS protection (HTTPS) on the registration page, as well as the protection provided by the HTTP Strict Transport Security (HSTS) header, if any, which compels web browsers to enforce HTTPS. This may be achieved by using a MITM framework like Bettercap [58] , which uses a built-in SSL-Strip function. It is stressed that such an attack uses publicly available tools, and thus can be mounted by even a script-kiddie.

This section summarises the main approaches to alleviate the potential attack scenarios presented above. The focus of this section is on the main centralised and decentralised frameworks, that is, DP-3T and PEPP-PT; however, the methods presented here can be applied to other frameworks with the same architecture as well.

In regards to security, the DP-3T framework describes three main aspects: fake contact events exploited by a potential attacker to trick the user; suppressing at-risk contacts, in which people are blocked from knowing they are at risk; and prevent contact discovery, in which the system functionality is obstructed due to, say, jamming of Bluetooth radio. As discussed by the DP-3T consortium [6] , to cope with fake contact events, the low-cost design prevents relay attacks in which an EphID is relayed with a delay of more than one day, because the seeds of infected users are bound to the day on which they are valid. In the case of the unlinkable design, this aspect is further mitigated, because EphIDs are linked to a certain epoch, so that the attacker should rebroadcast the EphIDs in the same epoch. To avoid a user claiming another user's EphID as their own, the use of a hash function and a pseudo-random function to derive EphIDs from a seed makes infeasible to learn another user's seed from observing their broadcasts.

With respect to privacy concerns, the DP-3T specification considers several aspects. First, the social graph represents the social relationships between users in the system. The DP-3T approach does not reveal such a graph to any party, except for the two users involved in a contact. Second, the interaction graph reflects close-range physical interactions between users. In this case, it is not possible to infer about people in contact from the EphIDs being shared. Third, location traceability should be also avoided. In DP-3T, the EphIDs are unlinkable, and only the user's smartphone knows the seed to generate them. In case a user is infected and gives permission, the seed of the first contagious day is uploaded to the backend. Taking into account this seed, the user's EphIDs are linkable from the start of the contagious day until the seed is uploaded, when the phone will generate a new seed. In the case of the unlinkable design, EphIDs remain unlinkable, as long as the server is considered honest. Fourth, at-risk individuals make reference to people who recently contacted with infected individuals, and only they should know about this circumstance. The system does provide this feature since the seeds of an infected person do not reveal anything about their contacts. Fifth, COVID-19 positive status means that the system should ensure that only infected people and the corresponding health authority know about this circumstance. In the case of the unlinkable design, this issue is mitigated because of the unlinkability properties of the EphIDs of infected people.

PEPP-PT According to its designers, malicious backend admins are not considered as adversaries because the cost to succeed in the attack outweighs the benefits. Also, state-level adversaries are considered out of scope of the threat model of the system; a potential mitigation is that users can change their pseudonym at any time by re-installing the app and, thus, evade a continuous tracking by a state-level adversary.

Regarding Sybil attacks, i.e., registration of multiple accounts by the same user, PoW and Captcha are used. The authentication of the EBIDs is addressed by using authenticated channels between the app and the backend. By using a TAN provided by a healthcare professional it is ensured that only officially diagnosed users can upload EBID lists to the backend server. The backend server is the only one having in possession -ideally stored in a hardware security module -the secret key to produce EBIDs from the persistent ID (PUID) of the user. Thus, EBIDs are linkable to a PUID by the backend server only. In scenario A3, the possibility of turning a short encounter with a user (that would not be relevant for a Covid-19 infection) into a longer encounter that might be deemed as relevant by the risk scoring algorithm is described. A potential solution could be to use signed EBIDs, but this would create key management issues considering the large scale of proximity tracing apps.

Regarding the privacy properties of the system, the temporary IDs exchanged through BLE are pseudorandom and changed regularly, making it difficult for an attacker to associate multiple temporary IDs to the same device and consequently identify its user. Also, these IDs remain stored in the collecting devices and sent to the server only if the user is positive to COVID-19. The network traffic of all users when requesting updates of their risk score is indifferent, so that an eavesdropper cannot distinguish at-risk from not-at-risk users. Periodically, older data are erased, reducing the probability of data misuse. The location privacy of users is protected by not collecting location data. An adversary can determine that a user is positive to COVID-19 by observing network traffic, namely the user uploads a higher volume of data than usual; a mitigation measure is to use mix networks like Tor.

To help health authorities and governments in the fight against COVID-19 pandemic at national level, many countries decided to develop and deploy mobile apps. This work focuses on European initiatives. Their goal is to detect as soon as possible new potential sources of infection, so that the COVID-19 spread could be promptly mitigated. Two types of mobile apps can be found so far, namely contact tracing apps and location sharing apps.

A contact tracing app is based on the digital contact tracing frameworks presented in Section 2 relying on proximity wireless technology such as BLE. When two users are physically close, the smartphones send their identity in terms of ephemeral IDs or pseudonyms to each other. Each smartphone records all its encounters that happened within a period of time, say, the last 14 days. If a user declares a COVID-19 infection, then all their encountered users that were evaluated at risk are warned of the situation through a central server, acting as an information dispatching office, and are requested to remain in self-isolation.

A location sharing app relies on the smartphone positioning information, i.e., via GPS tracking or cell tower mapping. For such an app, the user needs to accept that their smartphone sends on a regular basis, say, every 5 min its position to a central server, which can map every user for an unlimited period of time. If a user declares a COVID-19 infection, then all the users that were within a close range to the infected user during the last, say, 14 days are warned of the situation. As with contact tracing apps, all the concerned users are requested to self-isolate. Note that location sharing apps appear to be far less privacy-preserving for the users as the latter must agree to share continuously their location with a central server. In the case of contact tracing apps, only the -sometimes anonymised -information related to the encounters are shared. Tables 3 and 4 sum up the different mobile apps that European countries have already deployed or are currently developing to fight against COVID-19. Apps that are deployed outside the European continent are left for future work. A detailed discussion on each app is provided in the subsequent subsections.

Several European countries were very prompt to deploy mobile apps that assist in containing as much as possible the spread of the pandemic. This section is based on the available public information of the apps at the time of its writing. Consequently, note that some technical details might be missing. 

The Austrian Red Cross in collaboration with the UNIQA Foundation and Accenture Austria developed Stopp Corona [59] , a free-to-use app available for Android 6+ and iOS 12+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters using a "digital handshake" via Bluetooth.

The system architecture is based on the decentralised DP-3T approach.

Installation No registration or personal information is needed to install and use the app. During the app installation, a random Unique User ID (UUID) is generated and assigned to the user, and a pair of public/private keys is generated on a smartphone. The private key never leaves the smartphone.

Functioning When two users are in proximity, a digital handshake between the smartphones via Bluetooth is performed. It can be either manual or automatic, as defined by the user. The automatic handshake is performed by an external app managed by the Swiss company Uepaa. During the handshake, the public keys of the users/apps are exchanged between the smartphones. In case of infection, a user can activate an alert message. That is, the infected user must enter their smartphone number in the app, and a SMS validation phase is performed to link the smartphone number to the infected user ID. Then, the app automatically informs the encountered users with whom the infected user has performed the handshake during the last 48 hours. The app does so by sending a unique code encrypted with the public key of each encountered user: the app of each encountered user is the only one able to decrypt the received message with the correct corresponding private key, and it thus informs the user of the potential infection. The identity of the infected user remains anonymous for the encountered users. The infected user and encountered users are consequently asked to self-isolate.

Data retention The Austrian Red Cross records the installation UUIDs. The smartphone numbers of the infected users are reportedly stored for a maximum of 30 days. The report about an infection is stored for up to 30 days. The metadata used for automatic handshakes are reportedly stored by Uepaa for 14 days, while the data used for digital handshakes are stored on the smartphone for 7 days.

Data processing The user's consent is required for the processing of personal data. The webpage [71] explains (currently in German only) all the technical data processing performed by the Austrian Red Cross to offer this app along with any legal implication. The organisation is very transparent and details on the sub-contractors involved in the development of the app. It appears that several parts of the app are treated by Uepaa, Google, Amazon, and Microsoft.

After approval by the Bulgarian ministry, the company ScaleFocus developed ViruSafe [60] , a free-to-use app available for Android 5+ and iOS 10+. The use of the app is on a voluntary basis. Contrary to a contact tracing app, ViruSafe is based on GPS location sharing to enable institutions to act accordingly in case of an emergency. The source code of the app is available on GitHub [72] .

Installation After downloading the app, the registration with a personal ID number is required, and a SMS validation phase is performed to link the smartphone number to the user's identity.

Functioning The app has a location tracker based on GPS coordinates, enabled voluntarily by the user, to create a heatmap with potentially infected people. The users can also share any chronic diseases they may have. Additionally, the app can notify users under quarantine when the quarantine period is over.

Data retention The data are collected in a central registry. They include the following personal data: smartphone number, personal ID number or passport number, age, gender, chronic illnesses, answers to personal status questions, location of the smartphone. The data are reportedly stored for the duration of the emergency period as defined by the state.

Data processing The user's consent is required for the processing of personal data. All collected data are accessible by the Ministry of Health, acting as data processor, and authorised governmental institutions with a digital certificate.

The app also provides physicians with access to the processed data automatically. They can decide if and when to contact the users at risk and provide medical advice.

Based on the Safepaths [73] MIT project, the Cypriot research centre RISE developed CovTracer [61] with the contribution of XM.com and Prountzos & Prountzos LLC. It is free and available for Android 5+ and iOS 9+. The use of the app is on a voluntary basis. It is not a contact tracing app, but rather a location sharing app. Note that location can be established with either GPS, IP address of Wi-Fi access points, cell towers, smartphone sensor data, or Bluetooth.

Installation Insufficient information is provided.

Functioning The app starts recording the user's location via GPS. All information remains on the smartphone. In case of infection, the user can share their geolocation data, i.e., their movements during the last two weeks with the epidemiologists. This information is a simple list of times and coordinates on a JavaScript Object Notation (JSON) file; no other identifying information is sent. This file is updated every 5 min on the user's smartphone. The epidemiologists check this information and may act upon, e.g., evacuate areas, perform cleaning, or inform people who were in proximity with the patient. If the user wishes, the geolocations of their movements can be uploaded to CovTracer server in an anonymised form. That is, information about the user's home and any possible identification traces are removed prior to uploading.

Data retention Along with location data, other information is collected, such as the full name, address, date of birth, and reason(s) of moving per occasion. The user's name and password provided during the registration phase may also be required. A phone number and email address may also be provided. All the data are stored on RISE servers and a cloud-based database located within the EU. Data are stored for one year unless a deletion request is received or the user consents to a longer period.

Data processing The detailed privacy policy of the app can be found in the document [74] . The user's consent is required for the processing and sharing of personal data. By default, the personal data are only accessible by RISE, and the location data are shared with the Cypriot epidemiologists.

Within the Czech government's "smart quarantine" plan, the Ministry of Health developed eRouška [62] , a free-to-use app available for Android 5+ and iOS 11+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE.

Installation To use the app, registration with a smartphone number is required. During app installation, a random UUID is generated and assigned to the user. Note that this ID is updated on a regular basis.

Functioning When two users are physically close, the smartphones send their ID to each other, and record via BLE the time of the encounter, its duration, and the ID of the other user. To be logged, the encounter must be at a distance of less than 2 meters and last for more than 15 min. Upon infection, a user sends the list of all the recorded encounters to the regional health authorities, which contact and signal the infection to the encountered users. Note that, although the regional health authorities know the ID of the infected user, they cannot reveal this information to the encountered users.

Data retention All the data are stored by the Ministry of Health. The smartphone number is reportedly stored for up to 6 months. The details of encounters is stored for 12 hours. The data on the smartphone are stored for 30 days.

Data processing The details regarding the privacy policy of the app and its compliance with the GDPR can be found in the document [75] . The app uses servers in the EU and US, only for some sub-services offered by Google. The audit of the app code can be found in the corresponding report [76] . The user's consent is required for the processing and sharing of the data, which is only accessible by the Ministry of Health and the regional health authorities.

Under the supervision of the Ministry for Solidarity and Health and the Ministry of State for Digital Affairs, INRIA researchers developed StopCovid [63] , a free-to-use app available for Android 5+ and iOS 11.4+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE. It further uses ultrasounds emitted via the smartphone's speaker and microphone to reduce the number of false positives. The system is centralised and based on ROBERT [16] . The source code of the app can be found on GitLab [30] . Note that the CNIL published an official opinion [77] in favour of the StopCovid app on April 24, 2020, and confirmed the release of the app in a decision report [78] in favour of the StopCovid app on May 25, 2020. At the end of May 2020, a bug bounty program is launched on the YesWeHack platform to verify the robustness of the app [79] .

Installation No registration or personal information is needed to install and use the app. During the app installation, a random UUID is generated by the server and assigned to the user. Then the app updates the ID every 15 min.

Functioning When two users are physically close, the smartphones send their ID to each other, and record via BLE the time of the encounter, its duration, and the ID of the other user. To be logged, the encounter must be at a distance of less than 1 meters and last for more than 15 min. Upon infection, a user receives from the health authorities a QR code that can be scanned within the app, which sends the list of all the recorded encounters to the central health authorities server. The latter signals the infection to the encountered users. Note that, although the regional health authorities know the ID of the infected user, they cannot reveal this information to the encountered users.

Data retention The central server stores the details of encounters for infected users and the UUIDs of all users. The details of encounters is stored for 15 days, either on the smartphone or on the central server. All the other data should not be stored for more than 6 months after the end of the health emergency state.

Data processing The central server is hosted by Outscale, a French cloud service provider that is part of the Stop-Covid project team. To date, it is the only hosting provider with the SecNumCloud qualification delivered by the French cybersecurity agency ANSSI.

Under the supervision of the German Federal Government and the Robert-Koch-Institut, Deutsche Telekom and SAP Deutschland developed Corona-Warning-App [64] , a free app available for Android 6+ and iOS 13.5+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE.

The system architecture is based on the decentralised Google/Apple API. The source code of the app can be found on GitHub [80] .

Installation No registration or personal information is needed to install and use the app. During the app installation, a random UUID (called temporary exposure key) is generated by the app. Then the app updates this ID every day.

Functioning When two users are physically close, their smartphones send their pseudorandom ID (derived from the current UUID and renewed every 15 min) to each other via BLE. The app assesses the risk of the encounter based on its duration and the distance between the two smartphones. This is estimated from the signal attenuation of BLE.

These information related to the encounters are stored for 2 weeks. In case of infection, a user sends its current UUID to the app server. The app of the other users periodically downloads the new UUIDs of infected users, and uses them to derive the infected users' pseudorandom IDs for the recent past. If one matches the IDs stored in the smartphone's memory, the app notifies the user of the risky exposure. Optionally, if a user has been tested for the COVID-19, they can register the test in the app by scanning a QR code received from the testing laboratory. In that case, the result of the test is sent directly from the laboratory to the app server, which registers the result and sends it to the user via the app.

Data retention The UUIDs of infected users are stored on the app server for 14 days. All the UUIDs and details of encounters are stored for 14 days on the smartphone. If the option is chosen, the test results are stored on the app server for 21 days.

Data processing The details regarding the privacy policy of the app and its compliance with the GDPR can be found in the document [81] . The app (including server) is operated and maintained by Deutsche Telekom and SAP Deutschland. The servers are located in Germany or in Europe.

NextSense developed VirusRadar [65] , a free app available for Android 5+ and iOS 11+. Originally, NextSense developed an app for North Macedonia, and offered it for free to Hungary too. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE.

Installation During the app installation, a UUID is generated and assigned to the user. To use the app, the registration with a smartphone number is required, and a SMS validation phase is performed to link the smartphone number to the user's UUID. The smartphone number and UUID are stored by the Hungarian government on a secure server.

Functioning When two users are physically close, their smartphones send their ID to each other, and record via Bluetooth the time of the encounter, its duration, and the ID of the other user. The encounter must be at a distance of less than 2 meters and last for more than 20 min. These data are stored for 2 weeks. In case of infection, a user sends the list of all the recorded encounters to the health authorities, which contact and signal the infection to the encountered users.

Data retention Insufficient information is provided.

Data processing Insufficient information is provided.

In collaboration with the Ministry of Health and the Ministry for Innovation Technology and Digitalisation, Bending Spoons S.p.A. developed Immuni [66] , a free app available for Android 6+ and iOS 13+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE. The system is based on the decentralised Google/Apple API. The source code of the app can be found on GitHub [82] .

Installation This phase is similar to the one of the German Corona-Warn-App. No registration or personal information is needed to install and use the app. During the app installation, a random UUID (called temporary exposure key) is generated by the app. Then the app updates this ID every day.

Functioning It is also similar to the one of the German Corona-Warn-App. When two users are physically close, their smartphones send their pseudorandom ID (derived from the current UUID and renewed every 15 min) to each other via BLE. The app assesses the risk of the encounter based on its duration and the distance between the two smartphones. This is estimated from the attenuation of BLE. These information related to the encounters are stored for 2 weeks. In case of infection, a user sends its current UUID to the app server. The app of the other users periodically downloads the new UUIDs of infected users, and uses them to derive the infected users' pseudorandom IDs for the recent past. If one matches the IDs stored in the smartphone's memory, the app notifies the user of the risky exposure.

Immuni also sends to the server some analytical data. These include epidemiological (i.e. details of encounters) and operational information, and are sent for the purpose of helping the National Healthcare Service 10 to provide effective assistance to users.

Data retention All the data stored on the smartphone or on the server will be deleted by December 31, 2020.

Data processing The app server is located in Italy and managed by Sogei S.p.A., a public Italian company. The Ministry of Health is the body that collects the data and decides for which purposes to use it. The data is used solely with the aim of containing the COVID-19 epidemic or for scientific research.

In collaboration with Ministry of Health, the SPKC 11 developed Apturi Covid [67] , a free app available for Android 6+ and iOS 13.5+. The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via BLE. The system is based on the decentralised Google/Apple API. The source code of the app will soon be released on GitHub [83] .

Installation This phase is similar to the other Google/Apple-based apps. No registration or personal information is needed to install and use the app. During the app installation, a random UUID (called temporary exposure key) is generated by the app. Then the app updates this ID every day.

Functioning This phase is also similar to the other Google/Apple-based apps. When two users are physically close, their smartphones send their pseudorandom ID (derived from the current UUID and renewed every 15 min) to each other via BLE, and record the time of the encounter and its duration. The encounter must be at a distance of less than 10 Servizio Sanitario Nazionale 11 The Latvian Center for Disease Prevention and Control 2 meters and last for more than 15 min. These information related to the encounters are stored for 14 days. In case of infection, a user sends its current UUID to the app server. The app of the other users periodically downloads the new UUIDs of infected users, and exploits them to derive the infected users' pseudorandom IDs for the recent past. If one matches the IDs stored in the smartphone's memory, the app notifies the user of the risky exposure. Note that a smartphone can optionally be provided in the app, allowing the SPKC to directly contact the users in case of contact with an infected user.

Data retention The UUIDs and details of encounters are stored for 14 days on the smartphone. On the app server side, all the data are reportedly stored for the required time needed for the fulfillment of the obligations specified in regulatory enactments.

Data processing The details regarding the privacy policy of the app and its compliance with the GDPR can be found in the document [84] . Installation Before using the app, each user must verify that their smartphone number is correctly registered in the Norwegian Contact and Reservation Register 12 . Next, the same smartphone number will be used to communicate with the user. During the installation of the app, a random UUID is generated and assigned to the user. The smartphone number and UUID are stored on a central server.

Functioning When two users are physically close, the smartphones send their ID to each other, and record via Bluetooth the time of the encounter, its duration, and the ID of the other user. The encounter must be at a distance of less than 2 meters and last for more than 15 min. For more accurate positioning, the app will also record GPS coordinates. The details of the encounters logged by a smartphone along with the corresponding GPS data are sent continuously to the central server. In case of infection, a user signals it within the app, and the encountered users will receive a SMS notification of the situation. Note that the ID of the infected user is said to be kept anonymous to the encountered users.

The following data are stored: smartphone number, UUID, age, GPS coordinates, operating system, version number and phone model, details of the encounters. All the collected personal data will reportedly be stored until Dec. 1, 2020. The GPS data and any detail regarding the encounters are stored for up to 30 days in the smartphone and the server.

Data processing Data is only accessible to "authorised personnel". The Institute of Public Health receives anonymised data about the users' movement patterns to monitor and analyse the effectiveness of the implemented measures against COVID-19. Independently of the app, once a user is diagnosed as infected, they will be recorded on a specific national health registry of persons tested positive to coronary infection.

Following the same model as Singapore, the Ministry of Digital Affairs developed ProteGO [69] , a free-to-use app available for Android 5+ and iOS 12.1+. The source code of the app is available on GitHub [85] . The use of the app is on a voluntary basis. It is based on an anonymous contact diary that logs the various encounters via Bluetooth.

Installation To use the app, the registration with a smartphone number is required. For the communication between smartphones, a random UUID is generated and assigned to the user every hour.

Functioning When two users are physically close, the smartphones send their ID to each other, and record via Bluetooth the time of the encounter, its duration, and the ID of the other user. These data are stored in an encrypted form for 2 weeks. In case of infection, a user sends the list of all the recorded encounters to the health authorities, who are in charge of communicating the infection to the encountered users. Note that the ID of the infected user is said to be anonymous to the authorities and the encountered users.

Data retention Insufficient information is provided.

Data processing The data are automatically transmitted to allow health inspectors to contact people who should remain in quarantine. The health authorities, Ministry of Digital Affairs, Ministry of Health and a limited number of other private companies can have access to the anonymised data.

In synergy with the Zostanzdravy and Sygic initiatives, Slovak volunteers and experts developed ZostanZdravy (Stay-Healthy) [70] , a free-to-use app available for Android 5+ and iOS 10+. The use of the app is on a voluntary basis. Like for Norway, it is a mix between anonymous contact diary that logs the various encounters via BLE advertisements and GPS location sharing.

Installation During the installation of the app, a UUID is generated and assigned to the user.

Functioning When two users are physically close, the smartphones send their ID to each other, and record via BLE beacons the time of the encounter, its duration, and the ID of the other user. For more accurate positioning, the app will also record GPS coordinates and send the corresponding anonymous logs of both users to the server. In case of infection, a user must register their smartphone number, and subsequently a SMS validation phase is performed to link the smartphone number to the user ID. The user afterwards provides the place of their quarantine so that the app can detect if the GPS location of the user is outside the quarantine area. Next, the user sends the list of all the recorded encounters to the health authorities, which communicate the infection to the encountered users.

The data related to the quarantine place and the respective GPS logs do not leave the smartphone. The general data retention is fixed for as long as required for the state emergency period. The smartphone number is stored for up to 180 days. The details of encounters is stored for 21 days.

Data processing The details regarding the privacy policy of the app and its compliance with the GDPR can be found in the document [86] . The app communicates with servers in the EU and US. The user's consent is required for the processing and sharing of the data, the latter being accessible by the Slovak government and the health authorities.

Several other European countries are in the process of developing apps to help the fight against COVID-19. All the apps are meant to be used on a voluntary basis.

The government asked nine national companies to develop a privacy-preserving contact tracing app [87] based on BLE. The system's architecture would be based on the decentralised DP-3T approach.

Finland The companies Reaktor, Futurice and Fraktal were asked by the Finnish government to develop a contact tracing app, called Ketju [88] , based of BLE. Finland opted for the decentralised DP-3T approach.

Ireland The government, the Department of Health, and the national HSE 13 have joined forces on the development of a contact tracing app based on BLE. The Irish government published an overview of the proposed app [89] and the different technological choices such as the use of the decentralised Google/Apple API.

The Netherlands The government announced [90] that they are studying the possibilities in terms of mobile apps to help the fight against COVID-19, but no concrete app has been communicated yet. Note however that an unofficial Dutch app, called PrivateTracer [91] , has been developed as an initiative of the non-profit, open-source, public-private partnership PrivateTracer.org. It is based on the DP-3T approach and its source code can be found on GitLab [92] .

The government are deploying a contact tracing app, called SwissCovid. The BLE-based app has been developed by ETH Zurich and EPFL, and follows the decentralised Google/Apple framework. It is currently available only to the users participating to a pilot phase [12] .

U.K. The government announced that the NHS 14 digital department is currently deploying a contact tracing app, called NHS COVID-19 [93] . The app uses BLE and it is available for Android 8+ and iOS 11+. It is based on a centralised approach and its source code can be found on GitHub [94] . It is currently under a testing phase on the Isle of Wight [95] .

So far 15 , Belgium has decided to abandon the potential use of a contact tracing app. In fact, the country thinks that only a small amount of the population would use such an app, thus rendering the app inefficient in the fight against COVID-19. In the same vein, Sweden has no plans to develop or adopt any mobile app regarding the COVID-19 emergency.

The work at hand provides a state-of-the-art and, to the best of our knowledge the first of its kind, review of the digital contact tracing apps ecosystem. Its contribution is threefold. First, it offers a succinct, but full-fledged review and classification of the hitherto complete frameworks proposed to realise such a service. Second, it details on and categorises the contact tracing apps already deployed by European countries. Lastly, it offers a generic adversary model, which not only conflates the relevant literature, but also delivers fresh perspectives to analysing such systems both from a security and data protection viewpoints. The current work can be used as a reference to anyone interested in better grasping the diverse facets of this rapidly evolving and timely area. It is also anticipated to stimulate and foster research efforts to the development of solutions that equally focus on the technological and data protection aspects.

Contact tracing

Commission Recommendation 2020/518 of 8 April 2020 on a common Union toolbox for the use of technology and data to combat and exit from the COVID-19 crisis, in particular concerning mobile applications and the use of anonymised mobility data

Communication from the Commission -Guidance on Apps supporting the fight against COVID-19 pandemic in relation to data protection (2020/C 124 I/01)

DP-3T, Decentralized Privacy-Preserving Proximity Tracing," source: github.com

Pan-European Privacy-Preserving Proximity Tracing

Decentralized Privacy-Preserving Proximity Tracing

Aims of the Decentralized Privacy-Preserving Proximity (DP-3T) Project

Cuckoo Filter: Practically Better Than Bloom

ENExposureConfiguration

Privacy-Preserving Contact Tracing -Apple and Google

Apple and Google update joint coronavirus tracing tech to improve user privacy and developer flexibility

First pilot for the Google and Apple-based decentralised tracing app

Security Analysis of the COVID-19 Contact Tracing Specifications by Apple Inc. and Google Inc

PEPP-PT, Pan-European Privacy-Preserving Proximity Tracing, Data Protection and Information Security Architecture, Illustrated on German Implementation

ROBERT: ROBust and privacy-presERving proximity Tracing

The OAuth 2.0 Authorization Framework

BlueTrace Protocol

TraceSecure: Towards Privacy Preserving Contact Tracing

DESIRE -3rd-way proposal for a European Exposure Notification System

TCN Coalition

Privacy and the pandemic: UW and Microsoft researchers present a "PACT" for using technology to fight the spread of COVID-19

PACT: Privacy sensitive protocols And mechanisms for mobile Contact Tracing

PACT: Private Automated Contact Tracing

Fully Private Open Source Contact Tracing Technology

Whisper Tracing -an open and privacy first protocol for contact tracing

Centralized or Decentralized? The Contact Tracing Dilemma

Pandemic Contact Tracing Apps: DP-3T, PEPP-PT NTK, and ROBERT from a Privacy Perspective

2020, source: gitlab.inria.fr

OpenTrace source code," source: github.com

PACT UW -CovidSafe source code

TCN source code," source: github.com

OpenCovidTrace source code," source: github.com

Exposure Notification Reference Server source code," source: github.com

Exposure Notifications Android Reference Design source code," source: github.com

PEPP-PT documentation

PEPP-PT NTK core Android source code," source: github.com

PEPP-PT NTK sample Android app source code," source: github.com

Proximity Tracing Approaches Comparative Impact Analysis

DESIRE: A Practical Assessment

Security and privacy analysis of the document 'PEPP-PT: Data Protection and Information Security Architecture

Security and privacy analysis of the document 'ROBERT: ROBust and privacy-presERving proximity Tracing

Analysis of DP-3T

Analysis of DP-3T: Between Scylla and Charybdis

Towards Defeating Mass Surveillance and SARS-CoV-2: The Pronto-C2 Fully Decentralized Automatic Contact Tracing System

Exposure Notification, Cryptography Specification

The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA

Delayed Authentication: Preventing Replay and Relay Attacks in Private Contact Tracing

Breaking BLE Beacons For Fun But Mostly Profit

Contact Tracing BLE sniffer PoC

Tracking Anonymized Bluetooth Devices

Privacy Considerations for Internet Protocols

Anonymity and closely related terms in the cyberspace: An analysis by example

The Social-Engineer Toolkit (SET)

Bettercap

2020, source: www.roteskreuz.at

CovTracer, Ensuring Privacy -Assuring Public Health," source: covid-19.rise.org.cy

eRouška -chráním sebe, chráním tebe," source: erouska.cz

source: economie.gouv.fr

App open-source project

VírusRadar -a Koronavírus követéséreés a COVID-19 elleni védekezésre

source: immuni.italia.it

Apturi Covid," source: apturicovid.lv

Together we can fight coronavirus -download the Smittestopp app

Życie po kwarantannie -przetestuj ProteGO

ZostanZdravy (StayHealthy

Datenschutzinformation zur Stopp Corona App

2020, source: github.com

Private Kit: Safe Paths; Privacy-by-Design COVID-19 Solutions using GPS+Bluetooth for Citizens and Public Health Officials

CovTracer Privacy Policy

eRouška -Ochrana soukromí a cookies

source: erouska.cz

Délibération no 2020-046 du 24 avril 2020 portant avis sur un projet d'application mobile dénommée StopCovid

Délibération no 2020-056 du 25 mai 2020 portant avis sur un projet de décret relatifà l'application mobile dénommée StopCovid

StopCovid France Bug Bounty Program," source: yeswehack.com

Corona-Warn-App source code

Corona-Warn-App: Privacy notice," source: coronawarn.app

2020, source: github.com

Apturi Covid source code," source: github.com

source: apturicovid.lv

Polish Ministry of Digital Affairs

ZostanZdravy (StayHealthy) -Podmienky ochrany súkromia

How do you trace COVID-19 while respecting privacy

Ketju warns of the risk of contagion and alerts you about potential exposure

Dáil Statement and Briefing for Minister Harris, National app for COVID-19

Dutch Ministry of General Affairs

PrivateTracer source code," source: gitlab.com

source: covid19.nhs.uk

Coronavirus test, track and trace plan launched on Isle of Wight

The authors declare that there is no conflict of interest regarding the publication of this paper.

Authors would like to thank Massimiliano Gusmini for the figures.