key: cord-0209579-fdddunmn
authors: Raskar, Ramesh; Singh, Abhishek; Zimmerman, Sam; Kanaparti, Shrikant
title: Adding Location and Global Context to the Google/Apple Exposure Notification Bluetooth API
date: 2020-07-01
journal: nan
DOI: nan
sha: fd7ffd440be44c87fd722286afb3f1bd1fc91ea0
doc_id: 209579
cord_uid: fdddunmn

Contact tracing requires a strong understanding of the context of a user, and location with other sensory data could provide a context for any infection encounter. Although Bluetooth technology gives a good insight into the proximity aspect of an encounter, it does not provide any location context related to it which helps to make better decisions. Using the ideas presented in this paper, one shall be able to obtain this valuable information that could address the problem of false-positive and false-negative to a certain extent. All of this within the purview of Google/Apple Exposure Notification (GAEN) specification, while preserving complete user privacy. There are four ways of propagating context between any two users. Two such methods allow private location logging, without revealing the location history within an app. The other two are encryption-based methods. The first encryption method is a variant of Apple's FindMy protocol, that allows nearby Apple devices to capture the GPS location of a lost Apple device. The second encryption is a minor modification of the existing GAEN protocol so that global context is available to a healthy phone only when it is exposed - this is a better option comparatively. It will still be the role of Public Health smartphone app to decide, on how to use the location-time context, to build a full-fledged contact tracing and public health solution. Lastly, we highlight the benefits and potential privacy issues with each of these context propagation methods proposed here.

Currently, exposure notification obtained from GAEN, only reports the day of an exposure, but does not give any details such as their location or time. We believe that the context of location and time become critical for (i) a user to self-assess their exposure (e.g. if they were wearing a mask, or maintaining social distance at that moment) and inform about the same to those who were around them, or in case they were not carrying their smartphone at all at that point in time, (ii) improve user's trust in the system to reject false-positives (e.g. if they had picked up BLE signal from behind a wall), (iii) help public health officials to perform contact tracing operations more accurately, also requires knowledge of the context (e.g. to request all those attending a wedding to self-isolate at their homes, if an infected person was observed to be at that place, and for a long duration). Lack of context and the lack of an agency can lead to irrational behavior, and civil unrest as explained in our document Contact Tracing: Holistic Solution beyond Bluetooth.

What is Global Context The idea behind global context is to deliver information which would improve exposure notification's accuracy or improve the actions followed by the exposure notification. One important component of the global context is GPS based location (which we also use interchangeably in this paper), in addition, it can have time, phone orientation, motion sensor (in hand or pocket), and any multipath (indoor vs outdoor) information. A user's behaviour and the level of precautionary measures they may need to take may vary depending on their specific circumstances. The risk from an exposure to a carrier also varies in different situations. Thus, the need for spatio-temporal context becomes imperative in contact tracing. Beyond location, there are many other context factors which can be utilized such as -Barometer reading, Ambient light sensor reading, magnetometer reading, gyroscope reading and etc. These sensor reading can unlock the potential of improving the false positive and false negative issues inherently associated with the bluetooth technology Leith & Farrell (2020) Our goal is to enable location-time context to be delivered to the user during exposure notification.

Here are a few possibilities and challenges.

• Log location by the same app An app could be rejected for storing time or location along with its Bluetooth packets, which makes it non-compliant under the current specification of Google/Apple Exposure Notification (GAEN) API.

One can store the GPS trails or any other similar context along with their timestamp using another app, which creates the issue of communication between these two apps, and also prevents mass adoption, as only a small percentage would install and run both these apps in parallel.

The GAEN approved app can estimate timestamp from ENIN, which is windowed at every ten minutes and uses a tolerance window of ±2 hours during the diagnosis key matching. So, one way of achieving this is to use the existing protocol, and use ENIN timestamp from the Bluetooth payload as a primary key between the two databases, and look up global context for intersecting code using another app.

Another important aspect of contact tracing that has been completely overlooked by a majority of existing Bluetooth-based approaches is the lack of assistance for the Policy Makers, Epidemiologists, City Officials, Response Teams, etc. With the availability of location context in a contact tracing app, it would enable the covid positive citizens, to give their consent more effectively, while providing data to the aforementioned decision-makers; and this could shape the policy significantly, to a level where the outcomes could drastically change, if right interventions are performed.

A significant amount of work has been done around contact tracing in the last six months of the COVID-19 outbreak. Raskar et al. (2020a) and Li & Guo (2020) provide a comprehensive survey of the contact tracing ecosystem across different parameters. In this work we are mainly interested in the bluetooth based protocol built by Google gae (2020d) and Apple gae (2020a) which circumvents the system level problem known with the bluetooth in background for the phones and hence has been adopted widely across many countries and states. There are few other protocols which also utilize bluetooth for proximity sensing Chan et al. (2020) ; Trieu et al. (2020) , however, they suffer with the same issue of the hardware compatibility which stops any app from running in the background in iOS. Goal of this work is to ensure privacy and ethical aspects Raskar et al. (2020b) while providing a user some context about the exposure which will make the contact tracing more effective.

We propose a protocol that stays completely within the boundaries of GAEN specification for both the bluetooth gae (2020b) as well as cryptography gae (2020c), based on the idea that Global context information is made available to a healthy phone, only when it is exposed to an infected person around. If Alice is healthy and comes in proximity to Bob, who later was diagnosed Covid+, then Alice will be able to see the location (and time) of that encounter, but rest of her location history shall remain invisible or encrypted -based on minor modification to GAEN, as suggested here. We also propose three other ideas, that do not require any modifications to the GAEN protocol, but rather require Google/Apple to allow apps to access the global context privately on the device and to run independent servers.

Using BLE for proximity, and GPS, sensory data for context exclusively, the 4 privacy preserving solutions we propose that provide location-time context can be summarized as follows:

1. Global context logs stay on device app, does not leave the phone, and no visualization 2. Global context + Time blurred and logged on device, data does not leave the phone, no visualization 3. FindMy variant: Encrypt RPI 4. GAEN variant: Encrypt your own Global context with DailyKey, and Broadcast it over BLE Please refer to this document for GAEN terminology that has been used here. Unless stated specifically, a Healthy person is X (Alice), and a person who gets diagnosed of Covid is Y (Bob).

BT : Bluetooth BLE : Bluetooth Low Energy RPI : Rolling Proximity Identifiers, are privacy-preserving identifiers that are broadcast in Bluetooth payload ENIN : Exposure Number Interval Number (Index of a 10 min window, 144 such windows per day) DailyKey : Diagnosis Keys, a subset of which becomes Temporary Exposure Keys (previously known as Daily Tracing Keys) 1. GPS logs stay on device app, data does not leave the phone, and cannot be visualized Approach 1 -based on direct RPI indexing: Every user logs their location, indexed with RPI. When exposure notification arrives, it matches the RPI with the logged location. We store the location only if there is RPI (which means another BT user was encountered). In this case the database of GPS is indexed with RPI. Approach 2 -based on calculated ENIN: The 144 RPIs generated from the DailyKey provides a match with one of the RPIs (10 minute window) so app has access to the timestamp. From that timestamp, the app can recover the GPS location for that time. In this case the database of GPS is indexed with time. No direct visualization of location log is made available to the user, to prevent unauthorized persons (nosy employers, abusive spouses or border agents) from seeing it.

• Location data stays local and casual unauthorized reader cannot see it (e.g. nosy employer, abusive spouse).

• The app could get rejected, because it stores location log, which is against the GAEN guidelines. • Sophisticated hackers can reverse engineer the exact location from logs.

2. BLE for proximity, GPS for context, GPS is blurred for privacy, data does not leave the phone, and cannot be visualized This is our recommended protocol if GAEN and GPS APIs can co-exist.

Same as solution 1, but the location-time is quantized in space-time, in order to blur it before storing locally on the phone. For example, based on the local population density, the blur can be about 200m in a city or 1km in the suburbs. With the help of user's own memory, the user can figure out where the exposure encounter could have happened.

• A nosy employer cannot see specific location data.

• A sophisticated hacker who can reverse engineer, cannot get the exact location because it has been quantized.

• Context could be reduced significantly, and hence this method appears to bring the classic dogma of utility vs privacy tradeoff. • Context could also be wrong in some cases.

• Possibility of on-the-fly attacks, when an attacker has prior knowledge of the precise location.

3. GPS is encrypted with the RPI of an infected person Borrowing the concept of "upload what you heard" described in FindMy protocol. Every user encrypts their own GPS value, using public key of the user nearby and stores them locally. The healthy user phone then downloads the DailyKey and computes the list of RPIs that are related to it, and checks for the intersections if any with the list of heard RPIs using the existing GAEN API. Using which the corresponding encrypted location data is decrypted using their own private key. Note that both UUID x and PublicKey x keep rotating at every 15 minutes interval. Rotating PublicKey x while keeping the same PrivateKey x in an efficient manner is non-trivial, hence we propose to use the already built-in FindMy device protocol by Apple.

