 Hello everyone, this is Reza Haymer and this is Oda Maliki. Today we are going to talk about a universal composability analysis of OpenStack, which is a joint work with Boston University and University of Connecticut. We will talk briefly about cloud competing and OpenStack and security concern around them. Then we will introduce universal composability as a security analysis tool. We will see why we think UC is a good choice for OpenStack security analysis. Then we will explain the analysis approach and the steps needs to be done and finally a conclusion will be given. As you know, cloud platform enable cloud computing. It is a middleware which sits over your hardware infrastructure and provides a software interface for the admin of the system. Using this interface, an admin is enabled to define virtual software defined isolated computer network and data storage. Now you can set up your application on any of these virtual computer network. Scale them up and down by just clicking some software button. You have your own computer network for installing and using your application, a dedicated network just for your application. It looks perfect, but there are many issues in the real world. Let's count some of the most important ones from security perspective. First of all, cloud platform involves huge code base, software remind bug for software engineer, bigger software more bug. Usually several application are executed on the same cloud platform. Are those really isolated? Of course not. All cloud application are using the same infrastructure. Although they are virtually isolated but still many attacks like side channel attacks are possible. Also as I mentioned before, cloud platforms have many bugs. So the isolation provided by this platform is not reliable. Each application has its own user with different privilege and capabilities, and some cloud services are open to public. In practice, the cloud serves many people. So it is an interesting target for hackers. Number of hackers that are attracted to the cloud services are growing rapidly and privacy of users and data confidentiality are in big risk. OpenStack is a cloud platform, so it suffers from common cloud platform issues. It is widely used platform, so it is very attractive for hackers. OpenStack mostly deployed as an infrastructure as a service. It means the OpenStack users has high privilege. High privilege means high risk. OpenStack has a huge code base which is deployed by different communities around the world. That makes security analysis that make security analysis of OpenStack very difficult. It goes even worse if you know there is not clear security model for OpenStack, and the APIs between the components are not well defined. OpenStack make use of many plugins, and almost in all cases, admin have the right to choose between bunch of plugins, and each plugins has its own vulnerability. All of these issues shows why security analysis of OpenStack is very important. Let us introduce universal composability as an approach which is useful for security analysis of OpenStack. Let's first see what is universal composability. It's a general purpose model for security analysis of crypto protocols. It's actually perfect for modular systems where the interaction between modules are very important, and it actually provides this common understanding and common language of system securities. It has been actually introduced by Ron Kennedy in 2000. The protocols that are defined, the UC actually remain secure even if arbitrarily are composed with other instances of the same protocol or other protocols. So this is an important property. The security is defined in a sense of the particle emulation. That means a protocol is emulating another one if there is no environment that can distinguish between the execution of these two protocols. For example, if we consider a protocol such as P1 to be secure per definition, so we say the protocol P2 emulates P1 if the environment is not able to distinguish between this emulation from the execution of the other protocol. In this language, we say that protocol P2 is actually as secure as P1. So our universal composability security analysis of OpenStack has the following goal. Better understanding of OpenStack security guarantees as in identifying the high impact security improvement and providing formal definition of OpenStack security related functionalities and study the security interface between the components. In order to achieve these goals, we are taking the following steps. We first are going to define the functionality of the ideal cloud. That is the protocol P1 in the previous example. Then we are going to define the functionality of the ideal component, which is a protocol P2 that is trying to emulate P1. And then show that the components realize the ideal cloud functionality, propose OpenStack modification to realize the functionalities, and finally propose component implementation that realize these functionalities. So let's look how we're going to do that. At the first step, we said we need to define the functionality of the ideal OpenStack. So the ideal OpenStack is actually an ideal black box which takes the actually does all the functionalities in accurate in no time. Now we have to consider that the user is in the environment, is part of the environment which could potentially be an adversary. In this step, we need to define the functionalities. These are some example of the OpenStack functionality, create node, delete node, and so on and so forth. Also, we have to consider that the F OpenStack here is an ideal system. However, the interaction between this F OpenStack and the environment is not ideal. That means we may have some information leakage which it may be influenced by the adversary. So the next step is to take a step down into the OpenStack. That means to split actually the OpenStack functionality into services, into actually several main modules which are the OpenStack services. Now all these services we are assuming to be ideal but the interaction between them as you can see is not ideal. That means we may have more leakages here because we split them up. This is how we make the Hybrid OpenStack. This is in a Hybrid OpenStack. Now we must inspect the new model and find out what are the extra leakages, how much they are important, and how we can mitigate them. If we're able to do that, we must show that the hybrid world and the ideal world are indistinguishable from the environment but we're not able to do it here because we have more leakage in the hybrid world. So therefore we're using simulator. The simulator actually needs to emulate the extra leakages. If the simulator is able to do these extra leakages, then we could say these two environments are indistinguishable from the environment. The next step is again to take each of these ideal services and split them into ideal components which make it more realistic hybrid world and we can repeat these steps until we get the real world. If we could go until that far, we say that the real world is as secure as the ideal one but otherwise we must provide some security solutions. As you can see the step-by-step UC analysis both the system bottlenecks and their issues. Here you can see the three words that we're talking about. The ideal one is on the left and the hybrid one and the real one. First we have to show that the hybrid world realizes the ideal one, then we have to show that the real world realizes the hybrid one. We talked about security issues of OpenStack and find out that the OpenStack security must be analyzed in depth. In this way UC is a helpful tool by applying UC. We will get better understanding of OpenStack security model and we will discover its bottleneck and concern. We find out that it is possible to model practical system and improve the security of system by applying universal composability but it's time consuming test and needs lots of expertise. Thank you everyone. If you have any question you can contact us with any of these emails.