HK1179799A

HK1179799A - Method and apparatus for binding subscriber authentication and device authentication in communication systems

Info

Publication number: HK1179799A
Application number: HK13106745.0A
Authority: HK
Inventors: A．E．艾斯科特; A．帕拉尼格朗德
Original assignee: 高通股份有限公司
Priority date: 2010-06-16
Filing date: 2011-06-16
Publication date: 2013-10-04

Description

Method and apparatus for binding subscriber authentication with device authentication in a communication system

Priority requirements according to 35U.S.C. § 119

This patent application claims priority from U.S. provisional application No.61/355,423 entitled "Apparatus and Method for Device authentication 3GPP Systems (Method and Apparatus for Device authentication in 3GPP Systems) filed on 16/2010 and assigned to the assignee of the present application and hereby expressly incorporated by reference.

Background

FIELD

Various features relate to communication systems, and more particularly to authentication of devices, such as relay nodes and machine-to-machine devices, employed in wired and/or wireless communication systems.

Background

Modern wireless networks may include relay nodes and/or access terminals, which are collectively referred to herein as devices. In order for such devices to function properly, the device is often provisioned/configured with operation and subscriber security credentials prior to bringing the device into operation. Such subscriber security credentials may be used, for example, to authenticate the device prior to providing wireless services or access, and in some cases may be stored in a module that is non-removably coupled to its host device. There is a risk that the subscriber security credentials may be removed from the authenticated device and placed in an unauthorized device. In the case of a relay node, this may allow an unauthorized relay node to implicitly access, for example, transmissions between the access node and one or more access terminals and/or gain free access to network services. This risk or vulnerability also exists in the case of machine-to-machine (M2M) devices because valid subscriber credentials in M2M devices (e.g., Authentication and Key Agreement (AKA) parameters in a removable Universal Integrated Circuit Card (UICC)) can be transferred to another device to get free network access. There are related weaknesses because physical access to the M2M device itself is not necessary. Access to data (e.g., a security key resulting from authentication) that is crossing an M2M device interface (e.g., a host device to UICC interface) is sufficient to gain access to the security key and expose the data protected by the key.

Similar problems exist in situations where an operator wishes to control which devices are allowed to access their network.

Therefore, there is a need to provide additional security for devices to address these and other vulnerabilities and risks.

SUMMARY

Methods and apparatus are provided for protecting devices by binding subscriber authentication with device authentication to generate security keys.

According to a first aspect, there is provided a method operational in a device for binding a subscriber with device authentication. The device may initially send an attach request to a network entity, the attach request including an indication of device authentication capabilities of the device. Subscriber authentication may be performed by the device and a network entity. For example, subscriber authentication may be exchanged based on an authentication key agreement between the device and the network entity. The device may also perform device authentication with the network entity. For example, device authentication may be based on a challenge-response exchange between the device and the network entity.

Subsequently, a security key may be generated that binds the subscriber authentication with the device authentication. The security key may be generated as a function of at least a first key obtained from a subscriber authentication and a second key obtained from a device authentication. Additionally, the security key may also be a function of the network nonce and the device nonce. The security key may then be used to secure communications between the device and the services network. Note that the security key may be generated by the device and the network entity separately, so the security key is not transmitted over the air.

According to one implementation, subscriber authentication may be performed by a first authentication server that is part of a network entity, while device authentication may be performed by a second authentication server that is part of the network entity.

In one example, device authentication may be performed by using a shared secret key to encrypt/decrypt certain exchanges between the device and a network entity. In another example, device authentication may be performed by: (a) receiving data encrypted with a public key of the device from a network entity; (b) decrypting the encrypted data using a corresponding private key; and/or (c) subsequently proving the network entity that the device is provided with knowledge of the data.

According to one aspect, device authentication may be protected by at least one key generated during subscriber authentication.

In various implementations, subscriber authentication and device authentication may be performed concurrently in a combined message exchange, or subscriber authentication may be performed in a security exchange that is earlier and separate from device authentication.

According to one feature, a subscriber-specific key may be provided on the device as part of a service agreement, wherein the subscriber-specific key is used for subscriber authentication. Similarly, a device-specific key may be provided in the device during manufacture, wherein the device-specific key is used for device authentication.

In one implementation, a device may be a relay node that appears to a network entity as an access terminal and to one or more access terminals as network devices. In another implementation, the device may be an access terminal.

According to one example, the apparatus may include a communication interface coupled to the processing circuit. The processing circuit may be adapted to: (a) performing subscriber authentication with a network entity; (b) performing device authentication for the device with the network entity; (c) generating a security key that binds the subscriber authentication with the device authentication; and/or (d) securing communications between the device and a serving network using the security key.

According to yet another example, a processor-readable medium comprising instructions operational on a device may be provided. When executed by a processor, the instructions may cause the processor to: (a) performing subscriber authentication with a network entity; (b) performing device authentication for the device with the network entity; (c) generating a security key that binds the subscriber authentication with the device authentication; and/or (d) securing communications between the device and a serving network using the security key.

According to another aspect, a method operational in a network entity is provided. The network entity may receive an attachment request from a device, the attachment request including an indication of device authentication capabilities of the device. The network entity may perform subscriber authentication with the device. Similarly, the network entity may perform device authentication for the device. Subsequently, a security key may be generated by the network entity that binds the subscriber authentication with the device authentication. The security key may then be used to secure communications between the network entity and the device. Note that to prevent over-the-air transmission of the security key, the security key may be generated by the device and the network entity, respectively.

In one example, subscriber authentication may be based on an authentication key agreement exchange between a network entity and a device. Device authentication may be based on a challenge-response exchange between a network entity and the device.

In one implementation, device authentication may include: (a) receiving a certificate from a device; and (b) verify that the certificate associated with the device has not been revoked.

In one implementation, to prevent snooping during the device authentication process, device authentication may be protected by at least one key generated during earlier subscriber authentication.

According to various examples, subscriber authentication and device authentication may be performed concurrently in a combined message exchange, or authentication may be performed in a security exchange that is earlier and separate from device authentication.

In another example, the security key may be generated as a function of at least a first key obtained from a subscriber authentication and a second key obtained from a device authentication.

In one implementation, a network entity may obtain a subscriber-specific key as part of a service agreement, which is used for subscriber authentication. Similarly, the network entity may obtain a device-specific key for the device, which is used for device authentication.

In one implementation, the network entity may include a communication interface coupled to the processing circuit. The processing circuit may be adapted to: (a) performing subscriber authentication with a device; (b) performing device authentication for the device; (c) generating a security key that binds the subscriber authentication with the device authentication; and/or (d) securing communications between the network entity and the device using the security key.

In one implementation, a processor-readable medium comprising instructions operational on a network entity is provided. When executed by a processor, the instructions may cause the processor to: (a) performing subscriber authentication with a device; (b) performing device authentication for the device; (c) generating a security key that binds the subscriber authentication with the device authentication; and/or (d) securing communications between the network entity and the device using the security key.

Brief Description of Drawings

Fig. 1 is a block diagram illustrating a wireless communication system in which various types of wireless devices may be authenticated by a core network for service.

Fig. 2 illustrates a general approach for binding device authentication with subscriber authentication.

Fig. 3 (including fig. 3A and 3B) illustrates an example of how a key hierarchy based on subscriber authentication may be modified to add device authentication.

Fig. 4 illustrates an exemplary protocol stack implemented in a device operable within a packet-switched network.

Fig. 5 is a block diagram illustrating a network system in which the various authentication and/or security keys illustrated in fig. 3 and 4 may be generated.

Fig. 6 is a block diagram illustrating a selection of components of a wireless device that may be adapted to bind subscriber authentication with device authentication.

Fig. 7 is a flow diagram illustrating an example of a method operational in a wireless device for generating a security key that binds subscriber authentication with device authentication.

Fig. 8 is a block diagram illustrating a selection of components of a network entity that may be adapted to bind subscriber authentication with device authentication.

Fig. 9 is a flow diagram illustrating an example of a method operational in a network entity for generating a security key binding subscriber authentication and device authentication.

Fig. 10 illustrates a first exemplary method for generating a security key by binding a subscriber with a device authentication.

Fig. 11 illustrates a second exemplary method for generating a security key by binding a subscriber with device authentication.

Fig. 12 illustrates a third exemplary method for generating a security key by binding a subscriber with a device authentication.

Detailed Description

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

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any implementation or embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or implementations. Likewise, the term "embodiments" does not require that all embodiments include the discussed feature, advantage or mode of operation.

Overview

Authentication methods between a device (e.g., a client device or an access terminal) and a network entity are provided. A removable storage device may be coupled to the device and store subscriber-specific keys that may be used for subscriber authentication. A secure storage device may be coupled to the device and store device-specific keys that are used for device authentication. Subscriber authentication may be performed between the device and a network entity. Device authentication of the device may also be performed with the network entity. Subsequently, a security key may be generated that binds the subscriber authentication with the device authentication. That is, keys, data, and/or information from the subscriber authentication process and keys, data, and/or information from the device authentication process may be combined to generate a (composite) security key. The security key may be used to secure communications between the device and the services network.

Exemplary network Environment

Fig. 1 is a block diagram illustrating a wireless communication system in which various types of wireless devices may be authenticated by a core network for service. This wireless communication system may be, for example, a Universal Mobile Telecommunications System (UMTS) compliant network or a compatible network, or a global system for mobile communications (GSM) compatible network. Although some of the examples described herein may relate to Long Term Evolution (LTE) networks, various features described herein may also be implemented in other networks.

The system may include one or more devices 101, such as an access terminal 103/104 and a relay node 102, in communication with an access node 106. The relay node 102 may facilitate wireless transmissions between the wireless communication network 106/108 and one or more access terminals 104. A wireless communication system (e.g., a Long Term Evolution (LTE) network, an LTE-advanced network, etc.) may include a core network 108 and one or more access nodes 106. Access node 106 may be coupled to core network 108 via a backhaul link (e.g., a wired connection). The core network 108 may include, for example, a Mobility Management Entity (MME) 110, a Home Subscriber Server (HSS) 112, and/or other components.

In one example, a Mobility Management Entity (MME) 110 may participate in bearer activation/deactivation for device 101, relay node 102, and/or access terminal 103/104 (hereinafter referred to generally as "device") and assist in authentication by interacting with a Home Subscriber Server (HSS) 112. MME 110 may also generate and/or assign temporary identities to devices (e.g., device 101, relay node 102, access terminal 103/104, etc.). The MME 110 may check for authorization of a Public Land Mobile Network (PLMN) hosted by a service provider (e.g., obtain service from the PLMN, connect to the PLMN, establish a communication link with the PLMN) and may enforce roaming restrictions on the device. The MME 110 may be a termination point in the network for cryptographically/integrity protecting non-access stratum (NAS) signaling and handling security key management. The MME 110 may also perform tracking and/or paging procedures (including retransmissions) for devices coupled to the core network 108.

The Home Subscriber Server (HSS) 112 is the primary subscriber database of the network entity that supports the actual handling equipment. The HSS may contain information about the subscription (subscriber profile), help perform authentication and authorization of the subscription, and may provide information about the location of the subscriber. The HSS is similar to GSM Home Location Register (HLR) and authentication center (AuC). The Home Location Register (HLR) may be a database containing details of each subscriber authorized to use the core network. The HLR may assist the AuC in authenticating the subscriber (i.e., using the user terminal).

The relay node 102 may be adapted to amplify and/or forward signals between the access terminal 104 and the access node 106. In general, the relay node 102 may appear to the access terminal 104 as AN Access Node (AN) and may appear to the access node 106 as AN Access Terminal (AT). For example, the relay node 102 may include an access terminal interface 105 by which to communicate with the access node 106, and may also include an access node interface 107 by which to communicate with the access terminal 104. That is, the access terminal interface 105 may make the relay node appear to the access node 106 as an access terminal. Similarly, the access node interface 107 may make the relay node 102 appear as an access node to the access terminal 104. In some implementations, the relay node 102 may convert signals between the access terminal interface 105 and the access node interface 107 from a first format to a second format. The relay node 102 may be placed near the edge of a cell to enable the access terminal 104 to communicate with the relay node 102 rather than communicating directly with the access node 106.

In a radio system, a cell is a geographical area of reception and transmission coverage. The cells may overlap each other. In a typical example, there is one access node associated with each cell. The size of a cell is determined by factors such as frequency band, power level, and channel conditions. A relay node, such as relay node 102, may be used to enhance coverage within or near a cell, or to extend the coverage size of a cell. Additionally, the use of the relay node 102 can enhance the throughput of signals within a cell because the access terminal 104 can access the relay node 102 at a higher data rate or lower transmit power than the access terminal 104 can use when communicating directly with the access node 106 of the cell. Transmissions at higher data rates create higher spectral efficiency, and lower power benefits the access terminal 104 by, for example, consuming less battery power.

