 Universal Composition with Responsive Environments by Ian Kaminich, Robert Underline, Stephen Crane, Halvküsters and Daniel Roche, who is giving the talk. Thank you very much for the introduction. Today I'm happy to present you our work on universal composition with responsive environments and I want to start my talk with a very brief recap of universal composability models so everyone here is on the same page. Universal composability models use simulability to define security, which essentially works as follows. We have some real protocol P, which we want to analyze and we have an ideal protocol or ideal functionality, which perfectly defines some task in a secure way. For example, we might have an ideal functionality for key exchanges. Now, P realizes this functionality or P is secure. If for all possible adversaries that try to attack P on the network, we can find an ideal adversary or simulator that attacks F on the network such that no environment can distinguish both settings. Or in other words, it does not matter whether we attack P on the network, we might as well attack F instead and get the same kind of information. The main feature of these models is their modularity, which allows for reusing security results. This works roughly as follows. Let's suppose we have already shown that some real protocol P realizes an ideal functionality F. For example, we have already shown that we have a key exchange protocol. We might now want to build another protocol, Q, which serves a different purpose. Say for example, we might now want to build a secure channel protocol and this protocol Q can reuse the ideal functionality F for this purpose to show that it is possible to realize a secure channel. Once we have shown this, we can use the composition theorems from these frameworks to automatically conclude that even if we replace F with its realization P, the resulting protocol will still be a secure channel. Of course, we can iterate this. For example, we can now build a protocol on top of F' which uses the secure channel and once we are done with analyzing this protocol, we can replace F' with its realization Q and P. There are lots of different models that use this approach. However, our work is model-independent. We have exemplified this by applying it to these three major models. So what exactly is the problem that we addressed with our work? In the following, I am going to explain what urgent requests are and why they cause what we call the non-responsiveness problem and then I am showing how we solve this problem entirely by proposing responsive environments. So when we model a protocol in the universal composability models, we often have to exchange some purely modeling-related meta-information with the adversary. There are several possible examples for this. Protocols often ask the adversary to provide a corruption status for the protocol to model that the protocol is secure both when running in an honest environment and both when running with corrupted protocol participants. Many protocols also allow the adversary to choose or provide some cryptographic material. For example, this is often done by ideal protocols which might ask the adversary to provide some keys to model that they are secure even in a setting where the key distribution is arbitrary. Sometimes we want to leak information to the adversary, for example, to model honest but curious corruption. In this case, the adversary gets to see the entire internal state of a protocol without being able to influence the actual protocol run and sometimes it's necessary to signal that some event occurred. For example, we might want to tell the adversary that a new protocol instance was created. All of this is easily done by just sending a simple message over the network to the adversary and these messages are what we call urgent requests. Urgent requests have one important property, namely they do not model any real network traffic. If we were to look at an implementation of this protocol P in reality, this message would simply not exist. A real protocol does not ask, am I corrupted on the network? It also does not ask the network to provide some algorithms to use. So instead, the protocol run would continue without giving a real adversary any way to interfere with this protocol run. So if we go back to our security model, it would be natural to require the same from our adversary in the security model. He should also allow the protocol to continue its run without interfering in any way by simply providing the expected answer. The adversary should just tell, for example, whether the protocol is corrupted or not. It should just provide the keys that it was asked for. It should just return control if, for example, the protocol signaled that some event occurred. While this is quite natural, this is actually not the case in any of the current universal composability models. Instead, our adversary in these models is actually much more powerful than any real adversary as he can abuse these urgent requests to mount distinguishing attacks. For example, the adversary might choose to activate the protocol in an unexpected way instead of answering an urgent request. So this might look as follows. Once he receives the urgent request, he sends a message to the environment, and the environment, in turn, can now send some IO input to the protocol, which the protocol might not even be able to process as it is still waiting for response from the adversary. The adversary could also try and change the state of other parts of the protocol in between, which might look as follows. Here we have a protocol P, which has a subroutine F, and the adversary is free to interact with F in arbitrary ways before it returns control to the protocol P. So every real protocol has to keep this in mind that other parts of the protocol stack might have changed the state before receiving a response. And even worse, there are even cases where the adversary can block parts of a protocol entirely. For example, if the subroutine needs some algorithms to perform its task, it might ask the adversary for these algorithms, and by simply never providing the expected algorithms, we now have a situation where F cannot do anything anymore. It's effectively blocked. If the adversary now activates P instead, P has to deal with a blocked subroutine. Altogether, we are in a situation where protocol designers have to deal with a lot of unintended adversarial behavior, which importantly does not relate to any attacks in reality. Dealing with this is quite difficult. In some cases, it might not be possible at all, and if it's possible, it complicates protocol specifications and proves quite a lot. Also, because it's so very unnatural to think about these artificial attacks that do not relate to anything in reality, it's often forgotten in the literature, which in turn leads to under-specified protocols, flawed security proofs, where the composition theorem can no longer be used, and functionalities that cannot be reused to build new protocols on top of it. This was quite theoretical. I want to illustrate the use of urgent requests by showing you some examples from the literature and showing you what exactly can go wrong. In the following examples, it's not so important to understand every detail of these functionalities. I've highlighted the sections where urgent requests occur, so please look at the highlighted parts. Here we have an ideal functionality for non-interactive key exchanges, and this functionality, in case one of the participants is corrupted, sends an init request to the adversary and expects a session key in response. This is a very natural system. If the session is corrupted, then the adversary should be able to choose the session key of the key exchange. However, by using this system, we actually end up in a situation where f9 no longer is non-interactive. The adversary gets activated, so a higher level protocol that has just called this functionality to provide a key now has to deal with activations by the adversary. Even the authors acknowledge that this is quite unsatisfying, but at the same time it's really the best one can do in current models if we want to allow the adversary to choose the session key. Here's another example, an ideal functionality for signatures of knowledge. This functionality has a setup phase where it sends a setup request to the adversary and expects to receive several algorithms in return. However, the adversary is of course free to never provide these algorithms in which case the functionality has to operate on undefined algorithms which can lead to problems if we want to reuse this functionality in another realization. We might end up with a distinguishing attack based on this. This is an ideal functionality for certificates and this functionality contacts the adversary to verify certificates. It expects some value in response which is then used in case the signer of the certificate is corrupted. So essentially once the signer is corrupted the adversary may choose freely whether a certificate is accepted or not. However, by activating the adversary the adversary is free to quickly corrupt an honest signer before returning control which in turn allows an adversary to accept invalid signatures even though they should have been rejected. The authors also provide the realization of this functionality which is a nice example to illustrate two other aspects of the non-responsiveness problem. This realization uses an ideal subroutine called fsig to sign messages and of course it expects an immediate response from the subroutine. Signing is some local operation so it should just return the signature immediately. However, this is actually not the case fsig uses urgent requests for signing messages so once it receives the sign request the adversary gains control and is now free to mount one of these distinguishing attacks on the protocol. This illustrates that the problem propagates throughout the whole protocol stack there is at least one subroutine using urgent requests then all higher level protocols have to deal with unintended adversary behavior they have to specify in particular what happens if they send a message to a subroutine as they're waiting for response and for example receive some message on the network or on the IO interface in between. Sadly, this is not done in this realization as you can see here this realization simply assumes that it immediately receives a signature from the subroutine it does not state what happens for example if it now receives a message on the network instead. I can illustrate another aspect of the problem using this example suppose for a moment that we did not build this realization using the ideal functionality fsig but instead try to build it directly on the realization of fsig called psig of course this goes against the spirit of universal composability models we want to use ideal functionalities to simplify our analysis they are conceptually very simple and then we want to get the replacement with their realization for free using the composition theorem however if we had defined the whole realization like this then p would actually be well defined because psig indeed immediately answer signing requests there are no urgent requests involved anymore so p does not have to deal with any activations by the adversary or environment in between. All together we have a situation here that shows that idealizations cannot express certain properties that might be present in realizations we could end up in a situation where we can prove the protocol secure using a realization but we cannot prove it secure if we had used an ideal sub-poutine instead which is really undesirable and goes against the whole spirit of the universal composability frameworks which try to replace parts of a protocol iteratively with ideal functionalities so as we have seen in these examples it's very important that protocol designer specify what happens if a protocol is still waiting for a response from the adversary or sub-poutine but receives a message on the network from the adversary or an unexpected message on the IO interface instead. There are several possible work-arounds that one can try to apply to get a full specification for these cases perhaps the most intuitive one is just to say I'm still waiting for a response so I will drop all other messages that I receive I will just block them. Alternatively we might also be so nice and just return an error message that tells other protocol parts that we still waiting for some response from the adversary. Maybe we could try to queue new requests and process them later on once the adversary was so nice to answer our urgent request. We could also try to reduce of urgent requests by using code upload constructs or in some cases it is possible to resort to a default. For example if we wanted to receive some algorithms from the adversary and the adversary does not provide these algorithms in time then we could use a default algorithm. However we have shown in our paper that none of these work-arounds is generally applicable instead protocol designers always provide solutions that are specifically tailored to both the realization and idealization they are currently analyzing and in any case these solutions just unnecessarily complicate both the protocol specification and in turn also the security proofs. Furthermore even if we have gotten a full specification we still have to deal with the unintended state changes the idea certification functionality led to a situation where it accepts invalid signatures or certificates and the limited expressivity of UC models. So how did we solve this mess? We propose responsive environments and responsive adversaries which essentially behave just as one would expect. So in our framework a protocol can specify that some message M on the network is actually an urgent request by simply adding a prefix to this message. Once the adversary receives such a message he is still free to communicate with the environment in arbitrary ways. However we have blocked all unintended communication path to the protocol until the adversary provides the expected response. Afterwards the protocol run can just continue as expected. So if we go back to the previous slide where I introduced a non-responsiveness problem and showed you several types of possible distinguishing attacks then we can see that using our framework none of these attacks work anymore but the adversary Raza behaves as a real adversary he is no longer more powerful than any real adversary. So our framework provides a very natural solution to the entire problem and at the same time it's quite simple it's really just adding a tag to a message to get an immediate response and it does not involve any additional complications that one has to show during security proofs. It can even be applied retroactively to the literature so for example if we have some functionality from the literature which is formally under specified we can use this framework to make sure that the specification actually is formally correct and it is model independent we have exemplified this by applying it to the three major models of the UC model the IITM model and the GNUC model. In case of the IITM model we also provide full details including formal definitions of urgent requests, responsive environments and responsive adversaries we define various security notions from the literature in this framework and show that all of them are still equivalent which serves as an important sanity check for our framework of course all security notions are still reflexive and transitive and perhaps most importantly we have shown that even though we reduced the power of environments and adversaries they are still strong enough to show all composition theorems of UC frameworks. So let's go back to the examples from the literature and see what our framework can do for them. Here we have the ideal functionality for non-interactive key exchanges again and this functionality uses an inert request to receive a session key if we simply add this single tag to the inert request we are now indeed guaranteed that the next message that it receives will be the session key so from the point of view of a higher level protocol the adversary is no longer able to interact with any higher level protocols that use f9 to generate a key so from the point of view of a higher level protocol this functionality now is indeed non-interactive. In case of the ideal functionality for signatures of knowledge if we add this respond tag to the setup requests we are now guaranteed that we will receive all algorithms immediately the adversary is no longer able to let this functionality operate with undefined algorithms in case of the ideal functionality for certificates by adding this respond tag to the verify request we make sure that the adversary cannot change state of the signer anymore so in particular it also cannot let the functionality accept invalid certificates of course we can also apply our framework to the realization of this ideal functionality in this case we change the urgent requests of fsig and now fsig can indeed provide an immediate response to signature requests the adversary can no longer interact with the protocol in between and fsig can now model properties that are present in its realization so to summarize my talk protocols very often use urgent requests to exchange some purely modeling related meter information and because these urgent requests do not exist in reality so a real adversary cannot abuse them for any attacks it would be very natural to also require the same from our adversaries in the security model however they are in fact more powerful they can abuse these requests to try and distinguish the real from the ideal protocol this dealing with this problem leads to complex protocol specifications and security proofs there is no simple and general solution that can just be plugged into the protocol specifications to deal with this problem it limits the expressiveness of UC models and perhaps most importantly because it's so very unnatural to think about this stuff it has often been ignored in the literature leading to under specified protocols, flawed proofs for other real protocols we provide responsive environments to solve this problem entirely they are very easy to use they really just involve the single tech that you can use to prefix messages and then everything works as expected and they can even be applied to literature retroactively where problems are we want to encourage you to use our framework it just makes your life so much easier by bringing an adversary from our security model to the level of a real adversary thank you very much for your attention is there any question? if there is no question let's thank Daniel again