 Hi, I'm Victor Schupen. I'm going to be talking about the security analysis of S-PAKE 2 plus and As let me start with some background going back to the olden days where we just had traditional password authentication protocols We have a client with a secret password pi a server who stores Some salts along with the hash value and this is a hash of the password Identifying information of the client and server and assault That's this is so these are the two values at the server source stores And then when the client wants to log into the server, he simply set his password over to the server The server would hash everything he would hash the password this identifying information along with the salt and test whether or not These two values this hash value here matches the hash value that was computed here So that's the way kind of things worked back in the 1970s or 80s I think we use this thing called telnet way back then and of course it was very insecure because if you logged in over the internet or Over then then what would happen is that you'd be sending your password out in the clear And of course everybody could just see your password and steal it So what that's been replaced by and what's actually quite widely used today is the following kind of scenario Where we combine this basic password protocol with one-sided authenticated key exchange So here the client and the server would run a one-sided authenticated key exchange protocol Using just the server's public key. We assume the clients don't have public keys and then once this A secure channel has been established in this way Then well the client knows he's talking securely to the server and the server also knows He's talking to somebody, but he doesn't really know who he's talking to yet So then what then the client in the server would use the secure channel to run this simple protocol here And that's and then once that was done then the server would know that he's talking to the client Who knows the password? So that's kind of the way a lot of things work now on the internet Some limitations of this approach is that it requires a public key infrastructure Certificate authorities etc. And it's also open to so-called phishing attacks Which most people I think knows know know what those are so one way to mitigate these limitations Is to use something called password authenticated key exchange or PAKE for short This is an idea that's been around for a long time is introduced by Belevin and Merritt in 1992 It eliminates the need for a PKI Which is nice? And it prevents So-called offline dictionary attacks. So I'll have more to say about that in a minute But the main ideas are as follows. So We have an adversary that If he actively interacts with the client or the server Say the adversary might pretend to be the client and interact with the server or pretend to be the server and interact with the client Then of course what the adversary can always do is just run the protocol with some Particular guess at the password and at the protocol succeeds. He'll know he's gotten the right password and if it fails Well, he can try it again, right? So with every run of the protocol The adversary effectively just gets one guess at the password If an adversary Passively observes the client and the server talking to each other running this protocol then the adversary should get no information about the password and All of this should hold even if the adversary learns Some information derived from the session key Or the session key itself So let to illustrate like what are the issues involved here? Let me just Go through a couple of simple examples by way of background and this is more for people who really haven't looked at this problem very much before Here's a simple protocol. That's not a very good protocol. I'll call it spake zero simple peak zero So client server have a shared password pi and they just exchange random nonces x and y And then they compute their session key as a hash of the password their identities and the two random nonces and The idea is that, you know, this should at least we're not sending the password in the clear here But the problem with this is that an eavesdropper Even though he can't see the password directly from the protocol. He can still mount What's called an offline dictionary attack and understand how an offline dictionary attack works? suppose that the adversary watches The parties exchange x and y so he knows those two values and say that then after the session key K is established One of the two parties sends out a message M along with a Mac a message authentication code applied to that message using the secret key K and the adversary learns this Mac and say The adversary just knows this message as well So the adversary knows all of these things he knows M He knows T the the value of the Mac And what the adversary can then do is try a whole bunch of passwords pi prime coming from some dictionary of likely passwords and test whether or not when you plug in well, when you plug in that password into the hash function and get a Test value for the session key and then plug that test value for the session key into the Mac algorithm Do you get the tag that you saw right? So this is really bad if you know these Passwords of course can be somewhat weak and I thought be that difficult for the adversary to run through, you know a few million or even a few billion passwords to Figure out what the user's password is just by eavesdropping on a session like this. So this protocol isn't very good. Here's a protocol that Tries to improve things a little bit. I'll call it protocol simple pick one This uses some elements of Diffie-Hellman key exchange. There's no public keys here So each party generates an ephemeral Diffie-Hellman key. So the P here generates you as G to the alpha Q generates V as G to the beta they exchange group elements U and V and then they each compute the the Diffie-Hellman key G to the alpha beta so Q computes that as U to the beta and P computes G to the alpha beta as V to the alpha and then they dump all of this information into the hash function U, V, and W and And that's their session key What you can prove about a protocol like this is that under the Computational Diffie-Hellman assumption and modeling the hash function as a random oracle you can prove that an eavesdropper Can't mount an offline dictionary attack of the type that we saw on the previous slide. However an Active adversary who plays the role of either P or Q can still mount an offline dictionary attack So for example the attacker can run the protocol as Q against an honest P So he just runs right this protocol knowing beta and so he can compute W and he just makes a stab at the password pi just like before and Once the protocol gets to this step, right? And then if the attacker can okay for this attack to work the following has to happen The attacker runs the protocols Q and then he hopes that P is going to send out a Tag like this a Mac value like this and then if P makes that first move Then the attacker can again carry out an offline dictionary attack because he knows all the inputs to the hash function Except the password and so he can just do that kind of dictionary attack like in the first protocol so this is better than the first protocol since You the adversary has to actively engage one of the parties But it only has to engage the party once and then once it does that it can do an offline dictionary attack So here's a protocol Called S peak 2 which is actually from of dollar and point of all in 2005 And it's a very simple and elegant protocol That does provide Security against offline dictionary attack. So I've highlighted in blue here the things that are different from The protocol in the previous slide. So basically what this protocol does is well, it makes use of two random group elements that are kind of Posted as public parameters for all to use and it's assumed that nobody knows the discrete log of these two random group elements Then the two parties what they do is well party P here kind of masks the first group element with a to the pi and party Q here masks its group element by multiplying by B to the password pi and then When it comes to the next step, they both kind of unmask the the values they receive from the other party Here and here and then they do the same thing so this extra bit of masking and Unmasking is the only difference between the two protocols and what of dollar and points of all proved was that Under the CDH assumption and modeling H as a random oracle There are actually no offline dictionary attacks And again, there are still online dictionary attacks, but these can't be avoided right a party can still run the protocol once The adversary can still run the protocol once And make one guess at the password. So those can never really be avoided So one limitation of this protocol is symmetry in a typical scenario Where you might use a protocol protocol like this the client memorizes the password pi and the server Is going to have to store pi in a password file, right? And so if the password file is compromised Then All passwords for all users are immediately compromised right so this is very bad in fact, it's even kind of this this kind of If this kind of password file compromise leads to even worse results Then in the traditional protocol where the server just stores a hash of the password plus himself here we've improved security in one sense by By You know not requiring a PKI and avoiding phishing attacks, but we've made security worse by Making, you know a password file compromise lead to much more catastrophic results than in the traditional Password protocol so To try to improve this situation people have studied this notion of asymmetric PAKE and This has been around for a while one of the early papers on this that has had a lot of influences this paper by Gentry McKenzie and Ramzan from 2006 and it it basically defines a notion of security whereby you do provide a Protection against password file compromise and more precisely the notion of security introduced there says that Essentially in order to impersonate a client to a server The attacker must carry out an offline dictionary attack even if the password file is compromised So think about what happens when a password file on the server gets compromised now the attacker knows everything in the Password file so that adversary can now play the role of the server to an unsuspecting client That you can't prevent because now the attacker knows everything at the server knows But we should still hope that even after the adversary obtains the password file That there's still some security left in the system and and that security says that the security property We want is that now that the adversary has the password file. He still has to perform an offline dictionary attack in order to Break the system So This here's a protocol that just embellishes S-PAKE to slightly I call it S-PAKE to plus This is in a paper that I published with cash and kilt in 2008 and also Appeared in my textbook with Dan Bonnet in a preliminary version that's been available online for quite a while And it's very similar to the to the first to S-PAKE to the main difference is that Now We take the password pi and we run it through a hash function f and that generates two exponents Phi zero and phi one the server is only going to store phi zero and instead of storing phi one He just he just stores the group element C Which is g raised to the power phi one Okay, so this is what the server is going to store He doesn't store the password and it doesn't store the output of this hash function He stores this Transformation of the output of the hash function the client of course is going to know phi zero phi one because well if it's a human client They'll know the password the hash the password to get phi zero phi one now What happens is in the protocol the differences is first of all we're going to use phi zero here in place of the password In all the places we did before And in it so that's one change in addition Where we're going to use phi one is as follows The client is going to compute in addition to the group elements UVW that they computed before it's going to compute an additional group element D Which is going to be basically The same as W but instead of computing w here we could raise this group element to the power Alpha we we raise this Same group element to the power phi one the server is going to compute the same group element by taking C Which is in its password file and raising that to the power beta and you can check that if the both parties follow the protocol Then these two group elements are the same So this is the only difference and intuitively You know while the server Can compute this group element knowing C right and Beta which the server chose itself the client really has to know phi one to be able to log into the server and the only way intuitively that the Client is going to know phi one is if he actually inputs The password into this hash function to get both outputs five zero and five one so this protocol is currently being standardized and In both of these sources it was claimed that this you know is a secure paid protocol And it provides resilience against password vial compromised, but nothing was ever proved One limitation of this protocol is that it's Subject to what's called a preprocessing attack, right? So here the problem is this for a given pair of users P and Q an attacker could pre-compute all Values of this hash function f on all Passwords pi prime coming from some dictionary and then if it pre-computs all of that data as soon as the Attacker obtains the password file information here. You can do a quick table look up to determine What is the right password, right? So even though the attacker still has to do an offline dictionary attack by computing, you know f for all these passwords He can take that pre-processed information and immediately upon Obtaining the password file get the user's password. So this this is a limitation. It's it's not as robust as we would like it More recently a stronger notion of asymmetric pake security was introduced by by Jerecki Kravchak and Jew in 2018 This also provides protection against pre-processing attacks But the difference is that in order to impersonate a client to the server The attacker must carry out an offline dictionary attack and that attack has to start only after the password file is compromised So that's the distinction but this is a limitation of spake 2 plus and We can't really say more about that, but I do want to But what I do want to do is focus on what we are able to prove on of this scheme It's definitely not secure in the stronger sense, but it is secure in the or in the original sense of asymmetric pake Introduced by Gentry McKenzie and Ramzan So what we the original goal of this work was to prove that under the computational Diffie-Hellman assumption and under the random oracle model for the hash functions that this is a secure Asymmetric pake, but to even prove a theorem like this. We have to talk about security models So there are two popular security models for for a pake One is what I'll call the BPR model just named after the inventors Bellari point you all in Rockaway from 2000 It's a game-based definition. It's actually very nice and fairly natural But the problem is there's no natural extension of this to asymmetric pake definition was originally crafted for a symmetric pake and There's no real nice extension of this definition to asymmetric pake The definition that's another model for security is the so-called universal composability model. This is simulation based and The UC model goes back a bit further, but it was applied originally to the pake protocol to pake protocols in 2005 One nice thing about this approach is that it extends to asymmetric pake This is what was done in the Gentry McKenzie and Ramzan paper But so this is the actually the the model that we want to look at here, but unfortunately S-paked to is not even secure in the symmetric variant of the UC model. So That's bad news and for the same reason S-paked to plus can't be secure in the asymmetric UC model I'll talk a little bit more about that later The main results of this work are to Define a new protocol which I call Casey S-paked to plus and this is basically just S-paked to plus together with Some straightforward key confirmation just vanilla key confirmation adding a couple extra flows to the protocol to do key confirmation and Then once we do that once we add key confirmation then indeed we can prove that this new protocol Spake S-paked to plus with key confirmation is a secure asymmetric Pake protocol in the UC model assuming the computational Diffie-Hellman assumption and in the random oracle model Along the way, we also prove that Casey S-paked to so this is just basically the original S-paked to with key confirmation We also prove that that's a secure symmetric peak protocol in the UC model under the same assumptions We also look at a particular variant of of Casey S-paked to plus that's currently being standardized and prove that secure as an asymmetric pace and take in the UC model and we also Fix a few problems in the in the current Formulations of security in both the symmetric and asymmetric UC definitions of PAKE So quick review 30-second review of the UC framework you have the real world where you have a Environment interacting with various machines running the protocol You have an adversary that interacts with these machines and with the environment and when we're modeling a hash function as a random oracle The random oracle is kind of also down here And the adversary can can interact with the random oracle Directly although for technical reasons the environment can't interact with the random oracle directly And in the ideal world we just have a simulator Which is kind of just the the ideal world's version of the adversary interacting with some ideal functionality that kind of is a trusted third party that kind of does what the protocol is supposed to do and then the the protocol machines in the real world are kind of just replaced by Dummy machines that are just repeaters that basically forward all the inputs to the to the trusted third party and Forward outputs from the trusted third party back to the environment And security just means that for all adversaries there exists a simulator Such that for every environment that there's no way for the environment to distinguish computationally speaking The real world whether it's operating the environment can't tell whether it's operating in the real world Or in the ideal world to to So we we formulate security for Symmetric pick and I'm going to skip over all of this because I don't have time You can read the details in the paper And I'm going to have to finish up So what I do want to do is to talk about in the last two minutes that I have available Why is an s-paked to you see secure because I think that's kind of like the most important thing So I think I can prove a theorem although I haven't really done it that protocol s-paked to is not you see secure According to my definition or any others in the literature, but I haven't worked out the details of that whether or not it's a theorem is not so Important or more fundamentally. What's important is that? Any secure channels protocol that you might layer on top of s-paked to is not going to be you see secure either By the way in concurrent work. Another paper that came out Also made the same observation that s-paked to is not you see secure and they in fact show that s-paked to is is Is you see secure with respect to a weaker? Ideal functionality that they call lazy extraction security and I'll refer refer you to their paper To see the details of that but in a nutshell what what's wrong with s-paked to In the uc model without key confirmation, so suppose that we have a Server running with the the right password pi and we have an adversary Who's just trying to make a guess he's gonna run the protocol with a guess pi prime at the password In the role of the client so he sends to the server. He just runs the protocol with this pi prime and And he sends this group element to the server the server responds With with this group element v computed in this way just like in the ordinary protocol then suppose what happens next? Server computes the third group element w Dumps it all into a hash function to get the session key and now say q starts encrypting Messages using the session key okay The problem is the simulator must immediately decide whether or not this key k is a fresh key or as a spoiled key meaning fresh means that His guess at the password who's incorrect and spoiled means His guess at the password was Correct Mean and that means and if his guess at the password is correct that of course means that the adversary now knows the session key So the question that the simulator has to answer at this point in time without knowing anything more is Whether or not to treat this session key as a is a secure session key or an insecure session key Because the simulator has to start simulating the the encrypted ciphertext above in some higher-level protocol and it's a later point in time much much later the adversary might come along and And Finish off the protocol get his session key and then and only then will the simulator now Be able to see what the adversaries guess at the password was because he's going to input it into this hash function and now the simulator can test whether or not Pi prime equals the adversaries guess at the password is equal to the right value of the password So it seems like kind of a technical point, but it's actually an important technical point which tells us that to achieve any Meaningful and useful notion of you see security for a peak protocol For a protocol like as picked to we have to add key confirmation flows to it So I invite you to see the details of the of the paper for more information about the details of the protocols The details of the security definitions, which I think are also interesting as they do Clean up some problems in previous work and then the proofs of security themselves, which I think are interesting So that's it. I'm out of time. Thank you very much