Does this randomize the Bluetooth address too? I saw the README (from the dissection) mention a function that hides the name "so the other side only gets the address", which would defeat the entire purpose of rotating identifiers.
If it does randomize the Bluetooth address, does it use a separate identifier, and if so, does it rotate both at the same time? Otherwise, you can use an identifier that changes at time 1 to link the other identifier with its new version when it changes at a different time.
It's OpenTrace [0]. OpenTrace is GPLv3, and is based on a published specification that's not too difficult understand. The fact that it is dervived from OpenTrace and they haven't published the source is the whole basis of this story.
To answer your direct questions:
- randomize Bluetooth addresses: I expect not, as that would screw any existing bluetooth connections, like headsets.
- does it use a separate randomised identifier: yes.
On Android at least you would be foolish to trust it without a verifiable chain of trust from the source to the binary you are running. It has two things that matter greatly: your true name, and your precise location. There is nothing physically preventing them from uploading your whereabouts every 10 minutes to a server - so you have to trust the binary doesn't do that. Right now we only have their word [1]. Whether you care enough above the sort of information it could leak to need to trust it is a different question. But if you do care, you would be a fool to do so without a verifiable chain.
A verifiable chain of trust means:
- source starts from a trusted origin. (It does: opentrace)
- there is a cryptographically signed audit trail showing how they change it to get to its current state. (The original is in github, so that's possible).
- they publish the source before deployment. (The two points above means someone inspecting the result only has to look at the changes, not the entire thing).
[1] Right now I'm sure they are good for their word. Move on 24 months and if you still have it installed, then based on their past history I would not trust them as far as I could kick them.
I assume you can use your "regular" Bluetooth address for any communication with paired devices (which is then just as trackable as it would be otherwise), while still using this at the same time for the BTLE announcements.
However, I suspect these APIs may not be available to non-OS applications.
It would be obvious if they tried to get precise location (GPS) as that requires a discrete permission. However, precision location is a red herring -- it isn't needed for intelligence purposes. They are much much more interested in the social graph. From that they can likely back track to calculate approximate location (using cell positioning information and other sources).
Last I looked the OpenTrace was exchanging an encrypted binary blob generated by the government, likely a unique identifier key and timestamp, which could be updated on demand by the server/app owner. Basically there is no anonymity for the user versus the Govt, only somewhat against other users.
I just realised that using bluetooth directly requires location permission on Android. Which makes sense since you can geolocate using the signal strength of known location beacons.
If it does randomize the Bluetooth address, does it use a separate identifier, and if so, does it rotate both at the same time? Otherwise, you can use an identifier that changes at time 1 to link the other identifier with its new version when it changes at a different time.