Algorithm 1: Encryption of context with infected person's RPI X is a healthy person and Y is infected; X emits (UUID x , PublicKey x ); Y receives (UUID x , PublicKey x ); Y encrypts its own GPS as D = Encrypt(PublicKey x , GPS y ) at this point; stores it locally (GPS x == GPS y ); Y gets identified as infected; Y uploads the data it had stored into a diagnosis server (UUID x , D x ); X pulls data from the diagnosis server; X performs a comparison, and finds a match with its UUID x ; X uses its own PrivateKey x obtains: GPS x = Decrypt(PrivateKey x , D x )

• Scalability, as this would need a lot of public keys to be encrypted • A sophisticated attacker could reverse engineer the key X 4. GPS in existing GAEN protocol "Upload what you broadcasted" as in GAEN protocol (as well as MIT PACT). In the following proposals we extend the existing GAEN scheme to allow context sharing. We propose two ways for this: one is based on Asymmetric key infrastructure, while the other is based on Symmetric key infrastructure. Our goal is to use the new Associated Encrypted Metadata (AEM) supported in GAEN. AEM currently is for the purpose of sharing BLE signal strength. We assume that we can append GPS value into this metadata, which gets broadcast over the BLE.

Using this protocol, Alice can recover the GPS location of her contact (and hence her own location) only for locations for which she received the Exposure Notification. She does not have access to the rest of her location history or the infected person's location history.

(a) Using Asymmetric key encryption -Algo Steps Every device has a Rotating Public Key -RPublicKey, and a single PrivateKey. This RPublicKey is different from the RPI, that is used in GAEN. We aim to encrypt the GPS with this RPublicKey, and the healthy user can then recover the encrypted GPS, using the corresponding PrivateKey downloaded from the server. RPI = Rolling Proximity Identifiers (broadcast over BLE as in GAEN), RPublicKey = Rotating Public Key (RPublicKey and a single PrivateKey)

Algorithm 2: Asymmetric key encryption based GAEN context encoding Infected phone Y emits ( RPI y , RPublicKey, Encrypt(RPublicKey, GPS y ) ) Healthy phone X, over BLE, receives this ( RPI y , RPublicKey, Encrypt(RPublicKey, GPS y ) ) and stores it locally If infected, Y uploads (DailyKey y , PrivateKey y ) With GAEN, Healthy phone X, downloads (DailyKey y , PrivateKey y ) X from DailyKey y , generates {RPI y } X finds the corresponding entry ( RPI y , RPublicKey, and Encrypt(RPublicKey, GPS y ) ) X obtains GPS y by Decrypt( PrivateKey y , Encrypt(RPublicKey, GPS y ) )

This approach does not change anything about the uploading of DailyKey. It changes the BLE payload to include GPS encrypted with DailyKey. The Encrypt method could be AES (key size can be adjusted to use standard 128 or 256 bit size).

Algorithm 3: Symmetric key encryption based GAEN context encoding Infected phone Y emits ( RPI y , Encrypt(DailyKey y , GPS y ) ) Healthy phone X, over BLE receives the same, and stores it locally ( RPI y , Encrypt(DailyKey y , GPS y ) ) Once diagnosed as infected, phone Y uploads its (DailyKey y ) As part of GAEN, the Healthy phone X, downloads (DailyKey y ) From DailyKey y , phone X generates its RPI y X Identifies the corresponding entry (RPI y , Encrypt(DailyKey y , GPS y )) X Extracts GPS y by Decrypt( DailyKey y , Encrypt(DailyKey y , GPS y ) ) (c) Using Symmetric key encryption and consent after infection We allow a consent mechanism after the broadcast. The user may have consented to broadcast BLE Ids, and also shared their encrypted GPS. But the infected user may change their opinion to share only the BLE, and not allow the healthy user to decrypt their GPS location. User keeps a 'ConsentSecret' code, and this is appended to the DailyKey 1 . The RPI is derived from DailyKey, and hence BLE decoding is not impacted. But GPS is encrypted with the key that appends DailyKey y with ConsentSecret. If the inflected user refuses to upload the ConsentSecret, the broadcast encrypted GPS coordinates cannot be recovered. Rest of the protocol is the same as 4(b) above.

Algorithm 4: Symmetric key encryption based GAEN context encoding Infected phone Y emits ( RPI y , Encrypt(DailyKey y || ConsentSecret y , GPS y ) ) (|| refers to the concatenation operator, for cryptographic reasons, it is advised to use XOR instead) Healthy phone X, over BLE, receives the same, and stores it locally ( RPI y , Encrypt(DailyKey y || ConsentSecret y , GPS y ) ) Once diagnosed as infected, they shall upload their (DailyKey, ConsentSecret), where 'ConsentSecret' is a unique secret key for allowing consent to be provided for decrypting location context, or just provide exposure notification a . With GAEN, Healthy phone X, downloads (DailyKey y , ConsentSecret y ) From DailyKey y , reconstructs RPI_y Find the corresponding entry ( RPI y , Encrypt(DailyKey y || ConsentSecret y , GPS y ) ) Extracts GPS y by Decrypt( DailyKey y || ConsentSecret y , Encrypt(DailyKey y || ConsentSecret y , GPS y ) ) a For brevity we are keeping ConsentSecret here as a non-rotating unique secret key, but this can be changed in the upcoming version of the draft