In some examples, the relay node 102 may be implemented as one of three relay types: a layer 1 relay node, a layer 2 relay node, and/or a layer 3 relay node. A layer 1 relay node is essentially a relay that can retransmit a transmission without any modification except amplification and slight delay. The layer 2 relay node may decode its received transmission, re-encode the decoded result, and then transmit the re-encoded data. The layer 3 relay node may have full radio resource control capability and may therefore function in a similar manner to the access node. The radio resource control protocols used by the relay node may be the same as those used by the access node, and the relay node may have a unique cell identity that is typically used by the access node. For purposes of this disclosure, the relay node 102 is distinguished from the access node 106 by the fact that: the relay node 102 may rely on the presence of at least one access node 106 (and the cell associated with that access node) or other access node to access other components in the telecommunications system (e.g., the network 108). That is, the relay node 102 may appear to the network as a subscriber device, a client device, or an access terminal, and thus the relay node 102 connects to the access node to communicate over the network 108. However, the relay node 102 may appear as a network device (e.g., access node) to other subscriber devices, user devices, and/or access terminals 104. Thus, the relay node 102 may implement one or more communication interfaces to communicate with an access node and/or one or more access/subscriber/user terminals. In one example, the same transmitter/receiver (e.g., in one or more wireless channels) may be used by the relay node 102 to communicate with its access node and/or one or more access terminals. In another example, the relay node 102 may utilize two or more different transmitters/receivers to communicate with the access node and/or the one or more access terminals.

To mitigate abuse of subscriptions to access network services, these devices may bind device authentication with subscriber authentication. Device authentication may work in conjunction with standard 3GPP AKA (authentication and key agreement) access authentication, e.g., based on credentials, such as a subscriber root key K, stored in a Universal Integrated Circuit Card (UICC) 109, 111, 113, and 116 or a universal subscriber identity module (e.g., USIM) that is removably coupled to the device. In some embodiments, device authentication may be performed in the same non-access stratum (NAS) message that is used for AKA authentication. In this manner, the device (e.g., relay node 102, access terminal 103/104, etc.) may be bound to its subscription (i.e., service subscription to core network 108) in order to prevent others from using their subscriber credentials (i.e., subscriber credentials for subscribing to services) in unauthorized devices.

One solution to the risk of unauthorized use of subscriber credentials is for the UICC 109 and the apparatus (e.g., apparatus 101, relay node 102 or access terminal 103/104) to mutually authenticate each other (e.g., using a secure channel between the host apparatus and the UICC), but this would require that the UICC 109, 111, 113 and 116 and/or the host apparatus (e.g., apparatus 101, relay node 102 or access terminal 103/104) be pre-provisioned with information to perform such mutual authentication.

Another solution may be that the key required for network access (e.g., the key used to protect traffic between the device and the network) depends on both the credentials stored on the UICC 109, 111, 113, and 116 and the credentials stored on the device (e.g., device 101, relay node 102, or access terminal 103/104). This may be achieved by binding the AKA authentication key to the device authentication in some way. This solution is also useful in the case of International Mobile Equipment Identity (IMEI) authentication, which may for example allow an operator to prevent unauthorized devices from attaching to their network. This is because by binding the key for network access resulting from AKA authentication with the key for device authentication, it is ensured that all messages originating from the device destined to the network 108 do originate from this authenticated device. Binding the key from AKA authentication to device authentication provides greater security than using a challenge/response based mechanism for device authentication alone, assuming that the bound key (and all other subsequent keys derived from the bound key) are securely stored on the device (e.g., device 101, relay node 102, or access terminal 103/104). Using the challenge/response mechanism alone for device authentication only proves that the device was present to generate an authentication response, but cannot prove that the device is still present at a subsequent time.

Fig. 2 illustrates a general approach for binding device authentication with subscriber authentication. A device 202 (e.g., device 101, relay node 102, or access terminal 103/104) may be provided with a subscriber root key 206 and/or a subscriber identity 207, which subscriber root key 206 and/or subscriber identity 207 may be used to authenticate a subscription to the core network 108 and/or to generate security keys used to access encrypted traffic sent to the device 202. Subscriber root key 206 may be uniquely associated with subscriber identity 207. In one example, the subscriber root key 206 and/or the subscriber identity 207 may be stored in the UICC 204 and/or subscriber authentication may be handled by the UICC 204. Similarly, the device 202 may be provided with (or may store) a device root key 208 and/or a device identity 209 that may be used to authenticate the device with the core network 108. The device root key 208 may be uniquely associated with the device identity 209.

In one example, the device identity 209 may be an International Mobile Equipment Identity (IMEI) of the device 202 (e.g., the device 101, the relay node 102, or the access terminal 103/104), although other forms of identities associated with the device (e.g., IEEE hardware addresses such as EUI-48 or EUI-64) may also be used.

In some implementations, the device root key 208 may be a secret key that is shared by the device 202 only with the core network 108, but is not transmitted over the air. The device identity 209 may be communicated by the device 202 to the core network 108 to enable the core network 108 to obtain the correct device root key for use in device authentication. Alternatively, device root key 208 may be a public key of a public/private key pair, where certificates are used for device authentication. For example, a device may receive some data from a network, where the data is encrypted with a public key. The device may then decrypt the encrypted data using its own private key and then prove to the network that it knows the data. The certificate (e.g., device credential) may be verified by the core network 108. The associated private key of the device 202 may be securely stored in the device 202. A device credential may refer to a device certificate or a pointer to a device certificate. These device credentials may allow the relevant network entities to form a device challenge and check the revocation status of the device 202 (e.g., check whether credentials associated with the device, such as a private key or shared key, are compromised). It is further assumed that a secure part of the device (such as the trusted environment or TrE defined in 3GPP technical specification 33.320) stores sensitive device keys such as device root keys and/or private keys associated with certificates. In addition, assume that the TrE performs all cryptographic operations with these keys.

Initially, subscriber authentication may occur between the device 202 and the network 108. For example, an Authentication and Key Agreement (AKA) exchange 210 between the device 202 and the network 108 may result in the key K _ ASME being established. Such AKA exchange 210 may, for example, be based on subscriber root key 206 and/or subscriber identity 207 to authenticate a subscriber associated with device 202. For example, such subscription information or credentials may be securely stored in the UICC 204 removably coupled to the host device 202.

The network 108 may also perform device authentication for the device 202. The device identity 209 may be provided by the device 202 to the core network 108 so that the core network 108 may look up or obtain the correct corresponding device root key 208. Network 108 can create device challenge 212 and send device challenge 212 to device 202 (e.g., as part of a related NAS message). In response, the device 202 computes a device response 214 (e.g., based on the device challenge and the device root key 208 or derivative thereof) and returns the device response 214 to the network 108. The device 202 may use the data in the device challenge and the device response to calculate the composite security key, K _ ASME _ D216. Note that in the case of device 202, the composite security key K _ ASME _ D216 may be generated either before device response 214 is sent or after device response 214 is sent. In one example, the composite security key K _ ASME _ D may be an equivalent key to the security key K _ ASME defined in evolved universal terrestrial radio access network E-UTRAN (E-UTRAN) defined in 3GPP technical specification 33.401, except that this key K _ ASME _ D is bound to the device identity 209 and also to a key derived from AKA authentication, such as a K _ ASME key. The network 108 also calculates a composite security key, K _ ASME _ D218, if the network 108 receives a valid device response.

