Authenticable key exchange method and application based on SM2 signature

Abstract

The invention discloses an authenticable key exchange method and application based on SM2 signature. The method comprises the following steps: a communication participant negotiates to select an elliptic curve and a base point and discloses parameters; each participant generates a private key and a corresponding public key, and the public keys are exchanged through a communication channel; carrying out key negotiation based on elliptic curve point multiplication operation to generate a shared key; each participant signs the related information of the shared key or the public key by using an SM2 signature method to generate a signature result; and the participant verifies the validity of the signature by using the public key of the opposite side through exchanging the signature result and related parameters, thereby realizing identity authentication and key integrity verification. According to the SM2 signature method, a public key and signature parameters are generated through elliptic curve point multiplication operation, and signature and verification are achieved based on the asymmetric relation between a private key and the public key. According to the invention, communication party identity authentication, data integrity verification and key confidentiality protection are realized, and the security and efficiency of key exchange in a cloud computing environment are improved.

Description

Technical Field

[0001] The present invention belongs to the field of data security technology, and in particular relates to an SM2 signature-based authenticated key exchange method in the field of data security. Background Art

[0002] In the field of network communications, key exchange is a core component of ensuring secure data transmission. The traditional Diffie-Hellman (DH) key exchange method, based on the finite field discrete logarithm problem, can generate a shared key through negotiation to ensure the integrity of transmitted data. However, this method lacks an authentication mechanism and cannot verify the true identities of the communicating parties, making it vulnerable to man-in-the-middle attacks—attackers can intercept and replace the public keys of both communicating parties, forge the shared key, and then steal or tamper with data.

[0003] In addition, the DH method relies on large prime number modular exponentiation operations, which has high computational complexity. As the key length increases, the computational efficiency decreases significantly, and key management requires additional mechanism support, resulting in high system complexity and cost.

[0004] On the other hand, in cloud computing environments, data must be frequently transferred between users, applications, and servers. However, the untrustworthy nature of cloud environments exacerbates the security challenges of key exchange. When users upload sensitive data to cloud servers, traditional methods cannot verify the trustworthiness of cloud servers, potentially resulting in data being stored on untrusted servers or being eavesdropped or tampered with. When two users communicate through a cloud server, transmitted data can be intercepted, tampered with, or forged, leaving the recipient unable to verify the authenticity of the data's source. For example, a user could mistakenly upload data to a disguised, untrusted cloud server, or a cloud server could tamper with messages during communication as an intermediary. Traditional DH methods, lacking authentication mechanisms, are unable to detect such attacks.

[0005] The SM2 method independently developed in China is based on the elliptic curve discrete logarithm problem (ECDLP). At the same security level, it has a shorter key length (for example, a 256-bit elliptic curve key is as secure as a 3072-bit RSA key), higher computational efficiency, and digital signature capabilities.

[0006] However, existing SM2-based key exchange schemes are mostly limited to one-party authentication or simple two-party scenarios. When communicating with multiple parties (such as three parties relaying through an untrusted cloud server), they lack efficient identity authentication and key negotiation mechanisms, making it difficult to balance security and communication efficiency.

[0007] In addition, how to deeply integrate the SM2 signature method with the key exchange process to achieve non-interactive authentication and reduce communication rounds is still a gap in existing technology. Summary of the Invention

[0008] The purpose of the present invention is to provide an authenticated key exchange method based on SM2 signature, which solves the defect of the traditional method lacking identity authentication by introducing the SM2 digital signature mechanism in the key negotiation process; reduces the computational complexity by utilizing the high efficiency of elliptic curve point multiplication operation; designs a two-party authenticated key exchange process to ensure the trusted interaction between the user and the cloud server, and designs a three-party authenticated process to support the secure communication between two users through an untrusted cloud server, realizes the identity authentication of the communicating parties, data integrity verification and key confidentiality protection, and improves the security and efficiency of key exchange in the cloud computing environment.

[0009] According to a first main aspect of the present invention, a method for authenticated key exchange based on SM2 signature is provided, comprising the following steps:

[0010] The communication participants negotiate to select an elliptic curve and base point and disclose the parameters; each participant generates a private key and a corresponding public key, and exchanges the public key through the communication channel; and then performs key negotiation based on the elliptic curve point multiplication operation to generate a shared key;

[0011] Each participant uses the SM2 signature method to sign the shared key or public key related information to generate a signature result;

[0012] The participants exchange signature results and related parameters, and use the other party's public key to verify the validity of the signature, thus achieving identity authentication and key integrity verification;

