Exposure Notification


The Exposure Notifications System, originally known as the Privacy-Preserving Contact Tracing Project, is a framework and specification developed by Apple Inc. and Google to facilitate digital contact tracing during the 2019-20 COVID-19 pandemic. When used by health authorities, it augments more traditional contact tracing techniques by automatically logging encounters with other ENF users using their Android or iOS smartphone. Exposure Notification is a decentralized reporting based protocol built on a combination of Bluetooth Low Energy technology and privacy-preserving cryptography. It is used as an opt-in feature within COVID-19 apps developed and published by authorized health authorities. Originally unveiled on April 10, 2020, it was first made available on iOS on May 20, 2020 as part of the iOS 13.5 update.
The Apple/Google protocol is heavily-influenced by the Decentralized Privacy-Preserving Proximity Tracing and the Temporary Contact Number protocol by Covid Watch, but is implemented at the operating system level, which allows for more efficient operation as a background process. Protocols such as TCN, DP-3T and BlueTrace are constrained in how they operate as they have no special privilege over normal apps. This leads to issues, particularly on iOS devices where digital contact tracing apps running in the background experience significantly degraded performance. The joint approach is also designed to maintain interoperability between Android and iOS devices, which constitute the sheer majority of the market. EPFL Professor Edouard Bugnion played an important role in getting Apple and Google to work together
The ACLU stated the approach "appears to mitigate the worst privacy and centralization risks, but there is still room for improvement". In late April, Google and Apple shifted the emphasis of the naming of the system, describing it as an "exposure notification service", rather than "contact tracing" system.

Technical specification

Typically digital contact tracing protocols have two major responsibilities: encounter logging and infection reporting. Exposure Notification only defines encounter logging which is an decentralized architecture, with the majority of the infection reporting, currently it is centralized, being delegated to individual app implementations.
To handle encounter logging, the system uses Bluetooth Low Energy to send tracking messages to nearby devices running the protocol to discover encounters with other people. The tracking messages contain unique identifiers that are encrypted with a secret daily key held by the sending device. These identifiers change every 15-20 minutes as well as Bluetooth MAC address in order to prevent tracking of clients by malicious third parties through observing static identifiers over time.
The sender's daily encryption keys are generated using a random number generator. Devices record received messages, retaining them locally for 14 days. If a user tests positive for infection, the last 14 days of their daily encryption keys are uploaded to a central server, where it is then broadcast to all devices on the network. The method through which daily encryption keys are transmitted to the central server and broadcast is defined by individual app developers. The received keys are then provided to the protocol, where each client individually searches for matches in their local encounter history. If a match meeting certain risk parameters is found, the app notifies the user of potential infection. Google and Apple intend to use the received signal strength of the beacon messages as a source to infer proximity. RSSI and other signal metadata will also be encrypted to resist deanonymization attacks.

Version 1.0

To generate encounter identifiers, first a persistent 32-byte private Tracing Key is generated by a client. From this a 16 byte Daily Tracing Key is derived using the algorithm , where is a HKDF function using SHA-256, and is the day number for the 24-hour window the broadcast is in starting from Unix Epoch Time. These generated keys are later sent to the central reporting server should a user become infected.
From the daily tracing key a 16-byte temporary Rolling Proximity Identifier is generated every 10 minutes with the algorithm, where is a HMAC function using SHA-256, and is the time interval number, representing a unique index for every 10 minute period in a 24 hour day. The Truncate function returns the first 16 bytes of the HMAC value. When two clients come within proximity of each other they exchange and locally store the current as the encounter identifier.
Once a registered health authority has confirmed the infection of a user, the user's Daily Tracing Key for the past 14 days is uploaded to the central reporting server. Clients then download this report and individually recalculate every Rolling Proximity Identifier used in the report period, matching it against the user's local encounter log. If a matching entry is found, then contact has been established and the app presents a notification to the user warning them of potential infection.

Version 1.1

Unlike version 1.0 of the protocol, version 1.1 does not use a persistent tracing key, rather every day a new random 16-byte Temporary Exposure Key is generated. This is analogous to the daily tracing key from version 1.0. Here denotes the time is discretized in 10 minute intervals starting from Unix Epoch Time. From this two 128-bit keys are calculated, the Rolling Proximity Identifier Key and the Associated Encrypted Metadata Key. is calculated with the algorithm , and using the algorithm.
From these values a temporary Rolling Proximity Identifier is generated every time the BLE MAC address changes, roughly every 15-20 minutes. The following algorithm is used:, where is an AES cryptography function with a 128-bit key, the data is one 16-byte block, denotes the Unix Epoch Time at the moment the roll occurs, and is the corresponding 10-minute interval number. Next, additional Associated Encrypted Metadata is encrypted. What the metadata represents is not specified, likely to allow the later expansion of the protocol. The following algorithm is used:, where denotes AES encryption with a 128-bit key in CTR mode. The Rolling Proximity Identifier and the Associated Encrypted Metadata are then combined and broadcast using BLE. Clients exchange and log these payloads.
Once a registered health authority has confirmed the infection of a user, the user's Temporary Exposure Keys and their respective interval numbers for the past 14 days are uploaded to the central reporting server. Clients then download this report and individually recalculate every Rolling Proximity Identifier starting from interval number , matching it against the user's local encounter log. If a matching entry is found, then contact has been established and the app presents a notification to the user warning them of potential infection.

