A data transmission method, a client, a server and a storage medium

Abstract

The application discloses a data transmission method, which is applied to a client and comprises the following steps: a first client hello message is sent, wherein the first client hello message is used for indicating a first key negotiation mode that can be supported by the client; a first server feedback message sent by a server based on the first client hello message is acquired, wherein the first server feedback message is used for indicating a second key negotiation mode determined by the server, and the first server feedback message comprises a request for re-sending a hello message or a server hello message; a first client shared key is determined, and target data transmission is performed according to the first client shared key. The application further discloses a data transmission device and a storage medium. Through the data transmission method, the client, the server and the storage medium provided by the embodiments of the application, flexible determination of a key negotiation mode can be realized.

Description

[0001] Case Analysis

[0002] This application is a divisional application of Chinese Patent No. 202010900055.3, filed on August 31, 2020, entitled "A data transmission method, client, server and storage medium". Technical Field

[0003] This application relates to the field of communication security technology, and in particular to a data transmission method, client, server and storage medium. Background Technology

[0004] Before transmitting data, IoT devices require clients and servers to negotiate a shared key through interaction to ensure data security. Therefore, how to negotiate this shared key is a key technical problem that needs to be solved. Summary of the Invention

[0005] This application provides a data transmission method, a client, a server, and a storage medium, which can flexibly determine the key negotiation mode, thereby negotiating a shared key for data transmission.

[0006] The technical solution of this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a data transmission method applied to a client, comprising:

[0008] Send a first client greeting message, the first client greeting message including first information, the first information being used to indicate a first key negotiation mode that the client can support;

[0009] Obtain a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0010] If the first key negotiation mode includes the second key negotiation mode, the first client shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first client shared key.

[0011] Secondly, embodiments of this application provide a data transmission method applied to a server, comprising:

[0012] Receive a first client greeting message sent by the client, the first client greeting message being used to indicate a first key negotiation mode that the client can support;

[0013] The server determines the second key negotiation mode selected by the server based on the first key negotiation mode, and sends it to the client through the feedback message from the first server.

[0014] If the first key negotiation mode includes the second key negotiation mode, the first server shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first server shared key.

[0015] Thirdly, embodiments of this application provide a client, the client comprising:

[0016] A first sending unit is configured to send a first client greeting message, the first client greeting message including first information, the first information being used to indicate a first key negotiation mode that the client can support;

[0017] The first acquisition unit is used to acquire a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0018] The first determining unit, if the first key negotiation mode includes the second key negotiation mode, is used to determine the first client shared key based on the second key negotiation mode, and to perform target data transmission according to the first client shared key.

[0019] In some embodiments, if the first key negotiation mode does not include the second key negotiation mode, then the first sending unit is configured to send a second client greeting message, wherein the second information is used to indicate a third key negotiation mode that the client can support;

[0020] The first acquisition unit is used to acquire a second server feedback message sent by the server based on the second client greeting message, wherein the second feedback information is used to indicate the fourth key negotiation mode determined by the server;

[0021] The first determining unit is used to determine the second client shared key based on the fourth key negotiation mode, and to perform target data transmission according to the second client shared key;

[0022] The first acquisition unit is configured to acquire a first warning message sent by the server based on the second client greeting message, and disconnect based on the first warning message; or, acquire a third server feedback message sent by the server based on the second client greeting message, send a second warning message based on the third server feedback message and disconnect.

[0023] In some embodiments, the first client greeting message, the second client greeting message, the first server feedback message, and the second server feedback message all include predefined fields, which include at least one of the following: a protocol version field, a cipher suite field, an encryption curve field, a first public key field, and a second public key field; the protocol version field is used to indicate some or all protocol version parameters supported by the client or the server; the cipher suite field is used to indicate some or all cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate some or all encryption curve parameters supported by the client or the server; the first public key field is used to indicate the first public key of the client or the server; and the second public key field is used to indicate the second public key of the client or the server.

[0024] In some embodiments, the first client greeting message includes the protocol version field, the cipher suite field, the first public key field, the encryption curve field, and the second public key field, wherein the first public key field includes the client's first public key; the second public key field is empty; and / or, when the client and the server apply a first key negotiation algorithm, the second client greeting message includes the protocol version field, the cipher suite field, and the first public key field, wherein the first public key field includes the client's second public key; and / or, when the client and the server apply a second key negotiation algorithm, and the client supports the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the second public key field, wherein the second public key field includes the client's third public key; and / or, when the client and the server apply a second key negotiation algorithm, and the client does not support the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the encryption curve field.

[0025] In some embodiments, the first key negotiation algorithm is the Elliptic-curve Diffie–Hellman (ECDH) algorithm, and the second key negotiation algorithm is the Password Authenticated Key Exchange by Juggling Over Elliptic Curve (ECJPAKE) algorithm.

[0026] In some embodiments, if the first key negotiation mode includes the second key negotiation mode, it includes: the protocol version parameter of the protocol version field of the first client greeting message includes the protocol version parameter of the protocol version field of the first server feedback message; the cipher suite parameter of the cipher suite field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; the encryption curve parameter of the encryption curve field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; and / or, if the first key negotiation mode does not include the second key negotiation mode, it includes: the protocol version parameter of the protocol version field of the first client greeting message does not include the protocol version parameter of the protocol version field of the first server feedback message; or, the cipher suite parameter of the cipher suite field of the first client greeting message does not include the cipher suite parameter of the cipher suite field of the first server feedback message; or, the encryption curve parameter of the encryption curve field of the first client greeting message does not include the cipher suite parameter of the cipher suite field of the first server feedback message.

[0027] Fourthly, this application provides a server, the server comprising:

[0028] The second receiving unit is configured to receive a first client greeting message sent by the client, wherein the first client greeting message is used to indicate a first key negotiation mode that the client can support;

[0029] The second determining unit is configured to determine the second key negotiation mode selected by the server based on the first key negotiation mode, and send it to the client through the first server feedback message; or, if the first key negotiation mode includes the second key negotiation mode, it is configured to determine the first server shared key based on the second key negotiation mode, and perform target data transmission based on the first server shared key.

[0030] In some embodiments, if the first key negotiation mode does not include the second key negotiation mode, the second receiving unit is configured to receive a second client greeting message sent by the client, the second client greeting message being used to indicate a third key negotiation mode that the client can support;

[0031] The second receiving unit is configured to send a second server feedback message based on the second client greeting message, wherein the second server feedback message is used to indicate the fourth key negotiation mode determined by the server.

[0032] The second determining unit is used to determine the second server-side shared key based on the fourth key negotiation mode, and to perform target data transmission according to the second client-side shared key; or, to disconnect based on the third server-side feedback message sent by the second client-side greeting message.

[0033] In some embodiments, the first client greeting message, the second client greeting message, the first server feedback message, and the second server feedback message all include predefined fields, which include at least one of the following: a protocol version field, a cipher suite field, an encryption curve field, a first public key field, and a second public key field; the protocol version field is used to indicate some or all protocol version parameters supported by the client or the server; the cipher suite field is used to indicate some or all cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate some or all encryption curve parameters supported by the client or the server; the first public key field is used to indicate the first public key of the client or the server; and the second public key field is used to indicate the second public key of the client or the server.

[0034] In some embodiments, the client and the server may apply a first key negotiation algorithm and / or a second key negotiation algorithm; the first server feedback message includes a request to resend the greeting message or a server greeting message.

[0035] In some embodiments, the request to resend the greeting message is any one of a first request to resend the greeting message, a second request to resend the greeting message, a third request to resend the greeting message, and a fourth request to resend the greeting message; the server greeting message is any one of a first server greeting message and a second server greeting message; wherein, the first request to resend the greeting message is sent when the server applies the first key agreement algorithm but does not support the first key agreement mode; and / or, the second request to resend the greeting message is sent when the server applies the second key agreement algorithm and supports the first key agreement mode; and / or, the third request to resend the greeting message is sent when the server applies the second key agreement algorithm but does not support the first key agreement mode; and / or, the fourth request to resend the greeting message is sent when the server applies the first key agreement algorithm and supports the first key agreement mode, but does not support the first public key; the first server greeting message is sent when the server applies the second key agreement algorithm and supports the first key agreement mode; and / or, the second server greeting message is sent when the server applies the first key agreement algorithm and supports the first key agreement mode.

[0036] In some embodiments, the first key negotiation algorithm is the ECDH algorithm, and the second key negotiation algorithm is the ECJPAKE algorithm.

[0037] The data transmission method, client, server, and storage medium provided in this application embodiment include: sending a first client greeting message, which includes first information indicating a first key negotiation mode supported by the client; obtaining a first server feedback message sent by the server based on the first client greeting message, which indicates a second key negotiation mode determined by the server, including a request to resend the greeting message or a server greeting message; if the first key negotiation mode includes the second key negotiation mode, determining a first client shared key based on the second key negotiation mode, and transmitting the target data according to the first client shared key. This allows for flexible determination of the key negotiation mode, shared key negotiation, and transmission of target data through the negotiated shared key. Attached Figure Description

[0038] Figure 1 This is a flowchart illustrating the distribution network protocol based on ECDH in related technologies;

[0039] Figure 2 This is a flowchart illustrating the distribution network protocol based on ECJPAKE in related technologies;

[0040] Figure 3 A schematic diagram of an optional process on the client side of the data transmission method provided in the embodiments of this application;

[0041] Figure 4 A schematic diagram of an optional process for negotiating a shared key using the ECDH distribution protocol, provided for an embodiment of this application;

[0042] Figure 5 A detailed flowchart illustrating the process of negotiating a shared key using the ECDH distribution protocol, provided for embodiments of this application;

[0043] Figure 6 A schematic diagram of an optional process for negotiating a shared key using the ECJPAKE distribution protocol, provided for an embodiment of this application;

[0044] Figure 7 A detailed flowchart illustrating the process of negotiating a shared key using the ECJPAKE distribution protocol, provided for embodiments of this application;

[0045] Figure 8 A schematic diagram of an optional server-side process for the data transmission method provided in an embodiment of this application;

[0046] Figure 9 This is a schematic diagram of an optional flow of the data transmission method provided in an embodiment of this application;

[0047] Figure 10 A detailed processing flowchart of the data transmission method provided in the embodiments of this application is shown below;

[0048] Figure 11 A schematic diagram of another optional flow of the data transmission method provided in the embodiments of this application;

[0049] Figure 12 A detailed flowchart illustrating another data transmission method provided in an embodiment of this application;

[0050] Figure 13 A schematic diagram illustrating another optional flow of the data transmission method provided in an embodiment of this application;

[0051] Figure 14 A schematic diagram illustrating another detailed processing flow of the data transmission method provided in the embodiments of this application;

[0052] Figure 15 A schematic diagram of another optional process for the data transmission method provided in the embodiments of this application;

[0053] Figure 16 A schematic diagram of another optional flow of the data transmission method provided in the embodiments of this application;

[0054] Figure 17 A schematic diagram illustrating an optional structure of the message content transmitted between the client and server in an embodiment of this application;

[0055] Figure 18 This is a schematic diagram of an optional structure of the client provided in an embodiment of this application;

[0056] Figure 19 This is a schematic diagram of an optional server structure provided in an embodiment of this application;

[0057] Figure 20 This is a schematic diagram of an optional structure of the data transmission device provided in an embodiment of this application;

[0058] Figure 21 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0059] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the scope of the present application.

[0060] Before performing functional operations, IoT devices often need to be configured for security reasons. Configuration involves verifying the identities of both parties through interaction and generating keys for data encryption. Since most IoT devices are capable of connecting via wireless technologies such as WiFi and Bluetooth Low Energy (BLE), they can only communicate on the current wireless network after configuration. This process is called network configuration.

[0061] Currently, there are two main distribution network protocols: those based on ECDH and ECJPAKE. The general process is as follows: Figure 1 and Figure 2 As shown.

[0062] Figure 1 A schematic diagram of the distribution network protocol based on ECDH in related technologies is shown.

[0063] like Figure 1 As shown, after the first client and the server establish a connection, corresponding key pairs are generated respectively. Then, a shared key is generated based on the public key exchanged. After the shared key is generated, the network configuration is considered complete, and application layer data is transmitted (using the shared key for symmetric encryption).

[0064] Figure 2 A schematic diagram of the distribution network protocol based on ECJPAKE in related technologies is shown.

[0065] like Figure 2 As shown, the first client establishes a connection with the server, enters the handshake phase to exchange public keys, and generates a shared key. After the shared key is generated, the network configuration is considered complete, and application layer data is transmitted (using the shared key for symmetric encryption).

[0066] However, in related technologies, the distribution network protocols based on ECDH or ECJPAKE do not provide flexible and comprehensive support for devices. At the same time, the current standard process interaction involves a large amount of data, which puts a heavy burden on BLE devices.

[0067] As people become increasingly aware of security and privacy, security technologies are becoming increasingly important in IoT products. Typically, the approach on BLE devices is to execute different negotiation processes based on the device's security level, specifically including:

[0068] (1) Low security level: Random numbers provide unpredictability, symmetric keys, symmetric encryption and decryption (AES-128);

[0069] (2) High security level: random numbers provide unpredictability, asymmetric key exchange (ECDH key exchange), symmetric encryption and decryption of messages (AES-128), message sequence number added to message header for anti-replay, and certificate authentication.

[0070] In addition, the applicant also found that for devices with Personal Identification Numbers (PINs), the PINs themselves are not adequately protected and are easily leaked. Furthermore, once the key is generated, it will be used throughout its entire lifecycle without an update mechanism.

[0071] Based on the problems existing in secure communication methods, this application proposes a data transmission method that can solve the technical problems and shortcomings that cannot be solved in existing technical solutions.

[0072] Figure 3 This paper illustrates an optional flowchart of the data transmission method provided in this application on the client side, and will describe each step accordingly.

[0073] Step S101: Send the first client greeting message.

[0074] In some embodiments, the client sends a first client greeting message to the server, the first client greeting message being used to indicate a first key negotiation mode that the client can support.

[0075] In some embodiments, the client sends a first client greeting message to the server. The first client greeting message includes first information, which indicates a first key negotiation mode that the client can support.

[0076] In some embodiments, the first key negotiation mode includes using a network distribution protocol negotiation key with ECDH and / or using a network distribution protocol negotiation key with ECJPAKE.

[0077] In some embodiments, the first information includes a first set of encryption suites; the first set of encryption suites includes a set of at least one encryption suite that the client can support.

[0078] In other embodiments, the first client greeting message may further include: a cipher suite field; the cipher suite field is used to indicate some or all of the cipher suite parameters supported by the client.

[0079] In some embodiments, the first information may further include a first set of encryption curves; the first set of encryption curves includes a set of at least one encryption curve that the client can support.

[0080] In other embodiments, the first client greeting message may further include: an encryption curve field; the encryption curve field is used to indicate some or all of the encryption curve parameters supported by the client.

[0081] In some embodiments, the first client greeting message further includes: a first public key, which includes: a public key determined by any one of the encryption suites in the first encryption suite set and / or any one of the encryption curves in the first encryption curve set, provided that the client can support the ECDH distribution protocol. Different encryption suites and / or encryption curves determine different public keys.

[0082] In some embodiments, the first client greeting message further includes: a first protocol identifier set, the first protocol identifier set including at least one protocol identifier corresponding to a protocol version, the protocol version and the protocol identifier being in one-to-one correspondence, the first protocol identifier set indicating the set of protocol versions supported by the client.

[0083] In other embodiments, the first client greeting message may further include a protocol version field; the protocol version field is used to indicate some or all of the protocol version parameters supported by the client.

[0084] In some embodiments, the first client greeting message further includes: a first public key list, wherein the first public key list of the first client greeting message is NULL.

[0085] Step S102: Obtain the first server feedback message sent by the server based on the first client greeting message.

[0086] It should be noted that, in this application's embodiments, "client" refers to the device (or app) that actively initiates the connection, or it can refer to the active connection end in this application; during connection, the client proves its control to the server. "Server" refers to the device that passively connects, or it can refer to the passive connection end in this application; during connection, the server authenticates the client's identity and verifies that the client has control. The client and server can be servers, terminal devices, "televisions," "speakers," or other Internet of Things (IoT) devices. The connection between the client and server can be established through a wired network, a wireless network, or a mobile network.

[0087] In some embodiments, the client can be an active connection end, which can be a Bluetooth Low Energy device, or an electronic device such as a handheld terminal, wearable terminal, personal laptop, or tablet computer; the server can be a passive connection end, which can be a Bluetooth Low Energy device, such as a blood pressure measuring device, temperature measuring device, or blood glucose monitoring device used in the field of monitoring and care; or a fitness equipment sensor, heart rate measuring device, positioning device, speed measuring device, or weight measuring device used in the field of sports and fitness; or a switch device, lighting device, smart door lock, electric curtain, or robot vacuum cleaner used in the field of smart homes. In some embodiments, the client obtains a first server feedback message sent by the server based on the first client greeting message; the first server feedback message is used to indicate the second key negotiation mode determined by the server.

[0088] In some embodiments, if the first client greeting message includes a first set of encryption suites that includes at least one encryption suite supported by the server, the first set of encryption curves that includes the first client greeting message includes at least one encryption curve supported by the server, or the first set of protocol identifiers that includes the first client greeting message includes a protocol identifier corresponding to at least one protocol version supported by the server, and the server determines that the second key negotiation mode is to negotiate the key using the ECDH network configuration protocol, the first server feedback message includes at least one of the following: a first encryption suite, a first encryption curve, a first protocol identifier, and a second public key; the first set of encryption suites includes the first encryption suite, which includes any one of the at least one encryption suites supported by the server; the first set of encryption curves includes the first encryption curve, which includes any one of the at least one encryption curve supported by the server; the first set of protocol identifiers includes the first protocol identifier, which includes a protocol identifier corresponding to any one of the at least one protocol version supported by the server. The second public key is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identifier. In other embodiments, if the first client greeting message includes a first set of encryption suites that includes at least one encryption suite supported by the server, a first set of encryption curves that includes at least one encryption curve supported by the server, or a first set of protocol identifiers that includes at least one protocol version supported by the server, and the server determines that the second key negotiation mode is to use the ECJPAKE network configuration protocol negotiation key, the first server feedback message includes: a first encryption suite, a first encryption curve, a first protocol identifier, and a first public key list; the first set of encryption suites includes the first encryption suite, which includes any one of the at least one encryption suites supported by the server; the first set of encryption curves includes the first encryption curve, which includes any one of the at least one encryption curves supported by the server; the first set of protocol identifiers includes the first protocol identifier, which includes a protocol identifier corresponding to any one of the at least one protocol version supported by the server. The second public key is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identifier. The first public key list includes public key pairs sent by the server to the client for determining the first client shared key.

[0089] In some embodiments, if at least one of the following conditions is met: the first set of encryption suites included in the first client greeting message does not include at least one encryption suite supported by the server; the first set of encryption curves included in the first client greeting message does not include at least one encryption curve supported by the server; or the first set of protocol identifiers included in the first client greeting message does not include a protocol identifier corresponding to at least one protocol version supported by the server, the first server feedback message includes: a second encryption suite, a second encryption curve, and a second protocol identifier. The first set of encryption suites does not include the second encryption suite, and the second encryption suite includes any one of the at least one encryption suites supported by the server; the first set of encryption curves does not include the second encryption curve, and the second encryption curve includes any one of the at least one encryption curve supported by the server; the first set of protocol identifiers includes the second protocol identifier, and the second protocol identifier includes a protocol identifier corresponding to any one of the at least one protocol version supported by the server.

[0090] For example, if the first set of encryption suites does not include the encryption suites supported by the server, the first set of encryption curves does not include the curves supported by the server, and the first set of protocol identifiers does not include the protocol identifier corresponding to the protocol version supported by the server, the first server feedback message includes the second encryption suite, the second encryption curve, and the second protocol identifier determined by the server based on its own performance.

[0091] Alternatively, if the first set of encryption suites includes the encryption suites supported by the server, the first set of encryption curves does not include the encryption curves supported by the server, and the first set of protocol identifiers does not include the protocol identifier corresponding to the protocol version supported by the server, then the first server feedback message includes the second encryption curve and the second protocol identifier determined by the server based on its own performance, and the first encryption suite determined by the server based on the first client greeting message.

[0092] Step S103: If the first key negotiation mode includes the second key negotiation mode, determine the first client shared key based on the second key negotiation mode, and perform target data transmission according to the first client shared key.

[0093] In some embodiments, when the first key negotiation mode includes the second key negotiation mode, a first client shared key is determined based on the second key negotiation mode, and target data is transmitted according to the first client shared key.

[0094] In some embodiments, the first key negotiation mode includes the second key negotiation mode as follows: when the first cipher suite set includes the first cipher suite, the first encryption curve set includes the first encryption curve, and the first protocol identifier set includes the first protocol identifier, the first key negotiation mode includes the second key negotiation mode corresponding to the first cipher suite, the first encryption curve, and the first protocol identifier carried in the first server feedback message.

[0095] In other embodiments, the first key negotiation mode includes the second key negotiation mode, and may further include: the protocol version parameter of the protocol version field of the first client greeting message includes the protocol version parameter of the protocol version field of the first server feedback message; the cipher suite parameter of the cipher suite field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; and the encryption curve parameter of the encryption curve field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message.

[0096] In some embodiments, determining the first client shared key based on the second key negotiation mode includes scenarios 1 and 2, which will be described in detail in subsequent embodiments.

[0097] In some embodiments, scenario 1 includes: the second key negotiation mode is a network distribution protocol negotiation key using ECDH; further, determining the first client shared key based on the second key negotiation mode includes: a network distribution protocol negotiation key using ECDH.

[0098] In some embodiments, scenario 2 includes a network configuration protocol where the second key negotiation mode is ECJPAKE. Further, determining the first client shared key based on the second key negotiation mode includes negotiating the key using the ECJPAKE network configuration protocol.

[0099] Step S104: If the first key negotiation mode does not include the second key negotiation mode, then send a second client greeting message.

[0100] In some embodiments, the first key negotiation mode does not include the second key negotiation mode, including: the first set of cipher suites included in the first client greeting message does not include the second cipher suite carried in the first server feedback message; or, the first set of encryption curves included in the first client greeting message does not include the second encryption curve carried in the first server feedback message; or, the first set of protocol identifiers included in the first client greeting message does not include the second protocol identifier carried in the first server feedback message. That is, the first key negotiation mode does not include the second key negotiation mode corresponding to the cipher suites, encryption curves, and protocol identifiers carried in the first server feedback message.

[0101] In some embodiments, the client sending a second client greeting message includes: the client sending a second client greeting message to the server, the second client greeting message including second information, the second information being used to indicate a third key negotiation mode that the client can support.

[0102] In some embodiments, the second information includes a second set of cipher suites that the client can support and / or a second set of encryption curves that the client can support. At least one cipher suite included in the first set of cipher suites is completely different from at least one cipher suite included in the second set of cipher suites; at least one encryption curve included in the first set of encryption curves is completely different from at least one encryption curve included in the second set of encryption curves.

[0103] In some embodiments, the second client greeting message further includes a fourth public key, which includes a public key determined by any one of the encryption suites in the second set of encryption suites and / or any one of the encryption curves in the second set of encryption curves, provided that the client is capable of supporting the ECDH distribution protocol.

[0104] In some embodiments, the second client greeting message further includes: a second protocol identifier set, the second protocol identifier set including at least one protocol identifier corresponding to a protocol version, the protocol version and the protocol identifier being in one-to-one correspondence, the second protocol identifier set indicating the set of protocol versions supported by the client.

[0105] In some embodiments, the second client greeting message further includes: a second public key list, wherein the second public key list of the second client greeting message is NULL.

[0106] In some embodiments, if the server can support the third key negotiation mode, step S105 is executed; if the server cannot support the third key negotiation mode, step S107 is executed.

[0107] Step S105: Obtain the second server feedback message sent by the server based on the second client greeting message.

[0108] In some embodiments, the client obtains a second server feedback message sent by the server based on the second client greeting message. The second server feedback message includes second feedback information. The second feedback information is used to indicate the specific steps of the fourth key negotiation mode determined by the server. The process is similar to step S102 and will not be repeated here.

[0109] Step S106: Determine the second client shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client shared key.

[0110] In some embodiments, the specific steps for determining the second client shared key based on the fourth key negotiation mode and transmitting the target data according to the second client shared key are similar to those in step S103, and will not be repeated here.

[0111] Step S107: Obtain the first warning message sent by the server based on the greeting message from the second client, and disconnect based on the first warning message.

[0112] In some embodiments, the client receives a first warning message sent by the server based on the second client greeting message, and disconnects based on the first warning message.

[0113] In some embodiments, if the server receives the second client greeting message and determines that the server does not support at least one cipher suite included in the second cipher suite set; or the server does not support at least one encryption curve included in the second encryption curve set; or the server does not support the protocol version corresponding to at least one protocol identifier included in the second protocol identifier set, the server sends a first warning message to the client, the first warning message being used to indicate disconnection between the client and the server.

[0114] In some embodiments, the method further includes: step S108, sending a second warning message.

[0115] In some embodiments, if the first server feedback message received by the client includes two or more encryption curves, two or more encryption suites, or two or more version identifiers, the client sends a second warning message to the server and disconnects from the server; the second warning message is used to indicate the disconnection of the connection between the client and the server. If the first server feedback message includes two or more encryption curves, two or more encryption suites, or two or more version identifiers, it indicates that the client has been maliciously attacked by a third party, or that the server has encountered an error, and the client sends the second warning message and disconnects from the server.

[0116] In other embodiments, if the second server feedback message received by the client includes two or more encryption curves, two or more encryption suites, or two or more version identifiers, the client sends a second warning message to the server and disconnects from the server; the second warning message is used to indicate the disconnection of the connection between the client and the server.

[0117] Thus, this application provides a flexible data transmission method. For clients with lower performance and less stringent security requirements, the ECDH network configuration protocol is used for data transmission; for clients with higher performance and more stringent security requirements, the ECJPAKE network configuration protocol is used. Developers do not need to pre-select the data transmission process; the client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, for clients with high security requirements, the client's PIN code is combined with the transmission process, increasing the difficulty of PIN code cracking and improving data transmission security. In addition, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0118] Figure 4 This illustration shows an optional process diagram for negotiating a shared key using the ECDH distribution protocol, provided in an embodiment of this application. Figure 5 This illustration shows a detailed flowchart of the process for negotiating a shared key using the ECDH distribution protocol, as provided in an embodiment of this application. Figure 4 , Figure 5 Please provide an explanation.

[0119] This embodiment corresponds to scenario 1 in step S103.

[0120] In some embodiments, if the client obtains the first server feedback message from the server based on step S102, and determines that the second key transmission mode is to negotiate a shared key using the ECDH distribution protocol based on the first server feedback message, then if the client determines that the first encryption curve of the second public key is different from the encryption curve of the first public key, step S200 is executed; if the client determines that the first encryption curve of the second public key is the same as the encryption curve of the first public key, step S201 is executed.

[0121] In step S200, the client sends a greeting message from the third client to the server.

[0122] In some embodiments, the third client greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0123] In some embodiments, the third client greeting message may further include: a third public key; the third public key is determined based on the first encryption suite and / or the first encryption curve.

[0124] In other embodiments, the third client greeting message may further include: a first digital sequence formed by combining a third public key with a first random sequence. The first random sequence is randomly generated by the client.

[0125] For example, the third public key may include: ####, the first random sequence may include ****** (the first random sequence may be a random sequence composed of numbers, uppercase and lowercase letters, and symbols), and the number sequence may include **####****. The first random sequence may be known only to the client to increase the complexity of the first public key transmission and prevent a third party from intercepting the first number sequence and obtaining the first public key based on it. The first random sequence does not participate in the determination of the first key. After receiving the first number sequence, the server removes the first random sequence from the first number sequence to obtain the third public key, and then determines the first key.

[0126] In some embodiments, such as Figure 5 As shown, the third client's greeting message is sent to the server via ClientHello information.

[0127] Step S201: The client determines the first key based on the second public key.

[0128] In some embodiments, the client determining the first key based on the second public key includes: the client determining the first key based on the second public key in the first server feedback message. The second client removes the second random sequence generated by the server from the first server feedback message, obtains the second public key, and determines the first key based on the second public key.

[0129] In some embodiments, the method for determining the first key based on the second public key is the same as the method for determining the key based on the public key in related technologies, and will not be repeated here.

[0130] In some embodiments, such as Figure 5 As shown, the first server feedback message is sent to the server via a ServerHello message.

[0131] Step S202: The server determines the first key based on the first public key or the third public key.

[0132] In some embodiments, if the first encryption curve used to determine the second public key is the same as the encryption curve used to determine the first public key, the server determines the first key based on the first public key in the first client greeting message. The server removes the random sequence from the first client greeting message, obtains the first public key, and determines the first key based on the first public key.

[0133] In other embodiments, if the first encryption curve used to determine the second public key is different from the encryption curve used to determine the first public key, the server determines the first key based on the third public key in the first digital sequence. The server removes the first random sequence from the first digital sequence to obtain the third public key, and determines the first key based on the third public key.

[0134] Step S203: The server sends the first verification information to the client.

[0135] In some embodiments, the server sends first verification information to the client, the first verification information including the server's certificate; the first verification information is used by the client to verify the identity of the server.

[0136] In some embodiments, such as Figure 5 As shown, the first verification information is sent to the client via Authenticate information.

[0137] In some embodiments, the first verification information may be an X.509 certificate or a server-defined integer.

[0138] Step S204: The server sends the first verification data to the client.

[0139] In some embodiments, the server sends first verification data to the client, the first verification data comprising a set of hash values ​​of each frame of messages sent and / or received by the client. For example, first verification data = hash(M1||M2||...||Mn), where M1, M2, ..., Mn are each frame of messages sent and / or received by the client. For example, in this embodiment, when the client sends a first client greeting message to the server, the server sends a first server feedback message to the client, and the server sends first verification information to the client, the first verification data includes: the hash value of the first client greeting message, the hash value of the first server feedback message, and the hash value of the first verification information.

[0140] In some embodiments, such as Figure 5 As shown, the first verification data is sent to the client via the Finished message.

[0141] In other embodiments, the first verification data can also be determined by hash(hash(M1||M2||...||Mn)).

[0142] In some embodiments, the first verification data may be sent after the client and server exchange public keys, including a set of hash values ​​for each frame of messages sent and / or received by the first client; or it may be carried in each message sent by the server to the client.

[0143] In some embodiments, the first verification data carried in each message sent by the server to the client includes: the server determining the first verification data based on a first hash value carried in a recently received message and a second hash value of a message the server is about to send to the client. The first verification data may be the sum of the first hash value and the second hash value. For example, the first hash value in the first client greeting message is obtained based on the first client greeting message; the second hash value of the first server feedback message is determined by the server based on the first server feedback message, wherein the set of hash values ​​of the first client greeting message and the first server feedback message includes the sum of the first hash value and the second hash value; the first hash value and the second hash value have the same length.

[0144] In step S205, the client sends the second verification information to the server.

[0145] In some embodiments, the client sends second verification information to the server, the second verification information including the client's certificate; the second verification information is used by the server to verify the client's identity.

[0146] In some embodiments, such as Figure 5 As shown, the second verification information is sent to the server via the Authenticate information.

[0147] Step S206: The client sends the second verification data to the server.

[0148] In some embodiments, the client sends second verification data to the server. The second verification data includes a set of hash values ​​for each frame of message sent and / or received by the server. For example, the second verification data = hash(M1||M2||...||Mn), where M1, M2, ..., Mn are each frame of message sent and / or received by the server. For example, in this embodiment, when the client sends a first client greeting message to the server, the server sends a first server feedback message to the client, the server sends first verification information to the client, the server sends first verification information to the client, and the client sends second verification information to the server, the first verification data includes: the hash value of the first client greeting message, the hash value of the first server feedback message, the hash value of the first verification information, the hash value of the second verification information, and the hash value of the first verification data.

[0149] In some embodiments, such as Figure 5 As shown, the second verification data is sent to the server via the Finished message.

[0150] In other embodiments, the second verification data can also be obtained by hash(hash(M1||M2||...||Mn)).

[0151] In some embodiments, the second verification data may be sent after the client and server exchange public keys, including a set of hash values ​​for each frame of messages sent and / or received by the first client; or it may be carried in each message sent by the client to the server.

[0152] In some embodiments, the second verification data carried in each message sent by the server to the client includes: the client determining the second verification data based on a third hash value carried in a recently received message and a fourth hash value of a message the client is about to send to the server. The second verification data may be the sum of the third hash value and the fourth hash value. For example, the third hash value in the first client greeting message is obtained based on a first server feedback message; the fourth hash value of the third client greeting message is determined by the client based on the third client greeting message, wherein the second verification data in the third client greeting message includes the sum of the third hash value and the fourth hash value; the first hash value and the second hash value have the same length.

[0153] Thus, the data transmission method provided in this application embodiment allows clients and / or servers with poor performance or low security requirements to use the ECDH network configuration protocol for data transmission. There is no need for developers to pre-select the data transmission process; the client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0154] Figure 6 This illustration shows an optional process diagram for negotiating a shared key using the ECJPAKE distribution protocol, provided in an embodiment of this application. Figure 7 This illustration shows a detailed flowchart of the process for negotiating a shared key using the ECJPAKE distribution protocol, as provided in an embodiment of this application. Figure 6 , Figure 7 Please provide an explanation.

[0155] This embodiment corresponds to scenario 2 in step S103, where the second key negotiation mode is to negotiate the shared key using the ECJPAKE distribution protocol.

[0156] Step S301: The client sends a greeting message from the third client to the server.

[0157] In some embodiments, if the client obtains the first server feedback message from the server based on step S102, and determines based on the first server feedback message that the second key transmission mode is to negotiate a shared key using the ECJPAKE network configuration protocol, the client sends a third client greeting message to the server.

[0158] In some embodiments, the third client greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0159] In some embodiments, the third client greeting message may further include: a second public key list, the second public key list including public key pairs used to determine the first server shared key. The second public key list may also include the client's PIN code.

[0160] In some embodiments, the third client greeting message may further include a fourth public key. The fourth public key is determined based on the first encryption suite and / or the first encryption curve. The fourth public key may also include the client's PIN code.

[0161] In other embodiments, the third client greeting message may further include a second digital sequence formed by combining a fourth public key with a second random sequence. The second random sequence is randomly generated by the client.

[0162] For example, the fourth public key may include: ####, the second random sequence may include ****** (the second random sequence may be a random sequence composed of numbers, uppercase and lowercase letters, and symbols), and the second number sequence may include **####****. The second random sequence may be known only to the server to increase the complexity of the fourth public key transmission and prevent a third party from intercepting the second number sequence and obtaining the fourth public key based on it. The second random sequence does not participate in the determination of the first key. After receiving the second number sequence, the server removes the second random sequence from the second number sequence to obtain the fourth public key, and then determines the first key.

[0163] In some embodiments, such as Figure 7 As shown, the third client's greeting message is sent to the server via ClientHello information.

[0164] Accordingly, the server receives the second public key list and the fourth public key, and determines the first key based on the public key pairs included in the second public key list and the fourth public key.

[0165] Step S302: The server sends a greeting message to the client's first server.

[0166] In some embodiments, the first server greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0167] In some embodiments, the first server greeting message may further include a fifth public key. The fifth public key is determined based on the first encryption suite and / or the first encryption curve. The list of fifth public keys may also include the server's PIN code.

[0168] In other embodiments, the first server greeting message may further include a third digital sequence formed by combining a fifth public key with a third random sequence. The third random sequence is randomly generated by the server.

[0169] In some embodiments, such as Figure 7 As shown, the first server greeting message is sent to the client via ServerHello information.

[0170] Accordingly, the client determines the first key based on the public key pairs included in the first public key list in the first server feedback message and the fifth public key.

[0171] Step S303: The server sends the first verification data to the client.

[0172] In some embodiments, the server sends first verification data to the client, the first verification data comprising a set of hash values ​​of each frame of message sent and / or received by the first client. For example, first verification data = hash(M1||M2||...||Mn), where M1, M2, ..., Mn are each frame of message sent and / or received by the first client. For example, in this embodiment, when the client sends a first client greeting message and a third client greeting message to the server, and the server sends a first server feedback message and a first server greeting message to the client, the first verification data includes: the hash value of the first client greeting message, the hash value of the third client greeting message, the hash value of the first server feedback message, and the hash value of the first server greeting message. Figure 7 As shown, the first verification data is sent to the first client via the Finished message.

[0173] In other embodiments, the first verification data can also be obtained by hash(hash(M1||M2||...||Mn)).

[0174] In some embodiments, the first verification data may be sent after the client and server exchange public keys, including a set of hash values ​​for each frame of messages sent and / or received by the first client; or it may be carried in each message sent by the server to the client.

[0175] In some embodiments, the first verification data carried in each message sent by the server to the client includes: the server determining the first verification data based on a first hash value carried in a recently received message and a second hash value of a message the server is about to send to the client. The first verification data may be the sum of the first hash value and the second hash value. For example, the first hash value in the first client greeting message is obtained based on the first client greeting message; the second hash value in the first server feedback message is determined by the server based on the first server feedback message, wherein the first verification data in the first server feedback message includes the sum of the first hash value and the second hash value; the first hash value and the second hash value have the same length.

[0176] Step S304: The client sends the second verification data to the server.

[0177] In some embodiments, the client sends second verification data to the server. The second verification data includes a set of hash values ​​for each frame of message sent and / or received by the server. For example, the second verification data = hash(M1||M2||...||Mn), where M1, M2, ..., Mn are each frame of message sent and / or received by the server. For example, in this embodiment, when the client sends a first client greeting message to the server, the server sends a first server feedback message to the client, the server sends first verification information to the client, the server sends first verification information to the client, and the client sends second verification information to the server, the first verification data includes: the hash value of the first client greeting message, the hash value of the first server feedback message, the hash value of the first verification information, the hash value of the second verification information, and the hash value of the first verification data.

[0178] In some embodiments, such as Figure 7 As shown, the second verification data is sent to the server via the Finished message.

[0179] In other embodiments, the second verification data can also be obtained by hash(hash(M1||M2||...||Mn)).

[0180] In some embodiments, the second verification data may be sent after the client and server exchange public keys, including a set of hash values ​​for each frame of messages sent and / or received by the first client; or it may be carried in each message sent by the client to the server.

[0181] In some embodiments, the second verification data carried in each message sent by the server to the client includes: the client determining the second verification data based on a third hash value carried in a recently received message and a fourth hash value of a message the client is about to send to the server. The second verification data may be the sum of the third hash value and the fourth hash value. For example, the third hash value in the first client greeting message is obtained based on a first server feedback message; the fourth hash value of the third client greeting message is determined by the client based on the third client greeting message, wherein the second verification data in the third client greeting message includes the sum of the third hash value and the fourth hash value; the first hash value and the second hash value have the same length.

[0182] Thus, this application provides a flexible data transmission method. For terminal devices with good performance and high security requirements, the ECJPAKE network configuration protocol is used for data transmission. There is no need for developers to pre-select the data transmission process; the terminal device or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, for terminal devices with high security requirements, the terminal device's PIN code is combined with the transmission process, increasing the difficulty of cracking the PIN code and improving data transmission security. In addition, in this application embodiment, each frame of message transmitted by the terminal device and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0183] Figure 8 This paper illustrates an optional process diagram of the server side of the data transmission method provided in an embodiment of this application, and will describe each step accordingly.

[0184] Step S401: Receive the first client greeting message sent by the client.

[0185] In some embodiments, the server receives a first client greeting message sent by the client. The first client greeting message includes first information indicating a first key negotiation mode that the client can support.

[0186] In some embodiments, the first key negotiation mode includes using a network distribution protocol negotiation key with ECDH and / or using a network distribution protocol negotiation key with ECJPAKE.

[0187] In some embodiments, the first information includes a first set of encryption suites; the first set of encryption suites includes a set of at least one encryption suite that the client can support.

[0188] In other embodiments, the first client greeting message may further include: a first cipher suite field; the cipher suite field is used to indicate some or all of the cipher suite parameters supported by the client.

[0189] In some embodiments, the first information may further include a first set of encryption curves; the first set of encryption curves includes a set of at least one encryption curve that the client can support.

[0190] In other embodiments, the first client greeting message may further include: a first encryption curve field; the encryption curve field is used to indicate some or all of the encryption curve parameters supported by the client.

[0191] In some embodiments, the first client greeting message further includes: a first public key, which includes: a public key determined by any one of the encryption suites in the first encryption suite set and / or any one of the encryption curves in the first encryption curve set, provided that the client can support the ECDH distribution protocol. Different encryption suites and / or encryption curves determine different public keys.

[0192] In some embodiments, the first client greeting message further includes: a first protocol identifier set, the first protocol identifier set including at least one protocol identifier corresponding to a protocol version, the protocol version and the protocol identifier being in one-to-one correspondence, the first protocol identifier set indicating the set of protocol versions supported by the client.

[0193] In other embodiments, the first client greeting message may further include a protocol version field; the protocol version field is used to indicate some or all of the protocol version parameters supported by the client.

[0194] In some embodiments, the first client greeting message further includes: a first public key list, wherein the first public key list of the first client greeting message is NULL.

[0195] Step S402: Determine the second key negotiation mode selected by the server according to the first key negotiation mode, and send it to the client through the first server feedback message.

[0196] In some embodiments, the server determines the second key negotiation mode selected by the server based on the first key negotiation mode by: the server determining the second key mode supported by the server based on at least one encryption suite included in the first encryption suite set carried in the first client greeting message, at least one encryption curve included in the first encryption curve set, and a protocol identifier corresponding to at least one protocol version included in the first protocol identifier set.

[0197] In some embodiments, where the first client greeting message includes a first set of cipher suites containing at least one cipher suite supported by the server, a first set of encryption curves containing at least one encryption curve supported by the server, and a first set of protocol identifiers containing at least one protocol version supported by the server, the server determines the first cipher suite, the first encryption curve, and the first protocol identifier corresponding to the second key negotiation mode, and sends them to the client via a first server feedback message. If the server determines that the second key negotiation mode is a network configuration protocol negotiation key using ECDH, the first server feedback message further includes: a second public key, which is determined based on at least one of the first cipher suite, the first encryption curve, and the first protocol identifier; or, if the server determines that the second key negotiation mode is a network configuration protocol negotiation key using ECJPAKE, the first server feedback message further includes: a first public key list, which includes public key pairs sent by the server to the client for determining the first client shared key. The first public key list may also include the server's PIN code.

[0198] In other embodiments, if the first set of encryption suites not included in the first client greeting message includes at least one encryption suite supported by the server, or the first set of encryption curves included in the first client greeting message does not include at least one encryption curve supported by the server, or the first set of protocol identifiers included in the first client greeting message does not include a protocol identifier corresponding to at least one protocol version supported by the server, the server sends a first server feedback message to the client based on its own capabilities. The first server feedback message includes: a second encryption suite, a second encryption curve, and a second protocol identifier. The first set of encryption suites does not include the second encryption suite, and the second encryption suite includes any one of the at least one encryption suites supported by the server; the first set of encryption curves does not include the second encryption curve, and the second encryption curve includes any one of the at least one encryption curve supported by the server; the first set of protocol identifiers includes the second protocol identifier, and the second protocol identifier includes a protocol identifier corresponding to any one of the at least one protocol version supported by the server.

[0199] Step S403: If the first key negotiation mode includes the second key negotiation mode, determine the first server shared key based on the second key negotiation mode, and perform target data transmission according to the first server shared key.

[0200] In some embodiments, when the first key negotiation mode includes the second key negotiation mode, a first client shared key is determined based on the second key negotiation mode, and target data is transmitted according to the first client shared key.

[0201] In some embodiments, the first key negotiation mode includes the second key negotiation mode as follows: when the first cipher suite set includes the first cipher suite, the first encryption curve set includes the first encryption curve, and the first protocol identifier set includes the first protocol identifier, the first key negotiation mode includes the second key negotiation mode corresponding to the first cipher suite, the first encryption curve, and the first protocol identifier carried in the first server feedback message.

[0202] In other embodiments, the first key negotiation mode includes the second key negotiation mode, and may further include: the protocol version parameter of the protocol version field of the first client greeting message includes the protocol version parameter of the protocol version field of the first server feedback message; the cipher suite parameter of the cipher suite field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; and the encryption curve parameter of the encryption curve field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message.

[0203] In some embodiments, determining the first client shared key based on the second key negotiation mode includes scenario 1 (steps S201 to S206) and scenario 2 (steps S301 to S304), which will not be repeated here.

[0204] In some embodiments, scenario 1 includes: the second key negotiation mode is a network distribution protocol negotiation key using ECDH; determining the first client shared key based on the second key negotiation mode includes: a network distribution protocol negotiation key using ECDH.

[0205] In some embodiments, scenario 2 includes a network distribution protocol where the second key negotiation mode is ECJPAKE.

[0206] Step S404: If the first key negotiation mode does not include the second key negotiation mode, receive the second client greeting message sent by the client.

[0207] In some embodiments, the first key negotiation mode does not include the second key negotiation mode, including: the first set of cipher suites included in the first client greeting message does not include the second cipher suite carried in the first server feedback message; or, the first set of encryption curves included in the first client greeting message does not include the second encryption curve carried in the first server feedback message; or, the first set of protocol identifiers included in the first client greeting message does not include the second protocol identifier carried in the first server feedback message. That is, the first key negotiation mode does not include the second key negotiation mode corresponding to the cipher suites, encryption curves, and protocol identifiers carried in the first server feedback message.

[0208] In some embodiments, the server receives a second client greeting message sent by the client. The client sending the second client greeting message includes: the client sending a second client greeting message to the server. The second client greeting message includes second information, which is used to indicate a third key negotiation mode that the client can support.

[0209] In some embodiments, the second information includes a second set of cipher suites that the client can support and / or a second set of encryption curves that the client can support. At least one cipher suite included in the first set of cipher suites is completely different from at least one cipher suite included in the second set of cipher suites; at least one encryption curve included in the first set of encryption curves is completely different from at least one encryption curve included in the second set of encryption curves.

[0210] In some embodiments, the second client greeting message further includes a fourth public key, which includes a public key determined by any one of the encryption suites in the second encryption suite set and / or any one of the encryption curves in the second encryption curve set, provided that the client is capable of supporting the ECDH distribution protocol.

[0211] In some embodiments, the second client greeting message further includes: a second protocol identifier set, the second protocol identifier set including at least one protocol identifier corresponding to a protocol version, the protocol version and the protocol identifier being in one-to-one correspondence, the second protocol identifier set indicating the set of protocol versions supported by the client.

[0212] In some embodiments, the second client greeting message further includes: a second public key list, wherein the second public key list of the second client greeting message is NULL.

[0213] In some embodiments, if the server can support the third key negotiation mode, step S405 is executed; if the server cannot support the third key negotiation mode, step S407 is executed.

[0214] Step S405: Based on the second client greeting message, send a second server feedback message. The second server feedback message is used to indicate the fourth key negotiation mode determined by the server.

[0215] In some embodiments, the second server feedback message is used to indicate the fourth key negotiation mode determined by the server.

[0216] In some embodiments, the specific steps for the server to send a second server feedback message based on the second client greeting message are similar to those in step S402, and will not be repeated here.

[0217] Step S406: Determine the second server-side shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client-side shared key.

[0218] In some embodiments, the second client shared key is determined based on the server's fourth key negotiation mode, and the specific steps for transmitting the target data according to the second client shared key are similar to those in step S203, and will not be repeated here.

[0219] Step S407: Send the first warning message.

[0220] In some embodiments, the server's inability to support the third key negotiation mode includes: the second set of cipher suites included in the second client greeting message does not include the cipher suites supported by the server; or, the first set of encryption curves included in the second client greeting message does not include the encryption curves supported by the server; or, the first set of protocol identifiers included in the second client greeting message does not include the protocol identifiers supported by the server.

[0221] In some embodiments, the server sends a first alarm message to the client, the first alarm message being used to indicate disconnection between the client and the server.

[0222] Thus, this application provides a flexible data transmission method. For clients with high performance and high security requirements, the ECJPAKE network configuration protocol is used for data transmission. Developers do not need to pre-select the data transmission process; the client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, for clients with high security requirements, the client's PIN code is combined with the transmission process, increasing the difficulty of PIN code cracking and improving data transmission security. In addition, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0223] Figure 9 This illustration shows an optional flowchart of the data transmission method provided in an embodiment of this application. Figure 10 This illustration shows a detailed processing flowchart of a data transmission method provided in an embodiment of this application, which will be combined with... Figure 9 , Figure 10 Please provide an explanation.

[0224] Step S501: The client sends the first client greeting message to the server.

[0225] In some embodiments, the client sends a first client greeting message to the server. The first client greeting message includes first information, which indicates a first key negotiation mode that the client can support.

[0226] In some embodiments, the first key negotiation mode includes using a network distribution protocol negotiation key with ECDH and / or using a network distribution protocol negotiation key with ECJPAKE.

