WO2019024937A1 - 密钥协商方法、装置及*** - Google Patents

密钥协商方法、装置及*** Download PDF

Info

Publication number
WO2019024937A1
WO2019024937A1 PCT/CN2018/098964 CN2018098964W WO2019024937A1 WO 2019024937 A1 WO2019024937 A1 WO 2019024937A1 CN 2018098964 W CN2018098964 W CN 2018098964W WO 2019024937 A1 WO2019024937 A1 WO 2019024937A1
Authority
WO
WIPO (PCT)
Prior art keywords
network element
key
eks
rand
res
Prior art date
Application number
PCT/CN2018/098964
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 中兴通讯股份有限公司
Publication of WO2019024937A1 publication Critical patent/WO2019024937A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • 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
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these

Definitions

  • the present disclosure relates to the field of communication technologies, for example, to a key agreement method, apparatus, and system.
  • the 3rd Generation Partnership Project (3GPP) proposes a mobile network authentication scheme.
  • the key agreement scheme between network elements is relatively simple.
  • the key negotiation scheme in the related technology only focuses on protecting the terminal and the terminal directly.
  • the communication protection between the visited networks if only the connection between the terminal and the visited network is emphasized, and the signaling connection between the home network and the visited network is basically in an unprotected state, the mobile network authentication process in the related art requires the home network.
  • the key used between the terminal and the visited network is transmitted to the visited network, which causes the key to be transmitted in plain text, resulting in leakage.
  • the embodiment of the present application provides a key negotiation method, device, and system, to at least solve the technical problem that the key security is poor through the plaintext transmission key in the related art.
  • the present application provides a key negotiation method, including: a first network element receives a second public key PubK2 and a random string RAND from a second network element; and the first network element generates a signaling key based on the PubK2 SK, and transmitting a response string RES to the second network element, wherein the RES is generated based on the RAND; the first network element receives an encrypted shared key EKs from the second network element, and is based on The SK and the EKs generate a shared key Ks.
  • the present application further provides another method for key agreement, comprising: receiving, by a second network element, a first public key PubK1 from a first network element, and generating a signaling key SK based on the PubK1; the second network element Sending a random string RAND to the first network element; the second network element receives a response string RES from the first network element, and sends an encrypted shared key EKs to the first network element, where The RES is generated based on the RAND, and the EKs are generated based on the SK and the shared key Ks.
  • the application further provides a key agreement apparatus, which is applied to the first network element, and includes: a transmission module, configured to receive a second public key PubK2 and a random string RAND from the second network element; and a generating module, configured to be based on The PubK2 generates a signaling key SK, and sends a response string RES to the second network element, where the RES is generated based on the RAND; and the processing module is configured to receive from the second network element
  • the shared key EKs is encrypted, and a shared key Ks is generated based on the SK and the EKs.
  • the present application further provides another key agreement apparatus, which is applied to the second network element, and includes: a receiving module, configured to receive the first public key PubK1 from the first network element, and generate a signaling key based on the PubK1 a sending module, configured to send a random string RAND to the first network element; the processing module is configured to receive a response string RES from the first network element, and send an encrypted share to the first network element A key EKs, wherein the RES is generated based on the RAND, the EKs being generated based on the SK and the shared key Ks.
  • the present application further provides a key agreement system, including a first network element, a second network element, and a third network element, where the first network element includes: a transmission module, configured to be to the second network element Transmitting a first public key PubK1, and receiving a second public key PubK2 and a random string RAND from the second network element; a generating module configured to generate a signaling key SK based on the PubK2, and to the second The network element sends a response string RES, wherein the RES is generated based on the RAND; the first processing module is configured to receive an encrypted shared key EKs from the second network element, and based on the SK and the The EKs generates a shared key Ks; the second network element includes: a first receiving module, configured to receive a first public key PubK1 from the first network element, and generate the SK based on the PubK1; and send a module, set to Transmitting the PubK2 to the first network element, and the RAND; the second processing module is configured
  • the application also provides a storage medium.
  • the storage medium is arranged to store program code for performing the following steps:
  • FIG. 1 is a flowchart of a key negotiation method according to an embodiment of the present application.
  • FIG. 2 is a flowchart of a key negotiation method according to another embodiment of the present application.
  • FIG. 3 is a flowchart of a key negotiation method according to another embodiment of the present application.
  • FIG. 5 is a structural block diagram of a key agreement apparatus according to an embodiment of the present application.
  • FIG. 6 is a structural block diagram of a key agreement apparatus according to another embodiment of the present application.
  • FIG. 7 is a structural block diagram of a key agreement system according to an embodiment of the present application.
  • FIG. 8 is a structural block diagram of a key agreement system according to another embodiment of the present application.
  • FIG. 9 is a schematic flowchart of a key network negotiation method based on a core network according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic flowchart of a core network-based key agreement method according to another embodiment of the present disclosure.
  • FIG. 1 is a flowchart of a key negotiation method according to an embodiment of the present application. As shown in FIG. 1, the key negotiation method provided in this embodiment includes the following steps.
  • Step 110 The first network element receives the public key PubK2 and the random string RAND from the second network element.
  • Step 120 The first network element generates a signaling key SK based on PubK2, and sends a response string RES to the second network element.
  • the RES is generated based on RAND.
  • Step 130 The first network element receives the encrypted shared key EKs from the second network element, and generates a shared key Ks based on the SK and the EKs.
  • the problem of poor key security caused by transmitting the shared key in plaintext is solved by negotiating and transmitting the encrypted shared key with the second network element.
  • FIG. 2 is a flowchart of a key negotiation method according to another embodiment of the present application. As shown in FIG. 2, the process includes the following steps.
  • Step 102 The first network element sends a first public key PubK1 to the second network element, and receives a second public key PubK2 and a random string RAND from the second network element.
  • Step 104 The first network element generates a signaling key SK based on PubK2, and sends a response string RES to the second network element.
  • Step 106 The first network element receives the shared key Ks from the second network element, or the first network element receives the encrypted shared key EKs from the second network element, and generates a shared key Ks based on the SK and the EKs.
  • the first network element and the second network element negotiate a transmission key, so that the signaling connection between the first network element and the second network element can be protected, thereby solving the related art, which causes the transmission key through the plaintext.
  • the technical problem of poor key security reduces the possibility of key compromise.
  • the first network element of the execution entity of the foregoing step may be a network element device, such as a visited network element, but is not limited thereto.
  • the implementation manner of acquiring Ks includes two types. First, the first network element receives the shared key Ks from the second network element. Second, in step 104, the first network element generates a signaling key based on PubK2. SK, the first network element receives the encrypted shared key EKs from the second network element, and generates a shared key Ks based on the SK and the EKs.
  • steps 104 and 106 are determined according to the above two implementations, and the execution order is interchangeable.
  • the method further includes: using the SK or the SK-derived key pair and the second network element by using the first network element
  • the data exchanged between network elements is confidential or integrity protected.
  • the method further includes: the first network element sends a RAND to the third network element; and the first network element receives the RES from the third network element.
  • the solution of the embodiment further includes: the first network element receives the token Token from the second network element; the first network element determines whether the Token is generated based on the Ks and the SK; the first network element determines based on the determination result The legality of SK or Ks.
  • the method further includes: the first network element sending the first check code MAC1 generated by the Ks to the third network element.
  • the solution of the embodiment further includes: the first network element receives the second check code MAC2 from the third network element; the first network element determines whether the MAC2 is generated based on the Ks; the first network element is based on the judgment result Determine the legality of SK or Ks. Determining legitimacy includes determining whether SK or Ks is correct, whether it was sent by the correct network element, or has been tampered with.
  • the solution of the embodiment further includes: the first network element receives the token Token from the second network element; the first network element determines whether the Token is generated based on the Ks and the SK; and the first network element performs the determination based on the judgment result. Or stop sending MAC1 to the third network element.
  • FIG. 3 is a flowchart of a key negotiation method according to another embodiment of the present application. As shown in FIG. 3, the key negotiation method provided in this embodiment includes the following steps.
  • Step 210 The second network element receives the public key PubK1 from the first network element, and generates a signaling key SK based on the PubK1.
  • Step 220 The second network element sends a random string RAND to the first network element.
  • Step 230 The second network element receives the response string RES from the first network element, and sends the encrypted shared key EKs to the first network element.
  • the RES is generated based on RAND, and the EKs are generated based on the SK and the shared key Ks.
  • the encrypted shared key is sent to the first network element, which solves the problem that the key security caused by transmitting the shared key in the plaintext is poor.
  • FIG. 4 is a flowchart of another key negotiation method provided in this embodiment. As shown in Figure 4, the process includes the following steps.
  • Step 202 The second network element receives the first public key PubK1 from the first network element, and generates a signaling key SK based on PubK1.
  • Step 204 The second network element sends a second public key PubK2 to the first network element, and a random string RAND.
  • Step 206 The second network element receives the response string RES from the first network element, and sends the shared key Ks or the encrypted shared key EKs to the first network element, where the EKs are generated based on the SK and the shared key Ks.
  • the second network element of the execution entity of the foregoing step may be a network element device, such as a home network element, but is not limited thereto.
  • the method further includes: using, by the second network element, the SK or the SK-derived key pair and the first The data exchanged between network elements is confidential or integrity protected.
  • the method further includes: determining, by the second network element, whether the RES is generated based on the RAND; and the second network element performing or stopping the operation of sending the Ks or the EKs to the first network element based on the determination result.
  • the method further includes:
  • the second network element receives the RAND from the third network element; the second network element sends the RES to the third network element.
  • the method further includes: the second network element receiving the Ks from the third network element.
  • the method further includes: the second network element receiving an indication from the third network element; and the second network element performing an operation of transmitting or stopping sending Ks or EKs to the first network element based on the indication.
  • the method further includes: the second network element sends a token Token to the first network element, wherein the Token is generated based on the SK and the Ks.
  • the first network element is a visited network element
  • the second network element is a home network element
  • the third network element is a terminal or a home network element.
  • the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the present application which is essential or contributes to the related art, may be embodied in the form of a software product stored in a storage medium (such as a read only memory (Read Only Memory, ROM)/Random Access Memory (RAM), disk, CD-ROM, including a plurality of instructions for causing a terminal device (such as a mobile phone, a computer, a server, or a network device) to perform any implementation of the present application.
  • a storage medium such as a read only memory (Read Only Memory, ROM)/Random Access Memory (RAM), disk, CD-ROM, including a plurality of instructions for causing a terminal device (such as a mobile phone, a computer, a server, or a network device) to perform any implementation of the present application.
  • a terminal device such as a mobile phone, a computer,
  • a key agreement device and a system are provided to implement the foregoing embodiments and preferred embodiments, which are not described again.
  • the term “module” may implement a combination of software and/or hardware of a predetermined function.
  • the devices described in the following embodiments are preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 5 is a structural block diagram of a key agreement apparatus according to an embodiment of the present application. As shown in FIG. 5, applied to the first network element, the device includes:
  • the transmitting module 30 is configured to receive the public key PubK2 and the random string RAND from the second network element; the generating module 32 is configured to generate a signaling key SK based on the PubK2, and send a response character to the second network element a string RES, wherein the RES is generated based on the RAND; the processing module 34 is configured to receive an encrypted shared key EKs from the second network element and generate a shared key Ks based on the SK and the EKs.
  • the transmission module 30 is configured to send the first public key PubK1 to the second network element, and receive the second public key PubK2 and the random string RAND from the second network element;
  • the generating module 32 is configured to Generating a signaling key SK based on PubK2 and transmitting a response string RES to the second network element;
  • the processing module 34 is configured to receive the shared key Ks from the second network element, or receive an encrypted share from the second network element The key EKs and generates a shared key Ks based on SK and EKs.
  • the apparatus further includes: a sending module, configured to send the first check code MAC1 generated based on the Ks to the third network element.
  • the apparatus further comprises: a protection module configured to use the SK or the SK-derived key pair and the first after the processing module 34 receives the shared key Ks or the encrypted shared key EKs from the second network element
  • a protection module configured to use the SK or the SK-derived key pair and the first after the processing module 34 receives the shared key Ks or the encrypted shared key EKs from the second network element The data exchanged between the two network elements is confidential or integrity protected.
  • FIG. 6 is a structural block diagram of a key agreement apparatus according to another embodiment of the present application. As shown in FIG. 6, applied to the second network element, the device includes:
  • the receiving module 40 is configured to receive the public key PubK1 from the first network element, and generate a signaling key SK based on the PubK1; the sending module 42 is configured to send a random string RAND to the first network element; the processing module 44. Set to receive a response string RES from the first network element, and send an encrypted shared key EKs to the first network element, where the RES is generated based on the RAND, and the EKs are based on the SK and shared key Ks are generated.
  • the receiving module 40 is configured to receive the first public key PubK1 from the first network element, and generate a signaling key SK based on the PubK1;
  • the sending module 42 is configured to be A network element sends a second public key PubK2, and a random string RAND;
  • the processing module 44 is configured to receive the response string RES from the first network element, and send the shared key Ks or the encrypted shared key to the first network element.
  • EKs where EKs are generated based on SK and shared key Ks.
  • the apparatus further includes: a protection module configured to use the SK or the SK-derived key pair and the first after the processing module 44 sends the shared key Ks or the encrypted shared key EKs to the first network element
  • a protection module configured to use the SK or the SK-derived key pair and the first after the processing module 44 sends the shared key Ks or the encrypted shared key EKs to the first network element
  • the data exchanged between network elements is confidential or integrity protected.
  • FIG. 7 is a structural block diagram of a key agreement system according to an embodiment of the present application.
  • the key agreement system provided in this embodiment includes: a first network element 50 and a second network element 52.
  • the first network element 50 includes: a transmission module 500, configured to send a first public key PubK1 to the second network element 52, and receive a second public key from the second network element 52.
  • the first processing module 504 is configured to receive the encrypted shared key EKs from the second network element 52 and generate a shared key Ks based on the SK and the EKs.
  • the second network element 52 includes: a first receiving module 520, configured to receive a first public key PubK1 from the first network element 50, and generate the SK based on the PubK1; and send a module 522, set to The first network element 50 sends the PubK2, and the RAND; the second processing module 524 is configured to receive the RES from the first network element 50, and send the location to the first network element 50.
  • EKs wherein the EKs are generated based on the SK and the Ks.
  • FIG. 8 is a structural block diagram of a key agreement system according to another embodiment of the present application.
  • the key agreement system provided in this embodiment includes: a first network element 50, a second network element 52, and a third network element 54.
  • the first network element 50 includes: a transmission module 500, configured to send a first public key PubK1 to the second network element 52, and receive a second public key PubK2 and a random string from the second network element 52.
  • a RAND configured to generate a signaling key SK based on PubK2, and send a response string RES to the second network element 52, wherein the RES is generated based on the RAND
  • the first processing module 504 is configured to Receiving the shared key Ks from the second network element, or receiving the encrypted shared key EKs from the second network element, and generating the shared key Ks based on the SK and the EKs
  • the first sending module 506 is set to the third network
  • the element 54 sends a first check code MAC1 generated based on the Ks
  • the second network element 52 includes: a first receiving module 520, configured to receive the first public key PubK1 from the first network element 50, and generate a signaling secret based on the PubK1
  • the second sending module 522 is
  • third network element comprising: a second receiving module 540, configured to receive a first network element 50 based on the first check code MACl Ks generated.
  • the above multiple modules may be implemented by software or hardware.
  • the foregoing may be implemented by, but not limited to, the above multiple modules are all located in the same processor; or, the above multiple modules are in any combination.
  • the forms are located in different processors.
  • FIG. 9 is a schematic flowchart diagram of a core network-based key agreement method according to an embodiment of the present disclosure. As shown in FIG. 9, the long-term key LTK or the shared key Ks already exists between the second network element and the third network element, and the process includes:
  • Step 601 The first network element, the visited network (such as a Mobile Management Function (MMF), a Security Anchor Function (SEAF), or an Access Management Function (AMF), etc.
  • MMF Mobile Management Function
  • SEAF Security Anchor Function
  • AMF Access Management Function
  • AUSF Authentication Service Function
  • AAA Authentication and Accounting
  • ARPF Authentication Vector Storage Function
  • HSS Home Subscriber Server
  • Step 602 The second network element acquires a random string RAND, and generates a desired response XRES based on Ks and RAND.
  • the second network element generates a signaling key SK based on PubK1, for example, using Diffie-Hellman key exchange (Diffie- Hellman key exchange) protocol, the second network element can also generate tokens based on Ks and SK, such as Secure Hash Algorithm-256 (SHA-256) or Hash Message Authentication Code-Secure Hash Algorithm- 256 (Hashed Message Authentication Code-Secure Hash Algorithm-256, HMAC-SHA-256) algorithm with Ks and SK as inputs.
  • Secure Hash Algorithm-256 SHA-256
  • Hash Message Authentication Code-Secure Hash Algorithm-256 Hashed Message Authentication Code-Secure Hash Algorithm-256, HMAC-SHA-256 algorithm with Ks and SK as inputs
  • Step 603 The second network element sends a shared key establishment response to the first network element, for example, an authentication data response (Authentication Data Response) message, where the message carries the RAND and the public key PubK2 of the second network element, and may further include a Token.
  • an authentication data response Authentication Data Response
  • Step 604 The first network element generates a signaling key SK based on the PubK2, for example, using a Diffie-Hellman key exchange protocol, where the protocol can generate the SK and the second network element generated by the first network element without the data being tampered with.
  • the generated SK is the same.
  • Step 605 The first network element sends an authentication request to the third network element, such as a user equipment (UE), an authentication service function AUSF, an authentication authorization accounting AAA, an authentication vector storage function ARPF, or an HSS, for example, sending a user authentication.
  • UE user equipment
  • AUSF authentication service function
  • ARPF authentication vector storage function
  • HSS HSS
  • Step 606 The third network element receives the RAND, and calculates a response string RES based on the LTK or Ks and the RAND.
  • the third network element sends an authentication response to the first network element, for example, sending a user authentication response (User Authentication Response) message, and a message. Carry RES.
  • a user authentication response User Authentication Response
  • Step 607 The first network element forwards the RES to the second network element.
  • the second network element may generate the expected response string XRES based on the LTK or Ks and the RAND, and compare the XRES with the RES. If the same, the subsequent steps are performed, and the different stops.
  • Step 608 If the LTK is shared between the second network element and the third network element, the second network element and the third network element respectively generate Ks based on the LTK.
  • Step 609 The second network element sends an authentication verification success message to the first network element, for example, an Extensible Authentication Protocol (EAP-Success) message, where the message carries Ks or EKs generated based on SK and Ks.
  • EAP-Success Extensible Authentication Protocol
  • Step 610 The first network element receives the authentication verification success message. If the EKs are received, the Ks is generated based on the SK and the EKs. If the Token is received, the expected token XToken is generated based on the SK and the Ks, and the XToken and the Token are compared. If the same, perform the next steps, otherwise stop;
  • Step 611 The first network element sends a data verification request to the third network element, for example, sending a security mode command (Secure Mode Command) message, where the message carries a first check code MAC1 generated based on Ks;
  • a security mode command Secure Mode Command
  • Step 612 The third network element receives the data verification request, generates the expected first check code XMAC1 based on the Ks, compares the XMAC1 and the MAC1, and sends the data verification response to the first network element, for example, the sending security mode is completed (Secure Mode Complete) a message carrying a second check code MAC2 generated based on Ks, the first network element may generate a desired second check code XMAC2 through Ks, compare XMAC2 and MAC2, and confirm that the generated SK and the second network element are generated.
  • the SK is the same, and the received Ks is the same as the Ks sent by the second network element, that is, it has not been tampered with.
  • FIG. 10 is a schematic flowchart of a core network-based key agreement method according to another embodiment of the present disclosure. As shown in FIG. 10, a long-term key LTK or a shared key Ks already exists between the first network element and the third network element, and the process includes:
  • Step 701 The first network element, the visited network (such as the mobility management function MMF, or the security anchor function SEAF, or the access management entity AMF, etc.) to the second network element, the home network (such as a security gateway (Secure Gateway, SEG)) Sending a shared key establishment request, for example, sending an Authentication Data Request message carrying the public key PubK1 of the first network element.
  • the visited network such as the mobility management function MMF, or the security anchor function SEAF, or the access management entity AMF, etc.
  • the home network such as a security gateway (Secure Gateway, SEG)
  • Sending a shared key establishment request for example, sending an Authentication Data Request message carrying the public key PubK1 of the first network element.
  • Step 702 The second network element sends an authentication request (Authentication Request) to the third network element, the home network (such as the authentication service function AUSF, or the authentication authorization accounting AAA, or the authentication vector storage function ARPF, or the HSS, etc.).
  • the home network such as the authentication service function AUSF, or the authentication authorization accounting AAA, or the authentication vector storage function ARPF, or the HSS, etc.
  • Step 703 If the LTK is shared between the first network element and the third network element, the first network element and the third network element respectively generate Ks based on the LTK.
  • Step 704 The third network element obtains a random string RAND, and generates a desired response XRES based on Ks and RAND.
  • Step 705 The third network element sends an authentication response (Authentication Response) to the second network element, where the authentication response carries RAND and Ks.
  • Authentication Response an authentication response
  • Step 706 The second network element generates a signaling key SK based on the PubK1.
  • the second network element can also generate a token based on the Ks and the SK, for example, using SHA-256 or HMAC-SHA-256. Algorithm with Ks and SK as input.
  • Step 707 The second network element sends a shared key establishment response to the first network element, for example, sends an Authentication Data Response message, where the message carries the RAND and the public key PubK2 of the second network element, and may further include a Token.
  • Step 708 The first network element generates a signaling key SK based on the PubK2, for example, using the Diffie-Hellman key exchange protocol, and the protocol can enable the SK and the second network element generated by the first network element without the data being tampered with.
  • the generated SK is the same.
  • Step 709 The first network element calculates a response string RES based on the LTK or Ks and the RAND, and sends an authentication verification request (Authentication Verification Request) to the second network element, where the RES is carried in the authentication verification request.
  • Authentication Verification Request an authentication verification request
  • Step 710 The second network element forwards the authentication verification request to the third network element.
  • Step 711 The third network element may generate an expected response string XRES based on LTK or Ks and RAND, and compare XRES with RES, and the third network element sends an authentication verification response (Authentication Verification Response) to the second network element.
  • the response carries a comparison result indication;
  • Step 712 The second network element forwards the authentication verification response to the first network element according to the indication information.
  • the authentication verification response carries the Ks or the EKs generated based on the SK and the Ks. Otherwise, the authentication verification response is not forwarded. .
  • Step 713 The first network element receives the authentication check response message, and determines the indication information in the message. If the indication is successful, and the received EKs, the Ks is generated based on the SK and the EKs, and if the Token is not received, the SK and/or are accepted. Or Ks, if you have received a Token, generate the expected token XToken based on SK and Ks, and compare XToken and Token. If they are the same, accept SK and / or Ks, otherwise reject, if the indication is unsuccessful, refuse to accept SK and / or Ks. Accepting SK indicates that the generated SK is the same as the SK generated by the second network element, and the received Ks is the same as the Ks sent by the third network element, that is, it has not been tampered with.
  • Embodiments of the present disclosure also provide a storage medium.
  • the above storage medium may be configured to store program code for performing the following steps:
  • the foregoing storage medium may include, but is not limited to, a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.
  • ROM read-only memory
  • RAM random access memory
  • the processor performs to send the first public key PubK1 to the second network element according to the stored program code in the storage medium, and receives the second public key PubK2 and the random string RAND from the second network element;
  • the processor generates a signaling key SK based on PubK2 according to the stored program code in the storage medium, and sends a response string RES to the second network element.
  • the processor is configured according to the storage medium.
  • the stored program code performs reception of the shared key Ks from the second network element, or receives the encrypted shared key EKs from the second network element, and generates the shared key Ks based on SK and EKs.

Landscapes

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

Abstract

一种密钥协商方法、装置及***。所述方法包括：第一网元接收来自第二网元的公钥PubK2和随机字符串RAND；第一网元基于PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，RES基于RAND生成；第一网元接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。

Description

密钥协商方法、装置及***
本公开要求申请日为2017年08月04日、申请号为201710662149.X、名称为“密钥协商方法、装置及***”的中国专利申请的优先权，该申请的全部内容通过引用结合在本公开中。
技术领域
本公开涉及通信技术领域，例如涉及一种密钥协商方法、装置及***。
背景技术
第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)提出了一种移动网络认证方案，网元之间的密钥协商方案比较单一，相关技术中的密钥协商方案只注重保护终端与终端直接拜访的网络之间的通信保护，如果只注重终端与拜访网之间的连接，而归属网与拜访网之间的信令连接基本处于无保护状态，相关技术中的移动网络认证过程要求归属网把终端与拜访网之间使用的密钥传递给拜访网，这导致该密钥往往是明文传输，导致泄密。
发明内容
本申请实施例提供了一种密钥协商方法、装置及***，以至少解决相关技术中通过明文传输密钥导致密钥安全性差的技术问题。
本申请提供了一种密钥协商方法，包括：第一网元接收来自第二网元的第二公钥PubK2和随机字符串RAND；所述第一网元基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES基于所述RAND生成；所述第一网元接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
本申请还提供了另一种密钥协商方法，包括：第二网元接收来自第一网元的第一公钥PubK1，并基于所述PubK1生成信令密钥SK；所述第二网元向所述第一网元发送随机字符串RAND；所述第二网元接收来自所述第一网元的响应字符串RES，并向所述第一网元发送加密共享密钥EKs，其中，所述RES基于所述RAND生成，所述EKs基于所述SK和共享密钥Ks生成。
本申请还提供了一种密钥协商装置，应用在第一网元，包括：传输模块， 设置为接收来自第二网元的第二公钥PubK2和随机字符串RAND；生成模块，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES为基于所述RAND生成；处理模块，设置为接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
本申请还提供了另一种密钥协商装置，应用在第二网元，包括：接收模块，设置为接收来自第一网元的第一公钥PubK1，并基于所述PubK1生成信令密钥SK；发送模块，设置为向所述第一网元发送随机字符串RAND；处理模块，设置为接收来自所述第一网元的响应字符串RES，并向所述第一网元发送加密共享密钥EKs，其中，所述RES基于所述RAND生成，所述EKs基于所述SK和共享密钥Ks生成。
本申请还提供了一种密钥协商***，包括第一网元、第二网元以及第三网元，其中，所述第一网元包括：传输模块，设置为向所述第二网元发送第一公钥PubK1，以及接收来自所述第二网元的第二公钥PubK2和随机字符串RAND；生成模块，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES为基于所述RAND生成；第一处理模块，设置为接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks；所述第二网元包括：第一接收模块，设置为接收来自第一网元的第一公钥PubK1，并基于所述PubK1生成所述SK；发送模块，设置为向所述第一网元发送所述PubK2，以及所述RAND；第二处理模块，设置为接收来自所述第一网元的所述RES，并向所述第一网元发送所述EKs，其中，所述EKs基于所述SK和所述Ks生成。
本申请还提供了一种存储介质。该存储介质设置为存储用于执行以下步骤的程序代码：
接收来自第二网元的第二公钥PubK2和随机字符串RAND；
基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES为基于所述RAND生成；
接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
附图说明
图1是本申请一实施例提供的一种密钥协商方法的流程图；
图2是本申请另一实施例提供的一种密钥协商方法的流程图；
图3是本申请另一实施例提供的一种密钥协商方法的流程图；
图4是本申请另一实施例提供的一种密钥协商方法的流程图；
图5是本申请一实施例提供的一种密钥协商装置的结构框图；
图6是本申请另一实施例提供的一种密钥协商装置的结构框图；
图7是本申请一实施例提供的密钥协商***的结构框图；
图8是本申请另一实施例提供的密钥协商***的结构框图；
图9为本申请一实施例提供的基于核心网的密钥协商方法的流程示意图；
图10为本申请另一实施例提供的基于核心网的密钥协商方法的流程示意图。
具体实施方式
下文中将参考附图并结合实施例来说明本申请。
本申请的说明书和权利要求书及上述附图中的术语“第一”以及“第二”等是用于区别类似的对象，而不必用于描述指定的顺序或先后次序。
实施例1
图1是本申请一实施例提供的一种密钥协商方法的流程图。如图1所示，本实施例提供的密钥协商方法包括如下步骤。
步骤110、第一网元接收来自第二网元的公钥PubK2和随机字符串RAND。
步骤120、第一网元基于PubK2生成信令密钥SK，以及向第二网元发送响应字符串RES。
在一实施例中，RES基于RAND生成。
步骤130、第一网元接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。
本实施例通过与第二网元协商传输加密共享密钥，解决了通过明文传输共享密钥导致的密钥安全性差的问题。
图2是本申请另一实施例提供的一种密钥协商方法的流程图。如图2所示，该流程包括如下步骤。
步骤102，第一网元向第二网元发送第一公钥PubK1，以及接收来自第二网元的第二公钥PubK2和随机字符串RAND。
步骤104，第一网元基于PubK2生成信令密钥SK，以及向第二网元发送响应字符串RES。
步骤106，第一网元接收来自第二网元的共享密钥Ks，或者，第一网元接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。
通过上述步骤，由于第一网元与第二网元协商传输密钥，可以保护第一网元与第二网元之间的信令连接，因此，解决了相关技术中通过明文传输密钥导致密钥安全性差的技术问题，降低了密钥泄密的可能性。
在一实施例中，上述步骤的执行主体第一网元可以为网元设备，如拜访网网元等，但不限于此。
本实施例中，获取Ks的实现方式包括两种：其一，第一网元接收来自第二网元的共享密钥Ks；其二，步骤104，第一网元基于PubK2生成信令密钥SK，第一网元接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。
在一实施例中，步骤104和步骤106中部分操作根据上述两种实现方式确定，执行顺序是可以互换的。
在一实施例中，在第一网元接收来自第二网元的共享密钥Ks或加密共享密钥EKs之后，还包括：第一网元使用SK或基于SK派生的密钥对与第二网元间交互的数据进行机密性或完整性保护。
在一实施例中，所述方法还包括：第一网元向第三网元发送RAND；第一网元接收来自第三网元的RES。
在一实施例中，本实施例的方案还包括：第一网元接收来自第二网元的令牌Token；第一网元判断Token是否基于Ks和SK生成；第一网元基于判断结果确定SK或Ks的合法性。
在一实施例中，在第一网元基于SK和EKs生成共享密钥Ks之后，还包括：第一网元向第三网元发送基于Ks生成的第一校验码MAC1。
在一实施例中，本实施例的方案还包括：第一网元接收来自第三网元的第 二校验码MAC2；第一网元判断MAC2是否基于Ks生成；第一网元基于判断结果确定SK或Ks的合法性。确定合法性包括确定SK或Ks是否正确，是否是正确网元发送的，还是经过篡改过的。
在一实施例中，本实施例的方案还包括：第一网元接收来自第二网元的令牌Token；第一网元判断Token是否基于Ks和SK生成；第一网元基于判断结果执行或停止向第三网元发送MAC1的操作。
图3为本申请另一实施例提供的一种密钥协商方法的流程图。如图3所示，本实施例提供的密钥协商方法包括如下步骤。
步骤210、第二网元接收来自第一网元的公钥PubK1，并基于PubK1生成信令密钥SK。
步骤220、第二网元向第一网元发送随机字符串RAND。
步骤230、第二网元接收来自第一网元的响应字符串RES，并向第一网元发送加密共享密钥EKs。
在一实施例中，RES基于RAND生成，EKs基于SK和共享密钥Ks生成。
本实施例通过与第一网元进行协商，向第一网元发送加密共享密钥，解决了通过明文传输共享密钥导致的密钥安全性差的问题。
在本申请另一实施例中提供了一种密钥协商方法，图4是本实施例提供的另一种密钥协商方法的流程图。如图4所示，该流程包括如下步骤.
步骤202，第二网元接收来自第一网元的第一公钥PubK1，并基于PubK1生成信令密钥SK。
步骤204，第二网元向第一网元发送第二公钥PubK2，以及随机字符串RAND。
步骤206，第二网元接收来自第一网元的响应字符串RES，以及向第一网元发送共享密钥Ks或加密共享密钥EKs，其中，EKs基于SK和共享密钥Ks生成。
在一实施例中，上述步骤的执行主体第二网元可以为网元设备，如归属网网元等，但不限于此。
在一实施例中，在第二网元向第一网元发送共享密钥Ks或加密共享密钥 EKs之后，方法还包括：第二网元使用SK或基于SK派生的密钥对与第一网元间交互的数据进行机密性或完整性保护。
在一实施例中，所述方法还包括：第二网元判断RES是否基于RAND生成；第二网元基于判断结果执行或停止向第一网元发送Ks或EKs的操作。
在一实施例中，所述方法还包括：
第二网元接收来自第三网元的RAND；第二网元向第三网元发送RES。
在一实施例中，所述方法还包括：第二网元接收来自第三网元的Ks。
在一实施例中，所述方法还包括：第二网元接收来自第三网元的指示；第二网元基于指示执行或停止向第一网元发送Ks或EKs的操作。
在一实施例中，所述方法还包括：第二网元向第一网元发送令牌Token，其中，Token基于SK和Ks生成。
在本实施例中，第一网元为拜访网网元，第二网元为归属网网元，第三网元为终端或归属网网元。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如只读存储器(Read Only Memory，ROM)/随机存取存储器(Random Access Memory，RAM)、磁碟、光盘)中，包括多个指令用以使得一台终端设备(如手机、计算机、服务器或者网络设备等)执行本申请任意实施例所述的方法。
实施例2
在本实施例中还提供了一种密钥协商装置、***，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图5是本申请一实施例提供的一种密钥协商装置的结构框图。如图5所示， 应用在第一网元，该装置包括：
传输模块30，设置为接收来自第二网元的公钥PubK2和随机字符串RAND；生成模块32，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES基于所述RAND生成；处理模块34，设置为接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
请继续参照图5。在另一实施例中，传输模块30，设置为向第二网元发送第一公钥PubK1，以及接收来自第二网元的第二公钥PubK2和随机字符串RAND；生成模块32，设置为基于PubK2生成信令密钥SK，以及向第二网元发送响应字符串RES；处理模块34，设置为接收来自第二网元的共享密钥Ks，或，接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。
在一实施例中，装置还包括；发送模块，设置为向第三网元发送基于Ks生成的第一校验码MAC1。
在一实施例中，装置还包括：保护模块，设置为在处理模块34接收来自第二网元的共享密钥Ks或加密共享密钥EKs之后，使用SK或基于SK派生的密钥对与第二网元间交互的数据进行机密性或完整性保护。
图6是本申请另一实施例提供的一种密钥协商装置的结构框图。如图6所示，应用在第二网元，该装置包括：
接收模块40，设置为接收来自第一网元的公钥PubK1，并基于所述PubK1生成信令密钥SK；发送模块42，设置为向所述第一网元发送随机字符串RAND；处理模块44，设置为接收来自所述第一网元的响应字符串RES，并向所述第一网元发送加密共享密钥EKs，其中，所述RES基于所述RAND生成，所述EKs基于所述SK和共享密钥Ks生成。
请继续参照图6，在另一实施例中，接收模块40，设置为接收来自第一网元的第一公钥PubK1，并基于PubK1生成信令密钥SK；发送模块42，设置为向第一网元发送第二公钥PubK2，以及随机字符串RAND；处理模块44，设置为接收来自第一网元的响应字符串RES，以及向第一网元发送共享密钥Ks或加密共享密钥EKs，其中，EKs基于SK和共享密钥Ks生成。
在一实施例中，装置还包括：保护模块，设置为在处理模块44向第一网元 发送共享密钥Ks或加密共享密钥EKs之后，使用SK或基于SK派生的密钥对与第一网元间交互的数据进行机密性或完整性保护。
图7是本申请一实施例提供的密钥协商***的结构框图。如图7所示，本实施例提供的密钥协商***包括：第一网元50和第二网元52。本实施例中，所述第一网元50包括：传输模块500，设置为向所述第二网元52发送第一公钥PubK1，以及接收来自所述第二网元52的第二公钥PubK2和随机字符串RAND；生成模块502，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元52发送响应字符串RES，其中，所述RES为基于所述RAND生成；第一处理模块504，设置为接收来自所述第二网元52的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
所述第二网元52包括：第一接收模块520，设置为接收来自所述第一网元50的第一公钥PubK1，并基于所述PubK1生成所述SK；发送模块522，设置为向所述第一网元50发送所述PubK2，以及所述RAND；第二处理模块524，设置为接收来自所述第一网元50的所述RES，以及向所述第一网元50发送所述EKs，其中，所述EKs基于所述SK和所述Ks生成。
图8是本申请另一实施例提供的密钥协商***的结构框图。如图8所示，本实施例提供的密钥协商***包括：第一网元50、第二网元52和第三网元54。
在本实施例中，第一网元50包括：传输模块500，设置为向第二网元52发送第一公钥PubK1，以及接收来自第二网元52的第二公钥PubK2和随机字符串RAND；生成模块502，设置为基于PubK2生成信令密钥SK，以及向第二网元52发送响应字符串RES，其中，所述RES为基于所述RAND生成；第一处理模块504，设置为接收来自第二网元的共享密钥Ks，或，接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks；第一发送模块506，设置为向第三网元54发送基于Ks生成的第一校验码MAC1；第二网元52包括：第一接收模块520，设置为接收来自第一网元50的第一公钥PubK1，并基于PubK1生成信令密钥SK；第二发送模块522，设置为向第一网元50发送第二公钥PubK2，以及随机字符串RAND；第二处理模块524，设置为接收来自第一网元50的响应字符串RES，以及向第一网元发送共享密钥Ks或加密共享密钥EKs， 其中，EKs基于SK和共享密钥Ks生成；第三网元54包括：第二接收模块540，设置为接收第一网元50基于Ks生成的第一校验码MAC1。
上述多个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述多个模块均位于同一处理器中；或者，上述多个模块以任意组合的形式分别位于不同的处理器中。
实施例3
本实施例集合具体的场景对本申请进行解释和说明：
图9为本申请一实施例提供的基于核心网的密钥协商方法的流程示意图。如图9所示，第二网元和第三网元间已经存在长期密钥LTK或共享密钥Ks，该流程包括：
步骤601：第一网元，拜访网(比如移动管理功能(Mobile Management Function，MMF)、安全锚点功能(Security Anchor Function，SEAF)或接入管理实体(Access Management Function，AMF)等)向第二网元，归属网(比如认证服务功能(Authentication Server Function，AUSF)、认证授权记账(Authentication、Authorization、Accounting，AAA)、认证向量存储功能ARPF，或归属签约用户服务器(Home Subscriber Server，HSS)等)发送共享密钥建立请求，比如发送认证数据请求(Authentication Data Request)消息，消息中携带第一网元的公钥PubK1。
步骤602：第二网元获取随机字符串RAND，基于Ks和RAND生成期望响应XRES，第二网元基于PubK1生成一个信令密钥SK，比如使用迪菲-赫尔曼密钥交换(Diffie-Hellman key exchange)协议，第二网元还可以基于Ks和SK生成Token，比如使用安全散列算法256(Secure Hash Algorithm-256，SHA-256)或散列消息身份验证码-安全散列算法-256(Hashed Message Authentication Code-Secure Hash Algorithm-256，HMAC-SHA-256)算法，以Ks和SK作为输入。
步骤603，第二网元向第一网元发送共享密钥建立响应，比如发送认证数据响应(Authentication Data Response)消息，消息携带RAND和第二网元的公钥PubK2，还可以包括Token。
步骤604：第一网元基于PubK2生成一个信令密钥SK，比如使用Diffie- Hellman key exchange协议，该协议可以在数据没有被篡改的情况下使得第一网元生成的SK与第二网元生成的SK相同。
步骤605，第一网元向第三网元(比如终端(User Equipment，UE)、认证服务功能AUSF、认证授权记账AAA、认证向量存储功能ARPF或HSS等)发送认证请求，比如发送用户认证请求(User Authentication Request)消息，User Authentication Request消息中携带RAND。
步骤606：第三网元收到RAND，基于LTK或Ks以及RAND计算出响应字符串RES，第三网元向第一网元发送认证响应，比如发送用户认证响应(User Authentication Response)消息，消息中携带RES。
步骤607：第一网元转发RES给第二网元，第二网元可以基于LTK或Ks以及RAND生成期望响应字符串XRES，并比较XRES与RES，相同则执行后续步骤，不同则停止。
步骤608：如果第二网元和第三网元间共享的是LTK，则第二网元和第三网元分别基于LTK生成Ks。
步骤609：第二网元向第一网元发送认证校验成功消息，比如发送可扩展认证协议成功(Extensible Authentication Protocol，EAP-Success)消息，消息携带Ks或基于SK和Ks生成的EKs。
步骤610：第一网元收到认证校验成功消息，如果收到的是EKs则基于SK和EKs生成Ks，如果收到Token，则基于SK和Ks生成期望令牌XToken，并比较XToken和Token，如果相同则执行后续步骤，否则停止；
步骤611：第一网元向第三网元发送数据验证请求，比如发送安全模式指令(Secure Mode Command)消息，消息中携带基于Ks生成的第一校验码MAC1；
步骤612：第三网元收到数据验证请求，基于Ks生成期望第一校验码XMAC1，比较XMAC1和MAC1，相同则向第一网元发送数据验证响应，比如发送安全模式完成(Secure Mode Complete)消息，消息中携带基于Ks生成的第二校验码MAC2，第一网元可以通过Ks生成期望第二校验码XMAC2，比较XMAC2和MAC2，相同则确认生成的SK与第二网元生成的SK相同，收到的Ks与第二网元发送的Ks相同，即没有被篡改。
图10为本申请另一实施例提供的基于核心网的密钥协商方法的流程示意图。如图10所示，第一网元和第三网元间已经存在长期密钥LTK或共享密钥Ks，该流程包括：
步骤701：第一网元，拜访网(比如移动管理功能MMF，或安全锚点功能SEAF，或接入管理实体AMF等)向第二网元，归属网(比如安全网关(Secure Gateway，SEG))发送共享密钥建立请求，比如发送Authentication Data Request消息，消息中携带第一网元的公钥PubK1。
步骤702：第二网元向第三网元，归属网(比如认证服务功能AUSF，或认证授权记账AAA，或认证向量存储功能ARPF，或HSS等)发送认证请求(Authentication Request)。
步骤703：如果第一网元和第三网元间共享的是LTK，则第一网元和第三网元分别基于LTK生成Ks。
步骤704：第三网元获取随机字符串RAND，基于Ks和RAND生成期望响应XRES。
步骤705：第三网元向第二网元发送认证响应(Authentication Response)，认证响应中携带RAND和Ks。
步骤706：第二网元基于PubK1生成一个信令密钥SK，比如使用Diffie-Hellman key exchange协议，第二网元还可以基于Ks和SK生成Token，比如使用SHA-256或HMAC-SHA-256算法，以Ks和SK作为输入。
步骤707：第二网元向第一网元发送共享密钥建立响应，比如发送Authentication Data Response消息，消息携带RAND和第二网元的公钥PubK2，还可以包括Token。
步骤708：第一网元基于PubK2生成一个信令密钥SK，比如使用Diffie-Hellman key exchange协议，该协议可以在数据没有被篡改的情况下使得第一网元生成的SK与第二网元生成的SK相同。
步骤709：第一网元基于LTK或Ks以及RAND计算出响应字符串RES，向第二网元发送认证校验请求(Authentication Verification Request)，认证校验请求中携带RES。
步骤710：第二网元向第三网元转发认证校验请求。
步骤711：第三网元可以基于LTK或Ks以及RAND生成期望响应字符串XRES，并比较XRES与RES，第三网元向第二网元发送认证校验响应(Authentication Verification Response)，认证校验响应中携带比较结果指示；
步骤712：第二网元依据指示信息，如果指示成功，则向第一网元转发认证校验响应，认证校验响应中携带Ks或基于SK和Ks生成的EKs，否则不转发认证校验响应。
步骤713：第一网元收到认证校验响应消息，判断消息中的指示信息，如果指示成功，且收到的是EKs则基于SK和EKs生成Ks，如果没收到过Token则接受SK和/或Ks，如果还收到过Token，则基于SK和Ks生成期望令牌XToken，并比较XToken和Token，如果相同则接受SK和/或Ks，否则拒绝，如果指示不成功，则拒绝接受SK和/或Ks。接受SK表明确认生成的SK与第二网元生成的SK相同，收到的Ks与第三网元发送的Ks相同，即没有被篡改。
实施例4
本公开的实施例还提供了一种存储介质。在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
接收来自第二网元的公钥PubK2和随机字符串RAND；基于PubK2生成信令密钥SK，以及向第二网元发送响应字符串RES；接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共享密钥Ks。
在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、移动硬盘、磁碟或者光盘等可以存储程序代码的介质。
在本实施例中，处理器根据存储介质中已存储的程序代码执行向第二网元发送第一公钥PubK1，以及接收来自第二网元的第二公钥PubK2和随机字符串RAND；在本实施例中，处理器根据存储介质中已存储的程序代码执行基于PubK2生成信令密钥SK，以及向第二网元发送响应字符串RES；在本实施例中，处理器根据存储介质中已存储的程序代码执行接收来自第二网元的共享密钥Ks，或者，接收来自第二网元的加密共享密钥EKs，并基于SK和EKs生成共 享密钥Ks。
本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本申请的多个模块或多个步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，在一实施例中，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成一个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。
以上所述仅为本申请的实施例而已，并不用于限制本申请。

