A Cryptographic Analysis of UMTS/LTE AKA

Abstract

Secure communications between mobile subscribers and their associated operator networks require mutual authentication and key deri-vation 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 currently-used 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 three-party setting. We formulate requirements with respect to both Man-in-the-Middle (MiM) adversaries, i.e. key-indistinguishability and impersonation security, and to local untrusted serving networks, denoted “servers”, namely state-confidentiality 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 real-life scenarios.

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 key-exchange (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¹. 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)², from both an architectural and a security-algorithm standpoint.

The $\mathsf {AKA}$ Protocol. Initially developed in the 1990s, $\mathsf {AKA}$ uses symmetric keys exclusively, in a mobile-network 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 long-term secrets (known only to the client and the operator); by contrast, servers do learn short-term secret values, such as session keys, which are necessary for the transmission of the required service. Consequently, unlike the classical two-party AKE setting, the $\mathsf {AKA}$ protocol requires three participants.

One specificity of the subscriber-operator architecture is that clients are associated both with a unique client-key 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 (one-way) 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³ 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 symmetric-key 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 AES-encryption-based 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, black-box way, but rather rely on something akin to a Merkle-Damgå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 server-impersonation 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 Bellare-Pointcheval-Rogaway (BPR) extension of this model [7]; however, the three-party 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 out-of-context 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 server-corruption attack against $\mathsf {AKA}$ and advised against the use of sequence numbers as state. He also presented a stateless modification of the protocol called AP-AKA and proved its security in Shoup’s model. In the full version of this paper, we show that AP-AKA is still vulnerable to a particular type of replay attack. Server corruptions are a highly relevant threat in a post-Snowden 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 server-specific 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 (Long-term Evolution) protocol in 4G networks (similar to $\mathsf {AKA}$, but using different identifiers and key-management), 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 IMSI-catcher attacks (which directly impact privacy without server corruptions); this is because, contrary to real-world 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 state-permissive tool called StatVerif [6] were not fruitful, as discussed in the full paper.

Our Contributions. We present four main contributions: (a) fully-formalized 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 somewhat-similar 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.

Security Model. We first define a threat model and five game-based security notions for the 3-party $\mathsf {AKA}$ protocol, three with respect to a Man-in-the-Middle –MiM– adversary (akin to BPR security, but with three parties, allowing server corruptions for the strong, as opposed to the weak property), and two with respect to malicious servers. These properties are:

• 1. Key-indistinguishability: the derived session keys are indistinguishable from random by a MiM attacker placed between the client and a server with black-box access to all operators.

• 2. Client- and server-impersonation: 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. State-confidentiality: (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 secure-channel primitives).

• 4. Soundness: (malicious) servers cannot authenticate to the client unless they are explicitly given authenticating information by a legitimate operator.

Security Proofs. We analyse the security of two versions of $\mathsf {AKA}$: the current one, and our modification of it. In the full version, we also show that the AP-AKA version of the protocol, due to Zhang, is vulnerable to a replay attack. We prove that, under the assumption that the seven cryptographic functions behave as a unitary function $G_{\mathsf {}}$ that is pseudorandom when keyed with the client key, the current $\mathsf {AKA}$ version guarantees: weak key-indistinguishability; weak server-impersonation resistance; strong client-impersonation resistance; and soundness. If furthermore the algorithms behave as a PRF called $G_{\mathsf {}}^*$, when keyed with the operator key, $\mathsf {AKA}$ also guarantees state confidentiality. For our modification of the $\mathsf {AKA}$ protocol, we prove, under the same assumptions: state-indistinguishabi-lity, soundness, as well as strong key-indistinguishability, server- and client-impersonation security. This first proof step, reducing protocol security to that of a unitary function, allows us to define a sufficient security requirement for the underlying sub-algorithms.

$\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 AES-version of a classic Davies-Meyer 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–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 message-exchanges. 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.⁴ 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 selectively-active 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 long-term 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}$ ⁵. 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 re-synchronization. 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 $\mathsf {AKA}$ protocol, depicted in Fig. 1, proceeds in several subparts. The first two protocol exchanges are between the client $\mathsf {C}$ and the server $\mathsf {S}$ over an insecure channel and they make up the user identification step. At the end of this phase, the server will associate $\mathsf {C}$ with an identifier, either the permanent International Mobile Subscriber Identity $\mathsf {IMSI}$ or the tuple of a Temporary Mobile Subscriber Identity $\mathsf {TMSI}$ and the Local Area Identifier $\mathsf {LAI}$ of the server issuing the latest $\mathsf {TMSI}$. The identification procedure is vital to the client’s privacy; however, as we focus here only on the security of $\mathsf {AKA}$, we just associate each client with a unique user ID $\mathsf {UID}$ (as we explain at the end of this section). Once the server associates the client with an identifier $\mathsf {UID}$, it proceeds either to the authentication vector generation step (detailed in the set $\textcircled {\small {1}}$ of instructions in Fig. 1), or to the authenticated key-exchange part (detailed in instruction sets $\textcircled {\small {2}}$-$\textcircled {\small {4}}$). The former of these is run by the server and the operator of the client $\mathsf {C}$ over a secure channel, and it provides the server $\mathsf {S}$ with authentication and key-exchange material for a batch of $\mathsf {AKA}$ sessions with $\mathsf {C}$; whenever $\mathsf {S}$ runs out of AKE material, it re-runs the vector generation step. For each session, $\mathsf {Op}$ prepares an authentication vector $\mathsf {AV}$ consisting of: a fresh random value $\mathsf {R}_{}$; a server-authentication string $\mathsf {Mac}_{\mathsf {\mathsf {S}}}$ (authenticating $\mathsf {R}_{}$ and the value $\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}$); a client-authentication string $\mathsf {Mac}_{\mathsf {\mathsf {C}}}$ (authenticating $\mathsf {R}_{}$ only); the session keys $\mathsf {CK}$ and $\mathsf {IK}$; and a one-time-pad encryption of $\mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}}$ with a pseudorandom string $\mathsf {AK}$. The values $\mathsf {Mac}_{\mathsf {\mathsf {S}}}, \mathsf {Mac}_{\mathsf {\mathsf {C}}}, \mathsf {CK}, \mathsf {IK}, \mathsf {AK}$ are output by cryptographic algorithms denoted $\mathcal {F}_{1}, \dots , \mathcal {F}_{5}$ respectively. The $\mathsf {AKA}$ protocol also features the algorithms $\mathcal {F}_{1}^*, \mathcal {F}_{5}^*$ for re-synchronization. All algorithms take as input the client key $\mathsf {sk}_{\mathsf {C}}$, the operator key $\mathsf {sk}_\mathsf {Op}$, and the random value $\mathsf {R}_{}$; in addition, $\mathcal {F}_{1}$ and $\mathcal {F}_{1}^*$ also use the operator’s and resp. the client’s sequence number. The server is given a batch of vectors of the form: $\mathsf {AV}=(\mathsf {R}_{}, \mathsf {CK}, \mathsf {IK}, \mathsf {Mac}_{\mathsf {\mathsf {S}}}, \mathsf {Mac}_{\mathsf {\mathsf {C}}}, \mathsf {AMF}, \mathsf {AK}\oplus \mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}})$, in which $\mathsf {AMF}$ is a public authentication management field managed by the operator.

Fig. 1.

The AKA procedure.

The authenticated-key-exchange 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 re-synchronization, 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}$ re-allocation. During the optional re-synchronization, 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}$ re-allocation. 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 agreed-upon 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 newly-allocated $\mathsf {TMSI}$ is reliable and non-modifiable 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: key-indistinguishability for the session keys $\mathsf {CK},\mathsf {IK}$, and client- and server-impersonation resistance. With respect to servers, we also require the key-confidentiality 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 three-party setting, we guarantee a same kind of security with respect to MiM attackers. While our server-impersonation model is slightly weaker than that for client-impersonation, this has no impact on the key-indistinguishability 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 black-box 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}$, long-term 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 black-box access to operator algorithms (or oracles for state-confidentiality and soundness) $\mathsf {Op}_1, \dots , \mathsf {Op}_{n_{\mathsf {Op}}}$, initialised with long-term 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 j-th 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}$ ⁶. 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$ black-box 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 key-reveal 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}}}$ ⁷.

Finally, $\mathcal {A}$ determines whether the returned keys were real or random, and wins if, and only if its response is correct. The adversary’s advantage is defined as:

$$ \mathsf {Adv}^{\mathsf {K.Ind}}_{\mathsf {\Pi }}({\mathcal {A}}) := |\Pr [\mathcal {A}\ \textsf {wins}] - 1/2|. $$

Definition 1

[ Weak/Strong Key-Indistinguishability ]. A key-agreement protocol $\mathsf {\Pi }$ is $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-weakly key-indistinguishable (resp. $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-strongly-key-indistinguishable) 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$.

We also consider impersonation attacks, in which $\mathcal {A}$ aims to impersonate a partner of a fresh instance. Again, the game begins by generating keys; then $\mathcal {A}$ gains access to all the oracles (except server corruption/operator access for weak adversaries). When $\mathcal {A}$ stops, she wins if, and only if, there exists an instance (server-instance $\mathsf {S}_i$ for client-impersonation, client-instance $\mathsf {C}_i$ for the server-impersonation) that ends in an accepting state and is fresh, subject to an offline/online relay attack described below. The adversary’s advantage is:

$$ \mathsf {Adv}^{\mathsf {C.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) := \Pr [\mathcal {A}\ \textsf {wins}], \text { and respectively } \mathsf {Adv}^{\mathsf {S.Imp}}_{\mathsf {\Pi }}({\mathcal {A}}) := \Pr [\mathcal {A}\ \textsf {wins}]. $$

Definition 2

[ Weak/Strong Impersonation security ]. A key-agreement protocol $\mathsf {\Pi }$ is $(t,q_{\mathsf {exec}},q_{\mathsf {res}},q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-weak-impersonation-secure (resp. $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {s}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-strong-impersonation 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$.

Though $\mathsf {AKA}$ is claimed to provide mutual authentication, its design introduces a vulnerability, leading to a subtle difference between the client-impersona-tion and server-impersonation guarantees. In fact, the protocol allows $\mathcal {A}$ to run a MiM attack resembling a relay attack. Servers can be impersonated even if we rule out online relays (an adversary just forwards messages from a server to a client instance, and vice versa): $\mathcal {A}$ merely performs an out-of-order (offline) relay as described in the third scenario of Fig. 2, as explained below. This is the gap between the client- and the server-impersonation guarantees for the $\mathsf {AKA}$ protocol. Our server-impersonation model rules out both offline and online relays, whereas client-impersonation only rules out online relays.

Fig. 2.

Examples of Online and Offline relays. For the $\mathsf {AKA}$ protocol, the message m is the client’s $\mathsf {UID}$, which the adversary can learn. The message $m'$ is a valid authentication challenge, and the message $m''$ is the authentication response. The message $\hat{m}$ is the $\mathsf {UID}$ request message, whereas $m^*$ is a random message.

Security Against Servers. We also formalize the notions of state-confidentiality and soundness with respect to a malicious server $\mathsf {S}$. The former requirement demands that (malicious) servers cannot learn the values: $\mathsf {sk}_{\mathsf {C}}$, $\mathsf {sk}_\mathsf {Op}$, and the tuple $(\mathsf {Sqn_{\mathsf {C}}}, \mathsf {Sqn_{\mathsf {Op}, \mathsf {C}}})$. We use a similar model as for the MiM-adversary model, except that now the adversary has oracle access to the operators. We preserve the oracles $\mathsf {UReg}, \mathsf {NewInstance}$, $\mathsf {Execute}$, $\mathsf {Send}$, $\mathsf {Reveal}$, $\mathsf {StReveal}$ described above, and add the following two oracles (with a modification of $\mathsf {Corrupt}$):

• $\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 key-indistinguishability, which guarantees the security of the session keys, state confidentiality protects the client- and operator long-term states against malicious servers. The state-confidentiality 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

[ State-confidentiality ]. A key-agreement protocol $\mathsf {\Pi }$ is $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-state-confidential 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 impersonation-security, but the adversary is now a legitimate server with operator access, interacting with the state-confidentiality 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 server-impersonation. 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 key-agreement protocol $\mathsf {\Pi }$ is $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{\mathsf {G_{\mathsf {}}}}, \epsilon )$-server-sound 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 session-ID.

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 re-synchronization, 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 state-confidentiality 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 sub-algorithm, 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 key-indistinguishability, client-, and server-impersonation resistance. The protocol also guarantees state-confidentiality 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 pseudo-random 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 key-space 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 key-indistinguishability, strong client- and weak server-impersonation resistance, and soundness with respect to servers. The second theorem is that for state-confidentiality, 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 legitimate-and-malicious 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}$, $\mathsf {S.C.Imp}$, $\mathsf {W.S.Imp}$, $\mathsf {Sound}$]. For the protocol $\mathsf {\Pi }$ using the unitary function $G_{\mathsf {}}$ described above, the following properties hold:

• $\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 {St.Conf}$ -resistance ]. For the protocol $\mathsf {\Pi }$ using the unitary functions $G_{\mathsf {}}, G_{\mathsf {}}^*$, for any $(t, q_{\mathsf {exec}}, q_{\mathsf {res}}, q_{\mathsf {Op}}, q_{G_{\mathsf {}}}, q_{G_{\mathsf {}}^*})$-adversary $\mathcal {A}$ against the $\mathsf {St.Conf}$-security of $\mathsf {\Pi }$, winning with advantage $\mathsf {Adv}^{\mathsf {St.Conf}}_{\mathsf {\Pi }}({\mathcal {A}})$, there exist: a $(t' \approx O(t), q' = q_{G_{\mathsf {}}} + q_{\mathsf {exec}}(5+q_{\mathsf {res}}))$-prf-adversary $\mathcal {A}_1$ on $G_{\mathsf {}}$ and $(t' \approx O(t), q' = q_{G_{\mathsf {}}^*})$-prf-adversary $\mathcal {A}_2$ on $G_{\mathsf {}}^*$ such that:

$$\begin{aligned} \mathsf {Adv}^{\mathsf {St.Conf}}_{\mathsf {\Pi }}({\mathcal {A}}) \le n_{\mathsf {C}}\cdot \bigg ( \frac{1}{2^{|\mathsf {sk}_{\mathsf {C}}|}} + \frac{1}{2^{|\mathsf {sk}_{\mathsf {Op}}|}} + \frac{2}{2^{|\mathsf {Sqn_{}}|}} + \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}}(\mathcal {A}_1) + \mathsf {Adv}^{\mathsf {prf}}_{G_{\mathsf {}}^*}(\mathcal {A}_2)\bigg ). \end{aligned}$$

$\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

[ $\mathsf {prf}$ -security for $\mathsf {TUAK}$ algorithms ]. For the generalization of the $\mathsf {TUAK}$ algorithms $G_{\mathsf {tuak}}$ (resp. $G_{\mathsf {tuak}}^*$) keyed with the subscriber key (resp. the operator key) and the functions $f_{}$ and $f_{}^*$ two different truncated keyed internal permutation of $\mathsf {Keccak}$, for any (t, q)-adversary $\mathcal {A}$ against the pseudorandomness of the function $f_{}$ (resp. $f_{}^*$), then there exists a $(t' \approx t, q'=q)$-adversary $\mathcal {A}$’ such that:

$$\begin{aligned} \mathsf {Adv}_{G_{\mathsf {tuak}}}^{\mathsf {prf}}(\mathcal {A})= \mathsf {Adv}_{f_{}}^{\mathsf {prf}}(\mathcal {A}') \quad \quad \mathsf {Adv}_{G_{\mathsf {tuak}}^*}^{\mathsf {prf}}(\mathcal {A})= \mathsf {Adv}_{f_{}^*}^{\mathsf {prf}}(\mathcal {A}'). \end{aligned}$$

Theorem 4

[ $\mathsf {prf}$ -security for $\mathsf {MILENAGE}$ algorithms ]. For the generalization of the $\mathsf {MILENAGE}$ algorithms $G_{\mathsf {mil1}}$ and $G_{\mathsf {mil2}}$ (resp. $G_{\mathsf {mil1}}^*$ and $G_{\mathsf {mil2}}^*$) keyed with the subscriber key (resp. the operator key) and the function $f_{}$ (resp. $f_{}^*$) the $\mathsf {AES}$ algorithm (resp. a keyed version of a classic Davies-Meyer), for any (t, q)-adversary $\mathcal {A}$ against the pseudorandomness of the function $f_{}$ (resp. $f_{}^*$), then there exists a $(t' \approx 3 \cdot t, q'=3 \cdot q)$-adversary $\mathcal {A}$’ such that:

$$\begin{aligned} \mathsf {Adv}_{G_{\mathsf {mil1}}}^{\mathsf {prf}}(\mathcal {A})= \mathsf {Adv}_{f_{}}^{\mathsf {prf}}(\mathcal {A}') (=\mathsf {Adv}_{G_{\mathsf {mil2}}}^{\mathsf {prf}}(\mathcal {A})), \mathsf {Adv}_{G_{\mathsf {mil1}}^*}^{\mathsf {prf}}(\mathcal {A})= \mathsf {Adv}_{f_{}^*}^{\mathsf {prf}}(\mathcal {A}') (=\mathsf {Adv}_{G_{\mathsf {mil2}}^*}^{\mathsf {prf}}(\mathcal {A})). \end{aligned}$$

4.2 Vulnerabilities of the $\mathsf {AKA}$ Protocol

In the three-party mobile setting, the server is authenticated by the client if it presents credentials (authentication vectors) generated by the client’s operator. The properties of state-confidentiality and soundness, which the $\mathsf {AKA}$ protocol guarantees, indicate that servers cannot learn the client’s long-term data, and that they cannot authenticate without the operator-generated 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 key-indistinguishability, nor strong server-impersonation resistance.

The main attack strategy is also depicted in Fig. 3. In a first step, the client $\mathsf {C}$ is assumed to be in the LAI corresponding to a server $\mathsf {S}^*$, which will later be corrupted. The server receives a batch of authentication vectors ($\textsf {AV}_1, \dots , \textsf {AV}_n$), using some of them (vectors $\textsf {AV}_1, \dots , \textsf {AV}_k$) to provide service to that client (and learn what services this client has provided, etc.). Subsequently, the client moves to a different $\mathsf {LAI}$, outside the corrupted network’s area. The adversary $\mathcal {A}$ has corrupted the server $\mathsf {S}^*$ and learned the remaining vectors $\textsf {AV}_{k+1}, \dots , \textsf {AV}_n$; this adversary then uses this authentication data to authenticate to the client, in its new location. This immediately breaks the server-impersonation guarantee. Moreover, since authentication vectors also contain the short-term session keys, key-indistinguishability is breached, too. This attack is particularly dangerous since a single server corruption can affect a very large number of clients. Moreover, server corruption is easily practiced in totalitarian regimes, in which mobile providers are subject to the state, and partial data is furthermore likely to be leaked upon using backdoored algorithms.

Fig. 3.

The attack of Zhang and Fang. On the right hand side, the client is in the vulnerable network, interacting with the server $\mathsf {S}^*$. The server uses up authentication vectors $\textsf {AV}_1, \dots \textsf {AK}_k$. Then, the server $\mathsf {S}^*$ is corrupted, and the adversary $\mathcal {A}$ learns $\textsf {AV}_{k+1}, \dots , \textsf {AV}_n$, which it uses in a second attack phase (on the left).

Such attack do not, however, affect client-impersonation resistance, since the server cannot use an authentication vector from the server to respond to a freshly-generated authentication challenge (the random value for the two authentication vectors is different).

5 Additional Security with Few Modifications

The main reason server-corruption attacks are effective is that servers associated with a specific geographic area (like a country, a region, etc.) can re-use 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 un-replayable 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.

We also show in the full version how to include $\mathsf {Id}_{\mathsf {S}}$ in the computation of each of the cryptographic algorithms. We present our modified protocol in Fig. 4.

Fig. 4.

The modified instructions of our variant.

Security of the Modified AKA Protocol. This modification still (trivially) preserves the properties of strong client-impersonation resistance, soundness, and state confidentiality. However, the modification yields in addition strong key-indistinguishability and server-impersonation resistance, as we detail below. The proofs are given in the full version.

Theorem 5

[ $\mathsf {S.K.Ind}$ , $\mathsf {S.S.Imp}$ ]. For the modified protocol $\mathsf {\Pi }$ using the unitary function $G_{\mathsf {}}$ described in Sect. 4, the following properties also hold:

• $\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.