How Apple and Google’s Bluetooth Contact Tracing Framework Actually Works
The COVID-19 pandemic affects us all, with public life seeing disruptions at an unprecedented scale. To help curb the spread of the disease, Apple and Google have announced a joint effort to develop a contact tracing framework with a heavy focus on privacy and security.
This post is the Punch Through team’s take on what this contact tracing framework is about, how it works based on what we know so far, and what this means for our future — as platform users and also as developers.
The Current State of Contact Tracing
Some governments like China, South Korea, and Singapore have started using mobile technology to perform some variations of contact tracing and quarantine enforcement. South Korea, for example, has an app that would alert officials when someone breaks quarantine. The country has also set up an automated system to perform contact tracing based on mobile location histories, reducing contact tracing time from 24 hours to ten minutes.
Source: The Economist.
It’s widely accepted that contact tracing is an important tool during the time of a pandemic. Nevertheless, when a government or state entity exercises its right to access and use that wealth of data it has on its citizens, it’s harrowing to imagine that privacy and civil liberty rights may never be the same again after this.
The announcement of Apple and Google’s unprecedented but inevitable partnership in collaborating on the development of a privacy-first, cross-platform contact tracing framework is music to our ears. If it all works as advertised, it’ll easily become the de facto way for public health authorities to conduct contact tracing, simply because of the level of OS support and integration.
Release and Integration Timelines
Why Now?
It’s no surprise that developers all over the world are scrambling to implement their own versions of a contact tracing framework, using APIs that are currently available in the Android and iOS developer SDKs. There are also established protocols such as Singapore’s BlueTrace and the EU’s Pepp-Pt out there that — albeit open source and peer-reviewed — further fragment the implementation details and adoption of a digital contact tracing ecosystem.
Given the nature of how contact tracing works, risks are also inherently present where unscrupulous parties implementing their own frameworks may surface users’ personally identifiable information (PII) for malicious reasons.
For example, a third-party contact tracing app may collect location data in the background on behalf of advertising marketers. A poorly designed or purposefully malicious app may also insert sensitive information into an advertising payload that the app then broadcasts with impunity.
It’s obvious that in light of all these factors, a unified contact tracing framework built by platform owners in the open will ensure interoperability between platforms and encourage mass adoption right off the bat. Platform owners can also optimize power consumption on the OS level for specific use cases outlined in the framework specifications.
Apple and Google are the platform owners for the two most popular mobile operating systems in the world, with iOS and Android jointly possessing more than 99% of mobile OS market shares globally. This makes them the best candidates for taking on the implementation of a cross-platform contact tracing framework.
The contact tracing framework will be rolled out in two stages.
Limited Access APIs
The first stage of rollout aims to address the immediate needs of developers working on apps for public health authorities. Apple and Google will offer a unified set of APIs that abstract away the underlying heavy-lifting implementation of the actual contact tracing logic. By eliminating the need for developers to reinvent the wheel, Apple and Google are hoping to protect user privacy while speeding up the app development process for public health authorities.
Both companies said their APIs will be released in May, and only apps developed for or by public health authorities will have access to these APIs. It’s likely that software updates are also required for supported iOS and Android devices before the APIs would function correctly on the users’ end.
For now, both companies have released preliminary API documentations for iOS and Android.
System-Level Integration
Once the immediate needs of developers working on contact tracing apps have been addressed, Apple and Google’s focus will shift to integrating the technology exposed by the limited access APIs into iOS and Android on a system level.
This means that any iOS or Android user can choose to opt in to the wider contact tracing ecosystem. This second stage of rollout will also likely contain optimizations on the OS level for power consumption, privacy, and security.
We’ll focus on this second stage of rollout for the rest of the post, seeing as this is the end goal of the companies’ efforts that’ll have the biggest impact on the world.
How it is Different from Conventional Means of Contact Tracing
Conventional Contact Tracing
Contact tracing is a monitoring process that records contacts between people to identify a potential chain of viral infections. In the event of a confirmed infection, others who have been in contact with the infected person will be followed up on. These people will then likely be quarantined and tested for the disease.
Contact tracing is not a new process by any means. The WHO have been using contact tracing as a tool for understanding and containing past outbreaks of diseases such as SARS and Ebola.
The conventional way of contract tracing is done by interviewing the infected individual on who they’ve been in contact with, and where they’ve been recently. Human error and lying by omission are some of the main downsides of this process that can severely hamper efforts to contain an outbreak.
Apple and Google’s Proposed Privacy-Safe BLE Contact Tracing
The proposed framework, once implemented and opted in to, will work automatically and seamlessly in the background of a mobile device. If a user has been in contact with a person who later tested positive for the virus, he or she will be notified immediately with information on next steps.
This proposed framework prioritizes user privacy. Explicit consent for opting in is required, and no PII or location data will ever be shared. Recent contacts are stored on-device, and infected individuals cannot be identified by other users, Apple, or Google.
Apple and Google have come up with a brilliant illustration for how they envision the system to work as a whole.
Source: Apple and Google.
Source: Apple and Google.
How it Works Under the Hood
Cryptographic Keys as Anonymous Identifiers
Apple and Google’s preliminary proposal of cryptography specifications mentioned the generation and utilization of a set of keys to anonymously identify participating users’ mobile devices.
- A permanent 256-bit Tracing Key (TK) is generated once for each participating mobile device and securely stored on the device. The TK is generated using a cryptographic random number generator and never leaves the device.
- A 128-bit Daily Tracing Key (DTK) is derived from the permanent Tracing Key every 24 hours. The DTKs are generated using a HKDF function that takes in as arguments the TK and a time value corresponding to the number of days since Epoch. This latter value is known as the Day Number of the DTK.
- A 128-bit Rolling Proximity Identifier (RPI) is derived from the day’s active DTK when the device’s Bluetooth MAC address rotates. This rotation happens randomly every 10 to 20 minutes. The RPIs are generated using a HMAC function that takes in as arguments the active DTK and the time when the Bluetooth MAC address change happened.
Source: Apple.
The RPI is included in a device’s Bluetooth advertisement payload, and anonymously identifies the device to other participating devices. Any encountered RPIs are stored and processed on users’ devices exclusively.
When a user is tested positive for the virus, a subset of their DTKs and the associated Day Numbers are uploaded with their consent to the server. These keys are known collectively as the Diagnosis Keys (DKs). Although not specified in the proposal, we believe this subset likely consists of about 14 days’ worth of DTKs to match COVID-19’s widely accepted 2-week incubation period.
These DKs are downloaded daily by all participating devices, which can use their stored (encountered) RPIs to resolve against the downloaded DKs to compute if the user has been in contact with an infected patient recently. An algorithm will then run locally to assess risk based on exposure duration and recency, before concluding if the user is at risk of being infected.
Advertising Device Presence via Bluetooth Beaconing
The presence and proximity of a device is advertised via Bluetooth Low Energy beaconing. The advertising PDU type is ADV_NONCONN_IND, which means that it cannot be connected to. This behavior is similar to most BLE beacon applications.
The BLE MAC address of the advertising device is of a private, random, non-resolvable type, and it’s rotated every 10 to 20 minutes. Meanwhile, the suggested advertising interval is currently 200-270 milliseconds.
Apple and Google have registered a Contact Detection Service with the Bluetooth SIG. This special service will have an assigned 16-bit UUID of 0xFD6F. All participating devices will advertise as well as scan for this Contact Detection Service. Any advertisement packets encountered will be timestamped, RSSI-captured, and kept on device.
To balance between power consumption and the detection or collision event of surrounding advertising packets, the scanning interval will be set such that nearby Contact Detection Service advertisements can be sampled at a minimum of every 5 minutes. Any filtering optimizations that can be done on the Bluetooth controller, hardware, and OS layers to save power will also be implemented by Apple and Google.
This proposed contact tracing framework is strictly about determining if devices have been in close proximity with one another, rather than where they’ve been. Therefore, the advertisement payload doesn’t contain location data whatsoever.
The only piece of significant information in the advertisement payload is the 128-bit Rolling Proximity Identifier. This identifier is contained within the Service Data section of the payload, nested under the Contact Detection Service.
What’s Next?
As BLE aficionados, we here at Punch Through are extremely excited to see how the implementation and rollout of this contact tracing framework will guide future specifications updates and development of Bluetooth, mobile platform SDKs, and other wireless technologies.
Never before has Bluetooth-based technology been deployed at such a scale for public health reasons. Therefore, we believe that the contact tracing framework is a big step forward for the developer community, society, and the world. The development of this framework will also be invaluable in curbing the spread of any future disease outbreaks.
No system design is completely immune to abuse, but we’re very impressed with Apple and Google’s proposed solution so far. We’re also glad to see that they’re open to stakeholders’ feedback and are being transparent about how they’ll implement the framework.
For now, please stay home and stay safe. The Punch Through team, signing off.
Resources
- Press announcements:
- Privacy-Preserving Contact Tracing: https://covid19.apple.com/contacttracing
- Contact tracing framework APIs:
- Contact tracing Bluetooth specifications: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf
- Contact tracing cryptography specifications: https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf