HK1112124B

HK1112124B - Secure bootstrapping for wireless communications

Info

Publication number: HK1112124B
Application number: HK08106747.5A
Authority: HK
Inventors: 格雷戈里‧戈登‧罗斯; 詹姆斯‧森普尔; 约翰‧华莱士‧纳谢尔斯基
Original assignee: 高通股份有限公司
Priority date: 2005-02-04
Filing date: 2006-02-03
Publication date: 2014-01-10

Abstract

A mutual authentication method is provided for securely agreeing application-security keys with mobile terminals supporting legacy Subscriber Identity Modules (e.g., GSM SIM and CDMA2000 R-UIM, which do not support 3G AKA mechanisms). A challenge-response key exchange is implemented between a bootstrapping server function (BSF) and mobile terminal (MT). The BSF generates an authentication challenge and sends it to the MT under a server-authenticated public key mechanism. The MT receives the challenge and determines whether it originates from the BSF based on a bootstrapping server certificate. The MT formulates a response to the authentication challenge based on keys derived from the authentication challenge and a pre-shared secret key. The BSF receives the authentication response and verifies whether it originates from the MT. Once verified, the BSF and MT independently calculate an application security key that the BSF sends to a requesting network application function to establish secure communications with the MT.

Description

Secure self-initiation of wireless communications

Claiming priority pursuant to 35U.S.C. § 119

The present patent application claims priority from us 60/650,358 provisional application entitled "Secure Bootstrapped Keys in GSM" filed on 4/2/2005 and us 60/654,133 provisional application entitled "Secure Bootstrapped with CAVE" filed on 18/2/2005, both assigned to the assignee of the present application and expressly incorporated herein by reference.

Technical Field

The present invention relates generally to systems and methods for securing wireless communications. More specifically, one feature of the present invention provides a novel authentication and key agreement mechanism for devices supporting legacy network authentication mechanisms to provide application security keys by utilizing legacy wireless authentication and key agreement mechanisms.

Background

One type of cellular technology for wireless communications is defined by the Global System for Mobile (GSM) protocol, which operates on second generation (2G) wireless telephone networks. GSM is extended by newer networks, such as General Packet Radio Service (GPRS), also known as 2.5G networks, which provide internet content and packet-based data services for GSM networks. GSM and GPRS are used for many types of wireless communication including voice, internet browsing, email, and multimedia data. GSM incorporates various security mechanisms to protect content transmitted over these systems. Both service providers and users rely on these security mechanisms to achieve the confidentiality of their communications and protection of their data, and the service providers use these security measures to authenticate their subscribers for billing purposes. These security mechanisms typically operate by authenticating the user mobile terminal to the network, and subsequent transmissions may be encrypted. However, GSM security measures are vulnerable to third party attacks due to weaknesses in the GSM security protocols (e.g., false base station attacks due to lack of network authentication, possibility of replaying the security protocol), and weaknesses in the GSM encryption algorithms.

These security vulnerabilities are addressed in the development of security protocols in third generation (3G) wireless communication standards. In particular, the Authentication and Key Agreement (AKA) protocol developed for the Universal Mobile Telecommunications System (UMTS) includes features such as sequence numbers and Message Authentication Codes (MACs) that protect GSM from false base station attacks. Thus, mobile subscribers using a UMTS User Service Identity Module (USIM) for network authentication are not vulnerable to attacks by users directed to a GSM Subscriber Identity Module (SIM).

For example, in the third generation partnership project document 3GPP 33.220 Generic Authentication Architecture (GAA), the 3G standardization organization is also developing a Generic Authentication Architecture (GAA) for generic bootstrapping architecture. This architecture relies on the 3GAKA protocol to establish keys between the User Equipment (UE) of a mobile subscriber and a new server entity known as a Bootstrapping Server Function (BSF). As a way of establishing security keys that are common between the NAF and the appropriate UE, further keys may be derived from these keys and provided by the BSF to various Network Application Functions (NAF).

The technology being developed relies on 3G authentication and key agreement methods, such as those supported in the UMTS Universal Subscriber Identity Module (USIM), with inherent security improvements compared to 2G or earlier legacy systems such as GSM. For example, Generic Authentication Architecture (GAA) and Generic Bootstrapping Architecture (GBA) are specified for 3G networks and are established on the security infrastructure of 3G mobile networks (i.e. USIM-based security) to provide secure mutual authentication between mobile user equipment and network servers that facilitate network applications and/or services.

However, these mutual authentication techniques (e.g., GAA and GBA) are not available for earlier developed (e.g., 2G) communication systems, such as GSM Authentication and Key Agreement (AKA) protocols. These GSM protocols are vulnerable to replay attacks so an attacker can force reuse of keys and may exploit weaknesses in certain circumstances to reveal keys and thus break security. Therefore, there is a need for a method for bootstrapping application security keys from GSM authentication and key agreement in a manner that is not susceptible to replay attacks and keys may not be easily compromised.

Accordingly, there is a need to establish techniques by which the Generic Authentication Architecture (GAA) specified for 3G networks can be extended to support legacy systems (e.g., 2G or earlier systems). This would allow subscribers of GSM or other devices with a Subscriber Identity Module (SIM) to be provided with keys for mobile network applications and/or services without having to replace their SIMs with a UMTS USIM. Furthermore, such an approach does not introduce weaknesses into the generic authentication architecture due to the vulnerability of the GSM authentication itself.

Disclosure of Invention

A method of mutual authentication is provided for securely agreeing application security keys with mobile terminals that support legacy subscriber identity modules (e.g., GSM SIM and CDMA 2000R-UTM, which do not support the 3G AKA mechanism). A challenge response key exchange is performed between the Bootstrapping Server Function (BSF) and the Mobile Terminal (MT). The BSF receives network authentication parameters (e.g., gsm rdan, SRES, Kc) corresponding to this mobile terminal from a Home Location Register (HLR), and generates an authentication challenge containing RAND under a public key mechanism of server authentication and sends it to the MT. This authentication challenge may include other parameters such as a random number, identity information, a timestamp, a sequence number, and a Diffie-Hellman public key.

