 Okay, welcome back, everybody. We have two talks in this mini session on secure messaging, and the first talk will be given by John Millican from Facebook, and he's going to tell us about end-to-end encryption for Messenger. Thank you, John. Thanks, Kenny. So, hello, everyone. My name is John Millican, and I'm a software engineer on Facebook's Messenger privacy team. So I'm going to talk to you today about our long-term plan to fully encrypt Messenger end-to-end, and primarily about how we're thinking about this and some of the challenges involved. I'll be honest right now and say that we're still in a place of having more questions than answers. While we have made progress in our planning, it turns out that adding end-to-end encryption into an existing complex system is incredibly challenging and involves fundamentally rethinking almost everything. So I'm not here today to tell you exactly what we're going to do. We've done a lot of thinking about this topic, and I'll be sharing some of it, but we're really starting out on a consultation process here. I'll really be focusing on the reasoning, goals, and real-world process and challenges of transforming a live system with well over a billion users into something that can run essentially via an opaque encrypted pipe. And let's start by addressing why we're doing this, and this boils down to three major points. First is simply that people deserve good security. It's undeniable that every major online service has security issues, and I imagine many people would give good odds that any service without public security issues simply hasn't found them yet. And I'd also note that the more data you have, the bigger a target you become. So over time, as more and more data are masses within major platforms, more effort is likely to be put into attacking them. In this world, who wouldn't want multiple layers of defense? And while we do already practice defense in depth, especially for messaging data, what better defense can we really add than not even having the data available to us in the first place, apart from, of course, making it impossible for us to even choose to get? And I'd be remiss not to highlight the importance of strong security for national security. The U.S. Department of Defense has recently stated, they believe, maintaining a domestic climate for state-of-the-art security and encryption is critical to the protection of our national security. And the second point, unsurprisingly, is that privacy is a fundamental human right. Usually this is considered to mean privacy from governments, but we believe that privacy of sensitive communications from companies is also really important. And to an encryption may fundamentally be a security technology, but it enables this sort of strong privacy. There are instances where service-side access to data is necessary to provide a service, so I'm not saying that perfect privacy and security should necessarily be blockers for the existence or usage of an otherwise useful service. However, we believe that messaging need not be one such service. Indeed, we already operate two messaging services, WhatsApp and Messenger's secret conversations that use the signal protocol to fully end to encrypt their data, such that Facebook has no access to the plain text data. And so the conclusion we've reached here is that we should aim to end to end encrypt our messaging services. This would encrypt data such that only the specific endpoint devices could read the contents of communications, strengthening the security of data while providing privacy from Facebook ourselves. So with that said, what's Facebook's vision here? Well, in March last year, Mark Zuckerberg announced his new vision for privacy-focused social networking. This, frankly, took a lot of people by surprise as it focused on seven main principles that people have tended not to associate with Facebook. These were private interactions, encryption, reducing permanence, safety, interoperability, and secure data storage. All principles that I imagine people in this room would tend to support, but I'm here today to really talk about these top two, private interactions and encryption. While Facebook has traditionally focused on providing a virtual town square through social networking products, what we really want from Messenger is to provide a virtual living room. That is a small intimate space where you can communicate in confidence with those closest to you and in the knowledge that nobody else is watching or listening. Now, the small intimate space is already roughly the product model that messaging apps offer, but encryption can serve to provide this guarantee of confidentiality. And as I said, we believe that this is desirable for all messaging on our services, not just WhatsApp and Messenger secret conversations. So that's the vision, but where are we with end-to-end encryption in Messenger today? Well, at Real World Crypto 2017, almost exactly three years, standing broadly in exactly this spot, I spoke about secret conversations, our existing E2E product. And in this talk, I discussed a lot of the reasons why at the time we didn't feel that E2E encryption was a realistic goal for Messenger as a whole. So what did we have at this point? Well, for starters, secret conversations were opt-in, with the vast majority of Messenger users not using them. Messenger is incredibly feature-rich, but many of these features are challenging to build without significant server-side support. So for secret conversations, the feature set that we provided was pretty limited. We had text, photos, stickers, and ephemerality. But I think that was pretty much it, and only for one-to-one chats, so no groups. Furthermore, it only worked on our main Android and iOS apps. And for any given account, we only supported one device at a time, meaning that most people who got new phones simply didn't have it enabled because it was already enabled on their old one. Although any secret conversations that they were having wouldn't have been transferred over to the new device anyway, so as there was no mechanism for transfer and conversation history. So since then, we have made some progress. It's otherwise broadly a pretty similar product there. So probably the most significant change was adding support for multiple devices on an account, meaning that people with multiple phones or those who got a new phone could use secret conversations much more similarly to how they use regular messenger. But we also did add a few more features, such as sending videos and audio clips. We also started to find ways to develop it a little more like how we develop regular Facebook products. So with some basic metrics that we collected about categorical data, and we did this using local differential privacy, and a fair bit of work to make the product just work better and be a more reliable messaging experience. But otherwise, as I said, it's broadly a pretty similar product to what it was. And most notably, we still don't have group chats, and there's still no means to transfer and message history between devices. So that's where we're starting from on the E2E encryption side for Messenger. Now let's look at how we're approaching the task of overcoming and mitigating the many challenges so that we can expand this to the whole product. Well, primarily, having strong end-to-end privacy guarantees is one of our key goals. We're not just adding end-to-end encryption to a product. We're building an end-to-end encrypted product. So for starters, that means we cannot have any access to message contents ever, unless these have been explicitly, willingly, and knowingly shared with us, for example, when abusive behavior is reported. Engineering-wise, we're investing in security and privacy by design, aiming to significantly reduce the likelihood of privacy and security bugs occurring. Method data collection is often the elephant in the room when it comes to end-to-end encryption. Indeed, at my last real-world crypto talk, I think one of the questions afterwards did focus on this as something which was explicitly not covered by or protected by E2E. But nonetheless, as we're improving the privacy of Messenger, our goal is to also improve on the metadata that we have available. WhatsApp, for example, takes a very principled position of minimizing collection of metadata. And we intend to take this approach for Messenger. And finally, while we do have significant expertise in the company, and we're spending a lot of time on getting this right, we do intend to gather external perspectives on what we're building. Because frankly, this isn't easy, and there are many more viewpoints and use cases than exist just within Facebook. So let's dig into this first point of what I meant by having no access to message content. So by definition, we won't have access to messages in transit. That's end-to-end encryption. But to provide end-to-end security, we also must ensure that message content cannot reach us in any other way. So some examples of avenues that we'll have to block and be concerned about are messages being logged, particularly in crash reports, which are particularly challenging case because frequently the best way to fix issues that are affecting people in the real world is to have a good idea of what's going on when app crashes do occur. We'll also need to make sure that there's no way for Facebook to remotely pull the contents of messages from our own apps. And also that the apps enforce that no device can receive any message unless that device has been verified by the sender. Or, sorry, can be verified by the sender. And to preempt a likely concern on this point, I'd call out that I don't just mean the precise message content here, but we're also talking about any data derived from message contents. The next point in our approach was security by design. And aside from it being a generally good principle, why is it particularly important for Messenger now? Well, we're a large, multi-disciplinary organization building a complex and feature-rich product across a number of platforms. Getting security right is a scaling challenge because even if everyone were an expert in security and cryptography, more engineers writing more code just provides more opportunities for bugs to be introduced. An effective way of scaling security to a large organization is to ensure that the building blocks that everybody works with are at the right level to provide blanket defenses. So this means having frameworks and APIs which are secured by defaults. And by doing this, we aim to make the easiest way to build a feature, the secure way to build it. And naturally, we want everyone to be privacy conscious all of the time, but if we were to rely only on expertise to get security right, we wouldn't really be practicing defense in depth or security by design within our own engineering practices. So for example, we don't want to rely on everyone having a good understanding of the signal protocol or exactly how we use it. Instead, if somebody needs to transmit data from one user to another within one of our features, we'd much rather provide an API that will do this for them and abstract away the transmission and encryption. And one particular call out I'd make on security by design for E2E encryption is that we're looking to push as much as we can onto the client. This is actually a pretty big departure from how Messenger works today. The vast majority of our features use the server as an active component in how they work. It isn't just moving plain text from one device to another. It actually contains product logic. So we'll need to significantly re-engineer the vast majority of Messenger features to work primarily on the client. But nonetheless, we think that this is the most realistic secure design for end-to-end encryption. And this means that we'll end up with the server being pretty much a dumb router. The next aspect of our approach was consulting with external stakeholders. Now, research is always an important aspect of product development and iteration. It's the best way to make sure that we're providing the best tools for our users. But what we did differently this time was to publicly announce the plan years in advance of being able to actually ship it. And this is because we're conscious of the broad implications of E2E encryption and the wide scope of design challenges that we'll need to address. With these in mind, we wanted to collaborate early with global stakeholders and listen to experts from a wide range of areas such as industry, civil society, activist groups, academia, and of course, attendees of cryptography conferences. And finally, I called out limiting metadata collection and storage as a goal. But how do we actually want to approach this technically? Well, we're looking into how security by design can be applied here. And there are a couple of points that I'd like to talk about on this front. The first is that privacy-preserving techniques are non-frivial to use at the moment. And so if we're going to ask engineers to be applying them, it makes a lot of sense to simplify this. So for example, building logging tooling that allows them to use local differential privacy more easily. But we're investigating at the moment how we can more systematically reduce sensitive data logging and storage by building this into logging frameworks. So the hope is, for example, that we might be able to automatically enforce policies that we define on data, or perhaps detect that certain data is no longer being used and automatically drop it. Or even potentially examine the queries that are being run to find opportunities under the hood to aggregate or anonymize datasets. So the goal here is to pretty much rethink our approach to data collection, storage, access, and usage, so that we're going beyond only collecting data that we use and actually automatically minimizing it too. So that's the approach that we're planning to take to the problem sort of at a high level. Let's now look at some specific challenges that we've been thinking about. I imagine this first example won't surprise anyone. Preserving message history when changing devices is something that we know people want. Indeed, it's a big value add for messenger at the moment. However, this is all data that Facebook cannot have access to in an E2E encrypted world, and therefore cannot be in a position to just give directly to the user when they log into a new device. Therefore, providing message history to a new device necessitates that there is some piece of information that Facebook does not have access to, be that the data itself or perhaps an encryption key. In this space, there are some previous examples of storing data on cloud providers. For example, WhatsApp will back messages up to iCloud or Google Drive, but we're not actually convinced that this approach suffices for messenger. One issue with this is that messenger is inherently multi-device and multi-platform. So for example, I use messenger independently across web, iOS, and Android, all from the same account. But there is no cloud storage provider that is easily and widely usable across all of these platforms. So one question we were wondering about is whether we should allow users to back their messages up, data up to Facebook, given that we can guarantee this data will be available to any client that we build. Although naturally, if we were to take this approach, we would have to encrypt the content so that it remains inaccessible to us. The next challenge we were looking at, which I also highlighted last time I spoke here, is that of supporting web clients. This is especially important to us as web access is another big value proposition for messenger. But web presents a number of significant challenges for building end-to-end encrypted apps. So we've been thinking about a number of questions in this space. For example, should we still actually support web clients as standalone? Or should we be looking more to the tethered approach that WhatsApp has taken? And should web chat be automatically available on Facebook.com as it is today? Or should people have to explicitly opt in to use chat on web? Then if people do use messenger in web, would it benefit them to be notified about the differences they are opting into compared against mobile devices, sorry? Or would this not be broadly useful to people? And indeed, regarding the code distribution model on web, could it be improved by developing binary transparency to ensure that everybody is running the same code? Indeed, is this even a viable technology for browser vendors to build and ship? And a more recent challenge has been in how notifications work. Given that secret conversations are aimed not to keep a permanent record of pair-wise threads, as we didn't have a technical reason why storing this should be necessary. Notifications, however, do rely on thread-specific behavior. For example, badge counts that are displayed by icons on iOS are calculated based on the number of unread threads. And muting a thread relies on suppressing notifications based on the sender of a message. So previously for secret conversations, we calculated badge counts and we handled muting of threads client-side instead of storing this data on the server. But we are starting to see new constraints from mobile platforms requiring that we can control these behaviors from the server and thus requiring that we store sufficient data on the server to be able to do these sorts of controls. And therefore, it involves having a bit more metadata about threads stored. So the approach that we've taken so far in secret conversations is to store as little data as we think that we can and format it so that only certain queries can easily be run. So for example, you could easily query if I have muted Kenny, but not for everybody who has muted him. But is this as good as we can do? Is it possible to improve on this? So that's just a few of the challenges that we've been looking at as we investigate fully end-to-end encrypted messenger. I'd now like to just wrap up with a few conclusions. First, I'd particularly stress the complexity of migrating a product like messenger to be fully end-to-end encrypted. What's up took years to migrate despite being a significantly simpler challenge than messenger in a number of ways. So when people ask, why can't you just with respect to end-to-end encryption on messenger? Quite frankly, it almost never applies because the challenge is much more complicated than they're imagining. Fundamentally, we're not just looking at a transport layer change for messages, but rather we're looking at a full stack rethink and re-architecture of the entire product. Next, I'd stress that we build for people first and building for people at scale means working within real world constraints. For example, those introduced by the variety of operating systems, platforms, distribution channels, et cetera, that our software has to run on. And remember that our goal here is to deploy end-to-end encryption to the communications of billions of people. And to do so, we still have to design our product to be usable by billions of people. And to wrap up, let me just say, we are going to ship this. It's going to take time to build and to make sure that we're doing it right. But nonetheless, this is happening. We are going to end-to-end encrypted messenger. Thank you very much. And do we have time for a couple of questions? Certainly do, and there are people at the mics. Great. All right, thanks for the great talk. What roadmap is there for social graph being put all the way onto the client and being completely off of the server? Great question. I don't think we have anything to share on that at the moment. Hi, thank you for the talk. Does Facebook have any plans to address the sort of threat model where the server pretends that I have a new phone when it's not really my phone? So secret conversations at the moment, whenever a device is added to a thread, will surface that to both parties in that thread. So it is visible and you can go and verify the keys in that thread. Thank you. Further to that, could you say any more about the key verification or key transparency or in general how people know that the keys that you're telling them are the right ones? So the approach we use today is the approach which is common across most encrypted messaging apps, which is allowing people to manually verify keys. We have slightly different approaches to this in WhatsApp and secret conversations, but they boil down to essentially the same approach. We're certainly tracking developments in this space, but to the best of my knowledge, no developments have been deployed sort of at scale yet. Oh, great, yeah. Hi, great talk. Thank you. I remember two years ago, I think the original decision was that Facebook, it was too difficult and I'm glad to see that it's come this way. My question is, does Facebook have an intent on marketing secret conversations and getting people to care about end-to-end encrypted messaging and explaining why that they should use Facebook's encrypted messenger over non-encrypted messengers and sort of making the default and actually having them care about it? Is there any way that you could explain the threat model to those people in terms that they would understand and care about? So I think you really hit the nail on the head when you said about making this the default. The ideal situation really is that people don't need to know and care about this to nonetheless get that level of security. And so that's what we've already done with WhatsApp and what we're hoping to do with Messenger. Right, and I think that's great, but my concern is like there are people who still, for example, domestic abusers who will steal their partner's Facebook accounts or gain access to it and they hijack the things that they read and see. So I'm curious exactly how the Facebook Messenger threat model it kind of intends to have that because obviously there's signal and things, but not many people use signals, they do Facebook Messenger. And I'm just concerned about those people and how the threat model will be adjusted for them. So one thing that I can share about what we do in secret conversations is regarding account switching on a device. So if, for example, you do log out of Messenger, all of your secret conversations will be inaccessible because they are encrypted. Besides that, we're certainly investing in our privacy roadmap and trying to improve privacy in a number of ways, but I'm afraid I don't have a specific product ideas to share at the moment. Cool, thank you. Thank you. How do you handle coordinating keys between multiple different devices or clients? We treat every client as a separate endpoint. So for multi-device under the hood, it is a group chat between a series of devices with the Facebook user identity superimposed over that. Next. So I saw you had a slide where you were pointing to the current problems in badging, notifications, being able to turn. Is there sort of research that's needed on specific techniques to address these or is it more there's techniques out there but you need to figure out what the trade-offs are and then pick one? Very possibly a bit of both. We're very interested in learning more about what's possible in this space. Hi, I have two very quick questions. One, I realize that the number is very small but I'm wondering if you can share any more precise usage statistics about secret conversations to date. And second, I'd like to hear from you. I think I know the answer but I'd like to hear from you. How committed is your team to preserving forward secrecy in the final protocol? So regarding the first point, I don't have any statistics to share. I'm not sure I'd characterize it as very small but yeah, we don't have numbers to share. Regarding the encryption, we're aiming for the best security that we can achieve while building a usable product. At the moment, we're using signal protocol for this which provides forward secrecy and postcode for my security. So you think that there is a chance that the final protocol won't include forward secrecy? I mean you can never give a firm commitment but our current plans are not to move away from that. Thank you. Thank you. Thanks everybody for all the great questions. We're actually out of time there so let's thank John again for a really insightful talk. Thank you very much. Okay, we're just getting mic'd up here. There's still a clicker here so if somebody would like to come and claim their clicker or claim somebody else's clicker, more than welcome. Okay, great. So now we come to the second talk of the session about the IETF MLS effort and the talk will be given by Joe. Thanks Kenny. So hi, my name's Joel. I'm a cryptographer over at Wicker. I'm gonna tell you about a joint work with Sandro, Evgeny and Yanis. We've been looking at the MLS protocol and we wanna tell you about some thoughts on that and some results we have. So first, you know, let's get some context. What is MLS? Well, the goal is here to design a messaging protocol and to end secure for groups, right? And groups is kind of really the key point here. We wanna support really large groups. By large, you know, think 50,000 people, for example. This should be asynchronous messaging. So in other words, think things like SMS or email, you know, you just come online, you read your messages, you can send out whatever you want, you go offline, other people come on and they can read their stuff. Sessions, you know, we expect them to last really long, years sometimes, and group membership therefore is gonna be dynamic, right? During a session, people are gonna join and leave the group. So challenges here are really, I'd say, the biggest challenge, you know, is keeping bandwidth and complexity low. By low, I mean, think logarithmic and group size, not linear. And really, that's what's gonna differentiate MLS from pretty much everything that's out there right now. We also wanna do, you know, we want a rigorous analysis of the security here and we wanna use practical primitives. Who's doing this? Well, this is under the auspices of the IETF. So it's being designed by a work group also called MLS. And I'd say the guiding principle here is really to do for group messaging, what TLS did for, you know, secure communication synchronous stuff. This is a collaboration between academia, industry, we got more people joining all the time, and the final product is going to be a series of RFCs that define the different aspects, the architecture, the protocol itself, things like that. So let's look a little more at the security goals. Basically in a nutshell, we're talking end-to-end security, authenticity and privacy. The adversarial model here, at least for the purposes of this talk, is all right, end-to-end security, we're talking man in the middle, in particular also corrupt delivery service, right? We got a delivery service in order to get this asynchronous messaging. And in terms of corruption, we're looking at state leakage, right? So when you corrupt a client, what we give the adversary is the local state, including all the secret keys, entropy and everything. So that's the corruption model. We're talking about an active and adaptive adversary so we can online make decisions about what to do next. And because these sessions last so long, we are interested in security notions that talk about corruptions during the session, all right? So in other words, forward secrecy, post-compromised secrecy. By forward secrecy or forward security, I kind of switched between the two of it. I'm talking about, we want that today's communication will remain secure despite possible corruptions that happen in the future. And kind of the flip side of that is PCS, which says, well, if we do have a corruption during the session, then continued usage of the protocol will eventually revert us back to a secure state, right? So these are kind of becoming like the standard, the bar in secure messaging and end-to-end messaging. And we, you know, MLS wants to achieve that as well. One thing to keep in mind here is denial of service is kind of at least at the moment, it's really outside the scope. And in particular, if you have a completely adversarial network, it's not clear really what you're gonna do about it. Anyway, at least for this talk, and I think it's fair to say for MLS at the moment, that's kind of out of scope. There are other security notions that are being considered by MLS, things like metadata hiding, in particular from the delivery service, security against malicious insiders. That means like really, you know, you get malware on your phone and starts actively trying to screw with the protocol. And in the future, probably, you know, deniability is coming up as another notion. But for now for this talk, it's really end-to-end authenticity, privacy in particular, forward secrecy in PCS. So, all right, what is group messaging as a primitive? Well, it's, you know, we'll do the classic thing. It's a sequence, it's a series of algorithms. What can you do? Well, you can initiate a group. You can add someone to the group. You can remove someone from the group. You can do this thing called update, which essentially it's like refreshing your local state. And this is really where we're gonna be getting our PCS from. And of course, you can also send and receive messages, right? So the goal here is to have secure communication in this dynamic group using this interface. And you can break this interface into two parts. The control messages that sort of manage the group state, add people, remove people, refresh the group state. And then there's like the application part, which is just sending, receiving messages. And I'm really gonna focus in this talk on the control part, right? And we can isolate this and look at it as its own primitive. Kind of what, you know, key agreement to a secure channel. It's kind of the same like analogy here. And so, you know, we're looking at just init, add, remove, and update as the primitive. And we call this in our work, we call this continuous group key agreement, right? CGKA, and sort of the focus of our work has been on the CGKA primitive inside MLS. Yeah, we'll get to that. So the goal of CGKA is kind of to maintain a shared secret or really a continuous stream of constantly updated shared secrets between all the members of this dynamically changing group. And why is it okay to just isolate the CGKA as a primitive if we really care about MLS? Well, because there's this nice decomposition that one can do, that we've already seen in the two-party case. So for lack of a better term, I'm gonna call this the ACD paradigm after the paper where this was introduced. And what ACD did for the two-party case, in particular the double ratchet, is it modularizes and generalizes the double ratchet. So it modularizes it into three primitives, CKA, PRF, PRG, and sort of forward secure AAD. And it shows how you can compose these three things into get a secure messaging for the two-party case, right? So this is applied to the two-party case. And we realize that one can look at MLS through a very similar lens with sort of a group variant of the same kind of paradigm. So by the way, with the addition that we also need signatures, or at least MLS uses signatures, maybe there's ways to get around it without signatures. So one subtlety here, though, is that at least for the purposes of MLS at the moment, we do want these control messages, in other words, the CGKA messages to be delivered in order, or at least processed by all group members in order, right? And so we inherit this assumption in our work as well. And in particular, this is something that CGKA can therefore assume about the network. And yeah. All right, so by the way, relaxing this is great avenue for future work, right? It's not clear that this is necessary. But at the moment, this is what MLS does and assumes explicitly that there's this in order processing. So when we look at this paradigm, we see that, okay, if you've got CGKA, well, then you can use these other primitives to essentially build your entire messaging protocol, and it's very non-trivial how this works, but it's not that different in the group setting from the two-party setting. And we know how to do this thanks to signal in the two-party setting. Basically, we're gonna keep this entropy pool and seed a bunch of ratchets, basically. So in this work, that's not what we look at. We look at the CGKA part because that is really quite different than what's happening in the two-party case, this asymmetric double ratchet, asymmetric ratchet. So this CGKA part is really quite different. That's what we focus on. And again, just the CGKA, the point is to agree on a continuous sequence of fresh shared secrets. For the purpose of this talk, we're gonna forget about the dynamic part because everything we say is already non-trivial and relevant if you have a static group. So never mind about adding or removing people. We'll just think of a static group and updating, right? Yeah, so, all right. One thing that's nice about this modular construction is that it allows us to relax what we need from the network for the CGKA. In particular, we can assume authenticated channels. Why is that? Because we get the authentication from the wider construction, right? From the signatures and the AEAD, they're used in a clever way to basically enforce the authentication from the point of view of CGKA. So that's nice. That means that we get to make this assumption. So now, okay, let's look at what the adversary is for the CGKA. Well, he gets to drive the execution. What does that mean? Essentially, the adversary gets to instruct users at will to perform this update operation. And every time there's an update operation, this defines a new epoch, right? So this term epoch is kind of important. And the next thing the adversary gets to do is also decide to deliver messages, right? So tell, okay, user, you need to now process this next message. But reflecting this assumption about the ordering, one restriction on the adversary is they can only tell a user to process update for epoch J if that user's already in epoch J minus one. So users can be left behind and then catch up. So in that sense, it's a bit different than broadcasts. It's weaker, but still we want that ordering. Of course, as we said, the adversary can at will at any time and repeatedly leak the local state of users. And finally, you can see all the network traffic, right? So we've got that man in the middle, but for an authenticated network. So that's the adversary. Now, what's the security notion that we want here? Well, we want that, basically, look at an epoch I. We've got this group key for epoch I, and we wanna ask when is this key secure? By the way, group key, I say group key or epoch key. In the MLS parlance, it's actually called the update key. That's just, for those of you who are already familiar with MLS, I use those terms interchangeably. So we wanna ask ourselves when, under what conditions is an epoch key considered secure? When is it secure? Well, ideally, kind of the minimal thing that we would want, this is what we would call optimal security for CGK, is that anybody who's been corrupted before epoch I has in between that corruption, i.e. when his state was leaked, and epoch I itself has performed an update, has refreshed his state, all right? That's pretty much it. That's all we really want. If that condition is satisfied for epoch I, then we want epoch I, then we wanna say, oh, fine, epoch I has to be secure. So some things to note here, this implies standard sort of forward security and isolation. What I mean by an isolation, well, the notion for forward security is normally, you consider only corruptions that happen after epoch I. So there are no corruptions before epoch I. At epoch I, you say, is it secure? And you look at any corruptions that happen afterwards. Conversely, PCS in isolation is kind of the other side. You say, well, I'm only allowing corrupt, I'm only considering corruptions that happen before epoch I. So this notion, it combines the two, it's actually stronger than the two, because it allows both before and afterwards, all right? So that's the optimal security we're going for. So when we look at MLS, they have a CGK, and it's a cool algorithm that's called Tree Chem. So this was originally introduced by Karthik, Richard, and Eric on the MLS mailing list, and it's inspired by the ART protocol, which appeared in CCS last year. Subsequent to the original introduction on the MLS mailing list, there was an update, I guess we could call that Tree Chem with blanks, and that's really what I'm gonna be referring to as Tree Chem in this talk. And this is what's currently being used by MLS. After, you know, there's been some follow-up works already around Tree Chem itself. There's been like causal Tree Chem, that was a really cool idea that sort of tries to relax this notion of in-order delivery. There's tainted Tree Chem, which tries to improve the efficiency. But I'll be looking at Tree Chem because that's what's in MLS right now. So how does Tree Chem work? Well, I guess a good way to think about the construction is to look at this shared group state, right? So every epoch in a Tree Chem execution is given, I say, you could characterize it by the distributed group state. And this is, it can be viewed as a binary tree, in particular what's called a ratchet tree. So this is a left-balanced annotated binary tree. Annotated, we're gonna be assigning keys and secrets and values to each of these nodes, right? And you know, it's important to understand each epoch has a fixed binary tree, the annotation is fixed for that epoch. When we move to the next epoch, we're gonna modify the tree, maybe some of the annotation, and that's gonna be the new ratchet tree for the next epoch. So how do we annotate it? By the way, when you see little question marks, that's meant to be arrows, that there's a bit of a font thing, so nothing too important there. Yeah, so how do we annotate this tree? Well, the first thing we do is each user in the group is assigned a leaf. There are as many leaves as there are users, each user gets his own leaf. So here's the example for four people in a group. The next thing is each node in the tree, except for the root, is also assigned a public secret key pair for that node, all right? So that's pretty much it in terms of this distributed state. But it's distributed so we need to talk about who knows what parts of this state. And to that end, there's two invariants, and really most of the work in TreeCam is about maintaining these invariants across epochs. The first invariant is about the secret keys. Who knows which secret keys? Very straightforward. A user knows the secret keys for the nodes that lead from their leaf to the root. Alice, for example, here knows secret key four and secret key two. The second invariant is about who knows which public keys. It's maybe not security-wise you could say everybody knows all public keys, that would be fine too, but what's kind of the minimal thing you need for the functionality is that users know the public keys on their co-path. Co-path means the sibling nodes on their path to root. So for example, Alice should know PK five because five is the sibling to her node four, and she should also know PK three because node three is a sibling to two. So these are the two invariants. You know the public keys on your co-path, you know the secret keys on your path. And that's pretty much it in terms of the shared group state. So as I said, really the most important thing that's kind of is how you do updates. And the way TreeKem does updates is as follows. We'll go by example with Alice doing an update. So the first thing Alice does, she needs to come up with a new ratchet tree. The first thing she does is delete all the nodes on her path to root and now she has to sign new secrets, right? So first thing she does, she chooses a random secret with enough entropy and from that, using a PRG, she's now gonna compute a new secret. So from her S she computes a new secret S prime as well as a public secret key pair. That public secret key pair becomes the public secret key for her node and the secret she derived as prime becomes the new secret for the next node up her path. So now we can recurse. We take S prime. She again uses a PRG to expand that into a new secret and new public secret key pair and so on so forth, defining public secret keys all the way up again to the root. And in particular, when you get to the root, this, the secret that gets defined this way is what's called the update secret, is the epoch secret itself for this new epoch. All right, so it's all about this secret trying to keep it distributed to everybody while maintaining these invariants that I told you about with secret key and public key. All right, so the question is, okay, we have to find our new regulatory, how do we distribute that information to the rest of the users in the group? So Alice prepares a packet, right, a network packet. I distinguish between packets and messages just since this is messaging, it's a bit ambiguous. Packets mean protocol messages here, okay? So she has to prepare a one-off packet. We can't have interactions, this is asynchronous. So what's she gonna put in this packet? Well, the first thing she does is she encrypts the secrets to the co-path, right? So for example, Bob needs to know, to maintain his invariant, he needs to know the secret key for node two. So she knows Bob's public key, so she takes that secret for node two and encrypts it to Bob's public key. Similarly, Charlie and Dave also need to know the group key, so this S double prime. So she encrypts that to public key three because both Bob and, sorry, Charlie and Dave know that secret key, right? So basically you encrypt nodes to the co-path. All right, so this is it. And then the other thing you do is also the new public keys, yeah, you also have to distribute these new public keys, right? For example, Bob needs to know Alice's public key, so she just includes this new public key as part of this packet. So that's how you construct this update packet, right? We've maintained these two invariants. So now we can look at the security of TreeKem. And so what do we want from, so TreeKem does achieve PCS and forward secrecy. I'm gonna have to skip this a little bit. So, sorry. In order to understand what kind of forward secrecy is achieved here, we have this notion of critical keys. So when can we claim that a secret at the root is actually secure? Well, in order to reason about that, we have this definition of a critical key, right? A secret key in this ratchet tree, we call it critical for a secret S if knowing the secret key and all the network traffic that is transpired in the session allows you to compute the secret S. That's what makes a secret key critical for some secret S. Well, with that definition, if you've got a ratchet tree and you wanna ask yourself, when is the secret at the root, this epoch key, when is it gonna be forward secret? Well, it's only gonna be forward secret if you've removed, in future iterations, you've managed to remove all critical keys from the group state. Why is that? Because if there's a group, if there's some critical key that's still left and then the adversary goes and corrupts that person, they're gonna learn the critical key and therefore, by definition of critical key, be able to go back and compute this epoch secret. In other words, for forward secrecy to kick in, we need that all these critical keys are gonna be removed. So in this particular example, critical key for S double prime would be SK five and SK three because each one of those allows you to decrypt one of the ciphertext that Alice sent out. But, and this is kinda like the big Eureka moment for us that we realized, this is actually, there's recursive critical keys as well because this SK five and SK three, in particular SK three itself has critical keys. In other words, if you learn these other critical keys, then you can recompute SK three and from SK three, you can then recompute the secret. So there's this recursion in terms of critical keys. And it turns out it's really not that great. If you've got a group of size n's, n people in this group, it turns out that of the two n minus one keys in the whole ratchetry, n of them are critical. And that's not really that good because that means that forward secrecy is really gonna take a heck of a long time. You're gonna have to do a ton of more updates and modifications to this ratchetry before a given epoch becomes forward secret. And in particular, you think about it, in any given update, you're only modifying log n keys. So you're gonna need at least n over log n, just from that observation alone, for more epochs before you get forward secrecy. And in fact, you can't pick and choose which key, so it turns out it's more like linear number of epochs. Whereas optimally, we said we wanted immediate forward secrecy within one single epoch. So Sho's tree cam is really quite far away from this optimal notion of forward secrecy. And by the way, this is best case, this n over log n or even n number of epochs. If the wrong guy doesn't do an update like your sibling, then you're never gonna get forward secrecy. Because as long as he doesn't do an update and his leaf key is critical, no one else can change that leaf key. All right, so good. So we established the tree cam doesn't have maybe the best forward secrecy, really pretty far from this optimal. So what can we hope for? Or can we do better? And it turns out, yes we can. And basically, the big sort of change that we make is that we show that, well, if tree cam uses public key encryption, you can replace public key encryption with this new notion of updatable public key encryption that we introduce, and that immediately gives you optimal security, right? So it's a pretty small change. So what is this updatable public key encryption? Well, it's a primitive that is very closely related to what's called key updatable PKE, which has already been introduced for improving on the double ratchet in two-party literature. And our construction is inspired by a suggestion for this application, in fact, by Konrad Korbrock on the MLS mailing list. So we basically ran with that in this paper. And intuitively, you can think about public key encryption, updatable PKE or UPKE is giving you sort of a very practical way of getting forward secret PKE. So how does it compare to standard PKE? Well, it's a pretty small change. We've got standard public key encryption. And what's the change? Well, basically, when you encrypt, you actually output now not just the ciphertext, but an updated public key. And when you decrypt that corresponding ciphertext, you output the updated corresponding secret key. So in other words, the active encrypting decrypting also re-randomizes your public secret key pair at the same time. So correctness traditionally is, okay, any ciphertext you get in a CPA scheme or a CCA scheme, you can decrypt. We now need things to be synchronized. We need this in-orderness, right? You have to keep your public secret key pairs as you update them. You have to keep that in sync. In terms of security, well, standard CPA security, we all know that. Encryptions of any two messages should be indistinguishable. And now we want that, if the adversary gets to choose these updates at will, so basically he's supplying ciphertexts, eventually he says, okay, now I want a challenge. He gets an encryption where he doesn't know the randomness. We want that encryption to still be secure in the normal CPA sense. Even if after the fact, he then you reveal the next updated secret key to him. Right, so there's the challenge ciphertext and then you do an update with fresh randomness which the adversary doesn't see and you reveal the new secret key. Still want security for the message in the challenge ciphertext. So the construct, we have a construction. It's very similar to El Gamal, basically, so it can be generalized across any prime order group and it's very practical in terms of efficiency. Yeah, so basically this new version of TreeCam, we call it our TreeCam, the takeaway is you take TreeCam, you replace public key encryption with updatable public key encryption and you go from not great forward secrecy to optimal forward secrecy. Yeah, so that's pretty much what the picture is there. And the reason this helps things is because now we have a second mechanism for replacing keys. We don't have to wait for somebody to do an update. Simply the act of sending them a ciphertext and then decrypting already updates those keys. So these critical keys are immediately replaced. The moment you decrypt the ciphertext with a key, you replace that key. So there aren't no more critical keys in this tree, right? And that's why we get forward secrecy within one step. So yeah, basically there are more results in the paper. We look at adaptive security. We also have future directions for secure messaging. I think, I agree with previous talk, there's all kinds of open problems there that we could work on. Also in a follow-up work, we show how to do UPKE for the X25549X448 curves because those are not primordial groups so you have to do a little bit more kind of working but it's also nice and efficient, practical. So yeah, I think that's about it. So we're gonna move straight on to the next talk, I'm sorry. If you wanna talk to Joelle about this paper or this work, please catch him at lunchtime. We're actually switching now to a slightly different mini-session. This one on compromised credentials and the first talk in this session will be given by Kevin Yeo. All right, so thanks for the introduction Kenny and so I'm Kevin and here today I'm gonna talk to you guys about protecting accounts from credential stuffing through the use of password breach alerting or what I like to call password checkout. So before I begin, I wanted to mention this was a joint work with a Dan Bonnet at Stanford as well as really a large-scale effort at Google that's spanned across many teams across many different locations and it also involves several teams and people that aren't listed here but were integral to the success of the project. All right, so let's get started. So it's sort of to understand the problem with the credential stuffing, we have to go back to the last decade and understand that there's been a lot of breaches of data for several organizations and companies and what's happened is the hackers that sort of perform these data breaches, they sort of share and pass around this data through the dark web. So like these sort of news articles show that these hackers have billions of records and in fact they're billions of breach account credentials. Using this large set of breach account credentials, what they can do is essentially perform credential stuffing. So what they do is literally go to websites and try to log in using these compromised credentials. So quite a, almost a jarring statistic for me was that let's say online retailers such as Macy's and Nordstrom, about 90% of login attempts are actually hackers trying to hijack accounts. So it's a real problem, it's actually quite prevalent and it's something that we really need to tackle. So there are ways to defend against breach credentials, so things like defense in depth. So a great way to defend against these kind of hijacking attacks are two-step authentication, right? So even if a hacker has my compromised credentials, which I'm not aware of, and they try to hijack my account, if I have two-factor authentication enabled, they wouldn't succeed at hijacking the account. Unfortunately, this only works for really like let's say larger websites because you can imagine there's a long tail of smaller websites for which many people don't even remember they even have accounts at and for which these defense in depth sort of protocols are not available, right? And in these cases, hackers would be able to hijack the account and would be successful essentially in taking over. So sort of to get to the actual problem, what we believe the real problem is is sort of an imbalance of knowledge. So you sort of have on one hand, you have these hackers who have gone to the dark web and they have access to billions of these compromised credentials and they're able to use them for credential stuffing and whatnot. On the other hand, you have an average user, the ones who know how to use the internet but maybe are not so well-versed in cryptography or they don't even know how to go to the dark web. So they have a list of credentials and they actually just don't know which of the credentials are compromised and which ones are actually secure to use, right? And sort of this imbalance of knowledge is actually one of the reasons that credential stuffing is so successful. So okay, so let's, in our work, we're actually trying to find a way to sort of solve this imbalance of knowledge and we try to do this through the use of what we call password reach alerting or what I like to call typically sometimes as password checkout. So you can imagine on your left, you have this sort of server and let's suppose the server is able to also source this list of breached account credentials maybe through the dark web or whatever and sort of they have these end compromised credentials. So what the password reach alerting protocol would sort of do is expose an API to the general public in such a way that an average user, let's say an internet user can come and sort of it has a sort of credential that it wants to check whether it's breached or not. So what it can, from a high level, what it will do is it'll send something like an encrypted request of its username and password and I'm gonna be very vague here and I'll go into more details of what the encryption means. So sort of using this encrypted request, the server would process an encrypted response of whether the username and password that was queried by this user was breached or not. All right, so now I was very vague about what encryptions, what does encryption mean here. So let me go deep in and try to exactly define what are the design principles that were necessary for this protocol. So the first principle, which is, I think the most important is obviously password privacy. So going back to sort of this protocol here, when this user does this query for its username and password, it should be done in such a way that the server who's hosting this API, they don't get any knowledge about the query password, right? So this is sort of the whole problem to begin with is that hackers were able to get plain text knowledge of the password. So to sort of solve this problem in our breach alerting protocol, it must be done in such a way that no knowledge about the query passwords is ever revealed to the server. All right, so that's sort of the very first design principle and of course it's probably the most important. A second sort of orthogonal issue, but it's actually quite important, is actually sort of mitigating abuse risk of the API. So going back to this server that has this database of breach credentials, even though it sourced it through the dark web, the database is actually still quite sensitive, right? And it shouldn't really be widely spread. It shouldn't just be available to everybody who wants to sort of have access through it through the API. So what you can imagine is sort of the scenario where a hacker comes, you know, the API is exposed to the general public, so a hacker could obviously also use it. And what he wants to do is maybe one query or sort of a series of queries to this API and does it in such a smart or maybe some sort of sophisticated way to sort of extract the database of breach credentials, right? And this would be a really bad problem if we like, you know, if this database was just available to all hackers because now they can go back and do credential stuffing again and again. All right, so to sort of see what's going on with the problem, you have to sort of take a step back and, you know, take a look at a higher level. So of course, one refer a hacker to get these sort of breach credentials is to use the password breach alerting API. But like I said, simultaneously, there are other means for this hacker to sort of get this data. One is through the dark web, right? And sort of one, the goal that we, how we were able to achieve mitigating abuse crisis is sort of trying to make sure that sort of the cost of abusing this API by these hackers is larger than the cost of maybe going through the dark web to get this data. So for example, you can imagine hackers might come up with very sophisticated and expensive sort of ways to sort of utilize the protocol to get the breach credentials. But if that cost is still much larger than what it would be to get on the dark web, you know, we have mitigated abuse risk if we haven't made it any easier for hackers to sort of get this sensitive data. All right, so, you know, taking a step back, we sort of have two privacy goals, right? For the user, we want to make sure that their queried password is never leaked to the server. And simultaneously, from the server's perspective, that exposes these API, they want to make sure that whenever a user sort of queries for a credential, username and password, it doesn't learn any knowledge about another credential, let's say username, prime and password prime. All right, so that was sort of the second design principle. And the third one is what I like to call simple but effective crypto. And this is very subjective, so let me try to get into it a little more carefully. Like I said before, this project is, you know, it was a really a large-scale effort across many different teams at Google. And there are many engineers at Google that are very smart but don't have the expertise or haven't spent the time studying crypto, right? And since it involves so many teams, having simple crypto enabled them to be able to utilize the library easily, right? And this is a very important thing because you can imagine there are reliability teams that need to make sure the machines are running and they actually need to understand the crypto protocol and simple crypto enables such sort of reliability. Another sort of aspect that's very important was developer velocity or implementation time. As we sort of all know, implementing crypto is quite difficult, right? And it takes a long time to implement it correctly, try to make sure it's vetted and make sure all it's secure. And sort of simple crypto sort of enables this at a faster rate and with more trust in the code. So what I guess what I'm trying to say is that simple and effective crypto is not necessary for launching this product at such a large scale, but it really makes it a lot easier and it's a very important part at least in my opinion. All right, so given that we have these three design principles, let's go ahead and I'll try to explain to you how we achieve design principles in our protocol. So again, we have, let's say, these Google servers on the left who have this set of N-compromised credentials, let's say U1P1 over the UMPN. So the first step essentially is how will the server pre-process this database in a way that it can readily sort of serve requests from users. So what we do essentially is we sort of take each credential and we take its username and keep it there and we sort of take the concatenation of the username and password and hash it using some hash H prime. I'll discuss what H prime is a little later, but let's say I do this for all N-bridge credentials that are that are exist on the database. The next step is the server sort of generates a secret key K and essentially encrypts, encrypts each of these hashes of username and password concatenations by simply exponentiating it. So sort of going back to this hash H prime, what it's really doing is sort of mapping strings to an elliptic curve, right? And in particular, we have to choose an elliptic curve obviously where Diffie-Hellman is hard so that this is actually an encryption. All right, so that sort of completes the pre-processing for the second tuple in each pair. Let's go back to the username which is the first tuple in each pair. For this username, what we're gonna do essentially is take an unkeyed hash, let's say H, we can think of it as let's say SHA-226 and sort of just simply hash each of the usernames. So the password breach protocol is actually parameterized by some positive integer B and this B comes in right here where essentially what we're gonna do is we're gonna take the unkeyed hash and just take the first B bits of it. So we're gonna drop everything beyond the first B bits and just keep the B bits. And sort of these B bits will actually act as a bucket identifier. So what we're gonna do actually is we're gonna have two to the B buckets and each bucket is uniquely identified by a B bit string. And we're gonna sort of bucketize all of these encryptions using this bucket identifier. So for example here, let's take this example here. You have the third compromise credential U3 and P3. Since it went to the bucket that has zero Bs or B zeros, what it essentially means is that the unkeyed hash of U3, the first B bits of that was all zeros. And actually that turns out that's all we need to do to sort of pre-process the database to get ready for queries. And I guess something I'd like to mention is that this is sort of easily shardable and you'll sort of see why, but you can sort of have many machines sort of handle different buckets. All right, so let's go on to the query algorithm and how a user who sort of comes with a specific username and password that it wants to query can now send a request and sort of get these responses. So the first step of a query algorithm is that the user will generate an ephemeral key. So this ephemeral key R is per session. It doesn't have a store long term or anything like that. And sort of what it does next is it'll send two things to the server in an encrypted request. The first is it takes the username that it wants to query and does the same sort of unkeyed hash, let's say shot two to six and just takes the first B bits and that'll be sent to the server. The second thing it does is also takes the concatenation of its username and password and hashes it to the lifted curve and encrypts it using the ephemeral key R. And that's the entire encrypted request by the user. So now let's suppose this request has been sent by the user and the server sort of receives it. So what it first does is sort of takes the B bits of the unkeyed hash and simply sort of identifies the bucket that's corresponding to these B bits. And then once it finds this sort of a correlated bucket, it sort of just returns all the encryptions in this bucket to the user. So that's the first part of the encrypted response. And the second part is it sort of takes the encryption of the username and password that was sent by the user encrypted by the user's secret key R and sort of re-encrypts it. So you can sort of think of this as an almost an oblivious PRF where it's going to sort of use a commutative encryption. But what it does is sort of takes this username password concatenation encrypted under R and re-encrypts it so that's now encrypted under both R and K, where K is the server's secret key. All right, so that's actually the entire encrypted response by the server. So given that now this encrypted response comes back to the user, the user has to do the following two steps to determine whether it's username and password are breached or not. The first step is it sort of decrypts its secret key R. So since it generated the ephemeral key R, it knows R inverse and can simply sort of exponentiate or decrypt by R inverse to sort of get its username and password encrypted under only the server's secret key. And you can view this essentially as an oblivious pseudo random function. And then the second step, all it does is actually takes this username and password that are encrypted under the server's secret key K and simply checks if it exists in the bucket that was returned by the server. And it's not hard to see that if UMP did exist in the breach database, it would have been encrypted under the server's key and appear in this bucket. Cause of course, the hash of the username first be bits would be the same. And actually this is the entirety of the protocol. So this is sort of very straightforward, very simple. I hope I've sort of convinced you it's sort of simple cause I've explained it in probably less than 10 minutes. So let's go back to the design principle. It's sort of said it's simple crypto. Let's go back to the design principles to make sure that we've sort of achieved what we wanted. To remember the first thing we talked about which was the most important was password privacy and that whatever request was sent by the user should be encrypted in a way that the server gains no knowledge about the query password. So let's take a look at the protocol again more carefully. The user sort of sends two pieces of information to the server. Clearly the first be bits of the hash of the username contains no information about the password so there's no information there. So the only bit that contains information about the password was actually this H prime UP but it's encrypted under this user's secret key R. So assuming the Diffie-Hellman problem is hard in the lifted curve we chose, you can actually show that the server doesn't gain any information about the password. All right, so sort of the second design principle we wanted to do was sort of mitigate abuse risk and that when a user does a single query for a username and password, it shouldn't learn information about other credentials. Let's say username prime and password prime. So taking a look at this side, you can sort of look at what's being responded by the server to the user. So even though the user sort of gets this bucket of all these encryptions on the server's secret key K, it only gets one double encryption of its username and password, of the username and password query. So even though it gets sort of this bucket, it can only test its specific username and password and whether it's in the esprit or not. So it sort of satisfies this goal in the sense but there are actually even more stronger ways to sort of achieve mitigating abuse risk and one way we actually did was sort of limit the number of queries that a user can perform by replacing this H, you know, I said before it shot you to six, you can imagine it being replaced by more expensive hash functions, let's say argon two. So, you know, if a hacker wants to come and try to perform many, many queries to the API, it sort of has to pay the cost of computing this expensive argon two hash over and over again. And in addition to sort of using expensive hash functions, you can also use things like rate limiting and stuff like that to ensure that we mitigate abuse risk. All right, so that's actually, you know, I hope I convinced you guys that the protocol is simple and it satisfies all the design principles that we had wanted ahead of time. So let's move on to the actual implementation of the protocol and where it's implemented. So the first thing that we need to figure out is, you know, where did we get these breached account credentials, right? Where did these breached passwords come from? So actually there's a fabulous counter-abuse team in Google that actually works on this stuff and they have a paper from CCS 2017 that describes, you know, that gives more details about how to get this database. But this database contains more than four billion unique usernames and passwords from breaches. And this is what will be used when serving for the API. All right, so I'll talk about the first feature that we launched earlier in 2019 that sort of exposed the password breach alerting API to the general public. And it was through the use of the password checkup extension. So right now this was just very recently, it has over a million users at this point in time. So what happens is, you know, a user goes and when they download this extension, what happens is the extension would automatically detect login forms. So let's suppose, you know, a Chrome user sort of downloads this Chrome extension, so every time it sort of logs in a username and password to a form, the Chrome browser extension would automatically detect it and automatically perform a password breach alerting protocol. And, you know, you get one or two notices. You know, if the account credentials you used to log in with were secure, you would get sort of no notice and if you sort of clicked on the extension, you'd see that none of the passwords you recently entered were detected in a data breach. On the other hand, in the bad case, when, you know, you do log in with a breach credential, you would automatically get sort of this red notice immediately telling you to change your password on this specific website. So for example, if I logged into github.com with some bad credentials, it would send you this notice. All right, so before I like to go, I'd like to just quickly mention that the extension actually uses an older version of the protocol and the other features I'll talk about later use the newer version of the protocol and the nuances between the two protocols will be discussed in the next talk by Lucy. All right, so going on, we were actually able to, you know, collect anonymous telemetry from this extension and so I wanted to share with you some very interesting statistics that we were able to deduce using this anonymous telemetry. So, you know, for anonymous telemetry, we got things like, you know, the domain of which people were logged into, timestamps, breach status, and, you know, performance and stuff like that. So the first thing I'd like to mention is performance metrics of the extension. So I think this might be a little outdated, but, you know, at peak usage is about 20 queries per second happening to the extension with over the million users and I think it's a little more now. And sort of the round-trip latency of a password breach learning protocol was about eight and a half seconds. This includes all the client work that needs to be done and stuff like that, and in particular, almost half of this was spent on this proof of work, you know, this Argon2 hash we had talked about where we used to mitigate abuse risk. So it turns out that, you know, this is, even though it seems like large 8.5 seconds, it's actually quite a lot smaller. All right, so moving on to, like, the frequency of warnings by extensions, in the first month after we launched the Chrome extension, we had about 21 million logins that were scanned. And of these 21 million logins that were scanned, about 316,000 of them had breach credentials that were detected. So sort of extrapolating this sort of data out, it seems like about one and a half percent of logins on the web are breached, but this might be a little skewed because of obviously the people who download the extension are privacy-conscious people to begin with, but sort of this is a general idea of a cool statistic. So now, this I'd like to call out to be a much more open problem is that user response to warnings by extensions were not actually great. So, you know, every time you sort of log in and you have a breach credential, you would sort of see this red notice and we wanted to, you know, keep track of how many people actually adhere to the notice and change their password. And it turns out only 26% of the people actually changed their password. So, you know, password checkup is great, but it doesn't really work unless users change their password. So I really wanted to call this out as a really an open problem that we really need to solve to make sure this sort of password checkup works better and, you know, I'd really love for people to work on this. All right, so this looks like bad news. On the other hand, we have much better news on the other hand. So, you know, we'd only have like 26% of people who actually changed their passwords when they see this notice, but of these 26% percent of people who changed their passwords, their newer passwords were strong or stronger than the previous one. So in this case, this is good news for us, right? When users see this, they sort of see that their passwords have been compromised, they change their passwords to become stronger in hopes of, you know, making sure they don't become compromised again. All right, so that was sort of the first feature we had launched, which was early 2019. It was this extension. And now it was a little more experimental in a sense. We were trying to get an idea of the feasibility of this protocol when before we deployed it to very large groups of people. So now, later in 2019, maybe around, I think, September, we actually launched this sort of a password breach alerting protocol directly into the Google password manager. So if you go to passwords.google.com or those who use the Google password manager, you know, they'll sort of show you a list of all the passwords that you have. And in particular, we launched this password checkup sort of a feature. So you know, if you go to passwords.google.com, you sort of click check passwords. It has a bunch of sort of checks for you to make sure that your passwords are strong and they're not compromised. So sort of the first line or the first thing that's sort of checked is whether your passwords have been compromised and data breaches or not, right? Of course, other things that are also checked are things like reused passwords or whether accounts have weak passwords and stuff like that. All right, so sort of going forward, and I think this is probably the most exciting thing that we did was that we, you know, previously we had this Chrome browser extension that required people to sort of download the extension or sort of opt in. So we went ahead and did it was actually implemented this natively into the Chrome browser. And this was just recently launched in December of 2019, so last month. So what sort of happens now is for every signed in user, whenever you log in to a, whenever you enter credentials into a login form, the Chrome browser would automatically detect that you're logging into a Chrome, into a login form and perform the check for you automatically, right? And you know, if again, if you sort of have a, you sort of log in with credentials that are breached, you would sort of get this notice immediately telling you to sort of change your passwords. All right, so I mean, these are like sort of the three features which are currently available for general public users to utilize the password checkup to help and go and check your credentials. All right, so going forward, I'd like to mention that, you know, a lot of cryptography, it's very difficult to implement and it's very important that the, you know, that the academic and the outside world, the general public, sort of vet the data, sort of vet the code. So I'd like to mention that all the cryptographic protocols that are used in the password, in the password breach alerting protocol are available on GitHub and under the private joining compute sort of section. So this contains all the cryptographic elements or the cryptographic implementations, but the actual, the more general implementation of the actual password breach alerting, you can see in the Chromium code base which is also open sourced. All right, so I wanted to come with the conclusion that, you know, hopefully I've convinced you guys that privacy preserving password checkup is actually protecting millions of users from hijacking around the world. And in particular, we're trying to solve this imbalance of knowledge where we give users more power and knowledge of which of their credentials are secure to, you know, which they can feel comfortable with and which ones are breached and should be changed. So thanks for listening to the talk and I'll be happy to take any questions if you have time. So we're already a little bit behind schedule, so I'm gonna limit the number of questions just to a few. So let's start on this side. Thank you, very, very, very cool work and I'm really happy to see Google working on this. My question is, it seems really crucial to the security properties of the protocol that there's this association between the username and the password. But what if all you have is a bag of passwords? So have you thought about that problem yet? Right, so this is a great question, it's something we actually considered. So one of the principles that we came up with when coming up with this protocol was that we didn't want any false positives. So we felt, what I mean by false positive is the following. You have a very strong password. We sort of give you a false positive that, oh, your password is compromised, you should change it, right? As we know, it's already very hard enough to come with a strong password and if you keep asking people to change it, you can sort of, they might enter, weaker passwords are ones that they'll forget. So going back to this idea of just doing password only checkups, suppose you can imagine a situation where I actually have a strong password and maybe only one other person in the world somehow shares the same strong password with me and their account credentials were breached, right? So in this sense, is it really, are your credentials actually compromised? And in our sense, we believe it's actually not and it was safer for us to keep, to make sure that users kept their old passwords. I think so though, if an attacker can guess the password that it knows, if it could do like an online attack to, it thinks it's highly likely that you might have that password. I just don't know if the risk is totally addressed. That's fair enough, but I think we still believe that the usability of this false positive stuff was much more important in the sense that we don't want to ask people to change their passwords. Thank you. So the server reveals the list of hashes to the PowerK and at the same time, the server can be used as an oracle to raise anything to the PowerK. So can it be abused by an adversary to find a weak password of someone? Yes, so that's a great question and that's one of the problems we're addressing. So one of the ways we talked about before was you could actually use these sort of, to limit the number of queries that are being performed, to like, you know, use the raising to the PowerK with the oracle, you can use sort of argon2 or expensive hash functions, right? To sort of, it makes a actor sort of like hacker sort of have to really spend the computational time to make that happen, right? Other ways we do this are things like rate limiting, so for example, the Chrome browser right now only allows signed-in users to sort of perform queries and we have rate limiting for each account and it sort of costs people money or like there's, there are costs and guards against creating many accounts so we sort of rate limit to prevent these sort of attacks from happening. Okay, I'm going to take one more question from the site and then we're going to cut the line. So my question is somewhat related to the first one. I'm wondering if you consider giving stronger privacy guarantees on the user name. So for example, if you ask for, if you check for a password then immediately after use, your user name to connect to on a private connection then you can easily infer that that username is being used for that connection. Yes, so absolutely, we always look at trying to improve the privacy of everything we do but in this case it turns out to be sort of a feasibility versus privacy sort of trade-off, right? To sort of gain very strong guarantees for user name, at least to my knowledge, they required significantly more efficient, like efficiency losses, right? Sort of having almost not real-time checks because you have to, we can go into this a little more detail but it costs more to sort of hide more bits of the username. So it's a trade-off of whether we have, whether the current, the scan anonymity that we provide for usernames suffices for the data and we believe it does so because usernames are less private than passwords, right? But on the other hand, having the feasibility and enabling users in the general public to have real-time password checkup we believe was much more important. So we were able to sort of find the right balance we believe. Thanks. Okay, thank you very much, Kevin. Let's thank the speaker again. Thank you. And we'll now move to the last talk of the session and it's a short talk and it's going to be given by Lucy. Just setting up. Okay, so the talk is about protocols for checking compromised credentials and the talk is given by Lucy Lee from Cornell. Hello, so today I'll be talking about the same general topic as Kevin's talk and Kevin talked about the details of Google's implementation of a compromised credential checker and I'll be taking a look at these types of protocols as a whole. So like what we want security-wise and to what extent existing protocols meet that goal. So as we've all heard about, there have been many password breaches over the years which has led to attacks called credential stuffing and these attacks can be dangerous because around 40% of users reuse passwords across different websites. Meaning that if an attacker has your credentials from another website they might be able to log in and see you on a different website. So one way to mitigate the problem of credential stuffing is to use a third-party to check if a user's credentials have been previously leaked and we call these third-party services compromised credential checking services. So using this service we have a client which can be some individual or another online service and the compromised credential checking server maintains a copy of a leaked credentials database. So a collection of usernames and passwords that have been previously leaked and the client has a credential which can be either a password or a username password pair and they want to find out whether or not their credential is present in the server's leaked password database. So the main question we wanna consider here is can we use a third-party checker and still preserve privacy of user credentials? Two big initial deployments of services with this goal in mind are have I been pwned which checks to see if your password is present in a known data breach and Google password checkup which we just heard about which checks if your username password pair is present in a breach. So to answer this question in our paper we made the following contributions. We gave a formalization of these C3 protocols and talked about the threat model and we show formally and empirically that have I been pwned and the initial Google password checkup protocols leak informational passwords. So I'll be differentiating between what I call GPC v1 and v2. The one that we just heard about is the second version which is an improvement upon the first version. The first one used a different bucketization protocol which I'll talk about in a minute. And we give new C3 protocols that leak less information about passwords. In the username password setting this is ID based bucketization which is now the second version of the Google password checkup protocol and we both arrived at this new protocol independently and in the password only setting we introduced a new protocol called frequency smoothing bucketization. So today I'll specifically be talking about our empirical results that motivate the move from the first version of GPC to the ID based bucketization and hopefully from the have I been pwned protocol to frequency smoothing bucketization. And we give an overview of frequency smoothing bucketization which is our new password only C3 protocol. So to take a quick look at our threat model it's pretty similar to the one that Kevin just described. So there's a lot of potential other issues but in this talk I'll focus on the key challenge which is protecting a client's password against a potentially malicious server. So obviously this means that we're not gonna send the password in the clear to the server and in the ideal case this means no information about the password is leaked because any partial information about the password that is leaked to the server could speed up online guessing attacks of this password. So more specifically suppose a malicious C3 service obtains some password leakage associated with a known user Alice and the service could then use this information to improve the efficacy of an online guessing attack in which they have queue tries to guess Alice's password before they get locked out and knowing any partial information about Alice's password can be the difference between guessing it correctly in queue tries versus not being able to guess it at all. So one main issue as we saw when designing compromised credential checking protocols is the large amount of information a server has to store and search through on request from a client. So typically a C3 server could store hundreds of millions of passwords or even billions of username password pairs so they need to be able to handle client requests efficiently. One way to achieve this kind of efficiency is to divide the entire credential space up into buckets. So here in this example the list of passwords held by the C3 server has been split into a few different buckets. When a user wants to check for their password in the database they send the bucket identifier in this case it's the color orange to the C3 service. The C3 service can then send back all the passwords that are in the same bucket. And we also need to combine this bucketization with some way of hiding the passwords like some sort of private set membership protocol similar to the one we saw in the Google protocol. So we don't reveal the plain text to the client. And in practice both Have I Been Pwn and Google password checkup use some sort of hash prefix as the bucket identifier. Have I Been Pwn uses a prefix of the hash of the password and in the first version of the Google password checkup protocol they use the hash of the prefix of the hash of the username password pair. So the key security question we wanna answer with artwork is how much does knowing the bucket queried help an adversary guess a client's password? So one way we answer this security question is through empirical evaluation. Again we wanna know how easily an attacker can guess passwords given bucket identifiers for different C3 protocols. We use a breach dataset of 1.4 billion username password pairs which we split into a test set and a leak password set. And we measure the percentage of passwords an attacker can guess in Q queries with access to the usernames that they're targeting. So to visualize our results I've plotted an attacker's successful password recovery rate when given one to 1,000 password guesses. And in the baseline simulation where the attacker gets no information about the password it can recover less than 10% of passwords in 1,000 guesses. But when we use the have I been pwned or the GPC v1 protocols and leak that bucket information to an attacker they can now guess 60 to 70% of the passwords. And frequency smoothing bucketization which is our new protocol that we propose in the password only C3 model. When we give the attacker the bucket information for that protocol the attack only performs a little bit better than the baseline. So first I'll take a quick look at the ID password C3 setting which we already heard a lot about and then I'll talk about the password only C3 setting. So in the ID password setting we check for an exact username password pair match with the C3 server. And the first version of Google password checkup initially implemented a protocol that uses the prefix of the hash of the username password pair as the bucket in the fire. And as we saw in the empirical evaluation I just showed this protocol is poor security if the username is known to the attacker. In our paper we also give a formal justification for why this won't, for what the security loss is. And so we eventually both settled on ID based bucketization which uses just the prefix of the hash of the username as the bucket in the fire which we also give a formal justification about for why this won't leak any information about the password. So moving on to the password only C3 setting this is where we check if a user's password is present in breach data. So the ID based bucketization protocol doesn't work in this setting because we don't have access to usernames. And a C3 server might wanna use this because it could avoid the risk of storing username password pairs and potentially making it easier for an attacker to find those. So I'll talk about why have I been pwned leaks information about passwords that speeds up remote guessing attacks and I'll go over our new protocol frequency smoothing bucketization. So how have I been pwned works is the user takes a hash of their password and sends the five character prefix to the server. The server then sends the user a bucket of all credentials that start with the same hash prefix. And then the user checks to see if their password's full hash is present in the bucket. So to illustrate the issue with have I been pwned I've constructed a small example. So users generally choose passwords from a skewed distribution like the one on the left where some passwords are much more popular than other lower probability passwords. And there's usually a long tail of low probability passwords which I haven't shown here but with the probability distribution you see here we might get a bucketization like the one on the right where each password is matched to one bucket. And the colors in the buckets here correspond to the probabilities of the passwords given the bucket. So if an attacker knows which bucket was created it's pretty easy to figure out which password is most likely to be the correct one. And then they can narrow down the search space to only those passwords that belong in the bucket and then choose the most likely ones from that list to guess. In this example even in the case where we have two passwords in one bucket the blue password is much more likely than the orange password so an attacker would guess that one first and have a higher chance of winning. So to fix this problem we introduce frequency smoothing bucketization as a more secure password bucketization algorithm. Instead of putting one password in each bucket corresponding to its hash value we add it to a number of buckets proportional to its probability. So the passwords in the distribution on the left might be mapped to buckets in a way that looks like this. And you can see that the most popular password the red password is put into every bucket and the least probable password which is the orange password is only added to one bucket. So the goal here is that given a bucket the probability of each password in the bucket being the correct password is about the same. And how do we actually implement this? So frequency smoothing bucketization is parameterized by an estimate of the password probability distribution as well as queue the expected getting budget for an attacker. And first I'll talk about how this works when queue is equal to one. So we have some number B of buckets and we take the most probable password and we add it to every bucket. We then add the rest of the passwords to a number of buckets proportional to their probability relative to the most probable password. So for example, since the blue password is half the probability of the red password we add it to half the total number of buckets. And we choose the starting bucket for a password based on some hash function and we add a password to every bucket in the range from its starting bucket to the number of buckets that we're adding it to. And a password can be included in anywhere from one to B buckets. If a client wants to check if their password is in the server's database they can compute the range and select a password randomly from that range. So the server when fetching some bucket I just returns all passwords that have ranges that intersect with I. So this parameter queue as I said reflects the expected online guessing budget of an attacker. So how do we actually implement this when queue is greater than one? So what we do is we include the top queue passwords in every bucket and distribute the rest proportionally relative to their probability compared to the probability of the queue with the most popular password. So for the security of our frequency smoothing bucketization protocol we show that if an attacker has less than or equal to queue guesses access to the bucket won't give any information, won't give any advantage over baseline guessing where baseline guessing is just guessing passwords in order of highest to lowest probability. And we also give bounds for when an attacker has greater than queue guesses which we show in our paper. In general, higher values for a queue lead to a smaller security loss but also they mean larger bucket sizes for our protocol. So when choosing a parameter queue we have to balance between the two factors. And taking a quick look at how all of these protocols that I mentioned perform. If we take a look at the password only setting it's pretty clear that have I been phoned is more efficient than frequency smoothing bucketization but as we saw it's also much less secure. Frequency smoothing bucketization has about the same cost as the protocols in the ID password C3 setting so it's definitely feasible to implement and run. And in terms of the ID password C3 setting they both have similar bandwidth and runtime so it's pretty clear that ID based bucketization would be the better protocol to use in this scenario. And so in conclusion some deployed C3 protocols a lot of information about the user's password to C3 server. And we recommend using frequency smoothing bucketization in the password only setting and ID based bucketization in the username password setting. Thank you. So we have time for perhaps one question or two questions if they exist. Have you got one coming? This sort of assumes that you can actually actively you accurately model the probability of any particular password. How close is that to accurate? Obviously we don't know like that for the real distribution but because there's so much data over like password breaches we have billions of credentials that have been leaked we can see that there is a lot of passwords that are like a lot more likely than other passwords and it kind of forms easily guessable distribution. So in order to compute the range to know what bucket to query the client needs to know the probability distribution. How does the client get that? So we have a model of the probability distribution that's relatively small that we can send to the client so they can compute this. Okay, thank you very much for the talk. Yeah, and that's lunchtime and we'll see you in the afternoon for a session on machine learning and cryptography. Thank you very much.