A Cryptographic Analysis of UMTS/LTE AKA
 7 Citations
 1.5k Downloads
Abstract
Secure communications between mobile subscribers and their associated operator networks require mutual authentication and key derivation protocols. The \(\mathsf {3GPP}\) standard provides the \(\mathsf {AKA}\) protocol for just this purpose. Its structure is generic, to be instantiated with a set of seven cryptographic algorithms. The currentlyused proposal instantiates these by means of a set of \(\mathsf {AES}\)based algorithms called \(\mathsf {MILENAGE}\); as an alternative, the ETSI SAGE committee submitted the \(\mathsf {TUAK}\) algorithms, which rely on a truncation of the internal permutation of \(\mathsf {Keccak}\).
In this paper, we provide a formal security analysis of the \(\mathsf {AKA}\) protocol in its complete threeparty setting. We formulate requirements with respect to both ManintheMiddle (MiM) adversaries, i.e. keyindistinguishability and impersonation security, and to local untrusted serving networks, denoted “servers”, namely stateconfidentiality and soundness. We prove that the unmodified \(\mathsf {AKA}\) protocol attains these properties as long as servers cannot be corrupted. Furthermore, adding a unique server identifier suffices to guarantee all the security statements even in in the presence of corrupted servers. We use a modular proof approach: the first step is to prove the security of (modified and unmodified) \(\mathsf {AKA}\) with generic cryptographic algorithms that can be represented as a unitary pseudorandom function –PRF– keyed either with the client’s secret key or with the operator key. A second step proceeds to show that \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) guarantee this type of pseudorandomness, though the guarantee for \(\mathsf {MILENAGE}\) requires a stronger assumption. Our paper provides (to our knowledge) the first complete, rigorous analysis of the original \(\mathsf {AKA}\) protocol and these two instantiations. We stress that such an analysis is important for any protocol deployed in reallife scenarios.
Keywords
Security proof \(\mathsf {AKA}\) protocol \(\mathsf {TUAK}\) \(\mathsf {MILENAGE}\)1 Introduction
Transmitting confidential and authenticated data between two parties across an insecure channel is a fundamental goal in cryptography. Secure channels are usually obtained by means of an authenticated keyexchange (AKE) protocol.
AKE protocols generally consist of two phases. During the first phase, the parties authenticate each other and exchange data that enables them to compute a master key. The latter is then used to derive one or several secret keys, as well as other useful values. In a second phase, the derived keys are used to construct the secure channel between the parties, guaranteeing the confidentiality, integrity, and authentication of the data they exchange.
In this paper, we focus on the Authentication and Key Agreement protocol (\(\mathsf {AKA}\)) used in 3G and 4G networks, more specifically the 3G UMTS AKA (Universal Mobile Telecommunications System) and 4G EPS AKA (Evolved Packet System) protocol^{1}. The \(\mathsf {AKA}\) protocol is used in a greater context in the \(3^{\text {rd}}\) Generation Partnership Project (\(\mathsf {3GPP}\)), which aims to develop the specifications for the next generation mobile systems. The security of the system is covered by Technical Specifications 33 (TS 33) and 35 (TS 35)^{2}, from both an architectural and a securityalgorithm standpoint.
The \(\mathsf {AKA}\) Protocol. Initially developed in the 1990s, \(\mathsf {AKA}\) uses symmetric keys exclusively, in a mobilenetwork context which imposes a peculiar architecture. In this setup, mobile clients subscribe to a single operator, which provides them with mobile services (messaging, calls, Internet use, etc.). Services are provided across a secure channel, not by the operator, but by an intermediate local network operator (which we call server to avoid confusion). The server and operator are affiliated together for domestic use. However, if the client is abroad, service is provided by a server affiliated with a different operator. Thus, servers are only trusted to provide services, but they must not learn the client’s longterm secrets (known only to the client and the operator); by contrast, servers do learn shortterm secret values, such as session keys, which are necessary for the transmission of the required service. Consequently, unlike the classical twoparty AKE setting, the \(\mathsf {AKA}\) protocol requires three participants.
One specificity of the subscriberoperator architecture is that clients are associated both with a unique clientkey and with their operator’s key, which is shared with all the other clients (a potentially very large number) of that operator. Clients minimize the risk of compromising the shared key by only storing a (oneway) function of that, and the client key, never the operator key in clear.
The design of the \(\mathsf {AKA}\) protocol is influenced by three important constraints. One is that (current and older) SIM cards, cannot generate (pseudo)random numbers. Thus, freshness has to be guaranteed without client randomness. The second constraint is that the (necessary) communication^{3} between servers and operators in the roaming scenario is usually expensive. In the \(\mathsf {AKA}\) protocol, operators generate batches of authentication vectors for the server, thus minimizing costs. Finally, mobile channels are notoriously noisy, requiring the protocol to be robust with respect to noise. As a result of these constraints, the \(\mathsf {AKA}\) protocol is stateful, with the authentication depending on an updatable sequence number, which is accepted within a tolerance interval.
\(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) . In this paper we focus on the provable security of \(\mathsf {AKA}\). The latter is constructed using symmetrickey primitives, namely a set of seven cryptographic functions, denoted \(\mathcal {F}_{1}, \dots , \mathcal {F}_{5}, \mathcal {F}_{1}^*, \mathcal {F}_{5}^*\). We closely follow the design of these algorithms, as well as that of the protocol, in our analysis.
Originally, 3GPP put forward a proposal for an AESencryptionbased algorithm set, called \(\mathsf {MILENAGE}\) [1]. As an alternative to \(\mathsf {MILENAGE}\), the ETSI SAGE committee proposed another set of algorithms called \(\mathsf {TUAK}\) [2], which relies on a truncation of \(\mathsf {Keccak}\)’s internal permutation. The winner of the \(\mathsf {SHA}\)3 hash function competition, \(\mathsf {Keccak}\) offers both higher performance, in hardware and software, than AES, and resistance to many generic attacks. While the \(\mathsf {TUAK}\) algorithms inherit \(\mathsf {Keccak}\)’s superior performance, they do not use the \(\mathsf {Keccak}\) permutation in a usual, blackbox way, but rather rely on something akin to a MerkleDamgård construction. Instead, the internal permutation is truncated, then used in a cascade, which makes previous results harder to use. We cannot simply use the same assumptions for the truncated version as we would for the original permutation, either. Our analysis of the key indistinguishability, as well as client and respectively serverimpersonation resistance of the protocol concerns both the classical \(\mathsf {MILENAGE}\)based version, and the one using \(\mathsf {TUAK}\).
Related Work. At its core, the \(\mathsf {AKA}\) protocol provides authenticated key exchange (AKE), a primitive first modelled by Bellare and Rogaway [8]. We use the BellarePointchevalRogaway (BPR) extension of this model [7]; however, the threeparty setting and lack of randomness on the prover side do not allow us to simply “import” their model, as we explain in more detail below.
Few papers give a security proof for \(\mathsf {AKA}\), especially when instantiated with \(\mathsf {MILENAGE}\). Gilbert provides an outofcontext proof for \(\mathsf {MILENAGE}\) [11], showing it operates as a kind of counter mode for key derivation. It is unclear whether this suffices to guarantee security for \(\mathsf {AKA}\) at large; indeed, we show in this paper that \(\mathsf {MILENAGE}\) is not quite as versatile as \(\mathsf {TUAK}\). The closest results to a security proof of \(\mathsf {AKA}\) (see below) use automated (formal) verification.
In 2003, Zhang [15] described an important servercorruption attack against \(\mathsf {AKA}\) and advised against the use of sequence numbers as state. He also presented a stateless modification of the protocol called APAKA and proved its security in Shoup’s model. In the full version of this paper, we show that APAKA is still vulnerable to a particular type of replay attack. Server corruptions are a highly relevant threat in a postSnowden cryptographic era, in which intelligence agencies have been known to substitute and backdoor algorithms, and store massive amounts of data. We take such attacks into account into our definitions. We also extend a countermeasure from Zhang [15], which features the addition, in the authentication string, of a unique serverspecific identifier, and we show how to incorporate it within the existent \(\mathsf {MILENAGE}\) and \(\mathsf {TUAK}\) specifications.
The security proof of Lee et al. [13] is complementary to ours as they focus on the LTE (Longterm Evolution) protocol in 4G networks (similar to \(\mathsf {AKA}\), but using different identifiers and keymanagement), rather than the handshake itself. Lee et al. analyse the privacy of LTE, rather than the security of \(\mathsf {AKA}\) (as we do). Their main result is that in the absence of server corruptions, LTE attains a weak untraceability against an active MiM adversary. We discuss their work in more detail in the full version. Though this is not made explicit, Lee et al.’s result implies the impersonation resistance of LTE and some security of the derived session keys; however, their proofs hold for an important modification of \(\mathsf {AKA}\), as we discuss in more detail in the full version. A surprising problem is that [13] cannot capture IMSIcatcher attacks (which directly impact privacy without server corruptions); this is because, contrary to realworld scenarios, they assume that once a TMSI is allocated, the IMSI will never again appear in clear. Finally, their proofs reduce the privacy of \(\mathsf {AKA}\) to some assumptions on the functions which are akin to the unitary function \(G_{\mathsf {}}\) that we use; however, they do not analyse \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) to verify whether these suites actually guarantee those required properties.
Arapinis et al. [5] focus on the client privacy of the \(\mathsf {AKA}\) protocol by automated verification in ProVerif [10]; however, they only assess a modified version, which randomizes the sequence number. This fundamental modification makes their results inapplicable to the original protocol. Our attempts to extend this analysis to that of the true protocol by using a statepermissive tool called StatVerif [6] were not fruitful, as discussed in the full paper.
Our Contributions. We present four main contributions: (a) fullyformalized definitions for the security of \(\mathsf {AKA}\) in the three party setting; (b) security proofs indicating that the current \(\mathsf {AKA}\) protocol does not attain full security in the presence of server corruptions (due to the attack of Zhang [15]); (c) we show how to attain full security by simply adding a unique server identifier in the authentication; (d) we prove that our security statements hold for both protocol instantiations (\(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\)). In particular, we analyse two somewhatsimilar versions of the protocol: the original \(\mathsf {AKA}\) scheme and a slight variation of it of our own design, which we also analyse. We detail our contributions below.
 1.
