An interaction method, device, medium and product

Abstract

This invention discloses an interaction method, device, medium, and product. Relating to the field of computer technology, the method includes: determining a first pre-shared key based on key generation parameters; sending a first-end handshake message to a second end, wherein the first-end handshake information is used for signature verification and determining a second pre-shared key; receiving at least a portion of the hash value of the second pre-shared key sent by the second end; if at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then using the first pre-shared key as the target shared key.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to an interactive method, device, medium and product. Background Technology

[0002] In the existing technology, the specific process for determining the shared key is as follows: the client and the server pre-agree on multiple shared keys before the handshake phase; the client sends handshake information to the server, which carries the client's identity identifier; the server queries the corresponding multiple shared keys based on the identity identifier and sends the index of the selected shared key to the client; the client selects the corresponding shared key based on the index, which is then used as the final negotiated shared key.

[0003] This scheme requires pre-storing a pre-agreed shared key on both the client and server sides, posing a risk of key leakage. Furthermore, after receiving the handshake information, the server directly queries and uses the shared key based on the identity identifier, without verifying the message's origin and integrity. In summary, this method of determining the shared key has low overall security. Summary of the Invention

[0004] This invention provides an interaction method, device, medium, and product that can improve the security of shared key determination.

[0005] According to one aspect of the present invention, an interaction method is provided, executed by a first end, the method comprising: Determine the first pre-shared key based on the key generation parameters; Send a first-end handshake message to the second end, the first-end handshake information being used for signature verification and determining the second pre-shared key; Receive at least a portion of the hash value of the second pre-shared key sent by the second end; If at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then the first pre-shared key is used as the target shared key.

[0006] According to another aspect of the present invention, an interaction method is provided, executed by a second end, the method comprising: Receive the first handshake message sent by the first end; Based on the first handshake information, the first signature value is verified and the second pre-shared key is determined. At least a portion of the hash value of the second pre-shared key is sent to the first end, and the at least portion of the hash value of the second pre-shared key is used to determine the target shared key if the corresponding portion is the same as the hash value of the first pre-shared key.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the interactive method described in any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the interactive method described in any embodiment of the present invention.

[0009] According to another aspect of the present invention, a computer program product is provided, which, when executed by a processor, implements the interaction method as described in any of the embodiments of the present invention.

[0010] This invention, through its embodiments, determines a first pre-shared key based on key generation parameters; sends a first-end handshake message to a second end, the first-end handshake information being used for signature verification and determining a second pre-shared key; receives at least a portion of the hash value of the second pre-shared key sent by the second end; if at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then the first pre-shared key is used as the target shared key. The first end can generate the first pre-shared key in real time, and the second end generates the second pre-shared key in real time based on the first-end handshake information, and performs signature verification based on the first-end handshake information. Since both the first and second pre-shared keys are generated in real time, the security of the negotiated key can be guaranteed, and the security of the negotiated key can be further guaranteed by performing signature verification based on the first-end handshake information.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1This is a flowchart of an interaction method in an embodiment of the present invention; Figure 2 This is a flowchart of another interaction method in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0017] Example 1 Figure 1 This is a flowchart of an interaction method provided by an embodiment of the present invention. This embodiment is applicable to the case of determining a shared key. The method can be executed by a first end in this embodiment, and the first end can be implemented in software and / or hardware, such as... Figure 1 As shown, the method specifically includes the following steps: S110, determine the first pre-shared key based on the key generation parameters.

[0018] In this embodiment, the first end can be either a client or a server. It should be noted that if the first end is a client, then the second end is a server; if the first end is a server, then the second end is a client. This embodiment of the invention does not impose any restrictions on this.

[0019] In this embodiment, before determining the first pre-shared key based on the key generation parameters, the third end assigns identity identifiers and key pairs to the first and second ends.

[0020] In this embodiment, the third end can be a Key Generation Center (KGC), which is used to assign identity identifiers and key pairs to each entity (client, server) in the system.

[0021] In this embodiment, the key generation parameters may include: identity information of both ends, end-to-end security information, and a first-end random commitment. The identity information of both ends includes: a first-end identity identifier and a second-end identity identifier. The end-to-end security information includes: a first-end private key, a second-end public key, a system public key, and relevant parameters of the second end. It should be noted that the identity information of both ends is used to determine the identities of the first and second ends, the end-to-end security information is used to ensure end-to-end security, and the first-end random commitment is used to ensure that each generated shared key is different.

