Managing undesired service requests in a network

[0001] The invention relates to the management of unwanted service requests in a network, especially, but not limited to, a method and system for managing unwanted service requests in a network, a user verification function and a terminal for use in this system and a computer program product to perform this method.

Background of the invention [0002] New generation mobile devices, such as smartphones, have more computer functions through open network connections. Such mobile devices are able e.g. to receive e-mails, share programs with each other through short-range connections, download and execute software from the Internet, make automatic connections and operate in accordance with remote control. Hence, like a personal computer, mobile devices, especially software components that work when establishing a mobile device's connection to the network, are susceptible to malicious code (malware) attacks. Usually, the malware attempts to abuse the mobile device or simply disorganize the authorized use of the mobile device. A microprocessor card that may be present in a mobile device, e.g. (U) SIM, does not provide protection to prevent this possibility.

[0003] One type of malware is referred to as dialers (devices for automatically dialing programmed numbers, hereinafter referred to as dialers). Dialers are positions of malicious code capable of making illegal connections on an infected mobile device. Such dialers often use verification information from the (U) SIM card of a mobile device to access the network as if the connection had been established by the user of the mobile phone. After the verification procedure, the dialer begins to establish connections, e.g. expensive special connection numbers, often undetectable to the user of the infected mobile device, leading to significant financial risk for both the user and the operator of the mobile phone.

[0004] Action can be taken to eliminate or at least reduce the undesirable effects of such malware. One of the known actions is introducing the filter to the network. Such filters are described in WO2007 / 041157 and US2005 / 0060399. The filter placed in the base station monitors the connections transmitted from the mobile device and blocks the blacklisted connections. The network operator and / or mobile device user can add service requests to the blacklist that should be explicitly excluded by the filter.

[0005] One problem with using such a filter is managing the list of excluded service requests. There are three problems for the operator. The first problem is that blocking all unwanted service requests can cause

- that the size of the necessary blacklist can become very large and almost impossible to manage. The second problem is that it is necessary to constantly search for malicious services so that the blacklist is constantly up to date. The third problem is that the identification of suspicious requests requires an analysis of the service requests of each individual user of the mobile device. Therefore, such analyzes require significant resources on the network. There is a problem for the user of the mobile device that unwanted requests for the mobile device service are usually unnoticed by the user and detected only after the billing, i.e. after the damage has been done. Another problem for the user may arise because of the operator's blacklisting of services that the user wants to use.

[0006] US2008 / 0196099 discloses a method of filtering URL (Uniform Resource Locator) within IM (Instant Messaging). If the IM message contains a URL, the URL is checked in the blacklist of known malicious URLs. When the URL is not blacklisted, the sender gets the task of confirming that the sender is a real user, not a program (malware). This protects recipients from receiving IM messages containing a malicious URL. In addition, the system may be configured to maintain an "allow list" or "white list" of known malicious URLs. In this way, an IM message containing a URL from the "white list" can be forwarded to the recipient without notifying the sender.

[0007] This method is undesirable from both a security and customer point of view when used in the context of a mobile phone. From a security perspective, the method of US2008 / 0196099 does not provide any ready solution to the problem, because it is not the content of the connection that is the threat, but the purpose, e.g. special call numbers for text messages (SMS). Therefore, the described method tries to protect the recipient, not the sender. This method is also a nuisance for the sender, since the sender will be verified with every IM message containing a URL that is not on the blacklist (or whitelist). When the sender (successfully) answers the verification, the IM containing the URL will be forwarded, but the whitelist will not be updated based on the sender's action. This means that the sender will receive verification of the same URL over and over again.

[0008] Summary of problems in the prior art:

• the size of the blacklist may become unmanageable, as all suspicious services must be blacklisted;

• there is no automatic creation of whitelists;

• malware detection does not include the service test;

• there is no rejection of service requests for new malicious uses, therefore the network operator's continuous action is needed to update the blacklist;

• the user is harassed many times during identical service requests;

• there is a possibility that the operator will blacklist the services that the user wants to use.

[0009] Hence, there is a need in the art for a simple way of managing unwanted service requests efficiently and preventing abuse.

Brief description of the invention [0010] The invention is defined by the independent claims.

[0011] The object of the invention is to reduce or eliminate at least one of the disadvantages known in the art and to provide in a first aspect of the invention a method and system for managing unwanted service requests sent from at least one terminal (mobile communication device) to a network, wherein the network may comprise a node network for storing information about trusted services. The method may include at least one of the steps: the network receives a service request from the terminal, a request containing information about the service request and / or sends, preferably via a secure communication channel, a user verification request for a request from the user to verify the service requested by the terminal, if at least part of the information about the service request is not on the list of trusted services information. Information on trusted services includes at least one type of service (SMS, MMS, call, instant message, video, etc.) and the purpose (e.g. address or phone number) of the service whose performance is requested, regardless of whether the type or purpose are allowed or not. In an embodiment of the invention, the trusted service information placed on the list is filled with subsequent requests, potentially supplemented by independent input of trusted service information. In another embodiment of the invention, the list of information about trusted services is populated by independently entering information about trusted services. The user may be a user who effectively uses the terminal or a user who is the owner of the terminal or one who is authorized or appointed to carry out verification of the service request.

[0012] The method and system effectively prevent damage caused by malware by verifying with the user if the submitted service request is an authorized request. This effect is achieved thanks to dynamic information on trusted services (e.g. in the form of a white list), about services allowed in the network and verification of each service request, whether the service is covered by information about trusted services before allowing the service. When the service is not listed, the network will dynamically ask the user in a secure manner to verify that the request should be established. In this way, requests from malware can be recognized by the user and the user may refuse to determine such services.

[0013] In one embodiment, the method further comprises at least one of the steps: receiving, preferably via a secure communication channel, responses to user verification, and the response includes verification information provided by the user, said verification information indicating whether the user accepts or rejects the service request; and / or adding at least part of the service request information to the trusted service information, if the verification information indicates that the requested service is allowed. In this way, the network automatically sets up a dialogue with the user for verification

-4usługi. If the service is allowed by the user, information about trusted services is dynamically updated.

[0014] In another embodiment, the method may further comprise one of the steps of: determining an encoded communication channel, preferably using a secure key stored in the terminal identification module, between the terminal and the network; sending a verification request via a coded communication channel to a terminal and / or receiving, via a coded communication channel, user verification responses, and the response includes verification information provided by the user whether the user accepts or rejects the service request. User dialogue can be established using an encoded communication channel and a private key stored in the terminal identification module.

[0015] In yet another embodiment, the terminal may include at least one of the following: an identification module, one or more input / output interfaces, and / or at least a trusted component of the equipment. A trusted piece of equipment can be configured to establish one or more communication paths between the trusted piece of equipment and the identification module and / or one or more input / output interfaces. By using one or more trusted hardware components in the terminal, one or more communication paths can be achieved in the terminal, thereby preventing malware interference with the user verification dialog between the user and the network.

[0016] In one example, the method may further comprise at least one of the steps of: determining another communication channel that differs from the communication channel through which the service request is received over the network; sending the user a verification request via a secure channel to the terminal and / or receiving, via another communication channel, user verification responses, and the response includes verification information whether the subscriber allows or rejects the service request. In yet another example, the next communication channel may be equipped with a messaging service, preferably a short messaging service or USSD.

[0017] In a further example, the verification request may include a test configured to determine whether the user is human or not, preferably an inverted Turing test, more preferably a Captcha, the verification response including information whether the test was successful or not.

[0018] In yet another example, the network may comprise at least one network node that provides services. The network node that provides services may contain a visitor location register (VLR) containing information about trusted services. The network node may also have a user verification function to send, in response to a service request from the terminal, a user verification request to the terminal if at least some of the information in the request is not on the list of trusted services information. In one example, the network may include a home location register (HLR), where the home location register contains information about trusted services of this location

-5terminala. The method may further include the step of transmitting trusted service information from the home location register to the visitor location register. When a terminal is registered in the VLR network of the network node that provides services, the serving terminal can recover information about trusted services from the HLR home registry of the terminal's home network. Similarly, information about trusted services in HLR can be updated by transmitting trusted services verified by the user and added to the information about trusted services in VLR back to HLR.

[0019] In another aspect, the invention may relate to a system for managing unwanted service requests sent from at least one terminal to the network. The system may have at least one of the following features: one or more terminals to establish a communication channel with the network; a network node providing services configured to receive a service request containing information about a service request from at least one of the terminals and / or a database of trusted services connected to the network node providing the services; wherein the service node is configured to send, preferably via a secure communication channel, a user verification request for a request from the user to verify the service requested by the terminal, if at least part of the service request information is not on the list of trusted services information.

[0020] In a further aspect, the invention may relate to a user verification function for use in the system described above, wherein the user verification function may have at least one of the features: means for receiving a service request from the terminal, a service request containing information about that service request; means for checking that at least part of the service request information is contained in the trusted services database and / or a means to establish a secure dialogue between the terminal user and the network if at least some of the service request information is not on the list of trusted service information.

[0021] In yet a further aspect, the invention may relate to a terminal for use in the system described above. The terminal may have at least one of the following features: a client for user verification to determine, in response to a user verification request from the network node providing services, a secure dialogue between the terminal user and the network; an identification module providing a private key for establishing a secure communication channel for this dialogue; input element for receiving dialog information from the user; an output element for transmitting dialog information to the user and / or a trusted hardware element for determining, preferably using a trusted computer standard, one or more communication paths between a client for user verification, an identification module, an input element and / or an output element.

[0022] The invention may also relate to a computer program product comprising parts of the program code configured when it runs in the computer's memory, preferably a computer located in one or more network nodes, for carrying out the method steps according to any method claims as described above.

The invention will be further illustrated with reference to the accompanying drawings, which schematically show embodiments of the invention. It will be understood that the invention is in no way limited to these specific embodiments.

Brief description of the drawings [0024]

Fig. 1 schematically shows a communication system according to one embodiment of the invention.

Fig. 2 shows a block diagram of a method according to one embodiment of the invention.

Fig. 3 shows a terminal for use in a method according to one embodiment of the invention.

Detailed description [0025] Fig. 1 is a diagram of a communication system 100 according to one embodiment of the invention. The system may include a terminal 102 connected to a communication network 104. In one embodiment, the network may be a 2G cellular telephone network (e.g., GSM), comprising a transceiver base station (BTS) 106 serving as an access node. The BTS can be connected via the base station controller 108 (BSC) to the digital telephone exchange (MSC) 110, e.g. Visitor networks (VN). In addition, the MSC can be connected to the Visitor Location Register (VLR) 112, which is a database that stores user-related data and performs security functions. In addition, the MSC may be connected to the Home Location Registry (HRL) 114, which is the authentication center (AuC) 116. The HLR / AUC may be located in the home network (HN) where the user of terminal 102 has a subscription with the network operator. HLR stores data related to users, e.g. data related to subscriptions, and also cooperates with MSC / VLR 110 in tracking the location of the terminal. The authentication panel (AuC) contains (among other things) algorithms for calculating the authentication parameters used in the authentication procedure. For each subscriber, the AuC stores the secret authentication key K, which is also stored in the associated identification module, e.g. (U) SIM card or similar module located in the terminal.

[0026] The trusted services database (TS) 118, containing information about trusted services, e.g. one or more trusted lists of allowed and / or unacceptable service identifiers (e.g. telephone numbers) associated with the subscriber, can be connected or be part of the HLR . The list in the TS database can be updated by the subscriber's HLR and / or by the service verification function 120. The service verification function is configured so that it has access to the TS database and establishes, in response to a service request from the terminal, a secure communication channel with the user terminal.

[0027] The service verification function may be implemented as a functional piece of equipment or as a product of a computer program performed at MSC or other

