A key negotiation method, device and terminal

Abstract

The present invention provides a key negotiation method, device and terminal, wherein the key negotiation method includes: determining the first public key and the first private key of the calling terminal; obtaining the second public key of the called terminal according to the blockchain certificate of the called terminal; obtaining the shared key according to the first private key and the second public key; obtaining the calling message according to the first public key and the shared key, and sending it to the called terminal. This scheme can obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the calling message according to the first public key and the shared key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for the shared key negotiation; it well solves the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a key negotiation method, device and terminal. Background Art

[0002] IP-based multimedia communications (including IP-based voice transmission VoIP) have become the mainstream of real-time communications. Due to the connectionless and public access characteristics of IP networks, VoIP communications are vulnerable to various attacks, including the possibility of voice eavesdropping (violation of confidentiality) and voice data tampering (violation of integrity). In this regard, a series of standards have been developed to ensure the security of VoIP communications: [1] SRTP (Secure Real-time Transport Protocol) is defined to encrypt and integrity protect RTP (Real-time Transport Protocol) or RTCP (Real-time Transport Control Protocol) packets carrying multimedia; [2] A protocol framework is designed for both parties in VoIP communication to establish a shared key TGK (TEK (Traffic-Encrypting Key) Generation Key). TGK can further derive the key TEK (Traffic-encrypting key) used in SRTP to protect the security of RTP or RTCP packets.

[0003] Specifically, three methods for generating the key TGK are defined: (1) based on a pre-set key; (2) based on public key encryption to transmit the key TGK; (3) based on the DH (Diffie-Hellman) key exchange protocol negotiation to generate TGK.

[0004] The above-mentioned pre-set keys can only be used in a small range because they require pre-configuration on both sides of the communication. The methods for generating the key TGK used on a large scale are the methods (2) and (3) mentioned above. Among them, method (3) is based on the scheme for generating TGK through negotiation of the DH key exchange protocol, as shown in the following example. Figure 1 As shown:

[0005] This scheme mainly involves the exchange of DH public keys between the calling and the called. As shown in the figure, the calling party sends an I_MESSAGE message containing its DH public key to the called party. In response, the called party sends an R_MESSAGE message containing its DH public key to the calling party. Then both parties use the DH key agreement algorithm (logarithmic operation) to generate a shared key TGK.

[0006] The I_MESSAGE message includes: a message header HDR, a timestamp T, a random number RAND, a caller identity IDi and its certificate CERTi, a called identity IDr, a security policy identifier SP, a public key DHi, and a digital signature SIGNi for the entire message.

[0007] The timestamp T is used to prevent replay attacks, and the random number RAND is used to increase the freshness of the key TEK when the key TEK is derived from the key TGK. The caller generates a random number xi as the DH private key and calculates the corresponding public key DHi=g xi The caller uses the private key corresponding to the public key in its certificate to sign the I_MESSAGE message to generate SIGNi to ensure that it has not been tampered with.

[0008] After receiving the I_MESSAGE message, the called party verifies the digital signature using the public key in the calling party's certificate to ensure that the received public key DHi has not been tampered with. The called party generates a random number xr as the DH private key and calculates the corresponding public key DHr = g xr The called party generates a key TGK by using its own private key xr and the caller's public key DHi to perform a DH operation, that is, TGK = g xrxi .

[0009] The called party generates an R_MESSAGE message, which includes a message header HDR, a timestamp T, a random number RAND, the called party's identity IDr and its certificate CERTr, the calling party's identity IDi, the called party's public key DHr, the calling party's public key DHi, and a digital signature SIGNi for the entire message.

[0010] After receiving the R_MESSAGE message, the caller verifies the digital signature using the public key in the called party's certificate to ensure that the received public key DHr has not been tampered with. The caller generates a key TGK by performing a DH operation using its own private key xi and the called party's public key DHr, that is, TGK = g xixr .

[0011] The entire solution is completely dependent on PKI (Public Key Infrastructure). The caller needs to use his private key to sign the entire message. The called party needs to use the caller's public key to verify the message. In addition to the signature requiring an asymmetric algorithm to perform calculations, the DH operation is also an asymmetric algorithm operation. Therefore, both the caller and the called party need to use the asymmetric key algorithm to perform calculations twice.

[0012] However, for the above method (3), since there are multiple CAs (authorization centers) in the actual public key infrastructure PKI, the existence of multiple CAs brings about the problem of mutual trust between CAs; and both the caller and the called party need to use the asymmetric key algorithm twice for calculation, resulting in a large amount of calculation; in addition, the caller and the called party need to complete two message exchanges to generate the key TGK, resulting in a long delay.

[0013] From the above, we can see that the existing shared key negotiation schemes have problems such as small application scope, mutual trust issues between CAs, large amount of calculation, and long delay. Summary of the invention

[0014] The purpose of the present invention is to provide a key negotiation method, device and terminal to solve the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0015] In order to solve the above technical problems, an embodiment of the present invention provides a key negotiation method, which is applied to a calling terminal and includes:

[0016] Determining a first public key and a first private key of the calling terminal;

[0017] Obtaining a second public key of the called terminal according to the blockchain certificate of the called terminal;

[0018] Obtain a shared key according to the first private key and the second public key;

[0019] A calling message is obtained according to the first public key and the shared key, and sent to the called terminal.

[0020] Optionally, obtaining the second public key of the called terminal according to the blockchain certificate of the called terminal includes:

[0021] According to the identity identifier of the called terminal, obtaining the blockchain certificate of the called terminal from the blockchain;

[0022] A second public key of the called terminal is obtained according to the blockchain certificate.

[0023] Optionally, the calling message includes a message authentication code;

[0024] The obtaining the calling message according to the first public key and the shared key includes:

[0025] The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling party identity identifier, the called party identity identifier, the security policy identifier and the first public key.

[0026] Optionally, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key includes:

[0027] Formula 1 is used to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0028] Wherein, the formula 1 is:

[0029] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0030] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0031] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0032] The embodiment of the present invention further provides a key negotiation method, which is applied to a called terminal and includes:

[0033] Receiving a calling message sent by a calling terminal;

[0034] Obtaining a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0035] Verifying the message authentication code in the calling message according to the shared key;

[0036] When the verification is successful, the shared key is confirmed to be the target shared key.

[0037] Optionally, the message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key.

[0038] Optionally, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0039] Wherein, the formula 1 is:

[0040] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0041] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0042] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0043] Optionally, before receiving the calling message sent by the calling terminal, the method further includes:

[0044] The second public key and identity of the called terminal are written into the blockchain in the form of a blockchain certificate.

[0045] The embodiment of the present invention further provides a key negotiation device, which is applied to a calling terminal and includes:

[0046] A first determination module, used to determine a first public key and a first private key of the calling terminal;

[0047] A first processing module, configured to obtain a second public key of the called terminal according to the blockchain certificate of the called terminal;

[0048] A second processing module, configured to obtain a shared key according to the first private key and the second public key;

[0049] The third processing module is used to obtain a calling message according to the first public key and the shared key, and send the message to the called terminal.

[0050] Optionally, the first processing module includes:

[0051] A first acquisition submodule, configured to acquire a blockchain certificate of the called terminal from the blockchain according to the identity identifier of the called terminal;

[0052] The first processing submodule is used to obtain the second public key of the called terminal according to the blockchain certificate.

[0053] Optionally, the calling message includes a message authentication code;

[0054] The third processing module comprises:

[0055] The second processing submodule is used to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key.

[0056] Optionally, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key includes:

[0057] Formula 1 is used to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0058] Wherein, the formula 1 is:

[0059] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0060] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0061] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0062] The embodiment of the present invention further provides a key negotiation device, which is applied to a called terminal and includes:

[0063] A first receiving module, used for receiving a calling message sent by a calling terminal;

[0064] a fourth processing module, configured to obtain a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0065] A first verification module, used to verify the message authentication code in the calling message according to the shared key;

[0066] The first confirmation module is used to confirm that the shared key is a target shared key when the verification passes.

[0067] Optionally, the message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key.

[0068] Optionally, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0069] Wherein, the formula 1 is:

[0070] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0071] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0072] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0073] Optionally, also include:

[0074] The fifth processing module is used to write the second public key and identity of the called terminal into the blockchain in the form of a blockchain certificate before receiving the calling message sent by the calling terminal.

[0075] The embodiment of the present invention further provides a terminal, the terminal is a calling terminal, and the terminal includes: a processor and a transceiver;

[0076] The processor is used to determine a first public key and a first private key of the calling terminal;

[0077] Obtaining a second public key of the called terminal according to the blockchain certificate of the called terminal;

[0078] Obtain a shared key according to the first private key and the second public key;

[0079] A calling message is obtained according to the first public key and the shared key, and is sent to the called terminal by using the transceiver.

[0080] Optionally, the processor is specifically configured to:

[0081] According to the identity identifier of the called terminal, obtaining the blockchain certificate of the called terminal from the blockchain;

[0082] A second public key of the called terminal is obtained according to the blockchain certificate.

[0083] Optionally, the calling message includes a message authentication code;

[0084] The obtaining the calling message according to the first public key and the shared key includes:

[0085] The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling party identity identifier, the called party identity identifier, the security policy identifier and the first public key.

[0086] Optionally, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key includes:

[0087] Formula 1 is used to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0088] Wherein, the formula 1 is:

[0089] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0090] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0091] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0092] An embodiment of the present invention further provides a terminal, which is a called terminal and includes: a processor and a transceiver;

[0093] The processor is used to receive a calling message sent by a calling terminal through the transceiver;

[0094] Obtaining a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0095] Verifying the message authentication code in the calling message according to the shared key;

[0096] When the verification is successful, the shared key is confirmed to be the target shared key.

[0097] Optionally, the message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key.

[0098] Optionally, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key;

[0099] Wherein, the formula 1 is:

[0100] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0101] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0102] Optionally, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0103] Optionally, the processor is further configured to:

[0104] Before receiving the calling message sent by the calling terminal, the second public key and identity of the called terminal are written into the blockchain in the form of a blockchain certificate.

[0105] An embodiment of the present invention also provides a terminal, including a memory, a processor, and a program stored in the memory and executable on the processor; when the processor executes the program, the key negotiation method on the calling terminal side is implemented; or, when the processor executes the program, the key negotiation method on the called terminal side is implemented.

[0106] An embodiment of the present invention also provides a readable storage medium on which a program is stored. When the program is executed by a processor, the steps in the key negotiation method on the calling terminal side are implemented; or, when the program is executed by a processor, the steps in the key negotiation method on the called terminal side are implemented.

[0107] The beneficial effects of the above technical solution of the present invention are as follows:

[0108] In the above scheme, the key negotiation method determines the first public key and the first private key of the calling terminal; obtains the second public key of the called terminal according to the blockchain certificate of the called terminal; obtains the shared key according to the first private key and the second public key; obtains the calling message according to the first public key and the shared key, and sends it to the called terminal; it is possible to obtain information based on the blockchain certificate, thereby avoiding the problem of mutual trust between multiple CAs; in addition, this scheme can directly obtain the calling message according to the first public key and the shared key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme can support the implementation of not requiring the called terminal to feedback the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it is a good solution to the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] Figure 1 It is a schematic diagram of a key agreement scheme in the prior art;

[0110] Figure 2 The key negotiation method according to the embodiment of the present invention is shown in FIG. Figure 1 ;

[0111] Figure 3 The key negotiation method according to the embodiment of the present invention is shown in FIG. Figure 2 ;

[0112] Figure 4 A schematic diagram of a specific implementation flow of the key negotiation method according to an embodiment of the present invention;

[0113] Figure 5 The structure of the key agreement device according to the embodiment of the present invention is shown as follows Figure 1 ;

[0114] Figure 6 The structure of the key agreement device according to the embodiment of the present invention is shown as follows Figure 2 ;

[0115] Figure 7 The terminal structure of the embodiment of the present invention is shown in FIG. Figure 1 ;

[0116] Figure 8 The terminal structure of the embodiment of the present invention is shown in FIG. Figure 2 . DETAILED DESCRIPTION

[0117] In order to make the technical problems, technical solutions and advantages to be solved by the present invention more clear, a detailed description will be given below with reference to the accompanying drawings and specific embodiments.

