[go: up one dir, main page]

WO2012031510A1 - Procédé et système pour mettre en œuvre une liaison synchrone de clé de sécurité - Google Patents

Procédé et système pour mettre en œuvre une liaison synchrone de clé de sécurité Download PDF

Info

Publication number
WO2012031510A1
WO2012031510A1 PCT/CN2011/077617 CN2011077617W WO2012031510A1 WO 2012031510 A1 WO2012031510 A1 WO 2012031510A1 CN 2011077617 W CN2011077617 W CN 2011077617W WO 2012031510 A1 WO2012031510 A1 WO 2012031510A1
Authority
WO
WIPO (PCT)
Prior art keywords
security key
binding
key
security
mme
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2011/077617
Other languages
English (en)
Chinese (zh)
Inventor
和峰
冯成燕
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
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 ZTE Corp filed Critical ZTE Corp
Publication of WO2012031510A1 publication Critical patent/WO2012031510A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices

Definitions

  • 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.
  • LTE Long Term Evolution
  • FIG. 1 is a schematic structural diagram of an LTE network.
  • 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).
  • MME mobility management entity
  • S monthly service gateway
  • -GW Serving Gateway
  • HE Home Environment
  • HSS Home Subscriber Server
  • HLR Home Location Register
  • the HE contains user profiles, performs user authentication and authorization, and provides information about the user's physical location.
  • LTE-Advanced Long-Term Evolution advance
  • 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.
  • RN relay node
  • 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.
  • the RN can be used as either a normal terminal device or a base station.
  • the RN can access the wireless network like a normal UE.
  • the network side authenticates the user and authenticates the Key Agreement (AKA).
  • AKA Key Agreement
  • the process is also called the Evolved Packet System Key Agreement (EPS AKA).
  • EPS AKA Evolved Packet System AKA
  • the UE refers to the general name of the mobile device (Mobile Equipment) and the Universal Subscriber Identity Module (USIM).
  • USIM Universal Subscriber Identity Module
  • 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.
  • the USIM card here represents a generalized Universal Integrated Circuit Card (UICC)
  • 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).
  • the access layer security protection key ratio
  • 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. .
  • the RN 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. .
  • the RN acts as a base station
  • the 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.
  • the specific implementation scheme for realizing the legality certification of the RN is not determined.
  • Figure 3 is a schematic diagram of a process in which a possible RN is illegally attacked, as shown in Figure 3.
  • the attacker inserts the legal USIM card into the illegal RN and inserts the illegal USIM card into the legal RN.
  • the attacker uses the legal USIM and the legal RN to complete the corresponding user authentication.
  • 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.
  • 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.
  • 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.
  • a method for implementing secure key synchronization binding includes:
  • the mobility management entity MME notifies the relay node RN to perform security key binding
  • the RN 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;
  • the NAS message is a new message
  • 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.
  • 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.
  • the response message fed back by the RN 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
  • 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.
  • HSS HSS or HLR or HE
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 is a schematic structural diagram of an LTE network
  • FIG. 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
  • FIG. 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.
  • 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.
  • 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.
  • NAS security mode command NAS SMC, NAS Security Mode Command
  • User Authentication Request User Authentication Request
  • a key binding request message that is specifically designed to notify the RN to perform security key binding.
  • the NAS message in this step may not carry any information, that is, a notification.
  • 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;
  • 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);
  • EKSI Key Set Identity in E-UTRAN
  • the NAS message may further carry identification information of a security parameter related to the device to be bound.
  • 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.
  • 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.
  • 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 security key bound to the device may be deriving 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.
  • KDF Key Derivation 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. .
  • 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.
  • 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.
  • 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.
  • an existing NAS message such as a NAS Security Mode Complete message, or a User Authentication Response message
  • 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.
  • 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.
  • 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.
  • IMEI International Mobile Equipment Identity
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the device security parameter is a security parameter that is agreed by the device authentication process.
  • 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 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.
  • 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.
  • eKSI key identification information
  • 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.
  • 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.
  • 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.
  • KASME-D KDF(CK, IK, Ksec)
  • KDF(CK, IK, Ksec) KDF(CK, IK, Ksec)
  • 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.
  • SN id service network identifier
  • SQL sequence number
  • AK Anonymity Key
  • Step 802 The HSS sends the generated security key KASME_D bound to the device to the MME in the authentication data response message.
  • 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.
  • the MME sends a user authentication response message carrying the binding failure flag to the MME.
  • 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.
  • 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.
  • 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.
  • FIG. 9 is a schematic flowchart of a fourth embodiment of implementing security key synchronization binding in the present invention.
  • 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.
  • 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.
  • 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.
  • KASME-D KDF (KASME, KD, RAND M)
  • KDF KASME, KD, RAND M
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 10 is a schematic flowchart of a fifth embodiment of implementing security key synchronization binding in the present invention.
  • the MME and the RN are assumed to: perform security key binding processing after each device authentication is completed.
  • the binding result can be verified by other messages (such as NAS SMC messages) after the binding ends.
  • 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.
  • Step 1004 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.
  • NAS SMC NAS Security Mode Command
  • 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.
  • 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.
  • 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.
  • step 1002 and step 1003 are in no order.
  • 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.