Keyindistinguishability: the derived session keys are indistinguishable from random by a MiM attacker placed between the client and a server with blackbox access to all operators.
 2.
Client and serverimpersonation: a MiM attacker cannot impersonate honest servers (to the client), or clients (to an honest server). Due to the identification phase, \(\mathsf {AKA}\) resists client impersonations better than server impersonations.
 3.
Stateconfidentiality: (malicious) servers cannot learn: the client’s secret key, the operator’s secret key, nor their state. The malicious server may interact with both operators and clients, but we only address the \(\mathsf {AKA}\) handshake (not the securechannel primitives).
 4.
Soundness: (malicious) servers cannot authenticate to the client unless they are explicitly given authenticating information by a legitimate operator.
\(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) . The second step of the proof is to show that both \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) behave as the required functions \(G_{\mathsf {}}\) and \(G_{\mathsf {}}^*\). This can be proved for \(\mathsf {TUAK}\) under the standard assumption that the (un)truncated \(\mathsf {Keccak}\) permutation is a good PRF [9, 12]. By contrast, proving that \(\mathsf {MILENAGE}\) can be modelled as a unitary PRF when keyed with the operator key requires the pseudorandomness of a keyed AESversion of a classic DaviesMeyer construction for \(\mathsf {MILENAGE}\), which seems a stronger assumption than just assuming the pseudorandomness of the underlying AES permutation.
\(\mathsf {AKA}\) Privacy. Several papers indicate privacy problems for \(\mathsf {AKA}\), e.g. [3, 4, 5, 14]. The last of these is a recent result, indicating that privacy can be attacked at a lower level than the protocol layer (by leakage at a physical layer). Since \(\mathsf {AKA}\) is known not to provide strong privacy, and it is moreover unclear whether it can even hope to provide it considering such leaks at lower layers, we choose to restrict ourselves to the subject of \(\mathsf {AKA}\) security, rather than its privacy.
2 The AKA Protocol
Mobile 3G networks use the variant of \(\mathsf {AKA}\) fully depicted in Fig. 1, allowing the client and the server to output session keys \((\mathsf {CK}, \mathsf {IK})\), which are then used to secure future messageexchanges. The same protocol is the backbone of the 4G LTE protocol; however, for LTE the client is associated with an identifier called GUTI (see 3GPP TS 23.003, release 13), as opposed to the tuple of permanent and temporary identifiers we describe below. The use of GUTIs make no difference for our analysis. More significantly, the session keys \(\mathsf {CK}\), \(\mathsf {IK}\) from the 3G protocol are only used as key material for a key derivation function KDF, which outputs the true session key.^{4} Our proofs work similarly for this new key derivation, but we would need an additional reduction to \(\mathsf {KDF}\) security.
This protocol features two main active actors: the client (in 3GPP terminology \(\mathsf {ME}/\mathsf {USIM}\)) and the server (denoted \(\mathsf {VLR}\)). The third, only selectivelyactive party is the operator (denoted \(\mathsf {HLR}\)). The tripartite setup of \(\mathsf {AKA}\) was meant for roaming, for which the server providing mobile coverage is not the client’s operator, and may be subject to different legislation and vulnerabilities than the latter. Thus, although the server is trusted to provide services across a secure channel, it must not learn longterm sensitive information about either clients or their home operators. Using the server as a mere proxy would ideal; however, the server/operator communication is (financially) expensive.
Section 3 describes in detail the setup of the three parties. Clients \(\mathsf {C}\) and operators \(\mathsf {Op}\) use both the client’s secret key \(\mathsf {sk}_{\mathsf {C}}\) and the operator’s secret key \(\mathsf {sk}_\mathsf {Op}\) ^{5}. The client and operator also keep track of sequence numbers \(\mathsf {Sqn_{\mathsf {C}}}\) (resp. \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\)), updated after each successful authentication (by a simple, predictable procedure, e.g. incrementing them by a fixed value). If the states are too far apart, the client prompts a resynchronization. The three parties: clients, servers, and operators, also know the client’s permanent identifier \(\mathsf {IMSI}\). Clients and servers must keep track of tuples (\(\mathsf {IMSI}\), \(\mathsf {TMSI}\), \(\mathsf {LAI}\)), the last two values forming a unique temporary identifier, which is updated at every session.
The authenticatedkeyexchange step allows clients and servers to mutually authenticate and compute session keys over an insecure channel. The server chooses the next \(\mathsf {AV}\) from the latest batch, using the random \(\mathsf {R}_{}\) and the string \(\mathsf {Autn}= (\mathsf {Sqn_{\mathsf {Op},\mathsf {C}}} \oplus \mathsf {AK}) \Vert \mathsf {AMF}\Vert \mathsf {Mac}_{\mathsf {\mathsf {S}}}\) as a challenge. The client uses \(\mathsf {R}_{}\) to compute \(\mathsf {AK}\) and recover \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\). If the received \(\mathsf {Mac}_{\mathsf {\mathsf {S}}}\) verifies and \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\) is within a predefined distance \(\varDelta \) of \(\mathsf {Sqn_{\mathsf {C}}}\), then \(\mathsf {C}\) computes \((\mathsf {CK}, \mathsf {IK})\) and the value \(\mathsf {Mac}_{\mathsf {\mathsf {C}}}\), sending this last value to \(\mathsf {S}\). If the two sequence numbers are too far apart, then \(\mathsf {C}\) forces a resynchronization, described below. Else, the client updates \(\mathsf {Sqn_{\mathsf {C}}}\) to \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\), and \(\mathsf {S}\) verifies the received authentication value with respect to the \(\mathsf {Mac}_{\mathsf {\mathsf {C}}}\) sent by \(\mathsf {Op}\). If \(\mathsf {Mac}_{\mathsf {\mathsf {C}}}\) verifies, then \(\mathsf {S}\) sends an acknowledgement to \(\mathsf {Op}\) and runs a \(\mathsf {TMSI}\) reallocation. During the optional resynchronization, the client uses \(\mathsf {Sqn_{\mathsf {C}}}\) to compute values \(\mathsf {Mac}_{\mathsf {\mathsf {S}}}^*\) and \(\mathsf {AK}^* \oplus \mathsf {Sqn_{\mathsf {C}}}\) as \(\mathsf {Op}\) did, using the session \(\mathsf {R}_{}\), but algorithms \(\mathcal {F}_{1}^*\) and \(\mathcal {F}_{5}^*\) (not \(\mathcal {F}_{1}\) and \(\mathcal {F}_{5}\)). If \(\mathsf {Mac}_{\mathsf {\mathsf {S}}}^*\) verifies, \(\mathsf {Op}\) resets \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\) to \(\mathsf {Sqn_{\mathsf {C}}}\) and sends to \(\mathsf {S}\) another batch of \(\mathsf {AV}\) as before. The protocol restarts.
Following successful key exchange, the client and server run the \(\mathsf {TMSI}\) reallocation. The server sends an (unauthenticated) encryption of a new, randomly chosen \(\mathsf {TMSI}\) (which is unique per server) to the client \(\mathsf {C}\), using the agreedupon key \(\mathsf {CK}\). Encryption is done by means of the A5/3 algorithm (see 3GPP TS 43.020, release 12), run in cipher mode. The new \(\mathsf {TMSI}\) value, called \(\mathsf {TMSI}_{\mathsf {new}}\), is only permanently saved by \(\mathsf {S}\) if acknowledged by the client; else, both \(\mathsf {TMSI}_{\mathsf {new}}\) and \(\mathsf {TMSI}_{\mathsf {old}}\) are retained and can be used in the next protocol run.
Identities and Reallocation. Though in this paper we stick close to the \(\mathsf {AKA}\) protocol, one simplification we make throughout is associating each client with a single, unique \(\mathsf {UID}\), which we consider public. In practice, \(\mathsf {UID}\) is the user’s \(\mathsf {IMSI}\), which is used in case a \(\mathsf {TMSI}\) value is not traceable to an \(\mathsf {IMSI}\). From the point of view of security, any attack initiated by mismatching \(\mathsf {TMSI}\) values (i.e. replacing one value by another) is equivalent to doing the same with \(\mathsf {IMSI}\) values.
Another important feature of \(\mathsf {AKA}\) that we abstract in this analysis is the \(\mathsf {TMSI}\) reallocation. If the \(\mathsf {TMSI}\) system were flawless (a newlyallocated \(\mathsf {TMSI}\) is reliable and nonmodifiable by an active MiM), then we could prove a stronger degree of server impersonation than we currently do. As discussed in Sect. 3, an active MiM can inject false \(\mathsf {TMSI}\) values, which make servers request an \(\mathsf {IMSI}\) value; if the MiM reuses this value, it can impersonate servers by offline relays. The use of the \(\mathsf {TMSI}\) in \(\mathsf {AKA}\) is undone by using \(\mathsf {IMSI}\)s as a backup for \(\mathsf {TMSI}\)s; also, insecurities in using \(\mathsf {TMSI}\)s translate to the identification by \(\mathsf {IMSI}\).
3 Security Model
In this section, we propose a security model with respect to two types of adversaries: an active MiM with access to the insecure channel between the client and the server; and a malicious server, which also has access to operators. Our security notions are: keyindistinguishability for the session keys \(\mathsf {CK},\mathsf {IK}\), and client and serverimpersonation resistance. With respect to servers, we also require the keyconfidentiality of the client’s long term data \(\mathsf {sk}_{\mathsf {C}}, \mathsf {sk}_\mathsf {Op}, \mathsf {Sqn_{\mathsf {C}}}\), and soundness. We use similar oracles for all the definitions. While we cannot use a basic BPR syntax [7] in this threeparty setting, we guarantee a same kind of security with respect to MiM attackers. While our serverimpersonation model is slightly weaker than that for clientimpersonation, this has no impact on the keyindistinguishability for the session keys. For clarity, we include here only intuitive description of the oracles, and leave the formalization for the full version.
Set Up and Participants. We consider a set \(\mathcal {P}\) of participants, which are either a server \(\mathsf {S}_i\) or a mobile client \(\mathsf {C}_i\). Operators \(\mathsf {Op}\) are not modelled as active parties; in all security games with respect to MiM adversaries, operators are blackbox algorithms within each server \(\mathsf {S}_i\). For security with respect servers, the operators are oracles which malicious servers may query. We assume there are \(n_{\mathsf {C}}\) clients, \(n_{\mathsf {S}}\) servers, and \(n_{\mathsf {Op}}\) operators. For MiM models, servers contain “copies” of all operators; the copies are assumed to be synchronized with respect to client state, though their output might depend on which server queries them. We associate each client with: a unique identifier \(\mathsf {UID}\), longterm static keys \((\mathsf {sk}_{{\mathsf {UID}}}, \mathsf {sk}_\mathsf {Op})\), and an ephemeral state \(\mathsf {st}_{\mathsf {UID}}\) which is a sequence number \(\mathsf {Sqn_{\mathsf {UID}}}\). Each of the \(n_{\mathsf {S}}\) servers has blackbox access to operator algorithms (or oracles for stateconfidentiality and soundness) \(\mathsf {Op}_1, \dots , \mathsf {Op}_{n_{\mathsf {Op}}}\), initialised with longterm keys \((\mathsf {sk}_{\mathsf {Op}_i})\) and tuples \((\mathsf {UID}, \mathsf {sk}_{\mathsf {C}}, \mathsf {Sqn_{\mathsf {Op},\mathsf {C}}})\), the last value dynamically updated. For simplicity, we assume that the key space of all operators is identical.
Security Against MiM Adversaries. In our model, the clients and servers may run concurrent executions of the protocol \(\mathsf {\Pi }\). We denote the jth execution of the protocol by party \(\mathsf {P}\) as \(\mathsf {P}_j\), associated with a session ID \(\mathsf {sid}\), a partner ID \(\mathsf {pid}\) (consisting either of one or of multiple elements), and an accept/reject bit \(\mathsf {accept}\) (explained in detail in Sect. 4). In this case \(\mathsf {P}_j\) is a handle, used by a MiM adversary \(\mathcal {A}\) to access the oracles below so as to schedule message deliveries, send tampered messages, or interact arbitrarily with any party. We also use a function \(G_{\mathsf {}}\), which we model as a PRF. For a more detailed description, see our full version.

\(\mathsf {CreateCl(\mathsf {Op})}\): creates a new user \(\mathsf {C}\) associated with a unique identifier \(\mathsf {UID}\), a key \(\mathsf {sk}_{\mathsf {UID}}\) drawn independently and uniformly at random from a key space \(\mathcal {S}\), the key \(\mathsf {sk}_\mathsf {Op}\) of operator \(\mathsf {Op}\), and a sequence number \(\mathsf {Sqn_{}}\) stored in \(\mathsf {st}_{\mathsf {UID}}\). The adversary is given \(\mathsf {UID}\) and \(\mathsf {Sqn_{\mathsf {UID}}}\). The operator \(\mathsf {Op}\) is given \((\mathsf {UID}, \mathsf {sk}_{\mathsf {UID}}, \mathsf {Op}, \mathsf {Sqn_{\mathsf {UID}}})\), and initializes \(\mathsf {st}_{\mathsf {Op}, \mathsf {UID}} := \mathsf {Sqn_{\mathsf {UID}}}\), saving the entry \((\mathsf {UID}, \mathsf {sk}_{\mathsf {UID}}, \mathsf {sk}_\mathsf {Op}, \mathsf {st}_{\mathsf {Op}, \mathsf {UID}})\) in its database.

\(\mathsf {NewInstance(\mathsf {P})}\): instantiates a new instance of \(\mathsf {\Pi }\) for party \(\mathsf {P}\), thus creating the handle \(\mathsf {P}_j\), which is made available to the adversary.

