Method and apparatus for updating key in an active state

DESCRIPTION

METHOD FOR UPDATING THE KEY IN AN ACTIVE CASE AND

APPARAT

FIELD OF THE INVENTION

The present invention relates to the communication domain and more specifically to the method and apparatus for updating the key in an active state.

INFRASTRUCTURE

Work on the evolved access technology continues within the 3GPP organization to ensure the competitive advantage of 3GPP (3rd Generation Partnership Project) in the future. The packet technology used in the 3GPP system requires further development, especially to strengthen the capability of the 3GPP system to handle rapidly increasing IP data service. Some of the most important parts of this type of evolved technology include: reduced latency and reaction time, accelerated user data rate, increased system capacity and coverage, and reduced overall cost of operators. In addition, the evolved network structure is also an important indicator of the compatibility of the existing network with the previous ones. Here, in the security evolved network, the user security procedure is required to ensure that a security mechanism is provided that has at least the same level as the level of the current 2G and 3G system.

As shown in Figure 1, the core network of the wireless evolved network mainly includes logic functional units such as a Mobility Management Entity (MME), a Systems Architecture Evolution Gateway (SAE Gateway), and the like. MME, handling user content and mobility state, allocating temporary user identification, security function, etc. is responsible for managing the mobility of the control plane, including SAE Gateway, the paging of downlink data in an inertia state, the handling and storage of IP bearer content, and the network serving as a connection point for the user plane between different access systems, etc. is responsible for directing the information in it. In the wireless evolved network, the security of the user plane is terminated in the access network, where a Base Station (BS) of the access network is referred to as an evolved NodeB (eNB). The security of the signaling plane is divided into two parts terminating in the access network and the core network respectively, namely the Radio Resource Control (RRC) and Inaccessible Layer (NAS) signaling signaling the Access Layer. The key required to secure the signaling and data is variously derived from the keys, namely CK, IK generated during an Authentication and Key Agreement (AKA) procedure. The derivation relationships are shown as Figure.

Here KeNB-RRc-iNi is a security key for RRC signaling integrity, K_mostBrrc-enc is a security key for encryption of RRC signaling, and Knas-enc is a security key for encrypting NAS, and Knas-ini is a security key for NAS signaling integrity.₆nb-rrc-up is a security key for encrypting user plane data.

SHORT DESCRIPTION

A method and an apparatus for updating a key in an active state are provided in accordance with embodiments of the present invention to update the key in the active state.

A method for updating a key while a user equipment for this purpose is in an active state is provided in accordance with an embodiment of the present invention.

The invention is defined in the claims.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 shows a schematic of a wireless evolved network according to conventional technique;

Figure 2 shows a schematic of derivative relationships for keys according to classical technique;

Figure 3 shows a flowchart of a method for updating a key in an active state according to a first embodiment of the present invention;

Figure 4 shows a flowchart of updating a switch in an active state actively initiated by a UE according to a second embodiment of the present invention;

Figure 5 shows a flowchart of updating a switch in an active state actively initiated by an eNB on a network side according to a third embodiment of the present invention;

Figure 6 shows a flowchart of updating a switch in an active state actively initiated by an eNB on a network side according to a fifth embodiment of the present invention;

Figure 7 shows a flowchart of updating a switch in an active state actively initiated by an MME on a network side according to a sixth embodiment of the present invention;

Figure 8 shows a flowchart in which an eNB informs a UE of new switches via an air interface switch update procedure according to a seventh embodiment of the present invention;

Figure 9 shows a flowchart in which an eNB informs a UE of new switches via an air interface switch update procedure according to an eighth embodiment of the present invention; and

Figure 10 shows a schematic of a system for updating a key in an active state according to a ninth embodiment of the present invention.

DETAILED EXPLANATION

In practicing the present invention, it has been discovered that the above classical scheme suffers at least the following problem.

In the System Architecture Evolution (SAE) / Long Term Evolution (LTE) system, the relevant discussion covering methods of how the key can be instantly applied to an activation communication after the key discussion has already been proposed. All of the methods are recommended here considering that the key has already been updated to a new key, but there is no procedure on how to obtain the new key. It is therefore necessary to provide a method for addressing the issue of how to understand new keys in an active situation. In addition, the switch update in active state requires that the network side also has the capability to initiate switch negotiation. In the conventional technique, the network side will not actively initiate the key update procedure. Instead, only after the user switches from an inactive state to an active state and initiates an initial NAS message to the network side, for example an insert request, a paging request, a location update request, etc. can determine if it is not needed.