The MT receives the authentication challenge and determines whether it originates from the BSF based on the bootstrapping server certificate. The MT formulates a response to the authentication challenge based on a key derived from the authentication challenge (e.g., a random number) and a pre-shared secret key (e.g., in a GSM SIM). That is, the SIM in the MT may derive the secret keys (e.g., SRES and Kc) used by the bootstrapping server function based on the random number RAND received in the authentication challenge and the pre-shared secret key stored in the SIM. The authentication response may contain other parameters such as an encrypted random number, identity information, a timestamp, a sequence number, and a Diffie-Hellman public key. The BSF receives the authentication response and determines whether it originated from the MT. The challenge-response mechanism utilizes a public key mechanism to verify the origin of the challenge and the pre-shared security key to verify the origin of the response. For example, the BSF may independently recalculate one or more parameters in the authentication response (e.g., RAND, SRES, and/or Kc obtained from the HLR using or based on it) to verify whether the one or more parameters received in the authentication response are the same.

With these messages authenticated, the BSF and MT can now compute the application security key based on RAND, SRES, Kc and/or other parameters that may have been transmitted between the BSF and MT. Note that BSF and MT know independently that keys SRES and Kc are not transmitted between the two. The application security key may be sent from the bootstrapping server function to the requesting network application function such that the mobile terminal and the network application function share the application security key and may use it for secure communications therebetween.

A method for authenticating a legacy mobile terminal to communicate with a network application function is provided, comprising: (a) generating an authentication challenge at the bootstrapping server function; (b) sending an authentication challenge to a mobile terminal, wherein the mobile terminal can verify an origin of the authentication challenge based on a previously obtained bootstrapping server certificate associated with a bootstrapping server function; (c) receiving, at the bootstrapping server function, an authentication response including a first parameter computed with a first key generated at the mobile terminal; (d) verifying whether the authentication response originates from the mobile terminal by recalculating, at the bootstrapping server function, the first parameter based on a second key provided to the bootstrapping server function; and (e) comparing the first parameter received in the authentication response with the first parameter recalculated by the bootstrapping server function. If the two first parameters are the same, the authentication response is considered to have originated from the mobile terminal.

The first key may be obtained from a subscriber identity module stored in the mobile terminal, which may be a Global System for Mobile (GSM) Subscriber Identity Module (SIM) or a CDMA2000 authentication module. The second key may be obtained from a home location register communicatively coupled to the bootstrapping server function. The first and second keys may be generated based on the same security algorithm and pre-shared security key known to a subscriber identity module in the mobile terminal and a network database communicatively coupled to the bootstrapping server function. The authentication challenge may include a random number as a parameter, and a first key used to calculate the first parameter in the authentication response is generated by the subscriber identification module with the random number and a pre-shared security key stored in the subscriber identification module in the mobile terminal. The second key provided to the bootstrapping server function may be generated based on a copy of the pre-shared security key stored externally to the mobile terminal and the random number in the authentication challenge. The first parameter of the authentication response may include a message authentication code calculated with the first key, and the origin of the authentication response is verified by the bootstrapping server function with the message authentication code.

In some implementations, a third key may be generated at the bootstrapping server function based on the second key; the first parameter is recalculated at the bootstrapping server function using the third key.

Furthermore, the method may further comprise: (a) calculating a fourth key at the bootstrapping server function based on the second key, wherein the second key is also independently calculated by the mobile terminal using the first key; and (b) transmitting the fourth key from the bootstrapping server function to the requesting network application function such that the mobile terminal and the network application function share the fourth key to ensure communication therebetween.

Another feature provides a network device, comprising: (a) a communication interface to communicate with a wireless mobile terminal; and (b) a processing circuit coupled to the communication interface and configured to implement a bootstrapping server function to authenticate a mobile terminal. The processing circuit may authenticate the mobile terminal by: (a) generating an authentication challenge comprising a random number; (b) sending the authentication challenge to a mobile terminal, wherein the mobile terminal can verify an origin of the authentication challenge based on a previously obtained bootstrapping server certificate related to a bootstrapping server function; (c) receiving an authentication response from the mobile terminal, the authentication response including a first parameter calculated with a first key based on a random number, a pre-shared secret key, and an algorithm, wherein the pre-shared secret key and algorithm are known to a subscriber identification module in the mobile terminal and a network database communicatively coupled to the bootstrapping server function; (d) calculating, at the bootstrapping server function, a second parameter based on a second key provided to the bootstrapping server by a network database; and (e) comparing the first parameter with the second parameter, wherein if the first and second parameters are the same, the authentication response is deemed to have originated from the mobile terminal. In some implementations, the subscriber identification module can be one of a Global System for Mobile (GSM) Subscriber Identity Module (SIM) or a CDMA2000 authentication module. Furthermore, the processing circuit may be further configured to implement a bootstrapping server function to authenticate the mobile terminal by: (a) calculating, at the bootstrapping server function, a fourth key based on the second key, the second key also being calculated at the mobile terminal based on the first key; and (b) sending the fourth key from the bootstrapping server function to the requesting network application function such that the mobile terminal shares the fourth key with the network application function. The processing circuit may be further configured to implement the bootstrapping server function to authenticate the mobile terminal by comparing the first parameter received in the authentication response with the first parameter calculated by the bootstrapping server function, wherein the authentication response is considered to originate from the mobile terminal if the two first parameters are the same.

