SECURE DISTRIBUTED HANDOVER SIGNALING

CROSS REFERENCE TO RELATED APPLICATIONS

[1] This application claims the benefit of U.S. Provisional Application No. 60/755,793 filed on January 4, 2006, and which is incorporated herein by reference.

FIELD OF ART

[2] The invention relates generally to communications networks. More specifically, the invention provides for security measures in a communication network.

BACKGROUND

[3] Communication networks have gained great importance in information exchange. For example, a network for communication of mobile media content provides a scalable method for delivering media streams to a large number of clients. As the availability of network infrastructure increases, it becomes possible to implement the exchange and communication of enhanced media services.

[4] In a typical network, a client connects to the network service. The service is expected to be available to the client when the client desires the service. However, in many cases, a user or organization may be deprived of the desired service due to a breach of the security of the system. For example, a denial of service (DoS) attack may occur that disrupts service provision or may even destroy programming or needed files in the system. Such DoS attacks may result in large costs in terms of both time and money.

[5] In a typical DoS attack, a user is denied access to a desired resource. There are many types of DoS attacks but most have a common goal of depriving the victim of services or resources that the victim would be expected to have access to. Such attacks can result in loss in productivity and resources. Therefore, there

exists a need for a method and system for preventing attacks on a communication system, preserving the integrity of the communication system, and/or ensuring proper data exchange in a communication network.

SUMMARY

[6] The following presents a simplified summary in order to provide a basic understanding of some aspects of the invention. The summary is not an extensive overview of the invention. It is neither intended to identify key or critical elements of the invention nor to delineate the scope of the invention. The following summary merely presents some concepts of the invention in a simplified form as a prelude to the more detailed description below.

[7] In one example of the invention, a method is provided for a secured handover procedure for a mobile communication device. In one example, a measurement report including a Nonce associated with the mobile communication device is sent to a source base station. The source base station and a target base station may communicate context information.

[8] In another example, the mobile communication device may confirm handover with the target base station. In another example, the target base station may forward signed and partially encrypted content to a core network for verification of handover messages.

BRIEF DESCRIPTION OF THE DRAWINGS

[9] A more complete understanding of the present invention and the advantages thereof may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:

[10] FIG. 1 illustrates a block diagram of a wireless communication system in which various aspects of the present invention may be implemented.

[11] FIG. 2 illustrates a block diagram of a mobile terminal in accordance with an aspect of the present invention.

[12] FIG. 3 illustrates a system in which a handover decision to a target device may be derived via a corresponding evolved node-B (eNB) or base station in accordance with an aspect of the present invention.

[13] FIG. 4 is a diagram illustrating an example of proactive intra-radio access handoff security in accordance with an aspect of the present invention.

[14] FIG. 5 is a flowchart illustrating the example of proactive intra-radio access handoff security of FIG. 4 in accordance with an aspect of the present invention.

[15] FIG. 6 a diagram illustrating an example of proactive security handover with new round trip in accordance with an aspect of the present invention.

[16] FIG. 7 is a flowchart illustrating the example of proactive security handover with new round trip of FIG. 6 in accordance with an aspect of the present invention.

[17] FIG. 8 a diagram illustrating an example of proactive handover with a pre- distributed SKC in accordance with an aspect of the present invention.

[18] FIG. 9 is a flowchart illustrating the example of proactive handover with a pre- distributed SKC of FIG. 8 in accordance with an aspect of the present invention.

DETAILED DESCRIPTION

[19] In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present invention.

