An Overview of the Bluetooth Contact Tracing Protocol by Apple & Google

On April 10th 2020 Apple and Google announced the introduction of a jointly developed contact tracing protocol in relation to the upcoming updates of iOS and Android.

The project aims to reduce the spread of coronavirus by tracking chains of contacts and early detection of newly infected followed with quick isolation, by providing a protocol that can be applied for the development of contact tracing apps.

Within this protocol, BLE (Bluetooth Low Energy) technology forms the basis used for contact tracing.

How it is intended to work:

The BLE service with special service UUIDs and characteristic UUIDs is launched on smartphones with iOS or Android operating systems.

BLE works in a similar way like e.g. Bluetooth earphones, which use the Bluetooth service by transmitting a standardised class-defining code (characteristic UUID), except in this case a special code is used, which defines the contact-tracing protocol from Apple & Google. Energy consumption is very low, which is an important factor for smartphone users.

Smartphones intermittently use Bluetooth to look for other devices with established service UUID and characteristic UUID, and when such devices are found in proximity, a contact is established and recorded.

The main task of the protocol is to share anonymous identifiers between smartphones in case of such contact, and to eventually notify all such contacts should someone get infected and report their status.

First results of app contact tracing shown in Singapore

A similar contact tracing technology called BlueTrace has already been developed in Singapore earlier this year.

The Trace Together app was launched by the Singaporean government in March 2020, and provided results within quite a short period of time.

Health experts and the World Health Organisation have stated that such widespread measures for tracing, testing and isolation in Singapore have helped to drastically reduce the spread of Covid-19, and led to a reduction of new cases of infection from 909 on 29th February to 74 cases on 16th March.

At the moment, Trace Together is installed on over 1 million devices, and the technology behind BlueTrace went open source.

Description of the Apple & Google protocol

Unlike BlueTrace, the Apple & Google protocol was developed with higher security and privacy in mind.

It does not require sign-up and authorisation with phone number or email, and information about infected users is transferred anonymously.

Temporary identifiers with a lifetime of 10 minutes before renewal are used to avoid device tracking.

How does the protocol work?

1. The smartphone generates a random 32-byte private Tracing Key, that stays on the device at all times.
   
2. A 16-byte Daily Tracing Key is created every day with HKDF function:
   

   dk = HKDF(tk , NULL, (UTF8(“CT-DTK”)||Di),16)

   
   where
   

   tk

   = private key, 
   

   Di

   = day number, which is calculated as
   

   unix_timestamp div (60*60*24)

   where
   

   div

   is integer division operation, 
   

   ||

   symbol stands for concatenation
   

   NULL

   in this case stands for salt, which is not used, and 16 is the final number of bytes.
   These keys are shared with the server should a user report infected.
   
3. Every 10 minutes* a temporary identifier, the so-called Rolling Proximity ID is generated, which length is 16 bytes as well.
   These identifiers are exchanged between devices in case a contact has been established. 
   They are generated with a HMAC function (first 16 bytes) where
   the Daily Key, together with the time slot number, is used as argument:
   

   RPI = Truncate(HMAC(dk, (UTF8(“CT-RPI”)||Ti)),16)

   
   

   Dk

   = Daily Tracing Key
   

   Ti

   = time interval number, calculated as
   

   (unix_timestamp mod (60*60*24)) div (60*10)

   , where
   

   div

   is integer division operation, 
   

   mod

   stands for remainder in division 
   * According to the protocol’s cryptographic specification, the identifier is changed every 10 minutes:
   TimeIntervalNumber provides a number for each 10-minute window in a 24-hour window as defined by DayNumber)
   Yet the bluetooth specification states a 15 minute interval.
   We are inclined to trust the cryptographic specification in this case.
   
4. In case of contact, the respective devices store each other’s RPI (Rolling Proximity ID) locally, together with the time of contact.
   
5. In case a user reports infected, the user’s Daily Keys generated over the last 14 days are uploaded to the server, from which all other devices continuously download the new keys.
   Upon downloading a new key, the smartphone compares it to it’s locally stored contact data, after calculating RPI for each contact and having it compared with stored RPI.
   In case of a match, the user receives a notification about a contact with an infected user.

By the time this article is published, Apple & Google have announced a new version of the specification for their contact tracing protocol, where principles behind the generating of Daily Keys and Rolling Proximity ID have been changed. Most likely this was caused by the possibility of tracing an infected user for the past 14 days before their keys were published, which is possible with the current version of protocol.