[0013] Among them, the SM2 signature method generates a public key and signature parameters through elliptic curve point multiplication operations, and realizes signature and verification based on the asymmetric relationship between the private key and the public key. Specifically, it includes: using the private key to perform elliptic curve point operations on the message hash value to generate signature parameters, and using the public key to perform elliptic curve point operations and hash verification on the signature parameters to realize signature verification.

[0014] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, when the method is applied to a two-party authenticated key exchange scenario, the specific steps include:

[0015] Both parties choose an elliptic curve E and a base point G, and make the parameters of E and G public; each party chooses a private key SK A SK B , calculate the public key PK A =SK A G, PK B =SK B G and exchange;

[0016] Through K=SK A ·PK B =SK B ·PK A Negotiate a shared key K;

[0017] Each party performs an SM2 signature on K: calculate the message hash value e = Hash(K) and convert it to a large integer, generate a random number g∈[1,n-1], calculate the elliptic curve point R = g·G, and generate signature parameters (r,s) through r = (e+Rx) mod n and s = [(1+SK)-1·(gr·SK)] mod n. If r = 0, r+g = n, or s = 0, regenerate a random number to obtain the signature results SA = (rA, sA) and SB = (rB, sB).

[0018] After exchanging signatures and K, the verifier checks r and s∈[1,n-1], calculates e=Hash(K), and calculates t=(r+s)modn. If t=0, the verification fails. The elliptic curve point R=s·G+PK is calculated, and the signature validity is verified by verifying v=(e+Rx)modn=r.

[0019] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, when the method is applied to a three-party authenticated key exchange scenario, the specific steps include:

[0020] User 1 generates a private key SK C and public key PK C =SK C G, for PK C The hash value h C =Hash(PK C )Execute SM2 signature:

[0021] Calculate e=Hash(h C ) and convert it into a large integer, generate a random number g∈[1,n-1], calculate R=g·G, and use r=(e+Rx)modn, s=[(1+SK C )-1·(gr·SK C )]modn generates a signature SC=(r,s). If r=0, r+g=n or s=0, a new random number is generated and SC, PK C 、h C Send to the intermediary;

[0022] Transfer party verification Hash (PK C )=h C To confirm that the public key has not been tampered with, by verifying r, s∈[1,n-1], calculating t=(r+s)modn, R=s·G+PK C 、v=(e+Rx)modn=r After verifying the validity of SC, PK C , SC and h C1 =Hash(PK C ) forwarded to user 2;

[0023] Second user verification and To confirm that the transmission has not been tampered with, repeat the SC verification process of the transfer party and pass K=SK A ·PK C Negotiate a shared key, generate a random number g∈[1,n-1] and calculate C1=g·G, and pass g·PK C =(x2,y2), t=KDF(x2y2,klen), C2=K⊕t, C3=Hash(x2Ky2) to generate ciphertext C=C1C2C3, which is transmitted to user 1 via the intermediary;

[0024] User 1 extracts C1 to verify the elliptic curve equation and calculates SK C C1 = (x2, y2). Obtain K after verification using t = KDF(x2y2, klen), K = C2⊕t, and Hash(x2Ky2) = C3.

[0025] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, the elliptic curve is a prime field elliptic curve, the base point G is a non-infinity point on the elliptic curve, the order of the elliptic curve is a prime number n, the private key SK is a random number in [1, n-1], and the public key is generated by the point multiplication operation of the private key and the base point.

[0026] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, the shared key K is an elliptic curve point, satisfying K=SK A SK B G, the random number g in signature generation is independently generated by a random number generator, and each signature uses a unique random number.

[0027] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, the hash operation adopts the SM3 hash method to output a 256-bit fixed-length hash value, and the elliptic curve point operation includes point addition and point multiplication, and the point multiplication is achieved by combining point doubling and point addition.

[0028] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, the transfer party is only responsible for transmitting the public key, signature result and ciphertext, and does not participate in key generation; during the encryption process, the key is generated by the key derivation function KDF(x2y2,klen), klen is the shared key length, and the ciphertext transmission path is user one → transfer party → user two.

[0029] As a further preferred solution, in the aforementioned authenticated key exchange method based on SM2 signature, the elliptic curve parameters include the prime field modulus P, the elliptic curve coefficients a and b, and the public parameters include the coordinates of P, a, b, and G; when user 2 decrypts, the data integrity is verified by Hash(x2Ky2)=C3 to ensure that the ciphertext has not been tampered with.

[0030] According to a second main aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, and when the program is executed, the authenticated key exchange method based on SM2 signature as described above is implemented.

