Third-Generation Security Mechanisms .1 Authentication and Key Agreement

Third-Generation Security (UMTS)

4.2 Third-Generation Security Mechanisms .1 Authentication and Key Agreement

The 3G AKA protocol, UMTS AKA, was originally designed for use in the circuit-switched (CS) and packet-circuit-switched (PS) domains of 3G. Variations of it have since been used in a range of other settings. In this chapter we describe UMTS AKA and refer the reader to the cited literature for other uses of AKA. These include:

• The Internet Engineering Task Force (IETF) speciﬁed Hypertext Transfer Protocol (HTTP) Digest AKA in two versions [RFC3310, RFC4169]. HTTP Digest AKA uses the UMTS AKA functions to dynamically generate passwords for HTTP Digest [RFC2617].

• 3GPP speciﬁed IP Multimedia Subsystem (IMS) AKA, which uses HTTP Digest AKA, embedded in Session Initiation Protocol (SIP) messages, to set up IPsec associa-tions between an IMS UE and a SIP proxy, the Proxy Call Session Control Function (P-CSCF) [TS33.203] – see Chapter 12.

• 3GPP also uses HTTP Digest AKA in its Generic Bootstrapping Architecture (GBA) for authentication between the UE and a key distribution server, the Bootstrapping Server Function (BSF) [TS33.220].

• 3GPP enhanced UMTS AKA to EPS AKA for authentication across LTE – see Chapter 7. The main enhancement consists in providing a binding of the agreed keys to the name of the SN.

• IETF speciﬁed Extensible Authentication Protocol (EAP) method called EAP-AKA [RFC4187], which embeds the UMTS AKA functions in the EAP framework [RFC3748]; in this way it makes UMTS AKA functions usable over a range of link layer technologies, including Wireless Local Area Network (WLAN). EAP-AKA [RFC5448] extends EAP-AKA by providing a binding of the agreed keys to the name of the access network.

3GPP uses EAP-AKA to provide authentication for subscribers connected across WLAN, and similar access networks, to the Internet and 3GPP core networks – see Section 11.2.

3GPP uses EAP-AKA to provide authentication for subscribers connected across trusted non-3GPP access networks to the Evolved Packet Core of EPS – see Chapter 11.

As we give a detailed description of the EPS AKA protocol in Section 7.2, and the elements of UMTS AKA adopted in EPS AKA are clearly distinguished there from the elements, which are new to EPS AKA, we do not present UMTS AKA in this section in full detail. We rather give an overview and discuss the signiﬁcant enhancements that UMTS AKA provides over the GSM AKA protocol.

Third-Generation Security (UMTS) 41

The 3GPP Security Working Group WG SA3, which designed the UMTS AKA pro-tocol, based its design on a threat and risk analysis of the GSM AKA protocol described in Chapter 3. Some weaknesses of GSM AKA have already been discussed in Chapter 3. The threat and risk analysis showed that, while GSM security is still adequate today to prevent widespread technical fraud, a determined attacker with signiﬁcant resources could attack GSM security using so-called false base stations, which are not under the control of a licenced operator. False base stations were not considered a possibility for an attacker when GSM was designed. We quote from a chapter written by Professor Michael Walker [Hillebrand 2001], who was heavily involved in the design of GSM security:

One of the key assumptions when GSM security was designed was that the system would not be subject to ‘active’ attacks, where the attacker could interfere with the operation of the system or impersonate one or more entities in the system. This assumption was made because it was believed such attacks, which would require the attacker to effectively have their own base station, would be too expensive compared to other methods of attacking GSM as a whole (e.g. wiretapping the ﬁxed links or even just bugging the target).

This view was clearly no longer tenable at the time that 3G security was designed; so, protection measures against attacks using false base stations had to be included as part of the 3G security architecture.

3G security includes two such protection measures: integrity protection of signalling and prevention of replay of authentication messages. The combination of these two measures can effectively mitigate false base station attacks.

Integrity protection is described in Section 4.2.3. Replay of authentication messages is prevented in UMTS AKA by including a sequence number (SQN) controlled by the USIM in the challenge sent to the mobile station and protecting the challenge, together with the SQN, with a message authentication code. Adding this feature is the main enhancement of UMTS AKA over GSM AKA.

