HK1164019A - Service-based authentication to a network - Google Patents

Description

Service-based authentication to a network

Technical Field

The present invention relates to service-based authentication to a network and in particular, but not exclusively, to a method and system for service-based terminal authentication to a network and a service interface module for use in such a system.

Background

New generation mobile devices, such as smart phones, provide increasingly enhanced computing functionality via open network connections. Such mobile devices are for example capable of receiving e-mails, sharing software with each other over short-range connections, downloading and executing software from the internet, making automated calls and actions under remote control. Thus, like a personal computer, the mobile devices and in particular the software components involved in establishing a connection between the mobile device to the network are vulnerable to malicious code (malware). Often, malware attempts to abuse the mobile device or simply destroys legitimate use of the mobile device.

Typically, malware exploits security flaws in an authentication process that provides a subscriber with access to a network. For example, GSM Authentication and Key Agreement (AKA) only authenticates a mobile device to a network but not vice versa. GSM AKA is therefore vulnerable to so-called false base station attacks, in which a hacker impersonates a valid base station. Part of these threats is mitigated in UMTS AKA by using mutual authentication, where the mobile device must authenticate itself to a Visitor Location Register (VLR) and the VLR must authenticate itself to the mobile device. An overview of security threats in GSM AKA and the way UMTS AKA combats a number of these threats are described in ETSI TS 33.900.

The UMTS AKA is still vulnerable to security attacks, as judged by TS 33.900. For example, UMTS AKA is vulnerable to so-called man-in-the-middle attacks, where the mobile device of the attacker can use authentication information from the (U) SIM of the victim in order to gain access to the network. Such man-in-the-middle attacks allow network access as if the connection was established by the victim. Since the network cannot distinguish between legitimate situations and such attacks, malware allows calls to be established at the cost of the victim, thereby causing a great deal of damage.

Disclosure of Invention

The present invention aims to reduce or eliminate at least one of the drawbacks known in the prior art and provides in a first aspect of the invention a method for service based terminal authentication to a network. The terminal includes one or more communication interfaces for allowing the terminal to establish a communication channel with the network. The method comprises the following steps: sending a service request for access to a network service; receiving an authentication request from a network in response to a service request; identifying a communication channel through which the authentication request was received; and sending an authentication response RES to the network, wherein the authentication response depends on the identified communication channel.

The method allows the network to determine over which communication channel to send authentication information to the network. The determination of the communication channel can be readily accomplished by identifying the communication interface through which the authentication request was received. Such a service-based authentication method effectively prevents misuse of authentication information, such as man-in-the-middle attacks, where an attacker uses authentication information from a victim (U) SIM in order to gain access to the network.

In addition, the method is compatible with all or at least most existing and proposed AKAs. It need only determine the communication channel through which the request was received and securely insert information about the communication channel into the response.

In one embodiment, the method further comprises the steps of: determining a service code associated with the identified communication channel; the response RES is calculated based on the service code and the information in the authentication request, whereby information, preferably cryptographically secure, about the identity of the communication channel through which the authentication request was received is included in the response.

Information on a communication channel through which authentication information is transmitted to a network is securely inserted in a response of an identification module of a terminal. It is therefore not possible, or at least very difficult, for malware to detect and/or modify the service channel information.

In another embodiment, a terminal for use in the method includes an identification module and a Service Interface (SI) module, preferably implemented as a trusted hardware module, configured to securely communicate with the identification module and to identify a communication channel over which an authentication request is received.

By using the service interface module as a trusted hardware module in the terminal, a very secure and reliable method for sending information about the identity of the communication channel to the network is achieved. Preferably, the service interface module is configured to receive all incoming authentication signals from the network. Thus, all authentication requests will be routed via the service interface module towards the identity module of the terminal.

In a further embodiment, the authentication request comprises authentication information (preferably a random challenge, RAND), and the method further comprises the steps of: modifying the authentication information based on the identified communication channel; the authentication response RES is preferably generated based on the modified authentication information using the telecommunication standard Authentication and Key Agreement (AKA).

