WO2017194163A1

WO2017194163A1 - Enduser verification in mobile networks

Info

Publication number: WO2017194163A1
Application number: PCT/EP2016/060871
Authority: WO
Inventors: Florin Alexandru DEACONU; Kostas Kouridakis
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-05-13
Filing date: 2016-05-13
Publication date: 2017-11-16

Abstract

A system, method, node and computer program for verifying a user of a user equipment, UE (100), in a mobile communication network comprising a control node (110) and a subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation comprises a set of UE (100) characteristics associated with the UE (100), the method comprises receiving, by the control node (110), an initial request message from the UE (100) and checking whether the UE representation matches a previous value. The method further comprises verifying, by the subscriber database (120) in case the UE representation does not match the previous value, the user of the UE (100) by retrieving the user identification password from the user and comparing it with a reference. The method comprises in addition proceeding, by the control node (110), with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

Description

ENDUSER VERIFICATION IN MOBILE NETWORKS Technical field

The present invention relates to telecommunications and in particular to a system, method, node and computer program for verifying a user of a user equipment, UE, in a mobile communication network.

Background

In the current mobile communication networks as defined by 3GPP specifications, a UE is personalized to a user and to the subscription held by the user by inserting a

Subscriber Identity Module, SIM, card into the UE. However, a malicious user that get its hands on an original SIM card can duplicate that SIM card by a simple cloning operation where all data of the SIM card are read and 1 :1 written to an empty SIM card. Such duplication is also known as SIM cloning.

The malicious user can then use such cloned SIM card to register to the mobile communication network and perform calls or data traffic on behalf of the rightful owner of the original SIM card.

As long as the legal owner is using his/her UE (i.e. the UE is in a busy status), the registration of the cloned SIM card can be prevented with the existing basic network security mechanisms implemented in the mobile communication networks.

Nevertheless, in case the owner is not using his/her phone and the UE (i.e. the UE is in idle or detached status), the current standards and check mechanisms are unable to detect if a new registration request/location update is a legit one or coming from a UE with cloned SIM card.

One obvious example is the case where the subscriber is travelling abroad by plane and when he boards the plane he switches off (detaches) his/her mobile. Several hours later, a network registration/location update request is received in the home mobile communication network from a location placed at a distance, that could fit the time the user have been detached (when the speed of a current commercial plane is

considered). In such cases, the mobile communication network has no means to detect if the received request is coming from the rightful user or from a malicious or fraudulent party using a cloned SIM card while the user is still travelling without network connection.

If such cloned SIM card manages to get registered into the mobile communication network and its malicious user starts using it, this results into the problem that an access by the rightful user will be denied, when he/she attempts to register in a mobile communication network available at his/her location.

This problematic may even increase when the usage of electronic SIM, e-SIM, takes off, where the e-SIM is not bound to any physical hardware anymore but pure software and related credentials.

Summary

The fundamental problem is that all current authentication verification mechanisms are based on the information on the SIM card, which, if being cloned to a further SIM card, is cloned as well. On the other hand, the authentication verification mechanism must still allow the user to change his/her UE, e.g. in case the old UE is malfunctioning.

There is a clear need for an improved verification mechanism of a user of a UE in a mobile communication network. It is an objective of the present invention to provide such improved verification mechanism.

Today's communication networks comprise control nodes and a subscriber database. A control node is handing the activities of the user such as network registration, mobility of the user, calls, messaging, or packet access to the Internet. The subscriber database holds the subscriber data and is located in the home network of the user.

The solution concept in this present application uses a user identification password, which is not stored on the SIM card, or in the UE. The user identification password is known only by the user of the UE and is stored in the subscriber database only. The user can authenticate himself/herself by providing the user identification password, when being prompted by the subscriber database. At cloning of the SIM card, such user identification password would not be part of the cloning process, and therefore a malicious user is not able to obtain that user identification password. Although the use of a user identification password provides much better protection against misuse, typing in of the user identification password can be annoying and not practical. Therefore the present application uses the concept of a UE representation. A UE representation could be based on a set of UE characteristics, so e.g. a fingerprint of the UE. As long as the current UE fingerprint is consistent with a previous UE fingerprint, it can be assumed that there is no change of the UE - SIM card combination. The UE fingerprint is taken and stored by the control node handling the UE. At the next access of that UE, a fresh UE fingerprint is taken and compared with the previous UE fingerprint. In case of a match, the access of the UE is granted, or in case of mismatch the control node instructs the subscriber database to retrieve the user identification password from the user, and compare it with the stored reference. So in case the user rightfully inserts his/her SIM card into a new UE, the UE fingerprint will indicate such change. Then the user has to authorize this change of UE by giving his/her user identification password.

In case a malicious user clones a SIM card and puts that cloned SIM card into another UE, the UE fingerprint will indicate a change. The malicious user is then prompted for the user identification password, which is not known to the malicious user. Then that malicious access attempt is rejected and the rightful user can fully retain his/her service.

By using an appropriate set of UE characteristics, it is possible to detect not only a change of the UE, but e.g. also a sudden change of geographical position of the UE, which may happen if the malicious user also fakes the hardware identity of the UE, but operates the malicious access remote from the actual location of the rightful UE.

The above objective is achieved by the independent claims. Advantageous

embodiments are described in the dependent claims. According to an exemplary aspect of the invention, a method for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises a control node and a subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The method comprises, receiving, by the control node, an initial request message from the UE, and checking, by the control node, whether the UE representation matches a previous value. The method further comprises, verifying, by the subscriber database in case the UE representation does not match the previous value, the user of the UE by retrieving the user identification password from the user and comparing it with a reference. The method also comprises, proceeding, by the control node, with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

According to another exemplary aspect of the invention, a method in a control node for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises the control node and a subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The method comprises, receiving an initial request message from the UE and checking whether the UE representation matches a previous value. The method further comprises, causing, in case the UE representation does not match a previous value, the subscriber database to verify the user of the UE. The method also comprises, proceeding with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

According to another exemplary aspect of the invention a method in a subscriber database for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises a control node and the subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The method comprises receiving a request to verify the user of the UE and causing the user to type in his user identification password. The method also comprises, verifying the user of the UE by comparing the user identification password with a reference.

According to another exemplary aspect of the invention, a control node for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises the control node and a subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The control node is capable of receiving an initial request message from the UE and checking whether the UE representation matches a previous value. The control node is further capable of causing, in case the UE representation does not match a previous value, the subscriber database to verify the user of the UE and proceeding with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

According to another exemplary aspect of the invention, a control node apparatus for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises the control node apparatus and a subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The control node apparatus comprises a processor and a memory, said memory containing instructions executable by said processor whereby said control node apparatus is operative to receive an initial request message from the UE, check whether the UE representation matches a previous value, cause, in case the UE representation does not match a previous value, the subscriber database to verify the user of the UE, and proceed with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

According to another exemplary aspect of the invention a subscriber database for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises a control node and the subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The subscriber database is capable of receiving a request to verify the user of the UE and causing the user to type in his user identification password. The control node is further capable of verifying the user of the UE by comparing the user identification password with a reference.

According to another exemplary aspect of the invention a subscriber database apparatus for verifying a user of a user equipment, UE, in a mobile communication network is provided. The mobile communication network comprises a control node and the subscriber database apparatus, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The subscriber database apparatus comprises a processor and a memory, said memory containing instructions executable by said processor whereby said apparatus is operative to receive a request to verify the user of the UE, cause the user to type in his user identification password, and verify the user of the UE by comparing the user identification password with a reference.

According to another exemplary aspect of the invention, a system for verifying a user of a user equipment, UE, in a mobile communication network is provided. The system comprises a control node and a subscriber database, wherein a user identification password is associated with a user of the UE, and a UE representation based on a set of UE characteristics is associated with the UE. The system comprises the control node, the subscriber database and the UE. The foregoing and other objects, features and advantages of the present invention will become more apparent in the following detailed description of embodiments of the invention illustrated in the accompanying drawings.

Brief description of the drawings

Further characteristics and advantages of the invention will become better apparent from the detailed description of particular but not exclusive embodiments, illustrated by way of non-limiting examples in the accompanying drawings, wherein:

Figure 1 shows a diagram illustrating a system for verifying a user of a UE according to the invention; Figure 2 shows a signaling flow where a UE roams into the area of a new MSC according to the invention;

Figure 3 shows a signaling flow where a MSC retrieves a previous UE fingerprint via the HLR and the IMEI and PLNM is unchanged according to the invention;

Figure 4 shows a signaling flow where a MSC retrieves a previous UE fingerprint via the HLR and the IMEI or PLNM is changed according to the invention;

Figure 5 shows a signaling flow where a MSC retrieves a previous UE fingerprint directly from a previous MSC according to the invention;

Figure 6 shows a signaling flow on how to compare two UE fingerprints according to the invention; Figure 7 shows a signaling flow on how the HLR retrieves a user identification password according to the invention;

Figure 8 shows a signaling flow where the UE roams within the area of the MSC according to the invention;

Figure 9 shows a signaling flow where there is no support by a visited MSC for checking the UE fingerprint and the HLR retrieves the user identification password according to the invention; Figure 10 shows a signaling flow on a change of the user identification password initiated by the HLR or the user according to the invention;

Figure 1 1 shows a signaling flow where a UE roams into a new MME area according to the invention; Figure 12 shows a signaling flow where a HSS retrieves a user identification password via a temporary APN and a landing web page according to the invention;

Figure 13 shows a flow diagram in a control node according to the invention;

Figure 14 shows a flow diagram in a subscriber database according to the invention;

Figure 15 shows a block diagram illustrating a control node apparatus according to the invention;

Figure 16 shows a block diagram illustrating a subscriber database apparatus according to the invention.

Detailed description

In the following, a system, method, node and computer program for verifying a user of a user equipment, UE, in a mobile communication network according to the invention are described in more detail.

Within the context of the present application, the term "user equipment" (UE) refers to a device for instance used by a person (i.e. a user) for his or her personal

communication. It can be a telephone type of device, for example a telephone or a Session Initiating Protocol (SIP) phone, cellular telephone, a mobile station, cordless phone, or a personal digital assistant type of device like laptop, notebook, notepad, tablet equipped with a wireless data connection. The UE may also be associated with non-humans like animals, plants, or even machines. A UE may be equipped with a SIM (Subscriber Identity Module) or electronic-SIM comprising unique identities such as IMSI (International Mobile Subscriber Identity), TMSI (Temporary Mobile Subscriber Identity), or GUTI (Globally Unique Temporary UE Identity) associated with the user using the UE. The presence of a SIM within a UE customizes the UE uniquely with a subscription of the user. For the sake of clarity, it is noted that there is a difference but also a tight connection between a user and a subscriber. A user gets access to a network by acquiring a subscription to the network and by that becomes a subscriber within the network. The network then recognizes the subscriber (e.g. by IMSI, TIMSI or GUTI or the like) and uses the associated subscription to identify related subscriber 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. E.g. the subscription owner may be the parent, and the actual user of the UE could be a child of that parent.

Within the context of the present application, the term "mobile communication network" or short "network" may particularly denote a collection of nodes or entities, related transport links, and associated management needed for running a service, for example a telephony service, Internet access service, or a packet transport service. Depending on the service, different node types or entities may be utilized to realize the service. A network operator owns the communication network and offers the implemented services to its subscribers. Typical examples of a communication network are radio access network (such as 2G, GSM, 3G, WCDMA, CDMA, 4G, LTE, WLAN, Wi-Fi), mobile backhaul network, or core network such as IMS (IP Multimedia System), CS (Circuit Switched) Core, PS (Packet Switched) Core.

Within the context of the present application, the term "control node" refers to a node of the communication network primarily performing control procedures for sessions or calls and services of a subscriber of the communication network. The term typically refers to those entities of the communication network handling control plane, subscriber data, services, or signaling traffic associated with user traffic in the communication network. In a core network a control node may be a MSC (Mobile Switching Center), MME (Mobility Management Entity), SGSN (Serving Gateway Support Node), P-CSCF (Proxy Call State Control Function), S-CSCF (Serving-CSCF), or TAS (Telephony Application Server) node.

Within the context of the present application, the term "subscriber database" refers to a database run by the network operator to store the information related to the subscribers of a network run by the operator. A subscriber database can be for example a HLR (Home Location Register), or a VLR (Visited Location Register), or a HSS (Home Subscriber Server), or a combination of HLR and HSS. A subscriber database may also be internally structured into a front end part handling the signaling with the other network nodes of the communication network and a generic database for storage of the data according to data layered architecture principles.

Equipment identity or identity refers to an identifier being unique in the sense that the same identifier will not exist a second time. Even an equipment of the same type would show a different identifier. The identifier itself consists of numbers and/or letters. The identifier may be sub-structured and the different substructures can be separated for example by hyphens, dots, or spaces. It may be constructed of a serial number combined with a product and manufacturer identifier. Examples for equipment identities are the International Mobile Equipment Identity, IMEI, as defined in 3GPP. Another example of an identifier may be a Media Access Control (MAC) address, as

programmed into computer interface hardware for communications on the physical network segment. Another example of an identifier may be a Globally Unique Identifier, GUID, which is a unique reference number used as an identifier in computer software. The term GUID typically refers to various implementations of the UUID (Universally Unique Identifier) standard. Another example of an identifier may be a Unique Identifier, UDID, used in certain type of mobile phones. In general a UE may comprise several identifiers, some of which may be related to the hardware of the equipment and/or the interface hardware; others may be related to the operating system software of the equipment, or other key software components running on the equipment. Within the context of the present application, the term "MSC" refers to a control node of the circuit switched communication network, for example a MSC. The MSC may be combined with a Visited Location Register (VLR) and be therefore also called

MSC/VLR. The MSC node may also be enabled to control a remote Media Gateway (MGW) and therefore act as a server and may therefore be also called MSC Server or short MSC-S. Within the context of the present application MSC, MSC/VLR and MSC-S are functional equivalent.

Within the context of the present application, the term "HLR" refers a subscriber database of a circuit switched mobile communication network. The HLR may be combined with or may be integrated part of a Home Subscriber Server (HSS). Within the context of the present application, the term "fingerprint" may particularly refer to a short sequence of bytes used to represent or look up a longer set of

characteristics. Fingerprints are created by applying a cryptographic hash function to the set. Since fingerprints are shorter than the set they refer to, they can be used to simplify certain tasks such as comparison, detection of changes, or transfer via signaling. Fingerprints may also be referred to by the term "thumbprint" instead. A fingerprint is typically created through the following steps: · A set of characteristic, and optionally some additional data, is encoded into a

sequence of bytes. To ensure that the same fingerprint can be recreated later, the encoding is deterministic.

• The data produced in the previous step is hashed with a cryptographic hash

function such as MD5 or SHA-1 . · If desired, the hash function output can be truncated in a deterministic way to

provide an even shorter, more convenient fingerprint.

A fingerprint can be reproduced by using the same set of characteristics, the same hashing function, and the same truncation. The hash function ensures that a minimal change of the set of characteristics results into a significant change of the fingerprint. However, it is not possible to re-create the original set of from the fingerprint.

Now turning to the figures, Figure 1 shows a diagram illustrating a system for verifying a user of a UE.

A UE 100 connects to a mobile communication network and is handled by a control node 1 10. This control node 1 10 may be a MME, a SGSN, or a MSC. When roaming, the UE 100 may move between geographical areas served by different control nodes 1 10. Consequently, when roaming, there is a current control node 1 10 handling the UE 100 and a previous control node 130, previously handling the UE 100.

An interface between the previous control node 130 and the control node 1 10 is used to transfer data from the previous control node 130 to the current control node 1 10. This avoids that the control node 1 10 has to fetch sensitive data over the radio interface from the UE 100.

For example, the interface between two MSC nodes is called E-interface, between two MME nodes it is called S10 interface, between two SGSN nodes it is called Gn interface. The control node 1 10 (and in a similar way also the previous control node 130), has an interface to the subscriber database 120. The subscriber database 120 holds the subscriber related data and may be a HLR or a HSS. The subscriber database 120 is always located in the home network, while the control node 1 10 is selected based on the location of the UE 100, so may be in the home network as well, or abroad in a visited network.

In case the control node 1 10 does not know the previous control node 130 (e.g. due to the fact that it is belonging to a different operator or to a different country), the control node 1 10 could reach the previous control node 130 also via the subscriber database 120.

The UE 100 is connected to the control node 1 10 via a radio access network, RAN, which is not depicted in the figure for the sake of brevity.

Note that in the signalling flows below, for the sake of brevitiy, only messages and steps significant for the invention are presented, and there may be furher steps, checks and messages required in a real system.

Note that the following figures illustrate the invention using an embodiment based on CS control nodes MSC and CS subscriber database HLR. A further embodiment based on PS control nodes MME an PS subscriber database HSS is covered by figures 1 1 and further. Referring to Figure 2, this figure shows a signaling flow where a UE 100 roams into the area of a new MSC. This figure and also a number of following figures illustrate the inventive concept by showing CS-access and the MSC as control node 100.

The UE 100 roams from the previous MSC 130 into a geographical area controlled by MSC 1 10. When detecting this change of geographical area, the UE 100 initiates a Location Update 205 to the MSC 1 10. This Location Update 205 comprises the TMSI allocated to the UE 100 by the previous MSC 130, the current Location Area

Identification (LAI), and the previously used/old LAI.

In step 210 the MSC 1 10 tries to identify the subscriber by using the received TMSI by checking the old LAI. Since the old LAI does not belong to the MSC 1 10 (but to the previous MSC 130) the MSC 1 10 cannot identify the subscriber, so the subscriber is regarded as unknown and new in the MSC 1 10.

In this embodiment, a UE representation is based on a set of UE characteristics associated with the UE 100, and here the characterizing UE characteristics are the LAI, the TMSI, and the IMEI of the UE 100. In order to simplify the handling, in this embodiment the UE representation is a fingerprint derived on the above UE

characteristics. So based on the information received from the UE 100 at Location Update 205, the MSC 1 10 in step 215 determines a UE fingerprint based on a hash of the old LAI, the received TMSI, and the IMEI of the UE 100. This UE fingerprint represents the previous UE fingerprint base on an own calculation, since it uses the old LAI and the old TMSI of the previous MSC 130.

The procedure then continues with authentication 220 and ciphering 225 procedures as defined in the standards. During these procedures also a new TMSI is allocated to the UE 100. Since the UE 100 is new in the MSC 1 10, there is no previous UE fingerprint available in the MSC 1 10. So in step 230, the MSC 1 10 retrieves the previous UE fingerprint from the previous MSC 130. The MSC 1 10 may do this by directly contacting the previous MSC 130 (if the MSC 1 10 can directly address the previous MSC 130) or by going via the subscriber database, which in this embodiment is a HLR 120. The HLR 120 is aware of the currently serving MSC, and since the Location Update procedure toward the HLR 120 has not been initiated yet, the HLR 120 still considers the previous MSC 130 as the serving MSC. So the MSC 1 10 can reach the previous MSC 130 by going via the HLR 120. This is further explained in the figures 3 and 5 and will be handled further down. For the sake of this signaling flow, it can be assumed that step 230 successfully retrieves the previous UE fingerprint from the previous MSC 130.

At this point, the MSC 1 10 has two UE fingerprints available, the first one is the one based on the own fingerprint calculation using the data received from the UE 1 10 at Location Update 205, and the second one is the previous one as received from the previous MSC 130. ln step 235, the MSC 1 10 compares these two UE fingerprints. How this is done is detailed in figure 6 further down. Since the UE fingerprint is a short representation of the LAI + TMSI + IMEI, the value of the UE fingerprint reflects any change of any of these three parameters. So the comparison performed in step 235 reveals any mismatch or change of any of these three parameters.

In detail, the old LAI as received in the Location Update 205 from the UE 100 is compared with the value of the LAI as known in the previous MSC 130. A mismatch in the LAI would indicate that the Location Update 205 is coming from a different previous location. E.g. assuming that a malicious user gets hold of the original SIM card and produces a clone copy of the SIM, in this case the current LAI gets copied to the cloned SIM card. If then the original SIM is put back into the UE 100, the UE 100 would continue roaming and the LAI on the original SIM card is changed accordingly reflecting always the current LAI. The UE 100 also reports a change of the current LAI to serving MSC 1 10, so also the MSC 1 10 is up to date with the current LAI. However, the clone copy of the SIM will still contain an old value of the LAI. So if the cloned SIM card is taken into use by the malicious user, the LAI value stored thereon will not match anymore the LAI of the original SIM. So a change of the LAI can be used as a hint that the access is fraudulent.

Furthermore, the TMSI as received from the in the Location update 205 from the UE 100 is compared with the value of the TMSI as known in the previous MSC 130. Also the IMEI, so a hardware identity of the UE 100, is s compared with the value of the IMEI as known in the previous MSC 130. If not received from the UE 100 at Location update access, the MSC 1 10 will explicitly request the IMEI from the UE 100.

The combination of LAI + TMSI + IMEI is one possible set of UE characteristics associated with the UE 100, in alternative embodiments more UE characteristics may be utilized, or the set of UE characteristics may be limited to e.g. the IMEI only.

If the result of that comparison is ok, the sequence continues in step 240 with the MSC 1 10 initiating the Location Update procedure towards the HLR 120 by sending a Location Update Request message. This message may be a Mobile Application Part (MAP) message comprising also the IMEI of the UE 100. The HLR 120 will then send the subscriber data by using one or more MAP Insert Subscriber Data messages 245. Then the HLR concludes the Location update procedure by sending MAP Location Update Response message 250 to the MSC 1 10.

The registration in the previous MSC 130 is then canceled by the HLR 120 by sending a MAP Cancel Location message 255 to the previous MSC 130, which then confirms by sending a MAP Cancel Location Ack message 260 to the HLR 120.

Then in step 265 the MSC 1 10 determines the current UE fingerprint by calculating the hash based on the current LAI (the current geographical position area identification of the UE 100), the current TMSI (temporary subscription identification allocated by the MSC 1 10 to the UE), and the IMEI (hardware identity of the UE 100), and store it in a local memory of the MSC 1 10, such as the VLR. This stored value of the UE fingerprint is reused as previous UE fingerprint at the next access of the UE 100 to the MSC 1 10.

Finally in step 270 the MSC confirms the successful Location Update by sending a Location Update Accept message to the UE 100. The UE 100 then receives that Location Update Accept message 270 and the procedure is finished.

The messages between UE 100 and the MSC 1 10 may use the Direct Application Part, DTAP, or the Radio Access Network Application Part, RANAP. The messages between the MSC 1 10 and the HLR 120, and the HLR 120 and the previous MSC 130 may use MAP. Referring to Figure 3, this figure shows a signaling flow where a MSC retrieves a previous UE fingerprint via the HLR and the IMEI and PLNM is unchanged.

This flow is triggered by step 230 of figure 2. So the purpose is to retrieve the previous UE fingerprint from the previous MSC 130. The previous MSC 130 is identified by the MSC 100 checking the old LAI as received in the Location Update 205 from the UE 100. This flow is based on the assumption that the previous MSC 130 is unknown 305 or cannot be addressed by signaling from the MSC 1 10.

In this case the MSC 1 10 sends a message to the HLR 120 to fetch 310 the previous UE fingerprint. This may be a new MAP message, which is called here "Fetch Pass" 310. This may also be an existing message with modified data and/or purpose. This message may comprise the IMSI of the user as derived from the received TMSI and the IMEI of the UE 100 as received from the UE 100.

The HLR 120 receives the MAP Fetch Pass message 310. Since the HLR 120 receives the IMEI via Location Update messages or via Fetch Pass messages from the MSC 1 10, the HLR 120 is also able to detect changes of the IMEI. This is explained in more detail further down.

The HLR 120 is also able to detect whether the UE 100 has changed PLMN. This may be the case if the UE 100 has left the home PLMN towards a visited PLMN, or is roaming from one visited PLMN to a further visited PLMN (of the same or in a different country). The HLR 120 can detect a change of the PLMN by checking the address of the MSC 1 10 sending the Fetch Pass message and comparing it with the address of the MSC stored as serving MSC in the HLR 120.

If the IMEI has changed or if a change of the PLMN is detected in step 315, the signaling flow continues as shown in figure 4 and is described further down. The signaling flow in figure 3 assumes that neither the IMEI nor the PLMN have changed. So in step 320 the HLR 120 sends on the MAP Fetch Pass message to the previous MSC 130. The previous MSC is the MSC as stored as serving MSC in the HLR 120. The MAP Fetch Pass message to the previous MSC 130 comprises the IMSI in order to identify the concerned subscriber. The previous MSC 130 receives the MAP Fetch Pass message and uses the received IMSI to check the state of the subscriber and to retrieve the UE fingerprint from the local storage such as the VLR. In step 330 the previous MSC 130 returns the determined UE fingerprint and the determined subscriber state to the HLR 130 via a MAP Fetch Pass Result message 330. The HLR 130 receives that information and forwards it in step 335 to the MSC 1 10 in a MAP Fetch Pass Result message 335.

The MSC 1 10 receives the UE fingerprint and the subscriber state via the MAP Fetch Pass Result message 335. In step 340 the MSC 1 10 checks the received state of the subscriber. If the handling of the subscriber is still active in the previous MSC 130, e.g. if the user has an ongoing call or is involved in messaging activities, this is a strong indication that the Location Update request 205 is fraudulent, since a UE cannot be in active state in the previous MSC 130 and perform Location Update towards a new MSC 1 10 at the same time.

Therefore, if the subscriber is found to be in busy state in the previous MSC 130, in step 345 the MSC 1 10 sends a Location Update Reject to the UE 1 10. The access request of the UE 1 10 is considered fraudulent and is therefore rejected.

If the subscriber is found to be in idle state in the previous MSC 130, so the handling of the subscriber in the previous MSC 130 is not active, the execution continues with step 235 as described above for figure 2.

Referring to Figure 4, this figure shows a signaling flow where a MSC retrieves a previous UE fingerprint via the HLR and the IMEI or PLNM is changed.

The steps 305, 310, and 315 are identical to the corresponding steps in figure 3 and are shown here for clarity reasons. This flow now shows the case that the check 315 reveals that there is a change of the IMEI, or a change of the PLMN.

The HLR 120 may be configurable concerning when to consider the PLMN to be changed. This may be the case if the access request is received from a non-home (i.e. a visited) PLMN, so if the UE is roaming into a visited PLMN. This may not be the case if the UE roams from one visited PLMN to another visited PLMN, but both belong to the same country. This may be the case if the country of the PLMN changes, so if roaming from one foreign country to another foreign country. However, if returning back to the home PLMN, this may not be considered as a change.

So if the HLR 120 detects a change of the IMEI or a change of the PLMN, step 420 is triggered. Since in case the IMEI or the PLMN is changed, these are indications that the access request is fraudulent. In order to make sure that the access request is rightful, the user shall identify himself/herself as the rightful one by giving his user identification password.

The retrieval of the user identification password is triggered in step 420, the details of this procedure are depicted in figure 7 and are described further down.

In case the user identification password was not given correctly by the user, the HLR 120 continues with step 425 by returning a MAP Fetch Pass Result comprising an indication that the result is not ok. When receiving the MAP Fetch Pass Result message 425, the MSC 1 10 checks this result indication and since the result is indicated as not ok, the MSC 1 10 rejects the Location Update request by sending Location Update Reject message 430 to the UE 100.

In case the user identification password was given correctly by the user, the execution continues with step 320 as described above for figure 3.

Referring to Figure 5, this figure shows a signaling flow where a MSC retrieves a previous UE fingerprint directly from a previous MSC.

This flow is triggered by the step 230 of figure 2. So the purpose is to retrieve the previous UE fingerprint from a previous MSC 130. The previous MSC 130 is identified by the MSC 100 checking the old LAI as received in the Location Update 205 message from the UE 100. This flow is based on the assumption that the previous MSC 130 can be determined 505 and can be addressed directly by signaling from the MSC 1 10.