The calculation of the device challenge 212, the device response 214, and the composite security key K _ ASME _ D may proceed as follows. Device challenge 212 may be calculated as:

device challenge = eKSI, [ E _ device root key (device temporary key), network nonce ],

where eKSI is the evolved/extended key set identifier to be associated with K _ ASME _ D, [. ] denotes optional parameters, E _ K (data) denotes data encrypted with key K, and the network nonce is a random number of appropriate size (e.g., 128 bits) selected by the network. The encryption algorithm may be asymmetric (in the case where the device root key is a public key associated with the device certificate) or symmetric (in the case where the device root key is a shared key). The device temporary key may be a key obtained or generated as part of device authentication. In one example, the device transient key may be selected (e.g., randomly) by the network 108, sent to the device 202 in an encrypted form, and have an appropriate length (e.g., 256-bit or 128-bit value).

Both the device 202 and the network 108 may maintain a device temporary key between network accesses for optimization purposes. If this is not the case, then the second parameter in the device challenge 212 ([ E device root Key (device temporary Key) ]) is not optional.

The device response 214 may be calculated as:

device response = device one-time count, device _ res.

Where the device nonce is a random number of appropriate size (e.g., 128 bits) selected by the device, and

device _ res = KDF (device temporary key, network nonce, device nonce)

Where KDF is a cryptographic function adapted to generate the response device _ res.

Where the authentication key K _ ASME has been previously obtained (e.g., as part of the AKA exchange 210), the calculation of the composite security keys K _ ASME _ D216 and 218 (i.e., binding device authentication with subscriber authentication) may proceed as follows:

k _ ASME _ D = KDF (device temporary key, K _ ASME, network nonce, device nonce)

Where K _ ASME may be a key or value obtained during subscriber authentication between the device and the network (as a result of the AKA authentication exchange 210). In one example, the K _ ASME key may be a key previously generated and/or used between device 202 and network 108. Alternatively, if the device authentication procedures 212 and 214 are being performed using the same NAS message as used for the AKA procedure 210, the K _ ASME key may be generated anew or concurrently. Similarly, the device temporary key may be a key or value obtained during device authentication between the device 202 and the network 108.

The composite security key may then be used as a basis and/or root for calculating the additional security keys 217 and 219. These additional security keys may be used to protect, for example, NAS-level and/or AS-level communications.

The composite security key, K _ ASME _ D, associated with the security parameters and all keys derived from K _ ASME _ D may be securely maintained on the device 202 and not stored on the UICC 204. The composite security key K _ ASME _ D may then be used to protect messages 220 exchanged between the device 202 and the core network 108.

Fig. 3 (including fig. 3A and 3B) illustrates an example of how a key hierarchy based on subscriber authentication may be modified to also include device authentication. The key hierarchy may be implemented to establish security parameters (e.g., security keys) used in encryption/decryption of communications between the device and the network. In this example, subscriber and device authentication may be performed between the device 322 and the network entity 324. The device 322 may be, for example, an Access Terminal (AT), a User Equipment (UE), a mobile phone, and/or a relay node. Network entity 324 may be one or more network devices such as a Mobility Management Entity (MME) and/or a Home Subscriber Server (HSS).

This example illustrates how a first key hierarchy 300 based on subscriber authentication is modified to obtain a second key hierarchy 300' based on both subscriber authentication and device authentication.

For the purpose of subscriber authentication as illustrated in the first key stage 300, the universal integrated circuit card (UICC in the device 322), and a network entity 324 (e.g., the MME 110, HSS 112, or other network entity in fig. 1) may use the master key K302 to generate a Cipher Key (CK) 304 and an Integrity Key (IK) 306. The Cryptographic Key (CK) 304 and the Integrity Key (IK) 306 may then be used by the device 322 and the network entity 324 as part of an Authentication and Key Agreement (AKA) exchange to generate an access security management entity key, K _ ASME 308 (also referred to herein as a subscriber authentication key). Security activation of the device 202 may be accomplished through an authentication and key agreement procedure (AKA), a non-access stratum (NAS) security mode configuration (NAS SMC) procedure, and an Access Stratum (AS) security mode configuration (AS SMC) procedure.

In this example, subscriber authentication may include AKA exchange 326 resulting in K _ ASME 308. AKA exchange 236 may include a subscriber authentication request 340 and a subscriber authentication response 342. In this example, the subscriber authentication process that generates the K _ ASME key 308 may also generate the associated NAS level keys (e.g., K _ NAS-enc 305 and K _ NAS-int 311) and/or AS level keys (e.g., K _ UP-enc 315, K _ RRC-enc 317, and K _ RRC-int 319). Note that in some implementations, if these versions of NAS-level keys and AS-level keys are not used, the generation of these keys may have been performed earlier during subscriber authentication.

The second key level 300' illustrates how device authentication may be bound to subscriber authentication to generate NAS level and AS level security keys. Concurrently with subscriber authentication (and generation of its corresponding K _ ASME key 308), either before or after it, device authentication 328 may be performed based at least in part on the device-specific root key. The device authentication 328 may include a device authentication request 344 and a device authentication response 346. In one implementation, device authentication 307 may be independent of subscriber authentication; the composite security key K _ ASME _ D309 is generated only when both subscriber and device authentication is satisfied. In an alternative implementation, device authentication may be performed prior to subscriber authentication.

The composite security key K _ ASME _ D309 may be used AS a base key for the evolution of, for example, NAS (non-access stratum) keys 310 and 312 and AS (access stratum) keys 314, 316, 318, and 320. That is, the device 322 and the network entity 324 may then use the K _ ASME _ D key 309 to generate one or more security keys.

The packet-switched network may be structured into a plurality of hierarchical protocol layers, with lower protocol layers providing services to upper layers and each layer being responsible for different tasks. For example, fig. 4 illustrates an exemplary protocol stack that may be implemented in a device operating in a packet-switched network. In this example, the protocol stack 402 includes a Physical (PHY) layer 404, a Medium Access Control (MAC) layer 406, a Radio Link Control (RLC) layer 408, a Packet Data Convergence Protocol (PDCP) layer 410, a Radio Resource Control (RRC) layer 412, a non-access stratum (NAS) layer 414, and an Application (APP) layer 416.

The layers below the NAS layer 414 are often referred to AS an Access Stratum (AS) layer 418. The RLC layer 408 may include one or more channels 420. The RRC layer 412 may implement various monitoring modes for the access terminal, including a connected state and an idle state. The non-access stratum (NAS) layer 414 may maintain a mobility management context, a packet data context, and/or its IP address for the communication device. Note that other layers may be present in the protocol stack 402 (e.g., above, below, and/or between the illustrated layers), but have been omitted for purposes of illustration.