Overview of UMTS AKA

In order to make this book self-contained, we include a high-level description of UMTS AKA here, which is similar to a description given elsewhere [Kaaranen 2005]. The detailed speciﬁcation of the protocol can be found in clause 6.3 of [TS33.102].

There are three entities involved in the authentication mechanism of the UMTS system:

• the home network, sometimes called the home environment (HE),

• the SN and

• the terminal, more speciﬁcally the USIM (in a smart card, the UICC).

The basic idea is that the SN checks the subscriber’s identity (as in GSM) by a challenge–response technique, while the terminal checks that the SN has been autho-rized by the home network to do so. The latter part is a new feature in UMTS (compared to GSM), and it enables the terminal to check that it is connected to a legitimate network.

The mutual authentication protocol itself does not prevent the scenario where an attacker puts up a false base station, but it guarantees (in combination with the other security mechanisms) that the active attacker cannot get any real beneﬁt out of the situation. The only possible gain for the attacker is to be able to disturb the connection, but clearly no protocol methods exist that can circumvent this type of attack completely. For instance, an attacker can implement a malicious action of this kind by radio jamming.

The cornerstone of the authentication mechanism is a permanent key K that is shared between the USIM of the user and the home network database. This is a permanent secret with a length of 128 bits. The key K is never transferred out from the two locations. For instance, users have no knowledge of their permanent key.

Together with mutual authentication, keys for encryption and integrity are derived.

These are temporary keys with the same length of 128 bits as the permanent key K.

New keys are derived from K during every authentication event. It is a basic principle in cryptography to limit the use of a permanent key to a minimum and instead derive temporary keys from it for protection of bulk data.

We describe now the AKA mechanism at a general level. The authentication procedure can be started after the user has been identiﬁed in the SN. The identiﬁcation occurs when the identity of the user (i.e. permanent identity International Mobile Subscriber Identity (IMSI) or Temporary Mobile Subscriber Identity (TMSI)) has been transmitted to the Visitor Location Register (VLR) or the Serving GPRS Support Node (SGSN).

Then the VLR or the SGSN sends an authentication data request to the Authentication Centre (AuC) in the home network.

The AuC contains the permanent keys of the users and, based on the knowledge of the IMSI, the AuC is able to generate authentication vectors for the user. The generation process consists of executions of several cryptographic algorithms, which are described in more detail in this chapter. The generated vectors are sent back to the VLR/SGSN in the authentication data response. These control messages are carried by the Mobile Application Part (MAP) protocol.

In the SN, one authentication vector is needed for each authentication instance, that is, for each run of the authentication procedure. This means that the (potentially long-distance) signalling between the SN and the AuC is not needed for every authentication event, and it can in principle be done independently of the user actions after the initial registration. Indeed, the VLR/SGSN may fetch new authentication vectors from the AuC well before the number of stored vectors runs out.

The SN (the VLR or the SGSN) sends a user authentication request to the terminal. This message contains two parameters from the authentication vector, called the random 128-bit string (RAND) and authentication token (AUTN). These parameters are transferred to the USIM that exists inside a tamper-resistant environment, the UICC. The USIM contains the permanent key K, and using it with the parameters RAND and AUTN as inputs, the USIM carries out a computation that resembles the generation of authentication vectors in the AuC. This process also consists of executions of several algorithms, as is the case in the corresponding AuC computation.

As a result of the computation, the USIM is able to verify whether the parameter AUTN was indeed generated in the AuC, and, in the positive case, the computed parameter RES is sent back to the VLR/SGSN in the user authentication response. Now the VLR/SGSN is

Third-Generation Security (UMTS) 43

able to compare the user response RES with the expected response (XRES) which is part of the authentication vector. When they match, the authentication has been successful.

The keys for radio access network encryption and integrity protection, Ciphering Key (CK) and Integrity Key (IK), are created as a by-product in the authentication process.

These temporary keys are included in the authentication vector and, thus, are transferred from the AuC to the VLR/SGSN. These keys are later transferred further to the RNC in the radio access network when the encryption and integrity protection are started. On the other side, the USIM is able to compute CK and IK as well after it has obtained RAND (and veriﬁed it through AUTN). These temporary keys are subsequently trans-ferred from the USIM to the ME where the encryption and integrity protection algorithms are implemented.