Detailed description will be made to the present invention in connection with the attached figures and arrangements.

One method of updating a key in an active state in the first embodiment of the present invention is that a user equipment (UE) can determine whether the key should be updated in the active state. The method for updating the key in the active state is as shown in Figure 3. The method includes the following steps.

Step (s301): In an active state, a user equipment or a network side can determine that a key update is needed based on a preconfiguration and initiate the key update.

The preconfiguration may include: (1) Finds that the User Plane (UP) or a COUNT to which the RRC is related has reached an upper threshold; (2) the user equipment has a transition between two eNBs, a handover within an eNB, or a handover between systems;

(3) user equipment or network side find that KASME has not been updated for a long time.

Step (s302): The network side performs the key update procedure.

Key update: Updating all keys through the AKA verification procedure; or updating derived keys of KASME instead of performing AKA to update Kashmere.

Step (s303): User equipment and network side can obtain the updated keys.

Step (s304): After the new keys are acquired, the user equipment and the network side can negotiate an activation time of the new keys.

The detailed description will be made to the present invention in connection with different application scenarios.

In the second embodiment of the present invention, a method for updating a key in an active state is as shown in Figure 4, where the UE can actively initiate the key update procedure in the active state. The method includes the following steps.

Step (s401): In the active state, when the UE finds that the key needs to be updated for some reason, the UE can actively initiate the key update procedure to the MME on the network side.

Possible reasons for updating the key could include the following: (1) COUNTs to which the UP or RRC is related reach the upper threshold; (2) UE has made a transition to a new eNB; (3) Kasme hasn't been updated for a long time. The UE can trigger the key update procedure by sending a TAU / RAU request or a special addition request or a special service request or a key update request message to the MME.

If the key update is triggered by sending a TAU / RAU message as a key update request, this TAU / RAU request can be sent separately even if no updates occur to the UE's location / routing zone, where the old routing zone identification, a new routing Identical to the region designation. In the TAU / RAU request to define the key update request, the Update type can be set as a custom value indicating that the key needs to be updated. The custom value can use a custom value that is not defined for different reasons, or it can use different values ​​for different reasons (an RRC / UP counter value flows or a transition has occurred, or the KASME's lifetime expires). Or the UE may not show a few existing values ​​but may use them (eg values ​​indicating the changed orientation / location field). In addition, the Update type is distinguished from this in that a periodic location record requires no key update. To distinguish it from the periodic location / routing record, it is better to use a value other than the value indicating "Periodic update", such as 000, for the Update type.

Notes: A few values ​​for the Update type in UMTS available are as shown in Table 1.

Table 1:

RA update combined RA / LA update

RA / LA update combined with IMSI plugin

Periodic update

Step (s402): After the MME receives the request that triggers the key update procedure (it could be one of the requests mentioned in step 401), the MME can perform the corresponding key update procedure according to the request type.

The AKA verification procedure can be initiated if the KASME needs to be updated, for example if a transition between systems is performed between GSM / UMTS and SAE / LTE, or if KASME expires.

New derived keys do not need to update KASME and only its derived keys need to be updated, for example if key update is required when a transition is performed in the LTE system or when an RRC / UP counter value reaches an upper threshold K_AIt can be calculated based on SME, in this case only Κ_θνβ or K_NAs-int and K_NAs-enc can be updated together.

Step (s403): The AKA procedure is performed to update the keys if the update of KASME is verified in step (s402). This step is optional.

Step (s404): Each key is updated according to the determination in step (s402). The corresponding key is calculated based on the existing Kasme key only if KASME's derived keys need to be updated.

Step (s405): MME sends new keys to eNB.

Step (s406): eNB and UE negotiate the activation time of new keys.

The eNb can report the activation time of new keys using one of the methods below or a method other than the one below.

(1) The eNB can inform the UE about the activation time of new keys by means of a simplified security mode command, and the UE can receive the reception of the security mode command. UE and network side, the new switches

Ί can activate the new key according to the activation time. If the NAS switches need to be updated, step s405 may also include initiating a NAS security mode command to negotiate the activation time of the new NAS switches.

(2) The eNB can initiate a switch-to-cell command requesting the UE to perform the transition from the eNB itself to an existing serving cell so that the UE can use the new keys.

(3) The eNB can add a KSI with each data packet to show which key the UE can use for decryption.

In addition to the above methods, it may also be referred to the following description described in step s801 in the seventh embodiment or step s901 in the eighth embodiment.

