Trace-Σ: a privacy-preserving contact tracing app Jean-François Biasse ∗ , Sriram Chellappan † , Sherzod Kariev, Noyem Khan Lynette Menezes § , Efe Seyitoglu, Charurut Somboonwit § , Attila Yavuz ‡ University of South Florida § USF Health 4202 E Fowler Ave, 1 Tampa General Cir Tampa, FL 33620 Tampa, FL 33606 Corresponding authors: ∗ biasse@usf.edu, † sriramc@usf.edu, ‡ attilaayavuz@usf.edu Abstract—We present a privacy-preserving protocol to anony- mously collect information about a social graph. The typical application of our protocol is Bluetooth-enabled “contact-tracing apps” which record information about proximity between users to infer the risk of propagation of COVID-19 among them. The main contribution of this work is to enable a central server to construct an anonymous graph of interactions between users. This graph gives the central authority insight on the propagation of the virus, and allows it to run predictive models on it while protecting the privacy of users. The main technical tool we use is an accumulator scheme due to Camenisch and Lysyanskaya [1] to keep track of the credentials of users, and prove accumulated credentials in Zero-Knowledge. Index Terms—Exposure notification, contact tracing, Zero- Knowledge proofs, Σ-protocols, Accumulators, Signatures of Knowledge, COVID-19. I. I NTRODUCTION Since the beginning of the SARS-Cov-2 epidemic, contact tracing has been a major stake to protect populations. Early on, the idea of leveraging mobile devices to automate certain tasks (quarantine, monitoring, contact tracing ...) became popular. In most of the proposed system, authorities had to strike a bal- ance between users’ privacy and efficacy. So-called “contact- tracing apps” emerged after Singapore piloted the system TraceTogether [2] to leverage Bluetooth signals. The model of TraceTogether was adopted by Alberta’s ABTraceTogether [3] and Australia’s COVIDSafe [4]. The basic idea consists in having the phone of each user constantly broadcast identifiers provided by a central server. These identifiers are collected by the phones of other users who are within reach of the Bluetooth signal. When a user tests positive for COVID-19, they are invited by the central server to upload the identifiers they recently received. The corresponding users may have been infected. Once the server receives their identifiers, it contacts them to inform them they should get tested. Many systems relying on phone apps were subsequently described. The two major drives for technical improvements were privacy and reliability of the signal. Note that the efficacy of contact tracing apps is also ruled by a major non-technical aspect: the adoption rate. As of now, no contact tracing app has been adopted by the majority of a given population. The highest rate was in Iceland with around 40% of the population, followed by early This work was supported by a USF COVID-19 Rapid Response Grant. adopters such as Singapore and Australia where the adoption rate is around 25%. These rates are too low to guarantee that a significant proportion of interactions get recorded (a 25% adoption rate means that no more than 6.25% of interactions will be recorded on average). This paper does not deal with the issues of adoption and reliability of the signal. We consider the case of the exchange of Bluetooth signal, but our system might be compatible with WiFi and ultrasonic signals. GPS information has also been considered in the context of contact- tracing apps. Privacy has been a major drive in the development of new protocols for contact tracing apps. Indeed, the collection of information on proximity, localization, and health have a lot of legal ramifications. Additionally, it is possible (but conjectural) that a higher privacy protection results in a higher adoption rate. TraceTogether (and its successors) use a server that needs to be trusted with information on contacts and positive tests. This highly centralized design has lead to criticisms that this information could be misused (through mass surveillance), or hacked. To counter that risk, decentralized approaches were proposed. A consortium of European researchers lead by the EPFL described a decentralized approach called DP-3T [5] which inspired Apple and Google in the design of an API [6] available to health authorities to facilitate the development of Bluetooth-based contact tracing apps. In a decentralized approach, phones broadcast random tokens that are collected by other phones in close proximity. Unlike in the centralized TraceTogether system, these tokens do not tie to the identity of the users. Once a user tests positive for COVID-19, they upload the tokens they have been recently broadcasting. Then the server makes these tokens available to the other users who can learn whether they have been in contact with a positive user by comparing the tokens sent by the server with the tokens they have recently received. It is clear that a the privacy of a user that does not notify the server of a positive test cannot be compromised in this setting. However, it has been pointed out by several authors, including Vaudenay [7] that the action of uploading the tokens recently used (and their subsequent broadcast by the central server) can lead to de-anonymisations of positive users. The typical scenario in which this could happen is when an entity records Bluetooth tokens together with information on individuals around (pictures, name, etc