WO2008152611A1 - Dispositif, procédé et progiciel produisant un conteneur transparent - Google Patents

Dispositif, procédé et progiciel produisant un conteneur transparent Download PDF

Info

Publication number
WO2008152611A1
WO2008152611A1 PCT/IB2008/052352 IB2008052352W WO2008152611A1 WO 2008152611 A1 WO2008152611 A1 WO 2008152611A1 IB 2008052352 W IB2008052352 W IB 2008052352W WO 2008152611 A1 WO2008152611 A1 WO 2008152611A1
Authority
WO
WIPO (PCT)
Prior art keywords
user equipment
network node
identifier
transparent container
nonce
Prior art date
Application number
PCT/IB2008/052352
Other languages
English (en)
Inventor
Benoist Sebire
Leping Huang
Jukka Ranta
Original Assignee
Nokia Corporation
Nokia, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Corporation, Nokia, Inc. filed Critical Nokia Corporation
Publication of WO2008152611A1 publication Critical patent/WO2008152611A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
    • H04W36/0038—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information of security context information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic

Definitions

  • the exemplary and non-limiting embodiments of this invention relate generally to wireless communications systems and, more specifically, relate to handovers of a user equipment/mobile station from one network node to another.
  • DL downlink e-/E- evolved also known as LTE
  • LTE long term evolution also known as 3.9G
  • This invention is related to mobility handling in a wireless communication network, and embodiments are detailed in the context of E-UTRAN (e.g., 3GPP Release 8).
  • E-UTRAN e.g., 3GPP Release 8
  • the current assumption in E-UTRAN is to have a network-prepared and network-controlled handover procedure, which is also known as a backward handover procedure (BHO).
  • BHO backward handover procedure
  • This is stated explicitly in 3GPP TS 36.300 V8.0.0 (2007-03) at Section 10.1.2.1 HANDOVER: "The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN.”
  • a detailed description of the handover procedure for E- UTRAN can be found at subclause 10.1.2.1. Relevant portions of 3GPP TS 36.300 V8.0.0 (2007-03) are attached hereto as Exhibit A.
  • the E-UTRAN network includes a plurality of eNBs 12a, 12b, 12c that communicate with one another via a X2 interface or link. Each is coupled to one or more MME/SAE Gateways 14a, 14b via a S1 interface or link. Each of the eNBs 12a-c control one or more UEs (not shown) in its cell. In the prior art, BHOs are initiated by one of the eNBs 12a-c for handing over a specific UE within its cell to another eNB 12a-c.
  • the source eNB refers to the BS (or more generically the network node) from which the UE moves and the target eNB refers to the BS (or more generically the network node) under whose control the UE is moving.
  • an FHO procedure is not network- prepared but instead it is the user equipment UE that selects the target eNB and it is the UE which initiates the handover procedure from the source eNB to the target eNB.
  • the target eNB needs to learn the UE context. In the E-UTRAN system this encompasses the security context, UE capability context and QoS context.
  • One problem related to FHO is how to establish a secure communication between the UE and the source eNB through the target eNB. Because FHO is user-initiated, the target eNB does not have the UE's context initially, and cannot communicate securely with the UE until given it.
  • a method that includes establishing with a serving network node an identifier for a user equipment, and at the user equipment generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node. Further in the method is sent to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter the user equipment is handed over to the target network node.
  • the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed toward executing a handover.
  • the actions include establishing with a serving network node an identifier for a user equipment, generating a transparent container and encrypting the generated transparent container with a security context of the user equipment that is known to the serving network node, sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context, and thereafter handing over to the target network node.
  • an apparatus that includes a first module (e.g., transceiver circuitry that includes a transmitter and receiver) and a second module (e.g., processor circuitry).
  • the first module is configured to establish with a serving network node an identifier for the apparatus.
  • the second module is configured to generate a transparent container and to encrypt the generated transparent container with a security context of the apparatus that is known to the serving network node.
  • the first module is further configured to send to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
  • this apparatus is the user equipment or an integrated circuit configured for use within the user equipment.
  • an apparatus that includes communicating means (such as a transceiver that includes a transmitter and a receiver) for establishing with a serving network node an identifier for the apparatus, and computing means (such as a processor) for generating a transparent container and encrypting the generated transparent container with a security context of the apparatus that is known to the serving network node.
  • the communicating means is further for sending to a target network node the encrypted transparent container and the identifier which is unencrypted but not the security context so as to handover the apparatus to the target network node.
  • a target network node receiving from a user equipment an encrypted transparent container and an identifier for the user equipment.
  • the received identifier is unencrypted.
  • the encrypted transparent container and the unencrypted identifier are forwarded from the target network node to a source network node, a context for the user equipment is received at the target network node from the source network node, and thereafter the target network node receives handover of the user equipment.
  • a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover.
  • the actions include receiving from a user equipment an encrypted transparent container and an identifier for the user equipment (the received identifier is unencrypted), forwarding to a source network node the encrypted transparent container and the unencrypted identifier, receiving from the source network node a context of the user equipment, and thereafter receiving handover of the user equipment.
  • an apparatus that includes a first module (e.g., a receiver of a transceiver) and a second module (e.g., a modem) and a third module (e.g., a processor).
  • the first module is configured to receive from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted.
  • the second module is configured to forward to a source network node the encrypted transparent container and the unencrypted identifier.
  • the second module is further configured to receive from the source network node a context of the user equipment.
  • the third module is configured to receive handover of the user equipment.
  • this apparatus is a target network node or an integrated circuit configured for use within a target network node.
  • an apparatus that includes receive means (such as a receiver), communication means different from the receive means (such as a modem) and computing means (such as a processor).
  • receive means such as a receiver
  • communication means different from the receive means such as a modem
  • computing means such as a processor.
  • the receive means is for receiving from a user equipment an encrypted transparent container and an identifier for the user equipment, where the received identifier is unencrypted.
  • the communication means is for forwarding to a source network node the encrypted transparent container and the unencrypted identifier, and further for receiving from the source network node a context of the user equipment.
  • the computing means is for receiving handover of the user equipment.
  • [0015] in accordance with another exemplary embodiment of the invention is a method that includes establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
  • the invention is a memory embodying a program of instructions that are executable by a processor for performing actions directed to executing a handover.
  • the actions include establishing with a user equipment an identifier for the user equipment, receiving from a target network node an encrypted transparent container and the identifier for the user equipment which is unencrypted, decrypting the transparent container received from the target network node with a security context of the user equipment, and responsive to matching the established identifier with the identifier received from the target network node, sending to the target network node a context of the user equipment.
  • an apparatus that includes a first module (e.g., a transceiver), a second module (e.g., a modem), and a third module (e.g., a processor).
  • the first module is configured to establish with a user equipment an identifier for the user equipment.
  • the second module is configured to receive from a target network node an encrypted transparent container and the identifier for the user equipment, which identifier is received unencrypted.
  • the third module is configured to match the established identifier with the identifier received from the target network node and to decrypt the transparent container received from the target network node with a security context of the user equipment.
  • the first module is further configured, responsive to the third module matching the established identifier with the received identifier, to send to the target network node a context for the user equipment.
  • this apparatus is a serving network node or an integrated circuit configured for use within a serving network node.
  • first communication means such as a transceiver
  • second communication means such as a modem
  • processing means such as a processor
  • the first communication means is for establishing with a user equipment an identifier for the user equipment.
  • the second communication means is for receiving from a target network node an encrypted transparent container and the identifier for the user equipment, where the received identifier is unencrypted.
  • the processing means is for matching the established identifier with the identifier received from the target network node, and for decrypting the transparent container received from the target network node with a security context of the user equipment. Responsive to the processor matching the established identifier with the received identifier, the first communication means is further for sending to the target network node a context for the user equipment.
  • a method that includes establishing a nonce between a serving access node and a user equipment, wherein establishing may be by receiving the nonce from the user equipment or by the serving access node generating the nonce and sending the generated nonce to the user equipment. Further in the method, from a target network node is received a transparent container that is encrypted with a security context of the user equipment that is valid between the user equipment and the serving access node, and also from the target network node is received a nonce that is unencrypted.
  • the transparent container is from the user equipment by matching the nonce received from the target network node with the nonce established with the user equipment, decrypting the transparent container using the security context of the user equipment, and conditional on the matching, sending to the target network node a context for the user equipment.
  • Figure 1A is a prior art E-UTRAN system architecture overview, reproduced from Figure 4 at section 4 of 3GPP TS 36.300, V8.0.0 (2007-03).
  • Figure 1 B is a prior art E-UTRAN signaling protocol for an Intra-MME/SAE Gateway HO (BHO) of a UE from a source eNB to a target eNB, reproduced from Figure 10.1.2.1 at Section 10.1.2.1.1 of 3GPP TS 36.300, V8.0.0 (2007-03).
  • BHO Intra-MME/SAE Gateway HO
  • Figure 2 shows high-level schematic block diagrams of apparatus in which embodiments of the invention may be implemented.
  • Figure 3 is a signaling diagram for a forward handover procedure according to an embodiment of the invention.
  • Figure 4 is a diagram of method steps executed by the source eNB of Figure 2 according to an exemplary embodiment of the invention.
  • Figure 5 is a diagram of method steps executed by the target eNB of Figure 2 according to an exemplary embodiment of the invention.
  • Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention.
  • the UE sends a transparent container for the source eNB to the target eNB during the FHO procedure.
  • the transparent container is encrypted with security keys of the UE's context (e.g., the UE's security context), and so the content of the transparent container can be understood/deciphered by the source eNB with which the UE has been communicating securely, but not by the target eNB which has not yet securely communicated with the UE.
  • the target eNB sends the transparent containerto the source eNB, where the UE originating the transparent container is authenticated and the transparent container itself is deciphered.
  • the source eNB then sends the UE context to the target eNB and handover of the UE is completed so that the UE is under control of the target eNB and no longer under control of the source eNB.
  • Certain messages of Figure 1 B e.g., handover confirm, handover complete, ACK, release resource, data forwarding, etc.
  • the source eNB then provides the UE context to the target eNB so that it may communicate securely with the UE, completing the forward handover.
  • ciphering/deciphering refers to security-related encryption/decryption, as distinct from non-security related wireless signal processing such as coding/decoding for error control.
  • a wireless network 20 is adapted for communication with a UE 22 via a source eNB [designated eNB (S)] 24 and also via a target eNB 26 [designated eNB (T)].
  • the network 20 may include a serving MME/SAE/radio network controller RNC 28 or other radio controller function known by various terms in different wireless communication systems.
  • the UE 22 includes a digital processor (DP) 2A, a memory (MEM) 22B that stores a program (PROG) 22C, and a suitable radio frequency (RF) transceiver 22D coupled to one or more antennas 22E (one shown) for bidirectional wireless communications over one or more wireless links 21 A, 21 B with the source eNB 24 and with the target eNB 26.
  • DP digital processor
  • MEM memory
  • PROG program
  • RF radio frequency
  • Each of the eNBs 24, 26 also includes a DP 24A, 26A, a MEM 24B, 26B that stores a PROG 24C, 26C, and a suitable RF transceiver 24D, 26D coupled to one or more antennas 24E, 26E.
  • Each of the eNBs 24, 26 may be coupled via a data path 30 (e.g., lub or S1 interface) to the serving or other MME/RNC 28.
  • the MME/RNC 28 includes a DP 28A, a MEM 28B that stores a PROG 28C, and a suitable modem and/or transceiver (not shown separately from the DPs) for communication with either or both of the eNBs 24, 26 over the lub link 30.
  • the source eNB 24 and the target eNB 26 are coupled to one another via a separate bidirectional data link 32 (e.g., X2 interface), and may communicate directly with one another independent of the MME/SAE/RNC 28.
  • a separate bidirectional data link 32 e.g., X2 interface
  • the communications detailed below between the source eNB 24 and the target eNB 26 with respect to embodiments of this invention may be communicated via the S1 interface(s) and via the MME/RNC 28 without loss of generality.
  • communications between the eNBs 24, 26, whether directly or through the MME 28, are via modems at the respective devices which as shown are a part of the illustrated DPs 24A, 26A.
  • a security block 22F that stores a ciphering/deciphering program and related security keys as will be detailed below.
  • the source eNB 24 and the target eNB 26 include similar security blocks 24F, 26F.
  • the MME/RNC 28 may in certain embodiments also include a similar security block, such as where the MME acts as more than a passive conduit for communications between the source eNB 24 and the target eNB 26 for the messages detailed below.
  • each of the UE 22, source eNB 24 and target eNB 26 include a similar security block does not imply that they each store at the same times the same security keys or means to decode/decipher a particular message; in the described embodiments security is enhanced by passing certain security keys between the source eNB 24 and target eNB via the X2 interface 32 (or passively through the MME/SEA 28 where no viable X2 interface is available).
  • At least one of the PROGs 22C, 24C and 26C is assumed to include program instructions that, when executed by the associated DP, enable the electronic device to operate in accordance with the exemplary embodiments of this invention, as will be discussed below in greater detail.
  • Inherent in the DPs 22A, 24A, and 26A is a clock to enable synchronism among the various apparatus for transmissions and receptions within the appropriate time intervals and slots required, and to determine time-validity of the authentication nonce for those embodiments.
  • the PROGs 22C, 24C, 26C may be embodied in software, firmware and/or hardware, as is appropriate.
  • the exemplary embodiments of this invention may be implemented by computer software stored in the MEM 22B and executable by the DP 22A of the UE 22 and similar for the other MEMs and DPs of the eNBs 24, 26, or by hardware, or by a combination of software and/or firmware and hardware in any or all of the devices shown.
  • the various embodiments of the UE 22 can include, but are not limited to, mobile stations, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.
  • PDAs personal digital assistants
  • portable computers having wireless communication capabilities
  • image capture devices such as digital cameras having wireless communication capabilities
  • gaming devices having wireless communication capabilities
  • music storage and playback appliances having wireless communication capabilities
  • Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.
  • the MEMs 22B, 24B and 26B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.
  • the DPs 22A, 24A and 26A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.
  • a transparent container is sent from the UE to the target eNB, which cannot decipher its contents.
  • the following detailed implementation is in the context of E-UTRAN and references specific terminology and messages known for that wireless system protocol, but the more general principles of the invention are not limited to only E-UTRAN systems.
  • the FHO procedures detailed below can be compared to having cell re- reselection in the RRC_CONNECTED / LTE_ACT!VE state, but with the addition of the transparent container.
  • the various names used forthe network entities, connection states, and the messages exchanged herein are not intended to be limiting in any respect, as these entities and states and messages may be identified by any suitable names.
  • One way to implement this embodiment is in a standard (e.g., 3GPP TS) that defines the specific content of the transparent container, and how the source eNB 24 (which receives the transparent container from the target eNB 26) determines from the transparent container exactly which UE 22 originated it and is initiating a FHO.
  • 3GPP TS 3rd Generation Partnership Project
  • Figure 3 is a signalling diagram according to a particular embodiment specific to E-UTRAN implementation, showing the UE 22, source eNB 24, and target eNB 26 from Figure 2.
  • Figure 3 begins with the UE 22 under control of the source eNB 24 as normal, prior to any FHO initiation.
  • the UE 22 and eNB 24 agree in the interchange of message 302 on a UE authenticating nonce, a C-RNTI, or some other identifier for the UE such as a NAS level identity (e.g., IMSI).
  • a NAS level identity e.g., IMSI
  • the UE 22 accesses the target eNB 26, while still under control of the source eNB 24, by performing a random access procedure (see for example 3GPP TS 36.300 subclause 10.1.5), modified with the transparent container as seen in Figure 3.
  • the UE 22 sends a random access RA preamble 304 on the RACH to the target eNB 26 as is known.
  • the target eNB 26 sends to the UE 22 a RA RESPONSE message 306 on the DL- SCH as is known.
  • the UE 22 then sends back to the target eNB 26 a RA CONNECTION REQUEST message 308.
  • RRC CONNECTION REQUEST message 308 generated by the RRC layer at the UE 22 and transmitted via CCCH on UL-SCH to the target eNB 26, a transparent container aimed at the source eNB 24 is included.
  • the transparent container is ciphered and integrity protected with the security keys known to both the UE 22 and the source eNB 24, but not known to the target eNB 26. This ensures that the content of the container cannot be read by the target eNB 26, or by any other network node or other UEs apart from the source eNB 24.
  • the transparent container is sent 310 by the target eNB 26 to the source eNB
  • the target eNB 26 identifies the source eNB 24 by any of various methods, for example having the UE 22 indicate the source eNB 24 identity to the target eNB 26 in the RA CONNECTION REQUEST message or via some other explicit signaling.
  • the source eNB 24 receives 310 from the target eNB 26 the transparent container over the X2 interface. To be able to decipher its content and check the originator (integrity protection), the identity of the UE is given with the message bearing the transport container (308 and 310). Three specific alternatives for that UE identification are detailed: • Before handover, the UE and the source eNB agree on a one time nonce. This nonce is used to authenticate UE, and is updated whenever it is used (or whenever it expires). It is included in plain text (i.e. non-ciphered) in the transparent container. • The C-RNTI used by the UE in the source eNB is included in plain text (i.e. non-ciphered) in the transparent container.
  • a NAS level identity of the UE e.g. IMSI or some mathematical operation on IMSl such as IMSImod128 that protects security of the IMSI itself
  • plain text i.e. non-ciphered
  • the source eNB 24 knows the IMSI or IMSImodi 28 (or similar) already from network access and subscriber identification, it knows the C-RNTI because it assigns it to the UE 22, and it knows the UE authenticating nonce due to explicit signaling at 302 added by embodiments of this invention that use the nonce option to identify the UE 22.
  • the UE authenticating nonce option provides additional security in that tracking movement of the UE 22 is not possible; only the UE 22 and the source eNB 24 know that the particular UE 22 is associated with that particular nonce.
  • An authenticating nonce is generally a number or bit string or initialization vector for the encryption that is used only once, often a random or pseudo-random number/vector issued in an authentication protocol to ensure that old communications are not subject to a replay attack. To ensure that a nonce is used only once, they are often made time-variant and possibly including a suitably granular timestamp in its value, or generated with enough random bits to ensure a probabilistically insignificant chance of repeating a previously generated value.
  • a suitable authentication nonce for the FHO/transparent container purposes detailed herein may be a randomly generated initialization vector or bit string with or without a time stamp.
  • the entity issuing the nonce (the UE 22 or the eNB 24) can simply re-issue to the other entity a new authentication nonce with a refreshed validity period.
  • the source eNB 24 can authenticate the UE 22 and find out the security context (Keys and serial number SN) associated with that UE 22.
  • the source eNB 24 uses those security keys (e.g. K_ ⁇ RRC ⁇ ) and SN to decipher and authenticate 312 the protected content of the transparent container.
  • the exact content of the transparent container itself may vary widely in various implementations, but one embodiment includes a forward handover command included within the transparent container.
  • the source eNB 24 Upon decryption 312 of the container, the source eNB 24 forwards the UE context 314 to the target eNB 26, including keying materials for the security keys. From that message 314 onward, the target eNB 26 has all the information it needs to communicate securely with the UE 22.
  • the same handover is repeated within a short period of time, i.e. the UE 22 moves back to the source eNB 24 and tries the same handover again. This is to be expected in the case of a handover failure.
  • the encryption keys are not necessarily updated in between these events, so it is advantageous to avoid using the same encryption parameters again to cipher the transparent container.
  • a new nonce could be generated in the UE and included as plaintext in the message (e.g., repeat of message 308) carrying the transparent container in such instances.
  • the specifics of how the nonce is used in the initialization vector depends on the encryption algorithm being used, and will vary widely in different implementations of this invention.
  • the COUNT parameter of the Snow algorithm can be set to be the value of the nonce, [see ETSI TC SAGE Specification: "Specification of the 3GPP Confidentiality and Integrity Algorithms UEA2 & UIA2; Document 2: SNOW 3G specification" version 1.0, 2006-01-10.
  • the above ETSI document is referenced at 3GPP TS 35.216 V7.0.0 (2006-06).
  • SNOW 3G is a word-oriented stream cipher that generates a sequence of 32-bit words under the control of a 128-bit key and a 128-bit initialization variable.]
  • Figure 4 is a diagram of method steps executed by the source eNB 24 of
  • the source eNB 24 stores some predetermined identifier for the UE initiating the FHO, of which the three options detailed above are listed as examples. Also at block 402 the source eNB 24 stores the UE context, which it uses for communicating securely with the UE 22.
  • the source eNB 24 receives from a neighboring eNB 26 (the UE's target eNB 26) a transparent container.
  • the message bearing that transparent container may include, unencrypted/plain text, the C-RNTI or the IMSI for the UE 22 or the nonce that was previously arranged/agreed with the source eNB 24 and the UE 22.
  • the source eNB 24 determines from the IMSI/C- RNTI/nonce the UE to which the transparent container applies, and at block 408 the source eNB 24 authenticates the UE that sent the transparent container and deciphers it using the keying materials and security keys of the UE context.
  • the source eNB 24 then sends at block 410 the UE context, including the keying materials and the security keys, to the neighbor eNB which is the target eNB 26.
  • the target eNB 26 then has all the information it needs to communicate securely with the UE 22, and the source eNB 24 deletes the UE 22 from its list of UEs for which it currently is the serving eNB.
  • Figure 5 is a diagram of method steps executed by the target eNB 26 of Figure
  • the target eNB 26 receives from a UE 22, which is not served at that time by the target eNB 26, a random access preamble on the RACH. in reply at block 504 the target eNB 26 sends to the UE 22 a RA RESPONSE message on the DL-SCH, which is a common control channel CCCH.
  • the target eNB 26 receives from the UE 22 a RA CONNECTION REQUEST message that includes a transparent container. As above, this message may include, unencrypted/plain text, the C-RNTI or IMSI or authenticating nonce as plain text identifiers for the UE 22.
  • the target eNB 26 determines which is the source eNB 24 for that UE 22 (e.g., from that RA CONNECTION REQUEST message or from other signalling). Once determined, the target eNB 26 sends at block 510 to the source eNB 24 the transparent container, as well as the C-RNTI or IMSI of the UE 22 or the nonce, whichever predetermined UE identifier is used for FHO and included unencrypted in the transparent container or message bearing that container. At block 512 the target eNB 26 receives from the source eNB 24 the UE context, including security keys and keying materials. The target eNB 26 now has all the information it needs to communicate securely with the UE 22, which it then does at block 514 where the FHO to the target eNB 26 is complete.
  • Figure 6 is a diagram of method steps executed by the UE of Figure 2 according to an exemplary embodiment of the invention.
  • the UE 22 stores at block 602 of Figure 6 the predetermined identifier used for the FHO/transparent container.
  • the predetermined identifier used for the FHO/transparent container.
  • certain security advantages are realized by using the UE authenticating nonce implementation, where the UE itself generates the nonce initialization vector.
  • the UE 22 sends to its chosen target eNB 26 a random access preamble on the RACH.
  • the UE 22 receives from that target eNB 26 a RA RESPONSE message on the DL-SCH, and thereafter at block 608 the UE 22 sends to the target eNB 26 a RA CONNECTION REQUEST message that includes the transparent container.
  • the message from block 608 may also include the C-RNTI or IMSI or nonce as the plain text identifier of the UE 22.
  • the target eNB 26 at this point does not yet have the UE context and its related security keys (from the UE's security context) to decipher the transparent container.
  • the eNB 26 receives those as detailed above with respect to Figure 5, which enables the UE 22 to communicate securely with the target eNB 26 at block 610 using the UE context/security keys that were previously used with the source eNB 24 at block 602.
  • the user equipment e.g., UE 22
  • the message identifies the UE by an unencrypted IMSI or an unencrypted C-RNTI for a cell other than that of the target network node, or an unencrypted authentication nonce.
  • the UE sends the transparent container to the target network node in a RA CONNECTION REQUEST message.
  • the UE prior to initiating FHO the UE exchanges the nonce with a source network node, stores the UE authenticating nonce, and sends it as an identifier of the UE in the same message with (alongside or as part of) the transparent container.
  • the target network node e.g., target eNB 26
  • a method, an apparatus, and a computer program embodied on a computer readable memory and executable by a processor configured to receive from a UE not currently served by the target network node a message that includes an identifier of the UE and a transparent container that is encrypted with a context of the UE, to forward the identifier of the UE and the transparent container to a source network node of the UE without decrypting the container, to receive from the source network node the context of the UE, and thereafter to use the context of the UE to communicate securely with the UE.
  • the transparent container is included in a RA CONNECTION REQUEST message received after the target network node sends to the UE a RA RESPONSE message.
  • the identifier of the UE is one of an IMSI or a C-RNTI for the UE or a nonce which was received in the RA CONNECTION REQUEST message, where for the case of the C-RNTI the C-RNTI is for a cell other than that of the target network node.
  • the source network node e.g., source eNB 24
  • the message comprising the transparent container includes, unencrypted, one of an authentication nonce or the UE's IMSI or the UE's C-RNTI, where the C-RNTI is for the cell of the source network node.
  • the UE authentication nonce is received from the UE at the source network node, or the source network node generates the UE authentication nonce and sends it to the UE, prior to the time the source network node receives from the target network node the message comprising the transparent container.
  • the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof.
  • some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.
  • firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto.
  • While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
  • Embodiments of the inventions may be practiced in various components such as integrated circuit modules.
  • the design of integrated circuits is by and large a highly automated process.
  • Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un identifiant (p. ex., IMSI, IMSI mod 128, C-RNTI, ou nonce) est établi entre un nœud d'accès de desserte (s-BS) et un équipement d'usager (UE). L'UE produit et chiffre un conteneur transparent avec son contexte de sécurité, connu du s-BS. L'UE envoie le conteneur transparent chiffré, auquel est annexé un identifiant non chiffré, à un nœud d'accès cible (t-BS). Pour un transfert intercellulaire direct (FHO), ces éléments sont envoyés dans une procédure d'accès aléatoire avec un identifiant destiné au s-BS. Le t-BS lit l'identifiant du s-BS, et transmet au s-BS le conteneur chiffré avec l'identifiant d'UE annexé. Le s-BS fait correspondre l'identifiant d'UE reçu avec l'identifiant établi, déchiffre le conteneur transparent reçu du t-BS avec le contexte de sécurité de l'UE, et, sur la base de la correspondance, envoie au t-BS un contexte pour l'UE. Le contexte de sécurité de l'UE est maintenu sécurisé et le FHO ne se poursuit que vers le t-BS sélectionné par l'UE.
PCT/IB2008/052352 2007-06-15 2008-06-13 Dispositif, procédé et progiciel produisant un conteneur transparent WO2008152611A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US93482107P 2007-06-15 2007-06-15
US60/934,821 2007-06-15

Publications (1)

Publication Number Publication Date
WO2008152611A1 true WO2008152611A1 (fr) 2008-12-18

Family

ID=39811751

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2008/052352 WO2008152611A1 (fr) 2007-06-15 2008-06-13 Dispositif, procédé et progiciel produisant un conteneur transparent

Country Status (1)

Country Link
WO (1) WO2008152611A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014099886A (ja) * 2009-08-10 2014-05-29 Nec Corp 通信装置においてネットワークセキュリティ鍵を作成する方法及び通信装置
US10091649B2 (en) 2015-07-12 2018-10-02 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
US10097995B2 (en) 2015-07-12 2018-10-09 Qualcomm Incorporated Network architecture and security with encrypted network reachability contexts
CN110583049A (zh) * 2017-05-03 2019-12-17 瑞典爱立信有限公司 Ran中的ue处理
WO2020248624A1 (fr) * 2019-06-13 2020-12-17 华为技术有限公司 Procédé de communication, dispositif de réseau, équipement utilisateur et dispositif de réseau d'accès

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708423A1 (fr) * 2005-03-29 2006-10-04 Matsushita Electric Industrial Co., Ltd. Transfert de contexte inter-domaines utilisant des gestionnaires de transfert de contexte
US20060233376A1 (en) * 2005-04-15 2006-10-19 Nokia Corporation Exchange of key material

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708423A1 (fr) * 2005-03-29 2006-10-04 Matsushita Electric Industrial Co., Ltd. Transfert de contexte inter-domaines utilisant des gestionnaires de transfert de contexte
US20060233376A1 (en) * 2005-04-15 2006-10-19 Nokia Corporation Exchange of key material

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
QUALCOMM EUROPE: "Cell Switching in LTE_Active State", 3GPP TSG-RAN WG2, 12 May 2006 (2006-05-12), MEETING #53, Shanghai, China, pages 1 - 5, XP002499600, Retrieved from the Internet <URL:http://www.quintillion.co.jp/3GPP/TSG_RAN/TSG_RAN2006/TSG_RAN_WG2_RL2_5.htm> *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014099886A (ja) * 2009-08-10 2014-05-29 Nec Corp 通信装置においてネットワークセキュリティ鍵を作成する方法及び通信装置
US10091649B2 (en) 2015-07-12 2018-10-02 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
US10097995B2 (en) 2015-07-12 2018-10-09 Qualcomm Incorporated Network architecture and security with encrypted network reachability contexts
US11172357B2 (en) 2015-07-12 2021-11-09 Qualcomm Incorporated Network architecture and security with encrypted client device contexts
CN110583049A (zh) * 2017-05-03 2019-12-17 瑞典爱立信有限公司 Ran中的ue处理
CN110583049B (zh) * 2017-05-03 2021-12-21 瑞典爱立信有限公司 Ran中的ue处理
US11523444B2 (en) 2017-05-03 2022-12-06 Telefonaktiebolaget Lm Ericsson (Publ) UE handling in RAN
WO2020248624A1 (fr) * 2019-06-13 2020-12-17 华为技术有限公司 Procédé de communication, dispositif de réseau, équipement utilisateur et dispositif de réseau d'accès

Similar Documents

Publication Publication Date Title
EP3449608B1 (fr) Sécurité de strate de non-accès améliorée
JP4820429B2 (ja) 新しい鍵を生成する方法および装置
US8627092B2 (en) Asymmetric cryptography for wireless systems
KR101270342B1 (ko) 키 요소의 교환
US8179860B2 (en) Systems and method for performing handovers, or key management while performing handovers in a wireless communication system
US20080039096A1 (en) Apparatus, method and computer program product providing secure distributed HO signaling for 3.9G with secure U-plane location update from source eNB
US20070224993A1 (en) Apparatus, method and computer program product providing unified reactive and proactive handovers
US20090209259A1 (en) System and method for performing handovers, or key management while performing handovers in a wireless communication system
Forsberg LTE key management analysis with session keys context
CN101841810B (zh) 空中接口密钥的更新方法、核心网节点及无线接入系统
KR20130114561A (ko) 무선 통신 장치에서의 로컬 보안 키 업데이트
CN101405987A (zh) 无线系统的非对称加密
CN101309503A (zh) 无线切换方法、基站及终端
WO2008152611A1 (fr) Dispositif, procédé et progiciel produisant un conteneur transparent
KR20100126691A (ko) 무선 통신 시스템에서 핸드오버들을 수행, 또는 핸드오버들을 수행하면서 키 관리를 수행하는 시스템 및 방법
CN101835151B (zh) 空中接口密钥的更新方法及无线接入系统
CN101902736B (zh) 空中接口密钥的更新方法、核心网节点及无线接入系统
JP6499315B2 (ja) 移動通信システム及び通信網

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08763339

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08763339

Country of ref document: EP

Kind code of ref document: A1