Proof of concept app that uses opportunistic scanning mode an Android BluetoothLE Scanner to sniff Google/Apple API Bluetooth scans on the device running the app. This allows the RPIs seen by the Google/Apple API to be recorded, together with the time and place and the received signal strength. It has been tested with both the Italian Immuni contact tracing app and the Google exemplar Exposure Notification app.
Since the app uses opportunistic scanning it places no additional drain on the phone battery. It requires no special privileges.
The data collected might be used, for example, to:
- Display the number of nearby handsets running the Google/Apple API (estimated via the number of distinct RPIs observed in each scan), and how this varies with time and location.
- Display the times and places when a user was within range of another handset running the Google/Apple API with a specified Temporary Exposure Key (TEK) (the RPIs associated with the TEK can be generated and matched against logged beacons).
- Display the times and places a user was within range of the handset of person infected with Covid-19 and whose TEKs have been published by a health authority.
- Reproduce the internal state of the Google/Apple API (since the app sees exactly the same beacon data as the Google/Apple API). This might be used to augment a proprietary/enterprise contact tracing app (businesses may encourage use of safety-related apps for employees returning to work) or to allow inter-operability between contact tracing apps in different countries/states. It might be used to allow open source implementations of the Google/Apple API to inter-operate with existing closed-source versions and for independent testing/verification of Google/Apple API operation.
Such apps are far from being a simple "attack". For people using apps such as these it might well be empowering to know the times and places when they have been exposed to an infected person or to monitor the number of nearby handsets and so potential infection risk. The proof of concept app only stores the logged information locally on the handset running the app, and it allows a user to see data that is already publicly broadcast and received by their handset.
However, people with handsets broadcasting Google/Apple API beacons should be made aware that they might be used in this way. When combined with additonal information, e.g. knowledge of work colleagues, it may allow an app user to guess the identity of people whose TEKs have been published by a health authority.
Importantly, if the collected data is shared and aggregated then this may significantly elevate the privacy risks. In particular, aggregating information on the time and place where beacons associated with a particular TEK were observed might allow the TEKs published by a health authority to be de-anonymised (de-anonymisation of location time histories to known to be relatively easy). Combining information on the time and place where beacons from the set of TEKs published by a health authority were observed would allow infection "hot spots" to be inferred.
The technical bar for implementing such apps is very low, as this proof of concept app demonstrates. The main method available for discouraging their use is probably via Google Play Store regulation (the Google Play Store already places substantial constraints on publication of Covid-related apps) although of course other app stores do exist and users can always side load apps themselves.