(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.
First of all, here to list all the documents mentioned in both Apple and Google press release posts:
- Post: Apple press release
- Post: Google press release
- Memo: these two
Cryptography Specificationdocuments are the same.
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.
- BBC: Coronavirus: Apple and Google team up to contact trace Covid-19, by Leo Kelion.
- 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
- User can transmit his/her
beacon keyto a cloud of a public health organization with user consent.
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
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
- Contact Detection Service
- Advertisement Payload
- Advertising Behavior
- Advertising Flow
- Scanning Behavior
- Scan Power Considerations
- Scanning Flow
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 :)
- This document provides the detailed technical specification for a new privacy-preserving Bluetooth protocol to support Contact Tracing.
Contact Detection Serviceis 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.
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
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 Serviceis a BLE service registered with the Bluetooth SIG with 16-bit UUID:
- 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 Typedefinition at SIG official website.
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 Datawhich will be modified periodly.
- Advertisements are to be non-connectable undirected of type
ADV_NONCONN_IND(Section 188.8.131.52 of 5.2 Core Spec).
- The advertiser address type should be
- On the platforms supporting
Bluetooth Random Private Addresswith randomized rotation timeout interval, the advertiser address rotation period shall be a random value, greater than 10 minutes and less than 20 minutes.
Rolling Proximity Identifiershall be changed synchronously so address and Rolling Proximity Identifier can not be linked.
- A separate
advertising instanceshould be used, if HW allows, to provide advertising reliability and flexibility in choosing optimal interval.
advertising intervalis subject to change, but is currently recommended to be 200-270 milliseconds.
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 addressand
Rolling Proximity Identifierfrequently. (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
- Wherever supported by HW and OS, Bluetooth controller duplicate filters and other HW filters should be used to prevent excessive power drain.
- Maintaining user privacy is an essential requirement in the design of this specification.
Contact Tracing Bluetooth Specificationdoes 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 Identifierschanges on average every 15 minutes, and needs the
Daily Tracing Keyto 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 Keyswith the server.
- Users have transparency into their participation in contact tracing.
I got some feedback and discussion, I will summarize here:
- Talking about the anonymous identification beacons, how far can the geographical range (distance) of this matter be?
- Distance is based on the communication distance of Bluetooth technology. Usual idea is within 10 meters, based on the environment and devices. General reference can be found athttps://en.wikipedia.org/wiki/Bluetooth_advertising
I will try to update some more other documents after my reading.
Please kindly keep washing your hands, keep social distance, keep healthy.
- 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)