Discussion of UMTS AKA

We discuss here brieﬂy some of the properties and prerequisites of UMTS AKA. This discussion is similar to one presented elsewhere [Horn and Howard 2000]. UMTS AKA relies on the following prerequisites.

• Trust prerequisites. Users have to trust their home network in all respects concerning this protocol. The SN trusts the home network to send correct authentication vec-tors, and not disclose them to unauthorized entities. As the home network delegates authentication checking to the SN, the former must place corresponding trust in the SN.

• Prerequisites on interface security. It is assumed that the core network interfaces carrying authentication data between the SN and the home network, and between two adjacent SNs, are adequately secure. UMTS AKA can, however, be run securely with-out additional assumptions on the security of the interface between the UE and the SN entities.

• Prerequisites on cryptographic functions. UMTS AKA makes use of symmetric key-based cryptographic functions f1 to f5, f1* and f5*. All seven functions¹ are implemented in the USIM and the AuC, respectively. Furthermore, there needs to be a random number generator in the AuC. None of these cryptographic functions need to be standardized; they are all up to agreements between operators and their AuC and UICC vendors. One such realization of these functions is the set of algorithms provided by the speciﬁcation of MILENAGE [TS35.205].

UMTS AKA achieves the following protocol goals.

• Entity authentication. As for GSM AKA, the SN obtains assurance that the user with the claimed identity was involved in the current protocol run. On the other hand, the user obtains the somewhat lesser assurance that the authentication challenge RAND, AUTN, and consequently the keys CK and IK derived from RAND were generated by the user’s HE and not used in a previous successful UMTS AKA run. SN authen-tication is not achieved by UMTS AKA. The user only obtains assurance ‘that he is connected to a serving network that is authorized by the user’s HE to provide him

1The same seven functions are used in an identical way with EPS AKA. Their use with EPS AKA is described in detail in Chapter 7.

services; this includes the guarantee that this authorisation is recent’ (cf. [TS33.102]).² SN authentication was not deemed necessary when 3G security was designed as there was an assumption of mutual trust among all UMTS operators. This assumption was, however, considered no longer valid for the entire lifetime of EPS; see the discussion on design decisions for EPS in Section 6.3. Consequently, for EPS, UMTS AKA was enhanced to also provide SN authentication – see Section 7.2. A proposal to introduce SN authentication already for 3G can be found in the publication [Zhang and Fang 2005].

• Session key agreement. As a result of UMTS AKA, the CK and the IK are agreed between UE and VLR or SGSN. These keys are mutually implicitly authenticated in the sense that the keys can only be held by the legitimate entities, under the assumption that the entities and interfaces in the core network are secure and the authentication algorithms are secure.

• Session key freshness. This property is obtained by the fact that the session keys are derived using RAND, and RAND is guaranteed to be fresh by the use of the sequence number in the message authentication code protecting RAND. Both the UE and the VLR or SGSN have to trust the HE for generating a new RAND for every protocol run.

Due to key freshness, a compromise of the session keys agreed in a previous UMTS AKA run does not affect the session keys from the new UMTS AKA run.

• User identity conﬁdentiality. The conﬁdentiality of the user identity-related informa-tion on the interface between the user and the server is provided in the same way as in GSM, by using a temporary identity TMSI. This implies that an eavesdropper on the interface between the user and the SN cannot gain information on the user identity from reading UMTS AKA messages. However, active attacks using so-called IMSI catchers are still possible. Prevention of active attacks was discussed at length in 3GPP, and it was concluded that symmetric key techniques bore the risk of shutting out legitimate users during a crash on the network side, and the cost of introducing a public key mechanism for this purpose would be too high.

• Mitigation of pre-play attacks. A number of RAND, AUTN pairs may be obtained from the network by an attacker at one point in time and used towards the user at some time later. However, such an attacker cannot know the agreed keys. The mandatory use of the IK rules out threats arising from this attack.

• Mitigation of compromise of authentication vectors. If authentication vectors stored in, or sent to, the VLR or SGSN became known to attackers, they could impersonate the user towards the compromised network, or they could impersonate any 3G net-work towards the user, using the IK in local authentications. Furthermore, attackers could eavesdrop on sessions. But as soon as a new run of UMTS AKA has been performed successfully, attackers can no longer beneﬁt from the compromised authen-tication vectors.

