Erroneous assertions on need for physical infrastructure

[pdehaye]

In this section

the passage on the requirement to deploy physical infrastructure to attack Exposure Notification is wrong.

See (among other sources) this paper, recently accepted at the 19th Workshop on Privacy in the Electronic Society, WPES 2020, coincidentally chaired by the lead author of CrowdNotifier.

This last paper is particularly relevant in the context of the attack described in the screenshot above, since of course a SDK-based attack would benefit of all the might of adtech to discriminate via, for instance, false notifications.

[wouterl]

The “ie.” should have been an “e.g.”. Will fix. Apps that act as confused deputies by emitting the attacker’s beacons still constitute physical infrastructure. However, more to the point: The attack described in the WPES paper is neither costless nor does it have unlimited scalability. Modifying SDKs and getting it integrated into apps costs real money.

There is also the risk of detection to consider. The larger the deployment base of the malicious SDK, the sooner it is detected, e.g., by security researchers. It is highly likely that these apps are subsequently removed from the play store. Resulting in an even higher financial penalty.

Finally, please respect the Code of Conduct and keep this a friendly space. Please refrain from referring to people when this is not central to the point. (See also #6)

[pdehaye]

Apps acting as confused deputies still constitute physical infrastructure, but the cost has already been borne out by someone else (the confused deputy). One of the attacks described in the WPES paper is completely passive on the Bluetooth channel (biosurveillance attack), to the extent that the only cost when operating the attack is in the battery and bandwidth in sending beacon payloads back to base. This is highly scalable and the cost is negligible (it has been confirmed to me that in some cases there is even no costs in bandwidth on the attacker side, as they can use free tiers on AWS etc). This biosurveillance attack also enables making the active attack more targeted, i.e. harder to detect when interference attacks are actually run.

It is unlikely such apps would be removed in the play store, beyond the most trivial examples. The person writing these lines can confirm that Google Play Store enforcers state their appreciation of reports of (potentially-)malevolent apps, but can also observe Google made the following change in its previous commitment around GAEN:

It's not exactly confidence-inspiring, especially given the difficulty of detecting such apps in the first place.

In addition, the NCSC (Swiss Cybersecurity authority) has confirmed not to be doing such audits either.

Remains the question of how an attacker could place themselves in such a situation. We discuss the financial cost of doing so in the WEPS paper, and actually observe that there is already a market around building such SDKs, showing the attack comes at no cost actually, when the motives are profit: it's just an extra revenue stream, where the biosurveillance attack transforms into a hedge fund attack.

In addition to SDKs, similar attacks could be run from browsers, leveraging a new litany of browser-based and adtech-based vulnerabilities.

I do not see the fact of neutrally referring to people, even when this is not the central point, as unfriendly. It might not be the central point, but is not an irrelevant point either. Six months after this issue has been posted, there is still no real acknowledgement from GAEN or DP-3T of the threat posed by SDK-based attacks. Worse, there is a consistent misrepresentation of the pertinence of this threat.

[carmelatroncoso]

Thanks for the pointer to Google's repository. This is a repository for CrowdNotifier, where we will fix the text as suggested. A discussion of DP-3T/GAEN security is out of the scope of this document. We suggest you bring the issue to Google/Apple and propose solutions to them.