Landscapes

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

Abstract

L'invention concerne un procédé et un système pour mettre en œuvre une liaison synchrone de clé de sécurité. Le procédé comprend les étapes suivantes : un MME notifie un RN de la réalisation d'une liaison de clé de sécurité; après réception de la notification, le RN réalise le même traitement de liaison de clé de sécurité que celui sur un côté réseau pour obtenir une clé de sécurité liée à un dispositif, et répond au MME. Selon la solution de l'invention, la clé de sécurité liée au dispositif et obtenue grâce au traitement de liaison de clé de sécurité, ou d'autres clés découlant de l'utilisation de la clé de sécurité liée au dispositif, protègent la sécurité des données de communication entre le RN et le côté réseau. De plus, grâce à la clé de sécurité liée au dispositif, la liaison d'une authentification d'abonné de RN au dispositif est mise en œuvre, et il est garanti que le RN communiquant actuellement avec le côté réseau est incontestablement un RN légal ayant une carte USIM légale. Par conséquent, les attaquants illégaux ne peuvent pas déchiffrer les données de communication.
PCT/CN2011/077617 2010-09-10 2011-07-26 Procédé et système pour mettre en œuvre une liaison synchrone de clé de sécurité Ceased WO2012031510A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010282470.3A CN101945386B (zh) 2010-09-10 2010-09-10 一种实现安全密钥同步绑定的方法及系统
CN201010282470.3 2010-09-10

Publications (1)

Publication Number Publication Date
WO2012031510A1 true WO2012031510A1 (fr) 2012-03-15

Family

ID=43437080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/077617 Ceased WO2012031510A1 (fr) 2010-09-10 2011-07-26 Procédé et système pour mettre en œuvre une liaison synchrone de clé de sécurité

Country Status (2)