Claims (20)

  1. 一种密钥协商方法，包括：
    第一网元接收来自第二网元的公钥PubK2和随机字符串RAND；
    所述第一网元基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES基于所述RAND生成；
    所述第一网元接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
  2. 根据权利要求1所述的方法，还包括：
    所述第一网元向第三网元发送所述RAND；
    所述第一网元接收来自所述第三网元的所述RES。
  3. 根据权利要求1所述的方法，还包括：
    所述第一网元接收来自所述第二网元的令牌Token；
    所述第一网元判断所述Token是否基于所述Ks和所述SK生成。
  4. 根据权利要求1所述的方法，其中，在所述第一网元基于所述SK和所述EKs生成所述Ks之后，还包括：
    所述第一网元向第三网元发送基于所述Ks生成的第一校验码MAC1。
  5. 根据权利要求4所述的方法，还包括：
    所述第一网元接收来自所述第三网元的第二校验码MAC2；
    所述第一网元判断所述MAC2是否基于所述Ks生成。
  6. 根据权利要求4所述的方法，还包括：
    所述第一网元接收来自所述第二网元的令牌Token；
    所述第一网元判断所述Token是否基于所述Ks和所述SK生成；
    所述第一网元基于判断结果执行或停止向所述第三网元发送所述MAC1的操作。
  7. 根据权利要求2、4、5或6所述的方法，其中，所述第一网元为拜访网网元，所述第二网元为归属网网元，以及所述第三网元为终端或归属网网元。
  8. 一种密钥协商方法，包括：
    第二网元接收来自第一网元的公钥PubK1，并基于所述PubK1生成信令密钥SK；
    所述第二网元向所述第一网元发送随机字符串RAND；
    所述第二网元接收来自所述第一网元的响应字符串RES，并向所述第一网元发送加密共享密钥EKs，其中，所述RES基于所述RAND生成，所述EKs 基于所述SK和共享密钥Ks生成。
  9. 根据权利要求8所述的方法，还包括：
    所述第二网元判断所述RES是否基于所述RAND生成；
    所述第二网元基于判断结果执行或停止向所述第一网元发送所述EKs的操作。
  10. 根据权利要求8所述的方法，还包括：
    所述第二网元接收来自第三网元的所述RAND；
    所述第二网元向所述第三网元发送所述RES。
  11. 根据权利要求10所述的方法，其中，在所述向所述第一网元发送EKs之前，还包括：
    所述第二网元接收来自所述第三网元的所述Ks。
  12. 根据权利要求10或11所述的方法，还包括：
    所述第二网元接收来自所述第三网元的指示；
    所述第二网元基于所述指示执行或停止向所述第一网元发送所述EKs的操作。
  13. 根据权利要求8所述的方法，还包括：
    所述第二网元向所述第一网元发送令牌Token，其中，所述Token基于所述SK和所述Ks生成。
  14. 根据权利要求10所述的方法，其中，所述第一网元为拜访网网元，所述第二网元为归属网网元，以及所述第三网元为终端或归属网网元。
  15. 一种密钥协商装置，应用在第一网元，包括：
    传输模块，设置为接收来自第二网元的公钥PubK2和随机字符串RAND；
    生成模块，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES基于所述RAND生成；
    处理模块，设置为接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks。
  16. 根据权利要求15所述的装置，还包括；
    发送模块，设置为向第三网元发送基于所述Ks生成的第一校验码MAC1。
  17. 一种密钥协商装置，应用在第二网元，包括：
    接收模块，设置为接收来自第一网元的公钥PubK1，并基于所述PubK1生成信令密钥SK；
    发送模块，设置为向所述第一网元发送随机字符串RAND；
    处理模块，设置为接收来自所述第一网元的响应字符串RES，并向所述第一网元发送加密共享密钥EKs，其中，所述RES基于所述RAND生成，所述EKs基于所述SK和共享密钥Ks生成。
  18. 一种密钥协商***，包括第一网元、第二网元以及第三网元，其中，
    所述第一网元包括：
    传输模块，设置为向所述第二网元发送第一公钥PubK1，以及接收来自所述第二网元的第二公钥PubK2和随机字符串RAND；
    生成模块，设置为基于所述PubK2生成信令密钥SK，以及向所述第二网元发送响应字符串RES，其中，所述RES为基于所述RAND生成；
    第一处理模块，设置为接收来自所述第二网元的加密共享密钥EKs，并基于所述SK和所述EKs生成共享密钥Ks；
    所述第二网元包括：
    第一接收模块，设置为接收来自所述第一网元的第一公钥PubK1，并基于所述PubK1生成所述SK；
    发送模块，设置为向所述第一网元发送所述PubK2，以及所述RAND；
    第二处理模块，设置为接收来自所述第一网元的所述RES，以及向所述第一网元发送所述EKs，其中，所述EKs基于所述SK和所述Ks生成。
  19. 一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行权利要求1至14中任一项所述的方法。
  20. 一种处理器所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至14中任一项所述的方法。