In this case the MSC 1 10 sends a MAP Send Identification message 510 to the previous MSC 130. The message comprises the IMSI of the subscriber concerned. The previous MSC 130 receives the MAP Send Identification message 510 and uses the received IMSI to check the state of the subscriber and to retrieve the UE fingerprint from the local storage such as the VLR. In step 520 the previous MSC 130 returns the determined UE fingerprint and the determined subscriber state to the HLR 130 via a MAP Send Identification Response message 520. The MSC 1 10 receives the UE fingerprint and the subscriber state via the MAP Send Identification Response message 520. In step 525 the MSC 1 10 checks the received state of the subscriber. If the handling of the subscriber is still active in the previous MSC 130, e.g. if the user has an ongoing call or is involved in messaging activities, this is a strong indication that the Location Update request 205 is fraudulent, since a UE cannot be in active state in the previous MSC 120 and perform Location Update towards a new MSC 1 10 at the same time.

Therefore, if the subscriber is found to be in busy state in the previous MSC 130, in step 530 the MSC 1 10 sends a Location Update Reject to the UE 1 10. The access request of the UE 1 10 is considered fraudulent and is therefore rejected. If the subscriber is found to be in idle state in the previous MSC 130, so the handling of the subscriber in the previous MSC 130 is not active, the execution continues with step 235 as described above for figure 2.

Referring to Figure 6, this figure shows a signaling flow on how to compare two UE fingerprints.

This signaling flow is called by step 235 of figure 2. In step 605 the determined previous UE fingerprint is compared versus the previous UE fingerprint as locally stored in the MSC (see figure 8), or as retrieved from the previous MSC 130 via the HLR 120 (see figure 3), or as retrieved from the previous MSC 130 directly (see figure 5). Since in a fingerprint is a short representation of a set of UE characteristics, this comparison may be a simple check for equality of bits of both UE fingerprints.

In case both UE fingerprints do not match, this is an indication that the access request of the UE 100 may be fraudulent. Therefore the MSC 1 10 sends a request to the HLR 120 to verify the user identification password. This may be done by sending a Verify Pass message 610 from the MSC 1 10 to the HLR 120 comprising the IMSI of the concerned subscriber. This Verify Pass message 610 may be a new MAP message.

In order to verify whether the access is rightful, the HLR retrieves 615 the user identification password from the user. This is shown in detail in figure 7 below.

In case the user identification password was not given correctly by the user, the HLR 120 continues with step 620 by returning a MAP Verify Pass Result message comprising an indication that the result is not ok. When receiving the MAP Verify Pass Result message 620, the MSC 1 10 checks the result indication and since the result is indicated as not ok, the MSC 1 10 rejects the Location Update request by sending Location Update Reject message 625 to the UE 100. The access request of the UE 1 10 is considered fraudulent and is therefore rejected.

In case the user identification password was given correctly by the user, the HLR 120 continues with step 630 by returning a MAP Verify Pass Result message comprising an indication that the result is ok and the execution continues with step 240 as described above for figure 2. Referring to Figure 7, this figure shows a signaling flow on how the HLR retrieves a user identification password from the user.

There may be various ways how to retrieve the user identification password from the user. The embodiment used in this signaling sequence is to utilize Unstructured Supplementary Service Data, USSD, procedures as define in 3GPP. USSD can be used as a network initiated procedure in order to retrieve user input in form of a text string.

So the procedure may be triggered by steps 420, 615, or 935. The HLR starts by sending a MAP USSD message 705 to the serving MSC 1 10 where the subscriber is currently registered. The MAP USSD message may comprise a text string that invites the user to type in his/her user identification password. Receiving the MAP USSD message, the MSC 1 10 forwards it to the UE 100, the text string being passed on transparently to the UE 100 by the MSC 1 10 in step 710. The UE 100 receiving the USSD message 710 will display the text string to the user, prompting him/her for a response string.

Then in step 715 the user will type in the user identification password. If supported by the UE 100, the USSD message may also launch a local application on the UE 100 that allows prompting the user for the password. In this case it is not needed to send a text string from the HLR 120, but an appropriate indication which application shall be launched by the UE 100. It is important to note that the intention is to really prompt the user to type the user identification password and not return any pre-stored value of the password stored on the UE 100 or stored on the SIM card. The malicious user would copy any user identification password stored on the SIM card when cloning it, so this would not provide any security. Also storing it on the UE will not be advisable, as the content of the UE store may also be part of such fraudulent cloning process.

After the user having typed in the user identification password, the UE 100 will return the user identification password as a text string in a USSD response message 720 to the MSC 1 10. The MSC 1 10 then forwards that text string to the HLR 120 in a MAP USSD Response 725. In the next step 730 the HLR 120 compares the received user identification password with a reference of the correct user identification password as stored in the HLR 120. The result may be that the user typed in the correct user identification password, or a mismatch. The execution then continues in the respective figures depending from where this procedure was called, steps 425, 620, or 940.

The reference of the correct user identification password may be set to an initial value by the network operator when selling the subscription. That initial value would then be passed to the user at purchase. The reference of the user identification password may also be changed by the user as shown in figure 10 below.

If the user types in the user identification password wrongly or does not provide any input within a certain time, the prompting of the user may be repeated for a limited number of times. Referring to Figure 8, this figure shows a signaling flow where the UE roams within the area of the MSC.

This flow is similar to the flow of figure 2, however in this case the UE 100 performs a Location Update after roaming to a further Location Area belonging to the same MSC 1 10, or a so called periodic Location Update, so when staying in the same Location Area as before. In this case the MSC 1 10 has the previous UE fingerprint available in the local storage, e.g. the VLR, and there is no need to retrieve the previous UE fingerprint from any previous MSC 130.

The UE sends in step 805 a Location Update message comprising the old LAI and the new LAI. The MSC 1 10 is then able in step 810 to identify the subscriber in the VLR based on the received TMSI and the old LAI is known in the MSC 1 10.

So based on the information received from the UE 100 at Location Update 805, the MSC 1 10 in step 815 determines a UE fingerprint based on a hash of the old LAI, the received TMSI, and the IMEI of the UE 100. This UE fingerprint represents the previous UE fingerprint base on an own calculation, since it uses the old LAI and the old TMSI of the previous access.

The procedure then continues with authentication 820 and ciphering 825 procedures as defined in the standards. During these procedures also a new TMSI may be allocated to the UE 100.

Since the UE 100 is known in the MSC 1 10, the previous UE fingerprint is already available in the MSC 1 10. So at this point, the MSC 1 10 has two UE fingerprints available, the first one is the one based on the own fingerprint calculation using the data received from the UE 1 10 at Location Update 805, and the second one is the one as from the previous access of the UE 100.

The execution then continues as described in step 235 of figure 2 above. Referring to Figure 9, this figure shows a signaling flow where there is no support by a visited MSC for checking the UE fingerprint, and therefore the HLR has to retrieve the user identification password.

The concept of verifying a user of a UE in a mobile communication network requires changes to the MSC 1 10/130 and the HLR 120. While the HLR 120 is always located in the home network, a network operator introducing this concept is in full control to upgrade the HLR 120 accordingly. However, MSC nodes being located outside of the home network are not under the control of that network operator, and support of that concept cannot be consistently assumed. This signaling flow sketches a case where the UE 100 roams into and area controlled by an MSC 150 which does not have any support for this new concept, and the HLR 120 would be the only node that supports that concept.

In step 905 the UE 100 sends a Location Update message to the MSC 150. The MSC 150 applies standard behavior and checks in step 910 whether the MSC 150 can identify the subscriber. In this scenario the subscriber is not known in the MSC 150. The procedure then continues with authentication 915 and ciphering 920 procedures as defined in the standards. During these procedures also a new TMSI may be allocated to the UE 100.

In step 925 the MSC 150 sends a MAP message Location Update Request to the HLR 120. In this case the MSC 150 will not add any IMEI to the message. The HLR 120 receives the MAP message Location Update Request, and from the fact that there is no IMEI included in the message, the HLR 120 can derive that the sending MSC 150 does not support the concept of verifying a user of a UE. However, based on the address of the MSC 150, the HLR can still determine whether the PLMN has changed or whether the UE 100 has roamed into a foreign country, as described above in step 315 above. However, since the HLR 150 has determined that support in the MSC 150 is missing, the HLR may apply stronger user identification password verification rules.

So for example in case the PLMN has changed, the HLR 120 decides that for security reasons the user shall be prompted to authorize this access by typing in his user identification password. This is done in step 935 and is detailed in figure 7 above. Note that the USSD method for transfer of the text string in figure 7 is a standard compliant procedure and does not require any changes to the MSC. The text string is forwarded transparently from the HLR 120 to the UE 100 by the MSC 150. In the same manner, the response string is forwarded transparently from the UE 100 to the HLR 120 by the MSC 150.

In case the user did not provide the correct user identification password, the HLR 120 rejects in step 940 the Location update by sending a MAP Location Update Reject message to the MSC 150. The MSC 150 then rejects the Location update towards the user as shown in step 945. In case the user typed in the correct user identification password, the Location Update procedure continues. The HLR 120 will then send the subscriber data by using one or more MAP Insert Subscriber Data messages 950. Then the HLR 120 concludes the Location update procedure by sending MAP Location Update Response message 955 to the MSC 150. The registration in the previous MSC 130 is then canceled by the HLR 120 by sending a MAP Cancel Location message 960 to the previous MSC 130, which then confirms by sending a MAP Cancel Location Ack message 965 to the HLR 120.

Finally in step 970 the MSC 150 confirms the successful Location Update by sending a Location Update Accpet message to the UE 100. The UE 100 then receives that Location Update Accpet message 970 and the procdure is finished.