[0118] In view of the problems of mutual trust between CAs and large amount of computation in the shared key negotiation scheme in the prior art, the present invention provides a key negotiation method, which is applied to a calling terminal, such as Figure 2 As shown, including:

[0119] Step 21: Determine the first public key and the first private key of the calling terminal;

[0120] Step 22: Obtain the second public key of the called terminal according to the blockchain certificate of the called terminal;

[0121] Step 23: Obtain a shared key according to the first private key and the second public key;

[0122] Step 24: Obtain a calling message according to the first public key and the shared key, and send the message to the called terminal.

[0123] Among them, the first public key can specifically be a first DH (Diffie-Hellman) public key, the first private key can specifically be a first DH private key, the second public key can specifically be a second DH public key, and the second private key involved below can specifically be a second DH private key, but is not limited to this.

[0124] The key negotiation method provided in the embodiment of the present invention determines the first public key and the first private key of the calling terminal; obtains the second public key of the called terminal according to the blockchain certificate of the called terminal; obtains the shared key according to the first private key and the second public key; obtains the calling message according to the first public key and the shared key, and sends it to the called terminal; it is possible to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the calling message according to the first public key and the shared key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme can support the implementation of not requiring the called terminal to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it is a good solution to the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0125] Among them, obtaining the second public key of the called terminal according to the blockchain certificate of the called terminal includes: obtaining the blockchain certificate of the called terminal from the blockchain according to the identity identifier of the called terminal; and obtaining the second public key of the called terminal according to the blockchain certificate.

[0126] In an embodiment of the present invention, the calling message includes a message authentication code; obtaining the calling message based on the first public key and the shared key includes: obtaining the message authentication code based on the shared key, message header, timestamp, random number, calling identity, called identity, security policy identifier and the first public key.

[0127] The message authentication code MAC can be used by the called terminal to verify the integrity of the calling message.

[0128] Specifically, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key includes: using formula 1 to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0129] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0130] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0131] The timestamp T can be used to prevent replay attacks, and the random number RAND can be used to increase the freshness of the calling message.

[0132] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0133] The determining of the first public key and the first private key of the calling terminal includes: generating a random number as the first private key; and obtaining the first public key according to the first private key.

[0134] Specifically, obtaining the first public key according to the first private key includes: using formula 1 to obtain the first public key according to the first private key; wherein the formula 1 is: DHi = g xi ; DHi represents the first public key; g represents a constant, and xi represents the first private key.

[0135] In the embodiment of the present invention, obtaining a shared key according to the first private key and the second public key includes: using Formula 2 and Formula 3 to obtain a shared key according to the first private key and the second public key; wherein Formula 2 and Formula 3 are respectively: DHr = g xr ;

[0136] TGK=(DHr) xi =g xrxi ; TGK represents the shared key; xi represents the first private key; DHr represents the second public key; xr represents the random number generated by the called terminal.

[0137] The embodiment of the present invention also provides a key negotiation method, which is applied to a called terminal, such as Figure 3 As shown, including:

[0138] Step 31: receiving a calling message sent by the calling terminal;

[0139] Step 32: Obtain a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0140] Step 33: Verify the message authentication code in the calling message according to the shared key;

[0141] Step 34: If the verification is successful, confirm that the shared key is the target shared key.

[0142] Among them, the second private key can specifically be the second DH private key, the first public key can specifically be the first DH public key, the first private key involved below can specifically be the first DH private key, and the second public key can specifically be the second DH public key, but it is not limited to this.

[0143] The key negotiation method provided by the embodiment of the present invention receives a calling message sent by a calling terminal; obtains a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; verifies the message authentication code in the calling message according to the shared key; and confirms that the shared key is the target shared key when the verification passes; can support the calling terminal to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the shared key from the second private key and the first public key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme does not need to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it well solves the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0144] The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key.

[0145] Specifically, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0146] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0147] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0148] The timestamp T can be used to prevent replay attacks, and the random number RAND can be used to increase the freshness of the calling message.

[0149] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0150] Furthermore, before receiving the calling message sent by the calling terminal, it also includes: writing the second public key and identity identifier of the called terminal into the blockchain in the form of a blockchain certificate.