[0022] In this embodiment, the method for determining the first pre-shared key based on the key generation parameters can be as follows: The first pre-shared key is determined based on the identity information of both ends, the end-to-end security information, and the first end random commitment. For example, a first shared secret point is determined based on the end-to-end security information; the identity information of both ends, the first shared secret point, and the first end random commitment are sequentially concatenated to obtain the concatenated result; and an SM3 hash operation is performed on the concatenated result to obtain the first pre-shared key.

[0023] In this embodiment, the method for determining the first pre-shared key based on the key generation parameters can also be: determining the first pre-shared key based on the first-end identity identifier, the second-end identity identifier, the first-end private key, the second-end public key, the system public key, the relevant parameters of the second end, and the first-end random commitment.

[0024] In this embodiment, the method for determining the first pre-shared key based on the key generation parameters can be as follows: determine the first shared secret point based on the first-end private key, the second-end public key, the system public key, and the relevant parameters of the second end; sequentially concatenate the first-end identity identifier, the second-end identity identifier, the first shared secret point, and the first-end random commitment to obtain the concatenated result; perform SM3 hash operation on the concatenated result to obtain the first pre-shared key.

[0025] Optionally, the key generation parameters include: identity information of both ends, end-to-end security information, and a random commitment from the first end; Based on the key generation parameters, the first pre-shared key is determined, including: Based on the end-to-end security information, the first shared secret point is determined.

[0026] In this embodiment, the method for determining the first shared secret point based on the end-to-end security information can be as follows: the first shared secret point is determined based on the first end private key, the second end public key, the system public key, and relevant parameters of the second end.

[0027] The identity information from both ends, the first shared secret point, and the first random commitment are sequentially concatenated to obtain the concatenated result.

[0028] Perform an SM3 hash operation on the concatenated result to obtain the first pre-shared key.

[0029] It should be noted that the first pre-shared key can be determined based on the key generation parameters as follows: the first pre-shared key is determined based on the first-end identity identifier, the second-end identity identifier, the first-end private key, the second-end public key, the system public key, the relevant parameters of the second end, and the first-end random commitment.

[0030] Specifically, the steps include: determining the first shared secret point based on the first-end private key, the second-end public key, the system public key, and relevant parameters of the second end; sequentially concatenating the first-end identity identifier, the second-end identity identifier, the first shared secret point, and the first-end random commitment to obtain the concatenated result; and performing an SM3 hash operation on the concatenated result to obtain the first pre-shared key.

[0031] In this embodiment, if the first end is a client and the second end is a server, the method for determining the first shared secret point based on the first end's private key, the second end's public key, the system public key, and the relevant parameters of the second end can be: First shared secret point = Client private key × (Server public key + Server-related parameters × System public key). If the first end is a server and the second end is a client, the method for determining the first shared secret point based on the first end's private key, the second end's public key, the system public key, and the relevant parameters of the second end can be: First shared secret point = Server private key × (Client public key + Client-related parameters × System public key).

[0032] In a specific example, with the first end as the client and the second end as the server, the first pre-shared key = H(ID) A ||ID B ||d A ×(W B +λ B ×P pub )||R A IDA ID is used to identify the client. B d serves as the server's identity identifier. A W is the client's private key. B For the server public key, λ B For server-side related parameters, R A Make random commitments to the client.

[0033] Optionally, the identity information at both ends includes: a first-end identity identifier and a second-end identity identifier, and the end-to-end security information includes: a first-end private key, a second-end public key, a system public key, and relevant parameters of the second end; Before determining the first pre-shared key based on the key generation parameters, the process also includes: Generate the first temporary random number.

[0034] In this embodiment, the first temporary random number ∈ [1, n-1], where n is the order of the base point of the elliptic curve.

[0035] The first end random commitment is determined based on the first temporary random number and the elliptic curve base point.

[0036] In this embodiment, the product of the first temporary random number and the elliptic curve base point can be used as the first end random commitment.

[0037] Receive the first-end identity identifier, second-end identity identifier, second-end public key, system public key, and related parameters of the second end sent by the third end.

[0038] Wherein, the first-end identity identifier is an identity identifier assigned to the first end by the third end, the second-end identity identifier is an identity identifier assigned to the second end by the third end, the system public key is determined by the third end based on the elliptic curve base point and the system master key, the second-end related parameters are determined by the third end based on the second-end identity identifier and the system public key, the second-end public key is determined by the third end based on the second-end private key, the elliptic curve base point, the second-end related parameters and the system public key, and the first-end related parameters are determined by the third end based on the first-end identity identifier and the system public key.