In one embodiment, the authentication request comprises authentication information (preferably a random challenge, RAND), and the method further comprises the steps of: generating an authentication response RES, preferably based on an Authentication and Key Agreement (AKA) of a telecommunication standard; preferably a one-way function is used to modify the authentication parameter RES based on the identified communication channel.

This embodiment allows a simple and secure implementation of the method by using a service interface module in secure communication with the identification module. Identifying the communication channel and securely inserting information about the identified communication channel may be performed in the service interface module such that no modification of the identification module is required. This implementation is thus compatible with existing identification modules.

In another embodiment, the method further comprises the steps of: the terminal sends a service request to the network via a predetermined communication channel; the network generates an expected service code XSC based on the communication channel type sending the service request to the network; an expected response XRES is determined based on the expected service code XSC.

In one embodiment, the method further comprises the steps of: comparing the expected response XRES with an authentication response RES sent by the terminal to the network; and determining that the terminal is in an untrusted state if RES is not equal to XRES.

Thus, the method requires only a simple modification in the existing network in the sense that it requires a network node configured to identify the communication channel through which the network receives the service request and to extract the information about the communication channel encrypted in the terminal response.

In one embodiment, the terminal comprises a 2G or 3G type radio interface, a bluetooth radio interface, a WLAN interface, a Digital Enhanced Cordless (DECT) radio interface or an ethernet data interface.

In a further aspect, the invention relates to a service interface module for use in a terminal, the service interface module preferably being configured to securely process all authentication information sent to and from an identity module in the terminal, wherein the service interface module comprises: a receiver for receiving an authentication signal from a network via one of the communication interfaces of the terminal; a channel identifier for identifying a communication channel through which the authentication signal is received, preferably by providing a service code associated with the identified communication channel; an interface for establishing a secure communication channel between the module and an identification module of the terminal.

All functions required in the terminal for implementing the method may simply be located in one trusted hardware module in secure communication with the identification module.

In one embodiment, the service interface module further comprises a modifier for modifying an authentication response of the identification module based on the identified communication channel or a transmitter for transmitting information about the identified communication channel to the identification module or a modifier for modifying an authentication request received from the network.

In another aspect, the invention relates to an identification module, preferably a smart card, for establishing a secure communication channel with a service interface module as described above. The secure communication channel may for example consist of a cryptographically protected link or a direct hardware link between the service interface module and the identification module that cannot be disturbed by an attacker. The identification module comprises: a calculator for calculating a response RES, preferably according to GSM AKA, 3GPP AKA or IMS AKA, upon receiving the authentication request; and optionally a modifier for modifying the response RES based on a predetermined mathematical function using information about the identified communication channel.

In a further aspect, the present invention relates to a terminal (preferably a mobile device) for accessing network services, wherein the terminal is configured to send a modified response RES' to the network in response to an authentication request, wherein the modification depends on the type of communication channel through which the terminal received the authentication request.

In one embodiment, the terminal comprises a service interface module according to the description and optionally an identification module as described above.

In a further aspect, the invention relates to a network node for service based terminal authentication to a network, wherein the network node is configured to generate a modified expected response XRES' in response to receiving an authentication data request, wherein the modification of the expected response XRES is dependent on a type of communication channel sending the authentication data response to the network.

In one embodiment, a network node comprises: a receiver for receiving a service request from a terminal; a generator for generating an expected service code XSC based on a communication channel type of a service request sent to a network; a generator for generating an expected response XRES or a receiver for receiving the expected response XRES from another network node, preferably according to GSM AKA, 3GPP AKA or IMS AKA; and a modifier for modifying the expected response XRES based on a predetermined mathematical function, preferably a one-way function, using the expected service code XSC as an input parameter.

In one embodiment, the network node further comprises: a receiver for receiving a response RES from the terminal; a comparator for comparing the response RES with the modified expected response XRES'.