Referring to fig. 4, radio/session bearers 422 may be established at the RRC layer 412 and/or the NAS layer 414, for example. As a result, the NAS layer 414 may be used by the device 202 and the core network 108 to generate the security keys K _ NAS-enc 310 and K _ NAS-int 312 shown in fig. 3. Similarly, RRC layer 412 can be used by device 202 and access node 108 to generate Access Stratum (AS) security keys K _ UP-enc 316, K _ RRC-enc318, and K _ RRC-int 320. While the security keys K _ UP-enc 316, K _ RRC-enc318, and K _ RRC-int320 may be generated at the RRC layer 312, these keys may be used by the PDCP layer 410 to protect signaling and/or user/data communications. For example, the key K _ UP-enc 316 can be used by the PDCP layer 410 to protect user/data plane (UP) communications, while the keys K _ RRC-enc318 and K _ RRC-int320 can be used to protect signaling (i.e., control) communications at the PDCP layer 410.

In the derivation of these security keys, which are used for the ciphering and integrity algorithms, the provision of individual algorithm identities AS one of the inputs is required at both the AS (user plane and RRC) and the NAS. At the AS level, the algorithm to be used is provided by the Radio Resource Control (RRC) security mode command.

Fig. 5 is a block diagram illustrating a network system in which the various authentication and/or security keys illustrated in fig. 3 and 4 may be generated. Here, the device 322 may implement a communication stack including various layers (e.g., APP, NAS, RRC, RLC, MAC, and PHY). Access network 504 (e.g., access node 106 in fig. 1) may provide wireless connectivity to device 322 so that device 322 may communicate with network 108. The home subscriber server 506 and the apparatus 322 may both know or have access to a root key (K) that may be used to generate or obtain a Cryptographic Key (CK) and/or an Integrity Key (IK). The device 322 and/or HSS506 may then use the Cipher Key (CK) and/or the Integrity Key (IK) to generate an access security management entity key, K _ ASME. Device authentication may also be performed and combined with or based on the K _ ASME key to generate a composite security key, K _ ASME _ D, thereby combining the subscriber and device authentication into one key. Using this K _ ASME _ d key, the device 322 and the Mobility Management Entity (MME) 510 may then generate the keys K _ NAS-enc and K _ NAS-int. The device 322 and MME 510 may also generate an access network specific key K _ eNB/NH. Using the access network-specific key K _ eNB/NH, the device 322 and the access network 504 may generate the keys K _ UP-enc and K _ RRC-int.

Details regarding the derivation of these keys are evolved in the 3GPP STD-T63-33.401 "(Systemarchitecture Evolution (SAE): Security Architecture) System Architecture (SAE): security architecture "(referred to as 3GPP TS 33.401), eighth edition, which is incorporated herein by reference. Note that while fig. 3-5 describe a particular environment/context in which device and subscriber authentication and binding may be implemented, this is not intended to be limiting as features may be implemented in various other types of networks.

Exemplary Wireless device

Fig. 6 is a block diagram illustrating a selection of components of a wireless device 600 that may be adapted to bind subscriber authentication with device authentication. The wireless device 600 generally includes processing circuitry 602 coupled to one or more wireless communication interfaces 604. For example, wireless device 600 may be a relay node and/or an access terminal.

The processing circuitry 602 may be arranged to obtain, process and/or transmit data, control data access and storage, issue commands, and control other desired operations. In at least one embodiment, the processing circuitry 602 may include circuitry configured to implement desired programming provided by appropriate media. For example, the processing circuit 602 may be implemented as one or more of a processor, a controller, multiple processors, and/or other structure configured to execute executable instructions including, for example, software and/or firmware instructions, and/or hardware circuitry. Embodiments of the processing circuit 602 may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing components, such as a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. These examples of the processing circuit 602 are for illustration, and other suitable configurations are contemplated within the scope of the present disclosure.

The wireless communication interface 604 may be configured to facilitate wireless communication for the wireless device 600. For example, the communication interface 604 may be configured to communicate information bi-directionally with respect to other wireless devices, such as access terminals, access points, other relay nodes, and so forth. The communication interface 604 may be coupled to an antenna (not shown) and may include wireless transceiver circuitry including at least one transmitter and/or at least one receiver (e.g., one or more transmitter/receiver chains) for wireless communication.

The processing circuit 602 may include a subscriber and device authentication binding module 610. The subscriber and device authentication module 610 may include circuitry and/or programming adapted to perform subscriber authentication procedures using subscriber security credentials (e.g., subscriber-specific key 607 and/or subscriber identity 609 stored in universal integrated circuit card 608), to perform device authentication procedures (within the trusted environment 606) using device-specific credentials (e.g., device-specific key 605 and/or device identity 611), and to bind subscriber authentication and device authentication together. Such "binding" may involve combining some of the results from both subscriber authentication and device authentication. For example, a first security key obtained from subscriber authentication may be combined with a second security key obtained from device authentication to obtain a third (composite) security key.

In some embodiments, wireless device 600 may include a trusted environment (TrE) 606. Trusted environment 606 may be adapted to meet specifications for the trusted environment in 3GPP specification details at TS 33.320. At least some security credentials (e.g., device-specific key 605 and/or device identity 6111) may be pre-provisioned (or securely embedded) for trusted environment 606. For example, the trusted environment 606 may have security credentials related to device authentication.

In some embodiments, the wireless device 600 may include protected processing within a Universal Integrated Circuit Card (UICC) 608. The UICC 608 can be removably coupled to the wireless device 600. UICC 608 can be pre-provisioned with subscriber security credentials (e.g., subscriber-specific key 607 and/or subscriber identity 609), such as initial Authentication and Key Agreement (AKA) credentials. Alternatively, the protected processing may be performed within a Universal Subscriber Identity Module (USIM).

In accordance with one or more features of the wireless device 600, the processing circuit 602 may be adapted to perform any or all of the related processes, functions, steps, and/or routines illustrated in fig. 2-5, 7, 10, 11, and 12. As used herein, the term "adapted to" with respect to the processing circuit 602 may refer to the processing circuit 602 being configured, employed, implemented and/or programmed to perform particular processes, functions, steps and/or routines in accordance with various features described herein.

