Potential privacy issues due to Bluetooth scanning services

[kbobrowski]

What is missing

Information about services running on devices that may monitor beacon data, whether these services are filtering only specific type of beacons (not to capture beacons used for contact tracing), and in case these services might pose privacy risk - how to disable them.

Why should it be included

edit: in short - the privacy risk for the user is that a service or an app running on user's device may be collecting BLE beacons, and could infer if user was in contact with infected person (based on published Diagnosis Keys). If additionally timestamps and location data is collected, it could be possible to infer time and location of the contact. Google Location Services is a known example of a service which was reported to collect BLE beacons, but this issue may apply to any service / app with Bluetooth and internet access. This threat applies also to users without CWA installed. See discussion below for more details.

According to reporting by Quartz, enabled Location History results in sending to Google's servers scanned beacon data:

The MAC address, identifier, type, and two measures of signal strength of every nearby Bluetooth beacon

In another article Quartz reports that in order to turn off transmitting beacon information to Google, user has to either switch off both Bluetooth and "Bluetooth scanning" or turn off "Location History".

This issue is also described in a document from Australian Competition & Consumer Commission:

If Location Accuracy is set for “High accuracy” and Location Scanning is enabled, the Android device will also scan for Wi-Fi and Bluetooth signals even if a user toggles Wi-Fi and Bluetooth off on the Android device. Collected Wi-Fi base station and Bluetooth beacon data is transmitted to Google to provide updated data for GLS.

In this document a letter from Google's VP to US Senators is attached at the bottom, where she specifies that:

There are other Google products that may scan and collect certain information from Bluetooth beacons near the device. This includes information that any Bluetooth beacon may be publicly broadcasting for use, such as beacon type, beacon identifier, signal strength, and broadcast power

Where should it be included

Probably the most efficient way to resolve this issue is to aquire an assurance from Google that these services filter only specific types of beacons to be transmitted (e.g. iBeacons and not the type of beacons used for contact tracing), or that this system is suspended for as long as Bluetooth tracing needs to be active. This assurance could be included in the documentation and/or application, to increase user confidence in keeping Bluetooth on. Independent audit of the code behind these services would also increase confidence.

Alternatively, if turning off Location History is indeed stopping beacon information from being transmitted to Google's servers, instruction to do so may be included in the application. The problem with this approach is that it would only prevent user device from sending other users beacon data, it would still allow user beacon data to be transmitted by other devices (even those without CWA installed).

[mh-]

@kbobrowski Sorry, I don't understand why this could be a privacy issue. Is your point that a 3rd party (like Google) could also do BLE scanning, and receive RPI beacons? IMHO the system is designed such that transmitting these beacons is not a privacy issue, and if that's the case, then it doesn't really matter if a 3rd party collects them. Could you please clarify?

[kbobrowski]

@mh-, if 3rd party registers BLE frames around you it could simply infer whether you were exposed, right? Using published TEKs and own implementation of part of Exposure Notification API. Do we have currently a cryptographic component that would prevent this?

[mh-]

@kbobrowski "if 3rd party registers BLE frames around you it could simply infer whether you were exposed, right? Using published TEKs" - yes, and so could everybody else who was around me, because this is the main purpose of advertising these frames in the first place. Once I publish TEKs as Diagnosis Keys, other users should be warned. However, I think the key point is that none of these parties can link these randomly generated TEKs to me as a person.

[kbobrowski]

@mh- sorry I was not precise enough - what I mean is that if 3rd party registers BLE frames sent to you by other people, it would be able to infer if you were in contact with person who later was declared as infected. It would be possible using published TEKs of other people, and BLE frames that you received from other people. This is a scenario in which you never publish your TEKs - 3rd party will only learn that you were in contact with someone who was tested positive, not that you were tested positive.

As far as I understand, the system is safe with respect to sharing your RPI beacons around and it's true that it cannot be traced to you as a person after you publish your TEKs. But it is not safe in a way that you can share what RPI beacons you have received - because it could reveal if you were in contact with covid-positive person. That's why these received RPIs have to be stored in secure local storage on your phone - but it won't be the case if they are listened to and transmitted to some external server.

[mh-]

@kbobrowski Ok, thanks, now I understand your concern. Google could achieve that more easily by secretly monitoring calls to getTemporaryExposureKeyHistory(), but the scheme that you describe could be hidden more effectively on their servers.

Personally I don’t see a high risk in this context, and I think the goal of the assurance you mentioned is already covered by the assurances of Apple and Google regarding the overall Exposure Notification system. But I see your point.

[kbobrowski]

@mh- I also don't believe that Google would consciously decide to perform this attack, but since it seems that a system which gathers received BLE frames is already up and running, this sensitive data may appear on Google servers "accidentally" - unless Google was only looking for specific frame types, or already rolled out update to stop transmitting this data. In any case, I think would be safe to check.

This concern also extends to any app which has access to internet and Bluetooth, but to counter this we would probably need to have some community effort to monitor if the app triggers Bluetooth scanning - I think it should be possible on Android (like using btmon tool on Linux).

This attack vector also applies to users without CWA installed, so potentially 3rd party could know if a user was in contact with infected person even if this user decided not to participate in contact tracing.

[mh-]

@kbobrowski Yes, the 0xFD6F beacons should be of particularly low value for positioning purposes, since they are usually transmitted by moving devices.

Regarding the wider concern that other malicious apps could now see the same beacons as the Exposure Notification service, and could thus try to estimate themselves whether a user was exposed, it would be a good idea if Android's BLE scanning now suppressed such beacons by default, unless the user explicitly activates that, e.g. in a developer setting. I don't think that this could be rolled out via a Play Services update, though.

