Notes: COVID-19 Contact Tracing Technology

Published:
  Lastmod: 2023-01-16
by Ernest Chiang

(Context: Wherever we walk, you will leave traces, would we leave some sort of traces after nearby contact? Image source.)

Apple and Google jointly published a press release about: “Apple and Google partner on COVID-19 contact tracing technology” on April 10, 2020. Also provide APIs of both Apple iOS and Google Android platforms, and corresponding technical documents: Contact Tracing Bluetooth Specification 與 Contact Tracing Cryptography Specification.

I guess there could be some Flutter plugins based on it very soon. :)

This is a personal reading notes. I would like to start with privacy and Bluetooth specification documents. I want to learn and practice how to plan and organize such kind of solution architecture to resolve some challenges in the future.

The content of this reading notes will include my personal observation and comments. The purpose of taking notes is to improve my learning efficiency and keep the habit of sharing.

Doc List

First of all, here to list all the documents mentioned in both Apple and Google press release posts:

News Posts

Some media (probably most of them) had transformed the press release into some sort of visual form, which is convenient for the public to understand.

Key Takeaways

  • Explicit user consent required。
  • Doesn’t collect personally identifiable information or user location data
    • Originally the data matching works can be done on the cloud, but this time, privacy-preserving, all the matching works will happen on users’ mobile phone devices.
    • There are two kinds of data, one is beacon, the other is beacon key.
    • User can transmit his/her beacon key to a cloud of a public health organization with user consent.

Privacy-Preserving

Both Apple and Google care about maintaining user privacy. The first of the four documents cited by Google is about privacy: Privacy-safe contact tracing using Bluetooth Low Energy, attached with illustrations. Below are duplicated from the document and place my comments in brackets.

  • Explicit user consent required
  • Doesn’t collect personally identifiable information or user location data
  • List of people you’ve been in contact with never leaves your phone (I think it means the contact log data list will not be transmitted to another device by any communication methods. For example, they will not be (should not be) tranmitted to a cloud.)
  • People who test positive are not identified to other users, Google or Apple (The technical architecture planning spirit focuses on presenting factual information. Make witch hunting unnecessary for the public or third parties.)
  • Will only be used for contact tracing by public health authorities for COVID-19 pandemic management
  • Doesn’t matter if you have an Android phone or an iPhone - works across both

Please kindly download the 3-page PDF document and check out the illustrations of user scenarios on page 2 and page 3.

You will see there are two kinds of data in the scenarios: one is beacon, the other is beacon key.

Contact Tracing Bluetooth Specification

Once participated in a Bluetooth SIG Working Group, it should be reasonable to read a Bluetooth specification… (obviously it is a thirst for knowledge XDD)

Here are just my notes, if you are planning to work on something seriously, please do reference to the latest official documents.

v1.1, April 2020

On the first page of the cover, it says: “Preliminary - Subject to Modification and Extension”.

Contents on the second page

  • Overview
  • Definitions
  • Contact Detection Service
  • Advertisement Payload
  • Advertising Behavior
  • Advertising Flow
  • Scanning Behavior
  • Scan Power Considerations
  • Scanning Flow
  • Privacy

The table of contents looks like a lot of items, but in fact the entire PDF file is only 6 pages, and the cover and table of contents are deducted, leaving only 4 pages.

It is a very concise and easy-to-read Bluetooth specification file. You may want to download and read to taste it, and close your distance with Bluetooth :)

Overview

  • This document provides the detailed technical specification for a new privacy-preserving Bluetooth protocol to support Contact Tracing.
  • The Contact Detection Service is the vehicle for implementing contact tracing and uses the Bluetooth LE (Low Energy) for proximity detection of nearby smartphones, and for the data exchange mechanism.

Definitions

  • Contact Detection Service - The BLE service for detecting device proximity.
  • Tracing Key - A key that is generated once per device.
  • Daily Tracing Key - A key derived from the Tracing Key every 24 hours for privacy consideration.
  • Diagnosis Key - The subset of Daily Tracing Keys which are uploaded when the device owner is diagnosed positive for the COVID-19 virus. (Memo: If the app want to upload some data to the cloud with user consent, the data will be this Diagnosis Key.)
  • Rolling Proximity Identifier - A privacy preserving identifier derived from the Daily Tracing Key and sent in the bluetooth advertisements. It changes every ~15 minutes to prevent wireless tracking of the device.

