Content for TS 33.401 Word version: 17.3.0

1… 4 5… 6… 6.2… 7… 7.2.5… 7.2.8 7.2.9… 7.3… 8… 9… 10… 11… 15… A… B… C… C.1.6 C.2… C.2.7 C.2.8 C.3… C.4.7 D… E… E.2… E.3… F… G… H… I… K…

F.1 General Description F.2 IOPS security solution F.3 Security Considerations F.4 Mitigation of compromise of a local HSS F.5 Actions in case of compromise of a local HSS
...

F Isolated E-UTRAN Operation for Public Safety |R13| p. 149

F.1 General Description p. 149

Isolated E-UTRAN Operation for Public Safety (IOPS) provides the ability to maintain a level of communications for Public Safety users, via an IOPS-capable eNB (or set of connected IOPS-capable eNBs), following the loss of backhaul communications.

The Isolated E-UTRAN mode of operation is also applicable to the formation of a Nomadic EPS deployment, i.e. a deployment of one or more standalone IOPS-capable eNBs, creating a serving radio access network without backhaul communications and also providing local IP connectivity and services to Public Safety users in the absence of normal EPS infrastructure availability.

3GPP TS 22.346 lists the general requirements for LTE networks in Isolated E-UTRAN Operation for Public Safety (IOPS). A description of the architectural concept of IOPS is given in informative Annex K of TS 23.401.

This Annex provides security guidelines for the operation of Public Safety networks in the no backhaul (to Macro EPC) scenario using the Local EPC approach [2].

The Local EPC approach assumes that an IOPS network can comprise either:

A Local EPC and a single isolated IOPS-capable eNB (or a deployable IOPS-capable eNB), which may be co-located or have connectivity to the Local EPC; or
A Local EPC and two or more IOPS-capable eNBs (or deployable IOPS-capable eNBs), which have connectity to a single Local EPC.

A Local EPC includes at least MME, SGW/PGW and HSS functionality.

The Public Safety network operator dedicates a PLMN identity to IOPS mode of operation which is broadcast in System Information by the eNB when IOPS mode is in operation. Only authorized IOPS-enabled UEs can access a PLMN indicated as an IOPS PLMN.

F.2 IOPS security solution p. 149

The security features and procedures described in this specification can be used to provide a security solution for an IOPS network based upon the Local EPC approach.

In order to ensure that support for IOPS does not compromise the security of normal operation, when operating in IOPS mode the AKA procedure (clause 6.1 of this specification) is performed between a USIM application dedicated exclusively for IOPS operation on a UICC, present in IOPS-enabled UEs, and the Local HSS (contained in the Local EPC). The same applies in the event of a loss of backhaul communications and a transition of the IOPS-capable eNB to support Isolated E-UTRAN operation for a population of IOPS-enabled UEs.

The USIM application dedicated exclusively for IOPS operation uses a distinct set of security credentials separate from those used for 'normal' operation. These credentials are configured in the Local HSS and in the UICC prior to the commencement of IOPS operation.

The USIM application dedicated exclusively for IOPS operation, in an IOPS-enabled UE, has a distinct set of security credentials which contains at least:

A permanent key K (uniquely assigned for IOPS operation).
The PLMN identity assigned for IOPS network operation.
An IMSI (uniquely assigned for IOPS operation).
Access Class status of 11 or 15 (subject to regional/national regulatory requirements and operator policy).

These credentials are provisioned in all Local HSSs within the Local EPCs supporting IOPS operation where the Public Safety authority requires that the UE be provided service in the event of a loss of backhaul communication.

Storage of the IOPS network security credential set in the Local HSS is only performed for UEs authorised for operation in the IOPS network. Administrative provisioning is used to keep up to date security credentials for all authorised UEs at the Local HSSs within the Local EPCs. Updates are provided within a security context that already exists between the EPC and eNBs in the 'normal' network.

This solution provides integrity and confidentiality for IOPS networks and maintains commonality with the procedures defined in this specification. Furthermore, the approach is aligned with the implementation and deployment guidelines for IOPS as defined in TS 23.401.

F.3 Security Considerations p. 150

