WO2012031510A1

WO2012031510A1 - Method and system for implementing synchronous binding of security key

Info

Publication number: WO2012031510A1
Application number: PCT/CN2011/077617
Authority: WO
Inventors: 和峰; 冯成燕
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-09-10
Filing date: 2011-07-26
Publication date: 2012-03-15
Also published as: CN101945386A; CN101945386B

Abstract

Disclosed are a method and a system for implementing synchronous binding of a security key, the method comprising: an MME notifying an RN of performing security key binding; after receiving the notification, the RN performing the same security key binding processing as that on a network side so as to obtain a security key bound to a device, and responding to the MME. Based on the solution of the present invention, the security key bound to the device and obtained through the security key binding processing, or other keys derived by using the security key bound to the device protect the security of communication data between the RN and the network side. Moreover, through the security key bound to the device, the binding of RN subscriber authentication to the device is implemented, and it is guaranteed that the RN currently communicating with the network side is definitely a legal RN having a legal USIM card. Therefore, illegal attackers cannot crack the communication data.

Description

Method and system for realizing security key synchronization binding

The present invention relates to a security authentication technology in a Long Term Evolution (LTE) network, and more particularly to a method and system for implementing security key synchronization binding. Background technique

FIG. 1 is a schematic structural diagram of an LTE network. As shown in FIG. 1 , an LTE network consists of an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) and an Evolved Packet Core (EPC). Composition, the network is flat. The E-UTRAN is connected to the EPC via the SI interface.

The E-UTRAN is composed of a plurality of interconnected evolved base stations (eNBs, Evolved NodeBs), and each eNB is connected through an X2 interface; the EPC is composed of a mobility management entity (MME, Mobility Management Entity) and a monthly service gateway (S). -GW, Serving Gateway). In addition, in the LTE network architecture, there is also a Home Environment (HE), such as a Home Subscriber Server (HSS) or a Home Location Register (HLR), as a user database. The HE contains user profiles, performs user authentication and authorization, and provides information about the user's physical location.

In order to meet the growing demand for large-bandwidth, high-speed mobile access, the Third Generation Partnership Projects (3GPP, Third Generation Partnership Projects) introduced the LTE-Advanced (Long-Term Evolution advance) standard. LTE-Advanced retains the core of LTE for the evolution of LTE networks. Based on this, a series of technologies are used to expand the frequency domain and airspace to improve spectrum utilization and increase system capacity. Wireless relay technology is one of the technologies in LTE-Advanced. It aims to extend the coverage of the cell, reduce the dead zone in communication, balance the load, transfer the traffic in the hotspot, and save users. The device (UE, User Equipment) is the transmit power of the terminal. FIG. 2 is a schematic diagram of a network structure after adding a relay node (RN, Relay-Node) in the existing network architecture. As shown in FIG. 2, the wireless device between the newly added RN and the donor evolved base station (Donor-eNB) is used. connection. The interface between the Donor-eNB and the RN is called the Un port. The radio link between the two is called the backhaul link. The interface between the RN and the UE is called the Uu port. The wireless link between them is called the Uu port. The road is called an access link. The downlink data arrives at the Donor-eNB first, and then is transmitted to the RN, and the RN transmits the signal to the UE. The uplink data first arrives at the UE, and then is transmitted to the RN, and the RN transmits the signal to the Donor-eNB.

In the actual communication process, the RN can be used as either a normal terminal device or a base station. When the RN is used as a terminal device, the RN can access the wireless network like a normal UE.

When a normal UE accesses the network, the network side authenticates the user and authenticates the Key Agreement (AKA). In the LTE network, the process is also called the Evolved Packet System Key Agreement (EPS AKA). Evolved Packet System AKA ) „ In the above description, the UE refers to the general name of the mobile device (Mobile Equipment) and the Universal Subscriber Identity Module (USIM). The EPS AKA process is actually completed by the USIM. Therefore, the process completes the network-to-terminal USIM authentication (or subscription authentication) and key agreement, and the subsequent description also refers to the USIM authentication as user authentication. It should be noted that the USIM card here represents a generalized Universal Integrated Circuit Card (UICC)

