WO2022042244A1 - 一种数据传输方法、客户端、服务端及存储介质 - Google Patents

一种数据传输方法、客户端、服务端及存储介质 Download PDF

Info

Publication number
WO2022042244A1
WO2022042244A1 PCT/CN2021/110617 CN2021110617W WO2022042244A1 WO 2022042244 A1 WO2022042244 A1 WO 2022042244A1 CN 2021110617 W CN2021110617 W CN 2021110617W WO 2022042244 A1 WO2022042244 A1 WO 2022042244A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
server
key
message
field
Prior art date
Application number
PCT/CN2021/110617
Other languages
English (en)
French (fr)
Inventor
尹康凯
Original Assignee
Oppo广东移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oppo广东移动通信有限公司 filed Critical Oppo广东移动通信有限公司
Priority to EP21860084.9A priority Critical patent/EP4170962A4/en
Publication of WO2022042244A1 publication Critical patent/WO2022042244A1/zh
Priority to US18/090,910 priority patent/US20230171090A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/047—Key management, e.g. using generic bootstrapping architecture [GBA] without using a trusted network node as an anchor
    • H04W12/0471—Key exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present application relates to the technical field of communication security, and in particular, to a data transmission method, a client, a server and a storage medium.
  • the client and the server need to negotiate a shared key interactively, and then transmit data through the shared key. Therefore, how to negotiate the shared key is a technical problem that needs to be solved.
  • the embodiments of the present application provide a data transmission method, a client, a server, and a storage medium, which can flexibly determine a key negotiation mode, and then negotiate a shared key for data transmission.
  • an embodiment of the present application provides a data transmission method, which is applied to a client (Client), including:
  • first client hello message includes first information, where the first information is used to indicate a first key agreement mode that the client can support;
  • the server-side feedback message includes a request to resend a greeting message or a server-side greeting message;
  • the first client shared key is determined based on the second key negotiation mode, and the target data is processed according to the first client shared key. transmission.
  • an embodiment of the present application provides a data transmission method, which is applied to a server, including:
  • the first server shared key is determined based on the second key negotiation mode, and the target data is processed according to the first server shared key. transmission.
  • an embodiment of the present application provides a client, where the client includes:
  • a first sending part configured to send a first client hello message, where the first client hello message includes first information, where the first information is used to indicate a first key agreement mode that the client can support;
  • a first obtaining part configured to obtain a first server feedback message sent by the server based on the first client hello message, where the first feedback information is used to indicate the second key negotiation mode determined by the server,
  • the first server-side feedback message includes a request to resend a greeting message or a server-side greeting message;
  • the first determination part if the first key negotiation mode includes the second key negotiation mode, is configured to determine the first client shared key based on the second key negotiation mode, and according to the first client End-to-end shared secret key for target data transfer.
  • the first sending part is configured to send a second client hello message, and the second information is used for indicating a third key agreement mode that the client can support;
  • the first obtaining part is configured to obtain a second server feedback message sent by the server based on the second customer hello message, where the second feedback information is used to indicate the fourth key determined by the server negotiation mode;
  • the first determining part is configured to determine a second client shared key based on the fourth key negotiation mode, and perform target data transmission according to the second client shared key;
  • the first obtaining part is configured to obtain the first warning message sent by the server based on the second client hello message, and disconnect the connection based on the first warning message;
  • the third server feedback message sent by the second client hello message is sent, and a second warning message is sent based on the third server feedback message and the connection is disconnected.
  • the first client hello message, the second client hello message, the first server feedback message, and the second server feedback message all include predefined fields, and the predefined fields include: a protocol version at least one of fields, encryption suite field, encryption curve field, first public key field and second public key field; the protocol version field is used to indicate part or all supported by the client or the server Protocol version parameter; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate the part supported by the client or the server or all encryption curve parameters; the first public key field is used to indicate the first public key of the client or the server; the second public key field is used to indicate the first public key of the client or the server Two public keys.
  • the first client hello 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 first public key of the client; the second public key field is empty; and/or, when the client and the server apply the first key agreement algorithm , the second client hello message includes the protocol version field, the cipher suite field, and the first public key field, where the first public key field includes the second public key of the client; and/or , when the client and the server apply the second key agreement algorithm, and the client supports the second key agreement mode, the second client hello message includes the protocol version field, the encryption suite field and the second public key field, where the second public key field includes the third public key of the client; and/or, when the client and the server apply the second key When the negotiation algorithm is used, and the client does not support the second key negotiation mode, the second client hello message includes the protocol version field, the encryption suite field, and the encryption curve field.
  • the first key agreement algorithm is an Elliptic-curve Diffie-Hellman (ECDH) algorithm
  • the second key agreement algorithm is a cryptographically authenticated key exchange (Password Authenticated Key Exchange by Juggling Over Elliptic Curve, ECJPAKE) algorithm.
  • the if the first key agreement mode includes the second key agreement mode including: the protocol version parameter of the protocol version field of the first client hello message includes the 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 hello message includes the cipher suite field of the first server feedback message cipher suite parameter; the ciphering curve parameter of the ciphering curve field of the first client hello message includes the ciphering suite parameter of the ciphering suite field of the first server feedback message; and/or, the if The first key agreement mode does not include the second key agreement mode, including: the protocol version parameter of the protocol version field of the first client hello message does not include the first server feedback message.
  • the protocol version parameter of the protocol version field or, the cipher suite parameter of the cipher suite field of the first client hello 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 hello message does not include the encryption suite parameter of the encryption suite field of the first server feedback message.
  • the present application provides a server, the server comprising:
  • the second receiving part is configured to receive a first client hello message sent by the client, where the first client hello message is used to indicate a first key agreement mode that the client can support;
  • the second determining part 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, and is configured to determine a first server shared key based on the second key negotiation mode, and perform a target based on the first server shared key. data transmission.
  • the second receiving part is configured to receive a second client hello message sent by the client, the The second client hello message is used to indicate the third key agreement mode that the client can support;
  • a second receiving part configured to send a second server feedback message based on the second client hello message, where the second server feedback message is used to indicate the fourth key agreement mode determined by the server;
  • the second determining part is configured to determine a second server-side shared key based on the fourth key agreement mode, and perform target data transmission according to the second client-side shared key; or, based on the second client-side shared key
  • the third server feedback message sent by the client hello message and disconnect.
  • the first client hello message, the second client hello message, the first server feedback message, and the second server feedback message all include predefined fields, and the predefined fields include: a protocol version at least one of fields, encryption suite field, encryption curve field, first public key field and second public key field; the protocol version field is used to indicate part or all supported by the client or the server Protocol version parameter; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate the part supported by the client or the server or all encryption curve parameters; the first public key field is used to indicate the first public key of the client or the server; the second public key field is used to indicate the first public key of the client or the server Two public keys.
  • the client and the server can apply the first key agreement algorithm and/or the second key agreement algorithm; the first server feedback message includes a request to resend the hello message or the server greeting message.
  • the request to resend the hello message is any one of the first request to resend the hello message, the second request to resend the hello message, the third request to resend the hello message, and the fourth request to resend the hello message
  • the server hello message is any one of a first server hello message and a second server hello message, wherein the first request to resend the hello message is used to apply the first password on the server.
  • the second request to resend the hello message is used for applying the second key agreement algorithm at the server and Sent when the first key agreement mode is supported; and/or, the third request to resend the hello message is used to apply the second key agreement algorithm on the server and does not support the first key agreement Sent in the case of a key agreement mode; and/or, the fourth request retransmission hello message is used when the service applies the first key agreement algorithm and supports the first key agreement mode, but does not Sent when the first public key is supported; the first server hello message is used when the server applies the second key agreement algorithm and supports the first key agreement mode and/or, the second server hello message is used for sending when the server applies the first key agreement algorithm and supports the first key agreement mode.
  • the first key agreement algorithm is an ECDH algorithm
  • the second key agreement algorithm is an ECJPAKE algorithm
  • the data transmission method, client, server, and storage medium provided in the embodiments of the present application send a first client hello message, where the first client hello message includes first information, and the first information is used to indicate the The first key negotiation mode that the client can support; obtain the first server feedback message sent by the server based on the first client hello message, and the first feedback information is used to indicate the second determined by the server.
  • the first server feedback message includes a request to resend a hello message or a server hello message; if the first key agreement mode includes the second key agreement mode, based on the second key agreement
  • the key agreement mode determines the shared key of the first client, and performs target data transmission according to the shared key of the first client. In this way, the key negotiation mode can be flexibly determined, the shared key negotiation can be performed, and the target data can be transmitted through the negotiated shared key.
  • Fig. 1 is the schematic flow chart of the distribution network protocol based on ECDH in the related art
  • Fig. 2 is the schematic flow chart of the distribution network protocol based on ECJPAKE in the related art
  • FIG. 3 is a schematic flowchart of an optional client side of the data transmission method provided by the embodiment of the present application.
  • FIG. 4 is a schematic schematic diagram of an optional process for negotiating a shared key using a distribution network protocol of ECDH according to an embodiment of the present application
  • FIG. 5 is a schematic diagram of a detailed processing flow for negotiating a shared key using a distribution network protocol of ECDH according to an embodiment of the present application
  • FIG. 6 is a schematic schematic diagram of an optional process for negotiating a shared key using the distribution network protocol of ECJPAKE according to an embodiment of the present application
  • FIG. 7 is a schematic diagram of a detailed processing flow for negotiating a shared key using a distribution network protocol using ECJPAKE provided by an embodiment of the present application;
  • FIG. 8 is a schematic flowchart of an optional server side of the data transmission method provided by the embodiment of the present application.
  • FIG. 9 is an optional schematic flowchart of a data transmission method provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a detailed processing flow of the data transmission method provided by the embodiment of the present application.
  • FIG. 11 is another optional schematic flowchart of the data transmission method provided by the embodiment of the present application.
  • FIG. 12 is a schematic diagram of another detailed processing flow of the data transmission method provided by the embodiment of the present application.
  • FIG. 13 is a schematic schematic diagram of yet another optional flow of the data transmission method provided by the embodiment of the present application.
  • FIG. 14 is a schematic diagram of still another detailed processing flow of the data transmission method provided by the embodiment of the present application.
  • FIG. 15 is another optional schematic flowchart of the data transmission method provided by the embodiment of the present application.
  • FIG. 16 is another optional schematic flowchart of the data transmission method provided by the embodiment of the present application.
  • 17 is a schematic structural diagram of an optional structure of the content of a message transmitted by a client and a server according to an embodiment of the present application;
  • FIG. 18 is a schematic diagram of an optional structure of a client according to an embodiment of the present application.
  • FIG. 19 is a schematic diagram of an optional structure of a server provided by an embodiment of the present application.
  • FIG. 20 is a schematic diagram of an optional structure of a data transmission apparatus provided by an embodiment of the present application.
  • FIG. 21 is a schematic structural diagram of a hardware composition of an electronic device according to an embodiment of the present application.
  • IoT Internet of Things
  • BLE Bluetooth Low Energy
  • FIG. 1 shows a schematic flowchart of an ECDH-based network distribution protocol in the related art.
  • FIG. 2 shows a schematic flowchart of a distribution network protocol based on ECJPAKE in the related art.
  • a connection is established between the first client and the server, and the public key is exchanged in the handshake phase, and a shared key is generated. shared key for symmetric encryption).
  • the network distribution protocol based on ECDH or the network distribution protocol based on ECJPAKE is not flexible and comprehensive enough to support devices.
  • the current standard process interaction process has a high amount of data, which is a heavy burden for BLE devices.
  • the applicant also found that for a device with a Personal Identification Number (PIN) code, the PIN code itself is not sufficiently protected and is prone to leakage. In addition, once the key is generated, it will be used throughout the life cycle, and there is no update mechanism. .
  • PIN Personal Identification Number
  • the present application proposes a data transmission method, which can solve the technical difficulties and shortcomings that cannot be solved in the prior art solutions.
  • FIG. 3 shows an optional schematic flowchart of the client side of the data transmission method provided by the embodiment of the present application, which will be described according to each step.
  • Step S101 sending a first client hello message.
  • the client sends a first client hello message to the server, where the first client hello message is used to indicate a first key agreement mode that the client can support.
  • the client sends a first client hello message to the server, where the first client hello message includes first information, and the first information is used to indicate the first client hello message that the client can support.
  • a key agreement mode is used to indicate the first client hello message that the client can support.
  • the first key negotiation mode includes negotiating a key using a distribution protocol of ECDH and/or negotiating a key of a distribution protocol using ECJPAKE.
  • the first information includes a first set of cipher suites; the first set of cipher suites includes a set of at least one cipher suite capable of being supported by the client.
  • the first client hello message may further include: an cipher suite field; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client.
  • 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.
  • the first client hello message may further include: an encryption curve field; the encryption curve field is used to indicate part or all of the encryption curve parameters supported by the client.
  • the first client hello message further includes: a first public key, where the first public key includes: if the client can support the ECDH network configuration protocol, the first public key
  • the public key determined by any cipher suite in the set of cipher suites and/or any one of the encryption curves in the first set of encryption curves. Different cipher suites and/or encryption curves determine different public keys.
  • the first client hello message further includes: a first protocol identifier set, where the first protocol identifier set includes a protocol identifier corresponding to at least one protocol version, and the protocol version and the protocol identifier are one In one correspondence, the first set of protocol identifiers indicates a set of protocol versions supported by the client.
  • the first client hello message may further include: a protocol version field; the protocol version field is used to indicate part or all of the protocol version parameters supported by the client.
  • the first client hello message further includes: a first public key list, and the first public key list of the first client hello message is NULL.
  • Step S102 Obtain first feedback information sent by the server based on the first client hello message.
  • the client in the embodiments of this application refers to a device (or APP) that initiates a connection actively, and may also refer to an active connection terminal in this application; ) to demonstrate its control.
  • the server refers to a passively connected device, and may also refer to a passive connection in this application; when connecting, the server authenticates the identity of the client and verifies that the client has control.
  • the client and server can be servers, terminal equipment, "TV", “speaker” and other Internet of Things (Internet of Things, IoT) devices, etc.
  • the connection between the client and the server can be established through a wired network. It can also be a connection established through a wireless network, or a connection established through a mobile network.
  • the client may be an active connection terminal, the client may be a Bluetooth low energy device, or an electronic device such as a handheld terminal, a wearable terminal, a personal notebook, a tablet computer, etc.;
  • the The server can be a passive connection terminal, and the server can be a Bluetooth low energy device, such as a blood pressure measuring device, a temperature measuring device, and a blood sugar monitoring device applied in the field of monitoring and nursing; or a fitness equipment sensor applied in the field of sports and fitness , heart rate measurement device, positioning device, speed measurement device, weight measurement device; or switch devices, lighting devices, smart door locks, electric curtains, sweeping robots, etc. in the field of smart homes.
  • the client obtains a first server feedback message sent by the server based on the first client hello message; the first server feedback message includes first feedback information, and the first feedback The information is used to indicate the second key agreement mode determined by the server.
  • the first feedback information includes at least one of the following: a first encryption suite, a first encryption curve, a first protocol identifier and the second public key; the first cipher suite set includes the first cipher suite, and the first cipher suite includes any one of at least one cipher suite supported by the server; the first encryption curve set including the first encryption curve, and the first encryption curve includes any encryption curve in at least one encryption curve supported by the server; the first protocol identifier set includes the first protocol identifier, the first The protocol identifier includes
  • the second public key is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identification.
  • at least one cipher suite supported by the server is included in the first cipher suite set included in the first client hello message, and the first cipher suite included in the first client hello message includes at least one cipher suite supported by the server.
  • An encryption curve set includes at least one encryption curve supported by the server or a first protocol identifier set included in the first client hello message includes a protocol identifier corresponding to at least one protocol version supported by the server, and the When the server determines that the second key negotiation mode is to use the ECJPAKE distribution protocol to negotiate the key, the first feedback information includes: the first encryption suite, the first encryption curve, the first protocol identifier, and the first public key.
  • the first cipher suite set includes the first cipher suite, and the first cipher suite includes any one of at least one cipher suite supported by the server;
  • the first encryption curve set includes all the first encryption curve, the first encryption curve includes any encryption curve in at least one encryption curve supported by the server;
  • the first protocol identification set includes the first protocol identification, the first protocol identification The protocol identifier corresponding to any one of the at least one protocol version supported by the server is included.
  • the second public key is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identification.
  • the first public key list includes a public key pair sent by the server to the client and used to determine the shared key of the first client.
  • the first cipher suite set included in the first client hello message does not include at least one cipher suite supported by the server
  • the first client The first encryption curve set included in the hello message does not include at least one encryption curve supported by the server or the first protocol identifier set included in the first client hello message does not include at least one protocol supported by the server
  • the first feedback information includes: the second encryption suite, the second encryption curve, and the second protocol identifier.
  • the first encryption suite set does not include the second encryption suite, and the second encryption suite includes any one of at least one encryption suite supported by the server; the first encryption curve set does not include the a second encryption curve, where the second encryption curve includes any one of at least one encryption curve supported by the server; the first protocol identification set part includes the second protocol identification, and the second protocol identification
  • the protocol identifier corresponding to any one of the at least one protocol version supported by the server is included.
  • the first encryption suite set does not include encryption suites supported by the server
  • the first encryption curve set does not include curves supported by the server
  • the first protocol identifier set does not include encryption suites supported by the server.
  • the first feedback information includes the second encryption suite, the second encryption curve and the second protocol determined by the server according to the performance of the server itself logo.
  • the first encryption suite set includes encryption suites supported by the server, the first encryption curve set does not include encryption curves supported by the server, and the first protocol identifier set does not include
  • the first feedback information includes the second encryption curve and the second protocol identifier determined by the server according to the performance of the server itself, and the service The first cipher suite determined by the client based on the first client hello message.
  • Step S103 if the first key negotiation mode includes the second key negotiation mode, determine a first client shared key based on the second key negotiation mode, and determine the first client shared key according to the first client shared key Carry out the target data transfer.
  • the first client shared key is determined based on the second key agreement mode, according to the second key agreement mode.
  • the first key agreement mode includes the second key agreement mode including: the first encryption suite set includes the first encryption suite, the first encryption curve set includes all In the case where the first encryption curve and the first protocol identifier set include the first protocol identifier, the first key negotiation mode includes the first encryption suite carried in the first server feedback message, The second key agreement mode corresponding to the first encryption curve and the first protocol identifier.
  • the first key agreement mode includes the second key agreement mode, and may further include: the protocol version parameter of the protocol version field of the first client hello message includes the 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 hello message includes the cipher suite field of the first server feedback message The encryption curve parameter of the encryption curve field of the first client hello message includes the encryption suite parameter of the encryption suite field of the first server feedback message.
  • determining the shared key of the first client based on the second key agreement mode includes scenario 1 and scenario 2, which will be described in detail in subsequent embodiments.
  • the scenario 1 includes: the second key negotiation mode is to negotiate a key using a distribution protocol of ECDH; further, the determining that the first client share is based on the second key negotiation mode
  • the key includes: use the ECDH distribution network protocol to negotiate the key.
  • the scenario 2 includes a configuration protocol in which the second key agreement mode is ECJPAKE. Further, the determining the shared key of the first client based on the second key negotiation mode includes: negotiating the key by using a distribution network protocol of ECJPAKE.
  • Step S104 if the first key agreement mode does not include the second key agreement mode, send a second client hello message.
  • the first key agreement mode does not include the second key agreement mode, including: the first cipher suite set included in the first client hello message does not include the first service The second encryption suite carried in the terminal feedback message; or, the first encryption curve set included in the first client hello message does not include the second encryption curve carried in the first feedback information; or, the first encryption curve set The first protocol identifier set included in the client hello message does not include the second protocol identifier carried in the first feedback information. That is, the first key agreement mode does not include the second key agreement mode corresponding to the encryption suite, encryption curve and protocol identifier carried in the first server feedback message.
  • the sending, by the client, the second client hello message includes: the client sending a second client hello message to the server, where the second client hello message includes second information, and the first The second information is used to indicate the third key negotiation mode that the client can support.
  • 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 encryption suite included in the first encryption suite set is completely different from at least one encryption suite included in the second encryption suite set; at least one encryption curve included in the first encryption curve set is the same as the At least one encryption curve included in the second set of encryption curves is completely different.
  • the second client hello message further includes: a fourth public key, where the fourth public key includes: if the client can support the ECDH network configuration protocol, the second public key The public key determined by any cipher suite in the set of cipher suites and/or any one of the encryption curves in the second set of encryption curves.
  • the second client hello message further includes: a second protocol identifier set, where the second protocol identifier set includes a protocol identifier corresponding to at least one protocol version, the protocol version and the protocol identifier are one
  • the second set of protocol identifiers indicates a set of protocol versions supported by the client.
  • the second client hello message further includes: a second public key list, and the second public key list of the second client hello message is NULL.
  • step S105 in the case that the server can support the third key agreement mode, step S105 is performed; in the case that the server cannot support the third key agreement mode, step S105 is performed S107.
  • Step S105 Acquire a second server feedback message sent by the server based on the second customer greeting message.
  • the client obtains a second server feedback message sent by the server based on the second client hello message, where the second server feedback message includes second feedback information, and the second
  • the specific steps in which the feedback information is used to indicate the fourth key agreement mode determined by the server is similar to that of step S102, and details are not repeated here.
  • 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.
  • the shared key of the second client is determined based on the fourth key negotiation mode, and the specific steps for transmitting target data according to the shared key of the second client are similar to step S103. Repeat again.
  • Step S107 Acquire a first warning message sent by the server based on the second client hello message, and disconnect the connection based on the first warning message.
  • the client obtains a first warning message sent by the server based on the second client hello message, and disconnects the connection based on the first warning message.
  • the server receives the second client hello message, and determines that the server does not support at least one cipher suite included in the second set of cipher suites; or the server does not support At least one encryption curve included in the second encryption curve set; or if 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 the The client sends a first warning message, where the first warning message is used to instruct to disconnect the connection between the client and the server.
  • the method further includes: step S108, sending a second warning message.
  • the first server feedback message in the first server feedback message received by the client, includes more than 2 encryption curves or more than 2 encryption suites or more than 2 version identifiers
  • the client sends a second warning message to the server, and disconnects the connection with the server; the second warning message is used to instruct to disconnect the connection between the client and the server.
  • the first server feedback message includes more than 2 encryption curves or more than 2 encryption suites or more than 2 version identifiers, it means that the client is maliciously attacked by a third party, or an error occurs on the server, The client sends a second warning message and disconnects from the server.
  • the second server feedback message in the second server feedback message received by the client, includes more than two encryption curves or more than two encryption suites or more than two version identifiers
  • the client sends a second warning message to the server, and disconnects the connection with the server; the second warning message is used to indicate disconnecting the connection between the client and the server .
  • the embodiments of the present application provide a flexible data transmission method.
  • the ECDH network distribution protocol is used for data transmission; for clients with better performance and high security requirements terminal, use ECJPAKE's distribution network protocol for data transmission.
  • the PIN code of the client is combined with the transmission process, which improves the difficulty of cracking the PIN code and improves the security of data transmission.
  • each frame of message transmitted by the client and/or the server participates in the hash value calculation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 4 shows a schematic diagram of an optional process for negotiating a shared key using a distribution network protocol using ECDH provided by an embodiment of the present application
  • FIG. 5 shows the details of the shared key negotiation using a distribution network protocol using ECDH provided by an embodiment of the present application.
  • a schematic diagram of the processing flow will be described with reference to FIG. 4 and FIG. 5 .
  • This embodiment corresponds to scenario 1 in step S103.
  • the client obtains the first server feedback message from the server based on step S102, and determines, based on the first feedback information, that the second key transmission mode is a distribution network using ECDH
  • step S200 is executed; After determining that the first encryption curve of the second public key is the same as determining the encryption curve of the first public key, step S201 is executed.
  • Step S200 the client sends a third client hello message to the server.
  • the third client hello message includes at least one of: a first encryption suite, a first encryption curve, and a first protocol identification.
  • the third client hello 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.
  • the third client hello message may further include: a first digital sequence formed by combining the third public key and the first random sequence.
  • the first random sequence is randomly generated by the client.
  • 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 ), the sequence of numbers may include **####****.
  • the first random sequence may only be known by the client, and is used to increase the complexity of the transmission of the first public key, and to prevent the first digital sequence from being intercepted by a third party, and to obtain the first random sequence based on the first digital sequence.
  • a public key the first random sequence does not participate in the determination of the first key; after receiving the first digital sequence, the server removes the first random sequence in the first digital sequence, and obtains the the third public key, and then determine the first key.
  • the third client hello message is sent to the server through ClientHello information.
  • Step S201 the client determines the first key based on the second public key.
  • 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 in the feedback message of the first server, obtains the second public key, and determines the first password based on the second public key. key.
  • 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 the related art, and details are not repeated here.
  • the first server feedback message is sent to the server through a ServerHello message.
  • Step S202 the server determines the first key based on the first public key or the third public key.
  • the server when determining that the first encryption curve of the second public key is the same as determining the encryption curve of the first public key, the server is based on the first encryption curve in the first client hello message.
  • the public key determines the first key.
  • the server removes the random sequence in the first client hello message, obtains the first public key, and determines the first key based on the first public key.
  • the server in the case where it is determined that the first encryption curve of the second public key is not the same as the encryption curve determined that the first public key is different, the server based on the third encryption curve in the first number sequence
  • the public key determines the first key.
  • the server removes the first random sequence in the first digital sequence, obtains the third public key, and determines the first key based on the third public key.
  • Step S203 the server sends the first verification information to the client.
  • the server sends first verification information to the client, where the first verification information includes a certificate of the server; the first verification information is used by the client to verify the service end identity.
  • the first authentication information is sent to the client through Authenticate information.
  • the first verification information may be an X509 certificate or a server-defined integer.
  • Step S204 the server sends the first verification data to the client.
  • the server sends first verification data to the client, where the first verification data includes a set of hash values of each frame of messages sent and/or received by the client.
  • the first check data hash(M1
  • the server sends the first server feedback message to the client, and the server sends the first verification information to the client, the The first verification data includes: the hash value of the first client hello message, the hash value of the first server feedback message, and the hash value of the first verification information.
  • the first verification data is sent to the client through Finished information.
  • the first verification data may also be determined by: hash(hash(M1
  • the first verification data may be sent after the client and the server exchange public keys, including the hash value of each frame of messages sent and/or received by the first client. Collection; it can also be carried in each message sent by the server to the client.
  • the first verification data carried in each message sent by the server to the client includes: the server, based on the first hash value carried in the most recently received message, Determine the first verification data with the second hash value of the message that the server is about to send to the client.
  • the first check data may be the sum of the first hash value and the second hash value. For example, obtain the first hash value in the first client hello message based on the first client hello message; the server determines the second hash value of the first server feedback message based on the first server feedback message Hash value, in the first feedback information, the hash value set of the first client hello message and the first server feedback message includes the first hash value and the second hash value and the first hash value and the second hash value have the same length.
  • Step S205 the client sends the second verification information to the server.
  • the client sends second verification information to the server, where the second verification information includes a certificate of the client; the second verification information is used by the server to verify the client end identity.
  • the second verification information is sent to the server through Authenticate information.
  • Step S206 the client sends the second verification data to the server.
  • the client sends second verification data to the server, where the second verification data includes a set of hash values of each frame of messages sent and/or received by the server.
  • the second check data hash(M1
  • the client sends the first client greeting message to the server
  • the server sends the first server feedback message to the client
  • the server sends the first verification information to the client
  • the server sends the client
  • the server sends the client
  • the server sends the client
  • the server sends the client
  • the client sends the second verification information to the server
  • the first verification data includes: the hash value of the first client hello message, the first server feedback The hash value of the 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.
  • the second verification data is sent to the server through Finished information.
  • the second verification data can also be obtained by: hash(hash(M1
  • the second verification data may be sent after the client and the server exchange public keys, including the hash value of each frame of messages sent and/or received by the first client. Collection; it can also be carried in each message sent by the client to the server.
  • the second verification data carried in each message sent by the server to the client includes: the client is based on the third hash value carried in the most recently received message, The second check data is determined with the fourth hash value of the message to be sent by the client to the server.
  • the second check data may be the sum of the third hash value and the fourth hash value.
  • the third hash value in the first client hello message is obtained based on the first server feedback message; the fourth hash value of the third client hello message determined by the client based on the third client hello message hash value, in the third client hello message, the second check data includes the sum of the third hash value and the fourth hash value; the first hash value and the The second hash value has the same length.
  • clients and/or servers with poor performance or low security performance requirements can use the ECDH network distribution protocol for data transmission.
  • the client or server can determine the transmission process according to actual needs.
  • each frame of message transmitted by the client and/or the server participates in the hash value operation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 6 shows a schematic diagram of an optional process for negotiating a shared key using the distribution network protocol using ECJPAKE provided by the embodiment of the present application
  • Fig. 7 shows the details of the shared key negotiation using the distribution network protocol using ECJPAKE provided by the embodiment of the present application
  • a schematic diagram of the processing flow will be described with reference to FIG. 6 and FIG. 7 .
  • This embodiment corresponds to scenario 2 in step S103, and the second key negotiation mode is to negotiate a shared key using the distribution network protocol of ECJPAKE.
  • Step S301 the client sends a third client hello message to the server.
  • the client obtains the first feedback information from the server based on step S102, and determines, based on the first feedback information, that the second key transmission mode is the distribution network protocol negotiation using ECJPAKE In the case of a shared key, the client sends a third client hello message to the server.
  • the third client hello message includes at least one of: a first encryption suite, a first encryption curve, and a first protocol identification.
  • the third client hello message may further include: a second public key list, where the second public key list includes a public key pair used for determining the shared key of the first server.
  • the second public key list may also include the PIN code of the client.
  • the third client hello 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 PIN code of the client.
  • the third client hello message may further include: a second digital sequence formed by combining the fourth public key and the second random sequence.
  • the second random sequence is randomly generated by the client.
  • 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 ), the second sequence of numbers may include **####****.
  • the second random sequence may only be known by the server, and is used to increase the complexity of the transmission of the fourth public key and prevent the second digital sequence from being intercepted by a third party, and the second random sequence is obtained based on the second digital sequence.
  • Four public keys the second random sequence does not participate in the determination of the first key; after receiving the second digital sequence, the server removes the second random sequence in the second digital sequence, and obtains the the fourth public key, and then determine the first key.
  • the third client hello message is sent to the server through ClientHello information.
  • the server receives the second public key list and the fourth public key, and determines the first key based on the public key pair included in the second public key list and the fourth public key.
  • Step S302 the server sends a greeting message to the first server of the client.
  • the first server hello message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.
  • the first server hello 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 list may further include the PIN code of the server.
  • the first server hello message may further include: a third digital sequence formed by combining the fifth public key and the third random sequence.
  • the third random sequence is randomly generated by the server.
  • the first server hello message is sent to the client through ServerHello information.
  • the client determines the first key based on the public key pair included in the first public key list in the first server feedback message and the fifth public key.
  • Step S303 the server sends the first verification data to the client.
  • the server sends first verification data to the client, where the first verification data includes a hash value of each frame of messages sent and/or received by the first client collection.
  • the first check data hash(M1
  • the client sends the first client hello message and the third client hello message to the server, and the server sends the first server feedback message and the first server hello message to the client.
  • the first verification data includes: the hash value of the first client hello message, the hash value of the third client hello message, the hash value of the first server feedback message, and the hash value of the first server feedback message.
  • the first verification data is sent to the first client through Finished information.
  • the first verification data may also be obtained by: hash(hash(M1
  • the first verification data may be sent after the client and the server exchange public keys, including the hash value of each frame of messages sent and/or received by the first client. Collection; it can also be carried in each message sent by the server to the client.
  • the first verification data carried in each message sent by the server to the client includes: the server, based on the first hash value carried in the most recently received message, Determine the first verification data with the second hash value of the message that the server is about to send to the client.
  • the first check data may be the sum of the first hash value and the second hash value. For example, obtain the first hash value in the first client hello message based on the first client hello message; the server determines the second hash value of the first server feedback message based on the first server feedback message Hash value, in the first feedback information, the first verification data includes the sum of the first hash value and the second hash value; the first hash value and the second hash value
  • the hash values are the same length.
  • Step S304 the client sends the second verification data to the server.
  • the client sends second verification data to the server, where the second verification data includes a set of hash values of each frame of messages sent and/or received by the server.
  • the second check data hash(M1
  • the client sends the first client greeting message to the server
  • the server sends the first server feedback message to the client
  • the server sends the first verification information to the client
  • the server sends the client
  • the server sends the client
  • the server sends the client
  • the server sends the client
  • the client sends the second verification information to the server
  • the first verification data includes: the hash value of the first client hello message, the first server feedback The hash value of the 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.
  • the second verification data is sent to the server through Finished information.
  • the second verification data can also be obtained by: hash(hash(M1
  • the second verification data may be sent after the client and the server exchange public keys, including the hash value of each frame of messages sent and/or received by the first client. Collection; it can also be carried in each message sent by the client to the server.
  • the second verification data carried in each message sent by the server to the client includes: the client is based on the third hash value carried in the most recently received message, The second check data is determined with the fourth hash value of the message to be sent by the client to the server.
  • the second check data may be the sum of the third hash value and the fourth hash value.
  • the third hash value in the first client hello message is obtained based on the first server feedback message; the fourth hash value of the third client hello message determined by the client based on the third client hello message hash value, in the third client hello message, the second check data includes the sum of the third hash value and the fourth hash value; the first hash value and the The second hash value has the same length.
  • the embodiments of the present application provide a flexible data transmission manner, and for terminal devices with better performance and high security requirements, the ECJPAKE distribution network protocol is used for data transmission. There is no need for the developer to select the data transmission process in advance, and the terminal device or server can determine the transmission process by itself according to actual needs. Moreover, in the embodiment of the present application, for a terminal device with high security level requirements, the PIN code of the terminal device is combined with the transmission process, which improves the difficulty of cracking the PIN code and improves the security of data transmission.
  • each frame of message transmitted by the terminal device and/or the server participates in the hash value operation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 8 shows an optional schematic flowchart of the server side of the data transmission method provided by the embodiment of the present application, and will be described according to each step.
  • Step S401 receiving a first client hello message sent by a client.
  • the server receives the first client hello message sent by the client.
  • the first client hello message includes first information, where the first information is used to indicate a first key agreement mode that the client can support.
  • the first key negotiation mode includes negotiating a key using a distribution protocol of ECDH and/or negotiating a key of a distribution protocol using ECJPAKE.
  • the first information includes a first set of cipher suites; the first set of cipher suites includes a set of at least one cipher suite capable of being supported by the client.
  • the first client hello message may further include: a first cipher suite field; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client.
  • 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.
  • the first client hello message may further include: a first encryption curve field; the encryption curve field is used to indicate part or all of the encryption curve parameters supported by the client.
  • the first client hello message further includes: a first public key, where the first public key includes: if the client can support the ECDH network configuration protocol, the first public key
  • the public key determined by any cipher suite in the set of cipher suites and/or any one of the encryption curves in the first set of encryption curves. Different cipher suites and/or encryption curves determine different public keys.
  • the first client hello message further includes: a first protocol identifier set, where the first protocol identifier set includes a protocol identifier corresponding to at least one protocol version, and the protocol version and the protocol identifier are one In one correspondence, the first set of protocol identifiers indicates a set of protocol versions supported by the client.
  • the first client hello message may further include: a protocol version field; the protocol version field is used to indicate part or all of the protocol version parameters supported by the client.
  • the first client hello message further includes: a first public key list, and the first public key list of the first client hello message is NULL.
  • Step S402 Determine a 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.
  • the server determining the second key agreement mode selected by the server according to the first key agreement mode includes: the server is based on the first key agreement carried in the first client hello message. At least one encryption suite included in the encryption suite set, 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, determine the second encryption supported by the server. key mode.
  • the first cipher suite set included in the first client hello message includes at least one cipher suite supported by the server, the first cipher suite included in the first client hello message
  • the curve set includes at least one encryption curve supported by the server
  • the first protocol identifier set included in the first client hello 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 the first server feedback message to the client.
  • the first server feedback message further includes: a second public key, the second public key is based on the At least one of the first encryption suite, the first encryption curve and the first protocol identifier is determined; or, when the server determines that the second key negotiation mode is to use the ECJPAKE distribution network protocol negotiation key, the The first server feedback message further includes: a first public key list, where the first public key list includes a public key pair sent by the server to the client and used to determine the shared key of the first client.
  • the first public key list may further include the PIN code of the server.
  • At least one cipher suite supported by the server is included in the first cipher suite set not included in the first client hello message, or included in the first client hello message
  • the first encryption curve set does not include at least one encryption curve supported by the server, or the first protocol identifier set included in the first client hello message does not include a protocol 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: the second encryption suite, the second encryption curve and the second protocol identifier .
  • the first encryption suite set does not include the second encryption suite, and the second encryption suite includes any one of at least one encryption suite supported by the server; the first encryption curve set does not include the a second encryption curve, where the second encryption curve includes any one of at least one encryption curve supported by the server; the first protocol identification set part includes the second protocol identification, and the second protocol identification
  • the protocol identifier corresponding to any one of the at least one protocol version supported by the server is included.
  • Step S403 if the first key negotiation mode includes the second key negotiation mode, determine a first server shared key based on the second key negotiation mode, and determine the first server shared key according to the first server shared key Carry out the target data transfer.
  • the first client shared key is determined based on the second key agreement mode, according to the second key agreement mode.
  • the first key agreement mode includes the second key agreement mode including: the first encryption suite set includes the first encryption suite, the first encryption curve set includes all In the case where the first encryption curve is used and the first protocol identifier set includes the first protocol identifier, the first key negotiation mode includes the first encryption suite carried in the first server feedback message, The second key agreement mode corresponding to the first encryption curve and the first protocol identifier.
  • the first key agreement mode includes the second key agreement mode, and may further include: the protocol version parameter of the protocol version field of the first client hello message includes the 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 hello message includes the cipher suite field of the first server feedback message The encryption curve parameter of the encryption curve field of the first client hello message includes the encryption suite parameter of the encryption suite field of the first server feedback message.
  • determining the shared key of the first client based on the second key agreement mode includes scenario 1 (step S201 to step S206) and scenario 2 (step S301 to step S304), which will not be repeated here. .
  • the scenario 1 includes: the second key negotiation mode is to negotiate a key using a distribution network protocol using ECDH; and determining the first client shared key based on the second key negotiation mode includes: The key is negotiated using the ECDH network distribution protocol.
  • the scenario 2 includes a configuration protocol in which the second key agreement mode is ECJPAKE.
  • Step S404 if the first key agreement mode does not include the second key agreement mode, receive a second client hello message sent by the client.
  • the first key agreement mode does not include the second key agreement mode, including: the first cipher suite set included in the first client hello message does not include the first service The second encryption suite carried in the terminal feedback message; or, the first encryption curve set included in the first client hello message does not include the second encryption curve carried in the first feedback information; or, the first encryption curve set The first protocol identifier set included in the client hello message does not include the second protocol identifier carried in the first feedback information. That is, the first key agreement mode does not include the second key agreement mode corresponding to the encryption suite, encryption curve and protocol identifier carried in the first server feedback message.
  • the server receives the second client hello message sent by the client, and the client sending the second client hello message includes: the client sends the second client hello to the server message, the second client hello message includes second information, where the second information is used to indicate a third key agreement mode that the client can support.
  • 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 encryption suite included in the first encryption suite set is completely different from at least one encryption suite included in the second encryption suite set; at least one encryption curve included in the first encryption curve set is the same as the At least one encryption curve included in the second set of encryption curves is completely different.
  • the second client hello message further includes: a fourth public key, where the fourth public key includes: if the client can support the ECDH network configuration protocol Next, the public key determined by any encryption suite in the second encryption suite set and/or any encryption curve in the second encryption curve set.
  • the second client hello message further includes: a second protocol identifier set, where the second protocol identifier set includes a protocol identifier corresponding to at least one protocol version, the protocol version and the protocol identifier are one
  • the second set of protocol identifiers indicates a set of protocol versions supported by the client.
  • the second client hello message further includes: a second public key list, and the second public key list of the second client hello message is NULL.
  • step S405 in the case that the server can support the third key agreement mode, step S405 is performed; in the case that the server cannot support the third key agreement mode, step S405 is performed S407.
  • Step S405 Send a second server feedback message based on the second client hello message, where the second server feedback message is used to indicate the fourth key agreement mode determined by the server.
  • the second server feedback message is used to indicate the fourth key agreement mode determined by the server.
  • step S402 the specific step process of the server sending the second server feedback message based on the second client hello message is similar to step S402, and details are not repeated here.
  • Step S406 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.
  • 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 step S203. It will not be repeated here.
  • Step S407 sending a first warning message.
  • the failure of the server to support the third key agreement mode includes: the second cipher suite set included in the second client hello message does not include an cipher suite supported by the server; or , the first encryption curve set included in the second client hello message does not include an encryption curve supported by the server; or, the first protocol identifier set included in the second client hello message does not include the service The protocol identifier supported by the endpoint.
  • the server sends first warning information to the client, where the first warning message is used to instruct to disconnect the connection between the client and the server.
  • the embodiment of the present application provides a flexible data transmission manner, and for a client with better performance and high security requirements, the ECJPAKE network distribution protocol is used for data transmission. There is no need for the developer to select the data transmission process in advance, and the client or server can determine the transmission process according to actual needs. Moreover, in the embodiment of the present application, for a client with high security level requirements, the PIN code of the client is combined with the transmission process, which improves the difficulty of cracking the PIN code and improves the security of data transmission.
  • each frame of message transmitted by the client and/or the server participates in the hash value operation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 9 shows an optional schematic flowchart of the data transmission method provided by the embodiment of the present application
  • FIG. 10 shows a schematic schematic diagram of a detailed processing process of the data transmission method provided by the embodiment of the present application. 10 is explained.
  • Step S501 the client sends a first client greeting message to the server.
  • the client sends a first client hello message to the server, where the first client hello message includes first information, and the first information is used to indicate the first client hello message that the client can support.
  • a key agreement mode is used to indicate the first client hello message that the client can support.
  • the first key negotiation mode includes negotiating a key using a distribution protocol of ECDH and/or negotiating a key of a distribution protocol using ECJPAKE.
  • the first information includes at least one of a first set of encryption suites, a first set of encryption curves, and a first set of protocol identifiers.
  • the first set of encryption suites includes a set of at least one encryption suite that the client can support;
  • the first set of encryption curves includes a set of at least one encryption curve that the client can support;
  • the first protocol identifier The set includes a protocol identifier corresponding to at least one protocol version, the protocol version is in a one-to-one correspondence with the protocol identifier, and the first protocol identifier set indicates a set of protocol versions supported by the client.
  • the first Client Hello message is transmitted via the ClientHello message shown in FIG. 10 .
  • 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 ClientHello message includes The “supported_group” field of the message is used to indicate the first encryption curve set; the "keyshare” field included in the ClientHello message is used to indicate the first public key.
  • the ClientHello message further includes "ecjpake_key_kp_pair_list” for indicating the public key pair used by the network distribution protocol of ECJPAKE.
  • the "ecjpake_key_kp_pair_list” is NULL.
  • the "keyshare" field is further used to indicate a fourth random sequence, and the fourth random sequence includes a sequence randomly generated by the client; further, the "keyshare” field is used to indicate the first random sequence The fourth sequence of numbers formed by the combination of the public key and the fourth random sequence.
  • Step S502 the server sends a first server feedback message to the client.
  • the server receives the first client hello message sent by the client; and determining the second key agreement mode selected by the server according to the first key negotiation mode includes: the server is based on the The protocol corresponding to at least one encryption suite included in the first encryption suite set, at least one encryption curve included in the first encryption curve set, and at least one protocol version included in the first protocol identifier set carried in the first client hello message The identifier is used to determine the second key mode supported by the server.
  • the first cipher suite set included in the first client hello message includes at least one cipher suite supported by the server, the first cipher suite included in the first client hello message
  • the curve set includes at least one encryption curve supported by the server
  • the first protocol identifier set included in the first client hello 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 the first server feedback message to the client.
  • the first server feedback message when the server determines that the second key negotiation mode is to use the ECDH distribution protocol to negotiate the key, the first server feedback message further includes: a second public key, the The second public key is determined based on at least one of the first encryption suite, the first encryption curve, and the first protocol identification.
  • the first server feedback message is transmitted through the ServerHello message shown in FIG. 10 .
  • 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 “cipher_suites” field included in the ServerHello message is used to indicate the first cipher suite.
  • the "supported_group” field is used to indicate the first encryption curve; the "keyshare” field included in the ServerHello message is used to indicate the second public key.
  • the ServerHello message does not include "ecjpake_key_kp_pair_list”.
  • the "keyshare" field is further used to indicate a second random sequence, and the second random sequence includes a sequence randomly generated by the server; further, the "keyshare” field is used to indicate a second random sequence A fourth sequence of numbers formed by combining the public key with the second random sequence.
  • Step S503 the client receives the first server feedback message.
  • the client receives the first server feedback message, and determines that the first encryption curve included in the first feedback message is the same as the first encryption curve included in the first client hello message. Whether the encryption curve of the key is the same, if the first encryption curve is different from the encryption curve determined for the first public key, step S504 is executed; When the encryption curves of the public keys are the same, step S505 is executed.
  • Step S504 the client sends a second client hello message to the server.
  • the second client hello message includes at least one of: a first encryption suite, a first encryption curve, and a first protocol identification.
  • the second client hello 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.
  • the second client hello message may further include: a first digital sequence formed by combining the third public key and the first random sequence.
  • the first random sequence is randomly generated by the client.
  • the second Client Hello message is transmitted via the ClientHello message shown in FIG. 10 .
  • 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 “cipher_suites” field included in the ClientHello message is used to indicate the first cipher suite.
  • the "supported_group” field is used to indicate the first encryption curve; the "keyshare” field included in the ClientHello message is used to indicate the third public key.
  • the ClientHello message further includes "ecjpake_key_kp_pair_list” for indicating the public key pair used by the network distribution protocol of ECJPAKE.
  • the "ecjpake_key_kp_pair_list” is NULL.
  • Step S505 the server determines the first key based on the first public key or the third public key.
  • the determining, by the server, the first key based on the first public key includes: the first encryption curve included in the first feedback message and determining the first encryption curve included in the first client hello message When the encryption curves of the public keys are the same, the server determines the first key based on the first client hello message.
  • the server determines the first key based on the first public key indicated by the "keyshare" field included in the first client hello message; or, the server removes the "keyshare” field indication A fourth random sequence in the fourth sequence of numbers, the first key is determined based on the first public key included in the fourth sequence of numbers.
  • the determining, by the server, the first key based on the first public key includes: the first encryption curve included in the first feedback message and determining the first encryption curve included in the first client hello message When the encryption curves of a public key are different, the server determines the first key based on the second client hello message.
  • the server determines the first key based on the third public key indicated by the "keyshare" field included in the second client hello message; or, the server removes the "keyshare” field indication
  • the first random sequence in the first sequence of numbers of the first key is determined based on the third public key included in the first sequence of numbers.
  • steps S501 to S505 may be processes performed in the Epoch0 stage, and the messages transmitted between the client and the server are not encrypted.
  • Step S506 the server sends the first verification information to the client.
  • step S506 are the same as those of the step S203, and are not repeated here.
  • Step S507 the server sends the first verification data to the client.
  • step S507 The specific steps of the step S507 are the same as those of the step S204, and are not repeated here.
  • Step S508 the client sends the second verification information to the server.
  • step S508 are the same as those of the step S205, and are not repeated here.
  • Step S509 the client sends the second verification data to the server.
  • step S509 are the same as those of the step S206, and are not repeated here.
  • the client sends the second verification information to the server.
  • steps S506 to S509 may be processes performed in the Epoch1 stage, and the messages transmitted between the client and the server are encrypted and/or decrypted using the first key.
  • Step S510 the client determines the shared key of the first client, and performs target data transmission according to the shared key of the first client.
  • the client determining the first client shared key includes: the client determining, based on at least one of the first public key, the second public key, the third public key and the first key, The first client shares the secret key.
  • the verification of the first verification data is passed, indicating that the message sent and/or received by the client has not been tampered with, and the client can transmit the target data based on the shared key of the first client.
  • Step S511 the server determines the first server shared key, and performs target data transmission according to the first server shared key.
  • the determining, by the server, the first server shared key includes: the server determining, based on at least one of the first public key, the second public key, the third public key, and the first key, The first server shares the key.
  • the verification of the second verification data is passed, indicating that the message sent and/or received by the server has not been tampered with, and the server can transmit the target data based on the shared key of the first server.
  • the first client shared key is the same as or different from the first server shared key.
  • the first client shared key is determined based on the first key, for example, the first client shared key may include data determined after encryption of the first key.
  • steps S510 to S511 may be processes performed in the Epoch2 stage, and the messages transmitted by the client are encrypted and/or decrypted by the first client shared key; the server The transmitted message is encrypted and/or decrypted by the first server shared key.
  • the method further includes: if the number of times that the client sends and/or receives the target data encrypted by the first client shared key is greater than a first threshold, the client Re-determine the client shared secret with the server.
  • the number of times that the client sends and/or receives the target data encrypted by the first client shared key is greater than a first threshold, including: the first client shared key is encrypted for too many times , multiple transmissions will increase the risk of the first client's shared key being deciphered.
  • the client and all The server updates the first key and/or the first client shared key.
  • the embodiments of the present application provide a flexible data transmission method, and the data transmission process does not need to be selected by the developer or in advance, and the client or server can determine the transmission process by itself according to actual needs.
  • each frame of message transmitted by the client and/or the server participates in the hash value calculation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 11 shows another optional schematic flowchart of the data transmission method provided by the embodiment of the present application
  • FIG. 12 shows another detailed processing flowchart of the data transmission method provided by the embodiment of the present application, which will be combined with FIG. 11 , Fig. 12 is explained.
  • Step S601 the client sends a first client greeting message to the server.
  • step S601 The specific process of the step S601 is the same as that of the step S501, and details are not repeated here.
  • Step S602 the server receives the first client hello message sent by the client.
  • the server receives the first client hello message sent by the client; determines the second key negotiation mode selected by the server according to the first key negotiation mode, and uses the first service
  • the client feedback message is sent to the client.
  • the server determining the second key agreement mode selected by the server according to the first key agreement mode includes: the server is based on the first key agreement carried in the first client hello message. At least one encryption suite included in the encryption suite set, 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, determine the second encryption supported by the server. key mode.
  • the first cipher suite set included in the first client hello message includes at least one cipher suite supported by the server, the first cipher suite included in the first client hello message
  • the curve set includes at least one encryption curve supported by the server
  • the first protocol identifier set included in the first client hello 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 the first server feedback message to the client.
  • the first server feedback message further includes: a first public key list, the The first 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 may further include the PIN code of the server.
  • the first server feedback message is transmitted through the HelloRetryRequest message shown in FIG. 12 .
  • 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; the “cipher_suites” included in the HelloRetryRequest message
  • the supported_group” field is used to indicate the first encryption curve.
  • 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.
  • the HelloRetryRequest message includes "ecjpake_key_kp_pair_list", which is used to indicate the first public key list.
  • Step S603 the client sends a third client hello message to the server.
  • the third client hello message includes at least one of: a first encryption suite, a first encryption curve, and a first protocol identification.
  • the third client hello message may further include: a second public key list and a sixth public key; the sixth public key is determined based on the first encryption suite and/or the first encryption curve .
  • the second public key list may also include the PIN code of the client.
  • the third client hello message may further include: a first digital sequence formed by combining the sixth public key and the first random sequence.
  • the first random sequence is randomly generated by the client.
  • the sixth public key may also include the PIN code of the client.
  • the third Client Hello message is transmitted via the ClientHello message shown in FIG. 12 .
  • 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 “cipher_suites” field included in the ClientHello message is used to indicate the first cipher suite.
  • the supported_group” field is used to indicate the first encryption curve.
  • 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.
  • the ClientHello message further includes "ecjpake_key_kp_pair_list" for indicating the second public key list used by the ECJPAKE network configuration protocol.
  • Step S604 the server sends a greeting message to the first server of the client.
  • the first server hello message includes at least one of the following: a first encryption suite, a first encryption curve, and a first protocol identifier.
  • the first server hello 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 further include the PIN code of the server.
  • the first server hello message may further include: a third digital sequence formed by combining the fifth public key and the third random sequence.
  • the third random sequence is randomly generated by the server.
  • the first server hello message is transmitted through the ServerHello message shown in FIG. 12 .
  • 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 “cipher_suites” field included in the ServerHello message is used to indicate the first cipher suite.
  • the supported_group” field is used to indicate the first encryption curve.
  • 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.
  • steps S601 to S604 may be processes performed in the Epoch0 stage, and the messages transmitted between the client and the server are not encrypted.
  • Step S605 the server sends the first verification data to the client.
  • step S605 The specific process of the step S605 is the same as that of the step S303, and will not be repeated here.
  • Step S606 the client sends the second verification data to the server.
  • step S606 The specific process of the step S606 is the same as that of the step S303, and details are not repeated here.
  • steps S605 to S606 may be processes performed in the Epoch1 stage, and the messages transmitted between the client and the server are encrypted and/or decrypted using the first key.
  • Step S607 the client determines the shared key of the first client, and performs target data transmission according to the shared key of the first client.
  • the client determining the first client shared secret comprises: the client is based on the fifth public key, the sixth public key, the first public key list, the second public key list and the first secret key. At least one of the keys is used to determine the shared key of the first client.
  • the verification of the first verification data is passed, indicating that the message sent and/or received by the client has not been tampered with, and the client can transmit the target data based on the shared key of the first client.
  • Step S608 the server determines the first server shared key, and performs target data transmission according to the first server shared key.
  • the determining, by the server, the shared key of the first server includes: the server is based on the fifth public key, the sixth public key, the first public key list, the second public key list and the first secret key. at least one of the keys to determine the shared key of the first server.
  • the verification of the second verification data is passed, indicating that the message sent and/or received by the server has not been tampered with, and the server can transmit the target data based on the shared key of the first server.
  • the first client shared key is the same as or different from the first server shared key.
  • the first client shared key is determined based on the first key, for example, the first client shared key may include data determined after encryption of the first key.
  • steps S510 to S511 may be processes performed in the Epoch2 stage, and the messages and/or data transmitted by the client are encrypted and decrypted by the first client shared key; the service The messages and/or data transmitted by the terminal are encrypted and decrypted by the shared key of the first server
  • the method further includes: if the number of times that the client sends and/or receives the target data encrypted by the first client shared key is greater than a first threshold, the client Re-determine the client shared secret with the server.
  • the number of times that the client sends and/or receives the target data encrypted by the first client shared key is greater than a first threshold, including: the first client shared key is encrypted for too many times , multiple transmissions will increase the risk of the first client's shared key being deciphered.
  • the client and all The server updates the first key and/or the first client shared key.
  • the embodiment of the present application provides a flexible data transmission manner, and for a client with better performance and high security requirements, the ECJPAKE network distribution protocol is used for data transmission. There is no need for the developer to select the data transmission process in advance, and the client or server can determine the transmission process according to actual needs. Moreover, in the embodiment of the present application, for a client with high security level requirements, the PIN code of the client is combined with the transmission process, which improves the difficulty of cracking the PIN code and improves the security of data transmission.
  • each frame of message transmitted by the client and/or the server participates in the hash value calculation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 13 shows another optional schematic flowchart of the data transmission method provided by the embodiment of the present application
  • FIG. 14 shows another detailed processing flowchart of the data transmission method provided by the embodiment of the present application, which will be combined with FIG. 13 , Fig. 14 is explained.
  • Step S801 the client sends a first client greeting message to the server.
  • step S801 The specific process of the step S801 is the same as that of the step S501, and details are not repeated here.
  • Step S802 the server sends a first server feedback message to the client.
  • the first cipher suite set not included in the first client hello message includes at least one cipher suite supported by the server, or the first cipher suite included in the first client hello message
  • An encryption curve set does not include at least one encryption curve supported by the server, or the first protocol identifier set included in the first client hello 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 encryption suite set does not include the second encryption suite, and the second encryption suite includes any one of at least one encryption suite supported by the server; the first encryption curve set does not include the a second encryption curve, where the second encryption curve includes any one of at least one encryption curve supported by the server; the first protocol identification set part includes the second protocol identification, and the second protocol identification
  • the protocol identifier corresponding to any one of the at least one protocol version supported by the server is included.
  • the first server feedback message is transmitted through the HelloRetryRequest message shown in FIG. 14 .
  • 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; the “cipher_suites” included in the HelloRetryRequest message
  • the supported_group” field is used to indicate the second encryption curve.
  • 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.
  • step S803 in the case that the first key agreement mode includes the second encryption suite, the second encryption curve, and the second key agreement mode corresponding to the second protocol identifier, performing the step The flow from S503 to step S511, or the flow from step S603 to step S608 is performed. In the case that the first key agreement mode does not include the second encryption suite, the second encryption curve and the second key agreement mode corresponding to the second protocol identifier, step S803 is performed.
  • Step S803 the client sends the second client greeting information to the server.
  • the sending, by the client, the second client hello message includes: the client sending a second client hello message to the server, where the second client hello message includes second information, and the first The second information is used to indicate the third key negotiation mode that the client can support.
  • 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 encryption suite included in the first encryption suite set is completely different from at least one encryption suite included in the second encryption suite set; at least one encryption curve included in the first encryption curve set is the same as the At least one encryption curve included in the second set of encryption curves is completely different.
  • the second client hello message further includes: a fourth public key, where the fourth public key includes: if the client can support the ECDH network configuration protocol Next, the public key determined by any encryption suite in the second encryption suite set and/or any encryption curve in the second encryption curve set.
  • the second client hello message further includes: a second protocol identifier set, where the second protocol identifier set includes a protocol identifier corresponding to at least one protocol version, the protocol version and the protocol identifier are one
  • the second set of protocol identifiers indicates a set of protocol versions supported by the client.
  • the second client hello message further includes: a second public key list, and the second public key list of the second client hello message is empty (NULL).
  • the second Client Hello message is transmitted via the ClientHello message shown in FIG. 14 .
  • 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; the ClientHello message includes The “supported_group” field is used to indicate the second encryption curve set.
  • 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.
  • the ClientHello message further includes "ecjpake_key_kp_pair_list” for indicating the public key pair used by the network distribution protocol of ECJPAKE.
  • the "ecjpake_key_kp_pair_list” is NULL.
  • step S804 when the third key agreement mode includes an encryption suite that the server can support, an encryption curve, and a fourth key agreement mode corresponding to the protocol identifier, step S804 is performed. In the case that the third key agreement mode does not include the fourth key agreement mode corresponding to the encryption suite, encryption curve and protocol identifier that can be supported by the server, step S805 is performed.
  • Step S804 the server sends the second feedback information.
  • the second cipher suite set included in the second client hello message includes at least one cipher suite supported by the server, the second cipher included in the second client hello message
  • the curve set includes at least one encryption curve supported by the server
  • the second protocol identifier set included in the second client hello message includes a protocol identifier corresponding to at least one protocol version supported by the server
  • the server determines the second encryption suite, the second encryption curve and the second protocol identifier corresponding to the fourth key negotiation mode, and sends the second server feedback message to the client.
  • the first server feedback message further includes: a fourth public key, the fourth public key is based on the At least one of the second encryption suite, the second encryption curve, and the second protocol identifier is determined; or, when the server determines that the second key negotiation mode is to use the ECJPAKE distribution network protocol negotiation key, the The first server feedback message further includes: a third public key list, where the third public key list includes a public key pair sent by the server to the client and used to determine the shared key of the first client.
  • the first server feedback message is transmitted through the ServerHello message shown in FIG. 14 .
  • 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 “cipher_suites” field included in the ServerHello message is used to indicate the second cipher suite.
  • the "supported_group” field is used to indicate the second encryption curve; the "keyshare” field included in the ServerHello message is used to indicate the fourth public key.
  • the ServerHello message does not include "ecjpake_key_kp_pair_list”; if the client and the server use the ECJPAKE network configuration
  • the key negotiation process of the protocol the ServerHello message further includes "ecjpake_key_kp_pair_list", and the "ecjpake_key_kp_pair_list” is used to indicate the first public key list.
  • the method further includes: performing the process from step S503 to step S511, or performing the process from step S603 to step S608.
  • Step S805 the server sends a first warning message.
  • the failure of the server to support the third key agreement mode includes: the second cipher suite set included in the second client hello message does not include an cipher suite supported by the server; or , the first encryption curve set included in the second client hello message does not include an encryption curve supported by the server; or, the first protocol identifier set included in the second client hello message does not include the service The protocol identifier supported by the endpoint.
  • the server sends first warning information to the client, where the first warning message is used to instruct to disconnect the connection between the client and the server.
  • the method further includes:
  • Step S806 the client sends a second warning message.
  • the client when the message sent by the server received by the client includes two or more encryption curves, two or more encryption suites, or two or more version identifiers, the client sends the message to the server.
  • the second warning message is used to disconnect the connection with the server; the second warning message is used to instruct to disconnect the connection between the client and the server.
  • the message sent by the server includes: a first server feedback message and/or a first server hello message.
  • the embodiments of the present application provide a flexible data transmission method.
  • the ECDH network distribution protocol is used for data transmission; for clients with better performance and high security requirements terminal, use ECJPAKE's distribution network protocol for data transmission.
  • the PIN code of the client is combined with the transmission process, which improves the difficulty of cracking the PIN code and improves the security of data transmission.
  • each frame of message transmitted by the client and/or the server participates in the hash value calculation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 15 shows another optional schematic flowchart of the data transmission method provided by the embodiment of the present application.
  • Step S901 the client sends a client greeting message to the server.
  • the client hello message when the client hello message is sent for the first time in a round of negotiation, includes at least one of the following: a protocol version field: used to indicate the part supported by the client or All protocol version parameters; the encryption suite field is used to indicate part or all of the encryption suite parameters supported by the client; the encryption curve field is used to indicate part or all of the encryption curve parameters supported by the client; the first A public key field is used to indicate the first public key of the client; the second public key field is empty or does not include the second public key field.
  • a protocol version field used to indicate the part supported by the client or All protocol version parameters
  • the encryption suite field is used to indicate part or all of the encryption suite parameters supported by the client
  • the encryption curve field is used to indicate part or all of the encryption curve parameters supported by the client
  • the first A public key field is used to indicate the first public key of the client
  • the second public key field is empty or does not include the second public key field.
  • Step S902 the receiving server resends the hello message or the server hello message or the warning message based on the request sent by the client hello message.
  • the client hello message when the request to resend the hello message is the request to resend the hello message sent by the server for the first time in a round of negotiation, the client hello message is sent again; and/or, when The request to resend the hello message is the request to resend the hello message sent by the server for the second time in one round of negotiation, then a warning message is sent and the connection is disconnected; and/or the service sent by the server is received.
  • the client hello message lacks any required field, a warning message is sent and the connection is disconnected; and/or, a warning message is sent when the protocol version number field of the server hello message sent by the server includes multiple protocol versions.
  • Disconnect when the cipher suite field of the server hello message sent by the server includes multiple cipher suite parameters or does not support cipher suite parameters, send a warning message and disconnect; and/or, When the encryption curve field of the server hello 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; When the first public key field of the server hello message includes multiple first public keys, a warning message is sent and the connection is disconnected.
  • Step S903 generating a client shared key based on the public key sent by the server.
  • the client when the client can support the request to resend the feedback message sent by the server or the key agreement mode indicated by the server hello message, the client resends the feedback message based on the request or The server public key carried in the server hello message generates a client shared key.
  • the embodiments of the present application provide a flexible data transmission method, and the data transmission process does not need to be selected by the developer or in advance, and the client or server can determine the transmission process by itself according to actual needs.
  • each frame of message transmitted by the client and/or the server participates in the hash value operation of the verification data, which ensures that the handshake negotiation data is not tampered with, and improves the safety and reliability of the handshake negotiation process. sex.
  • FIG. 16 shows another optional schematic flowchart of the data transmission method provided by the embodiment of the present application, which will be described according to each step.
  • Step S1001 the first end negotiates a shared key with the second end through a handshake message.
  • the second end when the first end is a client, the second end is a server; or, when the first end is a server, the second end is a client.
  • the client negotiates the shared key with the server through the 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 S407.
  • the handshake message includes 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 greeting message Warning message at least one.
  • the handshake message includes a handshake hello message and a handshake response message;
  • the handshake hello message includes: at least one of a first client hello message, a second client hello message, and a third client hello message ;
  • the handshake response message includes: a first server hello message;
  • the retransmission request message includes a first server feedback message.
  • the message payload of the handshake greeting message or the handshake response message includes a public key list field, the value of the public key list field is NULL, and the null value is used to determine whether the second end supports the target encryption suite .
  • the public key list field is indicated by the "ecjpake_key_kp_pair_list" field.
  • the method further includes: in the process of negotiating the key, the first end checks the handshake message to obtain a check value.
  • the handshake message includes a handshake complete message, which is used to indicate completion of the negotiation process of the key, wherein the handshake complete message carries the check value.
  • the handshake completion message may include the first verification data in steps S204, S303, S507, and S605, and/or the second verification data in steps S205, S304, S509, and S606.
  • check data correspondingly, the check value may be a hash value carried in the first check data and/or the second check data.
  • Step S1002 the first end transmits application data to the second end through a content message, and the content message is encrypted and decrypted by using the shared key.
  • 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 end by using the shared key.
  • the method further includes encrypting a message payload in the content message using the shared key.
  • the message payload includes: a protocol version field, an encryption suite field, a shared key field, and an encryption curve field.
  • the protocol version field includes the "supported_version” field in the flow of Fig. 3 to Fig. 16;
  • the cipher suite field includes the "cipher_suites” field in the flow of Fig. 3 to Fig. 16;
  • the shared key field includes Fig. 3 to At least one of the "key_share” field, the "ecjpake_key_kp_pair_list” field, and the "ecjpake_key_kp_params” field in the flow of FIG. 16 ;
  • the encryption curve field includes the "supported_group” field in the flow of FIG. 3 to FIG. 16 .
  • the handshake hello message includes the first client hello message, the second client hello message, and the third client hello message included in the processes of FIG. 3 to FIG. 16 ;
  • the handshake response message includes the 3 to the first server hello message included in the flow of FIG. 16;
  • the retransmission request message includes the first server feedback message and/or the second server feedback message included in the flow of FIG. 3 to FIG. 16;
  • the authentication data message includes the first verification information and/or the second verification information included in the flow of FIG. 3 to FIG. 16;
  • the handshake complete message includes the first verification data and/or the flow of FIG. 3 to FIG. 16. or the second check data.
  • the first client hello message, the first server feedback message, the second client hello message, the first server hello message, and the third server hello message included in the processes of FIGS. 3 to 16 The message has the same message format, and the message format includes: message count and message payload; the message count includes a key generation (Epoch) identification and a message count (Seq), wherein the key generation passes less than the first bit.
  • the message count is characterized by bit information less than the second digit.
  • the first number of digits may be 2; the second number of digits may be 8.
  • the message payloads of the first client hello message, the first server feedback message, the second client hello message, the first server hello message, and the third server hello message include at least the following fields One or more of: protocol version field, cipher suite field, shared key field, encryption curve field.
  • the key algebra is represented by E, and the E represents the lowest bit of the Epoch; the Epoch is used to indicate the form of the currently used symmetric key, as shown in Table 1, in the case of Epoch 0, no encryption is used. key; in the case of Epoch 1, use the first key; in the case of Epoch 2, use the second key, etc.
  • the key generation identifier is a;
  • the key algebraic identifier is a+1; the first end communicates with the second end through 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 generation for the transmission of the preceding application data is smaller than the key generation for the transmission of the latter application data.
  • steps S501 to S505 may be performed in the Epoch0 phase, and the messages transmitted between the client and the server are not encrypted; steps S506 to S509 may be performed in the Epoch1 phase.
  • the message transmitted between the client and the server is encrypted and/or decrypted by the first key;
  • the transmission of the application data can be Epoch2 to EpochN, between the client and the server
  • the transmitted messages are encrypted and/or decrypted by the shared key.
  • the message count includes 8 bytes, and each byte occupies 8 bits (8 bits of information), wherein the first 2 bytes of the message count represent the Epoch (16 bits).
  • E is represented by bit information that is less than the first digit; the E may be the lowest 1 bit corresponding to the Epoch (occupying 1 bit), or the E may be the lowest 0 bit corresponding to the Epoch (do not occupy 1 bit). bit information).
  • the message payload of the handshake hello message or the handshake response message includes an ecjpake_key_kp_pair_list field, the value of the public key list field is NULL, and the null value is used to determine whether the second end The target cipher suite is supported.
  • the second end returns the retransmission request message based on the handshake hello message, wherein the cipher suite field in the retransmission request message is configured as the target cipher suite.
  • the data sent and/or received by the client and the server are encrypted and decrypted using different keys.
  • enter Epoch 2 If the key needs to be updated later, it can be updated by the client and the server synchronously, that is, enter Epoch N.
  • FIG. 17 shows an optional structural schematic diagram of the content of a message transmitted by a client and a server according to an embodiment of the present application.
  • Seq is the message count
  • the message corresponding to the Seq is the sequence number of the information transmitted by the client and/or the server (that is, the message corresponding to the Seq is the client and/or the server). number of messages transmitted).
  • the message count includes 8 bytes, and each byte occupies 8 bits (8 bits of information), wherein the last 6 bytes of the message count represent Seq (occupying 48 bits), and this
  • the message count identifier is represented by the bit information of the lowest third digit of the message count; the value of the message count identifier is equal to the sum of the value of the previously transmitted adjacent message count identifier and 1. The third digit is smaller than the second digit.
  • the third digit may be 7, and accordingly, the message count identifier is the lowest 7 digits of the message count; or, in the second digit In the case of 8, the third digit may be 6, and accordingly, the message count identifier is the lowest 6 digits of the message count. That is to say, in the embodiment of the present application, the message sequence number is represented by bit information less than or equal to 8 bits. Compared with the byte length of the current standard ECJPAKE network distribution protocol, the message sequence number is reduced by 1-2 bytes, which is more streamlined. , which can reduce the amount of transmitted data.
  • the message payload includes actual data and a message type including padding type, application data type, alert type, and handshake type.
  • Payload is actual data, including: transmission data carried in the verification data encrypted by the first key; or transmission data carried in the application data encrypted by the shared key; or , the transmission data carried by the handshake information.
  • the transmission data carried in the verification data encrypted by the first key may be a set of hash values included in the verification data;
  • the transmission data carried in the application data can be the application data to be transmitted (such as turning on the lights, turning off the lights, starting to sweep the floor, opening the curtains, etc.);
  • the transmission data carried by the handshake information can be public keys, random sequences, encryption curves, At least one of cipher suite, protocol identifier, and public key list.
  • the message format includes: E, Seq and Payload; the Payload includes Content and Type.
  • the payload includes a message payload, and the payload data is encrypted except for the 0th generation key (Epoch 0).
  • the message payload includes actual data and a message type including padding type, application data type, warning type and handshake type.
  • the definition of the message type (Type) is shown in Table 2:
  • the padding type includes Padding in Table 2, which is used to pad the Payload to an appropriate length.
  • the Content part corresponding to Padding is still in Payload format, that is, the last byte needs to be re-judged according to the message type. When parsing, you can directly drop the Padding at the end of the Payload.
  • the application data type includes Application Data in Table 2, including the transmission of application data between the first client and/or the server, which can be turning on the lights, turning off the lights, collecting environmental information, Biometric data collection, etc.
  • the warning type includes the notification messages in Table 2, and specifically includes messages that inform the ECDH distribution network protocol or the ECJPAKE distribution network protocol, such as the first warning message, the second warning message, etc., such as handshake success and handshake failure.
  • the handshake type includes the handshake negotiation message in Table 2, and specifically includes the first information, the second sequence, the first verification data, the first verification information, the second verification data, the second verification information, the third sequence, the first verification At least one of a retransmission request and a first greeting message.
  • Alert is used to send alarm messages, and the codes include:
  • the client and/or server must disconnect when receiving the alarm message.
  • the code of the Handshake message includes:
  • the Handshake is used to send a handshake message, and the handshake message includes: first information, a second sequence, first verification data, first verification information, second verification data, and second verification information , at least one of a third sequence, a first retransmission request, and a first greeting message.
  • the end that sends the at least one Handshake message may combine the at least one Handshake message, so that only one encryption is required.
  • the boundary of each Handshake message is determined by Handshake.len, and all Handshakes included in a message are determined by the length of the entire message.
  • the code of ClientHello sent by the client includes:
  • extension is an extension used to describe the client's own capabilities and related parameters. All extensions in Extension must be arranged in ascending order of extension type.
  • ClientHello is the first message in protocol negotiation, sent by Client to Server. It is used to inform the Server of the authentication capability and custom parameters of the Client.
  • the code of ServerHello sent by the server includes:
  • extension is an extension used to describe the server's own capabilities and related parameters. All extensions in Extension must be arranged in ascending order of extension type. Only when a certain extension is given in the ClientHello (representing that the Client supports the certain extension), the corresponding extension is allowed to be responded to in the response of the ServerHello.
  • ServerHello is sent by the Server to the Client to determine the connection parameters of the session.
  • ClientHello is the first message in protocol negotiation, sent by Client to Server. It is used to inform the Server of the authentication capability and custom parameters of the Client.
  • the Client When the Client processes ServerHello, if it finds any unsupported extension, it must send an unexpected_message warning to the Server and disconnect the connection. The server finds that the required extension does not exist, and must send an unexpected_message warning to the client and disconnect the connection.
  • the code for the HelloRetryRequest message includes:
  • the extensions represent extensions, which are used to describe the server's own capabilities and related parameters.
  • the Server may send a HelloRetryRequest to request the Client to re-initiate the negotiation.
  • the more common situation 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.
  • Retryrequest is only allowed to be initiated once.
  • the Server if the parameters sent by the second Clienthello are still unacceptable, the Server must send a handshake_failure warning and close the connection.
  • the Client if a second HelloRetryrequest is received, the Client must send an unexpected_message and disconnect.
  • the HelloRetryRequest message is used in the ECDH distribution protocol to respond to the wrong ClientHello message; or, in the ECJPAKE distribution protocol, it is used to transmit ECJPAKE Round 1 data.
  • the response to the wrong ClientHello message in the ECDH network distribution protocol includes steps S301 to S302, which will not be repeated here;
  • the ECJPAKE Round 1 data transmission in the ECJPAKE network distribution protocol includes: Steps S401 to S402 are not repeated here.
  • the code for the Authenticate message includes:
  • the Authenticate message is used to transmit authentication data.
  • the message format will change according to the value of the Authentication column defined by cipher_suites. In particular, when Authentication is None, the message must be omitted. Under different authentication methods, Authenticate is constructed in different ways.
  • the code of the Authenticate message includes:
  • the Authenticate message is used for certificate authentication of ECDH, and supports two kinds of certificates: X509 certificate and custom certificate.
  • the code for the Finished message includes:
  • verify_data is to use the current Transcripthash value to calculate the HMAC. Calculation methods include:
  • TranscriptHash Server: TranscriptHash(ClientHello1...Server Authenticate).
  • extension is a supplementary description of the message, and the code includes:
  • extension_data represents the extension data defined in each extension type; data_size represents the data length.
  • the encoding method can refer to variable-length integers.
  • data_size is not greater than 16383 bytes, that is, data_size can only be 1 byte or 2 bytes after encoding. When the encoding is 2 bytes, the highest bit of the first byte is 1, and the highest bit of the second byte is not 1.
  • the extension_type represents the message type of the Extension as shown in Table 3:
  • Type Sym apply to 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
  • the "applicable to” is used to identify the handshake message that allows the use of the corresponding extension.
  • the message names are represented by abbreviations: CR (ClientHello), SR (ServerHello), HRR (HelloRetryRequest), AU (Authenticate).
  • Type 0 represents the version number
  • Type 1 represents the encryption suite, which can be ECDH, (Diffle-Hellman, DH), etc.
  • Type 2 represents the type of curve used, such as elliptic curve
  • Type 4 represents the interactive public key
  • Type 5 and Type 6 represent the Public keys at different stages.
  • the code for supported_version includes:
  • supported_version indicates a protocol version supported by the client or server.
  • the current protocol version is 1.
  • the clent when the Client finds that there are multiple Versions in the supported_version extension in the received ServerHello, or finds that the Version itself does not support, the clent should send a protocol_version warning and close the connection.
  • the code for cipher_suites includes:
  • the cipher_suites indicates the cipher suites supported by the client or the server.
  • the cipher_suites include CipherSuite, Sym, KeyExchange, Authentication, Cipher, MAC Tag, and Hash.
  • CipherSuite is used to indicate the value of uint8 of the cipher suite; Sym is used to indicate the name of the cipher suite, which is used to unify the naming of an implementation.
  • KeyExchange is used to indicate the key exchange method and affects the key_share extension.
  • Authentication is used to indicate the authentication method, which affects the Authenticate message;
  • Cipher is used to indicate the data encryption method, which needs to be used during encryption;
  • MAC Tag is used to indicate the length of the MAC Tag of the encryption suite.
  • Hash is used to indicate the hash function used by HKDF, HMAC and other functions used during the operation of the protocol.
  • Client fills in one or more CipherSuites in ClientHello.
  • a CipherSuite is selected and filled in by the Server in ServerHello and HelloRetryRequest.
  • the CipherSuite filled in by the Server will be used as the encryption suite used for this connection.
  • the 0x00 (None) cipher suite is not allowed for non-debug purposes.
  • the Client when the Client finds in the received ServerHello that there are multiple cipher_suites in the cipher_suites extension or that the cipher_suites itself does not support it, the Client should send an unexpected_message warning and close the connection.
  • the code for supported_group includes:
  • supported EC curve parameters The definitions are shown in Table 4:
  • Client fills in one or more NamedGroups that it supports in ClientHello, but Server selects and fills in a NamedGroup in ServerHello and HelloRetryRequest.
  • the NamedGroup filled in by the server will be used as the EC curve for this connection.
  • the Client when the Client finds in the received ServerHello that there are multiple NamedGroups in the supported_group extension or that the NamedGroup itself is not supported, the Client should send an unexpected_message warning and close the connection.
  • the code for key_share includes:
  • key_share is used to share the key with the other party. Used for key negotiation. Key_share may be used in ClientHello, ServerHello, HelloRetryRequest messages.
  • ClientHello multiple key_shares are allowed to appear for the Server to choose.
  • ServerHell only one key_shares can appear, which is used to select key negotiation.
  • HelloRetryRequest only one key_shares can appear, and len is 0. It is only used to tell Client to re-send ClientHello.
  • the Client when the Client finds in the received ServerHello that there are multiple key_shareEntry in the extension or that the NamedGroup itself does not support it, the Client should send an unexpected_message warning and close the connection.
  • the client should carry an empty ecjpake_key_pair_list in the first ClientHello1. If the server side selects ECJPAKE for authentication, the server side needs to select the ECJPAKE class cipher_suites, fill in its own ECJPAKE Round1 data, and send a HelloRetryRequest to require the client to re-authenticate.
  • the message payload of the handshake greeting message or the handshake response message includes an ecjpake_key_kp_pair_list field, the value of the ecjpake_key_kp_pair_list field is NULL, and the null value is used to determine whether the second end supports the target cipher suite.
  • the format definitions are the same as those defined in Elliptic Curve J-PAKE Cipher for Transport Layer (TLS) Section 7.2.2 17 .
  • the "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, and so on.
  • TrainscriptHash is the Hash context that needs to be maintained during the handshake process to ensure the integrity of the data during the handshake process. Every time the Client and Server send or receive a message, they need to write the message content into the Hash context. Client initializes TranscriptHash when it receives ServerHello or HelloRetryRequest. Server initializes TranscriptHash when it receives the first packet of ClientHello.
  • TranscriptHash construction methods include:
  • HelloRetryRequest generally does not need to be used, so that HelloRetryRequest and the second ClientHello will be omitted in the entire interaction process.
  • the TranscriptHash composition includes:
  • the code for the message sequence number includes:
  • the message sequence number is divided into two parts, epoch and seq, with a total of 64 bits. Client and Server are handled separately.
  • epoch is the key algebra. When the connection is just established successfully, the epoch is 0. Including epoch 0, seq is incremented by 1 every time a message is sent and received.
  • FIG. 18 is a schematic diagram showing an optional structure of the client provided by the embodiment of the present application, which will be described according to each part.
  • the client 1100 includes: a first sending part 1101 , a first acquiring part 1102 and a first determining part 1103 .
  • the first sending part 1101 is configured to send a first client hello message, where the first client hello message includes first information, and the first information is used to indicate a first key agreement mode that the client can support ;
  • the first obtaining part 1102 is configured to obtain a first server feedback message sent by the server based on the first client hello message, where the first feedback information is used to indicate a second key agreement mode determined by the server , the first server-side feedback message includes a request to resend a greeting message or a server-side greeting message;
  • the first determining part 1103, if the first key negotiation mode includes the second key negotiation mode, is configured to determine the first client shared key based on the second key negotiation mode, and determine the first client shared key according to the first key negotiation mode. Clients share secret key for target data transfer.
  • the first sending part 1101 is configured to send a second client hello message, the second information is used to indicate a third key agreement mode that the client can support;
  • the first obtaining part 1102 is configured to obtain a second server feedback message sent by the server based on the second customer hello message, where the second feedback information is used to indicate the fourth password determined by the server. key negotiation mode;
  • the first determining part 1103 is configured to 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;
  • the first obtaining part 1102 is configured to obtain the first warning message sent by the server based on the second client hello message, and disconnect the connection based on the first warning message;
  • the third server feedback message sent by the second client hello message sends a second warning message and disconnects the connection based on the third server feedback message.
  • the first client hello message, the second client hello message, the first server feedback message, and the second server feedback message all include predefined fields, and the predefined fields include: a protocol version at least one of fields, encryption suite field, encryption curve field, first public key field and second public key field; the protocol version field is used to indicate part or all supported by the client or the server Protocol version parameter; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate the part supported by the client or the server or all encryption curve parameters; the first public key field is used to indicate the first public key of the client or the server; the second public key field is used to indicate the first public key of the client or the server Two public keys.
  • the first client hello 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 first public key of the client; the second public key field is empty; and/or, when the client and the server apply the first key agreement algorithm , the second client hello message includes the protocol version field, the cipher suite field, and the first public key field, where the first public key field includes the second public key of the client; and/or , when the client and the server apply the second key agreement algorithm, and the client supports the second key agreement mode, the second client hello message includes the protocol version field, the encryption suite field and the second public key field, where the second public key field includes the third public key of the client; and/or, when the client and the server apply the second key When the negotiation algorithm is used, and the client does not support the second key negotiation mode, the second client hello message includes the protocol version field, the encryption suite field, and the encryption curve field.
  • the first key agreement algorithm is an ECDH algorithm
  • the second key agreement algorithm is an ECJPAKE algorithm
  • the if the first key agreement mode includes the second key agreement mode including: the protocol version parameter of the protocol version field of the first client hello message includes the 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 hello message includes the cipher suite field of the first server feedback message cipher suite parameter; the ciphering curve parameter of the ciphering curve field of the first client hello message includes the ciphering suite parameter of the ciphering suite field of the first server feedback message; and/or, the if The first key agreement mode does not include the second key agreement mode, including: the protocol version parameter of the protocol version field of the first client hello message does not include the first server feedback message.
  • the protocol version parameter of the protocol version field or, the cipher suite parameter of the cipher suite field of the first client hello 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 hello message does not include the encryption suite parameter of the encryption suite field of the first server feedback message.
  • the step of sending the first client hello message is re-executed.
  • FIG. 19 is a schematic diagram showing another optional structure of the data transmission apparatus provided by the embodiment of the present application, which will be described according to each part.
  • the server 1200 includes: a second receiving part 1201 and a second determining part 1202 .
  • the second receiving part 1201 is configured to receive a first client hello message sent by a client, where the first client hello message is used to indicate a first key agreement mode that the client can support;
  • the second determining part 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 transfer.
  • the second receiving part 1201 is configured to receive a second client hello message sent by the client, so The second client hello message is used to indicate the third key agreement mode that the client can support;
  • the second receiving part 1201 is configured to send a second server feedback message based on the second client hello message, where the second server feedback message is used to indicate the fourth key negotiation mode determined by the server;
  • the second determining part 1202 is configured to determine a 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; or, based on the second The third server feedback message sent by the client hello message and disconnect.
  • the first client hello message, the second client hello message, the first server feedback message, and the second server feedback message all include predefined fields, and the predefined fields include: a protocol version at least one of fields, encryption suite field, encryption curve field, first public key field and second public key field; the protocol version field is used to indicate part or all supported by the client or the server Protocol version parameter; the cipher suite field is used to indicate part or all of the cipher suite parameters supported by the client or the server; the encryption curve field is used to indicate the part supported by the client or the server or all encryption curve parameters; the first public key field is used to indicate the first public key of the client or the server; the second public key field is used to indicate the first public key of the client or the server Two public keys.
  • the client and the server can apply the first key agreement algorithm and/or the second key agreement algorithm; the first server feedback message includes a request to resend the hello message or the server greeting message.
  • the request to resend the hello message is any one of the first request to resend the hello message, the second request to resend the hello message, the third request to resend the hello message, and the fourth request to resend the hello message
  • the server hello message is any one of a first server hello message and a second server hello message, wherein the first request to resend the hello message is used to apply the first password on the server.
  • the second request to resend the hello message is used for applying the second key agreement algorithm at the server and Sent when the first key agreement mode is supported; and/or, the third request to resend the hello message is used to apply the second key agreement algorithm on the server and does not support the first key agreement Sent in the case of a key agreement mode; and/or, the fourth request retransmission hello message is used when the service applies the first key agreement algorithm and supports the first key agreement mode, but does not Sent when the first public key is supported; the first server hello message is used when the server applies the second key agreement algorithm and supports the first key agreement mode and/or, the second server hello message is used for sending when the server applies the first key agreement algorithm and supports the first key agreement mode.
  • the first key agreement algorithm is an ECDH algorithm
  • the second key agreement algorithm is an ECJPAKE algorithm
  • This application provides an embodiment to transmit data after security authentication is performed between the client and the server.
  • security authentication For example, in Bluetooth point-to-point transmission, a shared key is generated through security authentication, and then application data is performed (that is, the target data described below)
  • application data is performed (that is, the target data described below)
  • the client and the server must first determine the key agreement mode that both parties can support, such as the same protocol version, the same encryption suite, and the same encryption curve.
  • the message transmitted between the client and the server includes predefined fields, the predefined fields include at least one of a protocol version field, an encryption 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 agreement algorithms, for example, the first public key field is used to store the public key using the ECDH algorithm, and the second public key field is used to store The public key of 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 three public keys corresponding to the ECJPAKE algorithm.
  • a data transmission method is applied to a client (Client) and a server (Server), and the method includes:
  • Step C1 sends a first client hello message (eg Clienthello), where the first client hello message is used to indicate the first key agreement mode that the client can support;
  • a first client hello message eg Clienthello
  • Step S1 receiving a first client hello message sent by a client, where the first client hello message is used to indicate a first key agreement mode that the client can support;
  • the first key agreement mode may include part or all of the key agreement modes that the client can support. That is, each field of the first client hello message carries some or all of the parameters that the client can support.
  • the first client hello message may be understood as the first client hello message (eg Clienthello) sent in this round of negotiation.
  • the first client hello 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 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 absent.
  • the key negotiation mode applicable to the server can be tested, and the negotiation process can be saved, for example, the server supports the ECDH algorithm, Then, the above-mentioned first public key can be directly obtained to improve the negotiation speed.
  • Step S2 determines the 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, the first server feedback message Including request to resend greeting message or server-side greeting message;
  • the request to resend the hello message may be any one of the first request to resend the hello message, the second request to resend the hello message, the third request to resend the hello message, and the fourth request to resend the hello message.
  • the server-side greeting message may be any one of the first server-side greeting message and the second server-side greeting message, wherein,
  • the first request to resend the hello message is sent when the server applies the first key agreement algorithm and does not support the first key agreement mode; and/or,
  • the second request to resend the hello 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 hello message is sent when the server applies the second key agreement algorithm and does not support the first key agreement mode; and/or,
  • the fourth request retransmission hello message is for sending when the service applies the first key agreement algorithm and supports the first key agreement mode, but does not support the first public key; and/ or,
  • the first server hello message is sent when the server applies the first key agreement algorithm and supports the first key agreement mode and the first public key.
  • the first request to resend the hello message includes: a first public key field, where the first public key field is empty;
  • the first request to resend the hello message includes: a first public key field and a second public key field, and both the first public key field and the second public key field are empty;
  • the second request to resend the hello message includes: a second public key field, where the second public key field is the second public key of the server;
  • the second request to resend the greeting message includes: a first public key field and a second public key field, the first public key field is empty, and the second public key field is the second public key field of the server key;
  • the third request to resend the greeting message includes: a second public key field, where the second public key field is empty;
  • the third request to resend the hello message includes: a first public key field and a second public key field, and both the first public key field and the second public key field are empty;
  • the fourth request to resend the hello message includes: a first public key field, where the first public key field is the first public key of the server;
  • the fourth request to resend the greeting message includes: a first public key field and a second public key field, the first public key field is the first public key of the server, and the second public key field is null;
  • the first server hello message includes: a first public key field, where the first public key field is the first public key of the server;
  • the first server hello message includes: a first public key field and a second public key field, the first public key field is the first public key of the server, and the second public key field is empty .
  • the request to resend the greeting message includes a field for storing the public key of the server, and has a first public key field and a second public key field applicable to different key agreement algorithms, which is not only compatible with different key negotiation algorithms.
  • the algorithm can also save the negotiation process and improve the negotiation speed.
  • the server decodes the parameters in it, compares the relevant parameters with the corresponding parameters supported by itself, and determines one of the two parties from the parameters in each field.
  • the parameters supported by both parties are determined, that is, the second key negotiation mode that both parties can support is determined.
  • the server applies the ECDH algorithm, it sends the first server feedback message (such as serverhello).
  • the server passes the first public key.
  • the key field (such as the key share field) sends the public key of the server.
  • the server sends a pair of services through the second public key field (such as the ecjpake_key_kp_pair_list field) of the first server feedback message (such as HelloRetryRequest).
  • the public key of the client if the key negotiation mode supported by both parties cannot be found this time, the server can only choose a second key negotiation mode supported by the server itself, and then send back a message through the first server (such as ecjpake_key_kp_pair_list, applicable In the case of ECDH and ECJPAKE), at this time, since the key agreement mode has not been determined, it is not necessary to carry the corresponding public key of the server.
  • the key negotiation mode supported by the server and the server, but the curve server of the first public key in the first Clienthello does not support it, so the server can send HelloRetryRequest instead of serverhello, and can send the server public through the keyshare field. key.
  • Step C2 obtains a first server feedback message sent by the server based on the first client hello message, the first server feedback message is used to indicate the second key agreement mode determined by the server, and the first server feedback message is used to indicate the second key agreement mode determined by the server.
  • the terminal feedback message includes a request to resend a greeting message or a server-side greeting message;
  • 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.
  • Start the transmission of public keys For example, when the client and the server use the ECJPAKE algorithm, the server sends a pair of public keys to the client (may be sent with a pair of public keys in the ecjpake_key_kp_pair_list field of HelloRetryRequest or serverhello), and the client receives After that, the client's pair of public keys and another public key are sent through the second public key field (such as the ecjpake_key_kp_pair_list field and ecjpake_key_kp_params field) in clienthello, and the server receives it through the second public key field in the server hello message (such as serverhello). ecjpake_key_kp_params field) to send another public key of the server.
  • the second public key field such as the ecjpake_key_kp_p
  • Step C3 determines the shared key of the client, and performs target data transmission through the shared key of the client.
  • 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 first client shared key is determined according to the second key negotiation mode. carry out the target data transfer;
  • a second client hello message is sent, where the second information is used to indicate a third key agreement mode that the client can support ;
  • Step S3 determines the shared key of the server, and performs target data transmission through the shared key of the server.
  • the first server shared key is determined based on the second key negotiation mode, and according to the first server shared key carry out the target data transfer;
  • the first key agreement mode does not include the second key agreement mode, receive a second client hello message sent by the client, where the second client hello message is used to indicate that the client can support The third key agreement mode of ;
  • a third server feedback message is sent and the connection is disconnected.
  • the second client hello message includes the protocol version field, the cipher suite field, the first public key field, the first public key field includes the second public key of the client, and the second public key is used to determine the shared key of the client; and/or,
  • the second client hello message includes the protocol version field, the the cipher suite field and the second public key field, where the second public key field includes the third public key of the client, the third public key being used to determine the shared key of the client; and/or ,
  • the second client hello message includes the protocol version field, the encryption suite field, the encryption curve field.
  • the first key agreement algorithm is the ECDH algorithm
  • the second key agreement algorithm is the ECJPAKE algorithm.
  • the client generates the shared key based on the ECJPKE algorithm according to the public keys of the three clients sent by the server, and the server generates the shared key based on the ECJPKE algorithm according to the three public keys of the server sent by the client;
  • the first public key of the server in the first public key field (such as the key share field) in the message sent by the client is based on the ECDH algorithm to generate the server shared key, and the client sends the first public key field (such as the key share field) in the message through the server.
  • the first public key of the server in the key share field generates the client shared key based on the ECDH algorithm.
  • the first client hello message, the second client hello message, the first server feedback message, and the second server feedback message all include the above-mentioned predefined fields, and the predefined fields include: protocol version at least one of a 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 of the protocol version parameters supported by the client or the server;
  • the cipher suite field is used to indicate some or all of the cipher suite parameters supported by the client or the server;
  • the encryption curve field is used to indicate part or all of the 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
  • the second public key field is used to indicate the second public key of the client or the server
  • the first public key and the second public key correspond to different key agreement algorithms.
  • 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 hello 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 hello 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 hello message includes the encryption suite parameter of the encryption suite field of the first server feedback message
  • the if the first key agreement mode does not include the second key agreement mode including:
  • the protocol version parameter of the protocol version field of the first client hello 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 hello 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 hello message does not include the encryption suite parameter of the encryption suite field of the first server feedback message.
  • the step of sending the first client hello message is re-executed. This improves security by automatically updating the shared key after a certain number or time of use.
  • the server can only send a request to resend a greeting message (such as HelloRetryRequest) once.
  • a greeting message such as HelloRetryRequest
  • the client can send three client greeting messages once.
  • the server sends a maximum of two public keys at a time, because it needs to confirm the PIN code before generating a third public key and sending it separately, which further enhances the security of the entire transmission process.
  • a client comprising:
  • a first sending part configured to send a first client hello message, where the first client hello message is used to indicate a first key agreement mode that the client can support;
  • a first obtaining part configured to obtain a first server feedback message sent by the server based on the first client hello message, where the first feedback information is used to indicate the second key negotiation mode determined by the server,
  • the first server-side feedback message includes a request to resend a greeting message or a server-side greeting message;
  • a first determining part configured to determine the shared key of the client
  • the first transmission part is configured to perform target data transmission through the shared key of the client.
  • a server is provided, and the server includes:
  • the second receiving part is configured to receive a first client hello message sent by the client, where the first client hello message is used to indicate a first key agreement mode that the client can support;
  • a second determining part configured to determine a second key agreement mode selected by the server according to the first key agreement mode
  • the second sending part is configured to send to the client through the first server feedback message, where the first server feedback message includes a request to resend a hello message or a server hello message;
  • the second transmission part is configured to determine the shared key of the server, and perform target data transmission through the shared key of the server.
  • a storage medium stores an executable program, wherein when the executable program is executed by a processor, any one of the above data transmission methods is implemented.
  • An electronic device comprising a memory, a processor, and an executable program stored on the memory and executable by the processor, wherein the processor executes any of the data transmission methods described above when the executable program is executed.
  • the processor may include a data transceiving module.
  • FIG. 20 shows an optional schematic structural diagram of the data transmission apparatus provided by the embodiment of the present application, which will be described according to each part.
  • the data transmission apparatus 1400 includes: a negotiation part 1401 and an application data part 1402 .
  • the negotiation part 1401 is configured to negotiate a key with the second end through a handshake message
  • an application data part 1402 configured to transmit application data with the second end through a content message, the content message being encrypted and decrypted by using the shared key;
  • the handshake message and the content message have the same message format, and the message format includes: a message sequence number and a message payload; the message sequence number includes a key generation identifier and a message count identifier, wherein the key generation number
  • the identifier is characterized by bit information less than the first number of digits, and the message count identifier is characterized by the bit information of less than the second number of digits.
  • the message payload includes actual data and a message type including padding type, application data type, alert type, and handshake type.
  • the data transmission device 1400 further comprises: an encryption part 1403;
  • the encryption part 1403 is configured to encrypt the message payload in the content message by using the shared key.
  • the data transmission apparatus 1400 further includes: a checking part 1404;
  • the verification part 1404 is configured to verify the handshake message to obtain a verification value during the process of negotiating the shared key.
  • the handshake message includes a handshake complete message for instructing to complete the negotiation process of the shared key, wherein the handshake complete message carries the check value.
  • the handshake message includes at least one of the following: a handshake greeting message, a handshake response message, a resend request message, an authentication data message, and a handshake complete message.
  • the message payload of the handshake hello message, the handshake response message, and the retransmission request message includes at least one or more of the following fields: a protocol version field, a cipher suite field, a shared key field, an encryption Curve field.
  • the key algebraic identifier is a ;
  • the key algebra is identified as a+1; the first end passes the content
  • 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.
  • a message payload of the handshake hello message or the handshake response message includes a public key list field, and the value of the public key list field is NULL, and the NULL value is used to determine the Whether the second end supports the target cipher suite.
  • the second end returns the retransmission request message based on the handshake hello message, wherein the cipher suite field in the retransmission request message is configured as the target cipher suite.
  • 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.
  • FIG. 21 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present 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 through a bus system 1305 .
  • the bus system 1305 is used to implement the connection communication between these components.
  • the bus system 1305 also includes a power bus, a control bus, and a status signal bus.
  • the various buses are labeled as bus system 1305 in FIG. 15 .
  • the electronic device may be a hardware structure corresponding to a client or a server.
  • the memory 1302 may be either volatile memory or non-volatile memory, and may include both volatile and non-volatile memory.
  • the non-volatile memory can be ROM, Programmable Read-Only Memory (PROM, Programmable Read-Only Memory), Erasable Programmable Read-Only Memory (EPROM, Erasable Programmable Read-Only Memory), Electrically Erasable Programmable Read-Only Memory Programmable read-only memory (EEPROM, Electrically Erasable Programmable Read-Only Memory), magnetic random access memory (FRAM, ferromagnetic random access memory), flash memory (Flash Memory), magnetic surface memory, optical disk, or CD-ROM -ROM, Compact Disc Read-Only Memory); magnetic surface memory can be disk memory or tape memory.
  • RAM Random Access Memory
  • SRAM Static Random Access Memory
  • SSRAM Synchronous Static Random Access Memory
  • DRAM Dynamic Random Access Memory
  • SDRAM Synchronous Dynamic Random Access Memory
  • DDRSDRAM Double Data Rate Synchronous Dynamic Random Access Memory
  • ESDRAM Double Data Rate Synchronous Dynamic Random Access Memory
  • ESDRAM Enhanced Type Synchronous Dynamic Random Access Memory
  • SLDRAM Synchronous Link Dynamic Random Access Memory
  • DRRAM Direct Rambus Random Access Memory
  • DRRAM Direct Rambus Random Access Memory
  • the memory 1302 in this embodiment of the present application is used to store various types of data to support the operation of the client or the server 1300 .
  • Examples of such data include: any computer program, such as application program 1322, used to operate on client or server 1300.
  • a program for implementing the methods of the embodiments of the present application may be included in the application program 1322 .
  • the methods disclosed in the embodiments of the present application may be applied to the processor 1301 or implemented by the processor 1301 .
  • the processor 1301 may be an integrated circuit chip with signal processing capability. In the implementation process, each step of the method can be completed by an integrated logic circuit of hardware in the processor 1301 or an instruction in the form of software.
  • the processor 1301 may be a general-purpose processor, a digital signal processor (DSP, Digital Signal Processor), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like.
  • DSP Digital Signal Processor
  • the processor 1301 may implement or execute the methods, steps, and logical block diagrams disclosed in the embodiments of this application.
  • a general purpose processor may be a microprocessor or any conventional processor or the like.
  • the steps of the method disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor.
  • the software module may be located in a storage medium, and the storage medium is located in the memory 1302, and the processor 1301 reads the information in the memory 1302, and completes the steps of the foregoing method in combination with its hardware.
  • the client or server 1300 may be implemented by one or more Application Specific Integrated Circuit (ASIC, Application Specific Integrated Circuit), DSP, Programmable Logic Device (PLD, Programmable Logic Device), complex programmable logic A device (CPLD, Complex Programmable Logic Device), FPGA, general-purpose processor, controller, MCU, MPU, or other electronic component implementation for performing the aforementioned method.
  • ASIC Application Specific Integrated Circuit
  • DSP Digital Signal processor
  • PLD Programmable Logic Device
  • CPLD Complex Programmable Logic Device
  • FPGA general-purpose processor
  • controller MCU, MPU, or other electronic component implementation for performing the aforementioned method.
  • Embodiments of the present application further provide a storage medium for storing a computer program.
  • the storage medium may be applied to the first client in the embodiment of the present application, and the computer program enables the computer to execute the corresponding processes in each method of the embodiment of the present application, which is not repeated here for brevity.
  • These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means, the instructions
  • the apparatus implements the functions specified in the flow or flow of the flowcharts and/or the block or blocks of the block diagrams.
  • the data transmission method, client, server, and storage medium provided in the embodiments of the present application send a first client hello message, where the first client hello message includes first information, and the first information is used to indicate the The first key negotiation mode that the client can support; obtain the first server feedback message sent by the server based on the first client hello message, and the first feedback information is used to indicate the second determined by the server.
  • the first server feedback message includes a request to resend a hello message or a server hello message; if the first key agreement mode includes the second key agreement mode, based on the second key agreement
  • the key agreement mode determines the shared key of the first client, and performs target data transmission according to the shared key of the first client. In this way, the key negotiation mode can be flexibly determined, the shared key negotiation can be performed, and the target data can be transmitted through the negotiated shared key.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开一种数据传输方法，应用于客户端，包括：发送第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一服务端反馈消息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。本申请还公开了一种数据传输装置及存储介质；通过本申请实施例提供的数据传输方法、客户端、服务器及存储介质，可以实现密钥协商模式的灵活确定。

Description

一种数据传输方法、客户端、服务端及存储介质
相关申请的交叉引用
本申请要求在2020年08月31日提交中国专利局、申请号为202010900055.3、申请名称为“一种数据传输方法、客户端、服务端及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信安全技术领域，尤其涉及一种数据传输方法、客户端、服务端及存储介质。
背景技术
物联网设备在进行数据传输之前，考虑到数据传输的安全因素，客户端与服务端需要先通过交互的方式协商共享密钥，进而通过共享密钥进行数据传输。因此，如何协商共享密钥，是需要解决的技术问题。
发明内容
本申请实施例提供一种数据传输方法、客户端、服务端及存储介质，可以灵活地确定密钥协商模式，进而协商共享密钥，进行数据传输。
本申请实施例的技术方案是这样实现的：
第一方面，本申请实施例提供一种数据传输方法，应用于客户端(Client)，包括：
发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式；
获取服务端(Server)基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
第二方面，本申请实施例提供一种数据传输方法，应用于服务端，包括：
接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端；
若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输。
第三方面，本申请实施例提供一种客户端，所述客户端包括：
第一发送部分，配置为发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式；
第一获取部分，配置为获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
第一确定部分，若所述第一密钥协商模式包括所述第二密钥协商模式，配置为基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
在一些实施例中，若所述第一密钥协商模式不包括所述第二密钥协商模式，则所述第一发送部分，配置为发送第二客户端问候消息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式；
所述第一获取部分，配置为获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息，所述第二反馈信息用于指示所述服务端确定的第四密钥协商模式；
所述第一确定部分，配置为基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；
所述第一获取部分，配置为获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接；或者，获取所述服务端基于所述第二客户端问候消息发送的第三服务端反馈消息，基于所述第三服务端反馈消息发送第二警告消息并断开连接。
在一些实施例中，所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥。
在一些实施例中，所述第一客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段、所述加密曲线字段和所述第二公钥字段，其中，所述第一公钥字段包括所述客户端的第一公钥；所述第二公钥字段为空；和/或，当所述客户端和所述服务端适用第一密钥协商算法时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字 段、所述第一公钥字段，所述第一公钥字段包括所述客户端的第二公钥；和/或，当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第二公钥字段，所述第二公钥字段包括所述客户端的第三公钥；和/或，当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端不支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述加密曲线字段。
在一些实施例中，所述第一密钥协商算法为椭圆曲线迪菲-赫尔曼(Elliptic-curve Diffie–Hellman，ECDH)算法，所述第二密钥协商算法为密码验证的密钥交换(Password Authenticated Key Exchange by Juggling Over Elliptic Curve，ECJPAKE)算法。
在一些实施例中，所述若所述第一密钥协商模式包括所述第二密钥协商模式，包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；和/或，所述若所述第一密钥协商模式不包括所述第二密钥协商模式，包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数不包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；或者，所述第一客户端问候消息的所述加密套件字段的加密套件参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；或者，所述第一客户端问候消息的所述加密曲线字段的加密曲线参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
第四方面，本申请提供一种服务端，所述服务端包括：
第二接收部分，配置为接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
第二确定部分，配置为根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端；或者，若所述第一密钥协商模式包括所述第二密钥协商模式，配置为基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输。
在一些实施例中，若所述第一密钥协商模式不包括所述第二密钥协商模式，所述第二接收部分，配置为接收所述客户端发送第二客户端问候消息，所述第二客户端问候消息用于指示所述客户端能够支持的第三密钥协商模式；
第二接收部分，配置为基于所述第二客户端问候消息发送第二服务端反馈消息，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式；
所述第二确定部分，配置为基于所述第四密钥协商模式确定第二服务端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，基于所述第二客户端问候消息发送的第三服务端反馈消息并断开连接。
在一些实施例中，所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥。
在一些实施例中，所述客户端和所述服务端能够适用第一密钥协商算法和/或第二密钥协商算法；所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息。
在一些实施例中，所述请求重发问候消息为第一请求重发问候消息、第二请求重发问候消息、第三请求重发问候消息、第四请求重发消息中的任一种，所述服务端问候消息为第一服务端问候消息、第二服务端问候消息中的任一种，其中，所述第一请求重发问候消息用于在所述服务端适用所述第一密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，所述第二请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且支持所述第一密钥协商模式的情况下发送的；和/或，所述第三请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，所述第四请求重发问候消息用于在所述服务适用所述第一密钥协商算法且支持第一密钥协商模式，但不支持所述第一公钥的情况下发送的；所述第一服务端问候消息用于在所述服务端适用所述第二密钥协商算法且支持所述第一密钥协商模式的情况下发送；和/或，所述第二服务端问候消息用于在所述服务端适用所述第一密钥协商算法且支持所述第一密钥协商模式的情况下发送的。
在一些实施例中，所述第一密钥协商算法为ECDH算法，所述第二密钥协商算法为ECJPAKE算法。
本申请实施例提供的数据传输方法、客户端、服务端及存储介质，发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式；获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。如此，可以灵活地确定密钥协商模式，进行共享密钥协商，进而通过协商的共享密钥传输目标数据。
附图说明
图1为相关技术中基于ECDH的配网协议的流程示意图；
图2为相关技术中基于ECJPAKE的配网协议的流程示意图；
图3为本申请实施例提供的数据传输方法的客户端侧的一种可选流程示意图；
图4为本申请实施例提供的使用ECDH的配网协议协商共享密钥的可选流程示意图；
图5为本申请实施例提供的使用ECDH的配网协议协商共享密钥的详细处理流程示意图；
图6为本申请实施例提供的使用ECJPAKE的配网协议协商共享密钥的可选流程示意图；
图7为本申请实施例提供的使用ECJPAKE的配网协议协商共享密钥的详细处理流程示意图；
图8为本申请实施例提供的数据传输方法的服务端侧的一种可选流程示意图；
图9为本申请实施例提供的数据传输方法的一种可选流程示意图；
图10为本申请实施例提供的数据传输方法的一种详细处理流程示意图；
图11为本申请实施例提供的数据传输方法的又一种可选流程示意图；
图12为本申请实施例提供的数据传输方法的又一种详细处理流程示意图；
图13为本申请实施例提供的数据传输方法的再一种可选流程示意图；
图14为本申请实施例提供的数据传输方法的再一种详细处理流程示意图；
图15为本申请实施例提供的数据传输方法的还一种可选流程示意图；
图16为本申请实施例提供的数据传输方法的另一种可选流程示意图；
图17为本申请实施例提供的客户端与服务端传输的消息的内容的可选结构示意图；
图18为本申请实施例提供的客户端的一种可选结构示意图；
图19为本申请实施例提供的服务端的一种可选结构示意图；
图20为本申请实施例提供的数据传输装置的一种可选结构示意图；
图21为本申请实施例的电子设备的硬件组成结构示意图。
具体实施方式
以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
物联网设备在进行功能层面的操作前，出于安全的考虑，往往需要先经过配置，所谓配置，就是通过交互的方式以验证双方身份，并在此过程产生用于数据加密的密钥，由于大部分物联网(Internet of Things，IoT)设备具备通过无线技术，如WiFi、蓝牙低能耗(Bluetooth Low Energy，BLE)等，进行连接的能力，设备配置后才可以在当前无线网络进行通讯，故将此过程称为配网。
目前有两种主流配网协议，基于ECDH与ECJPAKE的配网协议，大致流程如图1和图2所示。
图1示出了相关技术中基于ECDH的配网协议的流程示意图。
如图1所示，在第一客户端与服务端建立连接后，分别生成相应的密钥对，然后基于交互的公钥产生共享密钥，在产生共享密钥后即可认为配网完成，进行应用层数据的传输(用共享密钥进行对称加密)。
图2示出了相关技术中基于ECJPAKE的配网协议的流程示意图。
如图2所示，在第一客户端与服务端建立连接，进入握手阶段交换公钥，产生共享密钥，在产生共享密钥后即可认为配网完成，进行应用层数据的传输(用共享密钥进行对称加密)。
但是，在相关技术中基于ECDH的配网协议或者基于ECJPAKE的配网协议，设备的支持不够灵活、全面，同时，目前的标准流程交互过程中数据量高，对BLE设备而言负担大。
随着人们对安全、隐私的意识越来越高，安全技术在物联网产品中显得愈发重要，通常在BLE设备端的做法是，根据BLE设备的安全等级执行不同的协商流程，具体包括：
(1)低安全等级：随机数提供不可预测性，对称密钥，对称加、解密(AES-128)；
(2)高安全等级：随机数提供不可预测性，非对称密钥交换(ECDH密钥交换)，对消息进行对称加、解密(AES-128)，在消息头加消息序列号用于防重放，证书认证身份。
此外，申请人还发现对于有个人识别密码(Personal Identification Number，PIN)码的设备，PIN码本身的保护程度不够，容易发生泄露，另外密钥一旦产生将会在整个生命周期使用，没有更新机制。
基于安全通信方法中存在的问题，本申请提出一种数据传输方法，能够解决现有技术方案中无法解决的技术难题和缺点。
图3示出了本申请实施例提供的数据传输方法的客户端侧的一种可选流程示意图，将根据各个步骤进行说明。
步骤S101，发送第一客户端问候消息。
在一些实施例中，所述客户端向服务端发送第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式。
在一些实施例中，所述客户端向服务端发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式。
在一些实施例中，所述第一密钥协商模式包括使用ECDH的配网协议协商密钥和/或使用ECJPAKE的配网协议协商密钥。
在一些实施例中，所述第一信息包括第一加密套件集合；所述第一加密套件集合包括所述客户端能够支持的至少一个加密套件的集合。
在另一些实施例中，所述第一客户端问候消息还可以包括：加密套件字段；所述加密套件字段用于指示所述客户端支持的部分或全部加密套件参数。
在一些实施例中，所述第一信息还可以包括第一加密曲线集合；所述第一加密曲线集合包括所述客户端能够支持的至少一个加密曲线的集合。
在另一些实施例中，所述第一客户端问候消息还可以包括：加密曲线字段；所述加密曲线字段用于指示所述客户端支持的部分或全部加密曲线参数。
在一些实施例中，所述第一客户端问候消息还包括：第一公钥，所述第一公钥包括：在所述客户端能够支持ECDH的配网协议的情况下，所述第一加密套件集合中任一个加密套件和/或所述第一加密曲线集合中任一个加密曲线确定的公钥。不同加密套件和/或加密曲线确定的公钥不同。
在一些实施例中，所述第一客户端问候消息还包括：第一协议标识集合，所述第一协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第一协议标识集合指示所述客户端支持的协议版本的集 合。
在另一些实施例中，所述第一客户端问候消息还可以包括：协议版本字段；所述协议版本字段用于指示所述客户端支持的部分或全部协议版本参数。
在一些实施例中，所述第一客户端问候消息还包括：第一公钥列表，所述第一客户端问候消息的第一公钥列表为NULL。
步骤S102，获取服务端基于所述第一客户端问候消息发送的第一反馈信息。
需要说明的是，本申请实施例中的客户端(client)是指主动发起连接的设备(或APP)，也可以是指本申请中的主动连接端；连接时，客户端向服务端(server)证明自己的控制权。服务端(server)是指被动连接的设备，也可以是指本申请中的被动连接端；连接时，服务端认证客户端的身份，验证客户端具有控制权。客户端和服务端可以是服务器、终端设备、“电视”、“音箱”等物联网(Internet of Things，IoT)设备等，客户端与服务端之间的连接可以是通过有线网络建立的连接，也可以是通过无线网络建立的连接，还可以是通过可移动的网络建立的连接。
在一些实施例中，所述客户端可以是主动连接端，所述客户端可以是蓝牙低功耗设备，也可以是如手持终端、可穿戴终端、个人笔记本、平板电脑等电子设备；所述服务端可以是被动连接端，所述服务端可以是蓝牙低功耗设备，如应用于监控护理领域的血压测量装置、温度测量装置、血糖监测装置；或应用于运动和健身领域的健身器材传感器、心律测量装置、定位装置、测速装置、测重装置；或应用于智能家居领域的开关装置、照明装置、智能门锁、电动窗帘、扫地机器人等。在一些实施例中，所述客户端获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息；所述第一服务端反馈消息包括第一反馈信息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式。
在一些实施例中，在满足所述第一客户端问候消息中包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合包括所述服务端支持的至少一个加密曲线或所述第一客户端问候消息包括的第一协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识，且所述服务端确定第二密钥协商模式为使用ECDH的配网协议协商密钥的情况下，所述第一反馈信息包括以下至少一种：第一加密套件、第一加密曲线、第一协议标识和第二公钥；所述第一加密套件集合包括所述第一加密套件，所述第一加密套件包括所述服务端支持的至少一个加密套件中任一个加密套件；所述第一加密曲线集合包括所述第一加密曲线，所述第一加密曲线包括所述服务端支持的至少一个加密曲线中任一个加密曲线；所述第一协议标识集合包括所述第一协议标识，所述第一协议标识包括所述服务端支持的至少一个协议版本中任一个协议版本对应的协议标识。所述第二公钥基于所述第一加密套件、第一加密曲线和第一协议标识中至少一种确定。在另一些实施例中，在满足所述第一客户端问候消息中包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合包括所述服务端支持的至少一个加密曲线或所述第一客户端问候消息包括的第一协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识，且所述服务端确定第二密钥协商模式为使用ECJPAKE的配网协议协商密钥的情况下，所述第一反馈信息包括：第一加密套件、第一加密曲线、第一协议标识和第一公钥列表；所述第一加密套件集合包括所述第一加密套件，所述第一加密套件包括所述服务端支持的至少一个加密套件中任一个加密套件；所述第一加密曲线集合包括所述第一加密曲线，所述第一加密曲线包括所述服务端支持的至少一个加密曲线中任一个加密曲线；所述第一协议标识集合包括所述第一协议标识，所述第一协议标识包括所述服务端支持的至少一个协议版本中任一个协议版本对应的协议标识。所述第二公钥基于所述第一加密套件、第一加密曲线和第一协议标识中至少一种确定。所述第一公钥列表包括服务端向客户端发送的，用于确定第一客户端共享密钥的公钥对。
在一些实施例中，在满足以下至少一种情况：所述第一客户端问候消息中包括的第一加密套件集合中不包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合不包括所述服务端支持的至少一个加密曲线或所述第一客户端问候消息包括的第一协议标识集合中不包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述第一反馈信息包括：第二加密套件、第二加密曲线和第二协议标识。所述第一加密套件集合不包括所述第二加密套件，所述第二加密套件包括所述服务端支持的至少一个加密套件中任一个加密套件；所述第一加密曲线集合不包括所述第二加密曲线，所述第二加密曲线包括所述服务端支持的至少一个加密曲线中任一个加密曲线；所述第一协议标识集合部包括所述第二协议标识，所述第二协议标识包括所述服务端支持的至少一个协议版本中任一个协议版本对应的协议标识。
例如，在所述第一加密套件集合中不包括所述服务端支持的加密套件、所述第一加密曲线集合中不包括所述服务端支持的曲线，且所述第一协议标识集合中不包括所述服务端支持的协议版本对应的协议标识的情况下，所述第一反馈信息包括所述服务端根据所述服务端自身性能确定的第二加密套件、第二加密曲线和第二协议标识。
或者，在所述第一加密套件集合中包括所述服务端支持的加密套件、所述第一加密曲线集合不包括所述服务端支持的加密曲线，且所述第一协议标识集合中不包括所述服务端支持的协议版本对应的协议标识的情况下，所述第一反馈信息包括所述服务端根据所述服务端自身性能确定的第二加密曲线和第二协议标识，以及所述服务端基于所述第一客户端问候消息确定的第一加密套件。
步骤S103，若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
在一些实施例中，在所述第一密钥协商模式包括所述第二密钥协商模式的情况下，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
在一些实施例中，所述第一密钥协商模式包括所述第二密钥协商模式包括：所述第一加密套件集合中包括所述第一加密套件、所述第一加密曲线集合包括所述第一加密曲线、所述第一协议标识集合中包括所述第一协议标识的情况下，所述第一密钥协商模式包括所述第一服务端反馈消息中携带的第一加密套件、第一加密曲线和第一协议标识对应的第二密钥协商模式。
在另一些实施例中，所述第一密钥协商模式包括所述第二密钥协商模式，还可以包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
在一些实施例中，基于所述第二密钥协商模式确定第一客户端共享密钥包括情景1和情景2，将在后续实施例中进行 详细说明。
在一些实施例中，所述情景1包括：所述第二密钥协商模式为使用ECDH的配网协议协商密钥；进一步，所述基于所述第二密钥协商模式确定第一客户端共享密钥包括：使用ECDH的配网协议协商密钥。
在一些实施例中，所述情景2包括所述第二密钥协商模式为ECJPAKE的配网协议。进一步，所述基于所述第二密钥协商模式确定第一客户端共享密钥包括：使用ECJPAKE的配网协议协商密钥。
步骤S104，若所述第一密钥协商模式不包括所述第二密钥协商模式，则发送第二客户端问候消息。
在一些实施例中，所述第一密钥协商模式不包括所述第二密钥协商模式，包括：所述第一客户端问候消息包括的第一加密套件集合中不包括所述第一服务端反馈消息中携带的第二加密套件；或者，所述第一客户端问候消息包括的第一加密曲线集合不包括所述第一反馈信息中携带的第二加密曲线；或者，所述第一客户端问候消息包括的第一协议标识集合中不包括所述第一反馈信息中携带的第二协议标识。即所述第一密钥协商模式不包括所述第一服务端反馈消息中携带的加密套件、加密曲线和协议标识对应的第二密钥协商模式。
在一些实施例中，所述客户端发送第二客户端问候消息包括：所述客户端向服务端发送第二客户端问候消息，所述第二客户端问候消息包括第二信息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式。
在一些实施例中，所述第二信息包括所述客户端能够支持的第二加密套件集合和/或所述客户端能够支持的第二加密曲线集合。所述第一加密套件集合中包括的至少一个加密套件与所述第二加密套件集合中包括的至少一个加密套件完全不相同；所述第一加密曲线集合中包括的至少一个加密曲线与所述第二加密曲线集合中包括的至少一个加密曲线完全不相同。
在一些实施例中，所述第二客户端问候消息还包括：第四公钥，所述第四公钥包括：在所述客户端能够支持ECDH的配网协议的情况下，所述第二加密套件集合中任一个加密套件和/或所述第二加密曲线集合中任一个加密曲线确定的公钥。
在一些实施例中，所述第二客户端问候消息还包括：第二协议标识集合，所述第二协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第二协议标识集合指示所述客户端支持的协议版本的集合。
在一些实施例中，所述第二客户端问候消息还包括：第二公钥列表，所述第二客户端问候消息的第二公钥列表为NULL。
在一些实施例中，在所述服务端能够支持所述第三密钥协商模式的情况下，执行步骤S105；在所述服务端不能支持所述第三密钥协商模式的情况下，执行步骤S107。
步骤S105，获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息。
在一些实施例中，所述客户端获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息，所述第二服务端反馈消息包括第二反馈信息，所述第二反馈信息用于指示所述服务端确定的第四密钥协商模式的具体步骤流程与步骤S102相似，此处不再重复赘述。
步骤S106，基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输。
在一些实施例中，基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输的具体步骤流程与步骤S103相似，此处不再重复赘述。
步骤S107，获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接。
在一些实施例中，所述客户端获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接。
在一些实施例中，所述服务端接收所述第二客户端问候消息，并确定所述服务端不支持所述第二加密套件集合中包括的至少一个加密套件；或者所述服务端不支持所述第二加密曲线集合中包括的至少一个加密曲线；或者所述服务端不支持所述第二协议标识集合中包括的至少一个协议标识对应的协议版本的情况下，所述服务端向所述客户端发送第一警告消息，所述第一警告消息用于指示断开所述客户端与所述服务端之间的连接。
在一些实施例中，所述方法还包括：步骤S108，发送第二警告消息。
在一些实施例中，在所述客户端接收到的第一服务端反馈消息中，所述第一服务端反馈消息中包括2个以上加密曲线或者2个以上加密套件或者2个以上版本标识的情况下，所述客户端向服务端发送第二警告消息，并断开与服务端之间的连接；所述第二警告消息用于指示断开所述客户端和服务端之间的连接。在所述第一服务端反馈消息中包括2个以上加密曲线或者2个以上加密套件或者2个以上版本标识的情况下，说明所述客户端受到第三方的恶意攻击，或者服务端出现错误，所述客户端发送第二警告消息并断开与服务端之间的连接。
在另一些实施例中，在所述客户端接收到的第二服务端反馈消息中，所述第二服务端反馈消息中包括2个以上加密曲线或者2个以上加密套件或者2个以上版本标识的情况下，所述客户端向服务端发送第二警告消息，并断开与服务端之间的连接；所述第二警告消息用于指示断开所述客户端和服务端之间的连接。
如此，本申请实施例提供一种灵活的数据传输方式，对于性能较差且对安全要求不高的客户端，使用ECDH的配网协议进行数据传输；对于性能较好且对安全要求高的客户端，使用ECJPAKE的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，对于安全级别要求高的客户端，将客户端的PIN码与传输流程结合，提升了PIN码破解的难度，提升了数据传输的安全性。此外，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图4示出了本申请实施例提供的使用ECDH的配网协议协商共享密钥的可选流程示意图；图5示出了本申请实施例提供的使用ECDH的配网协议协商共享密钥的详细处理流程示意图，将结合图4、图5进行说明。
本实施例对应步骤S103中的情景1。
在一些实施例中，所述客户端基于步骤S102，从所述服务端获取所述第一服务端反馈消息，并基于所述第一反馈信息确定第二密钥传输模式为使用ECDH的配网协议协商共享密钥的情况下，若所述客户端在确定所述第二公钥的第一加密曲线与确定所述第一公钥的加密曲线不相同，执行步骤S200；若所述客户端在确定所述第二公钥的第一加密曲线与确定所述第一公钥的加密曲线相同，执行步骤S201。
步骤S200，客户端向服务端发送第三客户端问候消息。
在一些实施例中，所述第三客户端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第三客户端问候消息还可以包括：第三公钥；所述第三公钥基于所述第一加密套件和/或第一加密曲线确定。
在另一些实施例中，所述第三客户端问候消息还可以包括：第三公钥与第一随机序列组合形成的第一数字序列。所述第一随机序列由所述客户端随机生成。
例如，所述第三公钥可以包括：####，所述第一随机序列可以包括******(所述第一随机序列可以是数字、大小写字母、符号组成的随机序列)，所述数字序列可以包括**####****。所述第一随机序列可以只有所述客户端知晓，用于增加第一公钥传输的复杂度，防止所述第一数字序列被第三方截取后，基于所述第一数字序列获得所述第一公钥；所述第一随机序列不参与所述第一密钥的确定；所述服务端接收所述第一数字序列后，去除所述第一数字序列中的第一随机序列，获取所述第三公钥，进而确定所述第一密钥。
在一些实施例中，如图5所示，所述第三客户端问候消息通过ClientHello信息发送至所述服务端。
步骤S201，所述客户端基于第二公钥确定第一密钥。
在一些实施例中，所述客户端基于第二公钥确定第一密钥包括：所述客户端基于所述第一服务端反馈消息中的第二公钥确定第一密钥。所述第二客户端去除所述第一服务端反馈消息中，所述服务端产生的第二随机序列，获取所述第二公钥，并基于所述第二公钥确定所述第一密钥。
在一些实施例中，所述基于第二公钥确定第一密钥的方法与相关技术中，基于公钥确定密钥的方法相同，此处不再重复赘述。
在一些实施例中，如图5所示，所述第一服务端反馈消息通过ServerHello消息发送至所述服务端。
步骤S202，服务端基于第一公钥或第三公钥确定第一密钥。
在一些实施例中，在确定所述第二公钥的第一加密曲线与确定所述第一公钥的加密曲线相同的情况下，所述服务端基于第一客户端问候消息中的第一公钥确定第一密钥。所述服务端去除所述第一客户端问候消息中的随机序列，获取所述第一公钥，并基于所述第一公钥确定所述第一密钥。
在另一些实施例中，在确定所述第二公钥的第一加密曲线与确定所述第一公钥的加密曲线不相同的情况下，所述服务端基于第一数字序列中的第三公钥确定第一密钥。所述服务端去除所述第一数字序列中的第一随机序列，获取所述第三公钥，并基于所述第三公钥确定所述第一密钥。
步骤S203，服务端向客户端发送第一验证信息。
在一些实施例中，所述服务端向所述客户端发送第一验证信息，所述第一验证信息包括所述服务端的证书；所述第一验证信息用于所述客户端验证所述服务端的身份。
在一些实施例中，如图5所示，所述第一验证信息通过Authenticate信息发送至所述客户端。
在一些实施例中，所述第一验证信息可以是X509证书或者是服务端自定义的整数。
步骤S204，服务端向客户端发送第一校验数据。
在一些实施例中，所述服务端向客户端发送第一校验数据，所述第一校验数据包括所述客户端发送和/或接收的每一帧消息的哈希值的集合。例如第一校验数据＝hash(M1||M2||...||Mn)，其中M1，M2……，Mn为所述客户端发送和/或接收的每一帧消息。例如，在本实施例中，客户端向服务端发送第一客户端问候消息、服务端向客户端发送第一服务端反馈消息以及服务端向客户端发送第一验证信息的情况下，所述第一校验数据包括：所述第一客户端问候消息的哈希值、所述第一服务端反馈消息的哈希值以及所述第一验证信息的哈希值。
在一些实施例中，如图5所示，所述第一校验数据通过Finished信息发送至所述客户端。
在另一些实施例中，所述第一校验数据还可以通过：hash(hash(M1||M2||...||Mn))确定。
在一些实施例中，所述第一校验数据可以在所述客户端和服务端交换公钥后发送，包括所述第一客户端发送和/或接收的每一帧消息的哈希值的集合；也可以携带在所述服务端向所述客户端发送的每一条消息中。
在一些实施例中，所述第一校验数据携带在所述服务端向所述客户端发送的每一条消息中包括：所述服务端基于最近接收的消息中携带的第一哈希值，与所述服务端即将向客户端发送消息的第二哈希值，确定第一校验数据。所述第一校验数据可以是所述第一哈希值与所述第二哈希值之和。例如，基于第一客户端问候消息获取所述第一客户端问候消息中的第一哈希值；所述服务端基于第一服务端反馈消息确定的所述第一服务端反馈消息的第二哈希值，所述第一反馈信息中，所述第一客户端问候消息和所述第一服务端反馈消息的哈希值集合包括所述第一哈希值与所述第二哈希值的和；所述第一哈希值与所述第二哈希值长度相同。
步骤S205，客户端向服务端发送第二验证信息。
在一些实施例中，所述客户端向所述服务端发送第二验证信息，所述第二验证信息包括所述客户端的证书；所述第二验证信息用于所述服务端验证所述客户端的身份。
在一些实施例中，如图5所示，所述第二验证信息通过Authenticate信息发送至所述服务端。
步骤S206，客户端向服务端发送第二校验数据。
在一些实施例中，所述客户端向服务端发送第二校验数据，所述第二校验数据包括所述服务端发送和/或接收的每一帧消息的哈希值的集合。例如第二校验数据＝hash(M1||M2||...||Mn)，其中M1，M2……，Mn为所述服务端发送和/或接收的每一帧消息。例如，在本实施例中，客户端向服务端发送第一客户端问候消息、服务端向客户端发送第一服务端反馈消息、服务端向客户端发送第一验证信息、服务端向客户端发送第一校验信息以及客户端向服务端发送第二验证信息的情况下，所述第一校验数据包括：所述第一客户端问候消息的哈希值、所述第一服务端反馈消息的哈希值、所述第一验证信息的哈希值、第二验证信息的哈希值以及第一校验数据的哈希值。
在一些实施例中，如图5所示，所述第二校验数据通过Finished信息发送至所述服务端。
在另一些实施例中，所述第二校验数据还可以通过：hash(hash(M1||M2||...||Mn))获得。
在一些实施例中，所述第二校验数据可以在所述客户端和服务端交换公钥后发送，包括所述第一客户端发送和/或接收的每一帧消息的哈希值的集合；也可以携带在所述客户端向所述服务端发送的每一条消息中。
在一些实施例中，所述第二校验数据携带在所述服务端向所述客户端发送的每一条消息中包括：所述客户端基于最近接收的消息中携带的第三哈希值，与所述客户端即将向服务端发送的消息的第四哈希值，确定第二校验数据。所述第二校 验数据可以是所述第三哈希值与所述第四哈希值之和。例如，基于第一服务端反馈消息获取所述第一客户端问候消息中的第三哈希值；所述客户器基于第三客户端问候消息确定的所述第三客户端问候消息的第四哈希值，所述第三客户端问候消息中，所述第二校验数据包括所述第三哈希值与所述第四哈希值的和；所述第一哈希值与所述第二哈希值长度相同。
如此，本申请实施例提供的数据传输方式，性能较差或对安全性能要求不高的客户端和/或服务端可以使用ECDH的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图6示出了本申请实施例提供的使用ECJPAKE的配网协议协商共享密钥的可选流程示意图；图7示出了本申请实施例提供的使用ECJPAKE的配网协议协商共享密钥的详细处理流程示意图，将结合图6、图7进行说明。
本实施例对应步骤S103中的情景2，所述第二密钥协商模式为使用ECJPAKE的配网协议协商共享密钥。
步骤S301，客户端向服务端发送第三客户端问候消息。
在一些实施例中，所述客户端基于步骤S102，从所述服务端获取所述第一反馈信息，并基于所述第一反馈信息确定第二密钥传输模式为使用ECJPAKE的配网协议协商共享密钥的情况下，所述客户端向所述服务端发送第三客户端问候消息。
在一些实施例中，所述第三客户端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第三客户端问候消息还可以包括：第二公钥列表，所述第二公钥列表包括用于确定第一服务端共享密钥的公钥对。所述第二公钥列表还可以包括所述客户端的PIN码。
在一些实施例中，所述第三客户端问候消息还可以包括：第四公钥。所述第四公钥基于所述第一加密套件和/或第一加密曲线确定。所述第四公钥还可以包括所述客户端的PIN码。
在另一些实施例中，所述第三客户端问候消息还可以包括：第四公钥与第二随机序列组合形成的第二数字序列。所述第二随机序列由所述客户端随机生成。
例如，所述第四公钥可以包括：####，所述第二随机序列可以包括******(所述第二随机序列可以是数字、大小写字母、符号组成的随机序列)，所述第二数字序列可以包括**####****。所述第二随机序列可以只有所述服务端知晓，用于增加第四公钥传输的复杂度，防止所述第二数字序列被第三方截取后，基于所述第二数字序列获得所述第四公钥；所述第二随机序列不参与所述第一密钥的确定；所述服务端接收所述第二数字序列后，去除所述第二数字序列中的第二随机序列，获取所述第四公钥，进而确定所述第一密钥。
在一些实施例中，如图7所示，所述第三客户端问候消息通过ClientHello信息发送至所述服务端。
相应地，所述服务端接收所述第二公钥列表和第四公钥，基于所述第二公钥列表中包括的公钥对与所述第四公钥确定第一密钥。
步骤S302，服务端向客户端第一服务端问候消息。
在一些实施例中，所述第一服务端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第一服务端问候消息还可以包括：第五公钥。所述第五公钥基于所述第一加密套件和/或第一加密曲线确定。所述第五公钥列表还可以包括所述服务端的PIN码。
在另一些实施例中，所述第一服务端问候消息还可以包括：第五公钥与第三随机序列组合形成的第三数字序列。所述第三随机序列由所述服务端随机生成。
在一些实施例中，如图7所示，所述第一服务端问候消息通过ServerHello信息发送至所述客户端。
相应地，所述客户端基于第一服务端反馈消息中第一公钥列表包括的公钥对与所述第五公钥确定第一密钥。
步骤S303，服务端向客户端发送第一校验数据。
在一些实施例中，所述服务端向所述客户端发送第一校验数据，所述第一校验数据包括所述第一客户端发送和/或接收的每一帧消息的哈希值的集合。例如第一校验数据＝hash(M1||M2||...||Mn)，其中M1，M2……，Mn为所述第一客户端发送和/或接收的每一帧消息。例如，在本实施例中，客户端向服务端发送第一客户端问候消息和第三客户端问候消息、服务端向客户端发送第一服务端反馈消息和第一服务端问候消息的情况下，所述第一校验数据包括：所述第一客户端问候消息的哈希值、所述第三客户端问候消息的哈希值、所述第一服务端反馈消息的哈希值以及所述第一服务端问候消息的哈希值。如图7所示，所述第一校验数据通过Finished信息发送至所述第一客户端。
在另一些实施例中，所述第一校验数据还可以通过：hash(hash(M1||M2||...||Mn))获得。
在一些实施例中，所述第一校验数据可以在所述客户端和服务端交换公钥后发送，包括所述第一客户端发送和/或接收的每一帧消息的哈希值的集合；也可以携带在所述服务端向所述客户端发送的每一条消息中。
在一些实施例中，所述第一校验数据携带在所述服务端向所述客户端发送的每一条消息中包括：所述服务端基于最近接收的消息中携带的第一哈希值，与所述服务端即将向客户端发送消息的第二哈希值，确定第一校验数据。所述第一校验数据可以是所述第一哈希值与所述第二哈希值之和。例如，基于第一客户端问候消息获取所述第一客户端问候消息中的第一哈希值；所述服务端基于第一服务端反馈消息确定的所述第一服务端反馈消息的第二哈希值，所述第一反馈信息中，所述第一校验数据包括所述第一哈希值与所述第二哈希值的和；所述第一哈希值与所述第二哈希值长度相同。
步骤S304，客户端向服务端发送第二校验数据。
在一些实施例中，所述客户端向服务端发送第二校验数据，所述第二校验数据包括所述服务端发送和/或接收的每一帧消息的哈希值的集合。例如第二校验数据＝hash(M1||M2||...||Mn)，其中M1，M2……，Mn为所述服务端发送和/或接收的每一帧消息。例如，在本实施例中，客户端向服务端发送第一客户端问候消息、服务端向客户端发送第一服务端反馈消息、服务端向客户端发送第一验证信息、服务端向客户端发送第一校验信息以及客户端向服务端发送第二验证信息的情况下，所述第一校验数据包括：所述第一客户端问候消息的哈希值、所述第一服务端反馈消息的哈希值、所述第一验证信息的哈希值、第二验证信息的哈希值以及第一校验数据的哈希值。
在一些实施例中，如图7所示，所述第二校验数据通过Finished信息发送至所述服务端。
在另一些实施例中，所述第二校验数据还可以通过：hash(hash(M1||M2||...||Mn))获得。
在一些实施例中，所述第二校验数据可以在所述客户端和服务端交换公钥后发送，包括所述第一客户端发送和/或接收的每一帧消息的哈希值的集合；也可以携带在所述客户端向所述服务端发送的每一条消息中。
在一些实施例中，所述第二校验数据携带在所述服务端向所述客户端发送的每一条消息中包括：所述客户端基于最近接收的消息中携带的第三哈希值，与所述客户端即将向服务端发送的消息的第四哈希值，确定第二校验数据。所述第二校验数据可以是所述第三哈希值与所述第四哈希值之和。例如，基于第一服务端反馈消息获取所述第一客户端问候消息中的第三哈希值；所述客户器基于第三客户端问候消息确定的所述第三客户端问候消息的第四哈希值，所述第三客户端问候消息中，所述第二校验数据包括所述第三哈希值与所述第四哈希值的和；所述第一哈希值与所述第二哈希值长度相同。
如此，本申请实施例提供一种灵活的数据传输方式，对于性能较好且对安全要求高的终端设备，使用ECJPAKE的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，终端设备或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，对于安全级别要求高的终端设备，将终端设备的PIN码与传输流程结合，提升了PIN码破解的难度，提升了数据传输的安全性。此外，本申请实施例中，所述终端设备和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图8示出了本申请实施例提供的数据传输方法的服务端侧的一种可选流程示意图，将根据各个步骤进行说明。
步骤S401，接收客户端发送的第一客户端问候消息。
在一些实施例中，所述服务端接收客户端发送的第一客户端问候消息。所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式。
在一些实施例中，所述第一密钥协商模式包括使用ECDH的配网协议协商密钥和/或使用ECJPAKE的配网协议协商密钥。
在一些实施例中，所述第一信息包括第一加密套件集合；所述第一加密套件集合包括所述客户端能够支持的至少一个加密套件的集合。
在另一些实施例中，所述第一客户端问候消息还可以包括：第一加密套件字段；所述加密套件字段用于指示所述客户端支持的部分或全部加密套件参数。
在一些实施例中，所述第一信息还可以包括第一加密曲线集合；所述第一加密曲线集合包括所述客户端能够支持的至少一个加密曲线的集合。
在另一些实施例中，所述第一客户端问候消息还可以包括：第一加密曲线字段；所述加密曲线字段用于指示所述客户端支持的部分或全部加密曲线参数。
在一些实施例中，所述第一客户端问候消息还包括：第一公钥，所述第一公钥包括：在所述客户端能够支持ECDH的配网协议的情况下，所述第一加密套件集合中任一个加密套件和/或所述第一加密曲线集合中任一个加密曲线确定的公钥。不同加密套件和/或加密曲线确定的公钥不同。
在一些实施例中，所述第一客户端问候消息还包括：第一协议标识集合，所述第一协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第一协议标识集合指示所述客户端支持的协议版本的集合。
在另一些实施例中，所述第一客户端问候消息还可以包括：协议版本字段；所述协议版本字段用于指示所述客户端支持的部分或全部协议版本参数。
在一些实施例中，所述第一客户端问候消息还包括：第一公钥列表，所述第一客户端问候消息的第一公钥列表为NULL。
步骤S402，根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端。
在一些实施例中，服务端根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式包括：所述服务端基于所述第一客户端问候消息中携带的第一加密套件集合包括的至少一个加密套件、第一加密曲线集合中包括的至少一个加密曲线和第一协议标识集合中包括的至少一个协议版本对应的协议标识，确定所述服务端支持的第二密钥模式。
在一些实施例中，在所述第一客户端问候消息中包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合包括所述服务端支持的至少一个加密曲线，且所述第一客户端问候消息包括的第一协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端确定所述第二密钥协商模式对应的第一加密套件、第一加密曲线和第一协议标识，并通过第一服务端反馈消息发送给所述客户端。在所述服务端确定第二密钥协商模式为使用ECDH的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第二公钥，所述第二公钥基于所述第一加密套件、第一加密曲线和第一协议标识中至少一种确定；或者，在所述服务端确定第二密钥协商模式为使用ECJPAKE的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第一公钥列表，所述第一公钥列表包括服务端向客户端发送的，用于确定第一客户端共享密钥的公钥对。所述第一公钥列表还可以包括所述服务端的PIN码。
在另一些实施例中，在所述第一客户端问候消息中不包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件，或者所述第一客户端问候消息中包括的第一加密曲线集合不包括所述服务端支持的至少一个加密曲线，或者所述第一客户端问候消息包括的第一协议标识集合中不包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端基于自身能力，向所述客户端发送第一服务端反馈消息；所述第一服务端反馈消息包括：第二加密套件、第二加密曲线和第二协议标识。所述第一加密套件集合不包括所述第二加密套件，所述第二加密套件包括所述服务端支持的至少一个加密套件中任一个加密套件；所述第一加密曲线集合不包括所述第二加密曲线，所述第二加密曲线包括所述服务端支持的至少一个加密曲线中任一个加密曲线；所述第一协议标识集合部包括所述第二协议标识，所述第二协议标识包括所述服务端支持的至少一个协议版本中任一个协议版本对应的协议标识。
步骤S403，若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输。
在一些实施例中，在所述第一密钥协商模式包括所述第二密钥协商模式的情况下，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
在一些实施例中，所述第一密钥协商模式包括所述第二密钥协商模式包括：所述第一加密套件集合中包括所述第一加密套件、所述第一加密曲线集合包括所述第一加密曲线且所述第一协议标识集合中包括所述第一协议标识的情况下，所述第一密钥协商模式包括所述第一服务端反馈消息中携带的第一加密套件、第一加密曲线和第一协议标识对应的第二密钥协 商模式。
在另一些实施例中，所述第一密钥协商模式包括所述第二密钥协商模式，还可以包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
在一些实施例中，基于所述第二密钥协商模式确定第一客户端共享密钥包括情景1(步骤S201至步骤S206)和情景2(步骤S301至步骤S304)，此处不再重复赘述。
在一些实施例中，所述情景1包括：所述第二密钥协商模式为使用ECDH的配网协议协商密钥；基于所述第二密钥协商模式确定第一客户端共享密钥包括：使用ECDH的配网协议协商密钥。
在一些实施例中，所述情景2包括所述第二密钥协商模式为ECJPAKE的配网协议。
步骤S404，若所述第一密钥协商模式不包括所述第二密钥协商模式，接收所述客户端发送第二客户端问候消息。
在一些实施例中，所述第一密钥协商模式不包括所述第二密钥协商模式，包括：所述第一客户端问候消息包括的第一加密套件集合中不包括所述第一服务端反馈消息中携带的第二加密套件；或者，所述第一客户端问候消息包括的第一加密曲线集合不包括所述第一反馈信息中携带的第二加密曲线；或者，所述第一客户端问候消息包括的第一协议标识集合中不包括所述第一反馈信息中携带的第二协议标识。即所述第一密钥协商模式不包括所述第一服务端反馈消息中携带的加密套件、加密曲线和协议标识对应的第二密钥协商模式。
在一些实施例中，所述服务端接收所述客户端发送的第二客户端问候消息，所述客户端发送第二客户端问候消息包括：所述客户端向服务端发送第二客户端问候消息，所述第二客户端问候消息包括第二信息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式。
在一些实施例中，所述第二信息包括所述客户端能够支持的第二加密套件集合和/或所述客户端能够支持的第二加密曲线集合。所述第一加密套件集合中包括的至少一个加密套件与所述第二加密套件集合中包括的至少一个加密套件完全不相同；所述第一加密曲线集合中包括的至少一个加密曲线与所述第二加密曲线集合中包括的至少一个加密曲线完全不相同。
在一些实施例中，在一些实施例中，所述第二客户端问候消息还包括：第四公钥，所述第四公钥包括：在所述客户端能够支持ECDH的配网协议的情况下，所述第二加密套件集合中任一个加密套件和/或所述第二加密曲线集合中任一个加密曲线确定的公钥。
在一些实施例中，所述第二客户端问候消息还包括：第二协议标识集合，所述第二协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第二协议标识集合指示所述客户端支持的协议版本的集合。
在一些实施例中，所述第二客户端问候消息还包括：第二公钥列表，所述第二客户端问候消息的第二公钥列表为NULL。
在一些实施例中，在所述服务端能够支持所述第三密钥协商模式的情况下，执行步骤S405；在所述服务端不能支持所述第三密钥协商模式的情况下，执行步骤S407。
步骤S405，基于所述第二客户端问候消息发送第二服务端反馈消息，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式。
在一些实施例中，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式。
在一些实施例中，所述服务端基于所述第二客户端问候消息发送第二服务端反馈消息的具体步骤流程与步骤S402相似，此处不再重复赘述。
步骤S406，基于所述第四密钥协商模式确定第二服务端共享密钥，根据所述第二客户端共享密钥进行目标数据传输。
在一些实施例中，基于所述服务端第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输的具体步骤流程与步骤S203相似，此处不再重复赘述。
步骤S407，发送第一警告消息。
在一些实施例中，所述服务端不能支持所述第三密钥协商模式包括：所述第二客户端问候消息包括的第二加密套件集合中不包括所述服务端支持的加密套件；或者，所述第二客户端问候消息包括的第一加密曲线集合不包括所述服务端支持的加密曲线；或者，所述第二客户端问候消息包括的第一协议标识集合中不包括所述服务端支持的协议标识。
在一些实施例中，所述服务端向所述客户端发送第一告警信息，所述第一警告消息用于指示断开所述客户端和所述服务端之间的连接。
如此，本申请实施例提供一种灵活的数据传输方式，对于性能较好且对安全要求高的客户端，使用ECJPAKE的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，对于安全级别要求高的客户端，将客户端的PIN码与传输流程结合，提升了PIN码破解的难度，提升了数据传输的安全性。此外，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图9示出了本申请实施例提供的数据传输方法的一种可选流程示意图，图10示出了本申请实施例提供的数据传输方法的一种详细处理流程示意图，将结合图9、图10进行说明。
步骤S501，客户端向服务端发送第一客户端问候消息。
在一些实施例中，所述客户端向服务端发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式。
在一些实施例中，所述第一密钥协商模式包括使用ECDH的配网协议协商密钥和/或使用ECJPAKE的配网协议协商密钥。
在一些实施例中，所述第一信息包括第一加密套件集合、第一加密曲线集合和第一协议标识集合中至少一种。所述第一加密套件集合包括所述客户端能够支持的至少一个加密套件的集合；所述第一加密曲线集合包括所述客户端能够支持的至少一个加密曲线的集合；所述第一协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第一协议标识集合指示所述客户端支持的协议版本的集合。
在一些实施例中，所述第一客户端问候消息通过图10中示出的ClientHello消息传输。所述ClientHello消息中包括的 “supported_version”字段用于指示所述第一协议标识集合；所述ClientHello消息中包括的“cipher_suites”字段用于指示所述第一加密套件集合；所述ClientHello消息中包括的“supported_group”字段用于指示所述第一加密曲线集合；所述ClientHello消息中包括的“keyshare”字段用于指示所述第一公钥。
在一些实施例中，所述ClientHello消息中还包括“ecjpake_key_kp_pair_list”用于指示ECJPAKE的配网协议使用的公钥对，在本实施例中，所述“ecjpake_key_kp_pair_list”为NULL。
在一些实施例中，所述“keyshare”字段还用于指示第四随机序列，所述第四随机序列包括所述客户端随机生成的序列；进一步，所述“keyshare”字段用于指示第一公钥与第四随机序列组合形成的第四数字序列。
步骤S502，服务端向客户端发送第一服务端反馈消息。
在一些实施例中，服务端接收客户端发送的第一客户端问候消息；根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式包括：所述服务端基于所述第一客户端问候消息中携带的第一加密套件集合包括的至少一个加密套件、第一加密曲线集合中包括的至少一个加密曲线和第一协议标识集合中包括的至少一个协议版本对应的协议标识，确定所述服务端支持的第二密钥模式。
在一些实施例中，在所述第一客户端问候消息中包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合包括所述服务端支持的至少一个加密曲线，且所述第一客户端问候消息包括的第一协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端确定所述第二密钥协商模式对应的第一加密套件、第一加密曲线和第一协议标识，并通过第一服务端反馈消息发送给所述客户端。
在一些实施例中，在所述服务端确定第二密钥协商模式为使用ECDH的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第二公钥，所述第二公钥基于所述第一加密套件、第一加密曲线和第一协议标识中至少一种确定。
在一些实施例中，所述第一服务端反馈消息通过图10中示出的ServerHello消息传输。所述ServerHello消息中包括的“supported_version”字段用于指示所述第一协议标识；所述ServerHello消息中包括的“cipher_suites”字段用于指示所述第一加密套件；所述ServerHello消息中包括的“supported_group”字段用于指示所述第一加密曲线；所述ServerHello消息中包括的“keyshare”字段用于指示所述第二公钥。
由于本实施例描述的是使用ECDH的配网协议协商密钥的流程，因此，所述ServerHello消息中不包括“ecjpake_key_kp_pair_list”。
在一些实施例中，所述“keyshare”字段还用于指示第二随机序列，所述第二随机序列包括所述服务端随机生成的序列；进一步，所述“keyshare”字段用于指示第二公钥与第二随机序列组合形成的第四数字序列。
步骤S503，客户端接收所述第一服务端反馈消息。
在一些实施例中，所述客户端接收所述第一服务端反馈消息，判断所述第一反馈消息中包括的第一加密曲线与确定所述第一客户端问候信息中包括的第一公钥的加密曲线是否相同，在所述第一加密曲线与确定所述第一公钥的加密曲线不相同的情况下，执行步骤S504；或者，在所述第一加密曲线与确定所述第一公钥的加密曲线相同的情况下，执行步骤S505。
步骤S504，客户端向服务端发送第二客户端问候消息。
在一些实施例中，所述第二客户端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第二客户端问候消息还可以包括：第三公钥；所述第三公钥基于所述第一加密套件和/或第一加密曲线确定。
在另一些实施例中，所述第二客户端问候消息还可以包括：第三公钥与第一随机序列组合形成的第一数字序列。所述第一随机序列由所述客户端随机生成。
在一些实施例中，所述第二客户端问候消息通过图10中示出的ClientHello消息传输。所述ClientHello消息中包括的“supported_version”字段用于指示所述第一协议标识；所述ClientHello消息中包括的“cipher_suites”字段用于指示所述第一加密套件；所述ClientHello消息中包括的“supported_group”字段用于指示所述第一加密曲线；所述ClientHello消息中包括的“keyshare”字段用于指示所述第三公钥。
在一些实施例中，所述ClientHello消息中还包括“ecjpake_key_kp_pair_list”用于指示ECJPAKE的配网协议使用的公钥对，在本实施例中，所述“ecjpake_key_kp_pair_list”为NULL。
步骤S505，服务端基于第一公钥或第三公钥确定第一密钥。
在一些实施例中，所述服务端基于第一公钥确定第一密钥包括：所述第一反馈消息中包括的第一加密曲线与确定所述第一客户端问候信息中包括的第一公钥的加密曲线相同的情况下，所述服务端基于所述第一客户端问候消息确定第一密钥。
在一些实施例中，所述服务端基于第一客户端问候消息中包括的“keyshare”字段指示的第一公钥确定第一密钥；或者，所述服务端去除所述“keyshare”字段指示的第四数字序列中的第四随机序列，基于所述第四数字序列中包括的第一公钥确定第一密钥。
在另一些实施例中，所述服务端基于第一公钥确定第一密钥包括：所述第一反馈消息中包括的第一加密曲线与确定所述第一客户端问候信息中包括的第一公钥的加密曲线不相同的情况下，所述服务端基于第二客户端问候消息确定第一密钥。
在一些实施例中，所述服务端基于第二客户端问候消息中包括的“keyshare”字段指示的第三公钥确定第一密钥；或者，所述服务端去除所述“keyshare”字段指示的第一数字序列中的第一随机序列，基于所述第一数字序列中包括的第三公钥确定第一密钥。
在一些实施例中，步骤S501至步骤S505可以是Epoch0阶段执行的流程，所述客户端与所述服务端之间传输的消息不加密。
步骤S506，服务端向客户端发送第一验证信息。
所述步骤S506的具体步骤与步骤S203相同，此处不再重复赘述。
步骤S507，服务端向客户端发送第一校验数据。
所述步骤S507的具体步骤与步骤S204相同，此处不再重复赘述。
步骤S508，客户端向服务端发送第二验证信息。
所述步骤S508的具体步骤与步骤S205相同，此处不再重复赘述。
步骤S509，客户端向服务端发送第二校验数据。
所述步骤S509的具体步骤与步骤S206相同，此处不再重复赘述。
客户端向服务端发送第二验证信息。
在一些实施例中，步骤S506至步骤S509可以是Epoch1阶段执行的流程，所述客户端与所述服务端之间传输的消息通过第一密钥加密和/或解密。
步骤S510，客户端确定第一客户端共享密钥，并根据第一客户端共享密钥进行目标数据传输。
在一些实施例中，所述客户端确定第一客户端共享密钥包括：所述客户端基于第一公钥、第二公钥、第三公钥和第一密钥中至少一种，确定第一客户端共享密钥。
在一些实施例中，所述第一校验数据验证通过，说明所述客户端发送和/或接收的消息未被篡改，所述客户端可以基于第一客户端共享密钥传输目标数据。
步骤S511，服务端确定第一服务端共享密钥，并根据第一服务端共享密钥进行目标数据传输。
在一些实施例中，所述服务端确定第一服务端共享密钥包括：所述服务端基于第一公钥、第二公钥、第三公钥和第一密钥中至少一种，确定第一服务端共享密钥。
在一些实施例中，所述第二校验数据验证通过，说明所述服务端发送和/或接收的消息未被篡改，所述服务端可以基于第一服务端共享密钥传输目标数据。
在一些实施例中，所述第一客户端共享密钥与所述第一服务端共享密钥相同或不同。
在一些实施例中，所述第一客户端共享密钥基于所述第一密钥确定，例如所述第一客户端共享密钥可以包括所述第一密钥加密后确定的数据。
在一些实施例中，在一些实施例中，步骤S510至步骤S511可以是Epoch2阶段执行的流程，所述客户端传输的消息通过第一客户端共享密钥加密和/或解密；所述服务端传输的消息通过第一服务端共享密钥加密和/或解密。
在一些实施例中，所述方法还包括：所述客户端发送和/或接收的经所述第一客户端共享密钥加密的目标数据的次数大于第一阈值的情况下，所述客户端与服务端重新确定客户端共享密钥。
在一些实施例中，所述客户端发送和/或接收的经所述第一客户端共享密钥加密的目标数据的次数大于第一阈值，包括：第一客户端共享密钥加密次数过多，多次传输会提升所述第一客户端共享密钥被破译的风险，在所述第一客户端共享密钥加密的目标数据的次数大于第一阈值的情况下，所述客户端和所述服务端更新第一密钥和/或第一客户端共享密钥。
如此，本申请实施例提供一种灵活的数据传输方式，无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。此外，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图11示出了本申请实施例提供的数据传输方法的又一种可选流程示意图，图12示出了本申请实施例提供的数据传输方法的又一种详细处理流程示意图，将结合图11、图12进行说明。
步骤S601，客户端向服务端发送第一客户端问候消息。
所述步骤S601的具体流程与步骤S501相同，此处不再重复赘述。
步骤S602，服务端接收客户端发送的第一客户端问候消息。
在一些实施例中，服务端接收客户端发送的第一客户端问候消息；根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端。
在一些实施例中，服务端根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式包括：所述服务端基于所述第一客户端问候消息中携带的第一加密套件集合包括的至少一个加密套件、第一加密曲线集合中包括的至少一个加密曲线和第一协议标识集合中包括的至少一个协议版本对应的协议标识，确定所述服务端支持的第二密钥模式。
在一些实施例中，在所述第一客户端问候消息中包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件、所述第一客户端问候消息中包括的第一加密曲线集合包括所述服务端支持的至少一个加密曲线，且所述第一客户端问候消息包括的第一协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端确定所述第二密钥协商模式对应的第一加密套件、第一加密曲线和第一协议标识，并通过第一服务端反馈消息发送给所述客户端。
在一些实施例中，在所述服务端确定第二密钥协商模式为使用ECJPAKE的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第一公钥列表，所述第一公钥基于所述第一加密套件、第一加密曲线和第一协议标识中至少一种确定。所述第一公钥列表还可以包括所述服务端的PIN码。
在一些实施例中，所述第一服务端反馈消息通过图12中示出的HelloRetryRequest消息传输。所述HelloRetryRequest消息中包括的“supported_version”字段用于指示所述第一协议标识；所述HelloRetryRequest消息中包括的“cipher_suites”字段用于指示所述第一加密套件；所述HelloRetryRequest消息中包括的“supported_group”字段用于指示所述第一加密曲线。
在一些实施例中，所述HelloRetryRequest消息中包括的“ecjpake_key_kp_params”字段用于指示所述第二公钥；或者，所述HelloRetryRequest消息中包括的“key_share”字段用于指示所述第二公钥。
由于本实施例描述的是使用ECJPAKE的配网协议协商密钥的流程，因此，所述HelloRetryRequest消息中包括“ecjpake_key_kp_pair_list”，所述“ecjpake_key_kp_pair_list”用于指示第一公钥列表。
步骤S603，客户端向服务端发送第三客户端问候消息。
在一些实施例中，所述第三客户端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第三客户端问候消息还可以包括：第二公钥列表和第六公钥；所述第六公钥基于所述第一加密套件和/或第一加密曲线确定。所述第二公钥列表还可以包括所述客户端的PIN码。
在另一些实施例中，所述第三客户端问候消息还可以包括：第六公钥与第一随机序列组合形成的第一数字序列。所述第一随机序列由所述客户端随机生成。所述第六公钥还可以包括所述客户端的PIN码。
在一些实施例中，所述第三客户端问候消息通过图12中示出的ClientHello消息传输。所述ClientHello消息中包括的“supported_version”字段用于指示所述第一协议标识；所述ClientHello消息中包括的“cipher_suites”字段用于指示所述第一加密套件；所述ClientHello消息中包括的“supported_group”字段用于指示所述第一加密曲线。
在一些实施例中，在一些实施例中，所述ClientHello消息中包括的“ecjpake_key_kp_params”字段用于指示所述第六公钥；或者，所述ClientHello消息中包括的“key_share”字段用于指示所述第六公钥。
在一些实施例中，所述ClientHello消息中还包括“ecjpake_key_kp_pair_list”用于指示ECJPAKE的配网协议使用的第二公钥列表。
步骤S604，服务端向客户端第一服务端问候消息。
在一些实施例中，所述第一服务端问候消息包括一下至少一种：第一加密套件、第一加密曲线和第一协议标识。
在一些实施例中，所述第一服务端问候消息还可以包括：第五公钥。所述第五公钥基于所述第一加密套件和/或第一加密曲线确定。所述第五公钥还可以包括所述服务端的PIN码。
在另一些实施例中，所述第一服务端问候消息还可以包括：第五公钥与第三随机序列组合形成的第三数字序列。所述第三随机序列由所述服务端随机生成。
在一些实施例中，所述第一服务端问候消息通过图12中示出的ServerHello消息传输。所述ServerHello消息中包括的“supported_version”字段用于指示所述第一协议标识；所述ServerHello消息中包括的“cipher_suites”字段用于指示所述第一加密套件；所述ServerHello消息中包括的“supported_group”字段用于指示所述第一加密曲线。
在一些实施例中，在一些实施例中，所述ServerHello消息中包括的“ecjpake_key_kp_params”字段用于指示所述第五公钥；或者，所述ServerHello消息中包括的“key_share”字段用于指示所述第五公钥。
在一些实施例中，步骤S601至步骤S604可以是Epoch0阶段执行的流程，所述客户端与所述服务端之间传输的消息不加密。
步骤S605，服务端向客户端发送第一校验数据。
所述步骤S605的具体流程与步骤S303相同，此处不再重复赘述。
步骤S606，客户端向服务端发送第二校验数据。
所述步骤S606的具体流程与步骤S303相同，此处不再重复赘述。
在一些实施例中，步骤S605至步骤S606可以是Epoch1阶段执行的流程，所述客户端与所述服务端之间传输的消息通过第一密钥加密和/或解密。
步骤S607，客户端确定第一客户端共享密钥，并根据第一客户端共享密钥进行目标数据传输。
在一些实施例中，所述客户端确定第一客户端共享密钥包括：所述客户端基于第五公钥、第六公钥、第一公钥列表、第二公钥列表和第一密钥中至少一种，确定第一客户端共享密钥。
在一些实施例中，所述第一校验数据验证通过，说明所述客户端发送和/或接收的消息未被篡改，所述客户端可以基于第一客户端共享密钥传输目标数据。
步骤S608，服务端确定第一服务端共享密钥，并根据第一服务端共享密钥进行目标数据传输。
在一些实施例中，所述服务端确定第一服务端共享密钥包括：所述服务端基于第五公钥、第六公钥、第一公钥列表、第二公钥列表和第一密钥中至少一种，确定第一服务端共享密钥。
在一些实施例中，所述第二校验数据验证通过，说明所述服务端发送和/或接收的消息未被篡改，所述服务端可以基于第一服务端共享密钥传输目标数据。
在一些实施例中，所述第一客户端共享密钥与所述第一服务端共享密钥相同或不同。
在一些实施例中，所述第一客户端共享密钥基于所述第一密钥确定，例如所述第一客户端共享密钥可以包括所述第一密钥加密后确定的数据。
在一些实施例中，在一些实施例中，步骤S510至步骤S511可以是Epoch2阶段执行的流程，所述客户端传输的消息和/或数据通过第一客户端共享密钥加密解密；所述服务端传输的消息和/或数据通过第一服务端共享密钥加密解密
在一些实施例中，所述方法还包括：所述客户端发送和/或接收的经所述第一客户端共享密钥加密的目标数据的次数大于第一阈值的情况下，所述客户端与服务端重新确定客户端共享密钥。
在一些实施例中，所述客户端发送和/或接收的经所述第一客户端共享密钥加密的目标数据的次数大于第一阈值，包括：第一客户端共享密钥加密次数过多，多次传输会提升所述第一客户端共享密钥被破译的风险，在所述第一客户端共享密钥加密的目标数据的次数大于第一阈值的情况下，所述客户端和所述服务端更新第一密钥和/或第一客户端共享密钥。
如此，本申请实施例提供一种灵活的数据传输方式，对于性能较好且对安全要求高的客户端，使用ECJPAKE的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，对于安全级别要求高的客户端，将客户端的PIN码与传输流程结合，提升了PIN码破解的难度，提升了数据传输的安全性。此外，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图13示出了本申请实施例提供的数据传输方法的再一种可选流程示意图，图14示出了本申请实施例提供的数据传输方法的再一种详细处理流程示意图，将结合图13、图14进行说明。
步骤S801，客户端向服务端发送第一客户端问候消息。
所述步骤S801的具体流程与步骤S501相同，此处不再重复赘述。
步骤S802，服务端向客户端发送第一服务端反馈消息。
在一些实施例中，在所述第一客户端问候消息中不包括的第一加密套件集合中包括所述服务端支持的至少一个加密套件，或者所述第一客户端问候消息中包括的第一加密曲线集合不包括所述服务端支持的至少一个加密曲线，或者所述第一客户端问候消息包括的第一协议标识集合中不包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端基于自身能力，向所述客户端发送第一服务端反馈消息；所述第一服务端反馈消息包括：第二加密套件、第二加密曲线和第二协议标识。所述第一加密套件集合不包括所述第二加密套件，所述第二加密套件包括所述服务端支持的至少一个加密套件中任一个加密套件；所述第一加密曲线集合不包括所述第二加密曲线，所述第二加密曲线包括所述服务端支持的至少一个加密曲线中任一个加密曲线；所述第一协议标识集合部包括所述第二协议标识，所述第二协议标识包括所述服务端支持的至少一个协议版本中任一个协议版本对应的协议标识。
在一些实施例中，所述第一服务端反馈消息通过图14中示出的HelloRetryRequest消息传输。所述HelloRetryRequest消息中包括的“supported_version”字段用于指示所述第二协议标识；所述HelloRetryRequest消息中包括的“cipher_suites”字段用于指示所述第二加密套件；所述HelloRetryRequest消息中包括的“supported_group”字段用于指示所述第二加密曲线。
在一些实施例中，所述HelloRetryRequest消息中包括的“ecjpake_key_kp_params”字段用于指示所述第二公钥；或者，所述HelloRetryRequest消息中包括的“key_share”字段用于指示所述第二公钥。
在一些实施例中，在所述第一密钥协商模式包括所述第二加密套件、所述第二加密曲线和所述第二协议标识对应的第二密钥协商模式的情况下，执行步骤S503至步骤S511的流程，或者，执行步骤S603至步骤S608的流程。在所述第一密钥协商模式不包括所述第二加密套件、所述第二加密曲线和所述第二协议标识对应的第二密钥协商模式的情况下，执行步骤S803。
步骤S803，客户端向服务端发送第二客户端问候信息。
在一些实施例中，所述客户端发送第二客户端问候消息包括：所述客户端向服务端发送第二客户端问候消息，所述第二客户端问候消息包括第二信息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式。
在一些实施例中，所述第二信息包括所述客户端能够支持的第二加密套件集合和/或所述客户端能够支持的第二加密曲线集合。所述第一加密套件集合中包括的至少一个加密套件与所述第二加密套件集合中包括的至少一个加密套件完全不相同；所述第一加密曲线集合中包括的至少一个加密曲线与所述第二加密曲线集合中包括的至少一个加密曲线完全不相同。
在一些实施例中，在一些实施例中，所述第二客户端问候消息还包括：第四公钥，所述第四公钥包括：在所述客户端能够支持ECDH的配网协议的情况下，所述第二加密套件集合中任一个加密套件和/或所述第二加密曲线集合中任一个加密曲线确定的公钥。
在一些实施例中，所述第二客户端问候消息还包括：第二协议标识集合，所述第二协议标识集合包括至少一个协议版本对应的协议标识，所述协议版本与所述协议标识一一对应，所述第二协议标识集合指示所述客户端支持的协议版本的集合。
在一些实施例中，所述第二客户端问候消息还包括：第二公钥列表，所述第二客户端问候消息的第二公钥列表为空(NULL)。
在一些实施例中，所述第二客户端问候消息通过图14中示出的ClientHello消息传输。所述ClientHello消息中包括的“supported_version”字段用于指示所述第二协议标识集合；所述ClientHello消息中包括的“cipher_suites”字段用于指示所述第二加密套件集合；所述ClientHello消息中包括的“supported_group”字段用于指示所述第二加密曲线集合。
在一些实施例中，所述ClientHello消息中包括的“ecjpake_key_kp_params”字段用于指示所述第四公钥；或者，所述ClientHello消息中包括的“key_share”字段用于指示所述第四公钥。
在一些实施例中，所述ClientHello消息中还包括“ecjpake_key_kp_pair_list”用于指示ECJPAKE的配网协议使用的公钥对，在本实施例中，所述“ecjpake_key_kp_pair_list”为NULL。
在一些实施例中，在所述第三密钥协商模式包括所述服务端能够支持的加密套件、加密曲线和协议标识对应的第四密钥协商模式的情况下，执行步骤S804。在所述第三密钥协商模式不包括所述服务端能够支持的加密套件、加密曲线和协议标识对应的第四密钥协商模式的情况下，执行步骤S805。
步骤S804，服务端发送第二反馈信息。
在一些实施例中，在所述第二客户端问候消息中包括的第二加密套件集合中包括所述服务端支持的至少一个加密套件、所述第二客户端问候消息中包括的第二加密曲线集合包括所述服务端支持的至少一个加密曲线，且所述第二客户端问候消息包括的第二协议标识集合中包括所述服务端支持的至少一个协议版本对应的协议标识的情况下，所述服务端确定所述第四密钥协商模式对应的第二加密套件、第二加密曲线和第二协议标识，并通过第二服务端反馈消息发送给所述客户端。在所述服务端确定第四密钥协商模式为使用ECDH的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第四公钥，所述第四公钥基于所述第二加密套件、第二加密曲线和第二协议标识中至少一种确定；或者，在所述服务端确定第二密钥协商模式为使用ECJPAKE的配网协议协商密钥的情况下，所述第一服务端反馈消息还包括：第三公钥列表，所述第三公钥列表包括服务端向客户端发送的，用于确定第一客户端共享密钥的公钥对。
在一些实施例中，所述第一服务端反馈消息通过图14中示出的ServerHello消息传输。所述ServerHello消息中包括的“supported_version”字段用于指示所述第二协议标识；所述ServerHello消息中包括的“cipher_suites”字段用于指示所述第二加密套件；所述ServerHello消息中包括的“supported_group”字段用于指示所述第二加密曲线；所述ServerHello消息中包括的“keyshare”字段用于指示所述第四公钥。
在一些实施例中，若所述客户端与服务端使用ECDH的配网协议协商密钥的流程，所述ServerHello消息中不包括“ecjpake_key_kp_pair_list”；若所述客户端与服务端使用ECJPAKE的配网协议协商密钥的流程，所述ServerHello消息中还包括“ecjpake_key_kp_pair_list”，所述“ecjpake_key_kp_pair_list”用于指示第一公钥列表。
在一些实施例中，所述方法还包括：执行步骤S503至步骤S511的流程，或者，执行步骤S603至步骤S608的流程。
步骤S805，服务端发送第一警告消息。
在一些实施例中，所述服务端不能支持所述第三密钥协商模式包括：所述第二客户端问候消息包括的第二加密套件集合中不包括所述服务端支持的加密套件；或者，所述第二客户端问候消息包括的第一加密曲线集合不包括所述服务端支持的加密曲线；或者，所述第二客户端问候消息包括的第一协议标识集合中不包括所述服务端支持的协议标识。
在一些实施例中，所述服务端向所述客户端发送第一告警信息，所述第一警告消息用于指示断开所述客户端和所述服务端之间的连接。
在一些实施例中，所述方法还包括：
步骤S806，客户端发送第二警告消息。
在一些实施例中，在所述客户端接收到的服务端发送的消息中包括2个以上加密曲线或者2个以上加密套件或者2个以上版本标识的情况下，所述客户端向服务端发送第二警告消息，并断开与服务端之间的连接；所述第二警告消息用于指示断开所述客户端和服务端之间的连接。
在一些实施例中，所述服务端发送的消息包括：第一服务端反馈消息和/或第一服务端问候消息。
如此，本申请实施例提供一种灵活的数据传输方式，对于性能较差且对安全要求不高的客户端，使用ECDH的配网协议进行数据传输；对于性能较好且对安全要求高的客户端，使用ECJPAKE的配网协议进行数据传输。无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，对于安全级别要求 高的客户端，将客户端的PIN码与传输流程结合，提升了PIN码破解的难度，提升了数据传输的安全性。此外，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图15示出了本申请实施例提供的数据传输方法的还一种可选流程示意图。
步骤S901，客户端向服务端发送客户端问候消息。
在一些实施例中，在一轮协商中第一次发送所述客户端问候消息时，所述客户端问候消息包括以下至少一项：协议版本字段：用于指示所述客户端支持的部分或全部协议版本参数；所述加密套件字段用于指示所述客户端支持的部分或全部加密套件参数；所述加密曲线字段用于指示所述客户端支持的部分或全部加密曲线参数；所述第一公钥字段用于指示所述客户端的第一公钥；所述第二公钥字段为空或不包括所述第二公钥字段。
步骤S902，接收服务端基于所述客户端问候消息发送的请求重发问候消息或服务端问候消息或警告消息。
在一些实施例中，当所述请求重发问候消息为所述服务端在一轮协商中第一次发送的请求重发问候消息，则再次发送所述客户端问候消息；和/或，当所述请求重发问候消息为所述服务端在一轮协商中第二次发送的请求重发问候消息，则发送警告消息并断开连接；和/或，接收到所述服务端发送的服务端问候消息缺少任一必选字段时发送警告消息并断开连接；和/或，接收到所述服务端发送的服务端问候消息的协议版本号字段中包括多个协议版本时发送警告消息并断开连接；和/或，接收到所述服务端发送的服务端问候消息的加密套件字段中包括多个加密套件参数或不支持加密套件参数时发送警告消息并断开连接；和/或，接收到所述服务端发送的服务端问候消息的加密曲线字段中包括多个加密曲线参数或不支持加密曲线参数时发送警告消息并断开连接；和/或，接收到所述服务端发送的服务端问候消息的第一公钥字段中包括多个第一公钥时发送警告消息并断开连接。
步骤S903，基于服务端发送的公钥生成客户端共享密钥。
在一些实施例中，当所述客户端能够支持所述服务端发送的所述请求重发反馈消息或所述服务端问候消息指示的密钥协商模式时，基于所述请求重发反馈消息或所述服务端问候消息携带的所述服务端公钥生成客户端共享密钥。
如此，本申请实施例提供一种灵活的数据传输方式，无需由开发者或提前选择数据传输流程，客户端或服务端可以根据实际需求自行确定传输流程。并且，本申请实施例中，所述客户端和/或服务端传输的每一帧消息均参与校验数据的哈希值运算，保证了握手协商数据不被篡改，提升握手协商过程的安全可靠性。
图16示出了本申请实施例提供的数据传输方法的另一种可选流程示意图，将根据各个步骤进行说明。
步骤S1001，第一端通过握手消息与第二端协商共享密钥。
在一些实施例中，所述第一端为客户端的情况下，所述第二端为服务端；或者，所述第一端为服务端的情况下，所述第二端为客户端。
所述客户端通过握手消息与服务端协商共享密钥包括步骤S101至步骤S108，或者包括步骤S200至步骤S206，或者包括步骤S301至步骤S304，或者包括步骤S401至步骤S407，或者包括步骤S501至步骤S511，或者包括步骤S601至步骤S608，或者包括步骤S801至步骤S806，或者包括步骤S901至步骤S903以及图5、图7、图10、图12和图14中示出的具体流程，此处不再重复赘述。相应地，所述握手消息包括第一客户端问候消息、第一服务端反馈消息、第二客户端问候消息、第一服务端问候消息、第三客户端问候消息、第一警告消息和第二警告消息至少一种。
在一些实施例中，所述握手消息包括握手问候消息和握手应答消息；所述握手问候消息包括：第一客户端问候消息、第二客户端问候消息和第三客户端问候消息中至少一种；所述握手应答消息包括：第一服务端问候消息；所述重发请求消息包括第一服务端反馈消息。
所述握手问候消息或所述握手应答消息的消息载荷中包括公钥列表字段，所述公钥列表字段的值为空NULL，所述空值用于确定所述第二端是否支持目标加密套件。所述公钥列表字段通过“ecjpake_key_kp_pair_list”字段指示。
在一些实施例中，所述方法还包括：在协商密钥过程中，所述第一端对所述握手消息进行校验得到校验值。所述握手消息包括握手完成消息，用于指示完成所述密钥的协商流程，其中，所述握手完成消息携带所述校验值。
在一些实施例中，所述握手完成消息可以包括步骤S204、步骤S303、步骤S507、步骤S605中的第一校验数据，和/或步骤S205、步骤S304、步骤S509、步骤S606中的第二校验数据；相应地所述校验值可以是所述第一校验数据和/或所述第二校验数据中携带的哈希值。
步骤S1002，所述第一端通过内容消息与所述第二端传输应用数据，所述内容消息通过使用所述共享密钥进行加密和解密。
在一些实施例中，所述内容消息包括所述第一端和所述第二段传输的目标数据。所述第一端和所述第二段通过使用所述共享密钥对所述第一端和第二端传输的内容消息进行加密和解密。
在一些实施例中，所述方法还包括：使用所述共享密钥对所述内容消息中的消息载荷进行加密。所述消息载荷包括：协议版本字段、加密套件字段、共享密钥字段、加密曲线字段。所述协议版本字段包括图3至图16的流程中的“supported_version”字段；所述加密套件字段包括图3至图16的流程中的“cipher_suites”字段；所述共享密钥字段包括图3至图16的流程中的“key_share”字段、“ecjpake_key_kp_pair_list”字段和“ecjpake_key_kp_params”字段中至少一种；所述加密曲线字段包括图3至图16的流程中的“supported_group”字段。
在一些实施例中，所述握手问候消息包括图3至图16的流程中包括的第一客户端问候消息、第二客户端问候消息、第三客户端问候消息；所述握手应答消息包括图3至图16的流程中包括的第一服务端问候消息；所述重发请求消息包括图3至图16的流程中包括的第一服务端反馈消息和/或第二服务端反馈消息；所述认证数据消息包括图3至图16的流程中包括的第一验证信息和/或第二验证信息；所述握手完成消息包括图3至图16的流程中包括的第一校验数据和/或第二校验数据。
在一些实施例中，如图3至图16的流程中包括的第一客户端问候消息、第一服务端反馈消息、第二客户端问候消息、第一服务端问候消息、第三服务端问候消息具有相同的消息格式，所述消息格式包括：消息计数和消息载荷；所述消息计数包括密钥代数(Epoch)标识和消息计数(Seq)，其中，所述密钥代数通过小于第一位数的比特信息进行表征，所述消息计数通过小于第二位数的比特信息进行表征。
在一些实施例中，所述第一位数可以是2；所述第二位数可以是8。
在一些实施例中，所述第一客户端问候消息、第一服务端反馈消息、第二客户端问候消息、第一服务端问候消息、第 三服务端问候消息的消息载荷中至少包括以下字段中的一种或多种：协议版本字段、加密套件字段、共享密钥字段、加密曲线字段。
其中，所述密钥代数使用E表示，所述E表征Epoch的最低位；所述Epoch用于指示当前使用的对称密钥的形式，如表1所示，Epoch 0的情况下，不使用密钥；Epoch 1的情况下，使用第一密钥；Epoch 2的情况下，使用第二密钥等。
在一些实施例中，所述第一端通过所述握手问候消息、所述握手应答消息或所述重发请求消息与所述第二端协商密钥时，所述密钥代数标识为a；所述第一端通过所述认证数据消息或所述握手完成消息与所述第二端协商密钥时，所述密钥代数标识为a+1；所述第一端通过所述内容消息与所述第二端传输应用数据时，所述密钥代数标识为a+2至a+N；其中，a为整数，N为大于或等于2的整数。传输在先的应用数据的密钥代数小于传输在后的应用数据的密钥代数。
例如，在a＝0的情况下，步骤S501至步骤S505可以是Epoch0阶段执行的流程，所述客户端与所述服务端之间传输的消息不加密；步骤S506至步骤S509可以是Epoch1阶段执行的流程，所述客户端与所述服务端之间传输的消息通过第一密钥加密和/或解密；传输所述应用数据可以是Epoch2至EpochN，所述客户端与所述服务端之间传输的消息通过共享密钥加密和/或解密。
在一些实施例中，所述消息计数包括8个字节，每个字节占8位(8比特信息)，其中，所述消息计数的前2个字节表征Epoch(占16位)，本申请实施例中，E通过小于第一位数的比特信息表征；所述E可以是对应Epoch的最低1位(占用1比特)，或者，所述E可以是对应Epoch的最低0位(不占用比特信息)。
在一些实施例中，所述握手问候消息或所述握手应答消息的消息载荷中包括ecjpake_key_kp_pair_list字段，所述公钥列表字段的值为空NULL，所述空值用于确定所述第二端是否支持目标加密套件。
在一些实施例中，所述第二端基于所述握手问候消息返回所述重发请求消息，其中，所述重发请求消息中的加密套件字段配置为所述目标加密套件。
表1
Epoch 阶段(Stage) 客户端密钥 服务端密钥
0 Hello 不加密 不加密
1 Handshake ClientHandshake Key ServerHandshake Key
2 Application ClientHandshake Key0 ServerHandshake Key0
…… …… …… ……
N Application ClientHandshake KeyN ServerHandshake KeyN
在不同的阶段，所述客户端和服务端端发送和/或接收的数据，使用不同的密钥进行加密、解密。当握手完成后，进入Epoch 2，后续如果需要更新密钥，可以由客户端和服务端端同步更新，即进入Epoch N。
图17示出了本申请实施例提供的客户端与服务端传输的消息的内容的可选结构示意图。
图17中，Seq为消息计数，用于所述Seq对应的消息是所述客户端和/或服务端传输的信息的序号(即所述Seq对应的消息是所述客户端和/或服务端传输的第几条消息)。
在一些实施例中，所述消息计数包括8个字节，每个字节占8位(8比特信息)，其中，所述消息计数的后6个字节表征Seq(占48位)，本申请实施例中，所述消息计数标识通过所述消息计数的最低第三位数的比特信息表征；消息计数标识的值等于在前传输的相邻的消息计数标识的值与1的和。所述第三位数小于所述第二位数。在所述第二位数为8的情况下，所述第三位数可以是7，相应地，所述消息计数标识为所述消息计数的最低7位；或者，在所述第二位数为8的情况下，所述第三位数可以是6，相应地，所述消息计数标识为所述消息计数的最低6位。也就是说，本申请实施例中，使用小于或等于8位比特信息表征所述消息序号，相比目前标准ECJPAKE的配网协议的字节长度，消息序号减少了1-2字节，更加精简，可以减少传输数据量。
在一些实施例中，所述消息载荷包括实际数据和消息类型，所述消息类型包括填充类型、应用数据类型、警告类型和握手类型。
图17中，Payload为实际数据，包括：经所述第一密钥加密的所述校验数据中携带的传输数据；或者，经共享密钥加密的所述应用数据携带中的传输数据；或者，所述握手信息携带的传输数据。其中，所述经所述第一密钥加密的所述校验数据中携带的传输数据可以是所述校验数据包括的哈希值的集合；所述经所述第一密钥加密的所述应用数据携带中的传输数据可以是待传输的应用数据(如开灯、关灯、开始扫地、打开窗帘等)；所述握手信息携带的传输数据可以是公钥、随机序列、加密曲线、加密套件、协议标识、公钥列表中至少一种。
图17中，“+”表示消息所附带的的extension；“{}”表示Epoch 1，即消息使用[sender]HandshakeTraffic派生的密钥功能进行加密；“[]”表示Epoch 2，即消息使用[sender]ApplicationTraffic派生的密钥进行加密。
图17中，所述消息格式包括：E、Seq和Payload；所述Payload包括Content和Type。
其中，所述Payload包括消息载荷，除第0代密钥(Epoch 0)外，Payload数据被加密。
所述消息载荷包括实际数据和消息类型，所述消息类型包括填充类型、应用数据类型、警告类型和握手类型。所述消息类型(Type)的定义如表2所示：
表2
消息类型(Type) 符号(Sym) 信息(Info)
0 Padding 填充字节0
1 Application Data 应用层消息
2 Alter 通知消息
3 Handshake 握手协商消息
其中，所述填充类型包括表2中的Padding，用于填充Payload至合适的长度。Padding对应的Content部分仍然是Payload格式，即最后一个字节需要根据消息类型重新判断。解析时，可以直接掉过Payload结尾的Padding。
如表2所示，所述应用数据类型包括表2中的Application Data，包括传输所述第一客户端和/或服务端之间的应用数据，可以是开灯、关灯、环境信息采集、生物特征采集等数据。
所述警告类型包括表2中的通知消息，具体包括握手成功、握手失败等告知ECDH的配网协议或ECJPAKE的配网协 议的消息，如第一警告消息、第二警告消息等。
所述握手类型包括表2中的握手协商消息，具体包括第一信息、第二序列、第一校验数据、第一验证信息、第二校验数据、第二验证信息、第三序列、第一重传请求、第一问候信息中至少一种。
如表2所示，Alert用于发送告警消息，代码包括：
Figure PCTCN2021110617-appb-000001
其中，所述客户端和或服务端在接收到告警消息的情况下，必须断开连接。
在一些实施例中，Payload内容为Handshake的情况下，Handshake消息的代码包括：
Figure PCTCN2021110617-appb-000002
在一些实施例中，所述Handshake用于发送握手消息，所述握手消息包括：第一信息、第二序列、第一校验数据、第一验证信息、第二校验数据、第二验证信息、第三序列、第一重传请求、第一问候信息中至少一种。
在一些实施例中，至少一个Handshake消息的Epoch相同，则发送所述至少一个Handshake消息的一端可以将所述至少一个Handshake消息合并，如此只需要加密一次。
相应地，在接收所述消息的一端解密数据时，通过Handshake.len确定每个Handshake消息的边界，通过整条消息长度确定一条消息中包含的所有Handshake。
图14中，客户端发送的ClientHello的代码包括：
Figure PCTCN2021110617-appb-000003
其中，random包括8字节的随机数据，用于防止重放攻击。extension为扩展，用于描述所述客户端的自身能力和相关参数。Extension中所有扩展必须按照扩展类型从小到大的顺序排列。
ClientHello是协议协商的第一条消息，由Client向Server发送。用于向Server告知所述Client的认证能力以及自定义参数。
图14中，服务端发送的ServerHello的代码包括：
Figure PCTCN2021110617-appb-000004
其中，random包括32字节的随机数据，用于防止重放攻击。extension为扩展，用于描述所述服务端的自身能力和相关参数。Extension中所有扩展必须按照扩展类型从小到大的顺序排列。只有当ClientHello中给出了某个扩展时(代表Client支持所述某个扩展)，在ServerHello的应答中才允许应答对应的扩展。
ServerHello由Server向Client发送，用于确定会话的连接参数。
ClientHello是协议协商的第一条消息，由Client向Server发送。用于向Server告知所述Client的认证能力以及自定义参数。
在Client处理ServerHello时，若发现其中存在任何不支持的扩展，必须向Server发送unexpected_message警告并断开连接。Server发现必选扩展不存在是，必须向Client发送unexpected_message警告并断开连接。
图14中，HelloRetryRequest消息的代码包括：
Figure PCTCN2021110617-appb-000005
其中，extensions表征扩展，用于描述所述服务端的自身能力和相关参数。在所述Client第一次向Server发送ClientHello以后，Server可能发送HelloRetryRequest要求Client重新发起协商。比较常见的情况是Client提供的key_share曲线Server不支持，比如Client提供secp256r1曲线，但Server只支持C25519曲线，此时，Server需要从ClientHello中找到supported_group扩展，从supported_group中找到能够进行协商的曲线，然后使用HelloRetryRequest消息通知Client重新协商。
在客户端和服务端协商共享密钥的过程中，Retryrequest只允许发起一次。对于Server,若第二次Clienthello发送的参数仍然无法接受时,Server必须发送handshake_failure警告并关闭连接。对于Client,若收到第二个HelloRetryrequest,Client必须发送unexpected_message并断开连接。
HelloRetryRequest消息在ECDH的配网协议中用于对错误ClientHello消息的应答；或者，在ECJPAKE的配网协议中用于传输ECJPAKE Round 1数据。
在一些实施例中，所述在ECDH的配网协议中对错误ClientHello消息的应答包括步骤S301至步骤S302，此处不再重复赘述；所述在ECJPAKE的配网协议中传输ECJPAKE Round 1数据包括步骤S401至步骤S402，此处不再重复赘述。
图14中，Authenticate消息的代码包括：
Figure PCTCN2021110617-appb-000006
其中，所述Authenticate消息用于传输认证数据。消息格式会根据cipher_suites定义的Authentication列的取值变化。特殊的，当Authentication取值为None时,该消息必须被省略。不同的认证方式下,Authenticate构造方式不同。
在认证方式使用ECDH的配网协议的情况下，Authenticate消息的代码包括：
Figure PCTCN2021110617-appb-000007
其中，所述Authenticate消息用于对ECDH的证书认证，支持两种证书：X509证书与自定义证书。
图14中，Finished消息的代码包括：
Figure PCTCN2021110617-appb-000008
其中，verify_data为使用当前Transcripthash值计算HMAC。计算方法包括：
Verify_data＝HMAC(key＝FinishedKey,message＝TranscriptHash)
其中，TranscriptHash：Server：TranscriptHash(ClientHello1……Server Authenticate)。
Client：TranscriptHash(ClientHello1…Server Authenticate,Server Finished,Client Authenticate)。
Finished Key:Server:Expand(PRK＝ServerHandshakeTraffic,|abe|＝”htbts finished”,len＝Hash Length)。
Client:Expand(PRK＝ClientHandshakeTraffic,|abe|＝”htbts finished”,len＝Hash Length)
图14中，Application Data消息的Content部分为完整的用户数据。
所述消息代码中，extension是对消息的补充说明，代码包括：
Figure PCTCN2021110617-appb-000009
其中，extension_data表征各扩展类型内，定义的扩展数据；data_size表征数据长度。编码方式可以参考变长整数。data_size不大于16383字节，即data_size编码后只可能为1字节或2字节。当编码为2字节时，第一字节最高位为1，第二字节最高位不为1。解码时，若发现data_size不符合要求，则应发送unexpected_message告并关闭连接；extension_type表征Extension的消息类型如表3所示：
表3
Type Sym 适用于
0 supported_version CR(必选)，SR(必选)，HRR(必选)
1 cipher_suits CR(必选)，SR(必选)，HRR(必选)
2 supported_group CR，SR，HRR
4 key_share CR(必选)，SR(必选)
5 Ecjpake_key_kp_pair_list CR，SR
6 Ecjpake_key_kp_params CR，SR
其中，所述“适用于”用于标识允许使用相应扩展的握手消息。消息名称通过缩写表示：CR(ClientHello)，SR(ServerHello)，HRR(HelloRetryRequest)，AU(Authenticate)。
其中，“必选”表示响应的消息中必须存在。在对端发送的消息中，缺少某个必选扩展，必须发送unexpected_message并断开连接。
表3中，Type 0表征版本号；Type1表征加密套件，可以是ECDH、(Diffle-Hellman，DH)等；Type2表征使用的曲线类型，如椭圆曲线；Type4表征交互公钥；Type5和Type6分别表征不同阶段的公钥。
图14中，supported_version的代码包括：
Figure PCTCN2021110617-appb-000010
其中，supported_version指示所述客户端或服务端支持的协议版本。目前协议版本为1。
supported_version必须被添加到ClientHello、ServerHello、HelloRetryRequest中。并填写一个Version。Server填写的Version将作为本次连接的协议版本。
在一些实施例中，当Client在收到的ServerHello中，发现supported_version扩展中存在多个Version或发现Version自己不支持时，clent应该发送protocol_version警告并关闭连接。
图14中，cipher_suites的代码包括：
Figure PCTCN2021110617-appb-000011
其中，所述cipher_suites指示所述客户端或服务端支持的加密套件。所述cipher_suites包括CipherSuite、Sym、KeyExchange、Authentication、Cipher、MAC Tag、和Hash。
CipherSuite用于指示加密套件的uint8的取值；Sym用于指示加密套件名称，用于统一个实现的命名。KeyExchange用于指示密钥交换方式，影响key_share扩展。Authentication用于指示认证方式，影响Authenticate消息；Cipher用于指示数据加密方式，在加密时需要使用；MAC Tag用于指示加密套件的MAC Tag长度。Hash用于指示在协议运行过程中使用的HKDF、HMAC等函数所使用的散列函数。
在一些实施例中，Client在ClientHello中填写一个或多个CipherSuite。由Server在ServerHello和HelloRetryRequest中选中并填写一个CipherSuite。Server填写的CipherSuite将作为本次连接使用的加密套件。
在一些实施例中，非调试目的不允许使用0x00(None)加密套件。
在一些实施例中，当Client在收到的ServerHello中，发现cipher_suites扩展中存在多个cipher_suites或发现cipher_suites自己不支持时，Client应该发送unexpected_message警告并关闭连接。
图14中，supported_group的代码包括：
Figure PCTCN2021110617-appb-000012
在一些实施例中，支持的EC曲线参数。定义如表4：
表4
NamedGroup sym
0x17 secp256r1
0x18 secp384r1
0x19 secp521r1
0x1D x25519
0x1E x448
其中，Client在ClientHello中填写一个或多个自己支持的NamedGroup，但Server在ServerHello和HelloRetryRequest中，选中并填写一个NamedGroup。Server填写的NamedGroup将作为本次连接使用的EC曲线。
在一些实施例中，当Client在收到的ServerHello中，发现supported_group扩展中存在多个NamedGroup或发现NamedGroup自己不支持时，Client应该发送unexpected_message警告并关闭连接。
图14中，key_share的代码包括：
Figure PCTCN2021110617-appb-000013
Figure PCTCN2021110617-appb-000014
其中，key_share用于向对方共享密钥。用于密钥协商。key_share在ClientHello、ServerHello、HelloRetryRequest消息中可能使用。
在一些实施例中，ClientHello中，key_shares允许出现多个，用于供Server挑选。ServerHell中，key_shares仅能出现一个，用于选择密钥协商。HelloRetryRequest中，key_shares仅能出现一个，并且len为0。仅用于告知Client重新发起ClientHello。
在一些实施例中，当Client在收到的ServerHello中，发现扩展中存在多个key_shareEntry或发现NamedGroup自己不支持时，Client应该发送unexpected_message警告并关闭连接。
图14中，ecjpake_key_kp_pair_list的代码包括：
Figure PCTCN2021110617-appb-000015
在一些实施例中，如果不确定Server端是否支持ECJPAKE认证，Client端在第一个ClientHello1中应该携带空的ecjpake_key_pair_list。若Server端选择ECJPAKE进行认证，则Server端需要选择ECJPAKE类cipher_suites，填写自己的ECJPAKE Round1数据并发送HelloRetryRequest要求Client重新认证。
在一些实施例中，所述握手问候消息或所述握手应答消息的消息载荷中包括ecjpake_key_kp_pair_list字段，所述ecjpake_key_kp_pair_list字段的值为空NULL，所述空值用于确定所述第二端是否支持目标加密套件。
在一些实施例中，格式定义与Elliptic Curve J-PAKE Cipher for Transport Layer(TLS)Section 7.2.2 17中定义相同。对应ClientHello/ServerHello中的“ECJPAKEKeyKPPairList”扩展。identtity字段被删除，使用mbedTLS实现中预定义的“Client”/“Server”。
图14中，ecjpake_key_kp_params的代码包括：
Figure PCTCN2021110617-appb-000016
其中，格式定义与Elliptic Curve J-PAKE Cipher for Transport Layer(TLS)Section 7.3 18中定义相同。对应ServerKeyExchange/ClientKeyExchange中的“ServerECJPAKEParams”或“ClientECJPAKEParams”。
在一些实施例中，所述“ecjpake_key_kp_params”用于指示ECJPAKE的协议中的公钥，如第五公钥、第六公钥等。
图14中，TrainscriptHash是握手过程中需要保持的Hash上下文，用于保障握手过程数据的完整性。Client、Server每发送、接收一条消息，都需要将消息内容写入Hash上下文。Client在收到ServerHello或HelloRetryRequest时初始化TranscriptHash。Server在收到第一包ClientHello时初始化TranscriptHash。
在一些实施例中，TranscriptHash构造方法包括：
Transcript-Hash(M1,M2,...Mn)＝Hash(M1||M2||...||Mn)
其中，HelloRetryRequest一般情况下是不需要使用的，这样整个交互过程就会省略HelloRetryRequest和第二个ClientHello。
此时TranscriptHash组成包括：
Hash(ClientHello||ServerHello||...Mn)
在一些实施例中，消息序号的代码包括：
Figure PCTCN2021110617-appb-000017
其中，消息序号分为epoch、seq两部分，共64位。Client与Server分开处理。epoch为密钥代数。连接刚刚建立成功时，epoch为0。包括epoch 0在内，每发送和接收一条消息，seq递增1。
图18示出了本申请实施例提供的客户端的一种可选结构示意图，将根据各个部分进行说明。
在一些实施例中，所述客户端1100包括：第一发送部分1101，第一获取部分1102和第一确定部分1103。
第一发送部分1101，配置为发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式；
第一获取部分1102，配置为获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
第一确定部分1103，若所述第一密钥协商模式包括所述第二密钥协商模式，配置为基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。
在一些实施例中，若所述第一密钥协商模式不包括所述第二密钥协商模式，则所述第一发送部分1101，配置为发送第二客户端问候消息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式；
所述第一获取部分1102，配置为获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息，所述第二反 馈信息用于指示所述服务端确定的第四密钥协商模式；
所述第一确定部分1103，配置为基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；
所述第一获取部分1102，配置为获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接；或者，获取所述服务端基于所述第二客户端问候消息发送的第三服务端反馈消息，基于所述第三服务端反馈消息发送第二警告消息并断开连接。
在一些实施例中，所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥。
在一些实施例中，所述第一客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段、所述加密曲线字段和所述第二公钥字段，其中，所述第一公钥字段包括所述客户端的第一公钥；所述第二公钥字段为空；和/或，当所述客户端和所述服务端适用第一密钥协商算法时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段，所述第一公钥字段包括所述客户端的第二公钥；和/或，当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第二公钥字段，所述第二公钥字段包括所述客户端的第三公钥；和/或，当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端不支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述加密曲线字段。
在一些实施例中，所述第一密钥协商算法为ECDH算法，所述第二密钥协商算法为ECJPAKE算法。
在一些实施例中，所述若所述第一密钥协商模式包括所述第二密钥协商模式，包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；和/或，所述若所述第一密钥协商模式不包括所述第二密钥协商模式，包括：所述第一客户端问候消息的所述协议版本字段的协议版本参数不包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；或者，所述第一客户端问候消息的所述加密套件字段的加密套件参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；或者，所述第一客户端问候消息的所述加密曲线字段的加密曲线参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
在一些实施例中，若所述第一客户端共享密钥或所述第二客户端共享密钥使用预设次数或预设时间后，重新执行所述发送第一客户端问候消息的步骤。
图19示出了本申请实施例提供的数据传输装置的另一种可选结构示意图，将根据各个部分进行说明。
在一些实施例中，服务端1200包括：第二接收部分1201和第二确定部分1202。
第二接收部分1201，配置为接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
第二确定部分1202，配置为根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端；或者，若所述第一密钥协商模式包括所述第二密钥协商模式，配置为基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输。
在一些实施例中，若所述第一密钥协商模式不包括所述第二密钥协商模式，所述第二接收部分1201，配置为接收所述客户端发送第二客户端问候消息，所述第二客户端问候消息用于指示所述客户端能够支持的第三密钥协商模式；
第二接收部分1201，配置为基于所述第二客户端问候消息发送第二服务端反馈消息，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式；
所述第二确定部分1202，配置为基于所述第四密钥协商模式确定第二服务端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，基于所述第二客户端问候消息发送的第三服务端反馈消息并断开连接。
在一些实施例中，所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥。
在一些实施例中，所述客户端和所述服务端能够适用第一密钥协商算法和/或第二密钥协商算法；所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息。
在一些实施例中，所述请求重发问候消息为第一请求重发问候消息、第二请求重发问候消息、第三请求重发问候消息、第四请求重发消息中的任一种，所述服务端问候消息为第一服务端问候消息、第二服务端问候消息中的任一种，其中，所述第一请求重发问候消息用于在所述服务端适用所述第一密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，所述第二请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且支持所述第一密钥协商模式的情况下发送的；和/或，所述第三请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，所述第四请求重发问候消息用于在所述服务适用所述第一密钥协商算法且支持第一密钥协商模式，但不支持所述第一公钥的情况下发送的；所述第一服务端问候消息用于在所述服务端适用所述第二密钥协商算法且支持所述第一密钥协商模式的情况下发送；和/或，所述第二服务端问候消息用于在所述服务端适用所述第一密钥协商算法且支持所述第一密钥协商模式的情况下发送的。
在一些实施例中，所述第一密钥协商算法为ECDH算法，所述第二密钥协商算法为ECJPAKE算法。
本申请提供一种实施例，在客户端和服务端之间进行安全认证后传输数据，例如在蓝牙点对点传输中先通过安全认证生成共享密钥然后进行应用数据等(即下面描述的目标数据)的传输，一般要客户端和服务端先确定出双方均能够支持的密钥协商模式，例如能够支持相同的协议版本、相同的加密套件、相同的加密曲线。客户端和服务器之间传输的消息包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段。其中，第一公钥字段和第二公钥字段用于存放不同密钥协商算法对应的公钥，例如第一公钥字段用于存放使用ECDH算法的公钥，第二公钥字段用于存放ECJPAKE算法的公钥，因此，第二公钥字段可能包括ecjpake_key_kp_pair_list字段、ecjpake_key_kp_params字段中的至少一种。也就是说，对应的第二公钥可能包括ECJPAKE算法对应的三个公钥。
可以理解的，一种数据传输方法，应用于客户端(Client)和服务端(Server)，所述方法包括：
步骤C1发送第一客户端问候消息(例如Clienthello)，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
步骤S1接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
可以理解的，第一密钥协商模式可能包括客户端能够支持的部分或全部密钥协商模式。即在第一客户端问候消息的各个字段中携带客户端所能够支持的部分或者全部参数。示例的，第一客户端问候消息可以理解为本轮协商中第一次发送客户端问候消息(例如Clienthello)。示例的，所述第一客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段、所述加密曲线字段和所述第二公钥字段，其中，所述第一公钥字段包括所述客户端的第一公钥；所述第二公钥字段为空；一种情况下，第二公钥字段也可以没有。
在第一客户端问候消息采用上述字段，在第一公钥字段中携带客户端第一公钥可以试探服务端适用的密钥协商模式的同时，可以节省协商流程，例如服务端支持ECDH算法，则可以直接获取上述第一公钥，提升协商速度。
步骤S2根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
可以理解的，所述请求重发问候消息可以为第一请求重发问候消息、第二请求重发问候消息、第三请求重发问候消息、第四请求重发消息中的任一种，所述服务端问候消息可以为第一服务端问候消息、第二服务端问候消息中的任一种，其中，
所述第一请求重发问候消息用于在所述服务端适用第一密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，
所述第二请求重发问候消息用于在所述服务端适用第二密钥协商算法且支持所述第一密钥协商模式的情况下发送的；和/或，
所述第三请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，
所述第四请求重发问候消息用于在所述服务适用所述第一密钥协商算法且支持第一密钥协商模式，但不支持所述第一公钥的情况下发送的；和/或，
所述第一服务端问候消息用于在所述服务端适用所述第一密钥协商算法且支持所述第一密钥协商模式和所述第一公钥的情况下发送的。
可以理解的，所述第一请求重发问候消息包括：第一公钥字段，所述第一公钥字段为空；
或，所述第一请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段和所述第二公钥字段均为空；
所述第二请求重发问候消息包括：第二公钥字段，所述第二公钥字段为所述服务端的第二公钥；
或，所述第二请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为空，所述第二公钥字段为所述服务端的第二公钥；
所述第三请求重发问候消息包括：第二公钥字段，所述第二公钥字段为空；
或，所述第三请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段和所述第二公钥字段均为空；
所述第四请求重发问候消息包括：第一公钥字段，所述第一公钥字段为所述服务端的第一公钥；
或，所述第四请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为所述服务端的第一公钥，所述第二公钥字段为空；
所述第一服务端问候消息包括：第一公钥字段，所述第一公钥字段为所述服务端的第一公钥；
或，所述第一服务端问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为所述服务端的第一公钥，所述第二公钥字段为空。
需要说明的是，请求重发问候消息中加入了存放服务端公钥的字段，且具有适用不同密钥协商算法的第一公钥字段和第二公钥字段，不仅可以兼容不同的密钥协商算法，还可以节省协商流程，提升协商速度。
可以理解的，服务端在接收到客户端发送的第一服务端反馈消息后解码其中的参数，并将相关参数与自己支持的对应参数进行比对，从各个字段中的参数中分别确定一个双方都支持的参数，即确定出双方都能够支持的第二密钥协商模式，此时如果服务端适用ECDH算法，则发送第一服务端反馈消息(如serverhello)，此时服务端通过第一公钥字段(如key share字段)发送服务端的公钥，若服务端适用ECJPAKE算法,则服务端通过第一服务端反馈消息(如HelloRetryRequest)的第二公钥字段(如ecjpake_key_kp_pair_list字段)发送一对服务端公钥；如果本次不能找到双方都支持的密钥协商模式时，服务端只能选择一个服务端自己支持的第二密钥协商模式，然后通过第一服务端反馈消息(如ecjpake_key_kp_pair_list，适用于ECDH和ECJPAKE情况)发出，此时由于没有确定好密钥协商模式，则不需携带对应的服务端公钥，一种特殊的情况，在适用ECDH算法时，第一次虽然确定了客户端和服务端都支持的密钥协商模式，但第一次Clienthello中的第一公钥的曲线服务端并不支持，因此服务端可以发HelloRetryRequest而不是发serverhello，并且可以通过keyshare字段发送服务端公钥。
步骤C2获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，第一服务端反馈消息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
可以理解的，第二密钥协商模式可以是服务端从客户端发的第一密钥协商模式中选择的一个双方都支持的模式，当选出了双方都支持的密钥协商模式后，就可以开始公钥的传输，例如客户端和服务端适用ECJPAKE算法时，服务端发送其 一对公钥给客户端(可能是通过HelloRetryRequest或serverhello的ecjpake_key_kp_pair_list字段携带一对公钥发送)，客户端收到后通过clienthello中的第二公钥字段(例如ecjpake_key_kp_pair_list字段和ecjpake_key_kp_params字段)发送客户端的一对公钥和另一个公钥，服务端收到后通过服务端问候消息中第二公钥字段(例如serverhello的ecjpake_key_kp_params字段)发送服务端的另一个公钥。
步骤C3确定所述客户端的共享密钥，通过所述客户端的共享密钥进行目标数据传输。
示例的，若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输；
若所述第一密钥协商模式不包括所述第二密钥协商模式，则发送第二客户端问候消息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式；
获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息，所述第二反馈信息用于指示所述服务端确定的第四密钥协商模式；基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，
获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接；或者，
获取所述服务端基于所述第二客户端问候消息发送的第三服务端反馈消息，基于所述第三服务端反馈消息发送第二警告消息并断开连接。
步骤S3确定所述服务端的共享密钥，通过所述服务端的共享密钥进行目标数据传输。
示例的，若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输；
若所述第一密钥协商模式不包括所述第二密钥协商模式，接收所述客户端发送第二客户端问候消息，所述第二客户端问候消息用于指示所述客户端能够支持的第三密钥协商模式；
基于所述第二客户端问候消息发送第二服务端反馈消息，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式；
基于所述第四密钥协商模式确定第二服务端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，
基于所述第二客户端问候消息发送第三服务端反馈消息并断开连接。
可以理解的，当所述客户端和所述服务端适用第一密钥协商算法时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段，所述第一公钥字段包括所述客户端的第二公钥，所述第二公钥用于确定所述客户端的共享密钥；和/或，
当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第二公钥字段，所述第二公钥字段包括所述客户端的第三公钥，所述第三公钥用于确定所述客户端的共享密钥；和/或，
当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端不支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述加密曲线字段。
第一密钥协商算法为ECDH算法，第二密钥协商算法为ECJPAKE算法。
可以理解的，客户端根据服务端发送的三个客户端的公钥基于ECJPKE算法生成共享密钥，服务端根据客户端发送的三个服务端公钥基于ECJPKE算法生成共享密钥；或者服务端通过客户端发送消息中的第一公钥字段(如key share字段)的服务端的第一公钥基于ECDH算法生成服务端共享密钥，客户端通过服务端发送消息中的第一公钥字段(如key share字段)的服务端的第一公钥基于ECDH算法生成客户端共享密钥。
一种可行的实施方式，所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括上述预定义字段，预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；
所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；
所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；
所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；
所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；
所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥；
所述第一公钥和所述第二公钥对应不同的密钥协商算法。
可以理解的，所述若所述第一密钥协商模式包括所述第二密钥协商模式，包括：
所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；
所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；
所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；
和/或，
所述若所述第一密钥协商模式不包括所述第二密钥协商模式，包括：
所述第一客户端问候消息的所述协议版本字段的协议版本参数不包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；或者，
所述第一客户端问候消息的所述加密套件字段的加密套件参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；或者，
所述第一客户端问候消息的所述加密曲线字段的加密曲线参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
可以理解的，若所述第一客户端共享密钥或所述第二客户端共享密钥使用预设次数或预设时间后，重新执行所述发送 第一客户端问候消息的步骤。这样可以在共享密钥使用一定次数或时间后自动进行更新从而提高安全性。
需要说明的，本申请实施例中，可以设定服务端仅能发送一次请求重发问候消息(如HelloRetryRequest)，示例的，在适用ECJPAKE算法时，客户端一次客户端问候消息可发送三个客户端公钥，而服务端一次最多发送两个公钥，因为需要确认PIN码后才生成第三个公钥单独发送，从而使得整个传输过程安全性进一步增强。
一些实施例中，提供一种客户端，所述客户端包括：
第一发送部分，配置为发送第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
第一获取部分，配置为获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
第一确定部分，配置为确定所述客户端的共享密钥；
第一传输部分，配置为通过所述客户端的共享密钥进行目标数据传输。
上述部分的其他作用对应与方法部分，在此不再赘述。
一些实施例中，提供一种服务端，所述服务端包括：
第二接收部分，配置为接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
第二确定部分，配置为根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，
第二发送部分，配置为通过所述第一服务端反馈消息发送给所述客户端，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
第二传输部分，配置为确定所述服务端的共享密钥，通过所述服务端的共享密钥进行目标数据传输。
一种存储介质，存储有可执行程序，其中，所述可执行程序被处理器执行时，实现上述任一项数据传输方法。
一种电子设备，包括存储器、处理器及存储在存储器上并能够由所述处理器运行的可执行程序，其中，所述处理器运行所述可执行程序时执行上述任一项数据传输方法的步骤，处理器可以包括数据收发模块。
需要说明的是，本申请提供了多个实施例，其中使用的各种描述上存在差异，但可能表示相同的特征或方案，在不冲突的情况下可以替换。
图20示出了本申请实施例提供的数据传输装置的一种可选结构示意图，将根据各个部分进行说明。在一些实施例中，数据传输装置1400，包括：协商部分1401和应用数据部分1402。
协商部分1401，配置为通过握手消息与第二端协商密钥；
应用数据部分1402，配置为通过内容消息与所述第二端传输应用数据，所述内容消息通过使用所述共享密钥进行加密和解密；
其中，所述握手消息和所述内容消息具有相同的消息格式，所述消息格式包括：消息序号和消息载荷；所述消息序号包括密钥代数标识和消息计数标识，其中，所述密钥代数标识通过小于第一位数的比特信息进行表征，所述消息计数标识通过小于第二位数的比特信息进行表征。
在一些实施例中，所述消息载荷包括实际数据和消息类型，所述消息类型包括填充类型、应用数据类型、警告类型和握手类型。
在一些实施例中，所述数据传输装置1400还包括：加密部分1403；
所述加密部分1403，配置为通过所述共享密钥对所述内容消息中的消息载荷进行加密。
在一些实施例中，所述数据传输装置1400还包括：校验部分1404；
所述校验部分1404，配置为在协商共享密钥过程中，对所述握手消息进行校验得到校验值。
在一些实施例中，所述握手消息包括握手完成消息，用于指示完成所述共享密钥的协商流程，其中，所述握手完成消息携带所述检验值。
在一些实施例中，所述握手消息包括以下至少一项：握手问候消息、握手应答消息、重发请求消息、认证数据消息、握手完成消息。
在一些实施例中，所述握手问候消息、握手应答消息、重发请求消息的消息载荷中至少包括以下字段中的一种或多种：协议版本字段、加密套件字段、共享密钥字段、加密曲线字段。
在一些实施例中，所述第一端通过所述握手问候消息、所述握手应答消息或所述重发请求消息与所述第二端协商共享密钥时，所述密钥代数标识为a；所述第一端通过所述认证数据消息或所述握手完成消息与所述第二端协商共享密钥时，所述密钥代数标识为a+1；所述第一端通过所述内容消息与所述第二端传输应用数据时，所述密钥代数标识为a+2至a+N；其中，a为整数，N为大于或等于2的整数。
在一些实施例中，所述握手问候消息或所述握手应答消息的消息载荷中包括公钥列表字段，所述公钥列表字段的值为空(NULL)，所述空值用于确定所述第二端是否支持目标加密套件。
在一些实施例中，所述第二端基于所述握手问候消息返回所述重发请求消息，其中，所述重发请求消息中的加密套件字段配置为所述目标加密套件。
在一些实施例中，所述第一端为客户端，所述第二端为服务端；或者，所述第一端为服务端，所述第二端为客户端。
图21是本申请实施例的电子设备的硬件组成结构示意图，电子设备1300包括：至少一个处理器1301、存储器1302和至少一个网络接口1304。客户端或服务端1300中的各个组件通过总线系统1305耦合在一起。可理解，总线系统1305用于实现这些组件之间的连接通信。总线系统1305除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图15中将各种总线都标为总线系统1305。
在一些实施例中，所述电子设备可以是客户端或服务器对应的硬件结构。
可以理解，存储器1302可以是易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是ROM、可编程只读存储器(PROM，Programmable Read-Only Memory)、可擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，Electrically Erasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagnetic random access memory)、快闪存储器(Flash  Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random Access Memory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random Access Memory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data Rate Synchronous Dynamic Random Access Memory)、增强型同步动态随机存取存储器(ESDRAM，Enhanced Synchronous Dynamic Random Access Memory)、同步连接动态随机存取存储器(SLDRAM，SyncLink Dynamic Random Access Memory)、直接内存总线随机存取存储器(DRRAM，Direct Rambus Random Access Memory)。本申请实施例描述的存储器1302旨在包括但不限于这些和任意其它适合类型的存储器。
本申请实施例中的存储器1302用于存储各种类型的数据以支持客户端或服务端1300的操作。这些数据的示例包括：用于在客户端或服务端1300上操作的任何计算机程序，如应用程序1322。实现本申请实施例方法的程序可以包含在应用程序1322中。
所述本申请实施例揭示的方法可以应用于处理器1301中，或者由处理器1301实现。处理器1301可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，所述方法的各步骤可以通过处理器1301中的硬件的集成逻辑电路或者软件形式的指令完成。所述的处理器1301可以是通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。处理器1301可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤，可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于存储介质中，该存储介质位于存储器1302，处理器1301读取存储器1302中的信息，结合其硬件完成前述方法的步骤。
在示例性实施例中，客户端或服务端1300可以被一个或多个应用专用集成电路(ASIC，Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD，Programmable Logic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、FPGA、通用处理器、控制器、MCU、MPU、或其他电子元件实现，用于执行前述方法。
本申请实施例还提供了一种存储介质，用于存储计算机程序。
可选的，该存储介质可应用于本申请实施例中的第一客户端，并且该计算机程序使得计算机执行本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围，凡在本申请的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本申请的保护范围之内。
工业实用性
本申请实施例提供的数据传输方法、客户端、服务端及存储介质，发送第一客户端问候消息，所述第一客户端问候消息包括第一信息，所述第一信息用于指示所述客户端能够支持的第一密钥协商模式；获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输。如此，可以灵活地确定密钥协商模式，进行共享密钥协商，进而通过协商的共享密钥传输目标数据。

Claims (20)

  1. 一种数据传输方法，应用于客户端，所述方法包括：
    发送第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
    获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
    确定所述客户端的共享密钥，通过所述客户端的共享密钥进行目标数据传输。
  2. 根据权利要求1所述的方法，其中，所述确定所述客户端的共享密钥，通过所述客户端的共享密钥进行目标数据传输，包括：
    若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一客户端共享密钥，根据所述第一客户端共享密钥进行目标数据传输；
    若所述第一密钥协商模式不包括所述第二密钥协商模式，则发送第二客户端问候消息，所述第二信息用于指示所述客户端能够支持的第三密钥协商模式；
    获取所述服务端基于所述第二客户问候消息发送的第二服务端反馈消息，所述第二反馈信息用于指示所述服务端确定的第四密钥协商模式；基于所述第四密钥协商模式确定第二客户端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，
    获取所述服务端基于所述第二客户端问候消息发送的第一警告消息，基于所述第一警告消息断开连接；或者，
    获取所述服务端基于所述第二客户端问候消息发送的第三服务端反馈消息，基于所述第三服务端反馈消息发送第二警告消息并断开连接。
  3. 根据权利要求1或2所述的方法，其中，
    所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；
    所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；
    所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；
    所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；
    所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；
    所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥；
    所述第一公钥和所述第二公钥对应不同的密钥协商算法。
  4. 根据权利要求3所述的方法，其中，
    所述第一客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段、所述加密曲线字段和所述第二公钥字段，其中，所述第一公钥字段包括所述客户端的第一公钥；所述第二公钥字段为空；和/或，
    当所述客户端和所述服务端适用第一密钥协商算法时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第一公钥字段，所述第一公钥字段包括所述客户端的第二公钥，所述第二公钥用于确定所述客户端的共享密钥；和/或，
    当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述第二公钥字段，所述第二公钥字段包括所述客户端的第三公钥，所述第三公钥用于确定所述客户端的共享密钥；和/或，
    当所述客户端和所述服务端适用第二密钥协商算法，且所述客户端不支持所述第二密钥协商模式时，所述第二客户端问候消息包括所述协议版本字段、所述加密套件字段、所述加密曲线字段。
  5. 根据权利要求4所述的方法，其中，
    所述第一密钥协商算法为ECDH算法，所述第二密钥协商算法为ECJPAKE算法。
  6. 根据权利要求3所述的方法，其中，
    所述若所述第一密钥协商模式包括所述第二密钥协商模式，包括：
    所述第一客户端问候消息的所述协议版本字段的协议版本参数包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；
    所述第一客户端问候消息的所述加密套件字段的加密套件参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；
    所述第一客户端问候消息的所述加密曲线字段的加密曲线参数包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；
    和/或，
    所述若所述第一密钥协商模式不包括所述第二密钥协商模式，包括：
    所述第一客户端问候消息的所述协议版本字段的协议版本参数不包括所述第一服务端反馈消息的所述协议版本字段的协议版本参数；或者，
    所述第一客户端问候消息的所述加密套件字段的加密套件参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数；或者，
    所述第一客户端问候消息的所述加密曲线字段的加密曲线参数不包括所述第一服务端反馈消息的所述加密套件字段的加密套件参数。
  7. 根据权利要求1-2任一所述的方法，其中，
    若所述第一客户端共享密钥或所述第二客户端共享密钥使用预设次数或预设时间后，重新执行所述发送第一客户端问候消息的步骤。
  8. 根据权利要求1-2、4、6任一所述的方法，其中，
    所述第二密钥协商模式为使用ECDH的配网协议协商密钥；或者，所述第二密钥协商模式为ECJPAKE的配网协议。
  9. 根据权利要求2所述的方法，其中，所述基于所述第二密钥协商模式确定第一客户端共享密钥，包括：
    使用ECDH的配网协议协商密钥；或者，使用ECJPAKE的配网协议协商密钥。
  10. 一种数据传输方法，应用于服务端，所述方法包括：
    接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
    根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，并通过所述第一服务端反馈消息发送给所述客户端，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
    确定所述服务端的共享密钥，通过所述服务端的共享密钥进行目标数据传输。
  11. 根据权利要求10所述的方法，其中，
    若所述第一密钥协商模式包括所述第二密钥协商模式，基于所述第二密钥协商模式确定第一服务端共享密钥，根据所述第一服务端共享密钥进行目标数据传输；
    若所述第一密钥协商模式不包括所述第二密钥协商模式，接收所述客户端发送第二客户端问候消息，所述第二客户端问候消息用于指示所述客户端能够支持的第三密钥协商模式；
    基于所述第二客户端问候消息发送第二服务端反馈消息，所述第二服务端反馈消息用于指示所述服务端确定的第四密钥协商模式；
    基于所述第四密钥协商模式确定第二服务端共享密钥，根据所述第二客户端共享密钥进行目标数据传输；或者，
    基于所述第二客户端问候消息发送第三服务端反馈消息并断开连接。
  12. 根据权利要求10或11所述的方法，其中，
    所述第一客户端问候消息、第二客户端问候消息、第一服务端反馈消息、第二服务端反馈消息均包括预定义字段，所述预定义字段包括：协议版本字段、加密套件字段、加密曲线字段、第一公钥字段和第二公钥字段中的至少一种字段；
    所述协议版本字段用于指示所述客户端或所述服务端支持的部分或全部协议版本参数；
    所述加密套件字段用于指示所述客户端或所述服务端支持的部分或全部加密套件参数；
    所述加密曲线字段用于指示所述客户端或所述服务端支持的部分或全部加密曲线参数；
    所述第一公钥字段用于指示所述客户端或所述服务端的第一公钥；
    所述第二公钥字段用于指示所述客户端或所述服务端的第二公钥；
    所述第一公钥和所述第二公钥对应不同的密钥协商算法。
  13. 根据权利要求12所述的方法，其中，
    所述请求重发问候消息为第一请求重发问候消息、第二请求重发问候消息、第三请求重发问候消息、第四请求重发消息中的任一种，所述服务端问候消息为第一服务端问候消息、第二服务端问候消息中的任一种，其中，
    所述第一请求重发问候消息用于在所述服务端适用第一密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，
    所述第二请求重发问候消息用于在所述服务端适用第二密钥协商算法且支持所述第一密钥协商模式的情况下发送的；和/或，
    所述第三请求重发问候消息用于在所述服务端适用所述第二密钥协商算法且不支持所述第一密钥协商模式的情况下发送的；和/或，
    所述第四请求重发问候消息用于在所述服务适用所述第一密钥协商算法且支持第一密钥协商模式，但不支持所述第一公钥的情况下发送的；和/或，
    所述第一服务端问候消息用于在所述服务端适用所述第一密钥协商算法且支持所述第一密钥协商模式和所述第一公钥的情况下发送的。
  14. 根据权利要求13所述的方法，其中，
    所述第一请求重发问候消息包括：第一公钥字段，所述第一公钥字段为空；
    或，所述第一请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段和所述第二公钥字段均为空；
    所述第二请求重发问候消息包括：第二公钥字段，所述第二公钥字段为所述服务端的第二公钥；
    或，所述第二请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为空，所述第二公钥字段为所述服务端的第二公钥；
    所述第三请求重发问候消息包括：第二公钥字段，所述第二公钥字段为空；
    或，所述第三请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段和所述第二公钥字段均为空；
    所述第四请求重发问候消息包括：第一公钥字段，所述第一公钥字段为所述服务端的第一公钥；
    或，所述第四请求重发问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为所述服务端的第一公钥，所述第二公钥字段为空；
    所述第一服务端问候消息包括：第一公钥字段，所述第一公钥字段为所述服务端的第一公钥；
    或，所述第一服务端问候消息包括：第一公钥字段和第二公钥字段，所述第一公钥字段为所述服务端的第一公钥，所述第二公钥字段为空。
  15. 根据权利要求13所述的方法，其中，
    所述第一密钥协商算法为ECDH算法，所述第二密钥协商算法为ECJPAKE算法。
  16. 根据权利要求10或11所述的方法，其中，所述基于所述第二密钥协商模式确定第一客户端共享密钥，包括：
    所述第二密钥协商模式为使用ECDH的配网协议协商密钥；或者，所述第二密钥协商模式为ECJPAKE的配网协议。
  17. 一种客户端，所述客户端包括：
    第一发送部分，配置为发送第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
    第一获取部分，配置为获取服务端基于所述第一客户端问候消息发送的第一服务端反馈消息，所述第一反馈信息用于指示所述服务端确定的第二密钥协商模式，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
    第一确定部分，配置为确定所述客户端的共享密钥；
    第一通传输部分，配置为通过所述客户端的共享密钥进行目标数据传输。
  18. 一种服务端，所述服务端包括：
    第二接收部分，配置为接收客户端发送的第一客户端问候消息，所述第一客户端问候消息用于指示所述客户端能够支持的第一密钥协商模式；
    第二确定部分，配置为根据所述第一密钥协商模式确定所述服务端选择的第二密钥协商模式，
    第二发送部分，配置为通过所述第一服务端反馈消息发送给所述客户端，所述第一服务端反馈消息包括请求重发问候消息或服务端问候消息；
    第二确定部分，配置为确定所述服务端的共享密钥；
    第二传输部分，配置为通过所述服务端的共享密钥进行目标数据传输。
  19. 一种存储介质，存储有可执行程序，所述可执行程序被处理器执行时，实现权利要求1至16任一项所述的数据传输方法。
  20. 一种电子设备，包括存储器、处理器及存储在存储器上并能够由所述处理器运行的可执行程序，所述处理器运行所述可执行程序时执行如权利要求1至16任一项所述的数据传输方法的步骤。
PCT/CN2021/110617 2020-08-31 2021-08-04 一种数据传输方法、客户端、服务端及存储介质 WO2022042244A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21860084.9A EP4170962A4 (en) 2020-08-31 2021-08-04 DATA TRANSFER METHOD, CLIENT, SERVER AND STORAGE MEDIUM
US18/090,910 US20230171090A1 (en) 2020-08-31 2022-12-29 Data Transmission Method, And Electronic Device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010900055.3 2020-08-31
CN202010900055.3A CN114124368B (zh) 2020-08-31 2020-08-31 一种数据传输方法、客户端、服务端及存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/090,910 Continuation US20230171090A1 (en) 2020-08-31 2022-12-29 Data Transmission Method, And Electronic Device

Publications (1)

Publication Number Publication Date
WO2022042244A1 true WO2022042244A1 (zh) 2022-03-03

Family

ID=80352647

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/110617 WO2022042244A1 (zh) 2020-08-31 2021-08-04 一种数据传输方法、客户端、服务端及存储介质

Country Status (4)

Country Link
US (1) US20230171090A1 (zh)
EP (1) EP4170962A4 (zh)
CN (2) CN116318677A (zh)
WO (1) WO2022042244A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114124367B (zh) * 2020-08-31 2023-03-24 Oppo广东移动通信有限公司 一种数据传输方法、装置及存储介质
US11451949B2 (en) * 2021-06-14 2022-09-20 Ultralogic 6G, Llc Sidelink V2V, V2X, and low-complexity IoT communication in 5G and 6G

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101459506A (zh) * 2007-12-14 2009-06-17 华为技术有限公司 密钥协商方法、用于密钥协商的系统、客户端及服务器
WO2015062314A1 (zh) * 2013-11-04 2015-05-07 华为技术有限公司 密钥协商处理方法和装置
CN106411528A (zh) * 2016-10-17 2017-02-15 重庆邮电大学 一种基于隐式证书的轻量级认证密钥协商方法
US20170054555A1 (en) * 2015-08-20 2017-02-23 Alibaba Group Holding Limited Method, apparatus, terminal device and system for generating shared key
WO2017152423A1 (zh) * 2016-03-11 2017-09-14 华为技术有限公司 密钥协商方法、设备和系统
US20200153618A1 (en) * 2017-05-10 2020-05-14 Koninklijke Philips N.V. Key agreement devices and method

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101488853B (zh) * 2009-01-15 2011-04-13 赵建国 一种基于种子密钥管理的交叉认证方法
CN102447690B (zh) * 2010-10-12 2015-04-01 中兴通讯股份有限公司 一种密钥管理方法与网络设备
US9973481B1 (en) * 2015-06-16 2018-05-15 Amazon Technologies, Inc. Envelope-based encryption method
WO2018177905A1 (en) * 2017-03-29 2018-10-04 Koninklijke Philips N.V. Hybrid key exchange

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101459506A (zh) * 2007-12-14 2009-06-17 华为技术有限公司 密钥协商方法、用于密钥协商的系统、客户端及服务器
WO2015062314A1 (zh) * 2013-11-04 2015-05-07 华为技术有限公司 密钥协商处理方法和装置
US20170054555A1 (en) * 2015-08-20 2017-02-23 Alibaba Group Holding Limited Method, apparatus, terminal device and system for generating shared key
WO2017152423A1 (zh) * 2016-03-11 2017-09-14 华为技术有限公司 密钥协商方法、设备和系统
CN106411528A (zh) * 2016-10-17 2017-02-15 重庆邮电大学 一种基于隐式证书的轻量级认证密钥协商方法
US20200153618A1 (en) * 2017-05-10 2020-05-14 Koninklijke Philips N.V. Key agreement devices and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4170962A4 *

Also Published As

Publication number Publication date
US20230171090A1 (en) 2023-06-01
CN116318677A (zh) 2023-06-23
CN114124368B (zh) 2023-04-14
EP4170962A1 (en) 2023-04-26
CN114124368A (zh) 2022-03-01
EP4170962A4 (en) 2023-12-06

Similar Documents

Publication Publication Date Title
US10601594B2 (en) End-to-end service layer authentication
CN108650227B (zh) 基于数据报安全传输协议的握手方法及系统
US10158991B2 (en) Method and system for managing security keys for user and M2M devices in a wireless communication network environment
US10439991B2 (en) Communicating with a machine to machine device
WO2018177905A1 (en) Hybrid key exchange
WO2022042244A1 (zh) 一种数据传输方法、客户端、服务端及存储介质
US20200092113A1 (en) Method and System For Securing In-Vehicle Ethernet Links
US20210165885A1 (en) Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium
US20230080139A1 (en) Communication method and communications apparatus
US20240223364A1 (en) Rekeying a security association (sa)
KR20090102050A (ko) 서버 기반 이동 인터넷 프로토콜 시스템에 있어서 보안방법
CN108040071A (zh) 一种VoIP音视频加密密钥动态切换方法
US11943209B2 (en) Rekeying a security association SA
WO2022042137A1 (zh) 一种数据传输方法、装置、设备及存储介质
KR20230039722A (ko) 사전-공유 키 psk 업데이트 방법 및 장치
WO2021032304A1 (en) Gateway devices and methods for performing a site-to-site communication
CN117279119B (zh) 用于设备间无线通信的方法和通信装置
JP2023523957A (ja) 装置の再設定時のループ防止

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21860084

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021860084

Country of ref document: EP

Effective date: 20230112

NENP Non-entry into the national phase

Ref country code: DE