PaperlayerView exact revision on arXiv

Source-linked AI summary

A Survey of COVID-19 Contact Tracing Apps

Nadeem Ahmed, Regio A. Michelin, Wanli Xue, Sushmita Ruj, Robert Malaney, Salil S. Kanhere, Aruna Seneviratne, Wen Hu, Helge Janicke, Sanjay Jha

arXiv:2006.10306v3cs.CR

TL;DR

Contact tracing apps raise unresolved questions about architecture, privacy, security, efficacy, and user adoption. This survey reviews three architectures, proposed applications, reported user concerns, and attack vulnerabilities, concluding that no architecture is universally preferable and that privacy and security concerns remain central to adoption.

  • Problem

    Contact tracing apps lack a comprehensive assessment of their architectures, data management, efficacy, privacy, security, and attack vulnerabilities, despite these issues influencing adoption.

  • Method

    The paper surveys three tracing-app architectures, proposed applications, reported user concerns, proximity-estimation methods, and attacks against app security and privacy.

  • Results

    The review finds that architectures differ in privacy protection, attack models, implementation complexity, and operating costs, while apps face data-management, accuracy, security, and privacy concerns.

  • Takeaways & Limitations

    Architecture selection depends on governmental technology familiarity, existing-process integration, and deployment ease, while user adoption depends on trust, transparency, and safeguards against data misuse.

  • Takeaways & Limitations

    Proximity estimation based solely on RSSI is limited because environmental interference and differences among phones affect distance estimates.

Abstract

from arXiv · show

The recent outbreak of COVID-19 has taken the world by surprise, forcing lockdowns and straining public health care systems. COVID-19 is known to be a highly infectious virus, and infected individuals do not initially exhibit symptoms, while some remain asymptomatic. Thus, a non-negligible fraction of the population can, at any given time, be a hidden source of transmissions. In response, many governments have shown great interest in smartphone contact tracing apps that help automate the difficult task of tracing all recent contacts of newly identified infected individuals. However, tracing apps have generated much discussion around their key attributes, including system architecture, data management, privacy, security, proximity estimation, and attack vulnerability. In this article, we provide the first comprehensive review of these much-discussed tracing app attributes. We also present an overview of many proposed tracing app examples, some of which have been deployed countrywide, and discuss the concerns users have reported regarding their usage. We close by outlining potential research directions for next-generation app design, which would facilitate improved tracing and security performance, as well as wide adoption by the population at large.

1 Introduction

COVID-19’s asymptomatic transmission and the limits of manual tracing motivate smartphone-based contact-tracing apps, whose architecture, efficacy, privacy, and security have become central concerns. This article surveys these attributes and the implications of current and emerging tracing-app designs.

  • Motivation: Asymptomatic contagiousness means infected individuals may transmit COVID-19 before testing positive, making timely contact tracing necessary.Manual tracing relies on interviews covering contacts from the prior 14–21 days, but infected people may not identify unknown contacts and repeated interviews require substantial trained staff.
  • Motivation: Smartphones are suited to automate contact tracing because they support location tracking through GPS or WiFi and proximity detection through Bluetooth.Researchers pursue these technologies to identify contacts at significant infection risk quickly and reliably.
  • Challenges: Tracing apps have prompted debate over architecture, data management, efficacy, privacy, and security, with privacy concerns influencing adoption.Most apps claim not to disclose contacts’ personally identifiable, identity, or location information without explicit user permission.
  • Organization: The article organizes subsequent analysis around centralized, decentralized, and hybrid architectures, followed by security, privacy, data management, BLE proximity estimation, and attacks or vulnerabilities.These topics structure Sections 2–5 of the survey.

2 System Architecture · 2.1 Centralised