[0031] According to a third main aspect of the present invention, an application of an authenticated key exchange method based on SM2 signature is provided, the application comprising:

[0032] In a scenario where both the user and the cloud server can authenticate each other, the user and the cloud server exchange a shared key through a two-party authenticated key exchange. The user uses the shared key to encrypt the data uploaded to the cloud server and verifies the cloud server's identity through an SM2 signature, ensuring that the data is stored in a trusted cloud server and has not been tampered with during transmission.

[0033] In a three-party authenticated scenario where two users communicate through a cloud server acting as a transit party, the communicating parties negotiate a shared key through a three-party authenticated key exchange, with the cloud server acting as an untrusted transit party. The sender uses the shared key to encrypt the communication data and append an SM2 signature. After the receiver obtains the encrypted data and signature through the cloud server, it uses the SM2 signature to verify the sender's identity and data integrity, ensuring the confidentiality, authenticity, and integrity of the communication content.

[0034] Compared with the prior art, the technical solution of the present invention has the following beneficial effects:

[0035] First, the existing Diffie-Hellman (DH) key exchange method can only guarantee the mathematical security of key negotiation, but lacks an identity authentication mechanism, which makes it impossible for the communicating parties to verify the authenticity of the other party's public key and makes them vulnerable to man-in-the-middle attacks. The present invention embeds the SM2 digital signature method in the key negotiation process. The communicating parties use their private keys to sign the shared key or public key hash value, and use the other party's public key to verify the validity of the signature. In the two-scheme scenario, the user and the cloud server exchange the SM2 signature results to verify the binding relationship between the other party's public key and private key, ensuring that the identity of the communicating entity is authentic and reliable. This fundamentally solves the security defect of the traditional method of "being unable to confirm whether the communicating party is the expected object" and significantly improves the anti-attack capability of key exchange.

[0036] Secondly, the traditional DH method is based on large prime number modular exponentiation, and its time complexity is O(k 3)(k is the key length), as security requirements increase, the key length needs to be continuously increased (such as from 1024 bits to 3072 bits), resulting in a cubic increase in computational overhead. The present invention adopts the mathematical basis of the Elliptic Curve Discrete Logarithm Problem (ECDLP) of the SM2 method. Under the same security level, the key length only needs to be 256 bits (equivalent to the security of 3072-bit RSA / 1024-bit DH), and the core operation is the elliptic curve point multiplication (the time complexity is O(n), n is the elliptic curve order), which significantly improves computational efficiency. Measured data show that when the key length is ≥128 bits, the execution time of the present invention is reduced by more than 50% compared with the DH method, which is more suitable for high-frequency, low-latency key exchange requirements in cloud computing.

[0037] Third, existing key exchange methods are not specifically adapted to the untrusted environment of cloud computing, and users cannot verify the trustworthiness of cloud servers or the neutrality of communication intermediaries. This invention designs a two-party authentication method to solve the "user-cloud server" trusted interaction problem: users verify that the cloud server public key has not been tampered with through SM2 signatures, ensuring that data is uploaded to a trusted server; a three-party authentication method is designed to solve the "user-untrusted cloud-user" communication security problem: even if the cloud server is untrusted, the communicating parties can still use SM2 signature chain verification to ensure that key negotiation does not rely on the trustworthiness of the intermediary. At the same time, elliptic curve encryption is used to ensure the confidentiality of data transmission, which is more secure than the traditional DH method that relies only on a single key negotiation process.

[0038] Fourth, the traditional DH method relies on additional protocols (such as IPSEC / IKE) to achieve authentication, which increases the number of communication rounds and the complexity of the protocol. Some existing solutions based on SM2 use interactive authentication, which requires multiple rounds of communication. The present invention controls the number of communication rounds to 2-4 rounds (2 rounds for two parties, 4 rounds for three parties) through non-interactive SM2 signatures (such as the two solutions in which both parties independently generate signatures and exchange them at one time), reducing the number of round trips by 30%-50% compared to interactive authentication. At the same time, the method does not need to rely on a trusted third party or a complex certificate system. It only achieves authentication through the disclosure of elliptic curve parameters and direct verification of public keys / signatures, reducing the complexity of key management. It is particularly suitable for dynamically expanding distributed node scenarios in cloud computing, reducing resource consumption and deployment costs.