Step (s407): The network side sends a response message to the user to complete all the procedures for key update.

It should be noted that the activation time of new NAS keys can also be ported in this response.

In the third embodiment of the present invention, a method for updating a key in an active state is as shown in Figure 5, where the eNB on the network side can actively initiate the key update procedure in the active state.

The current arrangement refers to the key update procedure initiated by the eNB. When COUNTs for UP or RRC encryption / integrity security are about to reach an upper threshold (about to encapsulate), the relevant key may possibly need to be updated to prevent duplicate key stream. Or, if the COUNTs do not reach the upper threshold but the UE is in the LTE_ACTIVE state for a long time, the user plane security key, ie Kup-enc or KeNB, may possibly need to be updated. In the above two scenarios, Shrink and με do not need to be updated, only K_up and KRRc needs to be updated. Kasme can also be updated at this point.

In the third embodiment, the key update procedure is explained as follows.

Step (s501): When the eNB finds that it needs to be updated according to the above security requirement, the eNB can send a key update request message to the MME requesting the MME to generate a new KeNB. MME followed by K_AIt can derive a new KeNB from the sME.

The key update request message may possibly be the following: (1) a request message specifically to request the MME to update the key by the eNB, where the MME response is required in relation to this request message; (2) an acknowledgment type message informing the MME that the key needs to be updated, where no MME response is required in relation to this informative message.

Step (s502): MME, switch key (Κ_θνβ). Here Κ_θνβ can be derived from existing KASME by MME or calculated by MME after Kasme is updated through AKA procedure.

Step (s503): MME sends new KeNB to eNB. The MME can send the key to the eNB in ​​the following ways:

(1) by means of a key update request message corresponding to the key update request sent by the eNB according to step (s501);

(2) via a content modification message actively initiated by the MME, where the new key is sent to the eNB in ​​the modification message;

(3) Via a security content modification message actively initiated by the MME, where the new key is sent to the eNB in ​​the modification message.

In addition to the new KeNB, MME also has a K_mostIt should be noted that it may need to send other parameters needed to calculate B. For example, when the MME computes the new key using the existing Kasme, a variable parameter (eg a counter, a random number) may possibly need to be applied. Therefore, this variable parameter may also need to be sent to the eNB and then sent to the UE via the eNB so that the UE can calculate the new KeNB using the same parameters.

eNB, this new K_mostNew Kup and K depending on B_RRCan derive c. C - RNTI or a random number can be used as an input parameter during the derivation procedure. If the C RNTI is used, the original C - RNTI could possibly be used, or a C RNTI parameter could possibly be newly created for the UE.

Step (s504): An air interface new key initiation procedure is provided, ie a method of how to negotiate an activation time of new keys. Packet Data Convergence Protocol (PDCP) SN or KSI or UE is forced to perform an activator-active state conversion or an inter-cell transition, in addition to the methods described in the previous description, in step s801 and step s802 or eighth in the seventh embodiment. In the embodiment, reference may also be made to the following description described in step s901 and step s902.

If the MME sends the KeNB in ​​the figure (2) in step (s503), the eNB may possibly need to send the (security) side message of the content modification after the activation of the new key.

In the fourth embodiment of the present invention, a method for updating a key in an active state is as shown in Figure 5, where the eNB on the network side can actively initiate the key update procedure in the active state.

The current arrangement refers to the key update procedure initiated by the eNB. When COUNTs for UP or RRC encryption / integrity security are about to reach an upper threshold (about to encapsulate), the relevant key may possibly need to be updated to prevent duplicate key stream. Or, even if the COUNTs do not reach the upper threshold but the UE is in the LTE_ACTIVE state for a long time, the user plane security key, ie Kup-enc or KeNB, may need to be updated. In the above two scenarios, Kasme and K_MME does not need to be updated, only K_up and KRRc needs to be updated.

The difference between the third arrangement and the current arrangement, Κ_θνβ is that KeNB is not updated in the current issue while it is updated in the third issue. In the fourth embodiment, the key update procedure is explained as follows.

(1) When the eNB finds that the key needs to be updated (when the eNB finds that the key needs to be updated according to the security requirement mentioned above), the eNB can generate a random number or a new C - RNTI, and then Κ_θIt can create a new RRC / UP key using νβ and other parameters .

(2) The eNB can inform the UE about the new key parameters via the air interface key update procedure. The air interface switch update procedure used herein may refer to the description of the regulations below.

