Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy compromised through querying services? #111

Open
romeokienzler opened this issue May 18, 2020 · 7 comments
Open

Privacy compromised through querying services? #111

romeokienzler opened this issue May 18, 2020 · 7 comments

Comments

@romeokienzler
Copy link

romeokienzler commented May 18, 2020

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

@jeffallen
Copy link
Contributor

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?

@romeokienzler
Copy link
Author

@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....

@romeokienzler
Copy link
Author

romeokienzler commented May 19, 2020

@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

@simonroesch
Copy link
Contributor

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

@pdehaye
Copy link

pdehaye commented May 27, 2020

@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.

@romeokienzler
Copy link
Author

@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

@ozppupbg
Copy link

ozppupbg commented May 28, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants