 Hi everyone, my name is Yanis and I will present our results on messaging lay security This is a joint work with Joel, Sandra and Evgeny. First I'll give some context by comparing secure messaging with secure communication and highlight the differences. So in secure communication, we assume reliable channels between parties So there is no message loss Communication is synchronous and sensors are typically short lived Parties are online during sessions and resilience to compromises of minor concern On the other hand on messaging Channels are unreliable. So messages may be lost Communication is a synchronous users might send messages and then go offline Sessions are long lived they might last for years and this is why state compromise is very likely to happen over the lifetime of a session In the two-party setting for messaging we have the success story of the signal protocol Which is loosely based on the of the record protocol it is used by billions of people and By many applications like signal Facebook Messenger. What's up and Skype? It won the Levin prize at real-world crypto And its security is very very well studied and very well understood So what about security of messaging for groups? So the naive approach would be basically to use a two-party protocol in a pairwise manner however, this solution Is highly inefficient it requires complexity and square So we need something much better than that and this is the purpose of message-less security So I'm a less started about two years ago and currently we have its night version The goal is to standardize a protocol for secure group messaging With all again message complexity where n is the number of users There are many contributors in this project both like from the academia like many universities and also the industry The functionality provided by MLS is like the following parties can basically Join a group when they're invited by group members. They can leave group at any time They perform updates to refresh key material And they can also send and receive messages The attacker controls the network and the server He sees all packets transmitted in the network. He can change packets and he also controls message delivery It can also leak the state of group members The MLS design considers several modular components and there is lots of inspiration from the two-party setting This is similar to the ACD-19 paradigm in ACD-19 The offer show how to modularize the double ratchet using three primitives namely continuous key agreement Which is the public ratchet Forward secret of the negated encryption, which is a symmetric ratchet and also the glue between them, which is the PRF PRNG So ACD-19 shows how to compose those three primitives and build to party secure messaging Now the good news is that the ACD-19 paradigm also applies to MLS Of course by considering the group variants of the corresponding primitives So here we have a continuous group key agreement and and party forward secure authenticated encryption and also signatures for authentication in our work we focus on the continuous group key agreement primitive In more detail the contributions of our work are the following We provide a formal security model for CGKAA We also proven that security of the CGKAA protocol that is proposed by MLS Which is called Trichem and their main surprise is here And we also propose a modified version of Trichem that achieves better security So now I will present the simplified version of our CGKAA security definition Our primitive supports the following functionalities group creation first of all so user you can create a group G A member you can add a non-member V to the group by executing add and similarly for remove So a member you can remove another member V from the group We also have the update operation which basically refreshes the group state and this is important for security as we will see later and Then we have the process operation which enables processing of control messages generated by the above operations The goal is to synchronously maintain a search secret in a dynamically changing group So protocol execution proceeds in epochs And with each operation we have a new epoch and a new group secret So for instance consider our example So here we have group creation by party a and we're an epoch number one with group secret I1 Then B is added and we move to epoch number two and new group secret and Then B updates C is added C updates and A is removed So the group secrets are basically used by full messaging by the high-level protocol to refresh keys now the adversary Controls the network and the server. He sees all packets transmitted in the network, but he cannot modify them so this is one restriction another one is that It controls message delivery, but it must deliver all messages in the same order to all users So those two points are basically handled by the high-level protocol How basically using signatures? So the adversary would not be able to modify packets if messages are signed and also You can protect the order of messages by passing the transcript So besides that the adversary fully controls the sequence of operations you can ask users to update their state To add other users or to remove users from the group and also he can leak the state of group members The privacy guarantees that we require is that group secret should look random to the attacker unless they are trivially known and Since Sessions are long-lasting. We also require post-compromise security. So we should be able to recover from state compromise Via normal protocol execution and also we require forward secrecy which basically Means that privacy should hold even against future state corruption state compromise Now consider an adversary that challenges epoch I So the question is like is epoch key also known as update secret of epoch I secure Let's see the notion of optimal security optimal security which implies PCS and FS Requires that all users that are corrupted at epoch J prior to I or less Vanu equal to I issue an update operation at some epoch T in the rates J plus 1 comma I so basically this means if you have corrupted users before epoch I Those users just need to issue an update operation Before epoch I we also allow corruptions after epoch I and we also consider Two weaker notions of security forward security in isolation in which first corruption Can happen only after the challenge epoch and Also PCS in isolation Which is like optimal security like optimal security, but no corruptions are allowed after the challenge epoch Now I will present The cgk protocol which is proposed by MLS called tricking Tricking was initially proposed in the MLS mailing list in 2018 and it's based on an early work on asynchronous ratcheting trees The bucket size is all again And we also have subsequent work, which is causal tricking Tainted tricking and also actively secure cgk which is a completely different protocol For this talk, I will omit add and remove operations and I will assume that no user is left behind Meaning that all users process instantly all messages all control messages generated by operations Our paper handles the general case So we only focus on update and corrupt operations for study groups and as we will see this is still on trivial and captures the main difficulties So the goal is to maintain a shared secret in a study group tricking uses a tree-based structure So members group members are arranged at the leaves of the tree. So here we have eight members each note consists of a public and sacred key for public encryption and The invariant is that part is known only the secret keys on the path to the root So this party here knows the secret key for this note this note this note and this note The root note is a special note, which I will Refer to it In more detail later So here we have eight parties and the I'd leave corresponds to the I'd party from the left to the right Let's see how the update operation works on tree game Assume that party one which is the first leaf Executes an update operation the operation is basically using Calls to a PRG which is denoted by age So what party one does is the following it samples s0 a uniformly random seed s0 and computes the PRG over s0 This gives a new seed s1 which will be used in the higher layer and Also gives and secret key SK0 This is the secret key the new secret key for this note From this secret key we can also derive pk0, which is the public key of the note then we go to the next level and Then using s1 we compute the PRG over s1 and we compute the seed For the next level s2 and we also compute the secret key for this note and Using us through here We can compute the seed for the next level and the secret key for this note now The thing is that s3 is basically the update secret Is the secret or the group secret is the secret that is being computed that needs to be computed by by all group members So this is how the update operation works from the view of like party one and this is how party one updates that The tree how do other group members compute i how do other members compute the group secret? What party one does is that and it encrypts the seeds as i using The public keys of what we call co-path nodes so basically s1 is encrypted Under the public key of node a and since party two knows sk a it can recover s1 and compute all the secrets to the root Similarly Party one encrypts s2 under pkb and since all those two parties 3 and 4 they know skb because this keys in their path to the root They can decrypt the cypher text recover s2 and compute s3 again and the same for node c and those four parties those four parties here from 4 to 8 they know skc and they can directly recap decrypt the cypher text and recover s3 For forward secret c we need to delete intermediate values So the SI values that we computed earlier need to need to be deleted and also Forward secrecy as soon as the group secret is being processed by the high-level protocol. It needs to be deleted from the state However, we observe that the cypher text that have been generated by the update operation Have been are known to the attacker because the attacker has access to the network traffic So what we observe here is that if at some point in the future the adversary via some corruption Manages to learn ska or skb or skc, then he's able to compute The update secret generated by party one now. Let's see an example that illustrates issues with three games forward secrecy From now on we just write epoch numbers and We use the cross for blank nodes. So initially all nodes in the tree besides the leaves are blank we still have eight users and the leaves store the public and secret key of each user which Like we refer to as a need keys. This is a term used by MLS So party one executes an update along the brown path and refreshes all keys along the brown path and also computes a new update secret and We move to epoch one Party three executes another update operation. So we have fresh keys along the red path Then party five executes an update along the green path and Refreshes all those keys and finally party seven executes an update along the yellow path now the question is whether The update secret for epoch four is secure We introduce the notion of a bomb. So a bomb is a key that lets the adversary recover The update the update secret for epoch four So observe that information about epoch four update is encrypted under keys of nodes with a Yellow bomb So when party seven executes the update operation, it basically encrypts this secret Under the secret key of this node. This is why we have a bomb here Also, this secret is being encrypted under the secret key of this node This is why we have another bomb here and finally the update secret is being encrypted under the secret of this node So we have a third bomb So each update operation generates log n bombs. Are those the only bombs that we have? The answer is no and We can see why by checking previous update operations When party number five issued the update operation the secret for this node was encrypted under the secret key of this node So here we have a green bomb. This green bomb basically says that the secret key of this node Enables the recovery of the secret key and the update secret for epoch three, but the recovery of this secret Basically enables the recovery of the secret for epoch four Similarly for previous update operations like for the red path for this update When user number three executed the update operation he encrypted this secret under this secret key This basically implies that we have a red bomb here that allows the recovery of the red path But if you recover the red path you can recover this secret key and the discovery of this secret key Enables the recovery of epoch secret four due to this bomb similarly for for this node and Of course for the first update and the bomb that we have here So forever for every level I we have two to the I minus one active bombs Which implies that half of the leaf keys are bombs So by corrupting any user Still holding a bomb implies Security breach for a pop for secret What if users update so can the update operation help us, you know make things better Assume Parti six issues and update operations operation alone along the great path Then this update operation overrides all the keys in this path. So some bombs are diffused Making critical keys inside those bombs no longer accessible since we override this path Those secret keys are erased so are no longer accessible the thing is that At most one bomb is being diffused per level I with each update operation We have n over two leaf bonds and this implies that we need at least n over two updates to diffuse all bonds So every update has n over two keys at least which allow to recover new secrets Why is this a problem because forward security takes a long time to kick in and Each update overhead at most one leaf key So we need n over two epochs to get forward security even in the best case even if nobody's corrupted yet however forward secrecy Requires Security after a single update So in the worst case We will never achieve forward security if the right people don't perform and don't perform an update operation So trick em achieves less than ideal forward security even under the most favorable circumstances In our paper will characterize precisely the set of secure keys given the sequence of attackers queries We use the notion of graph reach ability on key graphs And we basically saw that The level of security achieved by trick em is very far from optimal The question is can we do better? Can we do optimal? And the answer is yes, we can By replacing standard public encryption in trick em with updateable public encryption. We get an optimal secure scheme For cdka This notion of updateable pke is closely related to key updateable pke, which is used in the two-party setting for secure messaging by JMM 18 Our idea is inspired by proposal of Conrad in the MLS naming list And basically the intuition is that this updateable pke It gives you practical forward security Let's compare updateable pke with standard pke So in standard pke we have key gen which generates public and secret key the encryption operation generates a ciphertext Over the message in the public key and the encryption recovers the message for correctness Senders need not to be synchronized and cpa security requires encryptions of any two messages to be in distinction Now for updateable public encryption the cdx has as follows key gen Outputs a new public key secret key pair pk0sk0 then the initial keys and The encryption operation receives public key and message and outputs a ciphertext together with a new public key So the encryption operation refreshes the public key became Refreshes the public key the description operation receives a secret key and ciphertext and produces the message But also produces a new secret key which basically this secret key needs to be synchronized with this public key here for correctness we require all senders to be synchronized and this is guaranteed by the MLS assumption and And also Encryptions of any two messages are indistinguishable like for cpa security even given the secret key Obdained after decrypting the challenge ciphertext So the idea here is that even if the adversary is given see I SKI and pki he cannot recover any information about SKI minus one and Basically, this means that mi is still protected. So this it gives you like forward security our update of public encryption Construction is based on El Gamal and the random oracle model and is similar to jam jam and 18 And now let's see how this new protocol works our tricking which stands for a re-randomized tricking As soon party one executes an update operation The update operation is very similar You generate basically the seeds along the direct path and then you encrypt with respect to the circle nodes as we did before However, the scheme that you use now is a bit of public encryption instead of standard public encryption So as one here is encrypted under the public key of node a The encryption operation generates CA but also re-randomizes the public key and produces a new public key pka a prior also the description operation over CA Recovers as one but also produces a randomized Key SK a prime and the same happens for nodes B and C like encryption other PKB of s2 produces CB and a new public key PKB prime and also the encryption of CB Produces a new secret key and now the idea is that if you have corruptions If the states of the users are linked to the adversary, let's say for this node Then the adversary learns SK prime a but By recovering SK prime a does not break security of Of the scheme right so SK a remain secure and S1 remain secure and the same happens If you have States that are leaked for those nodes and also for those nodes So here if you if you have users Compromise users here then the adversary learns SK prime B, but it's not recovering SK B or s2 So this is the main idea in the paper. We have more results We have security against that adaptive adversaries and we also propose future directions and open programs for secure group messaging There are also other stuff like multiplicative UPK for a little girls You can check the post by jail in the MLS mailing list and Also a draft on this topic and basically the that's all I had to say and This is our imprint version of the paper and thank you