Version 1.2

Version 1.2 of the protocol is identical to version 1.1, only introducing minor terminology changes.

Adoption requirements

Modeling by researchers at Oxford University has suggested that 80% of all smartphone users in a city of one million people would have to use a tracking system to be effective against the coronavirus if no other measures against the spread of the virus were taken but contact tracing. Since the two vendors effectively control the entire smartphone market, the joint initiative between the companies puts them in a unique position compared to other potential actors in this field.
To address this, the Exposure Notification protocol is designed to be deployed and maintained via both platforms' respective application stores and update systems. The APIs enabled through such updates will then be available for authorized applications from national health authorities.

Privacy

Preservation of privacy was referred to as a major component of the protocol; it is designed so that no personally identifiable information can be obtained about the user or their device. Apps implementing Exposure Notification are only allowed to collect personal information from users on a voluntary basis. As an additional measure, the companies stated that it would sunset the protocol by-region once they determine that it is "no longer needed".
The Electronic Frontier Foundation showed concerns the protocol was vulnerable to "linkage attacks", where sufficiently capable third parties who had recorded beacon traffic may retroactively be able to turn this information into tracking information, for only areas in which they had already recorded beacons, for a limited time segment and for only users who have disclosed their COVID-19 status, once a device's set of daily encryption keys have been revealed.

Release schedule

Deployment plan

According to the joint announcement by Apple and Google, the system is intended to be rolled out in three stages:
  • API specification and publication
  • rollout of tools to enable governments to create official privacy-preserving coronavirus tracing apps
  • integration of this functionality directly into iOS and Android
Apple have stated that the system is designed to work on all recent devices that can support iOS 13.
The companies planned an API for development on April 28, 2020 and it was released to developers the following day.

Release

The iOS 13.5 update released on May 20, 2020 introduced support for the Exposure Notification API. Google stated that on Android, Exposure Notification will be serviced via Google Play Services, ensuring compatibility with Android Marshmallow and later and not requiring them to be integrated into an Android firmware.

Regulatory scrutiny

On April 16, the European Union started the process of assessing the proposed system for compatibility with privacy and data protection laws, including the General Data Protection Regulation. On April 17, 2020, the UK's Information Commissioner's Office, a supervisory authority for data protection, published an opinion analyzing both Exposure Notification and the Decentralized Privacy-Preserving Proximity Tracing protocol, stating that the systems are "aligned with the principles of data protection by design and by default".

Adoption by country

As of May 21, at least 22 countries had received access to the protocol. Switzerland and Austria were among the first to back the protocol. On April 26, after initially backing PEPP-PT, Germany announced it would back Exposure Notification, followed shortly after by Ireland and Italy. Despite already adopting the centralised BlueTrace protocol, Australia's Department of Health and Digital Transformation Agency are investigating whether the protocol could be implemented to overcome limitations of its COVIDSafe app. On May 25, Switzerland became the first country to launch an app leveraging the protocol,, beginning with a small pilot group.
In England, the National Health Service trialed both an in-house app on a centralized platform developed by its NHSX division, and a second app using Exposure Notification. On June 18, the NHS announced that it would focus on using Exposure Notification to compliment manual contact tracing, citing tests on the Isle of Wight showing that it had better cross-device compatibility, but that its distance calculations were not as reliable as the centralised version of the app. Later, it was stated that the app would be supplemented by QR codes at venues.
CountryNameAnnounced/ReleasedNotes
CANCOVID AlertJuly 31, 2020Co-developed in partnership with BlackBerry Limited and Shopify
Currently active only in Ontario
DENSmittestopJune 18, 2020
GERJune 16, 2020
IRLCOVID Tracker IrelandJuly 7, 2020
ITAImmuniJune 1, 2020
JPNCOCOAJune 19, 2020
LAT,May 29, 2020
POLProteGO SafeJune 9, 2020Update to existing encounter logging app
SPARadar COVIDJune 30, 2020
SUI,May 26, 2020
URYCoronavirus - UYJune 15, 2020
BRACoronavírus-SUSJuly 31, 2020

Non-adopters

Some countries, such as France, have pursued centralized approaches to digital contact tracing, in order to maintain records of personal information that can be used to assist in investigating cases. The French government has asked Apple to allow apps to perform Bluetooth operations in the background, allowing the government to create its own system independent of Exposure Notification.
In the United States, states such as New York, California and Massachusetts declined to use the technology, opting for manual contact tracing. The U.S. states of Alabama, North Dakota and South Carolina announced an intent to use Exposure Notification, but have not yet deployed any software that uses it.