The paper distinguishes centralised, decentralised, and hybrid tracing architectures according to server use, emphasizing that centralised designs assign core functions to a trusted server. In the centralised Bluetrace-based protocol, devices exchange encrypted temporary identifiers while encounter analysis and notifications remain server-side.

  • 2 System Architecture: The survey classifies COVID-19 tracing systems into centralised, decentralised, and hybrid architectures according to how the server is used.
  • 2.1 Centralised: In the centralised Bluetrace protocol, users pre-register, and the server generates encrypted, privacy-preserving Temporary IDs for their devices.
  • 2.1.1 Registration Phase: Registration requires personal details and mobile-number verification by SMS; the server then computes a short-lived TempID, recommended by Bluetrace to expire after 15 minutes.
  • 2.1.2 Registering encounters/contacts information: During encounters, devices exchange TempID, phone model, and TxPower, while recording RSSI and timestamps; phone numbers are excluded from encounter messages.
  • 2.1.3 Uploading encounters data: Encounter records remain local until a COVID-19-positive user voluntarily uploads them after health-official confirmation and OTP verification.
  • 2.1.4 Server-side processing of the uploaded data: After upload, the server decrypts TempIDs, maps them to mobile numbers, and uses TxPower and RSSI to estimate encounter proximity.
  • 2.1.4 Server-side processing of the uploaded data: Combining proximity with timestamps, the server determines encounter risk and prepares information for health officials; its centralized responsibilities raise privacy concerns despite assumed trust and regulation.

2.2 Decentralised

The decentralised architecture shifts identifier generation and exposure-notification processing from the server to user devices, reducing the server’s role and limiting access to personal information. Devices generate short-lived pseudonyms from local seeds, while users locally reconstruct exposures after downloading infected users’ seeds.

  • Architecture: Decentralised tracing generates anonymous identifiers and performs exposure notification on user devices, leaving the server minimally involved.This design aims to keep real identities secret from both the server and other users.
  • Identifier generation: Using PACT, devices generate random seeds and approximately one-minute pseudonyms, or “chirps,” without pre-registering users or storing PII on the server.The seeds serve as inputs to a pseudorandom function combined with the current time.
  • Server and privacy: The server acts as an honest-but-curious rendezvous point that advertises infected users’ seeds, which other devices download to reconstruct corresponding chirps without directly deriving identities.Only other app users perform the exposure-risk analysis on their devices.
  • Encounter exchange: Devices broadcast new chirps via Bluetooth every few seconds, storing received chirps with timestamps and maximum RSSI while ignoring duplicates received within one minute.Unlike the centralised architecture, both seeds and chirps are generated on the device rather than by the server.
  • Tracing process: After an authorised positive diagnosis, the user uploads locally stored seeds and their creation and expiry times, and downloaded seeds enable local reconstruction of past chirps for exposure tracing.Users typically contact the server once per day to download seeds uploaded by infected users.

2.3 Hybrid · 2.4 Architecture summary

The hybrid architecture splits contact-tracing functions between servers and devices, while the architecture summary contrasts centralised, decentralised, and hybrid designs by server functionality and privacy preservation. Its protocol uses privacy-preserving registration, ephemeral identifiers, encounter tokens, and server-assisted risk matching.

  • 2.4 Architecture summary: Hybrid architecture divides complex tracing functions between the server and devices, unlike centralised designs that centralise them or decentralised designs that delegate them entirely to devices.In the hybrid model, the server retains limited coordination and lookup responsibilities rather than performing every tracing operation.
  • 2.3 Hybrid: The Desire protocol assigns each app a unique device ID without recording PII, exchanges cryptographic Ephemeral IDs over BLE, and stores two unlinkable Private Encounter Tokens per encounter.The protocol’s interaction sequence is illustrated in Figure 9.
  • 2.3.1 Installation and registration: Hybrid registration uses phone-number OTP and server-issued authorization-token authentication, then deletes the phone number and encryption key after assigning an app ID.Figure 10 depicts this registration process.
  • 2.3.2 Generating and exchanging Ephemeral IDs: Devices generate EphIDs through Diffie–Hellman key exchange, rotate them typically every 15 minutes, and derive two PETs from each received identifier.Figure 11 shows the encounter process, while the app maintains upload and query tables for encounter data.
  • 2.3.3 Uploading Encounter data: After a positive diagnosis, explicit consent is required before uploading the user ID, encryption key, PETs, timestamps, and durations to the server.The server records the PETs and associated data and updates the infected user’s status using the encryption key.
  • 2.3.4 Contact tracing process: Users query exposure through a proxy or anonymisation network, while the server matches PETs, evaluates risk from time and duration, and notifies at-risk users to contact health authorities.Figure 12 presents the notification process.
  • 2.4 Architecture summary: The three architectures are categorised by the functionality and privacy preservation assigned to the central server, with centralised systems retaining security, identifier, risk-analysis, and notification roles.The architecture summary contrasts these server responsibilities with their transfer to devices in decentralised systems and their division in hybrid systems.