[0151] This can further support the calling terminal to use blockchain certificates to obtain information to solve the mutual trust problem between multiple CAs.

[0152] The key negotiation method provided by the embodiment of the present invention is further described below in conjunction with multiple sides such as a calling terminal and a called terminal. The shared key takes the key TGK as an example, and the first public key, the first private key, the second public key and the second private key are all taken as DH keys as an example.

[0153] In response to the above technical problems, an embodiment of the present invention provides a key negotiation method, which can be specifically implemented as a blockchain-based (DH) key negotiation scheme, involving: the user's DH public key and its identity identifier are written to the blockchain in the form of a blockchain certificate (for the blockchain certificate format and the management method of the blockchain certificate, please refer to the existing method, which will not be repeated here). Before the calling terminal sends the I_MESSAGE message (i.e. the above-mentioned calling message), it generates its own DH public-private key pair (i.e. the above-mentioned first public key and the first private key), and can also find the blockchain certificate corresponding to the called terminal from the blockchain, and use the DH public key in the blockchain certificate (i.e. the above-mentioned second public key) and its own private key (i.e. the above-mentioned first private key) to generate the key TGK (i.e. the above-mentioned shared key); and use TGK to perform integrity protection on the entire I_MESSAGE message (specifically, MAC can be generated using TGK). After the called terminal receives the I_MESSAGE message, it uses the private key corresponding to the DH public key on its own blockchain certificate (that is, the above-mentioned second public key) (that is, the above-mentioned second private key) and the received DH public key of the caller (that is, the above-mentioned first public key) to generate the DH key TGK, and uses the key TGK to verify the integrity of the message (specifically, it can be used to verify MAC), so that the calling and called parties can obtain the shared key TGK.

[0154] Specifically, the solution provided by the embodiment of the present invention can be as follows Figure 4 As shown, the calling terminal sends an I_MESSAGE message to the called terminal, which specifically involves:

[0155] First, the initial condition: the DH public key and identity of each user (i.e., terminal) are written to the blockchain in the form of a blockchain certificate; it can be written by the user himself or by the operator, and there is no limitation here.

[0156] Secondly, the blockchain-based DH key negotiation process includes:

[0157] (1) Before sending the I_MESSAGE message, the calling terminal generates a random number xi as the DH private key (i.e., the first private key mentioned above), and calculates the corresponding public key (i.e., the first public key mentioned above) DHi=g xi The calling terminal finds the blockchain certificate of the called terminal from the blockchain, and obtains the DH public key DHr of the called terminal from the blockchain certificate (that is, the second public key mentioned above, specifically DHr = g xr , where xr is a random number generated by the called terminal side), and uses its own private key (i.e. the first private key mentioned above) and the DH public key of the called terminal (i.e. the second public key mentioned above) to generate a key TGK=g xrxi ;

[0158] (2) The calling terminal generates an I_MESSAGE message based on its own public key (i.e., the first public key) and the key TGK, and sends it to the called terminal. Specifically, the I_MESSAGE message includes: a message header HDR, a timestamp T, a random number RAND, a calling identity IDi and a called identity IDr, a security policy identifier SP, and a public key DHi. Specifically, the entire message is protected by the key TGK for integrity. Specifically, TGK can be used to perform integrity calculation to obtain MAC. The formula for calculating MAC can be as follows:

[0159] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0160] Here, HASH is a hash function, such as SHA-256. ║ represents an information concatenation symbol, which is used to indicate the concatenation of information.

[0161] (3) After receiving the I_MESSAGE message, the called terminal uses its own private key (i.e., the second private key) and the received public key DHi (i.e., the first public key) to generate a key TGK. Specifically, TGK = (DHi) xr =g xixr , and then use the key TGK to verify the MAC. If the verification is successful, it means that the I_MESSAGE message has not been tampered with and the received key TGK is correct; thus both the caller and the called party know the key TGK.

[0162] In the embodiment of the present invention, the called terminal no longer returns an R_MESSAGE message (ie, a called message corresponding to the calling message) to the calling terminal.

