WO2020140926A1 - 一种密钥生成方法、终端设备及网络设备 - Google Patents

一种密钥生成方法、终端设备及网络设备 Download PDF

Info

Publication number
WO2020140926A1
WO2020140926A1 PCT/CN2020/070036 CN2020070036W WO2020140926A1 WO 2020140926 A1 WO2020140926 A1 WO 2020140926A1 CN 2020070036 W CN2020070036 W CN 2020070036W WO 2020140926 A1 WO2020140926 A1 WO 2020140926A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
terminal device
session key
network
session
Prior art date
Application number
PCT/CN2020/070036
Other languages
English (en)
French (fr)
Inventor
刘福文
Original Assignee
***通信有限公司研究院
***通信集团有限公司
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 ***通信有限公司研究院, ***通信集团有限公司 filed Critical ***通信有限公司研究院
Priority to US17/420,534 priority Critical patent/US20220085990A1/en
Priority to AU2020204946A priority patent/AU2020204946B2/en
Priority to CA3125583A priority patent/CA3125583C/en
Priority to JP2021538677A priority patent/JP7329604B2/ja
Priority to EP20735916.7A priority patent/EP3905585B1/en
Priority to SG11202107340QA priority patent/SG11202107340QA/en
Publication of WO2020140926A1 publication Critical patent/WO2020140926A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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]
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • This application relates to the field of information processing technology, and in particular, to a key generation method, terminal device, network device, and computer storage medium.
  • the security architecture is the guarantee for the normal operation of the 5G network.
  • the authentication protocol is the cornerstone of building a 5G security architecture.
  • the UE and the network each need to generate DH key exchange related parameters. The generation of these parameters requires the use of asymmetric algorithms, which consumes a lot of computing resources, which is particularly unacceptable for IoT terminals, and this kind of processing can only prevent passive attacks (eavesdropping), not active attacks (man-in-the-middle attacks).
  • the embodiments of the present application provide a key generation method, terminal device, network device, and computer storage medium.
  • a key generation method is provided, which is applied to a terminal device.
  • the method includes:
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the keys are all symmetric keys.
  • a key generation method is provided, which is applied to a network device.
  • the method includes:
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • a terminal device including:
  • the first key generation unit is used to determine the first key based on the long-term key; generate the session key based on the first key and at least one additional key;
  • a first communication unit configured to communicate with the network side based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the key is a symmetric key.
  • a terminal device including:
  • the first processor is used to determine the first key based on the long-term key; generate the session key based on the first key and at least one additional key;
  • a first communication interface used to communicate with the network side based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the key is a symmetric key.
  • a network device including:
  • a second key generating unit for determining the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; generating the terminal based on the first key and at least one additional key The session key corresponding to the device;
  • a second communication unit configured to communicate with the terminal device based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • a network device including:
  • the second processor is used to determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; based on the first key and at least one additional key, generate the terminal device The corresponding session key for this session;
  • a second communication interface used to communicate with the terminal device based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • a computer storage medium on which a computer program is stored, wherein the computer program is executed by a processor to implement the steps of the foregoing method
  • a key generation system includes: at least one terminal device and an authentication service function AUSF entity; wherein,
  • the terminal device is used to determine the first key based on the long-term key; generate the session key based on the first key and at least one additional key, and communicate with the network side based on the session key ;
  • the AUSF entity is used to determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; generate the terminal based on the first key and at least one additional key
  • the current session key corresponding to the device communicates with the terminal device based on the current session key; wherein, the at least one additional key includes: an initial session generated when the terminal device connects to the network for the first time
  • the key, and/or the session key used in the last communication with the terminal device the first key and the at least one additional key are symmetric keys.
  • the initial session key generated when the terminal device is connected to the network for the first time can be used, and/or, the last time
  • the session key used for communication is used to jointly generate the session key; in this way, the security of the session key can be enhanced without major changes to the original authentication protocol.
  • the use of symmetric key algorithms has very low requirements on the operation of the device, and thus consumes less power, so it is more suitable for use in the Internet of Things scenario.
  • FIG. 1 is a schematic flowchart 1 of a key generation method provided by an embodiment of the present application.
  • FIG. 2 is a schematic flowchart 2 of a key generation method provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart 3 of a key generation method according to an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram 1 of a composition structure of a terminal device provided by an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram 2 of a composition structure of a terminal device provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram 1 of a composition of a network device according to an embodiment of this application.
  • FIG. 7 is a schematic structural diagram 2 of a network device composition provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a system composition structure provided by an embodiment of the present application.
  • an embodiment of the present application provides a key generation method, which is applied to a terminal device, and the method includes:
  • Step 101 Determine the first key based on the long-term key
  • Step 102 Generate a session key based on the first key and at least one additional key, and communicate with the network side based on the session key;
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the key is a symmetric key.
  • This embodiment provides a variety of specific processing scenarios, which are described below respectively:
  • the method further includes: generating an initial session key when connecting to the network for the first time and completing mutual authentication with the authentication service function.
  • the terminal device connects to the network for the first time, completes mutual authentication with the authentication service function (AUSF, Authentication Server Function), and generates the first key, which can be recorded as KSEAF_first;
  • AUSF Authentication Server Function
  • the subsequent generation of the session key based on the first key and at least one additional key includes generating the session key based on the first key and the initial session key.
  • the final session key KSEAF* is generated in addition to the first key KSEAF derived using the long-term key K, plus the first initial session key KSEAF_first.
  • the terminal device connects to the network for the first time, completes mutual authentication with AUSF, and generates the first session key KSEAF_first. After the subsequent terminal device and AUSF complete mutual authentication, the final session key is generated in addition to the long-term key K In addition to the key KSEAF, the first session key KSEAF_first must be added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and the AUSF on the network side obtain the first key derived based on the long-term key K, which can be expressed as KSEAF.
  • the terminal device and AUSF use the first key KSEAF and the initial session key KSEAF_first stored in the secure area to generate the session key KSEAF*.
  • the calculation can be expressed as follows:
  • KSEAF* KDF (KSEAF, KSEAF_first, AP);
  • KDF represents the key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing bidding down attacks, it needs to be understood that AP is an optional parameter, which can be used or not, so AP may not appear in the formula.
  • the initial session key can be saved in the terminal device and the AUSF on the network side, specifically, the terminal device side: stored in the USIM or information tamper-resistant storage area; AUSF is stored in the information tamper-resistant storage area.
  • the first session key KSEAF* generated is set as the initial session key KSEAF_first and stored in the terminal device and AUSF for a long time.
  • 5G AKA or EAP-AKA the former is developed from the LTE-based authentication protocol EPS-AKA, while the latter is an IETF-defined authentication protocol used by UEs to access the operator’s network using WIFI in 4G networks.
  • EAP-AKA' the UE can not only access the operator network through WIFI, but also access the operator network through the 5G wireless access network.
  • the AKA authentication protocol relies on the root key K stored in the USIM to implement mutual authentication between the UE and the network, and derive the session key.
  • the assumption of security is that the root key K is unknown to everyone except the network operator, so the attacker cannot derive the session key.
  • the report [1] shows that this assumption is not always correct, because the root key K may have been leaked during the production stage of the USIM card. Therefore, a passive attacker can use the root key K and the session key derived from the exchange of messages between the UE and the network to eavesdrop on the communication.
  • An active attacker may use a large number of stolen root keys to forge a base station and initiate a man-in-the-middle attack.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the root key K, but also on the first session key KSEAF_first.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the first session key KSEAF_first, which is a relatively low probability.
  • the session key is generated as follows:
  • the generating the session key based on the first key and at least one additional key includes:
  • the current session key is generated based on the first key and the session key used in the previous communication.
  • the final session key is generated in addition to the key KSEAF derived from the long-term key K, and the stored session key KSEAF_pre that was generated last time is added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and AUSF obtain the session key KSEAF derived based on the long-term key K.
  • the terminal device and AUSF use KSEAF and KSEAF_pre stored in the secure area to generate the final session key KSEAF*, which is calculated as follows:
  • KSEAF* KDF (KSEAF, KSEAF_pre, AP)
  • KDF is a key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter used for auxiliary functions, such as preventing bidding down attacks
  • AP is an optional parameter, and may not appear in the formula.
  • KSEAF_pre null.
  • the terminal device and the network After the terminal device and the network generate this session key KSEAF*, it will replace the session key KSEAF_pre used in the last communication stored in the terminal device and the network with it.
  • the session key after the session key is generated, it can be stored on the terminal device and the network side respectively, and the session key used in the previous communication can be replaced for storage, and then, the next time the session key is generated again, The session key used in the last communication after replacement is used to generate the next session key.
  • the processing method is the same as the above description in this scenario, so it will not be described again.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the long-term key K, but also on the last stored session key KSEAF_pre.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the last stored session key KSEAF_pre. This requires the attacker to continue to obtain the last stored session key KSEAF_pre in order to continue to obtain the final session key.
  • Scenario 3 Based on the initial session key and the session key used in the previous communication, this session key is jointly generated; the specific instructions are as follows:
  • the generating the session key based on the first key and at least one additional key includes:
  • the current session key is generated based on the first key, the initial session key, and the session key used in the previous communication.
  • this scenario is based on scenarios 1 and 2.
  • the generation of the final session key KSEAF* uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the generation and storage of the initial session key and the session key used in the previous communication are the same as those in scenes 1 and 2, which will not be repeated here.
  • KSEAF* KDF (KSEAF, KSEAF_first, KSEAF_pre, AP)
  • KDF is a key deduction function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing a bidding down attack
  • This scenario 3 is more secure than scenarios 1 and 2, because in this scenario, the attacker needs to be able to obtain the first session key and continue to obtain the last stored session The key KSEAF_pre.
  • the initial session key generated when the terminal device is first connected to the network can be used, and/or, the last communication Use the session key to jointly generate the session key; in this way, the security of the session key can be enhanced without major changes to the original authentication protocol.
  • the use of symmetric key algorithms has very low requirements on the operation of the device, and thus consumes less power, so it is more suitable for use in the Internet of Things scenario.
  • an embodiment of the present application provides a key generation method, which is applied to a network device, and the method includes:
  • Step 301 Determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device;
  • Step 302 Generate a session key corresponding to the terminal device based on the first key and at least one additional key, and communicate with the terminal device based on the session key;
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • the network device involved in this embodiment may be regarded as a device with AUSF function on the network side.
  • This embodiment provides a variety of specific processing scenarios, which are described below respectively:
  • the method further includes:
  • an initial session key used for communication between the network side and the terminal device is generated.
  • the terminal device connects to the network for the first time, completes mutual authentication with the authentication service function (AUSF, Authentication Server Function), and generates the first key, which can be recorded as KSEAF_first;
  • AUSF Authentication Server Function
  • the generating the session key corresponding to the terminal device based on the first key and at least one additional key includes:
  • the current session key of the terminal device is generated based on the first key corresponding to the terminal device and the initial session key generated when the terminal device connects to the network for the first time.
  • the final session key KSEAF* is generated in addition to the first key KSEAF derived using the long-term key K, plus the first initial session key KSEAF_first.
  • the terminal device connects to the network for the first time, completes mutual authentication with AUSF, and generates the first session key KSEAF_first. After the subsequent terminal device and AUSF complete mutual authentication, the final session key is generated in addition to the long-term key K In addition to the key KSEAF, the first session key KSEAF_first must be added.
  • the UDM on the network side When the UDM on the network side performs secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G, AKA, or EAP-AKA. Of course, authentication The protocol may also have other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and the network device on the network side obtain the first key derived based on the long-term key K, which can be expressed as KSEAF.
  • the terminal device and AUSF use the first key KSEAF and the initial session key KSEAF_first stored in the secure area to generate the session key KSEAF*.
  • the calculation can be expressed as follows:
  • KSEAF* KDF (KSEAF, KSEAF_first, AP);
  • KDF represents the key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing bidding down attacks, it needs to be understood that AP is an optional parameter, which can be used or not, so AP may not appear in the formula.
  • the initial session key can be saved in the terminal device and the AUSF on the network side, specifically, the terminal device side: stored in the USIM or information tamper-resistant storage area; AUSF is stored in the information tamper-resistant storage area.
  • the first session key KSEAF* generated is set as the initial session key KSEAF_first and stored in the terminal device and AUSF for a long time.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the root key K, but also on the first session key KSEAF_first.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the first session key KSEAF_first, which is a relatively low probability.
  • the session key is generated as follows:
  • the generating the session key corresponding to the terminal device based on the first key and at least one additional key includes:
  • a current session key used for communication between the network side and the terminal device is generated.
  • the final session key is generated in addition to the key KSEAF derived using the long-term key K, and the stored session key KSEAF_pre that was generated last time is added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and AUSF obtain the session key KSEAF derived based on the long-term key K.
  • the terminal device and AUSF use KSEAF and KSEAF_pre stored in the secure area to generate the final session key KSEAF*, which is calculated as follows:
  • KSEAF* KDF (KSEAF, KSEAF_pre, AP)
  • KDF is a key deduction function, such as HMAC-SHA-256
  • AP is an auxiliary parameter used for auxiliary functions, such as preventing bidding attacks
  • AP is an optional parameter, and may not appear in the formula.
  • KSEAF_pre null.
  • the terminal device and the network After the terminal device and the network generate this session key KSEAF*, it will replace the session key KSEAF_pre used in the last communication stored in the terminal device and the network with it.
  • the session key after the session key is generated, it can be stored on the terminal device and the network side respectively, and the session key used in the previous communication can be replaced for storage, and then, the next time the session key is generated again,
  • the session key used in the last communication after replacement is used to generate the next session key, and the processing method is the same as the above description in this scenario, so it will not be described again.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the long-term key K, but also on the last stored session key KSEAF_pre.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the last stored session key KSEAF_pre. This requires the attacker to continue to obtain the last stored session key KSEAF_pre in order to continue to obtain the final session key.
  • Scenario 3 Based on the initial session key and the session key used in the previous communication, this session key is jointly generated; the specific instructions are as follows:
  • this scenario is based on scenarios 1 and 2.
  • the generation of the final session key KSEAF* uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the generation and storage of the initial session key and the session key used in the previous communication are the same in scenarios 1 and 2 and will not be repeated here.
  • KSEAF* KDF (KSEAF, KSEAF_first, KSEAF_pre, AP)
  • KDF is a key deduction function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing a bidding down attack
  • This scenario 3 is more secure than scenarios 1 and 2, because in this scenario, the attacker needs to be able to obtain the first session key and continue to obtain the last stored session The key KSEAF_pre.
  • the initial session key generated when the terminal device is first connected to the network can be used, and/or, the last communication Use the session key to jointly generate the session key; in this way, the security of the session key can be enhanced without major changes to the original authentication protocol.
  • an embodiment of the present application provides a terminal device, including:
  • the first key generation unit 41 is used to determine the first key based on the long-term key; generate the session key based on the first key and at least one additional key;
  • the first communication unit 42 is configured to communicate with the network side based on the current session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the key is a symmetric key.
  • an embodiment of the present application provides a terminal device, including:
  • the first processor 51 is configured to determine the first key based on the long-term key; generate the session key based on the first key and at least one additional key;
  • the first communication interface 52 is used to communicate with the network side based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication; the first key and the at least one additional key
  • the key is a symmetric key.
  • This embodiment provides a variety of specific processing scenarios, which are described below respectively:
  • the first processor 51 is configured to generate an initial session key when connecting to the network for the first time and completing mutual authentication with the authentication service function.
  • the terminal device connects to the network for the first time, completes mutual authentication with the authentication service function (AUSF, Authentication Server Function), and generates the first key, which can be recorded as KSEAF_first;
  • AUSF Authentication Server Function
  • the subsequent first processor 51 is configured to generate the current session key based on the first key and the initial session key.
  • the final session key KSEAF* is generated in addition to the first key KSEAF derived using the long-term key K, plus the first initial session key KSEAF_first.
  • the terminal device connects to the network for the first time, completes mutual authentication with AUSF, and generates the first session key KSEAF_first. After the subsequent terminal device and AUSF complete mutual authentication, the final session key is generated in addition to the long-term key K In addition to the key KSEAF, the first session key KSEAF_first must be added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and the AUSF on the network side obtain the first key derived based on the long-term key K, which can be expressed as KSEAF.
  • the terminal device and AUSF use the first key KSEAF and the initial session key KSEAF_first stored in the secure area to generate the session key KSEAF*.
  • the calculation can be expressed as follows:
  • KSEAF* KDF (KSEAF, KSEAF_first, AP);
  • KDF represents the key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing bidding down attacks, it needs to be understood that AP is an optional parameter, which can be used or not, so AP may not appear in the formula.
  • the initial session key can be saved in the terminal device and the AUSF on the network side, specifically, the terminal device side: stored in the USIM or information tamper-resistant storage area; AUSF is stored in the information tamper-resistant storage area.
  • the first session key KSEAF* generated is set as the initial session key KSEAF_first and stored in the terminal device and AUSF for a long time.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the root key K, but also on the first session key KSEAF_first.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the first session key KSEAF_first, which is a relatively low probability.
  • the session key is generated as follows:
  • the first processor 51 is configured to generate the current session key based on the first key and the session key used in the previous communication.
  • the final session key is generated in addition to the key KSEAF derived using the long-term key K, and the stored session key KSEAF_pre that was generated last time is added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and AUSF obtain the session key KSEAF derived based on the long-term key K.
  • the terminal device and AUSF use KSEAF and KSEAF_pre stored in the secure area to generate the final session key KSEAF*, which is calculated as follows:
  • KSEAF* KDF (KSEAF, KSEAF_pre, AP)
  • KDF is a key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter used for auxiliary functions, such as preventing bidding down attacks
  • AP is an optional parameter, and may not appear in the formula.
  • KSEAF_pre null.
  • the terminal device and the network After the terminal device and the network generate this session key KSEAF*, it will replace the session key KSEAF_pre used in the last communication stored in the terminal device and the network with it.
  • the session key after the session key is generated, it can be stored on the terminal device and the network side respectively, and the session key used in the previous communication can be replaced for storage, and then, the next time the session key is generated
  • the session key used in the last communication after replacement is used to generate the next session key.
  • the processing method is the same as the above description in this scenario, so it will not be described again.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the long-term key K, but also on the last stored session key KSEAF_pre.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the last stored session key KSEAF_pre. This requires the attacker to continue to obtain the last stored session key KSEAF_pre in order to continue to obtain the final session key.
  • Scenario 3 Based on the initial session key and the session key used in the previous communication, this session key is jointly generated; the specific instructions are as follows:
  • the first processor 51 is configured to generate the session key based on the first key, the initial session key, and the session key used in the previous communication.
  • this scenario is based on scenarios 1 and 2.
  • the generation of the final session key KSEAF* uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the generation and storage of the initial session key and the session key used in the previous communication are the same in scenarios 1 and 2 and will not be repeated here.
  • KSEAF* KDF (KSEAF, KSEAF_first, KSEAF_pre, AP)
  • KDF is a key deduction function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing a bidding down attack
  • This scenario 3 is more secure than scenarios 1 and 2, because in this scenario, the attacker needs to be able to obtain the first session key and continue to obtain the last stored session The key KSEAF_pre.
  • the initial session key generated when the terminal device is first connected to the network can be used, and/or, the last communication Use the session key to jointly generate the session key; in this way, the security of the session key can be enhanced without major changes to the original authentication protocol.
  • an embodiment of the present application provides a network device.
  • the method includes:
  • the second key generation unit 61 is used to determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; based on the first key and at least one additional key, generate the The session key corresponding to the terminal device;
  • the second communication unit 62 is configured to communicate with the terminal device based on the current session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • an embodiment of the present application provides a network device.
  • the method includes:
  • the second processor 71 is configured to determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; generate the terminal device based on the first key and at least one additional key The corresponding session key for this session;
  • the second communication interface 72 is used to communicate with the terminal device based on the session key
  • the at least one additional key includes: an initial session key generated when the terminal device connects to the network for the first time, and/or a session key used in the last communication with the terminal device; the first password
  • the key and the at least one additional key are symmetric keys.
  • the network device involved in this embodiment may be regarded as a device with AUSF function on the network side.
  • This embodiment provides a variety of specific processing scenarios, which are described below respectively:
  • the second processor 71 is configured to generate an initial session key used for communication between the network side and the terminal device when the terminal device connects to the network for the first time and completes mutual authentication with the authentication service function.
  • the terminal device connects to the network for the first time, completes mutual authentication with the authentication service function (AUSF, Authentication Server Function), and generates the first key, which can be recorded as KSEAF_first;
  • AUSF Authentication Server Function
  • the second processor 71 is configured to generate the session key of the terminal device based on the first key corresponding to the terminal device and the initial session key generated when the terminal device connects to the network for the first time .
  • the final session key KSEAF* is generated in addition to the first key KSEAF derived using the long-term key K, plus the first initial session key KSEAF_first.
  • the terminal device connects to the network for the first time, completes mutual authentication with AUSF, and generates the first session key KSEAF_first. After the subsequent terminal device and AUSF complete mutual authentication, the final session key is generated in addition to the long-term key K In addition to the key KSEAF, the first session key KSEAF_first must be added.
  • the UDM on the network side When the UDM on the network side performs secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G, AKA, or EAP-AKA. Of course, authentication The protocol may also have other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and the network device on the network side obtain the first key derived based on the long-term key K, which can be expressed as KSEAF.
  • the terminal device and AUSF use the first key KSEAF and the initial session key KSEAF_first stored in the secure area to generate the session key KSEAF*.
  • the calculation can be expressed as follows:
  • KSEAF* KDF (KSEAF, KSEAF_first, AP);
  • KDF represents the key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing bidding down attacks, it needs to be understood that AP is an optional parameter, which can be used or not, so AP may not appear in the formula.
  • the initial session key can be saved in the terminal device and the AUSF on the network side, specifically, the terminal device side: stored in the USIM or information tamper-resistant storage area; AUSF is stored in the information tamper-resistant storage area.
  • the first session key KSEAF* generated is set as the initial session key KSEAF_first and stored in the terminal device and AUSF for a long time.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the root key K, but also on the first session key KSEAF_first.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the first session key KSEAF_first, which is a relatively low probability.
  • the session key is generated as follows:
  • the second processor 71 is configured to generate the current session key used for communication between the network side and the terminal device based on the first key and the session key used in the last communication with the terminal device .
  • the final session key is generated in addition to the key KSEAF derived using the long-term key K, and the stored session key KSEAF_pre that was generated last time is added.
  • the network side When the network side needs to perform secondary authentication on the user terminal device, it determines which authentication protocol is used to authenticate the terminal device according to the profile of the terminal device; wherein, the authentication protocol may be 5G AKA or EAP-AKA'. Of course, the authentication protocol also There may be other protocols, but it is not exhaustive in this embodiment.
  • the relevant information profile of the user's terminal device can be written into Unified Data Management (UDM, Unified Data Management) when the terminal device signs a contract with the network side, and then when the terminal device needs to be authenticated, UDM To determine which authentication protocol the terminal equipment uses for processing;
  • UDM Unified Data Management
  • the terminal device and the network side use the selected authentication protocol for mutual authentication; for example, the terminal device, such as the UE, can mutually authenticate with the UDM/ARPF through the selected authentication protocol.
  • both the terminal device and AUSF obtain the session key KSEAF derived based on the long-term key K.
  • the terminal device and AUSF use KSEAF and KSEAF_pre stored in the secure area to generate the final session key KSEAF*, which is calculated as follows:
  • KSEAF* KDF (KSEAF, KSEAF_pre, AP)
  • KDF is a key derivation function, such as HMAC-SHA-256
  • AP is an auxiliary parameter used for auxiliary functions, such as preventing bidding down attacks
  • AP is an optional parameter, and may not appear in the formula.
  • KSEAF_pre null.
  • the terminal device and the network After the terminal device and the network generate this session key KSEAF*, it will replace the session key KSEAF_pre used in the last communication stored in the terminal device and the network with it.
  • the session key after the session key is generated, it can be stored on the terminal device and the network side respectively, and the session key used in the previous communication can be replaced for storage, and then, the next time the session key is generated again, The session key used in the last communication after replacement is used to generate the next session key.
  • the processing method is the same as the above description in this scenario, so it will not be described again.
  • the security of the final session key KSEAF* can be guaranteed, because its generation depends not only on the key KSEAF generated based on the long-term key K, but also on the last stored session key KSEAF_pre.
  • the attacker cannot obtain the final session key KSEAF* unless the attacker can obtain the last stored session key KSEAF_pre. This requires the attacker to continue to obtain the last stored session key KSEAF_pre in order to continue to obtain the final session key.
  • Scenario 3 Based on the initial session key and the session key used in the previous communication, this session key is jointly generated; the specific instructions are as follows:
  • the second processor 71 is configured to generate the network-side and based on the first key, the initial session key generated when the terminal device first connects to the network, and the session key used in the last communication with the terminal device The session key used for communication by the terminal device.
  • this scenario is based on scenarios 1 and 2.
  • the generation of the final session key KSEAF* uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the key KSEAF_pre uses the initial session key KSEAF_first and the last generated session in addition to the first key KSEAF derived from the long-term key K.
  • the generation and storage of the initial session key and the session key used in the previous communication are the same in scenarios 1 and 2 and will not be repeated here.
  • KSEAF* KDF (KSEAF, KSEAF_first, KSEAF_pre, AP)
  • KDF is a key deduction function, such as HMAC-SHA-256
  • AP is an auxiliary parameter for auxiliary functions, such as preventing a bidding down attack
  • This scenario 3 is more secure than scenarios 1 and 2, because in this scenario, the attacker needs to be able to obtain the first session key and continue to obtain the last stored session The key KSEAF_pre.
  • the initial session key generated when the terminal device is first connected to the network can be used, and/or, the last communication Use the session key to jointly generate the session key; in this way, the security of the session key can be enhanced without major changes to the original authentication protocol.
  • Embodiments of the present application also provide a computer-readable storage medium for storing computer programs.
  • the computer-readable storage medium can be applied to any network device in the embodiments of the present application, and the computer program enables the computer to execute the corresponding process implemented by the network device in each method of the embodiments of the present application, for simplicity And will not be repeated here.
  • An embodiment of the present application further provides a key generation system.
  • the system includes: at least one terminal device 81 and an authentication service function AUSF entity 82; wherein,
  • the terminal device 81 is configured to determine a first key based on a long-term key; generate a session key based on the first key and at least one additional key, and perform a session with the network side based on the session key Communication
  • the AUSF entity 82 is configured to determine the first key corresponding to the terminal device based on the long-term key corresponding to the terminal device; based on the first key and at least one additional key, generate the The current session key corresponding to the terminal device communicates with the terminal device based on the current session key; wherein, the at least one additional key includes: an initial value generated when the terminal device connects to the network for the first time The session key, and/or the session key used in the last communication with the terminal device; the first key and the at least one additional key are symmetric keys.
  • the system also includes: a unified data management UDM entity 83, which is used to complete authentication with the terminal device when the terminal device is first connected to the network;
  • the terminal device is used to complete the authentication when the network is connected to the UDM entity for the first time, generate and save the initial session key.
  • the terminal device is configured to generate the session key based on the first key and the initial session key
  • the AUSF entity is used to generate the current time for the network side to communicate with the terminal device based on the first key corresponding to the terminal device and the initial session key generated when the terminal device connects to the network for the first time Session key.
  • the terminal device is configured to generate the session key based on the first key and the session key used in the previous communication;
  • the AUSF entity is used to generate the current session key used for communication between the network side and the terminal device based on the first key and the session key used in the last communication with the terminal device.
  • the terminal device is configured to generate the session key based on the first key, the initial session key, and the session key used in the previous communication;
  • the AUSF entity is used to generate the network side and all based on the first key, the initial session key generated when the terminal device connects to the network for the first time, and the session key used in the last communication with the terminal device Describe the session key used for terminal device communication.
  • the disclosed system, device, and method may be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the unit is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical, or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium.
  • the technical solution of the present application essentially or part of the contribution to the existing technology or part of the technical solution can be embodied in the form of a software product
  • the computer software product is stored in a storage medium, including Several instructions are used to enable a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本申请实施例提供了一种密钥生成方法、其涉及终端设备、网络设备以及计算机可读存储介质，其中方法包括：基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥均为对称密钥。

Description

一种密钥生成方法、终端设备及网络设备
相关申请的交叉引用
本申请基于申请号为201910000352.X、申请日为2019年1月2日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
本申请涉及信息处理技术领域，尤其涉及一种密钥生成方法、终端设备、网络设备以及计算机存储介质。
背景技术
5G将渗透到未来社会的各个领域，在构建以用户为中心的全方位信息生态***中将起到关键作用。安全架构是5G网络正常运行的保障。认证协议是构建5G安全架构的基石。UE和网络每次都要生成DH密钥交换相关的参数。生成这些参数需要使用非对称算法，这就要消耗大量的计算资源，这对于物联网终端尤其不可接受，并且，这种处理只能防御被动攻击(窃听)，不能防止主动攻击(中间人攻击)。
发明内容
为解决上述技术问题，本申请实施例提供了一种密钥生成方法、终端设备、网络设备以及计算机存储介质。
第一方面，提供了一种密钥生成方法，应用于终端设备，所述方法包括：
基于长期密钥，确定第一密钥；
基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述 本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥均为对称密钥。
第二方面，提供了一种密钥生成方法，应用于网络设备，所述方法包括：
基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；
基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
第三方面，提供了一种终端设备，包括：
第一密钥生成单元，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
第一通信单元，用于基于所述本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
第四方面，提供了一种终端设备，包括：
第一处理器，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
第一通信接口，用于基于所述本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及 所述至少一个附加密钥为对称密钥。
第五方面，提供了一种网络设备，包括：
第二密钥生成单元，用于基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
第二通信单元，用于基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
第六方面，提供了一种网络设备，包括：
第二处理器，用于基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
第二通信接口，用于基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
第七方面，提供了一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现前述方法的步骤
第七方面，提供了一种密钥生成***，所述***包括：至少一个终端设备、鉴权服务功能AUSF实体；其中，
所述终端设备，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；
所述AUSF实体，用于基于所述终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥， 生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
本申请实施例的技术方案，就能够在生成最终的会话密钥的时候，除了根据长期密钥之外，还可以利用终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥，共同进行本次会话密钥的生成；如此，不需要对原有的认证协议做大的改动就可实现会话密钥的安全性增强。并且，采用对称密钥算法对设备的运算要求很低，进而消耗的功耗也较低，因此，更加适合在物联网场景下使用。
附图说明
图1是本申请实施例提供的一种密钥生成方法流程示意性图1；
图2是本申请实施例提供的一种密钥生成方法流程示意性图2；
图3为本申请实施例提供的一种密钥生成方法流程示意图3；
图4为本申请实施例提供的一种终端设备组成结构示意图1；
图5为本申请实施例提供的一种终端设备组成结构示意图2；
图6为本申请实施例提供的一种网络设备组成结构示意图1；
图7为本申请实施例提供的一种网络设备组成结构示意图2；
图8为本申请实施例提供的一种***组成结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
如图1所示，本申请实施例提供了一种密钥生成方法，应用于终端设备，所述方法包括：
步骤101：基于长期密钥，确定第一密钥；
步骤102：基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
本实施例提供了多种具体处理场景，下面分别进行说明：
场景1、采用初始会话密钥以及第一密钥生成本次会话密钥，说明如下：
所述基于长期密钥，确定第一密钥之前，所述方法还包括：当初次连接网络，完成与鉴权服务功能之间的相互认证时，生成初始会话密钥。
即终端设备第一次连接网络，完成与鉴权服务功能(AUSF，Authentication Server Function)间的相互认证，生成第一密钥，可以记为KSEAF_first；
后续所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥。
也就是说，终端设备与AUSF完成相互认证后，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，再加上第一个初始会话密钥KSEAF_first。
终端设备第一次连接网络，完成与AUSF间的相互认证，生成第一个会话密钥KSEAF_first.后续终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上第一个会话密钥KSEAF_first。
参见图2，此方案的步骤如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定 使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和网络侧的AUSF都获得基于长期密钥K而推导出的第一密钥，可以表示为KSEAF。
最后，终端设备和AUSF分别使用第一密钥KSEAF和存储在安全区域的初始会话密钥KSEAF_frist，生成本次会话密钥KSEAF*。其计算可以如下表示：
KSEAF*＝KDF(KSEAF，KSEAF_frist,AP)；
其中，KDF表征密钥推演函数，如HMAC-SHA-256；AP是辅助参数用于辅助功能，如防止bidding down攻击，需要理解的是，AP是可选参数，可以不使用也可以使用，因此AP也可能不出现在公式里。
其中，初始会话密钥可以分别在终端设备以及网络侧的AUSF中进行保存，具体来说，终端设备侧：存储在USIM或信息不可篡改的存储区域；AUSF存储在信息不可篡改的存储区域。
需要说明的是，终端设备与网络侧进行初次连接的时候，并进行初次认证的时候，初始会话密钥可以设置为空，即与用户第一次认证时，KSEAF_frist＝null.。网络与用户第一次认证后，生成的第一个会话密钥KSEAF*设为初始会话密钥KSEAF_first，并长期存储在终端设备和AUSF。
关于5G AKA或EAP-AKA’：前者是基于LTE的认证协议EPS-AKA 发展而来，而后者是一个IETF定义的认证协议用于4G网络中UE使用WIFI接入运营商网络。在5G中，UE基于EAP-AKA′不仅能通过WIFI接入运营商网络，而且通过5G无线接入网也能接入运营商网络。
AKA认证协议依靠存储在USIM中的根密钥K实现UE和网络之间的相互认证，并导出会话密钥。安全的假设条件是根密钥K除了网络运营商外，别人都不知道,从而攻击者也无法推导出会话密钥。然而，报告[1]表明，这种假设并不总是正确的，因为根密钥K可能在USIM卡的生产阶段就已被泄露。因此，被动攻击者可以使用从根密钥K，以及UE和网络之间交换消息而衍生的会话密钥来窃听通信。一个主动攻击者可能会利用偷来的大量根密钥伪造基站而发起中间人攻击。长期密钥泄密已经在TR33.899中的5.2.3.2节被认为是一个关键问题。5G-AKA和EAP-AKA′都会受到长期密钥泄露的威胁，因为它们都是基于AKA认证协议扩展而来的。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于根密钥K而生成的密钥KSEAF，还依赖于第一个会话密钥KSEAF_first。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得第一个会话密钥KSEAF_first，这是比较低的概率。
场景2、基于上一次通信的会话密钥，生成本次会话密钥，说明如下：
所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：
基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
即终端设备与AUSF完成相互认证后，最终本次会话密钥KSEAF*的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥KSEAF_pre。
终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥 KSEAF_pre。
同样可以参见图2，具体如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和AUSF都获得基于长期密钥K而推导出的会话密钥KSEAF。
终端设备和AUSF分别使用KSEAF和存储在安全区域的KSEAF_pre生成最终会话密钥KSEAF*，其计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_pre,AP)
其中，KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。
需要指出的是，网络与用户第一次认证时，上一次通信使用的会话密钥可以设置为空，比如KSEAF_pre＝null。终端设备和网络生成本次会话密钥KSEAF*后，会用它替换存储在终端设备和网络中的上一次通信使用的会话密钥KSEAF_pre。也就是说，本次会话密钥在生成之后，可以分别在终端设备以及网络侧进行存储，并且，替换上一次通信使用的会话密钥进行存储，进而，在下一次再次生成会话密钥的时候，采用替换后的上一次 通信使用的会话密钥进行下一次会话密钥的生成，其处理方式与本场景上述说明是相同的，因此不再赘述。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于长期密钥K而生成的密钥KSEAF，还依赖于上次存储的会话密钥KSEAF_pre。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得上次存储的会话密钥KSEAF_pre。这要求攻击攻击者能持续的获得上次存储的会话密钥KSEAF_pre，才能持续获得最终会话密钥。
场景3、基于初始会话密钥、以及上一次通信使用的会话密钥，共同生成本次会话密钥；具体说明如下：
所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：
基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
也就是说，本场景基于场景1、2，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。
关于初始会话密钥以及上一次通信使用的会话密钥的生成以及保存与场景1、2相同，这里不做赘述。
与场景1、2不同之处在于，本场景中，进行会话密钥的生成时，除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。最终会话密钥KSEAF*的计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_frist,KSEAF_pre，AP)
这里KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。需要指出的是，网络与用户第一次认证时，KSEAF_pre＝null， KSEAF_frist＝null。
本场景3的安全性比场景1、2更高，因为在此方案中，攻击者要获得最终会话密钥，既需要能获得第一个会话密钥，又需要能持续获得上次存储的会话密钥KSEAF_pre。
最后需要指出的是，本实施例提供的场景都只使用对称密钥算法(密钥推演算法)。
可见，通过采用上述方案，就能够在生成最终的会话密钥的时候，除了根据长期密钥之外，还可以利用终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥，共同进行本次会话密钥的生成；如此，不需要对原有的认证协议做大的改动就可实现会话密钥的安全性增强。并且，采用对称密钥算法对设备的运算要求很低，进而消耗的功耗也较低，因此，更加适合在物联网场景下使用。
如图3所示，本申请实施例提供了一种密钥生成方法，应用于网络设备，所述方法包括：
步骤301：基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；
步骤302：基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
本实施例中所涉及的网络设备，可以认为是网络侧具备AUSF功能的设备。
本实施例提供了多种具体处理场景，下面分别进行说明：
场景1、采用初始会话密钥以及第一密钥生成本次会话密钥，说明如下：
所述基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥之前，所述方法还包括：
当所述终端设备初次连接网络，完成与鉴权服务功能之间的相互认证时，生成网络侧与所述终端设备通信所使用的初始会话密钥。
即终端设备第一次连接网络，完成与鉴权服务功能(AUSF，Authentication Server Function)间的相互认证，生成第一密钥，可以记为KSEAF_first；
所述基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，包括：
基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成所述终端设备的本次会话密钥。
也就是说，终端设备与AUSF完成相互认证后，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，再加上第一个初始会话密钥KSEAF_first。
终端设备第一次连接网络，完成与AUSF间的相互认证，生成第一个会话密钥KSEAF_first.后续终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上第一个会话密钥KSEAF_first。
参见图2，此方案的步骤如下：
网络侧的UDM对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由 UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和网络侧的网络设备，如AUSF都获得基于长期密钥K而推导出的第一密钥，可以表示为KSEAF。
最后，终端设备和AUSF分别使用第一密钥KSEAF和存储在安全区域的初始会话密钥KSEAF_frist，生成本次会话密钥KSEAF*。其计算可以如下表示：
KSEAF*＝KDF(KSEAF，KSEAF_frist,AP)；
其中，KDF表征密钥推演函数，如HMAC-SHA-256；AP是辅助参数用于辅助功能，如防止bidding down攻击，需要理解的是，AP是可选参数，可以不使用也可以使用，因此AP也可能不出现在公式里。
其中，初始会话密钥可以分别在终端设备以及网络侧的AUSF中进行保存，具体来说，终端设备侧：存储在USIM或信息不可篡改的存储区域；AUSF存储在信息不可篡改的存储区域。
需要说明的是，终端设备与网络侧进行初次连接的时候，并进行初次认证的时候，初始会话密钥可以设置为空，即与用户第一次认证时，KSEAF_frist＝null.。网络与用户第一次认证后，生成的第一个会话密钥KSEAF*设为初始会话密钥KSEAF_first，并长期存储在终端设备和AUSF。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于根密钥K而生成的密钥KSEAF，还依赖于第一个会话密钥KSEAF_first。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得第一个会话密钥KSEAF_first，这是比较低的概率。
场景2、基于上一次通信的会话密钥，生成本次会话密钥，说明如下：
所述基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所 对应的本次会话密钥，包括：
基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
即终端设备与AUSF完成相互认证后，最终本次会话密钥KSEAF*的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上终端以及网络设备均存储的上次与终端设备进行通信时生成的会话密钥KSEAF_pre。
终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥KSEAF_pre。
同样可以参见图2，具体如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和AUSF都获得基于长期密钥K而推导出的会话密钥KSEAF。
终端设备和AUSF分别使用KSEAF和存储在安全区域的KSEAF_pre生成最终会话密钥KSEAF*，其计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_pre,AP)
其中，KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用 于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。
需要指出的是，网络与用户第一次认证时，上一次通信使用的会话密钥可以设置为空，比如KSEAF_pre＝null。终端设备和网络生成本次会话密钥KSEAF*后，会用它替换存储在终端设备和网络中的上一次通信使用的会话密钥KSEAF_pre。也就是说，本次会话密钥在生成之后，可以分别在终端设备以及网络侧进行存储，并且，替换上一次通信使用的会话密钥进行存储，进而，在下一次再次生成会话密钥的时候，采用替换后的上一次通信使用的会话密钥进行下一次会话密钥的生成，其处理方式与本场景上述说明是相同的，因此不再赘述。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于长期密钥K而生成的密钥KSEAF，还依赖于上次存储的会话密钥KSEAF_pre。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得上次存储的会话密钥KSEAF_pre。这要求攻击攻击者能持续的获得上次存储的会话密钥KSEAF_pre，才能持续获得最终会话密钥。
场景3、基于初始会话密钥、以及上一次通信使用的会话密钥，共同生成本次会话密钥；具体说明如下：
基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
也就是说，本场景基于场景1、2，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。
关于初始会话密钥以及上一次通信使用的会话密钥的生成以及保存于场景1、2相同，这里不做赘述。
与场景1、2不同之处在于，本场景中，进行会话密钥的生成时，除了 使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。最终会话密钥KSEAF*的计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_frist,KSEAF_pre，AP)
这里KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。需要指出的是，网络与用户第一次认证时，KSEAF_pre＝null，KSEAF_frist＝null。
本场景3的安全性比场景1、2更高，因为在此方案中，攻击者要获得最终会话密钥，既需要能获得第一个会话密钥，又需要能持续获得上次存储的会话密钥KSEAF_pre。
最后需要指出的是，本实施例提供的场景都只使用对称密钥算法(密钥推演算法)。采用对称密钥算法对设备的运算要求很低，进而消耗的功耗也很低。因此，更加适合在物联网场景下使用。
可见，通过采用上述方案，就能够在生成最终的会话密钥的时候，除了根据长期密钥之外，还可以利用终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥，共同进行本次会话密钥的生成；如此，不需要对原有的认证协议做大的改动就可实现会话密钥的安全性增强。
如图4所示，本申请实施例提供了一种终端设备，包括：
第一密钥生成单元41，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
第一通信单元42，用于基于所述本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
如图5所示，本申请实施例提供了一种终端设备，包括：
第一处理器51，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
第一通信接口52，用于基于所述本次会话密钥与网络侧进行通信；
其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
本实施例提供了多种具体处理场景，下面分别进行说明：
场景1、采用初始会话密钥以及第一密钥生成本次会话密钥，说明如下：
所述第一处理器51，用于当初次连接网络，完成与鉴权服务功能之间的相互认证时，生成初始会话密钥。
即终端设备第一次连接网络，完成与鉴权服务功能(AUSF，Authentication Server Function)间的相互认证，生成第一密钥，可以记为KSEAF_first；
后续第一处理器51，用于基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥。
也就是说，终端设备与AUSF完成相互认证后，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，再加上第一个初始会话密钥KSEAF_first。
终端设备第一次连接网络，完成与AUSF间的相互认证，生成第一个会话密钥KSEAF_first.后续终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上第一个会话密钥KSEAF_first。
参见图2，此方案的步骤如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G  AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和网络侧的AUSF都获得基于长期密钥K而推导出的第一密钥，可以表示为KSEAF。
最后，终端设备和AUSF分别使用第一密钥KSEAF和存储在安全区域的初始会话密钥KSEAF_frist，生成本次会话密钥KSEAF*。其计算可以如下表示：
KSEAF*＝KDF(KSEAF，KSEAF_frist,AP)；
其中，KDF表征密钥推演函数，如HMAC-SHA-256；AP是辅助参数用于辅助功能，如防止bidding down攻击，需要理解的是，AP是可选参数，可以不使用也可以使用，因此AP也可能不出现在公式里。
其中，初始会话密钥可以分别在终端设备以及网络侧的AUSF中进行保存，具体来说，终端设备侧：存储在USIM或信息不可篡改的存储区域；AUSF存储在信息不可篡改的存储区域。
需要说明的是，终端设备与网络侧进行初次连接的时候，并进行初次认证的时候，初始会话密钥可以设置为空，即与用户第一次认证时，KSEAF_frist＝null.。网络与用户第一次认证后，生成的第一个会话密钥KSEAF*设为初始会话密钥KSEAF_first，并长期存储在终端设备和AUSF。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于根密钥K而生成的密钥KSEAF，还依赖于第一个会话密钥 KSEAF_first。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得第一个会话密钥KSEAF_first，这是比较低的概率。
场景2、基于上一次通信的会话密钥，生成本次会话密钥，说明如下：
所述第一处理器51，用于基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
即终端设备与AUSF完成相互认证后，最终本次会话密钥KSEAF*的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥KSEAF_pre。
终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥KSEAF_pre。
同样可以参见图2，具体如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和AUSF都获得基于长期密钥K而推导出的会话密钥KSEAF。
终端设备和AUSF分别使用KSEAF和存储在安全区域的KSEAF_pre生成最终会话密钥KSEAF*，其计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_pre,AP)
其中，KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。
需要指出的是，网络与用户第一次认证时，上一次通信使用的会话密钥可以设置为空，比如KSEAF_pre＝null。终端设备和网络生成本次会话密钥KSEAF*后，会用它替换存储在终端设备和网络中的上一次通信使用的会话密钥KSEAF_pre。也就是说，本次会话密钥在生成之后，可以分别在终端设备以及网络侧进行存储，并且，替换上一次通信使用的会话密钥进行存储，进而，在下一次再次生成会话密钥的时候，采用替换后的上一次通信使用的会话密钥进行下一次会话密钥的生成，其处理方式与本场景上述说明是相同的，因此不再赘述。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于长期密钥K而生成的密钥KSEAF，还依赖于上次存储的会话密钥KSEAF_pre。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得上次存储的会话密钥KSEAF_pre。这要求攻击攻击者能持续的获得上次存储的会话密钥KSEAF_pre，才能持续获得最终会话密钥。
场景3、基于初始会话密钥、以及上一次通信使用的会话密钥，共同生成本次会话密钥；具体说明如下：
所述第一处理器51，用于基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
也就是说，本场景基于场景1、2，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。
关于初始会话密钥以及上一次通信使用的会话密钥的生成以及保存于场景1、2相同，这里不做赘述。
与场景1、2不同之处在于，本场景中，进行会话密钥的生成时，除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。最终会话密钥KSEAF*的计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_frist,KSEAF_pre，AP)
这里KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。需要指出的是，网络与用户第一次认证时，KSEAF_pre＝null，KSEAF_frist＝null。
本场景3的安全性比场景1、2更高，因为在此方案中，攻击者要获得最终会话密钥，既需要能获得第一个会话密钥，又需要能持续获得上次存储的会话密钥KSEAF_pre。
最后需要指出的是，本实施例提供的场景都只使用对称密钥算法(密钥推演算法)。采用对称密钥算法对设备的运算要求很低，进而消耗的功耗也很低。因此，更加适合在物联网场景下使用。
可见，通过采用上述方案，就能够在生成最终的会话密钥的时候，除了根据长期密钥之外，还可以利用终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥，共同进行本次会话密钥的生成；如此，不需要对原有的认证协议做大的改动就可实现会话密钥的安全性增强。
如图6所示，本申请实施例提供了一种网络设备，所述方法包括：
第二密钥生成单元61，用于基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
第二通信单元62，用于基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
如图7所示，本申请实施例提供了一种网络设备，所述方法包括：
第二处理器71，用于基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
第二通信接口72，用于基于所述本次会话密钥与所述终端设备进行通信；
其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
本实施例中所涉及的网络设备，可以认为是网络侧具备AUSF功能的设备。
本实施例提供了多种具体处理场景，下面分别进行说明：
场景1、采用初始会话密钥以及第一密钥生成本次会话密钥，说明如下：
所述第二处理器71，用于当所述终端设备初次连接网络，完成与鉴权服务功能之间的相互认证时，生成网络侧与所述终端设备通信所使用的初始会话密钥。
即终端设备第一次连接网络，完成与鉴权服务功能(AUSF，Authentication Server Function)间的相互认证，生成第一密钥，可以记为KSEAF_first；
所述第二处理器71，用于基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成所述终端设备的本次会话密钥。
也就是说，终端设备与AUSF完成相互认证后，最终会话密钥KSEAF* 的生成除了使用长期密钥K推演出的第一密钥KSEAF外，再加上第一个初始会话密钥KSEAF_first。
终端设备第一次连接网络，完成与AUSF间的相互认证，生成第一个会话密钥KSEAF_first.后续终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上第一个会话密钥KSEAF_first。
参见图2，此方案的步骤如下：
网络侧的UDM对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和网络侧的网络设备，如AUSF都获得基于长期密钥K而推导出的第一密钥，可以表示为KSEAF。
最后，终端设备和AUSF分别使用第一密钥KSEAF和存储在安全区域的初始会话密钥KSEAF_frist，生成本次会话密钥KSEAF*。其计算可以如下表示：
KSEAF*＝KDF(KSEAF，KSEAF_frist,AP)；
其中，KDF表征密钥推演函数，如HMAC-SHA-256；AP是辅助参数用于辅助功能，如防止bidding down攻击，需要理解的是，AP是可选参数，可以不使用也可以使用，因此AP也可能不出现在公式里。
其中，初始会话密钥可以分别在终端设备以及网络侧的AUSF中进行保存，具体来说，终端设备侧：存储在USIM或信息不可篡改的存储区域；AUSF存储在信息不可篡改的存储区域。
需要说明的是，终端设备与网络侧进行初次连接的时候，并进行初次认证的时候，初始会话密钥可以设置为空，即与用户第一次认证时，KSEAF_frist＝null.。网络与用户第一次认证后，生成的第一个会话密钥KSEAF*设为初始会话密钥KSEAF_first，并长期存储在终端设备和AUSF。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于根密钥K而生成的密钥KSEAF，还依赖于第一个会话密钥KSEAF_first。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得第一个会话密钥KSEAF_first，这是比较低的概率。
场景2、基于上一次通信的会话密钥，生成本次会话密钥，说明如下：
所述第二处理器71，用于基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
即终端设备与AUSF完成相互认证后，最终本次会话密钥KSEAF*的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上终端以及网络设备均存储的上次与终端设备进行通信时生成的会话密钥KSEAF_pre。
终端设备与AUSF完成相互认证后，最终会话密钥的生成除了使用长期密钥K推演出的密钥KSEAF外，还要加上存储的上次生成的会话密钥KSEAF_pre。
同样可以参见图2，具体如下：
网络侧对用户终端设备要进行次认证时，根据终端设备的Profile确定使用何种认证协议对终端设备进行认证；其中，所述认证协议可以为5G AKA或EAP-AKA’，当然，认证协议还可以有其他的协议，只是本实施例中并不做穷举。另外，关于用户的终端设备的相关信息profile，可以在 终端设备与网络侧进行签约的时候，写入统一数据管理(UDM，Unified Data Management)中，然后当终端设备需要进行认证的时候，由UDM来确定终端设备采用哪种认证协议进行处理；
终端设备和网络侧使用选定的认证协议进行相互认证；比如，具体的可以为终端设备，比如UE，与UDM/ARPF之间通过选定的认证协议，相互认证。
认证结束后，终端设备和AUSF都获得基于长期密钥K而推导出的会话密钥KSEAF。
终端设备和AUSF分别使用KSEAF和存储在安全区域的KSEAF_pre生成最终会话密钥KSEAF*，其计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_pre,AP)
其中，KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。
需要指出的是，网络与用户第一次认证时，上一次通信使用的会话密钥可以设置为空，比如KSEAF_pre＝null。终端设备和网络生成本次会话密钥KSEAF*后，会用它替换存储在终端设备和网络中的上一次通信使用的会话密钥KSEAF_pre。也就是说，本次会话密钥在生成之后，可以分别在终端设备以及网络侧进行存储，并且，替换上一次通信使用的会话密钥进行存储，进而，在下一次再次生成会话密钥的时候，采用替换后的上一次通信使用的会话密钥进行下一次会话密钥的生成，其处理方式与本场景上述说明是相同的，因此不再赘述。
如此，能保证最终会话密钥KSEAF*的安全性，因它的生成除了依赖于基于长期密钥K而生成的密钥KSEAF，还依赖于上次存储的会话密钥KSEAF_pre。攻击者无法获得最终会话密钥KSEAF*，除非攻击者能获得上次存储的会话密钥KSEAF_pre。这要求攻击攻击者能持续的获得上次存储 的会话密钥KSEAF_pre，才能持续获得最终会话密钥。
场景3、基于初始会话密钥、以及上一次通信使用的会话密钥，共同生成本次会话密钥；具体说明如下：
第二处理器71，用于基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
也就是说，本场景基于场景1、2，最终会话密钥KSEAF*的生成除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。
关于初始会话密钥以及上一次通信使用的会话密钥的生成以及保存于场景1、2相同，这里不做赘述。
与场景1、2不同之处在于，本场景中，进行会话密钥的生成时，除了使用长期密钥K推演出的第一密钥KSEAF外，还要使用初始会话密钥KSEAF_first和上次生成的会话密钥KSEAF_pre。最终会话密钥KSEAF*的计算如下：
KSEAF*＝KDF(KSEAF，KSEAF_frist,KSEAF_pre，AP)
这里KDF是密钥推演函数，如HMAC-SHA-256，AP是辅助参数用于辅助功能，如防止bidding down攻击，AP是可选参数，也可能不出现在公式里。需要指出的是，网络与用户第一次认证时，KSEAF_pre＝null，KSEAF_frist＝null。
本场景3的安全性比场景1、2更高，因为在此方案中，攻击者要获得最终会话密钥，既需要能获得第一个会话密钥，又需要能持续获得上次存储的会话密钥KSEAF_pre。
最后需要指出的是，本实施例提供的场景都只使用对称密钥算法(密钥推演算法)。采用对称密钥算法对设备的运算要求很低，进而消耗的功耗也很低。因此，更加适合在物联网场景下使用。
可见，通过采用上述方案，就能够在生成最终的会话密钥的时候，除了根据长期密钥之外，还可以利用终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥，共同进行本次会话密钥的生成；如此，不需要对原有的认证协议做大的改动就可实现会话密钥的安全性增强。
本申请实施例还提供了一种计算机可读存储介质，用于存储计算机程序。
可选的，该计算机可读存储介质可应用于本申请实施例中的任意一种网络设备，并且该计算机程序使得计算机执行本申请实施例的各个方法中由网络设备实现的相应流程，为了简洁，在此不再赘述。
本申请实施例还提供了一种密钥生成***，如图8所示，所述***包括：至少一个终端设备81、鉴权服务功能AUSF实体82；其中，
所述终端设备81，用于基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；
所述AUSF实体82，用于基于所述终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
所述***还包括：统一数据管理UDM实体83，用于当终端设备初次连接网络时，完成与所述终端设备之间的认证；
所述终端设备，用于当初次连接网络与UDM实体完成认证，生成初始 会话密钥并保存。
所述终端设备，用于基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥；
所述AUSF实体，用于基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
所述终端设备，用于基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥；
所述AUSF实体，用于基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
所述终端设备，用于基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥；
所述AUSF实体，用于基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
另外，本***中各个设备中具备的功能与前述方法或装置实施例相同，因此不再进行赘述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***、装置和单元的具体工作过程，可以参考前述方法实施例中的 对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的***、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个***，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，)ROM、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可 轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (29)

  1. 一种密钥生成方法，应用于终端设备，所述方法包括：
    基于长期密钥，确定第一密钥；
    基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；
    其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥均为对称密钥。
  2. 根据权利要求1所述的方法，其中，所述基于长期密钥，确定第一密钥之前，所述方法还包括：
    当初次连接网络，完成与网络侧的相互认证，生成初始会话密钥。
  3. 根据权利要求2所述的方法，其中，所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：
    基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥。
  4. 根据权利要求1所述的方法，其中，所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：
    基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
  5. 根据权利要求1或2所述的方法，其中，所述基于第一密钥、以及至少一个附加密钥，生成本次会话密钥，包括：
    基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
  6. 一种密钥生成方法，应用于网络设备，所述方法包括：
    基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；
    基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；
    其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  7. 根据权利要求6所述的方法，其中，所述基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥之前，所述方法还包括：
    当所述终端设备初次连接网络完成与网络之间的相互认证后，生成所述终端设备对应的初始会话密钥。
  8. 根据权利要求7所述的方法，其中，所述基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，包括：
    基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  9. 根据权利要求6所述的方法，其中，所述基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，包括：
    基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  10. 根据权利要求7所述的方法，其中，所述基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，包括：
    基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  11. 一种终端设备，包括：
    第一密钥生成单元，配置为基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
    第一通信单元，配置为基于所述本次会话密钥与网络侧进行通信；
    其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  12. 一种终端设备，包括：
    第一处理器，配置为基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥；
    第一通信接口，配置为基于所述本次会话密钥与网络侧进行通信；
    其中，所述至少一个附加密钥中包括：终端设备初次连接网络时生成的初始会话密钥，和/或，上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  13. 根据权利要求12所述的终端设备，其中，所述第一处理器，配置为当初次连接网络，完成与网络之间的相互认证，生成初始会话密钥。
  14. 根据权利要求13所述的终端设备，其中，所述第一处理器，配置为基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥。
  15. 根据权利要求12所述的终端设备，其中，所述第一处理器，配置为基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
  16. 根据权利要求12或13所述的终端设备，其中，所述第一处理器，配置为基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥。
  17. 一种网络设备，包括：
    第二密钥生成单元，配置为基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
    第二通信单元，配置为基于所述本次会话密钥与所述终端设备进行通 信；
    其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  18. 一种网络设备，包括：
    第二处理器，配置为基于终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥；
    第二通信接口，配置为基于所述本次会话密钥与所述终端设备进行通信；
    其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  19. 根据权利要求18所述的网络设备，其中，所述第二处理器，配置为当所述终端设备初次连接网络，完成与网络之间的相互认证后，生成所述终端设备对应的初始会话密钥。
  20. 根据权利要求19所述的网络设备，其中，所述第二处理器，配置为基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  21. 根据权利要求18所述的网络设备，其中，所述第二处理器，配置为基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  22. 根据权利要求19所述的网络设备，其中，所述第二处理器，配置为基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端 设备通信所使用的本次会话密钥。
  23. 一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现权利要求1-5任一项所述方法的步骤。
  24. 一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现权利要求6-10任一项所述方法的步骤。
  25. 一种密钥生成***，所述***包括：至少一个终端设备、鉴权服务功能AUSF实体；其中，
    所述终端设备，配置为基于长期密钥，确定第一密钥；基于第一密钥以及至少一个附加密钥，生成本次会话密钥，基于所述本次会话密钥与网络侧进行通信；
    所述AUSF实体，配置为基于所述终端设备所对应的长期密钥，确定所述终端设备所对应的第一密钥；基于所述第一密钥以及至少一个附加密钥，生成所述终端设备所对应的本次会话密钥，基于所述本次会话密钥与所述终端设备进行通信；其中，所述至少一个附加密钥中包括：所述终端设备初次连接网络时生成的初始会话密钥，和/或，与所述终端设备上一次通信使用的会话密钥；所述第一密钥以及所述至少一个附加密钥为对称密钥。
  26. 根据权利要求25所述的***，其中，所述***还包括：统一数据管理UDM实体，配置为当终端设备初次连接网络时，完成与所述终端设备之间的认证；
    所述终端设备，配置为当初次连接网络与UDM实体完成认证，生成初始会话密钥并保存。
  27. 根据权利要求26所述的***，其中，所述终端设备，配置为基于所述第一密钥、以及所述初始会话密钥，生成本次会话密钥；
    所述AUSF实体，配置为基于所述终端设备所对应的第一密钥、以及所述终端设备初次连接网络时生成的初始会话密钥，生成网络侧与所述终 端设备通信所使用的本次会话密钥。
  28. 根据权利要求25所述的***，其中，所述终端设备，配置为基于所述第一密钥、以及上一次通信使用的会话密钥，生成本次会话密钥；
    所述AUSF实体，配置为基于所述第一密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
  29. 根据权利要求25或26所述的***，其中，所述终端设备，配置为基于所述第一密钥、初始会话密钥、以及上一次通信使用的会话密钥，生成本次会话密钥；
    所述AUSF实体，配置为基于所述第一密钥、所述终端设备初次连接网络时生成的初始会话密钥、以及与所述终端设备上一次通信使用的会话密钥，生成网络侧与所述终端设备通信所使用的本次会话密钥。
PCT/CN2020/070036 2019-01-02 2020-01-02 一种密钥生成方法、终端设备及网络设备 WO2020140926A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US17/420,534 US20220085990A1 (en) 2019-01-02 2020-01-02 Key generation method, terminal device and network device
AU2020204946A AU2020204946B2 (en) 2019-01-02 2020-01-02 Key generation method, terminal device and network device
CA3125583A CA3125583C (en) 2019-01-02 2020-01-02 Key generation method, terminal device and network device
JP2021538677A JP7329604B2 (ja) 2019-01-02 2020-01-02 鍵生成方法、端末機器及びネットワーク機器
EP20735916.7A EP3905585B1 (en) 2019-01-02 2020-01-02 Key generation method, terminal device and network device
SG11202107340QA SG11202107340QA (en) 2019-01-02 2020-01-02 Key generation method, terminal device and network device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910000352.XA CN111404666B (zh) 2019-01-02 2019-01-02 一种密钥生成方法、终端设备及网络设备
CN201910000352.X 2019-01-02

Publications (1)

Publication Number Publication Date
WO2020140926A1 true WO2020140926A1 (zh) 2020-07-09

Family

ID=71407260

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/070036 WO2020140926A1 (zh) 2019-01-02 2020-01-02 一种密钥生成方法、终端设备及网络设备

Country Status (8)

Country Link
US (1) US20220085990A1 (zh)
EP (1) EP3905585B1 (zh)
JP (1) JP7329604B2 (zh)
CN (1) CN111404666B (zh)
AU (1) AU2020204946B2 (zh)
CA (1) CA3125583C (zh)
SG (1) SG11202107340QA (zh)
WO (1) WO2020140926A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113141327B (zh) * 2020-01-02 2023-05-09 ***通信有限公司研究院 一种信息处理方法、装置及设备
CN115379445B (zh) * 2022-08-23 2024-05-14 中国联合网络通信集团有限公司 一种密钥派生方法及装置、网络设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1532726A (zh) * 2003-03-19 2004-09-29 大唐微电子技术有限公司 一种获得数字签名和实现数据安全的方法
US20120011362A1 (en) * 2010-07-08 2012-01-12 Certicom Corp. System and Method for Performing Device Authentication Using Key Agreement
CN104618380A (zh) * 2015-02-03 2015-05-13 浙江师范大学 一种适用于物联网的密钥更新方法
CN105530687A (zh) * 2016-02-04 2016-04-27 中国联合网络通信集团有限公司 一种无线网络接入控制方法及接入设备

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4604418B2 (ja) * 2001-07-26 2011-01-05 パナソニック株式会社 通信装置および通信方法
US7475241B2 (en) * 2002-11-22 2009-01-06 Cisco Technology, Inc. Methods and apparatus for dynamic session key generation and rekeying in mobile IP
WO2004084458A2 (en) * 2003-03-14 2004-09-30 Thomson Licensing S.A. Wlan session management techniques with secure rekeying and logoff
KR100770928B1 (ko) * 2005-07-02 2007-10-26 삼성전자주식회사 통신 시스템에서 인증 시스템 및 방법
CN1941695B (zh) * 2005-09-29 2011-12-21 华为技术有限公司 初始接入网络过程的密钥生成和分发的方法及***
JP2007110487A (ja) * 2005-10-14 2007-04-26 Oki Electric Ind Co Ltd Ｌａｎシステムおよびその通信方法
US8107397B1 (en) * 2006-06-05 2012-01-31 Purdue Research Foundation Protocol for secure and energy-efficient reprogramming of wireless multi-hop sensor networks
EP2559275A1 (en) * 2010-04-16 2013-02-20 Qualcomm Incorporated Apparatus and method for transitioning enhanced security context from a utran-based serving network to a geran-based serving network
EP2785010A1 (en) * 2013-03-28 2014-10-01 Astrium Limited Key distribution in a satellite system
CN103457722B (zh) * 2013-08-11 2017-02-08 吉林大学 一种基于Shamir门限的提供双向身份认证和数据安全传输的体域网安全方法
US9515823B2 (en) * 2013-08-30 2016-12-06 L-3 Communications Corporation Cryptographic device with detachable data planes
US9432345B2 (en) * 2014-05-16 2016-08-30 Lattice Semiconductor Corporation Authentication engine and stream cipher engine sharing in digital content protection architectures
EP3876573B1 (en) * 2015-02-27 2022-09-07 Telefonaktiebolaget LM Ericsson (publ) Security arrangements in communication between a communication device and a network device
EP3086585B1 (en) * 2015-04-23 2019-12-11 Nxp B.V. Method and system for securing data communicated in a network
US9883385B2 (en) * 2015-09-15 2018-01-30 Qualcomm Incorporated Apparatus and method for mobility procedure involving mobility management entity relocation
US9801060B2 (en) * 2015-11-05 2017-10-24 Intel Corporation Secure wireless low-power wake-up
SG10201509342WA (en) * 2015-11-12 2017-06-29 Huawei Int Pte Ltd Method and system for session key generation with diffie-hellman procedure
GB2547676B (en) * 2016-02-25 2018-03-21 Arm Ip Ltd Methods and resources for generating secure communications
WO2018002856A1 (en) * 2016-06-28 2018-01-04 Verimatrix Gmbh Systems and methods for authenticating communications using a single message exchange and symmetric key
CN107820239B (zh) * 2016-09-12 2021-11-19 ***通信有限公司研究院 信息处理方法及装置
CN106888092B (zh) * 2016-09-12 2019-06-25 ***通信有限公司研究院 信息处理方法及装置
WO2018053271A1 (en) * 2016-09-16 2018-03-22 Idac Holdings, Inc. Unified authentication framework
CN108809903B (zh) * 2017-05-02 2021-08-10 ***通信有限公司研究院 一种认证方法、装置及***
CN108809635B (zh) * 2017-05-05 2024-07-09 华为技术有限公司 锚密钥生成方法、设备以及***
CN107920350B (zh) * 2017-11-13 2020-12-29 西安电子科技大学 一种基于sdn的隐私保护切换认证方法、5g异构网络

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1532726A (zh) * 2003-03-19 2004-09-29 大唐微电子技术有限公司 一种获得数字签名和实现数据安全的方法
US20120011362A1 (en) * 2010-07-08 2012-01-12 Certicom Corp. System and Method for Performing Device Authentication Using Key Agreement
CN104618380A (zh) * 2015-02-03 2015-05-13 浙江师范大学 一种适用于物联网的密钥更新方法
CN105530687A (zh) * 2016-02-04 2016-04-27 中国联合网络通信集团有限公司 一种无线网络接入控制方法及接入设备

Also Published As

Publication number Publication date
CN111404666A (zh) 2020-07-10
EP3905585A4 (en) 2022-01-26
SG11202107340QA (en) 2021-08-30
CN111404666B (zh) 2024-07-05
EP3905585A1 (en) 2021-11-03
US20220085990A1 (en) 2022-03-17
CA3125583C (en) 2024-05-28
AU2020204946B2 (en) 2023-04-06
AU2020204946A1 (en) 2021-08-19
JP2022516165A (ja) 2022-02-24
JP7329604B2 (ja) 2023-08-18
CA3125583A1 (en) 2020-07-09
EP3905585B1 (en) 2023-06-07

Similar Documents

Publication Publication Date Title
US9467432B2 (en) Method and device for generating local interface key
US11178584B2 (en) Access method, device and system for user equipment (UE)
Yang et al. Faster authenticated key agreement with perfect forward secrecy for industrial internet-of-things
Chen et al. Lightweight and provably secure user authentication with anonymity for the global mobility network
US7370350B1 (en) Method and apparatus for re-authenticating computing devices
US8312278B2 (en) Access authentication method applying to IBSS network
WO2021147997A1 (zh) 密钥生成方法及设备
CN110572800B (zh) 面向机器到机器环境下设备身份认证方法及装置
US20070124587A1 (en) Re-Keying in a Generic Bootstrapping Architecture Following Handover of a Mobile Terminal
CN110121196A (zh) 一种安全标识管理方法及装置
WO2020140926A1 (zh) 一种密钥生成方法、终端设备及网络设备
US9756504B2 (en) Security authentication method, device, and system
WO2020140929A1 (zh) 一种密钥生成方法、ue及网络设备
CN112235799B (zh) 终端设备入网鉴权方法及***
CN111404669A (zh) 一种密钥生成方法、终端设备及网络设备
TWI641271B (zh) 一種存取認證方法、ｕｅ和存取設備
CN109586913B (zh) 安全认证方法、安全认证装置、通信设备及存储介质
CN102833746B (zh) 用户重认证方法及接入控制器
CN111404667A (zh) 一种密钥生成方法、终端设备及网络设备
WO2019024937A1 (zh) 密钥协商方法、装置及***
US20240195639A1 (en) Digital-asset authentication with anonymity
US20220377061A1 (en) Accelerated Reconnection in Authenticated Networks
Zabihi et al. Improving security levels of IEEE 802.16 e authentication by Diffie-Hellman method
CN113141327A (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: 20735916

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021538677

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3125583

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020735916

Country of ref document: EP

Effective date: 20210728

ENP Entry into the national phase

Ref document number: 2020204946

Country of ref document: AU

Date of ref document: 20200102

Kind code of ref document: A