[0227] In some embodiments, the first information includes at least one of a first cipher suite set, a first encryption curve set, and a first protocol identifier set. The first cipher suite set includes a set of at least one cipher suite that the client can support; the first encryption curve set includes a set of at least one encryption curve that the client can support; the first protocol identifier set includes a protocol identifier corresponding to at least one protocol version, wherein the protocol version and the protocol identifier correspond one-to-one, and the first protocol identifier set indicates the set of protocol versions supported by the client.

[0228] In some embodiments, the first client greeting message is transmitted via Figure 10The ClientHello message transmission is shown in the figure. The "supported_version" field included in the ClientHello message is used to indicate the first protocol identifier set; the "cipher_suites" field included in the ClientHello message is used to indicate the first cipher suite set; the "supported_group" field included in the ClientHello message is used to indicate the first cipher curve set; and the "keyshare" field included in the ClientHello message is used to indicate the first public key.

[0229] In some embodiments, the ClientHello message may also include “ecjpake_key_kp_pair_list” to indicate the public key pair used by the ECJPAKE distribution protocol. In this embodiment, “ecjpake_key_kp_pair_list” is NULL.

[0230] In some embodiments, the "keyshare" field is also used to indicate a fourth random sequence, the fourth random sequence including a sequence randomly generated by the client; further, the "keyshare" field is used to indicate a fourth digital sequence formed by combining the first public key with the fourth random sequence.

[0231] Step S502: The server sends the first server feedback message to the client.

[0232] In some embodiments, the server receives a first client greeting message sent by the client; determining the second key negotiation mode selected by the server according to the first key negotiation mode includes: the server determining the second key mode supported by the server based on at least one encryption suite included in the first encryption suite set carried in the first client greeting message, at least one encryption curve included in the first encryption curve set, and a protocol identifier corresponding to at least one protocol version included in the first protocol identifier set.

[0233] In some embodiments, if the first set of encryption suites included in the first client greeting message includes at least one encryption suite supported by the server, the first set of encryption curves included in the first client greeting message includes at least one encryption curve supported by the server, and the first set of protocol identifiers included in the first client greeting message includes a protocol identifier corresponding to at least one protocol version supported by the server, the server determines the first encryption suite, the first encryption curve, and the first protocol identifier corresponding to the second key negotiation mode, and sends them to the client through a first server feedback message.

[0234] In some embodiments, when the server determines that the second key negotiation mode is to negotiate the key using the ECDH distribution protocol, the first server feedback message further includes: a second public key, which is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identifier.

[0235] In some embodiments, the first server feedback message is transmitted via... Figure 10 The ServerHello message transmission is shown in the figure. The "supported_version" field included in the ServerHello message is used to indicate the first protocol identifier; the "cipher_suites" field included in the ServerHello message is used to indicate the first cipher suite; the "supported_group" field included in the ServerHello message is used to indicate the first encryption curve; and the "keyshare" field included in the ServerHello message is used to indicate the second public key.

[0236] Since this embodiment describes the process of negotiating the key using the ECDH distribution protocol, the ServerHello message does not include "ecjpake_key_kp_pair_list".

[0237] In some embodiments, the "keyshare" field is also used to indicate a second random sequence, the second random sequence including a sequence randomly generated by the server; further, the "keyshare" field is used to indicate a fourth digital sequence formed by combining the second public key with the second random sequence.

[0238] Step S503: The client receives the feedback message from the first server.

[0239] In some embodiments, the client receives the first server feedback message, determines whether the first encryption curve included in the first feedback message is the same as the encryption curve of the first public key included in the first client greeting message, and executes step S504 if the first encryption curve is different from the encryption curve of the first public key; or, if the first encryption curve is the same as the encryption curve of the first public key, executes step S505.

[0240] In step S504, the client sends a second client greeting message to the server.

[0241] In some embodiments, the second client greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0242] In some embodiments, the second client greeting message may further include: a third public key; the third public key is determined based on the first encryption suite and / or the first encryption curve.

[0243] In other embodiments, the second client greeting message may further include: a first digital sequence formed by combining a third public key with a first random sequence. The first random sequence is randomly generated by the client.

[0244] In some embodiments, the second client greeting message is transmitted via Figure 10 The ClientHello message transmission is shown in the figure. The "supported_version" field included in the ClientHello message is used to indicate the first protocol identifier; the "cipher_suites" field included in the ClientHello message is used to indicate the first cipher suite; the "supported_group" field included in the ClientHello message is used to indicate the first encryption curve; and the "keyshare" field included in the ClientHello message is used to indicate the third public key.

[0245] In some embodiments, the ClientHello message may also include “ecjpake_key_kp_pair_list” to indicate the public key pair used by the ECJPAKE distribution protocol. In this embodiment, “ecjpake_key_kp_pair_list” is NULL.

[0246] Step S505: The server determines the first key based on the first public key or the third public key.

[0247] In some embodiments, the server determining the first key based on the first public key includes: if the first encryption curve included in the first feedback message is the same as the encryption curve for determining the first public key included in the first client greeting message, the server determines the first key based on the first client greeting message.

[0248] In some embodiments, the server determines the first key based on the first public key indicated by the "keyshare" field included in the first client greeting message; or, the server removes the fourth random sequence from the fourth digital sequence indicated by the "keyshare" field and determines the first key based on the first public key included in the fourth digital sequence.

[0249] In other embodiments, the server determining the first key based on the first public key includes: if the first encryption curve included in the first feedback message is different from the encryption curve of the first public key included in the first client greeting message, the server determines the first key based on the second client greeting message.

[0250] In some embodiments, the server determines the first key based on the third public key indicated by the "keyshare" field included in the second client greeting message; or, the server removes the first random sequence from the first digital sequence indicated by the "keyshare" field and determines the first key based on the third public key included in the first digital sequence.

[0251] In some embodiments, steps S501 to S505 may be processes executed in the Epoch 0 phase, and the messages transmitted between the client and the server are not encrypted.

[0252] Step S506: The server sends the first verification information to the client.

[0253] The specific steps of step S506 are the same as those of step S203, and will not be repeated here.

[0254] Step S507: The server sends the first verification data to the client.

[0255] The specific steps of step S507 are the same as those of step S204, and will not be repeated here.

[0256] In step S508, the client sends the second verification information to the server.

[0257] The specific steps of step S508 are the same as those of step S205, and will not be repeated here.

[0258] Step S509: The client sends the second verification data to the server.

[0259] The specific steps of step S509 are the same as those of step S206, and will not be repeated here.

[0260] The client sends a second verification message to the server.

[0261] In some embodiments, steps S506 to S509 may be processes executed in the Epoch 1 phase, wherein messages transmitted between the client and the server are encrypted and / or decrypted using a first key.

[0262] In step S510, the client determines the first client shared key and performs target data transmission based on the first client shared key.

[0263] In some embodiments, the client determining the first client shared key includes: the client determining the first client shared key based on at least one of a first public key, a second public key, a third public key, and a first key.

[0264] In some embodiments, if the first verification data passes verification, it indicates that the messages sent and / or received by the client have not been tampered with, and the client can transmit target data based on the first client shared key.

[0265] In step S511, the server determines the first server shared key and transmits the target data according to the first server shared key.

[0266] In some embodiments, the server determining the first server shared key includes: the server determining the first server shared key based on at least one of a first public key, a second public key, a third public key, and a first key.

[0267] In some embodiments, if the second verification data passes verification, it indicates that the messages sent and / or received by the server have not been tampered with, and the server can transmit the target data based on the first server shared key.

[0268] In some embodiments, the first client shared key may be the same as or different from the first server shared key.

[0269] In some embodiments, the first client shared key is determined based on the first key, for example, the first client shared key may include data determined by encrypting the first key.

[0270] In some embodiments, steps S510 to S511 may be processes executed in the Epoch 2 phase, wherein the messages transmitted by the client are encrypted and / or decrypted using a first client shared key; and the messages transmitted by the server are encrypted and / or decrypted using a first server shared key.

[0271] In some embodiments, the method further includes: if the number of times the client sends and / or receives target data encrypted with the first client shared key exceeds a first threshold, the client and the server re-determine the client shared key.

[0272] In some embodiments, if the number of times the client sends and / or receives target data encrypted with the first client shared key exceeds a first threshold, it includes: if the number of times the first client shared key encrypts data is too high, multiple transmissions will increase the risk of the first client shared key being deciphered; if the number of times the target data is encrypted with the first client shared key exceeds the first threshold, the client and the server update the first key and / or the first client shared key.

[0273] Thus, this application provides a flexible data transmission method, eliminating the need for developers to pre-select the data transmission process. The client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0274] Figure 11 This illustration shows another optional flowchart of the data transmission method provided in an embodiment of this application. Figure 12 This illustration shows another detailed processing flowchart of the data transmission method provided in an embodiment of this application, which will be combined with... Figure 11 , Figure 12 Please provide an explanation.

[0275] Step S601: The client sends the first client greeting message to the server.

[0276] The specific process of step S601 is the same as that of step S501, and will not be repeated here.

[0277] Step S602: The server receives the first client greeting message sent by the client.

[0278] In some embodiments, the server receives a first client greeting message sent by the client; determines a second key negotiation mode selected by the server according to the first key negotiation mode, and sends it to the client through the first server feedback message.

[0279] In some embodiments, the server determines the second key negotiation mode selected by the server based on the first key negotiation mode by: the server determining the second key mode supported by the server based on at least one encryption suite included in the first encryption suite set carried in the first client greeting message, at least one encryption curve included in the first encryption curve set, and a protocol identifier corresponding to at least one protocol version included in the first protocol identifier set.

[0280] In some embodiments, if the first set of encryption suites included in the first client greeting message includes at least one encryption suite supported by the server, the first set of encryption curves included in the first client greeting message includes at least one encryption curve supported by the server, and the first set of protocol identifiers included in the first client greeting message includes a protocol identifier corresponding to at least one protocol version supported by the server, the server determines the first encryption suite, the first encryption curve, and the first protocol identifier corresponding to the second key negotiation mode, and sends them to the client through a first server feedback message.

[0281] In some embodiments, when the server determines that the second key negotiation mode is to negotiate the key using the ECJPAKE network configuration protocol, the first server feedback message further includes: a first public key list, wherein the first public key is determined based on at least one of the first cipher suite, the first encryption curve, and the first protocol identifier. The first public key list may also include the server's PIN code.

[0282] In some embodiments, the first server feedback message is transmitted via... Figure 12 The HelloRetryRequest message transmission is shown in the figure. The “supported_version” field included in the HelloRetryRequest message is used to indicate the first protocol identifier; the “cipher_suites” field included in the HelloRetryRequest message is used to indicate the first cipher suite; and the “supported_group” field included in the HelloRetryRequest message is used to indicate the first encryption curve.

[0283] In some embodiments, the "ecjpake_key_kp_params" field included in the HelloRetryRequest message is used to indicate the second public key; or, the "key_share" field included in the HelloRetryRequest message is used to indicate the second public key.

[0284] Since this embodiment describes the process of negotiating keys using the ECJPAKE distribution protocol, the HelloRetryRequest message includes "ecjpake_key_kp_pair_list", which indicates the first public key list.

[0285] In step S603, the client sends a greeting message from the third client to the server.

[0286] In some embodiments, the third client greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0287] In some embodiments, the third client greeting message may further include: a second public key list and a sixth public key; the sixth public key is determined based on the first cipher suite and / or the first encryption curve. The second public key list may further include the client's PIN code.

[0288] In other embodiments, the third client greeting message may further include a first digital sequence formed by combining a sixth public key with a first random sequence. The first random sequence is randomly generated by the client. The sixth public key may also include the client's PIN code.

[0289] In some embodiments, the third client greeting message is transmitted via Figure 12 The ClientHello message transmission is shown in the figure. The “supported_version” field included in the ClientHello message is used to indicate the first protocol identifier; the “cipher_suites” field included in the ClientHello message is used to indicate the first cipher suite; and the “supported_group” field included in the ClientHello message is used to indicate the first encryption curve.

[0290] In some embodiments, the "ecjpake_key_kp_params" field included in the ClientHello message is used to indicate the sixth public key; or, the "key_share" field included in the ClientHello message is used to indicate the sixth public key.

[0291] In some embodiments, the ClientHello message may also include “ecjpake_key_kp_pair_list” to indicate a second public key list used by the ECJPAKE distribution protocol.

[0292] Step S604: The server sends a greeting message to the client's first server.

[0293] In some embodiments, the first server greeting message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.

[0294] In some embodiments, the first server greeting message may further include a fifth public key. The fifth public key is determined based on the first encryption suite and / or the first encryption curve. The fifth public key may also include the server's PIN code.

[0295] In other embodiments, the first server greeting message may further include a third digital sequence formed by combining a fifth public key with a third random sequence. The third random sequence is randomly generated by the server.

[0296] In some embodiments, the first server greeting message is transmitted via... Figure 12The ServerHello message transmission is shown in the figure. The "supported_version" field included in the ServerHello message is used to indicate the first protocol identifier; the "cipher_suites" field included in the ServerHello message is used to indicate the first cipher suite; and the "supported_group" field included in the ServerHello message is used to indicate the first encryption curve.

[0297] In some embodiments, the "ecjpake_key_kp_params" field included in the ServerHello message is used to indicate the fifth public key; or, the "key_share" field included in the ServerHello message is used to indicate the fifth public key.

[0298] In some embodiments, steps S601 to S604 may be processes executed in the Epoch 0 phase, and the messages transmitted between the client and the server are not encrypted.

[0299] Step S605: The server sends the first verification data to the client.

[0300] The specific process of step S605 is the same as that of step S303, and will not be repeated here.

[0301] Step S606: The client sends the second verification data to the server.

[0302] The specific process of step S606 is the same as that of step S303, and will not be repeated here.

[0303] In some embodiments, steps S605 to S606 may be processes executed in the Epoch 1 phase, where messages transmitted between the client and the server are encrypted and / or decrypted using a first key.

[0304] In step S607, the client determines the first client shared key and performs target data transmission based on the first client shared key.

[0305] In some embodiments, the client determines the first client shared key by: the client determining the first client shared key based on at least one of a fifth public key, a sixth public key, a first public key list, a second public key list, and a first key.

[0306] In some embodiments, if the first verification data passes verification, it indicates that the messages sent and / or received by the client have not been tampered with, and the client can transmit target data based on the first client shared key.

[0307] In step S608, the server determines the first server shared key and transmits the target data according to the first server shared key.

[0308] In some embodiments, the server determining the first server shared key includes: the server determining the first server shared key based on at least one of a fifth public key, a sixth public key, a first public key list, a second public key list, and a first key.

[0309] In some embodiments, if the second verification data passes verification, it indicates that the messages sent and / or received by the server have not been tampered with, and the server can transmit the target data based on the first server shared key.

[0310] In some embodiments, the first client shared key may be the same as or different from the first server shared key.

[0311] In some embodiments, the first client shared key is determined based on the first key, for example, the first client shared key may include data determined by encrypting the first key.

[0312] In some embodiments, steps S510 to S511 may be processes executed during the Epoch 2 phase, wherein the messages and / or data transmitted by the client are encrypted and decrypted using a first client shared key; and the messages and / or data transmitted by the server are encrypted and decrypted using a first server shared key.

[0313] In some embodiments, the method further includes: if the number of times the client sends and / or receives target data encrypted with the first client shared key exceeds a first threshold, the client and the server re-determine the client shared key.

[0314] In some embodiments, if the number of times the client sends and / or receives target data encrypted with the first client shared key exceeds a first threshold, it includes: if the number of times the first client shared key encrypts data is too high, multiple transmissions will increase the risk of the first client shared key being deciphered; if the number of times the target data is encrypted with the first client shared key exceeds the first threshold, the client and the server update the first key and / or the first client shared key.

[0315] Thus, this application provides a flexible data transmission method. For clients with high performance and high security requirements, the ECJPAKE network configuration protocol is used for data transmission. Developers do not need to pre-select the data transmission process; the client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, for clients with high security requirements, the client's PIN code is combined with the transmission process, increasing the difficulty of PIN code cracking and improving data transmission security. In addition, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0316] Figure 13 This illustration shows another optional flowchart of the data transmission method provided in an embodiment of this application. Figure 14 This illustration shows another detailed processing flowchart of the data transmission method provided in an embodiment of this application, which will be combined with... Figure 13 , Figure 14 Please provide an explanation.

[0317] Step S801: The client sends the first client greeting message to the server.