Contact Detection Service

  • Contact Detection Service is a BLE service registered with the Bluetooth SIG with 16-bit UUID: 0xFD6F。
    • I checked on Bluetooth SIG official website for this 16-bit UUID List. This new UUID hasn’t appeared yet (April 11, 2020 23:50), and it’s curious which company it will belong to.
    • According to the time point on the list, this UUID may be distributed between 20/March/2020 and 02/April/2020. And temporarily hidden.
    • Here is a screenshot for reference:
    • Updated screenshot on 2020/May/06. The UUID is registered by Apple:
  • Rolling Proximity Identifier: 128-bit.
  • You can find Bluetooth Advertising AD Type definition at SIG official website.
    • 0x01: «Flags»
    • 0x03: «Complete List of 16-bit Service Class UUIDs»
    • 0x16: «Service Data - 16-bit UUID»
  • In current situation, most of the fields are fixed, except the Rolling Proximity Identifier (128-bit; 16-bytes) in Service Data which will be modified periodly.

Advertising Behavior

  • Advertisements are to be non-connectable undirected of type ADV_NONCONN_IND (Section 2.3.1.3 of 5.2 Core Spec).
  • The advertiser address type should be Random Non-resolvable.
  • On the platforms supporting Bluetooth Random Private Address with randomized rotation timeout interval, the advertiser address rotation period shall be a random value, greater than 10 minutes and less than 20 minutes.
  • The advertiser address and Rolling Proximity Identifier shall be changed synchronously so address and Rolling Proximity Identifier can not be linked.
  • A separate advertising instance should be used, if HW allows, to provide advertising reliability and flexibility in choosing optimal interval.
  • The advertising interval is subject to change, but is currently recommended to be 200-270 milliseconds.

Advertising Flow

Scanning Behavior

You get some devices doing advertising, then you need some devices doing scanning to receive these advertisment data. Here are the parts of Scanning.

  • Discovered Contact Detection Service advertisements shall be kept on the device.
  • Scan results shall be timestamped and RSSI-captured per advertisement. (RSSI value can be used to estimate the distance of the advertising device roughly.)
  • Scanning interval and window shall have sufficient coverage to discover nearby Contact Detection Service advertisers within 5 mins.
  • Scanning strategy that works best is opportunistic (leveraging existing wakes and scan windows) and with minimum periodic sampling every 5 mins.

Scan Power Considerations

  • Platforms running the Contact Detection Service should be designed to account for large volume of advertisers in public spaces that shall rotate their Random Non-resolvable address and Rolling Proximity Identifier frequently. (Memo: My team had tested 50~100 advertising devices in the same space before, the scanning result is quite okay. (It is another kind of user scenario, not contact tracing, but using same base Bluetooth Advertising technology) If there are more devices in the same space, you may consider to modify advertising interval dynamically.）
  • Wherever supported by HW and OS, Bluetooth controller duplicate filters and other HW filters should be used to prevent excessive power drain.

Scanning Flow

Privacy

  • Maintaining user privacy is an essential requirement in the design of this specification.
  • The Contact Tracing Bluetooth Specification does not use location for proximity detection. It strictly uses Bluetooth beaconing to detect proximity. (Memo: it is a really good decision.)
  • A user’s Rolling Proximity Identifiers changes on average every 15 minutes, and needs the Daily Tracing Key to be correlated to the user. This reduces the risk of privacy loss from advertising them.
  • Proximity identifiers obtained from other devices are processed exclusively on device.
  • Users decide whether to contribute to contact tracing.
  • If diagnosed with COVID-19, users consent to sharing Diagnosis Keys with the server.
  • Users have transparency into their participation in contact tracing.

FAQ

I got some feedback and discussion, I will summarize here:

  1. Talking about the anonymous identification beacons, how far can the geographical range (distance) of this matter be?

I will try to update some more other documents after my reading.

Please kindly keep washing your hands, keep social distance, keep healthy.

Revision History

Timezone: UTC+8

  • 2020-04-12 00:30: Init. Read the privacy scenario and Bluetooth spec.
  • 2020-04-12 14:30: Added FAQ section.
  • 2020-04-13: Added Advertising AD Type ref link.

Because the contact tracing technology uses Bluetooth technology, as a Bluetooth enthusiast, please allow me to add this hashtag: #BluetoothCanHelp

(btw, is it possible that Bluetooth SIG gives me sort of discount on my annual membership fee? XDD)

Loading comments…