[0163] As can be seen from the above, in the solution provided by the embodiment of the present invention: the DH public key and identity of each user are written into the blockchain in the form of a blockchain certificate, thereby solving the multi-CA trust problem; since the key TGK is used to protect the integrity of the I_MESSAGE message instead of using a digital signature, the amount of calculation is significantly reduced compared to the existing DH key agreement scheme; since the caller and the called party only need to perform the operation of the asymmetric key algorithm once, and since the DH public key of the called party on the blockchain is directly used to generate the key TGK, the R_MESSAGE message is omitted, thereby reducing the communication delay.

[0164] The embodiment of the present invention also provides a key negotiation device, which is applied to a calling terminal, such as Figure 5 As shown, including:

[0165] A first determining module 51, configured to determine a first public key and a first private key of the calling terminal;

[0166] A first processing module 52 is used to obtain a second public key of the called terminal according to the blockchain certificate of the called terminal;

[0167] A second processing module 53, configured to obtain a shared key according to the first private key and the second public key;

[0168] The third processing module 54 is used to obtain a calling message according to the first public key and the shared key, and send the message to the called terminal.

[0169] The key negotiation device provided by the embodiment of the present invention determines the first public key and the first private key of the calling terminal; obtains the second public key of the called terminal according to the blockchain certificate of the called terminal; obtains the shared key according to the first private key and the second public key; obtains the calling message according to the first public key and the shared key, and sends it to the called terminal; it is possible to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the calling message according to the first public key and the shared key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured, so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme can support the implementation of not requiring the called terminal to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it is a good solution to the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0170] Among them, the first processing module includes: a first acquisition submodule, used to obtain the blockchain certificate of the called terminal from the blockchain according to the identity identification of the called terminal; a first processing submodule, used to obtain the second public key of the called terminal according to the blockchain certificate.

[0171] In an embodiment of the present invention, the calling message includes a message authentication code; the third processing module includes: a second processing sub-module, used to obtain the message authentication code based on the shared key, message header, timestamp, random number, calling identity, called identity, security policy identifier and first public key.

[0172] Specifically, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key includes: using formula 1 to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0173] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0174] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0175] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0176] Among them, the implementation embodiments of the key negotiation method on the calling terminal side are all applicable to the embodiments of the key negotiation device and can achieve the same technical effect.

[0177] The embodiment of the present invention also provides a key negotiation device, which is applied to a called terminal, such as Figure 6 As shown, including:

[0178] The first receiving module 61 is used to receive a calling message sent by a calling terminal;

[0179] A fourth processing module 62, configured to obtain a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0180] A first verification module 63, configured to verify the message authentication code in the calling message according to the shared key;

[0181] The first confirmation module 64 is used to confirm that the shared key is a target shared key when the verification is successful.

[0182] The key negotiation device provided by the embodiment of the present invention receives a calling message sent by a calling terminal; obtains a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; verifies the message authentication code in the calling message according to the shared key; and confirms that the shared key is the target shared key when the verification is passed; can support the calling terminal to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the shared key by using the second private key and the first public key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme does not need to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it well solves the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0183] The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key.

[0184] Specifically, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0185] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0186] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0187] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0188] Furthermore, the key agreement device also includes: a fifth processing module, which is used to write the second public key and identity of the called terminal into the blockchain in the form of a blockchain certificate before receiving the calling message sent by the calling terminal.

[0189] Among them, the implementation embodiments of the key negotiation method on the called terminal side are all applicable to the embodiments of the key negotiation device and can achieve the same technical effect.

[0190] The embodiment of the present invention further provides a terminal, wherein the terminal is a calling terminal, such as Figure 7 As shown, the terminal includes: a processor 71 and a transceiver 72;

[0191] The processor 71 is used to determine the first public key and the first private key of the calling terminal;

[0192] Obtaining a second public key of the called terminal according to the blockchain certificate of the called terminal;

[0193] Obtain a shared key according to the first private key and the second public key;

[0194] The calling message is obtained according to the first public key and the shared key, and is sent to the called terminal by using the transceiver 72 .