Through user authentication, the UE and the network side generate an integrity key (IK, Integrity Key) and an encryption key (CK, Cipher Key) according to the root key K, and the MME generates an intermediate key KASME according to IK and CK. Then use this intermediate key KASME to derive other new keys to protect the communication data of the access layer (AS, Access Stratum) and non-access stratum (NAS, Non-Access Stratum). Among them, the access layer security protection key (ratio For example, the radio resource control encryption key KRRCenc, the radio resource control integrity protection key KRRCint and the user plane encryption key KUPenc are respectively derived from the base station key KeNB according to different algorithms, and the KeNB is derived from the intermediate key KASME. .

Similar to the UE, when the RN is an ordinary terminal device, it is a general term for a relay node device (or RN platform) and a USIM card (or a UICC card). The RN can complete the USIM authentication of the RN according to the EPS AKA process described above. .

However, when the RN acts as a base station, if the base station is an illegal device, it may threaten the user equipment it serves. Therefore, it is first necessary to ensure the legitimacy of the base station before the base station serves the UE. At present, the specific implementation scheme for realizing the legality certification of the RN is not determined.

However, even for an RN that completes user authentication and device legality authentication, the following security threats exist. Figure 3 is a schematic diagram of a process in which a possible RN is illegally attacked, as shown in Figure 3. The attacker (Attacker) inserts the legal USIM card into the illegal RN and inserts the illegal USIM card into the legal RN. In this case, the attacker uses the legal USIM and the legal RN to complete the corresponding user authentication. And equipment certification. In the actual communication process, the illegal RN can obtain the access layer security protection key generated by the legal USIM card authentication, and the partial communication data between the illegal RN and the network side is protected by the access layer security protection key. It is possible for the illegal RN to tamper with or eavesdrop on the communication content between the RN and the DeNB. Therefore, the existing RN authentication does not guarantee that the legal USIM card is inserted on the legal RN device, that is, the user authentication of the RN and the binding of the device cannot be implemented, so that the communication data between the RN and the network side cannot be secured. . Summary of the invention

In view of this, the main purpose of the present invention is to provide a method and system for implementing secure key synchronization binding, which can implement RN user authentication and device binding, and ensure communication data security between the RN and the network side.

In order to solve the above technical problem, the technical solution of the present invention is implemented as follows: A method for implementing secure key synchronization binding includes:

The mobility management entity MME notifies the relay node RN to perform security key binding;

After receiving the notification, the RN performs the same security key binding process as the network side, obtains the security key bound to the device, and responds to the MME.

The MME notifying the RN to perform security key binding includes: the MME sending a non-access stratum NAS message to the RN, and notifying the RN to perform security key binding.

The NAS message carries key binding indication information for instructing the RN to perform binding of the security key.

The NAS message also carries algorithm identification information for identifying an algorithm used when performing key binding.

The NAS message also carries identification information of a security key to be bound.

The NAS message also carries identification information about security parameters related to devices that need to be bound.

The NAS message multiplexes an existing NAS message; the existing NAS message includes: a NAS security mode command message, or a user authentication request message;

Alternatively, the NAS message is a new message, and the new message is a key binding request message. The same security key binding process performed by the RN as the network side is performed in the MME or the home subscriber server HSS or the home location register HLR or the home environment HE on the network side.

The security key binding process performed by the network side is before the MME sends a NAS message to notify the RN; or after the MME receives the response from the RN.

The method further includes: obtaining, by the network side, the user security key of the RN through the user authentication process, and obtaining the device-related security parameter of the RN;

The security key binding process includes: deriving a security key bound to the device according to the agreed algorithm by using the device-related security parameter and the user security key.

The security key derived from the device according to the agreed algorithm further includes: The device-related security parameters, the user security key, and other parameters are used to derive a security key bound to the device according to the agreed algorithm.

The other parameters include the parameters shared by the RN and the network side; or the random number generated by the network side or the RN. At this time, the method further includes: the random number generated by the network side or the RN by using a message. Notify the RN or the network side.

The user security key may be an intermediate key KASME or an encryption key CK, a integrity key IK.

The device-related security parameter is a specific parameter shared by the RN and the network side; the specific parameter is: a parameter in the subscription information of the RN; or a preset parameter in the device certificate.

The device-related security parameter is: a device-related security parameter that is agreed in the device authentication process on the network side; the device-related security parameter that is agreed in the device authentication process is a root key in the device subscription information, or Other new keys derived from the root key.

The sending of the response by the RN to the 包括 includes:

The RN feeds back the binding result to the 通过 through the existing NAS message or by using a new message.

The key binding success indication information is used to indicate that the RN successfully completes the security key binding; or the key binding failure is used to indicate that the RN fails to complete the security key binding successfully. Instructions.

When the response message fed back by the RN carries the key binding failure indication information, the response message fed back by the RN further carries the failure reason.

A system for implementing secure key synchronization binding, including at least RN and ΜΜΕ, wherein

ΜΜΕ, used to send a security key binding notification to the RN;

The RN is configured to receive the security key binding notification from the ,, perform the same security key binding processing as the network side, obtain the security key bound to the device, and respond to ΜΜΕ. The MME is specifically configured to: after the RN passes the user authentication, send a security key binding notification to the RN; before sending the security key binding notification to the RN, or after receiving the response from the RN, performing the same as the RN Secure key binding processing to obtain a security key bound to the device.

The system also includes an HSS or HLR or HE, which is used to perform the same security key binding process as the RN, and sends the security key bound to the device obtained by the security key binding process to the MME.

The network side is further configured to obtain a user security key of the RN through a user authentication process, and obtain device-related security parameters of the RN.

It can be seen from the technical solution provided by the present invention that the MME notifies the RN to perform security key binding after the RN passes the user authentication; and after receiving the notification, the RN performs the same security key binding processing as the network side. Obtain a security key bound to the device and respond to the MME. Based on the solution of the present invention, the security key bound to the device obtained by the security key binding process or the other key derived from the security key bound to the device protects the communication between the RN and the network side. Data Security. Moreover, the RN user authentication and the device binding are implemented by the security key bound to the device, and the RN that communicates with the network side at this time is surely a legal RN with a legal USIM card, thus, an illegal attacker It is impossible to crack communication data. DRAWINGS

FIG. 1 is a schematic structural diagram of an LTE network;

2 is a schematic diagram of a network composition after adding an RN in an existing network architecture;

Figure 3 is a schematic diagram of a possible process in which an RN is illegally attacked;

4 is a schematic flowchart of a method for implementing security key synchronization binding according to the present invention;

FIG. 5 is a schematic structural diagram of a system for implementing security key synchronization binding according to the present invention; FIG. 6 is a schematic flowchart of a first embodiment of implementing security key synchronization binding according to the present invention; FIG. 7 is a schematic diagram of implementing security key synchronization according to the present invention. A schematic flowchart of a second embodiment of the binding; FIG. 8 is a schematic flowchart of a third embodiment of implementing security key synchronization binding according to the present invention; FIG. 9 is a schematic flowchart of a fourth embodiment of implementing security key synchronization binding according to the present invention; FIG. 10 is a schematic flowchart of a fifth embodiment of implementing security key synchronization binding according to the present invention. detailed description

FIG. 4 is a schematic flowchart of a method for implementing security key synchronization binding according to the present invention, which includes the following steps:

Step 400: The MME notifies the RN to perform security key binding.

In this step, the MME may send a NAS message to the RN to notify the RN to perform security key binding. The NAS message may be used to re-use an existing NAS message, such as a NAS security mode command (NAS SMC, NAS Security Mode Command) message, or a user authentication request (User Authentication Request) message; the NAS message may also be a new message. For example, a key binding request message that is specifically designed to notify the RN to perform security key binding.

If the RN and the network side agree that the security key binding process must be performed after the NAS message for informing the RN to perform the security key binding, the NAS message in this step may not carry any information, that is, a notification. The indication, that is, the RN and the network side perform the operation of secure key binding after the RN passes the user authentication in an implicit manner.

If the RN and the network side do not agree, the NAS message sent by the MME to the RN may carry the key binding indication information and/or the algorithm identification information used when the key is bound, such as an algorithm identifier. Used to instruct the RN to perform binding of the security key;

Further, the NAS message may further carry identification information of a security key to be bound, such as an E-UTRAN key set identifier (eKSI, Key Set Identity in E-UTRAN);

Further, the NAS message may further carry identification information of a security parameter related to the device to be bound.

In addition, before the step, the network side obtains the user security key of the RN through the user authentication process, or obtains the device-related security parameter of the RN by performing authentication on the device or according to the device identifier index. Step 401: After receiving the notification, the RN performs the same security key binding process as the network side, obtains a security key bound to the device, and responds to the MME.

In this step, the security key binding process includes: deriving a security key bound to the device according to the agreed algorithm by using the device-related security parameter and the user security key. The security key bound to the device, or other key derived from the security key bound to the device, protects the communication data between the RN and the network side. Moreover, the RN user authentication and the device binding are implemented by the security key bound to the device, and the RN that communicates with the network side at this time is surely a legal RN with a legal USIM card, thus, an illegal attacker It is impossible to crack communication data.

Further, in the process of deriving the security key bound to the device according to the agreed algorithm, other parameters, such as parameters shared by the RN and the network side, or random numbers generated by the network side (or RN) may be used. The message notifies the peer RN (or the network side) of the random number.

The device-related security parameter is a specific parameter shared by the RN and the network side, for example, it may be a parameter in the subscription information of the RN (such as a device root key), or may be a pre-request in a device certificate (Device Certificate). Set parameters and so on. Further, the device-related security parameter may also be: a device-related security parameter that is agreed in the device authentication process on the network side, such as a root key in the device subscription information, or other new key derived from the root key. Wait.

The user security key refers to the security key associated with the user's subscription information, such as the intermediate key KASME agreed in the user authentication process, or the CK, IK, etc. derived from the user root key.

The convention algorithm in this step may be a known key derivation function (KDF, Key Derivation Function), or other one-way function. The specific implementation of the algorithm belongs to the technical means used by those skilled in the art, and details are not described herein. .

In addition, in this step, the security key binding process performed by the RN on the network side is also performed on the network side, for example, in the MME, and the security key binding process may occur before the MME sends the NAS message to notify the RN. It can also happen after the MME receives a response from the RN. Alternatively, the security key binding process performed by the network side may also be performed by the HE or the HSS or the HLR. Afterwards, the HE or the HSS or the HLR sends the security key bound to the device obtained by the security key binding process to the MME.

In this step, the RN feeds back the binding result through the response message, including:

The RN passes an existing NAS message, such as a NAS Security Mode Complete message, or a User Authentication Response message, or a new key, such as a key for feedback binding. Bind the response message and feed back the binding result to the MME.

The key binding success indication information used to indicate that the RN successfully completes the security key binding may be carried in the response message fed back by the RN; or the key binding failure indication used to indicate that the RN does not successfully complete the security key binding. Information, at this time, optionally, may also carry the reason for the failure.

Based on the method of the present invention, the security key bound to the device obtained by the security key binding process or the other key derived from the security key bound to the device protects the communication between the RN and the network side. Data Security. Moreover, the RN user authentication and the device binding are implemented by the security key bound to the device, and the RN that communicates with the network side at this time is surely a legal RN with a legal USIM card, thus, an illegal attacker It is impossible to crack communication data. The network side can be MME, or HSS, or HLR, or HE.

FIG. 5 is a schematic structural diagram of a system for implementing security key synchronization binding according to the present invention. As shown in FIG. 5, at least an RN and an MME are included, where

The MME is configured to send a security key binding notification to the RN.

The RN is configured to receive the security key binding notification from the MME, perform the same security key binding process as the network side, obtain a security key bound to the device, and respond to the MME.

The MME is specifically configured to send a security key binding notification to the RN. Before sending the security key binding notification to the RN, or after receiving the response from the RN, perform the same security key binding processing as the RN to obtain The security key that is bound to the device.

The system of the present invention also includes an HSS or HLR or HE for key binding in place of the MME. The initiation and security key binding processing, and the security key bound to the device obtained by the security key binding processing is sent to the MME.

The network side is further configured to obtain a user security key of the RN by using a user authentication process, or obtain a device-related security parameter of the RN by performing authentication on the device or according to a device identifier index. FIG. 6 is a schematic flowchart of a first embodiment of implementing security key synchronization binding according to the present invention. In the first embodiment, the MME does not use the NAS SMC message to notify the RN to perform security key binding, and the NAS SMC message carries Instructions. The MME and the RN respectively use the device-related security parameters and the user intermediate key KASME to derive the security key bound to the device. After the RN succeeds, the MME is fed back through the response message. As shown in FIG. 6, the following steps are specifically included:

Step 600: The user authentication between the MME and the RN is completed through a User Authentication Procedure, and the intermediate key KASME is obtained. The implementation of this step belongs to the prior art and will not be described here.

Step 601: The MME obtains device-related security parameters, such as a shared key K-D, according to the device identification information of the RN, such as an International Mobile Equipment Identity (IMEI) index of the device, where the shared key K-D may exist. The pre-configured key in the RN device subscription information may also be information generated by a specific process, and the specific implementation is well-known to those skilled in the art, and is not intended to limit the scope of the present invention.

Step 602: The MME performs a key binding process: the MME uses the intermediate key KASME and device-related security parameters such as the shared key K-D to derive a security key KASME D bound to the device according to the agreed key derivation algorithm. For example, KASME D = KDF (KASME, KD), the specific implementation is a common technical means for those skilled in the art, and is not described here, and the specific implementation method is not used to limit the scope of the present invention.

Step 603: The MME initiates a NAS SMC message to the RN, and carries the message in the NAS SMC message. With key binding indication information.

Step 604: The RN derives the security key KASME-D bound to the device by using the same calculation method as the MME according to the key binding indication.

It should be noted that, in the process of deriving the security key KASME-D bound to the device, other parameters may also be introduced, for example, parameters that may be shared by the RN and the MME; or, random numbers generated by the MME (or RN) At this point, the random number needs to be notified to the peer through the message.

Step 605: The RN sends a NAS security mode complete message to the MME, and the MME successfully completes the synchronization binding of the security key after successfully receiving the NAS security mode complete message.

The subsequent RN and the network side can use the key derived from the security key KASME-D bound to the device to protect the communication data between the RN and the network side. Specifically, KASME-D can be used instead of the ordinary intermediate key KASME to derive other security keys respectively. The specific derivation method is consistent with the existing security key derivation method.

In the first embodiment, the timing at which the MME derives the security key bound to the device may also be performed after step 605.

FIG. 7 is a schematic flowchart of a second embodiment of implementing security key synchronization binding in the present invention. In the second embodiment, the MME does not use the NAS SMC message to notify the RN to perform security key binding, and the NAS SMC message carries The indication information, and the security key identification information that requires security binding and/or the algorithm identification information used by the key binding. The MME and the RN respectively derive the security key bound to the device by using the device-related security parameters and the security key specified in the NAS SMC message to identify the corresponding security key. In this embodiment, the device security parameter is a security parameter that is agreed by the device authentication process. After the RN succeeds, the MME feeds back the MME through the response message, and the response message carries a binding success flag. As shown in Figure 7, the following steps are specifically included:

Step 700: The user authentication between the MME and the RN is completed through the EPS AKA process, and the intermediate key KASME is obtained. The implementation of this step belongs to the prior art, and details are not described herein again.

Step 701: The MME performs device authentication with the RN, and the two parties agree on one in the device authentication process. A shared security parameter K-relay.

Step 702: The MME uses the intermediate key KASME, device-related security parameters (such as K-relay), and other parameters (such as the random number RAND-M generated by the MME) to derive the binding with the device according to the agreed key derivation algorithm. The security key KASME-D, such as KASME-D = KDF (KASME, K relay, RAND M), the specific implementation belongs to the technical means of those skilled in the art, and details are not described herein, and the specific implementation method is not used to limit the present invention. The scope of protection. Where RAND—Μ is an optional parameter.

Step 703: The MME initiates a NAS SMC message to the RN, where the NAS SMC message carries the key binding indication information and/or the algorithm identification information used by the key binding, and the random number RAND_M required for the key derivation. And key identification information (eKSI) of the intermediate key KASME to be bound.

Step 704: The RN derives the security key KASME-D bound to the device by using the same calculation method as the MME according to the eKSI index to the corresponding intermediate key KASME.

Step 705: The RN sends a NAS security mode complete message to the MME, where the NAS security mode completion message carries a security key binding success flag. After the MME successfully receives the NAS security mode completion message, it completes the synchronization binding of the security key.

The subsequent RN and the network side can use the key derived from the security key KASME-D bound to the device to protect the communication data between the RN and the network side.

In the second embodiment, the timing at which the MME derives the security key bound to the device may also be performed after step 705.

FIG. 8 is a schematic flowchart of a third embodiment of implementing security key synchronization binding in the present invention. In the third embodiment, it is assumed that the HSS completes the security key binding processing on the network side, and then initiates a user authentication request to the RN through the MME. The message carries the key binding indication information in the user authentication request message, and the RN uses the device-related security parameter (such as the root key in the device subscription information, or the key information derived from the root key, or the number of the device) Signature, etc.) and the key CK to be bound, The IK derived binding security key KASME-D. The device-related security parameter is a specific parameter related to the operator certificate of the device. After the RN performs the security key binding process successfully, the RN feeds back to the MME through the user authentication response message. As shown in FIG. 8, the following steps are specifically included:

Step 800: The HSS acquires identification information of the device, such as IMEI. This step is implemented by a person skilled in the art and is not related to the scope of protection of the present invention, and will not be described in detail herein.

Step 801: The HSS derives a new security key KASME bound to the device according to the protocol-derived algorithm according to the unique parameter related to the operator certificate of the device corresponding to the IMEI (such as Ksec) and the key CK and IK to be bound. D. Where KASME-D = KDF(CK, IK, Ksec), the specific implementation is a common technical means for those skilled in the art, and details are not described herein, and the specific implementation method is not used to limit the scope of the present invention. The keys CK, IK are derived from the root key K in the RN user subscription data according to an agreed algorithm, which is known information. Optionally, other parameters may be introduced in the foregoing calculation process, such as a service network identifier (SN id ) on the network side, or a sequence number (SQN), or an Anonymity Key (AK). Or a random value generated by the network side, or any combination of the above parameters.

Step 802: The HSS sends the generated security key KASME_D bound to the device to the MME in the authentication data response message. Optionally, the password binding indication information may also be carried in the authentication data response message.

Step 803: The MME sends a User Authentication Request message to the RN, where the user authentication request message carries the key binding indication information.

Step 804: After receiving the user authentication request message, the RN derives CK and IK according to the root key K, and then performs a security key binding process according to the indication message to obtain a security key KASME-D bound to the device, and calculates The method is completely consistent with the calculation method of HSS in step 801.