[0318] The specific process of step S801 is the same as that of step S501, and will not be repeated here.

[0319] In step S802, the server sends the first server feedback message to the client.

[0320] In some embodiments, if the first set of encryption suites not included in the first client greeting message includes at least one encryption suite supported by the server, or the first set of encryption curves included in the first client greeting message does not include at least one encryption curve supported by the server, or the first set of protocol identifiers included in the first client greeting message does not include a protocol identifier corresponding to at least one protocol version supported by the server, the server sends a first server feedback message to the client based on its own capabilities. The first server feedback message includes: a second encryption suite, a second encryption curve, and a second protocol identifier. The first set of encryption suites does not include the second encryption suite, and the second encryption suite includes any one of the at least one encryption suites supported by the server; the first set of encryption curves does not include the second encryption curve, and the second encryption curve includes any one of the at least one encryption curve supported by the server; the first set of protocol identifiers includes the second protocol identifier, and the second protocol identifier includes a protocol identifier corresponding to any one of the at least one protocol version supported by the server.

[0321] In some embodiments, the first server feedback message is transmitted via... Figure 14 The HelloRetryRequest message transmission is shown in the figure. The “supported_version” field included in the HelloRetryRequest message is used to indicate the second protocol identifier; the “cipher_suites” field included in the HelloRetryRequest message is used to indicate the second cipher suite; and the “supported_group” field included in the HelloRetryRequest message is used to indicate the second cipher curve.

[0322] In some embodiments, the "ecjpake_key_kp_params" field included in the HelloRetryRequest message is used to indicate the second public key; or, the "key_share" field included in the HelloRetryRequest message is used to indicate the second public key.

[0323] In some embodiments, if the first key negotiation mode includes the second encryption suite, the second encryption curve, and the second key negotiation mode corresponding to the second protocol identifier, steps S503 to S511 are executed; or steps S603 to S608 are executed. If the first key negotiation mode does not include the second encryption suite, the second encryption curve, and the second key negotiation mode corresponding to the second protocol identifier, step S803 is executed.

[0324] In step S803, the client sends a second client greeting message to the server.

[0325] In some embodiments, the client sending a second client greeting message includes: the client sending a second client greeting message to the server, the second client greeting message including second information, the second information being used to indicate a third key negotiation mode that the client can support.

[0326] In some embodiments, the second information includes a second set of cipher suites that the client can support and / or a second set of encryption curves that the client can support. At least one cipher suite included in the first set of cipher suites is completely different from at least one cipher suite included in the second set of cipher suites; at least one encryption curve included in the first set of encryption curves is completely different from at least one encryption curve included in the second set of encryption curves.

[0327] In some embodiments, the second client greeting message further includes a fourth public key, which includes a public key determined by any one of the encryption suites in the second encryption suite set and / or any one of the encryption curves in the second encryption curve set, provided that the client is capable of supporting the ECDH distribution protocol.

[0328] In some embodiments, the second client greeting message further includes: a second protocol identifier set, the second protocol identifier set including at least one protocol identifier corresponding to a protocol version, the protocol version and the protocol identifier being in one-to-one correspondence, the second protocol identifier set indicating the set of protocol versions supported by the client.

[0329] In some embodiments, the second client greeting message further includes a second public key list, wherein the second public key list of the second client greeting message is empty (NULL).

[0330] In some embodiments, the second client greeting message is transmitted via Figure 14 The ClientHello message transmission is shown in the figure. The "supported_version" field included in the ClientHello message is used to indicate the second protocol identifier set; the "cipher_suites" field included in the ClientHello message is used to indicate the second cipher suite set; and the "supported_group" field included in the ClientHello message is used to indicate the second cipher curve set.

[0331] In some embodiments, the “ecjpake_key_kp_params” field included in the ClientHello message is used to indicate the fourth public key; or, the “key_share” field included in the ClientHello message is used to indicate the fourth public key.

[0332] In some embodiments, the ClientHello message may also include “ecjpake_key_kp_pair_list” to indicate the public key pair used by the ECJPAKE distribution protocol. In this embodiment, “ecjpake_key_kp_pair_list” is NULL.

[0333] In some embodiments, if the third key negotiation mode includes a fourth key negotiation mode corresponding to the encryption suites, encryption curves, and protocol identifiers supported by the server, step S804 is executed. If the third key negotiation mode does not include a fourth key negotiation mode corresponding to the encryption suites, encryption curves, and protocol identifiers supported by the server, step S805 is executed.

[0334] Step S804: The server sends the second server feedback information.

[0335] In some embodiments, where the second set of cipher suites included in the second client greeting message includes at least one cipher suite supported by the server, the second set of encryption curves included in the second client greeting message includes at least one encryption curve supported by the server, and the second set of protocol identifiers included in the second client greeting message includes a protocol identifier corresponding to at least one protocol version supported by the server, the server determines the second cipher suite, the second encryption curve, and the second protocol identifier corresponding to the fourth key negotiation mode, and sends them to the client via a second server feedback message. If the server determines that the fourth key negotiation mode is a network configuration protocol negotiation key using ECDH, the first server feedback message further includes: a fourth public key, which is determined based on at least one of the second cipher suite, the second encryption curve, and the second protocol identifier; or, if the server determines that the second key negotiation mode is a network configuration protocol negotiation key using ECJPAKE, the first server feedback message further includes: a third public key list, which includes public key pairs sent by the server to the client for determining the first client shared key.

[0336] In some embodiments, the first server feedback message is transmitted via... Figure 14 The ServerHello message transmission is shown in the figure. The "supported_version" field included in the ServerHello message is used to indicate the second protocol identifier; the "cipher_suites" field included in the ServerHello message is used to indicate the second cipher suite; the "supported_group" field included in the ServerHello message is used to indicate the second encryption curve; and the "keyshare" field included in the ServerHello message is used to indicate the fourth public key.

[0337] In some embodiments, if the client and server use the ECDH network configuration protocol to negotiate the key, the ServerHello message does not include "ecjpake_key_kp_pair_list"; if the client and server use the ECJPAKE network configuration protocol to negotiate the key, the ServerHello message also includes "ecjpake_key_kp_pair_list", where "ecjpake_key_kp_pair_list" indicates the first public key list.

[0338] In some embodiments, the method further includes: executing the process of steps S503 to S511, or executing the process of steps S603 to S608.

[0339] Step S805: The server sends the first warning message.

[0340] In some embodiments, the server's inability to support the third key negotiation mode includes: the second set of cipher suites included in the second client greeting message does not include the cipher suites supported by the server; or, the first set of encryption curves included in the second client greeting message does not include the encryption curves supported by the server; or, the first set of protocol identifiers included in the second client greeting message does not include the protocol identifiers supported by the server.

[0341] In some embodiments, the server sends a first alarm message to the client, the first alarm message being used to indicate disconnection between the client and the server.

[0342] In some embodiments, the method further includes:

[0343] In step S806, the client sends a second warning message.

[0344] In some embodiments, if the message received by the client from the server includes two or more encryption curves, two or more encryption suites, or two or more version identifiers, the client sends a second warning message to the server and disconnects from the server; the second warning message is used to indicate the disconnection of the connection between the client and the server.

[0345] In some embodiments, the messages sent by the server include: a first server feedback message and / or a first server greeting message.

[0346] Thus, this application provides a flexible data transmission method. For clients with lower performance and less stringent security requirements, the ECDH network configuration protocol is used for data transmission; for clients with higher performance and more stringent security requirements, the ECJPAKE network configuration protocol is used. Developers do not need to pre-select the data transmission process; the client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, for clients with high security requirements, the client's PIN code is combined with the transmission process, increasing the difficulty of PIN code cracking and improving data transmission security. In addition, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0347] Figure 15 This illustration shows another optional flowchart of the data transmission method provided in an embodiment of this application.

[0348] Step S901: The client sends a client greeting message to the server.

[0349] In some embodiments, when the client greeting message is sent for the first time in a round of negotiation, the client greeting message includes at least one of the following: a protocol version field indicating some or all protocol version parameters supported by the client; a cipher suite field indicating some or all cipher suite parameters supported by the client; a cryptographic curve field indicating some or all cryptographic curve parameters supported by the client; a first public key field indicating the client's first public key; and a second public key field that is empty or does not include a second public key field.

[0350] Step S902: Receive a request from the server to resend the greeting message, server greeting message, or warning message based on the client's greeting message.

[0351] In some embodiments, when the request to retransmit the greeting message is the first request to retransmit the greeting message sent by the server in a round of negotiation, the client greeting message is retransmitted; and / or, when the request to retransmit the greeting message is the second request to retransmit the greeting message sent by the server in a round of negotiation, a warning message is sent and the connection is disconnected; and / or, when the server greeting message sent by the server is missing any required field, a warning message is sent and the connection is disconnected; and / or, when the protocol version number field of the server greeting message sent by the server includes multiple protocol versions, a warning message is sent and the connection is disconnected; and / or, when the cipher suite field of the server greeting message sent by the server includes multiple cipher suite parameters or does not support cipher suite parameters, a warning message is sent and the connection is disconnected; and / or, when the encryption curve field of the server greeting message sent by the server includes multiple encryption curve parameters or does not support encryption curve parameters, a warning message is sent and the connection is disconnected; and / or, when the first public key field of the server greeting message sent by the server includes multiple first public keys, a warning message is sent and the connection is disconnected.

[0352] Step S903: Generate a client-shared key based on the public key sent by the server.

[0353] In some embodiments, when the client is able to support the key negotiation mode indicated by the request retransmission feedback message or the server greeting message sent by the server, a client shared key is generated based on the server public key carried in the request retransmission feedback message or the server greeting message.

[0354] Thus, this application provides a flexible data transmission method, eliminating the need for developers to pre-select the data transmission process. The client or server can determine the transmission process according to actual needs. Furthermore, in this application embodiment, each frame of message transmitted by the client and / or server participates in the hash value calculation of the verification data, ensuring that the handshake negotiation data is not tampered with and improving the security and reliability of the handshake negotiation process.

[0355] Figure 16 This paper illustrates another optional flowchart of the data transmission method provided in the embodiments of this application, which will be described step by step.

[0356] In step S1001, the first end negotiates a shared key with the second end through a handshake message.

[0357] In some embodiments, if the first end is a client, the second end is a server; or if the first end is a server, the second end is a client.

[0358] The client negotiates a shared key with the server via a handshake message, including steps S101 to S108, or steps S200 to S206, or steps S301 to S304, or steps S401 to S407, or steps S501 to S511, or steps S601 to S608, or steps S801 to S806, or steps S901 to S903. Figure 5 , Figure 7 , Figure 10 , Figure 12 and Figure 14 The specific process illustrated herein will not be repeated here. Accordingly, the handshake messages include at least one of the following: a first client greeting message, a first server feedback message, a second client greeting message, a first server greeting message, a third client greeting message, a first warning message, and a second warning message.

[0359] In some embodiments, the handshake message includes a handshake greeting message and a handshake response message; the handshake greeting message includes at least one of a first client greeting message, a second client greeting message, and a third client greeting message; the handshake response message includes a first server greeting message; and the retransmission request message includes a first server feedback message.

[0360] The message payload of the handshake greeting message or the handshake response message includes a public key list field, the value of which is NULL. This NULL value is used to determine whether the second end supports the target cipher suite. The public key list field is indicated by the "ecjpake_key_kp_pair_list" field.

[0361] In some embodiments, the method further includes: during the key negotiation process, the first end verifies the handshake message to obtain a verification value. The handshake message includes a handshake completion message, used to indicate the completion of the key negotiation process, wherein the handshake completion message carries the verification value.

[0362] In some embodiments, the handshake completion message may include first verification data in steps S204, S303, S507, and S605, and / or second verification data in steps S205, S304, S509, and S606; correspondingly, the verification value may be a hash value carried in the first verification data and / or the second verification data.

[0363] In step S1002, the first end transmits application data to the second end through content messages, wherein the content messages are encrypted and decrypted using the shared key.

[0364] In some embodiments, the content message includes target data transmitted by the first end and the second segment. The first end and the second segment encrypt and decrypt the content message transmitted by the first end and the second segment using the shared key.

[0365] In some embodiments, the method further includes: encrypting the message payload in the content message using the shared key. The message payload includes: a protocol version field, a cipher suite field, a shared key field, and an encryption curve field. The protocol version field includes... Figures 3 to 16 The “supported_version” field in the process; the encryption suite field includes Figures 3 to 16 The "cipher_suites" field in the process; the shared key field includes Figures 3 to 16 The process includes at least one of the following fields: "key_share", "ecjpake_key_kp_pair_list", and "ecjpake_key_kp_params"; the encryption curve field includes... Figures 3 to 16 The “supported_group” field in the process.

[0366] In some embodiments, the handshake greeting message includes Figures 3 to 16 The process includes a first client greeting message, a second client greeting message, and a third client greeting message; the handshake response message includes... Figures 3 to 16 The process includes a first server-side greeting message; the retransmission request message includes... Figures 3 to 16 The process includes a first server-side feedback message and / or a second server-side feedback message; the authentication data message includes... Figures 3 to 16 The process includes first verification information and / or second verification information; the handshake completion message includes Figures 3 to 16 The process includes first verification data and / or second verification data.

[0367] In some embodiments, such as Figures 3 to 16 The process includes a first client greeting message, a first server feedback message, a second client greeting message, a first server greeting message, and a third server greeting message, all of which have the same message format. The message format includes a message count and a message payload. The message count includes a key algebra (Epoch) identifier and a message count (Seq), wherein the key algebra is represented by bits less than the first bit, and the message count is represented by bits less than the second bit.

[0368] In some embodiments, the first bit may be 2; the second bit may be 8.

[0369] In some embodiments, the message payloads of the first client greeting message, the first server feedback message, the second client greeting message, the first server greeting message, and the third server greeting message include at least one or more of the following fields: protocol version field, cipher suite field, shared key field, and encryption curve field.

[0370] The key algebra is represented by E, which represents the least significant bit of the Epoch. The Epoch indicates the form of the symmetric key currently in use, as shown in Table 1. In the case of Epoch 0, no key is used; in the case of Epoch 1, the first key is used; in the case of Epoch 2, the second key is used, and so on.

[0371] In some embodiments, when the first end negotiates a key with the second end via the handshake greeting message, the handshake response message, or the retransmission request message, the key algebra is identified as 'a'; when the first end negotiates a key with the second end via the authentication data message or the handshake completion message, the key algebra is identified as 'a+1'; when the first end transmits application data with the second end via the content message, the key algebra is identified as 'a+2' to 'a+N'; where 'a' is an integer, and 'N' is an integer greater than or equal to 2. The key algebra of the application data transmitted first is less than the key algebra of the application data transmitted later.

[0372] For example, when a=0, steps S501 to S505 can be the process executed in Epoch 0, where the messages transmitted between the client and the server are not encrypted; steps S506 to S509 can be the process executed in Epoch 1, where the messages transmitted between the client and the server are encrypted and / or decrypted using a first key; the transmission of the application data can be in Epoch 2 to Epoch N, where the messages transmitted between the client and the server are encrypted and / or decrypted using a shared key.

[0373] In some embodiments, the message count includes 8 bytes, each byte occupying 8 bits (8 bits of information), wherein the first 2 bytes of the message count represent the Epoch (occupying 16 bits). In this embodiment, E is represented by bits less than the first bit; E can be the lowest bit of the corresponding Epoch (occupying 1 bit), or E can be the lowest 0 bit of the corresponding Epoch (not occupying bit information).

[0374] In some embodiments, the message payload of the handshake greeting message or the handshake response message includes an ecjpake_key_kp_pair_list field, where the value of the public key list field is NULL. This NULL value is used to determine whether the second end supports the target cipher suite.

[0375] In some embodiments, the second end returns the retransmission request message based on the handshake greeting message, wherein the cipher suite field in the retransmission request message is configured as the target cipher suite.

[0376] Table 1

[0377]

[0378]

[0379] At different stages, the data sent and / or received by the client and server are encrypted and decrypted using different keys. After the handshake is completed, Epoch 2 begins. If a key update is needed subsequently, it can be synchronized between the client and server, thus entering Epoch N.

[0380] Figure 17 This illustration shows an optional structural diagram of the message content transmitted between the client and the server according to an embodiment of this application.

[0381] Figure 17 In this context, Seq stands for message count, and is used to indicate the sequence number of the message corresponding to the Seq that is transmitted by the client and / or server (i.e., which message the Seq corresponds to is the nth message transmitted by the client and / or server).

