KR20070100932A - Method and apparatus for providing bootstrapping procedures in a communication network - Google Patents

Abstract

An approach is provided for performing authentication in a communication system. In one embodiment, a key is established with a terminal in a communication network according to a key agreement protocol. The agreed key is tied to an authentication procedure to provide a security association that supports reuse of the key. A master key is generated based on the agreed key. In another embodiment, digest authentication is combined with key exchange parameters (e.g., Diffie-Hellman parameters) in the payload of the digest message, in which a key (e.g., SMEKEY or MN-AAA) is utilized as a password. In yet another embodiment, an authentication algorithm (e.g., Cellular Authentication and Voice Encryption (CAVE)) is employed with a key agreement protocol with conversion functions to support bootstrapping.

Description

Method and apparatus for providing bootstrapping procedures in a communication network

This application is filed February 11, 2005, entitled "Method and Apparatus for Supporting Authentication in a Radio Communication System," US Provisional Application No. 60 / 652,235, April 15, 2005, entitled "Method and Apparatus for Bootstrapping in a Radio Communication." 35 USC§119 (e) provisions to US Provisional Application No. 60 / 671,621, filed under the title "System," and US Provisional Application No. 60 / 651,620, filed February 11, 2005, entitled "Using GAA in Legacy CDMA networks." Claims priority pursuant to, including the entirety of the applications in the form of references.

The present invention relates to communication, and more particularly, to providing an authentication service in a communication system.

Wireless communication systems, such as cellular systems (e.g., spread spectrum systems (CDMA (Code division Multiple Access) networks, etc.) or time division multiplexed access (TDMA) networks), such as the convenience of mobility to the user rich services and functions To provide. This convenience has resulted in a meaningful adoption as a recognized mode of communication for business and personal use by ever-increasing consumers. To facilitate further adoption, the telecommunications industry has agreed to develop the standards of communication protocols that underlie a variety of services and functions, at cost and effort, from manufacturers to service providers. One important area of such efforts involves certification. Authentication plays an important role in ensuring that communication is established between the appropriate users or applications in any communication system. Unfortunately, the implementation of such standards may require modification of other protocols, which can be enormously costly, even if technically feasible.

Thus, there is a need for a method of providing authentication services without requiring modification of existing standard protocols or development of new protocols.

With this and other needs, the present invention is undertaken, and a way of performing an initial authentication (boottrapping) in a communication system more effectively is proposed.

According to one aspect of embodiments of the present invention, an authentication method includes a method for setting a key with a terminal in a communication network according to a key agreement protocol, wherein the terminal is configured to operate using spread spectrum. It is composed. The method also includes linking the agreed-upon key to one authentication procedure to provide a security association that supports key reuse. The method also includes generating a master key based on the agreed key.

According to another aspect of an embodiment of the present invention, an authentication method includes establishing a shared key with a network element in a communication network according to a key agreement protocol, wherein the network element authenticates with an agreed key. Intertwined with the procedure to provide a security association that supports key reuse. The method also includes generating a master key based on the agreed upon key.

According to another aspect of an embodiment of the present invention, an authentication apparatus includes an authentication module configured to set a shared key with a network element in a communication network according to a key agreement protocol, the network element having an agreed key. In conjunction with the authentication procedure, it is configured to provide a security association that supports key reuse, and the authentication module is further configured to generate a master key based on the agreed upon key.

According to yet another aspect of an embodiment of the present invention, an authentication method includes generating a message for authenticating communication with a network element configured to perform bootstrapping. The method also includes setting a password field of the message for the encrypted secret key function; And specifying keying information in the payload of the message, wherein the message is transmitted according to a transport protocol for accessing information over the data network.

According to another aspect of an embodiment of the present invention, an authentication method includes receiving a message from a terminal according to a transport protocol for accessing information through a data network, requesting authentication, and including the message. Includes a password field that is a function of a secret key and a keyload that includes key setting information specifying parameters to determine another secret key. The method also includes generating a master key based on the secret key.

According to another aspect of an embodiment of the present invention, an apparatus for authentication generates a message for authenticating communication with a network element configured to perform bootstrapping, and a password field of a message to be a function of a secret key. It includes an authentication module that is set to set the. The message has a payload containing the new key setting information. This message is sent according to a transport protocol for accessing information over the data network.

According to another aspect, which is for an embodiment of the present invention, an authentication method includes receiving an authentication request specifying a user identity from a terminal. The method also transmits the user ID to a positioning register configured to generate encryption parameters including random secret data based on such user ID, and one secret data generated from the random secret data according to an encryption algorithm. It also includes a step. In addition, the method includes receiving encryption parameters generated from the location register. The method also includes converting encryption parameters into key parameters including an authentication token and an authentication response to generate an authentication vector and transmitting the authentication token to a terminal configured to output the authentication vector. The method also includes ratifying an authentication response from the terminal using the authentication response from the authentication vector; And generating a master key based on the key parameters.

According to another aspect according to an embodiment of the present invention, the authentication method includes generating an authentication request specifying a user ID. The method also includes sending the authentication request to a network element configured to provide bootstrapping, wherein the network element is based on a user ID and a secret generated from the random secret data according to an encryption algorithm. Send the user ID to a location register configured to generate encryption parameters containing the data. The network element converts its encryption parameters into key parameters including an authentication token and an authentication response to generate an authentication vector. In addition, the method includes receiving an authentication token from a network element; And outputting an authentication response based on the authentication token. The method also includes determining a digest response using the authentication response; Sending the digest response to the network element for ratification; And generating a master key based on the key parameters.

According to yet another aspect of an embodiment of the present invention, an apparatus includes an authentication module configured to generate an authentication request specifying a user ID. The apparatus also includes a transceiver configured to send the authentication request to a network element configured to provide bootstrapping, the network element being configured to store a user ID based on the user ID in accordance with random secret data and an encryption algorithm. Send to a positioning register configured to generate encryption parameters including secret data generated from the random secret data. The network element generates an authentication vector by converting its encryption parameters into key parameters including an authentication token and an authentication response. The transceiver is further configured to receive an authentication token from the network element, and the authentication module is further configured to output an authentication vector based on the authentication token to determine the digest response using the authentication response and to validate the digest response by the network element. Generate a master key based on the time key parameters.

Further aspects, features, and advantages of the present invention will become apparent from the following detailed description by simply illustrating a number of specific embodiments and configurations, including the best mode contemplated for carrying out the invention. Will lose. The invention is also capable of other different embodiments, the various details of which can be varied in various and obvious ways. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature and not as restrictive.

The present invention is illustrated by way of example and not by way of limitation, with reference to the accompanying drawings, in which like reference numerals refer to like elements:

1 is a diagram of a wireless communication system supporting General Authentication Architecture (GAA), in accordance with various embodiments of the present invention;

2 is a diagram of an exemplary bootstrapping procedure used in the system of FIG. 1;

3 is a diagram of a bootstrapping procedure utilizing an anonymous Transport Layer Security (TLS) with a Test Handshake Authentication Protocol (CHAP) application, in accordance with an embodiment of the present invention;

4 is a diagram of a bootstrapping procedure using server authentication TLS with a CHAP request, in accordance with an embodiment of the present invention;

5 and 6 are diagrams of bootstrapping procedures supporting key exchange parameters, in accordance with various embodiments of the present invention;

7 and 8 are diagrams of bootstrapping procedures that support key exchange parameters covered by a hash of passwords, in accordance with various embodiments of the present invention;

9 is a diagram of bootstrapping utilizing cellular authentication and voice encryption (CAVE) with one shared secret data (SSD), in accordance with an embodiment of the present invention;

10A and 10B are diagrams of a bootstrapping procedure using CAVE with multiple SSDs, in accordance with an embodiment of the present invention;

11 is a diagram of bootstrapping utilizing CAVE with HTTP Digest Authentication and Key Agreement Protocol (AKA) in accordance with an embodiment of the present invention;

12 is a diagram of hardware that may be used to implement various embodiments of the present invention;

13A and 13B are diagrams of different cellular mobile phone systems that can support various embodiments of the present invention;

14 is a diagram of typical components of a mobile station capable of operating in the systems of FIGS. 13A and 13B, in accordance with an embodiment of the invention;

15 is a diagram of an enterprise network capable of supporting the processes disclosed herein, in accordance with an embodiment of the invention.

In a communication system, an apparatus, method, and software for providing bootstrapping will be described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced with equivalent construction without such details. In other instances, well known structures and devices will be shown in block diagram form in order not to unnecessarily obscure the present invention.

1 is a diagram of a wireless communication system for supporting a generic authentication architecture (GAA) according to various embodiments of the present invention. Although the present invention discusses wireless communication systems using spread spectrum technology, those skilled in the art will recognize that various aspects of the present invention are applicable to any kind of transmission network including wired and wireless systems. In addition, several embodiments of the present invention have been described with reference to Diffie-Hellman and HyperText Transfer Protocol (HTTP); It is envisioned that other equivalent key exchange protocols and communication protocols that support the presentation of resources to resources may be used to practice the present invention.

