BlueTrace

Developed by	Singapore Government Digital Services
Introduced	March 24, 2020 (2020-03-24)
Industry	Digital contact tracing
Compatible hardware	Android & iOS smartphones
Physical range	~10 m (33 ft)[1]
Website	bluetrace.io

BlueTrace is an open-source application protocol that facilitates digital contact tracing of users to stem the spread of the COVID-19 pandemic.^[2] Initially developed by the Singaporean Government, BlueTrace powers the contact tracing for the TraceTogether app.^[3][4] Australia and the United Arab Emirates have already adopted the protocol in their gov apps,^[5][6][7] and other countries were considering BlueTrace for adoption.^[8][9] A principle of the protocol is the preservation of privacy and health authority co-operation.^[10]

Overview

Preservation of user privacy was one of the core considerations around which BlueTrace was designed. To achieve this, personal information is collected only once at the point of registration and is only used to contact potentially infected patients. Additionally, users can opt-out at any time, clearing all personal information and rendering any recorded data untraceable. Contact tracing is done entirely locally on a client device using Bluetooth Low Energy, storing all encounters in a contact history log chronicling encounters for the past 21 days. Users in the contact log are identified using anonymous time-shifting "temporary IDs" issued by the health authority. This means a user's identity cannot be ascertained by anyone except the health authority with which they are registered. Additionally, since temporary IDs change on a regular basis, malicious third parties cannot track users by observing log entries over time.

Once a user tests positive for infection, the health authority requests the contact log. If the user chooses to share their log, it is sent to the health authority where they match the temporary ID with contact information. Health authorities are not able to access log entries about foreign users, so those entries are sent to the appropriate foreign health authority to be processed there. Once a log has been processed, the health authority contacts the user identified by the record.

Technical specification

Sequence diagram describing the BlueTrace protocol

The protocol is focused on two areas: locally logging registered users in the vicinity of a device and the transmission of the log to the operating health authority, all while preserving privacy. To achieve this, the protocol can be divided into the areas of device to device communication (DDC), and device to reporting server communication (DRSC).

The DDC component operates on top of the existing Bluetooth Low Energy protocol, defining how two devices acknowledge each other's presence.^{[10]: p. 2} The DRSC component uses HTTPS to communicate a timeline of visits to a centralized server owned by a health authority once a user has tested positive for an infection. The health authority can then, using the log, notify the users who came in contact with the infected patient.^{[10]: p. 2}

Device to reporting server communication protocol

Each app implementing the BlueTrace protocol has a corresponding central reporting server operated by a health authority. The reporting server is responsible for handling initial registration, provisioning unique user identifiers, and collecting contact logs created by the DDC part of the protocol. When the user first launches a BlueTrace app, they will be asked for their internationally formatted phone number and are assigned a static UserID.^{[10]: section. 4} This phone number is later used if the user has registered an encounter in an infected patient's contact log.

Once registered, users are provisioned Temporary IDs (TempID) uniquely identifying them to other devices. Each TempID has a lifetime of 15 minutes to prevent malicious parties from performing replay attacks or tracking users over time with static unique identifiers.^{[10]: section. 4.2} TempIDs are generated from a user's UserID, the TempID start time, and the TempID expiry time, which is encrypted and turned into a Base64 encoded string by the server using a secret symmetric encryption key. To ensure devices have a constant supply of TempIDs, even in an unstable network environment, TempIDs are transmitted to devices in forward dated batches.^{[10]: section. 4.2} The composition of a TempID is shown below:

BlueTrace TempID packet composition

Once a user has been tested positive for infection, the health authority generates a PIN authenticating the user to upload their contact log to the reporting server. As part of the log, metadata about each encounter is included; the most important of which being the timestamp and health authority identifier (HAI).

The HAI identifies to which health authority the logged contact reports. If the HAI represents a foreign health authority the log entry is transmitted to the identified authority to be processed there.

Once a health authority has filtered log entries to only include home clients, they decrypt the TempID to reveal the UserID, start time, and expiry time. The start and expiry date are compared with the encounter timestamp to ensure validity, and the UserID is matched to a phone number. The health authority can then contact the phone number to inform a user of potential contact with an infected patient.

{
	"id": "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==", // TempID
	"md": "iPhone X", // Device model
	"rc": -60, // Signal strength
	"o": "IJ_HAI", // Health authority identifier
	"v": 2 // Protocol version
}

Health authority cooperation

BlueTrace Health Authority Cooperation

The cooperation between separate health authorities is a core component of the BlueTrace protocol, and it is designed such that multiple authorities can work together without revealing personal information to foreign authorities with which a user is not registered. Since each authority maintains its separate encryption key and user records, a health authority can't decrypt and see a foreign user's data.

To ensure log entries are sent to the correct authority, part of the DDC handshake contains a health authority identifier (HAI), a unique string assigned to registered health authorities. Once a foreign health authority's log entry is identified, the receiving health authority transmits the log entry to the foreign authority's reporting server where it is verified, and a static PseudoID is returned.

The PseudoID is a salted cryptographic hash of the UserID, designed to allow foreign health authorities to perform statistical analysis on contact logs and communicate about a specific user without revealing unnecessary personal information. Once the PseudoID is assessed to have been in close contact with the infected patient, the foreign health authority that issued the PseudoID is informed and can follow up as necessary.

Withdrawal of consent

The ability of users to withdraw consent to the use and collection of their data at any time was an important consideration in the design of the protocol.^{[10]: section. 3, point. 4} To allow this, personally identifiable information is excluded from the DDC component of the protocol. This means the only place personal information is stored is on the reporting server, where it is associated with an anonymous static UserID. This UserID (encrypted in a TempID) is what is used for identification in the DDC part of the protocol. If a user withdraws consent, the user record is deleted from the reporting server, meaning UserIDs obtained through contact logs can no longer be matched to a phone number.

Controversy

One of the largest privacy concerns raised about protocols such as BlueTrace or PEPP-PT is the usage of centralised report processing.^{[12][13][14][15][16][17]} In a centralised report processing protocol, a user must upload their entire contact log to a health authority administered server, where the health authority is then responsible for matching the log entries to contact details, ascertaining potential contact, and ultimately warning users of potential contact.^[18]

Alternatively, decentralised report processing protocols, while still having a central reporting server, delegate the responsibility to process logs to clients on the network. Protocols using this approach, such as TCN and DP-3T, have the client upload a number from which encounter tokens can be derived by individual devices. Clients then check these tokens against their local contact logs to determine if they have come in contact with an infected patient.^[19] Inherent in the fact the protocol never allows the government access to contact logs, this approach has major privacy benefits. However, this method also presents some issues, primarily the lack of human in the loop reporting, leading to a higher occurrence of false positives;^[18] and potential scale issues, as some devices might become overwhelmed with a large number of reports. Decentralised reporting protocols are also less mature than their centralised counterparts.^[20][21][22]

OpenTrace

OpenTrace is the open-source reference implementation of BlueTrace released under the GPL-3.0 license.^[23][24][25] The DRSC side of the protocol is implemented using the Firebase platform,^[26] using Firebase functions, a serverless computing framework, for all client calls; and Firebase Secret Manager^{[27]: lines 29–37} and Storage^{[28]: line 22} for storing the encryption key and contact logs respectively. For the app/DDC side of the protocol, a modified version of the TraceTogether app for Android and iOS devices is included.^[29][30]

See also

• TraceTogether
• TCN Protocol
• Pan-European Privacy-Preserving Proximity Tracing
• (Google/Apple) Exposure Notification (GAEN)

References

External links

• White paper
• OpenTrace GitHub
• BlueTrace homepage