In the fifth embodiment of the present invention, a method for updating a key in an active state is as shown in Figure 6, where the eNB on the network side can actively initiate the key update procedure in the active state. The method includes the following steps.

Step (s601): In a non-handover scenario, if the network side like eNB wants to update the key, a switch between cells command is sent to the UE, in other words, the UE is requested to switch to the source cell (the target cell is identical to the source cell) .

Step (s602): The UE can access the eNB cell again upon receipt of the switch command.

The description in step s603 to step s609 in the following procedure may refer to step s401 to step s407 in the second embodiment omitted here for attribute.

A method for updating a key in an active state in the sixth embodiment of the present invention is as shown in Figure 7, where the MME on the network side can actively initiate the key update procedure in the active state. The method includes the following steps.

Step (s701): MME, K on network side_AThe MME can then determine to actively initiate the AKA procedure after the KAsME needs to be updated when it finds that the sME has been used for a long time or that a transition between RATs is performed by the UE and so on. The network side must determine a valid time for each Kasme'yc so that a corresponding procedure is triggered suddenly when the current time reaches the upper threshold.

Step (s702): The MME actively initiates a paging message specific to the UE. This step is optional.

A pagination reason for the custom paging request can be NULL or a special value indicating the key update.

Step (s703): The UE sends a paging response to the network upon receipt of the paging message.

Steps (s702 and s703) are optional.

Step (s704): When the MME sends a verification request message to the UE to initiate the AKA to perform, or upon receiving the paging response similar to the conventional technique of receiving the paging message, the MME can determine to perform the AKA and therefore initiate the AKA procedure to the UE.

Step (s705): MME creates each derived key.

Step (s706): MME to eNB_toNB^!Sends you. Κ_θSpecifically, νβ may be such that in the NAS message the KeNe will be moved and the UE will be notified about the activation time of the optional new NAS switches.

The MME can send the new key to the eNB in ​​the following ways:

(1) use of a content modification message actively sent to the eNB; The content modification message may use a particular S1 initial content setting message or a newly identified S1 interface signaling. The content modification message contains the new key.

(2) The use of a security content modification message actively sent to the eNB. The security content modification message contains the new key.

Other similar messages can also be used for sending.

Step (s707): eNB and UE negotiate the activation time of new keys. Optionally, the activation time of NAS switches can also be negotiated during this procedure.

Step (s708): The user communicates with the network side using the new keys.

Regarding the newly created key, the eNB needs to inform the UE about the initialization of new keys via the air interface key update procedure. During the key update procedure, the main purpose of the key update procedure to the air product is: (1) to send the UE parameters related to the derived keys, for example a new C - RNTI or a random number; (2) informing the UE about the activation time of the keys.

In the seventh embodiment of the present invention, the disclosure is made via the Security Mode Command (SMC) procedure as an example, where the eNB informs the UE about the initialization of new keys via the air interface key update procedure. With reference to Figure 8, the following steps are included.

Step (s801): The eNB determines that a special SMC message should be sent to the UE, depending on the triggering reasons.

The SMC message may include one or more of the following parameters: (1) parameters required to derive the key, such as a new C - RNTI, a random number, and the like; (2) a downlink activation time of the NAS switches; (3) a downlink activation time of RRC keys; (4) an uplink and a downlink activation time of user plane switches; (5) other possible parameters, for example, an activation time of new keys for determining uplink data packets (including data packets of the user plane and the control plane).

In addition, when a downlink message is sent by the eNB, the eNB can: (1) stop sending the downlink data so that the downlink activation time can start from the next data packet; (2) can continue to send data packets, but the PDCP SN for activating the use of new keys can be set slightly larger in order to avoid a key activation error due to the rapid sending of packets.

In addition to the SMC message, a new command such as the newly defined security content modification command / security reconfiguration command can also be used to request the UE to switch the key in use according to the parameters carried in the command or for a period of time.

Step (s802): The UE returns a corresponding message to eNB upon receipt of the corresponding message.

Specifically, upon receipt of the SMC message, the UE can derive new keys depending on the relevant parameters. Optionally, an activation time of uplink data packets (including user plane and control plane data packets) may also be required. The UE can then return the corresponding message to the eNB. A PDCP SN for initializing new keys is carried in the corresponding message. The UE can stop sending data packets but can calculate new keys and get the activation time of the new keys, and then send the new activation time to the eNB. At this point, the activation time of switches for uplink data packets needs to be adjusted slightly backward if this method is adopted.

Step (s803): Air interfaces can communicate under the protection of new switches.

