Secure contact tracing platform from simplest private set intersection cardinality

IET Information SecurityVolume 16, Issue 5 p. 346-361 ORIGINAL RESEARCHOpen Access Secure contact tracing platform from simplest private set intersection cardinality Jiahui Gao, Corresponding Author Jiahui Gao [email protected] orcid.org/0000-0003-3821-2263 Biodesign Institution, Arizona State University, Tempe, Arizona, USA Correspondence Jiahui Gao, Biodesign Institution, Arizona State University, 727 E TYLER St, Tempe, AZ 85287, USA. Email: [email protected]Search for more papers by this authorChetan Surana, Chetan Surana Computer Science, Amazon.com Inc, Seattle, Washington, USASearch for more papers by this authorNi Trieu, Ni Trieu Biodesign Institution, Arizona State University, Tempe, Arizona, USASearch for more papers by this author Jiahui Gao, Corresponding Author Jiahui Gao [email protected] orcid.org/0000-0003-3821-2263 Biodesign Institution, Arizona State University, Tempe, Arizona, USA Correspondence Jiahui Gao, Biodesign Institution, Arizona State University, 727 E TYLER St, Tempe, AZ 85287, USA. Email: [email protected]Search for more papers by this authorChetan Surana, Chetan Surana Computer Science, Amazon.com Inc, Seattle, Washington, USASearch for more papers by this authorNi Trieu, Ni Trieu Biodesign Institution, Arizona State University, Tempe, Arizona, USASearch for more papers by this author First published: 09 June 2022 https://doi.org/10.1049/ise2.12070AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract Contact tracing is an essential tool for controlling the spread of disease through human populations. However, existing contact tracing applications are either vulnerable to privacy and security attacks or heavy bandwidth/computational requirements on the client's devices. In this work, we introduce SecureCT, a Secure Contact Tracing platform with strong privacy protection and lightweight cost. SecureCT prevents linkage attacks, eliminates replay and relay attacks, and allows the phone's holder to delegate their contact tracing computation to untrusted servers while maintaining the user's privacy. The technical core of our scheme is an efficient Private Set Intersection Cardinality protocol which only relies on symmetric-key primitives. We evaluate its performance to show the feasibility of our proposed system in practice. 1 INTRODUCTION In the past 2 years, our life has been dramatically changed by the pandemic of coronavirus SARS-CoV-2 which is also known as COVID-19. This virus can be spread via air and droplets. When an infected person has contact with others physically, it is likely that the virus is spread to them. By tracking down the spread route of the virus, medical workers can make the right plan to contain the spread and inform the potential infection to the related people timely. This process is called contact tracing (CT). At the beginning of the pandemic, CT was done in the form of interviewing, to ask the patient to recall the place they have been and the people they have met, which has low efficiency and a high error rate. A more powerful technique is required to implement contact tracing digitally and efficiently. A large number of CT mobile applications (apps) have been developed and deployed, with most of them based on the exchange of random and anonymous tokens using Bluetooth (BT) [1, 2]. These are generally decentralised systems that alert users if they may have come in close proximity with other positively diagnosed users (infected users). A high adoption rate is critical for the success of CT apps in helping curb the spread of severe diseases. However, adoption is low as these systems are prone to a host of attacks, like linkage attack, relay attack, and replay attack [3-5]. Most CT apps have a service provider (server) in the loop which stores tokens of infected users. User devices periodically query the server and download the tokens of infected users. They check whether there is a match between the set of downloaded tokens and the set of tokens received from other users they were in close contact with. This involves a download of a huge set of data from the server, periodically, hence making it computationally inefficient for client mobile devices. Moreover, the coronavirus spread through common surfaces that have been touched by infected users. Informing users to avoid geographical areas where many positively diagnosed users have visited can help lessen the spread of the disease through surface transmission. Decentralised, BT-based systems based on proximity of devices cannot handle this case. GPS-based methods that match location traces of users may not be as accurate as BT-based systems and are vulnerable to dictionary attacks [6]. Hence a secure, efficient, and scalable protocol for CT that considers both contact transmission and surface transmission is needed. No matter using the BT-based method or the GPS-based method, the privacy of the user is another concern. There is a need for a framework that is robust against attacks and information leakage, and is computationally light and efficient. In this work, we aim to prevent two important attacks: linkage attack and replay/relay attack. In the linkage attack, we consider valid tokens which are generated from the same device and may be broadcast at several places. The tokens of the same client cannot be linked together by any participant. Most BT-based contact tracing systems are vulnerable to this attack. For example, Seiskari [7] installed BLE-sniffing devices to different known physical locations and collected contact tracing tokens. By keeping track of when and where they received which tokens, authors in [7] can identify the travel route of the individuals. To prevent the linkage attack, prior work [8, 9] relies on private set intersection cardinality (PSI-CA), which is used to check how many tokens held by a user match the tokens in a set stored on a server without the users revealing their tokens. In this work, we propose a more efficient PSI-CA protocol, which can be integrated into a contact tracing system to improve the system's performance. To prevent the replay and relay attacks, prior work [5, 10] propose delayed authentication so that the CT server uses public verification to authenticate user tokens. However, their authenticated system is not efficient, especially on the user's device. In addition, the identity of COVID-19 positive users might be revealed during the authenticated process. To eliminate the replay and relay attacks, we integrate the random tokens generation of the BT approach with GPS and time-stamps [11] such that the transformed token contains the user's secret BT token and location only in an encrypted form. Our contribution In this work, we make the following contributions: We propose a novel and deployment-friendly PSI-CA protocol which relies only on symmetric-key primitives (e.g. AES). We design and implement a contact tracing system, SecureCT, that can provide strong privacy guarantees. It is able to eliminate replay and relay attack using GPS. We implement SecureCT and evaluate it on the client's phone using Google Pixel 3. For the client set size n = 211, without including the time spent waiting on the server's response, the client requires a running time of 208 milliseconds and only 32 KBs of communication. The server requires 35 s to perform CT for the server set size N = 109. Organisation In Section 2, we begin with the related work of Contact Tracing systems as well as the protocols of PSI-CA. Then we give the details of primitives for our design, security model, and potential attacks in Section 3. The PSI-CA is presented in Section 4. The SecureCT contact tracing system is demonstrated in Section 5. Finally, we present the details and the result of our implementation in Section 6. 2 RELATED WORK In this section, we overview the state of the art in contact tracing and PSI-CA. Decentralised contact tracing There are two main categories of CT approach: centralised and decentralised. In a centralised approach, a trusted third party is required. The TraceTogether app is a typical example that is launched by the Singapore government. In TraceTogether, the central authority (the government server) registers and stores user details and unique identifiers, and assigns a set of contact tokens to be broadcast at specific times. An infected user shares all the received broadcast tokens with the central authority, who then uses the tokens to identify and follow-up with users who have come in contact with him. This system could be misused as a surveillance system, where the central authority can learn graphs of user interaction. In this work, we focus on decentralised contact tracing and review two popular types of contact tracing systems. 2.1.1 GPS-based construction It is very important for the patient to recall the place they visited and the people they met before they tested positive. Based on this information, the analyst can rebuild the trajectory of the patient and make the corresponding plan to track and contain the spread of the virus. A natural way to implement contact tracing digitally is to record the physical location of the people and find the potential contact upon that. In the GPS-based construction, the location information of the user is collected for contact tracing analysis. In reference [12], the authors proposed a network-centric WiFi sensing approach for digital contact tracing. By collecting the Wifi logs of device associations to access points within the network, a graph structure capturing the user device trajectory can be generated. The intersection of the trajectories can be gained by using efficient time-evolving graphs and algorithms. Safe Paths [13], extended to Path Check, is one contact tracing approach that is based on GPS location traces of users. The app logs the user's GPS location periodically. The location is quantised to a geographical area using Geohash [11]. The app then uses a one-way hash function to mask the Geohash and timestamp. An infected user's hashes are shared to a central server maintaining a public list. Other devices can download this list and detect an exposure using set intersection. This approach may not be as effective as BT-based techniques and involves a large number of hashes to be stored locally and downloaded from a server. It is susceptible to dictionary attacks [6], where a one-way deterministic hash used to mask private information can be potentially reversed. 2.1.2 BLE-based construction Most of the current decentralised CT systems are based on Bluetooth Low Energy (BLE). BLE is a radio specification for short-range communication and is well suited for proximity detection due to its accuracy and feasibility. The BLE-based CT protocols are designed in a very similar way as follows: Alice and Bob are two users of the contact tracing protocol. They download and install the app on their smartphone. When Alice and Bob meet each other, their phone will generate and exchange the token. Suppose Alice is tested positive for the disease. She will upload all the tokens she generates to a third-party server. At the server, a list of tokens from the user who is tested positive can be maintained and published or a query mechanism can be provided to the user for checking their contacts. Google/Apple Exposure Notification (GAEN) solution and Decentralised Privacy-Preserving Proximity Tracing (DP3T) [1] are built based on this idea of sharing tokens via Bluetooth devices. As discussed in Section 1, the typical BLE-based CT approach remains susceptible to various attacks. For example, in GAEN, when Alice is diagnosed with the disease, her daily diagnosis keys (used to generate the tokens) are uploaded to the server. Thus, Alice's anonymous identifier tokens, as they are broadcast each day, can be linked to each other. The tokens can also be linked across days if Alice frequently appears at the same place. According to the calculation in [9], DP3T with Cuckoo filters requires the users to download 110 MB each day for 40,000 new daily infections. It costs each user $1/day using Google Fi network $10/GB. The GAEN solution would cost $0.10/day although their design is more vulnerable to linkage attacks than the DP3T. PSI-CA was introduced to prevent the linkage attack in the CT [8, 9, 14]. We review their PSI-CA protocols in Section 2.2. Server-aided PSI-cardinality Private set intersection (PSI) allows two parties to compute the intersection of their datasets without revealing any additional information. The description of functionality is given in section 3.5 Over the last several years PSI has become truly practical with extremely fast cryptographically secure implementations [15, 16]. We refer the reader to [17] for additional discussion and motivation of PSI. Recently, private contact tracing applications related to COVID-19 [6, 8, 9, 14] found PSI-CA as the ultimate cryptographic tool, allowing multiple participants (users and healthcare providers) to privately match contact information and notify users who may have been infected. In this work, we mainly focus on a variant of PSI problems, PSI-CA. The functionality of PSI-CA is to allow parties to learn the size of the intersection and nothing else. Particularly, this functionality can be achieved in a "server-aided" way in which there is a helping cloud server to do some of the computation for the participants. Below we consider the works most relevant to ours. DH-based PSI-CA [14]: Epione [14] is one of the first works that applies PSI-CA into CT to prevent the linkage attack. Instead of using CT tokens (referring the token in some of the earlier contact tracing schemes that do not hide the identity of the corresponding user) for matching, their protocol uses PRF values of these tokens. The PRF computation is implemented via DH-based OPRF [18]. To make PSI-CA efficient for a large server-side database and a small client-side database, Epione relies on keyword-PIR [19, 20] which allows a client to check whether their PRF is in the server's data, without revealing the PRF itself to the server. As a result, their PSI-CA protocol has communication complexity O(n log N) which is linear in the size of the smaller set (n), and logarithmic in the larger set size N. However, it requires each user to perform O(n) exponentiations (public-key operations) for DH-based OPRF and O(N) symmetric-key operations for keyword PIR computation. Delegated PSI-CA [9]: Catalic, a delegated contact tracing system proposed in [9], allows multiple untrusted cloud servers to do the most of contact tracing computation so that the efficiency of the PSI-CA protocol on the client's device can be improved. A set of non-colluding cloud servers take the secret shares of the token from the client and jointly perform oblivious distributed key PRF (Odk-PRF) [9] with a backend server holding a set of tokens from infected patients. In the end, only one cloud server learns the PRF value of the client's token and nothing else. By having these values, the cloud server can compute PSI-CA with less computation for the client. The client's computation and communication complexity of the PSI-CA protocol in Catalic is linear in the size of the smaller set O(n), and is independent of the larger set's size N. However, Catalic system requires at least two non-colluding cloud servers with a heavy computation/communication cost of Odk-PRF. In addition, the underlying OPRF of Odk-PRF is based on Oblivious Transfer [21], which is not deployment-friendly. Function Secret Sharing (FSS) based PSI-CA [8]: Dittmer et al. [8] introduces a variant of PSI-CA (so-called weighted PSI-CA) in which each token of the client has an associated secret weight. The weight indicates a proximity estimate (e.g. "is there a wall between us?") that enables a more fine-grained tracing response. The weighted PSI-CA is based on cheap FFS constructions [22, 23], thus it is efficient on both the client's and server's sides. Concretely, in the FSS-based PSI-CA, the computation complexity of the client and server is O(n) and O(N), respectively. The communication complexity is O(n). However, their construction assumes that there exist two non-colluding servers, each holding an identical set of infected tokens. This assumption is not realistic in the context of contact tracing. 3 PRELIMINARIES In this section, we introduce the notation and the primitives for our contact tracing system and the PSI-CA protocol which will be discussed in the later sections. Notations In this work, the computational and statistical security parameters are denoted by κ, λ respectively. We use [.] notation to refer to a set. For example, [m] implies the set {1, 2, …, m}. Additionally, we use [i, j] to denote the set {i, i + 1, …, j}. Other special notations for the data structure will be introduced before the usage. Geohash Geohashing [11] is a convenient geocoding system that can encode a location latitude and longitude into a string of letters and digits, with the length of encoding defining the precision. It is a hierarchical spatial data structure that divides geographical areas into the grid like buckets. A useful property of a geohash is arbitrary precision, allowing one to gradually remove characters from the end, and reducing the length while losing precision. The longer the prefix of geohashes of the two locations, the closer they are spatially. A geohash from GPS coordinates is computed by interleaving two binary strings, one each for the latitude and longitude, with bits recursively splitting the grid into intervals. The calculation of a geohash can be elucidated with an example. The interval is between −90 and 90° for latitude and between −180 and 180° for longitude. For example, the first four bits of a GPS coordinate with latitude 19.5 is 1001. The first bit is 1 for it lies in the second half of the first interval. Then, 0 is noted for it lies in the first half of the interval 0–90, followed by 0 for the interval 0–45, 1 for interval 0–22.5, and so on recursively, until the desired accuracy is reached. The interleaved binary strings for longitude and latitude are represented as letters and digits using the base-32 encoding. In the implementation of the BT plus GPS protocol proposed in this work, geohash of length 8 is chosen, to accommodate for reasonable accuracy of proximity detection. Oblivious Key-Value Store (OKVS) An OKVS [24] is a data structure in which a sender, holding a set of key-value mapping P = {(xi, yi), i ∈ [n]} with pseudo-random values yi, wishes to hand that mapping over to a receiver who is able to evaluate the mapping on any input but without revealing the keys xi. Formally, an Oblivious Key-Value Store consists of two algorithms: Encode(P) → T: a randomised algorithm that takes as input a set of n key-value pairs P = k i , v i i ∈ [ n ] $P=\left\{{\left({k}_{i},{v}_{i}\right)}_{i\in [n]}\right\}$ from the key-value domain K × V $\mathcal{K}\times \mathcal{V}$ , and outputs an OKVS table T. Decode(x, T) → y: a deterministic algorithm that takes as input a table T, a key x and outputs a value y. The correctness of the OKVS is that if for all key-value pairs A ⊆ K × V $A\subseteq \mathcal{K}\times \mathcal{V}$ with distinct keys and pseudo-random values, Encode(A) = T and (k, v) ∈ A then Decode(T, k) = v. An OKVS is secure if the values vi are chosen uniformly then the output of Encode hides the choice of the keys ki. Hash table data structures 3.4.1 Cuckoo hashing In the scheme of Cuckoo hashing, there is a hash table of β bins denoted B[1…β]. k random hash functions h1, …, hk : {0,1}⋆ → [β] are chosen to generate the position index for the input element. There is an additional storage called stash in case some elements failed to find an empty bin. The client uses a variant of Cuckoo hashing such that each item x ∈ X is placed in exactly one of the β bins. Using the Cuckoo analysis [20] based on the set size |X|, the parameters β, k are chosen so that with high probability (1 − 2−λ) every bin contains at most one item, and no item has to be placed in the stash during the Cuckoo eviction (i.e. no stash is required) It is a scheme with worst case constant lookup and deletion time, and amortised constant insertion time. On inserting an item, it uses the first hash function. If an item already exists there, the current item replaces it, and the evicted item is re-inserted using the subsequent hash function. Repeat till the process settles. If there is a cycle, a rehash is performed by choosing new hash functions h1, …, hk : {0,1}⋆ → [β]. 3.4.2 Simple hashing With simple hashing, items in the input set Y are inserted into β bins using the same set of k Cuckoo hash functions (i.e. each item y ∈ Y appears k times in the hash table). Using a standard ball-and-bin analysis based on k, β, and the input size of the client |X|, one can deduce an upper bound η such that no bin contains more than η items with high probability. PSI-CA Private set intersection cardinality is a security protocol which allows parties to learn the size of the intersection of their input sets and nothing else. We consider two parties setting with a helping server. The description of its functionality is given by Figure 1. FIGURE 1Open in figure viewerPowerPoint Functionality of private set intersection cardinality Security models The protocols in this work are scrutinised under specific security and adversarial models. Consider that multiple parties agree to cooperatively compute a function f, and also agree to share the evaluation result to a particular party. Two classical security models are the colluding and non-colluding models [14]. In a colluding model, a subset of parties may be dishonest and collude during the execution of the protocol. In a non-colluding model, the parties are independent and do not collude. There are two adversarial model definitions. In the honest but curious model (semi-honest model), the parties strictly follow the protocol without deviation but may attempt to learn extra information from the execution script apart from that intended by the protocol. In the malicious model, the adversary or dishonest party may attempt any polynomial time strategy such as supplying invalid inputs, deviating and executing different computation, so as to disrupt the protocol to leak information. In this work, the non-colluding and semi-honest setting is considered, where the parties are assumed not to collude and follow the protocol's description. Attacks The aforementioned approaches introduced in Section 2 are all vulnerable to some of the attacks including relay attacks, linkage attacks by users or servers, and also false reporting by users. We list and illustrate these possible attacks below. Linkage Attack: Linkage attack allows attacker to refer the identity of anonymous data by linking it to some non-anonymous dataset. In the case of contact tracing, linkage attack can be applied by both the server and the client. The server can do it by observing the contact token it received. In our proposed SecureCT, this is prevented by having all the tokens randomly generated. For clients, all they will receive from the protocol is the number of infected people they have been in contact, they cannot apply linkage attack to any arbitrary client. Social graph reconstruction: A determined malicious adversary can learn a part of the social graph in a centralised system. The server can learn the social subgraphs with contacts between the diagnosed users and the people they have come in contact with. A determined user can obtain proof of encounter with a diagnosed person in a decentralised system [10]. Replay and relay attack—Identification of diagnosed users: An adversary, whether an individual, group, or organisation, can collect contact tokens, from the app or using strong Bluetooth receivers, along with the time and place of collection. In a decentralised system, the tokens of the diagnosed users are public. The adversary can use this to a posteriori identify the user that was diagnosed [10]. False encounter and false reporting: An adversary may install artificial broadcasters, and/or falsely report as positively diagnosed, to increase false positive exposure alerts. In this work, our proposed SecureCT framework is robust against all the attacks listed above. 4 SIMPLEST SERVER-AIDED PSI-CA In this section, we present the simplest server-aided PSI-CA in which the computation utilises a third-party non-colluding cloud server. Our proposed protocol does not require OT-based OPRF [25] or Odk-PRF [9] (e.g. public-key base-OT), thus, it relies only on symmetric-key primitives. To the best of our knowledge, this is the only construction with such a property. Technical overview Consider an untrusted cloud server C $\mathcal{C}$ who helps to perform PSI-CA on behalf of the receiver R $\mathcal{R}$ . Our protocol consists of two main phases. In the first phase, the receiver R $\mathcal{R}$ chooses a random key k which is sent to the sender S $\mathcal{S}$ . On the other hand, R $\mathcal{R}$ computes the PRF values x i ′ ← F k , x i , ∀ i ∈ [ n ] ${x}_{i}^{\prime }{\leftarrow}F\left(k,{x}_{i}\right),\forall i\in [n]$ , and sends them to the cloud server C $\mathcal{C}$ . One can consider this phase as executing oblivious PRF where the sender S $\mathcal{S}$ knows the PRF key k and the cloud server C $\mathcal{C}$ learns the PRF values F(k, xi) without knowing the key k. However, different from traditional OPRF, C $\mathcal{C}$ learns nothing about the underlying values xi. Having the PRF key k, the sender computes the PRF values y i ′ ← F k , y i , ∀ i ∈ [ N ] ${y}_{i}^{\prime }{\leftarrow}F\left(k,{y}_{i}\right),\forall i\in [N]$ . Our second phase replies on OKVS and takes the PRF values x i ′ , y i ′ ${x}_{i}^{\prime },{y}_{i}^{\prime }$ as inputs. More precisely, the sender S $\mathcal{S}$ encodes the points P = y 1 ′ , v 1 , … , y N ′ , v N $P=\left\{\left({y}_{1}^{\prime },{v}_{1}\right),\text{{\ldots}},\left({y}_{N}^{\prime },{v}_{N}\right)\right\}$ into an OKVS table T ← Encode(P) which is sent to the cloud server C $\mathcal{C}$ . Here, the set V = {v1, …, vN} is randomly chosen by the sender S $\mathcal{S}$ . The cloud server C $\mathcal{C}$ knows a table T, so she decodes it on every x i ′ ${x}_{i}^{\prime }$ and obtains a set W = {w1, …, wn}. According to the OKVS's functionality, we have wi ∈ V if x i ′ ${x}_{i}^{\prime }$ was encoded in T, otherwise, wi is random. In addition, the cloud server C $\mathcal{C}$ cannot infer any information from W due to the randomness property of the OKVS. To allow the receiver R $\mathcal{R}$ to learn only the intersection size, the sender S $\mathcal{S}$ and the cloud server C $\mathcal{C}$ respectively send a set V and W to the receiver R $\mathcal{R}$ in a randomly shuffled order. At this point, the receiver can count how many items are in the intersection by computing W ∩ V as | W ∩ V | = | x i ′ i ∈ [ n ] ∩ y i ′ i ∈ [ N ] | = | X ∩ Y | $\vert W\cap V\vert =\vert {\left\{{x}_{i}^{\prime }\right\}}_{i\in [n]}\cap {\left\{{y}_{i}^{\prime }\right\}}_{i\in [N]}\vert =\vert X\cap Y\vert $ . In addition, the shuffling makes the receiver learn nothing about which specific item was in common (i.e. which wi corresponds to the item xj ∈ X). Thus, the intersection set is not revealed which can prevent the linkage attack in the contact tracing scenarios. Garimella et al. [24] lists several OKVS constructions with different encoding/decoding costs. The most efficient OKVS scheme is based on a 3-Hash Garbled Cuckoo Table (3H-GCT) in which: the encoding time for encoding N items in the OKVS is O(Nλ); the decoding time for decoding n elements is O(nλ); and the length of the OKVS table T is 1.27N + log(N) + λ. However, 3H-GCT is not deployment-friendly as it involves complicated peeling/unpeeling processes. Thus, in the implementation of SecureCT, we use a deployment-friendly OKVS variant, a polynomial-based OKVS scheme, in which the encoding and decoding algorithms are exactly polynomial interpolation and evaluation. In polynomial-based OKVS, the encoding/decoding time takes O(N log(N)2) and the table's length is N. Construction Our server-aided PSI-CA protocol is presented in Figure 2. It closely follows the technical overview described in Section 4.1. Recall that the set V is pseudo-random and known by both parties, S $\mathcal{S}$ and R $\mathcal{R}$ . Thus, the set V can be generated from a PRG seed known by these parties. In our construction, we reuse the PRF key k as the PRG seed. Clearly, the outputs of PRG and PRF are independent, and their distributions are uniform. FIGURE 2Open in figure viewerPowerPoint Our server-aided PSI-CA construction 4.2.1 Correctness To show correctness of our construction, we consider two following cases based on whether xi ∈ X is in the intersection of X and Y: Case 1: Suppose xi is an element in the set of Y, ∃yj ∈ Y, such that yj = xi. Then we have x i ′ = F k , x i