In this step, if the RN is in the process of deriving the KASME-D, the MME sends a user authentication response message carrying the binding failure flag to the MME. Optionally, the RN may also carry the corresponding failure reason. For example, key binding is not supported. Step 805: The RN sends a User Authentication Response message to the MME. Optionally, the binding success flag is carried in the user authentication response. After the MME successfully receives the user authentication response message, it completes the synchronization binding of the security key.

FIG. 9 is a schematic flowchart of a fourth embodiment of implementing security key synchronization binding in the present invention. In the fourth embodiment, it is assumed that the MME uses the newly added message to notify the RN to perform security key binding, and the new message carries the security binding. The security key identification information and the identification information related to the device security parameters to be bound, the MME and the RN respectively derive the security key bound to the device by using the device-related security parameter and the security key specified in the message. In this embodiment, the device-related security parameter is the device security key K-D agreed by the device authentication process, and the RN successfully feeds back to the MME through the response message. As shown in Figure 9, the following steps are specifically included:

Step 900: The user authentication between the MME and the RN is completed through a User Authentication Procedure, and the intermediate key KASME is obtained. The implementation of this step belongs to the prior art and will not be described here.

Step 901: The MME performs device authentication with the RN, and the two parties agree on a shared security parameter K-D in the device authentication process.