F.3.1 Malicious switching of USIM applications p. 150

The use of a distinct set of security credentials counteracts the possibility that malicious switching of USIM applications would permit unauthorised access to an IOPS network or to a normal PLMN. eNBs operating in IOPS mode and Local EPCs support Network Domain Control Plane protection (clause 11) and backhaul link user plane protection (clause 12) as appropriate.

F.3.2 Compromise of local HSSs p. 150

Subscriber credentials are provisioned in all Local HSSs within the Local EPCs supporting IOPS operation where the Public Safety authority requires that the UE be provided service in the event of a loss of backhaul communication. If one of these local HSSs was compromised by an attacker, either in the form that the attacker could obtain the subscriber credentials or that the attacker could control the interface to the local HSS, and if, for any given subscriber, the credentials in the local HSSs were the same, this would imply that, for all subscribers whose credentials were stored in the compromised local HSS, the USIMs out in the field would have to be swapped and the subscriber credentials would have to be re-provisioned in all local HSS.

The following clause F.4 describes a mechanism, termed 'subscriber key separation' that would mitigate the effects of a compromise of a local HSS, as described in the preceding paragraph

F.4 Mitigation of compromise of a local HSS p. 150

F.4.0 Introduction p. 150

The text in the present clause is informative as the described mechanism is completely transparent to MEs, eNBs, MMEs, and, for local HSSs, requires only configuration changes in the local Authentication Centres. The corresponding configuration capability is already available in AuCs today. The mechanism does require functional changes to UICCs, but not to the UICC-ME interface. As both UICC and local Authentication Centre are under the control of one operator, the configuration in the local Authentication Centre and the functional changes to UICCs can be implemented without any normative changes to existing 3GPP specifications. However, normative changes to UICC specifications are not precluded by the present text.

F.4.1 'Subscriber key separation' mechanism p. 150

Subscriber key handling:

For each subscriber, there is a subscriber master key MK for IOPS purposes. This master key MK is stored in the UICC, but not in any local HSS. Assume that there are N local HSSs, HSS_1, ..., HSS_N. As part of the provisioning process for local HSS_n (1<=n<=N), a key K_n is derived from MK using a suitable representation of n as input, so that all K_n are different and the knowledge of K_n does neither allow inferring knowledge about MK nor about any K_m with m different from n. An example of a suitable key derivation function is given further below in clause F.4.2. Each local HSS_n is then provisioned with the subscriber key K_n.

Identification of a local HSS:

A local HSS is identified by a number n between 1 and N. We assume here that N<256. If this assumption does not hold then a grouping into subclasses is used, as described in the next clause. The number n is represented by 8 bits, bit "0" to bit "7". The representation of n draws on the proprietary part of the Authentication Management Field (AMF), cf. Annex H of TS 33.102, in the following way:

Bits "0" to "7" of n: The IOPS operator chooses a subset of the proprietary bits "8" to "15" of the AMF to be used in order to address his N local HSSs, and then informs the UICC vendor of his choice of AMF bits. Bits that are not in this subset are set to zero in the representation of n. For a given local HSS, the IOPS operator selects a specific combination of the chosen AMF bits, which is the same for all subscribers, and maps them to the bit position k-8 in the representation of n when k is the position of the bit in the AMF. It needs to be ensured by agreement between local HSS vendor and UICC vendor (following operator requirements) that the AMF bits chosen for IOPS purposes are not used for any other purpose.

An example of the use of these AMF bits for IOPS purposes is as follows: Assume that there are 50 local HSSs (i.e. N=50) and the IOPS operator uses bit 10 of the AMF for a proprietary purpose. By way of example, bit "9" and bits "11" to "15" of the AMF are chosen for IOPS purposes, which would allow addressing 64 local HSSs.

Grouping into Subclasses:

Let us assume that the maximum number of local HSSs that can be uniquely addressed through the use of the selected AMF bits is L. (If all 8 bits are used, L=256). In case the number N of local HSSs is greater than or equal to L then the local HSSs can be grouped into M subclasses where M<L. In each subclass, the subscriber credential K_n would be the same for a given subscriber. In this way, the impact of a compromise of one local HSS would be limited to the local HSSs in one subclass, and only the local HSSs of this subclass would need to be reconfigured. I.e. this would greatly reduce the impact of a compromise from N local HSSs to N/M local HSSs. There would still be no need for exchanging the UICCs.