In yet another aspect, the invention relates to a system for service-based authentication to a network, the system comprising: a terminal configured to send a modified response RES' to the network in response to the authentication request, wherein the modification depends on the type of communication channel the terminal receives the authentication request; and a network node configured to generate a modified expected response XRES ' in response to receiving the authentication data request and configured to compare RES ' with XRES ', wherein the modification of the expected response XRES is dependent on the type of communication channel over which the authentication data response is sent to the network.

The invention also relates to a computer program product comprising software code portions configured for, when run in a memory of a terminal, preferably a mobile device, performing the method steps as described above.

The invention will be further explained with reference to the appended drawings, which will schematically show embodiments according to the invention. It will be understood that the invention is not in any way restricted to these specific embodiments.

Drawings

FIG. 1 depicts a schematic representation of a system according to one embodiment of the invention.

Figure 2 illustrates a schematic flow diagram of a GSM authentication procedure and a UMTS authentication procedure.

FIG. 3 depicts a service interface module according to one embodiment of the invention.

FIG. 4 depicts a flow diagram according to one embodiment of the invention.

Fig. 5 illustrates a process for preventing fraudulent authentication by using the present invention.

Detailed Description

Fig. 1 illustrates a schematic representation of a communication system 100 according to an embodiment of the present invention. The system includes a terminal 102 connected to a communication network 104. In one embodiment, the network may be a type 2G (e.g., GSM) mobile network that includes a Base Transceiver Station (BTS) 106 that acts as an access node. The BSC is connected via a Base Station Controller (BSC) 108 to a Mobile Switching Center (MSC) 110, e.g., a Visited Network (VN). The MSC is linked to a Visitor Location Register (VLR) 112, which is a database that stores subscriber-related data and performs security functions. The MSC is also linked to a Home Location Register (HLR) 114 located in the Home Network (HN) where the user of the terminal 102 has a subscription with the network operator. The HLR 114 stores subscriber-related data (e.g., subscription-related data) and operates in conjunction with the MSC/VLR 110 to keep track of the location of the terminal. The HLR is connected to an authentication center (AuC) 116. The authentication center (AuC) includes, among other things, algorithms for computing authentication parameters used in the authentication process. For each subscriber, the AuC stores a secret authentication key K, which is also stored in an associated identification module, e.g. a (U) SIM card or the like, located in the terminal.

Alternatively, the network in fig. 1 may also depict a 3G type (e.g. UMTS) mobile network comprising 3G network elements. In this case, the network may include a radio base station (Node-B) 106 connected to a Serving GPRS Support Node (SGSN) 110 via a Radio Network Controller (RNC) 108. The SGSN is also connected to VLR 112 and AuC/HLR 114, 116 in a similar manner as in a 2G type network as described above.

In yet another embodiment, communication network 104 may include IMS-based network elements in the form of a set of call/session control functions (CSCFs) such as proxy-CSCFs (P-CSCFs), interrogating-CSCFs (I-CSCFs), serving-CSCFs (S-CSCFs), and Home Subscriber Servers (HSS). In further embodiments, the communication network may comprise a 3GPP LTE or 3GPP SAE network element.

The terminal 102 may be a personal computer or a mobile device such as a smart phone, a Personal Digital Assistant (PDA), a laptop, or any other mobile communication device capable of providing services over one or more networks. The terminal includes a Service Interface (SI) module 118, an Operating System (OS) 126, and an identification module 120.

SI module 118 acts as a central access point to wired and wireless network services and includes a number of service interfaces for this purpose. For example for wireless services it comprises an interface to an RF module, for example a 2G or 3G radio card, comprising an RF receiver connected to one or more antennas. Fig. 1 depicts an example implementation in which radio card module 119 provides radio contact with base station 106. The RF interface of the radio card is capable of receiving and/or transmitting RF signals according to various radio technologies using licensed frequency bands, such as TDMA for GSM services or W-CDMA for UMTS services. The radio card must have a secure interface with the SI module. In addition to the interface with the RF module, the SI module may also include a plurality of interfaces with other wireless interface modules, for example, a wireless interface module using an unlicensed frequency band such as an IEEE 802.11 interface for WLAN service, an IEEE 802.15.1 interface for bluetooth service, a DECT interface as described in ETS 300175, and the like.