3 Data Management, Privacy and Security

This section compares data management across centralised, decentralised, and hybrid contact-tracing architectures, then examines privacy and security risks involving governments, servers, devices, and malicious users. It shows that architecture determines where data resides, who can access it, and how attacks may compromise privacy, integrity, or availability.

  • Data Management, Privacy and Security: The review evaluates each architecture by asking what data is produced, exchanged, stored, and accessible to each stakeholder.The analysis considers governments, central servers, malicious users, and health authorities that know the identities of positive cases.
  • Centralised Architecture: Centralised systems place personally identifiable information, temporary identifiers, and positive-case contact lists on the server, while devices retain encounter data and may upload it with user consent.The server periodically generates and transfers TempIDs, whereas devices generate, exchange, and store contacts for a specified period, usually 21 days.
  • Decentralised Architecture: Decentralised systems keep hourly seeds, chirps, RSSI, timestamps, and potentially location metadata on devices, with the server playing a more limited role.Users can download seeds and calculate chirps associated with infected users, creating risks of identification through side-channel information.
  • Hybrid Architecture: Hybrid systems store encounters as PET entries on devices, record limited device information on the server, and receive PETs only from positive users who volunteer to upload them.Hybrid privacy protections include secret sharing, decisional Diffie-Hellman, and private set intersection, so compromising one party does not reveal the entire secret or risk-analysis result.
  • Privacy: Centralised architectures expose all three data categories to compromised servers, whereas decentralised systems risk re-identification and hybrid systems reduce disclosure through privacy-preserving computation.The three categories are participant PII, pseudonymous contact advertisements, and social/proximity graphs; smartphone theft or coercion can expose device-stored data in every architecture.
  • Security: Security threats include data theft, false exposure notifications, de-anonymisation, erroneous entries, and denial of service when servers are compromised or collude with malicious entities.Centralised servers therefore require trusted execution environments, authentication, and access controls, while all architectures must address integrity and availability threats.

4 Proximity Estimation

Proximity estimation is central to assessing infection risk because transmission likelihood depends on contact distance and duration. Current smartphone approaches, primarily GPS and Bluetooth RSSI, remain unreliable in real-world environments, producing substantial proximity errors and false classifications.

  • Proximity Estimation: Current apps primarily use GPS and Bluetooth to estimate proximity, which helps assess infection risk from contact distance and duration.WiFi can provide limited proximity estimation but requires supporting infrastructure and setup.
  • Proximity Estimation: Bluetooth estimates distance from RSSI because wireless signals attenuate with travel distance, using a path-loss model to relate signal strength to separation.The model includes the reference-distance RSSI and path-loss exponent, while the receiver infers approximate distance from recorded RSSI values.
  • Proximity Estimation: Environmental obstructions and channel effects, including walls, furniture, and people, distort RSSI beyond the effect of distance and limit mitigation strategies in real-world conditions.Variation in the path-loss exponent captures some environmental factors, but unknown model parameters and noise variance create additional uncertainty.
  • Proximity Estimation: Current proximity techniques produce false positives and false negatives, sometimes indicating close contact when people are far apart or missing nearby contact.A wall or other obstruction can make an apparently close distance estimate fail to represent actual exposure, such as between adjacent apartments.