PCT/CN2018/098964 2017-08-04 2018-08-06 密钥协商方法、装置及*** WO2019024937A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710662149.XA CN109391938A (zh) 2017-08-04 2017-08-04 密钥协商方法、装置及***
CN201710662149.X 2017-08-04

Publications (1)

Publication Number Publication Date
WO2019024937A1 true WO2019024937A1 (zh) 2019-02-07

Family

ID=65232309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/098964 WO2019024937A1 (zh) 2017-08-04 2018-08-06 密钥协商方法、装置及***

Country Status (2)

Country Link
CN (1) CN109391938A (zh)
WO (1) WO2019024937A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113163399B (zh) * 2020-01-07 2024-06-11 阿里巴巴集团控股有限公司 一种终端与服务器的通信方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047505A (zh) * 2006-03-27 2007-10-03 华为技术有限公司 一种网络应用push业务中建立安全连接的方法及***
CN101640886A (zh) * 2008-07-29 2010-02-03 上海华为技术有限公司 鉴权方法、重认证方法和通信装置
CN102395130A (zh) * 2011-11-01 2012-03-28 重庆邮电大学 一种lte中鉴权的方法
WO2017107143A1 (en) * 2015-12-24 2017-06-29 Nokia Technologies Oy Authentication and key agreement in communication network

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047505A (zh) * 2006-03-27 2007-10-03 华为技术有限公司 一种网络应用push业务中建立安全连接的方法及***
CN101640886A (zh) * 2008-07-29 2010-02-03 上海华为技术有限公司 鉴权方法、重认证方法和通信装置
CN102395130A (zh) * 2011-11-01 2012-03-28 重庆邮电大学 一种lte中鉴权的方法
WO2017107143A1 (en) * 2015-12-24 2017-06-29 Nokia Technologies Oy Authentication and key agreement in communication network