We are planning to provide a detailed overview about the differences between the two versions within our next article, so stay tuned.

Plans to use the Protocol

Upon releasing the protocol description, Apple & Google have announced that third-party developers will only get API access, while the protocol will be introduced on OS level.

An app might ask the user for Contact Tracing Framework access, while OS itself is going to generate the Private and Daily Keys, as well as time slot identifiers. Bluetooth will be activated on a system level as well.

The API will also get access to a user’s status, and in case of contact with an infected user, this status will change to ‘exposed’.
In this case, the app may ask for additional information about the contact: it’s date and duration of close contact.
The API also supports an option to inform that a user has been infected with COVID-19. However, such information must be confirmed by a medical institution with special authorisation from Apple & Google to conduct such operations.

Apps must share their daily keys for the past 14 days, obtain a digital signature and submit them to the API.

This procedure raises several questions:

• Which medical institutions will be granted the ability to confirm the above mentioned diagnosis?
  
• How are the respective medical institutions audited and or certified to conduct such operations and confirm diagnosis?

Apple’s App Store and Google’s Play Marked have already limited the ability to publish COVID-19 related apps to medical and government institutions only. It is possible that keys necessary to sign diagnoses will be given to developers, affiliated with such medical institutions, upon publishing apps that deploy Apple and Google’s contact tracing protocol.

Conclusions

The announcement of Google & Apple’s protocol once again proves how important contact tracing is to fight infectious diseases, COVID-19 in particular.

It’s hard to recall another case where two rival IT giants would join forces and create a joining release so quickly.

Singapore’s TraceTogether has accumulated over 1 million users over the past two or three months, yet this number is quite insignificant compared with several billion devices that Apple & Google can expect to reach through their protocol.

Such scope makes their protocol very promising for medical and government institutions across the world.

International engagement problem is solved by centralized database of infected together with global coverage, which already is a huge advantage — but also a drawback of this technology.
Not every government is ready to entrust their users data to Apple & Google without getting it first.
Furthermore, realisation of this protocol on OS level makes it impossible for the community to examine, thus, we cannot be 100% sure that private key is not shared with any third parties.

Open-source

Social significance and privacy protection make an open-source implementation of the Apple & Google protocol crucial. Such implementation could be examined in terms of back-doors and privacy concerns by the professional community and could be available to everyone interested basing their app development on an open-source license.

That’s why we are working on OpenCovidTrace, an open-source platform that realises Apple & Google protocol with several changes and improvements, made necessary due to iOS’s limitations.

iOS limitations

Contact exchange, as described within the Apple & Google protocol, is made passively. Timestamps are stored in advertising packets of BLE, which is the reason for their reduction to 16 bytes.

Two nearby smartphones see each other’s BLE services with respective UUID and are able to read identifiers from advertising info of the BLE service.

Limitations of the Core Bluetooth framework in iOS make it impossible for apps, working in background mode, to access BLE parameters needed.

That’s why our implementation of the protocol has smartphones create two BLE services: one is used for searching for other smartphones, and the other one is used for connection and acquisition of other smartphones’ temporary identifiers.

We expect Apple to remove this limitation within their next iOS update for the realisation of their contact exchange protocol. Otherwise, should this limitation be only removed for the Apple & Google protocol implementation, but still be in place on the app level, Apple would place other developers in disadvantage, which could be perceived as unfair competition.

Consolidation of Technologies

Another goal for OpenCovidTrace is interoperability. Our aim is to unify all different contact tracking protocols, including the aforementioned BlueTrace, Apple & Google as well DP-3T envisioned by european scientific community. We will go into more detail about it in one of our follow-up articles.

Join us on Github! 

Your input and feedback will help our project’s development and together we’ll be able to quench coronavirus outbreaks after the quarantine is lifted.

OpernCovidTrace Team

Links:

• https://www.apple.com/covid19/contacttracing — Apple & Google protocol documentation
• https://www.tracetogether.gov.sg/ — Singaporean Trace Together app
• https://bluetrace.io/ — technology upon which Trace Together is built
• https://opencovidtrace.org — our open-source project
• https://github.com/OpenCovidTrace — our Github repository
• https://github.com/DP-3T/ — another promising open-source contact tracing project

Previously published at https://medium.com/macoclock/an-overview-to-the-bluetooth-contact-tracing-protocol-by-apple-google-9c03a2c1e30a