 Hello, my name is Lisa Melidio, and I will be talking about our paper, Symmetric Key Exchange with Full Forward Security and Robust Synchronization. This is joint work with Colin Boyd, Gareth T. Davis, Paul DeCoek, Kai Gellat and T. Boyaga. In this paper, we are looking at authenticated key exchange for very constrained devices, but we still want to achieve desirable security properties. For this purpose, we want to look at only symmetric key primitives, as they in general require less resources than public key primitives. Another benefit of protocols relying purely on symmetric key techniques, such as hash functions and symmetric encryption, is that they can also achieve post-quantum security. So we want to achieve symmetric authentic key exchange from pre-shared keys, and we want to keep desirable security properties such as forward security and concurrent correctness. Typically, forward security is achieved with ephemeral keys using, for example, Diffie-Hellman. However, for symmetric keys, we don't have a similar technique, and using traditional long-term symmetric keys will not protect previous sessions upon corruption. A natural way of overcoming this issue is to evolve our symmetric keys in such a way that finding the previous key and thus ending the previous session keys would be impractical. When we use evolving keys, we run into a synchronization issue. We need some way of ensuring that both parties have evolved their key, the same number of steps from the starting point. If the parties become out of sync with no means of recovery, then our system is broken. Another problem we face is correctness in the presence of multiple concurrent or parallel sessions. We want to make sure that we don't have sessions where the parties accept a different session keys. We have proposed two methods of overcoming this issue. One way is by keeping a counter that counts the number of steps the key has been advanced, and the other way is by making use of a puncturable pseudo-random function. More on this later. In this paper, we present a suite of key exchange protocols. Three of these protocols are very efficient and make use of a linear key-evolving scheme. These protocols also achieve the weak synchronization property that we will see later. In order to address the challenges we face with linearly-evolving keys, we also present two protocols which make use of puncturable pseudo-random functions for key evolution. And this allows them to achieve the full synchronization robustness properties. We also provide a formal framework for protocol analysis. We describe the AKE model and also note that this model lacks any formal notion of concurrent correctness. Therefore, we formalize the security notion of synchronization robustness which captures the ability of re-synchronization and concurrent correctness of the protocols. This security definition is a novel modeling of availability as a security property, and this is our most important contribution to the security model. We will see some more detail on this later. So what we're trying to achieve is authenticated key exchange, AKE, for short, with very constrained devices. And thus, we choose to do this with pre-shared symmetric keys and only symmetric key primitives. Alice and Bob want to exchange a session key, and they each have the pre-shared key, KAB. They run a key exchange protocol by sending messages to each other. They use the pre-shared key material to convince each other that they are, in fact, the person they're claiming to be. And if Alice and Bob are both convinced of the identity of their partner and all of the messages were delivered and accepted, then they both derive a session key. Forward security is a property that ensures that if a party is compromised, then any previous session still remains secure. Specifically, Alice and Bob are sharing a symmetric key, KAB, and they run the AKE protocol to get a session key, KS1. At a later point, they run the AKE protocol again and get a new session key, KS2. If our adversary, Eve, now compromises Alice, Eve will get access to the shared symmetric key, KAB. Depending on how the key state is and how we define corruption, Eve may also get access to the second session key, even if she is unable to recompute it from the shared symmetric key. However, Eve will not be able to get access to or recompute any previous session key. In particular, Eve is unable to recompute the first session key, so the first session is protected against the adversary. Using symmetric keys in the traditional way does not give us forward security since all of the key material is static. In order to overcome this, we evolve our symmetric keys. If we, after deriving a session key, evolve our long-term symmetric key in such a way that it's not convenient to find the previous version of the key, then any past session will be protected from the symmetric key being compromised. There are essentially two strategies to evolve the key. Either time-based or triggered evolution. Time-based evolution was first described by Dusty and Jalili in their paper from 2015. This means that the parties agree that they will evolve their key after a specific amount of time, for example, every day or every hour. This means that within this time, which we call an epoch, any past session remains vulnerable, but any session from previous epochs are protected. This is a weaker form of forward security, but may in some cases be acceptable. This method does require synchronized clocks on the devices in use. Since we are considering very constrained devices, this is not an assumption that we are willing to make. Therefore, we use triggered evolution. Triggered key evolution essentially means that we evolve the key every time some specific event occurs. In our case, any time a session key has been derived by a party, we evolve the key. So immediately after session key derivation, the key is evolved and we are no longer able to recompete the session key. Since we're using triggered key evolution, where each party evolves their key after they have derived a session key, we run into a synchronization issue. Both parties need to have evolved their key the same number of steps in order to derive the same session key. This is in order to achieve correctness of our AKE protocol. Another significant challenge is how can we ensure correctness when we allow concurrent protocol sessions in parallel. The problem is that the requirement of all forward security and concurrent correctness seem incompatible with our first attempt at key evolution. In the case of two parallel sessions, we have that one of the sessions may advance the key too early, such that the other session is unable to complete. Note that this is a problem even if we assume that all parties are honest and messages are reliably transmitted. It is inherent to the linear key evolution. In traditional key exchange protocols with forward security, this is not an issue since the long-term key material isn't changed and forward security is achieved using ephemeral keys. In order to overcome the synchronization problem, we propose two fixes. The first fix is more efficient using a counter to keep track of how many steps the key has been evolved. The other method uses puncturable pseudo-random functions. Puncturable PRFs are computationally efficient, but do require larger key sizes, so they are less efficient in terms of memory, but it also provides stronger security properties. In the table, we see the state of the art before this work for the type of protocol we are interested in. Before our protocols, there were two protocols presented by Avran et al in 2020. These protocols do not achieve synchronization robustness or concurrent correctness, but they do achieve forward security using only symmetric key primitives. It is surprisingly non-trivial to achieve these properties, and we will illustrate where this can go wrong and present our protocols that do achieve them. Let's have a look at one of our protocols. We call it LP2. This is a two-message protocol with fixed roles, meaning that the same party will always initiate the key exchange. We start out with Alice and Bob, and they have a pre-shared key KAB. They both also keep a counter that we usually call CTR, which is initialized at zero. Note that the parties will be synchronized before the first session, but we don't in general assume that they are synchronized, as we will see. The parties also share a MAC key, which is used for authentication. The MAC key is static, so there is no synchronization issue involved with authentication. Please see the protocol description in the paper or for the details on MAC generation and what is included in the messages. When Alice initiates a session, she will evolve her countering key to the next odd number, in this case, one. She generates a message with a MAC and sends it to Bob. Bob receives the message, he authenticates Alice, and if he accepts the message, he will set his own counter to the same value as Alice and generate a message with a MAC to send back to Alice. He will then derive the session key and evolve the shared symmetric key KAB, ending up with counter value two. Alice will receive this message, she will authenticate Bob, and if she accepts, then she will derive the session key and evolve the shared symmetric key KAB, also ending up with counter value two. Let's also have a look at a session which doesn't successfully complete. Alice and Bob both have counter value two from the last session. Alice wants to initiate a new session, and she will, so she will evolve her counter and key to the next odd number, which is three. She generates a message and sends it to Bob. Bob receives this message and authenticates Alice. If he accepts, then he evolves his counter and key to three, generates a message and sends it to Alice, and then he derives the session key and ends up at counter value four. However, the message is never delivered to Alice. If Alice now wants to initiate a new session at that point, she will be one step behind Bob, so she can't initiate a key exchange at the counter value she's at because Bob cannot go back to this counter value. Since Bob can get one step ahead of Alice if the second message is not delivered, Alice overcomes this by moving to the next odd number at the beginning of the session. If she was at an even number, this means that the previous session never completed. If she wasn't at an odd number, the last session had completed. Either way, starting at the next odd number, we'll put Alice ahead of Bob, making it possible to execute a successful protocol run. Therefore, Alice initiates the next session at counter value five. This strategy of choosing the next odd number to start a new session ensures that the new session can always be successful if messages from previous sessions were not delivered. Note that the protocol has fixed roles. If Bob could also initiate a session, then we could never be sure that the initiator would be behind its partner, and thus we could never be sure that a session could be completed successfully. Our linearly evolving protocols come in three variations. The two message protocol we have already seen, and two others, a one message protocol and a three message protocol. If we require a simpler protocol, we can go for the one message protocol. We naturally get only one-sided explicit authentication, but this is the most efficient way we can exchange keys. If we require stronger properties, we can use the three message protocol. This protocol gives mutual authentication and also has a provably bounded gap. This means that regardless of adversarial influence, the parties will never be more out of sync than the number of concurrent sessions. This property is proved in the state analysis. This protocol also allows the role reversal, meaning it is more flexible than our one and two message protocols. The table summarizes the security properties of our linearly evolving protocols. As we can see, they all achieve forward security and they all achieve weak synchronization robustness. We provide a framework that makes it possible to analyze protocols of this type. There are other examples of protocols of this type in the literature, which also achieve many of the desirable properties that we're interested in. However, we have not seen other protocols who satisfy all of the properties that we prove that our protocol satisfy. We give a description of the AKE model in which we prove our protocol secure. This model follows the standard approach for AKE models based on the Balarabargaway model and is very similar to the one presented by Lee et al in 2014. The AKE model doesn't have any notion of correct correctness or synchronization robustness. In traditional public key AKE protocols, we don't have the synchronization problem so the model doesn't need to handle this. However, for the symmetric key case with evolving keys, we need some way of analyzing this property. This is something we have addressed. The formalization of this property is our most important contribution to the security model and our framework for analyzing protocols is unique in that it models availability as security feature. Synchronization robustness captures the ability to compute keys in the future, no matter what happens either accidentally or by adversarial intervention now. Concorrect correctness is what we call the property that any protocol run that is allowed to honestly complete will succeed. We can see that for a linearly key evolving protocol such as LP2, if we have two concurrent sessions, at least one of them will fail. Again, Alice and Bob will exchange keys. They start out synchronized at counter value zero and now we will let them run two concurrent key exchange sessions. Alice initiates a session at counter value one. She sends the message to Bob who accepts the session at counter value one and concludes the session accepting the final counter value two and sends the message back to Alice. Before Alice receives the message from Bob, she initiates a new session. She has to start the session at the next odd number so she initiates with counter value three and sends the message to Bob. Now she gets the message that Bob sent in the session with counter value one. However, she has already evolved past this point so she cannot derive a key at this counter value. Thus she has to abort the session. Bob, on the other hand, gets the second message from Alice for a session on counter value three. He accepts this and completes the session accepting the final counter value four and sends the message back to Alice. Alice gets this message and since she has not evolved too far, she is able to accept this message and complete the session accepting this final counter value four. So with two concurrent session, the first session failed because Alice cannot go back to a previous counter value. This linear nature of the key evolving scheme makes it impossible for this kind of protocol to achieve concurrent correctness. The security property we call synchronization robustness captures the ability of successfully exchanging keys in the future, even if something goes wrong now. If the parties get out of sync for any reason, they need to be able to re-synchronize. We formalize this property and present it in two variants. Because linearly evolving protocols cannot achieve concurrent correctness, we define weak synchronization robustness which our linearly evolving protocols will achieve. Full synchronization robustness is achieved by our nonlinear evolving protocols. The weaker gradient of synchronization robustness captures the idea that no matter how much the adversary does to mess things up for Alice by initiating concurrent sessions, dropping, reordering and altering messages, making the parties go out of sync by arbitrarily many steps. In any case, the next time Alice and Bob are able to execute a session without interruption, that session will complete successfully. We synchronization robustness may not be achieved by a linearly evolving protocol. For instance, with our two message protocol LP2, if we drop the requirement of fixed roles, we may find ourselves in a situation where the initiator is more than one step behind the responder. And thus, when the next session is initiated, it will not succeed breaking the weak synchronization robustness requirement. Full synchronization robustness captures concurrent correctness. That is the requirement that any honestly executed and completed session will succeed. Even if the adversary is messing with concurrent sessions and interleaving messages from different sessions. Linear key evolving protocols did not achieve full synchronization robustness because if we're running two parallel sessions, then one of the sessions will trigger a key evolution first, making it impossible for the other session to succeed in deriving a session key at the counter value it was initiated. In order to overcome this limitation of linearly evolving keys, we present our alternative solution. As we have seen, our linearly evolving protocols achieve weak synchronization robustness, but it is not possible for them to achieve full synchronization robustness due to the nature of the key evolution. So we cannot get concurrent correctness and therefore we need a different way of evolving our keys in order to achieve this. Our way of solving this problem is to use puncturable pseudo random functions. A puncturable PRF is a PRF with an additional algorithm that we call puncture. So we have two algorithms, evaluation and puncturing. We evaluate in a point to get a session key and we puncture our key in the same value to make it impossible to recompute this session key. If we puncture on a specific value, then evaluating on that value later will return failure. And if we puncture on the same value twice, the second time will return no change in the key. Puncturing also have a commutative property, which means that it doesn't matter in which order you puncture the values. Note that the GGM pseudo random function is essentially a pseudo random function and we can in general construct a PRF by using hash-based evaluation in a tree structure. In our protocols using this, a nonce is chosen for each session and the session key is derived by evaluating the PRF in this nonce. After key duration, the shared key is punctured in this value so that it's no longer possible to evaluate the PRF in this point. Thus, we achieve forward security. Since the order in which you puncture values doesn't matter, any honestly computed session will succeed because any puncturing done by other sessions and other values do not affect this session's ability to derive the session key. The two protocols we present with non-linear key evolution are called PP1 and PP2. They have one and two messages respectively. These protocols achieve all of the properties we are interested in, full and therefore also weak, synchronization robustness, concurrent correctness and forward security. Lastly, we would like to summarize the security properties of our protocols and compare them to the protocols introduced by AB1 at AL in 2020. The sake and sake AM protocols do not achieve weak synchronization robustness or concurrent correctness, but they do achieve forward security. Our linear protocols, LP1, 2 and 3, all achieve weak synchronization robustness and forward security, but they do not achieve concurrent correctness. Our non-linear protocols, PP1 and PP2, using puncturable PRFs, achieve full synchronization robustness, concurrent correctness and forward security. These protocols achieve everything we want, but we do have to sacrifice some efficiency due to the nature of the puncturable PRF. Thank you for your attention. The paper is also available on e-print, and if you have any questions, you are welcome to contact one of the authors.