[0382] In some embodiments, the message count comprises 8 bytes, each byte occupying 8 bits (8 bits of information), wherein the last 6 bytes of the message count represent the Seq (occupying 48 bits). In this embodiment, the message count identifier is represented by the bit information of the least significant third bit of the message count; the value of the message count identifier is equal to the sum of the values ​​of the adjacent message count identifiers transmitted previously and 1. The third bit is less than the second bit. When the second bit is 8, the third bit can be 7, and correspondingly, the message count identifier is the least significant 7 bits of the message count; or, when the second bit is 8, the third bit can be 6, and correspondingly, the message count identifier is the least significant 6 bits of the message count. That is to say, in this embodiment, using less than or equal to 8 bits of information to represent the message sequence number reduces the message sequence number by 1-2 bytes compared to the byte length of the current standard ECJPAKE distribution protocol, making it more concise and reducing the amount of data transmitted.

[0383] In some embodiments, the message payload includes actual data and a message type, wherein the message type includes a padding type, an application data type, a warning type, and a handshake type.

[0384] Figure 17 In this context, the payload is the actual data, including: transmission data carried in the verification data encrypted with the first key; or, transmission data carried in the application data encrypted with the shared key; or, transmission data carried in the handshake information. Specifically, the transmission data carried in the verification data encrypted with the first key may be a set of hash values ​​included in the verification data; the transmission data carried in the application data encrypted with the first key may be application data to be transmitted (such as turning on lights, turning off lights, starting sweeping, opening curtains, etc.); the transmission data carried in the handshake information may be at least one of a public key, a random sequence, an encryption curve, a cipher suite, a protocol identifier, or a list of public keys.

[0385] Figure 17 In the text, "+" indicates an extension attached to the message; "{}" indicates Epoch 1, meaning the message is encrypted using a key derived from [sender]HandshakeTraffic; "[]" indicates Epoch 2, meaning the message is encrypted using a key derived from [sender]ApplicationTraffic.

[0386] Figure 17 In this context, the message format includes: E, Seq, and Payload; the Payload includes Content and Type.

[0387] The payload includes a message payload, and the payload data is encrypted except for the 0th generation key (Epoch 0).

[0388] The message payload includes actual data and message type, and the message type includes padding type, application data type, warning type, and handshake type. The definitions of the message type are shown in Table 2.

[0389] Table 2

[0390] 0 Padding padding byte 0 1 Application Data Application layer messages 2 Alter Notification message 3 Handshake Handshake negotiation message

[0391] The padding types mentioned include Padding from Table 2, used to pad the Payload to an appropriate length. The Content portion corresponding to Padding is still in Payload format, meaning the last byte needs to be re-evaluated based on the message type. During parsing, the Padding at the end of the Payload can be skipped.

[0392] As shown in Table 2, the application data types include Application Data in Table 2, which includes application data transmitted between the first client and / or server, such as data on turning lights on and off, environmental information collection, and biometric data collection.

[0393] The warning types include the notification messages in Table 2, specifically messages that inform the ECDH distribution protocol or ECJPAKE distribution protocol of handshake success or handshake failure, such as first warning message, second warning message, etc.

[0394] The handshake type includes the handshake negotiation messages in Table 2, specifically including at least one of the following: first information, second sequence, first verification data, first verification information, second verification data, second verification information, third sequence, first retransmission request, and first greeting information.

[0395] As shown in Table 2, Alert is used to send alarm messages, and the code includes:

[0396]

[0397] Upon receiving an alarm message, the client or server must disconnect.

[0398] In some embodiments, when the payload content is a Handshake, the Handshake message code includes:

[0399]

[0400]

[0401] In some embodiments, the Handshake is used to send a handshake message, which includes at least one of the following: first information, second sequence, first verification data, first verification information, second verification data, second verification information, third sequence, first retransmission request, and first greeting information.

[0402] In some embodiments, if at least one Handshake message has the same Epoch, the end sending the at least one Handshake message can merge the at least one Handshake message, thus requiring only one encryption.

[0403] Accordingly, when decrypting data at the receiving end of the message, the boundary of each Handshake message is determined by Handshake.len, and all Handshakes contained in a message are determined by the length of the entire message.

[0404] Figure 14In the ClientHello message sent by the client, the code includes:

[0405]

[0406] The `random` parameter contains 8 bytes of random data to prevent replay attacks. The `extension` parameter describes the client's capabilities and related parameters. All extensions within the `Extension` parameter must be arranged in ascending order of their extension type.

[0407] ClientHello is the first message in the protocol negotiation, sent by the client to the server. It is used to inform the server of the client's authentication capabilities and custom parameters.

[0408] Figure 14 In the ServerHello message sent by the server, the code includes:

[0409]

[0410] The `random` parameter contains 32 bytes of random data to prevent replay attacks. The `extension` parameter describes the server's capabilities and related parameters. All extensions in the `Extension` parameter must be arranged in ascending order of extension type. Only when an extension is specified in `ClientHello` (meaning the client supports that extension) is the corresponding extension allowed to be acknowledged in the `ServerHello` response.

[0411] ServerHello is sent by the server to the client to determine the connection parameters of the session.

[0412] ClientHello is the first message in the protocol negotiation, sent by the client to the server. It is used to inform the server of the client's authentication capabilities and custom parameters.

[0413] When the client processes ServerHello, if it finds any unsupported extensions, it must send an unexpected_message warning to the server and disconnect. Similarly, if the server finds that a required extension is missing, it must send an unexpected_message warning to the client and disconnect.

[0414] Figure 14 In the code, the HelloRetryRequest message includes:

[0415]

[0416] The `extensions` parameter represents extensions, describing the server's capabilities and related parameters. After the client sends a `ClientHello` to the server for the first time, the server may send a `HelloRetryRequest` to request the client to renegotiate. A common scenario is that the server does not support the key-share curve provided by the client. For example, the client provides the `secp256r1` curve, but the server only supports the `C25519` curve. In this case, the server needs to find the `supported_group` extension from the `ClientHello`, find the curve that can be negotiated from the `supported_group`, and then use the `HelloRetryRequest` message to notify the client to renegotiate.

[0417] During the process of negotiating the shared key between the client and server, a RetryRequest is only allowed to be initiated once. For the server, if the parameters sent by the second ClientHello request are still unacceptable, the server must send a handshake_failure warning and close the connection. For the client, if it receives a second HelloRetryRequest, the client must send an unexpected_message and disconnect.

[0418] The HelloRetryRequest message is used in the ECDH network configuration protocol to respond to erroneous ClientHello messages; or in the ECJPAKE network configuration protocol to transmit ECJPAKE Round 1 data.

[0419] In some embodiments, the response to the erroneous ClientHello message in the ECDH distribution protocol includes steps S301 to S302, which will not be repeated here; the transmission of ECJPAKERound 1 data in the ECJPAKE distribution protocol includes steps S401 to S402, which will not be repeated here.

[0420] Figure 14 In the code, the Authenticate message includes:

[0421]

[0422] The Authenticate message is used to transmit authentication data. The message format varies depending on the value of the Authentication column defined in cipher_suites. Specifically, when Authentication is set to None, this message must be omitted. The Authenticate message is constructed differently for different authentication methods.

[0423] When the authentication method uses the ECDH network configuration protocol, the Authenticate message code includes:

[0424]

[0425] The Authenticate message is used for certificate authentication of ECDH and supports two types of certificates: X.509 certificates and custom certificates.

[0426] Figure 14 In the code, the Finished message includes:

[0427]

[0428] Here, `verify_data` is used to calculate the HMAC using the current Transcripthash value. The calculation method includes:

[0429]

[0430] Among them, TranscriptHash: Server: TranscriptHash(ClientHello1...ServerAuthenticate).

[0431] Client: TranscriptHash(ClientHello1...Server Authenticate, ServerFinished, Client Authenticate).

[0432] Finished Key: Server: Expand (PRK=ServerHandshakeTraffic, |abe|=”htbtsfinished”, len=Hash Length).

[0433] Client:Expand(PRK=ClientHandshakeTraffic,|abe|=”htbts finished”,len=Hash Length)

[0434] Figure 14 In the Application Data message, the Content portion contains complete user data.

[0435] In the message code, "extension" provides supplementary information about the message, and the code includes:

[0436]

[0437] Wherein, `extension_data` represents the extended data defined within each extension type; `data_size` represents the data length. The encoding method can refer to variable-length integers. `data_size` is no greater than 16383 bytes, meaning that `data_size` can only be 1 byte or 2 bytes after encoding. When encoded as 2 bytes, the highest bit of the first byte is 1, and the highest bit of the second byte is not 1. During decoding, if `data_size` is found to be inconsistent with requirements, an `unexpected_message` should be sent and the connection closed; `extension_type` represents the message type of the Extension, as shown in Table 3.

[0438] Table 3

[0439] 0 supported_version CR (required), SR (required), HRR (required) 1 cipher_suits CR (required), SR (required), HRR (required) 2 supported_group CR, SR, HRR 4 key_share CR (required), SR (required) 5 Ecjpake_key_kp_pair_list CR, SR 6 Ecjpake_key_kp_params CR, SR

[0440] The term "applies to" is used to identify messages for which the corresponding extensions are allowed. Message names are represented by abbreviations: CR (ClientHello), SR (ServerHello), HRR (HelloRetryRequest), AU (Authenticate).

[0441] Here, "required" means that it must be present in the response message. If a required extension is missing from the message sent by the other end, an unexpected_message must be sent and the connection closed.

[0442] In Table 3, Type 0 represents the version number; Type 1 represents the encryption suite, which can be ECDH, (Diffle-Hellman, DH), etc.; Type 2 represents the curve type used, such as elliptic curve; Type 4 represents the public key exchange; and Type 5 and Type 6 represent the public keys at different stages.

[0443] Figure 14 In the code, supported_version includes:

[0444]

[0445] The `supported_version` indicates the protocol version supported by the client or server. Currently, the protocol version is 1.

[0446] The `supported_version` parameter must be added to `ClientHello`, `ServerHello`, and `HelloRetryRequest`, and a `Version` parameter must be entered. The `Version` entered by the server will be used as the protocol version for this connection.

[0447] In some embodiments, when the Client finds multiple Versions in the supported_version extension or finds that the Version itself is not supported in the received ServerHello, the Client should send a protocol_version warning and close the connection.

[0448] Figure 14 In the code, cipher_suites includes:

[0449]

[0450] The cipher_suites indicates the cryptographic suites supported by the client or server. The cipher_suites include CipherSuite, Sym, KeyExchange, Authentication, Cipher, MAC Tag, and Hash.

[0451] CipherSuite indicates the uint8 value of the cipher suite; Sym indicates the cipher suite name, used for naming consistency within a single implementation. KeyExchange indicates the key exchange method, affecting key_share extension. Authentication indicates the authentication method, affecting the Authenticate message; Cipher indicates the data encryption method, required during encryption; MAC Tag indicates the MAC Tag length of the cipher suite. Hash indicates the hash function used by functions such as HKDF and HMAC during protocol execution.

[0452] In some embodiments, the client enters one or more CipherSuites in ClientHello. The server selects and enters a CipherSuite in ServerHello and HelloRetryRequest. The CipherSuite entered by the server will be used as the encryption suite for this connection.

[0453] In some embodiments, the 0x00 (None) encryption suite is not permitted for non-debugging purposes.

[0454] In some embodiments, when the Client finds in the received ServerHello that there are multiple cipher_suites in the cipher_suites extension or that cipher_suites itself is not supported, the Client should send an unexpected_message warning and close the connection.

[0455] Figure 14 In the code, the supported_group includes:

[0456]

[0457] In some embodiments, the supported EC curve parameters are defined as shown in Table 4:

[0458] Table 4

[0459] 0x17 secp256r1 0x18 secp384r1 0x19 secp521r1 0x1D x25519

[0460] In this process, the Client enters one or more NamedGroups it supports in ClientHello, while the Server selects and enters a NamedGroup in ServerHello and HelloRetryRequest. The NamedGroup entered by the Server will be used as the EC curve for this connection.

[0461] In some embodiments, when the Client finds multiple NamedGroups in the supported_group extension or finds that NamedGroup itself is not supported in the received ServerHello, the Client should send an unexpected_message warning and close the connection.

[0462] Figure 14 In the code, key_share includes:

[0463]

[0464] The `key_share` parameter is used to share a secret key with the other party. It is used for key negotiation. `key_share` may be used in the `ClientHello`, `ServerHello`, and `HelloRetryRequest` messages.

[0465] In some embodiments, multiple `key_shares` can appear in `ClientHello` for the server to choose from. In `ServerHello`, only one `key_shares` can appear, used for key negotiation. In `HelloRetryRequest`, only one `key_shares` can appear, and its length (len) is 0. It is only used to inform the client to re-initiate `ClientHello`.

[0466] In some embodiments, if the Client finds multiple key_shareEntries in the extension or finds that NamedGroup itself is not supported in the received ServerHello, the Client should send an unexpected_message warning and close the connection.

[0467] Figure 14 In the code snippet, ecjpake_key_kp_pair_list includes:

[0468]

[0469] In some embodiments, if it is uncertain whether the server supports ECJPAKE authentication, the client should include an empty ecjpake_key_pair_list in the first ClientHello1. If the server chooses ECJPAKE for authentication, it needs to select the ECJPAKE class cipher_suites, fill in its own ECJPAKE Round1 data, and send a HelloRetryRequest to request the client to re-authenticate.

[0470] In some embodiments, the message payload of the handshake greeting message or the handshake response message includes an ecjpake_key_kp_pair_list field, the value of which is NULL, and the NULL value is used to determine whether the second end supports the target cipher suite.

[0471] In some embodiments, the format definition is consistent with Elliptic Curve J-PAKE Cipher for TransportLayer (TLS) Section 7.2.2. 17 The definitions are the same. It corresponds to the "ECJPAKEKeyKPPairList" extension in ClientHello / ServerHello. The identity field has been removed, and the predefined "Client" / "Server" fields in the mbedTLS implementation are used instead.

[0472] Figure 14 In the code snippet, ecjpake_key_kp_params includes:

[0473]

[0474] The format definition is related to Elliptic Curve J-PAKE Cipher for Transport Layer (TLS) Section 7.3. 18 The definitions are the same. They correspond to "ServerECJPAKEParams" or "ClientECJPAKEParams" in ServerKeyExchange / ClientKeyExchange.

[0475] In some embodiments, “ecjpake_key_kp_params” is used to indicate the public key in the ECJPAKE protocol, such as the fifth public key, the sixth public key, etc.

[0476] Figure 14 In this context, TrainscriptHash is a hash context that needs to be maintained during the handshake process to ensure the integrity of the handshake data. Each time the client and server send or receive a message, they need to write the message content into the hash context. The client initializes TrainscriptHash upon receiving a ServerHello or HelloRetryRequest. The server initializes TrainscriptHash upon receiving the first ClientHello packet.

[0477] In some embodiments, the TranscriptHash constructor includes:

[0478]

[0479] HelloRetryRequest is generally not needed, so the entire interaction process will omit HelloRetryRequest and the second ClientHello.

[0480] At this point, the TranscriptHash consists of:

[0481]

[0482] In some embodiments, the message sequence number code includes:

[0483]

[0484] The message sequence number consists of two parts: epoch and seq, totaling 64 bits. The client and server process them separately. The epoch is the key algebra. When the connection is first established, the epoch is 0. Including epoch 0, the seq increments by 1 for each message sent and received.

[0485] Figure 18 A schematic diagram of an optional structure of the client provided in an embodiment of this application is shown, and will be described in terms of each part.

[0486] In some embodiments, the client 1100 includes: a first sending unit 1101, a first acquiring unit 1102, and a first determining unit 1103.

[0487] The first sending unit 1101 is used to send a first client greeting message, the first client greeting message including first information, the first information being used to indicate a first key negotiation mode that the client can support;

[0488] The first acquisition unit 1102 is used to acquire a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0489] The first determining unit 1103, if the first key negotiation mode includes the second key negotiation mode, is used to determine the first client shared key based on the second key negotiation mode, and to perform target data transmission according to the first client shared key.

[0490] In some embodiments, if the first key negotiation mode does not include the second key negotiation mode, then the first sending unit 1101 is used to send a second client greeting message, the second information being used to indicate a third key negotiation mode that the client can support;

[0491] The first acquisition unit 1102 is used to acquire the second server feedback message sent by the server based on the second client greeting message, wherein the second feedback information is used to indicate the fourth key negotiation mode determined by the server;