[20] The present invention may be utilized across a broad array of networks and communication protocols. Figure 1 illustrates an example of a wireless communication system 110 in which the systems and methods of the invention may be employed. One or more network-enabled mobile devices 112, such as a personal digital assistant (PDA), cellular telephone, mobile terminal, personal video recorder, portable television, personal computer, digital camera, digital camcorder, portable audio device, portable radio, or combinations thereof, are in communication with a service source 122 through a broadcast network 114 and/or cellular network 116. Although mobile devices are described, the present invention is not so limited. For example, aspects of the present invention may be provided in stationary devices. In an example of a stationary device, a backchannel for contacting the service providing entity may further be provided. The mobile terminal/device 112 may comprise a digital broadcast receiver device. The service source 122 may be connected to several service providers that may provide their actual program content or information or description of their services and programs to the service source that further provides the content or information to the mobile device 112. The several service providers may include but are not limited to one or more television and/or digital television service providers, AM/FM radio service providers, SMS/MMS push service providers, Internet content or access providers.

[21] The broadcast network 114 may include a radio transmission of IP datacasting over DVB-H. The broadcast network 114 may broadcast a service such as a digital or analog television signal and supplemental content related to the service via transmitter 118. The broadcast network may also include a radio, television or IP datacasting broadcasting network. The broadcast network 114 may also transmit supplemental content which may include a television signal, audio and/or video streams, data streams, video files, audio files, software files, and/or video games. In the case of transmitting IP datacasting services, the service source 122 may communicate actual program content to user device 112 through the broadcast network 114 and additional information such as user right and

access information for the actual program content through the cellular network 116.

[22] The mobile device 112 may also contact the service source 122 through the cellular network 116. The cellular network 116 may comprise a wireless network and a base transceiver station transmitter 120. The cellular network may include a second/third-generation/fourth-generation (2G/3G/4G) cellular data communications network, a Global System for Mobile communications network (GSM), OMA broadcast networks, FLO, MBMS, or other wireless communication network such as a WLAN or WiMAX networks.

[23] In one aspect of the invention, mobile device 112 may comprise a wireless interface configured to send and/or receive digital wireless communications within cellular network 116. The information received by mobile device 112 through the cellular network 116 or broadcast network 114 may include user selection, applications, services, electronic images, audio clips, video clips, and/or WTAI (Wireless Telephony Application Interface) messages. As part of cellular network 116, one or more base stations (not shown) may support digital communications with receiver device 112 while the receiver device is located within the administrative domain of cellular network 116.

[24] As shown in Figure 2, mobile device 112 may include processor 128 connected to user interface 130, memory 134 and/or other storage, and display 136. Mobile device 112 may also include battery 150, speaker 152 and antennas 154. User interface 130 may further include a keypad, touch screen, voice interface, four arrow keys, joy-stick, data glove, mouse, roller ball, touch screen, or the like. In addition, the mobile device 112 may include a parsing module 180 for receiving information in a service guide (i.e., ESG fragment) and parsing the information to determine elements, sub-elements and attributes for compiling a service/interaction offering or message template. Also, the mobile device 112 may include a template compiler 190 for compiling a message template based on the attributes or sub-elements in the ESG fragment.

[25] Computer executable instructions and data used by processor 128 and other components within mobile device 112 may be stored in a computer readable memory 134. The memory may be implemented with any combination of read only memory modules or random access memory modules, optionally including both volatile and nonvolatile memory, wherein some of the memory modules may be detachable. Software 140 may be stored within memory 134 and/or storage to provide instructions to processor 128 for enabling mobile device 112 to perform various functions. Alternatively, some or all of mobile device 112 computer executable instructions may be embodied in hardware or firmware (not shown).

[26] Mobile device 112 may be configured to receive, decode and process transmissions based on the Digital Video Broadcast (DVB) standard, such as DVB-H or DVB-MHP, through a specific DVB receiver 141. Additionally, receiver device 112 may also be configured to receive, decode and process transmissions through FM/AM Radio receiver 142, WLAN transceiver 143, and telecommunications transceiver 144. Further the mobile device may be configured to receive transmissions based on the Digital Audio Broadcasting (DAB) standard (not shown). In one aspect of the invention, mobile device 112 may receive radio data stream (RDS) messages.