5 Attacks

The section examines attacks against centralized, decentralized, and hybrid contact-tracing architectures, including replay, tracking, location inference, enumeration, linkage, and identifier-carryover attacks. It shows that architecture-specific design choices affect attack scope, identifiability, and resistance, while additional sensing can reduce privacy guarantees.

  • Replay and relay attacks: Replay attacks can induce false positives with minimal resources by forwarding messages, while centralized, decentralized, and hybrid architectures differ in vulnerability and victim scope.Centralized replay can identify the originator as a close contact; decentralized replay can affect multiple recipients, whereas hybrid protocols prevent replay but remain susceptible to relay attacks.
  • Device tracking: BLE advertisements, temporary identifiers, and phone-model information can enable device tracking, although short identifier lifetimes limit tracking unless attackers link successive identifiers.Address carryover and analysis of an identifier’s disappearance and immediate replacement can extend tracking beyond anonymous-ID expiration, even when identifier changes are synchronized.
  • Location and enumeration attacks: Centralized encounter data can reveal whether a known user is present at a location, while decentralized uploads allow users to estimate positive-case counts from shared seeds.A Bloom filter is proposed to conceal the number of positive cases by storing server-generated chirps.
  • Linkage attacks: Linkage attacks can de-anonymize users through side-channel correlations: decentralized systems can expose positive users, centralized systems can expose close contacts, and hybrid protocols are generally unlinkable.Mobile-model information, isolation, contact duration, and isolated encounters can support identification in centralized systems.
  • Server and privacy threats: Attackers may correlate wireless encounters or steal phones to mine interaction data, but malicious servers cannot disclose interactions involving users with neither positive tests nor contact with positive patients.Additional sensors or gait recognition could counter some tracking attacks, but collecting more contextual or personal data may weaken privacy guarantees.

6 Analysis of Specific Apps and Protocols

This section examines concrete contact-tracing apps and protocols that instantiate the three broad system architectures, covering proposals, developments, and deployments across countries.

  • 6 Analysis of Specific Apps and Protocols: The section introduces tracing apps and protocols that instantiate the three broad architectures discussed earlier.It shifts from architecture-level features, capabilities, and attack exposure to specific systems.
  • 6 Analysis of Specific Apps and Protocols: It covers systems that are being proposed, developed, and deployed in many countries.Figure 15 summarizes the apps and protocols included in this analysis.
  • 6 Analysis of Specific Apps and Protocols: The discussion is divided into three sections, each focusing on a different system architecture.

6.1 Apps/Protocols based on centralised architecture

Centralised contact-tracing implementations include BlueTrace-based TraceTogether and CovidSafe, ROBERT-based StopCovid, and Aarogya Setu, which combines Bluetooth and GPS. They differ in stored data, notification processes, identifier lifetimes, and privacy or attack exposure.

  • Implementations: BlueTrace-based TraceTogether and CovidSafe use centralised architectures, while ROBERT-based StopCovid and Aarogya Setu represent other deployments.Aarogya Setu uses both Bluetooth and GPS; OpenTrace and StopCovid source code were publicly released.
  • TraceTogether and CovidSafe: CovidSafe uses two-hour TempIDs versus TraceTogether’s 15-minute lifetime, reducing downloads but increasing vulnerability to replay attacks.Both apps otherwise follow Bluetrace and share vulnerability to the attacks listed in Table 4.
  • BlueTrace and ROBERT: ROBERT stores anonymous EphIDs rather than BlueTrace’s personally identifiable information, providing greater privacy, but requires users to check the server frequently for risk notifications.The protocols also differ in notification processes, with BlueTrace using a contrasting notification mechanism.
  • BlueTrace and ROBERT: ROBERT uploads positive users’ EphIDs in staggered, random order to hinder contact linking and social-graph analysis, although traffic analysis may reconnect reports.BlueTrace instead uploads all contacts in one go.
  • Aarogya Setu: Aarogya Setu collects personally identifiable, contact, GPS-location, and self-assessment data for analytics indicating positive cases within 500 m to 10 km.The app’s Android code was released, while its iOS and server code were not yet available.

