 Thanks for the introduction so Luke made the the case very early on and very convincingly why we need provably secure schemes or why we need to provide a proof of security for the protocols that we introduce so in his case it was like about three years right until the proof came out 2013 or so the signal protocol was developed in this case we're talking about a proof that took 26 years so yeah moving on so I I'm not gonna go very well into authenticated key exchange because the previous speakers already did a great job of it so briefly what we want is secure communication between two parties and we usually typically use authenticated key exchange mechanisms so those are protocols that look a bit like this between Alice and Bob or a client in server so usually authenticated key exchange schemes and secure messaging protocols they consist of two stages the first one is the authenticated and key exchange mechanism which we also call a handshake and in the second step we use keys derived during the first step in order to secure the communication between the two parties by usually authenticated encryption mechanisms so in this talk I'm going to focus only on the first part so we we already saw that typically when we define security and authenticated key exchange we talk about network attackers which are able to stop messages interact with parties in multiple sessions they can corrupt long-term secrets of parties and they can reveal computed session keys this is the typical Balara Raguay type of methodology of defining security for a key we're also talking about forward secrecy or perfect forward secrecy which is to say even if the key has been come the long-term key of a party has been compromised the security of past sessions is not compromised so in this talk we're gonna talk about a different kind of authenticated key exchange protocol namely this security model and typical analysis of such security models such security protocols they only depend on the fact that you have two parties which you typically both trust to some degree so you can secure the the key if the two parties are honest but in this talk we're gonna talk about a key exchange protocol which is executed by two parties but out of which one of them is untrusted or only semi-trusted so this is the case of the aka protocol which is used in 3g and 4g mobile networks so the aka protocol is was developed in a bit of a stranger context than say people who are familiar with TLS know in the case of mobile communications you don't just have two actors a client in the server you have typically three actors or three main parties the first of which is the client or the user the mobile user and then there are two parties to which this client gets affiliated at different times so a client usually registers with a mobile operator so this can be orange if you're in France or it can be Vodafone or it can be any other mobile operator the client is said to trust its operator now I don't know if we physically trust our operators but at least our phones do so then then there's also the third party whenever the client actually requires mobile services such as I know SMS privileges or minister talk or internet access the the client has to establish a secure channel to receive those services with a third entity and this entity which I called here a server is just so that we we have some sort of backward compatibility with TLS people these servers are called actually mobile management entities MMEs and they are affiliated either with the client's own operator in the domestic network or and this is important in the case of roaming the server is a fill with another operator possibly an operator that the client and the client's operators do not fully trust so usually the server and the operator may be assumed to communicate over a secure channel which is mutually authenticated hence the two padlocks but the client and the server they communicate over an insecure channel and it's that channel which the aka protocol aims to secure so to understand how this works there's in mobile communications there's a three tier trust the operator is the most trusted entity apparently so it is trusted to know everything about the stateful protocol including long-term secret data of client and operator together the client is only trusted to know the client data which is usually stored in the SIM card or use SIM card and then there's the server which is not trusted to know anything except the current session data because it's the server that actually has to provide the service so it has to know the session keys there apart from the security of the keys and the security of these sessions we also need to worry about client privacy namely the access pattern of the client should be at least hidden from men in the middle adversaries the identity of the client should be hidden from men in the middle adversaries and there there's quite a convincing case of requirements done by 3GPP on how a client access pattern should be hidden with respect to men in the middle however our results showed that the aka protocol which was also standardized by 3GPP actually does not answer those requirements so this is the aka protocol and you don't need to worry about a lot of the computations the important part of it is that there are these three parties in this case we're just talking about the basic two-party protocol which is done by the client and the operator as we will learn and in the real life this is actually forwarded from one party to the other by the server so the basic two-party protocol underlying the aka protocol is that the client and the server have some stateful information namely the the client's secret key which is denoted SKC the operator's secret key which is called denoted SKOP and a sequence number called SQNC this is the state the client state which is also somewhat shared by the operator as we will see and there are some identifying information which I call here just UID which is user ID we'll find out more about this identity a bit later so the operator has the same information and what happens is the operator actually generates both the randomness for the session which is denoted as R and a number of values namely an authentication information Mac op which authenticates the operator to the client maxi which will have to identify the the client to the operator as well as some some session key information the two keys a CK and IK are used afterwards for integrity and confidentiality so those are the encryption and integrity check keys and then there's the authentication key the authentication key is used to actually transport the sequence number that is used at every authentication session so what happens here is that the operator generates the randomness and as long as the sequence number based on which this information has been computed is not too far from the client's own sequence number the client will accept the authentication and run the protocol the role of the sequence number is a little bit obscure but what it does is it actually replaces somehow the randomness on the client side now in the 1990s the SIM cards used by mobile phones did not produce randomness even current SIM cards do not produce randomness but next generation SIM cards will be able to produce some randomness and do such computations the problem was there that you had to ensure freshness while only providing randomness from one party so and that's why the sequence number is used so what happens is the client checks that the values are somewhat compatible with its own stored sqn and afterwards it sends the response which is hopefully equal to maxi these cryptographic functions f1 to f5 they're actually standardized as one of two types of cipher suites either based on millenage or on Chouac so in the in case the two sequence numbers are not the same but the Mac of the operator checks out there is a resynchronization procedure so this can sometimes happen when when the sequence number of the operator was used for other processes not for the aka process but for other processes in the phone so this resynchronization basically reversed the clients and the operator roles in the key exchange so the client encapsulates its own sequence number and forces the operator to go back a notch and resynchronize the its own sequence number so now we introduced the third party this was a the basic two-party protocol in which a cave space the problem is that the protocol is not run by the operator and the client which both know the symmetric values which are required for this it's run by the client in the server and the server does not trust it to know the the client's key the operators key nor the sequence numbers so how can authentication work without the server knowing the client's secret well essentially what happens is that the server is only used as an identity management tool it only basically figures out who the client is and then asks the operator for the rest of the protocol information it acts only as a proxy with some identity management ideas so in 3g networks the the identifier that is provided by the client to the server is either an international mobile subscriber identifier MC which is a permanent identifier or a temporary one now the temporary identifier is unique is designed to be unique per server but two servers can assign the same value by some accident to the same to the same client and in order to make sure that these are unique you also send your location data with it so the location data tells the operator which server has issued the TMSI the temporary identifier and so you can you can find a unique client to which this this temporary identifier was issued this is important for the privacy for 4g you replace this by a different kind of identifier which does not differ so very much in its structure it also sends some location data and some some identifier data so the three party protocol looks like this so you you start with a with an identification procedure between the client and the server whose only goal is for the server to identify the permanent identifier of the of the client and then figure out which operator to ask for information in the second step the the server will ask for information for a batch of authentication vectors these authentication vectors basically provide what you saw a few slides ago which is all the results of the f1 to the f5 functions the encapsulation of the sequence number practically everything and it does this in batches so the operator will generate a number of random numbers and update the sqn at every every time before it sends the the authentication vectors then there's a challenge response phase and finally there's a TMSI reallocation so here I sort of put it between mutually authenticated padlocks but it's it's an insecure actually it's an insecure transmission it's encrypted but it's not authenticated which is to say anybody can send it so there are some security weaknesses of the protocol that I want to highlight so first of all you have a weird kind of offline really relay attack that works for server impersonation now this is not a disastrous attack but it shows that there is a weakness in the protocol namely the the former part of the protocol which is the identification phase can can be you can spot that it's the same client and you can replay it so basically what you do as an attacker you look at the first two messages you let them pass and for the third one you just stop it so the next time the client actually is is going to forward it's it's identifier which is going to be the same between the two notion this two sessions so you're going to see it you you can just replay the authentic authentication challenge and be identified by the client as the server of course you won't be able to calculate to compute the key so it's just it's a problem with authentication but yes so it's still a problem so there's some more problems with corruptions namely the their Zhang and Feng showed that corrupting servers can allow an attacker to reuse authentication vectors and impersonate clients sorry impersonate server to clients which is to say that if you have a weak partner a weak weak roaming partner that partner can can have its its sessions corrupted and that information can be used later to extract information from the client what we showed that aka guarantees is some client impersonation security some server impersonation security and some security of the keys but where it fails is that it it does not it is not robust with respect to server corruptions and there's also this problem with the offline relays now there's also the point of privacy here so 3GPP requires three notions of privacy identity hiding location hiding and untraceability strobel and 2007 showed a parallelizable imsi catcher attack which shows that basically with just very little effort you can always find the permanent identifier of every single user in the whole network all you have to do is re-randomize whatever the the temporary identifier comes out to be from the client because in that case the backup alternative for aka is please can you give us your permanent identifier so you can do this for all the clients and all the network at all the time now I'm not going to go over everything because I'm running short on time the point is that even if you fix this as found in brook did at CCS I think two years ago you you're not going to solve this in in addition you have a problem we with re-synchronization namely you can you can trace a desynchronized client from a non desynchronized client and you can force this desynchronization to happen so there's also a third one by TMS area location but the whole point is there's no privacy for the aka protocol our counter proposals do fix it both the security and the privacy the privacy is more involved and it features a more complex type of encryption for the TMS I send sending but the whole point of this is is this sufficient for 5g networks there is the advent of the 5g the fifth generation mobile networks and those will also need the aka protocol so there are some some more important aka problems than just security and privacy in this respect namely we have some problems with respect to end to end encryption it does not exist because everything goes through the operator so this is something that we should think about how do we get end to end encryption for 5g networks how do we get peer-to-peer communication with 5g networks this only works for through the servers at the moment so all of this has to be solved for 5g networks so in perspective the 3g and 4g aka protocol has limited security has no privacy we can fix this so that it has some security and some privacy but this is not sufficient for 5g networks so I think just as we have done for TLS when we went from 1.2 to 1.3 what we actually need is the same same kind of leap from 3g 4g to 5g for aka the aka protocol taking into account speed because that's very important for all operators taking into account compliance with the law and taking into account the new network infrastructure that 5g networks are going to have thank you very much