[0492] The first determining unit 1103 is used to determine the second client shared key based on the fourth key negotiation mode, and to perform target data transmission according to the second client shared key;

[0493] The first acquisition unit 1102 is used to acquire a first warning message sent by the server based on the second client greeting message, and disconnect based on the first warning message; or, acquire a third server feedback message sent by the server based on the second client greeting message, send a second warning message based on the third server feedback message and disconnect.

[0494] In some embodiments, the first client greeting message, the second client greeting message, the first server feedback message, and the second server feedback message all include predefined fields, which include at least one of the following: a protocol version field, a cipher suite field, an encryption curve field, a first public key field, and a second public key field; the protocol version field is used to indicate some or all protocol version parameters supported by the client or the server; the cipher suite field is used to indicate some or all cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate some or all encryption curve parameters supported by the client or the server; the first public key field is used to indicate the first public key of the client or the server; and the second public key field is used to indicate the second public key of the client or the server.

[0495] In some embodiments, the first client greeting message includes the protocol version field, the cipher suite field, the first public key field, the encryption curve field, and the second public key field, wherein the first public key field includes the client's first public key; the second public key field is empty; and / or, when the client and the server apply a first key negotiation algorithm, the second client greeting message includes the protocol version field, the cipher suite field, and the first public key field, wherein the first public key field includes the client's second public key; and / or, when the client and the server apply a second key negotiation algorithm, and the client supports the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the second public key field, wherein the second public key field includes the client's third public key; and / or, when the client and the server apply a second key negotiation algorithm, and the client does not support the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the encryption curve field.

[0496] In some embodiments, the first key negotiation algorithm is the ECDH algorithm, and the second key negotiation algorithm is the ECJPAKE algorithm.

[0497] In some embodiments, if the first key negotiation mode includes the second key negotiation mode, it includes: the protocol version parameter of the protocol version field of the first client greeting message includes the protocol version parameter of the protocol version field of the first server feedback message; the cipher suite parameter of the cipher suite field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; the encryption curve parameter of the encryption curve field of the first client greeting message includes the cipher suite parameter of the cipher suite field of the first server feedback message; and / or, if the first key negotiation mode does not include the second key negotiation mode, it includes: the protocol version parameter of the protocol version field of the first client greeting message does not include the protocol version parameter of the protocol version field of the first server feedback message; or, the cipher suite parameter of the cipher suite field of the first client greeting message does not include the cipher suite parameter of the cipher suite field of the first server feedback message; or, the encryption curve parameter of the encryption curve field of the first client greeting message does not include the cipher suite parameter of the cipher suite field of the first server feedback message.

[0498] In some embodiments, if the first client shared key or the second client shared key has been used a preset number of times or for a preset time, the step of sending the first client greeting message is re-executed.

[0499] Figure 19 A schematic diagram of another optional structure of the data transmission apparatus provided in the embodiments of this application is shown, and will be described in terms of each part.

[0500] In some embodiments, the server 1200 includes a second receiving unit 1201 and a second determining unit 1202.

[0501] The second receiving unit 1201 is used to receive a first client greeting message sent by the client, wherein the first client greeting message is used to indicate a first key negotiation mode that the client can support;

[0502] The second determining unit 1202 is configured to determine the second key negotiation mode selected by the server according to the first key negotiation mode, and send it to the client through the first server feedback message; or, if the first key negotiation mode includes the second key negotiation mode, it is configured to determine the first server shared key based on the second key negotiation mode, and perform target data transmission according to the first server shared key.

[0503] In some embodiments, if the first key negotiation mode does not include the second key negotiation mode, the second receiving unit 1201 is used to receive a second client greeting message sent by the client, the second client greeting message being used to indicate a third key negotiation mode that the client can support;

[0504] The second receiving unit 1201 is used to send a second server feedback message based on the second client greeting message. The second server feedback message is used to indicate the fourth key negotiation mode determined by the server.

[0505] The second determining unit 1202 is used to determine the second server shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client shared key; or, based on the third server feedback message sent by the second client greeting message and disconnect the connection.

[0506] In some embodiments, the first client greeting message, the second client greeting message, the first server feedback message, and the second server feedback message all include predefined fields, which include at least one of the following: a protocol version field, a cipher suite field, an encryption curve field, a first public key field, and a second public key field; the protocol version field is used to indicate some or all protocol version parameters supported by the client or the server; the cipher suite field is used to indicate some or all cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate some or all encryption curve parameters supported by the client or the server; the first public key field is used to indicate the first public key of the client or the server; and the second public key field is used to indicate the second public key of the client or the server.

[0507] In some embodiments, the client and the server may apply a first key negotiation algorithm and / or a second key negotiation algorithm; the first server feedback message includes a request to resend the greeting message or a server greeting message.

[0508] In some embodiments, the request to resend the greeting message is any one of a first request to resend the greeting message, a second request to resend the greeting message, a third request to resend the greeting message, and a fourth request to resend the greeting message; the server greeting message is any one of a first server greeting message and a second server greeting message; wherein, the first request to resend the greeting message is sent when the server applies the first key agreement algorithm but does not support the first key agreement mode; and / or, the second request to resend the greeting message is sent when the server applies the second key agreement algorithm and supports the first key agreement mode; and / or, the third request to resend the greeting message is sent when the server applies the second key agreement algorithm but does not support the first key agreement mode; and / or, the fourth request to resend the greeting message is sent when the server applies the first key agreement algorithm and supports the first key agreement mode, but does not support the first public key; the first server greeting message is sent when the server applies the second key agreement algorithm and supports the first key agreement mode; and / or, the second server greeting message is sent when the server applies the first key agreement algorithm and supports the first key agreement mode.

[0509] In some embodiments, the first key negotiation algorithm is the ECDH algorithm, and the second key negotiation algorithm is the ECJPAKE algorithm.

[0510] This application provides an embodiment in which data is transmitted after secure authentication between the client and the server. For example, in Bluetooth point-to-point transmission, a shared key is first generated through secure authentication before the transmission of application data (i.e., the target data described below). Generally, the client and the server must first determine a key negotiation mode that both can support, such as supporting the same protocol version, the same cipher suite, and the same encryption curve. The message transmitted between the client and the server includes predefined fields, which include at least one of the following: a protocol version field, a cipher suite field, an encryption curve field, a first public key field, and a second public key field. The first public key field and the second public key field are used to store public keys corresponding to different key negotiation algorithms. For example, the first public key field stores the public key using the ECDH algorithm, and the second public key field stores the public key using the ECJPAKE algorithm. Therefore, the second public key field may include at least one of the ecjpake_key_kp_pair_list field and the ecjpake_key_kp_params field. That is, the corresponding second public key may include the three public keys corresponding to the ECJPAKE algorithm.

[0511] Understandably, a data transmission method, applied to both a client and a server, includes:

[0512] Step C1 sends a first client greeting message (e.g., Clienthello), which indicates the first key negotiation mode that the client can support;

[0513] Step S1 receives a first client greeting message sent by the client, the first client greeting message being used to indicate a first key negotiation mode that the client can support;

[0514] Understandably, the first key negotiation mode may include some or all key negotiation modes that the client can support. That is, the various fields of the first client greeting message carry some or all of the parameters that the client can support. For example, the first client greeting message can be understood as the first client greeting message sent in this round of negotiation (e.g., Clienthello). For example, the first client greeting message includes the protocol version field, the cipher suite field, the first public key field, the encryption curve field, and the second public key field, wherein the first public key field includes the client's first public key; the second public key field is empty; in one case, the second public key field may also be omitted.

[0515] The first client greeting message uses the above fields. Carrying the client's first public key in the first public key field can probe the key negotiation mode applicable to the server, while saving the negotiation process. For example, if the server supports the ECDH algorithm, the first public key can be obtained directly, improving the negotiation speed.

[0516] Step S2 determines the second key negotiation mode selected by the server based on the first key negotiation mode, and sends it to the client through the first server feedback message. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0517] Understandably, the request to resend the greeting message can be any one of the following: a first request to resend the greeting message, a second request to resend the greeting message, a third request to resend the greeting message, or a fourth request to resend the greeting message. The server-side greeting message can be any one of the following: a first server-side greeting message or a second server-side greeting message.

[0518] The first request to retransmit the greeting message is sent when the server applies the first key negotiation algorithm but does not support the first key negotiation mode; and / or,

[0519] The second request to resend the greeting message is sent when the server applies the second key negotiation algorithm and supports the first key negotiation mode; and / or,

[0520] The third request to resend the greeting message is used when the server applies the second key negotiation algorithm and does not support the first key negotiation mode; and / or,

[0521] The fourth request to resend the greeting message is used when the service applies the first key negotiation algorithm and supports the first key negotiation mode, but does not support the first public key; and / or,

[0522] The first server greeting message is sent when the server applies the first key negotiation algorithm and supports the first key negotiation mode and the first public key.

[0523] Understandably, the first request to resend the greeting message includes: a first public key field, where the first public key field is empty;

[0524] Alternatively, the first request to resend the greeting message includes: a first public key field and a second public key field, both of which are empty;

[0525] The second request to resend the greeting message includes: a second public key field, wherein the second public key field is the second public key of the server;

[0526] Alternatively, the second request to resend the greeting message includes: a first public key field and a second public key field, wherein the first public key field is empty and the second public key field is the second public key of the server;

[0527] The third request to resend the greeting message includes: a second public key field, wherein the second public key field is empty;

[0528] Alternatively, the third request to resend the greeting message includes: a first public key field and a second public key field, both of which are empty;

[0529] The fourth request to resend the greeting message includes: a first public key field, wherein the first public key field is the first public key of the server;

[0530] Alternatively, the fourth request to resend the greeting message includes: a first public key field and a second public key field, wherein the first public key field is the first public key of the server, and the second public key field is empty;

[0531] The first server greeting message includes: a first public key field, wherein the first public key field is the first public key of the server;

[0532] Alternatively, the first server greeting message may include: a first public key field and a second public key field, wherein the first public key field is the server's first public key, and the second public key field is empty.

[0533] It should be noted that the request to resend the greeting message includes a field for storing the server's public key, and has a first public key field and a second public key field applicable to different key negotiation algorithms. This not only ensures compatibility with different key negotiation algorithms, but also saves negotiation steps and improves negotiation speed.

[0534] Understandably, after receiving the first server feedback message from the client, the server decodes the parameters and compares them with its supported parameters. It then determines a parameter supported by both parties from each field, thus identifying the second key exchange mode that both parties can support. If the server uses the ECDH algorithm, it sends the first server feedback message (e.g., serverhello). At this point, the server uses the first public key field (e.g., key) to... The server sends its public key via the `share` field. If the server uses the ECJPAKE algorithm, it sends a pair of server public keys via the second public key field (e.g., the `ecjpake_key_kp_pair_list` field) in the first server feedback message (e.g., `HelloRetryRequest`). If a mutually supported key exchange mode cannot be found, the server can only choose a second key exchange mode that it supports and send it via the first server feedback message (e.g., `ecjpake_key_kp_pair_list`, applicable to ECDH and ECJPAKE). In this case, since the key exchange mode has not been determined, the corresponding server public key does not need to be carried. In a special case, when using the ECDH algorithm, although a key exchange mode supported by both the client and server is determined in the first instance, the server does not support the first public key in the first `Clienthello` message. Therefore, the server can send `HelloRetryRequest` instead of `serverhello`, and can send the server public key via the `keyshare` field.

[0535] Step C2 obtains the first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0536] Understandably, the second key negotiation mode can be a mode supported by both parties, selected by the server from the first key negotiation mode sent by the client. Once a mutually supported key negotiation mode is selected, the transmission of public keys can begin. For example, when the client and server use the ECJPAKE algorithm, the server sends its pair of public keys to the client (possibly via the ecjpake_key_kp_pair_list field in HelloRetryRequest or serverhello). Upon receiving this, the client sends its pair of public keys and another public key through the second public key field in clienthello (e.g., the ecjpake_key_kp_pair_list field and the ecjpake_key_kp_params field). Upon receiving this, the server sends its other public key through the second public key field in the server greeting message (e.g., the ecjpake_key_kp_params field in serverhello).

[0537] Step C3 determines the shared key of the client and uses the shared key of the client to transmit the target data.

[0538] For example, if the first key negotiation mode includes the second key negotiation mode, the first client shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first client shared key;

[0539] If the first key negotiation mode does not include the second key negotiation mode, then a second client greeting message is sent, the second information being used to indicate the third key negotiation mode that the client can support;

[0540] Obtain the second server feedback message sent by the server based on the second client greeting message, the second feedback information being used to indicate the fourth key negotiation mode determined by the server; determine the second client shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client shared key; or...

[0541] Obtain the first warning message sent by the server based on the greeting message from the second client, and disconnect the connection based on the first warning message; or,

[0542] Obtain the third server feedback message sent by the server based on the second client greeting message, send a second warning message based on the third server feedback message and disconnect.

[0543] Step S3 determines the shared key of the server and uses the shared key of the server to transmit the target data.

[0544] For example, if the first key negotiation mode includes the second key negotiation mode, the first server shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first server shared key;

[0545] If the first key negotiation mode does not include the second key negotiation mode, the client sends a second client greeting message, which is used to indicate the third key negotiation mode that the client can support;

[0546] A second server feedback message is sent based on the second client greeting message. The second server feedback message is used to indicate the fourth key negotiation mode determined by the server.

[0547] The second server-side shared key is determined based on the fourth key negotiation mode, and the target data is transmitted according to the second client-side shared key; or...

[0548] Based on the greeting message from the second client, a feedback message is sent to the third server and the connection is closed.

[0549] Understandably, when the client and the server apply the first key negotiation algorithm, the second client greeting message includes the protocol version field, the cipher suite field, and the first public key field, wherein the first public key field includes the client's second public key, which is used to determine the client's shared key; and / or,

[0550] When the client and the server use the second key negotiation algorithm, and the client supports the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the second public key field. The second public key field includes the client's third public key, which is used to determine the client's shared key; and / or,

[0551] When the client and the server use the second key negotiation algorithm, and the client does not support the second key negotiation mode, the second client greeting message includes the protocol version field, the cipher suite field, and the encryption curve field.

[0552] The first key negotiation algorithm is the ECDH algorithm, and the second key negotiation algorithm is the ECJPAKE algorithm.

[0553] Understandably, the client generates a shared key based on the ECJPKE algorithm using the three client public keys sent by the server, and the server generates a shared key based on the ECJPKE algorithm using the three server public keys sent by the client; or the server generates a server shared key based on the ECDH algorithm using the first server public key field (such as the key share field) in the message sent by the client, and the client generates a client shared key based on the ECDH algorithm using the first server public key field (such as the key share field) in the message sent by the server.

[0554] In one feasible implementation, the first client greeting message, the second client greeting message, the first server feedback message, and the second server feedback message all include the aforementioned predefined fields. The predefined fields include at least one of the following: protocol version field, cipher suite field, encryption curve field, first public key field, and second public key field.

[0555] The protocol version field is used to indicate some or all of the protocol version parameters supported by the client or the server.

[0556] The cipher suite field is used to indicate some or all of the cipher suite parameters supported by the client or the server.

[0557] The encryption curve field is used to indicate some or all of the encryption curve parameters supported by the client or the server.

[0558] The first public key field is used to indicate the first public key of the client or the server;

[0559] The second public key field is used to indicate the second public key of the client or the server;

[0560] The first public key and the second public key correspond to different key negotiation algorithms.

[0561] It is understood that if the first key negotiation mode includes the second key negotiation mode, it includes:

[0562] The protocol version parameter of the protocol version field of the first client greeting message includes the protocol version parameter of the protocol version field of the first server feedback message;

[0563] The cipher suite parameter of the cipher suite field in the first client greeting message includes the cipher suite parameter of the cipher suite field in the first server feedback message;

[0564] The encryption curve parameter of the encryption curve field of the first client greeting message includes the encryption suite parameter of the encryption suite field of the first server feedback message;

[0565] And / or,

[0566] If the first key negotiation mode does not include the second key negotiation mode, it includes:

[0567] The protocol version parameter of the protocol version field in the first client greeting message does not include the protocol version parameter of the protocol version field in the first server feedback message; or,

[0568] The cipher suite parameter of the cipher suite field in the first client greeting message does not include the cipher suite parameter of the cipher suite field in the first server feedback message; or,

[0569] The encryption curve parameter of the encryption curve field in the first client greeting message does not include the encryption suite parameter of the encryption suite field in the first server feedback message.