Fig. 7 is a flow diagram illustrating an example of a method operational in a wireless device for generating a security key that binds subscriber authentication with device authentication. The wireless device may be pre-provisioned with a device-specific key 702. For example, such device-specific keys may be embedded in a chip or configured during manufacture of the wireless device. The wireless device may also include a device identifier associated with the device-specific key. Additionally, the wireless device may be pre-provisioned with a subscriber-specific key 704. For example, such subscriber-specific keys may be a root key assigned to a subscriber and may be stored within a fixed or removable module (e.g., UICC or USIM) coupled to the wireless device. The wireless device may also include a subscription identity associated with the subscriber-specific key. The wireless device may perform subscriber authentication with a network entity (e.g., using a subscriber-specific key) 706. This may include, for example, authentication and key agreement exchanges with the network entity. The wireless device may also perform device authentication 708 with a network entity (e.g., using a device-specific key). The subscriber authentication and the device authentication may be performed at the same or different times and with the same network entity or with different network entities. A security key (e.g., K _ ASME _ D, etc.) may then be generated by the wireless device, such security key binding 710 the subscriber authentication with the device authentication. For example, in one example, data from device authentication (e.g., one or more resulting keys, certificates, identifiers, etc.) and data from subscriber authentication (e.g., one or more resulting keys, certificates, identifiers, etc.) may be combined to generate a security key. For example, in fig. 1, the K _ ASME key from the subscriber authentication 210 and the device temporary key from the device authentication in fig. 1 may be combined to generate the security key K _ ASME _ D. The security key may then be used to secure the wireless communication between the wireless device and the network entity 712. For example, the security key may be used to generate other keys and/or credentials (e.g., NAS-level and/or AS-level security keys) that may be used to encrypt/decrypt communications (e.g., data and signaling) between the wireless device and the network.

Exemplary network entity

Fig. 8 is a block diagram illustrating a selection of components of a network entity 800 that may be adapted to bind subscriber authentication with device authentication. Gateway entity 800 may include a processing circuit 802 coupled to a communication interface 804. The processing circuitry 802 is arranged to obtain, process and/or transmit data, control data access and storage, issue commands, and control other desired operations. In at least one embodiment, the processing circuitry 802 may comprise circuitry configured to implement desired programming provided by an appropriate medium. For example, the processing circuit 802 may be implemented as one or more of a processor, a controller, multiple processors, and/or other structure configured to execute executable instructions including, for example, software and/or firmware instructions, and/or hardware circuitry. Embodiments of the processing circuit 802 may include a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing components, such as a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. These examples of processing circuit 802 are for illustration, and other suitable configurations are contemplated within the scope of the present disclosure.

The processing circuit 802 includes a subscriber and device authentication binding module 806. The subscriber and device authentication binding module 806 may include circuitry and/or programming adapted to perform a subscriber authentication procedure for authenticating a subscription based on subscriber security credentials (e.g., subscriber-specific keys and/or subscriber identifiers), perform a device authentication procedure for authenticating a device based on device-specific credentials (e.g., device-specific keys and/or device identifiers), and bind data (e.g., keys, values, certificates, etc.) from device authentication and subscriber authentication to generate a security key.

The communication interface 804 is configured to facilitate communications of the network entity 800 to communicate directly or indirectly (e.g., through one or more other network entities) with other devices such as relay nodes and access terminals.

In accordance with one or more features of the network entity 800, the processing circuitry 802 may be adapted to perform any or all of the procedures, functions, steps and/or routines related to various network entities such as the Mobility Management Entity (MME) 110 and the Home Subscriber Server (HSS) 112. Further, network entity 800 may comprise a single entity, or a combination of two or more entities in a network. By way of example and not limitation, network entity 800 may include, among other things, a Mobility Management Entity (MME), a Home Subscriber Server (HSS), a device authentication server, and so forth. As used herein, the term "adapted to" with reference to the processing circuit 802 may refer to the processing circuit 802 being configured, employed, implemented and/or programmed to perform one or more of the specific processes, functions, steps and/or routines in accordance with the various features described herein.

Fig. 9 is a flow diagram illustrating an example of a method operational in a network entity for generating a security key binding subscriber authentication and device authentication. The network entity may obtain a device-specific key 902 for the wireless device. For example, such device-specific keys may be embedded in the chip or configured during manufacture of the wireless device, and this information may be stored in a database accessible by a network entity. The device identifier may be associated with the device-specific key and may be used to identify the device and its key. Additionally, the network entity may obtain a subscriber-specific key 904 associated with the subscription of the wireless device. Such subscriber-specific keys may be, for example, a root key assigned to a subscriber and may be stored within a fixed or removable module (e.g., UICC or USIM) coupled to the wireless device. The network entity may perform subscriber authentication 906 with the wireless device (e.g., using a subscriber-specific key). This may include, for example, authentication and key agreement exchanges with the network entity. The network entity may also perform device authentication 908 with the wireless device (e.g., using a device-specific key). The subscriber authentication and the device authentication may be performed at the same or different times. A (composite) security key (e.g., K _ ASME _ D, etc.) may then be generated by the network entity, such security key binding the subscriber authentication with the device authentication 910. For example, in one example, data from device authentication (e.g., one or more resulting keys, certificates, identifiers, etc.) and data from subscriber authentication (e.g., K _ ASME, etc.) may be combined to generate a security key. The security key can then be used to secure wireless communications between the network entity and the wireless device 912. For example, the security key may be used to generate other keys and/or certificates that may be used to encrypt/decrypt communications between the wireless device and the network.

First exemplary method of subscriber-device authentication

Fig. 10 illustrates a first exemplary method for generating a security key by binding a subscriber with a device authentication. In this example, the device 1002 may be, for example, a relay node or an access terminal. During the attachment phase in which device 1102 may seek to attach to a wireless network (e.g., the wireless network includes MME 1002 and HSS 1006), the over-the-air revealing of device identity or other relevant device information may be a security issue (e.g., for device 1002). As a result, in this approach, the device 1002 does not present its device credentials (e.g., a device-specific identifier such as an International Mobile Equipment Identity (IMEI)) over the air until securely requested by the network to prevent passive attacks on the device identity.

The device may initially send an attach request 1010 to the network, the attach request 1010 including an indication that the device is capable of device authentication. Upon receiving the attach request 1010, the Mobility Management Entity (MME) 1004 may request and receive subscription and authentication information 1012 (e.g., associated with a subscription-based account or user of the device 1002) from a Home Subscription Server (HSS) 1006. The MME1004 then sends an authentication request 1014 including an AKA challenge to perform AKA authentication. Upon receiving the AKA authentication request 1014, the device 1002 sends an authentication response 1016 that includes an AKA response. AKA authentication request 1014 and response 1016 are used to perform subscription authentication. Such AKA authentication procedures may result in a subscriber authentication key (e.g., K _ ASME) being generated by the device 1002 and the MME.