Step 902: The MME uses the intermediate key KASME, device-related security parameters (such as KD), and other parameters (such as the random number RAND-M generated by the MME) to derive the security bound to the device according to the agreed key derivation algorithm. The key KASME-D, such as KASME-D = KDF (KASME, KD, RAND M), the specific implementation belongs to the technical means of those skilled in the art, and is not described here again, and the specific implementation method is not used to limit the protection of the present invention. range.

Step 903: The security key binding command message is sent to the RN, where the security key binding command message carries the random number RAND_Μ, the key identification information (eKSI) of the intermediate key KASME to be bound, and Identification parameter corresponding to the device security parameter KD to be bound (eKSI D). The eKSI and eKSI-D can respectively determine the security key and security parameters of the required binding separately.

Step 904: The RN indexes the corresponding intermediate key KASME according to the eKSI, and indexes the device security parameter K_D to be bound according to the eKSI D, and derives the security key KASME bound to the device by using the same calculation method as the MME. — D.

In this step, if the RN fails to perform the security key binding process due to an abnormality, such as the failure to index the corresponding security key or security parameter, the RN can directly send the security key binding failure flag to the MME. The key binding response message, or set the binding success flag to false (False) in the security key binding response message. Optionally, the corresponding failure cause may be further carried in the security key binding response message, for example, the identifier in this embodiment does not exist.