[0039] Finally, most of the existing mainstream key exchange methods (such as DH and RSA) are foreign standards, which pose supply chain security risks. The present invention is entirely based on the SM2 / SM3 national secret method system with my country's independent intellectual property rights: the SM2 method is issued by the State Cryptography Administration, and its security has been verified by domestic cryptography research; the SM3 hash method provides a 256-bit summary output, which meets security properties such as anti-collision and avalanche effects. Compared with existing solutions that rely on foreign methods, the present invention is autonomous and controllable from the underlying cryptographic method to the protocol design, and complies with the requirements of the "Cybersecurity Law" for the use of national secret methods for critical information infrastructure. It is irreplaceable in cloud computing scenarios in sensitive fields such as government and finance, filling the gap in the application of domestic autonomous and controllable key exchange technology in complex network environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, without paying any creative work, other drawings obtained based on these drawings still fall within the scope of the present invention.

[0041] Figure 1 A schematic diagram of a two-party authenticated key exchange method in one embodiment of the present invention is shown;

[0042] Figure 2 A flow chart of a two-party authenticated key exchange method according to an embodiment of the present invention is shown;

[0043] Figure 3 A two-party key authentication flow chart is shown in one embodiment of the present invention;

[0044] Figure 4 A two-party key authentication flow chart is shown in one embodiment of the present invention;

[0045] Figure 5 A schematic diagram of a three-party key exchange method in one embodiment of the present invention is shown;

[0046] Figure 6 A flow chart of a three-party authenticated key exchange method according to an embodiment of the present invention is shown;

[0047] Figure 7 A flowchart of three-party key authentication in one embodiment of the present invention is shown;

[0048] Figure 8 A flowchart of verifying the authenticity of a public key C in one embodiment of the present invention is shown;

[0049] Figure 9FIG2 shows a flow chart for verifying the authenticity of a signature result SC in one embodiment of the present invention;

[0050] Figure 10 A flowchart of key verification in one embodiment of the present invention is shown;

[0051] Figure 11 Shown is an encryption flow chart in one embodiment of the present invention;

[0052] Figure 12 The figure shows a decryption flow chart in one embodiment of the present invention. DETAILED DESCRIPTION

[0053] The preferred embodiments of the present invention will be described in detail below so that the purpose, features and advantages of the present invention can be more clearly understood. It should be understood that the following embodiments are not intended to limit the scope of the present invention, but are only intended to illustrate the substantive content of the technical solution of the present invention.

[0054] In the following description, for the purpose of illustrating the various disclosed embodiments, certain specific details are set forth in order to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the relevant art will recognize that the embodiments may be practiced without one or more of these specific details. In other cases, well-known techniques associated with this application may not be shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.

[0055] Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any manner in one or more embodiments.

[0056] In the following example, a two-party authenticated key exchange method is used. Assume that the communicating parties, Alice and Bob, first negotiate a key to obtain a shared key K. Then, both parties use their own private keys K to sign, obtaining signature results SA and SB. User Alice then sends the signature SA to user Bob, who uses Alice's public key to verify whether the signature SA is valid. Similarly, user Bob sends the signature SB to user Alice, who uses Bob's public key to verify whether the signature SA is valid. The method process is as follows: Figure 1 shown.

[0057] In one embodiment, the specific steps are described as follows:

[0058] S1. Select an elliptic curve and base point: Alice and Bob negotiate to select an elliptic curve E and a base point G, and make the parameters of E and G public.

[0059] S2. Key generation: Alice and Bob, the key negotiation parties, determine their own private keys SK A and SK B , then generate the public key:

[0060] PK A =SK A ·G

[0061] PK B =SK B ·G.

[0062] S3. Key exchange: Alice and Bob exchange their public keys PK through an encrypted communication channel A and PK B S4. Key negotiation, calculation of shared key

[0063] Alice: K=SK A ·PK B =SK A ·(SK B ·G)=(SK A SK B )·G

[0064] Bob: K=SK B ·PK B =SK B ·(SK A ·G)=(SK A SK B )·G

[0065] S5. Key authentication: Alice uses the private key SK A Sign K to get SA;

[0066] S51. Calculate the information digest hash value e=Hash(K), and convert e into a large integer.

[0067] S52. Generate a random number g, where g belongs to [1, n-1] (where n is the order on the elliptic curve).

[0068] S53. Calculate a point C=g·G on the elliptic curve, where G is a base point on the elliptic curve.

[0069] S54. Calculate the signature parameter r = (e + Cx) mod n. If r = 0 or r + g = n, proceed to step S52.

[0070] S55. Calculate signature parameter s=[(1+SK A ) -1 ·(gr·SK A )]modn, if s=0, continue to step S52.

[0071] S56. Signature result SA = (SA_r, SA_s) = (r, s).

[0072] Bob uses the private key SK B Sign K to get SB;

[0073] S57. Calculate the information digest hash value e=Hash(K), and convert e into a large integer.

