WO2014067541A1

WO2014067541A1 - Methods, apparatuses and computer program products enabling to improve handover security in mobile communication networks

Info

Publication number: WO2014067541A1
Application number: PCT/EP2012/071349
Authority: WO
Inventors: Guenther Horn; Hinrich Eilts
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2012-10-29
Filing date: 2012-10-29
Publication date: 2014-05-08
Anticipated expiration: 2015-04-29

Abstract

The present invention proposes computer program products, methods and apparatuses enabling to improve security in handovers in mobile communication networks, and for example, apparatuses, comprising a memory unit; and a control unit connected to the memory unit, the apparatus being configured to interface at least one access node wherein the control unit is configured to process one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forward said derived local security key to at least one access node. Based upon the occurrence of a renewal suppression condition, the apparatuses are configured to modify the policy for renewing {NH, NCC} pairs in the MME in that the parameters {NH, NCC} are conditionally suppressed to be renewed in relation to a failed S1 handover, or instead of new (renewed) ones, previously generated ones which originate from an earlier failed S1 handover are re-used.

Description

DESCRIPTION Title

Methods, apparatuses and computer program products enabling to improve handover security in mobile communication networks

Field of the invention

The present invention relates to methods, apparatuses and computer program products enabling to improve handover security in mobile communication networks. In particular, the proposed methods, computer program products and apparatuses are for example applicable to scenarios within such networks, e.g. within an evolved packet system EPS network, in order to improve security of handovers HO taking place on a particular interface within such system.

Background

Mobile data transmission and data services are constantly making progress. With the increasing usage of mobile communication, network organization and optimization is becoming more and more important. Also, in such context, security of handovers is being investigated, e.g. in the framework of LTE™ or LTE™-A and e.g. the EPS system and interfaces thereof, such as the so-called S1 interface between a network mobility entity e.g. also known as a mobility management entity, MME, and an access node providing (wireless) network access to a terminal such as a user equipment UE, the access node being e.g. also known as evolved NodeB, eNB.

Insofar, the present invention relates in particular but without limitation to mobile communications, for example to environments under LTE™ (Long Term Evolution) or LTE™-A (LTE™ Advanced), or any other communication scenario, potentially standardized by 3GPP (3^rd Generation Partnership Project), ETSI (European Telecommunication Standards Institute) and/or other local or regional standardization bodies e.g. NGMN (Next Generation Mobile Networks), and can advantageously be implemented as or in chipsets, or modules, or units, or apparatuses of devices (e.g. network entities such as a transceiver device also known as base station, or NodeB, or evolved NodeB eNB, or e.g. a mobility management entity MME) forming part of those networks, as well as related terminal devices such as a so-called user equipment UE (e.g. smart-phones, a network-access enabled computers or laptops, or the like).

More particularly, as a specific example referred to in order to describe aspects of the present invention, the present invention relates to those apparatuses / units of devices or network entities that are applied in such communication networks or a part thereof, e.g. known as evolved packet system, EPS, network. Thus, security of handovers HO in such EPS network and security of handovers taking place with involvement of particular interfaces in such system, such as the so-called S1 interface between a MME and a eNB, are being considered.

With the evolution of LTE™ and/or EPS system, such cellular networks will become more and more complex, various and huge. For network operators, along with the uses of new technologies, to maintain security and/or data integrity is a big challenge.

The present invention relates to the security of handovers in LTE, and more specifically to failures of so-called S1 handovers, i.e. handovers, in which not only the eNBs, but also the MME are involved. Security of handovers is for example specified in 3GPP TS 33.401 , more specifically in clause 7.2.8. thereof.

Fig. 1 illustrates some typical scenario for explanatory purposes. A network mobility entity referred to as mobility management entity MME is denoted by numeral 1 . The MME has an interface /connection to other entities of the EPS (not shown in Fig.1 ). Further, the MME has an interface known as S1 interface (S1 -I/F) towards each of a plurality of access nodes referred to as evolved NodeBs, eNBs. Such access node eNB provides network access based on e.g. a wireless access technology for one or more terminals referred to as user equipments U E and denoted by numeral 4 and 4', respectively. A source eNB denoted by numeral 2 is labeled as eNB #A. A target eNB denoted by numeral 3 is labeled as eNB #B. The expression source and target pertains to an assumed mobility of a terminal UE (4, 4'). Namely, with a moving UE, a UE is at a time t1 served by eNB #A, but after a handover HO served by a eNB #B. An interface between eNBs is referred to a X2 interface, X2 l/F. An interface between an eNB, 2 and 3, respectively, and a terminal UE, 4 or 4', is referred to as Uu interface. In case of a handover between eNBs having an interface X2 there between, the HO typically takes place via the X2 interface. In case of a HO between eNBs without an X2 interface there between, the HO involves the S1 interface. In case of a HO via S1 interface, the MME derives, inter alia, parameters and/or keys such as {NH, NCC} and informs at least the NCC thereof to the target eNB which forwards it to the UE handed over in a handover command that is sent from the target eNB to the UE via the source eNB. Thus, NCC is forwarded to UE in a handover command that is sent from the target eNB to the UE via the source eNB, i.e. target eNB does not directly send NCC to UE over Uu.

In order to establish security in such EPS system architecture, various keys are established and/or derived in a hierarchical manner. E.g. a key K as a master or base key is stored permanently in an authentication centre AuC and universal subscriber identity module USIM. Using that key and various procedures such as one known as AKA (Authentication and Key Agreement) plural other keys in the hierarchical EPS system are generated and/or derived. Keys used at a specific entity or at a level of similar entities are also referred to herein as local level keys, whereas keys used to derive those may be referred to as higher level keys (determined/kept at hierarchically higher entities or nodes).

A key KeNB, for example, is a eNB base key and set up / derived as intermediate key in a MME and UE based on other keys, e.g. upon a state transition of a terminal and/or by the UE and a target eNB upon handover of the terminal.

Particular focus in relation to the present invention will have to be put on keys referred to as "next hop", NH, and "next hop chaining counter", NCC, as will be explained below. The use of Next Hop Chaining Counter (NCC) and Next Hop parameter (NH) is specified in TS 33.401 , clause 7.2.8. Both the UE and the MME can derive NH from the current Kasme, which was formerly generated and kept by MME and UE, in an iterative fashion according to TS 33.401 , Annex A.4, when they know the Kasme and the number of iterations, cf. TS 33.401 , clause 7.2.2. The NCC consists of the three least significant bits of the number of iterations performed in computing NH. Only NCC is transmitted to the UE in a handover for efficiency reasons. The UE can correctly derive a new NH from the currently stored {NH, NCC} pair and a newly received NCC only if that newly received NCC relates to an NH that was computed in the MME by at most seven iterations from the NH equal to the one stored in the UE. (This is a simple consequence of the fact that NCC has only three bits.)

In an S1 handover, the MME computes a new NH parameter, thereby increasing NCC by 1 - with the exception marked with (^**) below - and sends the {NH, NCC} pair to the target eNB. After a successful S1 handover, both UE and MME will have the same {NH, NCC} pair stored. When the S1 handover fails the MME will have increased NCC by 1 while the NCC in the UE will remain the same.

(^**) Exception: The first NH sent to an eNB after the KeNB was established corresponds to NCC=2, according to the rules in TS 33.401 , clause 7.2.8.

In an X2 handover (including the Path Switch procedure), the MME computes a new NH parameter, thereby increasing NCC by 1 - but see exception (^**) above - , and sends the {NH, NCC} pair to the target eNB, in the Path Switch Acknowledge message, i.e. only after the handover had been successfully completed between UE, source eNB and target eNB.

So, an unsuccessful X2 handover has no effect on the NCC value in UE and MME. The new {NH, NCC} pair created in a successful X2 handover will be used only in the next vertical X2 handover, hence the UE will not learn about this new NCC value until then. While the effect of a successful X2 handover (including the Path Switch procedure) on the NCC value in the MME is straightforward the effect on the NCC value in the UE is a bit tricky to determine and depends on the history of handovers as follows: If the current X2 handover is the first successful (S1 or X2) handover after the KeNB was established then NCC does not change in the UE; the difference between the NCC values in UE and MME after the current X2 handover increases by 1 (if there was a preceding failed S1 HO) or 2 otherwise, cf. (^**) above ).

If the preceding successful handover was an S1 handover then NCC does not change in the UE; the difference between the NCC values in UE and MME after the current X2 handover increases by 1 ;

If the preceding successful handover was an X2 handover then NCC in the UE is set to the value of the NCC sent by the MME in that preceding handover; the amount by which the NCC value increases in the UE depends on the history even before that preceding handover; but the difference between the NCC values in UE and MME after the current X2 handover is more amenable to computation: it is equal to the number of failed S1 handovers between the current and the preceding X2 handovers plus 1.

It was observed in laboratory tests by applicant that S1 handover failures may lead to loss of synchronization of so-called NextHop (NH) parameter between UE and MME and consequently to a connection failure. Namely, applicant observed in laboratory tests that S1 handover requests could be rejected several times, while the UE remained connected to the same source eNB. Those tests involved a low mobility case, in a scenario where a laptop was being moved from one corner of a building to another one. This move caused an S1 handover attempt, which failed due to the target eNB being congested. By this, the NCC value was increased by 1 in the MME while it remained the same in the UE, because the new NCC value could not propagate from the MME via the new target eNB towards the UE due to the handover failure, or, stated in other words, because the new NCC will only be propagated to UE if the handover actually happens.

The radio conditions permitted the UE to remain connected to the source eNB. As the laptop did not move any further the radio conditions did not change any further, and, after some time, another S1 handover attempt was made, failing again (and increasing the NCC value in the MME again), while the UE still remained connected to the source eNB. When finally a successful (S1 or X2) handover was made this then led to a condition (according to the 'background' information above) where a UE and an MME would compute different NH parameters and, hence, the UE and the eNB would compute different AS level cryptographic keys, leading to a connection failure.

The observed scenario is plausible enough, and the negative impact sufficiently important, to warrant implementing countermeasures.

Generally, prior art can be found in 3GPP TS 33.401 and the related stage 3 specifications 3GPP TS 24.301 and 3GPP TS 36.331. An NCC length of three bits has so far been considered sufficient to prevent any loss of synchronisation due to handover failures.

To the inventors' knowledge, the failure case observed in applicant's laboratory tests described above has not been publicly discussed yet. Hence, as the problem had not been revealed, no countermeasures have been proposed so far.

Generally, as a countermeasure it is conceivable to use a KeNB re-keying as specified in 3GPP TS 33.401 , clause 7.2.9.2. This could be used to re-synchronize the NH parameter in MME and UE. The big disadvantage of this re-keying procedure is that it requires a run of the EPS AKA authentication protocol. This, however, is undesirable as operators are currently looking for ways to reduce the load on the home subscriber server, HSS, caused by authentications, which is considered too high already.

Thus, there is still a need to further improve such systems.

Summary

Various aspects of examples of the invention are set out in the claims. According to an aspect of the present invention, there is provided an apparatus as set out in claims 1 and 2, respectively, and a method as set out in claims 6 and 7, respectively.

Advantageous further developments are as set out in respective dependent claims in relation to each of the above aspects.

According to a further aspect of the present invention, there are provided computer program products, as set out in claim 1 1 , comprising computer-executable components which, when the program is run on a computer, are configured to implement and/or carry out the above method aspects. Those computer program product/products may be embodied as a computer-readable storage medium.

Thus, improvement is based on methods, apparatuses and computer program products according to at least one or more embodiments covered by the above aspects.

For example:

- the concepts as presented in line with aspects of the invention are in particular applicable for a MME, for example; - more particularly, the concepts as presented in line with aspects of the invention will also be applicable to e.g. a follow-up version of 3GPP TS 33.401 , "Security of handovers" as e.g. specified in particular in its clause 7.2.8., and lead to an updated version thereof;

- aspects of the invention encompass countermeasures which prevent that {NH, NCC} pairs in UE and MME get out of synchronization due to a number of S1 handover failures; - aspects of the invention enable prevention of unnecessary NCC increments, e.g. by restoring an "old" NCC, or e.g. by bypassing computation of new ones.

Brief description of drawings For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

Figure 1 illustrates an overview of some entities of an EPS network and interfaces there between

Figure 2 (2A and 2B) illustrates a schematic flow chart according to aspects of embodiments of the invention;

Figure 3 illustrates an example of a basic block circuit diagram of a network mobility entity, e.g. a MME.

Description of exemplary embodiments

Examples of aspects of the invention will be described herein below.

In various standards, different names may apply for those entities. Therefore, as a mere example only that was chosen to describe a possible implementation framework of the present invention, reference is made to LTE™ EPS and related documents, especially 3GPP TS 33.401 . Abbreviations and definitions as set out in such documents/context shall also apply for the purpose of describing at least concepts / embodiments of this invention, though those are not intended to limit the applicability of those concepts / embodiments to other telecommunication environments. In brief, according to at least aspects of the invention, countermeasures are proposed which prevent that {NH, NCC} pairs of keys in a terminal UE and MME get out of synchronization due to a number of S1 handover failures.

That is, in relation to the aspect of the present invention as described herein below, it is proposed to modify the policy for renewing {NH, NCC} pairs in the MME. Stated in other words, the parameters {NH, NCC} are conditionally suppressed to be renewed in relation to a failed S1 handover, and instead of new (renewed) ones, previously generated ones which originate from an earlier failed S1 handover are re-used. This is based upon occurrence of a renewal suppression condition.

