 Hi everyone, my name is Lee. I'm from Arizona State University and I'll present our paper, Delegating Private Set Interest and Mechanicality and its Application to Contact Tracing. This is a short work with Kai from Google and him from Telecom Parties. So I'll start with an overview of contact tracing. We see an application for our PSICR, the current solutions of contact tracing and its limitation. Later, I will go more detail how we can handle privacy concerns and how to improve a contact tracing performance. So you know, contact tracing is to find out all individuals that an infected person has been in contact with. And we want to do this because we would like to stop the disease spread. So how is contact tracing done? It can do manually by interviewing the patients. So you can now where and when they have been. So this solution has privacy concerns and offensive to scale. In this paper, we focus on mobile contact tracing. The phone application can detect all possible nearby contacts. However, it must be privacy sensitive, must be high scalable, especially on the user device and requires less false positive or negative rate. So most current contact tracing approaches are based on Bluetooth and work as well. When Alice and Bob are close in SIGFIX, Bob use a C to generate and broadcast a random token. So you can see here the number one, two and three. And Alice save all the nearby random tokens to her phone. A few days later, Bob is positive with the disease. He applies all the CIS that used for his random token. So the server can see number one, two, three. And now Alice downloads all the nearby random tokens on the CIS from the server and check make posters. So the users broadcast and save random numbers. So it looks like that the personal information never shared or collected. But it's not always true. There are several problems include security issues, for example, the linked attack or replace attack. The current solution is not scalable for the end user device. And they have the highest false positive or negative rate. So in this talk, we focus on the linked attack. And we want to address this problem. And we also want to improve the performance of the contact tracing, especially on the user device. So I will present the detail of security issue here. So you know, because all the infected tokens are publicly available. So when doing the compare reasons, Alice can learn which token is infected. So she can see that token number one, two, three is infected token. And then she can infer when and where and from whom she received this token and then can re-identify both. So for example, Alice put an Uber ad known and receive this token at that time. So she can infer the infected status of the Uber driver. And actually, Apple and Google solution store these tokens at the OS level, but it still has some privacy issues. So moreover, an attacker can install the Bluetooth sleeping device to different physical locations and then collect the random token. So is it possible for the attacker to keep track when and where they receive it with tokens? And the attacker can do that to learn the travel road of the individuals. So this picture is the real attack of Apple and Google solution. So beside the security issue, there is a performance problem, especially on the end user device. So they call that the user needs to download the token on the scene of all infected users. So for 32,000 new daily impressions, the DP3T approach requires 450 megabyte download in the token. And Google and Apple approach requires only seven megabytes download in the scene, but they need 66 million AES operation to generate the token. So clearly that you need a good phone to do the contact tracing. So in the rest of my talk, I will present our solution to prevent the link attack using private matching, private set intersets and connectivity. And we also show how to improve the performance of contact tracing with the outshot scene protocol. So I'll start with the link attack. The main reason of this attack is that all the infected tokens are publicly available and therefore known by the attacker. So previous solution would propose a simple solution to address this problem. The main idea is still allow Alice to check his exposure status without knowing all the infected tokens. And they use PSICR for this. So PSICR is a two-party protocol where the server has a set of X and Alice has a set of Y and Alice learns the size of the interactions and nothing else. So by doing so, Alice doesn't know which token is infected. So she can infer both infected status. However, this solution is heavy on public key operations and requires exponentiation for each item. Therefore it's inefficient when the set size is large. And here is the contact tracing system. And they have several systems here. And you can see that they either expensive on the running time or the communication cost. So for the poor phone, can we outsource the contact tracing computation to the cloud? So I will go to our delegated PSICR protocol and with our delegated contact tracing system. So along with that we introduce the new crypto-tune which we call or previous distributed key PLF. So a simple solution for delegated contact tracing system is that we introduce another cloud server. And Alice outsources her receiving token to that server who the server, this is the cloud server and the back end server runs PSICR. And then we turn the Rbook to Alice. However, these solutions preview the Alice travel history to the cloud server because the cloud server known all the non-infected tokens. So in our paper we propose a delegated contact tracing system where Alice can introduce her receiving token to several cloud servers using secret sharing. So it means that the sum of the value here equal to the token. So you can see number 123 can be the sum of number 100, 20 and 3. Now cloud servers and the back end servers run secure computations and Alice is the person to get an output whether there is a match. The secure computation here is delegated PSICR. So input Alice has Y, the set of Y, the back end server has a set of X and the cloud server with no input. And Alice learns the size of the interaction and nothing else. So this paper propose the first delegated PSICR protocol. Before going to the protocol, I would like to present a previous PIF functionality and it's the definition of our new OPF. So the traditional OPF we have one sender and one receiver. And the sender with the key k, the receiver input, the value Y and receive fky. So you can think h of Y to the k, the half function of Y to the k is the OPF. So clearly a property is that if x equal to Y, then kx equal to fky. We introduced a new crypto term which we call oblivious distributed key pf. So instead of having one receiver, now we have many receivers. The sender have the same key as before, but the key is distributed. So for the first receiver, if he inputs Y1, he will receive fk1Y1. Similarly, the last receiver input Yn will receive fknyn. And we have the property that if x equal to sum all the Yi, then fk of x equal to sum all the fkyYi. So you can think like the value Y is also distributed. And another important property is that if we have the combiner who can collect all the OPF value fkyYi, the combiner can reconstruct fky by some of all fkyYi. And the combiner learn nothing about fkyYi or the value Y. So given that functionality, we go into our delegated PSICR protocol. So the main idea is that Alice distributes her token to cloud servers. So say Alice has a number of Y1 and Y2. Each cloud server has a share of Y1 and the share of Y2. And then these cloud servers run ODKPS with the backend server. So the backend server has the key k and the cloud server receives fkyY. So you can see that for Y1, the cloud server receives fk1Y11. And now we introduce a combiner who can combine all the OPF value here. And he can compute fkyY1 and fkyY2, right? And because the backend server has the key, the backend server can compute all OPF values on his set. So he can compute fkX1, fkXn. And now what we want is that if the combiner have have the two, the same OPF values, so for example, if the combiner have Y1 equal to some fkyY, then the combiner will receive the secret values of the backend servers. And otherwise, this is the random value. And then somehow, if Alice knows all the secret values here, Alice can do the comparison between the secret values and then see whether there is a match. So we use the polynomial to implement this step. So quickly, the server interpolates the polynomials on the OPF values and the secret value. So this is the polynomial going through the OPF values, fkXi and the secret value Si. And then the server sends the coefficient to the combiner. The combiner either you add the polynomial on the OPF value. So clearly, if X equal to Y, then you have OPF value equal. So the combiner can learn the secret value. And otherwise, the OPF value here is random. So the polynomial on the random values is the random value. And now the combiner sends all the x, y to Alice and she needs to set it in the server order so that Alice doesn't know which one is in the interactions. Similarly, the backend server sends all the set of secret values to Alice. And now Alice can compute the intersection of x, y and x. So to reduce the communication cost, you can see here the size of the secret value proportional to the set size of the backend server. But the secret value can be a random. So we can reduce the communication cost here by using PRG. And we also use the hash to mean scheme to reduce the cost. So please see the paper for more detail. So by interacting our dedicated PSICR to contact tracing systems, we have the lowest communication cost. And plus in the running time, because in our system, the user can outsource all the communication to the cloud. And we also can prevent the link attack. We also benchmark the performance of end user device. So for 4,000 tokens, the server only require the user only require a few millisecond to do the dedicated PSICR protocol. And it requires only a few like 200 kilobyte per second. This is a very reasonable cost for the phone. And for the cloud server, it takes about a few minutes to do the PSICR or contact tracing on the very large set size. So, and this is for single threading. So if you have multiple threading, then the cost, the running time can be reduced to some seconds. Yeah. Thank you for listening and you can see the talk on e-print and the demo of our implementation on e-print.