DP-3T/dp3t-sdk-android

Privacy compromised through querying services?

romeokienzler opened this issue · 7 comments

Dear team,

first of all, thanks a lot for your work, I really appreciate your efforts. It is very important to get the privacy right to reach the 60%+ adoption and you are heavily contribution towards this goal, many kudos to you!

I'm a (hobby) security researcher and used a Raspberry Pi Zero W and the blescan tool from the bluepy package "against" your android app.

So if I'm in "listen only" mode, it's pretty obvious that privacy is preserved as you can see from the two traces:

sudo blescan -v |grep -B 5 8c8494e3-bab5-1848-40a0-1b06991c0000
Got: 'rsp=$scan\x1eaddr=b5BC195D323CA\x1etype=h2\x1erssi=h3A\x1eflag=h0\x1ed=b020102020AF1110700001C99061BA0404818B5BAE394848C13FFBAABBF69D9117F72F946302F293073C76102\n' Device (new): 5b:c1:95:d3:23:ca (random), -58 dBm Flags: <02> Tx Power: <f1> Manufacturer: <baabbf69d9117f72f946302f293073c76102> Complete 128b Services: <8c8494e3-bab5-1848-40a0-1b06991c0000>

sudo blescan -v |grep -B 5 8c8494e3-bab5-1848-40a0-1b06991c0000
Got: 'rsp=$scan\x1eaddr=b51EE4A385C86\x1etype=h2\x1erssi=h3C\x1eflag=h0\x1ed=b020102020AF1110700001C99061BA0404818B5BAE394848C13FFBAABC36017B56C95F72E139BE6C1C596F8FC\n' Device (new): 51:ee:4a:38:5c:86 (random), -60 dBm Flags: <02> Tx Power: <f1> Manufacturer: <baabc36017b56c95f72e139be6c1c596f8fc> Complete 128b Services: <8c8494e3-bab5-1848-40a0-1b06991c0000>

As you can see, the Service ID stays the same but the MAC address as well as the EphemeralID change. Great!

But here is the catch:
As I know the temporary, random MAC address I can now scan the device on the services offered and what I get back from that scan isn't changing through two subsequent runs and therefore can be used to fingerprint and track devices over a long period of time.

I'm attaching the two connection scan traces as well for your review.

Trace 1
Trace 2

E.g. search for the string 8b17cf6cbfe8 in the two traces and you'll find it in both

I've recorded this in a video to make it more clear
https://www.youtube.com/watch?v=aoEPH9OnruE

I believe that the current focus is on replacing the original BLE advertising system with the Google/Apple Exposure Notification system, see branch gaen: https://github.com/DP-3T/dp3t-sdk-android/tree/gaen

Could you take a look at the GAEN Bluetooth spec and see if you think this issue of querying services is considered there? https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf

I took a quick look now, but I'm not an expert in Bluetooth, I don't understand what service querying is, and if it can/should be disabled?

@jeffallen thanks a lot for getting back. I'm neither a bluetooth expert but I'll have a look at the GAEN branch. I guess that somehow service discovery needs to be disabled on the bluetooth stack on the mobile device somehow ... not sure if this is possible as part of the stack IMHO are cast into hardware ... hoping to get a bluetooth expert into the loop....

@jeffallen just checkedout out the GAEN branch, so the only reference to com.google.android.gms.exposurenotification I can find in AndroidManifest.xml - where the app needs to claim permission to use the service. nothing more so far ... will update this issue once we can see if the GAEN API fixes the problem

The GAEN branch is now merged to develop and master-alpha. The interaction with the Google framework happens all in this class: https://github.com/DP-3T/dp3t-sdk-android/blob/develop/dp3t-sdk/sdk/src/main/java/org/dpppt/android/sdk/internal/nearby/GoogleExposureClient.java

@romeokienzler to add to your question, the Apple update will filter the packets at OS level with BLE UUID header "0xFD6F". It looks like the Android update via Google Play will however not be able to do that.

@pdehaye thanks a lot. offered in DP-3T/documents#69 to do the tests again on the GAEN implementation once available. btw. will publish the source code on the testing framework (based on a Raspberry Pi Zero W) soon

@romeokienzler
Apparently the public security test and the pilot test have been started:
https://www.melani.admin.ch/melani/en/home/public-security-test/infos.html

So the first option to test this might be to get into the pilot:
https://play.google.com/store/apps/details?id=ch.admin.bag.dp3t
https://www.ubique.ch/swisscovid-pilot-ios/
And in the FAQ (which is not yet available in English), they mention 4 links to get access to the API with a self-compiled app:
Apple:
https://developer.apple.com/contact/request/download/Exposure_Notification_Addendum.pdf
https://developer.apple.com/contact/request/exposure-notification-entitlement
Android:
https://blog.google/documents/72/Exposure_Notifications_Service_Additional_Terms.pdf
https://support.google.com/googleplay/android-developer/contact/expo_notif_api

I haven't looked into this or tested it, but this might be the way to go.