Patent Description:
Subscribers in the cellular systems have a long-term identifier called the International Mobile Subscriber Identifier (IMSI), which should be handled with care in network protocols and applications for security and privacy reasons. When a subscriber attempts to join in the network by connecting to a base station via her UE, a procedure called "Attach" has to be followed which requires disclosure of UE 's (User Equipment, also called mobile entity hereinafter) identity on the radio link.

When an attach request is sent by the UE, the MME (Mobility Management Entity) initiates a different procedure depending on the type of such attach. The criteria such as with which UE ID (e.g., IMSI) the UE is making a request, to which MME the UE is trying to attach, and whether the valid last UE context exist in the network will be used to distinguish different types of initial attach. In all types of initial attach, the UE ID acquisition procedures are required. There are three attach cases. First case occurs when neither UE nor network has the last UE context; a UE sends an attach request message to an MME using its IMSI as UE ID. The MME initiates authentication and NAS (Non-Access Stratum) security setup procedure since it does not know the UE. Second case is when a UE is attaching to the MME that it has attached to last time, but the MME doesn't have the valid last UE Context of the UE. In this case the MME sends an Identity Request message, requesting an IMSI. The third case is when a UE is attaching to a new MME to which it has never attached before, and the MME doesn't have the valid Last UE Context of the UE.

During the "Attach" procedure in <NUM> and earlier generations, UEs are requested to identify themselves by the base station they are attempting to connect. UEs usually respond to these requests by declaring their TMSI (temporary identifier). Yet, related standards allow MME to request UEs' long term identifiers, IMSI, instead of TMSI, by sending a special IDENTITY REQUEST message, as a mechanism to resolve the cases where TMSIs are lost in the network. The MME can send an IDENTITY REQUEST message to a UE at any time while the UE is in EMM-CONNECTED mode and the UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED mode. The user's response contains the IMSI in cleartext. This may cause a breach in the provision of user identity confidentiality. This mechanism is exploited by false base stations (FBS, also known as IMSI catchers) to capture IMSI of UEs by transmitting IDENTITY REQUEST messages to the victim UEs. To do this, false base stations usually advertise themselves as a good service point by radiating more powerful signals. Because there is no security mechanism by design for mutual authentication between a UE and a base station during the initial phase of the Attach procedure, they can easily manage to fool UEs around the fake base stations in this way. Preventing this kind of misuse of base stations is mostly not possible by just legal regulations. It is also necessary to take some technical countermeasures.

The earlier approaches proposed for detection of false base stations can be device-assisted, network-assisted or apparatus-based. Known device-assisted methods are usually primitive in that a technician just manually observes the wireless signals at a specific location by using a radio device or spectrum analyzer to see if there is any suspicious signal that could be a sign for a possible false base station. In another solution within this category, a special terminal sends a Location Area Update Request message to a targeted base station, and then if a REJECT message is received from this base station in return, it is identified as false base station. In network-assisted solutions, regular measurement reports of all UEs in a region of interest are first collected by the base stations and forwarded to a central unit for further processing. Then, a type of anomaly detection is performed in comparison with the legitimate network topology by analyzing the collected measurement reports. There is also an apparatus-based solution, which proposes a method and an apparatus to detect IMSI catchers by using the apparatus as a bait to reveal IMSI catcher. That approach relies on the observation that a typical IMSI catcher unicasts IDENTITY REQUEST messages more frequently than expected.

Some solutions require additional information about underlying legitimate network such as network topology. Some of these also require information from measurement reports of UEs, which requires collection of additional data with large size about network topology under investigation.

Some of the existing solutions are based on comparison of the radio signals collected from false base station with signals from or data related to legitimate base stations. In these methods, characteristics of underlying legitimate network are used as the basis for comparison. However, to be able to do this, a heavy data collection process is required from both legitimate network and from possible rogue base stations. This could be done by using a dedicated radio device belonging to the network operator, usually on a car to scan various locations. These are expensive operations in terms of time and workforce.