This signalling flow shows that a basic level of user verification can be applied even if the visited MSC 150 does not support this concept.

The above figures illustrate the concpet of the invention based on an embodiment of a location update access request. Location update is a key traffic case since location update is the first procedure run by a UE when powered on, when roaming into a new network, and also periodically.

However, it is to be understood that the UE fingerprint, or rather the change of the UE fingerprint, may also be checked and detected at other traffic cases such as call establishment, short message handling, positioning, or supplementary service procedures. If a change of the UE fingerprint is detected, the traffic case may only be accepted after the user typing in the correct user identification password. Such a check at additional traffic cases may also subject to detailed configuration per traffic case by the network operator. The traffic cases may be grouped into different security levels and the operator may determine the security level to be applied depending on the general threat situation and/or on a per subscriber and/or a location base.

Referring to Figure 10, this figure shows a signaling flow for a change of the user identification password, initiated by the HLR, or the user.

As described above, the user identification password reference as stored in the HLR 120 may be set to an initial value by the operator. However, there must be a possibility for the user to change this user identification password reference stored in the HLR 120. Additionally, the network should be able to prompt the user to change the user identification password reference stored in the HLR 120. An embodiment of such a procedure to change the user identification password reference stored in the HLR 120 is shown in figure 10.

The procedure starts in step 1005, either by a trigger in the HLR 120 (step 1005b) or by the user requesting a change of the user identification password reference as stored in the HLR 120 (step 1005a).

The user may trigger this procedure in step 1005a, e.g. if he has revealed the password to someone else or he considers the user identification password to be unsecure or publicly disclosed. Or, at initial access after purchase of a new

subscription, the user wants to change to a user identification password that is easier for him/her to remember.

The HLR 120 may trigger this procedure in step 1005b, e.g. if a predefined threshold has been reached for a time period the reference of the user identification password has been in use. Or if a predefined threshold has been reached for a number of times the reference of the user identification password has been used for verification of the user. Or by alternative, if a change indication was received by the HLR 120 by operation and maintenance command from the operator. The time period threshold or the predefined threshold for the number of usages may also be different if the UE 100 is roaming in a foreign PLMN or in the home PLMN or country, or whether the currently serving MSC 1 10/150 supports the concept of user verification or not.

If the user triggers the change of the user identification password, he/she can do that for example as shown in step 1010 by requesting that on the UE 100, causing the UE 100 to send that request in a USSD message to the serving MSC 1 10/150. That request may take the form of a ^*#-code, e.g. ^*123#. Such ^*#-code are well known for example for checking the own prepaid account. The MSC 1 10/150 forwards that ^*#- code transparently to the HLR 120 in step 1015 by using a MAP USSD message. Since that USSD procedure is transparent for the MSC 1 10/150, this would work also in a MSC 150, which is not upgraded with support for the user verification concept. The HLR 120 receives the MAP USSD request for change of the user identification password in step 1015. This may trigger the change procedure started by step 1020. By alternative, the HLR 120 may trigger the start of this change procedure based on own events as described above.

So the change procedure is triggered in the HLR 120, and as a first step in 1020 the HLR 120 sends a USSD text string to the MSC 1 10/150. This text string could for example invite the user to type in the old and a new user identification password. The MSC 1 10/150 receiving that MAP USSD message will forward it to the UE 100 in step 1025.

The UE 100 receiving the USSD message will display the received text string and prompt the user to type in the old password (to verify that he is the rightful user) and a new user identification password, as shown in step 1030. As described above, instead of sending a text string, the HLR 120 may also trigger the launch of an appropriate application on the UE 100.

The input of the user is then sent to the MSC 1 10/150 in step 1035, and forwarded by the MSC 1 10/150 to the HLR 120 in step 1040. The HLR 120 then receives in step 1040 the old and the new user identification password. As a first check, the HLR 120 verifies that the user typed in the correct old user identification password by comparing it with the stored user identification password reference stored in HLR 120. In case the old user identification password was given correctly, the received new user identification password is stored in step 1050 as the new user identification password reference in the HLR 120. The HLR 120 may simply overwrite the previous reference user identification password, or may keep a history of previous user identification passwords in order to prevent that a previous user identification password is reused. If the old user identification password was not given correctly, it can be assumed that the user is not the rightful one and the HLR 120 deletes the registration in the MSC 1 10/150 by sending in step 1055 a MAP Cancel Location message to the MSC

1 10/150. Once the registration in the MSC 1 10/150 is canceled, the UE 100 will not be served anymore. In case the trigger to change the user identification password is coming from the HLR 120, the HLR 120 may first send a pre-warning to the user that a change of the user identification password is required. This may give the user somewhat more time to think of and decide on a new user identification password.

The above embodiment shows the principle of changing the user identification password using the HLR as an example. However, the general mechanism is applicable for other subscriber databases, e.g. for example a HSS subscriber database.

The subscriber database 120 may initiate a change of the reference of the user identification password. The subscriber database 120 may initiate the change of the reference of the user identification password based on a trigger received from the user.

The subscriber database 120 may initiate the change of the reference of the user identification password based on different triggers.

For example, such trigger may be a predefined threshold for a time period the reference of the user identification password has been in use. So there is a timer started each time the user identification password is set. If the time reaches a certain threshold, so the age of the user identification password reaches that threshold, a change of the user identification password is triggered.

For example, such trigger may be a predefined threshold for a number of times the reference of the user identification password has been used for verification of the user. So there is a counter stepped up each time the user identification password is used to verify the user of the UE 100. The counter is reset if the user identification password is set. If the counter reaches a certain threshold, a change of the user identification password is triggered.

For example, such trigger may be an indication received by the subscriber database 120 by operation and maintenance command. The operator may trigger a change of the user identification password by directing an appropriate command to the subscriber database 120. For example, the operator may obtain information that the user identification password has been publicly disclosed or the operator's customer care may have received a call from a user that he wants his user identification password to be changed. Then the operator may command the subscriber database 120 to trigger the change of the user identification password.

Furthermore, the subscriber database 120 may clear the UE representation stored in the control node 1 10 by sending a reset indication to the control node 1 10. That may be done by using an appropriate MAP or diameter message to the control node 1 10. The subscriber database 120 may do this for example based on an operation and maintenance command by the operator or based on a time threshold. The control node 1 10 may, when receiving that reset indication from the subscriber database 120, clear the stored UE representation. This may cause the next UE representation comparison (e.g. see figure 6, or 1550 of figure 15) to result into a UE representation mismatch. Referring to Figure 1 1 , this figure shows a signaling flow where a UE roams into a new MME area.

While the figures 2 to 10 above describe the embodiment of the invention where the control node is a MSC and the subscriber database is a HLR, the figures 1 1 and 12 show how the invention can be implemented if the control node is a MME and the subscriber database is a HSS. The UE 100 roams from the previous MME 130 into a geographical area controlled by the MME 1 10. The previous control node may also be a SGSN. When detecting this change of geographical area, the UE 100 initiates an Attach Request 1 105 to the MME 1 10. This Attach Request 1 105 comprises the Globally Unique Temporary UE Identity (GUTI) allocated to the UE 100 by the previous MME 130, the current Tracking Area Identification (TAI), and the previously used/old TAI.

In step 1 1 10 the MME 1 10 tries to identify the subscriber by using the received GUTI by checking the old TAI. Since the old TAI does not belong to the MME 1 10 (but to the previous MME 130) the MME 1 10 cannot identify the subscriber, so the subscriber is regarded as unknown and new in the MME 1 10.

Also in this embodiment, the UE representation is based on a set of UE characteristics associated with the UE 100, and here the characterizing UE characteristics are the TAI, the GUIT, and the IMEI of the UE 100. In order to simplify the handling, in this embodiment the UE representation is a fingerprint of the above UE characteristics. So based on the information received from the UE 100 at Attach Request 1 105, the MME 1 10 in step 1 1 15 determines a UE fingerprint based on a hash of the old TAI, the received GUIT, and the IMEI of the UE 100. This UE fingerprint represents the previous UE fingerprint base on an own calculation, since it uses the old TAI and the old GUTI of the previous MME 130. The procedure then continues with authentication 1 120 and ciphering 1 125 procedures as defined in the standards. During these procedures also a new GUTI is allocated to the UE 100.

Since the UE 100 is new in the MME 1 10, there is no previous UE fingerprint available in the MME 1 10. So in step 1 130, the MME 1 10 retrieves the previous UE fingerprint from the previous MME 130. The MME 1 10 may do this by directly contacting the previous MME 130 (if the MME 1 10 can directly address the previous MME 130) or by going via the HSS 120. The HSS 120 is aware of the currently serving MME 1 10, and since the Location Update procedure toward the HSS 130 has not been initiated yet, the HSS 120 still considers the previous MME 130 as the serving MME. So the MME 1 10 can reach the previous MME 130 by going via the HSS 120. This concept is further explained in the figures 3 and 5, based on the MSC and HLR embodiment; however the same principle is applied here for the MME and the HSS. Instead of using MAP signaling mechanisms, it is more conventional to used Diameter as a signaling mechanism between MME and HSS. However, the functional purpose of the signaling is the same.

For the sake of this signaling flow, it can be assumed that step 1 130 successfully retrieves the previous UE fingerprint from the previous MME 130.