The SI module may also include an interface to one or more wired interface modules, such as an ethernet interface that allows the SI module to connect to a network using a wired ethernet communication channel. An Access and Configuration (AC) manager in the SI module manages the establishment of a communication channel with an access node of the network or-in the case of a short-range connection such as bluetooth-another terminal. It determines the correct operating parameters under the specific wired or wireless technology and/or protocol associated with the network service requested by the terminal. In addition, the SI module is configured to securely include information about the interface used in data sent to a service identification unit (STU) 124 in the network. The interaction between SI module 118 and SIU 124 is described in more detail below.

The Operating System (OS) of the terminal includes a kernel that manages the resources of the mobile device, such as a Central Processing Unit (CPU), memory for storing program instructions and data, and input/output (I/O) devices such as radio modules. In addition, the OS includes an Application Programming Interface (API) through which the application 122 can access services offered by the OS. The OS may include an API for establishing a wired or wireless connection via one of the interface modules.

The removable identity module 120 may typically be a UICC (universal integrated circuit card) for use in a mobile device adapted for 2G type network services (GSM) or 3G type network services (UMTS). To this end, the UICC may include a Subscriber Identity Module (SIM) application (including SIM functionality) and/or a UMTS Subscriber Identity Module (USIM) application (including USIM functionality). It will be appreciated that the identity module is not limited to SIM and/or USIM applications. In further embodiments, the identity module may be an IP multimedia subsystem, SIM, (isim) for authenticating and accessing IMS-based services according to a predetermined IMS-based AKA as described for example in ETSI technical specification TS 33.203 or an Extensible Authentication Protocol (EAP) -based SIM for authenticating and accessing a network according to a predetermined EAP-based AKA as described for example in RFC 4187.

The identification module may include a processor, one or more memory components such as ROM, RAM, and/or EEPROM, and I/O circuitry. For authentication purposes, the UICC comprises a secret service subscriber authentication key K and one or more algorithms for calculating a response comprising one or more authentication parameters when receiving a random challenge.

Figure 2(a) illustrates a schematic flow diagram of a standard GSM authentication procedure that can be used by the SIM module in the identity module. In the GSM standard, the MSC initiates a request for authentication data to the AuC/HLR in response to a service request for network services originating from the terminal (step 202). The random number generator at the AuC/HLR generates a random value RAND that is input to the GSM A3/A8 algorithm that generates the expected response XRES and the cryptographic key K_C. Returning triplets { RAND, XRES, K to MSC_C} (step 204), the MSC then forwards the RAND value to the SIM card of the terminal (step 206). The corresponding calculation is performed by the terminal (typically by the integrity module), which returns a calculated response RES to the MSC (step 208). By comparing RES with XRES, the MSC can authenticate the terminal to the network.

Similar steps as the GSM procedure are performed in the standard UMTS authentication procedure. However, for increased security additional parameters and a set of eight functions f0-f5, f1, f2 are used. Fig. 2(b) illustrates a schematic flow diagram of a UMTS authentication procedure that may be used with a USIM application in the identity module. In response to a request for authentication data from the SGSN/VLR (step 210), the AuC/HRL generates a random number RAND (using function f 0) and a fresh sequence number SQN. The AuC/HRL provides a secret authentication key K (stored in the AuC and USIM, but never directly exchanged) and an operator specific authentication management domain AMF. These four parameters are fed into five symmetric cryptographic functions f1-f5 resulting in five new parameters: a Message Authentication Code (MAC), an expected response (XRES), an encryption key (CK), an Integrity Key (IK), and an Anonymity Key (AK). Will be provided withSequence number SQN is encrypted into SQN alone¹。

The AuC/HRL returns these parameters { AUTN, RAND, XRES, CK, IK } in the Authentication Vector (AV) to the SGSN/VLR (step 212), where the authentication token AUTN is a triplet { SQN } (step 212)¹AMF, MAC }. The SGSN/VLR then forwards the authentication and encryption request, including the RAND and AUTN, to the mobile device (step 214). Using RAND and AUTN, the USIM calculates, among other things, a response RES which is sent back to the SGSN (step 216) and compared to the XRES as received from the AuC/HLR.