Device authentication may be performed at various stages during this security activation process. In this example, device authentication may be piggybacked on NAS level security messages. For example, MME1004 may send NAS security mode command 1018 including a request for an equipment identity (e.g., a request for IMEI software version (IMEISV) and/or a request for equipment credentials). In response, the device 1002 may provide the device identity or credentials within a security mode complete 1020 message that device authentication is to be performed. Note that to avoid exposing the device identity or credential over the air during transmission, the device identity or credential in security mode completion 1020 may be protected by a previously computed subscriber authentication key (e.g., K _ ASME). Upon receiving the device identity or credentials, the MME1004 may send an identity request 1022 message with an evolved/extended key set identifier (eKSI) and a device challenge. The eKSI may be associated with K _ ASME _ D to be generated. Thus, the eKSI used in identity request 1022 may be different or distinct from any other eKSI that may have been used, for example, for AKA (i.e., subscriber authentication). Upon receiving the identity request 1022 message, device 1002 may generate a device response based on the device challenge and send the device response as part of identity response 1024 message. The device response may be based on the device challenge and the device identity or credentials. Device 1002 may then calculate (compound) security key (K _ ASME _ D) 1025 based on the authentication key (e.g., K _ ASME) and device authentication data (e.g., device response, etc.). The MME1004 checks the device response, for example by using the device identity or certificate of the device 1002 and using the device challenge. The MME1004 also generates a security key (K _ ASME _ D) 1027 if the device 1002 is successfully authenticated by the MME 1004. At this point, the device 1002 and MME1004 share the security key (K _ ASME _ D) and its associated identifier eKSI.

MME1004 may then send security mode command 1026 with the evolved/extended key set identifier eKSI associated with the security key (K _ ASME _ D). This allows the device 1002 to calculate one or more security keys based on the security key (K _ ASME _ D). The device 1002 may send a security mode complete 1028 message to the MME1004, thereby allowing the MME1004 to send an attach complete 1030 message.

Second exemplary method of subscriber-device authentication

Fig. 11 illustrates a second exemplary method for generating a security key by binding a subscriber with device authentication. In this example, revealing the device identity or certificate (or other relevant credential information) in the over-the-air transmission is not a security concern. Unlike the method of fig. 10, in this case, assuming that the device identity is presented at the outset will not result in any privacy issues or risks.

The device already has a device identifier or credential (e.g., IMEI) that the MME will accept but does not have an E-UTRAN security context that the MME is willing to use.

The device 1102 sends an attach request 1108 to the MME 1104 including its own device identifier or credentials. The MME 1104 may obtain subscription and authentication information 1110 from the HSS 1106 and send an authentication request 1112 including, for example, an AKA challenge (for subscription authentication) and/or a device challenge (for device authentication). Note that the device 1102 may respond by sending an authentication response 1114, which may include an AKA response and/or a device response. The AKA response may be based at least in part on a subscriber identifier. The device response may be based on the device identifier and/or credentials and the device challenge. The device 1104 may then generate a (composite) security key K _ ASME _ D by combining the subscriber authentication information with the device authentication information. Similarly, once the AKA response and the device response are successfully verified, the MME 1104 may also generate a security key K _ ASME _ D by combining the subscriber authentication information with the device authentication information.

The MME sends a security mode command 1116 message to start using the security context based on the security key K _ ASME _ D. Device 1102 responds with a security mode complete 1118 message. That is, the device 1102 and the MME 1104 may use the security key K _ ASME _ D to generate one or more additional security keys (or otherwise secure communications between the device 1102 and the MME 1104). The MME 1104 may then send an attach complete 1120 message to the device 1102.

It is observed here that if the device identifier and/or credentials (or previously obtained/generated device key) are stored with the subscriber identifier in the HSS 1106 or another server in the network, the device 1102 may perform the attachment using this procedure. To do so there, the device 1102 may indicate (e.g., in the attach request 1108) that its device identifier and/or credentials are available from the HSS 1106 or other network server. Alternatively, the MME 1104 may indicate to the device 1102 that the device challenge is associated with a particular device identifier (e.g., by including in some form a device identifier such as an IMEI with the device challenge). In this way, the device 1102 may know that the device challenge (in the authentication request 1112) is associated with its own device identifier.

Third exemplary method of subscriber-device authentication

Fig. 12 illustrates a third exemplary method for generating a security key by binding a subscriber with a device authentication. In this example, subscriber authentication has been previously performed, so the subscriber security context 1206 (e.g., K _ ASME key) already exists. Combined subscriber and device authentication may be initiated by the network to replace an existing security context. This embodiment may be beneficial for devices that may need to establish an initial AKA-based security context to obtain fully qualified or functioning credentials from an operator.

This approach assumes that the MME is aware of the device identifier (e.g., IMEI) and/or device credentials.

MME 1204 sends authentication request 1208 including device challenge to device 1202. In response, device 1202 sends authentication response 1210, including the device response, to MME 1204. The device response may be based on the device challenge and the device identity and/or credentials. At this point, both the device 1202 and MME 1204 may have sufficient information to calculate (compound) the security key K _ ASME _ D (e.g., based on the AKA-based security context and device authentication information).

The MME 1204 may send NAS security mode command 1212 to the device 1202 to replace the existing security context 1206 with a security context based on the new security key K _ ASME _ D (e.g., the security context incorporates both subscriber authentication and device authentication). In response, the device 1202 may generate a new security context based on the security key K _ ASME _ D and may send a NAS security mode complete 1214 message in response.

Note that while various example illustrations herein may perform both subscriber authentication and device authentication via an MME, other network entities may perform some of these functions in combination with or in place of an MME.

One or more of the components, steps, features and/or functions illustrated in figures 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, and/or 12 may be rearranged and/or combined into a single component, step, feature or function or may be implemented in several components, steps, or functions. Additional elements, components, steps, and/or functions may also be added without departing from the disclosure. The apparatus, devices, and/or components illustrated in fig. 1, 5, 6, and/or 8 may be configured to perform one or more of the methods, features, or steps described in fig. 2, 3, 4, 7, and/or 9-12. The novel algorithms described herein may also be efficiently implemented in software and/or embedded in hardware.

It is also noted that at least some implementations are described as processes that are depicted as flow diagrams, flow charts, structure diagrams, or block diagrams. Although a flow diagram may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process terminates when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a procedure corresponds to a function, its termination corresponds to the return of the function to the caller function or the main function.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, or any 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. A 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 any 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 via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

The terms "machine-readable medium," "computer-readable medium," and/or "processor-readable medium" can include, but are not limited to portable or fixed storage devices, optical storage devices, and various other non-transitory media capable of storing, containing, or carrying instruction(s) and/or data. Thus, the various methods described herein may be implemented, in part or in whole, by instructions and/or data that may be stored in a "machine-readable medium," "computer-readable medium," and/or "processor-readable medium" and executed by one or more processors, machines, and/or devices.

The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, in a combination of the two, in the form of a processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory storage medium known in the art. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