- a separate network element connected to the MSC. Alternatively, the function may be a distributed function having two or more elements containing one or more computer program products. A more detailed explanation of the connection verification function will be provided below with reference to Fig. 2.

[0028] Other networks than the GSM network shown in Fig. 1 may be used. For example, in an embodiment it may be a 3G cellular network (UMTS) comprising 3G network elements. In this case, the network may include a radio base station (RBS) 106 connected via a radio network controller (RNC) 108 to the serving GPRS supporting node (SGSN) 110. SGSN is also connected to VLR 112 and AuC / HLR 114.116 in a similar manner to the network type 2G, described above. In another embodiment, the communication network 104 may include IMS network elements in the form of a set of connection / session control functions (CSCF), such as proxy-CSCF (P-CSCF), query-CSCF (I-CSCF), support-CSCF (S- CSCF) and home subscriber server (HSS). Further examples include 3GPP LTE or 3GPP SAE network elements.

[0029] Terminal 102 may be a personal computer or mobile device, such as a smartphone, palmtop (PDA), laptop or any other mobile communication device capable of providing services through one or more mobile networks (2G, 2.5G, 3G, 4G, NG, WiMax, etc.) The terminal includes radio module 122, operating system (OS) 124 and identification module 120.

[0030] Radio module 122 acts as a connection point to wireless network services and comprises for this purpose at least a radio interface comprising an RF receiver connected to one or more antennas. Fig. 1 shows an exemplary embodiment where radio card 122 provides radio contact with base station 106. The RF interface of the radio module is capable of receiving and transmitting RF signals in accordance with various wireless technologies (e.g. TDMA for GSM services, W-CDMA for UMTS services, IEEE 802.11 used for WiFi, Bluetooth, DECT services, etc.).

[0031] The terminal operating system (OS) 124 may include a kernel that manages mobile device resources, e.g., a central processing unit (CPU), memory for storing program instructions 130, and input / output (I / O) data devices, such as a radio module 122, display 134 and keyboard 132. In addition, OS usually includes one or more application programming interfaces (APIs) through which application programs 128 can access services offered by the OS, e.g. API radio network for establishing a radio connection to a mobile network.

[0032] The identification module 126, which can usually be removed, can be a UICC (Universal Integrated Circuit Card) for use in mobile devices suitable for 2G (GSM) network services or 3G (UMTS) network services . For this purpose, the UICC card may include a subscriber identification module (SIM) containing SIM applications and / or a UMTS subscriber identification module (USIM) containing USIM applications. It should be understood that the identification module is not limited to SIM and / or USIM applications. In further embodiments, a module

- the identification may be an IP Multimedia SIM (ISIM) subsystem for authentication and access to IMS-based services, in accordance with the pre-established IMS-based AKA, such as e.g. described in the technical specification ETSI TS 33.203 or the Extensible Authentication Protocol (EAP) based on SIM for authentication and network access according to a predetermined EAP-based AKA, as described e.g. in RFC4187.

[0033] The identification module may include a processor, one or more memory elements, e.g. ROM, RAM and / or EEPROM, and I / O circuits. For authentication purposes, UICC includes the secret key K of the subscriber's service authentication and one or more algorithms for calculating responses having one or more authentication parameters at the time the random job is received.

[0034] To access the network, the terminal first performs the authentication procedure defined by one of the authentication and key agreements (AKA) of the telecommunications standard used by the network. GSM AKA is a task-response authentication procedure that involves sending a random RAND number to the SIM in the terminal. The SIM card generates an RES response, which is sent back to the network, which compares the response with the expected response calculated by the network. As part of GSM AKA, a symmetrical CK encryption key is established between the mobile terminal and the service network for data encryption via the GSM radio interface. The GSM AKA procedure is described in detail in the ETSI GSM 02.09 and GSM 03.20 standards, which are given here as a reference.