Initial authentication (ie, bootstrapping) of the Third Generation Project Collaboration (3GPP) Comprehensive Authentication Architecture (GAA) is based on the Authentication and Key Agreement Protocol (AKA). Typically, authentication in Code Division Multiple Access 2000 (CDMA2000) networks is based on the CAVE (Cellular Authentication and Voice Encaryption) algorithm, and CDMA 1x Evolution Data only (EvDo) is a CHAP (Challenge Handshake Authentication). Protocol). For CDMA networks (eg, CDMA 2000 1x Revision C and subsequent amendments), AKA is being adopted by the Third Generation Project Cooperation 2 (3GPP2).

Communication system 100 includes one or more mobile stations (MSs) 101 configured to communicate with one or more base station transceiver subsystems (BTSs) 103. The BTSs 103 are serviced by a base station controller (BSC) 105 that cooperates with a network element capable of providing Bootstrapping Server Functin (BSF) 107. The system 100 also includes a mobile node authentication, authentication and accounting service (MN-AAA) 109, which communicates with a Packet Data Serving Node (PDSN) 111.

According to one embodiment, system 100 provides 3GPP comprehensive authentication scheme functionality within CDMA Ev-Do networks. In particular, the bootstrapping mechanism requires establishing a GAA master secret between the MS 101 and the BSF 107. This master secret is, in one exemplary embodiment, tied to a Challenge Handshake Authentication Protocol (CHAP) based authentication procedure. According to one embodiment of the present invention, one such key negotiation (ie key exchange) method is Diffie-Hellman. This method is further described in Internet Engineering Task Force (IETF) Request For Comment (RFC) 2631, which is hereby incorporated by reference in its entirety.

For example, in a CDMA 1x EvDo network, the MS 101 is authenticated using CHAP specified in IETF RFC 1994 (incorporated herein by reference in its entirety). In the defined CHAP procedure, the network element PDSN 111 sends a challenge to the MS 101, and the MS calculates a response based on the received task and the subscriber's unique secret stored in the MS 101. . This response is sent back to the PDSN 111 with the subscriber ID. The PDSN 111 forwards the received response and ID to the MN-AAA 109 along with the task that the PDSN 111 sent to the MN 101 earlier.

The MN-AAA 109 uses the ID to locate the subscriber's unique secret and verifies that the response sent to the MS 101 is equal to the value of the response produced by the MN-AAA 109. According to the result of this verification, the MN-AAA 109 returns a success or failure notification to the PDSN 111. When the PDSN 111 receives the success message, the MS 101 is successfully authenticated.