[0074] S58. Generate a random number g, where g belongs to [1, n-1] (where n is the order on the elliptic curve).

[0075] S59. Calculate a point C=g·G on the elliptic curve, where G is a base point on the elliptic curve.

[0076] S510. Calculate the signature parameter r = (e + Cx) mod n. If r = 0 or r + g = n, continue with S58.

[0077] S511. Calculate signature parameter s=[(1+SK B ) -1 ·(gr·SK B )]modn, if s=0, continue with S58.

[0078] S512. Signature result SB = (SB_r, SB_s) = (r, s).

[0079] S6. Key Verification

[0080] Alice and Bob exchange SA,K and SB,K.

[0081] Alice uses Bob's public key B to verify whether SB is valid. After receiving the shared key K' and signature (r', s'), Alice performs the following verification operation:

[0082] S61. Check whether r'∈[1,n-1] holds. If not, the verification fails.

[0083] S62. Check whether s'∈[1,n-1] holds. If not, the verification fails.

[0084] S63. Calculate the information digest hash value e=Hash(K).

[0085] S64. Convert e to a large integer.

[0086] S65. Calculate t=(r'+s')modn. If t=0, the verification fails.

[0087] S66. Calculate the point C on the elliptic curve = s'·G+PK B ·t.

[0088] S67. Calculate the verification value R = (e + Cx) mod n.

[0089] S68. If R=r', the verification is successful.

[0090] Bob uses Alice's public key A to verify whether SA is valid. After receiving the shared key K' and signature (r', s'), Bob performs the following verification operation:

[0091] S69. Check whether r'∈[1,n-1] holds. If not, the verification fails.

[0092] S610. Check whether s'∈[1,n-1] holds. If not, the verification fails.

[0093] S611. Calculate the information digest hash value e=Hash(K).

[0094] S612. Convert e to a large integer.

[0095] S613. Calculate t=(r'+s') mod n. If t=0, the verification fails.

[0096] S614. Calculate the point C on the elliptic curve = s'·G+PK A ·t.

[0097] S615. Calculate the verification value R = (e + Cx) mod n.

[0098] S616. If R=r', the verification is successful.

[0099] In one embodiment, the flow chart of the two-party authenticated key exchange method based on SM2 signature is as follows: Figure 2 As shown. First, users Alice and Bob jointly select a suitable elliptic curve E and base point G, then Alice and Bob select a random number a and b as their own private keys, and then calculate the public key

[0100] A=a·G,B=b·G

[0101] Alice and Bob exchange public keys over a secure communication channel. They then negotiate a shared key, K, and sign K to obtain SA and SB. Alice and Bob then exchange signatures, SA and SB, along with the shared key, K over a secure communication channel. Each party verifies the other's signature using their public key.

[0102] In one embodiment, two-party key authentication is Figure 3 As shown. User Alice uses private key SK A Sign K to get SA, user Bob uses private key SK B Sign K to get SB.

[0103] In one embodiment, two-party key authentication is Figure 4 After user Alice and user Bob exchange signatures, Alice uses Bob's public key PK B To verify the signature result SB, Bob uses Alice's public key PK A Verify the signature result SA.

[0104] The following embodiment provides a three-party authenticated key exchange method, where user Alice and user Candy negotiate a key through intermediary user Bob, and user Bob does not participate in the generation of the key K.

[0105] First, user Candy performs a hash operation on her public key h C =Hash(PK C ), then use the private key to h C Sign to get SC. User Candy sends the public key and signature to user Bob, who uses the public key PK C Verify that SC is valid, and then use the public key PK C Sent to user Alice. User Alice uses public key PK C and your own private key SK A Generate a shared key K and use the public key PK C Encrypt K to get C K User Alice will C K Sent to user Candy by user Bob, user Candy uses her own private key SK C C K Decrypt and get the shared key K. The method process is as follows Figure 5 shown.

[0106] In one embodiment, the specific method is described as follows:

[0107] S1. Select an elliptic curve and base point: Alice, Bob, and Candy negotiate to select an elliptic curve E and a base point G, and make the parameters of E and G public.

[0108] S2. Key generation: Alice and Candy determine their own private keys SK A and SK C , then generate the public key PK A =SK A G, PK C =SK C ·G.

[0109] S3. Key exchange: Candy sends the public key PK C Send it to Bob, and then Bob will send the public key PK C Send to Alice.

[0110] S4. Key Authentication

[0111] Candy's public key PK C Perform hashing and then use the private key SK C Sign the hash value to obtain SC;

