 Welcome to my talk. My name is Sai Krishna and I'm gonna be talking about our paper titled Beta, Biometric Enabled Threshold Authentication. This is joint work with Shashank, Payment, Prathya and Shikha. First let's look at how password based authentication works today. So there is first an enrollment phase during which the user endures their password onto a server. Typically this is done in the form of storing the salted hash of the password. And then in an online phase, the user enters their password onto their device, say a mobile phone. The phone passes along this password or a salted hash version of it to the server. The server then checks whether the password matches with the one it had on its end and then authenticates the phone. While password based authentication is great, there are multiple issues that we have identified over the years. As everybody is aware, the biggest concern is the problem of offline dictionary attacks. There have been several large scale real world breaches where servers storing millions of passwords have been breached and compromised users privacy. And then also there is a lot of usability concerns of using passwords because it inherently requires a high entropy and that is not easy to remember for users. Moving along to biometric authentication, the flows are similar, you have an enrollment phase where the user endures their biometric template to store on a server. And then in an online phase, the user enters their biometric measurement onto mobile phone or their device. The phone passes it along to the server, the server checks if it was a match or not to authenticate the user. On the one hand, there is better usability than passwords because users don't need to remember any data and no high entropy requirement is posed here. While on the other hand, a server-side breach is much more damaging in the case of biometrics than passwords because unlike passwords, you cannot really change your biometric easily. One of the popular industry-wide standards for using biometric authentication is the Fido Alliance and let me briefly recall how that works. First, as we mentioned before, in the enrollment phase, the user enters the biometric template onto the phone, but then instead of sending across this phone, the biometric template onto the server, the phone locally stores the biometric template. It then generates a public key and a signing key, sends along the public key to the server and keeps the signing key with itself. Now, in the online phase, when a user wants to authenticate themselves, they once again enter the biometric measurement onto the phone. The phone locally performs the biometric comparison with the template that was stored earlier to check whether the new measurement matched on it. And if it was a match, the secret key or the signing key is unlocked. And then the server sends along the challenge and the phone signs this challenge to indicate to the server that the user indeed produced a measurement that matched. And this is how the user is authenticated. While this is a popular standard and is very effective in several aspects, there are once again some concerns with this as well. The first is that as before, there's again a single point of failure with the phone storing the user's biometric. And then another usability concern is that every time the user wishes to authenticate themselves, they now need to carry along the same device that originally held the biometric template. Now, if you think about how the user can store the biometric data on the phone, there are a few options here. One with maybe there's a secure hardware, but this is costly and are not easily available and so on. Another option similar to the case of password could be to store a salted hash of the biometric. And one concern here is that the biometric matching process unlike passwords is fuzzy. Whereas in the case of passwords, it's an exact quality test. So salted hash might not be quite compatible with biometric matching. And then of course, there's also the issue of an offline attack that an adversary who manages to capture the phone can launch. Another option, a popular option is using the notion of fuzzy extractors, but then this requires high entropy from the underlying biometric data. Fuzzy extractors also result in a loss in accuracy and of biometric matching. And once again, the offline dictionary attacks are still possible here. Our solution to address this problem is to propose the notion of, you can think of it as distributed FIDO. So we propose this new primitive called a fuzzy threshold tokenizer, which works as follows. We have an enrollment phase as before, but now in the enrollment phase when the user enters the biometric template into the phone, the phone no longer stores the biometric template entirely in the clear in itself. Instead, we think of several more devices that the user owns and the phone secret shares its template on with all these devices. Similarly, the signing key is also not stored only on the phone. The signing key is also secret shared between all these devices. So think of a user who has a phone, an iPad, a watch, a smart watch, and let's say a laptop, for example. And then the public key central server is before. You can also think of a setting where the user only has one device, but now instead of a single server, there are multiple servers each of whom holds one sharing of the key. But for the purpose of this talk, let's just take the user having multiple devices. And now what happens in the online phase? The user can enter their biometric measurement. The phone now instead of performing the biometric matching locally on its end talks to all these different other devices that the user owns to check whether the biometric measurement matched with the template that was secret shared amongst all these devices. If the match succeeded, then the phone tries to generate a signature once again by talking to all these devices and produces back to the server to authenticate. So this prevents the single point of failure attack that we were concerned about. And what would be the advantage of this primitive or in particular, how would the phone communicate with all these other devices? What are the requirements that we impose here in our primitive? The first is that we do not want the user to carry along all their devices all the time. In particular, the primitive requires or the primitive states that it's enough and sufficient and necessary for the user to only interact with some threshold T number of devices. And secondly, we want to enforce that the all the T devices do not need to interact amongst each other. It's enough if they interact only with the device that is initiating this authentication session. In particular, this is like a star network where the one who's initiating the session is the star and of the star mode and sitting in the center and all communication only happens via this device. And finally, the third requirement we pose is that the initiator need not be the phone that originally took us input the user's biometric measurement or in fact, it did not even be the same device every time. We call that one of our concerns with the Fido standard was that we did not want the same device to be required to be used every time. So any of these devices could serve as the initiator in any of the authentication sessions but the only requirement that they then talk to a threshold number of other devices using a star network communication model. So with this primitive in mind what are the security goals that we would want to achieve from such a primitive? Let's consider a malicious adversity that can corrupt a set of devices and the number of devices that corrupts can only be less than T. The first requirement is privacy of the biometric template the template that is generated that is registered in the enrollment phase and secret shared amongst the users amongst the devices should always remain private. So in any authentication session the adversary should not be able to learn anything about the template. Similarly, we also want privacy of the measurement so the adversary should not be able to learn anything about the measurement no matter whether a match was successful or not. And both of these requirements can be formalized using indistinguishability or simulation-based definitions. And finally we want the notion of unforgeability which states that the adversary should not be able to generate a valid signature on any challenge without actually running the protocol on a valid measurement. By valid here, I mean that the measurement that the protocol is run with should indeed produce a match with the template that was stored. Moreover, another requirement we have is that even by using a valid measurement and running an honest session the adversary should not be able to generate more than one signature. In particular, in order to generate any fresh signature you need to run a fresh session using a valid measurement. We formalize all these three security requirements by using a simulation-based definition in the universal composability framework. Before I move on to the results that we obtain in this paper let me briefly touch upon how the process of biometric matching works. So how do we compare two biometric measurements? So the first step is that the biometric matching in the biometric matching process is to convert each of these measurements into vectors. So let's say one of them is converted to a vector x and the other to a vector y. And then we say that the two measurements match if the distance between these two vectors is small. And this distance can be various distance functions depending on which biometric matching process we use or which biometric quantity we assume. For example, it could be a different distance metric for your iris scan, a different one for fingerprints and so on. So what are the results we obtain in this work? As I mentioned before, we define a new primitive for threshold biometric authentication and we formalize security of this primitive in using a standard simulation-based definition with universal composable security. We then design three protocols that are secured against malicious adversaries with this UC-secure definition. And these three protocols have various trade-offs amongst each other. The first protocol works for any distance metric. In all three protocols, there is no bound in the number of parties in the system. In the first protocol, the number of the threshold T can be anything, anything less than n. The number of corrupt parties can be anything less than T. The protocol is based on any Turon MPC protocol and it's not completely efficient. It's a feasibility result. The second protocol is also a feasibility result that works for any distance metric, any number of corrupt parties, any threshold T. And this one is based on the primitive called threshold FHE. The third protocol is a completely efficient protocol. This is tailor-made to cosine similarity and Euclidean distance metrics. Both of which are popular for fingerprint and facial recognition. This protocol is based on only pyre encryption. It works in the setting where the adversary can corrupt at most one party and the threshold number of parties required for any authentication session is only three. In this work, I'll focus briefly on the techniques underlying our first feasibility result and the efficient protocol focus sensibility. So what are the techniques in our protocol? So first let's see the Turon MPC-based one. So suppose there was no constraint on the communication pattern at all. So now we have an authentication session in the online phase where each of these devices have their own shares of the template and the six-line key. And the device that initiating the protocol has a new measurement view and a challenge value that is sent from the server. So if there was no constraint with the communication pattern, we could just run an MPC amongst all these T plus one or these T parties for the following function. The MPC for each party, each of these T devices send use as input their share of the signing key and the template. The initiator additionally also uses the challenge and the measurement as input. The MPC just simply reconstructs the template W and the signing key SK. If the measurement and W are close, according to the underlying distance metric, then it generates the threshold signature. So this would be simple, but the real challenge sure is we want to be able to do all of this only using the star network communication model. And also we would like to ensure that only one signature is sent in each time and so on. So how do we emulate a two-round MPC protocol? Let's call it protocol SPAC. For simplicity, for the stock, let's say N and T are both three. So the initiator sitting in the middle of the first party, P2 is sitting on the left and P3 on the right. So let's say P1 just sends out one message saying begin to let them know that they can now start running the protocol and both of them send the first round of the two-round MPC message. As you would imagine, P1 can just forward this to the other party, just act as a messenger in between forwarding the messages. But of course, this nightly would not work because P1 could send inconsistent or different messages. P1 could send to P3, something that it did not actually receive from P2. As you might guess, this can be easily solved by just adding a signature. Let's say in the setup, in the enrollment phase, P2's verification key is known to P3 and so on. So you can add a signature that will prevent P1 from sending different messages that it did not receive from one party to the other. So the parties check the signature. Additionally, P1 sends the first round of, its own first round of the underlying MPC protocol to both parties. They respond back with their respective second round messages. Now notice that since we want only P1 to get the output, it need not actually even generate its own second round message. It can just use the transcript of the protocol so far to compute the output of MPC. And we will be done. Unfortunately, that is not the case. As you might have noticed, we also need to ensure that P1 does not send inconsistent first round messages to both the parties. Notice that this underlying tour on MPC protocol, if it's based in the broadcast channel setting, requires that the first round message sent by P1 to all the parties are the same. So now we need a mechanism to ensure that P1 indeed sends the same first round message to both parties or otherwise that this is detected. Our idea is that we do not require P2 and P3 to detect that they got inconsistent messages, but instead we want to design a mechanism that allows P1 to recover P2, P2 second round message of the MPC protocol if and only if it indeed sent the same first round message to both parties. That is, we want to say that only if message 2 is equal to message 3, then P2's second round message of protocol Pi is learned by P1. And how do we do this? This can be achieved by a very simple trick. We let P2 and P3 share a couple of PRF keys, say K2 and K3. Now instead of sending its own message in the clear, P2 encrypts its second round message of Pi using a key generated, think of it like a one-time pad generated using the PRF K2 on the message it received. And now we can allow P3 to send across this one-time pad to P1. So P3 would send PRF of K2 on the message 3 that it received. Now only if message 2 is equal to message 3, P1 would be able to decrypt and learn the second round message of P2. The same thing can be done in reverse to allow P3's first second round message to also be learned. And this approach naturally generalizes for arbitrary NNT by using either pairs of PRF keys or a distributed PRF. And I'll not get into the details of that. And now let me get into details of the techniques behind our three-party protocol. So how does the biometric matching work in the case of cosine similarity? The distance function here is that the inner product between both these vectors should be greater than some threshold T. I'm simplifying a little bit when I say it's inner product, but for the purpose of this talk, let's just think about the inner product. And the number of elements that you want to match is typically in the order of 256 or 512. So how does our protocol design work? Since we have just three parties, let's say even NS3 for simplicity. In the enrollment phase, as before, we just secret share the template and the signing key. Additionally, suppose we have only considered the case where this phone at the center is going to be the initiator always. Then we share some randomness between the other two parties, P2 and P3. Now in the online phase, as before, the initiator sits in the middle. The initiator just runs a two-party protocol with one with P2 on the left and one with P3 on the right. This is inspired by the work of MRZ, Mohasil, Nassal Lake, and Zang from 2015 CCS, where they consider the setting where you could run two parallel executions of the ARV protocol and check whether one of them is lying or not, since we have only one party that can at most be correct. So both P2 and P3 generate a double circuit for the following circuit. They just deconstruct W in the template using the shares W1 and W2. W2 is local to themselves and W1 is received. And then if the inner product between you and W is greater than T, it outputs some simple encryption key where the partial signature of the threshold spending scheme is generated and encrypted using this encryption key. And now P3 just can send a hash of this message. P1 checks the hash, whether they're equal. If so, it recovers the labels of the OT protocol, evaluates the double circuit which generates the encryption key and decrypts the ciphertext to recover this signature. So this is pretty straightforward, but there are multiple issues here. The first is the computation inside the double circuit is very expensive because a reconstructing W, computing the inner product term by term, each of these is very expensive as you saw the number of elements in each vector is in the order of 200 or 256 or 500. So can we do backup? We can do a simple double circuit. In particular, can we offload the computation of the inner product somewhere outside the double circuit and use the double circuit only to do the comparison. And secondly, from a security point of view, we'd also need to ensure that the input W1 that P1 uses in the OT receiver message is consistent with the W1 that it received at the end of the enrollment phase. We need, there's no guarantee that it's using the actual template shared that it stored at the end of the enrollment phase. To tackle the first problem, we resort to using Pyr encryption, which is an additively homomorphic encryption scheme to compute the inner product outside the double circuit initially. In more detail, P1 first generates an encryption of its measurement cube. P2 using the additively homomorphic encryption scheme computes an inner product, encryption of the inner product between U and W2. P1 can, after checking the hash, decrypt this to learn U inner product between U and W2 in the clear, adds it to the inner product between U and W1, which it can compute locally to compute the actual inner product. And then they can run this protocol as before. Now notice that the double circuit does not need to compute the inner product. It can just directly check if this is greater than the threshold, which makes it much more efficient. How do we solve the input consistency issue? The idea is that in addition to sending an encryption of its measurement, we require P1 to also send an encryption of the inner product between the measurement and the temperature that it owned. That is an encryption of inner product between U and W1. And additionally, we require P1 to add knowledge proofs that this encryption U was correctly generated and that this inner product is consistent with the W1 it had at the end of the enrollment phase. So I'm not getting to the details of how we generated this visit, but for the purpose of this talk, just believe me that this can be done efficiently using existing schemes and literature. And now what does P2 do? Instead of just computing the inner product between U and W2, it adds it also to the inner product it received here to actually send an encryption of the inner product itself. Okay. Now P1 can just decrypt this and directly receive the inner product and proceed with the rest of the protocol. I skipped over some issues, some challenges here, but those are mainly in terms of generating this visit and I'll let you look at the paper to understand more details here. But now let me move on to some other issues with this protocol structure. Now notice that in by running this step here, what happens is that P1 now learns the decryption of being the inner product directly in the clear. And this is too much leakage because we do not want P1 to learn any information whatsoever about either the template or the measurement that was generated. While P1 knows the measurement since it uses it, it shouldn't learn the template. So the inner product leaks information about the template. How do we prevent that? This can just be done by a simple one-time pad that P2 can add. P2 adds some randomness R to the inner product and this hides the anything about W entirely from P1. And the rest of the protocol can proceed. The next challenge is how do we ensure that P1 indeed uses this value IP that it decrypts in the OT query. In particular, P1 could now just send OT1 for any value that it wants on its own choice. And the idea to prevent that is to add additional one-time MACs. So along with this encryption of the inner product plus randomness, P2 also sends a MAC on the inner product. The MAC on this value. And so the couple circuit would check this MAC before it outputs the encryption key. I don't have time to get into the details, but I hope you got the gist of the idea. And the final thing is we also need additional checks to make sure that P1 is using the right modulus for U and W1. Since there is no checks whatsoever, especially no checks whatsoever being placed on the measurement U. For the sake of the biometric matching protocol, we need to make sure that the vector U that is picked is indeed small and satisfies some modulus checks. But I'll defer that to the paper for more details. Finally to conclude, we have a new formal model for biometric, threshold biometric authentication with a UC secure definition. We have multiple protocols, two feasibility results, and one efficient protocol focused on similarity. And now some open problems. Can we define weaker game-based definition than the simulation based one that we have here and perhaps more efficient protocols with respect to this weaker definition? How about considering other distance functions like how many missions which is popularly used for either scans? Can we consider a dynamic system where devices can be added and removed dynamically? And finally, can we consider the case of adaptive corruption? Are protocols and security proofs all considered only static corruption? Thank you and that's the end of my talk. Thank you for listening.