Keys used for encryption and integrity checking have a limited lifetime to prevent attempts to break the password or integrity protection by brute force (brute force) long duration monitoring attacks. At expiry, a new set of ciphering and integrity keys is generated with re-authentication between the terminal and the network.

GSM AKA is described in particular in ETSI standards GSM 02.09 and GSM 03.20 incorporated by reference herein and UMTS AKA is described in particular in ETSI technical specification TS 33.102 incorporated by reference herein.

Fig. 3 depicts an SI module according to a preferred embodiment of the present invention. The SI module 300 is located in a terminal 322 and comprises a plurality of interfaces 302a-302e connected to associated interface modules 320a-320e, preferably by one or more secure communication channels. The interface module is located in the terminal and is used to establish a network connection with the network 316. The SI module is configured to generate a Service Code (SC) that identifies a particular service interface used to establish a wired or wireless communication channel. To this end, the AC manager 304 in the SI module may use a look-up table 306 comprising different service interface types and associated service codes supported by the mobile terminal. The AC manager may be implemented in the form of a processor and one or more memory modules including, for example, look-up table configuration data.

The hardware of the terminal is preferably configured in such a way that all incoming authentication requests for network services received by one of the interfaces 302a-302e will be centrally routed via the SI module towards the UICC connected to the SI module. Such a hardware architecture ensures that all incoming authentication requests are identified with respect to the communication channel over which the terminal receives the request. In addition, the SI module is configured to provide a UICC 310 connected to the SI module to a secure communication channel 308. The SI module is therefore preferably implemented in the form of one or more trusted hardware components.

If, for example, the terminal 322 receives a network signal, for example a 3G signal, via the 3G RF interface module 320c and the 3G interface 302c of the SI module, the signal is translated into a digital signal according to the technical specifications of the wireless air interface. Subsequently, the digital signal including the authentication request is transmitted to the UICC 310 via the SI module. In addition, the AC manager 304 uses the lookup table 306 to identify the service code associated with the 3G RF interface 302 c. The service code is used by the SI module to provide information to the network about the origin of the authentication request.

The UICC processes the authentication request according to the AKA of the telecommunications standard (e.g. GSM AKA or UMTS AKA as described with respect to fig. 2) and then returns a response RES to the SI module. Subsequently, the SI module uses a predetermined mathematical algorithm stored in the secure memory 312 of the SI module in order to securely include the information embodied in the service code into the response RES received from the UICC. Preferably, the mathematical algorithm f is a so-called one-way function which is easy to calculate but impossible or very difficult to invert. A suitable one-way function may be a secure hash operation with an SC. Inserting the service code into the response allows the SI module to inform the network 316 of the communication channel (bluetooth 314a, WLAN 314b, 3G 314c, ethernet 314d, etc.) over which the authentication request was received from the network in a manner that is not possible, or at least very difficult, to modify by malware.

In order for the network to extract the channel information, the network, preferably the SGSN/VLR or an equivalent network node such as an MSC/VLR, comprises a Service Identification Unit (SIU). The SIU includes the same function f as used by the SI module. In addition, the SIU is configured to determine over what type of communication channel to receive the service request.

An advantage of the architecture of the SI module as depicted in fig. 3 is that the specification of the (U) SIM does not need to be changed. This embodiment is simple and requires only the installation of the SI module in the terminal and the installation of the SIU in the network. In addition, the architecture is backward compatible with conventional devices, i.e. terminals and network nodes (e.g. SGSN/VLR or MCS/VLR), which do not include SI mode or SIU.

A more detailed description of the operation of the SIU will be given with respect to fig. 4.

Fig. 4 depicts a process flow 400 between a UMTS network and a terminal including USIM and SI modules as described in relation to fig. 1 and 3. The procedure starts by a terminal application requesting UMTS services from the network. The request triggers the RF interface module to establish a wireless UMTS communication channel between the terminal and the access node of the requesting UMTS network. A service request is then sent to the SGSN/VLR via a wireless communication channel (step 402).

The SIU in the SGSN/VLR then determines over which service interface (UMTS, GSM, WiFi, bluetooth, etc.) contact has been established with the terminal. Based on the identified service interface information, the expected service code XSC is determined (step 404). The SIU may determine the XSC by retrieving the service code associated with the identified service interface (in this case the UMTS service) from a look-up table stored in the secure memory of the SI module, which is substantially the same as the look-up table used by the SI module in the terminal.

In response to the service request, the SGSN/VLR sends an authentication data request to the AuC/HLR of the network (step 406). The AuC/HLR generates a UMTS authentication vector AV which is sent back (step 408) to the SGSN/VLR. The RAND and AUTN are then transmitted to the terminal in an authentication and encryption request over the wireless communication channel (step 410). When the RF interface module of the terminal receives a radio signal including a request, the signal is converted into a digital signal. The AC manager identifies a service code associated with the interface used by the SI module to communicate with the RF module (step 412). The digital signal including RAND and AUTN is then forwarded to the USIM (step 414), which calculates the response RES, for example using the f1-f5 algorithm of UMTS AKA. The USIM then sends a response RES back to the SI module (step 416).

The SI module uses the SC and the one-way function f to determine a modified response RES' = f (RES, SC) (step 418), thus securely inserting information about the communication channel through which the request was received. In this way, the response RES' becomes specific to the service it is directed to. A response RES 'is then sent back to the SGSN/VLR in the network via the RF interface (step 420) for comparison with the expected response XRES' (step 422). The SIU may determine the expected response XRES' using a one-way function f, where the expected response XRES is determined based on UMTS AKA and SC as input parameters: XRES' = f (XRES, SC).

A comparison between the terminal response RES 'and the expected response XRES' is then made. If RES 'equals XRES', this provides the network with the following indication: the terminal receives the authentication request via a communication channel expected by the network. In which case access to the network is granted.

If RES 'is not equal to XRES', an indication is provided to the network as follows: the terminal receives the authentication request via a communication channel different from the communication channel expected by the network. This may provide an indication to the network as follows: the terminal may be corrupted by malware.

Note that the present invention is not limited to the embodiments as described with respect to fig. 3 and 4. In yet another embodiment, the UICC (instead of the SI module) includes a one-way function f for securely inserting service code information into the response.

After the AC manager has selected the correct SC, the code is inserted into the digital signal comprising the request and sent to the identification module for further processing (e.g., authentication and/or calculation of a decryption key). Thus, in this variant, the digital signal sent by the SI module to the identification module comprises information of via which service interface (and therefore via which communication channel) the signal was received. Further variants for transmitting the service code to the identification module may for example comprise transmitting the service code to the identification module in a separate signal.