[27] In an example of the DVB standard, one DVB 10 Mbit/s transmission may have 200, 50 kbit/s audio program channels or 50, 200 kbit/s video (TV) program channels. The mobile device 112 may be configured to receive, decode, and process transmission based on the Digital Video Broadcast-Handheld (DVB-H) standard or other DVB standards, such as DVB-MHP, DVB-Satellite (DVB-S), DVB-Terrestrial (DVB-T) or DVB-Cable (DVB-C). Similarly, other digital transmission formats may alternatively be used to deliver content and information of availability of supplemental services, such as ATSC (Advanced Television Systems Committee), NTSC (National Television System Committee), ISDB-T (Integrated Services Digital Broadcasting - Terrestrial), DAB (Digital Audio Broadcasting), DMB (Digital Multimedia Broadcasting) or

DIRECTV. Additionally, the digital transmission may be time sliced, such as in DVB-H technology. Time-slicing may reduce the average power consumption of a mobile terminal and may enable smooth and seamless handover. Time- slicing consists of sending data in bursts using a higher instantaneous bit rate as compared to the bit rate required if the data were transmitted using a traditional streaming mechanism. In this case, the mobile device 112 may have one or more buffer memories for storing the decoded time sliced transmission before presentation.

[28] FIG. 3 illustrates a system in which user equipment (UE), such as a mobile communication device, may derive a handover decision to a target device via a corresponding evolved node-B (eNB) or base station. As illustrated in the example of FIG. 3, user equipment (UE) 301 may interact with a first base station 302 to transmit a measurement report to the first base station 302. The measurement report may include, for example, a nonce (i.e., a parameter that may vary with time that may limit or prevent unauthorized access to data) corresponding to the UE 301. The UE 301 may further communicate with a second base station 303. For example, the UE 301 may transmit a message to the second base station 303 to confirm a handover. The message to confirm the handover may include a variety of parameters.