[0035] In the authentication procedure according to the UMTS standard, similar steps are performed as in GSM AKA. However, for added security, the network also authenticates itself in the terminal. In the UMTS AuC / HLR scheme, a random RAND number is generated and the authentication vector (AV) {AUTN, RAND, XRES, CK, IK} is determined. Then SGSN / VLR sends RAND and AUTN to the terminal. The USIM in the terminal determines the RES response based on RAND and AUTN, which is then sent to the network and compared with the expected response determined by the network. Similar to GSM AKA, the CK digital key and IK integrity key are set during UMTS AKA, which are used to encrypt and protect the integrity of data sent over the radio interface between the mobile terminal and the serving network. UMTS AKA is described in detail in the technical specification ETSI TS 33.102, which is given here as a reference.

[0036] Fig. 2 is a block diagram of an outgoing connection determination in a GSM network according to an embodiment of the invention. During the authentication process described above, subscriber registration data, including the subscriber's identity (IMSI), credentials, subscriber's telephone number, list of acceptable services, subscriber's HLR address and information on trusted services, including, but not limited to, a white list and / or a black list, can be transferred from HLR to MSC / VLR (step 202). After successful authentication, the terminal may have access to the network service by sending a service request, e.g., a connection establishment request, including the mobile integration network subscriber number (MSISDN) via BSS to MSC / VLR (step 204).

[0037] In response, the MSC checks via the VLR whether the terminal can access the requested service. In addition, the service verification function in MSC checks whether the information in the service request, in particular MSISDN, is on the list of information about trusted services (e.g. in the form of a list of trusted phone numbers). The list can be checked by accessing the VLR connected to the MSC (steps 206 and 208). If a match occurs, MSC instructs BSS to allocate resources for the connection and redirect the connection via GMSC, a gateway that connects the mobile network with the fixed PSTN network to the recipient (not shown).

[0038] If the number is not found in the list of allowable numbers, the MSC service verification function may initiate a dialogue with the exit terminal to request the user to verify whether the call is acceptable or not. For this purpose, you can establish a secure communication channel between the terminal and the network, which is difficult to damage by malware. Examples of such secure communication channels will be described in more detail below.

[0039] Using a secure communication channel, the service verification function in the MSC / VLR can send the user a verification request to the user's terminal. The user verification request may launch a dialog with the terminal user in which the user is asked to verify whether to establish the desired service (step 210). In response to the user verification request, the user response message is sent back to the service verification function in the MSC (step 212). If the user's response indicates that the connection has been accepted by the user, the list of trusted services is updated by adding the number to the information about trusted services (steps 214 and 216). After the user connection verification dialog, the MSC allocates resources to the requested service, e.g., connection and directs the service request via GMSC and one or more communication networks, e.g., public switched telephone network (PSTN) to the selected terminal (step 218). If the response message indicates that the user does not accept the connection, the connection will be rejected by the MSC (not shown).

[0040] Hence, in contrast to the standard output connection arrangements, the invention allows strict control of the service sent by the terminal to the network by checking that the information in the service request is whitelisted. By using the white list, the malware generated by the output service requests can be successfully blocked. Furthermore, the invention makes it possible to construct a whitelist in an interactive and dynamic way. When the list will have a certain size, using the white list as generated by the connection verification feature gives network operators increased assurance that the registered connections are in fact indisputable connections.

[0041] The communication channel between the terminal and the network should be secure in the sense that it does not allow malware interference. In one embodiment, the radio channel may be coded, which uses a CK code key, established between the mobile terminal and the serving network during the authentication procedure based on GSM or UMTS AKA. In this scheme, the MSC / VLR can send an encrypted user verification request 210 to the terminal, which can be modified to prevent

- malware interferences with dialog between the user and the network. One exemplary embodiment of such a terminal 300 is shown in more detail in Fig. 3. In this embodiment, the terminal has a user verification application 302 (client) running in the terminal's OS 304 operating system. The terminal further includes one or more trusted 306 (THC) hardware components for establishing one or more trusted 308-316 communication paths between user verification client 302, identification module 318 (e.g. (U) SIM), memory 320 and / or one or more I / O interfaces such as the 322 input element (keyboard, microphone, etc.) and 324 output element (display, speaker, etc.).