At this point, the MME 1 10 has two UE fingerprints available, the first one is the one based on the own fingerprint calculation using the data received from the UE 1 10 at Attach Request 1 105, and the second one is the previous one as received from the previous MME 130. In step 1 135, the MME 1 10 compares these two UE fingerprints. How this is done is detailed in figure 6 above, also here referring to the MSC and HLR embodiment. The same principle is applied here for the MME and the HSS. Instead of using MAP signaling mechanisms, it is more conventional to used Diameter as a signaling mechanism between MME and HSS. However, the functional purpose of the signaling is the same.

Since the UE fingerprint is a short representation of the TAI + GUTI + IMEI, the UE fingerprint reflects any change of any of these three parameters. So the comparison performed in step 1 135 reveals any mismatch or change of any of these three parameters. The combination of TAI + GUTI + IMEI is one possible set of UE characteristics associated with the UE 100, in alternative embodiments more UE characteristics may be utilized, or the set of UE characteristics may be limited to the IMEI only.

If the result of that comparison is ok, the sequence continues in step 1 140 with the MME 1 10 initiating the Location Update procedure towards the HSS 120 by sending a Location Update Request message. This message may be a Diameter based message comprising also the IMEI of the UE 100.

Then the HSS 120 concludes the Location Update procedure by sending Diameter message Location Update Response message 1 145 to the MME 1 10. This message also comprises the subscriber data of the subscriber for local storage in the MME 1 10. The registration in the previous MME 130 is then canceled by the HSS 120 by sending a Diameter Cancel Location message 1 150 to the previous MME 130, which then confirms by sending a Diameter Cancel Location Ack message 1 155 to the HSS 120.

Then in step 1 160 the MME 1 10 determines the current UE fingerprint by calculating the hash based on the current TAI (the current geographical position area identification of the UE 100), the current GUTI (temporary subscription identification allocated by the MME 1 10 to the UE 100), and the IMEI (hardware identity of the UE 100), and store it in a local memory of the MME 1 10. This stored value of the UE fingerprint is reused as previous UE fingerprint at the next access of the UE 100 to the MME 1 10. Finally in step 1 165 the MME 1 10 confirms the successful attach by sending an Attach Accept message to the UE 100. The UE 100 then receives that Attach Accept message 1 165 and the procedure is finished. Note that the Attach Accept message may be combined with an initial context setup request to the UE 100.

The function of a previous MME/SGSN 130 in figure 1 1 , the previous MSC 130 of figure 3 and figure 5, is typically combined into the function of the control node (i.e.

MSC 1 10 and MME/SGSN 1 10). So a control node can, depending on the traffic case, act as a control node 1 10 or as a previous control node 130.

From the point of view of the previous control node 130, the previous control node 130 may receive a request to provide the UE representation. This request may be received from a control node 1 10 directly, or via the subscriber database 120.

So the previous control node 130 may send, on request, the UE representation to a further control node 1 10. Or the previous control node 130 may send, on request, the UE representation to the subscriber database 120.

The response to such a request may comprise additional data. For example the control node 130 may indicate in the response whether the handling of the UE 100 is still active in the control node 130. For example, the handling of the UE 100 is still active in the control node 130 if there is still a call ongoing, an SMS handling ongoing, a positioning request pending, a supplementary service procedure ongoing, or a packet session still ongoing. From the point of view of the subscriber database 120, the subscriber database 120 receives a request to provide the UE representation. The subscriber database 120 retrieves the UE representation from a previous control node 130 most recently handling the UE 100, if being requested to provide the UE representation. The subscriber database 120 stores the address of the control node handling the UE, so if being requested to provide the UE representation, the subscriber database 120 may look up that information. Then the subscriber database 120 receives and stores the UE representation, as received from the previous control node 130.

Referring to Figure 12, this figure shows a signaling flow where a HSS retrieves a user identification password via a temporary APN and a landing web page.

When using a packet access, there is an alternative embodiment to retrieve the user identification password, which is shown in figure 12. The signaling flow is the same as for figure 1 1 for steps up to step 1 135, so the MME 1 10 is comparing the two UE fingerprints, the first one is the one based on the own fingerprint calculation using the data received from the UE 1 10 at Attach Request 1 105, and the second one is the previous one as received from the previous MME 130.

In case of a mismatch of the two UE fingerprints the HSS 120 has to retrieve and verify the user identification password. In step 1205 the MME sends a Location Update Request message to the HSS 120. This message may comprise the IMEI of the UE 100 and/or an indication that a verification of the user identification password is required.

Receiving the IMEI, the HSS 120 may perform checks whether the IMEI has changed as described above for the HLR. The HSS 120 may also check whether the UE 100 has roamed into another PLMN or a foreign PLMN as described above for the HLR. If the HSS 120 has to verify the user identification password, the HSS 120 sends in step 1210 a Location Update Response comprising a specific security Access Point Name (APN) and a specific Packet Gateway (P-GW) 140 address. This Location Update Response may also comprise an initial set of subscriber data.

The MME 1 10 receives the Location Update Response message 1210 and responses in step 1215 an Attach Accept message combined with an Initial Context Setup

Request to the UE100. That message comprises the APN and the address of the P- GW 140. This P-GW 140 may be combined with a Security Bootstrap Server offering a first landing web page which is shown to the UE 100 at first access. Such a web page can then be used to prompt the user to type in his/her user identification password. So receiving the Initial Context Setup Request in step 1215 the UE 100 establishes an Evolved Packet System (EPS) session towards the P-GW 140 in step 1220.

In step 1225 the user is prompted for the user identification password and the result is received by the P-GW 140. The received user identification password is then passed by the P-GW to the HSS 120.

In the next step 1235 the HSS 120 compares the received user identification password with a reference of the correct user identification password as stored in the HSS 120. The result may be that the user typed in the correct user identification password or a mismatch.

In case the user provided the correct user identification password, the HSS 120 in step 1240 sends an update of the subscriber data to the MME 1 10. These subscriber data then comprise an new APN, a so called traffic APN, that can be used but the UE 100 for packet access, e.g. to the Internet. Also a new P-GW address may be provided, corresponding to the traffic APN

In step 1245 the MME 1 10 requests the UE 100 to setup a new context to the traffic APN as indicated by the HSS 120. A new EPS session is then established. Then in step 1250 the MME 1 10 determines the current UE fingerprint by calculating the hash based on the current TAI (the current geographical position area identification of the UE 100), the current GUTI (temporary subscription identification allocated by the MME 1 10 to the UE 100), and the IMEI (hardware identity of the UE 100), and store it in a local memory of the MME 1 10. This stored value of the UE fingerprint is reused as previous UE fingerprint at the next access of the UE 100 to the MME 1 10.

In case the user did not provided the correct user identification password, so in case of a mismatch, the HSS 120 in step 1255 sends a Cancel Location message to the MME 1 10. The MME 1 10 receives that Cancel Location message 1255 and sends in step 1260 a Detach Request to the UE 100, indicating that a reattach is not wanted. The UE 100 has to accept the Detach Request and responses in step 1265 with a Detach Accept message to the MME 1 10. The MME 1 10 then replies a Cancel

Location Answer message to the HSS 120 in step 1270. This results into the UE 100 being detached without permission to try a re-attach, and the MME having removed any subscriber related data from the local storage. The UE 100 does not receive any service anymore.

Referring to Figure 13, this figure shows a flow diagram in a control node. The control node may be a MSC 1 10 or a MME 1 10 as shown in the figures 1 to 12.

The flow starts in step 1300 when the control node 1 10 receives an initial request message from the UE 100. This initial request may correspond to a received

RANAP/DTAP message, indicating an initial request. Examples for such initial request may be a Location Update message, or a setup request for a call, a short message, a positioning request, or a response to a paging message. This initial request may by alternative correspond to a received S1 Application Part message, indicating an initial request. Examples for such initial request may be an Attach request, context transfer request, mobility functions for the UE 100, or a paging response.

The flow continues in step 1310 by checking whether the UE representation matches a previous value. The UE representation may be a UE fingerprint derived by a

cryptographic hash function applied on the set of UE characteristics. The set of UE characteristics may comprises one or more of, a geographical position area

identification of the UE 100 (such as the LAI or TAI), a temporary subscription identification (such as a GUTI or TMSI), and a hardware identity of the UE 100 (such as an IMEI).

If the UE representation matches a previous value, so the check results into a "yes", the flow continues with step 1330 by proceeding with handling of the received initial request message. Then the flow ends.

The control node 1 10 may fetch the previous value of the UE representation from a previous control node 130 most recently handling the UE 100. By alternative the control node 1 10 may fetch the previous value of the UE representation from a previous control node 130 via the subscriber database 120. If the UE representation does not matches a previous value, so the check results into a "no", the flow continues with step 1340 by causing the subscriber database 120 to verify the user of the UE 100.

The causing the subscriber database 120 to verify the user of the UE 100, may comprise sending a request to the subscriber database 120 to verify the user identification password.

The result of the verification of the user of the UE 100 is checked in step 1350. If the user provided the correct user identification password, so the answer is "ok", the flow continues with step 1330 by proceeding with handling of the received initial request message. Then the flow ends.

If the user provided a wrong user identification password, or no password in time, so the answer is "not ok", the flow continues with step 1360 by rejecting the received initial request. Then the flow ends.

The control node 1 10 may reject also the initial request message from the UE 100 in case the handling of the UE 100 is still active in the previous control node 130.

Referring to Figure 14, this figure shows a flow diagram in a subscriber database. The subscriber database may be a HLR 120 or a HSS 120 as shown in the figures 1 to 12.