[0195] The terminal provided in the embodiment of the present invention determines the first public key and the first private key of the calling terminal; obtains the second public key of the called terminal according to the blockchain certificate of the called terminal; obtains the shared key according to the first private key and the second public key; obtains the calling message according to the first public key and the shared key, and sends it to the called terminal; it is possible to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the calling message according to the first public key and the shared key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured, so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme can support the implementation of not requiring the called terminal to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it is a good solution to the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0196] The processor is specifically used to: obtain a blockchain certificate of the called terminal from the blockchain according to the identity identifier of the called terminal; and obtain a second public key of the called terminal according to the blockchain certificate.

[0197] In an embodiment of the present invention, the calling message includes a message authentication code; obtaining the calling message based on the first public key and the shared key includes: obtaining the message authentication code based on the shared key, message header, timestamp, random number, calling identity, called identity, security policy identifier and the first public key.

[0198] Specifically, obtaining the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key includes: using formula 1 to obtain the message authentication code according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0199] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0200] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0201] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0202] Among them, the implementation embodiments of the key negotiation method on the calling terminal side are all applicable to the embodiments of the terminal and can achieve the same technical effect.

[0203] The embodiment of the present invention further provides a terminal, which is a called terminal. Figure 8 As shown, the terminal includes: a processor 81 and a transceiver 82;

[0204] The processor 81 is used to receive a calling message sent by a calling terminal through the transceiver 82;

[0205] Obtaining a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message;

[0206] Verifying the message authentication code in the calling message according to the shared key;

[0207] When the verification is successful, the shared key is confirmed to be the target shared key.

[0208] The terminal provided in the embodiment of the present invention receives a calling message sent by a calling terminal; obtains a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; verifies the message authentication code in the calling message according to the shared key; and confirms that the shared key is the target shared key when the verification is passed; can support the calling terminal to obtain information based on the blockchain certificate, thereby avoiding the mutual trust problem between multiple CAs; in addition, this scheme can directly obtain the shared key by using the second private key and the first public key, and no longer needs to use the asymmetric key algorithm twice for calculation, thereby reducing the amount of calculation for shared key negotiation; in addition, this scheme no longer needs to be pre-configured so that it can be applicable to various shared key negotiation scenarios, thereby ensuring the scope of application; further, this scheme does not need to feed back the corresponding called message to the calling terminal, thereby avoiding resource waste and reducing communication delay; it well solves the problems of mutual trust between CAs and large amount of calculation in the shared key negotiation scheme in the prior art.

[0209] The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key.

[0210] Specifically, the message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the caller identity, the called identity, the security policy identifier and the first public key; wherein the formula 1 is:

[0211] MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi);

[0212] MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

[0213] In the embodiment of the present invention, the calling message further includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

[0214] Furthermore, the processor is also used to: before receiving the calling message sent by the calling terminal, write the second public key and identity of the called terminal into the blockchain in the form of a blockchain certificate.

[0215] Among them, the implementation embodiments of the key negotiation method on the called terminal side are all applicable to the embodiments of the terminal and can achieve the same technical effect.

[0216] An embodiment of the present invention also provides a terminal, including a memory, a processor, and a program stored in the memory and executable on the processor; when the processor executes the program, the key negotiation method on the calling terminal side is implemented; or, when the processor executes the program, the key negotiation method on the called terminal side is implemented.

[0217] Among them, the implementation embodiments of the key negotiation method on the calling terminal side or the called terminal side are all applicable to the embodiments of the terminal and can also achieve the corresponding same technical effects.

[0218] An embodiment of the present invention also provides a readable storage medium on which a program is stored. When the program is executed by a processor, the steps in the key negotiation method on the calling terminal side are implemented; or, when the program is executed by a processor, the steps in the key negotiation method on the called terminal side are implemented.

[0219] Among them, the implementation embodiments of the key negotiation method on the calling terminal side or the called terminal side are all applicable to the embodiments of the readable storage medium, and can also achieve the corresponding same technical effects.

[0220] It should be noted that many functional components described in this specification are referred to as modules / sub-modules in order to more particularly emphasize the independence of their implementation methods.

[0221] In the embodiment of the present invention, module / submodule can be implemented with software so that it can be performed by various types of processors. For example, an executable code module of an identification can include one or more physical or logical blocks of computer instructions, for example, it can be constructed as an object, process or function. Nevertheless, the executable code of the identified module does not need to be physically located together, but can include different instructions stored in different positions, and when these instructions are logically combined together, it constitutes a module and realizes the specified purpose of this module.

