User:Bravetheif/BlueTrace

BlueTrace

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

BlueTrace is an open source application protocol that facilitates digital contact tracing of infected participants. Initially developed by the Singaporean Government for the TraceTogether app and the 2019–20 coronavirus pandemic, it has since been considered for adoption by multiple other countries including New Zealand and Australia. A core principle of the protocol is the preservation of privacy and health authority cooperation.

Technical overview

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. 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.

Device to reporting server communication protocol

Each implementation of the BlueTrace protocol has a reporting server run by the health authority publishing the app. The reporting server is responsible for recording user information, provisioning unique user identifiers, and collecting device 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. This phone number is later used if the user is found 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. 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. 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 must be forwarded to the identified authority to be decrypted and processed there. Once a health authority has all the log entries it can access, they decrypt the TempID to reveal the details contained within. The start and expiry date is compared with the contact timestamp to ensure validity, and the UserID contained in the record 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.

Device to device communication protocol

The DDC part of the protocol defines how two devices communicate and log their contact. Each device is in one of two states, Central or Peripheral, on a duty cycle of around 1:4 respectively. In Peripheral mode, a device advertises it's presence, and in Central mode it scans for other devices in Peripheral mode. Additionally, certain devices are incapable of operating in Peripheral mode, and thus operate purely in Peripheral mode. Once two devices have discovered each other, they communicate a characteristic packet containing information about themselves. The packet is formed as a JSON file, containing the device's TempID, device model, HAI, and BlueTrace protocol version. When operating in Central mode the device additionally sends the strength of the signal, allowing the approximate distance between the two devices to be calculated later. These characteristics are then added to a local database on the device where they are stored for 21 days and can be sent to the reporting server later. The contacted device is also added to a local blacklist for two duty cycles in order to stop two devices repeatedly contacting each other, saving power and storage.

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 their own separate encryption key and user records, it is impossible for a health authority to 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.

Protocol example

This section outlines an example situation in which two devices from separate health authorities meet, and one user is later tested positive for an infection.

Device handshake

When two devices meet with one acting as Central, the other Peripheral, the Central device first reads the characteristic packet from the Peripheral:

{
	"id": "Fj5jfbTtDySw8JoVsCmeul0wsoIcJKRPV0 HtEFUlNvNg6C3wyGj8R1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==",
	"md": "Samsung S10+",
	"o": "FB_HAI",
	"v": "2"
}

In this example packet, the Peripheral device is a Samsung S10+ registered with the FooBar health authority, running version 2 of the protocol. Once Central has successfully read the packet, it writes it's own characteristic packet to the Peripheral device:

{
	"id": "FmFISm9nq3PgpLdxxYpTx5tF3ML3Va1wqqgY9DGDz1utPbw+Iz8tqAdpbxR1 nSvr+ILXPG==",
	"md": "iPhone X",
	"rc": "-60",
	"o": "IJ_HAI",
	"v": "2"
}

As Central, the rs or signal strength is also included in the packet to allow health authorities to calculate the approximate distance between the two devices. Both devices then store the encounter in a local database.

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. In order 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.

OpenTrace

OpenTrace

Original author(s)	Singapore Government Digital Services
Developer(s)	Singapore Government Digital Services
Initial release	10 April 2020 (2020-04-10)
Repository	github.com/opentrace-community
Written in	Kotlin Swift TypeScript
Operating system	Android, iOS
Platform	Firebase
Available in	English
Website	bluetrace.io

OpenTrace is the open source reference implementation of BlueTrace released under the GPL-3.0 licence. The DRSC side of the protocol is implemented using the Firebase platform, using Firebase functions, a serverless computing framework, for all client calls; and Firebase Secret Manager and Storage 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.

See also

• TraceTogether
• Bluetooth Low Energy

External links

• White paper
• OpenTrace GitHub
• BlueTrace homepage