The flow starts in step 1400 when the subscriber database 120 receives a request to verify the user of the UE 100. This request may be received from a control node 1 10. The flow continues in step 1410 by causing the user to type in his user identification password. This may comprise to send a prompt to the user to type in his/her user identification password. This may result in receiving the user identification password from the user.

In the next step 1420 the subscriber database 120 verifying the user of the UE 100 by comparing the received user identification password with a reference. This reference may be stored in the subscriber database 120.

If the received user identification password matches a reference, so the check results into a "yes", the flow continues with step 1440 by returning a result indicating "ok". Then the flow ends. If the received user identification password does not match a reference stored in the subscriber database 120, so the check results into a "no", the flow continues with step 1450 by returning a result indicating "not ok". Then the flow ends.

Referring now to Figure 15, this figure shows a schematic block diagram illustrating a control node embodiment. The control node may be a MSC 1 10/130 or a MME 1 10/130 as shown in the figures 1 to 12 and the control node 1 10/130 may be adapted to perform a method according to figure 13. The control node may also be a virtual network function, VNF, e.g. instantiated by a VNF manager.

The control node may comprise a number of functional units, which are described in further detail below and which are adapted to perform respective method steps.

A processing unit 1500 of the control node may be adapted to execute steps for verifying a user of a UE 100. The processing unit 1500 may handle an initial request message from the UE 100, and may check whether the UE representation matches a previous value. The processing unit 1500 may further cause, in case the UE representation does not match a previous value, the subscriber database 120 to verify the user of the UE 100. The processing unit 1500 may proceed with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value. These steps may also be performed in cooperation with the other functional elements of the control node shown in figure 15. In a practical implementation the processing unit 1500 may be one processor taking care of all the above functions, or may also be distributed over more than one processor, wherein the functions are distributed over the available processors.

The control node may further comprise a sending unit 1510 and a receiving unit 1520 via which the control node can communicate with other network entities such as the UE 100, the subscriber database 120, or a further entity of a control node, e.g. a previous control node 130. If acting as previous control node 130, the previous control node 130 may communicate with the control node 1 10. The sending unit 1510 may send out signaling messages composed by the processing unit 1500. The receiving unit 1520 may receive signaling messages from those external entities above and forward the received signaling messages to the processing unit 1500 for decoding and/or dispatching. The control node may also comprise a storing unit 1530 for storing information related to verification of a user of a UE 100. The storing unit 1530 may store a UE

representation, which may be a UE fingerprint derived by a cryptographic hash function applied on the set of UE characteristics. The set of UE characteristics may comprise one or more of, a geographical position area identification of the UE 100, a temporary subscription identification, and a hardware identity of the UE 100. The storing unit 1530 may be a pure software functional module such as a SQL database software module. The storing unit 1530 may also have access to and/or use a centralized storage (e.g. a Network Attached Storage, NAS). The storing unit 1530 may comprise various types of memory such as volatile memory, non-volatile memory, hard disk drives, solid state drives, a network interface to a database or a data center, secure digital cards, or hardware such as smart cards, non-reversible chips, security chips, security modules, or trusted platform module devices. The storing unit 1530 may be used by the processing unit 1500 to store information, for example program code or data related to control node tasks.

The control node may further comprise a UE representation handler 1540. The UE representation handler 1540 may generate a UE fingerprint based on a set of UE characteristics. This may be done by applying a cryptographic hash function on the set of UE characteristics. The set of UE characteristics may comprise one or more of, a geographical position area identification of the UE 100, a temporary subscription identification, and a hardware identity of the UE 100. The UE representation handler 1540 may perform this task in cooperation with the processing unit 1500 and further use the storing unit 1530 to store the resulting UE fingerprint.

The control node may further comprise a matching unit 1550. The matching unit 1550 compares two UE representations and checks if the two match. As described above, the UE representation may be a UE fingerprint based on above set of UE

characteristics. When requested to perform a check for match, the matching unit 1550 may perform a bit match check on the input UE representations and returns a positive result in case of a full match, or a failure indication in case of mismatch. The matching unit 1550 may perform this task in cooperation with the processing unit 1500 and further use the storing unit 1530 to fetch the UE representations and to store the result.

Referring to Figure 16, this figure shows a schematic block diagram illustrating a subscriber database. The subscriber database may be a HLR 120 or a HSS 120 as shown in the figures 1 to 12 and the subscriber database may be adapted to perform a method according to figure 14. The subscriber database may also be a virtual network function, VNF, e.g. instantiated by a VNF manager.

The subscriber database may comprise a number of functional units, which are described in further detail below and which are adapted to perform respective method steps.

A processing unit 1600 of the subscriber database may be adapted to execute steps for verifying a user of a UE 100. The processing unit 1600 may handle a request to verify the user of the UE 100. The processing unit 1600 may also cause the user to type in his/her user identification password and verify the user of the UE 100 by comparing the user identification password with a reference. The reference may be a locally stored reference of the user identification password. These steps may also be performed in cooperation with the other functional elements of the control node shown in figure 16.

In a practical implementation the processing unit 1600 may be one processor taking care of all the above functions, or may also be distributed over more than one processor, wherein the functions are distributed over the available processors.

The subscriber database may further comprise a sending unit 1610 and a receiving unit 1620 via which the subscriber database can communicate with other network entities such as the control node 1 10/130, either acting as the control 1 10 or acting as a previous control node 130. The sending unit 1610 may send out signaling messages composed by the processing unit 1600. The receiving unit 1620 may receive signaling messages from those external entities above and forward the received signaling messages to the processing unit 1600 for decoding and/or dispatching.

The subscriber database may also comprise a storing unit 1630 for storing information related to verification of a user of a UE 100. The storing unit 1630 may store a subscription profile for the user and a reference of the user identification password. The storing unit 1630 may be a pure software functional module such as a SQL database software module. The storing unit 1630 may also have access to and/or use a centralized storage (e.g. a Network Attached Storage, NAS). The storing unit 1630 may comprise various types of memory such as volatile memory, non-volatile memory, hard disk drives, solid state drives, a network interface to a database or a data center, secure digital cards, or hardware such as smart cards, non-reversible chips, security chips, security modules, or trusted platform module devices. The storing unit 1630 may be used by the processing unit 1600 to store information, for example program code or data related to subscriber database tasks.

The subscriber database further comprises a user password handler 1640. The user password handler 1640 may cause the user to type in his/her user identification password for example by sending a prompting message or text string or by causing the display of an appropriate window / web page with a prompting window on the UE display. The user password handler 1640 may also be adapted to receive the user identification password from the user and to compare it with a reference. The reference may be a reference user identification password, which may be stored locally in the subscriber database. By alternative the user identification password may also be transmitted from the user in encrypted format or as a fingerprint value. The comparison is then done against a fingerprint of the reference user identification password, or the transmitted user identification password is decrypted first before such comparison is done. The user password handler 1640 may perform these tasks in cooperation with the processing unit 1600, the sending unit 1610 and receiving unit 1620.

The subscriber database may also comprise a PLMN / IMEI matching unit 1650. The PLMN / IMEI matching unit 1650 may receive an IMEI of a UE 100. Based on an IMEI received previously, the subscriber database may determine whether the IMEI has changed, which is an indication that the actual UE 100 has changed. This may be caused by the user removing his SIM card from the previous UE (it may be broken, outdated, or simply out of power) and inserts it into a further UE. However, the IMEI change may also hint at a malicious access request.

The PLMN / IMEI matching unit 1650 may receive an address of a control node 1 10 handling the UE 100. Based on the control node address, it is possible to derive the PLMN of the requesting control node. Based on an previous value of the PLMN, the PLMN / IMEI matching unit 1650 may determine whether the access request is received from a non-home (i.e. a visited) PLMN, so if the UE has roamed into a visited PLMN. Or the UE may roam from one visited PLMN to another visited PLMN, but both belonging to the same country. Or the country of the PLMN may change, so roaming from one foreign country to another foreign country. Or the PLMN / IMEI matching unit 1650 may determine the UE returning back to the home PLMN. For these cases the PLMN / IMEI matching unit 1650 may determine whether to verify the user of the UE and trigger the user password handler 1640 accordingly. The PLMN / IMEI matching unit 1650 may user the storing unit 1630 for storing the previous PLMN and/or IMEI.

According to another embodiment, a computer program is provided. The computer program may be executed by the processing units 1500 and/or 1600 of the above mentioned entities 1 10, 130 and/or 120 respectively such that a method for verifying a user of a UE 100 as described above with reference to Figures 13 or 14 may be carried out or be controlled. In particular, the entities 1 10, 130 and/or 120 may be caused to operate in accordance with the above described method by executing the computer program. The computer program may be embodied as computer code, for example of a computer program product. The computer program product may be stored on a computer readable medium, for example a disk or the storing unit 1530 and/or 1630 of the entities 1 10, 130 and/or 120, or may be configured as downloadable information.

One or more embodiments as described above may enable at least one of the following technical effects: solves the problem related to the fact that fraudulent/malicious mobiles cannot be identified and rejected when they are attempting to access the network

• inform the operators about UEs using cloned SIM cards and usage by non- authorized users protect rightful users against extra costs in cases fraudulent users are using cloned SIM cards or against legal consequences in case malicious users are using cloned SIM cards to perform illegal actions

Modifications and other embodiments of the disclosed invention will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiments are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1 . A method for verifying a user of a user equipment, UE (100), in a mobile

communication network comprising a control node (1 10) and a subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the method comprising:

• receiving (1300), by the control node (1 10), an initial request message from the UE (100);