• Re-synchronization procedure. UMTS AKA provides a mechanism to re-synchronize the SQNs used between USIM and AuC. While, in most cases, a rejection of an authentication request by a USIM due to a SQN being out of range will be due to the VLR or SGSN using an outdated authentication vector it still has in storage, the re-synchronization procedure of UMTS AKA even allows securely resetting any SQNs held in the AuC to bring it into line with the SQN held in the USIM.

2Some text reproduced with permission from2010, 3GPP

Third-Generation Security (UMTS) 45

• Sequence number management. The generation and veriﬁcation of SQNs in the AuC and the USIM, respectively, need not be standardized in detail. However, the SQN man-agement scheme needs to be carefully considered. Therefore, [TS33.102] provides an informative annex for guidance. The schemes described in this annex are resilient against denial of service through accidental or malicious modiﬁcation of authenti-cation vectors in the network and against out-of-order use of authentiauthenti-cation vectors by network entities. The selection of the scheme is important to ensure minimizing of re-synchronization events when AKA is used for multiple purposes, such as IMS or GBA.

• Precomputation of authentication vectors in the AuC. This is possible as a UMTS AKA run is not bound to any properties of the requesting entity (VLR or SGSN).

4.2.2 Ciphering Mechanism

Once the user and the network have authenticated each other, they may begin secure communication. As described in this chapter, a CK is shared between the core network and the terminal after a successful authentication event. Before encryption can begin, the communicating parties have to agree on the encryption algorithm also. The encryption algorithms are discussed in Section 4.3.

The encryption and decryption take place in the terminal and in the RNC on the network side. This means that the CK has to be transferred from the core network to the radio access network. This is done in a speciﬁc Radio Access Network Application Protocol (RANAP) message called Security Mode Command. After the RNC has obtained CK, it can switch on the encryption by sending a Radio Resource Control (RRC) Security Mode Command message to the terminal.

The 3G encryption mechanism is based on a stream cipher as described in Figure 4.1.

See Section 2.3 for details of the concept of a stream cipher.

The encryption occurs in either the Medium Access Control layer (MAC) or in the Radio Link Control layer (RLC). In both cases, there is a counter that changes for each

COUNT-C/32 DIRECTION/1

KEYSTREAM BLOCK (MASK) BEARER/5

CK/128 f8

+ Ciphered MAC SDU or RLC PDU (data part) Plaintext MAC SDU or

RLC PDU (data part)

LENGTH

Figure 4.1 3G encryption. (Reproduced from Niemi and Nyberg,UMTS Security, John Wiley &

Sons, Ltd.2003.)

Protocol Data Unit (PDU). In MAC this is a Connection Frame Number (CFN), and in RLC a speciﬁc RLC sequence number (RLC-SN). If these counters were used as such as input for the mask generation, replay of messages could still occur since these counters wrap around very quickly. This is why a longer counter called a Hyperframe Number (HFN) is introduced. It is incremented whenever the short counter (CFN in the MAC case and RLC-SN in the RLC case) wraps around. The combination of HFN and the shorter counter is called COUNT-C and is used as an ever-changing input to the mask generation inside the encryption mechanism.

In principle, the longer counter HFN could also eventually wrap around. Fortunately, it is reset to zero whenever a new key is generated during the AKA procedure. The authentication events are in practice frequent enough to rule out the possibility of HFN wrap-around.

The radio bearer identity BEARER is also needed as an input to the encryption algo-rithm since the counters for different radio bearers are maintained independently of each other. If the input BEARER was not in use, then this could again lead to a situation where the same set of input parameters would be fed into the algorithm, and the same mask would be produced more than once. Consequently, replay of messages could occur, and the messages (this time in different radio bearers) encrypted with the same mask would be exposed to the attacker.

The parameter DIRECTION indicates whether uplink or downlink trafﬁc is encrypted.

The parameter LENGTH indicates the length of the data to be encrypted. Note that the value of LENGTH affects only the number of bits in the mask bit stream; it does not

Dans le document LTE SECURITY (Page 56-65)