Yet another aspect provides a method for authenticating a legacy mobile terminal to communicate with a network application function, comprising: (a) receiving, at the mobile terminal, an authentication challenge containing a random number; (b) verifying whether the authentication challenge originated at the bootstrapping server function based on previously obtained bootstrapping server credentials associated with the bootstrapping server function; (c) generating an authentication response based on a first key generated by a legacy subscriber identity module in the mobile terminal; and (d) providing the first key from the subscriber identification module to the mobile terminal in response to receiving the random number received in the authentication challenge. The method may further include generating a first key at the subscriber identification module using the random number, the pre-shared secret key, and an algorithm. The pre-shared secret key and the algorithm are both stored in the subscriber identification module and a network database communicatively coupled to the bootstrapping server function. In some embodiments, the first key may be generated using additional parameters transmitted in the authentication challenge and response.

The method may further include calculating, at the mobile terminal, a third key based on the first key. The third key may also be independently computed at the bootstrapping server function based on a second key provided by the network database to the bootstrapping server function. The third key is sent from the bootstrapping server function to the requesting network application function such that the mobile terminal and the network application function share the third key.

Another feature provides a mobile terminal, comprising: (a) a wireless communication interface to communicate with the bootstrapping server function; (b) a subscriber identification module for storing a pre-shared secret key and an algorithm; and (c) processing circuitry configured to operate a legacy communication protocol and authenticate the mobile terminal with the bootstrapping server function with the challenge response protocol. The processing circuit may operate by (a) receiving an authentication challenge containing a random number from a bootstrapping server function; (b) determining whether the authentication challenge originated from the bootstrapping server function based on previously obtained bootstrapping server credentials associated with the bootstrapping server function; and (c) generating an authentication response comprising the first parameter calculated with a first key, wherein the first key is generated from a random number, a pre-shared secret key, and an algorithm. Further, the processing circuit may (a) generate a third key based on the first key and other parameters transmitted in the authentication challenge and response; and (b) generating a message authentication code calculated using the third key. The message authentication code may be included in an authentication response to the bootstrapping server. The subscriber identification module may generate the first key based on the random number, the pre-shared secret key, and an algorithm.

The subscriber identification module may be a Subscriber Identity Module (SIM) compatible with Global System for Mobile (GSM) protocols. A pre-shared secret key may also be employed to allow the mobile terminal to establish communications over a conventional wireless network.

Drawings

Fig. 1 is a block diagram illustrating a communication system in which a bootstrapping server and a legacy mobile terminal can mutually authenticate each other according to one embodiment.

Fig. 2 is a block diagram illustrating a mobile terminal configured to perform mutual authentication with a bootstrapping server function operating on a communication network according to one implementation.

Fig. 3 is a block diagram illustrating a network device configured to perform bootstrapping server function for authenticating a mobile station according to one implementation.

Fig. 4 illustrates a method for implementing a challenge response mechanism that mutually authenticates a legacy mobile terminal and a bootstrapping server function, according to one embodiment.

Fig. 5 illustrates a general method of authenticating a mobile terminal using a bootstrapping server function and authentication of the server function according to one embodiment.

Fig. 6 illustrates a method of performing a challenge-response protocol between a GSM-compliant mobile terminal and a bootstrapping server function to securely authenticate each other for network application functions according to one embodiment.

Fig. 7 illustrates an alternative method of performing a challenge-response protocol between a GSM-compliant mobile terminal and a bootstrapping server function to securely authenticate each other for network application functions according to one embodiment.

Detailed Description

In the following description, specific details are given to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the embodiments.

Furthermore, it is noted that the embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. Further, the order of operations may be rearranged. When an operation of a process is completed, the operation is terminated. A process may correspond to a method, a function, a procedure, a subroutine, etc. When a procedure corresponds to a function, it terminates the return corresponding to the function to the calling function or the main function.

Further, a storage medium may represent one or more devices for storing data, including Read Only Memory (ROM), Random Access Memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and/or other machine-readable media for storing information. The term "machine-readable medium" includes, but is not limited to portable or fixed storage devices, optical storage devices, wireless channels and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, or a combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage device. The processor may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or a combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, etc.

In the following description, specific terminology is used to describe certain features of one or more embodiments of the invention. For example, the terms "mobile terminal," "user equipment," "mobile device," "wireless device," and "wireless mobile device" may be used interchangeably to refer to a mobile telephone, pager, wireless modem, personal digital assistant, Personal Information Manager (PIM), palmtop computer, laptop computer, and/or other mobile communications/computing device that communicate, at least in part, over a cellular network. The term "legacy" is used to refer to networks, protocols, and/or mobile devices that are pre-3G devices, operate pre-3G protocols, or employ GSM-compatible SIMs or CDMA-compatible authentication modules or MN-AAA authentication modules. Furthermore, the term "subscriber authentication module" is used to refer to a GSM-compatible Subscriber Identity Module (SIM), a CDMA-compatible authentication module, or a MN-AAA authentication module, or any other module commonly included in mobile terminals to identify the mobile terminal for accessing a wireless network.

One feature provides a way to extend the universal authentication architecture to support legacy systems so that subscribers holding GSM Subscriber Identity Modules (SIMs) can be provisioned with keys for mobile applications without replacing the SIM with a 3G, UMTS-compliant User Service Identity Module (USIM).

Fig. 1 is a block diagram illustrating a communication system in which a bootstrapping server and a legacy mobile terminal can mutually authenticate each other according to one embodiment. The network architecture 100, such as a GSM-compliant or CDMA 2000-compliant communication system, includes a Mobile Terminal (MT)102, a Home Location Register (HLR)104, a Bootstrapping Server Function (BSF)106, and at least one Network Application Function (NAF) 108. HLR104 and BSF 106 may be hosted in one or more network devices and/or servers that are part of the infrastructure of network architecture 100. HLR104 includes a database containing mobile subscriber information for wireless carriers including the International Mobile Subscriber Identity (IMSI) of each MT102 belonging to a subscriber. The IMSI is a unique number associated with the MT102 in the network. The IMSI is also stored in the Subscriber Identity Module (SIM) of each MT102 and is sent by the MT to the network HLR to look up information about the MT 102.