Generally, in terms of a network mobility entity, e.g. a MME, aspects of the invention encompass an apparatus, comprising a memory unit; and a control unit connected to the memory unit, the apparatus being configured to interface at least one access node wherein the control unit is configured to process one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forward said derived local security key to at least one access node, detect a handover for a terminal being served by a first access node towards a second access node, wherein the handover concerns the interface between the apparatus and said second access node, responsive thereto, update at least one derived local level security key, store the updated at least one derived local security key in the memory, detect a failure in said handover on the interface between the apparatus and said second access node, verify a restore condition based on a handover failure history, and responsive to the restore condition verified, fetch the stored at least one local level security key from the memory.

The at least one local level security key is a next hop, NH, key and a next hop chaining counter, NCC. Note that the apparatus, in terms of verifying a trigger condition based on a handover failure history, the control unit is further configured to detect a subsequent failed handover for said terminal being served by the first access node towards said same second access node on said interface between the apparatus and said second access node. This subsequent handover is the first handover following the handover responsive to which the update and storage of the local level security key was performed. Similar notions as made above with reference to apparatus aspects apply likewise to related method aspects.

The above will be set out in greater detail with reference to the flow chart in Fig. 2.

According to one aspect of the invention, as illustrated in Fig. 2A and B, there are proposed solutions which, in brief, introduce a procedure as follows:

When an S1 handover fails, the MME falls back to the {NH, NCC} pair stored or computed before that handover under one of the following trigger conditions (e.g. also referred to as "renewal suppression condition"):

- "Restore condition": (cf. Fig. 2A)

Resore the old key pair, if the old {NH, NCC} pair was created in a preceding failed S1 handover to the same target eNB. - "Bypass condition": (cf. Fig. 2B)

Bypass the computation of a new key pair, if the current {NH, NCC} pair was computed for a failed S1 handover to the same target eNB.

Note that there is no similar rule in the 3GPP specifications. The condition 'to the same target eNB' is important in that it avoids that (as otherwise) two different target eNBs could receive the same {NH, NCC} pair. (This would be contrary to the intention of so-called forward security (cf. definition in TS 33.401 , clause 3.1 ) and thus would violate those principles).

As shown e.g. in Fig. 2A, a MME related procedure for S1 handover starts at stage 20. At stage 21 , a copy of the old next hop, NH, key and old next hop chaining counter, NCC will be stored. Stage 22 calculates a new next hop, NH, key and a new next hop chaining counter, NCC according to TS 33.401 clause 7.2.8.4.3. These new parameters will replace the old ones, but not their copies. Stage 23 checks for the "restore condition" mentioned above: If and only if the handover failed and the old (copied) NH and NCC was already derived for same target eNB #B, the NH and NCC will be restored from its copies, as shown in stage 24. Otherwise, the process will proceed from stage 23 to stage 25 and the process will proceed "normally".

One possible modification of or alternative for the new procedure is to check for previously failed S1 handover before a new NH and NCC shall be computed. In this way, the restore condition becomes replaced by a not-incrementing condition which is refered to herein above also as "bypass" condition, but the basic principle of avoiding unnecessary NCC incrementing is always the same.

This option is illustrated in Fig. 2B. A MME related procedure for S1 handover starts at stage 26 In stage 27, the bypass condition is verified, i.e. it is verified whether the current pair of keys {NH, NCC}.was computed for a failed S1 -HO for the same target eNB. If YES, the flow branches and bypasses computation of the new parameter pair and proceeds to stage 29 in which the process proceeds as "normal". If NO, the process proceeds to stage 28 in which a new pair of keys {NH, NCC} is computed, and only thereafter, the process proceeds to stage 29.

Figure 3 shows, supplementing the above description of aspects of the invention, a basic block circuit diagram of a network entity such as a MME, in which embodiments of the present invention are implemented. Thus, the entity 4 can be any kind of a mobility management entity MME.

The MME, denoted by numeral 4, comprises a interface, Tx/Rx, cf. numeral 43, for transmission to / reception from another EPS network entity, e.g. an eNB and/or further to a UE. The interface is bidirectional connected to a control module or unit such as a processor, e.g. a digital signal processor, DSP, or ASIC (ASIC = application specific integrated circuit), CPU (central processing unit), or the like, denoted by numeral 42. The control module or unit (aka controller) is bidirectional connected to a memory module or unit (aka memory) MEM, denoted by numeral 41. The memory module can be any type of memory to which data can be written and from which data can be read, e.g. a Flash memory, RAM (Random Access Memory), or also EPROM (Electrically Programmable Read Only Memory). The memory module is configured to store at least data necessary for implementation of the invention, e.g. control code, acquired and/or processed data to be used for implementing/realizing at least aspects of the invention.

