4 Confidentiality of signalling information elements, connectionless data and user information elements on physical connections

3GPP43.020Release 17Security related network functionsTS

4.1 Generality

In 3GPP TS 42.009, some signalling information elements are considered sensitive and must be protected.

To ensure identity confidentiality (see clause 2), the Temporary Subscriber Identity must be transferred in a protected mode at allocation time and at other times when the signalling procedures permit it.

The confidentiality of connection less user data requires at least the protection of the message part pertaining to OSI layers 4 and above.

The user information confidentiality of user information on physical connections concerns the information transmitted on a traffic channel on the MS-BSS interface (e.g. for speech). It is not an end-to-end confidentiality service.

These needs for a protected mode of transmission are fulfilled with the same mechanism where the confidentiality function is a OSI layer 1 function. The scheme described below assumes that the main part of the signalling information elements is transmitted on DCCH (Dedicated Control Channel), and that the CCCH (Common Control Channel) is only used for the allocation of a DCCH.

Four points have to be specified:

– the ciphering method;

– the key setting;

– the starting of the enciphering and deciphering processes;

– the synchronization.

4.2 The ciphering method

The layer 1 data flow (transmitted on DCCH or TCH) is ciphered by a bit per bit or stream cipher, i.e. the data flow on the radio path is obtained by the bit per bit binary addition of the user data flow and a ciphering bit stream, generated by algorithm A5 using a key determined as specified in subclause 4.3. The key is denoted below by Kc if it is the 64-bit key and Kc₁₂₈ if it is the 128-bit key derived as specified in TS 33.102 [18], and is called "Ciphering Key".

For multislot configurations (e.g. HSCSD) different ciphering bit streams are used on the different timeslots. On timeslot "n" a ciphering bit stream, generated by algorithm A5, using a key Kcn is used. Kcn is derived from the 64-bit Kc as follows:

Let BN denote a binary encoding onto 64 bits of the timeslot number "n" (range 0‑7). Bit "i" of Kcn, Kcn(i), is then calculated as Kc(i) xor (BN<<32(i)) ("xor" indicates: "bit per bit binary addition" and "<<32" indicates: "32 bit circular shift"), the number convention being such that the lsb of Kc is xored with the lsb of the shifted BN.

Deciphering is performed by exactly the same method.

For the 128-bit Kc₁₂₈ derived according to TS 33.102 [18], the corresponding keys Kc₁₂₈n is used, and Kc₁₂₈n is derived from the 128-bit Kc₁₂₈ as follows:

Let BN denote a binary encoding onto 128 bits of the timeslot number "n" (range 0‑7). Bit "i" of Kc₁₂₈n, Kc₁₂₈n(i), is then calculated as Kc₁₂₈(i) xor (BN<<32(i)) ("xor" indicates: "bit per bit binary addition" and "<<32" indicates: "32 bit circular shift"), the number convention being such that the lsb of Kc₁₂₈ is xored with the lsb of the shifted BN.

Algorithm A5 is specified in annex C.

4.3 Key setting

Mutual key setting is the procedure that allows the mobile station and the network to agree on the key Kc to use in the ciphering and deciphering algorithms A5.

A key setting is triggered by the authentication procedure. Key setting may be initiated by the network as often as the network operator wishes.

Key setting must occur on a DCCH not yet encrypted and as soon as the identity of the mobile subscriber (i.e. TMSI or IMSI) is known by the network.

The transmission of Kc to the MS is indirect and uses the authentication RAND value; Kc is derived from RAND by using algorithm A8 and the Subscriber Authentication key Ki, as defined in annex C.

As a consequence, the procedures for the management of Kc are the authentication procedures described in subclause 3.3.

The values Kc are computed together with the SRES values. The security related information (see subclause 3.3.1) consists of RAND, SRES and Kc.

The key Kc is stored by the mobile station until it is updated at the next authentication.

Key setting is schematized in figure 4.1.

Figure 4.1: Key setting

4.4 Ciphering key sequence number

The ciphering key sequence number is a number which is associated with the ciphering key Kc and they are stored together in the mobile station and in the network.

However since it is not directly involved in any security mechanism, it is not addressed in this specification but in 3GPP TS 24.008 instead.

4.5 Starting of the ciphering and deciphering processes

The MS and the BSS must co-ordinate the instants at which the enciphering and deciphering processes start on DCCH and TCH.

On DCCH, this procedure takes place under the control of the network some time after the completion of the authentication procedure (if any), or after the key Kc has been made available at the BSS.

No information elements for which protection is needed must be sent before the ciphering and deciphering processes are operating.

The transition from clear text mode to ciphered mode proceeds as follows: deciphering starts in the BSS, which sends in clear text to the MS a specific message, here called "Start cipher". Both the enciphering and deciphering start on the MS side after the message "Start cipher" has been correctly received by the MS. Finally, enciphering on the BSS side starts as soon as a frame or a message from the MS has been correctly deciphered at the BSS.

The starting of enciphering and deciphering processes is schematized in figure 4.2.

Figure 4.2: Starting of the enciphering and deciphering processes

When a TCH is allocated for user data transmission, the key used is the one set during the preceding DCCH session (Call Set-up). The enciphering and deciphering processes start immediately.

4.6 Synchronization

The enciphering stream at one end and the deciphering stream at the other end must be synchronized, for the enciphering bit stream and the deciphering bit streams to coincide. The underlying Synchronization scheme is described in annex C.

4.7 Handover

When a handover occurs, the necessary information (e.g. key Kc, initialization data) is transmitted within the system infrastructure to enable the communication to proceed from the old BSS to the new one, and the Synchronization procedure is resumed. The key Kc remains unchanged at handover.

Handover involving both a 64-bit Kc and a 128-bit Kc₁₂₈ is slightly more complex.

