Journal:BlueTrace: A privacy-preserving protocol for community-driven contact tracing across borders

Full article title	BlueTrace: A privacy-preserving protocol for community-driven contact tracing across borders
Author(s)	Bay, Jason; Kek, Joel; Tan, Alvin; Hau, Chai S.; Yongquan, Lai; Tan, Janice; Quy, Tang A.
Author affiliation(s)	Singapore's Government Technology Agency
Primary contact	Email: info at bluetrace dot io
Year published	2020
Page(s)	1–9
Distribution license	Reproduced with written permission
Website	https://bluetrace.io/
Download	https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf (PDF)

Abstract

TraceTogether is the first national deployment of a Bluetooth-based contact tracing system in the world. It was developed by Singapore’s Government Technology Agency and the Ministry of Health to help the country better respond to epidemics.

Following its release, more than 50 governments have expressed interest in adopting or adapting TraceTogether for their countries. Responding to this interest, we are releasing an overview of BlueTrace, the privacy-preserving protocol that underpins TraceTogether, as well as OpenTrace, a reference implementation.

OpenTrace comprises the source code for an iOS app, an Android app, a cloud-based backend, and baseline signal strength calibration data. This will be made available to the open source community at github.com/opentrace-community on 9 April 2020.

Context

Contact tracing is an important tool for reducing the spread of infectious diseases. Its goal is to reduce a disease’s effective reproductive number (R) by identifying people who have been exposed to the virus through an infected person and contacting them to provide early detection, tailored guidance, and timely treatment. By stopping virus transmission chains, contact tracing helps “flatten the curve” and reduces the peak burden of a disease on the healthcare system. Contact tracing forms an essential part of Singapore’s response to the COVID-19 pandemic.

Overview of BlueTrace

BlueTrace is a protocol for logging Bluetooth encounters between participating devices to facilitate contact tracing, while protecting the users’ personal data and privacy.

When two participating devices encounter each other, they exchange non-personally identifiable messages that contain temporary identifiers. The identifiers rotate frequently to prevent third parties from tracking users. The user’s encounter history is stored locally on their device; none of this data can be directly accessed by the health authority.

If a user is infected or is the subject of contact tracing, they will be asked to share their encounter history with the relevant health authority with the use of a PIN. (A verification code may optionally be provided, to authenticate the health authority official’s request.) Only the health authority has the ability to decrypt the shared encounter history to obtain and use personally-identifiable information and to subsequently filter for close contacts and notify potentially infected users.

BlueTrace is designed to supplement manual contact tracing by addressing its key limitation: an infected person can only report contacts they are acquainted with and remember having met. BlueTrace could also allow for contact tracing to be more scalable and less resource-intensive.

BlueTrace also allows a federated network of credentialed health authorities to each maintain distinct user bases, while allowing for contact tracing between users from different health authority jurisdictions (more later in the section "Federation and interoperability").

Data protection and privacy safeguards

We believe that even during pandemics, public health and personal privacy should not be a binary choice. BlueTrace is designed to safeguard user privacy and give users control of their data. The protocol includes the following privacy safeguards:

• Limited collection of personally-identifiable information: The only personally-identifiable information collected is a phone number, which is securely stored by the health authority.
• Local storage of encounter history: Each user’s encounter history is stored exclusively on their own device. The health authority only has access to this history when an infected person chooses to share it.
• Prevention of third-party tracking: Third parties cannot use BlueTrace communications to track users over time. A device’s temporary identifier rotates frequently, preventing malicious actors from tracking individual users over time by sniffing for BlueTrace messages.
• Revocable consent: Users have control of their personal data. When they withdraw consent, all personally-identifiable data stored at the health authority is deleted. All encounter history will thus cease to be linked to the user.

How BlueTrace works

User registration and assignment of UserID

When the user of a BlueTrace-implementing app registers with their phone number, the back-end service generates a unique, randomised UserID and associates it with the user’s phone number (Figure 1).

Figure 1. User registration

Phone numbers are the only personally-identifiable information required from the user. The phone numbers are used to contact users if they are found to have had prolonged exposure to an infected person. Alternative implementations of BlueTrace that do not require a phone number are possible, however. These might rely on push notification tokens to alert individual users (see the next section "Protocol design considerations").

Generation of TempIDs

BlueTrace devices log encounters with each other by exchanging messages over Bluetooth. To protect users’ privacy, these messages cannot reveal a user's identity. Additionally, in order to prevent users from being tracked over time by third parties, these messages cannot contain static identifiers. However, when an infected user uploads these messages to the health authority, the authority must be able to obtain contact information from the messages.

BlueTrace addresses this by having users exchange temporary IDs (TempIDs). Each TempID comprises a UserID, created time, and expiry time encrypted symmetrically with AES-256-GCM and then Base64-encoded (Figure 2). Only the health authority holds the secret key to encrypt and decrypt TempIDs. Each TempID is generated with a random initialisation vector (IV).

Figure 2. Format of TempID

TempIDs have a short lifetime (we recommend 15 minutes). This helps to mitigate the impact of replay attacks by reducing the window of opportunity for exploitation. If malicious users impersonate other users by rebroadcasting their messages, they will only be able to do so for a short time before the message expires. This duration would likely be below the threshold duration of close contact, and hence not result in false positives (more later in the section "Encounter Message replay/relay attacks").

In order to ensure that devices have a supply of valid TempIDs even when the internet connection is unstable, devices pull batches of forward-dated TempIDs from the health authority’s back-end service each time (Figure 3).

Figure 3. TempIDs sent to device

Notes

This presentation is faithful to the original, with only a few minor changes presentation. Some grammar was corrected for clarity.