exposure notification exposure notification the (google/apple) exposure notification (gaen) system, originally known as the privacy-preserving contact tracing project, is a framework and protocol specification developed by apple inc. and google to facilitate digital contact tracing during the covid-19 pandemic. when used by health authorities, it augments more traditional contact tracing techniques by automatically logging encounters with other notification system 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 and on december 14, 2020 as part of the ios 12.5 update for older iphones. on android, it was added to devices via a google play services update, supporting all versions since android marshmallow. exposure notificationdeveloped byapple inc.googleintroducedapril 10, 2020 (2020-04-10)industrydigital contact tracingcompatible hardwareandroid & ios smartphonesphysical range~10 m (33 ft) the apple/google protocol is similar to the decentralized privacy-preserving proximity tracing (dp-3t) protocol created by the european dp-3t consortium and the temporary contact number (tcn) protocol by covid watch, but is implemented at the operating system level, which allows for more efficient operation as a background process. since may 2020, a variant of the dp-3t protocol is supported by the exposure notification interface. other protocols 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. 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 a 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 can be 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 google-developed reference implementation calls for a health official to request a one-time verification code (vc) from a verification server, which the user enters into the encounter logging app. this causes the app to obtain a cryptographically signed certificate, which is used to authorize the submission of keys to the central reporting server. 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 exposure to the 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. version 1.0 to generate encounter identifiers, first a persistent 32-byte private tracing key ( t k ) is generated by a client. from this a 16 byte daily tracing key is derived using the algorithm d t k i = h k d f ( t k , n u l l , 'ct-dtk' | | d i , 16 ) =hkdf(tk,null,||d_,16)} , where h k d f ( key, salt, data, outputlength ) )} is a hkdf function using sha-256, and d i 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 r p i i , j = truncate ( h m a c ( d t k i , 'ct-rpi' | | t i n j ) , 16 ) =(hmac(dtk_,||tin_),16)} , where h m a c ( key, data ) )} is a hmac function using sha-256, and t i n j 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 r p i i , j 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 ( t e k i ) is generated. this is analogous to the daily tracing key from version 1.0. here i 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 ( r p i k i ) and the associated encrypted metadata key ( a e m k i ). r p i k i is calculated with the algorithm r p i k i = h k d f ( t e k i , n u l l , 'en-rpik' , 16 ) =hkdf(tek_,null,,16)} , and a e m k i using the algorithm a e m k i = h k d f ( t e k i , n u l l , 'en-aemk' , 16 ) =hkdf(tek_,null,,16)} . from these values a temporary rolling proximity identifier ( r p i i , j ) is generated every time the ble mac address changes, roughly every 15–20 minutes. the following algorithm is used: r p i i , j = a e s 128 ( r p i k i , 'en-rpi' | | 0 x 000000000000 | | e n i n j ) =aes128(rpik_,||||enin_)} , where a e s 128 ( key, data ) )} is an aes cryptography function with a 128-bit key, the data is one 16-byte block, j denotes the unix epoch time at the moment the roll occurs, and e n i n j 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: associated encrypted metadata i , j = a e s 128 _ c t r ( a e m k i , r p i i , j , metadata ) _=aes128\_ctr(aemk_,rpi_,)} , where a e s 128 _ c t r ( key, iv, data ) )} 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 t e k i and their respective interval numbers i 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 i , 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. 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. consent must be obtained by the user to enable the system or publicize a positive result through the system, and apps using the system are prohibited from collecting location data. 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. 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 (gdpr). 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" (as mandated by the gdpr). deployment exposure notification is compatible with android devices supporting bluetooth low energy and running android 6.0 "marshmallow" and newer with google mobile services. it is serviced via updates to google play services, ensuring compatibility with the majority of android devices released outside of mainland china, and not requiring it to be integrated into android firmware updates (which would hinder deployment by relying on individual oems). it is not compatible with devices that do not have gms, such as huawei devices released since may 2019. on ios, en is serviced via operating system updates. it was first introduced as part of ios 13.5 on may 20, 2020. in december 2020, apple released ios 12.5, which backported en support to iphone models that cannot be upgraded to ios 13, including iphone 6 and older. exposure notification apps may only be released by public health authorities. to discourage fragmentation, each country will typically be restricted to one app, although apple and google stated that they would accommodate regionalized approaches if a country elects to do so. apple and google released reference implementations for apps utilizing the system, which can be used as a base. on september 1, 2020, the consortium announced "exposure notifications express" (en express), a system designed to ease adoption of the protocol by health authorities by removing the need to develop an app themselves. under this system, a health authority provides parameters specific to their implementation (such as thresholds, branding, messaging, and key servers), which is then processed to generate the required functionality. on android, this data is used to generate an app, and a configuration profile that can also be deployed to users via google play services without a dedicated app. on ios, the functionality is integrated directly at the system level on ios 13.7 and newer without a dedicated