MT102 may be a conventional wireless communication device that registers with or connects to a service provider using a predefined protocol (e.g., a pre-3G protocol) to communicate over network 100. In some embodiments, this registration with the service provider may involve authenticating the MT102 using a pre-shared secret key (e.g., stored in a GSM SIM, CDMA authentication module, or other legacy module). For example, the MT102 may contain a GSM-compatible SIM or a CDMA 2000-compatible authentication module to enable the MT102 to operate in a GSM or CDMA2000 network and to allow it to be authenticated by the network for wireless communication.

Once the MT102 is authenticated by the service provider for communication over the network, one aspect of the present invention adds another authentication layer to implement secure network applications. This additional authentication mechanism is independent of the underlying network operator or the operator's authentication mechanism. The additional authentication layer uses existing keys in the SIM or authentication module along with novel protocols to establish keys that are independent of network or operator security services. This new authentication mechanism provides keys for authentication or other purposes that are shared between the MT102 and a particular NAF 108 and distributed to the NAF via the BSF 106. The NAF 108 may be an application running on a networked device, such as a business service application and/or a location-based service.

When the MT102 is ready to start using a network application, it initiates contact with the NAF 108 over the communication link 110. If the MT and NAF have not shared the appropriate keys, the NAF 108 issues a request for an authentication key to the BFS 106 via the interface 112. If it has not done so, the MT102 and the BSF 106 agree on a key with the MT102 over the authentication link 114.

A Diffie-Hellman key exchange may be employed as part of the key agreement procedure between the MT102 and the BSF 106. Diffie-Hellman key exchange is an encryption protocol that allows two parties that have no prior knowledge of each other to jointly establish a common secret key over an insecure communication channel. In one application, this common secret key may then be used to encrypt subsequent communications using a symmetric key cipher.

However, only then, conventional Diffie-Hellman key exchange algorithms are vulnerable to "man-in-the-middle" attacks, which can undermine the security of such algorithms. This is particularly important in the case of exchanging information over the wireless medium to perform commercial and/or confidential services between the MT102 and the NAF 108.

One feature of the present invention provides a protocol that enables the BSF 106 and the MT102 to agree on a common or shared secret key in a manner that is not susceptible to inherent GSM and/or CDMA2000 vulnerabilities. Specifically, the MT102 is first provided with a digital certificate to authenticate the BSF 106. This allows communications from the BSF 106 to the MT102 to be digitally signed or carried in a server-authenticated channel, thus allowing the MT102 to be confident that the keys or parameters received during the authentication process are from the BSF 106 and not from another entity attempting to become a "man-in-the-middle" or conduct a replay attack. Thus, the present method can be applied to extend the authentication scheme of the 3G generic bootstrapping architecture to protocols other than UMTS AKA, which do not themselves benefit from network authentication.

Fig. 2 is a block diagram illustrating a Mobile Terminal (MT)200 configured to perform mutual authentication with a bootstrapping server function operating on a communication network. The MT 200 includes: processing circuitry 202 (e.g., a processor) coupled to the communication interface 202 to communicate with a wireless network; and a Subscriber Identity Module (SIM) card 204. The processing circuit 202 may be configured to perform some or all of the methods described in fig. 4, 5, 6, and 7. The SIM 204 may contain a secret key Ki, an implementation of GSM authentication, and a key agreement algorithm (i.e., the GSM A3/A8 algorithm), and is inserted in the MT102 containing a public key or digital server certificate of a public key corresponding to a private key in the BSF 106. In particular, the SIM 204 may be a standard conventional smart card configured for use with GSM networks. The public key or server certificate may correspond to an RSA public key, or other public key techniques that can provide a digital signature, such as DSA (digital signature algorithm), may also be used. The BSF 106 and the MT102 may also share a predetermined generator P of a cyclic group, e.g., a multiplicative subgroup of points in a finite field or elliptic curve, allowing them to employ Diffie-Hellman key exchange. In an alternative embodiment, the MT 200 may include a CDMA2000 compatible authentication module instead of the SIM 204.

Fig. 3 is a block diagram illustrating a network device configured to perform a Bootstrapping Server Function (BSF) for authenticating a mobile station (MT) according to one aspect of the disclosure. The network device 300 includes: processing circuitry 302 (e.g., a processor) coupled to communications interface 306 to communicate with a wireless network; and a memory device 304. The processing circuit 302 may be configured to perform the bootstrapping server function while maintaining keys and/or parameters to implement a Diffie-Hellman key exchange with the MT. For example, the processing circuit 302 may be configured to perform some or all of the methods illustrated in fig. 4, 5, 6, and 7.

Figure 4 illustrates a method for performing a challenge response mechanism that mutually authenticates a mobile terminal with a legacy SIM and a bootstrapping server function, according to one embodiment. This challenge-response mechanism utilizes a public key mechanism to verify the origin of the challenge and a pre-shared secret key to verify the origin of the response.

The Bootstrapping Server Function (BSF) generates an authentication challenge and sends it to the Mobile Terminal (MT)402 under a server-authenticated public key mechanism. The authentication challenge may include a random number (e.g., RAND) and is derived from a pre-shared secret key (e.g., Ki) known to the network database and the subscriber identification module in the MT. For example, the pre-common secret key Ki and a random number (e.g., RAND) may be used to generate secret keys (e.g., SRES and Kc) that are used to generate the authentication challenge parameters. The authentication challenge may also include additional parameters, such as a timestamp, other random numbers, identity information, a Diffie-Hellman public key, etc., and is sent over a digitally signed and/or server authenticated channel.