[0112] S41. Perform hash operation on the public key h c =Hash(PK C ).

[0113] S42. Calculate the information summary hash value e=Hash(h c ), convert e to a large integer.

[0114] S43. Generate a random number g, where g belongs to [1, n-1] (where n is the order on the elliptic curve).

[0115] S44. Calculate a point C=g·G on the elliptic curve, where G is a base point on the elliptic curve.

[0116] S45. Calculate the signature parameter r = (e + Cx) mod n. If r = 0 or r + g = n, continue with S43.

[0117] S46. Calculate signature parameter s=[(1+SK C ) -1 ·(gr·SK C )]modn, if s=0, continue with S43.

[0118] S47. Signature result SC = (SC_r, SC_s) = (r, s).

[0119] S5. Key transmission

[0120] S51.Candy takes the signature result SC=(SC_r,SC_s), the public key and the hash value h c Send to Bob.

[0121] S52.Bob performs a hash operation on the signature result SC and the public key, e r =Hash(r),e s =Hash(s), And the hash operation result e r , e s , And the signature result SC and public key PK C Send to Alice.

[0122] S6. Key verification: Get the signature result (r', s') and public key PK C , verify Candy's identity and public key PK C authenticity.

[0123] Bob verifies the public key PK C Authenticity: Bob’s public key PK C Perform hash operation and get h c '=Hash(PK C ), if h c =h c ', then during the transmission process the public key PK C Bob uses Candy's public key PK C Verify whether the SC is valid; in one embodiment, the steps include:

[0124] S61. Check whether r'∈[1,n-1] holds. If not, the verification fails.

[0125] S62. Check whether s'∈[1,n-1] holds. If not, the verification fails.

[0126] S63. Calculate the information digest hash value e=Hash(h c ), convert e to a large integer.

[0127] S64. Calculate t=(r'+s')modn. If t=0, the verification fails.

[0128] S65. Calculate the point C on the elliptic curve = s'·G+PK C ·t.

[0129] S66. Calculate the verification value R = (e + Cx) mod n.

[0130] S67. If R=r', the verification succeeds.

[0131] Alice verifies SC and PK C Whether it has been tampered with during transmission;

[0132] S68.Alice signs the result SC and the public key PK C Perform hash operation.

[0133]

[0134] If e r =e r ',e s =e s ', Then the signature result SC and public key PK C It has not been tampered with during transmission.

[0135] Alice uses Candy's public key PK C Verify whether SC is valid;

[0136] S69. Check whether r'∈[1,n-1] holds. If not, the verification fails.

[0137] S610. Check whether s'∈[1,n-1] holds. If not, the verification fails.

[0138] S611. Calculate the information digest hash value e=Hash(h c ).

[0139] S612. Convert e to a large integer.

[0140] S613. Calculate t=(r'+s') mod n. If t=0, the verification fails.

[0141] S614. Calculate the point C on the elliptic curve = s'·G+PK C ·t.

[0142] S615. Calculate the verification value R = (e + Cx) mod n. If R = r', the verification is successful.

[0143] S7. Key negotiation: Alice uses her own private key SK A and Candy's public key PK C Generate a shared key, K = SK A ·PK C =(SK C SK A )·G, and then use Candy's public key to encrypt K to get C K .

[0144] S71. Generate a random number g, where g belongs to [1, n-1] (where n is the order on the elliptic curve).

[0145] S72. Calculate the point C1=g·G=(x1, y1) on the elliptic curve, where G is a base point on the elliptic curve.

[0146] S73. Calculate the point S on the elliptic curve = h·PK C , where h = E / n, is the cofactor. If S is a point at infinity, the program will exit with an error.

[0147] S74. Calculate the point gPK on the elliptic curve C =(x2,y2).

[0148] S75. Calculate t = KDF(x2||y2, klen). If t is a bit string of all zeros, return to S71 (where klen is the length of K, and KDF() is a key derivation function, which is essentially a pseudo-random number generator used to generate a key).

[0149] S76. Calculation

[0150] S77. Calculate C3 = Hash(x2||K||y2).

[0151] S78. Output ciphertext C K =(C1,C2,C3).

[0152] S8. Decryption: Alice converts C K Sent to Candy by Bob, Candy uses her own private key SK C Decryption. It includes the following steps:

[0153] S81.From C K Take out C1 and verify whether C1 satisfies the elliptic curve equation. If not, report an error and exit.

[0154] S82. Calculate the point S=hC1 on the elliptic curve. If S is a point at infinity, report an error and exit.

[0155] S83. Calculate SK C C1=(x2,y2).