[0039] In this embodiment, the first-end identity identifier, the first-end public key, and the first-end random commitment are concatenated sequentially, and then an SM3 hash operation is performed to obtain the first-end challenge value. The first-end signature value = first temporary random number + first-end challenge value × first-end private key × modulo n. For example, if the first end is a client and the second end is a server, the client generates a temporary random number r. A ∈[1,n-1], compute the client's random commitment: R A =r A ×G, calculate the client challenge value: e A =H(ID A||W A ||R A ), where ID A For client identity information, W A Let H be the client's public key and H be the SM3 hash function. Calculate the client signature value s. A =r A +e A ×d A (mod n).

[0040] In this embodiment, the SM2 elliptic curve parameters are configured in advance. Specifically, the recommended SM2 curve sm2p256v1 is used, defined over the finite field Fp, where p is a 256-bit prime number. The elliptic curve equation is: y 2 =x 3 +ax+b(mod p), where a and b are curve parameters, and the base point of the elliptic curve is G=(x G ,y G The order of is n (n can be a 256-bit prime number).

[0041] In this embodiment, KGC generates the system master key s∈[1,n-1] and calculates the system public key: P pub =s×G, system public key P pub The master key is publicly disclosed, but is kept secret by the KGC.

[0042] In this embodiment, KGC generates a key pair for each entity, and the specific process is as follows: A unique identity ID (such as a client identity ID) is assigned to each entity. A Server-side identity ID B KGC calculates the relevant parameter λ based on the entity's identity ID, where λ = H(ID||P) pub H is the SM3 hash function, the entity's private key d∈[1,n-1] can be generated by the entity itself or allocated by KGC, and the entity's public key W satisfies the relationship: W+λ×P pub =d×G, that is: W=d×G-λ×P pub In this embodiment, the entity can be either a client or a server; that is, the entity can be either a first end or a second end.

[0043] It should be noted that client A:W A +λ A ×P pub =d A ×G; Server B: W B +λ B ×P pub =d B ×G. W A For client public key, λ AFor client-related parameters, d A W is the client's private key. B For the server public key, λ B For server-side related parameters, d B This is the server's private key.

[0044] In this embodiment, KGC provides a public key query service. If it is the first query, the entity queries KGC to obtain the public key W through the other party's ID. After obtaining the public key W, the entity locally caches the mapping relationship between the ID and the public key W. Subsequent handshakes directly read from the cache. KGC provides standardized public key query interfaces (such as RESTful API, database query, etc.).

[0045] In this embodiment, the public key query logic includes: First handshake: querying KGC through ID to obtain public key W and caching it locally; Subsequent handshake: finding public key W through the local cache of ID.

[0046] In this embodiment, the KGC master key s is protected by a hardware security module (HSM) or secure storage. In addition, the KGC provides identity authentication and access control mechanisms to ensure that only authorized entities can query the public key. Furthermore, all key generation and query operations need to be recorded to support security auditing.

[0047] In this embodiment, by introducing a third end, 1-RTT fast authentication key negotiation based on SM2 is implemented on the basis of the TLS 1.3 standard PSK mechanism. This mainly includes three steps: KGC construction, PSK construction, and 1-RTT handshake. In this embodiment, the TLS 1.3 standard supports fast handshake based on a pre-shared key (PSK), which can achieve either 1-RTT or 0-RTT handshake.

[0048] S120, send a first handshake message to the second end, the first handshake information is used for signature verification and to determine the second pre-shared key.

[0049] The first handshake message includes: first-end identity identifier, second-end identity identifier, first-end random commitment, and first-end signature value.

[0050] In this embodiment, the first end sends a first end handshake message to the second end. After receiving the first end handshake message, the second end determines the second pre-shared key based on the first end handshake message, the second end private key, the first end public key, the system public key, and relevant parameters of the first end.

[0051] It should be noted that the second end determines the second pre-shared key based on the first end's handshake message, the second end's private key, the first end's public key, the system public key, and relevant parameters from the first end in the following ways: The second end determines the second shared secret point based on its private key, the first end's public key, the system public key, and relevant parameters from the first end; the second end sequentially concatenates the first end's identity identifier, the second end's identity identifier, the second shared secret point, and the first end's random commitment to obtain the concatenated result; the second end performs an SM3 hash operation on the concatenated result to obtain the second pre-shared key. In a specific example, with the first end as the client and the second end as the server: Second pre-shared key = H(ID) A ||ID B ||d B ×(W A +λ A ×P pub )||R A ID A ID is used to identify the client. B d serves as the server's identity identifier. B W is the server's private key. A For client public key, λ A For client-related parameters, R A Make random commitments to the client.

[0052] In this embodiment, if the first end is a client, the handshake information of the first end may include psk_identity_C, and the format of psk_identity_C is as follows: <ID A ID B ,R A ,s A >, where ID A For client identity identification (32 bytes), ID B For server-side identity identification (32 bytes), R A R provides a random commitment (32 bytes) to the client. A =r A ×G, where r A ∈[1,n-1] is the first temporary random number, for example, it can be the client's temporary random number, s A This is the client signature value (32 bytes), used to verify the client's identity.

[0053] It should be noted that this embodiment reuses the psk_identity field in the TLS 1.3 standard, which carries identity information and signature data to achieve SM2-based identity authentication.

[0054] S130, receiving at least a portion of the hash value of the second pre-shared key sent by the second end.

[0055] In this embodiment, at least part of the hash value of the second pre-shared key can be the first two bytes or the first three bytes of the hash value of the second pre-shared key, and this embodiment does not impose any restrictions on this.

[0056] S140, if at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then the first pre-shared key is used as the target shared key.

[0057] In this embodiment, after the second end calculates the second pre-shared key, it performs an SM3 hash on it, and then truncates the first 16 bits (2 bytes) as psk_identity_S and returns it to the first end for the first end to verify whether the key negotiation was successful.

[0058] In this embodiment, if the first two bytes of the hash value of the second pre-shared key are the same as the first two bytes of the hash value of the first pre-shared key, then either the first pre-shared key or the second pre-shared key will be used as the target shared key. It should be noted that if the first two bytes of the hash value of the second pre-shared key are the same as the first pre-shared key, then both the first and second pre-shared keys are the same, and either one can be used as the target shared key.

[0059] It should be noted that the psk_identity_C in the first handshake message sent by the first end is 128 bytes (it needs to be adapted to the TLS 1.3 standard through compression, hash indexing, or segmented transmission).

[0060] In this embodiment, since psk_identity_S in ServerHello is only a 2-byte index value, server authentication can be achieved through successful key negotiation.

[0061] Compared to certificate-based key negotiation schemes, the technical solution provided in this embodiment has significant technical advantages. In terms of performance, the handshake latency is reduced from 18-37ms (2-RTT) to 6-12ms (1-RTT), a latency reduction of over 65%, achieving a single round trip handshake and improving efficiency by 50%. In terms of management, unified management through KGC eliminates the need to maintain a complex CA certificate system, significantly reducing management costs. In terms of compliance, it natively supports SM2 / SM3 / SM4 algorithms, conforms to the GM / T0024-2014 standard, and maintains full compatibility with the standard TLS 1.3 protocol.

[0062] Compared to the standard PSK scheme, the technical solution provided in this embodiment has significant advantages in terms of security. The standard PSK scheme lacks authentication capabilities, cannot resist man-in-the-middle attacks, and lacks forward security. The technical solution provided in this embodiment, however, achieves authentication capabilities through SM2-based authentication and ensures the uniqueness of each PSK through random commitment, providing forward security and strong resistance to replay attacks. In terms of management, the standard PSK scheme requires pre-sharing of PSKs, while the technical solution provided in this embodiment dynamically generates PSKs through key negotiation, eliminating the need for pre-sharing and simplifying management. Regarding compliance, the technical solution provided in this embodiment complies with the GM / T0024-2014 standard and uses the SM2 / SM3 / SM4 algorithm, while the standard PSK scheme does not meet this standard. In terms of performance, the handshake latency of the technical solution provided in this embodiment is 6-12ms, close to the 5-7ms of the standard PSK scheme, with an increase of only 1-5ms while maintaining secure authentication.

[0063] Compared to existing National Cryptography Transport Layer Security (TLS) schemes, the technical solution provided in this embodiment has several advantages. In terms of performance, existing TLS schemes have a handshake latency of 18-37ms (2-RTT), while the technical solution provided in this embodiment achieves a 1-RTT fast handshake, reducing the handshake latency to 6-12ms, a reduction of over 65%. It also fully utilizes the TLS 1.3 PSK mechanism, resulting in a significant efficiency improvement. Regarding protocol compatibility, existing TLS schemes require protocol modifications, while the technical solution provided in this embodiment fully complies with the TLS 1.3 protocol specification without modifying the standard, maintaining complete compatibility. In terms of key management, existing TLS schemes require a CA system, while the technical solution provided in this embodiment uses a unified KGC for key management, eliminating the need to maintain a complex CA certificate system and simplifying management.

[0064] In summary, compared with the closest existing technology, the technical solution provided in this embodiment has the following comprehensive technical advantages: It utilizes the TLS 1.3 PSK mechanism to achieve a single round-trip handshake, reducing latency by more than 65% (from 18-37ms to 6-12ms), with performance approaching that of the standard PSK method (6-12ms vs 5-7ms). Identity authentication is achieved through dynamically constructed PSKs, providing resistance to man-in-the-middle attacks, forward security, and replay attack resistance, thus addressing the security deficiencies of the standard PSK scheme. Identity and public keys are uniformly managed through KGC, eliminating the need to maintain a complex CA certificate system, reducing management costs and complexity. It fully complies with the TLS 1.3 protocol standard, without modifying any fields or handshake procedures, ensuring compatibility with standard TLS 1.3. It adopts SM2 / SM3 / SM4 algorithms, conforming to standards such as GM / T0024-2014, meeting compliance requirements. PSKs are dynamically generated through key negotiation, eliminating the need for pre-sharing, and random commitment ensures the uniqueness of the PSK for each handshake, providing forward security and replay attack resistance.

[0065] The technical solution of this embodiment determines a first pre-shared key based on key generation parameters; sends a first-end handshake message to the second end, the first-end handshake information being used for signature verification and determining a second pre-shared key; receives at least a portion of the hash value of the second pre-shared key sent by the second end; if at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then the first pre-shared key is used as the target shared key. The first end can generate the first pre-shared key in real time, and the second end generates the second pre-shared key in real time based on the first-end handshake information, and performs signature verification based on the first-end handshake information. Since both the first and second pre-shared keys are generated in real time, the security of the negotiated key can be guaranteed, and the security of the negotiated key can be further guaranteed by performing signature verification based on the first-end handshake information.

[0066] Example 2 Figure 2 This is a flowchart of an interaction method provided by an embodiment of the present invention. This embodiment is applicable to the case of determining a shared key. The method can be executed by a second end in this embodiment of the present invention, and the second end can be implemented in software and / or hardware, such as... Figure 2 As shown, the method specifically includes the following steps: S210, receive the first handshake message sent by the first end.

[0067] The first handshake message includes: first-end identity identifier, second-end identity identifier, first-end random commitment, and first-end signature value.

[0068] S220, based on the first handshake information, performs signature verification and determines the second pre-shared key.

[0069] In this embodiment, the signature verification based on the first-end handshake information can be performed as follows: obtain the first-end public key corresponding to the first-end identity identifier; determine the first-end challenge value based on the first-end identity identifier, the first-end public key, and the first-end random commitment; determine the first value based on the first-end challenge value, the first-end random commitment, the first-end public key, the system public key, and the relevant parameters of the first end; if the product of the first-end signature value and the elliptic curve base point is the same as the first value, then the signature verification is determined to be successful.

[0070] It should be noted that if the signature verification is successful, the second pre-shared key is determined based on the first-end identity identifier, the second-end identity identifier, the second-end private key, the first-end public key, the system public key, the relevant parameters of the first end, and the first-end random commitment.

[0071] In this embodiment, the method for determining the second pre-shared key based on the first-end identity identifier, the second-end identity identifier, the second-end private key, the first-end public key, the system public key, the first-end related parameters, and the first-end random commitment can be as follows: determine the second shared secret point based on the second-end private key, the first-end public key, the system public key, and the first-end related parameters; sequentially concatenate the first-end identity identifier, the second-end identity identifier, the second shared secret point, and the first-end random commitment to obtain the concatenated result; perform an SM3 hash operation on the concatenated result to obtain the second pre-shared key.

[0072] In this embodiment, if the first end is a client and the second end is a server, the method for determining the second pre-shared key based on the first end's identity identifier, the second end's identity identifier, the second end's private key, the first end's public key, the system's public key, the first end's relevant parameters, and the first end's random commitment can be: H(first end's identity identifier || second end's identity identifier || server's private key × (client's public key + client's relevant parameters × system's public key) || first end's random commitment). If the first end is a server and the second end is a client, the method for determining the second pre-shared key based on the first end's identity identifier, the second end's identity identifier, the second end's private key, the first end's public key, the system's public key, the first end's relevant parameters, and the first end's random commitment can be: H(first end's identity identifier || second end's identity identifier || client's private key × (server's public key + server's relevant parameters × system's public key) || first end's random commitment).

[0073] S230, at least a portion of the hash value of the second pre-shared key is sent to the first end, wherein the at least portion of the hash value of the second pre-shared key is used to determine the target shared key if the corresponding portion of the hash value of the second pre-shared key is the same as that of the first pre-shared key.

[0074] In this embodiment, at least part of the hash value of the second pre-shared key can be the first two bytes or the first three bytes of the hash value of the second pre-shared key, and this embodiment does not impose any restrictions on this.

[0075] Optionally, the first handshake information includes: a first-end identity identifier, a second-end identity identifier, a first-end random commitment, and a first-end signature value; Signature verification is performed based on the first-end handshake information, including: Obtain the first-end public key corresponding to the first-end identity identifier.

[0076] In this embodiment, the first-end public key corresponding to the first-end identity can be obtained by querying the first-end identity or retrieving the first-end public key from the cache. The first-end public key satisfies: First-end public key + first-end related parameters × system public key = first-end private key × elliptic curve base point.

[0077] The first-end challenge value is determined based on the first-end identity identifier, the first-end public key, and the first-end random commitment.

[0078] In this embodiment, the first challenge value can be determined based on the first identity identifier, the first public key, and the first random commitment by concatenating the first identity identifier, the first public key, and the first random commitment in sequence and then performing an SM3 hash operation to obtain the first challenge value.

[0079] The first value is determined based on the first challenge value, the first random commitment, the first public key, the system public key, and the relevant parameters of the first end.

[0080] In this embodiment, the first value can be determined based on the first challenge value, the first random commitment, the first public key, the system public key, and the first related parameters as follows: First value = first random commitment + first challenge value × (first public key + first related parameters × system public key).

[0081] If the product of the first signature value and the base point of the elliptic curve is the same as the first value, then the verification is confirmed to be successful.

[0082] In this embodiment, if the following condition is met: First end signature value × Elliptic curve base point = First end random commitment + First end challenge value × (First end public key + First end related parameters × System public key), then the first end signature value is determined to be verified successfully.

[0083] In this embodiment, the first-end identity identifier, the second-end identity identifier, the first-end random commitment, and the first-end signature value are extracted from the psk_identity_C carried in the first-end handshake message. The first-end public key is retrieved by querying the first-end identity identifier or obtaining it from the cache. First-end public key + first-end related parameters × system public key = first-end private key × elliptic curve base point. The first-end challenge value is determined based on the first-end identity identifier, the first-end public key, and the first-end random commitment. The first value is determined based on the first-end challenge value, the first-end random commitment, the first-end public key, the system public key, and the first-end related parameters. If the product of the first-end signature value and the elliptic curve base point is the same as the first value, the verification is considered successful. For example, this can be illustrated by taking the first end as the client and the second end as the server: extracting the ID from psk_identity_C. A ID B R A s A via ID A Query or retrieve the client's public key W from the cache A (satisfies W) A +λ A ×P pub =d A ×G). Calculate the client challenge value: e A =H(ID A ||W A ||R A Verify the client signature value: s A ×G=R A +e A ×(W A +λ A ×P pub ).

[0084] Optionally, determine the second pre-shared key, including: The second shared secret point is determined based on the second private key, the first public key, the system public key, and relevant parameters of the first end.

[0085] In this embodiment, if the first end is a client and the second end is a server, the method for determining the second shared secret point based on the second end's private key, the first end's public key, the system public key, and the relevant parameters of the first end can be: Second shared secret point = Server private key × (Client public key + Client relevant parameters × System public key); If the first end is a server and the second end is a client, the method for determining the second shared secret point based on the second end's private key, the first end's public key, the system public key, and the relevant parameters of the first end can be: Second shared secret point = Client private key × (Server public key + Server relevant parameters × System public key).

[0086] The first-end identity identifier, the second-end identity identifier, the second shared secret point, and the first-end random commitment are sequentially concatenated to obtain the concatenated result.

[0087] Perform an SM3 hash operation on the concatenated result to obtain the second pre-shared key.

[0088] In this embodiment, a pre-shared key is dynamically generated through key negotiation for each handshake, without the need for pre-sharing; a random commitment (RA) ensures that the pre-shared key is different for each handshake, thereby guaranteeing forward security; security authentication is performed based on the security of the SM2 elliptic curve discrete logarithm problem; and a random commitment ensures that the pre-shared key is unique for each handshake to prevent replay attacks.

[0089] Optionally, before determining the second pre-shared key, the following steps are also included: Receive the first-end identity identifier, the second-end identity identifier, the second-end private key, the first-end public key, the system public key, and relevant parameters of the first end sent by the third end.

[0090] Wherein, the first end identity identifier is the identity identifier assigned to the first end by the third end, the second end identity identifier is the identity identifier assigned to the second end by the third end, the system public key is determined by the third end based on the elliptic curve base point and the system master key, the first end related parameters are determined by the third end based on the first end identity identifier and the system public key, and the first end public key is determined by the third end based on the first end private key, the elliptic curve base point, the first end related parameters and the system public key.

[0091] In this embodiment, the TLS 1.3 standard supports PSK-based fast handshakes, enabling 1-RTT (single round-trip) handshakes. The technical solution provided in this embodiment follows the TLS 1.3 standard handshake process, specifically as follows: The client sends a ClientHello message, which includes: psk_key_exchange_modes, the pre_shared_key extension, and other standard TLS 1.3 fields. psk_key_exchange_modes is the PSK key exchange mode extension, and the pre_shared_key extension includes psk_identity_C= <ID A ID B ,R A ,s AOther standard TLS 1.3 fields can include supported_versions, cipher_suites, etc. The server responds with a ServerHello message, which includes the pre_shared_key extension and other standard TLS 1.3 fields. The pre_shared_key extension is used to select and confirm the PSK, containing psk_identity_S (2 bytes, the first 16 bits of the SM3 hash of the second pre-shared key). After both parties exchange Finished messages, the handshake is complete, and encrypted communication begins. Total latency: T4-T0 ≈ 1-RTT (round-trip time).

[0092] The technical solution provided in this embodiment completes the handshake in a single round trip with low latency (6-12ms), requires no certificate verification or key exchange negotiation, has a simple process, and is more secure based on SM2 identity authentication and key negotiation. It fully complies with the TLS1.3 standard and requires no protocol modification.

[0093] In this embodiment, the psk_identity field from the TLS 1.3 standard is reused. The client carries psk_identity_C, which includes its own identity, the other party's identity, a signature random number, and the signature value. After the server calculates the second pre-shared key, it performs an SM3 hash on it and returns the first 16 bits (2 bytes) as psk_identity_S (which meets the requirement in the TLS 1.3 standard that psk_identity of ServerHello is a 2-byte index value). Client authentication is achieved through the SM2 signature algorithm, and the server's identity is confirmed through a key negotiation verification mechanism (the client calculates the first 16 bits of the SM3 hash of DHKey and verifies whether it matches the psk_identity_S returned by the server). The shared key is calculated as a dynamic PSK through a non-interactive key negotiation method based on the identity of both parties, the elliptic curve product of the client's private key and the server's public key, and the client's signature random number.

[0094] In this embodiment, the TLS 1.3 protocol standard is fully followed. The client sends ClientHello (carrying psk_identity_C), and the server responds with ServerHello (carrying psk_identity_S, which is the first 16 bits of the SM3 hash of the second pre-shared key). After the client verifies that the key negotiation is successful, the two parties exchange Finished messages to complete the handshake. The total delay is 1-RTT.

[0095] This embodiment provides a fast authentication key negotiation process for TLS 1.3 based on SM2. Without modifying the TLS 1.3 protocol standard, it introduces KGC to realize a 1-RTT fast handshake based on SM2, including PSK construction (identity authentication based on psk_identity and dynamic PSK generation) and the 1-RTT handshake process; the system includes a client and a server (maintaining a local public key cache to realize signature verification and non-interactive key calculation based on SM2).

[0096] The technical solution of this embodiment involves receiving a first-end handshake message sent by a first end; performing signature verification and determining a second pre-shared key based on the first-end handshake information; sending at least a portion of the hash value of the second pre-shared key to the first end, wherein the at least portion of the hash value of the second pre-shared key is used to determine the target shared key if it is the same as the corresponding portion of the hash value of the first pre-shared key. The first end can generate the first pre-shared key in real time, and the second end can generate the second pre-shared key in real time based on the first-end handshake information and perform signature verification based on the first-end handshake information. Since both the first and second pre-shared keys are generated in real time, the security of the negotiated key can be guaranteed, and the signature verification based on the first-end handshake information further guarantees the security of the negotiated key.

[0097] Example 3 Figure 3 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0098] like Figure 3As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded into the RAM 13 from storage unit 18. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0099] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0100] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as interactive methods.