[0042] The user verification request may launch a user verification client implementation that is configured to securely communicate with the (U) SIM card for data encryption and decryption and with the keyboard and memory interfaces 322, 324 of the terminal for user interaction.

[0043] THC may be a tamper-resistant device configured to perform a number of security functions, including local and / or remote validation, secure data storage and secure I / O functions. These functions can be used to establish trusted communication paths on the terminal. This THC can be implemented in accordance with a predefined trusted computer platform standard, e.g. trusted computer platform (TCP) as defined in the specification of the mobile trusted module (MTM) version 1.0, rev. 1, June 12, 2007, published by the Trusted Computer Group (TCG) or with the hardware platform of trusted Intel implementation technology (TXT).

[0044] It is THC that can verify the integrity of the user verification client using local and / or remote validation. After confirming the integrity, THC can establish one or more trusted communication paths in the terminal as illustrated in Fig. 3. Using these trusted paths, the user verification application establishes a secure dialog with the user, allowing the user to accept or reject the service request. User Response (i.e. keyboard input) is sent via the 326 radio interface and the encoded radio channel back to the service verification function in MSC / VLR.

[0045] In another embodiment, the communication channel may be established using an additional SIM card that is registered in the network. Such a dual SIM terminal allows the service request to be sent to the network using the channel established according to the first SIM card and the user response to the dialog box for accepting or rejecting the service request to be sent via the encrypted communication channel using the second SIM card. This embodiment is based on the fact that the malware is unaware of the second SIM card and thus provides less security compared to using a coded communication channel in conjunction with THC.

[0046] In another embodiment, the secure channel may be established as a separate communication channel on the same infrastructure. For example, in response to

Receiving a service request from the terminal, the network sends a message e.g. in the form of SMS, EMS, MMS or USSD to the terminal user, and the user sends the response back to the network using the same separate communication channel.

[0047] In another example, the service verification dialog between the terminal and the network may include the step of sending a test, preferably based on text, graphics and / or sound, which allows determining whether the user is human or not. The response to the test is sent to the network, where the correct answer corresponds to the acceptance of the service request by the terminal user. Preferably the test is an inverse Turing test (e.g. Captcha or similar). The reverse Turing test can allow dialogue to be carried out using regular and possibly unsecured infrastructure. However, for increased security, the dialogue using the reverse Turing test can easily be connected to the encoded and / or separate communication channel described above.

[0048] The functionality of the trusted services database (TS) can be enhanced by including another list of undesirable numbers (i.e. blacklist). When a network, e.g. MSC receives a service request, then that network will check whether the number selected in the request is blacklisted or whitelisted. If it is on the blacklist, the connection will be automatically rejected without another dialogue with the terminal. The blacklist can be updated in a similar way as described above in connection with the trusted list (whitelist).

[0049] In one embodiment, after rejection by the user, the service request may be added to the blacklist. This can be done automatically in response to rejection by the user or alternatively it can be presented in the dialog box as an option for the user during the connection verification dialog. Selecting an option from the blacklist will result in the rejection of the blacklist update in the TS database. This black and / or white list update may occur when there is communication between the MSC / VLR and the HLR, e.g. when the HLR is informed by the MSC / VLR that the subscriber is in the area covered by the VLR, after a pre-determined period no subscriber activity, after which the terminal will be de-registered from MSC / VLR service. In addition, such an update can occur in real time, i.e. directly after the user verification dialog or when the subscriber's record will be deleted from the VLR.

[0050] Furthermore, the network operator may make available to the user (indirectly) the lists in the TS database, e.g. via a secure internet connection, to allow the user to make changes to the list.

[0051] It should be understood that any feature described in connection with any embodiment may be used alone or in combination with the other features described, and may also be used in combination with one or more features of any other embodiment or combination of any examples. execution. Furthermore, equivalents and modifications not described above may be introduced without departing from the scope of the invention which is set out in the appended claims.

Grażyna Palka

Patent Attorney