[0156] S84. Calculate t = KDF(x2||y2,klen). If t is a bit string of all 0s, report an error and exit.

[0157] S85.From C k Take C2 and calculate

[0158] S86. Calculate u = Hash (x2 || K' || y2), from C K Take out C3, if C3≠u, report an error and exit.

[0159] S87. Output plaintext K'.

[0160] In one embodiment, a three-party authenticated key exchange method based on SM2 signature is as follows: Figure 6 As shown. Alice and Candy negotiate to select a suitable elliptic curve E and base point G, and then Candy selects a random number c as the private key and calculates the public key PK C =SK C G. Candy's public key PK C Perform hash operation to get h c =Hash 256 (PK C ), then sign the hash value to get SC, Candy will use the public key PK C , signature SC and hash value h c Transmitted to Bob. Bob performs a hash operation on the received public key to verify its authenticity and uses the public key PK C Verify the signature SC and perform hash operation on the signature, then use the public key PK C , signature SC and hash value are transmitted to Alice.

[0161] Alice receives the public key PK C And the signature SC is hashed to verify its authenticity, and then the public key PK is used C The signature SC is verified. After successful verification, Alice uses her private key and Candy's public key to negotiate a key to obtain K. She then encrypts K with Candy's public key to obtain ciphertext C, which is then sent to Candy through Bob. After receiving the ciphertext, Candy decrypts it using her private key to obtain the shared key K.

[0162] In one embodiment, key authentication is Figure 7 As shown. First, Candy uses the public key PK C Perform hash operation to get h c , then h c Sign and get SC.

[0163] In one embodiment, the authenticity of the received public key C is verified, such as Figure 8 As shown. First, Bob performs a hash operation on the received public key to obtain h c1 =Hash 256 (PK C ), and hc Compare them. If they are equal, it means that the public key has been tampered with during transmission. Alice performs a hash operation on the received public key and obtains e1=Hash 256 (PK C ),and Compare them. If they are equal, it means that the public key has been tampered with during transmission.

[0164] In one embodiment, after Alice receives the signature SC from Bob, she performs a hash operation on SC to verify its authenticity, such as Figure 9 shown.

[0165] In one embodiment, Alice uses the public key PK C Verify the received signature SC, such as Figure 10 shown.

[0166] In one embodiment, key negotiation is performed: K=SK A ·PK C =SK A SK C G, Alice uses the public key PK C and your own private key SK A Encrypt K to get the ciphertext C, such as Figure 11 shown.

[0167] In one embodiment, Candy uses her own private key to decrypt the ciphertext and obtain the plaintext K, such as Figure 12 shown.

[0168] Any related technologies in the field involved in the above implementation process that are not described in detail are common knowledge to those skilled in the art.

[0169] The basic principles, main features, and advantages of the present invention are shown and described above. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are merely illustrative of the principles of the present invention. Various changes and modifications may be made to the present invention without departing from the scope and spirit of the present invention. Such changes and modifications are intended to fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for authenticated key exchange based on SM2 signature, characterized in that: The steps include: The communication participants negotiate to select an elliptic curve and base point and disclose the parameters; each participant generates a private key and a corresponding public key, and exchanges the public key through the communication channel; and then performs key negotiation based on the elliptic curve point multiplication operation to generate a shared key; Each participant uses the SM2 signature method to sign the shared key or public key related information to generate a signature result; The participants exchange signature results and related parameters, and use the other party's public key to verify the validity of the signature, thus achieving identity authentication and key integrity verification; Among them, the SM2 signature method generates a public key and signature parameters through elliptic curve point multiplication operations, and realizes signature and verification based on the asymmetric relationship between the private key and the public key. Specifically, it includes: using the private key to perform elliptic curve point operations on the message hash value to generate signature parameters, and using the public key to perform elliptic curve point operations and hash verification on the signature parameters to realize signature verification.

2. The authenticated key exchange method based on SM2 signature according to claim 1, characterized in that: When the method is applied to a two-party authenticated key exchange scenario, the specific steps include: Both parties choose an elliptic curve E and a base point G, and make the parameters of E and G public; each party chooses a private key SK A SK B , calculate the public key PK A =SK A G, PK B =SK B G and exchange; Through K=SK A ·PK B =SK B ·PK A Negotiate a shared key K; Each party performs an SM2 signature on K: calculate the message hash value e = Hash(K) and convert it to a large integer, generate a random number g∈[1,n-1], calculate the elliptic curve point R = g·G, and generate signature parameters (r,s) through r = (e+Rx) mod n and s = [(1+SK)-1·(gr·SK)] mod n. If r = 0, r+g = n, or s = 0, regenerate a random number to obtain the signature results SA = (rA, sA) and SB = (rB, sB). After exchanging signatures and K, the verifier checks r and s∈[1,n-1], calculates e=Hash(K), and calculates t=(r+s)modn. If t=0, the verification fails. The elliptic curve point R=s·G+PK is calculated, and the signature validity is verified by verifying v=(e+Rx)modn=r.

3. The authenticated key exchange method based on SM2 signature according to claim 1, characterized in that: When the method is applied to a three-party authenticated key exchange scenario, the specific steps include: User 1 generates a private key SK C and public key PK C =SK C G, for PK C The hash value h C =Hash(PK C )Execute SM2 signature: Calculate e=Hash(h C ) and convert it into a large integer, generate a random number g∈[1,n-1], calculate R=g·G, and use r=(e+Rx)modn, s=[(1+SK C )-1·(gr·SK C )]modn generates a signature SC=(r,s). If r=0, r+g=n or s=0, a new random number is generated and SC, PK C 、h C Send to the intermediary; Transfer party verification Hash (PK C )=h C To confirm that the public key has not been tampered with, by verifying r, s∈[1,n-1], calculating t=(r+s)modn, R=s·G+PK C 、v=(e+Rx)modn=r After verifying the validity of SC, PK C , SC and h C1 =Hash(PK C ) forwarded to user 2; Second user verification and To confirm that the transmission has not been tampered with, repeat the SC verification process of the transfer party and pass K=SK A ·PK C Negotiate a shared key, generate a random number g∈[1,n-1] and calculate C1=g·G, and pass g·PK C =(x2,y2)、t=KDF(x2y2,klen)、 , C3 = Hash(x2Ky2) generates ciphertext C = C1C2C3, which is transmitted to user 1 via the transfer party; User 1 extracts C1 to verify the elliptic curve equation and calculates SK C C1=(x2,y2), through t=KDF(x2y2,klen), , Hash(x2Ky2)=C3 and obtain K after verification.

4. The authenticated key exchange method based on SM2 signature according to claim 2 or 3, characterized in that: The elliptic curve is a prime field elliptic curve, the base point G is a non-infinity point on the elliptic curve, the order of the elliptic curve is a prime number n, the private key SK is a random number in [1, n-1], and the public key is generated by the point multiplication operation of the private key and the base point.

5. The authenticated key exchange method based on SM2 signature according to claim 2, characterized in that: The shared key K is an elliptic curve point, satisfying K=SK A SK B G, the random number g in signature generation is independently generated by a random number generator, and each signature uses a unique random number.

6. The authenticated key exchange method based on SM2 signature according to claim 2 or 3, characterized in that: The hash operation adopts the SM3 hash method to output a 256-bit fixed-length hash value. The elliptic curve point operation includes point addition and point multiplication, and the point multiplication is achieved by combining point doubling and point addition.

7. The authenticated key exchange method based on SM2 signature according to claim 3, characterized in that: The transfer party is only responsible for transmitting the public key, signature result and ciphertext, and does not participate in key generation; during the encryption process, the key is generated by the key derivation function KDF(x2y2,klen), where klen is the shared key length, and the ciphertext transmission path is user one → transfer party → user two.

8. The authenticated key exchange method based on SM2 signature according to claim 3, characterized in that: The elliptic curve parameters include the prime field modulus P, elliptic curve coefficients a and b, and the public parameters include the coordinates of P, a, b, and G; when user 2 decrypts, the data integrity is verified by Hash(x2Ky2)=C3 to ensure that the ciphertext has not been tampered with.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed, the authenticated key exchange method based on SM2 signature as described in any one of claims 1 to 8 is implemented.

10. An application of an authenticated key exchange method based on SM2 signature, characterized in that: The applications include: In a scenario where both the user and the cloud server can authenticate each other, the user and the cloud server exchange a shared key through a two-party authenticated key exchange. The user uses the shared key to encrypt the data uploaded to the cloud server and verifies the cloud server's identity through an SM2 signature, ensuring that the data is stored in a trusted cloud server and has not been tampered with during transmission. In a three-party authenticated scenario where two users communicate through a cloud server acting as a transit party, the communicating parties negotiate a shared key through a three-party authenticated key exchange, with the cloud server acting as an untrusted transit party. The sender uses the shared key to encrypt the communication data and append an SM2 signature. After the receiver obtains the encrypted data and signature through the cloud server, it uses the SM2 signature to verify the sender's identity and data integrity, ensuring the confidentiality, authenticity, and integrity of the communication content.

Images