[0101] In some embodiments, the interaction method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the interaction method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the interaction method by any other suitable means (e.g., by means of firmware).

[0102] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0103] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0104] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0105] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0106] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0107] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0108] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0109] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the interaction method described in any embodiment of the invention.

[0110] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0111] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An interaction method, characterized in that, Executed by the first end, the method includes: Determine the first pre-shared key based on the key generation parameters; Send a first-end handshake message to the second end, the first-end handshake information being used for signature verification and determining the second pre-shared key; Receive at least a portion of the hash value of the second pre-shared key sent by the second end; If at least a portion of the hash value of the second pre-shared key is the same as the corresponding portion of the hash value of the first pre-shared key, then the first pre-shared key is used as the target shared key.

2. The method according to claim 1, characterized in that, The key generation parameters include: identity information of both ends, end-to-end security information, and a random commitment from the first end; Based on the key generation parameters, the first pre-shared key is determined, including: Based on the end-to-end security information, a first shared secret point is determined; The identity information at both ends, the first shared secret point, and the first random commitment are sequentially concatenated to obtain the concatenated result; Perform an SM3 hash operation on the concatenated result to obtain the first pre-shared key.

3. The method according to claim 2, wherein the identity information of the two ends includes: First-end identity identifier and second-end identity identifier, the end-to-end security information includes: first-end private key, second-end public key, system public key and related parameters of the second end; Before determining the first pre-shared key based on the key generation parameters, the process also includes: Generate the first temporary random number; The first-end random commitment is determined based on the first temporary random number and the elliptic curve base point; The system receives a first-end identity identifier, a second-end identity identifier, a second-end public key, a system public key, and second-end related parameters sent by a third end. The first-end identity identifier is assigned to the first end by the third end, the second-end identity identifier is assigned to the second end by the third end, the system public key is determined by the third end based on the elliptic curve base point and the system master key, the second-end related parameters are determined by the third end based on the second-end identity identifier and the system public key, the second-end public key is determined by the third end based on the second-end private key, the elliptic curve base point, the second-end related parameters, and the system public key, and the first-end related parameters are determined by the third end based on the first-end identity identifier and the system public key.