Thus, the memory module can be a separate memory module or a partition of a memory module storing also other user/control data handled by the MME. Other memory modules may be present, too, in the entity. Examples of the invention can be embodied in an apparatus or unit of the MME, e.g. denoted by numeral 40, comprising at least the modules 42 and 41 above.

Note that embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware generally resides on a module or unit, or chipset or apparatus associated to a device, i.e. mounted/inserted or mountable/insertable to or configured as a part of such a device, such as a network entity like an MSS or similar functionality.

In an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer or smart phone, or user equipment.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above- described functions may be optional or may be combined.

Although the above description focused on an algorithm aspect, it is to be understood that the algorithm is configurable to corresponding hardware or implemented as software code loaded to a processor. Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

List of some acronyms and abbreviations as used herein above: HO handover RRM Radio Resource Management

UE User Equipment

HeNB Host eNodeB SeNB Source eNodeB

TeNB Target eNodeB

EPS Evolved Packet System Other acronyms are conformant to those mentioned in 3GPP TR 21.905 or TS 33.401 .

Claims

What is claimed is:

1. An apparatus, comprising a memory unit; and a control unit connected to the memory unit, the apparatus being configured to interface at least one access node wherein the control unit is configured to process one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forward said derived local security key to at least one access node, detect a handover for a terminal being served by a first access node towards a second access node, wherein the handover concerns the interface between the apparatus and said second access node, responsive thereto, update at least one derived local level security key, store the non-updated at least one derived local security key in the memory, detect a failure in said handover on the interface between the apparatus and said second access node, verify a restore condition based on a handover failure history, and responsive to the restore condition verified, fetch the stored at least one local level security key from the memory.

2. An apparatus, comprising a memory unit; and a control unit connected to the memory unit, the apparatus being configured to interface at least one access node wherein the control unit is configured to process one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forward said derived local security key to at least one access node, detect a handover for a terminal being served by a first access node towards a second access node, wherein the handover concerns the interface between the apparatus and said second access node, responsive thereto, verify a bypass condition based on a handover failure history, and responsive to the bypass condition verified, skip the derivation of at least one local security key.

3. An apparatus according to claims 1 or 2, wherein the at least one local level security key is a next hop, NH, key and a next hop chaining counter, NCC.

4. An apparatus according to claim 1 or 2, wherein in terms of verifying a renewal suppression condition based on a handover failure history, the control unit is further configured to detect a subsequent failed handover for said terminal being served by the first access node towards said same second access node on said interface between the apparatus and said second access node.

5. An apparatus according to claim 4, wherein the subsequent handover is the first handover following the handover responsive to which the update and storage of the local level security key was performed.

6. A method, comprising processing one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forwarding said derived local security key to at least one access node, detecting a handover for a terminal being served by a first access node towards a second access node, wherein the handover concerns the interface between the apparatus and said second access node, responsive thereto, updating at least one derived local level security key, storing the non-updated at least one derived local security key in the memory, detecting a failure in said handover on the interface between the apparatus and said second access node, verifying a restore condition based on a handover failure history, and responsive to the restore condition verified, fetching the stored at least one local level security key from the memory.

7. A method, comprising processing one or more higher level security keys received from a network entity to derive at least one local level security key within an established security context for a terminal, forwarding said derived local security key to at least one access node, detecting a handover for a terminal being served by a first access node towards a second access node, wherein the handover concerns the interface between the apparatus and said second access node, responsive thereto, verifying a bypass condition based on a handover failure history, and responsive to the bypass condition verified, skipping the derivation of the at least one local security key.

8. A method according to claims 6 or 7, wherein the at least one local level security key is a next hop, NH, key and a next hop chaining counter, NCC.

9. A method according to claim 6 or 7, wherein in terms of verifying a renewal suppression condition based on a handover failure history, the control unit is further configured to detect a subsequent failed handover for said terminal being served by the first access node towards said same second access node on said interface between the apparatus and said second access node.

10. A method according to claim 9, wherein the subsequent handover is the first handover following the handover responsive to which the update and storage of the local level security key was performed.

1 1 . A computer program product comprising computer-executable components which, when the program is run on a computer, are configured to perform the method steps according to any of claims 6 to 10.