There are some solutions that do not require complex signal analysis but only collect selected protocol messages like IDENTITY REQUEST. However, these methods require use of dedicated devices in the form of apparatus to collect data from the mobile network. Although this approach may be effective, it is costly since it requires usage of additional hardware. <CIT> discloses a method for identifying and reporting fraudulent base stations based on the fact whether several reports are received from the same base station.

In sum, there are several problems of existing solutions in data collection and comparison phases as given below.

Accordingly a need exists to overcome the above-mentioned problems and to be able to easily detect the false base stations in an effective way.

According to a first aspect a carried out at a verification entity of the cellular network is provided as mentioned in claim <NUM>, wherein inter alia the verification entity receives a verification request transmitted by a mobile entity by which a verification of an identity request is requested, wherein the identity request requests a permanent, non-temporary identity of the mobile entity from the mobile entity by which the mobile entity is uniquely identified in the cellular network. In response to the verification request, the verification entity checks whether the identity request corresponds to one of a plurality of identity requests stored in a memory. If this is not the case, it is determined that the identity request was transmitted by an entity not belonging to the cellular network and not entitled to request the permanent, non-temporary identity of the mobile entity.

Furthermore, the corresponding verification entity is provided comprising a memory and at least one processing unit, wherein the memory contains instructions executable by the at least one processing unit, wherein the verification entity is operative as discussed above or as discussed in further detail below.

The verification entity receiving the verification request can check, based on a memory comprising the identity requests transmitted by the cellular network in a defined time period, whether the identity request was transmitted by an entity of the network or not. The memory can comprise a log of the transmitted identity requests, and based on the queries the verification entity can check whether the request was transmitted by an entity entitled to do so.

A computer program comprising program code is provided, wherein execution of the program code causes at least one processing unit of the verification request to execute a method as discussed above or as explained below in further detail.

Finally, a carrier comprising the computer program is provided, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

It is to be understood that the features mentioned above and features yet to be explained below, can be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the present invention. Features of the above-mentioned aspects and embodiments described below may be combined with each other in other embodiments unless explicitly mentioned otherwise.

The foregoing and additional features and effects of the invention will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numerals refer to like elements.

Rather, the various elements are represented such that their function and general purpose becomes apparent to a person with skill in the art. Any connection or coupling between functional blocks, devices, components of physical or functional units shown in the drawings and described hereinafter, may also be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Functional blocks may be implemented in hardware, software, firmware, or a combination thereof.

Within the context of the present application, the term mobile entity or user equipment, UE or user entity, refers to a device for instance used by a person, such as a user for his or her personal communication. It can be a telephone type of device, for example a telephone or a session initiation protocol, SIP, or voice over IP phone, cellular telephone, mobile station, cordless phone, or a personal digital assistant type of device like laptop, notebook, notepad, tablet equipped with a wireless data connection. A UE may be equipped with a subscriber identity module, SIM, or electronic SIM comprising unique identities such as the IMSI, the TMSI or the GUTI, Globally Unique Temporary UE Identity, which are associated with the user using the UE. The presence of a SIM within the UE customizes the UE uniquely, is a subscription of the user.

For the sake of clarity, it is noted that there is a difference, but also tight connection between a user and a subscriber. User gets access to the network by acquiring a subscription to the network and by that becomes a subscriber within the network. The network then recognizes the subscriber, using the IMSI, TMSI or GUTI or the like and uses the associated subscription to identify related subscription data. A user is the actual user of the UE, and the user may also be the one owning the subscription, but the user and the owner of the subscription may also be different. By way of example the subscription may be owned by one of the parents wherein the actual user is the child.

In the following a method is discussed in which the IMSI catchers or false base stations are detected, whose aim is to capture long-term identifiers such as the IMSI of the UE's to track the locations of mobile network subscribers.

The proposed method uses an approach used by the false base station, which sends identity request messages to force the subscribers to send their identities. In the solution below, a verification entity, such as an MME, logs the identity request messages of the network. In the solution discussed below, the mobile entity can comprise an application which can be a mobile device application or which can be USIM application, which captures the identity request messages received by the mobile entity and which sends the messages to the cellular network, the cellular network then checks whether the serving MME which has sent the identity request message, belongs to the cellular network. If the check result is negative, this means that someone else has sent the identity request message in the area where the identity request message has been detected by the UE.

The method introduces an application which can be a SIM application or can be a mobile application and works as follows. The application in the UE captures the IDENTITY REQUEST messages and sends them to the core network. Then the network checks whether these IDENTITY REQUEST messages have been sent by the MME or any other entity in the network. If the check result is that these messages haven't been sent by the MME, it is decided that there is an attacker in the area to which the serving MME belongs, who sends fake IDENTITY REQUEST messages. To be able to verify the messages, the network should store the IDENTITY REQUEST messages that have been sent for a short while. It is not necessary to store these messages for all the users and it is enough to store them for only the UEs where the application runs and/or for the UEs that are in subjected area.

When the application in the UE is a SIM application, then the UE can send the captured IDENTITY REQUEST messages to the network. If the application is a mobile application, then there can be different deployment options on the mobile operator. An example deployment scenario can be the following: An application server can be deployed in the operator DMZ zone, the client application communicates with the application server and the application server sends these messages to the core network via SCEF (Service Capabilities Exposure Function) framework.

The UEs used for detection of IMSI catchers can be special purpose UEs or they can be ordinary UEs that belong to subscribers of the operator. The false positive probability of this method is near to zero since no statistical analysis is executed for the decision.

There can be another use cases where all UEs include the SIM application and the operator can activate the application for a specific area where they would like to detect the IMSI catcher.

In the embodiment shown in <FIG> the core network comprises a verification entity, which is implemented here as the MME <NUM> or a network function or any other external system of function <NUM>. Furthermore, in the embodiment shown a UE <NUM> is shown which comprises a separate application which implements the verification of the received identity request. Additionally the RAN (Radio Access Network) <NUM> is shown.

As shown in step S10, the core network logs the identity request messages that were sent to mobile entities. The network function <NUM> can be a new network function or an existing network function such as a network data analytics function, NWDAF. The log mechanism can be implemented in different ways on the MME or on the external system or network function by using different memories such as a database or log files. The selection of the core network component such as the MME or the network function may depend on the choice of the operator of the cellular network. In step S11 the core network, here the MME <NUM>, sends an identity request message to the UE <NUM>, which provides the requested identity type to the MME due to the loss of the UE identity mapping or due to any other reason. In step S12 the UE sends the identity response message to the MME by providing the requested identity such as the IMSI.

Furthermore, the application in the UE, the UE app or the UE itself is transmitting a verification request requesting the verification of the identity request to the MME or the network function depending on the location of the stored log. This verification request comprises the requested identity type. <FIG> shows two different options, either the verification request is sent in step S 13a to the MME or it is sent to the network function in step S 13b. This transmission may be triggered by the reception of the identity request message or triggered after sending the identity response message. In <FIG> the first trigger case is shown.

In step S14 the receiving entity checks whether the message that the UE had received is one of the already logged messages. If this is the case, if the identity request is found in the memory storing the different transmitted identity request, it is determined that the identity request was transmitted by an entity entitled to ask for the identity. It is possible that the UE app sends the verification request of steps S13a or b via a different communication channel then the received identity request, as this may depend on the deployment scenario and the type of the application, whether it is an SIM application or a mobile application.

In <FIG> the situation is furthermore shown that a false base station <NUM> transmits the identity request as shown by step S15. In step S16 the UE <NUM> transmits back the identity response with the requested type of identity as it cannot determine alone whether the transmitting entity is entitled to ask for the requested identity. Furthermore, however the UE <NUM> transmits the verification request to the core network, here the MME in step S17a or to the network function in step S17b. The core network entity, the receiving entity, then checks if the network has sent the identity request. It can search in the database for the corresponding request. As this request was not sent by the core network or an entity attached to the core network, no entry is found in the database and the verification entity can deduce that a false base station, FBS, has transmitted the request ( S18). In a step not shown, the MME can either inform the operator of the cellular network or can otherwise collect the detected information about the false base stations, so that this information can be retrieved from the verification entity.

The verification entity <NUM>, <NUM> can log the transmitted identity requests for a defined period of time and after the period of time has lapsed, the information about the transmitted identity request may be removed from the memory or database. Furthermore, it is possible that the identity request messages are only stored and logged for a certain area in the cellular network, by way of example if there is a reasonable suspicion that a false base station may be present in a certain area of the cellular network. The memory may be collocated to the MME, or NF, or it may be a separate entity to which the MME <NUM> or NF <NUM> have access.

The method discussed above detects the false base stations or ID catchers by checking that the identity request messages received by a UE was indeed sent by a legitimate entity. This is obtained by mobile entities which notify the serving network about the reception of identity request messages, and the network can check its logs to see whether the identity request message was sent by the network itself or by a false base station. The method discussed above does not require a use of an additional device. Furthermore, information about the network topology is not needed. The mobile entity can implement an application running on the mobile entity or can use USIM application, which does not perform heavy computations but just informs the network about the reception of the identity request messages and request the verification.

The method is mainly based on the comparison of what is actually sent by the network and what is received by the UE, and any discrepancy here indicates that an unauthorized message has been transmitted by a false base station. Accordingly, the false-positive probability is nearly <NUM>, as no statistical analysis is required. Furthermore, no complex signal analysis is involved, but only the simple comparison of the transmitted and received messages. This simplifies the computational effort needed for the detection.

<FIG> summarizes some of the main steps carried out by the mobile entity <NUM> in the message exchange shown in <FIG>.

In a first step S21 the mobile entity receives an identity request from the requesting entity. The requesting entity can be a component from the cellular network entitled to request the identity, however the requesting entity can also be a false base station or a node not entitled to request the permanent identity of the mobile entity. As the mobile entity cannot identify whether the requesting entity is entitled to request the identity of the UE, in step S22 the mobile entity transmits the response including the requested identity. However, in step S23 the UE additionally transmits in response to the identity request a verification request to an entity of the cellular network, an entity provided in the core network which is named as verification entity and which can be implemented as MME, as a separate network function, such as a network data analytics function.

<FIG> summarizes some of the steps carried out at the corresponding verification entity.

In step S <NUM> the verification entity receives the verification request, which was transmitted by the mobile entity as mentioned in connection with <FIG>. The verification request asks the verification entity to check the identity request which was received by the mobile entity and which requested the permanent identity of the mobile entity. In step S <NUM> the verification entity checks, in response to the received verification request, whether the identity request corresponds to one of several requests which are stored in a memory where the identity requests of the cellular network are stored. Accordingly the verification entity can access a kind of log file, where all the identity requests sent by members of the cellular network are stored, especially the requests sent in a defined time period in the past such as several seconds. If the identity request is found in the memory, the verification entity can conclude that it was transmitted by an entity of the cellular network (S34). If the identity request cannot be found in the corresponding memory or log file, the verification entity can determine that it was transmitted by an entity not belonging to the cellular network and by an entity not entitled to request this permanent identity. This corresponds to step S35.

The verification entity can still carry out the following steps in order to generate the log file or populate the memory. If the verification entity transmits itself an identity request to the mobile entity, the transmitted identity request is stored for a defined period of time in the corresponding memory, where the plurality of different identity requests are stored. Furthermore, it can receive in response to the identity request, a response from the mobile entity in which the response includes the permanent non-temporary identity of the mobile entity. These steps can proceed the steps shown in <FIG>.

<FIG> shows a schematic architectural view of the mobile entity, which can carry out the above discussed steps in which the mobile entity is involved. The mobile entity <NUM> comprises an interface <NUM>, provided for transmitting user data or control messages to other entities, such as the verification entity and configured to receive user data or control messages from other entities, such as the identity request from an entitled entity or a false base station. The mobile entity furthermore comprises a processing unit <NUM> which is responsible for the operation of the mobile entity. The processing entity <NUM> comprises one or more processors and can carry out instructions stored on a memory <NUM>, wherein the memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory can furthermore include suitable program code to be executed by the processing unit <NUM> so as to implement the above described functionalities in which the mobile entity is involved.

