Additional design considerations

Stay organized with collections Save and categorize content based on your preferences.

There are a number of risk factors we considered during the Exposure Notification (EN) system framework.

Bluetooth traffic

The following mitigations address concerns about apps with location and Bluetooth admin permissions sniffing EN Bluetooth packets to gather information about devices.

  • All Bluetooth Low-Energy (BLE) packet MAC addresses rotate at least every 15 minutes alongside the EN RPI. For users who have not consented to upload their diagnosis keys following a positive COVID test result, an attacker cannot learn any more about the user than they already can by sniffing BLE packets. At most, a person's device can be recognized for 15 minutes by another device within physical BLE range.
  • An attacker with access to downloaded Temporary Exposure Keys (TEKs) and BLE sniffer apps on multiple devices could link together different observations of the user over the rolling window period but not longer. To reduce impact on users' network bandwidth, this window is set at 24 hours but can be reduced to lessen risks.
  • Unless the attacker has an independent means (for example, camera network) of identifying users whose devices are transmitting BLE packets, the attacker will not learn the identity of infected users or anything about who associates with whom. If an attacker has a mechanism for identifying users in proximity, then they could already use this to track the user's movements, and BLE does not significantly increase tracking risks.
  • Any such attacks using Google Play apps would be a violation of Play Store Privacy, Security, and Deception policies. We remove apps found to be in violation of our policies from the Play store.

Metadata authentication

The only purpose of Bluetooth is to transmit data through radio signals, so the risk of a relay attack is always present. A concern in this context is that the Associated Encrypted Metadata (AEM) transmit (TX) power could be altered as part of a relay attack.

We do not believe that TX power authentication would be a useful defense against relay attacks for the following reasons.

  • TX power authentication would not prevent the use of "zombie" phones to relay packets.
  • TX power authentication would not protect against the use of a high-power antenna positioned so as to cover a large area with a signal strength indicative of "nearness" because the system is designed to be highly tolerant of differences between TX-power and RSSI, for example caused by both devices being in-pocket. For example, some Android devices transmit signals 30dB weaker than others, so relaying a packet from such a device on a higher transmit power device would already make the device appear nearby without mutating the TX field.

Defenses using timestamps were also considered, but rejected since packets are typically relayed at the speed of light and matching must be tolerant to legitimate variations in timing (such as processor speed).