In the eighth embodiment of the present invention, the disclosure is made via an intercellular handover procedure as an example, where the eNB informs the UE about the activation of new keys via the air interface key update procedure. Referring to Figure 9, the following steps are included.

Step (s901): eNB determines whether an HO Command message should be sent to the UE, depending on the triggering reasons.

In normal cases, the HO Command message can be sent to the UE to notify the UE to switch to another Cell, so that the HO Command message can carry air resources, C-RNTI, etc., allocated by another Cell. In the embodiment, however, the HO Command message is merely about informing the UE to activate the updated keys, rather than notifying the UE to perform the switch to other Cells. Therefore, some conversions on parameters may be required: (1) in the original HO Command message the transparent container for the Target eNB to UE must be removed; (2) In the original message allocated to the UE by the "target eNB cell", the C-RNTI is modified as a new CRNTI allocated by the "source eNB cell" itself; (3) an activation time of possibly needed NAS keys should be added; (4) a downlink activation time of RRC keys is added; (5) add a downlink activation time of the user plane switches; (6) therefore the values ​​are added by informing the UE that the current HO Command message should inform the UE to update the key rather than performing an actual switch.

Also according to the general requirements of the HO Command, the eNB will send any data packet after the HO Command message is sent.

Step (s902): HO After the command message has been received by the UE, the UE can: (1) determine based on the values ​​of the reason that the current transition is for key update only, and therefore there is no need to synchronize with the new cell; (2) stop sending uplink data packets; (3) derive new keys; (4) determine an activation time of uplink data packets; (5) can send a message to eNB by informing the eNB about the activation time of uplink packets.

Step (s903): UE and eNB can communicate with each other under protection of new keys.

With the methods provided in accordance with embodiments of the present invention, the user equipment and the network side in active state can actively initiate the key update procedure in different situations, thus solving the problem of key update for a session in an active state. In addition, the application procedure is simple and easy to carry out.

In the ninth embodiment of the present invention, a system for updating a key in an active state is further described. Referring to Figure 10, the system includes at least one user equipment 10 and a network side entity 20, where in active state the user equipment and the network side entity can initiate the key update and update the key when a predefined situation is encountered.

Specifically, the user equipment (10) also:

a terminal key update detection unit (11) configured to determine, based on a predetermined situation, whether the key update should be initiated;

a terminal key update initiation unit (12) configured to send a key update request message to the network-side entity (20) when the terminal switch update detection unit (11) determines whether the key needs to be updated; and a terminal key update adjustment unit (13) configured to predict the state to initiate the key update and provide the status to the terminal switch update detection unit (11).

Specifically, the network side entity (20) specifically:

a key update detection unit (21) configured to determine, based on a predetermined situation, whether the key update should be initiated;

a key update initiation unit (22) configured to send a request message to the user equipment (10) for notifying the key update when the key update detection unit (21) determines whether the key needs to be updated;

a key update unit (23) configured to update the key when the user equipment (10) or network-side entity (20) initiates the key update;

a key update setting unit (24) configured to predict the state for initiating the key update and provide the status to the key update detection unit (21); and a key initiation negotiation unit (25) configured to negotiate an activation time of new keys with the user equipment.

Here, the functions of the above-mentioned units can be performed on the network side via MME and eNB.

With systems and apparatus provided in accordance with embodiments of the present invention, the user equipment and the network side in active state can actively initiate the key update procedure in different situations, thereby solving the problem of key update for a session in an active state. In addition, the application procedure is simple and easy to carry out.

Compared with the conventional technique, embodiments of the present invention benefit from the following advantages: In active state, the user equipment and the network side can actively initiate the key update procedure in different situations, thus solving the problem of key update for a session in an active state.

With the explanation of the above embodiments, those skilled in the art will easily understand that the present invention can be implemented with hardware 5 and also can be implemented with software on an important hardware platform. Based on this understanding, the solutions provided by the present invention can be organized into a software product. The software product can be stored in a non-volatile storage medium (can be a CD-ROM, a USB flash disk, a mobile hard disk, etc.). The software product may include a set of instructions that allow a computing device (may be a personal computer, a server 10, or a network device, etc.) to perform methods according to various embodiments of the present invention. Additionally, the above embodiments take the SAE / LTE system as an example. The eNB described in the above embodiments refers to a Base Station (BS) of the SAE / LTE system. It is easily understood by those skilled in the art that the BS is not limited to the eNB. Any Base that performs the same function as the above eNB

Station is within the scope of protection of the present invention.