TraceCORONA is a system framework for anonymous distributed contact tracing of users with the help of a mobile app. The idea is that users participating in the system download and install the TraceCORONA app that records proximity contacts between users with the help of Bluetooth LE. Contrary to many other proposed approaches, TraceCORONA performs contact tracing anonymously, making tracking of individual users of the system impossible. TraceCORONA is designed in a way that it can connect with a secure health service platform offering users the opt-in possibility to receive other private health-related sevices in a secure and trustworthy manner.
Below we provide an overview of how TraceCORONA works and how it can achieve anonymous and decentralised tracing of user contacts. We also provide an overview and comparison of TraceCORONA to other app solutions that have been proposed and partially deployed all over the world during the last months and weeks.
Scenario
All proposed approaches aim at tracing the contacts of an infected individual in a similar setting. Typically there are two main parties: a server and users. However, in a real-world pandemic a number of other stakeholders can be involved such as Centres for Disease Control (CDC), hospitals, physicians, authorities, red cross, heath insurances and other health organizations.
TraceCORONA System Overview
The TraceCORONA system involves three different kinds of components as shown in the system overview in Fig. 1:
TraceCORONA Server
Operated by entity running the TraceCORONA infrastructure
TraceCORONA Apps
Installed voluntarily by participating Smartphone users
Health Authority
Public entity performing authorized Coronavirus tests
The TraceCORONA system’s operation consists of following distinct activities which we describe in detail below:
- Establishing encounter tokens
- Verification of infected users
- Encounter token upload
- Encounter token download and contact verification
- (optional, opt-in) Voluntary sharing of contact data for epidemiologic research
Users of TraceCORONA download and install the TraceCORONA App on their smartphones. During installation users do not need to register nor provide any personal information about themselves. For efficiency reasons, users may be asked to provide coarse-grained information about the area in which they are located (e.g., a postal code). This information is not used for identifying the user but merely to filter the Encounter Tokens that individual users need to download and check later on when performing Contact Tracing.
Encounter Tokens
The TraceCORONA App uses Bluetooth LE to sense the presence of other App users nearby. Each TraceCORONA App advertises a random ephemeral (i.e., it is changed frequently) cryptographic token which can be sensed by other devices within Bluetooth LE range.
Two users Ui and Uj use their mutually sensed cryptographic tokens to establish an Encounter Token that uniquely identifies the encounter between Ui and Uj at that point in time. This is done using the so-called Elliptic Curve Diffie-Hellman (ECDH) key exchange algorithm.
Infection Verification
App user Ui gets a Coronavirus test at a testing centre run by the Health Authority and provides his phone number (or other contact information) to the health authority in order to receive the result of the test.
To verify the infection status of user Ui, following approach shown in Fig. 3 is used. If the test is positive, the Health Authority provides a Transaction Authentication Number (TAN) to user Ui (e.g., via SMS).
User Ui enters the TAN in his TraceCORONA App which then sends it to the Server.
The Server receives regularly a list of valid TANs from the health Authority and uses this list to verify the TAN provided by user Ui. The verified TAN acts as proof that Ui really has been tested positive for the Coronavirus and should thus be permitted to upload its Encounter Tokens for allowing other users to determine whether they have been in contact with Ui.
Note that the scheme can be operated in a fashion that the Server does not receive any information about the true identity of Ui. The contact information of Ui is therefore known only to the Health Authority.
Encounter Token Upload
After verifying its infection status, user Ui can choose to share his Encounter Tokens with other users in order to allow them to determine whether they have been in contact with user Ui.
For doing this, as shown in Fig. 4, user Ui uploads a list of encounter token hashes along with encrypted information about his infection status to the TraceCORONA Server.
Note that the uploaded Encounter Tokens do not contain any information about which users the Tokens are associated with. In fact, not even user Ui is able to determine which other users its Encounter Tokens are associated with.
Additionally, before uploading its Encounter Tokens, user Ui is free to remove any Encounter Tokens it does not want to share. For example, Ui could choose to omit specific Tokens generated during specific time periods or while visiting specific locations.
Encounter Token Download and Contact Verification
TraceCORONA Apps periodically download Encounter Tokens from the TraceCORONA Server in order to check whether they have had an encounter with a person that has been tested as infected with the Coronavirus. The overall procedure is shown in Fig. 5.
The TraceCORONA App of user Uj downloads the Encounter Tokens of an infected user Ui along with some encrypted information about the infection status of the Encounter Tokens’ originator.
User Uj‘s App verifies whether an encounter with Ui has taken place by comparing its Encounter Tokens to Ui‘s tokens. If there is a match, an encounter has taken place and user Uj is notified of this.
Optionally, user Uj can also decide to share its Encounter Tokens to other users. In this case, Uj‘s app will send the Encounter Tokens along with the encrypted status of the user (direct contact with infected person) to the Server for further distribution to other users.
Before sharing Encounter Tokens of users, the TraceCORONA Server will verify the encrypted infection status information. This way the Server makes sure that all shared Encounter Tokens indeed originate from an authentic contact chain originating from a user with a verified infection status.
Note that in practice user Uj will not know from which other user the Encounter Tokens it downloads originate, as the Encounter Tokens themselves are not linked to any identity or pseudonym of any of the involved users.
Voluntary Sharing of Contacts
For tracking the development of the epidemiological situation it is important that epidemiological researchers receive factual information about the contacts that infected persons have had with other persons.
By default, the TraceCORONA backend will not be able to derive any information about the contacts except their existence in the form of Encounter Tokens.
Contrary to other approaches like PEPP-PT in which the Central Authority will automatically receive information about contacts of infected users with other users, the decision to share information about a user’s contacts with infected persons is left to the discretion of the user in order to allow the users themselves to remain in charge of their privacy.
Opt-in Sharing
Optionally, the user of the TraceCORONA app can decide to share information about his contacts with infected persons with epidemiological researchers. The TraceCORONA app will then, after explicit approval by the user, transmit information about the observed contacts to an institution performing epidemiological research.
It is very important that the shared data based on which epidemiological research is done, is genuine, i.e., truthful, so that it can be relied on. Reporte data should therfore be verifiable in order to prevent malicious sabotage of the dataset based on which epidemiological models are developed. Otherwise, a malicious attacker could easily inject fabricated or maliciously modified information about contacts that have never taken place and thus lead to deterioration of the quality and accuracy of the models derived from the faked data.
TraceCORONA provides therefore the possibility to anonymously authenticate all encounters with infected persons claimed by a user reporting epidemiological data.
Privacy Properties
- The TraceCORONA system works with anonymous Encounter Tokens. This means that the TraceCORONA server receives neither information about the identity of the users involved, nor any contact details of the users. In particular, it is not possible for the server to determine which users have had contact with which other users. The determination of contacts is only possible for the apps of the people involved in the contact.
- Contacts also remain completely anonymous to users of the system. It is not possible for any user to use the Encounter Tokens he has collected to determine afterwards which other users he has been in contact with. The Encounter Tokens are specific to contacts, not to users.
- The cryptographic tokens beaconed by the apps are only valid for a short time and are continuously replaced with new tokens, so that an app cannot be tracked using the tokens it beacons.
- The TraceCORONA server only receives a list of valid TANs from the test laboratory or the health authority with which users can prove their infection status. No information about which persons the respective TANs are assigned to are provided to the server. The users are therefore completely anonymous to the TraceCORONA server. In particular, the server does not have any user contact details that would allow users to be identified.
Comparison to other Tracing App Solutions
China, South Korea and TaiwanChina, South Korea and Taiwan
Contact sensing technology
Detailed location data based on GPS positioning, Mobile Cell information, etc.
Required registration information for using App
Personally identifying information required (e.g. mobile phone number)
Collected data (client-side)
Fine-grained location (GPS, mobile cell, …)
Collected data (server-side)
Fine-grained location (GPS, mobile cell, …)
Anonymity
No anonymity towards service provider. Personally identifying information (e.g. phone number) is known to service provider.
Other functions
Tracking movements of individual persons for quarantine enforcement
China: Provides individual status for persons (Red, Yellow and Green). Movement restrictions imposed on persons based on their status
Specification / Implementation available?
N/A
MIT
MIT
Contact sensing technology
GPS (accuracy will be a big problem in indoor environments or big cities).
Required registration information for using App
None
Collected data (client-side)
Log of GPS coordinates is encrypted and stored locally on the smartphone of app user.
Collected data (server-side)
Location logs of infected persons
Anonymity
Infected persons release their location traces after removing sensitive places like home or workplace from the trace. This reduces, however, the utility of the system as it misses a lot of encounters (e.g., at workplace). Furthermore, location traces potentially still can reveal the true identity of the user if additional information (e.g. location traces from Google) is available.
Other functions
N/A
Specification / Implementation available?
Whitepaper on arXiv
Project webpage
OpenSource on github
Singapore (TraceTogether)
Singapore (Trace Together)
Contact sensing technology
Bluetooth (Requires location services to be enabled)
Required registration information for using App
Mobile phone number
Collected data (client-side)
Rolling pseudonyms (generated by the server) of encountered persons stored locally
Collected data (server-side)
App user identities based on phone number
Identities of persons who have encountered infected persons
Anonymity
No anonymity of user towards service provider. Service provider can link pseudonyms to personally identifiable information (phone number). Service provider can trace all contacts of infected persons.
Other functions
N/A
Specification / Implementation available?
Source code release on github.
Pan-European Consortium (PEPP-PT)
Pan-European Consortium (PEPP-PT)
Contact sensing technology
Bluetooth LE
Required registration information for using App
None
Collected data (client-side)
Rolling pseudonyms of encountered persons
Collected data (server-side)
App-IDs of registered apps and rolling pseudonyms associated with App-ID
Pseudonyms of persons who have encountered infected persons
Anonymity
Pseudonymous app IDs of all users are known to service provider and it can link these to encounters with infected persons. Movement tracing of infected persons is possible for a powerful attacker.
Other functions
N/A
Specification / Implementation available?
Will be published as OpenSource
Apple and Google
Apple and Google
Contact sensing technology
Bluetooth LE
Required registration information for using App
None
Collected data (client-side)
Rolling pseudonyms (in the form of a Rolling Proximity Identifier derived from a Daily Tracing Key) of the encountered persons.
Collected data (server-side)
The app-ID and Daily Tracing Keys (aka Diagnosis Keys) of infected persons
Anonymity
Cryptographic keys (Daily Tracing Keys) used as pseudonyms for all users’ Apps.
Infected users are not able to redact individual encounters or time periods after-the-fact, but are fully traceable for all days for which they release their Daily Tracing Keys (aka Diagnosis Keys). Movement tracing is possible for a powerful adversary.
Other functions
N/A
Specification / Implementation available?
Apple and Google Interface specification
Note: The Apple/Google approach is essentially the same as the DP-3T low cost design (design 1)
DP-3T (design 2)
DP-3T (design 2)
Contact sensing technology
Bluetooth LE
Required registration information for using App
None
Collected data (client-side)
Observed Ephemeral IDs of other Apps along with measurement metadata (coarse time, RSSI, duration)
Collected data (server-side)
Ephemeral IDs of infected persons
Anonymity
Frequently-changing Ephemeral IDs used as user pseudonyms
Infected users can redact Ephemeral IDs for specific time periods after-the-fact.
Other functions
Voluntary (opt-in) sharing of epidemiological data about contacts by users. Epidemiological data are unverified.
Specification / Implementation available?
DP-3T documentation
DP-3T github
TraceCORONA
TraceCORONA
Contact sensing technology
Bluetooth LE
Required registration information for using App
None
Collected data (client-side)
Cryptographic encounter tokens established between two apps in proximity
Collected data (server-side)
App-ID of infected persons
Anonymity
Uses no pseudonymous keys. Each individual encounter receives a person-to-person and encounter-specific Encounter Token. Infected users are able to redact any sensitive encounters they wish ater-the-fact.
Only participants of an encounter can identify that an encounter has taken place. Movement tracing is not possible even for a powerful adversary (see below for attack description)
Other functions
Voluntary (opt-in) sharing of epidemiological data about contacts by users. Epidemiological data can be verified.
Users can optionally choose to use add-on services like a secure messaging service and secure document exchange for secure and trusted interactions with entities like CDC, health professionals or testing centres.
Additional functionality is fully optional and can be operated independently from contact tracing functionality.
Specification / Implementation available?
For a technical description of TraceCORONA, please see here.
Tracing functionality will be published as OpenSource Software in May 2020 (tentatively).
Technology Features
Other Approaches
In addition to the approaches presented above, there are currently many other app development projects underway. At least 28 states are reported to have launched the development of such apps, including 11 European countries.
Comparison of anonymity properties
As shown above, there are currently numerous contact tracing apps and approaches that have been proposed during the recent weeks. Some of them that claim to aim at high privacy and data protection standards are currently being lively debated in Europe and the US.
Here, we provide the summary of a detailed comparative analysis of the privacy-preservation features of these proposed approaches that are in the middle of the ongoing discussion.
Summary of a comparative study of contact tracing approaches
Possible Attacks
Adversary Model
The goals of an attacker against a tracing system can be diverse: recovering the real identity of the involved users, linking data related to individuals (e.g., location data), or leaking any other personal data, as well as tampering with data, e.g., to falsify the results of contact tracing.
The attacker can be any stakeholder involved in the overall system, such as a user, a service provider, or any other organization. The attacker can have access to various resources. For instance a Powerful Attacker has access to a mesh of observation nodes in a particular area where the users move. Observation nodes are any devices (e.g., smartphones) that can perform Bluetooth sensing to collect observations of the pseudonyms / proximity identifiers / encounter tokens that users’ tracing Apps beacon into their vicinity. With such Bluetooth observations the attacker can potentially trace the user’s presence at and movements between the locations where the attacker’s sensing nodes are. This attack is high effort as it requires physical presence at multiple locations and requires considerable resources to perform.
| China, South Korea and Taiwan | Misuse by service provider: The service provider is able to reconstruct a location trace of individual users that are linkable to the true identities of users |
| MIT | If redaction of sensitive places is not done properly, users become easily identifiable through their home and workplace locations. Even redacted data may allow de-anonymisation if location traces of users are combined with movement traces that, e.g., Google has on its users. The more comprehensively the redaction of individual (sensitive) locations is performed, the more negatively this impacts the utility of the system |
| Singapore | Misuse by service provider: The service provider is able to trace all contacts of infected persons and can connect these to the true identities of users through their phone number |
| Pan-European consortium (PEPP-PT) | 1. Misuse by service provider: The service provider is able to trace all contacts of infected persons and has information about their associated App IDs. Possible de-anonymisation attacks possible when Apps connect to server to fetch their push-notifications by using out-of-band mechanisms like following back the IP address from which users are connecting to the server to retrieve data. 2. Powerful attacker*: A powerful attacker can trace infected user’s movements at specific locations. |
| Apple and Google | Powerful attacker*: Infected person’s movements can be traced‡ by a powerful attacker with the help of the released Daily Tracing Keys (aka Diagnosis Keys) of the infected user. Infected users have to share their location traces in an all-or-nothing fashion for each day. Selective redaction of sensitive locations or fine-grained time periods is not possible‡. If infected person shares its Daily Tracing Keys (aka Diagnosis Keys), all movements of the person at specific locations† can be traced for that day. |
| TraceCORONA | Powerful attacker*: Infected person’s movements can not be traced even by a powerful attacker. This is because encounter tokens are anonymous and thus can not be connected to a particular user or app pseudonym. Adversary is thus not able to connect individual encounters with other encounters of the same person making tracing of movement patterns infeasible. In addition, infected users can choose which encounters they want to share and selective redaction of encounters in sensitive locations is possible. Also redaction of encounters for fine-grained time periods is possible. |
| A note on MAC address tracing | It is known that smartphones with enabled Bluetooth can be traced with the help of the Bluetooth interface’s MAC address. A powerful attacker* could use this technique to trace users at specific locations†. Howerver, newer smartphone models perform periodically MAC address rotation (i.e., changing of the MAC address to a new value) to thwart such tracing attacks. |
* In the above scenarios a Powerful Attacker denotes an entity that has access to a mesh of observation nodes in a particular area where the users move. Observation nodes are any devices (e.g., smartphones) that can perform Bluetooth sensing to collect observations of the pseudonyms / proximity identifiers / encounter tokens that users’ tracing Apps beacon into their vicinity. With such Bluetooth observations the attacker can potentially trace the user’s presence at and movements between the locations where the attacker’s sensing nodes are. This attack is high effort as it requires physical presence at multiple locations and requires considerable resources to perform.
† specific locations refers to the locations where a powerful attacker has his observation nodes.
Contact
Prof. Dr.-Ing. Ahmad-Reza Sadeghi
Follow us on Twitter: @RealSystemSec