Contact tracing with static Contact IDs

The App User is identified with a pseudonym that never changes

Approach:

• The App assigns a pseudonym to each App User, called a Contact ID. This Contact ID remains the same for each App User for as long as the system is running (e.g. weeks, months or longer). Depending on the implementation, this Contact ID is either:
  • generated on the Smartphone Component, or
  • obtained from the Cloud Component.
• The App Instance broadcasts the Contact ID via Bluetooth Low Energy (BLE).
• Each App Instance also records all broadcasted Contact IDs it detects.
• When infected, the App User uploads the recorded pseudonyms to a central server.
• Uploaded Contact IDs are now marked as “exposed” in the central server.
• The App Users with a Contact ID marked as “exposed” are being notified of their exposure. The mechanism by which the matching and notification occurs can vary (pull vs. push model, for example).

Criticism:

Static Contact IDs for contact tracking purposes are similar to universal tracking cookies on the web: they enable a variety of privacy compromises. This is why many web browser manufacturers now block universal tracking cookies (e.g. see this article).

When such static Contact IDs are broadcast via Bluetooth Low Energy (BLE) rather than as tracking cookies on the web, privacy problems become arguably worse:

• Not just some websites, but everybody with a Bluetooth-based device can track App Users in their vicinity.
• This tracking can be performed without the possibility of being detected, as no communications (only listening) is required on behalf of the tracker.
• Unlike for tracking cookies which can be deleted, App Users only have the choice of not running the App in the first place, which defeats the contact tracing objective.
• When tracking Contact IDs, the location of the App Users is known within a small radius, and so it is easy for an Attacker to, for example, also take a photograph of the App User for later identification.

Specifically:

• Once a Contact ID has been correlated with a certain individual (or even just an unspecific member of a group), their locations before, and their location after, can be attributed 100%. So if the App User were to run an App with this implementation for one year, and their identity was established once, all of their locations for the entire year can now be attributed to this individual.

  This contrasts with other implementation alternatives in this group, where, for example, Contact IDs for a given App User change every 5 or 10 minutes, and longitudinal correlation is not possible as the changing Contact IDs cannot be correlated by an Attacker.

• There are many situations where Contact IDs can be attributed to a specific individual by many parties.

  • For example, if an App User pays with a credit card in a business, the business can easily record both the name of the App User (which is shown on the credit card) and the Contact ID (because the App User’s mobile phone is in close proximity). Because the Contact ID never changes, this now enables tracking of the App User 24x7. This is only an example scenario; many similar ones are also enabled.

  • Neighbors who know the name of their neighbor and can easily determine their Contact ID, e.g. simply watching when the neighbor is home or not while observing the presence of certain Bluetooth Low Energy (BLE) beacons at the same time.

  • Any entity, including government, that requires an App User to show identification documents for any purpose. This is similar to the credit card example.

  • Note that this Attack is available to anybody with the respective skills or third-party software to record Bluetooth Low Energy (BLE) beacons. This includes governments, businesses, disgruntled spouses, employers and so forth.

• Even if a given Contact ID is never directly associated with other Personally Identifiable Information, recording Contact IDs in public allows the large-scale creation of social networks of Contact IDs. Depending on what other information is available to the Attacker, it may be entirely possible to re-identify individuals from nothing else than their recorded social/proximity graph of Contact IDs.