It should be noted that the authentication procedure used in the CDMA 1x EvDo network cannot be used directly for the GAA because the secret is only known by the MS and the MN-AAA (similar to the GAA's home subscriber system (HSS)). Thus, the Bootstrapping Server Function (BSF) (which acts like a PDSN) cannot derive a GAA master key from this CHAP secret, which is not provided by MN_AAA (similar to the home subscriber system (HSS) of the GAA structure). Because it does not.

According to one exemplary embodiment, after a key is negotiated between the MS 101 and the BSF 107, the BSF 107 derives the CHAP task from the key negotiation procedure to associate the key negotiation procedure with CHAP authentication. According to various embodiments of the present invention, various methods may be utilized to associate the key negotiation procedure with CHAP. First, the BSF 107 will derive the task from the negotiated key. Second, the BSF 107 also derives the task from key negotiation messages that were sent between the BSF 107 and the MS 101. Third, for example, if the Diffie-Hellman key negotiation was performed during the Transport Layer Security (TLS) handshake, a finished message can be used to derive the task, which is already a TLS hand. This is because the message authentication code (MAC) of the shake messages is included.

When the MS 101 receives the CHAP task, the MS 101 verifies whether the task is actually derived from the key agreement procedure, in order to prevent a mand-in-the-middle attack. MS 101 then calculates the CHAP response and sends it back to BSF 107, which in turn validates the response with MN-AAA 109. If the MN_AAA 109 indicates that the CHAP response is correct, the BSF 107 authenticates the MS 101, and a GAA message secret is established. The GAA master secret may be the agreed key itself or additionally derived from that key.

Alternatively, in order to establish a secret between the MS 101 and the BSF 107, another approach according to one embodiment of the present invention is a server certificate transport layer security where the BSF is authenticated using a server certificate. (TLS) is used. In this case, the CHAP task does not need to be tied to the master secret as above, because the BSF 107 is already authenticated. In such cases (both original point-to-point protocol (PPP) CHAP authentication and the GAA related procedures described above), the MS 101 is authenticated by the server (ie PDSN 111 or BSF 107). If not, no response to CHAP task; Otherwise, there is a potential for man-in-the-middle attacks.

In accordance with one embodiment, the present invention provides a mechanism for agreeing on a master secret between an MS 101 and a network server (BSF 107), which mechanism is a backend server (eg, MN-AAA 109). It is tied to the authentication of the MS 101 for. This approach may preferably be performed to allow the backend server to utilize standardized protocols without modification.

Conventional approaches do not support bootstrapping from CHAP authentication so that the resulting security association can be reused with multiple servers as is done in GAA. One such technique is Diffie-Hellman-Challenge Handshake Authentication Protocol (DH-CHAP), which avoids CHAP authentication by adding new information elements to CHAP protocol messages between the CHAP initiator and responder (ie requiring CHAP change). Describe the specific mechanisms involved in the Hellman key agreement.

In one exemplary embodiment, it is assumed that the original PPP CHAP authentication procedure of the CDMA 1x EvDo network includes a mechanism to prevent an unauthorized server from sending a CHAP task to the MS 101 and receiving its response. Without this mechanism, there is a possibility of an man-in-the-middle attack where the attacker pretends to be the MS 101 and initiates communication with the BSF 107. When an attacker receives a task from the BSF 107, the attacker can forward the task to the actual MS 101, thereby posing the PDSN 111. The MS 101 will generate a response and send it back to the attacker, who will then send it to the BSF 107. If this succeeds, the attacker has successfully created a bootstrapping session and can use GAA credentials with any Network Application Function (NAF).

2 is a diagram of an exemplary bootstrapping procedure utilized in the system of FIG. Although only one user equipment (UE) is shown for illustrative purposes, it should be noted that usually several UEs are used. UEs may also be referred to as mobile devices (eg, mobile phones), mobile stations, and mobile communication devices. The UE may also be a device such as a personal digital assistant (PDA) with a transceiver function or a personal computer with a transceiver function.

In step 201, a UE such as MS 101 sends an HTTP Digest message, GET / HTTP / 1.1 Authorization: Digest username = "<IMPI>", to BSF 107. In response, the BSF 107 sends a 401 Unauthorized message, in step 203. Next, in step 205, the UE sends a message back to the BSF 107 (eg, response = "<RES used as pwd>") containing a portion calculated using the shared information as the shared password. The BSF 107 then provides, at step 207, a 200 OK message specifying the bootstrapping information.

After the bootstrapping procedure, the MS 101 (eg, UE) and the BSF 107 both agreed on key material (Ks), bootstrapping transaction identifier (B-TID), key material lifetime. After the bootstrapping procedure, the key material (Ks) can be used to derive additional application server specific key materials (Ks_NAFs) that can be used with other servers. Ks_NAF and B-TID can be used for the Ua interface to passively authenticate the traffic between the UE and the application server and optionally secure it (ie network application function (NAF)). As an example, Ks is a 256b GAA shared secret (Ks = CK∥IK in 3GPP GAA). The NAF may be an application server that uses GAA for user authentication.

The bootstrapping procedure (i.e., Ub interface) is described in 3GPP TS 33.220, entitled "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GAA); Generic Bootstrapping Architecture), and TS 24.109," Bootstrapping Interface ( Ub) and Network Application Function Interface (Ua); Protocol Details (Bootstrapping Interface (Ub) and Network Application Function Interface (Ua); Protocol Details) ", all of which are incorporated herein by reference. Included in the form of.

3 is a diagram of a bootstrapping procedure utilizing CHAP tasks and anonymous TLS in accordance with an embodiment of the present invention. Under this scenario, reference points Ub and Zh are involved, whereby Ub provides mutual authentication between the MS 101 and the BSF 107, and Zh is between the BSF 107 and the MN-AAA 109. Support exchange of authentication information. As discussed, traditionally the BSF 107 does not have knowledge of CHAP secrets, since only the MS 101 and the MN-AAA 109 own such information. The PDSN 111 only sends the CHAP task to the MN-AAA 109, and the MN-AAA 109 returns the CHAP-response and ID calculated using the CHAP task and the CHAP secret. The MN-AAA 109 may check the CHAP response to determine whether it is a success or a failure. Thus, negotiations on GAA secrets between the MS 101 and the BSF 107 must be reached through other means. In one embodiment of the present invention, the GAA secret is established using an unauthenticated key negotiation procedure, the CHAP authentication is tied to the GAA secret by deriving the CHAP task from the GAA secret, and the MS 101 identifies the GAA secret to the CHAP task. Check that it was used to derive.

In this example, MS 101 includes a security (SEC) module to execute the CHAP protocol and a GAA module to support GAA functions. In step 301, the MS 101 uses an anonymous TLS with a key exchange algorithm such as Diffie-Hellman to establish the BSF 107 and the GAA secret (called "key"). CHAP can then operate within the TLS tunnel. Accordingly, in step 303, the BSF 107 generates a CHAP task from the agreed key: Challenge = KDF (key, "chap-challenge"). The key derivation function (KDF) is, in one exemplary embodiment, provided by the GAA.

The comprehensive key derivation function, by GAA (TS 33.220), is now described. First, a string S is generated by concatenating the input parameters and their associated lengths as follows. The length of each input parameter (in octets) is encoded as a 2-octet string. The number of octets is represented by the number k in the range [0, 65535] for the input parameter Pi. Li is a 2-octet representation of the number k, where the most significant bit of the first octet of Li matches the most significant bit of k, and the least significant bit of the second octet of Li matches the least significant bit of k.

The string S is generated from n input parameters as follows:

S = FC ∥ P0 ∥ L0 ∥ P1 ∥ L1 ∥ P2 ∥ L2 ∥ P3 ∥ L3 ∥ ∥ Pn ∥ Ln

At this time,

FC is a single octet that is used to distinguish different cases of the algorithm,

P0 is a static ASCII encoded string,

L0 is a two octet representation of the length of P0,

P1 ... Pn are n input parameters

L1 ... Ln are 2-octet representations of the corresponding input parameters.

The extracted key is equal to HMAC-SHA-256 calculated for string S using the key Key: derived key = HMAC-SHA-256 (Key, S).

The CHAP task message is then sent by the BSF 107 to the GAA module of the MS 101 inside the TLS tunnel, as in step 305. In step 307, the GAA module verifies whether the received CHAP task is generated from the agreed key. The CHAP task message is then delivered to the SEC module by step 309. Next, the SEC module calculates a CHAP response as in step 311 and transmits the response to the GAA module (step 313). MS 101 now sends a CHAP response to BSF 107 over the TLS tunnel as in step 315.

Then, in step 317, the BSF 107 sends a Request message (eg, a Remote Authentication Dial In User Service (RADIUS) access-request message) to the MN-AAA 109 according to the authentication protocol. RADIUS is described in detail in the Internet Engineering Task Force (IETF) Request For Comment (RFC) 2865 entitled "Remote Authentication Dial In User Service (RADIUS)" (June 2000), which is hereby incorporated by reference in its entirety. Included. The request message specifies the user (or subscriber) ID, task and response. The MN-AAA 109 checks the response by step 319 and sends a RADIUS Access-Anser message (including an ID) to the BSF 107 (step 321). At this time, the BSF 107 obtains the GBA user security settings (GUSS) of the user, as in step 323. GUSS is GAA unique user profile data associated with NAF unique user IDs and powers of attorney stored in a home location register (HLR). The GUSS includes BSF 107 unique information element and application specific user security settings (USSs). In one exemplary embodiment, the USS defines application and subscriber specific parameters; The parameters include an authentication part and an authorization part. The authentication part specifies the user IDs associated with the application, and the delegation part specifies user permissions.

In addition, the BSF 107 sets the GAA master key (Ks = key), generates various bootstrapping parameters (e.g., bootstrapping transaction identifier (B-TID), key material lifetime, etc.) and sets the MN-AAA ( Save data from 109 (step 325). Next, the BSF 107 sends an OK message over the TLS tunnel, as in step 327; The message sent includes, for example, the B-TID and the key material lifetime. In step 329, the GAA module sets the GAA master key and stores: Ks = key, along with the received B-TID and key material lifetime. MS 101 now sends a message to BSF 107 to close the TLS tunnel (step 331).

Through the above process, the system of FIG. 1 provides GAA bootstrapping so that the MS 101 and the BSF 107 can agree on a key, and that key is tied to the CHAP authentication procedure. Compared to Diffie-Hellman (DH) -CHAP, the scheme adopted by the system of FIG. 1 does not require any change to already standardized protocol messages, and is appropriate "hook" in MS 101 and BSF 107. It can be implemented through functions. In addition, DH-CHAP describes one particular way of associating CHAP authentication with a D-H key; The task is derived from the agreed key. The present invention according to various embodiments provides other methods of indirectly associating an external key with internal authentication.

4 is a diagram of a bootstrapping procedure that supports server authentication TLS with a CHAP task, in accordance with an embodiment of the invention. In this alternative embodiment, server authentication TLS is used to establish a GAA secret between the MS 101 and the BSF 107, where CHAP is utilized inside the TLS tunnel. Specifically, in step 401, the MS 101 establishes a server authentication TLS tunnel with the BSF 107. As before, TLS is named 'key'. Next, in step 403, the BSF 107 generates a CHAP task (which does not need to be generated from the server authentication TLS key). The CHAP task message is then sent by the BSF 107 into the TLS tunnel to the GAA module of the MS 101, as in step 405.

The GAA module then delivers the CHAP task to the SEC module in step 407. Subsequently, the SEC module calculates a CHAP response as in step 409 and transmits the response to the GAA module (step 411). The MS 101 then sends the CHAP response to the BSF 107 via the TLS tunnel in step 413.

In step 415, the BSF 107 sends a RADIUS Access-Request message to the MN-AAA 109; The request message specifies the ID, task and response. The MN-AAA 109 checks the response in step 417 and sends a RADIUS Access-Answer message (including an ID) to the BSF 107 (step 419). At this time, the BSF 107 brings the GUSS of the user as in step 421. In addition, the BSF 107 sets the GAA master key (Ks = key), generates various bootstrapping parameters (eg, bootstrapping transaction identifier (B-TID), key material lifetime, etc.), MN- Store data from AAA 109 (step 423).

The BSF 107 then sends an OK message over the TSL tunnel, as in step 425. The sent message includes bootstrapping parameters such as B-TID and key material lifetime. In step 427, the GAA module sets the GAA master key and stores the key along with: Ks = key, received B-TID and key material lifetime. The MS 101 then sends a message to the BSF 107 to close the TLS tunnel in step 429.

5 and 6 are diagrams of bootstrapping procedures that support key exchange parameters (or key setting information) in the payload, in accordance with various embodiments of the present invention. It can be seen that in Hypertext Transfer Protocol (HTTP), there are no existing ways to provide Diffie-Hellman (ie, Key Exchange Protocol) for password protection. The processes of FIGS. 5 and 6 may use the HTTP digest and Diffie-Hellman parameters together to provide Diffie-Hellman for password protection for use in bootstrapping (eg, 3GPP2 architecture). That is, HTTP digests with a password (ie shared secret) in the HTTP payload, and the use of keyed protocol (eg, Diffie-Hellman) parameters, and combinations of the two are provided. The password field is set to be a function of the secret key.

In one embodiment of the present invention, the HTTP Digest message uses a Signaling Message Encryption Key (SMEKEY) or MN-AAA key as a password, a Mobile ID as a user name, and a Diff- Hellman parameters are provided in the HTTP payload. The Diffie-Hellman exchange is protected by a password because the quality of protection "qop (qualit-of-protection)" field in the HTTP digest is set to "auth-int"; As a result, the HTTP payload is included in the digest calculation. Via HTTP payload, Diffie-Hellman parameters can be sent as such; Alternatively, the HTTP payload may be provided password protected. This approach is desirable to allow existing specifications (eg HTTP digest) to be reused. This approach is also similar to 3GPP GAA functionality (eg, HTTP Digest Authentication and Key Agreement Protocol (AKA), Ub interface). In addition, according to various embodiments, this approach can be easily implemented without modifying existing standardized protocols.

3GPP GAA can be used without modification to current CDMA 2000 networks. However, it should be noted that the initial authentication of 3GPP GAA does not support AKA and thus requires adaptation to networks that are adapted only to CAVE or networks based on earlier 3GPP2 versions. Accordingly, a system structure and process are needed to accommodate the CAVE. System 100 according to various embodiments utilizes a translation function to map 3GPP2 CAVE authentication to HTTP Digest AKA; This approach is particularly applicable to pre-CDMA 2000 Rev. C systems.

HTTP Digest authentication allows a client to authenticate itself via a server without having to send the password in plain text rather than a password. This can be done using an "one-way" function or irreversible calculation using the password and random value provided by the server as input values. For HTTP Digest Authentication under the AKA context, the Internet Engineering Task Force, titled "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", which is hereby incorporated by reference in its entirety. See Request for Comment (RFC) 3310 for details.

For purposes of illustration, the bootstrapping procedures of FIGS. 5 and 6 will be described with respect to CDMA 1x networks and CDMA 1x EvDo networks, respectively. In one exemplary embodiment, these bootstrapping procedures are based on X.P0028; Here, the key difference via X.P0028 is that HTTP Digest Deviation is used instead of EAP (Extensible Authentication Protocol) between the UE and BSF 107 (which can be considered Home (H) -AAA). . In addition, only Diffie-Hell for password protection can be used. The password (ie, shared secret) can be a signaling message encryption key (SMEKEY) (CDMA 1x) or an MN-AAA key (CDMA 1xEvDo). A wireless LAN (WLAN) key (WKEY) is generated from its password (details are given in X.P0028). In addition, the WKEY becomes the master key (Ks) of the GAA. HTTP digest is used (as shown in FIGS. 5 and 6). The present invention according to various embodiments shows how CAVE and CHAP can be used in the 3GPP GAA structure for initial authentication.

As shown in FIG. 5, the terminal (eg, mobile station) includes a CAVE module configured to execute the CAVE protocol. In addition, GAA functions are supported by the GAA module. In step 501, the GAA module generates an HTTP Get message sent to the BSF 107; The ID is sent in the "username" field of the original message. This delegation request message, in one exemplary embodiment, includes the fields specified in Table 1 below:

Some of the commands in Table 1 are defined in Table 2:

Command Contents response A string of 32 hexa-digit digits to provide evidence that the user knows the password. username Username in a specific realm digest-uri URI from Request-URI of Request-Line qop Indicates the type of "quality of protection" applied to the message cnonce This is specified when the qop command is sent. The cnonce value is an ambiguously mentioned string value provided by the client and used by both the client and server to avoid selected plaintext attacks, provide mutual authentication, and support some message integrity protection. nonce-count This is specified when the qop command is sent. nc-value is the hexadecimal count of the number of requests (including the current request) that the client sent with the nonce value in this request. For example, upon a first request sent in response to a given nonce value, the client sends "nc = 00000001". The purpose of this command is to allow the server to detect request replay by keeping a copy of it for this count-if the same nc-value is seen twice, the request is replayed. auth-param This command enables further expansion. Unrecognized commands are ignored.

The BSF 107 now generates a RAND as in step 503 and responds with a 401 Not Authorized message (505 multi-steps). Initially, no delegation header is sent to the BSF 107, so the 401 message is used in the response. As shown, the RAND is sent via the "nonce" field (similar to HTTP Digest AKA). RAND and CHAP-Chanllege can also be sent via the HPPT payload. Upon receiving the RAND, the GAA module passes it to the CAVE module as in step 507.

As an example, an Authenticate Response Header is given in Table 3; The related commands are defined in Table 4.

Command Contents realm The string to be displayed to users so that they know which username and password to use. This string may contain the name of the host performing the authentication and the users that may have access. domain List of space-separated URIs to be cited, specifying protected space. The client can use this list to determine the set of URIs to which the same authentication information can be sent: any URI that has a URI in this list as a prefix (after both are complete) is assumed to be in the same protected space. being. If this command is deleted or its value is empty, the client assumes that the protected space contains all the URIs for the responding server. nonce A server specific data string that can be uniquely generated each time a 401 response is made. opaque String of data specified by the server, which can be returned by the client unaltered through the delegation header of subsequent requests with URIs in the same protected space. stale Flag indicating that a previous request from the client was rejected because the nonce value was stale. If stale is TRUE (case insensitive), the client can retry a request with a new encrypted response without prompting the user for a new username and password. If the server only receives a request with a valid digest for the nonce, but the nonce is invalid (which indicates that the client knows the correct username / password), then set the stale to TRUE. If stale is FALSE or any value other than TRUE, or no stale command exists, username and / or password are invalid and new values are obtained. algorithm  A string pointing to the pair of algorithms used to compute the digest and checksum

In step 509, the CAVE module sends an authentication response (denoted "AUTHR") and SMEKEY to the GAA module. The GAA module then sets the mobile station password (MS_PW), as in step 511: MS_PW = SMEKEY H1 '(MS_PW) og ^X mod p, where x is the secret random number generated by the UE.

Next, in step 513, the GAA module sends an HTTP message to the BSF 107 with client payload-Hellman parameters along with the payload. Along with CAVE, the HTTP payload also includes AUTHR. The payload is protected by the HTTP digest, because qop = auth-int; The HTTP payload is also included in the HTTP digest output of the "response" field. Diffie-Hellman parameters can be transmitted or protected on their own. In step 515, the BSF 107 sends an authentication request (“AUTHREQ”) message to the home location register / authentication center (HLR / AC) that verifies the RAND / AUTHR and generates an SMEKEY (step 517). The SMEKEY is sent to the BSF 107 in step 519.

The BSF 107 sets the base station password, as in step 521: BS_PW = SMEKEY H1 '(BS_PW) og ^y mod p, where y is a secret random number generated by the UE. The BSF 107 then generates a GAA master key (Ks) from BS_PW (in a manner similar to that of WKEY).

Next, the BSF 107 now sends an HTTP 200 OK message to the terminal (step 525). Server Diffie-Hellman parameters are sent via an HTTP payload and are protected by an HTTP digest, because qop = auth-int (ie, the HTTP payload is also included in the HTTP digest output of the "respauth" field). According to one embodiment, an authentication information header is provided via a message at step 525, indicating successful authentication through Table 5 below:

The message-qop command indicates the "quality of protection" options applied, whereby the "auth" value indicates authentication and the "auth-int" value indicates authentication with integrity protection.

In step 527, the GAA module generates a GAA master key, Ks from PS_PW (in a similar manner to the procedures for WKEY).

For bootstrapping of CDMA 1 × EvDo, CHAP is utilized (as shown in FIG. 6). Under this scenario, the GAA module generates an HTTP Get message, which is sent to the BSF 107; The ID is sent in the "username" field of the original message. The BSF 107 responds with a 410 message, as in step 603, and in this CHAP case, the CHAP-Challenge is sent in 'nonce' (i.e., the field is just random as in the standard HTTP digest). , CHA {tasks and responses are exchanged between the GAA module and the CHAP module (steps 605 and 607) In step 609, the GAA module sets the following parameters: BS_PW = MN-AAA key; H1 '(BS_PW) og ^x mod p, where x is a secret random number generated by the UE.

At this point, the terminal using the GAA module generates a delegation message and transmits it to the BSF 107 (step 611); This message specifies the following: Digest nonce = "<RAND>", response = "MS_PW used as passwd>", qop = auth-int, .... The HTTP payload is H1 '(MS_PWD) og ^x Include mod p In step 613 the BSF 107 sets the base station password (BS_PW): BS_PW = MN-AAA H1 '(BS_PW) og ^y mod p, where y is the secret random number generated by the UE. The BSF 107 also generates a GAA master key, Ks, from BS_PW.

The BSF 107 then sends a 200 OK message, B-TID and key lifetime specifying H1 '(MS_PWD) og ^y mod p to the GAA module (step 617). In step 619, the GAA module generates a GAA master key, Ks, from MS_PWD. WKEY is set to the GAA master secret (Ks).

7 and 8 are diagrams of bootstrapping procedures that support key exchange parameters that are translated by a hash of passwords, in accordance with various embodiments of the present invention. The bootstrapping procedure of FIG. 7 is similar to the procedure of FIG. 5; That is, steps 701-711 correspond approximately to steps 501-511. Likewise, the procedure of FIG. 8 follows the procedure of FIG. 6, whereby steps 801-809 follow steps 601-609. However, under the scenarios of FIGS. 7 and 8, client diffi-Hellman parameters are covered as a hash of a password (ie, SMEKEY, or MN-AAA Key) and transmitted in the "cnonce" field. This hash can be generated based on standard HTTP digest outputs.

In relation to the procedure of FIG. 7, the message transmitted from the GAA module to the BSF 107 in step 713 includes cnonce = &lt;< H1 '(MS_PWD) og ^x mod p>&quot;. Steps 715-723 follow steps 517-523 of FIG. 5. In step 725 under the current scenario, the BSF 107 sends a 200 OK message specifying H1 '(BS_PWD) og ^y mod p>", ie the server diff-Hellman parameters are transmitted in the" nextnonce "field. (I.e., SMEKEY, or MN-AAA-KEY) The GAA module then generates a GAA master key, Ks, from the PS_PW (step 727).

In relation to the bootstrapping procedure of FIG. 8, the HTTP message of step 811 includes <H1 '(MS_PWD) og ^x mod p> in the cnonce field. 813-819 generally follow steps 613-619, with the exception that the 200 OK message in step 817 specifies nextnonce = "<H1 '(BS_PWD) og ^y mod p>".

9 is a diagram of a bootstrapping procedure utilizing CAVE with one shared secret data (SSD), in accordance with an embodiment of the present invention. The UE (GAA module case) provides the SSD generation function and the authentication function, so the GAA application requires access to SSD_A_NEW and SSD_B_NEW. In step 901, the bootstrapping procedure is initiated with the presentation of the GET request by the UE to the BSF 107 between the UE and the BSF 107. This GET request includes the user ID, and the BSF 107 forwards it to the HLR / AC (step 903). HLR / AC then generates a random SSD (“RANDSSD”) and derives SSD_A and SSD_B using the CAVE algorithm (step 905); This information is passed to the BSF 107 in step 907. In this typical embodiment, the SSD is 128 bits of shared secret data, 64 bits of SSD_A key used for authentication and 64 bits used with other parameters to generate an encryption mask and private long code. SSD-B key. RANDSSD is a 56-bit random task generated in HLR / AC. SSD is the SSD_A key and SSD_B key is connected.

In step 909, the BSF 107 generates the RAND_CHALLENGE and pseudo AKA authentication vectors. As an example, RAND_CHALLENGE is a 32 bit random task. To generate an AKA authentication vector, transformation functions are performed to convert (or map) the CAVE parameters generated in step 905 to AKA parameters, in accordance with an embodiment of the present invention. Conversion functions are used to generate a pseudo AKA authentication vector from one or two sets of CAVE parameters including RANDSSD, SSD_B, and AUTH_SIGNATURE.

As shown in Fig. 9, the conversion functions are erased for the generation of the key, where SSD_A and SSD_B are connected as follows: key = SSD_A∥SS_B∥SSD_A∥SS_B. Next, the key, CAVE parameters, and 3GPP GAA key derivation function (KDF) are used to construct the pseudo AKA authentication vector (RAND, authentication token (AUTN), encryption key (CK), integrity key (IK), and authentication response ( RES)). As an example, a pseudo AKA authentication vector can be generated as follows:

RAND = RANDSSD∥RAND_CHALLENGE∥ZZRAND

AUTN = KDF (key, "3gpp2-cave-autn∥RAND), truncated to 128 bits

CK = KDF (key, "3gpp2-cave-ck" ∥RAND), truncated to 128 bits

IK = KDF (key, "3gpp2-cave-ik" ∥RAND), truncated to 128 bits

RES = KDF (key, "3gpp2-cave-res" AUTH_SIGNATURE), truncated to 128, where ZZRAND is a 40-bit long zero value parameter (to extend RAND to 128 bits).

In step 911, the BSF 107 sends an HTTP 401 message to the UE (eg, MS 101); This message specifies the RAND and AUTN. Upon receiving this message, the MS 101 extracts RANDSSD and RAND_CHALLENGE from the received RAND, as in step 913. MS 101 now generates an SSD_A_NEW key and an SSD_B_NEW key using RANDSSD.

The GAA module sends the RANDSSD and ESN to the SEC module, as in step 915, and the SEC module acknowledges this as an OK message (step 917). The ESN is for example the 32 bit electronic cellular authentication number of the terminal (or mobile station MS).

In step 919, SSD_A_NEW is used to generate the AUTH_SIGNATURE and pseudo AKA authentication vector. The GAA module sends an AUTH_SIGNATURE message to the SEC module as in step 921. The SEC module responds with an appropriate response (AUTH_SIGNATURE) through step 923. Next, in step 925, the GAA module generates a pseudo AKA authentication vector, determines whether the received AUTN is the same as that generated, and calculates a digest response using the RES.

In step 927, the UE sends an HTTP message to the BSF 107 that includes the RES as a password. Again, the BSF 107 validates the digest response using the RES as in step 929 and generates a GAA master key (Ks = CK IK, B-TID, key lifetime, etc.); these data are stored. The BSF 107 imports the GUSS as in step 931; alternatively, this information may be conveyed in step 907.

The BSF 107 then sends a 200 OK message to the MS 101 specifying the B-TID and key lifetime (step 933). At this time, the MS 101 generates a GAA master key, Ks, which is stored alongside the received B-TID and key lifetime (step 935).

10A and 10B are diagrams of a bootstrapping procedure utilizing CAVE with several SSDs in accordance with an embodiment of the present invention. As in the procedure of FIG. 9, the GAA module shown here includes SSD generation and authentication functions; GAA applications also require access to SSD_A_NEW and SSD_B_NEW. In this example, as shown in FIGS. 10A and 10B, in one message sequence, two SSDs and two RANDSSDs can be used to obtain a 256-bit Generic Bootstrapping Architecture (GBA) shared secret (Ks), for example. have. In step 1001, the UE sends a GET request to the BSF 107 to initiate the bootstrapping procedure. The user ID is passed to the HLR / AC from the GET request (step 1003). Next, the HLR / AC generates a RANDSSD and derives a first set of SSD_A and SSD_B (denoted "SSD_A1 and SSD_B1") (step 1005). The RANDSSD (eg, "RANDSSD1") is sent to the BSF 107 along SSD_A1 and SSD_B1 (step 1007).

In steps 1009 and 1011, the user ID is passed back to the HLR / AC, which generates another set of CAVE parameters: RANDSSD2, SSD_A2, and SSD_B2. These parameters are then passed to the BSF 107 (step 1013).

In step 1015, the BSF 107 generates a RAND_CHALLENGE and a pseudo AKA authentication vector. As in the procedure of FIG. 9, transform functions are used to generate a pseudo AKA authentication vector from CAVE parameters (eg, RANDSSD1, SSD_A1, SSD_B1, AUTH_SIGNATURE1, RANDSSD2, SSD_A2, SSD_B2, and AUTH_SIGNATURE2).

The key is generated as follows: key = SSD_A1 ∥ SSD_B1 ∥ SSD_A2 ∥ SSD_B2. This key, CAVE parameters, and GAA key derivation function (KDF) are then used to form the pseudo AKA authentication vector. This vector includes RAND, AUTN, CK, IK, and RES, and is defined as follows, for example:

RAND = RANDSSD1∥RANDSSD2∥ZZRAND

AUTN = KDF (key, "3gpp2-cave-autn∥RAND), truncated to 128 bits

CK = KDF (key, "3gpp2-cave-ck" ∥RAND), truncated to 128 bits

IK = KDF (key, "3gpp2-cave-ik" ∥RAND), truncated to 128 bits

RES = KDF (key, "3gpp2-cave-res" ∥AUTH_SIGNATURE1∥AUTH_SIGNATURE2), truncated to 128 bits.

Server specific data = RAND_CHALLENGE1∥RAND_CHALLENGE2,

Here, ZZRAND is 16 bits long zero data (used to fill up to 128 bits RAND).

In step 1017, the BSF 107 sends an HTTP 401 message specifying the RAND, AUTN and server specific data to the GAA module. Upon receiving this message, the GAA module extracts RANDSSD1, RANDSSD2, RAND_CHALLENGE1 and RAND_CHALLENGE2 from the received RAND and server specific data (step 1019). The GAA module now creates SSD_A_NEW1 and SSD_B_NEW1 together with AUTH_SIGNATURE1 (step 1021).

The GAA module then delivers an SSD generation message (SSD_generation) that includes the RANDSSD1 and the ESN to the SEC module. In response, the SEC module acknowledges as an OK message (steps 1023 and 1025).

In addition, the GAA module forwards the AUTH_SIGNATURE message to the SEC module (step 1027); The AUTH_SIGNATURE message specifies RAND_CHALLENGE1 and SSD_B_NEW1.

In step 1029, the SEC module provides AUTH_SIGNATURE1 to the GAA module. At this time, the GAA module stores SSD_A_NEW1, SSD_B_NEW1, and AUTH_SIGNATURE1 as in step 1031.

The steps 1033-1043 are substantially identical to steps 1021-1031, but differ in that they are a second set of parameters: SSD_A_NEW2, SSD_B_NEW2, and AUTH_SIGNATURE2.

In step 1045, the GAA module generates a pseudo AKA authentication vector and determines whether the received AUTN is the same as generated. The GAA module also outputs a digest response based on the RES.

Next, the UE sends an HTTP message to the BSF 107 containing the RES as a password, as in step 1047. The BSF 107 validates the digest response using the RES as in step 1049, and generates a GAA master key (Ks = CK IK), B-TID, key lifetime, etc .; The BSF 107 also stores its data. In step 1051, the BSF 107 brings the GUSS (this may be sent as another alternative in step 1007).

The BSF 107 sends a 200 OK message to the UE specifying the B-TID and key lifetime, as in step 1053. The UE then generates a GAA master key, Ks, which is stored side by side with the received B-TID and key lifetime (step 1055).

11 is a diagram of a bootstrapping procedure utilizing CAVE with an HTTP Digest AKA, in accordance with an embodiment of the present invention. In this bootstrapping procedure, the message sequence utilizes two SSDs and two RANDSSDs. The user ID is sent to the BSF 107 as in step 1101 and to the HLR / AC in step 1103. In step 1105, the HLR / AC sends SSD1, SSD2, RANDSS1, RANDSS2, and GBA User Security Settings (GUSS) to the BSF 107. In response, the BSF 107 generates two RAND_CHALLENGEs (ie, RAND_CHALLENGE1 and RAND_CHALLENGE2) in step 1107. In step 1109, RANDSSD1, RANDSSD2, RAND_CHALLENGE1, and RAND_CHALLENGE2 are delivered to the UE.

The UE then calculates the following: SSD1, SSD2, AUTH_SIGNATURE1, and AUTH_SIGNATURE2 (step 1111). SSD1 is calculated from RANDSSD1, A-Key and ESN; Likewise, SSD2 is determined from RANDSSD2, A-Key and ESN. AUTH_SIGNATURE1 is calculated from SSD_A1 and RAND_CHALLENGE1; AUTH_SIGNATURE2 is calculated from SSD_A2 and RAND_CHALLENGE2. In step 1113, the UE sends to the BSF 107 that the AUTH_SIGNATURE1 and AUTH_SIGNATURE2 are connected as a password.

Now, as in step 1115, a key is generated in the BSF 107 by connecting CK_UMTS ¦IK_UMTS (= SSD_A1 ∥SSD_A2 ∥SSD_B1 ∥SSD_B2). The BSF 107 also sends a 200 OK message specifying the B-TID and key lifetime to the UE (step 1117). In step 1119, the UE determines Ks.

One of ordinary skill in the art will appreciate that the above processes that support bootstrapping are software, hardware (e.g., general processors, digital signal processing (DSP) chips, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs). It may be understood that the present invention may be implemented through the above), firmware, or a combination thereof. Typical hardware for performing the above-described functions will be described below with respect to FIG.

12 illustrates exemplary hardware in which various embodiments of the present invention may be implemented. Computing system 1200 includes a bus 1201 or other communication mechanism for information communication and a processor 1203 coupled with bus 1201 to process information. Computing system 1200 also includes main memory 1205, such as random acces memory (RAM) or other dynamic storage device, that is coupled to bus 1201 to store information and instructions to be executed by processor 1203. Main memory 1205 may be used to store temporary variables or other intermediate information during execution of instructions by processor 1203. Computing system 1200 may further include a read only memory (ROM) 1207 or other static storage device coupled with bus 1201 to store fixed information and instructions for processor 1203. The storage device 1209, such as a magnetic disk or an optical disk, is connected to the bus 1201 to continuously store information and commands.

Computing system 1200 may be coupled to a display 1211 for displaying information to a user, such as a liquid crystal display or an active matrix display, via bus 1201. An input device 1213, such as a keyboard that includes alphanumeric and other keys, may be coupled to the bus 1201 to transmit information and command options to the processor 1203. Input device 1213 may include cursor control, such as a mouse, trackball, or cursor direction keys, to send direction information and command options to processor 1203 and to control cursor movement on display 1211.

In accordance with various embodiments of the present invention, the processes disclosed herein may be provided by computing system 1200 in response to processor 1203 executing an array of instructions contained in main memory 1205. Such instructions may be read into main memory 1205 from another computer readable medium, such as storage device 1209. Execution of the arrangement of instructions contained in main memory 1205 causes processor 1203 to perform the process steps disclosed herein. One or more processors under a multi-processing configuration may be used to execute the instructions contained in main memory 1205. In other alternative embodiments, a wired circuit may be used in place of or in combination with software instructions to implement an embodiment of the invention. In another example, reset hardware such as FPGSs can be used, where the function and connection topology of the logic gates can be customized at run time, usually by programming memory lookup tables. Thus, embodiments of the invention are not limited to any particular combination of hardware and software.

Computing system 1200 also includes at least one communication interface 1215 coupled with bus 1201. The communication interface 1215 provides two-way data communication coupled with a network link (not shown). Communication interface 1215 transmits and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. In addition, the communication interface 1215 may include peripheral interface devices such as a universal serial bus (USB) interface, a personal computer memory card international association (PCMCIA) interface, and the like.

Processor 1203 may execute the transmit code during reception and / or store the code in storage 1209 or other non- volatile storage to execute later. In this manner, computing system 1209 may obtain application code in the form of a carrier wave.

The term "computer readable medium" as used herein refers to any medium involved in providing instructions to processor 1203 for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1209. Volatile media includes dynamic memory, such as main memory 1205. Transmission media include wires, including bus 1201, including coaxial cable, copper wire, and fiber optics. The transmission medium may take the form of acoustic, optical, or electromagnetic waveforms, such as generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROM, CDRW, DVD, any other optical media, punch card, paper tape, optical mark paper , Any other physical medium with patterns of holes or other optically recognizable indices, RAM, ROM, and EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier, or any other computer readable medium.

Various forms of computer readable media may be involved in the act of providing the instructions to the processor for execution of the instructions. For example, instructions for carrying out at least part of the present invention may be initially carried on a magnetic disk or a remote computer. Under such a scenario, a remote computer loads instructions into main memory and sends them over a telephone line using a modem. The modem in the local system receives the data over the telephone line, converts the data into an infrared signal using an infrared transmitter, and sends the infrared signal to a portable computing device such as a personal digital assistant (PDA) or laptop. An infrared detector on a portable computing device receives the information and commands implied by the infrared signal and loads the data on the bus. The bus carries data to main memory from which the processor retrieves instructions and executes them. Instructions received by main memory may optionally be stored on the storage device before or after being executed by the processor.

13A and 13B are diagrams of other cellular mobile telephony systems that can support various embodiments of the present invention. 13A and 13B illustrate a mobile station (eg, handset) and a base comprising a transceiver installed (as part of a digital signal processor (DSP), hardware, software, integrated circuits, and / or semiconductor devices in the base station and mobile station, respectively). Typical cellular mobile telephone systems are shown that include both stations. As an example, the wireless network supports second and third generation (2G and 3G) services as defined by the International Telecommunications Association (ITU) for International Mobile Telecommunications 2000 (IMT-2000). For purposes of explanation, carrier and channel selection functions of a wireless network have been described in relation to the cdma2000 architecture. As the third generation version of IS-95, cdma2000 is standardized in the third generation joint project 2 (3GPP2).

The wireless network 1300 may be a mobile station 1301 (eg, a handset, terminal, station, unit, device, or other type of user interface (eg, “wearable”) in communication with a base station subsystem (BSS) 1303. Such as a circuit). According to one embodiment of the invention, the wireless network supports 3G services as defined in the ITU for IMT-2000.

In this example, the BSS 1303 includes a base transceiver station (BTS) 1305 and a base station controller (BSF) 1307. While only one BTS is shown, it should be noted that typically several BTSs are connected to the BS via point-to-point links and the like. Each BSS 1303 is linked to a packet data serving node (PDSN) 1309 via a transmission control entity or packet control function (PCF) 1311. Since the PDSN 1309 serves as a gateway to external networks, such as the Internet 1313 or other private customer networks 1315, the PDSN 1309 can safely determine the user's identity and privileges and utilize each user's utilization. It may include an access, authorization and accounting system (AAA) 1317 to track. The network 1315 includes a network management system (NMS) 1331 linked with one or more databases 1333 accessed through a home agent (HA) 1335 that is protected by a home AAA 1335.

Although only one BSS 1303 is shown, it should be noted that several BSSs 1303 are typically connected to a mobile switching center (MSC) 1319. The MSC 1319 supports connection with a circuit switched telephone network, such as a Public Switched Telephone Network (PSTN) 1321. Similarly, it can also be appreciated that the MSC 1319 can be connected to other MSCs 1319 and / or other wireless networks on the same network 1300. The MSC 1319 is generally co-located with a Visitor Location Register (VLR) 1323 database that holds temporary information about active subscribers to the MSC 1319. The data in the VLR 1323 database is in large part a copy of the Home Location Register (HLR) 1325 database that stores detailed subscriber service subscription information. In some embodiments, HLR 1325 and VLR 1323 are the same physical database; The HLR 1325 may be located at a remote location that is accessed via, for example, a signaling system number 7 (SS7) network. An authentication center (AuC) 1327 that includes subscriber-specific authentication data, such as a secret authentication key, is associated with the HLR 1325 to authenticate users. The MSC 1319 is further connected to a Short Message Service Center (SMSC) 1329 that stores short messages and forwards them to / from the wireless network 1300.

During normal cellular telephone system operation, BTSs 1305 receive and demodulate reverse-link signals from sets of mobile units 1301 that make a phone call or other communication. Each reverse-link signal received by a given BTS 1305 is processed within that station. The resulting data is passed to the BSC 1307. The BSC 1307 supports call resource allocation and mobility management functions, including the orchestration of soft handoffs between the BTSs 1305. The BSC 1307 also routes the received data to the MSC 1319, which then provides additional routing and / or switching for the interface with the PSTN 1321. The MSC 1319 is also responsible for call setup, suspension, management of inter-MSC handover and supplementary services, and collection of billing and accounting information. Similarly, wireless network 1300 transmits forward-link messages. PSTN 1321 interfaces with MSC 1319. The MSC 1319 further interfaces with the BSC 1307, which in turn communicates with the BTSs 1305, and the BSTs modulate forward-link signals to transmit to the sets of mobile units 1301.

As shown in FIG. 13B, two main elements of the GPRS infrastructure 1350 are a Serving GPRS Supporting Node (SGSN) 1332 and a Gateway GPRS Support Node (GGSN) 1334. In addition, the GPRS infrastructure includes a PCG (Packet Control Unit) 1336 and a Charging Gateway Function (CFG) 1338 linked with the billing system 1335. GPrS Mobile Station (MS) 1341 utilizes a Subscriber Identity Module (SIM) 1343.

PCU 1336 is a logical network element that is responsible for GPRS related functions such as propagation space interface access control, packet scheduling on the airspace interface, and packet scheduling for packet assembly and reassembly. In general, PCU 1336 is physically integrated with BSC 1345; It may be located with BTS 1347 or SGSN 1332. SGSN 1332 provides equivalent functions with MSC 1348, including mobility management, security, and access control functions, but only within a packet switched domain. In addition, the SGSN 1332 is connected to the PCU 1336 through, for example, a Fame Relay-based interface using the BSS GPRS protocol (BSSGP). Although only one SGSN is shown, it should be noted that several SGSNs 1331 can be used and that the service area can be divided into corresponding routing areas (RAs). The SGSN / SGSN interface allows packet tunneling from old SGSNs to new SGSNs when an RA update occurs during an ongoing Personal Development Planning (PDP) situation. While a given SGSN serves several BSCs 1345, any given BSC 1345 generally interfaces with one SGSN 1332. SGSN 1332 also provides HLR 1351 via SS7-based interface using GPRS Enhanced Mobile Application Part (MAP), or MSC 1349 via SS7-based interface using signaling connection control part (SCCP). Is optionally connected with. The SGSN / HLR interface may allow the SGSN 1332 to provide location updates to the HLR 1351 and retrieve GPRS related subscription information within the SGSN service area. The SGSN / MSC interface enables coordination between circuit switched services and packet data services, such as paging for a voice call to a subscriber. Finally, SGSN 1332 interfaces with SMSC 1335 to enable short messaging functionality over network 1350.

GGSN 1334 is a gateway to external packet data networks, such as the Internet 1313 or other private customer networks 1355. The network 1355 includes a network management system (NMS) 1357 that is linked to one or more databases 1357 that are accessed through the PDSN 1361. The GGSN 1334 may assign Internet Protocol (IP) addresses and authenticate users operating as a Remote Authentication Dial-In User Service host. Firewalls located in the GGSN 1334 also perform a firewall function to restrict unauthorized traffic. Although only one GGSN 1334 is shown, a given SGSN 1332 may interface with one or more GGSNs 1333 to allow user data to be tunneled from network 1350 to the network as well as between two entities. You should know that you can. When external data networks initiate a session over GPRS network 1350, GGSN 1334 queries HLR 1351 about SGSN 1332 currently serving MS 1341.

The BTS 1347 and BSD 1345 manage the air interface, including controlling which mobile station (MS) 1321 accessed when the radio channel. These elements substantially relay messages between the MS 1341 and the SGSN 1332. SGSN 1332 manages communication with MS 1341, sends and receives data, and tracks its location. The SGSN 1332 also registers the MS 1341, authenticates the MS 1341, and encrypts the data sent to the MS 1341.

14 is a diagram of typical components of a mobile station (eg, handset) that may operate in the systems of FIGS. 13A and 13B, in accordance with an embodiment of the present invention. In general, wireless receivers are often defined in terms of front-end and back-end characteristics. The front-end of the receiver surrounds all radio frequency (RF) circuits, while the back-end surrounds all baseband processing circuits. Related internal components of the telephone include a main control unit (MCU) 1403, a digital signal processor (DSP) 1405, and a transceiver unit comprising a microphone gain control unit and a speaker gain control unit. The main display unit 1407 provides a display to the user to support various applications and mobile station functions. The audio function circuit 1409 includes a microphone 1411 and a microphone amplifier for amplifying a speech signal output from the microphone 1411. The speech signal amplified and output from the microphone 1411 is given to a coder / decoder (CODEC) 1413.

The wireless section 1415 amplifies power and converts frequency to communicate via an antenna 1417 with a base station included in a mobile communication system (eg, the systems of FIG. 13A or 13B). The power amplifier (PA) 1419 and transmitter / modulation circuitry selectively respond to the MCU 1403, and the output from the PA 1418 is a duplexer 1421, circulator or antenna as is known in the art. It is connected to the switch.

In use, the user of the mobile station 1401 speaks into the microphone 1411, and his voice is converted into an analog voltage with some detected background noise. The analog voltage is then converted into a digital signal through an analog-to-digital converter (ADC) 1423. The control unit 1403 routes the digital signal to the DSP 1405 for processing such as speech encoding, channel encoding, encryption, and interleaving. In a typical embodiment, the processed speech signals are represented by TIA / EIA / IS-95- of the Telecommunications Industry Association for dual mode wide spread spectrum cellular systems, which are incorporated herein by reference in their entirety. As disclosed in detail in the A Mobile Station-Base Station Compatibility Specification, it is encoded using the cellular transport protocol of Code Division Multiplexed Access (CDMA).

The encoded signals are now routed to equalizer 1425 for compensation of any frequency dependent disturbances that occur during transmission over the propagation space, such as phase and amplitude distortion. After equalizing the bit stream, the modulator 1427 synthesizes the signal with the RF signal generated at the RF interface 1429. The modulator 1423 generates a sinusoidal wave through frequency or phase modulation. To prepare the signal for transmission, the up-converter 1431 combines the sinusoidal wave output from the modulator 1427 with another sinusoidal wave generated by the synthesizer 1433 to produce the desired transmission frequency. This signal is now transmitted through the PA 1419, which amplifies the signal to an appropriate power level. In practical systems, the PA 1419 operates as a variable gain amplifier whose gain is controlled by the DSP 1405 in the information received from the network base station. The signal is now filtered within duplexer 1421 and optionally sent to antenna coupler 1435 to match impedances to provide maximum power transfer. Finally, the signal is transmitted to the local base station via antenna 1417. Automatic gain control (AGC) may be provided to control the gain of the final stages of the receiver. The signals may be from other cellular telephones or other mobile telephones. Or a remote telephone, which may be a ground line connected to a PSTN or other telephone networks.

Voice signals sent to the mobile station 1401 are received via an antenna 1417 and immediately amplified by a low noise amplifier (LNA) 1437. Demodulator 1442 leaves only the digital bit stream at its RF while down-converter 1439 downgrades the carrier frequency. The signal then passes through equalizer 1425 and is processed by DSP 1005. A digital-to-analog converter (DAC) 1443 converts the signal, and the result is sent to the user through the speaker 1445, all of which are the main control unit (MCU) 1403 (Central Processing Unit (CPU)). Can be implemented) (not shown).

MCU 1403 receives various signals, including signals from keyboard 1447. The MCU 1403 is a display 1407 and a speech output switching controller that delivers display commands and switch commands, respectively. In addition, the MCU 1403 may exchange information with the DSP 1405 and, optionally, access the integrated SIM card 1449 and the memory 1451. In addition, the MCU 1403 performs various required control operations of the station. The DSP 1405 may perform any of several conventional digital processing functions for speech signals, depending on the configuration. Additionally, the DSP 1405 determines the background noise level of the surrounding environment from the signals detected by the microphone 1411 and compensates the gain of the microphone 1411 according to the user's disposition of the mobile station 1401. Set to the selected level.

CODEC 1413 includes an ADC 1423 and a DAC 1443. The memory 1451 stores various data including outgoing call tone data, and may store other data including music data received through the global Internet, for example. The software module may reside in RAM memory, flash memory, registers, or any other recordable storage known in the art. Memory device 1451 may be, but is not necessarily limited to, a single memory, CD, DVD, ROM, RAM, EEPROM, optical storage, or any other nonvolatile storage medium capable of storing digital data.

Optionally merged SIM card 1449 includes important information such as, for example, cellular telephone number, carrier supply service, subscriber details, and security information. SIM card 1449 primarily serves to identify mobile station 1401 on a wireless network. The card 1449 also includes a personal phone number registry, text messages, and memory for storing user specific mobile station settings.

FIG. 15 shows a typical enterprise network, which may be any kind of data communication network utilizing packet-based and / or cell-based technologies (eg, ATM (asynchronous transfer mode), Ethernet, IP-based, etc.). Enterprise network 1501 supports connections (fixed or mobile) to wireless nodes 1505-1509 and wired nodes 1503, each of which is configured to perform the processes described above. Enterprise network 1501 may be a variety of other networks such as WLAN network 1511 (eg IEEE 802.11), cdma2000 cellular network 1513, telephone network 1515 (eg, PSTN), or public data network 1517 (eg, the Internet). Can communicate with them.

Although the invention has been described in connection with various embodiments and configurations, the invention is not limited thereto but also covers various and obvious variations and equivalent arrangements falling within the scope of the appended claims. While the features of the invention are expressed through certain combinations of the claims, it is contemplated that these features may be determined in other combinations and orders.

Claims (57)

In the authentication method, Setting a terminal and a key configured to operate using spread spectrum in a communication network according to a key agreement protocol; Associating an agreed key with an authentication procedure to provide a security association that supports reuse of the key; And Generating a master key based on the agreed key. The method of claim 1, Generating a challenge message from an agreed key according to the authentication procedure. The method of claim 1, Generating a task message from a key agreement message exchanged with a terminal according to the key agreement protocol. 2. The method of claim 1, wherein the key agreement protocol comprises a Diffie-Hellman key exchange scheme. 5. The method of claim 4, wherein the key agreement is performed via a transport layer security (TLS) tunnel. 5. The method of claim 4, wherein the terminal is configured to communicate using spread spectrum and to perform bootstrapping according to a generic authentication scheme. The method of claim 1, wherein the authentication procedure comprises a challenge handshake authentication protocol (CHAP). In the authentication method, Establishing, according to a key agreement protocol, a network key and a shared key configured to associate an agreed key with an authentication procedure in a communication network to provide a security association that supports reuse of the key; And Generating a master key based on the agreed key. 10. The method of claim 8, wherein the key agreement protocol comprises a Diffie-Hellman key exchange scheme. 9. The method of claim 8, wherein said key agreement is performed via a transport layer security (TLS) tunnel. The method of claim 8, Communicating with a network element using code division multiplexed access (CDMA); And Performing bootstrapping according to a generic authentication scheme. 10. The method of claim 8, wherein said authentication procedure comprises a Challenge Handshake Authentication Protocol (CHAP). In the authentication device, In accordance with a key agreement protocol, an authentication module configured to establish a shared key with a network element configured to associate an agreed key to an authentication procedure within a communication network to provide a security association that supports reuse of the key, The authentication module is further configured to generate a master key based on the agreed key. 14. The apparatus of claim 13, wherein the key agreement protocol comprises a Diffie-Hellman key exchange scheme. 14. The apparatus of claim 13, wherein the key agreement is performed via a transport layer security (TLS) tunnel. The method of claim 13, Further comprising a transceiver configured to communicate with a network element using spread spectrum, The authentication module is further configured to perform bootstrapping according to a comprehensive authentication scheme. 14. The apparatus of claim 13, wherein the authentication procedure comprises a Challenge Handshake Authentication Protocol (CHAP). A system comprising the apparatus and network elements of claim 13. In the authentication method, Generating a message for authenticating communication with a network element configured to perform bootstrapping; Setting a password field of the message as a function of a secret key; And Specifying key setting information in the payload of the message, The message is transmitted over a data network according to a transport protocol for accessing information. 20. The method of claim 19, wherein said transport protocol comprises a hypertext transfer protocol. 20. The method of claim 19, wherein the key setting information includes Diffie-Hellman parameters. The method of claim 19, And setting a username field of the message as an identifier of a terminal. 20. The method of claim 19, wherein the function of the secret key is a checksum or digest. 20. The method of claim 19, wherein the secret key is a signaling message encryption key (SMEKEY) or a mobile node authentication, authorization and accounting (MN-AAA) key. In the authentication method, Receiving, via the data network, from the terminal according to a transport protocol for accessing the information, a message having a payload comprising a password field which is a function of a secret key and key setting information specifying parameters for determining another secret key; Requesting authentication; And Generating a master key based on the secret keys. 27. The method of claim 25, wherein said transport protocol comprises a hypertext transfer protocol. 27. The method of claim 25, wherein the key setting information comprises Diffie-Hellman parameters. 27. The method of claim 25, wherein the message includes a user name field for specifying an identifier of the terminal. 27. The method of claim 25, wherein the function of the secret key is a checksum or digest. 27. The method of claim 25, wherein the secret key is a signaling message encryption key (SMEKEY) or mobile node authentication, delegation and accounting (MN-AAA) key. In the authentication device, An authentication module configured to generate a message for authenticating communication with a network element intended to perform bootstrapping, and set the password field of the message to be a function of a secret key, The message comprises a payload comprising new key setting information and is transmitted over the data network according to a transport protocol for accessing the information. 32. The apparatus of claim 31, wherein said transport protocol comprises a hypertext transfer protocol supporting secure communication over a data network. 32. The apparatus of claim 31, wherein the key setting information comprises Diffie-Hellman parameters. 32. The apparatus of claim 31, wherein the authentication module is further configured to set a user name field of the message to an identifier of a terminal. 32. The apparatus of claim 31 wherein the function of the secret key is a checksum or digest. 32. The apparatus of claim 31, wherein the secret key is a signaling message encryption key (SMEKEY) or mobile node authentication, delegation and accounting (MN-AAA) key. The method of claim 31, wherein Further comprising a transceiver configured to communicate with the base station using a spread spectrum, The authentication module is further configured to perform bootstrapping according to a comprehensive authentication scheme. 32. A system comprising the device and network elements of claim 31. In the authentication method, Receiving an authentication request specifying a user ID from the terminal; Based on the user ID, passing the user ID to a positioning register configured to generate encryption parameters including random secret data and secret data generated from the random secret data according to an encryption algorithm; Receiving the encryption parameters generated from a location register; Generating an authentication vector by converting the encryption parameters into key parameters including an authentication token and an authentication response; Transmitting the authentication token to a terminal configured to output the authentication response; Ratifying an authentication response from a terminal using the authentication response from an authentication vector; And Generating a master key based on the key parameters. 40. The method of claim 39, wherein the authentication request is generated according to a hypertext transfer protocol. 40. The method of claim 39, wherein the conversion from encryption parameters to key parameters comprises generating a key based on the secret data. 40. The method of claim 39, wherein the authentication vector includes a random number based on random secret data, and further includes an encryption key and an integrity key. 40. The method of claim 39, wherein the encryption algorithm comprises a cellular authentication and voice encryption algorithm. 40. The method of claim 39, wherein the plurality of sets of cryptographic parameters are generated by a location register for use in generating an authentication vector. In the authentication method, Generating an authentication request specifying a user ID; Pass the user ID to a location register configured to support bootstrapping and to generate encryption parameters including random secret data based on the user ID and secret data generated from the random secret data according to an encryption algorithm; Transmitting the authentication request to a network element that converts encryption parameters into key parameters including an authentication token and an authentication response to generate an authentication vector; Receiving an authentication token from a network element; Outputting an authentication response based on the authentication token; Determining a digest response using the authentication response; Sending the digest response to the network element for ratification; And Generating a master key based on the key parameters. 46. The method of claim 45, wherein the authentication request is generated according to a hypertext transfer protocol. 46. The method of claim 45, wherein the conversion from encryption parameters to key parameters comprises generating a key based on secret data. 46. The method of claim 45, wherein the authentication vector includes a random number based on random secret data, and further includes an encryption key and an integrity key. 46. The method of claim 45, wherein the encryption algorithm comprises a cellular authentication and voice encryption algorithm. 46. The method of claim 45, wherein the plurality of sets of encryption parameters are generated by a location register for use in generating an authentication vector. In the authentication device, An authentication module, configured to generate an authentication request specifying a user ID; And Pass the user ID to a location register configured to support bootstrapping and to generate encryption parameters including random secret data based on the user ID and secret data generated from the random secret data according to an encryption algorithm; A transceiver configured to send the authentication request to a network element that converts cryptographic parameters into key parameters including an authentication token and an authentication response to generate an authentication vector, The transceiver is further configured to receive an authentication token from a network element, The authentication module is further configured to output an authentication vector based on an authentication token, determine an authentication response using the authentication response, and generate a master key based on key parameters in accordance with the digest response by the network element. Characterized in that the device. 53. The apparatus of claim 51, wherein the authentication request is generated according to a hypertext transfer protocol. 53. The apparatus of claim 51, wherein the conversion from encryption parameters to key parameters comprises key generation based on secret data. 52. The apparatus of claim 51, wherein the authentication vector includes a random number based on random secret data, and further includes an encryption key and an integrity key. 53. The apparatus of claim 51, wherein the encryption algorithm comprises a cellular authentication and voice encryption algorithm. 53. The apparatus of claim 51, wherein the plurality of sets of encryption parameters are generated by a location register for use in generating an authentication vector. 52. A system comprising the apparatus of claim 51 and a network element.

Images