Key agreement method and system

Abstract

This application relates to the field of communication technology and discloses a key negotiation method and system. The method includes: a requesting party generating a temporary key, encrypting the temporary key using the public key of the requesting party to obtain a first ciphertext, and broadcasting a first message containing the first ciphertext; the requesting party receiving the broadcast first message, decrypting the first ciphertext in the message using its own private key to obtain a decrypted temporary key, using the decrypted temporary key as the key for a message authentication code to generate a message authentication code for the first message and the second ciphertext, and sending a response message in response to the first message, the response message containing the message authentication code and the second ciphertext, the second ciphertext containing a session key with the requesting party; the requesting party A receiving the response message, verifying the validity of the message authentication code in the message based on the temporary key, and if valid, obtaining the session key from the response message. The implementation of this application reduces the complexity of communication while improving the security of the communication process and both parties.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to key negotiation methods and systems. Background Technology

[0002] Privacy-preserving authentication key agreement protocols are suitable for scenarios where both communicating parties have high privacy requirements and do not want to expose their identities to others. For example, in e-commerce transactions, the communication between sellers and buyers has extremely high privacy requirements, and the content of the calls is extensive. When neither party wants others to know about their transaction, they can use a privacy-preserving authentication key agreement protocol to share a session key, and then use this session key to encrypt subsequent transaction content, identity information, etc.

[0003] In existing technologies, in near-field communication scenarios (such as Bluetooth communication), the key negotiation process of the classic privacy-preserving AKE protocol is as follows: Figure 1 As shown, the process includes the following three steps: First, the sender S wants to communicate with the receiver R1, so it broadcasts an anonymous, unauthenticated key exchange protocol; second, all receivers R1...R n Upon receiving the message, since it is anonymous and unauthenticated, both parties will respond to it, and their responses will also be anonymous and unauthenticated. In the third step, the sender S receives several messages. Because these messages are all anonymous and unauthenticated, the sender S cannot distinguish which message is R1's response and must respond to each one sequentially. This response is authenticated, using the key negotiated in the first two messages to encrypt its identity and signature. In the fourth step, the receiver R1 receives the message, identifies the sender S, responds to the message, and authenticates its own identity. Therefore, it can be seen that the classic AKE scheme requires a large amount of communication between the two parties, which can trigger responses from other irrelevant users, wasting computational resources. Furthermore, the classic scheme has a high number of communication rounds, resulting in excessive communication costs. Summary of the Invention

[0004] The purpose of this application is to provide a key negotiation method and system that reduces the complexity of communication while improving the security of the communication process and both parties.

[0005] This application discloses a key negotiation method, which includes the following steps:

[0006] The requesting party A generates a temporary key, encrypts the temporary key using the public key of the party to whom it is requesting the first ciphertext, and broadcasts a first message containing the first ciphertext.

[0007] B. Upon receiving the first broadcast message, the other party decrypts the first ciphertext in the message using its private key to obtain a temporary decryption key. It then uses this temporary decryption key as the key to generate a message authentication code for the first message and the second ciphertext, and sends a response message to respond to the first message. The response message contains the message authentication code and the second ciphertext, and the second ciphertext contains the session key with the requesting party.

[0008] C. Upon receiving the response message, the requesting party verifies the validity of the message verification code in the message based on the temporary key it generates. If valid, it retrieves the second ciphertext from the response message and decrypts it to obtain the session key.

[0009] In a preferred embodiment, step A is preceded by the following: the requester generates a temporary public key and a temporary private key pair;

[0010] The first message also includes the temporary public key.

[0011] In a preferred embodiment, step B further includes:

[0012] The receiving party decrypts the first ciphertext in the message using its private key to obtain a decryption temporary key, encrypts the session key using the temporary public key in the message to obtain the second ciphertext, and uses the decrypted temporary key as a key to generate a message authentication code for the temporary public key, the first ciphertext, and the second ciphertext, and sends a response message to respond to the broadcast first message, the response message containing the second ciphertext and the message authentication code.

[0013] In a preferred embodiment, step C further includes:

[0014] Upon receiving the response message, the requesting party verifies the validity of the message verification code in the message based on its own generated temporary key. If valid, it uses its own temporary private key to decrypt the second ciphertext in the message to obtain the session key.

[0015] In a preferred embodiment, the method further includes:

[0016] The decrypted temporary key is used as the key to generate the temporary public key, the first ciphertext, and the message authentication code of the second ciphertext, based on a hash function or pseudo-random function.

[0017] In a preferred embodiment, step C is followed by the following steps:

[0018] The requesting party uses the obtained session key to encrypt its own signature and sends the encrypted signature to the other party;

[0019] The other party uses the session key to decrypt the received encrypted signature and verifies the decrypted signature. If the verification is successful, the session key is used to communicate with the requesting party.

[0020] This application also discloses a key negotiation system including a requester and a counterparty to whom a request is made;

[0021] The requesting parties include:

[0022] The key generation unit is configured to generate temporary keys.

[0023] The first encryption unit is configured to encrypt the temporary key using the public key of the requested counterparty to obtain the first ciphertext;

[0024] The broadcast unit is configured to broadcast a first message containing the first ciphertext;

[0025] The first receiving unit is configured to receive a response message from the other party;

[0026] The session key determination unit is configured to verify the validity of the message verification code in the response message based on the temporary key it generates. If valid, it obtains the second ciphertext from the response message and decrypts it to obtain the session key.

[0027] The other party includes:

[0028] The second receiving unit is configured to receive the first message broadcast.

[0029] The decryption unit is configured to use its own private key to decrypt the first ciphertext in the message to obtain a temporary decryption key;

[0030] The message authentication code generation unit is configured to use the decrypted temporary key as a key to generate a message authentication code for the first message and the second ciphertext, wherein the second ciphertext contains a session key with the requester.

[0031] The sending unit is configured to send a response message in response to the broadcast first message, the response message including the message authentication code and the second ciphertext.

[0032] In a preferred embodiment, the key generation unit is further configured to generate a temporary public key and a temporary private key pair;

[0033] The first message also includes the temporary public key.

[0034] In a preferred embodiment, the other party further includes a second encryption unit;

[0035] The second encryption unit uses the temporary public key in the message to encrypt the session key to obtain the second ciphertext. The message authentication code generation unit uses the decrypted temporary key as the key to generate the message authentication code of the temporary public key, the first ciphertext, and the second ciphertext.

[0036] In a preferred embodiment, the session key determination unit is further configured to obtain the session key by decrypting the second ciphertext in the message using its own temporary private key if the message verification code in the verification response message is valid.

[0037] Compared with existing technologies, the embodiments of this application not only reduce the complexity of communication (or reduce the number of communication rounds), but also improve the security of communication and both parties (ensuring forward security and anonymity of both parties). Furthermore, the embodiments of this application can be applied to near-field communication.

[0038] The specification of this application contains numerous technical features distributed across various technical solutions. Listing all possible combinations of these technical features (i.e., technical solutions) would make the specification excessively lengthy. To avoid this problem, the various technical features disclosed in the above-described invention, the various technical features disclosed in the following embodiments and examples, and the various technical features disclosed in the accompanying drawings can be freely combined to form various new technical solutions (all of which are considered to have been described in this specification), unless such a combination of technical features is technically infeasible. For example, one example discloses feature A+B+C, and another example discloses feature A+B+D+E. Features C and D are equivalent technical means that serve the same function, and technically only one needs to be used; they cannot be used simultaneously. Feature E can technically be combined with feature C. Therefore, the solution A+B+C+D should not be considered as described because it is technically infeasible, while the solution A+B+C+E should be considered as described. Attached Figure Description

[0039] Figure 1 This is a diagram of the key negotiation process of the classic AKE protocol in existing technology.

[0040] Figure 2 This is a schematic flowchart of a key negotiation method according to the first embodiment of this application.

[0041] Figure 3 This is a diagram of the key negotiation process according to the first embodiment of this application.

[0042] Figure 4 This is a schematic diagram of the key negotiation system structure according to the second embodiment of this application. Detailed Implementation

[0043] In the following description, many technical details are presented to help the reader better understand this application. However, those skilled in the art will understand that the technical solutions claimed in this application can be implemented even without these technical details and various variations and modifications based on the following embodiments.

[0044] Terminology Explanation:

[0045] Inter-round state: During the execution of the same protocol, in order for the next round to be executed, the user needs to pass information to the next round.

[0046] Session key: A key negotiated jointly by two users during a session.

[0047] Temporary key / temporary public key and temporary private key pair: a key that is used only once by two users during communication, with the purpose of making the session key more secure.

[0048] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0049] The first embodiment of this application relates to a key negotiation method, which is an improvement on the classic AKE scheme, and is applicable, for example but not limited to, scenarios such as Bluetooth protocol and near-field communication. Figure 2 and Figure 3 As shown, the method includes the following steps:

[0050] In step 202, requester A generates a temporary key, encrypts the temporary key using the public key of the requesting party B to obtain the first ciphertext, and broadcasts a first message containing the first ciphertext.

[0051] Optionally, the public key of the other party B may be pre-configured in the requesting party A, for example, but not limited to.

[0052] Optionally, the temporary key is randomly generated.

[0053] In one implementation example, step 202 is preceded by: requester A generating a temporary public key and a temporary private key pair, and the first message also containing the temporary public key. Optionally, the temporary public key and the temporary private key pair are randomly generated.

[0054] In step 204, the other party B receives the first broadcast message, decrypts the first ciphertext in the message using its private key to obtain a decryption temporary key, uses this decryption temporary key as the key to generate a message authentication code for the first message and the second ciphertext, and sends a response message to respond to the first message. This response message contains the message authentication code and the second ciphertext, where the second ciphertext contains the session key with the requesting party A. Optionally, the decryption temporary key is used as the key to generate the message authentication code for the first and second ciphertexts.

[0055] In an embodiment where the first message also includes a temporary public key, step 204 further includes the following steps: Upon receiving the first message, the other party B decrypts the first ciphertext in the message using its own private key to obtain a decrypted temporary key; encrypts the session key using the temporary public key in the message to obtain the second ciphertext; and uses the decrypted temporary key as the key for the message authentication code to generate a message authentication code containing the temporary public key, the first ciphertext, and the second ciphertext. A response message is then sent to respond to the broadcast first message, the response message containing the second ciphertext and the message authentication code. For example, but not limited to, the decrypted temporary key can be used as the key for the message authentication code to generate the temporary public key, the first ciphertext, and the second ciphertext.

[0056] In step 206, the requesting party A receives the response message, verifies the validity of the message verification code in the message based on its own generated temporary key, and if valid, obtains the second ciphertext from the response message and decrypts it to obtain the session key for communication with the other party B.

[0057] In an embodiment where the first message also contains a temporary public key, step 206 further includes the following steps: upon receiving the response message, requester A verifies the validity of the message verification code in the message based on the temporary key it generates. If valid, it decrypts the second ciphertext in the message using its own temporary private key to obtain the session key.

[0058] In another embodiment, step 206 is followed by the following steps: requester A encrypts its own signature using the obtained session key and sends the encrypted signature to the other party B; and the other party B decrypts the received encrypted signature using the session key and verifies the decrypted signature. If the verification is successful, the other party B uses the session key to communicate with requester A.

[0059] The second embodiment of this application relates to a key negotiation system, the structure of which is as follows: Figure 4 As shown, the key negotiation system includes requester A and requesting counterpart B.

[0060] The requesting party A includes a key generation unit, a first encryption unit, a broadcasting unit, a first receiving unit, and a session key determination unit. The key generation unit is configured to generate a temporary key; the first encryption unit is configured to encrypt the temporary key using the public key of the requesting party to obtain a first ciphertext; the broadcasting unit is configured to broadcast a first message containing the first ciphertext; the first receiving unit is configured to receive a response message from the requesting party; and the session key determination unit is configured to verify the validity of the message verification code in the response message based on the temporary key it generates, and if valid, to obtain the second ciphertext from the response message and decrypt it to obtain the session key.

[0061] The counterparty B includes a second receiving unit, a decryption unit, a message authentication code generation unit, and a sending unit. The second receiving unit is configured to receive a first broadcast message; the decryption unit is configured to use its own private key to decrypt the first ciphertext in the message to obtain a temporary decryption key; the message authentication code generation unit is configured to use the decrypted temporary key as a key to generate a message authentication code for the first message and the second ciphertext, the second ciphertext containing a session key with the requesting party; the sending unit is configured to send a response message in response to the first message, the response message containing the message authentication code and the second ciphertext.

[0062] In an embodiment where the first message also includes a temporary public key, the counterparty B further includes a second encryption unit. This second encryption unit uses the temporary public key in the message to encrypt the session key to obtain the second ciphertext. The message authentication code generation unit uses the decrypted temporary key as the key to generate a message authentication code for the temporary public key, the first ciphertext, and the second ciphertext. For example, but not limited to, the decrypted temporary key can be used as the key to generate the message authentication code for the temporary public key, the first ciphertext, and the second ciphertext based on a hash function or a pseudo-random function.