[0222] In fact, executable code module can be a single instruction or many instructions, and can even be distributed on a plurality of different code segments, distributed among different programs, and distributed across a plurality of memory devices. Similarly, operating data can be identified in the module, and can be implemented and organized in the data structure of any appropriate type according to any appropriate form. The operating data can be collected as a single data set, or can be distributed in different locations (including on different storage devices), and can only be present on a system or network as an electronic signal at least in part.

[0223] When a module can be implemented by software, considering the level of existing hardware technology, a person skilled in the art can build a corresponding hardware circuit to implement the corresponding function of the module that can be implemented by software without considering the cost. The hardware circuit includes a conventional very large scale integration (VLSI) circuit or gate array and existing semiconductors such as logic chips, transistors, or other discrete components. The module can also be implemented by a programmable hardware device, such as a field programmable gate array, a programmable array logic, a programmable logic device, etc.

[0224] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary personnel in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A key negotiation method, applied to a called terminal, characterized in that: include: Receiving a calling message sent by a calling terminal; Obtaining a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; Verifying the message authentication code in the calling message according to the shared key; When the verification is successful, the shared key is confirmed to be the target shared key.

2. The key negotiation method according to claim 1, characterized in that: The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling party identity identifier, the called party identity identifier, the security policy identifier and the first public key.

3. The key negotiation method according to claim 2, characterized in that: The message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key; Wherein, the formula 1 is: MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi); MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

4. The key negotiation method according to claim 2 or 3, characterized in that: The calling message also includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

5. The key negotiation method according to claim 1, characterized in that: Before receiving the calling message sent by the calling terminal, the method further includes: The second public key and identity of the called terminal are written into the blockchain in the form of a blockchain certificate.

6. A key negotiation device, applied to a called terminal, characterized in that: include: A first receiving module, used for receiving a calling message sent by a calling terminal; a fourth processing module, configured to obtain a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; A first verification module, used to verify the message authentication code in the calling message according to the shared key; The first confirmation module is used to confirm that the shared key is a target shared key when the verification passes.

7. The key agreement device according to claim 6, characterized in that: The message authentication code is obtained according to the shared key, the message header, the timestamp, the random number, the calling party identity identifier, the called party identity identifier, the security policy identifier and the first public key.

8. The key agreement device according to claim 7, characterized in that: The message authentication code is obtained by using formula 1 according to the shared key, the message header, the timestamp, the random number, the calling identity, the called identity, the security policy identifier and the first public key; Wherein, the formula 1 is: MAC=HASH(TGK,HDR║T║RAND║[IDi]║[IDr]║{SP}║DHi); MAC represents the message authentication code; HASH represents the hash function; TGK represents the shared key; HDR represents the message header; T represents the timestamp; RAND represents the random number; [IDi] represents the caller identity; [IDr] represents the called identity; {SP} represents the security policy identifier; DHi represents the first public key; ║ represents the information concatenation character.

9. The key agreement device according to claim 7 or 8, characterized in that: The calling message also includes the shared key, a message header, a timestamp, a random number, a calling identity, a called identity, a security policy identifier and a first public key.

10. The key agreement device according to claim 6, characterized in that: Also includes: The fifth processing module is used to write the second public key and identity of the called terminal into the blockchain in the form of a blockchain certificate before receiving the calling message sent by the calling terminal.

11. A terminal, the terminal being a called terminal, characterized in that: The terminal includes: a processor and a transceiver; The processor is used to receive a calling message sent by a calling terminal through the transceiver; Obtaining a shared key according to the second private key of the called terminal and the first public key of the calling terminal in the calling message; Verifying the message authentication code in the calling message according to the shared key; When the verification is successful, the shared key is confirmed to be the target shared key.

12. A terminal comprising a memory, a processor, and a program stored in the memory and executable on the processor; characterized in that: When the processor executes the program, the key negotiation method according to any one of claims 1 to 5 is implemented.

13. A readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the steps in the key negotiation method according to any one of claims 1 to 5 are implemented.

Images