In one embodiment, the (U) SIM may modify the authentication information in the authentication request based on the service code SC (e.g. random challenge RAN)D) And then calculates the response RES based on the Authentication and Key Agreement (AKA) of the telecommunication standard. For example, in the case of GSM service, the SIM may perform the following steps: RAND ' = f (RAND, SC) and RES ' = a3(RAND ', K)_C). In another variant, the SIM first computes a response RES based on RAND and then modifies RES based on SC: RES = a3(RAND, K)_C) And RES' = f (RES, SC). In case of UMTS service, the f1-f5 algorithm of UMTS AKA is used instead of the A3 algorithm of GSM AKA.

According to a specific scheme implemented in the USIM, the SIU, which comprises the mathematical function f used by the USIM in the terminal, may determine RAND ' = f (RAND, XSC) and send this value to the AuC/HLR to determine the expected response XRES ' based on UMTS AKA using RAND ' as one of the input parameters. Alternatively, the AuC/HRL may first determine XRES based on UMTS AKA using RAND as one of the input parameters and send this value to the SIU to determine the expected response XRES' = f (XRES, XSC).

Fig. 5 represents a simplified schematic diagram illustrating how the present invention may be used to prevent fraudulent authentication processes. In this scenario, the first terminal 502 of the attacker connects remotely to the infected second terminal 504 of the victim and then requests and uses authentication information from the (U) SIM 506 of the victim to gain access to the network 510.

The malware in second terminal 504 allows the terminal of attacker 502 to create a first communication channel 512, e.g. a bluetooth connection, with the infected terminal of the victim. Other types of connections, such as WiFi connections or wired connections such as ethernet connections, may also be possible. After connecting to the victim, the attacker starts the authentication process to the network by sending a service request to the AuC/HRL via the second communication channel 541. In response, the attacker will receive an authentication request that includes the RAND and AUTN, among others. The attacker forwards the request to the victim using the bluetooth connection with the victim's (U) SIM instead of responding to the request.

Conventional u (sim) cannot distinguish between requests originating from different communication channels (e.g. UMTS, GSM, WiFi, bluetooth, etc.). In this case, u (sim) responds to the request by calculating a correct response RES, which is then sent to the network via the bluetooth connection (i.e. the communication connection from which the request came). An attacker can use this RES to successfully authenticate itself to the network. Using this mechanism, an attacker can correctly respond to each subsequent authentication and encryption request from the network.

However, if the network 510 and the infected terminal 504 in fig. 5 are configured as a communication system according to the present invention as described in relation to fig. 1, the SI module 508 is able to distinguish between requests originating from different sources. In this case, the network 510 will determine the expected service code XSC based on the attacker's request. Since the attacker requested UMTS service via the second communication channel 514, the network will set XSC to the service code corresponding to UMTS service. Similarly, the SI module 508 of the infected terminal will modify RES using the service code corresponding to the bluetooth communication channel 512. This modified RES ' is sent via the bluetooth connection to the network, which will then determine that the XRES ' calculated by the network based on XSC does not match RES ' because the communication channel used to send the request for UMTS service to the network is different from the communication channel through which the terminal received the authentication request. In this case, the network may take appropriate action.

In one embodiment, the network may calculate an expected response value (XRES ", XRES"', etc.) for each service code available in a lookup table located in a service node of the network. If the XRES 'value associated with a particular service code matches RES', the source of the request received by the terminal may be determined.

This information may be used by the network to take appropriate action. It may, for example, provide no or limited access to the network or may place the mobile device in a separate isolated or stand alone network to provide remedial services to the subscriber's mobile device. If the response RES 'is neither equal to XRES' nor to other expected responses, the authentication procedure has failed.

It will be appreciated that the invention may also be used with IMS AKA (3 GPP TS 33.203), in Generic Bootstrapping (GBA) applications (see 3GPP TS 33.220, 33.222, 33.223) or in WLAN interworking applications with EAP AKA and/or EAP SIM. It can also be used in generic access solutions to mobile networks (see 3GPP TS 43.318).

It is to be further understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims (18)

1. A method for service based terminal authentication to a network, the terminal comprising one or more communication interfaces for establishing a communication channel with the network, the method comprising the steps of:

-sending a service request for access to a network service;

-receiving an authentication request from the network in response to the service request;

-identifying the communication channel through which the authentication request was received; and is

-sending an authentication response RES to the network, wherein the authentication response depends on the identified communication channel.

2. The method of claim 1, further comprising the steps of:

-determining a service code associated with the identified communication channel;

-calculating the response RES based on the information in the authentication request and the service code, thereby securely including information, preferably cryptographically, about the identity of the communication channel through which the authentication request was received in the response.

3. A method according to claim 1 or 2, wherein the terminal comprises an identity module and a Service Interface (SI) module, the SI preferably being implemented as a trusted hardware module configured to securely communicate with the identity module and to identify the communication channel over which the authentication request was received.

4. The method according to any of claims 1 to 3, wherein the authentication request comprises authentication information, preferably a random challenge, RAND, the method further comprising the steps of:

-modifying the authentication information based on the identified communication channel;

-generating an authentication response RES based on the modified authentication information, preferably using an Authentication and Key Agreement (AKA) of a telecommunication standard.

5. The method according to any of claims 1 to 3, wherein the authentication request comprises authentication information, preferably a random challenge, RAND, the method further comprising the steps of:

-generating an authentication response RES, preferably based on an Authentication and Key Agreement (AKA) of a telecommunication standard;

-modifying the authentication parameter RES based on the identified communication channel, preferably using a one-way function.

6. The method according to any one of claims 2 to 5, further comprising the steps of:

-the terminal sending a service request to the network via a predetermined communication channel;

-the network generating an expected service code XSC based on the type of communication channel sending the service request to the network;

-determining an expected response XRES based on the expected service code XSC.

7. The method of claim 6, further comprising the steps of:

-comparing said expected response XRES with said authentication response RES sent by said terminal to said network; and is

-if RES is not equal to XRES, determining that the terminal is in an untrusted state.

8. The method according to any of claims 1 to 7, wherein the terminal comprises a 2G or 3G type radio interface, a Bluetooth radio interface, a WLAN interface, a Digital Enhanced Cordless (DECT) radio interface or an Ethernet data interface.

9. A service interface module for use in a terminal, preferably configured to securely process all authentication information sent to and from an identity module in the terminal, the service interface module comprising:

-a receiver for receiving an authentication signal from the network via one of the communication interfaces of the terminal;

-a channel identifier for identifying the communication channel through which the authentication signal was received, preferably by providing a service code associated with the identified communication channel;

-a channel interface for establishing a secure communication channel between said module and an identification module of said terminal.

10. The service interface module of claim 9, the module further comprising:

-a modifier for modifying an authentication response of the identification module based on the identified communication channel, or means for sending information about the identified communication channel to the identification module, or means for modifying the authentication signal received from the network.

11. An identification module, preferably a smart card, for establishing a secure communication channel with a service interface module as claimed in claim 9 or 10, the identification module comprising: a calculator for calculating a response RES, preferably according to GSM AKA, 3GPP AKA or IMS AKA, upon receiving the authentication request; and optionally a modifier for modifying the response RES based on a predetermined mathematical function using information about the identified communication channel.

12. A terminal, preferably a mobile device, for accessing network services, the terminal being configured to send a modified response RES' to the network in response to an authentication request, wherein the modification depends on the type of communication channel the terminal receives the authentication request.

13. The terminal of claim 12, wherein the terminal is configured to:

-receiving an authentication request from the network;

-determining a service code associated with the type of communication channel via which the terminal received the authentication request; and is

-sending an authentication response RES to the network in response to the authentication request, wherein the authentication response depends on the determined service code.

14. A serving node for service-based terminal authentication to a network, the network node being configured to generate a modified expected response XRES' in response to receiving an authentication data request, wherein the modification of the expected response XRES is dependent on the type of communication channel over which the authentication data response is sent to the network.

15. The network node of claim 14, wherein the network node is configured to:

-receiving a request for authentication data;

-determining an expected service code associated with a type of communication channel via which the authentication data request was received by the network; and is

-generating an expected response XRES in response to receiving the authentication data request, wherein the expected response depends on the determined expected service code.

16. A system for service-based authentication to a network, comprising:

-a terminal configured to send a modified response RES' to the network in response to an authentication request, wherein the modification depends on the type of communication channel the terminal received the authentication request;

-a network node configured to generate a modified expected response XRES ' in response to receiving an authentication data request and configured to compare RES ' with XRES ', wherein the modification of the expected response XRES depends on the type of communication channel sending the authentication data response to the network.

17. The system of claim 16, comprising:

-a terminal configured to receive an authentication request from the network, to determine a service code associated with a type of communication channel via which the authentication request is received by the terminal, and to send an authentication response RES to the network in response to the authentication request, wherein the authentication response depends on the determined service code; and

-a network node configured to receive an authentication data request, to determine an expected service code associated with a type of communication channel via which the authentication data request was received by the network, and to generate an expected response XRES in response to receiving the authentication data request, wherein the expected response depends on the determined expected service code.

18. A computer program product comprising software code portions configured for performing the method steps according to any of claims 1 to 5 when run in a memory of a terminal, preferably a mobile device.