[0063] In an embodiment where the first message also includes a temporary public key, the session key determination unit in requester A verifies the validity of the message verification code in the response message based on the temporary key. If valid, it uses its own temporary private key to decrypt the second ciphertext in the message to obtain the session key.

[0064] In one embodiment, the first encryption unit is further configured to encrypt its own signature using the obtained session key, and the sender further includes a second sending unit configured to send the encrypted signature to the other party B. In this embodiment, the other party B further includes a signature verification unit, which decrypts the received encrypted signature using its own session key, and is configured to verify the decrypted signature. If the verification passes, the session key is used to communicate with the requesting party A.

[0065] In this embodiment, the broadcasting unit, transmitting unit, and receiving unit may use, for example but not limited to, the Bluetooth protocol.

[0066] The first embodiment is a method embodiment corresponding to this embodiment. The technical details in the first embodiment can be applied to this embodiment, and the technical details in this embodiment can also be applied to the first embodiment.

[0067] It should be noted that those skilled in the art should understand that the implementation functions of each module shown in the above-described key negotiation system implementation can be understood with reference to the relevant description of the aforementioned key negotiation method. The functions of each module shown in the above-described key negotiation system implementation can be implemented by a program (executable instructions) running on a processor, or by specific logic circuits. If the above-described key negotiation system in this application is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application embodiment, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, mobile hard drive, read-only memory (ROM), magnetic disk, or optical disk. Thus, this application embodiment is not limited to any specific hardware and software combination.

[0068] It should be noted that in this patent application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element. In this patent application, if it refers to performing an action according to an element, it means performing the action at least according to that element, including two cases: performing the action only according to that element, and performing the action according to that element and other elements. Expressions such as "multiple," "repeatedly," and "various" include two, two times, two kinds, and more than two, more than two times, and more than two kinds.

[0069] All documents mentioned in this application are considered to be incorporated integrally into the disclosure of this application so that they can serve as the basis for modifications if necessary. Furthermore, it should be understood that the above descriptions are merely preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A key negotiation method, characterized in that, The method includes the following steps: A requester generates a temporary key and a temporary public key and a temporary private key pair, encrypts the temporary key using the public key of the requesting party to obtain a first ciphertext, and broadcasts a first message containing the first ciphertext and the temporary public key; B. Upon receiving the first broadcast message, the other party decrypts the first ciphertext in the message using its private key to obtain a decryption temporary key, encrypts the session key using the temporary public key in the message to obtain a second ciphertext, and generates a message authentication code for the temporary public key, the first ciphertext, and the second ciphertext based on a hash function or pseudo-random function, using the decrypted temporary key as the key for the message authentication code, and sends a response message to respond to the first broadcast message, the response message containing the second ciphertext and the message authentication code; C. Upon receiving the response message, the requesting party verifies the validity of the message verification code in the message based on its own generated temporary key. If valid, it uses its own temporary private key to decrypt the second ciphertext in the message to obtain the session key.

2. The key negotiation method as described in claim 1, characterized in that, Following step C, the following steps are also included: The requesting party uses the obtained session key to encrypt its own signature and sends the encrypted signature to the other party; The other party uses the session key to decrypt the received encrypted signature and verifies the decrypted signature. If the verification is successful, the session key is used to communicate with the requesting party.

3. A key negotiation system, characterized in that, This includes both the requesting party and the party making the request; The requesting parties include: The key generation unit is configured to generate temporary keys as well as temporary public key and temporary private key pairs; The first encryption unit is configured to encrypt the temporary key using the public key of the requested counterparty to obtain the first ciphertext; The broadcast unit is configured to broadcast a first message containing the first ciphertext and the temporary public key; The first receiving unit is configured to receive a response message from the other party; The session key determination unit is configured to verify the validity of the message verification code in the response message based on the temporary key it generates. If the code is valid, it uses its own temporary private key to decrypt the second ciphertext in the message to obtain the session key. The other party includes: The second receiving unit is configured to receive the first message broadcast. The decryption unit is configured to use its own private key to decrypt the first ciphertext in the message to obtain a temporary decryption key; The second encryption unit is configured to encrypt the session key using the temporary public key in the message to obtain the second ciphertext; The message authentication code generation unit is configured to generate a message authentication code for the temporary public key, the first ciphertext, and the second ciphertext based on the decrypted temporary key using a hash function or a pseudo-random function as the key for the message authentication code. The sending unit is configured to send a response message in response to the first message of the broadcast, the response message containing the second ciphertext and the message authentication code.

Images