6.2 Apps/Protocols based on decentralised architecture

This section surveys decentralised contact-tracing protocols and implementations, including Apple/Google’s exposure-notification system, two PACT protocols, DP-3T, TCN, Pronto-C2, and Hamagen. These designs generally keep tracing data locally and use privacy-preserving identifiers, while addressing linkage, enumeration, accuracy, and adoption concerns through alternative mechanisms.

  • Apple/Google exposure notification: Apple and Google proposed a decentralised exposure-notification system with APIs for health-authority apps and planned OS-level support, enabling deployments such as SwissCoviD and Corona-Warn-App.APIs were released on 20 May 2020, followed by planned operating-system integration to reduce reliance on standalone apps.
  • PACT protocols: PACT East-coast and PACT West-coast [47] use local encrypted storage, pseudorandom identifiers, and voluntary data uploads, but remain susceptible to linkage and enumeration attacks.PACT East-coast optionally stores location metadata to identify contact contexts and potentially reduce false positives, while PACT West-coast underlies CovidSafe (UoW).
  • DP-3T: DP-3T uses daily keys and expiring Bluetooth EphIDs stored locally, while its ‘Un-linkable’ design converts uploaded keys into server-filtered EphIDs to reduce linkage and enumeration risks.The Un-linkable design increases server processing time, requires Cuckoo-filter tuning to limit false positives, prevents false negatives, and supports selective encounter uploads.
  • Other protocols and applications: Other decentralised approaches include TCN [49], which uploads compact keychain seeds; Pronto-C2, which hides anonymous device communications from the central server; and Hamagen, which locally cross-checks GPS histories instead of recording Bluetooth encounters.Hamagen’s location data does not leave the individual’s phone, whereas Pronto-C2 specifically targets protection against mass surveillance.

6.3 Apps/Protocols based on hybrid architecture

Hybrid protocols combine centralized and decentralized features, using server-mediated risk analysis and notification alongside device-generated identifiers. DESIRE, ConTra Corona [64], and EpiOne [65] aim to improve privacy by limiting linkage, enumeration, and social-graph attacks through cryptographic mechanisms and server separation.

  • DESIRE: DESIRE uses cryptographically generated PETs distinct from EphIDs and client-held encryption keys to prevent contact-data harvesting and protect server-stored data after a breach.Risk analysis and notification remain server-side, reducing the likelihood of user-launched Enumeration and Linkage attacks.
  • ConTra Corona: ConTra Corona [64] uses DDH key exchange and separated servers to verify diagnosed users’ uploads and mitigate linkage attacks against decentralized apps.Its privacy protections assume non-colluding servers and anonymized or authenticated communication channels.
  • ConTra Corona: ConTra Corona [64] generates daily warning identifiers, encrypted seed identifiers, and pseudorandom identifiers, then uses 15-of-45 secret sharing to reconstruct contact events from broadcasts.A device reconstructs an event after accumulating 15 broadcasts containing shares associated with the same random identifier.
  • EpiOne: EpiOne [65] uses Private Set Intersection to compare users’ received tokens with tokens reconstructed from encrypted positive-case seeds without revealing either set, preventing enumeration and social-graph construction.Positive users upload encrypted seeds through health officials, while users learn only the cardinality of the token intersection.

7 Common user concerns