The MT receives the authentication challenge and verifies whether it originates from the BSF 404 based on the bootstrapping server certificate. Such bootstrapping server certificates (e.g., public keys) may have been provided to the MT and BSF at setup, offline, and/or during a previous procedure. The MT formulates a response to the authentication challenge based on a key obtained and/or provided by a subscriber identity module in the MT 406. These secret keys may be generated by the subscriber identification module based on the random number received in the authentication challenge and a pre-shared secret key stored in the subscriber identification module. For example, the random number received in the authentication challenge (e.g., RAND) and the pre-shared secret key stored in the MT's subscriber identity module (e.g., Ki) may be used to generate keys (e.g., SRES and Kc) that are used to generate the authentication response parameters. Further, in some embodiments, the MT may also use additional parameters (e.g., timestamp, other random numbers, identity information, Diffie-Hellman public key) to calculate the key to formulate the authentication response.

The BSF receives the authentication response and verifies whether it originated from the MT based on secret keys (e.g., SRES and Kc) independently obtained by the bootstrapping server function 408. For example, the BSF may use secret keys (e.g., SRES and Kc) generated by a network database based on the random number RAND and a pre-shared secret key (e.g., Ki). Thus, the bootstrapping server certificate is used by the MT to verify the origin of the challenge, while the keys (e.g., SRES and Kc) are used by the BSF to verify the origin of the response. This ensures that no attacks initiated by third parties occur.

Through verification and independent calculation of the keys (e.g., SRES and Kc), a common key for the MT and BSF can be calculated. An application key may be generated at the mobile terminal and the bootstrapping server that may be provided to the requesting network application function by the bootstrapping server to enable secure communications 410 between the mobile terminal and the network application function. For example, the common key or an application key derived from the common key may be sent by the BSF to a requesting Network Application Function (NAF) so that the NAF and MT share a key that can be used to secure communications between the NAF and MT.

Fig. 5 illustrates a method of authenticating a mobile terminal using a bootstrapping server function and authentication of the server function according to one embodiment of the present invention. The method may be implemented when the network application function wishes to agree on a key with the Mobile Terminal (MT) before initiating network application traffic. For example, GSM Authentication and Key Agreement (AKA) is based on a challenge-response protocol. The secret key Ki and the two algorithms A3 and A8 are stored in the Subscriber Identity Module (SIM) inside the MT and in the network Home Location Register (HLR)/authentication center (AuC). The SIM is designed to be tamper-proof and contains secret data and algorithms that cannot be easily read by the user.

A request for a key is generated by the MT with a legacy SIM inside and sent to a Bootstrapping Server Function (BSF) 502. The BSF contains authentication information 504 from the MT of the network HLR or AuC. For example, the HLR/AuC selects a 128-bit random challenge RAND, which is input with Ki into two algorithms A3 and A8 to produce 32-bit output SRES and 64-bit output Kc, respectively. The BSF is then provided with the triplet (RAND, SRES, Kc) of SIMs corresponding to the requesting MT to authenticate the SIM inside the requesting MT. The BSF then challenges the MT with the random number RAND (generated by the HLR) and other parameters 506.

The MT verifies whether the authentication challenge originates from the given BSF based on the bootstrapping server certificate 508. This verification may be performed, for example, using the public key of the BSF or a digital server certificate that has been provisioned in the MT. If the authentication challenge is not from the expected BSF, the process terminates. Otherwise, an authentication response to the challenge is formulated based on a secret key provided by the SIM of the MT 510. For example, the MT passes the random number RAND to the SIM (in the MT), which computes one or more secret keys (SRES and Kc) using a pre-shared secret key Ki and the random number RAND with algorithms A3 and A8. The secret keys SRES and Kc are then provided to the MT to formulate an authentication response. In one implementation, the secret keys SRS and Kc may be used to calculate a message authentication code, or to derive or encrypt one or more parameters, which are sent as part of an authentication response.

An authentication response is sent from the MT to the BSF 512. The BSF then verifies the origin of the authentication response based on the independently obtained secret key 514. For example, one or more parameters in the authentication response from the MT may be verified using SRES and Kc obtained from the HLR (in the triplet corresponding to the random number RAND and the pre-common secret key Ki). For example, the BSF may independently calculate a message authentication code (or other parameters in the authentication response) using the random number RAND, SRES, and/or Kc received from the HLR. If the parameters (e.g., message authentication codes) computed by the MT and BSF match, then the origin of the authentication response is verified.

In an alternative implementation, the MT may calculate the third key using one or more secret keys (SRES and Kc obtained from the SIM) and other parameters (obtained from the authentication challenge or response or from the SIM). This third key is then used to formulate an authentication response (e.g., to calculate a message authentication code). Since the BSF knows the same keys and/or parameters as the MT, the BSF can also calculate the same keys. Thus, the BSF can verify whether the authentication response originated from the MT.

Once the authentication response is verified, the BSF and MT independently calculate a common key based on one or more keys and/or parameters (e.g., SRES, Kc, and/or other parameters) known to both the BSF and MT 516. This common key may then be provided to the requesting NAF to establish secure communications or traffic between the MT and the NAF 518.

The MT authenticates transmissions from the BSF by means of a public key mechanism. The BSF challenges the MT with a random number RAND and is assured that it possesses the corresponding secret keys SRES and/or Kc in order to authenticate transmissions from the MT. Thus, the BSF and the MT mutually authenticate in order to share information from which a key can be derived for bootstrapping.

Fig. 6 illustrates a method of performing a challenge-response protocol between a GSM-compatible mobile terminal 608 and a bootstrapping server function 604 in order to securely authenticate each other for network application functions according to one embodiment. GSM Authentication and Key Agreement (AKA) is based on a challenge-response protocol. For bootstrapping based on a traditional SIM, the HLR/AuC and SIM perform similar calculations based on the existing secret key Ki and GSM algorithms A3 and A8. In the GSM protocol, the secret key Ki and the authentication algorithms A3 and A8 are stored in a Subscriber Identity Module (SIM) smart card and are stored by the network HLR 602. The SIM608 is designed to be tamper-proof and contains data and algorithms that cannot be easily read by a user. In general, wireless services are established with the network using secret keys Ki and authentication algorithms A3 and A8.

In one embodiment, the request for the authentication key may be initiated by the MT 606 retrieving its associated International Mobile Subscriber Identity (IMSI)600 from its SIM608 and sending it to the Bootstrapping Server Function (BSF) 604. In case BSF 604 can verify whether IMSI 600 belongs to an MT of a subscribed network, BSF 604 sends IMSI 600 to HLR 602. HLR 602 may be operated by a service provider for a subscriber whose SIM is contained in MT 606. For example, the HLR 602 selects a 128-bit random challenge RAND along with a pre-shared secret key Ki and uses it as input to two algorithms A3 and A8 to generate a 32-bit output signed response SRES and a 64-bit output secret key Kc, respectively. Next, HLR 602 provides a triplet (RAND, SRES, Kc) to BSF 604, which corresponds to SThe identity of the IM608 is IMSI 600. The BSF 604 generates a random secret exponent x and computes a Diffie-Hellman public key P^xWhere P is the generator of the cyclic group previously provided to both the BSF 604 and the MT 606, such as a multiplicative group of finite fields or an additive group of elliptic curves. Next, the BSF 602 combines the triplets (RAND, P)^xSIG)610 is sent to the MT 606, where SIG is a digital signature computed using the BSF 604 RSA private key. Message 610 may be further enhanced to include other server-authenticated parameters, such as a service identifier.

MT 606 receives triplet (RAND, P)^xSIG)610 and verifies SIG using BSF 604 digital certificate. Assume that the MT 606 is provided with a digital certificate to enable it to authenticate data transmitted from the BSF 604. If the data is deemed to originate at the BSF, the MT 606 generates a random number y and calculates P^y. The MT 606 also passes the RAND 612 to the SIM608, which SIM608 returns a pair (SRES, Kc)614 generated based on RAND and Ki to the MT 606. If the SIM608 is authentic, it should generate the same SRES and Kc as the HLR 602. Then, MT 606 calculates P encrypted with SRES and Kc^yAuthenticates the code MAC and sends a response (P) to BSF 604^yMAC) 616. This response 616 may be further enhanced to include other parameters, such as a traffic identifier, by which the MAC is calculated.

BSF 604 receives P^yAnd verifies the MAC using the SRES and Kc it received in the authentication triplet from HLR 602. If this MAC is correct, it verifies that the MT 606 owns the correct SIM608, and can send an acknowledgement message 618 to the MT 606.

In this embodiment, the MT 606 and BSF 604 thus perform mutually authenticated Diffie-Hellman key exchanges, and compute the key p separately therefrom^xyA agreement is reached. The key for further communication may then be calculated, for example, as p^xyMay contain further information known to both the MT and the BSF, such as identity information, RAND, SRES and Kc. After the Diffie-Hellman calculation is performed or the resulting secret key is stored in the MT 606Not in the SIM608, this key p should be deleted if the SIM608 is removed from the MT or a different SIM608 is used to start the MT^xyAnd the resulting agreed upon key.

Note that this protocol does not have the standard weakness due to GSM, provided the MT 606 does not support algorithm a 5/2. The a5/2 algorithm allows for quasi-instantaneous cracking in the GSM protocol that could disrupt the above protocol. However, the a5/2 algorithm is being phased out in the 3GPP release 6 specification.

Further note that the man-in-the-middle trying to attack the protocol cannot change the initial challenge due to SIG (RAND, P)^xSIG), an attacker cannot insert his own P^zOr use a different RAND. It can replay these messages at most, but it cannot impersonate a BSF, since any replay is equivalent to using a short Diffie Hellman. Conversely, if the BSF ensures that the RAND used is new from one use of this protocol to the next and that the response (P) is received in a short period of time (P)^yMAC), then the attacker does not have the opportunity to derive SRES and Kc by other means, such as challenging with RAND in a typical GSM scenario and attacking the a5/1 algorithm to derive the keys.

Fig. 7 illustrates an alternative method of performing a challenge response protocol between a legacy Mobile Terminal (MT)706 supporting a GSM-compliant subscriber identity module 708(SIM) and a Bootstrapping Server Function (BSF)704 in order to securely authenticate each other and agree on keys for Network Application Functions (NAFs), according to one embodiment. Similar to the method in fig. 6, the request for an authentication key may be initiated by the MT 706 sending its associated IMSI 700 from its SIM 708 to the BSF 704. In case BSF704 can verify whether IMSI 700 belongs to an MT subscribed to the network, BSF704 sends the IMSI 700 to HLR 702. The HLR 702 then selects and provides a triplet (RAND, SRES, Kc) to the BSF704, which corresponds to the identity IMSI 700 of the SIM 708. For example, RAND may be a 128-bit random number and Ki a pre-common secret full key Ki, and may be used as input to two algorithms A3 and A8, which algorithms A3 and A8 generate a signed response SRES (e.g., 32-bit number) and a secret key Kc (e.g., 64-bit number), respectively. It is assumed that the MT 706 is provided with a public key or digital certificate that enables it to authenticate data transmitted from the BSF 704.

The BSF704 receives triplets (RAND, SRES, Kc) from the HLR 702. The BSF704 then computes the digital signature SIG of the RAND (and possibly other parameters such as a timestamp, sequence number, random seed, or identity information) using a public key based mechanism that enables the MT 706 to authenticate the source of the data received from the BSF 704. The BSF704 transmits the RAND and SIG 710 to the MT 706. Upon receiving the (RAND, SIG)710, the MT 706 verifies the SIG using the digital certificate of the BSF 704. If the data is deemed to be from the BSF704, the MT 706 sends RAND 712 to the SIM 708 to retrieve the corresponding parameters SRES and Kc. That is, the SIM 708 generates pairs of SRES and Kc by using the pre-shared secret keys Ki and RAND as inputs to the A3 and A8 algorithms it already possesses. The MT 706 may then generate a key PSK, encrypt the PSK under a public key based mechanism, and apply a message authentication code MAC to the result. Further parameters such as a timestamp, sequence number, random seed or identity information may be included in the response. The MAC may be based on a function or algorithm that may contain Kc and SRES as input parameters (known to both MT 706 and BSF 704) and is used to verify to BSF704 that MT 706 possesses the correct SIM 708. Note that the operations of public key based encryption of data and encryption of MAC with SRES and Kc may be performed in either order. MT 706 then sends (encrypted PSK, MAC)716 to BSF704, and BSF704 verifies that MT 706 possesses the correct SRES and Kc by verifying the MAC. The MAC is verified by recalculating the MAC using the SRES and Kc received by BSF704 from HLR 702 and comparing it with the MAC received from MT 706. If the MAC is deemed to be correct, the PSK is deemed to have originated from the MT 706 and the SIM 708, and an acknowledgement or acceptance 718 is sent to the MT 706. Thus, this PSK is agreed upon between MT 706 and BSF704, or further key derivation may be made using PSK, Kc, SRES, identity information, and possibly other parameters.

The challenge response mechanism described in fig. 6 and 7 for GSM-based mobile terminals may also be implemented on other types of mobile terminals. For example, the present invention may operate on CDMA2000 compatible networks and Mobile Terminals (MTs). In such an implementation, a CDMA2000 compliant mobile terminal contains a CDMA2000 authentication module, UIM, or RUIM to agree on a pre-shared secret key that can be used to achieve security for network applications. In one embodiment, the pre-shared key may be generated using an authenticated Diffie Hellman algorithm, where the public parameter P provided by the BSF is authenticated via a public key digital signature mechanism (i.e., a bootstrapping server certificate known to the MT)^xAnd authenticates the parameter P provided by the MT by adding a message authentication code^yWith the message authentication code having a key of material such as SMEKEY from CAVE (cellular authentication and voice encryption algorithm) or MN-AAA authenticator (mobile node authentication, authorization and accounting). It is assumed that the MT is provided with a public key or digital certificate enabling it to authenticate digitally signed messages from the BSF, and a pre-shared secret key Ki and an authenticator identifier IMSI, both known to the authenticator module and the HLR.

Those skilled in the art will appreciate that this approach is equally applicable to environments where merchant authentication is based on CAVE, and as such provides the advantage that these bootstrapping operations can always be performed using symmetric and RSA operations, and can therefore provide implementation advantages over protocols requiring support for both Diffie Hellman and RSA.

One or more of the components and functions illustrated in fig. 1, 2, and/or 3 may be rearranged and/or combined into a single component or implemented in several components without departing from the invention. Additional elements or components may also be added without departing from the invention. The apparatus, devices, and/or components illustrated in fig. 1, 2, and/or 3 may be configured to perform the methods, features, or steps illustrated in fig. 4, 5, 6, and/or 7.

It should be noted that the above embodiments are only examples and should not be construed as limiting the invention. The description of the embodiments is intended to be illustrative, and not to limit the scope of the claims. Accordingly, the present teachings may be readily applied to other types of apparatuses and many alternatives, modifications, and variations will be apparent to those skilled in the art.

Claims

1. A method for authenticating a legacy mobile terminal for communication with a network application function, comprising:

generating, at a bootstrapping server function, an authentication challenge that includes a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key, and a private key;

sending the authentication challenge to the legacy mobile terminal, wherein the legacy mobile terminal verifies an origin of the authentication challenge based on a previously obtained bootstrapping server digital certificate associated with the bootstrapping server function;

receiving, at the bootstrapping server function, an authentication response that includes a second random number and a second parameter computed with a copy of the private key, wherein the copy of the private key was generated at the legacy mobile terminal based on the first random number and a pre-shared secret key stored in a subscriber identity module in the legacy mobile terminal;

verifying whether the authentication response originates from the legacy mobile terminal by re-computing the first parameter at the bootstrapping server function based on a second key provided to the bootstrapping server function; and

generating a mutual authentication key at the bootstrapping service function based on the first random number, the second random number, and the private key.

2. The method of claim 1, wherein the subscriber identification module is one of a Global System for Mobile (GSM) user identity module (SIM) or a CDMA2000 authentication module.

3. The method of claim 1, further comprising:

comparing a second parameter received in the authentication response with the first parameter recalculated by the bootstrapping server function, wherein the authentication response is deemed to have originated from the legacy mobile terminal if the first parameter and the second parameter are the same.

4. The method of claim 1, further comprising:

the private key is obtained from a home location register communicatively coupled to the bootstrapping server function.

5. The method of claim 1, wherein the private key and the copy of the private key are generated based on the same security algorithm and pre-shared secret key known to the subscriber identification module in the legacy mobile terminal and a network database communicatively coupled to the bootstrapping server function.

6. The method of claim 1, wherein the copy of the private key provided to the bootstrapping server function is generated based on a copy of the pre-shared secret key stored outside the legacy mobile terminal and the random number in the authentication challenge.

7. The method of claim 1, wherein the second parameter of the authentication response includes a message authentication code that the bootstrapping server function uses to verify the origin of the authentication response.

8. The method of claim 1, further comprising:

and sending the mutual authentication key from the self-starting server function to the requested network application function, so that the conventional mobile terminal and the network application function share the mutual authentication key to ensure the communication security therebetween.

9. A network device, comprising:

a communication interface to communicate with a wireless legacy mobile terminal; and

a processing circuit coupled to the communication interface and configured to implement a bootstrapping server function to authenticate a legacy mobile terminal by:

generating, at the bootstrapping server function, an authentication challenge containing a random number, the authentication challenge including a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key, and a private key;

receiving, at the bootstrapping server function, an authentication response that includes a second random number and a second parameter computed with a copy of the private key, wherein the copy of the private key was generated at the legacy mobile terminal based on the first random number and a pre-shared secret key stored in a legacy subscriber identity module in the legacy mobile terminal;

generating a mutual authentication key at the bootstrapping server function based on the first random number, the second random number, and the private key.

10. The network device of claim 9, wherein the legacy subscriber identification module is one of a Global System for Mobile (GSM) user identity module (SIM) or a CDMA2000 authentication module.

11. The network device of claim 9, wherein the processing circuit is configured to implement the bootstrapping server function to authenticate the legacy mobile terminal by:

calculating, at the bootstrapping server function, a mutual authentication key based on the copy of the private key, wherein the mutual authentication key is also independently calculated at the legacy mobile terminal based on the private key; and

sending the mutual authentication key from the bootstrapping server function to the requesting network application function such that the legacy mobile terminal and network application function share the mutual authentication key.

12. The network device of claim 9, wherein the processing circuit is further configured to implement the bootstrapping server function to authenticate the legacy mobile terminal by:

comparing a second parameter received in the authentication response with a first parameter calculated by the bootstrapping server function, wherein the authentication response is considered to originate from the legacy mobile terminal if the first parameter and the second parameter are the same.

13. A network device for implementing a bootstrapping server function to authenticate a legacy mobile terminal, comprising:

means for generating an authentication challenge based on a random number, the authentication challenge comprising a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key, and a private key;

means for sending the authentication challenge to the legacy mobile terminal, wherein the legacy mobile terminal verifies an origin of the authentication challenge based on a previously obtained bootstrapping server digital certificate associated with the bootstrapping server function;

means for receiving an authentication response from the legacy mobile terminal, the authentication response including a second nonce and a second parameter computed based on a copy of the private key, wherein the copy of the private key is generated at the legacy mobile terminal based on the first nonce and a pre-shared secret key stored in the subscriber identity module in the legacy mobile terminal;

means for generating a mutual authentication key at the bootstrapping service function based on the first random number, the second random number, and the private key; and

means for determining whether the authentication response originates from the legacy mobile terminal.

14. The network device of claim 13, wherein the means for determining whether the authentication response originated from the legacy mobile terminal comprises: a copy of the private key to verify the second parameter of the authentication response, wherein the copy of the private key is derived from the pre-shared secret key and the random number and other parameters transmitted within the authentication challenge and authentication response.

15. A method for authenticating a network application function for communication with a legacy mobile terminal, comprising:

receiving an authentication challenge at the legacy mobile terminal, the authentication challenge comprising a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key, and a private key;

generating a mutual authentication key at the legacy mobile terminal based on the first random number, the second random number, and the private key;

verifying whether the authentication challenge originated at a bootstrapping server function based on a previously obtained bootstrapping server digital certificate associated with the bootstrapping server function; and

sending an authentication response to the bootstrapping server function, the authentication response including the second nonce and a second parameter computed with a copy of the private key, wherein the copy of the private key was generated at the legacy mobile terminal based on the first nonce and a pre-shared secret key stored in a subscriber identity module in the legacy mobile terminal.

16. The method of claim 15, further comprising:

providing the private key from the subscriber identification module to the legacy mobile terminal in response to receiving the random number received in the authentication response.

17. The method of claim 16, wherein the first key is generated using additional parameters transmitted in the authentication challenge and response.

18. The method of claim 15, wherein the subscriber identification module is one of a Global System for Mobile (GSM) user identity module (SIM) or a CDMA2000 authentication module.

19. A legacy mobile terminal, comprising:

a wireless communication interface to communicate with a self-starting server function; and

processing circuitry configured to operate a legacy communication protocol and authenticate the legacy mobile terminal with a challenge response protocol with a bootstrapping server function by:

receiving an authentication challenge from the bootstrapping server function, the authentication challenge comprising a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key and a private key;

verifying whether the authentication challenge originated from the bootstrapping server function based on a previously obtained bootstrapping server digital certificate associated with the bootstrapping server function, an

Sending an authentication response to the bootstrapping server function, the authentication response including the second nonce and a second parameter computed with a copy of the private key, wherein the copy of the private key was generated at the legacy mobile terminal based on the first nonce and a pre-shared secret key stored in the subscriber identity module in the legacy mobile terminal.

20. The legacy mobile terminal of claim 19, further comprising:

a subscriber identification module coupled to the processing circuit, the subscriber identification module for storing the pre-shared secret key and algorithm.

21. The legacy mobile terminal of claim 20, wherein the subscriber identification module generates the private key based on the random number, the pre-shared secret key, and the algorithm.

22. The legacy mobile terminal of claim 20, wherein the subscriber identification module is a Subscriber Identity Module (SIM) compatible with Global System for Mobile (GSM) protocols.

23. The legacy mobile terminal of claim 19, wherein the pre-shared secret key is further used to allow the legacy mobile terminal to establish communications over a legacy wireless network.

24. A legacy mobile terminal, comprising:

means for receiving an authentication challenge at the legacy mobile terminal, the authentication challenge comprising a first random number as a first parameter, a public key based on the first parameter, and a signature based on the first random number, the public key, and a private key;

means for generating a mutual authentication key at the legacy mobile terminal based on the first random number, a second random number, and the private key;

means for verifying whether the authentication challenge originated at a particular bootstrapping server function based on a previously obtained bootstrapping server digital certificate associated with the bootstrapping server function; and

means for sending an authentication response to the bootstrapping server function, the authentication response including the second nonce and a second parameter computed with a copy of the private key, wherein the copy of the private key was generated at the legacy mobile terminal based on the first nonce and a pre-shared secret key stored in a subscriber identity module in the legacy mobile terminal.