Country Link
CN (1) CN101945386B (fr)
WO (1) WO2012031510A1 (fr)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102196438A (zh) 2010-03-16 2011-09-21 高通股份有限公司 通信终端标识号管理的方法和装置
US9385862B2 (en) 2010-06-16 2016-07-05 Qualcomm Incorporated Method and apparatus for binding subscriber authentication and device authentication in communication systems
US8839373B2 (en) 2010-06-18 2014-09-16 Qualcomm Incorporated Method and apparatus for relay node management and authorization
CN101945386B (zh) * 2010-09-10 2015-12-16 中兴通讯股份有限公司 一种实现安全密钥同步绑定的方法及系统
CN101931953B (zh) * 2010-09-20 2015-09-16 中兴通讯股份有限公司 生成与设备绑定的安全密钥的方法及系统
US9112905B2 (en) 2010-10-22 2015-08-18 Qualcomm Incorporated Authentication of access terminal identities in roaming networks
CN102595403A (zh) * 2011-01-14 2012-07-18 中兴通讯股份有限公司 绑定中继节点的认证方法及装置
CN102595395A (zh) * 2011-01-14 2012-07-18 中兴通讯股份有限公司 一种中继节点的认证方法及系统
US9668128B2 (en) 2011-03-09 2017-05-30 Qualcomm Incorporated Method for authentication of a remote station using a secure element
CN102685735B (zh) * 2011-03-11 2017-02-01 中兴通讯股份有限公司 一种在rn切换过程中重建高层安全的方法和系统
US8887258B2 (en) 2011-08-09 2014-11-11 Qualcomm Incorporated Apparatus and method of binding a removable module to an access terminal
EP3139649A1 (fr) * 2015-09-04 2017-03-08 Gemalto Sa Procédé pour authentifier un abonné dans un réseau local
CN109698746B (zh) * 2019-01-21 2021-03-23 北京邮电大学 基于主密钥协商生成绑定设备的子密钥的方法和系统
US11310661B2 (en) * 2020-02-14 2022-04-19 Mediatek Inc. Security key synchronization method and associated communications apparatus

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101233734A (zh) * 2005-06-30 2008-07-30 朗迅科技公司 用于在无线通信系统中的越区切换期间分发安全密钥的方法
CN101500229A (zh) * 2008-01-30 2009-08-05 华为技术有限公司 建立安全关联的方法和通信网络系统
CN101500230A (zh) * 2008-01-30 2009-08-05 华为技术有限公司 建立安全关联的方法和通信网络
CN101931953A (zh) * 2010-09-20 2010-12-29 中兴通讯股份有限公司 生成与设备绑定的安全密钥的方法及系统
CN101945386A (zh) * 2010-09-10 2011-01-12 中兴通讯股份有限公司 一种实现安全密钥同步绑定的方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101233734A (zh) * 2005-06-30 2008-07-30 朗迅科技公司 用于在无线通信系统中的越区切换期间分发安全密钥的方法
CN101500229A (zh) * 2008-01-30 2009-08-05 华为技术有限公司 建立安全关联的方法和通信网络系统
CN101500230A (zh) * 2008-01-30 2009-08-05 华为技术有限公司 建立安全关联的方法和通信网络
CN101945386A (zh) * 2010-09-10 2011-01-12 中兴通讯股份有限公司 一种实现安全密钥同步绑定的方法及系统
CN101931953A (zh) * 2010-09-20 2010-12-29 中兴通讯股份有限公司 生成与设备绑定的安全密钥的方法及系统

Also Published As

Publication number Publication date
CN101945386A (zh) 2011-01-12
CN101945386B (zh) 2015-12-16

Similar Documents

Publication Publication Date Title
US11863982B2 (en) Subscriber identity privacy protection against fake base stations
US11856402B2 (en) Identity-based message integrity protection and verification for wireless communication
WO2012031510A1 (fr) Procédé et système pour mettre en œuvre une liaison synchrone de clé de sécurité
CN101931953B (zh) 生成与设备绑定的安全密钥的方法及系统
KR101554396B1 (ko) 통신 시스템들에서 가입자 인증과 디바이스 인증을 바인딩하는 방법 및 장치
CN101931955B (zh) 认证方法、装置及系统
EP2421292B1 (fr) Procédé et dispositif d'établissement de mécanisme de sécurité de liaison d'interface radio
KR101978084B1 (ko) Ue 및 네트워크 양자에서의 키 도출을 위한 mtc 키 관리
US9667413B2 (en) Encryption realization method and system
CN101945387B (zh) 一种接入层密钥与设备的绑定方法和系统
JP2019512942A (ja) ５ｇ技術のための認証機構
US20130091556A1 (en) Method for establishing a secure and authorized connection between a smart card and a device in a network
CN102056159B (zh) 一种中继系统的安全密钥获取方法、装置
CN101951590B (zh) 认证方法、装置及系统
JP2013537374A (ja) 中継ノード装置の認証メカニズム
CN101500229A (zh) 建立安全关联的方法和通信网络系统
EP3718330B1 (fr) Création de clé de session
US20170223531A1 (en) Authentication in a wireless communications network
CN101977378B (zh) 信息传输方法、网络侧及中继节点
WO2020056433A2 (fr) Communication sécurisée de demande de commande de ressource radio (rrc) sur porteuse radio de signal zéro (srb0)
WO2012094920A1 (fr) Procédé et système d'authentification de nœud relais
CN107925874B (zh) 超密集网络安全架构和方法
CN102595403A (zh) 绑定中继节点的认证方法及装置
CN108712742B (zh) 物联网网络安全优化方法、用户终端和网络侧设备

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: 11823033

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: 11823033

Country of ref document: EP

Kind code of ref document: A1