 Hi, my name is Marta, and I will tell you about Continuous Group Key Agreement with Active Security. It's a joint work with Joel Alvin, Sandro Corretti, and Daniel Jost. So to tell you what is Continuous Group Key Agreement, I must start with Secure Group Messaging, or SGM, which is the ultimate goal, and this basically generalizes the well-known two-party secure messaging, sometimes called ratcheting two groups. So the goal is to enable a large dynamic group of users, think thousands of users, to exchange confidential messages over the internet, and we want some security even if the secrets of the users can continuously leak. And formalizing SGM security is particularly important now that the MLS Working Group is developing a protocol and a standard for SGM. So Continuous Group Key Agreement, or CGKA, is the core primitive for building SGM. It's also a part of the MLS protocol, their CGKA protocol is called TRIKAM. And in a sense, CGKA is for SGM, what the key exchange is for TLS. So this means that it enables a group of users to agree, CGKA enables a group of users to agree on a sequence of shared symmetric keys. And really the way you should think about CGKA is that it creates a bunch of epochs where in each epoch a fixed set of group members shares a symmetric key, which they can use to send messages to the group, to encrypt messages to the group. And there are two important properties that we want from CGKA. The first is that it's not interactive. So this means that epoch can be changed by sending just one message to the group. So in other words, I can initiate a new epoch by sending just one message, then go offline, and whoever afterwards goes online and downloads my message can immediately transition to the new epoch and encrypt messages using the new shared key. Second property is that it should be efficient for large groups, so the message size should be logarithmic. So this is the functionality we want. Now intuitively, what does security mean? So first of all, we target adversaries who continuously leak states, who fully control the network. So this is asynchronous. It includes injecting, dropping, reordering messages and so on. And we model bad randomness generators. And it's important to note that all of these adversary powers were explicitly mentioned, are explicitly mentioned, for example, in the MLS standard. So with this adversary, the goal is to protect as many epochs as possible. So in general, you can think of the safe predicate that takes an execution where messages are sent and delivered, parties are corrupted, and then epoch created within this execution and returns one if the epoch is secure. And this should be true as often as possible. So this generalizes the well-known properties of forward secrecy and post-compromised security. As an example, if, say, Cindy's state leaks in some epoch, this inherently compromises some epochs, but for forward secrecy, we want that past epochs are not affected. And for post-compromised security, we want that if Cindy goes online and sends some messages, then the group heals and next epochs are safe again. This is intuition, but of course it's important to make it formal, to make formal claims about protocols like TRECAM. And this has been done, but not fully satisfactory yet. And this is because all previous security analyses make at least one of these two simplifying assumptions. So the first assumption we called non-splitting assumption, or NSA, and this means that if many messages are sent simultaneously, then there is an external mechanism that orders them. And everyone receives them in the same order. The second assumption called cannot inject assumption, or CAA, basically means that the adversary doesn't inject messages. And this contradicts an explicitly, an explicit call mentioned in the MLS standard. It's also not true that it's enough to add signatures to achieve the CAA, because if a party is compromised, their signing keys will leak. And at this particular point in time, inherently the adversary is able to impersonate the user. So all of the previous works actually rely on CAA. And this brings me to our contribution, which is first of all to define, to give up the first definition of active security for CGKA. We do not rely on CAA or NSA. So as I said, it's an explicit call and it has not been analyzed before. It's also not so trivial. It's not clear how to generalize the two-party active security, which is known by now. This is roughly because in the two-party case, in case of an active attack, there is not much left to guarantee. So it's kind of easy to define because of that. And our definition is a big step towards modeling malicious insiders, not all the way there. This is because we model an oversimplified PKI for this first analysis of active security. So we basically assume non-corruptible and in general not very realistic PKI. For the second contribution, we propose a couple of protocols which achieve the optimal safe predicates. So every epoch that can be protected given correctness is actually protected. So the first protocol is for the passive setting, which assumes CAA. Interestingly, all existing solutions are suboptimal and we had to do something else. The latter two protocols are for the active setting where the last one achieves more robustness or better agreement properties. So the plan for the rest of the talk is to first of all tell you how we talk about active security of CAA and then a bit about the optimal safe predicates and the techniques we used in the protocols. So first, to define CAA security, I must explain a bit more the syntax of CAA. So take for example this small group with three parties, Alice, Bob and Cindy, all in epoch I. The network will be called the delivery service, just an insecure service that delivers messages to users. And in this work, we adapted the so-called propose and commit syntax of CAA, which is also the syntax used by the MLS working group, so we wanted to match that. And this means that there are two types of messages. There are proposal messages and commit messages. So proposal messages do not create new epochs yet. They are just proposals to change the group state in some way. For example, Alice can propose to add a new member Dave. She sends a proposal message and that's it. The next type of proposal is to remove someone. So let's remove Cindy and Bob posts P2. The final type of proposal is to update. So if Cindy has been storing her keys for too long, she wants to refresh her secrets. She sends an update proposal P3. And this does not create the new epoch. The new epoch is created in the commit. So what Alice does to commit is she first collects a bunch of a list of proposals, for example P1 and P2. She didn't see P3. And then she sends two messages, a commit message C and a welcome message W. So the commit message is meant for the current members, the welcome message to transition to the new epoch. The welcome message is used by the new members to join the group. And Alice does not transition yet. She waits to receive her message or act back from the network. To process a message, to transition to the new epoch, parties process a message. For example, Bob processes C and transitions to the next epoch. He gets some updated group information. And Dave can join using the welcome message posted for him. So to recap, there is a proposal, message P, no new epoch. There is a commit message C and there is a welcome message W that do transition to the new epoch. And some of the transitions to the new epoch should heal from parties compromise. And the general rule is that a transition or a commit heals Alice from her compromise if either the commit C was sent by her or if C contains a update. So if Bob commits Alice's update proposal, it also heals Alice. So it can heal many parties. So with this syntax, we can now define security. In this work, we model CGK security in the UC framework, in the Universal Composability Framework, where security is defined by comparing the real world where parties run the protocol with the ideal world which is secured by design. If it's indistinguishable, then this means that the real protocol is as secure as this ideal secure by design ideal world. So this means that in the real world, we have a bunch of protocol instances, for example, one for Alice, one for Bob, one for Cindy, and an environment set that drives the execution. If you're not familiar with UC, you can think of this environment as your adversary who drives the execution. You should challenge and try to guess the bit real key or random key. So what happens if Z instructs Alice's protocol to remove Bob? Normally, the protocol would send this proposal message P. So in this work, we model arbitrary networks by routing the messages via the environment set. What this means is that now the protocol hands back the message P to Z, and then Z can tell, for example, Cindy's protocol to commit P. So this is maybe a bit non-standard for UC, but it has some advantages. For example, it excludes trivial protocols that drop all messages. It allows us to model robustness, which I'm going to talk about later. And Z can do other things. It can also, for example, request an epoch key, and Cindy's protocol tells Z what it thinks the current epoch key is. This is the real world. Now, to define security, we compare it to this ideal world, where we have, again, the environment Z who tries to distinguish, but this time it's interacting with instead of the protocol with these dummy parties to just forward all inputs and outputs to this ideal CGKA service, or ideal functionality F, who also interacts with the simulator, which is just an arbitrary protocol. So what happens if, for example, Z requests the epoch key? This is forwarded to F, and F, secured by design, samples a random independent key. And this model's security, right? Because it's indistinguishable from the real world where the key actually comes from the protocol. What about other inputs and what about messages? Well, messages don't really have any meaning in the ideal world, so we would like to say that they are arbitrary. And this is formalized by allowing the simulator to choose them. So they are arbitrary. So this is the framework. Now, what is left is to define this ideal functionality F CGKA. Just a disclaimer, we do not prove full use is security because of the commitment problem we restrict the environment not to perform certain corruptions. But now let's focus on defining the ideal functionality F. So for this, we first have to introduce the tool. The tool introduced by Alvin Coretti, Dodis and Selle Kunis is called history graphs. And a history graph is a symbolic representation of a CGKA execution in the asynchronous setting. So in more detail, a node in the graph, this will be a node, represent an epoch, so it has a fixed set of members and a fixed symmetric key. Of course, in an asynchronous execution, parties can be in different epochs. Different parties can be in different epochs. And this is represented by parties pointers. So a pointer of Alice stores the epoch that Alice currently is in. So this represents her view of the group. This graph can evolve. And sending messages is represented by creating nodes. So for example, sending proposal messages creates proposal nodes. So these nodes are not really epochs, are not epochs, but they are just these additional nodes. And they point to the epoch where they were created. Then when Alice sends a commit message, this creates a new commit node or a new epoch. And again, the pointer is from the parent epoch or the child epoch. That was, yeah. And finally, receiving messages is represented by moving pointers. So if Alice and Bob now receive Alice's commit message, they transition to the next epoch and we move their pointers. And this can go on. This can continue. For example, Cindy joins. There are more proposals. There can be two commits sent at the same time and parties can even disagree. So this actually represents a group split. Alice and Bob are in alternative epochs and they cannot communicate. They are out of sync. They cannot communicate anymore. So these are history graphs. And now the idea of CGKA service, the ideal functionality basically built such a graph inside based on the environments commands. For example, when Z tells Alice, when Z instructs Alice's protocol to propose something, the functionality creates new proposal nodes identified by the proposal messages. Recall that the messages are chosen by the simulator subject to being unique. Well, this is a restriction on the protocol, but reasonable in our opinion. And the message is given back to Alice, to the environment. Then Alice can commit. This creates a new commit node identified by C, chosen by the simulator. We also store the welcome message W if any was produced because a party was added. Alice can process the message and then this transitions her pointer and returns the group information Cindy can join. Using the welcome message. And Alice can request the key. And at this point, the functionality evaluates the safe predicate. This is a parameter of the functionality. Devaluates it on the current history graph and Alice's current pointer and returns either a random key or an arbitrary one chosen by the simulator according to safe. And we also store information about corruption. So nothing really deep happened yet. Things get interesting when we consider injections. So there will be some inherent injections. Like here if Bob's state leaks to the environment, this will allow the environment to come up with a valid looking message from Bob. So what happens if Z instructs Alice's protocol to process an injected commit C star, which the functionality has never seen before? Where does Alice transition now? Well, the solution is to create a new commit node with identifier C star and where the semantic is chosen by the simulator. So the simulator says this message was sent by Bob and this is the new group state and so on. And what guarantees does this actually buy? So we consider two types of guarantees, either weak robustness and the second one is called strong robustness. So for weak robustness, it means that if two parties accept C star and transition to this epoch, then they agree on all the relevant group info. Note that some group info is returned to Z and Z can always request the group key. So the functionality will always output the same values to every party who requests this in C star. And hence the protocol in order to be extinguishable also has to do this. So this is weak robustness and for strong robustness, we additionally require that if one party accepted C star, then any other party also does. So right now Alice already accepted C star, so this means that any other party will also accept it. So this is injected commit. Now another type of injection is injecting a welcome message and this actually is a bit more problematic. So what happens if the environment injects a message W star to Cindy? Where does Cindy join now? So first of all, we create again a new commit nodes for Cindy with identifier C star and semantics chosen by the simulator. C star is also chosen by the simulator. Now the problem is that we don't really know where to put C star in the graph. Now can we ask the simulator to figure it out for us? Unfortunately, probably not for efficient protocols because of this scenario, like imagine that set creates a very long chain of commits in his head ending in C star and invites Cindy to C star. Can the simulator come up with this long sequence of commits without including the whole history in the welcome message? Well, probably this seems unlikely. So what we do instead is to just leave this node detached. So now Cindy is in a detached node. This means that the history graph is not connected and in general think of it as a forest. Of course, what can happen later is that Z actually delivers all ancestors of C star Alice's Alice processes C star and then we connect the node. So this is it, of course, very much simplified, but this is roughly how we talk about active security of CGKA. Now let's move to defining the optimal safety predicate. So for this, let's look at an example history graph and the optimal safe will be false only in the following three types of nodes. First of all, if a party is corrupted while holding the key we want that if the key is outputted then it's deleted from the state but if a party is corrupted before that then the node is not secure. Second type is that our nodes reachable from our corrupt nodes where the messages corresponding to the edges can be processed via correctness. So on an example what this means here is that Bob's corrupted state can be inherently used to process Alice's commit message and hence the environment Z can use the state to actually compute the key in this node as well. And finally in all detached nodes safe will be false as well. Of course it might be true again if they're attached but in this work we focus on the guarantees for the main part of the history graph for the main component of the history graph and we do not model guarantees for detached nodes. This is because with our oversimplified PKI there is not much reasonable, there is not much we can actually guarantee for the detached nodes. We would need a better model of the PKI to give reasonable guarantees so we just don't guarantee anything for those. And in every other node the safety predicate is true. So for example in the bottom right node if Bob is corrupted and afterwards he commits this will restore security for post compromise security. So why are the existing solutions not optimal and they break basically here. This we called cross group attacks and here the siblings in the history graph share some group state and hence corruption in one sibling affects another sibling. So to be more concrete let's look at an example simplified protocol. This protocol is not efficient but it illustrates the main points. So in this protocol every party has a key pair for an encryption scheme so a public key and a secret key and he knows the public key of every other party. And to commit Alice sends a new public key for herself, remember she has to heal and she chooses a new group key K prime at random and she encrypts it for every other party. Bob of course decrypts. So this is vulnerable to cross group attacks. Why is this true? Well if Bob is corrupted in the top node so in the top node Alice sends Alice encrypts K1 in the bottom message Alice encrypts K2 and Bob's leaked secret key SK can be used to decrypt both Cypher texts. So if Bob is corrupted on the top he's also corrupted at the bottom. In this work we fix it with identity hierarchical identity based encryption or HYPE and this means that the protocol is would be modified as follows. Instead of encrypting directly to instead of encrypting using a normal encryption scheme to Bob Alice encrypts using a HYPE under Bob's public key and using an identity vector CB this vector contains all commit messages since PKB was created. And also importantly what Bob does upon process he updates his secret key with the last commit message C that he received. So now the key is delegated to subvector, sub identity. Why does it help? Well now the encryptions are made using this initial vector CB but Bob when he's corrupted he leaks the secret key updated with this commit C1. So this will definitely be different than the key updated with the commit C2 because they are different commits and hence it cannot be used to decrypt anything else, anything any of this type of text. And in general it can only be used in children of this node where Bob was corrupted. So this is our technique for the optimal security in the passive setting. Now the simplified protocol also has problems in the active setting. So forgetting about group speed attacks for a moment. In the active setting this protocol gives no agreement guarantees clearly. For example the environment can inject a safer text where it encrypts K1 to Bob and K2 to Cindy. Now Bob thinks the key is K1, Cindy thinks the key is K2. This clearly does not realize our ideal functionality. And we propose two fixes for this. The first fix is what we call the confirmation key. It's just explicit key confirmation. Instead of the key K prime Alice encrypts a seed S and publishes a hash of S and the key is another hash of S. So now the above attack doesn't work because maybe Bob will accept this but Cindy will say no, no, as two doesn't match the hash I reject. This is very efficient but offers weak robustness. And the second fix is uses general physics and we basically prove that the two plain texts contained in the ciphertext are the same roughly. This offers strong robustness but it's less efficient. And by the way we also prove only static security for the latter construction. So yeah, these are our protocols. They can be, so these are our techniques showcased on an example of a simplified protocol but they can be extended to, but in our paper we instead modify an efficient protocol and modification of 3CAM. So this concludes my talk. Thank you very much.