 Okay, so actually our work started with a very basic question, namely how can a user securely store and of course also retrieve his private personal data if we don't want to assume that he has trusted user storage. So we don't want to make the assumption that he has a particular hardware device that is always available and always secure. And then probably a straightforward solution is to say, okay, let's simply encrypt the data and put it to the cloud. Then we have the nice availability from the cloud and the security from the encryption scheme. So that's certainly a good start, but what we have actually only done is to reduce the problem of how to secure our entire personal data to how to secure the decryption key. Because the disadvantage of such a key is that user can't memorize it. So it still has to put the key on some hardware device and we have to assume that the hardware device is available and trusted and that was exactly the assumption that we tried to avoid. But the good thing is now we only have to securely store some fixed secret and then we can actually play a nice tool called secret sharing. So all we can do is to kind of secret share the decryption key over end service. As you know, secret sharing works like you provide end shares in a way that if you later on retrieve at least T plus one of those shares, you can securely reconstruct the key key. And thereby T plus one is really the lower bound. So if an adversary has at most T shares, you can actually not learn anything about the shared key key. So that looks like a good solution how to store the key key because we don't have to rely anymore that we have a particular hardware device that we can trust. But we actually are not fully done yet because what is quite crucial for our problem we want to solve is that only the right user you can retrieve the keys. Because if everyone goes to the service and retrieve my secret key, I wouldn't be happy with the solution. So we still have to solve is kind of how can we actually ensure that only the right user gets those shares? And of course we can assume that the user has some sort of an authentication key but then we basically go back to the problem that we want to solve. Namely, how can we actually store that particular key we want to use to authenticate with those servers? So what we really want to have is that we would kind of bootstrap the entire service. We want to make the user authenticate with the service in a way that the only thing he needs is something that he can memorize. And then we don't have a lot of options but basically we have to rely on passwords and human memorizable passwords. And that is basically what the password authenticated secret sharing is about. So here you don't only share a secret key K with end service but you also protect it somehow with the password P. So you also send some password shares to those servers. And this is done in a way that if you later on want to retrieve the key K you also have to provide password P prime. And the servers then verify whether the password P prime actually matches the password P that the user has used in the setup. And only if that is the case the user can end up with reconstructing a strong secret key. So that looks like a kind of very useful primitive but maybe some of you might kind of wonder whether relying or basing security on passwords is nowadays really a good idea because we have seen so many security incidents lately where we have the feeling like every week or months some major security incident happens where some service provider get hacked and loses millions of user passwords. But the good news is actually that passwords aren't that bad. They're just often used in a bad way because what happens is that usually passwords are stored in a hashed form which allows a single part of the server to verify whether the password P prime matches P. And the problem is if you have a single piece of information that allows you to verify whether a password is correct or not then as soon as you lose the information or it's stolen by an adversary then also the adversary can use it to make guesses of the password and verify whether it's correct or not. And given the low entropy that passwords usually have and the efficiency of those computations you can actually make hundred of million guesses if a password is correct or not and then for the average password that means it's broken in really short time. But if you can avoid having such a single piece of information and basically shared of several servers then passwords provide really good security. And the good thing is we're already in a multi-service setting and we're having something like secret sharing. So what password authenticated secret sharing does is basically also adopts the idea of secret sharing through the password. So you not only need T plus one shares to reconstruct K but also to verify whether P prime equals P. And that means if you have at most T servers which are corrupt then they not only learn anything about K but they also can't offline attack P because if at most T servers are corrupt and you need T plus one to verify you have always at least one on a server in the verification. And what an on a server will do is if it has seen that someone tries to log into your account 10 or 100 times and say okay something's going on here something is fishy I'll just block the account or I provide a capture or I send you an unblocked via mobile phone. So basically the on a server in the verification set will mimic the behavior we know from bank cards which will also block if we type in our pins three times in the wrong way. So that we have an even weaker secret but it somehow works because we have some trusted authority and that's kind of the on a server in here that will block such a guessing attempt if it's a thing something bad is happening. Okay so that's looks for our application that we want to solve like the perfect tool to start with. And the good news is also that there are already solutions for that out there. So this concept on the protocol was proposed by Bagasan Yadal at CCS 2011 who have a tiered event secret sharing scheme and here later a one out of two secret sharing scheme with improved efficiency and your CCQT was proposed by Kamid Yadal. But apparently we are not fully satisfied with those solutions yet. And the reason is that they actually not only require the user to store the password P prime or remember the password P prime but also to securely remember some of the service or at least he was one of the service he initially trusted it set up. And just to be sure it's so clear so the this is sat here does not have to be secret as the password but it has to be trusted. So the user is not allowed to make any typos or run into phishing attacks or actually ask someone to get reminded about who trusts it initially because what happens if somehow the user is lured into trying to retrieve his password from T plus one bad service and those are T plus one bad service he never initially trusted so they were not in the set up place because they're really, really bad then they will actually learn the password 10 P prime. And that now is really bad because we said we want to base our anti-security only on that password. So if we somehow get tricked into trying to run the protocol with bad service they learn our only secret we still had and course can now go to the good service get my secret and also give me actually any other key K and convince me that this was my memory. So we thought this is actually kind of a bad attack or let's say a strong assumption that we still have some trusted user storage where we can trust that this set S prime by is not altered with. And our work basically is about trying to avoid this assumption trying to avoid this type of attack. So in other words we want to build a threshold event password authenticated secret sharing scheme where the user really only has to remember a username and password and doesn't have any need of personalized trusted user storage anymore. Also means that we don't have these attack I just showed on the last slide. And we formally define what we mean or what security guarantees we aim for in terms of ideal functionality in the UC framework. And here we went for the UC framework as we thought that for password based protocols that actually offers a very nice modeling or much more nicer modeling than property based definitions. Because what you have in UC is that the environment always provides the inputs to the honest parties and those are the password and the password attempt. So we don't make and you see any assumptions on how passwords are distributed or chosen from. Whereas in a property based definitions you have somehow to define the distribution of passwords. I mean probably it's not random but you can define some dictionary and then it's chosen at random from the distribution. Also meaning that if we have two different protocols it's assumed that they are chosen independently from those distributions which is often not true because I for instance or people often reuse passwords or parts of passwords for different services. So this is actually really hard to capture in a property based definition whereas in UC it basically it's abstracted away by the environment providing that as input. I was also very nice with UC that provides very nice composition guarantees if you wanna combine it with other protocols which is of course of particular importance for our protocol as we want to reconstruct a strong key K that we wanted to use for other protocols for instance to decrypt the data that we have uploaded to the cloud. Okay now we'll of course not go through the details of the idea functionality but just present the security guarantees we were aiming for. So in our T pass definition or scheme of course the user shares a secret key K a secret K with N servers protected by a password P such that if he was somewhat lucky and has chosen servers from which at most T are corrupt then the adversaries does not learn anything about the password or the key K. And for the retrieval we then say that the user runs retrieval with now exactly T plus one service so we make that a limitation to make the idea functionality a bit more simpler. He provides a password P prime and then runs it with T plus one service. And here it's important that the adversaries will only learn whether P equals P prime if all the service that the user has chosen really wanna cooperate in the verification. So here again the throttling comes in and on a server will at some point not want to contribute anymore if it thinks that there's actually an attack going on on the account. And if the user is somehow unlucky and has come up with a set S prime bar which contains only bad service then the adversaries as I said before does not learn the P prime anymore but he only gets a single password gas against P prime. So he basically can provide a P and he will learn the evaluation of that function. But again it does not learn the password P prime. And what is also important is that the adversary cannot set up the user with the wrong key K star which comes with this claim that it can happen if actually the user tries to retrieve the password from T plus one bad service. And those bad service manage to guess directly the password P prime the user wants to authenticate with. But again here now the guessing is only he has a single gas against the password the user wants to use and cannot repeatedly try. So if my password is somewhat reasonable hopefully the adversary cannot guess it in one or two attempts. Okay so that's the security that we want to achieve. And of course we also have a protocol that realizes that. And the idea for our protocol is actually quite similar as the protocol idea of Bacchazzania DAO. But we had to make a couple of twists to remove that need of trusted user storage. And also add quite some proof through randomizations et cetera to make the protocol you see secure because the original protocol by Bacchazzania DAO was proven secure with respect to property-based definition. And the main building block we have is a tiered event threshold homomorphic encryption scheme and has the following algorithms at a key generation that now outputs one public key and secret key shares. An encryption algorithm that is quite similar takes public key message and outputs a ciphertext and to the decryption algorithm. A partial one that takes a secret key share a ciphertext and outputs a decryption share and a threshold decryption algorithm that takes at least t plus one decryption shares and a ciphertext and outputs a message. So from that we will get our threshold property from and we also need some homomorphic property of that encryption scheme. Meaning that if we have two ciphertexts C1 and C2 being encryptions of M1 and M2 we can apply some homomorphic operation on those ciphertexts that will translate down to an operation on the underlying plaintext. Okay, then let's have a look at the high level idea of our protocol. So what happens at setup when the user wants to share his secret, he first generates fresh keys of such an encryption scheme and then encrypts his password and his key K under the public key just generated. And then he distributes the information by sending his username, the two ciphertexts he just created, the public key, one secret key share per server and the set of servers he has chosen to each server. And if the servers don't have an account for the UID they simply store the information. And what we also assume here is that servers actually have certified public keys. Because we want of course to communicate those shares securely but to emphasize if server have a public key doesn't mean they are trusted it just means we can actually securely communicate with them but also bad servers actually can have trusted public keys. And what we then get from the setup phase is that if at most key servers here are corrupt then we will have that by the semantic security of the threshold encryption scheme that the adversary doesn't learn anything about the password and key K because we have distributed them only in encrypted form. And then for the retrieval the user only remembers his username and password and somehow can now comes up with a set of people's one service. So he might go on the street and ask the first person who is the server that you trust or he types it in in his favorite search engine. So he still has to somehow of course come up with a number or name of servers he wants to run the protocol with because he wants to run the protocol with him but it's important that this information doesn't have to be trusted anymore he can just try out something and hope it was a correct one. And what he then does he asks those servers to remind him basically on a state from the setup and he does so by sending his username and the set of servers he wants to run the retrieval with and then each server simply checks if they have an account for that username and if so if the set of servers the user now wants to run the protocol with is actually a valid subset of servers that he specified in the setup and also the check that the account isn't blocked so he again the throttling comes in so on a server at some point will simply refuse to cooperate if too many failed login attempts already happened. But everything is fine then the servers respond with it to cipher text and a public key and the user then checks that of course he gets kind of consistency of the same information from all the servers and only continues if that is indeed the case. And what happens next is he takes the cipher text CP that the servers claim to contain an encryption of his password on the PK and computes a randomized password quotient. So he takes the password attempt he's now trying to log in on P prime computes one over and encrypts one over P prime with the public key he also received applies a more fake operation on the results in CP and also adds some random exponent to it and that cipher text CTAS then sends to all the different servers. And the servers now applied a secret share they have and yeah decrypt or properly decrypt that's the cipher text and send it back to the user. And the user now verifies whether the threshold decryption so combining all the different decryption shares actually yields to the value one because what we have done here with that cipher text is we have created an encryption of one if the password attempt P prime matches the password P that was claimed to be in the cipher text CP or we have created an encryption of a random value in case the password actually did not match. And the letter is quite important because it means that even if all the T plus one servers are corrupt and provided a wrong cipher text CP star where they actually know the underlying P star from and PK star they do not learn P prime from the cipher text they also only learn whether it matches P star or not by getting either also one or random values output. Okay and that is actually kind of the main trick of our reconstruction that we have to get the security that our password attempt P prime is still secure if you try to authenticate with really bad service. And the next step is because we still of course want to retrieve our strong secret K is that the user distributes all the decryption shares of that cipher text C test to all the servers the servers and verify also if the password actually matched and if that was the case they compute the decryption share of CK again applying the secret key share and responded back to the user and finally the user can reconstruct a strong key K by applying the threshold decryption algorithm again. And of course this is always only the high level idea of the protocol because what is of course quite important in this step is that the decryption shares must be communicated securely to the user. So the user also generates a fresh encryption key at the beginning of the protocol and everything is then bound also to the public key and also all the decryption the partial decryption comes with a proof of correctness so that the user cannot be set up with a wrong key. Okay and that's basically the high level idea of the protocol and again the concrete steps are of course a bit more complicated. And we prove then this protocol to securely realize our ideal functionality based on or having a threshold homomorphic encryption scheme that is semantically secure. We also need to further encryption schemes one needs to be CPA secure another one CCA secure one is for all the encryption to the sky we need for the UC security the CCA tool one is needed to securely communicate the decryption or a secret key shares we need a signature scheme that is existentially unforgeable to let the server always assign their messages and the user can be sure that information is correct. A simulation sounds your knowledge proof system because whenever we actually re-vendomize something or encrypt something it has to come with a proof of correctness and we also make the proof in a hybrid model where we assume that we have a CRS and a CIA. But again, having our service having public keys doesn't mean that they're per definition trusted. So to sum up we have proposed a special tier of password authenticated secret sharing scheme where the user now can really store and reconstruct a strong secret key based only on the username and password and we don't have to rely on any trusted user storage anymore because even if he runs into bad servers they will not learn his password at 10 P prime. And everything is proven secure in the UC framework so it actually comes with nice composability guarantees. Okay, and that's it. Thank you.