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.
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.
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.
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.
dk = HKDF(tk , NULL, (UTF8(“CT-DTK”)||Di),16)
= private key,
= day number, which is calculated as
unix_timestamp div (60*60*24)
is integer division operation,
symbol stands for concatenation
in this case stands for salt, which is not used, and 16 is the final number of bytes.
RPI = Truncate(HMAC(dk, (UTF8(“CT-RPI”)||Ti)),16)
= Daily Tracing Key
= time interval number, calculated as
(unix_timestamp mod (60*60*24)) div (60*10)
is integer division operation,
stands for remainder in division
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.
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.
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.
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.
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.
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.
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.
Level up your reading game by joining Hacker Noon now!