[egandro]

Regarding the wider concern that other malicious apps could now see the same beacons as the Exposure Notification service, and could thus try to estimate themselves whether a user was exposed, it would be a good idea if Android's BLE scanning now suppressed such beacons by default, unless the user explicitly activates that, e.g. in a developer setting. I don't think that this could be rolled out via a Play Services update, though.

Such simple "devices" can be creates with a budget of $3-5. One could use a ESP32 devices (BT and Wifi) and just use this as a BT Emitter/Receiver while the "APP" is faked and duplicated in a data center and accessed by WiFi.

I personally think this is a very easy scenario that can impact the whole infrastructure for a very small budget.

The most vulnerable position would be, to use such fake ID devices in a location where a lot of people meet e.g. S-Bahn, U-Bahn, Airports, ...

[kbobrowski]

@egandro, there is a risk of such device being built and sold, I'd be a bit concerned about a situation where it is targeted against specific individuals, e.g. curious person could install such device close to a place where another person spends a lot of time (working chair etc.) and monitor whether target person tested positive (using own implementation of Exposure Notification API with strong signal / long exposure needed for contact event or properly damped Bluetooth antenna). But maybe this should be a topic of another issue.

Here we are trying to figure out how to deal with a threat of malicious service / application running on your device, thus able to get information whether you have been in contact with infected person. In fact it does not even have to be malicious application, we can imagine scenario where app associated to a smartwatch / headphones / heart rate monitor is eagerly reporting Bluetooth scan logs to company server, and data on this server is leaked - it would be possible to calculate if device owner was in contact with covid-positive person (and then try to sell fake post-exposure treatment or just publish this data).

@mh- yes, it seems likely that restricting what Android BLE can scan (or authorize specific service to scanning specific type of beacon) is not possible just by updating Google Play services. Perhaps encrypting each sent Bluetooth frame with rotating key could be a solution, but then we'd need to synchronize this key across all devices (in secure way, so only official applications get this information), if I'm not mistaken it is not part of current architecture.

By the way, I think identification of users who got in contact with infected person is only one way to use transmitted beacon data, there are also other privacy threats - e.g. if widely deployed service or app registered the same BLE frame received by two different users at the same time it'd be able to infer that these two users met each other (and for n users build more complex social graphs), it's already possible using currently deployed (stationary) beacons, but with wide deployment of contact tracing app this information can be much more fine-grained.

[mh-]

@kbobrowski Distributing the Diagnosis Keys only to "official applications" would serve the same purpose and could be integrated into the current architecture, however I'm quite certain that this would be hacked and the Diagnosis Keys be leaked in no time.

Regarding your statement on other privacy threats, I agree, but there are other mechanisms like position tracking that included these threats already in the past.

I think this is still a good trade-off; in this context there's a nice quote from Bruce Schneier: "And, yes, I know the game [...] works by tracking your location. I'm all right with that. As I repeatedly say, Internet privacy is all about trade-offs." https://www.schneier.com/blog/archives/2017/11/fraud_detection.html

[kbobrowski]

@mh- agree with the quote, it's all about trade-offs. Still hope though that there is some clever cryptographic solution possible that would at least prevent any external app/service on my phone from figuring out whether I was in contact with infected person.

[kbobrowski]

similar issue is discussed at DP-3T/documents#222

[egandro]

@egandro, there is a risk of such device being built and sold, I'd be a bit concerned about a situation where it is targeted against specific individuals, e.g. curious person could install such device close to a place where another person spends a lot of time (working chair etc.) and monitor whether target person tested positive (using own implementation of Exposure Notification API with strong signal / long exposure

Or an android phone running a custom rom with lots of BT devices connected to a USB hub... very simple - very simple. It's just sending old school ATZ Heyes Modem strings to a serial device.

There is no way in making an educated guess if a device is a battery or a USB hub with 16 BT dongles.

You can flood a lot of events. Of course there is top level of maximum "plausible" events - since you don't track GPS position they are plausible. Putting this devices in the direct area of an airport will mark a lot of individuals as "super contacts".

This will either create a "lot of dummy work" or letting go of infections people who can't be traced back as real or as fake.

Happy new world.

[kbobrowski]

@egandro I think what you are describing is also a potential attack vector, but it would require someone really determined in wrongdoing to locally decrease functionality of the system. Let's keep this issue focused on potential threat from an app running on user phone, perhaps we could discuss attacks using external hardware in separate issue.

Just checked and on my Android phone 52 out of 74 apps have "Location" permission, which allows each of them to scan for BLE beacons. If only one the popular apps happens to dump scanned BLE data to external database, and suffers data leak it may have disastrous consequences for the trust in the system, and should be somehow prevented. This is assuming that one can determine "contact with infected" status just from raw received BLE frames and Diagnosis Keys. I still hope this is wrong and there is some mechanism to prevent this, hopefully we'll get clarification from CWA team.

[egandro]

@egandro I think what you are describing is also a potential attack vector, but it would require someone really determined in wrongdoing to locally decrease functionality of the system.

I just checked my phone. Serial (=could be BT dongles!) just appear as expected on my stock ROM with a USB Hub. The cheapest BT 5 dongle I can find is below 2€. So yeah. ... somebody WILL do this.

[lukasmasuch]

@mh- @kbobrowski Sorry for the off-topic comment, but you both had a spot in Tagesschau yesterday :) Thanks for your engagement!

[kbobrowski]

Closing since it's clear that it cannot be mitigated - at the same time this threat seems to be low