\(\mathsf {Execute}(\mathsf {P},i,\mathsf {P}',j)\): simulates an execution of \(\mathsf {\Pi }\) between the initiating instance \(\mathsf {P}_i\) and the instance \(\mathsf {P}'_j\) outputting the transcript \(\tau \).

\(\mathsf {Send}(\mathsf {P},i,m)\): sends message m to instance \(\mathsf {P}_i\), which outputs a response \(m'\).

\(\mathsf {Reveal}(\mathsf {P},i)\): outputs the session key(s) \(\mathsf {K}\) of instance \(\mathsf {P}_i\).

\(\mathsf {Corrupt}(\mathsf {P})\): If \(\mathsf {P}\) is a client, return the key \(\mathsf {sk}_{\mathsf {C}}\), but not \(\mathsf {sk}_\mathsf {Op}\) ^{6}. If \(\mathsf {P}\) is a server, return \(\mathsf {sk}_\mathsf {Op}\), giving the adversary access to oracle \(\mathsf {OpAccess}\). Corrupted parties become adversarially controlled.

\(\mathsf {OpAccess}(\mathsf {S}, \mathsf {C})\): gives the adversary access to the local copy of all the operators stored “inside” a corrupted server \(\mathsf {S}\); the adversary receives as output the message \(\mathsf {Op}\) returns if \(\mathsf {S}\) queries \(\mathsf {Op}\) concerning a client \(\mathsf {C}\).

\(\mathsf {StReveal}(\mathsf {C}, i, \mathsf {bit}_{\mathsf {S}})\): returns the state of a client \(\mathsf {C}_i\) if \(\mathsf {bit}_{\mathsf {S}}= 0\) or the state of an operator with respect to a client if \(\mathsf {bit}_{\mathsf {S}}= 1\).
We consider two classes of adversaries \(\mathcal {A}\), weak and strong, depending on whether \(\mathcal {A}\) may corrupt servers or not. We model three requirements with respect to MiM adversaries.
The notion of key indistinguishability demands that the session keys for each execution be indistinguishable from random bitstrings of equal length. The corresponding game is played as follows. The challenger generates the keys of all the \(n_{\mathsf {Op}}\) operators and the \(n_{\mathsf {C}}\) clients; then it gives the \(\mathsf {n_\mathsf {S}}\) servers \(\mathsf {S}_i\) blackbox access to the operators. The adversary may query any of the oracles above, and finally issue a single Test query on a fresh instance \(\mathsf {P}_i\), which returns either the real keys this instance computed, or random ones of the same length. Strong adversaries can gain oracle access to the copies of the operators in that server. We say that an instance is fresh if, and only if: neither the party, nor the partner is corrupted, and no keyreveal was done either on this party, nor on the partner. We define partner instances as having the same session ID \(\mathsf {sid}\), which will consist of a random number \(\mathsf {R}_{}\), the client key \(\mathsf {sk}_{\mathsf {C}}\), the operator key \(\mathsf {sk}_\mathsf {Op}\), and the sequence number used in the successful server authentication \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\) ^{7}.
Definition 1
[ Weak/Strong KeyIndistinguishability ]. A keyagreement protocol \(\mathsf {\Pi }\) is \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)weakly keyindistinguishable (resp. \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)stronglykeyindistinguishable) if no adversary running in time t, creating at most \(q_{\mathsf {exec}}\) party instances with at most \(q_{\mathsf {res}}\) resynchronizations per instance, (corrupting at most \(q_{\mathsf {s}}\) servers and making at most \(q_{\mathsf {Op}}\) \(\mathsf {OpAccess}\) queries per operator per corrupted server for strong security), and making at most \(q_{\mathsf {G_{\mathsf {}}}}\) queries to function \(G_{\mathsf {}}\), has an advantage \(\mathsf {Adv}^{\mathsf {K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}}) > \epsilon \).
Definition 2
[ Weak/Strong Impersonation security ]. A keyagreement protocol \(\mathsf {\Pi }\) is \((t,q_{\mathsf {exec}},q_{\mathsf {res}},q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)weakimpersonationsecure (resp. \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)strongimpersonation secure) if no adversary running in time t, creating at most \(q_{\mathsf {exec}}\) party instances with at most \(q_{\mathsf {res}}\) resynchronizations per instance, (corrupting at most \(q_{\mathsf {s}}\) servers and making at most \(q_{\mathsf {Op}}\) \(\mathsf {OpAccess}\) queries per operator per corrupted server for strong security), and making at most \(q_{\mathsf {G_{\mathsf {}}}}\) queries to the function \(G_{\mathsf {}}\), has an advantage \(\mathsf {Adv}^{\mathsf {C.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) \ge \epsilon \) or \(\mathsf {Adv}^{\mathsf {S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) \ge \epsilon \).

\(\mathsf {Corrupt}(\mathsf {P}) \rightarrow S \): if \(\mathsf {P}\) is a client, behave as in the MiM model. If \(\mathsf {P}\) is an operator, return \(\mathsf {sk}_\mathsf {Op}\) and the tuples \(S=(\mathsf {UID}, \mathsf {sk}_{\mathsf {UID}}, \mathsf {st}_{\mathsf {C}}, \mathsf {st}_{\mathsf {Op},\mathsf {C}})\) of all clients \(\mathsf {C}\) subscribing to \(\mathsf {Op}\).

\(\mathsf {OpAccess}(\mathsf {S}, \mathsf {C}) \rightarrow m\): simulates querying \(\mathsf {C}\)’s operator on behalf of \(\mathsf {C}\) for a single session, returning the message m that \(\mathsf {Op}\) outputs to a corrupted \(\mathsf {S}\).
As opposed to keyindistinguishability, which guarantees the security of the session keys, state confidentiality protects the client and operator longterm states against malicious servers. The stateconfidentiality game begins by generating client and operator material. The adversary can use her oracles arbitrarily, finally outputting a tuple: \((\mathsf {P}_i, \mathsf {sk}_{\mathsf {UID}}^*, \mathsf {sk}_\mathsf {Op}^*, \mathsf {st}_{\mathsf {UID}}^*, \mathsf {st}_{\mathsf {Op},\mathsf {UID}}^*)\) for an uncorrupted client with identifier \(\mathsf {UID}\) such that no partner of any instance of \(\mathsf {P}\) has ever been corrupted. We say \(\mathcal {A}\) and wins if at least one of the values: \(\mathsf {sk}_{\mathsf {UID}}^*, \mathsf {sk}_\mathsf {Op}^*, \mathsf {st}_{\mathsf {UID}}^*, \mathsf {st}_{\mathsf {Op}, \mathsf {UID}}^*\) is equal to the client’s real \(\mathsf {sk}_{\mathsf {UID}}, \mathsf {sk}_\mathsf {Op}, \mathsf {st}_{\mathsf {UID}}, \mathsf {st}_{\mathsf {Op},\mathsf {UID}}\). The advantage of \(\mathcal {A}\) is: \(\mathsf {Adv}^{\mathsf {St.Conf}}_{\mathsf {\Pi }}({\mathcal {A}}) := \Pr [\mathcal {A}\ \textsf {wins}]\).
Definition 3
[ Stateconfidentiality ]. A keyagreement protocol \(\mathsf {\Pi }\) is \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)stateconfidential if no adversary running in time t, creating at most \(q_{\mathsf {exec}}\) party instances with at most \(q_{\mathsf {res}}\) resynchronizations per instance, making at most \(q_{\mathsf {Op}}\) \(\mathsf {OpAccess}\) queries and \(q_{\mathsf {G_{\mathsf {}}}}\) queries to \(G_{\mathsf {}}\), has an advantage \(\mathsf {Adv}^{\mathsf {St.Conf}}_{\mathsf {\Pi }}({\mathcal {A}}) \ge \epsilon \).
We also require the property of soundness, which demands that malicious servers cannot make an uncorrupted client instance terminate in an accepting state without help from the operator. This game resembles impersonationsecurity, but the adversary is now a legitimate server with operator access, interacting with the stateconfidentiality oracles arbitrarily, making \(q_{\mathsf {Op}}\) \(\mathsf {OpAccess}\) queries per client. The adversary wins if, and only if, there exist \((q_{\mathsf {Op}}+1)\) uncorrupted client instances that terminate in an accepted state. We also restrict this notion with respect to offline replay attacks, as for serverimpersonation. The advantage of \(\mathcal {A}\) is defined as: \(\mathsf {Adv}^{\mathsf {Sound}}_{\mathsf {\Pi }}({\mathcal {A}}) := \Pr [\mathcal {A}\ \textsf {wins}]\).
Definition 4
[ Soundness ]. A keyagreement protocol \(\mathsf {\Pi }\) is \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)serversound if no adversary running in time t, creating at most \(q_{\mathsf {exec}}\) party instances with at most \(q_{\mathsf {res}}\) resynchronizations per instance, making at most \(q_{\mathsf {Op}}\) queries to any operator \(\mathsf {Op}\) and at most \(q_{\mathsf {G_{\mathsf {}}}}\) queries to the function \(G_{\mathsf {}}\), has an advantage \(\mathsf {Adv}^{\mathsf {Sound}}_{\mathsf {\Pi }}({\mathcal {A}}) \ge \epsilon \).
4 Security of the \(\mathsf {AKA}\) Protocol
In this section, we focus on the current, unmodified version of the \(\mathsf {AKA}\) protocol with respect to the five properties formalized in Sect. 3.
In particular, parties \(\mathsf {P}\) (clients \(\mathsf {C}\) and servers \(\mathsf {S}\)) run sessions of the protocol, thus creating party instances denoted \(\mathsf {P}_i\). An instance is said to finish in an accepting state if and only if it auhenticates its partner. Each instance keeps track of a partner and a sessionID.
The partner ID \(\mathsf {pid}\) of an accepting client instance \(\mathsf {C}_i\) is \(\mathsf {S}\) (this reflects the lack of server identifiers); server instances \(\mathsf {S}_i\), have a \(\mathsf {pid}\) corresponding to a unique \(\mathsf {UID}\). The session ID \(\mathsf {sid}\) of each instance consists of: \(\mathsf {UID}\), \(\mathsf {R}_{}\), and the value \(\mathsf {Sqn_{}}\) that is agreed upon during the session. In the absence of resynchronization, the session ID is \((\mathsf {UID}, \mathsf {R}_{,} \mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}})\). During resynchronization, the operator updates \(\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}\) to the client’s \(\mathsf {Sqn_{\mathsf {C}}}\); this update is taken into account in the \(\mathsf {sid}\). Any two partners (same \(\mathsf {sid}\)) with accepting states compute session keys (\(\mathsf {CK}\Vert \mathsf {IK}\)).
A Unitary Function \(G_{\mathsf {}}\) . We analyse the security of \(\mathsf {AKA}\) in two steps. First, we reduce it to the pseudorandomness of an intermediate, unitary function \(G_{\mathsf {}}\). This function models the suite of seven algorithms used in \(\mathsf {AKA}\); each algorithm is a specific call to \(G_{\mathsf {}}\). For the stateconfidentiality property we must also assume the pseudorandomness of the related unitary function \(G_{\mathsf {}}^*\), which is the same as \(G_{\mathsf {}}\), but we key it with the operator key \(\mathsf {sk}_\mathsf {Op}\) rather than the client key \(\mathsf {sk}_{}\). This first step gives a sufficient condition to provide \(\mathsf {AKA}\) security for any suite of algorithms intended to be used within it. As a second step (showed in the full version), we prove that both \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\), guarantee this property.
We note that the pseudorandomness of \(G_{\mathsf {}}\) implies the pseudorandomness of each subalgorithm, but is a strictly stronger property, which is necessary since the session keys \(\mathsf {CK}\) and \(\mathsf {IK}\), computed by two different algorithms on the same input, must be independent.
4.1 Provable Security Guarantees
The existing \(\mathsf {AKA}\) protocol only attains the weaker versions of keyindistinguishability, client, and serverimpersonation resistance. The protocol also guarantees stateconfidentiality and soundness with respect to malicious servers.
Denote by \(\mathsf {\Pi }\) the \(\mathsf {AKA}\) protocol described in Sect. 2, but in which the calls to the internal cryptographic functions \(\mathcal {F}_{1}, \dots , \mathcal {F}_{5}, \mathcal {F}_{1}^*, \mathcal {F}_{5}^*\) are replaced by calls to the function \(G_{\mathsf {}}:\{0,1\}^{\kappa } \times \{0,1\}^{d} \times \{0,1\}^{t} \times \{0,1\}^{t} \rightarrow \{0,1\}^n\), in which \(\kappa \) is a security parameter, d is a positive integer strictly larger than the size of the operator key, and t indicates the block size of an underlying pseudorandom permutation. As we detail in the full paper, the exact values of d, t, and n differ for \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\); however, the construction of \(G_{\mathsf {}}\) is somewhat similar.
We denote by \(\mathcal {S}_{\mathsf {C}} := \{0,1\}^{\kappa }\) the keyspace for the client keys and by \(\mathcal {S}_{\mathsf {Op}} := \{0,1\}^{e}\), the key space for operator keys, for some specified \(e < d\) (in practice \(e = 256\)). Our system features \(n_{\mathsf {C}}\) clients, \(\mathsf {n_{\mathsf {S}}}\) servers and \(n_{\mathsf {Op}}\) operators.
Security Statements. We group the five security statements that we prove for the \(\mathsf {AKA}\) protocol into two theorems. The first groups the properties of: weak keyindistinguishability, strong client and weak serverimpersonation resistance, and soundness with respect to servers. The second theorem is that for stateconfidentiality, which requires an additional assumption. We defer the proofs for the full version.
Our security statements are phrased with respect to an adversary \(\mathcal {A}\) trying to break (in some way) the security of \(\mathsf {\Pi }\), which runs in time t, creates at most \(q_{\mathsf {exec}}\) party instances with at most \(q_{\mathsf {res}}\) resynchronizations per instance, and makes at most \(q_{G_{\mathsf {}}}\) queries to the function \(G_{\mathsf {}}\). Furthermore, in the case of strong MiM adversary, it can also corrupt at most \(q_{\mathsf {s}}\) servers and make at most \(q_{\mathsf {Op}}\) \(\mathsf {OpAccess}\) queries per operator per corrupted server. For the legitimateandmalicious adversary, we quantify \(\mathcal {A}\) in terms of the maximal number \(q_{\mathsf {Op}}\) of queries to the oracle \(\mathsf {OpAccess}\), and the similar \(q_{\mathsf {exec}}\), \(q_{\mathsf {res}}\) and \(q_{G_{\mathsf {}}}\) queries.
The function \(G_{\mathsf {}}\) is defined as above.
Theorem 1
 \(\mathsf {W.K.Ind}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{G_{\mathsf {}}})\)adversary \(\mathcal {A}\) against the \(\mathsf {W.K.Ind}\)security of \(\mathsf {\Pi }\) winning with advantage \(\mathsf {Adv}^{\mathsf {W.K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}})\) there exists a \((t' \approx O(t), q' = q_{G_{\mathsf {}}} +q_{\mathsf {exec}}(2+q_{\mathsf {res}}))\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) with:$$\begin{aligned} \mathsf {Adv}^{\mathsf {W.K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg (\frac{q_{\mathsf {exec}}^2}{2^{\mathsf {R}_{}}} + \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}')\bigg ). \end{aligned}$$
 \(\mathsf {S.C.Imp}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}},q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{G_{\mathsf {}}})\)adversary \(\mathcal {A}\) against the \(\mathsf {S.C.Imp}\)security of \(\mathsf {\Pi }\), winning with advantage \(\mathsf {Adv}^{\mathsf {S.C.Imp}}_{\mathsf {\Pi }}({\mathcal {A}})\), there exists a \((t' \approx O(t), q' = 5 \cdot q_{\mathsf {s}}\cdot q_{\mathsf {Op}}+ q_{G_{\mathsf {}}} + q_{\mathsf {exec}}(q_{\mathsf {res}}+2))\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) such that:$$\begin{aligned} \mathsf {Adv}^{\mathsf {S.C.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg (2 \cdot \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}') + \frac{(q_{\mathsf {exec}}+q_{\mathsf {s}}\cdot q_{\mathsf {Op}})^2}{2^{\mathsf {R}_{}}} + \frac{q_{\mathsf {exec}}\cdot q_{\mathsf {res}}}{2^{\mathsf {Res}}} + \frac{1}{2^{\kappa }}\bigg ). \end{aligned}$$
 \(\mathsf {W.S.Imp}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {G_{\mathsf {}}}})\)adversary \(\mathcal {A}\) against the \(\mathsf {W.S.Imp}\)security of \(\mathsf {\Pi }\), winning with advantage \(\mathsf {Adv}^{\mathsf {W.S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}})\), there exists a \((t' \approx t, q = q_{\mathsf {exec}}\cdot (q_{\mathsf {res}}+ 2) + q_{\mathsf {G_{\mathsf {}}}})\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) such that:$$ \mathsf {Adv}^{\mathsf {W.S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg (\mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}') + \frac{q_{\mathsf {exec}}\cdot q_{\mathsf {res}}}{2^{\mathsf {Mac}_{\mathsf {\mathsf {S}}}}} + \frac{1}{2^{\kappa }}\bigg ). $$
 \(\mathsf {Sound}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )\)adversary \(\mathcal {A}\) against the soundness of \(\mathsf {\Pi }\), winning with advantage \(\mathsf {Adv}^{\mathsf {Sound}}_{\mathsf {\Pi }}({\mathcal {A}})\), there exists a \((t' \approx t, q' = 5 \cdot q_{\mathsf {Op}}\ + q_{G_{\mathsf {}}} + n_{\mathsf {C}}\cdot q_{\mathsf {exec}}(2+q_{\mathsf {res}}))\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) such that:$$ \mathsf {Adv}^{\mathsf {Sound}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg ( 2 \cdot \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}') + \frac{q_{\mathsf {exec}}\cdot q_{\mathsf {res}}}{2^{\mathsf {Mac}_{\mathsf {\mathsf {S}}}}} + \frac{1}{2^{\kappa }}\bigg ). $$
Theorem 2
\(\mathsf {MILENAGE}\) and \(\mathsf {TUAK}\) . Our second step is to prove that \(\mathsf {TUAK}\) and \(\mathsf {MILENAGE}\) both behave as the generic function \(G_{\mathsf {}}\). Due to space constraints, we only propose two theorems of the pseudorandomness of these functions and leave all the details to the full paper. Notably, as opposed to \(\mathsf {TUAK}\) (whose symmetric design allows a lot more leeway), the \(\mathsf {MILENAGE}\) algorithms require a stronger assumption to prove the PRF property for \(G_{\mathsf {}}^*\) (which is keyed with \(\mathsf {sk}_\mathsf {Op}\)).
Theorem 3
Theorem 4
4.2 Vulnerabilities of the \(\mathsf {AKA}\) Protocol
In the threeparty mobile setting, the server is authenticated by the client if it presents credentials (authentication vectors) generated by the client’s operator. The properties of stateconfidentiality and soundness, which the \(\mathsf {AKA}\) protocol guarantees, indicate that servers cannot learn the client’s longterm data, and that they cannot authenticate without the operatorgenerated data.
However, Zhang [15] and Zhang and Fang [16] pointed out that once a server is corrupted, it can obtain legitimate authentication data from the client’s operator, and then use this data to set up a False Base Station (FBS), which can lead to a malicious, unauthorised server authenticating to the client. As a result, the \(\mathsf {AKA}\) protocol does not guarantee strong keyindistinguishability, nor strong serverimpersonation resistance.
Such attack do not, however, affect clientimpersonation resistance, since the server cannot use an authentication vector from the server to respond to a freshlygenerated authentication challenge (the random value for the two authentication vectors is different).
5 Additional Security with Few Modifications
The main reason servercorruption attacks are effective is that servers associated with a specific geographic area (like a country, a region, etc.) can reuse authentication vectors given by the operator in a different geographic area, impersonating the legitimate server associated with that area. This vulnerability, however, is easily fixed as long as the client’s device is aware of its geographical location. Our solution is to add a unique server identifier, denoted \(\mathsf {Id}_{\mathsf {S}}\), to the input of each of the cryptographic functions, thus making any leftover authentication tokens unreplayable in the wrong area. We stress that this is a minor modification to the protocol, as servers are already associated with a unique \(\mathsf {LAI}\) identifier.
Security of the Modified AKA Protocol. This modification still (trivially) preserves the properties of strong clientimpersonation resistance, soundness, and state confidentiality. However, the modification yields in addition strong keyindistinguishability and serverimpersonation resistance, as we detail below. The proofs are given in the full version.
Theorem 5
 \(\mathsf {S.K.Ind}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}},q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{G_{\mathsf {}}})\)adversary \(\mathcal {A}\) against the \(\mathsf {S.K.Ind}\)security of \(\mathsf {\Pi }\) winning with advantage \(\mathsf {Adv}^{\mathsf {S.K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}})\) there exists a \((t' \approx O(t), q' = 5 \cdot q_{\mathsf {s}}\cdot q_{\mathsf {Op}}+ q_{G_{\mathsf {}}} +q_{\mathsf {exec}}(q_{\mathsf {res}}+2))\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) with:$$\begin{aligned} \mathsf {Adv}^{\mathsf {S.K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg (\frac{(q_{\mathsf {exec}}+q_{\mathsf {s}}\cdot q_{\mathsf {Op}})^2}{2^{\mathsf {R}_{}}} + 2 \cdot \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}')\bigg ). \end{aligned}$$
 \(\mathsf {S.S.Imp}\). For any \((t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {s}}, q_{\mathsf {Op}}, \ q_{\mathsf {G_{\mathsf {}}}})\)adversary \(\mathcal {A}\) against the \(\mathsf {S.S.Imp}\)security of \(\mathsf {\Pi }\), winning with advantage \(\mathsf {Adv}^{\mathsf {S.S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}})\), there exists a \((t' \approx O(t), q' = 5 \cdot q_{\mathsf {s}}\cdot q_{\mathsf {Op}}\ + q_{G_{\mathsf {}}} + q_{\mathsf {exec}}(2+q_{\mathsf {res}}))\)adversary \(\mathcal {A}'\) against the pseudorandomness of \(G_{\mathsf {}}\) such that:$$ \mathsf {Adv}^{\mathsf {S.S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}_{\mathbb {G}_{0}}}) \le n_{\mathsf {C}}\cdot \bigg (\frac{q_{\mathsf {exec}}\cdot q_{\mathsf {res}}}{2^{\mathsf {Mac}_{\mathsf {\mathsf {S}}}}} + \frac{1}{2^{\kappa }} + 2 \cdot \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}')\bigg ). $$