[0570] Understandably, if the first client shared key or the second client shared key has been used a preset number of times or for a preset period of time, the step of sending the first client greeting message will be re-executed. This allows the shared key to be automatically updated after a certain number of uses or time, thereby improving security.

[0571] It should be noted that in this embodiment of the application, the server can be configured to send only one request to resend the greeting message (such as HelloRetryRequest). For example, when the ECJPAKE algorithm is applied, the client can send three client public keys in one client greeting message, while the server can send a maximum of two public keys at a time, because the third public key is generated and sent separately only after the PIN code is confirmed, thereby further enhancing the security of the entire transmission process.

[0572] In some embodiments, a client is provided, the client comprising:

[0573] The first sending unit is configured to send a first client greeting message, which indicates a first key negotiation mode that the client can support.

[0574] The first acquisition unit is used to acquire a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message.

[0575] The first determining unit is used to determine the shared key of the client;

[0576] The first transmission unit transmits target data using the shared key of the client.

[0577] The other functions of the above units correspond to the methods section, and will not be elaborated here.

[0578] In some embodiments, a server is provided, the server comprising:

[0579] The second receiving unit is configured to receive a first client greeting message sent by the client, wherein the first client greeting message is used to indicate a first key negotiation mode that the client can support;

[0580] The second determining unit is configured to determine the second key negotiation mode selected by the server based on the first key negotiation mode.

[0581] The second sending unit is used to send a message to the client via the first server feedback message, wherein the first server feedback message includes a request to resend the greeting message or a server greeting message.

[0582] The second transmission unit is used to determine the shared key of the server and to transmit the target data using the shared key of the server.

[0583] A storage medium storing an executable program, characterized in that, when the executable program is executed by a processor, it implements any of the above-described data transmission methods.

[0584] An electronic device includes a memory, a processor, and an executable program stored in the memory and executable by the processor, characterized in that the processor executes the steps of any of the above-described data transmission methods when running the executable program, and the processor may include a data transceiver module.

[0585] It should be noted that this application provides multiple embodiments, in which various descriptions may differ, but may represent the same features or solutions, and can be substituted where there is no conflict.

[0586] Figure 20 A schematic diagram of an optional structure of the data transmission apparatus provided in an embodiment of this application is shown, and will be described in terms of its various parts. In some embodiments, the data transmission apparatus 1400 includes: a negotiation unit 1401 and an application data unit 1402.

[0587] Negotiation unit 1401 is used to negotiate a key with the second end via a handshake message;

[0588] Application data unit 1402 is used to transmit application data to the second end via content messages, wherein the content messages are encrypted and decrypted using the shared key;

[0589] The handshake message and the content message have the same message format, which includes a message sequence number and a message payload. The message sequence number includes a key algebra identifier and a message count identifier, wherein the key algebra identifier is represented by bits less than the first bit, and the message count identifier is represented by bits less than the second bit.

[0590] In some embodiments, the message payload includes actual data and a message type, wherein the message type includes a padding type, an application data type, a warning type, and a handshake type.

[0591] In some embodiments, the data transmission device 1400 further includes: an encryption unit 1403;

[0592] The encryption unit 1403 is used to encrypt the message payload in the content message using the shared key.

[0593] In some embodiments, the data transmission device 1400 further includes: a verification unit 1404;

[0594] The verification unit 1404 is used to verify the handshake message to obtain a verification value during the negotiation of the shared key.

[0595] In some embodiments, the handshake message includes a handshake completion message, indicating the completion of the shared key negotiation process, wherein the handshake completion message carries the verification value.

[0596] In some embodiments, the handshake message includes at least one of the following: a handshake greeting message, a handshake response message, a retransmission request message, an authentication data message, and a handshake completion message.

[0597] In some embodiments, the message payload of the handshake greeting message, handshake response message, and retransmission request message includes at least one or more of the following fields: protocol version field, cipher suite field, shared key field, and encryption curve field.

[0598] In some embodiments, when the first end negotiates a shared key with the second end through the handshake greeting message, the handshake response message, or the retransmission request message, the key algebra identifier is a; when the first end negotiates a shared key with the second end through the authentication data message or the handshake completion message, the key algebra identifier is a+1; when the first end transmits application data with the second end through the content message, the key algebra identifier is a+2 to a+N; where a is an integer and N is an integer greater than or equal to 2.

[0599] In some embodiments, the message payload of the handshake greeting message or the handshake response message includes a public key list field, the value of which is empty (NULL), and the NULL value is used to determine whether the second end supports the target cipher suite.

[0600] In some embodiments, the second end returns the retransmission request message based on the handshake greeting message, wherein the cipher suite field in the retransmission request message is configured as the target cipher suite.

[0601] In some embodiments, the first end is a client and the second end is a server; or, the first end is a server and the second end is a client.

[0602] Figure 21 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. The electronic device 1300 includes at least one processor 1301, a memory 1302, and at least one network interface 1304. The various components in the client or server 1300 are coupled together via a bus system 1305. It is understood that the bus system 1305 is used to implement communication between these components. In addition to a data bus, the bus system 1305 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 15 The general labeled all buses as Bus System 1305.

[0603] In some embodiments, the electronic device may be a hardware structure corresponding to a client or a server.

[0604] It is understood that memory 1302 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM). The memory 1302 described in this application embodiment is intended to include, but is not limited to, these and any other suitable types of memory.

[0605] The memory 1302 in this embodiment is used to store various types of data to support the operation of the client or server 1300. Examples of such data include any computer program, such as application 1322, used for operation on the client or server 1300. A program implementing the method of this embodiment may be included in application 1322.

[0606] The methods disclosed in the embodiments of this application can be applied to processor 1301, or implemented by processor 1301. Processor 1301 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the method can be completed by the integrated logic circuit of the hardware in processor 1301 or by instructions in the form of software. The processor 1301 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 1301 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 1302. Processor 1301 reads the information in memory 1302 and combines its hardware to complete the steps of the aforementioned method.

[0607] In an exemplary embodiment, the client or server 1300 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), FPGAs, general-purpose processors, controllers, MCUs, MPUs, or other electronic components to perform the aforementioned method.

[0608] This application also provides a storage medium for storing computer programs.

[0609] Optionally, the storage medium can be applied to the first client in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0610] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0611] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0612] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0613] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data transmission method applied to a client, the method comprising: Send a first client greeting message, which indicates the first key negotiation mode that the client can support; Obtain a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message. Determine the shared key of the client, and use the shared key of the client to transmit the target data; The step of determining the shared key of the client and performing target data transmission using the shared key of the client includes: If the first key negotiation mode includes the second key negotiation mode, the first client shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first client shared key. The second key negotiation mode is determined by the server from the ECDH network configuration protocol negotiation key and the ECJPAKE network configuration protocol negotiation key based on the client's device performance and security level. When the second key negotiation mode is to negotiate the key using the ECJPAKE network configuration protocol, the first server feedback message is a request to retransmit the feedback message, which includes the server's first public key list; the negotiation of the key using the ECJPAKE network configuration protocol includes: sending a third client greeting message to the server, which includes the client's second public key list and fourth public key; receiving a first server greeting message sent by the server, which includes a fifth public key; and the client determining a first key based on the public key pairs included in the first public key list in the first server feedback message and the fifth public key.

2. The method according to claim 1, characterized in that, The messages transmitted between the client and the server include predefined fields, which include at least one of the following: protocol version field, cipher suite field, encryption curve field, first public key field, and second public key field; wherein the first public key field and the second public key field are used to store the public keys corresponding to different key negotiation algorithms.

3. The method according to claim 1 or 2, characterized in that, The request to resend the greeting message includes any one of the following: a first request to resend the greeting message, a second request to resend the greeting message, a third request to resend the greeting message, and a fourth request to resend the greeting message, wherein: The first request to retransmit the greeting message is sent when the server applies the first key negotiation algorithm but does not support the first key negotiation mode; and / or, The second request to resend the greeting message is sent when the server applies the second key negotiation algorithm and supports the first key negotiation mode; and / or, The third request to resend the greeting message is used when the server applies the second key negotiation algorithm and does not support the first key negotiation mode; and / or, The fourth request to resend the greeting message is sent when the server applies the first key negotiation algorithm and supports the first key negotiation mode, but does not support the first public key.

4. The method according to claim 3, characterized in that, The first request to retransmit the greeting message includes: a first public key field, wherein the first public key field is empty; or, the first request to retransmit the greeting message includes: a first public key field and a second public key field, wherein both the first public key field and the second public key field are empty. The second request to resend the greeting message includes: a second public key field, wherein the second public key field is the second public key of the server; Alternatively, the second request to resend the greeting message includes: a first public key field and a second public key field, wherein the first public key field is empty and the second public key field is the second public key of the server; The third request to resend the greeting message includes: a second public key field, wherein the second public key field is empty; Alternatively, the third request to resend the greeting message includes: a first public key field and a second public key field, both of which are empty; The fourth request to resend the greeting message includes: a first public key field, wherein the first public key field is the first public key of the server; Alternatively, the fourth request to resend the greeting message may include: a first public key field and a second public key field, wherein the first public key field is the first public key of the server, and the second public key field is empty.

5. The method according to claim 1, characterized in that, The step of determining the shared key of the client and performing target data transmission using the shared key of the client further includes: If the first key negotiation mode does not include the second key negotiation mode, then a second client greeting message is sent, which is used to indicate the third key negotiation mode that the client can support; Obtain the second server feedback message sent by the server based on the second client greeting message. The second server feedback message is used to indicate the fourth key negotiation mode determined by the server. Determine the second client shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client shared key; or... Obtain the first warning message sent by the server based on the greeting message from the second client, and disconnect the connection based on the first warning message; or, Obtain the third server feedback message sent by the server based on the second client greeting message, send a second warning message based on the third server feedback message and disconnect.

6. A data transmission method, characterized in that, Applied to the server side, the method includes: Receive a first client greeting message sent by the client, the first client greeting message being used to indicate a first key negotiation mode that the client can support; The second key negotiation mode selected by the server is determined according to the first key negotiation mode, and sent to the client through the first server feedback message. The first server feedback message includes a request to resend the greeting message or a server greeting message. Determine the shared key of the server, and use the shared key of the server to transmit the target data; The step of determining the shared key of the server and transmitting the target data using the shared key of the server includes: If the first key negotiation mode includes the second key negotiation mode, the first server-side shared key is determined based on the second key negotiation mode, and the target data is transmitted according to the first server-side shared key; The second key negotiation mode is determined by the server from the ECDH network configuration protocol negotiation key and the ECJPAKE network configuration protocol negotiation key based on the client's device performance and security level. When the second key negotiation mode is to negotiate the key using the ECJPAKE network configuration protocol, the first server feedback message is a request to retransmit the feedback message, which includes the server's first public key list; the negotiation of the key using the ECJPAKE network configuration protocol includes: receiving a third client greeting message sent by the client, which includes a second public key list and a fourth public key; sending a first server greeting message to the client, which includes a fifth public key; and the server determining a first key based on the public key pairs included in the second public key list and the fourth public key.

7. The method according to claim 6, characterized in that, The messages transmitted between the client and the server include predefined fields, which include at least one of the following: protocol version field, cipher suite field, encryption curve field, first public key field, and second public key field; wherein the first public key field and the second public key field are used to store the public keys corresponding to different key negotiation algorithms.

8. The method according to claim 6 or 7, characterized in that, The request to resend the greeting message includes any one of the following: a first request to resend the greeting message, a second request to resend the greeting message, a third request to resend the greeting message, and a fourth request to resend the greeting message, wherein: The first request to retransmit the greeting message is sent when the server applies the first key negotiation algorithm but does not support the first key negotiation mode; and / or, The second request to resend the greeting message is sent when the server applies the second key negotiation algorithm and supports the first key negotiation mode; and / or, The third request to resend the greeting message is used when the server applies the second key negotiation algorithm and does not support the first key negotiation mode; and / or, The fourth request to resend the greeting message is sent when the server applies the first key negotiation algorithm and supports the first key negotiation mode, but does not support the first public key.

9. The method according to claim 8, characterized in that, The first request to retransmit the greeting message includes: a first public key field, wherein the first public key field is empty; or, the first request to retransmit the greeting message includes: a first public key field and a second public key field, wherein both the first public key field and the second public key field are empty. The second request to resend the greeting message includes: a second public key field, wherein the second public key field is the second public key of the server; Alternatively, the second request to resend the greeting message includes: a first public key field and a second public key field, wherein the first public key field is empty and the second public key field is the second public key of the server; The third request to resend the greeting message includes: a second public key field, wherein the second public key field is empty; Alternatively, the third request to resend the greeting message includes: a first public key field and a second public key field, both of which are empty; The fourth request to resend the greeting message includes: a first public key field, wherein the first public key field is the first public key of the server; Alternatively, the fourth request to resend the greeting message may include: a first public key field and a second public key field, wherein the first public key field is the first public key of the server, and the second public key field is empty.

10. The method according to claim 6, characterized in that, The step of determining the shared key of the server and transmitting the target data using the shared key of the server further includes: If the first key negotiation mode does not include the second key negotiation mode, the client sends a second client greeting message, which indicates the third key negotiation mode that the client can support. A second server feedback message is sent based on the second client greeting message. The second server feedback message is used to indicate the fourth key negotiation mode determined by the server. The second server-side shared key is determined based on the fourth key negotiation mode, and the target data is transmitted according to the second server-side shared key; or... Based on the greeting message from the second client, a feedback message is sent to the third server and the connection is closed.

11. A client, characterized in that, The client includes: The first sending unit is configured to send a first client greeting message, which indicates a first key negotiation mode that the client can support. The first acquisition unit is used to acquire a first server feedback message sent by the server based on the first client greeting message. The first server feedback message is used to indicate the second key negotiation mode determined by the server. The first server feedback message includes a request to resend the greeting message or a server greeting message. The first determining unit is used to determine the shared key of the client; The first transmission unit transmits target data using the shared key of the client; If the first key negotiation mode includes the second key negotiation mode, the first determining unit is used to determine a first client shared key based on the second key negotiation mode, and the first transmission unit is used to perform target data transmission according to the first client shared key; wherein, the second key negotiation mode is determined by the server from the ECDH network configuration protocol negotiation key and the ECJPAKE network configuration protocol negotiation key based on the client's device performance and security level; when the second key negotiation mode uses the ECJPAKE network configuration protocol negotiation key, the first server feedback message is a request to retransmit feedback message, the request to retransmit feedback message includes the server's first public key list; using the ECJPAKE network configuration protocol negotiation key includes: sending a third client greeting message to the server, the third client greeting message including the client's second public key list and fourth public key; receiving a first server greeting message sent by the server, the first server greeting message including a fifth public key; the client determines a first key based on the public key pairs included in the first public key list in the first server feedback message and the fifth public key.

12. A server, characterized in that, The server includes: The second receiving unit is configured to receive a first client greeting message sent by the client, wherein the first client greeting message is used to indicate a first key negotiation mode that the client can support; The second determining unit is configured to determine the second key negotiation mode selected by the server based on the first key negotiation mode. The second sending unit is used to send a first server feedback message to the client, the first server feedback message including a request to resend the greeting message or a server greeting message; The second determining unit is further configured to determine the shared key of the server; The second transmission unit is used to transmit target data using the shared key of the server. The second determining unit is configured to determine a first server-side shared key based on the second key negotiation mode if the first key negotiation mode includes the second key negotiation mode; the second transmission unit is configured to perform target data transmission according to the first server-side shared key; wherein, the second key negotiation mode is determined by the server from the ECDH network configuration protocol negotiation key and the ECJPAKE network configuration protocol negotiation key based on the client's device performance and security level; when the second key negotiation mode uses the ECJPAKE network configuration protocol negotiation key, the first server-side feedback message is a request to retransmit the feedback message, the request to retransmit the feedback message includes the server's first public key list; the use of the ECJPAKE network configuration protocol negotiation key includes: receiving a third client greeting message sent by the client, the third client greeting message including a second public key list and a fourth public key; sending a first server-side greeting message to the client, the first server-side greeting message including a fifth public key; the server determining a first key based on the public key pairs included in the second public key list and the fourth public key.

13. A storage medium storing an executable program, characterized in that, When the executable program is executed by the processor, it implements the data transmission method according to any one of claims 1 to 10.

14. An electronic device comprising a memory, a processor, and an executable program stored in the memory and executable by the processor, characterized in that, When the processor runs the executable program, it performs the steps of the data transmission method as described in any one of claims 1 to 10.

Images