Step 905: The RN sends a security key binding response message to the MME, where the security key binding response message carries a security key binding success flag. After the MME successfully receives the security key binding response message, it completes the synchronization binding of the security key.

FIG. 10 is a schematic flowchart of a fifth embodiment of implementing security key synchronization binding in the present invention. In the fifth embodiment, the MME and the RN are assumed to: perform security key binding processing after each device authentication is completed. Optionally, the binding result can be verified by other messages (such as NAS SMC messages) after the binding ends. As shown in Figure 10, the specific implementation includes the following steps:

Step 1000: The user authentication between the MME and the RN is completed through a User Authentication Procedure, and the intermediate key KASME is obtained. The implementation of this step belongs to the prior art and will not be described here.

Step 1001: The MME performs device authentication with the RN, and the two parties agree on a shared security parameter K-D in the device authentication process.

Step 1002 to step 1003: The MME and the RN respectively bind to the device according to a predetermined agreement. The security key: The intermediate key KASME and the device-related security parameters such as the shared key K-D are respectively used to derive the security key KASME D bound to the device according to the agreed key derivation algorithm, such as KASME-D = The KDF (KASME, KD), the specific implementation is a common technical means for those skilled in the art, and is not described here, and the specific implementation method is not limited to the scope of the present invention.

Step 1004: Optionally, the MME initiates a NAS Security Mode Command (NAS SMC) message to the RN, and performs integrity protection on the NAS security mode command message. The integrity protection key is derived from the security key KASME-D that can be bound to the device.