Each of the two bounds above depend linearly on the number of clients \(n_{\mathsf {C}}\); while this number can be as large as, potentially, six billion, the size of the secret keys (128 or 256 bits) and of the random value (128 bits) can still make the bound negligible. The linear factor \(n_{\mathsf {C}}\), however, highlights the importance of using authentication strings longer than 128 bits for authentication.
Footnotes
 1.
We stress that while \(\mathsf {AKA}\) is an instance of authenticated keyexchange, AKE denotes a larger class of protocols, including e.g. TLS/SSL, PACE/EAC, etc.
 2.
 3.
Notably, since the server is not trusted, it needs information from the client’s operator to provide service to the client.
 4.
This key, denoted \(\mathsf {K_{asme}}\), is computed as: \(\mathsf {K_{asme}}=\mathsf {KDF(\mathsf {CK}\Vert \mathsf {IK}, \mathsf {ID_{SN}}, \mathsf {Sqn_{}} \oplus \mathsf {AK}, const)}\), with \(\mathsf {ID_{SN}}\) the serving operator network identity.
 5.
Technically speaking, the client never stores this value in clear; instead it uses a pseudorandom value \(\mathsf {Top}_C\) computed from the client and operator keys.
 6.
In this we keep faithful to the implementation of \(\mathsf {AKA}\), which protects \(\mathsf {sk}_\mathsf {Op}\) from the user by storing a 1way function of \(\mathsf {sk}_\mathsf {Op}\) and \(\mathsf {sk}_{\mathsf {C}}\) in the SIM card. Another approach would be to reveal an intermediate, \(\mathsf {AKA}\)specific value denoted \(\mathsf {Top}_C\) upon corruption. In the interest of generality, we keep the model at a higher level of abstraction than the peculiarities of \(\mathsf {AKA}\). We also note that in our proofs, a common first step is to give the adversary access to a broader corruption oracle, which also reveals \(\mathsf {sk}_\mathsf {Op}\), with no security loss.
 7.