4. An interaction method, characterized in that, Executed by the second end, the method includes: Receive the first handshake message sent by the first end; Signature verification and determination of the second pre-shared key are performed based on the first handshake information; At least a portion of the hash value of the second pre-shared key is sent to the first end, and the at least portion of the hash value of the second pre-shared key is used to determine the target shared key if the corresponding portion is the same as the hash value of the first pre-shared key.

5. The method according to claim 4, characterized in that, The first handshake information includes: first-end identity identifier, second-end identity identifier, first-end random commitment, and first-end signature value; Signature verification is performed based on the first-end handshake information, including: Obtain the first-end public key corresponding to the first-end identity identifier; The first-end challenge value is determined based on the first-end identity identifier, the first-end public key, and the first-end random commitment; The first value is determined based on the first challenge value, the first random commitment, the first public key, the system public key, and the relevant parameters of the first end; If the product of the first signature value and the base point of the elliptic curve is the same as the first value, then the verification is successful.

6. The method according to claim 4, characterized in that, Determine the second pre-shared key, including: The second shared secret point is determined based on the second private key, the first public key, the system public key, and relevant parameters of the first end; The first-end identity identifier, the second-end identity identifier, the second shared secret point, and the first-end random commitment are sequentially concatenated to obtain the concatenated result. Perform an SM3 hash operation on the concatenated result to obtain the second pre-shared key.

7. The method according to claim 4, characterized in that, Before determining the second pre-shared key, the following steps are also included: The system receives a first-end identity identifier, a second-end identity identifier, a second-end private key, a first-end public key, a system public key, and first-end related parameters sent by a third end. The first-end identity identifier is assigned to the first end by the third end, the second-end identity identifier is assigned to the second end by the third end, the system public key is determined by the third end based on the elliptic curve base point and the system master key, the first-end related parameters are determined by the third end based on the first-end identity identifier and the system public key, and the first-end public key is determined by the third end based on the first-end private key, the elliptic curve base point, the first-end related parameters, and the system public key.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the interactive method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the interactive method of any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the interactive method according to any one of claims 1-7.

Images