Step 1005: The RN derives an integrity protection key according to the security key KASME-D that is generated by the RN, and verifies the NAS security mode command message from the MME. If the risk certificate passes, the NAS security is returned to the MME. The mode completes (NAS SMC Complete) message, and encrypts the NAS security mode completion message, and the encryption key is derived from the device-bound security key KASME-D generated by the RN.

Step 1006: After receiving the NAS security mode complete message, the MME derives the decryption key according to the security key KASME-D that is generated by the MME itself, and decrypts the received NAS security mode completion message. If the decryption succeeds. The RN and the MME successfully receive the synchronization binding of the security key.

In this embodiment, the execution of step 1002 and step 1003 is in no order.

In the embodiment shown in FIG. 6 to FIG. 10, in the contract algorithm for performing security key binding, other parameters may be used, and the parameter may be a shared parameter known to both the RN and the network side; It is a random number generated by the RN or the network side. If it is a random number, the party that needs to generate the random number notifies the peer to the peer through the message.

The sequence of the processing flow in the embodiment shown in FIG. 6 to FIG. 10 of the present invention is embodied in the specific implementation. There may be variations in the process, which are readily available to those skilled in the art in accordance with the methods provided herein, and are not intended to limit the scope of the invention.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included. Within the scope of protection of the present invention.

