Introduction

This documentation is a work in progress. You can support us on GitHub.

The documentation is split into 3 parts. The general documentation on the actual page and the documentation for the React Native library and the Backend API.

Protocol comparison

In this document, multiple decentralized protocols are compared. This document is an attempt to explain the differences between these protocols in a way that is simple to understand. Please refer to the linked documents for more detailed information. Ideally, the protocol should have the following properties (taken from the TCN README):

• Server Privacy: An honest-but-curious server should not learn information about any user's location or contacts.
• Source Integrity: Users cannot send reports to users they did not come in contact with or on behalf of other users.
• Broadcast Integrity: Users cannot broadcast TCNs they did not generate.
• No Passive Tracking: A passive adversary monitoring Bluetooth connections should not be able to learn any information about the location of users who do not send reports.
• Receiver Privacy: Users who receive reports do not reveal information to anyone.
• Reporter Privacy: Users who send reports do not reveal information to users they did not come in contact with, and reveal only the time of contact to users they did come in contact with. Note that in practice, the timing alone may still be sufficient for their contact to learn their identity (e.g., if their contact was only around one other person at the time).

A Strawman Protocol

The Strawman Protocol as specified by TCN is one of the simplest approaches when it comes to contact tracing.

Summary

Random IDs are generated and broadcasted by each device. These IDs are rotated frequently. In case of an infection, all the IDs broadcasted during the time of infectiousness are published.

Benefits

• Tracking devices is only possible while the IDs are constant. Frequent rotation of the ID makes tracking unfeasible. Subsequent IDs are independently generated.
• Implementation is trivial.

Caveats

• Everyone can upload the IDs broadcasted by other devices. This means that everyone could notify contacts of people they received an ID from (no Source Integrity).
• The amount of data downloaded by each client grows linearly with the amount of users who upload reports
• Only a single-bit of information can be transferred (whether the ID is reported or not).

STRICT

STRICT is a protocol that has been developed during the #WirVsHackathon independently by multiple teams. It fixes the Source Integrity caveat of the strawman protocol.

Summary

Random IDs are generated. These IDs are rotated frequently. A cryptographic hash of this ID is broadcasted by each device. In case of an infection, all the (non-hashed) IDs broadcasted during the time of infectiousness are published.

Benefits

• Tracking devices is only possible while the IDs are constant. Frequent rotation of the ID makes tracking unfeasible. Subsequent IDs are independently generated.

Caveats

• The amount of data downloaded by each client grows linearly with the amount of users who upload reports
• Only a single-bit of information can be transferred (whether the ID is reported or not).

Apple-Google-Proposal

The proposal made by Apple and Google was published on the 10th of April 2020.

Summary

A random, permanent ID is generated on the device. Each day, a daily ID is generated by computing the hash of the permanent ID and the date. From these daily IDs, multiple “Rolling Proximity IDs” are derived from the daily IDs, a time interval number and a fixed string. In case of an infection, all the daily IDs used during the time of infectiousness are published. All “Rolling Proximity IDs” are then derived by each client for the local comparison.

Benefits

• The amount of data is reduced by publishing the data used for deriving keys instead

Caveats

• A reported user can be tracked from the first day he was infectious to the day the report was published when an adversary collects IDs in multiple locations.
• The amount of data downloaded by each client grows linearly with the amount of users who upload reports
• Only a single-bit of information can be transferred (whether the ID is reported or not).

DP-3T Design 1: Low-cost decentralized proximity tracing

This protocol by the DP-3T group was published on the 3rd of April 2020.

Summary

A random ID is generated on each device. Each day, this ID is replaced with an ID derived from this ID. From these daily IDs, the Broadcast IDs for the day are derived. In case of an infection, the first “infectious” daily ID is published. All subsequent IDs are then derived by each client for the local comparison.

Benefits

• The amount of data is reduced by publishing the data used for deriving keys

Caveats

• A reported user can be tracked from the first day he was infectious to the day the report was published when an adversary collects IDs in multiple locations.
• The amount of data downloaded by each client grows linearly with the amount of users who upload reports
• Only a single-bit of information can be transferred (whether the ID is reported or not).

DP-3T Design 2: Unlinkable decentralized proximity tracing

Summary

Random IDs are generated. These IDs are rotated frequently. A cryptographic hash of this ID is broadcasted by each device. In case of an infection, the source IDs are uploaded to a server. The server recreates the broadcasted IDs. To notify potentially infected users, the server doesn't reveal the neither the source IDs nor the broadcasted IDs. Instead, a cuckoo filter (a probabilistic data structure) containing the broadcasted IDs is generated and published. This probabilistic data structure reduces the amount of data that has to be published and doesn't allow adversaries to pick up a specific ID out of the filter.

Benefits

• Tracking devices is only possible while the IDs are constant. Frequent rotation of the ID makes tracking unfeasible. Subsequent IDs are independently generated.
• A smaller amount of data has to be published.

Caveats

• There is a false-positive rate associated with cuckoo filters. This means that there is a chance (albeit a small one) that a user might get a notification that he is at risk even though he didn't encounter an infectious person.
• Only a single-bit of information can be transferred (whether the ID is reported or not).

TCN

Summary

The device generates a key pair (a public and a private key). This keypair is rotated frequently. Temporary contact numbers (TCNs) are derived from the public key and broadcasted. In case of an infection, the device generates a report containing a memo field and information that can be used to recreate the relevant TCNs. The memo field can contain arbitrary information such as the type of pathogen or the type of report and can be used by health authorities to authorize the report. The report is signed with the private key and published.

Benefits

• A memo field can be transmitted. This memo field is important for describing what is being reported and can be used to authorize reports.

Caveats

• The amount of data downloaded by each client grows linearly with the amount of users who upload reports