 Hello everyone and welcome to this presentation. My name is Sia Vashriyahi and today I will present the paper Fuzzy Asymmetric Password Authenticated Key Exchange. This is a joint work with Andreas Erwick, Julia Hesse, Maximilian Ault and me myself. Andreas Maximilian and I work at TU Damstadt in Germany and Julia works at IBM Research Research in Switzerland. Let's start with some motivation. Assume that we have two parties, Alice and Bob, who share a secret password, which like most human-memorable passwords has low entropy. Alice and Bob wish to perform a password-based authentication and communicate securely with each other. This is a wide problem in today's digital world where two parties wish to communicate with each other securely. A trivial solution would be to first establish a secure channel and then verify each other's password by exchanging and comparing the passwords. This solution is also known as password over TLS. However, this solution has two major drawbacks. One, it requires a secure communication channel. This is necessary because otherwise, when exchanging the password, it would be leaked to anyone listening on the line. But secure communication channel would need public infrastructure and certificate authority. Furthermore, the passwords are exchanged in plain text. This would be insecure if the receiver of the password is compromised. We would like to have protocols that do not require these two assumptions. In other words, we would like to have protocols which are secure even if the channel is compromised and an adversary sitting on the line listening to the communication between Alice and Bob can drop messages and even impersonate one of the parties to the other one. Alice and Bob should derive the same cryptographic key if they have the same password, and the adversary would be oblivious to the password and the key. However, if Alice and Bob do not have the same password, they would derive different cryptographic keys and the adversary would still be oblivious to the passwords and keys. This must hold even if one of the parties, let's say Bob, in this case, is corrupted. So Bob would not learn anything about Alice's password or the key key, although he's corrupted. The solution to this problem is called password authenticated key exchange and has been analysing the past few decades. There are two variants of PIG which we are interested in in this work. One is azimetric PIG or APIG for short. In this setting Alice is not communicating with another party, say Bob, but is communicating with a server. And as we know, servers can get compromised, the passwords that the server has stored might get leaked, so the server doesn't want to store the password in clear text, but he wants to somehow store it in a way that cannot be directly extracted easily from the file. In practice, most parties, most servers hash the password and store it. Another variant of PIG is fuzzy PIG. Where Alice and Bob have passwords which might not be exactly the same, but are close to each other. And they would like to be able to drive cryptographic keys and authenticate each other. What do I mean that the passwords are close to each other? I mean that there is a distance metric called D, which would save the password PV and PV parameter close enough. And if that is the case, the parties should drive the same cryptographically secure key. Note that we do not necessarily require them to be passwords which includes alphabets, which includes the English alphabet and some numbers, maybe some exclamation points, but it can be any bit string that the parties share and has low entropy. The goal of this work is to for the first time define the primitive fuzzy asymmetric PIG and instantiate it. First, let's see why it would be interesting and important to have fuzzy asymmetric PIG with some examples. The first application would be handling typos. If we are all humans, we all have forgotten at some point one or two characters of the password that we have registered on a server. Using fuzzy asymmetric PIG, the client can choose the password that he or she thinks that is probably close enough to the password that she registered. The server would use the file that it had stored on behalf of this client. And both parties would drive the same cryptographically secure key key. Another use case would be authentication via biometrics. Now, the server, in this case, would store a scan of Alice's fingerprint, let's say, or Iris scan. And Alice can each time make a fresh scan. I would like to point out that biometric scans are never exactly the same. Each two consecutive scans are slightly different, but close enough to each other. Using FAPIC, the client can make a fresh scan, the server would use a file, and both the client and the server would drive the same cryptographically secure key key. But this goes beyond communication between a client and a server. It even addresses communication with a local device, authentication with a local device. Now, it might be an overkill to use a key exchange protocol just for authentication, but it is doable to use FAPIC in order to authenticate to a smartphone, for example. But why would someone wish to do authentication via such a protocol with a local device? Well, the local device here, the smartphone, must store the fingerprint in some format. Some encrypt it, some store it on some secure enclave. But at the end of the day, when authenticating, this fingerprint or biometric data must be extracted and compared with a fresh scan. We all know that devices might get compromised and the biometric data, in this case, can get leaked. This would be quite problematic because one cannot change easily the biometric, if at all, during their lifetimes. But if we use FAPIC, the client can make a fresh scan, the file would still be hiding the biometric data as extracting the biometric data would be difficult. And both parties would drive the same key, which would allow them to later verify if they have successfully authenticated each other or not. Now, you might be wondering, why FAPIC is difficult to construct? Can't we use the current PIG variants to construct it? Well, the answer is not really because APEIC only allows exact matching. So it cannot really be used in fuzzy matching. Second, the server doesn't have the password in clear text. It has stored it in some format which is not easily recoverable. So the fuzzy PIG paper of EuroCrypt 2018 doesn't really help us here because their solution requires both parties to have the password in clear text. Lastly, fuzzy crypto cannot really help us because it has leakage and, for example, information reconciliation or fuzzy extraction will not really be able to help us with passwords which have low entropy and do not follow any specific distribution. Our contribution in this work would be to for the first time present a model for fuzzy asymmetric password authenticated key exchange and design two protocols and prove their security in our model. I will start with our model and then continue with our protocols. So first, when do we actually use key exchange? We use key exchange protocol in order to run some other protocol on top of it. So our protocols must be composable and the standard and accepted composability framework for PIG and many other areas of research is universal composability framework of Karnitya. And we also prove our protocols and model of protocols in the UC model. Now, back to some functionality goals. So from the original PIG literature, we had the no online attack property. This I have touched before when I was motivating the problem. Online attacks means that if the adversary who's sitting on the line even corrupting one party can learn anything about the password or the key that the honest party has been used. This should not be allowed. The adversary, even if corrupt, even if he has corrupted one of the parties should not learn anything about the password or the key of the honest party. From a pig as a metric pig, we inherited the property of no offline attack. This this means that the password files must actually hide the password inside of it. Note that the in this model, it is possible that an adversary learns the password file. And when the adversary has learned the password file, he must be able to run some dictionary attacks and brute force attack on top of this file. So if the password that the client has registered is not secure, the adversary would be able to learn this. But if it's secure enough, long enough, the adversary would not be able to learn this. And this is also reflected in our model. Lastly, from fpig, we inherited the property of allowing fuzzy matching because we want to allow matching, we want to allow authentication, even if the password is not exactly the same. All in all, we generalize and combine the UC functionalities of the fuzzy pig paper and the asymmetric pig protocols from the literature. I will not go into more details regarding our functionality and the modeling and would refer you to our paper for more information. Now, regarding the protocols that we've designed, we've designed two protocols. The first one, which we call FA pig, is from secret sharing. And the second one is by transforming a pig into fuzzy as a metric pig. I would like to point two facts about this transformation protocol. First, it was mostly designed in order to compare its efficiency to our original fuzzy pig FA pig protocol. And second, it has weaker security guarantees compared to our FA pig protocol. Nevertheless, this protocol might be quite useful when when tolerating a few typos in passwords. And therefore, it is important to know where it stands compared to the other protocol FA pig. The FA pig protocol allows for hamming distance as its distance metric and requires the idealized assumptions of ideal cipher and jury group model. Just as a recall, hamming distance is when two values are x-ord and the number of ones in the x-ord value is counted. The transfer protocol, on the other hand, allows arbitrary distance measurement metrics and requires ideal cipher and random oracle model. In the rest of this talk, I would focus mostly on FA pig protocol. I would refer you to the paper for more information about the transfer protocol. But first, I would like to talk about the phases of as a metric pig and consequently FA pig protocols. The first phase is the password registration phase. During this phase, both Alice and the server, sorry, have the same password and the server generates a file and removes the password from its memory. It is always assumed that this phase is executed honestly because if it's not executed honestly, then you cannot really have any guarantees during the next phase, which is the key exchange phase. During this phase, the server uses this file and the client chooses a password, which might be the same as the one she registered or slightly different. And the client and the server both drive keys, which may or may not be equal depending on which party was corrupted or whether the client has used the same password or not. Finally, there is an explicit authentication phase where the parties check if K is equal to K prime and they had used indeed the same or close enough passwords. Note that this explicit authentication phase is not necessary in order to guarantee the functionalities which we require from a pig or FA pig. Now, some protocol require it in order to be proven secure, but it is not a necessary part in terms of functionality wise. Now, let's get to our protocol FA pig. The main idea behind our protocol is to use Shamir's secret sharing. The server can choose a cryptographically secure key, secret shares it, sends this shares to Alice, and Alice can reconstruct this cryptographically secure key. This is the crux of our main idea behind our fuzzy FA pig protocol. For the rest of this example, assume that the secret sharing that is being used is five out of six secret sharing. So given, or in other words, given five correct shares, Alice can actually reconstruct K. Now, this is the complete honest execution of the protocol, which might not make any sense because the server can just send K to Alice. But at this stage, this protocol is not even password dependent. So let's try to fix this. Let's make this protocol password dependent. To make the protocol password dependent, we add randomly chosen element and use one out of two OT so that the client can choose the correct element. Assume that the password that Alice has registered is 100100. So the server would first choose the secret key. The secret cryptographically secure key K shares it and adds some random elements in the following way. If the corresponding bit of the password is one, the element K, the secret share would be at location one. And if it's zero, it would be at location zero. So for the first bit, the random element is at the zeroth row and the correct element is at Kth row. For the second share, the correct element, the correct share is at the zeroth row and the random element is at the first row and so on. This whole matrix plus the key that the server has chosen would be the file. Now, we have a client who has, let's say, an error in the fifth bit. She will use her password by running six times one out of two OT and would receive K1, K2, K3, K4, R5 and K6. She has enough shares and enough correct shares and can reconstruct K. But there's a slight issue here. In normal secret sharing, you cannot really detect which one of these shares was incorrect. So Alice needs to try all combination of five elements from six elements. Even worse, in Shamir secret sharing, the client here Alice might not even know if she has reconstructed the correct share or not, the correct secret or not. To address this, we use a primitive called robust secret sharing, which allows error correction given enough correct shares. So Alice would be able to detect which one of these shares aren't the correct shares that she should use in order to reconstruct the original secret K. Thankfully, Shamir secret sharing can actually be transformed into robust secret sharing. I will refer you to the paper for more information regarding this. But there is a more fundamental issue as well with this protocol. A malicious client can actually get the whole file in just two queries, querying all zeros and all ones. And then she can run some brute force attack on the password file in order to extract K. If you recall from the properties that I mentioned for FAPIC, this should not be allowed. Even if one of the parties is corrupted, given the transcript of the protocol execution, she should not be able to learn anything about the key that would be driven by the other party. Let's fix this. The idea to fix this is to re-randomize this file every session. This would require some homomorphic properties from the secret sharing. For example, adding some random value to these correct shares would indeed results in a secret sharing of a modified secret. And thankfully, Shamir secret sharing also allows us to do this. So each session, the server re-randomizes the shares and which now are like sharing K prime instead of K. Alice again uses 6 times 1 out of 2 OT in order to get these re-randomized shares and then she can decode and reconstruct K prime. I will not go into more details regarding our protocol. I would refer you to the paper for more details. However, I would like to emphasize here that for technical reasons, in order to prove the security of our protocol, everything needs to be done in the exponent. So all these secret shared elements are stored in the exponent, K is stored in the exponent and Alice does not get directly this K's, but she receives them in the exponent. Thankfully, polynomial interpolation which is required for driving this K prime can be done in the exponent and therefore there is no problem here. With this, I would like to conclude my talk. In this work, we for the first time gave the definition of fuzzy asymmetric peak which allows a client to authenticate herself with passwords that are faulty or biometric data in a client server setting. Further, we designed two protocols. One is called FAPEC and the other one is TRANS protocol from secret sharing and APEC respective. This is a really new direction of research and there are still many things that can be done in order to improve our constructions. But there are two particular open questions that I would like to mention here. First, we would like to remove the error correction in the exponent. As I said before, we need to do the error correction in the exponent for technical reasons. This although doable, is not very efficient and we would be interested in being able to actually improve this. The second open question that I would like to mention is improve the error tolerance of the FAPEC protocol. Now, let me explain a little bit more into details here. As we know by now, fuzzy peak or fuzzy asymmetric peak allows fuzzy matching between two parties. They have some distance metric and if the two elements are close enough, they would be able to authenticate each other. Since we are using error correction in our FAPEC protocol, an error correction adds some additional fault to the protocol itself. We lose some error tolerance in our FAPEC protocol. This is somewhat undesirable and it would be quite good to actually solve this as well. So, I would like to thank you all for your attention and if you have any questions, I would be more than happy to answer them on the online panel of Azure Crypt. Thank you very much.