Various features of the invention described herein may be implemented in different systems without departing from the invention. It should be noted that the above embodiments are merely examples and should not be construed as limiting the present invention. The description of these embodiments is intended to be illustrative, and not to limit the scope of the disclosure. As such, the teachings of the present invention 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 operational in a device, comprising:

performing subscriber authentication with a network entity;

performing device authentication of the device with the network entity;

generating a security key that binds the subscriber authentication with the device authentication; and

securing communications between the device and a serving network using the security key.

2. The method of claim 1, wherein subscriber authentication is based on an authentication key agreement exchange between the device and the network entity.

3. The method of claim 1, wherein device authentication is based on a challenge-response exchange between the device and the network entity.

4. The method of claim 1, wherein subscriber authentication is performed by a first authentication server that is part of the network entity and device authentication is performed by a second authentication server that is part of the network entity.

5. The method of claim 1, wherein the device authentication is performed by:

receiving data encrypted with a public key of the device from the network entity;

decrypting the encrypted data using the corresponding private key; and

knowledge of the data is then demonstrated to the network entity that the device is provided with.

6. The method of claim 1, further comprising:

sending an attach request from the device to the network entity, the attach request including an indication of device authentication capabilities of the device.

7. The method of claim 1, wherein device authentication is protected by at least one key generated during the subscriber authentication.

8. The method of claim 1, wherein subscriber authentication and device authentication are performed concurrently in a combined message exchange.

9. The method of claim 1, wherein subscriber authentication is performed in a security exchange earlier and separate from the device authentication.

10. The method of claim 1, wherein the security key is generated as a function of at least a first key obtained from a subscriber authentication and a second key obtained from a device authentication.

11. The method of claim 10, wherein the security key is also a function of a network nonce and a device nonce.

12. The method of claim 1, wherein the device is a relay node that appears to the network entity as an access terminal and to one or more access terminals as a network device.

13. The method of claim 1, wherein the security key is generated by the device and the network entity separately.

14. The method of claim 1, further comprising:

providing a subscriber-specific key as part of a service agreement, wherein the subscriber-specific key is used for the subscriber authentication; and

providing a device-specific key in the device during manufacture, wherein the device-specific key is used for the device authentication.

15. An apparatus, comprising:

a communication interface; and

a processing circuit coupled to the communication interface, the processing circuit adapted to:

performing subscriber authentication with a network entity;

performing device authentication of the device with the network entity;

16. The apparatus of claim 15, wherein subscriber authentication is based on an authentication key agreement exchange between the apparatus and the network entity.

17. The device of claim 15, wherein device authentication is based on a challenge-response exchange between the device and the network entity.

18. The device of claim 15, wherein device authentication is performed by:

decrypting the encrypted data using the corresponding private key; and

19. The apparatus of claim 15, further comprising:

20. The apparatus of claim 15, wherein the apparatus authentication is protected by at least one key generated during the subscriber authentication.

21. The apparatus of claim 15, wherein subscriber authentication and device authentication are performed concurrently in a combined message exchange.

22. The apparatus of claim 15, wherein subscriber authentication is performed in a security exchange earlier and separate from the apparatus authentication.

23. The apparatus of claim 15, wherein the security key is generated as a function of at least a first key obtained from subscriber authentication and a second key obtained from device authentication.

24. The apparatus of claim 15, wherein the apparatus is a relay node that appears to the network entity as an access terminal and to one or more access terminals as a network device.

25. The apparatus of claim 15, further comprising:

a removable storage device coupled to the processing circuit and storing a subscriber-specific key for the subscriber authentication; and

a secure storage device coupled to the processing circuit and storing a device-specific key for the device authentication.

26. An apparatus, comprising:

means for performing subscriber authentication with a network entity;

means for performing device authentication of the device with the network entity;

means for generating a security key that binds the subscriber authentication with the device authentication; and

means for securing communications between the device and a serving network using the security key.

27. The apparatus of claim 26, further comprising:

means for storing a subscriber-specific key for the subscriber authentication; and

means for storing a device-specific key for the device authentication.

28. A processor-readable medium comprising instructions operational on a device, which when executed by a processor, cause the processor to:

performing subscriber authentication with a network entity;

performing device authentication of the device with the network entity;

29. A method operational in a network entity, comprising:

performing subscriber authentication with a device;

performing device authentication of the device;

securing communications between the network entity and the device using the security key.

30. The method of claim 29, wherein subscriber authentication is based on an authentication key agreement exchange between the network entity and the device.

31. The method of claim 29, wherein device authentication is based on a challenge-response exchange between the network entity and the device.

32. The method of claim 29, wherein the device authentication comprises:

receiving a certificate from the device;

verifying that the certificate associated with the device has not been revoked.

33. The method of claim 29, further comprising:

receiving an attach request from the device, the attach request including an indication of device authentication capabilities of the device.

34. The method of claim 29, wherein device authentication is protected by at least one key generated during the subscriber authentication.

35. The method of claim 29, wherein subscriber authentication and device authentication are performed concurrently in a combined message exchange.

36. The method of claim 29, wherein subscriber authentication is performed in a security exchange earlier and separate from the device authentication.

37. The method of claim 29, wherein the security key is generated as a function of at least a first key obtained from subscriber authentication and a second key obtained from device authentication.

38. The method of claim 29, wherein the security key is generated by the device and the network entity separately.

39. The method of claim 29, further comprising:

obtaining a subscriber-specific key as part of a service agreement, wherein the subscriber-specific key is used for the subscriber authentication; and

obtaining a device-specific key for the device, the device-specific key being used for the device authentication.

40. A network entity, comprising:

a communication interface; and

performing subscriber authentication with a device;

performing device authentication of the device;

41. The network entity of claim 40, wherein subscriber authentication is based on an authentication key agreement exchange between the network entity and the device.

42. The network entity of claim 40, wherein device authentication is based on a challenge-response exchange between the network entity and the device.

43. The network entity of claim 40, wherein the processing circuit is further configured to:

44. The network entity of claim 40, wherein device authentication is protected by at least one key generated during the subscriber authentication.

45. The network entity of claim 40, wherein subscriber authentication and device authentication are performed concurrently in a combined message exchange.

46. The network entity of claim 40, wherein subscriber authentication is performed in a security exchange earlier and separate from the device authentication.

47. The network entity of claim 40, wherein the security key is generated as a function of at least a first key obtained from a subscriber authentication and a second key obtained from a device authentication.

48. The network entity of claim 40, further comprising:

49. A network entity, comprising:

means for performing subscriber authentication with a device;

means for performing device authentication of the device;

means for securing communications between the network entity and the device using the security key.

50. A processor-readable medium comprising instructions operational on a network entity, which when executed by a processor, cause the processor to:

performing subscriber authentication with a device;

performing device authentication of the device;