Also Published As

Publication number Publication date
CN109391938A (zh) 2019-02-26

Similar Documents

Publication Publication Date Title
US11405780B2 (en) Method for performing verification by using shared key, method for performing verification by using public key and private key, and apparatus
US11825303B2 (en) Method for performing verification by using shared key, method for performing verification by using public key and private key, and apparatus
US10638321B2 (en) Wireless network connection method and apparatus, and storage medium
US10742418B2 (en) Authentication method, authentication apparatus, and authentication system
US11178584B2 (en) Access method, device and system for user equipment (UE)
JP4712871B2 (ja) サービス提供者、端末機及びユーザー識別モジュールの包括的な認証と管理のための方法及びその方法を用いるシステムと端末装置
US10411884B2 (en) Secure bootstrapping architecture method based on password-based digest authentication
KR101485230B1 (ko) 안전한 멀티 ｕｉｍ 인증 및 키 교환
WO2017028593A1 (zh) 网络接入设备接入无线网络接入点的方法、网络接入设备、应用程序服务器和非易失性计算机可读存储介质
JP4965671B2 (ja) 無線通信ネットワークにおけるユーザ・プロファイル、ポリシー及びｐｍｉｐキーの配布
US10149158B2 (en) Access method, system, and device of terminal, and computer storage medium
WO2020221252A1 (zh) 发送终端序列号的方法和装置以及认证方法和装置
CN111147231B (zh) 一种密钥协商的方法、相关装置及***
EP2296392A1 (en) Authentication method, re-certification method and communication device
JP2011139457A (ja) 無線通信装置とサーバとの間でデータを安全にトランザクション処理する方法及びシステム
JP2012217207A (ja) 鍵マテリアルの交換
CN110635901B (zh) 用于物联网设备的本地蓝牙动态认证方法和***
EP4231680A1 (en) Identity authentication system, method and apparatus, device, and computer readable storage medium
WO2018120217A1 (zh) 验证密钥请求方的方法和设备
WO2016011588A1 (zh) 移动管理实体、归属服务器、终端、身份认证***和方法
JP2016111660A (ja) 認証サーバ、端末及び認証方法
BR112021003460A2 (pt) dispositivo sem identidade de assinante, dispositivo de identidade do assinante, método para uso em um dispositivo sem identidade de assinante, método para uso em um dispositivo com identidade de assinante e produto de programa de computador
US10700854B2 (en) Resource management in a cellular network
WO2019024937A1 (zh) 密钥协商方法、装置及***
WO2018126791A1 (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: 18840998

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08/09/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18840998

Country of ref document: EP

Kind code of ref document: A1