Claims

Claim

A method for implementing security key synchronization binding, comprising:

2. The method according to claim 1, wherein the MME notifying the RN to perform security key binding comprises: sending, by the MME, a non-access stratum NAS message to the RN, and informing the RN to perform security key binding set.

The method according to claim 2, wherein the NAS message carries key binding indication information for instructing the RN to perform binding of the security key.

The method according to claim 3, wherein the NAS message further carries algorithm identification information for identifying an algorithm used when performing key binding.

The method according to claim 3, wherein the NAS message further carries identification information of a security key to be bound.

The method according to claim 5, wherein the NAS message further carries identification information related to a security parameter related to the device to be bound.

The method according to any one of claims 2 to 6, wherein the NAS message multiplexes an existing NAS message; the existing NAS message includes: a NAS security mode command message, or user authentication Request message

Alternatively, the NAS message is a new message, and the new message is a key binding request message.

The method according to claim 1, wherein the RN performs the same security key binding process as the network side, and the MME or the home subscriber HSS or the home location register HLR on the network side Or executed in the home environment HE.

The method according to claim 1, wherein the security key binding process performed by the network side is before the MME sends a NAS message to notify the RN; or, in the After the MME receives the response from the RN.

The method according to claim 1, 8 or 9, wherein the method further comprises: obtaining, by the network side, a user security key of the RN through a user authentication process, and obtaining a device-related security parameter of the RN;

The method according to claim 10, wherein the deriving the security key bound to the device according to the agreed algorithm further comprises:

The device-related security parameters, the user security key, and other parameters are used to derive a security key bound to the device in accordance with the predetermined algorithm.

The method according to claim 11, wherein the other parameters include parameters shared by the RN and the network side; or the random number generated by the network side or the RN, and the method further includes The network side or the RN notifies the RN or the network side of the generated random number by using a message.

The method according to claim 10, wherein the user security key is an intermediate key KASME or an encryption key CK, an integrity key IK.

The method according to claim 1, 8 or 9, wherein the device-related security parameter is a specific parameter shared by the RN and the network side;

The specific parameter is: a parameter in the subscription information of the RN; or a preset parameter in the device certificate.

The method according to claim 1, 8 or 9, wherein the device-related security parameter is: a device-related security parameter agreed upon in the device authentication process on the network side; The agreed device-related security parameter is the root key in the device subscription information, or other new key derived from the root key.

16. The method according to claim 1, 8 or 9, wherein the RN direction The MME sends a response including:

The RN feeds back the binding result to the MME by using an existing NAS message or by using a new message.

The method according to claim 16, wherein the response message fed back by the RN carries key binding success indication information for indicating that the RN successfully completes the security key binding; or The RN failed to complete the key binding failure indication information of the security key binding.

The method according to claim 17, wherein when the response message fed back by the RN carries the key binding failure indication information, the response message fed back by the RN further carries a failure reason.

A system for implementing a secure key synchronization binding, comprising: at least an RN and an MME, where

The MME is configured to send a security key binding notification to the RN.

The system according to claim 19, wherein the MME is specifically configured to: after the RN passes the user authentication, send a security key binding notification to the RN; before sending the security key binding notification to the RN Or, after receiving the response from the RN, perform the same security key binding process as the RN to obtain a security key bound to the device.

The system according to claim 19, wherein the system further comprises an HSS or an HLR or an HE, configured to perform the same security key binding processing as the RN, and obtain the security key binding process. The security key bound to the device is sent to the MME.

The system according to any one of claims 19 to 21, wherein the network side is further configured to obtain a user security key of the RN through a user authentication process, and obtain a device-related security parameter of the RN.