Infected user tracking

[muehlber]

https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Simplified%20Three%20Page%20Brief.pdf, 6ac1884, p.3:

• A tech-savvy adversary could reidentify identifiers from infected people ​ that they have been physically close to in the past by i) actively modifying the app to record more specific identifier data ​ and ii) collecting extra information about identities through additional means, such as a surveillance camera to record and identify the individuals. This would generally be illegal, would be spatially limited, and high effort.
• A ​ tech-savvy adversary deploying an antenna to eavesdrop on Bluetooth connections can learn which connections correspond to infected people, and then can estimate the percentage of infected people in a small radius of 50m.

https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Data%20Protection%20and%20Security.pdf, 6ac1884, p. 8:

The only way to link a device across multiple broadcast identifiers is by using information held on that individual’s device. This would require access to that device, or obtaining recordings from the device.

There seems to be a contradiction between these two quotes.

You (kind of) clarify this in the White Paper when you define the abilities of the eavesdropper. But, given that even supermarkets deploy ultrasonic and WiFi tracking, this appears to be a rather unrealistic attacker model?

Or do you assume users' mobile devices to use MAC randomisation on all wireless interfaces, and have no other apps installed? Maybe what's really missing is a system model?

[pdehaye]

Indeed, this is very similar to #9, where I also go into the legal consequences of the attack.

[muehlber]

@pdehaye indeed. And you referenced the "proximity marketing" and NYT articles, which I was a bit too lazy to dig up yesterday night. We probably want to continue the discussion in your issue.

[pdehaye]

It's also similar to #37

[pdehaye]

I have sharded away the proximity tracking bit from #9 into a standalone #43, so #9 is exclusively about the legal consequence.

[inaitana]

You are right, my #37 is actually similar to this and #9.

But I wanted to point out how simple the attack can be.
Way simplier than employing large antennas arrays or covert cameras, way more effective than well placed beacons.
A good old wardriving in the evening would be more then enough. And it might even be legal, as per #9.

Add collaborative gathering (possibly on an extra-UE server for safety) and the mass infected tracing is set up with no need of special hardware or access to any resource.

[lbarman]

Hi all, thanks for the input.
@muehlber You're right; it's the second statement which is oversimplified.

The only way to link a device across multiple broadcast identifiers is by using information held on that individual’s device. This would require access to that device, or obtaining recordings from the device.

... or using side-information. In this case, someone close to me can link my identifiers without the secret info in my phone because he visually confirms that it's me in both cases. We will add this precision to the text.

@inaitana Our latest design is specifically addressing the wardriving case (sec 4 p18 of the whitepaper), although not the collaborative gathering case (but making it a bit harder to mass-collect EphIDs). We're open for inputs if you have any suggestion there!

I'll follow the multiple cross-links in issues and answer there - let me know if something else should be answered here!