• checking (1310), by the control node (1 10), whether the UE representation matches a previous value;

• verifying, by the subscriber database (120) in case the UE representation does not match the previous value, the user of the UE (100) by retrieving the user identification password from the user and comparing it with a reference;

• proceeding (1330), by the control node (1 10), with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

2. The method according to claim 1 , wherein the UE representation is a UE fingerprint derived by a cryptographic hash function applied on the set of UE characteristics.

3. The method according to any of the claim 1 or 2, wherein the set of UE

characteristics comprises one or more of, a geographical position area

identification of the UE (100), a temporary subscription identification, and a hardware identity of the UE (100).

4. The method according to any of the claim 1 to 3, the method further comprising:

• fetching, by the control node (1 10), the previous value of the UE representation from a previous control node (130) most recently handling the UE (100).

5. The method according to claim 4, wherein the control node (1 10) fetches the previous value of the UE representation from the previous control node (130) via the subscriber database (120).

6. The method according to any of the claims 4 or 5, wherein the previous control node

(130) indicates in the response whether the handling of the UE (100) is still active in the previous control node (130).

7. The method according to claim 6, wherein the control node (1 10) rejects the initial request message from the UE (100) in case the handling of the UE (100) is still active in the previous control node (130).

8. The method according to any of the preceding claims, the method further

comprising:

• sending, by the control node (1 10), a request to the subscriber database (120) to verify the user identification password.

9. The method according to any of the preceding claims, wherein verifying, by the subscriber database (120), the user of the UE (100) by retrieving the user identification password from the user comprises:

• causing, by the subscriber database (120), the user to type in his user

identification password.

10. The method according to any of the preceding claims, wherein verifying, by the subscriber database (120), the user of the UE (100) by retrieving the user identification password from the user comprises:

• receiving, by the subscriber database (120), the user identification password.

1 1 . The method according to any of the preceding claims, wherein the control node (1 10) rejects the initial request message from the UE (100) in case the verification of the user of the UE (100) failed.

12. The method according to any of the preceding claims, the method further

comprising: • initiating, by the subscriber database (120), a change of the reference of the user identification password.

13. The method according to claim 12, wherein the subscriber database (120) initiates the change of the reference of the user identification password based on a trigger received from the user.

14. The method according to claim 12 or 13, wherein the subscriber database (120) initiates the change of the reference of the user identification password based on at least one of:

• a predefined threshold for a time period the reference of the user identification password has been in use;

• a predefined threshold for a number of times the reference of the user

identification password has been used for verification of the user; and

• an indication received by operation and maintenance command.

15. The method according to any of the preceding claims, wherein the subscriber

database (120) clears the UE representation stored in the control node (1 10) by sending a reset indication to the control node (1 10).

16. The method according to claim 15, wherein on instruction by operation and

maintenance command the subscriber database (120) clears the UE

representation stored in the control node (1 10).

17. A method in a control node (1 10) for verifying a user of a user equipment, UE (100), in a mobile communication network comprising the control node (1 10) and a subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the method comprising:

• receiving (1300) an initial request message from the UE (100);

• checking (1310) whether the UE representation matches a previous value; • causing (1340), in case the UE representation does not match a previous value, the subscriber database (120) to verify the user of the UE (100);

• proceeding (1330) with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

18. The method according to claim 17, wherein the UE representation is a UE

fingerprint derived by a cryptographic hash function applied on the set of UE characteristics.

19. The method according to any of the claim 17 or 18, wherein the set of UE (100) characteristics comprises one or more of, a geographical position area

20. The method according to any one of the claims 17 to 19, the method further

comprising:

• fetching the previous value of the UE representation from a previous control node (130) most recently handling the UE (100).

21 . The method according to claim 20, wherein the control node (1 10) fetches the

previous value of the UE representation from a previous control node (130) via the subscriber database (120).

22. The method according to any of the claims 20 or 21 , wherein the previous control node (130) indicates in the response whether the handling of the UE (100) is still active in the previous control node (130).

23. The method according to claim 22, wherein the control node (1 10) rejects the initial request message from the UE (100) in case the handling of the UE (100) is still active in the previous control node (130).

24. The method according to any of the claims 17 to 23, wherein causing the

subscriber database (120) to verify the user of the UE (100), comprises: • sending a request to the subscriber database (120) to verify the user identification password.

25. The method according to any of the claims 17 to 24, wherein the control node (1 10) rejects the initial request message from the UE (100) in case the verification of the user of the UE (100) failed.

26. The method according to any of the claims 17 to 25, the method further comprising:

• receiving a request to provide the UE representation.

27. The method of claim 26, further comprising:

• sending, on request, the UE representation to a further control node (1 10).

28. The method of claim 26, further comprising:

• sending, on request, the UE representation to the subscriber database (120).

29. The method according to any of the claims 26 to 28, wherein the control node (130) indicates in the response whether the handling of the UE (100) is still active in the control node (130).

30. A method in a subscriber database (120) for verifying a user of a user equipment, UE (100), in a mobile communication network comprising a control node (1 10) and the subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the method comprising:

• receiving (1400) a request to verify the user of the UE (100);

• causing (1410) the user to type in his user identification password, and

• verifying (1420) the user of the UE (100) by comparing the user identification password with a reference.

31 . The method according to claim 30, further comprising:

• receiving the user identification password from the user.

32. The method according to claims 30 or 31 , wherein the subscriber database (120) verifies the user of the UE (100) at least if:

• the subscriber database (120) receives a request from a control node (1 10) located in a foreign Public Land Mobile Network, PLMN;

• the subscriber database (120) receives a request from a control node (1 10) located in a PLMN different than the previous PLMN;

• the subscriber database (120) receives a request and the UE representation does not match a previous value; or

• the UE (100) attaches to the network for the first time.

33. The method according to any of the claims 30 to 32, the method further comprising

• initiating, by the subscriber database (120), a change of the reference of the user identification password.

34. The method according to claim 33, wherein the subscriber database (120) initiates the change of the reference of the user identification password based on a trigger received from the user.

35. The method according to claim 33 or 34, wherein the subscriber database (120) initiates the change of the reference of the user identification password based on at least one of:

• a predefined threshold for a number of times the reference of the user

identification password has been used for verification of the user; and

• an indication received by the subscriber database (120) by operation and

maintenance command.

36. The method according to any of the claims 30 to 35, wherein the subscriber database (120) clears the UE representation stored in the control node (1 10) by sending a reset indication to the control node (1 10).

37. The method according to claim 36, wherein the subscriber database (120) clears the UE representation stored in the control node (1 10) if receiving an indication by operation and maintenance.

38. The method according to any of the claims 30 to 37, the method further comprising:

• receiving a request to provide the UE representation.

39. The method according to claim 38, wherein the subscriber database (120) retrieves the UE representation from a previous control node (130) most recently handling the UE (100), if being requested to provide the UE representation.

40. The method according to any of the claims 30 to 39, wherein the subscriber

database (120) receives and stores the UE representation.

41 . The method according to any of the claims 30 to 40, the method further comprising:

• checking whether the UE representation matches a previous value.

42. A control node (1 10) for verifying a user of a user equipment, UE (100), in a mobile communication network comprising the control node (1 10) and a subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the control node (1 10) being capable of:

• receiving (1300) an initial request message from the UE (100);

• checking (1310) whether the UE representation matches a previous value;

• causing (1340), in case the UE representation does not match a previous value, the subscriber database (120) to verify the user of the UE (100); • proceeding (1330) with handling of the received initial request message, in case of successful user verification or in case the UE representation matches the previous value.

43. The control node (1 10) according to claim 42, wherein the control node (1 10) is adapted to perform a method according to any one of the claims 17 to 29.

44. The control node (1 10) according to claim 42 or 43, wherein the control node (1 10) stores the UE representation.

45. The control node (1 10) according to claim 42 to 44, wherein the control node (1 10) is one of a Mobility Management Entity, MME, a Mobile Switching Center, MSC, or a Serving General Packet Radio Service Support Node, SGSN.

46. A subscriber database (120) for verifying a user of a user equipment, UE (100), in a mobile communication network comprising a control node (1 10) and the subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the subscriber database (120) being capable of:

• receiving (1400) a request to verify the user of the UE (100);

• causing (1410) the user to type in his user identification password, and

47. The subscriber database (120) according to claim 46, wherein the subscriber

database (120) is adapted to perform a method according to any one of the claims 30 to 41 .

48. The subscriber database (120) according to claim 46 or 47, wherein the subscriber database (120) stores the reference of the user identification password.

49. The subscriber database (120) according to any of the claims 46 to 48, wherein the subscriber database (120) stores a hardware identity of the UE (100).

50. The subscriber database (120) according to any of the claims 46 to 49, wherein the subscriber database (120) is one of a Home Location Register, HLR, or a Home Subscriber Server, HSS.

51 . A system for verifying a user of a user equipment, UE (100), in a mobile

communication network comprising a control node (1 10) and a subscriber database (120), wherein a user identification password is associated with a user of the UE (100), and a UE representation based on a set of UE (100) characteristics is associated with the UE (100), the system comprising:

• the control node (1 10) according to claims 42 to 45;

• the subscriber database (120) according to claims 46 to 50; and

• the UE (100).

52. A computer program, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any one of claims 1 to 41 .

53. A computer program product comprising a computer program according to claim 52.

54. A carrier containing the computer program product of claim 53, wherein the carrier is one of an electrical signal, optical signal, radio signal, magnetic tape or disk, optical disk, memory stick, or paper.