– In case of a handover between two BTSes connected to the same BSC, the BSC signals both the selected algorithm and the ciphering key to the target BTS. If the BSC signals the use of a ciphering algorithm requiring a 128-bit ciphering key to the target BTS, the BSC sends Kc₁₂₈ to the target BTS. If only a 64-bit Kc is in the BSS, no ciphering algorithm (e.g., A5/4) requiring a 128-bit ciphering key shall be signalled from BSC to the target BTS.

– In case of a handover between two BSSes connected to the same MSC/VLR, the MSC/VLR signals the allowed ciphering algorithms to the target BSC. If one of the allowed ciphering algorithms requires a 64-bit ciphering key, the MSC/VLR shall send the 64-bit Kc to the target BSS. Additionally, if one of the allowed ciphering algorithms requires a 128-bit ciphering key, the MSC/VLR shall also send the 128-bit Kc₁₂₈ to the target BSS. If an MSC/VLR supporting Kc₁₂₈ could only obtain a 64-bit Kc for the MS, the MSC/VLR shall not include any ciphering algorithm (e.g., A5/4) requiring a 128-bit ciphering key in the allowed ciphering algorithms list. If the target BSC signals the use of a ciphering algorithm requiring a 128-bit ciphering key to the target BTS, the BSC sends Kc₁₂₈ to the target BTS.

– In case of a handover between two BSSes connected to different MSC/VLRs, the initial MSC/VLR shall send the allowed ciphering algorithms to the target MSC/VLR. If one of the allowed ciphering algorithms requires a 64-bit ciphering key, the initial MSC/VLR shall also send a 64-bit ciphering key to target MSC/VLR. . If one of the allowed ciphering algorithms requires a 128-bit ciphering key, the initial MSC/VLR shall also calculate the 128-bit ciphering key Kc₁₂₈ from the CK/IK as described in Annex B.5 of TS 33.102 [18], and shall sendit to the target MSC. If the initial MSC/VLR can only obtain a 64-bit ciphering key for the MS, the anchor MSC/VLR shall not include any ciphering algorithm requiring a 128-bit ciphering key in the allowed algorithms list. The target MSC shall send the 64-bit Kc and/or the 128-bit Kc₁₂₈, as received from the initial MSC/VLR, to the target BSS. If the target BSC signals the use of a ciphering algorithm requiring a 128-bit ciphering key to the BTS, the BSC sends Kc₁₂₈ to the target BTS.

4.8 Negotiation of A5 algorithm

Not more then seven versions of the A5 algorithm will be defined.

When an MS wishes to establish a connection with the network, the MS shall indicate to the network which of the seven versions of the A5 algorithm it supports. The network shall not provide service to an MS which indicates that it does not support the ciphering algorithm A5/1.

The network shall compare its ciphering capabilities and preferences, and any special requirements of the subscription of the MS, with those indicated by the MS and act according to the following rules:

1) If the MS and the network have no versions of the A5 algorithm in common and the network is not prepared to use an unciphered connection, then the connection shall be released.

2) If the MS and the network have at least one version of the A5 algorithm in common, then the network shall select one of the mutually acceptable versions of the A5 algorithm for use on that connection.

3) If the MS and the network have no versions of the A5 algorithm in common and the network is willing to use an unciphered connection, then an unciphered connection shall be used.

Since the use of 128-bit ciphering algorihms (e.g., A5/4) requires that the MS is in UMTS security context, if the MSC/VLR could only obtain a 64-bit Kc for the MS, the MSC/VLR shall not include A5/4 in the permitted GSM ciphering algorithms list when the algorthims are signalled to the BSS.

4.9 Support of A5 Algorithms in MS

It is mandatory for A5/1, A5/3, A5/4 and non encrypted mode to be implemented in mobile stations. It is prohibited to implement A5/2 in mobile stations. Only A5 algorithms that are included in 3GPP specifications shall be implemented in mobile stations.

The use of non encrypted mode, A5/1, A5/3 or A5/4 in the MS shall be disabled on a particular visited network if instructed to do so by the SIM/USIM application. The mechanism is based on an EF ‘Disabled Algorithms’ in the SIM/USIM application containing the unauthorized algorithms per visited network. If the EF ‘Disabled Algorithms’ is present and active, then the algorithms marked as disabled shall not be used by the MS in the corresponding visited network. The disabled algorithms may be defined on a global, per country or per network basis. The relevant file in the SIM/USIM application is managed by the home operator based on information supplied to the home operator by the visited network.

NOTE 1: It is still possible for an attacker to spoof the VPLMN id. In that case, it is possible for the attacker to downgrade the encryption level. This could be mitigated by an interaction between the UE and the end user in order to confirm the visited country.

NOTE 2: A mechanism to enforce mutual authentication in GSM is described in clause 6.8.1.4 in TS 33.102 [24].

Editor’s note: The following issues are FFS: Changing the supported algorithms during a handover between PLMNs. As this may lead to the network to believe the UE supports the original algorithms (received from the source network nodes for example) while the UE believes it supports the new set (modified based on changing PLMN). It should also be studied if it is necessary from a security perspective to change the supported algorithms after a handover, e.g. the UE is already connected so it is already on a false base station or a genuine network that would not handover to a false network. More details on the actual information that is held in the USIM and how the ME interpret that information is needed. In particular care should be taken to deal with corner cases such as the information in the USIM trying to disable all the algorithms that an ME supports (e.g. network supports A5/4 everywhere, but the UE only supports (up to) A5/3).

Editor’s note: It is FFS whether disabling algorithms on a per network basis successfully achieves the intention of mitigating downgrade attacks by false basestations.

4.10 Support of A5 Algorithms in the BSS

It is mandatory for A5/3 and A5/4 to be implemented in the BSS.