This choice of \(\mathsf {pid}\) and \(\mathsf {sid}\) makes our security guarantee noncomposable; however, the design of \(\mathsf {AKA}\) makes it hard to define \(\mathsf {pid}\)s based only on publiclyknown values.
References
 1.3GPP: 3G Security, Specification of the MILENAGE algorithm set: an example algorithm set for the 3Gpp. Authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document 2: algorithm specification. TS 35.206, 3rd Generation Partnership Project (3GPP), June 2007Google Scholar
 2.3GPP: 3G Security, Specification of the TUAK algorithm set: a 2nd example for the 3Gpp. Authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5* \(\) Document 1: algorithm specification. TS 35.231, 3rd Generation Partnership Project (3GPP), June 2013Google Scholar
 3.Shaik, A., Borgaonkar, R., Asokan, N., Niemi, V., Seifert, J.P.: Practical attacks against privacy and availability in 4G/LTE mobile communication systems. In: Accepted to NDSS 2016 (2016)Google Scholar
 4.Arapinis, M., Chothia, T., Ritter, E., Ryan, M.: Analysing unlinkability and anonymity using the applied Pi calculus. In: Proceedings of the CSF 2010, pp. 107–121 (2010)Google Scholar
 5.Arapinis, M., Mancini, L.I., Ritter, E., Ryan, M., Golde, N., Redon, K., Borgaonkar, R.: New privacy issues in mobile telephony: fix and verification. In: Proceedings of ACM CCSGoogle Scholar
 6.Arapinis, M., Ritter, E., Ryan, M.D.: StatVerif: verification of stateful processes. In: Proceedings of CSF 2011, pp. 33–47 (2011)Google Scholar
 7.Bellare, M., Pointcheval, D., Rogaway, P.: Authenticated key exchange secure against dictionary attacks. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 139–155. Springer, Heidelberg (2000)CrossRefGoogle Scholar
 8.Bellare, M., Rogaway, P.: Entity authentication and key distribution. In: Stinson, D.R. (ed.) CRYPTO 1993. LNCS, vol. 773, pp. 232–249. Springer, Heidelberg (1994)CrossRefGoogle Scholar
 9.Bertoni, G., Daemen, J., Peeters, M., Van Assche, G.: On the indifferentiability of the sponge construction. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 181–197. Springer, Heidelberg (2008)CrossRefGoogle Scholar
 10.Blanchet, B.: Automatic verification of security protocols in the symbolic model: the verifier ProVerif. In: Aldini, A., Lopez, J., Martinelli, F. (eds.) FOSAD VII. LNCS, vol. 8604, pp. 54–87. Springer, Heidelberg (2014)Google Scholar
 11.Gilbert, H.: The security of “OneBlocktoMany” modes of operation. In: Johansson, T. (ed.) FSE 2003. LNCS, vol. 2887, pp. 376–395. Springer, Heidelberg (2003)CrossRefGoogle Scholar
 12.Hall, C., Wagner, D., Kelsey, J., Schneier, B.: Building PRFs from PRPsGoogle Scholar
 13.Lee, M., Smart, N., Warinschi, B., Watson, G.: Anonymity guarantees of the UMTS/LTE authentication and connection protocol. Int. J. Inf. Sec. 13(6), 513–527 (2014)CrossRefGoogle Scholar
 14.Strobel, D.: IMSI catcher. In: Seminar Work, RuhrUniversitat Bochum (2007)Google Scholar
 15.Zhang, M.: ProvablySecure Enhancement on 3Gpp. Authentication and Key Agreement Protocol. In: IACR Cryptology ePrint Archive 2003, p. 92 (2003). http://eprint.iacr.org/2003/092
 16.Zhang, M., Fang, Y.: Security analysis and enhancements of 3GPP authentication and key agreement protocol. IEEE Trans. Wirel. Commun. 4(2), 734–742 (2005)CrossRefGoogle Scholar