This is our recommended algorithm if GPS is supported only in BLE payload. This does not change anything about the uploading of DailyKey. It rather changes the BLE payload to include a Blurred GPS encrypted with DailyKey. It allows infected user to change the Consent as frequently as DailyKey is changed. Currently, DailyKey changes per day, but in the future, they may change more frequently as in PACT, allowing more fine grained Consent by the infected user.

Algorithm 5: Symmetric key encryption based GAEN context encoding with blurred location Infected phone Y emits ( RPI y , Encrypt(DailyKey y || ConsentSecret y , FGPS y ) ) (|| refers to the concatenation operator) and FGPS y is quantized GPS. Quantization based blurring of location can be fixed, or vary from 100's of meters to 1km depending on the population density around that location. Healthy phone X, over BLE, receives the same, and stores it locally ( RPI y , Encrypt(DailyKey y || ConsentSecret y , FGPS y ) ) Once diagnosed as infected, they upload (DailyKey, ConsentSecret), where 'ConsentSecret' is a unique secret key for allowing consent to be provided for decrypting location context or just provide exposure notification. With GAEN, Healthy phone X, downloads (DailyKey y , ConsentSecret y ) From DailyKey y , reconstructs RPI y Find the corresponding entry ( RPI y , Encrypt(DailyKey y || ConsentSecret y , FGPS y ) ) Extracts FGPS y by Decrypt( DailyKey y || ConsentSecret y , Encrypt(DailyKey y || ConsentSecret y , FGPS y ) ) Which is a blurred location that is enough to provide context for the user, but does not provide the exact location.

• Only DailyKey is uploaded as in GAEN, so no change in upload protocol • A minor change in the BLE payload • GPS (encrypted) is available only to the proximate phone, so there is little or no risk to a non-proximate person • GPS history is invisible Challenges

• BLE payload increases but GAEN payload has plenty of space

We consider three possible levels of attack (The three levels are not mutually exclusive):

On-the-fly attack This scheme of attack is performed by an attacker acting either as a Healthy person or a future-infected person. They can potentially do two kind of attacks:

• Snoop on information.

• Spread wrong information through the Bluetooth transmission.

Post processing attack

• In this setting of attack, the attacker tries to make sense out of encrypted and unencrypted information available after collection on their phone or force someone else to show these information present on their phone.

• In this scheme, multiple individuals align together to share their data with each other in a distributed way to attack the secrecy and privacy of individuals or groups of individuals.

There are different threat actors against whom protection is required:

Nosy person looking at stored GPS trails because visualization is easy

• Can force the user to open the app and show any data visible on the screen.

Hacker looking at stored GPS trails if available in raw format somewhere in the app

• Can reverse engineer their own app to inject code on top of APIs (This is only possible by jailbreaking the iOS and rooting the Android OS).

• Can perform packet captures and snooping.

• Can not force the user to open app and share data with the attacker.

State actors reverse engineering information using poorly encrypted trails (using side channel)

• Combines the capabilities of the above actors and in addition can leverage multiple sources and supercomputing capabilities for cryptanalysis.

From the GPS location, for an added context, the user may need to call a reverse geocoding API to find the street address or name of the business there. If performed naively, this API call will leak user location. The easiest way to resolve would be to perform regional map caching but this approach is beyond the scope of this document.

In this proposal we have outlined several ways of allowing context-enabled contact tracing. We believe the contextual information and time will allow citizens to take informed decisions and reduce panic.

In the spirit of respecting privacy, allowing consent, and delivering context within the Exposure Notification service, we advocate for the adoption of Proposal 4(b).

Exposure Notification reference by Apple

Exposure Notification, Bluetooth Specification

Exposure Notification, Cryptography Specification

Exposure Notification reference by Google

Privacy sensitive protocols and mechanisms for mobile contact tracing

Coronavirus contact tracing: Evaluating the potential of using bluetooth received signal strength for proximity detection

Covid-19 contact-tracing apps: a survey on the global deployment and challenges

Covid-19 contact-tracing mobile apps: Evaluation and assessment for decision makers

Epione: Lightweight contact tracing with strong privacy