Exposure Notification

Exposure Notification

Developed by	Apple Inc. Google
Introduced	April 2020 (2020-04)
Industry	Digital contact tracing
Compatible hardware	Android & iOS smartphones
Physical range	~10 m (33 ft)

Exposure Notification, originally known as the Privacy-Preserving Contact Tracing Project, is a system with public available specifications developed by Apple Inc. and Google for using smartphones to determine whether a person may have recently been within the proximity of someone that had been infected with Coronavirus disease 2019 (COVID-19). Exposure Notification is a decentralized reporting based protocol built on a combination of Bluetooth Low Energy technology and privacy-preserving cryptography, and is designed to be implemented 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 Covid Watch nonprofit, which started as an independent research collaboration between Stanford University and the University of Waterloo, was the first in the world to publish a white paper, develop, and open source a fully anonymous Bluetooth exposure alert protocol - the TCN Protocol - in collaboration with CoEpi in early March 2020. This was followed by the rapid development and improvement of very similar decentralized protocols in early April 2020 like DP-3T, PACT, and the Apple/Google protocol.

The Apple/Google protocol is heavily-influenced by the Decentralized Privacy-Preserving Proximity Tracing (DP-3T) and the Temporary Contact Number (TCN) protocols, 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.

There has been doubt that Bluetooth Low Energy will be reliable enough measure distance to track relevant contact because of signal reflections as well as the inability to detect safety barriers such as plexiglass windows. Furthermore, treating a simple distance-based threshold as safe is too naive to approximate virus aerosol spread; room ventilation was found to be crucial, and infections beyond the "safe" distance are possible when inappropriate ventilation is used. A too low detection precision can cause missing of relevant contacts, false alerts, and will make the tracking apps largely useless. Experts estimate over 60% of smartphone users would need to install the apps. In countries where such an app is already available, adoption rates are much smaller, often less than 20%; and the apps are reportedly not working well enough to be useful. In Iceland, which has with 40% the highest adoption rate of such apps, the app has not helped much. In Norway, where 20% of people were reported to use the app, it had not identified a single infection by mid May.

Technical specification

Typically digital contact tracing protocols have two major responsibilities: encounter logging and infection reporting. Exposure Notification only defines encounter logging, with the majority of the infection reporting 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 (RSSI) of the beacon messages as a source to infer proximity. RSSI and other signal metadata will also be encrypted to resist deanonymization attacks. The system uses AES encryption as a power-saving measure.

Version 1.0

To generate encounter identifiers, first a persistent 32-byte private tracing key ($tk$) is generated by a client. From this a 16 byte daily tracing key ($dtk$) is derived using the algorithm $dtk_{d}=HKDF(tk,NULL,{\text{'CT-DTK'}}||d,16)$, where $HKDF({\text{Key, Salt, Data, OutputLength}})$ is a HKDF function, and $d$ is the day number calculated as $d=unix\_timestamp/(60*60*24)$. 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 ID ($rpi$) is generated every 10 minutes with the algorithm $rpi_{d,ti}=HMAC(dtk_{d},{\text{'CT-RPI'}}||ti)[0:16]$, where $HMAC({\text{Key, Data}})$ is a HMAC function, and $ti$ is the time interval number, calculated as $ti=(unix\_timestamp\%(60*60*24))/(60*10)$. The time interval number represents a unique index for every 10 minute period in a 24 hour day. When two clients come within proximity of each other they exchange and locally store the current $rpi$ as the encounter identifier.

Once a registered health authority has confirmed the infection of a user, the user's $dtk$ for the past 14 days is uploaded to the central reporting server. Clients then download this report and individually recalculate every $rpi$ 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 exposure key ($ek$) is generated. This is analogous to the daily tracing key from version 1.0. From this two values are calculated, the associated encrypted metadata key ($aemk$), and the rolling proximity key ($rpik$). $aemk$ is calculated with the algorithm $aemk_{d}=HKDF(ek_{d},NULL,{\text{'EN-AEMK'}},16)$, and $rpik$ using the algorithm $rpik_{d}=HKDF(ek_{d},NULL,{\text{'EN-RPIK'}},16)$, where $d$ is the day.

From these values a temporary rolling proximity ID ($rpid$) is generated every time the BLE MAC address changes, roughly every 15-20 minutes. The following algorithm is used to calculate the value $rpid_{d,ti}=AES128(rpik_{d},{\text{'EN-RPI'}}||{\mathtt {0x000000000000}}||ti)$, where $AES128({\text{Key, Data}})$ is an AES cryptography function with a 128-bit key. Next, 4 bytes of associated encrypted metadata ($aem$) is encoded. What the metadata represents is not specified, likely to allow the later expansion of the protocol. The following algorithm is used $aem_{d,ti}=AES128\_CTR(aemk_{d},rpid_{ti},metadata)$, where $AES128\_CTR({\text{Key, Data}})$ is an AES-CTR function with a 128-bit key. The $aem$ and $rpid$ 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 $ek$ for the past 14 days is uploaded to the central reporting server. Clients then download this report and individually recalculate every $rpid$ 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.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. Since the two vendors effectively control the entire smartphone market (with Android having an 86.6% market share as of 2020, and iOS the remaining 13.4%), 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. The companies stated that it would also sunset the protocol "on a regional basis when 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 (a system API component for Google services that is present on almost all Android devices outside of mainland China, and updated independently of Android itself via the Google Play store), ensuring compatibility with Android Marshmallow and later and not requiring them to be integrated into an Android firmware (which would hinder deployment).

Regulatory scrutiny

On April 16, the European Union started the process of assessing the proposed system for compatibility with privacy and data protection laws. On April 17, 2020, the UK's Information Commissioner's Office, a supervisory authority for data protection, published an opinion analysing both Apple and Google's protocol 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.

Alongside an NHSX-developed app, the United Kingdom announced plans to conduct a feasibility study in using Exposure Notification as a secondary option.

On May 25, Switzerland became the first country to launch an app leveraging the protocol, SwissCovid, although initially only in a pilot phase with a limited user group. The app became available on the Play Store on Android the same day.

On May 29, a consortium of IT companies and volunteers in Latvia launched application Apturi Covid, which makes use of Exposure Notification API. The county's president and government ministers installed the application on their phones on the launch day. Application developers stated a goal to reach 400 000 users, approximately 20% of the country's population.

On June 1, 2020, Italy launched its Immuni app, based on the Exposure Notification API.

On June 9, 2020, Poland launched version 4 of its ProteGO Safe app, which is now based on the Exposure Notification API.

Non-adopters

Some countries, such as France and the United Kingdom, 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 by "armies of people". In the European Union, states like Sweden have chosen not to use digital contact tracing at all.

External links

• Announcement (Google)
• Overview presentation (Google)
• Technical specifications (Apple)
• Exposure Notification: Frequently Asked Questions (Apple/Google)
• Overview of the version 1.0 of Contact Tracing protocol by Apple & Google
• Overview of the version 1.2 and comparation with version 1.0