<FIG> shows a further schematic architectural view of a mobile entity <NUM> which comprises a first module <NUM> configured to receive the identity request requesting the permanent unique identifier of the mobile entity. A second module <NUM> is configured to transmit in response to the received request, the requested permanent subscriber identity. A third module <NUM> is provided configured to transmit, also in response to the identity request the verification request to the verification entity, by which the mobile entity requests the verification entity to check the correctness and entitlement of the requesting entity.

<FIG> shows a schematic architectural view of the verification entity <NUM> which can carry out the above discussed verification of the identity requests. The verification entity <NUM> comprises an interface <NUM>, provided for transmitting user data or control messages to other entities, such as the mobile entity and configured to receive user data or control messages from other entities, such as the verification request received from the mobile entity. The verification entity furthermore comprises a processing unit <NUM> responsible for the operation of the verification entity. The processing entity <NUM> comprises one or more processors and can carry out instructions stored on a memory <NUM>. The memory may include a read-only memory, a random access memory, a mass storage, a hard disk or the like. The memory <NUM> can furthermore include a suitable program to be executed by the processing unit <NUM>, so as to implement the above described functionalities in which the verification entity is involved.

<FIG> shows a further schematic architectural view of the verification entity <NUM>, comprising a first module <NUM>, configured to receive the verification request from the mobile entity by which the verification of the identity request as received by the mobile entity is checked. A second module <NUM> is configured to check, in response to the verification request, whether the identity request corresponds to a known identity request, which is stored in a memory comprising the known identity requests. A third module <NUM> is provided configured to determine, if the request is not known, that the entity requesting the identity request is not belonging to the cellular network or is not entitled to request this permanent identity of the mobile entity.

From the above said some general conclusions can be drawn.

As far as the mobile entity is concerned, when the verification request is transmitted to the verification entity, the verification request may be transmitted to a core network of the cellular network, by way of example a mobile management entity MME, or a data analytics entity of the cellular network.

The transmission of the verification request may be triggered when the identity request is received or when the response is transmitted to the requesting entity.

The permanent non-temporary identifier may comprise the IMSI, however any other permanent non-temporary identifier might be used.

As far as the verification entity is concerned, the verification entity can transmit an identity request to the mobile entity, which requests the permanent non-temporary identity of the mobile entity. Furthermore, the verification entity can store the transmitted identity request for a defined time period in a memory where the plurality of different identity requests of the cellular network are stored. After the defined period of time has lapsed the transmitted identity request can be removed from the memory. The verification entity can furthermore receive, in response to the identity request, a response from the mobile entity which includes the permanent non-temporary identity of the mobile entity.

The transmitted identity request may be stored only for mobile entity's meeting a defined requirement, such as a defined type of mobile entity or a mobile entity located in a defined area within the cellular network.

The transmitted identity request may be stored in the memory configured to store identity requests for a plurality of different verification entities of the cellular network. Accordingly a unique memory or log file may be provided for the identity requests, transmitted by different entities of the cellular network. The memory can be a memory where the identity requests transmitted by any node of the cellular network ( e.g. nodes entitled to send identity requests) are stored for a defined period of time. Furthermore it is possible that different memories are used for different areas of the cellular network.

The verification entity may be implemented in a mobility management entity, a data analytics entity, or any other network function, which has access to the cellular network.

Claim 1:
A method carried out at a verification entity of a cellular network, the method comprising:
- receiving, a verification request transmitted by a mobile entity, requesting a verification of an identity request by which a permanent, non-temporary identity of the mobile entity is requested from the mobile entity by which the mobile entity is uniquely identified in the cellular network,
- checking, in response to the verification request, whether the identity request corresponds to one of a plurality of identity requests stored in a memory, wherein if this is not the case,
- determining that the identity request was transmitted by an entity not belonging to the cellular network and not entitled to request the permanent non-temporary identity of the mobile entity, the method further comprising:
- transmitting the identity request to the mobile entity, the identity request requesting the permanent, non-temporary identity of the mobile entity by which the mobile entity is uniquely identified in the cellular network,
- storing the transmitted identity request for a defined period of time, in a memory configured to store a plurality of different identity requests,
- receiving, in response to the identity request, a response from the mobile entity, the response including the permanent, non-temporary identity of the mobile entity.