[29] Also, the first base station 302 and the second base station 303 may communicate during the handover. For example, the first base station 302 may transmit a message to the second base station 303 to provide the context of handover in an associated message. The context information may further be encrypted to protect against eavesdroppers between the first base station 302 and the second base station 303. For example, the context information may be encrypted with a UE specific protection key that may be shared among the first base station 302, the second base station 303, and any base station listed in the context information of the UE 301. The UE specific protection used to encrypt the context information may be transported in an encrypted form (encrypted for the second eNB (e.g., second base station 303) by a third node 304 in the context

information. The context information may also include other keying material that is encrypted to the second base station by a third node in the network 304. This other keying material may be used to create encryption and integrity protection keys for the session between UE and the second node.

[30] FIGS. 4 and 5 illustrate one example of proactive intra-radio access handoff security. In this example, a UE 301 is operatively connected to a source base station (eNBl) 302. The UE 301 sends a measurement report to eNBl 302 to initiate a handover to a target device. In this example, the target device is operatively connected to a target base station (eNB2) 303. The measurement report may be a signed measurement report that may contain a nonce corresponding to the UE 301 (Nonceus). The Nonceu _E niay further be a new Nonceu _E that has not been previously used to create a key for encryption.

[31] The source base station 302 may receive the measurement report (401, STEP 501) including the Nonceu _E and may derive a handover decision to the target base station 303 based on the received measurement report and Nonceu _E - Hence, in this example, the source base station 302 initiates a handoff procedure for the UE 301 based on the measurement report from the UE 301. The source base station 302 may generate a message (e.g., a context push message) to initiate the handoff procedure for UE 301 (402, STEP 502). The context push message may include Session Keys Context (SKC) that may be specific to UE 301. The context push message may further include the Nonceu _E received by the source base station in the measurement report. In addition, the context push message may include identifiers for the source base station (e.g., ID _eNB i) and/or the target base station (e.g., ID _e NB2), as well as encryption associated parameters and information such as a NoncβN _E T generated at the source base station 302, a temporary identifier corresponding to the UE or UE_TID (UE temporary identifier) parameter and/or other RAN context information. This information may also be included in the context push message and may provide further security to the transmitted data. For example, the UE_TID and RAN context information may be encrypted to protect against eavesdroppers from

intercepting messages communicated between the source base station 302 and the target base station 303. In one example, the UE_TID and RAN context information may be encrypted with a Session Keys Context Protection Key (SPK) that corresponds to the UE 301 (i.e., SPK _UE ). The SPKUE may be a protection key that is shared among base stations that are included in the SKC of the UE 301 and may define the base stations authorized for data access. For example, each row in the SKC of the UE 301 may include the SPKUE encrypted for the corresponding base station.

[32] Also in this example, the target base station 303 may receive the context push message from the source base station 302 (402, STEP 502). Based on the context push message received, the target base station 303 may process the information (STEP 503). For example, the target base station may check if the received message was correctly transmitted and received or whether the message received was actually targeted to the target base station. Verification of proper delivery of the message may be accomplished in a variety of ways. For example, the context push message may include an identification parameter, such as ID _eN B ₂ , for identifying the target base station for receiving the corresponding message. Identifying the base station as the target base station may prevent the data packet from being replayed by an attacker for multiple base stations, for example.

[33] The target base station may further verify the row of the SKC that is created for the target base station in the core network (CN) to verify the integrity protection of the context push message from the source base station. Also, the target base station may decrypt the corresponding SPKU _E and may create a corresponding cipher key (CK) and/or integrity key (IK) for the corresponding UE 301 (e.g., CKuE_eNB2 and IKuE_eNB2) and may decrypt the UE_TID (UE temporary identity), nonceuε, nonceNET, and RAN context information received from the source base station.

[34] Also, the target base station may create a cipher key (CK) and/or integrity key (IK) corresponding to the UE 301 (e.g., CKuE_eNB2 and IKuE_eNB2) for encrypting parameters of a data communication. For example, the target base station may create the CKuE_eNB2 and encrypt a Radio link identifier (e.g., RLID _e NB2), Context ID (CTXID _eN B2), and/or a UEJTID corresponding to the target base station. In another example, the target base station may create the CK and/or IK based on a SKuE_eNB2 in the SKC row for the target base station, and/or Nonceu _E3 and/or NonceNET, and/or the UE_TID parameter. The content may thus be encrypted at the target base station and signed. Signing of the encrypted content may be accomplished, for example, with an integrity key (e.g., IKuE _j sNB2), derived from a target base station identifier (e.g., ID _e NB2) ₅ and/or NonceuE and/or Nonc ^β NET-

[35] The target base station may further send a message (e.g., a context confirm message) to the source base station (403, STEP 504). The context confirm message may include, for example, the signed (e.g., Siga.χj _E _ _eNB2 { ^< content>}) and encrypted (e.g., Encryptu _E _eNB2{<co«fe«t>}) contents which may include identifiers of the source and target base stations (e.g., ID _e NBh ID _e NB2), Nonceuε, NoncβNet, as well as the Radio link identifier (RLID _e NB2) and/or the Context ID (CTXID _e NB2)- The context confirm message may also be signed. For example, the context confirm message may be signed with an integrity key (e.g., IKUE_CTX) that may be derived from the SPKUE.

[36] As illustrated in the example of FIGS. 4 and 5, the source base station may receive the context confirm message from the target base station (STEP 504) and may further forward the content of the message in a handover command (404, STEP 505). The handover command message may include, for example, the NoncβNET and may further be signed with an integrity key (e.g., IKuE_eNBi) corresponding to the source base station and completely or partially signed with an integrity key (e.g. IK u _E _e _NB2 ) corresponding to the target bases station. The UE 301 may receive the handover command message and may verify the signature from the source base station and target base station. The UE 301 may

thus receive parameters and data corresponding to the encrypted data including the NonceuE, NonceNET, AAA-Key, ID _e NB2 and UE_TID. Based on the received data, the UE 301 may derive the integrity key (IK) and the cipher key (CK) corresponding to the target base station (e.g., IKuE_eNB2 and CKuE_eNB2)- The UE 301 may thus verify the signature from the target base station based on the IK and CK and decrypt the RLID _e NB2 and CTXID _e NB2 received.

[37] The UE 301 may send a message to complete the handoff to the target base station. For example, the UE 301 may send a handover confirm message to the target base station (405, STEP 506). The Handover confirm message may include, for example, a signed and encrypted content created with keys shared between the UE 301 and the core network (CN) (e.g., IKU _E _ _C N, CKUE_ _C N). Also, the handover confirm message may contain identification parameters for the source and target base stations (e.g., ID _e NBi or ID _e NB2), NonceuE, NonceNET, and/or UE_TID, which may also be encrypted such that UE_TID based location tracking may be prevented. The message content may further be signed for the source base station such that the source base station may check that the UE 301 was successfully connected to the target base station.

[38] The target base station may receive the handover confirm message (STEP 506) and may forward the message as a confirmation message (e.g., Handover Completed message) to the source base station (406, STEP 507). The source base station receives the handover completed message and may verify the accuracy of the information in the handover completed message such as NonceuE, NonceNET information of identification information of the base stations and that the information originated from the UE 301.

[39] In addition, the signed and/or encrypted information may be further forwarded to the core network (including the mobility management entity (MME) and/or user plane entity (UPE)). For example, the message may be used as verification in the core network for the handover messages. In this example, the target base station may send a signed and encrypted message (e.g., a Change Mapping

message) to the UPE (407, STEP 508) or may send a signed and encrypted (e.g., a relocation indication message) to the MME (408, STEP 509). The change mapping message and/or the relocation indication message may contain the handover confirm message that was signed and partially encrypted for the core network. The messages may further include the UE_TID.

[40] The target base station may receive an acknowledgement message from the UPE (409, STEP 510) and/or the MME (410, STEP 510) responsive to the change mapping message and the relocation indication message, respectively. In addition, the UPE may notify the MME (411, STEP 511).

[41] In this example, the signature of the UE in the message may prevent a hijacked base station from spoofing location updates to the core network (CN) such as to the MME or UPE. Also, the signed message prevents an attacker from injecting a location update message to the core network (CN, MME, UPE). In another example, the hijacked base station may not replay the location update messages and may not launch DoS attacks against other base stations or to the core network.

[42] FIGS. 6 and 7 illustrate another example of proactive handover with new round trip. In this example, the source base station may receive a measurement report from the UE 301 including a NonceuE (601, STEP 701). The source base station may generate a Nonce _NET and send a message (e.g., a handover request message) to the UE 301 responsive to the measurement report received from the UE 301 (602, STEP 702) and/or as an indication of handoff preparation to a target base station. The handover request may include the Nonceu _E received from the UE 301 and the NonceNET- Also, the handover request may contain an identifier for the target base station (e.g., ID _eNB 2).

[43] The UE 301 may receive the handover request from the source base station (602) and may derive a corresponding session key associated with the UE 301 and the target base station (e.g., SKuE_eNB2)- The session key may be based on

any number of encryption associated parameters such as the identifier of the target base station (ID _e NB2), Nonceuε, and/or Nonce^T, UE_TID, etc.

[44] The UE 301 may send a response message (e.g., handover response message) in response to the handover request message from the source base station (603, STEP 703). In this example, the handover response may include identifier information for the source base station (e.g., IDe _NB i) ₅ identifier information for the target base station (e.g., IDeNB ₂ ), Nonceuε, and/or Nonce^T- In addition, the handover response message may be signed and/or at least partially encrypted.

[45] The source base station may receive the handover response message from the UE 301 (STEP 703) and may forward the message to the target base station (604, STEP 704). For example, the source base station may forward the message to the target base station in a context push message (STEP 704). The context push message may contain additional parameters as described above.

[46] The target base station may receive the context push message from the source base station (604) and may process the message. For example, the target base station may verify that the receive message is intended for the target base station and may decrypt the SKC entry for the target base station. The target base station may also derive a cipher key (CK) and an integrity key (IK) associated with the UE 301. The CK and IK (e.g., CK _U E_ _CT X and IKU _E CT _X ) may be derived from the SKP _UE , for example. Also, the target base station may decrypt data received in the context push message. For example, the target base station may decrypt UE_TID, Nonceuε, Nonce _NE T, and RAN context received in the context push message from the source base station. In another example, the target base station may also derive CK and IK (e.g., CKuE-eNB2 and IKuE_eNB2) based on encryption associated parameters (e.g., SKuE-eNB2, NonceuE, NonceNET, UE_TID), may check the UE signature, may store the UE RAN context and SKC, and may reserve RLID and CTXID associated with the target base station (e.g., RLIDe _NB2 , CTXID _eNB2 )- The target base station may send a message (e.g., context confirm message) to confirm the context to the source base station (605,

STEP 705). For example, the target base station may send a context confirm message which may be signed and which may include identification information (e.g., IDeNBi ₅ ID _e NB2) ₅ NonceuE ₅ NoncβNET, and encryption information such as

UE_TID, CTXIDeNB ₂ , RLIDeNB ₂ -

[47] The source base station in this example may further send a message to the UE 301 responsive to the context confirm message. For example, the source base station may forward the context confirm message in a handover command to the UE (606, STEP 706). The UE may receive the handover command and may verify the signatures of the source base station and the target base station. The UE 301 may also decrypt the new RLID and CTXID.

[48] FIGS. 8 and 9 illustrate another example of proactive handover with a pre- distributed SKC and/or RAN context. In this example, the source base station may receive a measurement report from the UE 301 including a Nonceu _E (801, STEP 901). The source base station may generate a NoncβNET and send a message (e.g., a Context pre-push message) to the target base station responsive to the measurement report received from the UE 301 (802, STEP 902). Alternatively, the context pre-push message may be independent of the measurement report from the UE 301. The source base station may send one or multiple messages (e.g. Context pre-push message) to one or multiple base stations for preparing the base station(s) to receive the UE if needed. The Context pre-push message may include the Nonceu _E received from the UE 301 and the Nonce _N ET- Also, the handover request may contain an identifier for the source base station (e.g., IDeNBi) ₃ an identifier for the target base station (e.g., IDeNB _x ) ₅ UE_TID, and or RAN context. If the Context-pre push message does not include an identifier of a base station to which the message is sent to, then it can be re-sent as-is to multiple base stations.

[49] The target base station in this example receives the context pre-push message and may verify and decrypt the SKC entry for the target base station, derive a CK and IK (e.g., CKUE_CTX and IDUE_ _C TX) from the SKPU _E and verify the context

push message. In addition, the target base station may decrypt the UEJTID, NonceuEj NoncβNET, and the RAN context and may derive the CK and IK (e.g., CKuE_eNB2 and IKuE_eNBx) associated with the target base station based on the SKuE_eNBx, NonceuE, NonceNETj and UE_TID. Also, the target base station may store the UE RAN context and the SKC and reserve an RLID and CTXID associated with the target base station (e.g., RLIDeNBx and CTXIDeNBx)- The target base station may also send a context pre-confirm message to the source base station responsive to the context pre-push message. The context pre- confirm message may be signed and may be partially encrypted and may include identification information (e.g., ID _e NBi, IDeNBx, Nonceuε, NonceNET, UE_TID, CTXIDeNBx, or RLIDeNBx, for example.

[50] The source base station may receive the context pre-confirm and may store the message(s) received. The source base station may then also receive a measurement report from the UE 301 including a Nonceu _E and may locate the message(s) corresponding to the target base station resource message(s) responsive to the measurement report. The source base station may forward the context pre-confirm message to the UE 301 as a handover command responsive to receiving the measurement report. The UE 301 may receive the handover command and may derive SKu _E -e _NB x based on encryption parameters such as the AAA-Key, ID _e NBx, Nonceuε, NoncβNET, and/or UE_TID.

[51] The present invention includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques. Thus, the spirit and scope of the invention should be construed broadly as set forth in the appended embodiments.