 So welcome, my name is Sven Schäger and I'm going to present you a talk on privacy-preserving authenticated key exchange and the application to IPsec or iKey version 2. This is joint work with Jörg Schwenk and Sebastian Lauer. Okay, so in classical key exchange, you usually have the setting where there is two parties, Alice and Bob, and they want to communicate over an insecure channel and the goal of those two is to derive a session key that can be used to symmetrically protect the following data. So and typically in classical key exchange, you want as a security notion, you want that this key is indistinguishable from random so that you can plug in the symmetric security games quite nicely. So but in throughout the internet, you can often find other settings as well, where you for example have a physical server machine that is hosting different virtual servers. And well, publicly, there's only one endpoint, namely the IP address or the socket IP address in TCP and port. But behind that, there might be different servers running different web servers, for example. One web server might be out of the box online shop, they give me new shoes.com or something. And the other one might be some government, their critical website that contains their critical information and might give rise to political persecution. So this is actually a quite typical setting. For example, when using the multi home servers, but you might also consider the more general case where you have all the parties be equipped with more than one identity, right. And in those settings, it might make sense to to consider privacy mechanisms that tell that that guarantee that the actual choice Alice makes when when communicating with each of those web servers is actually hidden from the transcript that no attacker can can reveal if Alice is accessing the government critical website or just the online shop. And this paper is about formalizing that in a very strong strong sense and providing the foundations for that. Okay. So the motivation, of course, privacy, we want to have privacy and there's no there's no other motive to that. We just want to insist on privacy and have that Alice can can do that that only really necessary information is revealed about Alice. But there's also some some other benefit from from introducing such a model, namely circumvention of of censorship. And there are a lot of examples where the countries and governments, they do censorship based on based on the concrete choice Alice makes, right. So typically, this is done via server name indication. So if Alice actually tries to access the government critical website, there's some there's some information that is in the in the clear to be found in the transcript and those censorship mechanisms, they filter that out and block the website. Okay, so here's here's some remark. These security models are no substitution for tall, of course, because tall does does the whole thing tries to provide privacy from start to the beginning. But it it rather begins to to the network endpoint, it's so this security rather begins where tall ends, I would say. So tall guarantees that your information is is secure up to the network interface. And privacy preserving, aka can guarantee that behind that network interface, the user gets in some simple way, right, without additional and without too much additional and costly mechanisms can get some privacy for its choice of virtual server. Okay. So the contribution in this work is we provide a security model. And the the benefit of that model is that it gives a very strong way to formulate security in the sense that it makes indistinguishability of identities of use identities and indistinguishability of you of keys from random keys, independent of each other, those two properties are independent. So I'm going to explain what that means. So well, it's a very general model, I'd say. And we we rather regard it not as the the final model, but rather as a set of ingredients that can be used to extend existing classical models to also provide the privacy preserving property, right. So and the way that that so and and these and and this ingredients should should they give a very sound way to construct privacy preserving aka in the sense that the the resulting and new privacy preserving protocol model is is a proper extension of the classical model, right. This increases comparability. So everyone knows that in aka research, there's a zoo of models to not worsen the situation. We might and increase comparability. We might we we rather provide some some building blocks to extend security models to also provide privacy, the privacy preserving property. And there's also another the novelty in our in our work, which is called modes modes help to capture the expectation of who is responsible for choosing some identities. Well, now Alice and Bob has two identities. And well, Alice might be responsible for choosing her own identity. And likewise, Bob might be responsible for choosing its own identity. But it might also the case as we have in our example that actually Alice chooses the identity that is going to be used for Bob and our modes, they capture the they they encode these expectations and well, they they allow and they are in their public and they allow the attacker to adaptively make sessions, communicate with each other. They do not have fitting modes where the expectations and well, diverge or clash. So and finally, we provide the security proof for IPsec with signature based authentication. OK, so here's a very simple schematic of of a security model. And this is just an extraction. So we have your party related information. And we also have session related information. For example, the session key is different for each protocol run. Now, what we introduce is new session specific information. And the first set of information is called public modes. And those public modes, they they are encoding the expectations of who is of who is responsible for choosing identities. So for example, if this value, this value might be me or partner is is me is said to me. Then this means that Alice believes that she is responsible for choosing the secret key to to to to use and not Bob, right. And likewise, if this value is going to be said to to partner, she partner, she believes that Bob is responsible for choosing its own identity, right. And those information are public. And this has the benefit that the attacker knows those information and can pit sessions of Bob and Alice with unfitting modes against each other, right. And also those modes, because sessions might have different modes, they capture protocol options where still each protocol option relies on the same long term key material. So they are not independent of each other. It doesn't make sense to have them to have a look at them in a in a separate way. They are all they are all related to the same long term key material, but they are different modes. OK, so and then there are the the actual choices of the actual choices of of the key material. Those values may be set throughout the protocol execution. So this value, the identity select a bit of Alice, maybe one or zero. And this value is going to say that Alice is using secret key a zero. For example, if it is zero. And on the other hand, this value is going to to to state that this session is going to use public key B zero if the value is set to zero, OK. So of course, we also need to extend the attack capabilities. And since we have introduced new secret states as well, not only public state information, namely those identity select a bit. We also give the adversary the possibility to adaptively reveal them, right? And we have chosen to extend this test session. Now the test session has a parameter, an input parameter. Either we do the classical stuff with a parameter key or we choose identities to be as as to be to be given to the adversary as a challenge. So either the the the identity of the long term secret key that this session is using or the identity of the long term public key that Bob's public key that that Alice is is using to authenticate incoming data with, right? OK, now in the security experiment corresponding each party is as equipped with two keys and the the most critical point is that now in the security experiment, we have that each session that the attacker can always access all attack queries, attack their capabilities, also the unmask rate. This has some some consequences, right? So one consequence is that we cannot just reuse existing proofs because those existing proofs they indeed may show the key indistinguishability of some protocol, but they but the analysis was not made in the presence of the unmask rate. So one might come up with artificial examples of protocols where the unmask rate might give some information on the key used, right? So we to to to to actually use the previous proofs, we have to we have to fully revisit them and and they have a look at whether they still hold in the presence of unmask rates. So and this makes sense well because in well in in well typical in in classical proofs we want that independent of the used identity key indistinguishability is still guaranteed and the classical security model the adversary already knows because there's just one identity already knows the the identities of initiator and responder, right? So what we want is is that key indistinguishability holds this is what we mean by cryptographic independence. Key indistinguishability might hold even though identity indistinguishability is violated, right? So this makes sense in in practice because identity information are context dependent and might be leaked more easily and typically more easily than cryptographic keys which are uniformly random values, right? So there are other ways there are other ways to reveal identity information. So in a sense it it might in some situations be more likely that identity information is revealed but nevertheless even if it is revealed we want that it's still key indistinguishability holds and this is of course kind of a prerequisite for showing that our model is a proper extension of classical models because in those classical models we have the very same situation the attacker already knows the identities and still key indistinguishability should hold, right? I said before and our model also aims to capture the opposite even though the cryptographic key is somehow revealed we still would want that identities are indistinguishable. So this is what we mean by cryptographic independence between key and identity indistinguishability. Okay so well as we just view those building blocks on the unmask query and those new state information per session as ingredients we might also apply them to other security models for example authenticated key exchange with explicit authentication to the ACCE model or just to models that that focus on unilateral authentication as well so they might be adapted and apply it there as well. So the emphasis on having a strong cryptographic independence between those security properties. Okay so now we come to the final part our analysis of IPsec and what we have learned from that so IPsec with signature-based authentication and I would so I should rather say I keep two the internet key exchange protocol as part of IPsec basically has an anonymous key Diffie-Helman key exchange in this phase and derives symmetric keys over here so we have a closer look and those keys are then used to encrypt the following data and also the authentication mechanism is encrypted. Okay so this is phase one and basically what we have over here is that there are some keys used in the next phase and those keys depend on random nonces exchanged in the first two messages and also on some some secret S that works like a master secret but this random secret S is derived from an anonymous Diffie-Helman key exchange G to the X times Y coming from big Y sent over and big X sent over and now using those keys everything is going to in phase two is going to be encrypted. So now what we encrypt is what each party encrypts is also the authentication mechanism and the authentication mechanism in this protocol is signature-based so the initiator encrypts some signature here's a signature and sends over its identity and some signature and this signature encrypts as is bound to its secret key and can be verified with the corresponding public key but also protects information that comes from the from the first phase right so there is some interleaving of information and likewise the the responder also protects part of the messages and sends in the first phase right in this way these two parties guarantee that there has been no active adversary. Now there are now two protocol options and this is where we use modes and the first mode and first protocol option the initiator this is the option may send information on the identity that should be used by the responder and in the second protocol option since this is optional there's no such decision by the initiator the responder may decide on its own which identity to use okay so what we can learn from the analysis and the security proof is that one has to be careful in these situations right so why is that luckily for signatures this has worked out quite and quite nicely but there is some one writes like strategically one might run into into secularities basically the the signatures here they are used to protect the first phase without the signatures the first phase has no no guarantee of of resulting in secure keys but the secure keys they are needed to hide the identities right so the secure keys are needed to hide the identities and to encrypt all the data and protect the data from modifications right so it it kind of depends on the on the information here to protect the information in the in the first phase but the information the first pattern in the first phase also used to protect the information in the second phase but for signatures this has worked out quite nicely also a what we need as a take-home message is now that all identity and dependent information should not only be encrypted but have the same length so having two signature schemes two different signature schemes like I don't know DSA or ours a base signatures would be problematic so we can model that by requiring that the signatures have the same length or either or to to have length hiding authenticated encryption be used okay and from from the secret information we then derive the actual session keys okay so under the PRF audio assumption assumption and an appropriate variant of that assumption given that the PRF is secure the signature scheme is secure and if needed that the signature scheme is length preserving or that the that the authenticated encryption scheme is length hiding then this PP aka scheme is secure okay let's conclude now we have a privacy preserving aka model I authenticated key exchange model and we emphasize strong independence between identity and distinguishability and keen distinguishability right this is one of our total take-home messages and what we also have done is is introduced modes to to cope with protocol options now and well the proof of a PSAC is not too complicated but the take-home message is when we deal with privacy preserving information we have to make sure that all identity related information result in the same in the same transcript length right thank you very much for attention and I'm glad to take their messages to take questions and messages and in the in the in the online phase of this talk