User acceptability cannot be inferred from downloads alone, while practical concerns include battery use, device and app compatibility, consent withdrawal, and transparency. These concerns can limit trust and wider adoption of tracing applications.

  • Battery consumption: Battery consumption depends on processing, data management, message exchange, communication protocol, and whether the app runs in the foreground or background.CovidSafe and TraceTogether iOS reportedly face background-execution issues, while Google–Apple operating-system support addresses some constraints.
  • Compatibility: Compatibility remains difficult because tracing apps support different operating-system versions, and cross-app behaviour is unclear when users travel or install multiple apps.TraceTogether and CovidSafe require different minimum Android and iOS versions, while architectural differences complicate interoperability.
  • Consent withdrawal: Consent withdrawal is straightforward for locally stored encounter data but becomes difficult after infected users upload data or seeds that reach other devices.In decentralised systems, transferred seeds and reconstructed chirps may remain until their 21-day removal period.
  • Transparency and trust: Transparency can strengthen trust through open-source code and Privacy Impact Assessments, but users must still trust developers, operators, reviewers, and platform providers.Only CovidSafe (AU) and DP-3T were reported as accompanied by PIAs.

8 Future Directions

The paper prioritizes near-term research in proximity accuracy, fully decentralized architectures, and adaptive AI, while identifying quantum computing, sensing, and communications as longer-term opportunities for more capable and secure tracing applications.

  • 8 Future Directions: Near-term research should target proximity accuracy, decentralized architectures, and AI-based infection-likelihood algorithms over the next five years.Longer-term, more speculative research is deferred beyond five years.
  • 8 Future Directions: Next-generation apps could improve proximity estimation through BLE advances, Bluetooth-like protocols, UWB, and sensor fusion; UWB may provide cm-type precision using 500MHz bandwidth.Proposed fused inputs include WiFi, Enhanced-GPS, gyroscopes, and accelerometers.
  • 8 Future Directions: Fully decentralized, peer-to-peer infection tracing is needed to address privacy concerns and support wider public adoption beyond architectures relying on governing authorities.The surveyed applications all use central servers to differing degrees.
  • 8 Future Directions: AI-based algorithms could dynamically improve infection-likelihood decisions by adapting to true identifications, missed detections, and false-positive outcomes.Improved phone processing power enables increasingly sophisticated on-device algorithms.
  • 8 Future Directions: Quantum computing could support future tracing through quantum machine learning and advanced Monte-Carlo or particle-filter tracking using greater computational power.The paper recommends beginning research now because quantum computing may soon reach major development and commercialization breakthroughs.
  • 8 Future Directions: Quantum sensing could improve timing, synchronization, acceleration, and location accuracy, while quantum communications could strengthen tracing security and privacy.Quantum communications already has commercial offerings and proof-of-principle space deployment.

9 Conclusions

Contact tracing apps can strengthen health authorities’ ability to identify potential exposures, but they are not a silver bullet and remain constrained by architectural tradeoffs, privacy concerns, and voluntary adoption. The article aims to inform researchers, users, and agencies about these technological and cybersecurity considerations.

  • 9 Conclusions: Contact tracing apps may help health authorities quickly identify people who may have been exposed, but they cannot by themselves solve pandemic tracing challenges.The article emphasizes that these apps can improve tracing capability while still facing concerns from users, data protection agencies, and researchers.
  • 9 Conclusions: Architectural choices involve differing benefits, drawbacks, attack models, protections, implementation complexity, and operating costs.Governments’ choices depend on technological familiarity, integration with existing tracing processes, and ease of deployment.
  • 9 Conclusions: User adoption is voluntary, and concerns about privacy and security of personally identifiable information remain central barriers to app uptake.These concerns are raised by users in relation to PII collected through tracing apps.
  • 9 Conclusions: Users already face extensive tracking through WiFi, cellular towers, GPS apps, cameras, and other applications whose security and privacy implications may be unclear.The article places tracing apps within a broader ecosystem of existing tracking technologies and routinely installed applications.
  • 9 Conclusions: The article seeks to help researchers understand tracing-app technology and cybersecurity while supporting more informed voluntary adoption decisions by users and agencies.Its intended audience includes the research community, users, and agencies evaluating apps offered in their geographical areas.
Loading 2006.10306v3…