Contact Tracing Made Un-relay-able
Abstract
Automated contact tracing is a key solution to control the spread of airborne transmittable diseases: it traces contacts among individuals in order to alert people about their potential risk of being infected. The current SARS-CoV-2 pandemic put a heavy strain on the healthcare system of many countries. Governments chose different approaches to face the spread of the virus and the contact tracing apps were considered the most effective ones. In particular, by leveraging on the Bluetooth Low-Energy technology, mobile apps allow to achieve a privacy-preserving contact tracing of citizens. While researchers proposed several contact tracing approaches, each government developed its own national contact tracing app.
In this paper, we demonstrate that many popular contact tracing apps (e.g., the ones promoted by the Italian, French, Swiss government) are vulnerable to relay attacks. Through such attacks people might get misleadingly diagnosed as positive to SARS-CoV-2, thus being enforced to quarantine and eventually leading to a breakdown of the healthcare system. To tackle this vulnerability, we propose a novel and lightweight solution that prevents relay attacks, while providing the same privacy-preserving features as the current approaches. To evaluate the feasibility of both the relay attack and our novel defence mechanism, we developed a proof of concept against the Italian contact tracing app (i.e., Immuni). The design of our defence allows it to be integrated into any contact tracing app.
The analyzed relay attack scenario involves two honest Immuni app users (A and B), and two malicious attackers (Adv1 and Adv2).
B is an individual located in Place Y and has a high risk to be diagnosed positive to SARS-CoV-2 (e.g., a patient in a hospital). Adv2 approaches B, captures its Immuni app signal and relays it to Adv1. Adv1 comes close to A, the victim, and broadcasts the signal originated from B. If B is found positive to SARS-CoV-2 and uploads its identifiers to Immuni server, A will receive an incorrect exposure notification warning, since A never met B.
We evaluated our solution (i.e., ImmuniGuard) in the same relay attack scenario involving two honest users (A and B), both equipped with Immuni and ImmuniGuard apps.
For each contact, ImmuniGuard calculates the hash of the contact data (i.e., the identifiers of the two individuals, the GPS location, and the timestamp). Then, ImmuniGuard stores the hash in a local database. When B is found positive to SARS-CoV-2, he shares his stored hashes with the ImmuniGuard server. Since A and B never meet each other, the ImmuniGuard of A will find no match with the hashes uploaded by B. On the contrary, Immuni will still issue an exposure notification warning. This misalignment between Immuni and ImmuniGuard reflects the undertaken relay attack.
The demo video shows the relay attack we simulated against two users, both equipped with Immuni and ImmuniGuard apps. Our malicious app sniffs an Immuni Bluetooth identifier to retrasmit it in a different location, thus completing a relay attack. We, then, show how Immuni does not distinguish between a legitimate Bluetooth identifier and a relayed one, and could trigger an incorrect exposure notification alert. On the contrary, we show how ImmuniGuard achieves this aim and detects the relay attack, while being user privacy-preserving.
People
News and Media