Authentication Procedure:

The run of an EPS AKA procedure in the presence of the subscriber key separation mechanism is identical to that without the presence of the mechanism, except for the operation of the USIM application on the UICC dedicated to IOPS. The modified operation is described as follows: whenever the UICC receives an AUTHENTICATE command from the ME that is destined towards the USIM dedicated to IOPS, the USIM dedicated to IOPS first checks the AMF bits chosen for IOPS purposes and determines whether the local HSS uses the subscriber key separation mechanism and, if so, what is the number n of the local HSS. The USIM dedicated to IOPS then proceeds to derive K_n from MK. The key K_n then takes the role of the permanent subscriber key K, and EPS AKA proceeds as described in the present specification and in TS 31.102, with K_n replacing K in all computations.

F.4.2 Key derivation mechanism for 'subscriber key separation' p. 151

The key derivation (including input parameter encoding) for deriving K_n from MK is performed using the key derivation function (KDF) specified in Annex A.17 of the present specification.

One of the input parameters f(n) to the KDF in Annex A.17 is obtained by applying a function f to n. The function f is realised as a table in the IOPS dedicated USIM. The parameter P0 in Annex A.17 corresponds to the value indexed by n in the table. The table in the USIM needs to be updated by OTA (Over-The-Air) means in case a local HSS is compromised, cf. clause F.5.

An example realisation of a function f could take the following form: f(n) = n || m, where m is an 8-bit representation of a number between 0 and 255 and n || m is the concatentation of the bit representations of n and m. Initially, all m values are set to zero. When there is a need to update the table, due to a compromise of the local HSS with number n, then the value m for this n will be increased by 1. So, over time, the m-values for different n may differ. This table allows a UE to calculate the key K_n as the UE moves from one local HSS to another. If a local HSS is compromised, its keys cannot be updated until OTA communications with the macro-HSS are resumed. In that case, the UEs can be notified to update the relevant m value in their tables; the UEs can then re-calculate the new key for any compromised HSS without the necessity for OTA updates of the whole table. The circumstances in which the whole table is re-initialized will be determined by the individual operator.

F.5 Actions in case of compromise of a local HSS p. 152

In case of a compromise of one local HSS, other local HSSs are not affected (because they have a different set of secrets and it is assumed that an attacker knowing K_n cannot use this information to retrieve the corresponding IOPS master subscriber key). Furthermore, there is no need for swapping all USIMs, only the compromised local HSS (or the local HSSs in the subclass sharing the same subscriber key, cf. NOTE above) needs to be newly provisioned with keys derived from the MK and a newly provisioned value in the table of the IOPS dedicated USIM.

Action can, of course, only be taken, after the compromise of a local HSS was detected. But even before detection of the compromise, the subscriber key separation mechanism ensures that the attacker can neither use the compromised key K_n to impersonate the subscriber towards another local IOPS network nor impersonate another local IOPS network towards the subscriber. Therefore, the mechanism is useful even before new provisioning has taken place. But the attacker can impersonate the local IOPS network towards the subscriber until revocation has taken place.

NOTE 2:

Re-synchronisation: When a UE moves from one local HSS to the next one, it could happen that the second local HSS generates authentication vectors with a sequence number that is too low as seen from the USIM with the added functions. This would then result in a re-synchronisation procedure that would be successful as the AUTS parameter in the re-synchronisation procedure causes the local HSS to update its sequence number and consequently generate an authentication vector that will be accepted by the USIM. This would then result in a successful Attach procedure, albeit at the expense of some added delay. If the delay is a concern and re-synchronisation procedures may be frequent due to frequent movements of UEs between local HSSs then this problem could be almost completely solved by using the IND value of the sequence number, cf. Annex C of TS 33.102, to distinguish among local HSSs, i.e. set up the local HSSs such that they use only particular IND.